In recent years, the Australian Government has made great advances in bringing its business online. The benefits of government information and communications technology (ICT) systems and services becoming increasingly connected will continue as the government makes the most of new technologies. However, this new, connected way of doing business also creates opportunities for adversaries to gain an advantage by exploiting these technologies to access information of national importance.
As our intrusion detection, response, mitigation and threat assessment capabilities continue to improve, so too do the skills of cyber threat actors. This requires us to be vigilant, flexible and proactive in our approach to cyber and information security.
A strong security posture is not a trivial process-it requires ongoing vigilance and resources. By continually hardening our defences, we have a greater chance of protecting the information entrusted to us.
The Australian Government Information Security Manual (ISM) comprises three complementary documents designed to provide greater accessibility and understanding at all levels of government. This Controls document details the technical security controls which can be implemented to help mitigate security risks to agencies' information and systems.
I commend you on your agency's efforts to strengthen your cyber and information security and trust you'll continue to keep security as an agency priority.
The Australian Government Information Security Manual (ISM) is used for the risk-based application of information security controls. It provides best practice guidance for making informed risk-based technical and business decisions and implementing strong information security measures.
This section describes how to interpret the content and layout of this manual.
The purpose of this manual is to assist Australian government agencies, organisations and entities in applying a risk-based approach to protecting their information and systems. While there are other standards and guidelines designed to protect information and systems, the advice in this manual is specifically based on ASD's experience in providing cyber and information security advice and assistance to the Australian government. The controls are therefore designed to mitigate the most likely threats to Australian government agencies.
ASD encourages Australian government agencies, whether Commonwealth, state or territory, which do not fall within this list to apply the considered advice contained within this manual when selecting security controls on a case-by-case basis.
Non-government organisations and entities may also use the ISM in its entirety or as a list of controls for alternative compliance frameworks.
This manual represents the considered advice of ASD provided in accordance with its designated functions under the ISA. Therefore agencies are not required as a matter of law to comply with this manual, unless legislation, or a direction given under legislation or by some other lawful authority, compels them to comply with it.
This manual does not override any obligations imposed by legislation or law. Furthermore, if this manual conflicts with legislation or law, the latter takes precedence.
While this manual contains examples of when legislation or laws may be relevant for agencies, there is no comprehensive consideration of such issues. Accordingly, agencies should rely on their own inquiries in that regard.
Agencies deploying public systems that do not hold official, sensitive or security classified information can determine their own security measures based on their business needs, risk appetite and security risks to their systems. However, ASD encourages such agencies to use this manual, particularly the objectives, as a guide when determining security measures for their systems.
This manual uses the term 'public network infrastructure', defined as network infrastructure that an agency has no or limited control over (for example the Internet). Conversely, private network infrastructure is that which an agency controls exclusively.
However, there may be cases where a network does not precisely meet either of these definitions, a common example being the Intra Government Communications Network (ICON).
ICON provides dedicated network connectivity between Australian government agencies and has a different risk profile than both public and private network infrastructure. ICON provides additional physical and personnel security measures over general public network infrastructure. Agencies will need to consider which security mitigations to implement commensurate with their assessed level of risk. ASD recommends that, where feasible, networks whose infrastructure and devices are not wholly controlled by your agency and are vulnerable to interception or manipulation, should be treated as public network infrastructure in the context of relevant ISM controls.
Further information on ICON can be found at: http://www.finance.gov.au/collaboration-services-skills/icon/.
The three parts of the ISM are designed to complement each other and provide agencies with the necessary information to conduct informed risk-based decisions according to their own business requirements, specific circumstances and risk appetite.
The Executive Companion is aimed at the most senior executives in each agency, such as Secretaries, Chief Executive Officers and Deputy Secretaries, and comprises broader strategic messages about key cyber and information security issues.
The Principles document is aimed at Security Executives, Chief Information Security Officers, Chief Information Officers and other senior decision makers across government and focuses on providing them with a better understanding of the cyber threat environment. This document contains information to assist them in developing informed security policies within their agencies.
The Controls manual is aimed at Information Technology Security Advisors, Information Technology Security Managers, Information Security Registered Assessors and other security practitioners across government. This manual provides a set of detailed controls which, when implemented, will help agencies adhere to the higher level Principles document.
ASD provides further information security advice in the form of device-specific guides, Australian Communications Security Instructions (ACSIs) and Protect publications, such as the Strategies to Mitigate Targeted Cyber Intrusions. While these publications reflect the policy specified in this manual, not all requirements in this manual can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.
This manual uses a framework to present information in a consistent manner.
Each control in this manual has an applicability indicator that indicates the information and systems to which the control applies.
ASD maintains a System Controls Checklist to facilitate the incorporation of ISM advice into an agency's risk assessment.
James Mouat maintains a complete checklist (for all classifications) and is avaliable for free along with additional tools from his website: james.mouat.net.au/ism/
Information on the applicability of the Protective Security Policy Framework can be found at www.protectivesecurity.gov.au.
Agencies understand the risks to their information and select and implement information security measures from the ISM as part of a formal risk management process.
This section describes the expectations on Australian government agencies to include the controls contained in this manual in their existing agency risk management process.
The Australian Government Protective Security Policy Framework requires that agencies adopt a risk management approach to cover all areas of protective security activity across their agency. ASD recommends information security forms a part of an agency's broader risk management processes.
The ISM represents best practice in mitigating or minimising the threat to Australian government information and systems. However, due to the differences between government agencies, there is no one-size-fits-all model for information security. Taking a risk-based approach to information security provides agencies the flexibility to conduct their business and develop resilience in the face of a changing threat environment.
It may not be possible or appropriate for an agency to implement all controls included in this manual. Agencies will have different security requirements, business needs and risk appetites from one another. The ISM aims to assist agencies in understanding the potential consequences of non-compliance-and whether such non-compliance presents an acceptable level of risk-as well as selecting appropriate risk mitigation strategies.
Agencies should consult best practice risk assessment advice appropriate to their agency provided by the Australian Government Protective Security Policy or national and international standards.
While this manual provides controls for various technologies, not all systems will use all of the technologies mentioned. When agencies develop or procure systems they will need to determine the appropriate scope of the systems and which controls in this manual are applicable.
Not all ISM requirements can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.
This section should be read in conjunction with the Security Risk Management Plans section of the Information Security Documentation chapter. Further information on vulnerability assessments and managing change can be found in the Information Security Monitoring chapter.
Agencies must identify and analyse security risks to their information and systems.
Once information security risks have been identified and analysed, agencies will need to determine whether they are acceptable or not.
Treating a risk means that the consequences and/or likelihood of that risk is reduced. The controls included in this manual provide strategies to achieve this in different circumstances (in generic, agency and device non-specific terms).
Security risks deemed unacceptable must be treated.
Agencies must incorporate the controls contained in the Australian Government Information Security Manual in their security risk management processes.
Because an agency's risk owner - the agency head or their formal delegate - is accountable for an information or cyber security incident, they need to be made aware of any residual security risks to their information and systems through a formal approval process. Agency risk profiles will change over time as the threat environment, technology and agency business needs evolve, so it is important that any residual security risks are monitored.
Security risks deemed acceptable must be formally accepted by the responsible authority, as indicated for each control in this manual, and continually monitored by the agency.
Agencies should mitigate residual security risks through the implementation of alternative security measures.
While a baseline of controls is provided in this manual, agencies may have differing circumstances to those considered during the development of this manual. In such cases an agency needs to follow its own security risk management processes to determine its risk appetite and associated risk acceptance, risk avoidance and risk tolerance thresholds.
Agencies must determine system specific security risks that could warrant additional controls to those specified in this manual.
Documenting information security risk management activities can help an agency ensure security risks are managed in a coordinated and consistent manner. Documentation also provides a standard against which compliance can be measured.
Agencies must document identified information security risks, as well as the evaluation of those risks and mitigation strategies, in their Security Risk Management Plan.
The Australian Government Protective Security Policy Framework can be found at http://www.protectivesecurity.gov.au.
For further guidance please refer to the Australian Standard for Risk Management AS/NZS ISO 31000:2009, the Australian Standards HB 167:2006 Security risk management and HB 327:2010 Communicating and consulting about risk.
Agencies comply with ISM controls where appropriate, in accordance with their business needs, threat environment and risk appetite. Non-compliance is formally accepted by the appropriate authority.
This section explains the compliance language used in this manual and the appropriate authorities for approving non-compliance with ISM controls.
Each control specifies the authority that must provide approval for non-compliance with the control.
In most circumstances, the accreditation authority is the agency head or their formal delegate. For information on accreditation authorities, see the Conducting Accreditations section of the System Accreditation chapter.
Some controls will also require non-compliance notification to the relevant portfolio minister(s), the Attorney-General and the Auditor General as detailed in the Australian Government Protective Security Policy Framework (PSPF). These can be found in the PSPF Mandatory Requirement INFOSEC 4 Explained chapter.
There are two categories of compliance associated with the controls in this manual; 'must' and 'should'. These compliance requirements are determined according to the degree of security risk an agency will be accepting by not implementing the associated control. ASD's assessment of whether a control is a 'must' or a 'should' is based on ASD's experience in providing cyber and information security advice and assistance to the Australian government and reflect what ASD assesses the risk level to be. Agencies may have differing risk environments and requirements, and may have other mitigations in place to reduce the residual risk to an acceptable level.
Where an agency is non-compliant with multiple controls for similar reasons, they may group together these controls in their report to simplify the reporting process.
As smaller agencies may not always have sufficient personnel or budgets to comply with this manual, they may choose to consolidate their resources with another larger host agency to undertake a joint approach to compliance.
In such circumstances, smaller agencies may choose to either operate on systems fully hosted by another agency using their information security policies and security resources, or share security resources to jointly develop information security policies and systems for use by both agencies. In these cases, the requirements in this manual can be interpreted as either relating to the host agency or to both agencies, depending on the approach taken.
In situations where agencies choose a joint approach to compliance, especially when an agency agrees to fully host another agency, the agency heads may choose to seek a memorandum of understanding to formalise their security responsibilities.
All controls in this manual may be audited for compliance by the Australian National Audit Office (ANAO).
By using the latest release of this manual for system design activities, agencies will be taking steps to protect themselves from the current threats to Australian government systems.
Agencies undertaking system design activities for in-house or outsourced projects must use the latest release of this manual for security requirements.
ASD produces information security policies and guidance in addition to this manual, such as the ACSI suite, consumer guides, hardening guides and Protect publications. These may address device and scenario-specific security risks to information and systems, and accordingly may take precedence over the controls in this manual. Distinct time frames for compliance may also be specified.
Agencies must comply with additional or alternative controls as stipulated in device and scenario-specific guidance issued by ASD.
Non-compliance with 'must' and 'must not' controls are likely to represent a high security risk to information and systems. Non-compliance with 'should' and 'should not' controls are likely to represent a medium-to-low security risk to information and systems. The accreditation authority (the agency head or their formal delegate in most circumstances) is able to consider the justification for non-compliance and accept any associated residual security risk.
Non-compliance with controls where the authority is marked 'ASD' must be granted by the Director ASD.
For any control where the authority field is 'ASD', system owners must seek and be granted approval for non-compliance from the Director ASD in consultation with their accreditation authority.
System owners seeking approval for non-compliance with any control in this manual must be granted non-compliance from their accreditation authority.
If the agency head and accreditation authority form separate roles in an agency, the accreditation authority will need to ensure the agency head has appropriate oversight of the security risks being accepted on behalf of the agency. This helps to meet the PSPF's Protective Security Principles, which stipulate that agency heads need to understand, prioritise and manage security risks to prevent harm to official resources and disruption to business objectives. The authority for this control is listed as N/A as non-compliance approval cannot be sought under the ISM framework.
In circumstances where the agency head and accreditation authority roles are separate, the accreditation authority must ensure the agency head has appropriate oversight of the security risks being accepted on behalf of the agency.
Without sufficient justification, and consideration of the security risks, the agency head or their authorised delegate will lack the appropriate information to make an informed decision on whether to accept the residual security risk and grant non-compliance to the system owner.
When an agency processes, stores or communicates information on their systems that belongs to another agency or foreign government they have an obligation to inform that third party when they desire to risk manage the controls specified in this manual. If the agency fails to do so, the third party will be unaware that their information has been placed at a heightened risk of compromise. The third party is thus denied the opportunity to consider additional security measures for their information.
If a system processes, stores or communicates information from another agency, that agency should be consulted as part of seeking non-compliance with any control.
Agencies should provide a copy of their compliance and non-compliance reports to ASD.
When seeking approval for non-compliance, the system owner must provide a justification for non-compliance, outline any alternative mitigation measures to be implemented and conduct an assessment of the security risks. As the justification for non-compliance may change, and the risk environment will continue to evolve over time, it is important that the system owner update their approval for non-compliance at least every two years. This allows for the appropriate authority to have any decision to grant non-compliance either reaffirmed or, if necessary, rejected if the justification or residual security risk is no longer acceptable.
Agencies must review decisions to grant non-compliance with any control, including the justification, any mitigation measures and security risks, at least every two years or when significant changes occur to ensure its continuing relevance, adequacy and effectiveness.
Without appropriate records of decisions to grant non-compliance with controls, agencies have no record of the status of their security posture. Furthermore, a lack of such records will hinder any auditing activities that may be conducted by the agency or by external parties such as the ANAO. Failing to maintain such records is also a breach of the Archives Act 1983 (the Archives Act).
Agencies must retain a copy of decisions to grant non-compliance with any control from this manual.
ASD contact details can be found at http://www.asd.gov.au/contact.htm.
The PSPF's Protective Security Principles can be found at http://www.protectivesecurity.gov.au.
Security personnel are aware of and use security services offered in the Australian Government.
This section describes the government agencies and bodies involved in providing information security advice.
Australian Signals Directorate (ASD) is required under the Intelligence Services Act 2001 (the ISA) to perform various functions, including the provision of material, advice and other assistance to Commonwealth and state and territory authorities on matters relating to the security of information that is processed, stored or communicated by electronic or similar means.
ASD provides assistance to Commonwealth and state authorities in relation to cryptography, communications and computer technologies.
ASD works with industry to develop new cryptographic products. It has established the Australasian Information Security Evaluation Program (AISEP) to assist with the increasing requirement to evaluate products with security functionality.
ASD can be contacted for advice and assistance on implementing the controls in this manual through agency Information Technology Security Managers (ITSMs) or Information Technology Security Advisors (ITSAs).
ASD can be contacted for advice and assistance on cyber security incidents. ASD’s response will be commensurate with the urgency of the cyber security incident. Urgent and operational enquiries can be submitted through ASD’s OnSecure website or by phoning 1300 CYBER1 (1300 292 371) and selecting 1 at any time. Non-urgent and general enquiries can be submitted through the OnSecure website, by phoning 1300 CYBER1 (1300 292 371) and selecting 2 at any time, or by email at [email protected]. ASD’s incident response service is available 24 hours, 7 days a week.
ASD can be contacted by email at [email protected] for advice and assistance on the purchasing, provision, deployment, operation and disposal of High Assurance key material and High Assurance Cryptographic Equipment.
The following table contains a brief description of the other government agencies and bodies that have a role in information security in government.
|AGENCY OR BODY||SERVICES|
|Attorney-General's Department (AGD)||Responsible for information security policy and cyber security incident preparedness, response and recovery arrangements across government.|
|Australian Federal Police (Australian High Tech Crime Centre)||Responsible for law enforcement in relation to electronic and other high tech crimes.|
|Australian Cyber Security Centre (ACSC)||Leads the Australian government’s operational response to cyber security incidents, organises national cyber security operations and resources, encourages and receives reporting of cyber security incidents, raises awareness of the threat to Australia and study and investigates cyber threats. the ACSC includes representatives from ASD, the Australian Crime Commission (ACC), the Australian Defence Force (ADF), the Australian Federal Police (AFP), the Australian Security Intelligence Organisation (ASIO), the Computer Emergency Response Team (CERT) Australia and the Defence Intelligence Organisation (DIO).|
|Australian National Audit Office (ANAO)||Responsible for performance audits on information security.|
|Australian Security Intelligence Organisation (ASIO)||Responsible for collecting, analysing and reporting intelligence on threats to security.|
|ASIO-T4 Protective Security||Provides advice and training, technical surveillance counter-measures, physical security certifications, protective security risk reviews and physical security equipment testing.|
|CERT Australia||Provides the private sector with information and assistance to help them protect their Information and communications technology (ICT) infrastructure from cyber threats and vulnerabilities. CERT Australia also provides a coordination role during a serious cyber incident.|
|Cyber Security Operations Board||Provides strategic direction and oversight of operational cyber security matters. Chairmanship and Secretariat support provided by the Attorney-General’s Department.|
|Cyber Security Policy and Coordination Committee||Coordinates the development of cyber security policy for the Australian Government.|
|Department of Communications||Responsible for initiatives to educate and protect home users, students and small business from electronic intrusions and fraud.|
|Department of Finance||Development and oversight of whole-of-government policy on the Australian Government's use of information and communications technology.|
|Department of Foreign Affairs and Trade||Responsible for policy and advice for security overseas.|
|Department of the Prime Minister and Cabinet||Leads development of cyber and information security policy across the Australian Government. Responsible for implementation of the Cyber Security Strategy (2016). National Roadmap: 2020 Vision.|
|National Archives of Australia||Provides standards and advice on capturing and managing records to ensure their integrity as evidence is maintained. The National Archives also authorises the disposal of all Commonwealth records, including those relating to ICT and security processes and incidents.|
|Protective Security Policy Committee||Coordinates the development of protective security policy. Chairmanship and Secretariat support provided by the Attorney-General’s Department.|
|Security Construction and Equipment Committee||Oversees the evaluation of physical security equipment.|
If security personnel are unaware of the roles government organisations play in the information security space, they could miss out on valuable insight and assistance in developing effective security measures.
Security personnel should familiarise themselves with the information security roles and services provided by Australian government agencies and bodies.
Information technology service providers implement appropriate security measures to protect government information.
This section describes information on outsourcing information technology services, including general information technology or cloud computing.
In the context of this section, general information technology services encompass business process services, application processes and infrastructure services. The range of information technology services that can be procured from a source outside an organisation is extensive.
The terminology and definitions used in this section for cloud computing services are consistent with The National Institute of Standards and Technology (NIST) Definition of Cloud Computing, Special Publication 800-145, September 2011. This section also applies to cloud services that have a payment model which differs to the NIST pay-per-use measured service characteristic.
Where service providers have access to, or control over, Australian government personnel, information or assets, agencies are required to ensure that the service providers comply with Australian government protective security policies and procedures, as described in mandatory requirement GOV 12 in the Australian Government Protective Security Policy Framework (PSPF) produced by the Attorney-General’s Department.
PSPF Protective security governance guidelines - Security of outsourced services and functions provides agencies with guidance for incorporating protective security requirements into contracts when outsourcing agency functions.
Outsourcing can be a cost-effective option for providing general information technology services in an agency, as well as potentially delivering a superior service; however, it can also affect an agency’s risk profile. Storing information in multiple disparate locations and allowing more people to access it can significantly increase the potential for information compromise.
Agencies intending to use service providers not on ASD's Certified Cloud Services List (CCSL) must ensure that service providers are located in Australia.
Agency data and computing environments must not be accessed, configured or administered from outside Australian borders by a service provider unless a contractual arrangement exists between the service provider and customer to do so.
Using outsourced cloud services can affect an agency’s risk profile. Cloud services located offshore may be subject to lawful and covert collection, without the information owner’s knowledge. Additionally, use of offshore cloud services introduces jurisdictional risks as foreign countries’ laws could change with little warning. Further, foreign owned cloud service providers operating in Australia may be subject to a foreign government’s lawful access. A comprehensive risk assessment is essential in identifying and managing jurisdictional, governance, privacy, technical and security risks.
The risks of using outsourced cloud services, including those in ASD's cloud computing advice, must be assessed and documented.
ASD maintains a Certified Cloud Services List (CCSL), which lists cloud services certified against security and governance requirements.
This can be found via the ASD website at http://www.asd.gov.au.
Agencies must only use outsourced cloud services listed on ASD’s CCSL.
Agencies proposing to use outsourced cloud services not listed on ASD's CCSL must notify ASD in writing at the earliest opportunity and certainly before entering into or renewing a contract with a cloud service provider.
Agencies must notify ASD in writing at the earliest opportunity during the initial stages of considering using a cloud service and certainly prior to entering or renewing a contract with a cloud service provider.
Both cloud and general information technology service providers can be provided with government information as long as their systems are accredited to process, store and communicate that information. Further information on accrediting systems can be found in the System Accreditation chapter of this manual.
Service providers' systems that are used to provide information technology services, including outsourced cloud services, must be accredited prior to handling government information.
Agency privacy and security obligations for protecting government information are no different when using an outsourced information technology service, either cloud or general. The contract or service agreement between a service provider and their customer must address mitigations to governance, privacy and security risks, otherwise the customer only has service provider promises and marketing claims that can be hard to verify and may be unenforceable.
Any measures associated with the protection of information entrusted to another party must be documented in contract provisions, a memorandum of understanding or equivalent formal agreement between parties.
Although data ownership resides with the agency, this can become less clear in some circumstances, such as when legal action is taken and a service provider is asked to provide access to, or data from, their assets. To mitigate the risk of agency data being unavailable or compromised, agencies can explicitly retain ownership of their data through contract provisions.
When entering into a contract or other agreement for information technology services, agencies should explicitly retain contractual ownership over their data.
Agencies should determine whether security measures need to be taken to mitigate the threats arising from potential supply chain exploitation. In doing so, they should consider the risks that arise as systems and software are being built and delivered, as well as the degree of risk that a particular supplier may introduce into the delivery of a contracted service. The globalised nature of ICT products increases the difficulty in evaluating supply chain integrity. Adopting a risk management approach will assist in circumstances where agencies are not able to acquire all the information necessary to do a complete risk assessment.
Agencies should perform a due diligence review of suppliers, including their country of origin, before obtaining software, hardware or services, to assess the potential increase to agency security risk profiles.
Information on Australian Government expectations when outsourcing services and functions can be found in the Attorney-General’s Department’s Security of outsourced services and functions guidelines publication at http://www.protectivesecurity.gov.au/governance/contracting/Pages/Supporting-guidelines-for-contracting.aspx..
The National Institute of Standards and Technology (NIST) Special Publication 800-161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations can be found at http://csrc.nist.gov/publications/PubsDrafts.html.
ASD’s cloud computing advice and Certified Cloud Services List is available on ASD’s public website at http://www.asd.gov.au.
Whole-of-government policy and guidance on cloud computing, including detailed legal and financial considerations for contracts, can be found on the Department of Finance’s website at http://www.finance.gov.au/cloud/.
The Attorney-General’s Department’s Risk management of outsourced ICT arrangements (including Cloud) is available at http://www.protectivesecurity.gov.au/informationsecurity/Pages/riskmanagementofoutsourcedIctarrangements-Includingcloud.aspx.
The NIST Definition of Cloud Computing, Special Publication 800-145, can be accessed from the NIST website at http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
The Chief Information Security Officer (CISO) sets the strategic direction for information security for their agency.
This section describes the information security role of a CISO.
The CISO role is intended to be performed by the Security Executive, which is a position mandated by the Australian Government Protective Security Policy Framework (PSPF) in each agency at Senior Executive Service (or equivalent) level. Agencies are not required to create a new dedicated position to perform the CISO role. The CISO role was introduced in addition to the other PSPF requirements to provide a more meaningful title for the Security Executive’s responsibilities that relate specifically to information security.
The role of the CISO is based on industry best practice and has been introduced to ensure that information security is managed at the senior executive level.
Agencies must appoint a senior executive, commonly referred to as the CISO, who is responsible for coordinating communication between security and business functions, as well as manage and understand the application of controls and security risk management processes.
The Information Technology Security Advisor (ITSA) coordinates information technology security for their agency.
This section describes the information security role of the ITSA.
The ITSA is responsible for information technology security management across the agency, and acts as the first point of contact for the CISO or equivalent, and external agencies on any information technology security management issues.
The ITSA is also an Information Technology Security Manager (ITSM) - see the Information Technology Security Managers section of this chapter. The ITSA is the particular ITSM who has been designated as having these additional agency-wide technology security management responsibilities.
The ITSA retains full responsibility for their role as an ITSM in addition to ITSA responsibilities, and has the added responsibility of coordinating other ITSMs to ensure that security measures and efforts are undertaken in a coordinated manner.
Agencies must designate an ITSM as the ITSA, to have responsibility for information technology security management across the agency.
As security personnel in agencies need to communicate with security personnel from other agencies, often to provide warnings of threats to their systems, it is important that a consistent contact method is available across government to facilitate such communication.
Agencies should maintain an email address for their ITSA in the form of [email protected]
Further information on the role of ITSAs is available in the Attorney-General’s Department’s Protective Security Governance Guidelines, available at http://www.protectivesecurity.gov.au
Information Technology Security Managers (ITSMs) provide information security leadership and management for their agency.
This section describes the information security role of ITSMs.
ITSMs are executives that coordinate the strategic directions provided by the CISO and the technical efforts of Information Technology Security Officers (ITSOs). The main area of responsibility of an ITSM is the day-to-day management of information security within an agency.
Agencies must appoint at least one executive, commonly referred to as an ITSM, to manage the day-to-day operations of information security within the agency, in line with the strategic directions provided by the CISO or equivalent.
ITSOs provide information security operational support for their agency.
This section describes information security role of ITSOs.
ITSOs implement technical solutions under the guidance of an ITSM to ensure that the strategic direction for information security within the agency is achieved.
The ITSO role may be combined with that of the ITSM. Small agencies may choose to assign both ITSM and ITSO responsibilities to one person under the title of the ITSA. Furthermore, agencies may choose to have this role performed by existing system administrators with an additional reporting chain to an ITSM for the security aspects of their role.
Appointing a person with responsibility for ensuring the technical security of systems is essential to manage compliance and non-compliance with the controls in this manual. The main responsibility of ITSOs is the implementation and monitoring of technical security measures for systems.
Agencies must appoint at least one officer, commonly referred to as an ITSO, who is expert in administering and configuring a broad range of systems as well as analysing and reporting on information security issues.
System owners obtain and maintain accreditation of their systems.
This section describes the information security role of system owners.
The system owner is the person responsible for an information resource.
While the system owner is responsible for the operation of the system, they will delegate the day-to-day management and operation of the system to a system manager or managers.
While it is strongly recommended that a system owner is a member of the Senior Executive Service, or in an equivalent management position, it does not imply that the system managers should also be at such a level.
Each system must have a system owner who is responsible for the operation of the system.
System owners should be a member of the Senior Executive Service or in an equivalent management position.
The system owner is responsible for the secure operation of their system and needs to ensure it is accredited. If modifications are undertaken to a system the system owner will need to ensure that the changes are undertaken and documented in an appropriate manner, and that any necessary reaccreditation activities are completed.
System owners must obtain and maintain accreditation for their systems.
Information security documentation is produced for systems to support the accurate and consistent application of policy and procedures within an agency.
This section describes the information security documentation that government agencies should develop and maintain.
The suite of documents outlined in this chapter forms the Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
Documentation is vital to any information security regime as it supports the accurate and consistent application of policy and procedures within an agency. Documentation also provides increased accountability and a standard against which compliance can be measured.
Documentation that has been created for alternative compliance frameworks but fulfils the purpose specified in this chapter can be used to satisfy the controls in this chapter. Rather, the documentation framework should make this apparent.
Documentation may be presented in a number of formats including dynamic content such as wikis, intranets or other forms of document repositories. More detailed information about each document can be found in the relevant sections of this chapter.
The Information Security Policy (ISP) is a statement of high-level information security policies and is therefore an essential part of information security documentation.
Agencies must have a document that fulfils the purpose of an ISP.
The Security Risk Management Plan (SRMP) is a best practice approach to identifying and reducing potential security risks. Depending on the documentation framework chosen, multiple systems could refer to, or build upon, a single SRMP.
Every system must be covered by a document that fulfils the purpose of an SRMP.
The System Security Plan (SSP) describes the implementation and operation of controls for a system. It is derived by selecting relevant controls from the ISM with additional controls based on the security risks identified in the associated SRMP. Depending on the documentation framework chosen, some details common to multiple systems could be consolidated in a higher level SSP.
Every system must be covered by a document that fulfils the purpose of an SSP.
Standard Operating Procedures (SOPs) provide a step-by-step guide to undertaking security related tasks. They provide assurance that tasks can be undertaken in a repeatable manner, even by users without detailed knowledge of the system. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.
SOPs should be developed for systems.
Having an Incident Response Plan (IRP) ensures that when a cyber security incident occurs, a plan is in place to respond appropriately to the situation. In most situations, the aim of the response will be to preserve any evidence relating to the cyber security incident and to prevent the incident escalating.
Agencies must develop, maintain and implement a document that fulfils the purpose of an IRP and any required supporting procedures.
It is likely that personnel who are most knowledgeable about both information security issues and the business requirements will develop the most useful and accurate information security documentation.
Information security documentation should be developed by personnel with a good understanding of both the subject matter and the business requirements.
As the SRMP, SSP, SOPs and IRP form a documentation suite for a system, it is essential that they are logically connected and consistent. Furthermore, each documentation suite developed for a system will need to be consistent with the ISP.
SRMP, SSP, SOPs and IRP should be logically connected and consistent for each system and with the ISP.
Having a documentation framework for information security documents ensures that they are accounted for and maintained appropriately. Furthermore, the framework can be used to describe relationships between documents, especially when higher level documents are used to avoid repetition of information in lower level documents.
Agencies should create and maintain a document framework including a hierarchical listing of all information security documentation and their relationships.
Agencies should adopt the naming conventions provided in this manual for their information security documentation.
Agencies outsourcing the development of information security documentation still need to review and control the contents to make sure it meets their requirements.
If information security policy does not have formal approval, security personnel will have difficulty ensuring appropriate systems security procedures are in place. Having formal approval not only assists in the implementation of procedures, it also ensures senior managers are aware of information security issues and security risks.
All information security documentation should be formally approved by a person with an appropriate level of seniority and authority.
Stakeholders will not be able to make required changes to security measures if they are not made aware of new information security documentation or changes to existing information security documentation.
Once information security documentation has been approved it should be published and communicated to all stakeholders.
The threat environment and agencies’ businesses are dynamic. If an agency fails to keep their information security documentation current to reflect the changing environment, their security measures and processes may cease to be effective. In that situation, resources could be devoted to areas that have reduced effectiveness or are no longer relevant.
Agencies should record the date of the most recent review on each information security document.
The ISP sets the strategic direction for information security for an agency.
This section describes the development of an ISP.
ISPs are a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.
In developing the contents of the ISP, agencies may also consult any agency specific directives that could be applicable to information security.
Agencies should avoid including controls for systems in their ISP. Instead, they should be documented in the SSP.
The ISP should describe information security policies, standards and responsibilities.
A SRMP identifies security risks and appropriate mitigation measures for systems.
This section describes the development of a SRMP, focusing on security risks related to the operation of systems.
A SRMP is a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
This section should be read in conjunction with the Information Security Risk Management section of the About Information Security chapter.
Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.
Security risks cannot be managed if they are not known. Even if they are known, failing to deal with them is a failure of security risk management. For this reason a SRMP consists of two components, a security risk assessment and a corresponding risk treatment strategy.
The SRMP should contain a security risk assessment and a corresponding risk treatment strategy.
If an agency fails to incorporate the SRMP for systems into their wider agency risk management plan then the agency will be unable to manage risks in a coordinated and consistent manner across the agency.
Agencies should incorporate their SRMP into their wider agency risk management plan.
Standards Australia produces AS/NZS ISO 31000:2009, Risk Management - Principles and guidelines while the ISO/IEC has developed the risk management standard ISO/IEC 27005:2011, Information technology - Security techniques - Information security risk management, as part of the ISO/IEC 27000 family of standards.
Agencies should develop their SRMP in accordance with Australian or international standards for risk management.
For further guidance please refer to the Australian Standard for Risk Management AS/NZS ISO 31000:2009, the Australian Standards HB 167:2006 Security risk management and HB 327:2010 Communicating and consulting about risk.
Information on the development of SRMPs can be found in HB 231:2004, Information security risk management guidelines. In particular, section 5 discusses documentation. It is available from Standards Australia at http://www.standards.org.au/.
A SSP specifies the security measures for systems.
This section describes the development of a SSP.
A SSP is a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.
Further information to be included in a SSP about specific functionality or technologies that could be implemented for a system can be found in the applicable areas of this manual.
This manual provides a list of controls that are potentially applicable to a system based on its classification, its functionality and the technology it is implementing. Agencies need to determine which controls are in scope of the system and translate those controls to the SSP. These controls will then be assessed on their implementation and effectiveness during the accreditation process for the system.
ASD continually monitors the threat environment and conducts research into the security impact of emerging trends. With each release of this manual, controls can be added, rescinded or modified depending on changes in the threat environment. When performing accreditations against the latest release of this manual, agencies are ensuring that they are taking the most recent threat environment into consideration.
Agencies must select controls from this manual to be included in the SSP based on the scope of the system with additional system specific controls being included as a result of the associated SRMP or higher level SSP.
Agencies must use the latest release of this manual when developing, and updating, their SSPs as part of accreditation and reaccreditation of their systems.
Further information on the Australian Government Information Security Management Protocol can be found at http://www.protectivesecurity.gov.au.
SOPs ensure security procedures are followed in an appropriate and repeatable manner.
This section describes the development of security related SOPs.
SOPs are a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
To ensure that personnel undertake their duties appropriately, with a minimum of confusion, it is important that the roles of ITSMs, ITSOs, system administrators and users are covered by SOPs. Furthermore, ensuring that SOPs are consistent with SSPs reduces the potential for confusion resulting from conflicts in policy and procedures.
The ITSM SOPs cover the management and leadership activities related to system operations.
The following procedures should be documented in the ITSM's SOPs.
|Topic||Procedures to be Included|
|Cyber security incidents||Reporting and managing cyber security incidents|
The ITSO SOPs cover the operationally focused activities related to system operations.
The following procedures should be documented in the ITSO's SOPs.
|Topic||Procedures to be Included|
|Access control||Authorising access rights to applications and data|
|Asset musters||Labelling, registering and mustering assets, including media|
|Audit logs||Reviewing system audit trails and manual logs, particularly for privileged users|
|Configuration control||Approving and releasing changes to the system software or configurations|
|Cyber security incidents||Detecting potential cyber security incidents|
|Establishing the cause of any cyber security incident, whether accidental or deliberate|
|Actions to be taken to recover and minimise the exposure from a cyber security incident|
|Data transfers||Managing the review of media containing information that is to be transferred off-site|
|Managing the review of incoming media for viruses or unapproved software|
|ICT equipment||Managing the destruction of unserviceable ICT equipment and media|
|System integrity audit||Reviewing user accounts, system parameters and access controls to ensure that the system is secure|
|Checking the integrity of system software|
|Testing access controls|
|Inspecting ICT equipment and cables|
|System maintenance||Managing the ongoing security and functionality of system software, including: maintaining awareness of current software vulnerabilities, testing and applying software patches/updates/signatures, and applying appropriate hardening techniques|
|User account management||Authorising new users|
The system administrator SOPs support the ITSO SOPs; however, they focus on the administrative activities related to system operations.
The following procedures should be documented in the system administrator's SOPs.
|Topic||Procedures to be Included|
|Access control||Implementing access rights to applications and data|
|Configuration control||Implementing changes to the system software or configurations|
|System backup and recovery||Backing up data, including audit logs|
|Securing backup tapes|
|Recovering from system failures|
|User account management||Adding and removing users|
|Setting user privileges|
|Cleaning up directories and files when a user departs or changes roles|
The user SOPs focus on day-to-day activities that users need to know about, and comply with, when using systems.
The following procedures should be documented in the user's SOPs.
|Topic||Procedures to be Included|
|Cyber security incidents||What to do in the case of a suspected or actual cyber security incident|
|End of day||How to secure systems at the end of the day|
|Media control||Procedures for handling and using media|
|Passphrases||Choosing and protecting passphrases|
|Temporary absence||How to secure systems when temporarily absent|
When SOPs are produced, the intended audience needs to be made aware of their existence and acknowledge that they have read, understood and agree to abide by their contents. Additionally, the intended audience needs to be made aware of any consequences for deviating from the agreed SOP.
ITSMs, ITSOs, system administrators and users should sign a statement that they have read and agree to abide by their respective SOPs.
An IRP outlines actions to take in response to a cyber security incident.
This section describes the development of an IRP to address cyber security incidents. It does not cover physical security incidents.
An IRP is a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
The guidance provided on the content of an IRP ensures that agencies have a baseline to develop an IRP with sufficient flexibility, scope and level of detail to address the majority of cyber security incidents that could arise.
Information and systems are secured before personnel evacuate a facility in the event of an emergency, where it is safe to do so.
This section describes the requirements for securing information and systems as part of the procedures for evacuating a facility in the event of an emergency.
Emergency procedures are a component of an agency’s Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.
During the evacuation of a facility it is important that personnel secure information and systems as they would at the end of operational hours. This includes, but is not limited to, securing media and logging off workstations. This is important as a malicious actor could use such an opportunity to gain access to applications or databases that a user had already authenticated to, or use another user’s credentials, for a malicious purpose.
Agencies must include in evacuation procedures the requirement to secure information and systems before the evacuation; unless the chief warden, to avoid serious injury or loss of life, authorises personnel to evacuate immediately without securing information and systems.
The warning phase before the evacuation of a facility alerts personnel that they may be required to evacuate the facility. This warning phase is the ideal time for personnel to begin securing information and systems to ensure that if they need to evacuate the facility they can do so immediately.
Agencies should include in evacuation procedures the requirement to secure information and systems during the warning phase before the evacuation.
Business continuity and disaster recovery plans help minimise the disruption to the availability of information and systems after an event or disaster.
This section describes the role of business continuity and disaster recovery plans in ensuring continuing operation of agencies’ critical systems.
Business continuity and disaster recovery plans work to maintain security in the face of unexpected events and changes.
Additional information relating to business continuity can be found in the Service Continuity for Online Services section of the Network Security chapter.
As availability requirements will vary based on business requirements they cannot be stipulated in this manual. Agencies will need to determine their own availability requirements and implement appropriate security measures to achieve them.
Agencies must determine availability requirements for their systems and implement appropriate security measures to support these requirements.
Having a backup strategy in place is an important part of business continuity planning. The backup strategy ensures that critical business information is not accidentally lost. Mechanisms must be implemented to mitigate the risk of agency data being unavailable due to compromise or deletion. Such mechanisms include storing backups offline where practical.
Developing a business continuity plan can help ensure that critical functions of systems continue to operate when the system is in a degraded state. For example, when limited bandwidth is available on networks, agencies may choose to strip all large attachments from emails. This is a mandatory requirement of the PSPF.
Agencies must develop a business continuity plan.
Developing a disaster recovery plan will reduce the time between a disaster occurring and critical functions of systems being restored.
Agencies should develop a disaster recovery plan.
Additional information relating to business continuity is contained in ISO 22301:2012, Societal security – Business continuity management systems – Requirements and ISO 22313: 2012, Societal security – Business continuity management systems - Guidance.
Accreditation formally recognises and accepts the residual security risk to a system as well as the information that it processes, stores or communicates.
This section details the accreditation process for systems, where a system is defined as a related set of hardware and software used for the processing, storage or communication of information and the governance framework in which it operates.
Accreditation is the process by which the accreditation authority formally recognises and accepts the residual security risk to a system and the information it processes, stores and communicates.
Detailed information about the processes and the requirements for conducting accreditations is given in this section. Information about certification and security assessments or audits is given in the Conducting Certifications and Conducting Security Assessments sections of this chapter.
For TOP SECRET systems the accreditation authority is ASD.
For SECRET and below systems the accreditation authority is the organisation head or their formal delegate, which is strongly recommended to be the CISO or equivalent.
For systems that process, store or communicate caveated or compartmented information there may be a mandated accreditation authority external to the organisation operating the system.
For multinational and multi-organisation systems the accreditation authority is determined by a formal agreement between the parties involved.
For commercial providers providing services to organisations the accreditation authority is the head of the supported organisation or their authorised delegate, which is strongly recommended to be the CISO or equivalent.
In all cases the accreditation authority will be at least a senior executive who has an appropriate level of understanding of the security risks they are accepting on behalf of the organisation.
Depending on the circumstances and practices of an organisation, the organisation head can choose to delegate their authority to multiple senior executives who have the authority to accept security risks for specific business functions.
Accreditation for a system is awarded when the accreditation authority formally recognises and accepts the residual security risk to a system and its information, and gives formal approval for the system to operate. However, in some cases the accreditation authority may not accept the residual security risk due to security risks and measures being inadequately identified or implemented for the system. In such cases the accreditation authority may request that further work be undertaken by the system owner before reconsidering the system for accreditation. In the intervening time, the accreditation authority may choose to issue an interim approval to operate with caveats placed on the system’s use.
The following diagram shows, at a high level, the process of accreditation.
Developing and implementing an accreditation framework ensures that accreditation activities are conducted in a repeatable and consistent manner across the agency.
An accreditation framework must be developed and implemented.
Systems must be awarded accreditation before they are used to process, store or communicate sensitive or classified information.
Systems must not process, store or communicate information above the sensitivity or classification for which the system has received accreditation.
Systems must not process, store or communicate caveated or compartmented information unless specifically accredited for such purposes.
To ensure the accreditation authority can appropriately perform their duties, they will need to hold a senior position within the organisation and have an appropriate level of understanding of the security risks they are accepting for a system.
For multinational and multi-agency systems, determining the certification and accreditation authorities through a formal agreement between the parties ensures that the system owner has appropriate points of contact and does not receive conflicting advice from different authorities.
For multinational and multi-agency systems, the certification and accreditation authorities should be determined by a formal agreement between the parties involved.
An agency's accreditation authority must be at least a senior executive with an appropriate level of understanding of the security risks they are accepting on behalf of the agency.
For TOP SECRET systems, the accreditation authority must be ASD.
In advising the certification and accreditation authorities of their intent to seek certification and accreditation for a system, the system owner can seek information on the latest processes and requirements for their system.
Before beginning the accreditation process, the system owner should advise the certification and accreditation authorities of their intent to seek certification and accreditation for their system.
Certification (described in the Conducting Certifications section of this chapter provides the accreditation authority with information on the security posture of a system. This allows the accreditation authority to make an informed decision on whether the residual security risk of allowing the system to operate is acceptable.
All systems must undergo certification as part of the accreditation process; unless the accreditation authority is satisfied that if the system is not immediately operational it would have a devastating and potentially long-lasting effect on operations.
The purpose of conducting an accreditation of a system is to determine the security posture of the system and the security risk that it poses to information. In giving approval for the system to operate, the accreditation authority is accepting the residual security risk to information that is processed, stored or communicated by the system.
To assist in making an informed accreditation decision, the accreditation authority may also seek advice from technical experts on the technical components of information presented to them during the accreditation process.
The accreditation authority must accept the residual security risk to a system and the information it processes, stores or communicates in order to award accreditation.
Threat environments and business needs are dynamic. Agencies should reaccredit their systems every two years to ensure their security measures are appropriate in the current environment, as security measures and processes may cease to be effective over time.
Once three years have elapsed since the last accreditation, the agency needs to either reaccredit the system or seek approval for non-compliance from their accreditation authority.
While regular accreditation activities are highly beneficial in maintaining the security posture of a system, other activities may necessitate a need for an accreditation outside of regularly scheduled timeframes.
To assist in the reaccreditation of systems, agencies are encouraged to reuse as much information from previous accreditations as possible including, where appropriate, concentrating on the difference between the security posture of the system at the time of the last accreditation and the current security posture of the system.
Agencies should ensure that the period between accreditations of systems does not exceed two years.
Agencies must ensure that the period between accreditations of systems does not exceed three years.
For agencies wishing to gain a physical security certification for Sensitive Compartmented Information Facility (SCIF) areas in addition to their ICT certification, a SCIF Support Pack is available from ASD on request.
Certification formally recognises and accepts that the security measures for a system have been implemented effectively.
This section describes conducting a certification as part of the accreditation process for a system.
Certification is the process by which a certification authority formally recognises and accepts that the security measures for a system have been implemented effectively.
The outcome of certification is a certification report to the accreditation authority outlining the security measures that have been implemented for a system and the residual risk it poses to the system and the information that it processes, stores or communicates.
For TOP SECRET systems the certification authority is ASD.
For SECRET or below systems the certification authority is the agency ITSA.
For systems that process, store or communicate caveated or compartmented information there may be a mandated certification authority external to the agency operating the system.
For multinational and multi-agency systems the certification authority is determined by a formal agreement between the parties involved.
For commercial providers providing services to agencies, the certification authority is the ITSA of the agency sponsoring the provider.
For providers of gateway services, either government or commercial, intended for use by multiple agencies across government, ASD performs the role of the certification authority as an independent third party.
A security assessment reviews the system architecture and assesses the actual implementation and effectiveness of security measures.
All systems must undergo a security assessment as part of the certification process.
To award certification for a system the certification authority needs to be satisfied that the security measures identified by the system owner have been implemented and are operating effectively. However, certification only acknowledges that the identified security measures were implemented and are operating effectively and not that the residual security risk is acceptable or an approval to operate has been awarded.
The certification authority must accept the effectiveness of security measures for the system in order to award certification.
To assist the accreditation authority in determining whether to award accreditation for a system or not, the certification authority will need to produce a certification report outlining the security measures that have been implemented for the system and an assessment of the residual security risk relating to the system and information that it processes, stores or communicates.
The certification authority should produce a certification report for the accreditation authority outlining the security measures that have been implemented for a system and an assessment of the residual security risk relating to the system and the information that it processes, stores or communicates.
Agencies may provide their own gateway services, or outsource this function to a commercial provider. In either case, gateway services intended for use by multiple agencies are required to undergo a security assessment, conducted by a member of the Information Security Registered Assessor Program (IRAP) and be awarded certification from ASD. However, even though ASD may award certification to a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.
Commercial or government-provided gateway services intended for use by multiple agencies must undergo an Information Security Registered Assessor Program (IRAP) security assessment and be awarded certification by ASD at least every two years.
Cloud services are required to undergo a security assessment, conducted by an IRAP Assessor and be awarded certification from ASD. However, even though ASD may award certification to a cloud service, agencies using the cloud service still need to decide whether accreditation should be awarded or not. Cloud services are only permitted to handle Australian government information if they have been certified by ASD and accredited by agencies intending to use the cloud service.
Cloud services storing, processing or communicating Australian government information must undergo an Information Security Registered Assessor Program security assessment and be awarded certification by ASD at least every two years.
ASD's cloud computing advice and Certified Cloud Services List is available on ASD's public website at http://www.asd.gov.au.
The implementation and effectiveness of security measures for a system is assessed.
This section describes conducting a security assessment, as part of the certification process for a system.
The aim of a security assessment is to review the system architecture and assess the actual implementation and effectiveness of security measures.
The outcome of a security assessment is a report to the certification authority describing the implementation and effectiveness of security measures for a system. This includes areas of compliance and non-compliance for a system and any suggested remediation actions.
Security assessments for TOP SECRET systems can only be undertaken by ASD or IRAP Assessors.
Security assessments for SECRET and below systems can be undertaken by organisation ITSMs and IRAP Assessors.
A number of agencies and personnel are often consulted during a security assessment.
The ASA can also be consulted on personnel security aspects of systems.
An ITSM or communications security officer can be consulted on communications security aspects of systems.
A security assessment can be conducted by an agency’s own assessors. However, the agency may choose to add an extra level of objectivity by engaging the services of an IRAP Assessor to undertake the security assessment.
Connections to certain inter-agency systems could require an independent security assessment from an IRAP Assessor as a prerequisite to certification. Such requirements can be obtained from the inter-agency system owners.
As there can be a perceived conflict of interest if the system owner assesses the security of their own system, the assessor should be independent of the system owner and certification authority. This does not preclude an appropriately qualified system owner from assessing the security of a system that they are not responsible for.
Assessors of systems should not also be the system owner or certification authority.
It is important that the system owner has approved the system architecture and associated information security documentation before a security assessment is undertaken. This assists assessors in understanding the scope of work for the first stage of the assessment.
Before undertaking the security assessment, the system owner must approve the system architecture and associated documentation.
The purpose of a security assessment, also known as an audit, is two-fold: to determine that the system architecture is based on sound security principles and to determine whether the security measures chosen have been implemented and are operating effectively.
The system architecture, including associated documentation, must be reviewed by the assessor to determine whether it is based on sound security principles.
The security measures for the system must be reviewed by the assessor to determine whether they have been implemented and are operating effectively.
The assessor must ensure that, where applicable, a currently valid physical security certification has been awarded by an appropriate physical security certification authority.
To assist the certification authority in determining whether to award certification for a system or not, the assessor will need to produce a report outlining areas of concern for the system including any suggested remediation actions.
The assessor must produce a report for the certification authority outlining areas of non-compliance for a system and any suggested remediation actions.
Policy and Procedures for the Information Security Registered Assessors Program contains a definition of the range of activities IRAP Assessors are authorised to perform. It can be obtained from ASD’s website at http://www.asd.gov.au/irap.
Vulnerability management activities contribute to the security of systems.
This section describes agencies' requirements for conducting vulnerability management activities for their systems.
Information security monitoring practices can help ensure that new vulnerabilities are addressed and security is maintained through unforeseen events and changes, whether internal to the system or in the system's operating environment. Such practices allow agencies to be proactive in identifying, prioritising and responding to security risks. Measures to monitor and manage vulnerabilities in, and changes to, a system can provide an agency with a wealth of valuable information about its level of exposure to threats, as well as assisting agencies in keeping up to date with industry and product advances.
Vulnerability management activities will feed into an agency's wider risk management processes. Further information on risk management can be found in the About Information Security chapter and the Security Risk Management Plans section of the Information Security Documentation chapter.
Undertaking vulnerability management activities such as regular vulnerability assessments, analysis and mitigation are important as threat environments change over time. Vulnerability assessments allow agencies to identify security weaknesses caused by misconfigurations, bugs or flaws.
Conducting vulnerability assessments prior to systems being used, and after significant changes, can allow the agency to establish a baseline for further information security monitoring activities.
Conducting vulnerability assessments annually can help ensure that the latest threat environment is being addressed and that systems are configured in accordance with associated information security documentation.
It is recommended that vulnerability assessments are conducted by suitably skilled personnel independent of the target of the assessment. Such personnel can be internal to an agency, such as an IT security team, or a third party such as an IRAP Assessor. Where possible, it is advisable that system managers do not conduct vulnerability assessments themselves. This ensures that there is no conflict of interest, perceived or otherwise, and that the assessment is undertaken in an objective manner.
Agencies should have vulnerability assessments conducted by suitably skilled personnel independent of the target of the assessment or by an independent third party.
Agencies will find it useful to gather appropriate information before they start a vulnerability assessment. This will help to ensure that the assessment is undertaken to a degree that is commensurate with the threat environment, and if applicable, the sensitivity or classification of information that is involved.
Agencies are encouraged to monitor information about new vulnerabilities that could affect their systems. However, if no vulnerabilities are disclosed in specific products used in their systems it is important agencies are not complacent.
Vulnerabilities can be introduced as a result of poor security practices, implementations or accidental activities. Therefore, even if no new vulnerabilities in deployed products have been disclosed there is still value to be gained from conducting regular vulnerability analysis.
Furthermore, by monitoring vulnerability sources/alerts, conducting vulnerability analysis, keeping up to date with industry and product advances, and keeping up to date with changes to this manual, agencies will become aware of factors which may adversely impact the security risk profile of their systems.
Agencies may wish to consider that discovered vulnerabilities could be a result of their security practices, accidental activities or malicious activities and not just as the result of a technical issue.
To determine the potential impact and possible mitigations to a system, comprehensive documentation and an understanding of the system are required. External sources that can be monitored for information on new vulnerabilities are vendor-published vulnerability information, other open sources and subscription services.
Mitigation efforts are best prioritised using a risk-based approach in order to address the most significant vulnerabilities first. Where two or more vulnerabilities are of similar importance, the mitigations with lower cost (in time, staff and capital) can be implemented first.
Agencies must analyse any vulnerabilities to determine their potential impact on the agency and determine appropriate mitigations or other treatments.
Agencies must mitigate or otherwise treat identified vulnerabilities as soon as possible.
A high-level summary of vulnerability assessment, analysis and management can be found in ASD’s Protect publication Know and minimise your vulnerabilities before they are used against you. Protect publications can be accessed through the ASD public website at http://www.asd.gov.au
Information security is an integral part of change management policy and process.
This section describes the importance of maintaining the security of systems when implementing routine and urgent changes.
As part of any change process it is important that all stakeholders are consulted before the change is implemented. In the case of changes that will affect the security of a system, the accreditation authority will need to be consulted and approval sought prior to the change taking place.
The change management process ensures that changes to systems are made in an accountable manner with due consideration and with appropriate approval. Furthermore, the change management process provides an opportunity for the security impact of the change to be considered and, if necessary, reaccreditation processes initiated.
The most likely scenario for bypassing change management processes is when an urgent change needs to be made to a system. Before and after an urgent change is implemented, it is essential that the change management process strongly enforces appropriate actions to be taken.
Agencies must have a formal change management process in place.
The change management process must define appropriate actions to be followed before and after urgent changes are implemented.
The accreditation for a system is the acceptance of the residual security risk relating to the operation of the system. It is important therefore that, when a change occurs that affects the overall security risk for the system, the accreditation authority is consulted on whether that residual security risk is still acceptable.
When a configuration change impacts the security of a system, and is subsequently assessed as having changed the overall security risk for the system, the system must undergo reaccreditation.
Tools and appropriate procedures are in place to detect cyber security incidents.
This section describes controls aimed at detecting cyber security incidents. It does not cover detecting physical and personnel security incidents.
A cyber security event is an identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be relevant to security.
A cyber security incident is a single or series of unwanted or unexpected cyber security events that have a significant probability of compromising business operations and threatening information security.
Many potential cyber security incidents are noticed by personnel rather than software tools. As such, successful incident detection is based around trained cyber security staff with access to data, complemented with key tools supporting both manual and automated analysis.
One of the core elements of cyber incident detection and subsequent investigation is the availability of key data sources about system usage. Many of these key data sources can be extracted from existing systems without requiring new or specialised capabilities. Efforts should be made to consolidate the various data sources to allow for greater analysis and correlation.
These data sources can support a real-time tool-based detection capability while their retention allows for the manual and automated investigation and identification of historic malicious activity.
The following table describes some of the data sources and tools that organisations may use for detecting and investigating cyber security incidents.
|Operating system events||Can track process execution, file/registry/network activity, authentication events, operating system created security alerts and other activity.|
|Web proxy logs||For identifying HTTP-based infection vectors and malware communication traffic.|
|VPN/Remote access logs||For identifying unusual source addresses, times of access and logon/logoff times associated with malicious activity.|
|DNS logs||Can identify attempts to resolve malicious domains/IPs which can indicate an exploitation attempt or successful compromise.|
|Mail server logs||Can assist in identifying users targeted with spearphishing emails enabling further investigative leads. Can also assist in identifying the initial vector of a compromise.|
|Security logs||Logs and event details created by various security tools and appliances such as anti-virus, content filters and intrusion detection systems can be captured and correlated alongside other data sources.|
Agencies should use the results of the security risk assessment to determine the appropriate balance of resources allocated to prevention as opposed to detection of cyber security incidents.
Reported cyber security incidents assist in maintaining an accurate threat environment picture for government systems.
This section describes agencies' responsibilities for reporting cyber security incidents. It does not cover reporting physical or personnel security incidents.
The requirement to lodge a cyber security incident report applies even when an agency has outsourced some or all of its information technology functions and services.
The Cyber Security Incident Reporting (CSIR) scheme defines cyber security incidents that are reportable to ASD.
Reporting cyber security incidents to an ITSM as soon as possible after it occurs provides management with a means to assess the overall damage to a system and to take remedial action, including seeking advice from ASD if necessary.
Agencies must direct personnel to report cyber security incidents to an ITSM as soon as possible after the cyber security incident is discovered.
ASD uses the cyber security incident reports it receives as the basis for identifying and responding to cyber security events across government. Cyber security incident reports are also used by ASD to identify trends and maintain an accurate threat environment picture for government systems. ASD utilises this understanding to assist in the development of new or updated security guidance, capability and techniques to better prevent and respond to changing cyber threats. Agencies are recommended to internally coordinate their reporting of cyber security incidents to ASD e.g. through their ITSA.
Where agencies have outsourced information technology services and functions, they may request that the service provider report cyber security incidents directly to ASD. This could be specified in either a memorandum of understanding or as part of the contract of services. In such cases it is recommended that the agency’s ITSA be made aware of all reporting of cyber security incidents to ASD by the service provider.
Agencies must report cyber security incidents to ASD.
Reporting cyber security incidents to ASD via a CSIR scheme ensures that ASD receives the incident information it requires in a timely fashion enabling subsequent incident triage and response. Incidents not reported through the CSIR scheme are at risk of not being responded to in an efficient and effective manner.
Agencies must formally report cyber security incidents using the CSIR scheme.
When an agency outsources information technology services and functions, it is still responsible for reporting cyber security incidents. It is up to the agency to ensure the service provider informs them of all cyber security incidents.
Agencies that outsource their information technology services and functions must ensure that the service provider consults with the agency when a cyber security incident occurs.
Reporting any cyber security incident involving the loss or misuse of cryptographic keying material is particularly important, as the confidentiality and integrity of secure communications relies on the secure use of keying material.
Agencies must notify all communications security custodians of any suspected loss or compromise of keying material.
ACSI 107 applies to all agencies including contractors. Its requirements cover all High Assurance Cryptographic Equipment products used to process classified information.
For security incidents involving the suspected loss or compromise of keying material for High Assurance products, ASD will investigate the possibility of compromise and, where possible, initiate action to reduce the impact of the compromise.
Agencies must notify ASD of any suspected loss or compromise of High Assurance Cryptographic Equipment or keying material associated with High Assurance Cryptographic Equipment in accordance with ACSI 107.
Information on the Cyber Security Incident Reporting (CSIR) scheme is located on the ASD website at https://www.asd.gov.au/infosec/reportincident.htm
Appropriate remedies assist in preventing future cyber security incidents.
This section describes agencies' responsibilities for managing cyber security incidents.
The management of physical and personnel security incidents is not covered in this section unless it directly impacts on the protection of systems (for example, breaching physical protection for a server room).
Documenting responsibilities and procedures for cyber security incidents in relevant SSPs, SOPs and the IRP ensures that when a cyber security incident does occur, personnel can respond in an appropriate manner. In addition, ensuring that users are aware of reporting procedures assists in capturing any cyber security incidents that an ITSM, ITSO or system owner fails to notice.
Agencies must detail cyber security incident responsibilities and procedures for each system in the relevant SSP, SOPs and IRP.
The purpose of recording cyber security incidents in a register is to highlight the nature and frequency of the cyber security incidents so that corrective action can be taken. This information can subsequently be used as an input into future security risk assessments of systems.
Agencies should ensure that all cyber security incidents are recorded in a register.
Agencies should use their register as a reference for future security risk assessments.
When a cyber security incident occurs, agencies must assume that a data spill has occurred, until proven otherwise, and follow appropriate procedures. A worst case scenario would entail an intruder gaining access to a range of classified documentation.
When a data spill occurs agencies must assume that the information has been compromised.
Agencies must include in standard procedures for all personnel with access to systems a requirement that they notify an ITSM of any data spillage and access to any data which they are not authorised to access.
Agencies must document procedures for managing data spills in their IRP.
Agencies must treat any data spill as a cyber security incident and follow the IRP to manage it.
When a data spill occurs, agencies must report the details of the data spill to the information owner.
The spillage of information onto a system not accredited to handle it is considered a cyber security incident under the ASD CSIR scheme.
An affected system can be segregated by powering off the system, removing network connectivity to the device or applying access controls on information associated with the data spill to prevent access. However, it should be noted that powering off the system could destroy information that would be useful for forensics activities at a later date.
When information is introduced onto a system not accredited to handle the information, personnel must not delete the information until advice is sought from an ITSM.
When information is introduced onto a system not accredited to handle the information, personnel should not copy, print or email the information.
When information is introduced onto a system not accredited to handle the information, agencies should segregate the affected system from the network.
The guidance for handling malicious code infections is provided to help prevent the spread of the infection and to prevent reinfecting the system. An important consideration is the infection date of the machine. However, when determining the infection date, it is important to bear in mind that the record could be inaccurate as a result of the infection.
A complete operating system reinstallation, or an extensive comparison of characterisation information, is the only reliable way to ensure that malicious code is eradicated.
Taking immediate steps after the discovery of a malicious code infection can minimise the time and cost spent eradicating and recovering from the incident.
Upon reporting the incident to ASD, agencies are likely to be asked to provide information to ASD regarding the incident that will assist ASD investigations and response. If agencies have an understanding of the types of information that ASD might request then this can significantly shorten incident investigation and response times.
For more information on event logging, including required retention periods, see the Event Logging and Auditing section of the Access Control chapter.
Agencies may wish to allow an intrusion to continue against their system for a short period of time in order to allow time for the agency to fully understand the scope of the incident.
Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of scoping the intrusion should inform their accreditation authority.
Agencies allowing an intrusion to continue against a system in order to seek further information or evidence will need to establish with their legal advisors whether the actions are breaching the Telecommunications (Interception and Access) Act 1979 (the TIA Act).
Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of seeking further information or evidence must seek legal advice.
While gathering evidence it is important to maintain the integrity of the information, including metadata about the information, who used it, and how it was used. Even though in most cases an investigation does not directly lead to a police prosecution, it is important that the integrity of evidence such as manual logs, automatic audit trails and intrusion detection tool outputs be protected.
When storing raw audit trails onto media it is important that it is done in accordance with relevant retention requirements as documented in the National Archives of Australia’s (NAA) Administrative Functions Disposal Authority.
If the integrity of evidence of a cyber security incident is compromised, it reduces ASD’s ability to assist agencies. ASD therefore requests that no actions which could affect the integrity of the evidence be carried out before ASD’s involvement.
Agencies should ensure that any requests for ASD assistance are made as soon as possible after the cyber security incident is detected and that no actions, which could affect the integrity of the evidence, are carried out before ASD's involvement.
System analysis after a successful intrusion helps to ensure the incident has been contained and removed from the system. After an incident has occurred, agencies may wish to perform post-incident analysis on their system by conducting a full network traffic capture. Agencies will be able to identify anomalous behaviour that may indicate an intruder persisting on the system, perform post-incident analysis and ensure mitigations put in place are effective.
Agencies should perform a post-incident analysis of successful intrusions, storing network traffic for at least seven days after the incident.
Further information relating to the management of ICT evidence is contained in ISO/IEC 27037:2012, Information technology - Security techniques - Guidelines for identification, collection, acquisition and preservation of digital evidence.
Physical security measures are applied to facilities and network infrastructure to protect systems.
This section describes the requirements for the physical security of facilities and network infrastructure.
Information about securing servers, network devices, ICT equipment and media can be found in various sections of this chapter. Information on encryption requirements can be found in the Cryptographic Fundamentals section of the Cryptography chapter.
In the context of this manual, a facility is a physical space where government business is performed. For example, a facility can be a building, a floor of a building, or a designated space on the floor of a building.
For facilities that process or store caveated or compartmented information, there may be a certification authority external to the agency operating the facility.
For multinational and multi-agency facilities, the certification authority is determined by a formal agreement between the parties involved.
For commercial providers of gateway services intended for use by multiple agencies across government, ASIO performs the role of the certification authority as an independent third party.
For commercial providers of other services, the certification authority is the ASA of the sponsoring agency.
The accreditation of physical security measures for Zone Two to Zone Five security areas is undertaken by the ASA.
For facilities that process or store caveated or compartmented information, there may be an accreditation authority external to the agency operating the facility.
For multinational and multi-agency facilities, the accreditation authority is determined by a formal agreement between the parties involved.
For gateway services of commercial providers, the accreditation authority is the ASA. For commercial providers supporting agencies, the accreditation authority is the ASA.
Agencies operating sites in posts or missions located outside of Australia should contact the Department of Foreign Affairs and Trade to determine requirements.
The application of defence-in-depth to the protection of systems is enhanced through the use of successive layers of physical security. The first layer of security is the use of Security Zones for the facility, the second layer is the use of a higher Security Zone or security room for the server room and the final layer is the use of security containers or lockable commercial cabinets. All layers are designed to limit access to people without the appropriate authorisation to access the systems and infrastructure at the facility.
Deployable platforms need to meet physical security certification requirements as per any other system. physical security certification authorities dealing with deployable platforms can have specific requirements that supersede the requirements of this manual and, as such, security personnel should contact their appropriate physical security certification authority to seek guidance.
In the case of deployable platforms, physical security requirements may also include perimeter controls, building standards and manning levels.
Agencies must ensure that any facility containing a system, including deployable systems, is certified and accredited in accordance with the requirements of the Australian Government Physical Security Management Protocol.
Agencies do not have control over sensitive or classified information when it is communicated over public network infrastructure or over infrastructure in unsecured spaces (Zone One security areas). For this reason, it is imperative that information is encrypted to a sufficient level that if it were captured, it would not be cost-effective to decrypt the information.
The PSPF’s Physical Security Management Guidelines - Security Zones and Risk Mitigation Control Measures states a Zone Five security area is required for the storage of codeword and TOP SECRET information. Secure transmission of this information is also a key consideration. Transmission of TOP SECRET or codeword information through lower Security Zone areas without encryption could allow a malicious actor to successfully access and exploit TOP SECRET infrastructure with relative ease. The only way to mitigate this threat is to apply strong encryption through the use of High Assurance Cryptographic Equipment.
Agencies communicating sensitive or classified information over public network infrastructure or over infrastructure in unsecured spaces (Zone One security areas) must use encryption approved for communicating such information over public network infrastructure.
Agencies communicating TOP SECRET or codeword information outside a Zone Five security area boundary must encrypt information using High Assurance Cryptographic Equipment.
Facilities without sufficient perimeter security are often exposed to potential observation through windows. Ensuring information on workstation screens is not visible will assist in reducing this security risk. This can be achieved by using blinds or curtains on the windows.
Agencies should prevent unauthorised people from observing systems, in particular, displays and keyboards.
Further information relating to physical security is contained in the Australian Government Physical Security Management Protocol. This document can be found at http://www.protectivesecurity.gov.au.
Server and communication rooms protect servers and network devices.
This section describes the requirements for the physical security of servers and network devices.
Information relating to the physical security of facilities, network infrastructure and ICT equipment and media can be found in other sections of this chapter.
Agencies must certify and accredit the physical security of a facility and server or communications room in accordance with the requirements of the Australian Government Physical Security Management Protocol. In such cases, the additional layer of security described in this manual allows the requirements for physical storage of server and communications equipment provided in the Australian Government Physical Security Management Protocol to be reduced in line with the physical security of ICT equipment systems and facilities guideline.
Adequate physical protection must be provided to network devices, especially those in public areas, to prevent a malicious actor physically damaging a network device with the intention of interrupting services.
Physical access to network devices can allow an intruder to reset devices to factory default settings by pressing a physical reset button, connecting a serial interface to a device, or connecting directly to a device to bypass any access controls. Resetting a network device back to factory default settings may disable security settings on the device including authentication and encryption functions as well as resetting administrator accounts and passwords to known defaults. Even if access to a network device is not gained by resetting it, it is highly likely a denial of service event will occur.
Physical access to network devices can be restricted through methods such as physical enclosures that prevent access to console ports and factory reset buttons, mounting devices on ceilings or behind walls, or placing devices in locked rooms or cabinets.
Agencies must implement physical security measures to protect network devices, especially those in public areas, from physical damage or unauthorised access.
Actions such as personnel leaving server and communication rooms and security containers unlocked, or with keys in the locks, or with security functions disabled, negates physical security measures. Such actions compromise security efforts and must not be permitted.
Agencies must ensure that servers and network devices are secured in either security containers or rooms as specified in the Australian Government Physical Security Management Protocol.
Agencies must not leave server rooms, communications rooms and security containers or rooms in an unsecured state.
Agencies must ensure that keys or equivalent access mechanisms to server rooms, communications rooms and security containers or rooms are appropriately controlled.
Areas containing particularly sensitive materials or ICT equipment can be provided with additional security through the use of a designated no-lone zone. The aim of this designation is to enforce two-person integrity, where all actions are witnessed by at least one other qualified or knowledgeable person.
Agencies operating no-lone zones must suitably signpost the area and have all entry and exit points appropriately secured.
Further information relating to physical security is contained in the Australian Government Physical Security Management Protocol. This document can be found at http://www.protectivesecurity.gov.au.
ICT equipment and media is physically secured during operational and non-operational hours.
This section describes the physical security of ICT equipment and media. This includes but is not limited to workstations, printers, photocopiers, scanners, multifunction devices (MFDs), optical media, flash drives, portable hard drives and memory cards.
Additional information relating to ICT equipment and media can be found in the Fax Machines and Multifunction Devices section of the Communications Systems and Devices chapter as well as in the Product Security and Media Security chapters. Information on the encryption of media can be found in the Cryptography chapter.
Agencies must account for all sensitive and classified ICT equipment and media.
Agencies must register all ICT equipment and media with a unique identifier in an appropriate register.
During operational and non-operational hours, ICT equipment and media needs to be stored in accordance with the Australian Government Physical Security Management Protocol.
Agencies must ensure that ICT equipment and media with sensitive or classified information is secured in accordance with the requirements for storing sensitive or classified information in the Australian Government Physical Security Management Protocol.
In some circumstances it may not be feasible to secure ICT equipment during non-operational hours by storing it in a security container or room, using a removable hard drive, using ICT equipment without a hard drive or using approved encryption. In such cases the Australian Government Physical Security Management Protocol allows for the reduction of physical storage requirements for ICT equipment if appropriate logical controls are applied. This can be achieved by configuring systems to prevent the storage of sensitive or classified information on the hard drive (e.g. storing profiles and work documents on network shares) and enforcing scrubbing of the operating system swap file and other temporary data at logoff or shutdown in addition to the standard practice of sanitising the ICT equipment’s ram.
The security measures described in the previous paragraph do not constitute sanitisation of the hard drive in the ICT equipment. Therefore, the hard drive retains its classification for the purposes of reuse, reclassification, declassification, sanitisation, destruction and disposal as specified in this manual.
As hybrid hard drives and solid state drives cannot be sanitised in the same manner as standard magnetic hard drives, refer to the Media Sanitisation section of the Media Security chapter, the logical controls described above are not approved as a method of lowering the physical storage requirements of the ICT equipment.
There is no guarantee that techniques such as preventing the storage of sensitive or classified information on hard drives and scrubbing the operating system swap file and other temporary data at logoff or shutdown will always work effectively or will not be bypassed due to unexpected circumstances such as an unexpected loss of power to the workstation. As such these security risks need to be considered when implementing such a solution and documented in the SSP.
For further information on physical security and media security see the Australian Government Physical Security Management Protocol and Australian Government Information Security Management Protocol. These documents can be found at http://www.protectivesecurity.gov.au.