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 to information and systems.
This section describes how to interpret the content and layout of this manual.
Under the Defence White Paper 2013, the Defence Signals Directorate (DSD) was renamed the Australian Signals Directorate (ASD). For legal and policy purposes, all references to ASD should be taken to be references to DSD.
The purpose of this manual is to assist Australian government agencies 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 the 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.
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 later 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 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.
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 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.
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 agencies' risk assessments.
Agencies select and implement information security controls 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 wider agency risk management process. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.
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. The ISM aims to encourage agencies to take a risk-based approach to information security. This approach enables the flexibility to allow agencies to conduct their business and develop resilience in the face of a changing threat environment.
It is a mandatory requirement of the Australian Government Protective Security Policy Framework that agencies adopt a risk management approach to cover all areas of protective security activity across their organisation. ASD recommends information security forms a part of an agency's broader risk management processes.
The ISM is developed as a tool to assist Australian government agencies to risk-manage the protection of their information and systems. 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.
While this manual provides controls for various technologies, not all systems will use all of the technologies mentioned. When agencies develop 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 in 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 should 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.ag.gov.au/Protectivesecuritypolicyframework/Pages/default.aspx.
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.
Further guidance can also be found in the National Institute of Standards and Technology Risk Management Guide for Information Technology Systems at: http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf.
The Protective Security Training Centre, managed by the Attorney-General's Department, provides formal training opportunities on the subject of security risk management: http://www.ag.gov.au/Securitytraining/Pages/default.aspx.
Agencies comply with ISM controls where appropriate, in accordance with their business needs, threat environment and risk appetite. Non-compliance formally accepted by the appropriate authority.
This section explains the compliance language used in this manual and the appropriate authorities for 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 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 controls is a 'must' or a 'should' is based on ASD's experience in providing cyber and information security advice and assistance for 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.
When an agency is non-compliant with multiple controls, they may choose to logically group the areas of non-compliance when following the processes for non-compliance.
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 granting non-compliance with any control.
Agencies should provide a copy of their 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 Australian National Audit Office (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.
Security personnel are aware of and use security services offered in the Australian Government.
This section describes the agencies and bodies involved in providing information security advice.
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 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 Australian Information Security Evaluation Program (AISEP) to deal with the increasing requirement to evaluate products with security functionality.
ASD can be contacted for advice and assistance on implementing this manual through agency Information Technology Security Managers (ITSMs) or Information Technology Security Advisors (ITSAs). ITSMs and ITSAs can send questions to ASD by email at firstname.lastname@example.org or phone on 1300 CYBER1 (1300 292 371).
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 emailing the Cyber Security Operations Centre at email@example.com. ASD's incident response service is available 24 hours, 7 days a week.
ASD can be contacted by email at firstname.lastname@example.org for advice and assistance on the purchasing, provision, deployment, operation and disposal of High Assurance products.
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.|
|Attorney-General's Department - Protective Security Training Centre||Provides protective security training to government agencies and contractors.|
|Australian Federal Police (Australian High Tech Crime Centre)||Law enforcement in relation to electronic and other high tech crimes.|
|Australian Government Information Management Office (AGIMO)||Development, coordination and oversight of whole-of-government policy on electronic commerce, online services and the Internet.|
|Australian National Audit Office (ANAO)||Performance audits on information security.|
|Australian Security Intelligence Organisation (ASIO) - T4 Protective Security||ASIO is responsible for collecting, analysing and reporting intelligence on threats to security. ASIO - T4 Protective Security section provides advice and training, technical surveillance counter-measures, physical security certifications, protective security risk reviews and physical security equipment testing.|
|Computer Emergency Response Team (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; coordination role during a serious cyber incident.|
|Cyber Security Operations Centre (CSOC)||The CSOC is responsible for improving government understanding of sophisticated cyber threats against Australian interests, and coordinating/providing operational responses to cyber security events of national importance. It is hosted by ASD but includes representatives from ASD, the Defence Intelligence Organisation (DIO), Australian Defence Force, ASIO, AFP and AGD.|
|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 Foreign Affairs and Trade||Policy and advice for security overseas.|
|Department of the Prime Minister and Cabinet||Coordination of cyber and information security policy and activities across government. Responsible for implementation of the National Security Information Environment Roadmap: 2020 Vision.|
|National Archives of Australia||Provides standards and advice on capturing and managing records to ensure their integrity as evidence is maintained; 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.|
|Security Construction and Equipment Committee||Oversees the evaluation of 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.
Industry partners handle information appropriately and implement the same security measures as their sponsoring agency.
This section describes information on outsourcing information technology services and functions to industry as well as providing them with access to information in order to undertake their duties.
Cloud computing is a delivery model for information technology services. Where these services are provided by a third party (i.e. outsourced) cloud computing service provider, additional information security issues need to be considered. ASD's Cloud Computing Security Considerations document provides guidance for agencies considering implementing cloud computing services.
Additionally, the Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements establishes whole-of-government guidelines for outsourcing agency ICT functions and offshoring unclassified government information.
For further information on the use of virtualisation technologies to achieve functional separation, see the Standard Operating Environments section of the Software Security chapter.
A public cloud arrangement involves infrastructure which is shared via the Internet with many other organisations and other members of the public.
Outsourcing can be a cost-effective option for providing information technology services and functions in an agency, as well as potentially delivering a superior service. However, it can also affect an agency's risk profile and control over its threat environment. Storing data in multiple disparate locations and allowing more people to access agency information can significantly increase the potential for network infection and information loss or compromise.
Outsourcing information technology services and functions outside of Australia, unless agencies are handling data considered publicly available, presents a high risk of unauthorised disclosure of agency information. chooseChoosing a vendor (either locally or foreign owned) that is located in Australia and stores, processes and manages sensitive data only within Australian borders minimises this risk. An additional risk is that foreign owned vendors operating in Australia may be subject to foreign laws such as a foreign government's lawful access to data held by the vendor.
Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements establishes a whole-of-government approach to how different categories of information are treated when considering offshore or outsourced ICT arrangements.
Unclassified information that is not considered publicly releasable must not be stored or processed in public cloud or offshore ICT arrangements unless it meets the requirements outlined in the Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements.
Personal information as defined by the Privacy Act 1988 must not be stored or processed in public cloud or offshore ICT arrangements unless it meets the requirements outlined in the Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements.
Service providers' systems storing or processing Australian government information must be located in Australia.
Security classified information must not be stored or processed in a public cloud arrangement, unless the handling requirements have been appropriately downgraded as per the Cryptography and other related chapters of the ISM.
When agency functions and services are outsourced, agencies can lose oversight of how their information is handled and stored. Ensuring service providers seek agency approval before transmitting, processing or storing information offshore will minimise the risk of agencies losing control of their information.
Agencies must ensure service providers seek their approval before allowing information to leave, or be accessed from outside, Australian borders
Service providers can be provided with information as long as their systems are accredited to process, store and communicate the information. This ensures that when they are provided with information that it receives an appropriate level of protection.
ASD expects that agencies using cloud computing services can meet the principles and objectives set out in the ISM. In some circumstances, agencies might need to seek a waiver for controls that aren't applicable to a specific cloud computing implementation or usage scenario. The accreditation process should involve communication from the provider to the client agency on areas of non-compliance to inform their risk decision. This is no different to the expectations leveraged on government agencies when using this manual. If a service provider is changing its system architecture to meet ISM controls for certification purposes, which is in turn weakening security in other parts of the implementation scenario, then it is likely not meeting the intent of the ISM. In such circumstances, ASD should be contacted for ISM interpretation advice.
Systems used by service providers for the provision of information technology services and functions must be accredited to the same minimum standard as the sponsoring agency's systems.
There are a variety of information security risks that need to be considered when engaging cloud computing providers. Data stored in outsourced cloud infrastructure is vulnerable to malicious cyber activity, due to the Internet-connected nature of outsourced cloud computing. Moreover, the physical data storage location - and the people responsible - will not necessarily be known to the agency. This diminishes agency control over threat mitigation and response and increases the threat from malicious insiders. Risks will vary depending on the sensitivity of agency data to be stored and processed and how the chosen cloud vendor has implemented their specific cloud services.
Agencies should assess the information security risks of using cloud computing services against ASD's Cloud Computing Security Considerations document.
When an agency engages a service provider for the provision of information technology services and functions, having a central point of contact for information security issues will greatly assist incident response and reporting procedures.
Service providers should provide a single point of contact who will act as an equivalent to an ITSM.
Developing an information security industry engagement plan will help ensure an agency has a clear and coordinated approach when engaging and using service providers for the outsourcing and provision of information technology services and functions.
Agencies should develop an information security industry engagement plan to manage service providers that have been approved for the provision of information technology services and functions.
Additional information regarding cloud computing security considerations can be found in the Cloud Computing Security Considerations document on the ASD website at http://www.asd.gov.au/infosec/cloudsecurity.htm.
Additional information on outsourcing and offshoring ICT services can be found in the Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements.
Additional whole-of-government policy and guidance on cloud computing can be found on the Australian Government Information Management Office website at http://agict.gov.au/policy-guidance-procurement/cloud.
The Chief Information Security Officer (CISO) sets the strategic direction for information security.
This section describes the information security role of a CISO.
The requirement to appoint a member of the Senior Executive Service, or in an equivalent management position, to the role of CISO does not require a new dedicated position to be created in each agency. This role is intended to be performed by the Security Executive, which is a position in each agency mandated by the Australian Government Protective Security Policy Framework. The introduction of the CISO role is aimed at providing a more meaningful title for a subset of the Security Executive's responsibilities that relate to information security.
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 overseeing the application of controls and security risk management processes.
The Information Technology Security Advisor (ITSA) coordinates information technology security.
This section describes the information security role of an ITSM when designated as the ITSA.
The ITSM who has responsibility for information technology security management across the agency is designated as the ITSA. This title reflects the responsibility this ITSM has as the first point of contact for the CISO, or equivalent, and external agencies on any information technology security management issues.
Information on the responsibilities of ITSMs can be found in the Information Technology Security Managers section of this chapter.
An ITSM, when fulfilling the designation of ITSA, still maintains full responsibilities for their role as an ITSM in addition to ITSA responsibilities. An ITSA traditionally 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 ITSA@agency.
Information Technology Security Managers (ITSMs) provide information security leadership and management.
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 that of 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.
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.
ITSOs provide information security operational support.
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 whose responsibility is to ensure 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 expert, commonly referred to as an ITSO, 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.
This section describes the information security documentation that government agencies should develop.
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.
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 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.
Agencies must ensure that every system is covered by an SRMP.
The System Security Plan (SSP) is derived from this manual and the SRMP and describes the implementation and operation of controls for a system. Depending on the documentation framework chosen, some details common to multiple systems could be consolidated in a higher level SSP.
Agencies must ensure that every system is covered by 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 strong knowledge of the system. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.
Agencies should ensure that SOPs are 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 an IRP and supporting procedures.
It is likely that the most useful and accurate information security documentation will be developed by personnel who are knowledgeable about both information security issues and the business requirements.
Agencies should ensure that information security documentation is 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.
Agencies should ensure that their SRMP, SSP, SOPs and IRP are 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.
If stakeholders are not made aware of new information security documentation, or changes to existing information security documentation, they will not know about any changes they may need to make to the security measures for their systems.
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.
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.
An SRMP identifies security risks and appropriate mitigation measures for systems.
This section describes the development of an SRMP, focusing on security risks related to the operation of systems.
An 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 an 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/.
An SSP specifies the security measures for systems.
This section describes the development of an SSP.
An 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 an 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.
In performing accreditations against the latest baseline of this manual, agencies are ensuring that they are taking the most recent threat environment into consideration. 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.
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 should use the latest baseline of this manual when developing, and updating, their SSPs as part of accreditation and reaccreditation of their systems.
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.
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.
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 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 Ensuring Service Continuity 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.
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.
Agencies should 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 HB 221:2004, Business Continuity Management.
Accreditation formalises the acceptance of security risks relating to the operation of a system.
This section describes the accreditation framework for systems and agencies' responsibilities.
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, certification and audits is given in the Conducting Accreditations, Conducting Certifications and Conducting Audits sections of this chapter.
This chapter details the ICT system accreditation process.
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.
This chapter does not discuss physical security certifications. Further information on TOP SECRET physical security certifications can be provided by ASD on request.
Developing an accreditation framework ensures that accreditation activities are conducted in a repeatable and consistent manner across the agency.
Agencies must develop an accreditation framework.
Accreditation of a system ensures that either sufficient security measures have been put in place or that deficiencies in such measures have been accepted by an appropriate authority. When systems are awarded accreditation the accreditation authority accepts that the residual security risks are appropriate for the sensitivity or classification of the information that the system processes, stores or communicates.
Monitoring the accredited systems will assist in assessing changes to the environment and operation and to determine the implications for the security risk profile and accreditation status of the system.
Agencies must ensure that their system is awarded accreditation before they are used to process, store or communicate sensitive or classified information.
Agencies must ensure that all systems are awarded accreditation before connecting them via a gateway.
Agencies should ensure information security monitoring activities are conducted on accredited systems.
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.
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.
The list of accreditation and certification authorities is given in the Conducting Accreditations and Conducting Certifications sections of this chapter.
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.
When an agency is connecting to a system not under their control or passing information to another party, the agency needs to be aware of the security measures that have been implemented to protect the agency's information. More importantly, the agency needs to accept the security risks associated with non-compliance with controls in this manual by the other party before connecting or passing information to them. The security risks include the system potentially being used as a platform to launch an intrusion on the agency's system or spilling information onto a system not under their control and requiring subsequent clean up of the spilled information.
If information is processed, stored or communicated by a system not under an agency's control, the agency must ensure that the non-agency system has appropriate security measures in place to protect the agency's information.
Agencies should review an accreditation report when determining whether the non-agency system has appropriate security measures in place to protect the agency's information.
Agencies must ensure that a process is in place to provide assurance to its management that a non-agency system meets, and will continue to meet, the agency's security requirements.
When security is applied to systems, security measures are put in place based on the sensitivity or classification of information that will be processed, stored or communicated by the system. If information is placed on a system, and its sensitivity or classification is higher than the level of accreditation for the system, the information will be inadequately protected and will be exposed to a greater risk of compromise.
Agencies must not allow a system to process, store or communicate information above the sensitivity or classification for which the system has received accreditation.
When processing caveated or compartmented information on a system, agencies need to ensure that the system has received accreditation for the caveated or compartmented information.
It should be noted that for Special Compartmented Information Facilities (SCIFs), ICT security is only one part of the requirements for gaining accreditation. Further information on gaining SCIF accreditation can be provided upon request from ASD.
A system that processes, stores or communicates caveated or compartmented information must be accredited for such caveated or compartmented information.
Due to sensitivities associated with Australian Eyes Only (AUSTEO) and Australian Government Access Only (AGAO) systems, it is essential that control of such systems is maintained by Australian citizens working for the government of Australia.
Agencies must ensure that systems processing, storing or communicating AUSTEO or AGAO information remain at all times under the control of an Australian national working for the government.
Agencies' threat environment 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.
Agencies may have an additional year's grace if they follow the procedures defined in this manual for non-compliance with 'should' requirements: that is, providing a suitable justification, conducting a security risk assessment and obtaining formal approval from the accreditation authority.
Once three years has elapsed since the last accreditation, the agency needs to either reaccredit the system or seek approval for non-compliance from their agency head.
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 SCIF areas in addition to their ICT certification, a SCIF Support Pack is available from ASD on request.
Systems are accredited before they are used operationally.
This section describes conducting an accreditation for a system.
The aim of accreditation is to formally recognise and accept the residual security risk to a system and the information it processes, stores or communicates.
For standard systems the accreditation authority is the agency head or their formal delegate, which is strongly recommended to be the CISO or equivalent.
For TOP SECRET systems the accreditation authority is ASD.
For systems that process, store or communicate caveated or compartmented information there may be a mandated accreditation authority external to the agency operating the system.
For multinational and multi-agency systems the accreditation authority is determined by a formal agreement between the parties involved.
For gateway services of commercial providers the accreditation authority is the agency head or their delegate, which is strongly recommended to be the CISO or equivalent.
For commercial providers supporting agencies the accreditation authority is the head of the supported agency 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 agency.
Depending on the circumstances and practices of an agency, the agency head can choose to delegate their authority to multiple senior executives who have the authority to accept security risks for the specific business functions; for example the CISO or equivalent.
Accreditation is awarded when the accreditation authority accepts the residual security risk relating to the operation of the system and gives formal approval for the system to operate. However, in some cases the accreditation authority may not accept the residual security risk relating to the operation of the system. This is predominantly due to security risks being insufficiently considered and documented in the SRMP, resulting in security measures being inaccurately scoped in the SSP. In such cases the accreditation authority may request that the SRMP and SSP be amended and security measures reassessed before reconsidering the system for accreditation.
In awarding accreditation for a system, the accreditation authority may specify a shorter period before reaccreditation than that specified in this manual. The accreditation authority may also place restrictions on the use of the system which must be enforced until reaccreditation takes place or until required changes are made to the system.
The following diagram shows, at a high level, the process of accreditation.
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 be certified 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 relating to the operation of a system in order to award accreditation.
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.
Formal acceptance is given that a system has been audited appropriately and security controls implemented effectively.
This section describes conducting a certification as part of the accreditation process for a system.
The aim of certification is to ensure the audit for a system was conducted in an appropriate manner and to a sufficiently high standard.
The outcome of certification is a certificate to the system owner acknowledging that the system has been appropriately audited and that the controls identified by the system owner have been implemented effectively.
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 of gateway services intended for use by multiple agencies across government, ASD performs the role of the certification authority as an independent third party.
For commercial providers supporting agencies the certification authority is the ITSA of the agency sponsoring the organisation.
The aim of an audit is to assess the actual implementation and effectiveness of controls for a system. The process of conducting an audit is described in the Conducting Audits section of this chapter.
All systems must undergo an audit as part of the certification process.
To award certification for a system the certification authority needs to be satisfied that the controls identified by the system owner have been implemented and are operating effectively. However, certification only acknowledges that the identified controls 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 controls for the system in order to award certification.
Before the certification authority can make a recommendation to the accreditation authority, an assessment of the residual security risk must be done. The purpose of the assessment is to assess the residual security risk relating to the operation of a system following the audit.
Even if, after the audit, the system does not conform, the certification authority may be able to recommend to the accreditation authority that accreditation be awarded. For example, since the audit, the system owner may have taken corrective actions to address areas of non-compliance, or the residual security risk may not be great enough to preclude accreditation.
Following the audit, the certification authority should produce a certification report for the accreditation authority containing an assessment of the residual security risks relating to the operation of the system and a recommendation on whether to award accreditation or not.
Commercial providers of gateway services may be used by multiple agencies across government, agencies must ensure gateway services of commercial providers have undergone an audit conducted by an Information Security Registered Assessor and received certification from ASD. Even though ASD may certify a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.
Agencies must ensure that gateway services of commercial providers, intended for use by multiple agencies, have undergone an audit by an Information Security Registered Assessor and received certification from ASD.
The effectiveness of security measures for systems is assessed.
This section describes conducting an audit as part of the certification process for a system.
The aim of an audit is to review the system architecture (including the information security documentation) and assess the actual implementation and effectiveness of controls for a system.
The outcome of an audit is a report to the certification authority describing areas of compliance and non-compliance for a system and any suggested remediation actions.
Audits for TOP SECRET systems can only be undertaken by ASD and Information Security Registered Assessors.
Audits for SECRET and below systems can be undertaken by agency ITSMs and Information Security Registered Assessors.
A number of agencies and personnel are often consulted during an audit.
The ASA can be consulted on physical and personnel security aspects of information security.
An ITSM or communications security officer can be consulted on communications security aspects of information security.
An audit can be conducted by agency assessors; however, the agency may choose to add an extra level of objectivity by engaging the services of an Information Security Registered Assessor to undertake the audit.
Connections to certain inter-agency systems could require an independent audit from an Information Security Registered Assessor as a prerequisite to certification of the system. Such requirements can be obtained from the inter-agency system owners.
As there can be a perceived conflict of interest in the system owner assessing 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.
Agencies should ensure that assessors conducting audits are not also the system owner or certification authority.
Ensuring that the system owner has approved the system architecture and associated information security documentation assists assessors in determining the scope of work for the first stage of the audit.
Before undertaking the audit, the system owner must approve the system architecture and associated information security documentation.
The purpose of the first stage of the audit is to determine that the system architecture (including information security documentation) is based on sound security principles and has addressed all applicable controls from this manual. During this stage, the statement of applicability for the system will also be assessed along with any justification for non-compliance with applicable controls from this manual.
The system architecture should be reviewed by the assessor to ensure that it is based on sound security principles and meets security requirements.
The ISP should be reviewed by the assessor to ensure that policies have been developed or identified to protect information that is processed, stored or communicated by systems.
The SRMP, SSP, SOPs and IRP must be reviewed by the assessor to ensure that they are comprehensive and appropriate for the environment the system is to operate in.
The SSP must be reviewed by the assessor to ensure that all relevant controls specified in this manual are addressed.
Without implementing the controls for a system, their effectiveness cannot be assessed during the second stage of the audit.
Before undertaking the second stage of the audit the system owner must implement the controls for the system.
The purpose of the second stage of the audit is to determine whether the controls, as approved by the system owner and reviewed during the first stage of the audit, have been implemented and are operating effectively.
The implementation of controls must be assessed to determine whether they have been implemented and are operating effectively.
The assessor must ensure that, where applicable, a physical security certification has been awarded by an appropriate physical security certification authority.
The physical security certification should be less than 5 years old at the time of the audit.
The report of compliance helps the certification authority assess the residual security risk relating to the operation of a system following the audit and any remediation activities the system owner may have undertaken.
The assessor must produce a report of compliance 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 Information Security Registered Assessors are authorised to perform. It can be obtained from ASD's website at http://www.asd.gov.au/infosec/irap.htm.
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 Information Security Registered 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 to 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 analyses.
Furthermore, by monitoring vulnerability sources/alerts, conducting vulnerability analyses, 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 OnSecure, the ASD public website (in some cases) or upon request.
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 impacts 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.
The activities listed for assisting in detecting cyber security incidents will assist in mitigating the most common methods used to exploit systems.
Many potential cyber security incidents are noticed by personnel rather than software tools. However, this can only occur if personnel are well trained and aware of information security issues and know how to recognise possible cyber security incidents.
Automated tools are only as good as the quality of the analysis they provide. If tools are not adequately configured to assess potential security risks, it will not be evident when a weakness emerges. Additionally, if the tools are not regularly updated to include knowledge of new vulnerabilities their effectiveness will be reduced.
Agencies may consider some of the tools described in the following table for detecting potential cyber security incidents.
|Anomaly detection systems||Monitor network and host activities that do not conform to normal system activity.|
|Intrusion Detection Systems||Some Intrusion Detection Systems (IDSs) are combined with functionality to repel detected intrusions. Caution and assessment of the potential impact need to be exercised if this capability is to be used.|
|Log analysis||Involves collecting and analysing event logs using pattern recognition to detect anomalous activities.|
|Network and host IDSs||Monitor and analyse network and host activity, usually relying on a list of known malicious signatures to recognise potential cyber security incidents.|
|System integrity verification||Used to detect changes to critical system components such as files, directories or services. These changes may alert a system administrator to unauthorised changes that could signify an intrusion on the system and inadvertent system changes that render the system vulnerable to intrusion.|
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 cyber security incident reports as the basis for identifying and responding to cyber security events across government. Cyber security incident reports can also be used for developing new policies, procedures, techniques and training measures to prevent the recurrence of similar cyber security incidents across government. Agencies are recommended to 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 through the appropriate channels ensures that appropriate and timely assistance can be provided. In addition, it allows ASD to maintain an accurate threat environment picture for government systems through the Cyber Security Incident Reporting scheme.
Agencies should formally report cyber security incidents using the CSIR scheme.
When an agency outsources information technology services and functions, they are still responsible for the reporting of cyber security incidents. It is up to the agency to ensure the service provider informs them of all cyber security incidents to allow them to formally report these to ASD.
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 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 products or keying material associated with High Assurance products in accordance with ACSI 107.
Further information on reporting cyber security incidents is located on the ASD website at http://www.asd.gov.au/infosec/reportincident.htm.
The cyber security incident reporting form can be found at http://www.asd.gov.au/publications/Cyber_Security_Incident_Report.pdf.
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 fail 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.
Assuming that information is compromised as a result of a cyber security incident allows an agency to apply procedures in response to a worst case scenario.
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 dealing with data spills in their IRP.
Agencies must treat any data spill as a cyber security incident and follow the IRP to deal with 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, view, 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 a knowledge 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, this includes maintaining 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, 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 HB 171:2003, Guidelines for the management of information technology 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 on servers, network devices, ICT equipment and media can be found in other 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 an area that facilitates government business. 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 supporting agencies the certification authority is the ASA of the agency sponsoring the organisation.
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 those with the appropriate authorisation to access the system and infrastructure.
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 against the requirements in 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 information is encrypted to a sufficient level that if it was captured it would not be cost-effective to retrieve the original 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 products.
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 a High Assurance product.
Facilities without sufficient perimeter security are often exposed to the potential for 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 drapes on the inside of 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 against the requirements in the Australian Government Physical Security Management Protocol. In such cases, because of the additional layer of security described in this manual, the requirements for physical storage of server and communications equipment in the Australian Government Physical Security Management Protocol can be lowered according to 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 in order to cause a denial of service to a network.
Physical access to network devices can allow an intruder to reset devices to factory default settings by pressing a physical reset button, using a serial interface on 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 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.
Adequate physical protection must be provided to network devices, especially those in public areas.
If personnel leave server rooms, communications rooms and security containers or rooms unlocked, with keys in the locks or with security functions disabled, it negates the purpose of providing security. Such activities will compromise the 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 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.