2016-05
Australian Government
Information Security Manual
C O N T R O L S

Foreword

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.


Dr Paul Taloni
Director
Australian Signals Directorate
About Information Security
About
Information
Security

About Information Security

Using This Manual

Objective

The Australian Government Information Security Manual (ISM) is used for the risk-based application of information security controls.

Scope

This section describes how to interpret the content and layout of this manual.

Context

Purpose of the Australian Government Information Security Manual

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 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.

Applicability
    This manual applies to
  • Non-corporate Commonwealth entities that are subject to the Public Governance, Performance and Accountability Act 2013
  • bodies that are subject to the Public Governance, Performance and Accountability Act 2013, and that have received notice in accordance with that Act that the ISM applies to them as a general policy of the Government
  • other bodies established for a public purpose under the law of the Commonwealth and other Australian government agencies, where the body or agency has received a notice from their Portfolio Minister that the ISM applies to them
  • state and territory agencies that implement the Australian Government Protective Security Policy Framework
  • organisations that have entered a Deed of Agreement with the Government to have access to sensitive or classified information.

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.

Authority
    The Intelligence Services Act 2001 (the ISA) states that two functions of ASD are
  • to provide material, advice and other assistance to Commonwealth and state authorities on matters relating to the security and integrity of information that is processed, stored or communicated by electronic or similar means
  • to provide assistance to Commonwealth and state authorities in relation to cryptography, and communication and computer technologies.

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.

Legislation and legal considerations

This manual does not override any obligations imposed by legislation or law. Furthermore, if this manual conflicts with legislation or law the latter takes precedence.

While this manual contains examples of when legislation or laws may be relevant for agencies, there is no comprehensive consideration of such issues. Accordingly, agencies should rely on their own inquiries in that regard.

Public systems

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.

Public network infrastructure

This manual uses the term 'public network infrastructure', defined as network infrastructure that an agency has no or limited control over (for example the Internet). Conversely, private network infrastructure is that which an agency controls exclusively.

However, there may be cases where a network does not precisely meet either of these definitions, a common example being the Intra Government Communications Network (ICON). ICON provides dedicated network connectivity between Australian Government agencies and has a different risk profile than both public and private network infrastructure. ICON provides additional physical and personnel security measures over general public network infrastructure. Agencies will need to consider which security mitigations to implement commensurate with their assessed level of risk. ASD recommends that, where feasible, networks whose infrastructure and devices are not wholly controlled by your agency, should be treated as if public network infrastructure in the context of relevant ISM controls.

Further information on ICON can be found at http://www.finance.gov.au/collaboration-services-skills/icon/

Format of the Australian Government Information Security Manual

The three parts of the ISM are designed to complement each other and provide agencies with the necessary information to conduct informed risk-based decisions according to their own business requirements, specific circumstances and risk appetite.

The Executive Companion is aimed at the most senior executives in each agency, such as Secretaries, Chief Executive Officers and Deputy Secretaries, and comprises broader strategic messages about key cyber and information security issues.

The Principles document is aimed at Security Executives, Chief Information Security Officers, Chief Information Officers and other senior decision makers across government and focuses on providing them with a better understanding of the cyber threat environment. This document contains information to assist them in developing informed security policies within their agencies.

The Controls manual is aimed at Information Technology Security Advisors, Information Technology Security Managers, Information Security Registered Assessors and other security practitioners across government. This manual provides a set of detailed controls which, when implemented, will help agencies adhere to the higher level Principles document.

ASD provides further information security advice in the form of device-specific guides, Australian Communications Security Instructions (ACSIs) and Protect publications - such as the Strategies to Mitigate Targeted Cyber Intrusions. While these publications reflect the policy specified in this manual, not all requirements in this manual can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.

Framework

This manual uses a framework to present information in a consistent manner.

    The framework consists of a number of headings in each section
  • Objective - the desired outcome of complying with the controls specified in the section, expressed as if the outcome has already been achieved
  • Scope and Context - the scope and applicability of the section. It can also include definitions, legislative context, related ISM sections and background information
  • Controls - procedures with associated compliance requirements for mitigating security risks to an agency's information and systems
  • References - sources of information that can assist in interpreting or implementing controls.
System applicability

Each control in this manual has an applicability indicator that indicates the information and systems to which the control applies.

    The applicability indicator has up to five elements, indicating whether the control applies to:
  • UD: Baseline controls advised for Australian government systems holding information which requires some level of protection. Applicable to unclassified government systems containing unclassified but sensitive or official information not intended for public release, such as Unclassified Dissemination Limiting Marker (DLM) information. Please note that Unclassified (DLM) is not a classification under the Australian Government Security Classification System, as mandated by the Attorney-General's Department
  • P: PROTECTED information and systems
  • C: CONFIDENTIAL information and systems
  • S: SECRET information and systems
  • TS: TOP SECRET information and systems.

ASD maintains a System Controls Checklist to facilitate the incorporation of ISM advice into an agencys' risk assessment.

Controls

Nil.

References

Information on the applicability of the Protective Security Policy Framework can be found at http://www.protectivesecurity.gov.au.

Information Security Risk Management

Objective

Agencies select and implement information security controls from the ISM as part of a formal risk management process.

Scope

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.

Context

Taking a risk-based approach to Information Security

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.

Applicability of controls

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 section of the Information Security Documentation chapter. Further information on vulnerability assessments and managing change can be found in the Information Security Monitoring chapter.

Controls

Topic Link
Identifying and analysing information security risks
    Risk can be identified and analysed in terms of:
  • What could happen? How could resources and activities central to the operation of an agency be affected?
  • How would it happen? What weaknesses could be exploited to make this happen? What security controls are already in place? Are they adequate?
  • How likely is it to happen? Is there opportunity and intent? How frequent is it likely to be?
  • What would the consequence be? What possible effect could it have on an agency's operations, services or credibility?
Control: 1203; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must identify and analyse security risks to their information and systems.

Topic Link
Evaluating and treating information security risks

Once information security risks have been identified and analysed, agencies will need to determine whether they are acceptable or not.

    This decision can be made by balancing the risk against an agency's business needs and risk appetite, for example
  • What equipment and functionality is necessary for your agency to operate?
  • Will the risk mitigation strategies affect your agency's ability to perform its core duties?
  • What resource constraints are involved? (This can refer to financial or personnel limitations, for example)
  • Will the compromise of information, as a result of not treating this risk, breach your agency's obligation under law or damage national security in some way?

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).

Control: 1205; Revision: 1; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 1206; Revision: 1; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 1207; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should mitigate residual security risks through the implementation of alternative security measures.

Topic Link
System-specific security risks

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.

Control: 0009; Revision: 3; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must determine system specific security risks that could warrant additional controls to those specified in this manual.

Topic Link
Documentation

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.

Control: 1208; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must document identified information security risks, as well as the evaluation of those risks and mitigation strategies, in their Security Risk Management Plan.

References

The Australian Government Protective Security Policy Framework can be found at http://www.protectivesecurity.gov.au.

For further guidance please refer to the Australian Standard for Risk Management AS/NZS ISO 31000:2009, the Australian Standards HB 167:2006 Security risk management and HB 327:2010 Communicating and consulting about risk.

The Protective Security Training College, managed by the Attorney-General's Department, provides formal training opportunities on the subject of security risk management: http://www.ag.gov.au/NationalSecurity/ProtectiveSecurityTraining/Pages/default.aspx.

Compliance and Non-compliance

Objective

Agencies comply with ISM controls where appropriate, in accordance with their business needs, threat environment and risk appetite. Non-compliance is formally accepted by the appropriate authority.

Scope

This section explains the compliance language used in this manual and the appropriate authorities for non-compliance with ISM controls.

Context

Authority to approve non-compliance

Each control specifies the authority that must provide approval for non-compliance with the control.

    The authority indicates one of the two possible approvers
  • ASD: Director ASD
  • AA: Accreditation Authority

In most circumstances, the accreditation authority is the agency head or their formal delegate. For information on accreditation authorities, see the Conducting Accreditations section of the System Accreditation chapter.

Some controls will also require non-compliance notification to the relevant portfolio minister(s), the Attorney-General and the Auditor General as detailed in the Australian Government Protective Security Policy Framework (PSPF). These can be found in the PSPF Mandatory Requirement INFOSEC 4 Explained chapter.

Compliance language

There are two categories of compliance associated with the controls in this manual - 'must' and 'should'. These compliance requirements are determined according to the degree of security risk an agency will be accepting by not implementing the associated control. ASD's assessment of whether a control is a 'must' or a 'should' is based on ASD's experience in providing cyber and information security advice and assistance to the Australian government and reflect what ASD assesses the risk level to be. Agencies may have differing risk environments and requirements, and may have other mitigations in place to reduce the residual risk to an acceptable level.

Non-compliance with multiple controls

Where an agency is non-compliant with multiple controls for similar reasons, they may group together these controls in their report to simplify the reporting process.

Compliance by smaller agencies

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.

Auditing of compliance by the Australian National Audit Office

All controls in this manual may be audited for compliance by the Australian National Audit Office (ANAO).

Controls

Topic Link
Complying with the Australian Government Information Security Manual

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.

Control: 0007; Revision: 3; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 0008; Revision: 4; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must comply with additional or alternative controls as stipulated in device and scenario-specific guidance issued by ASD.

Topic Link
Granting non-compliance

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.

Control: 0001; Revision: 5; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: 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.

Control: 1061; Revision: 1; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 1379; Revision: 0; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: N/A

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.

Topic Link
Justification for non-compliance

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.

Control: 0710; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    System owners seeking approval for non-compliance with any control must document:
  • the justification for non-compliance
  • a security risk assessment
  • the alternative mitigation measures to be implemented, if any.
Topic Link
Consultation on non-compliance

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.

    The extent of consultation with other agencies and foreign governments may include:
  • a notification of the intent to be non-compliant
  • the justification for non-compliance
  • any mitigation measures that may have been implemented
  • an assessment of the security risks relating to the information they have been entrusted with.
Control: 0711; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

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.

Topic Link
Notification of non-compliance
    The purpose of notifying authorities of any decisions to grant non-compliance with controls, as well as areas an agency is compliant with, is three-fold:
  • to ensure that an accurate picture of the state of information security across government can be maintained
  • to help inform incident response
  • to use as feedback for the ongoing refinement of this manual.
Control: 0713; Revision: 5; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should provide a copy of their compliance and non-compliance reports to ASD.

Topic Link
Reviewing non-compliance

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.

Control: 0876; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Topic Link
Recording non-compliance

Without appropriate records of decisions to grant non-compliance with controls, agencies have no record of the status of their security posture. Furthermore, a lack of such records will hinder any auditing activities that may be conducted by the agency or by external parties such as the ANAO. Failing to maintain such records is also a breach of the Archives Act 1983 (the Archives Act).

Control: 0003; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must retain a copy of decisions to grant non-compliance with any control from this manual.

References

ASD contact details can be found at http://www.asd.gov.au/contact.htm.

The PSPF's Protective Security Principles can be found at http://www.protectivesecurity.gov.au.

Information Security Governance
Information
Security
Governance

Information Security Governance

Information Security Engagement

Government Engagement

Objective

Security personnel are aware of and use security services offered in the Australian Government.

Scope

This section describes the government agencies and bodies involved in providing information security advice.

Context

Australian Signals Directorate

Australian Signals Directorate (ASD) is required under the Intelligence Services Act 2001 (the ISA) to perform various functions, including the provision of material, advice and other assistance to Commonwealth and State authorities on matters relating to the security of information that is processed, stored or communicated by electronic or similar means.

ASD provides assistance to Commonwealth and State authorities in relation to cryptography, communications and computer technologies.

ASD works with industry to develop new cryptographic products. It has established the Australasian Information Security Evaluation Program (AISEP) to assist with the increasing requirement to evaluate products with security functionality.

ASD can be contacted for advice and assistance on implementing 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 asd.assist@defence.gov.au 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 by email at asd.assist@defence.gov.au. ASD's incident response service is available 24 hours, 7 days a week.

ASD can be contacted by email at asd.assist@defence.gov.au for advice and assistance on the purchasing, provision, deployment, operation and disposal of High Assurance key material and High Assurance Cryptographic Equipment.

Other government agencies and bodies

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 BODYSERVICES
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 CollegeProvides 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 Cyber Security Centre (ACSC)The role of the ACSC is to lead the Australian Government's operational response to cyber security incidents, organise national cyber security operations and resources, encourage and receive reporting of cyber security incidents, raise awareness of the threat to Australia and study and investigate cyber threats. The ACSC includes representatives from ASD, the Australian Crime Commission (ACC), the Australian Defence Force (ADF), the Australian Federal Police (AFP), the Australian Security Intelligence Organisation (ASIO), the Computer Emergency Response Team (CERT) Australia and the Defence Intelligence Organisation (DIO).
Australian National Audit Office (ANAO)Performance audits on information security.
Australian Security Intelligence Organisation (ASIO)ASIO is responsible for collecting, analysing and reporting intelligence on threats to security.
Australian Security Intelligence Organisation (ASIO) - T4 Protective SecurityASIO-T4 Protective Security section provides advice and training, technical surveillance counter-measures, physical security certifications, protective security risk reviews and physical security equipment testing.
CERT AustraliaProvides the private sector with information and assistance to help them protect their Information and Communications Technology (ICT) infrastructure from cyber threats and vulnerabilities. CERT Australia also provides a coordination role during a serious cyber incident.
Cyber Security Operations BoardProvides strategic direction and oversight of operational cyber security matters. Chairmanship and Secretariat support provided by the Attorney General's Department.
Cyber Security Policy and Coordination CommitteeCoordinates the development of cyber security policy for the Australian Government.
Department of CommunicationsResponsible for initiatives to educate and protect home users, students and small business from electronic intrusions and fraud.
Department of FinanceDevelopment and oversight of whole-of-government policy on the Australian Government's use of information and communications technology.
Department of Foreign Affairs and TradePolicy and advice for security overseas.
Department of the Prime Minister and CabinetCoordination 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 AustraliaProvides standards and advice on capturing and managing records to ensure their integrity as evidence is maintained. The national Archives also authorises the disposal of all Commonwealth records, including those relating to ICT and security processes and incidents.
Protective Security Policy CommitteeCoordinates the development of protective security policy. Chairmanship and Secretariat support provided by the Attorney-General's Department.
Security Construction and Equipment CommitteeOversees the evaluation of physical security equipment.

Controls

Topic Link
Organisations providing information security services

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.

Control: 0879; Revision: 4; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Security personnel should familiarise themselves with the information security roles and services provided by Australian government agencies and bodies.

References

Outsourced General Information Technology Services

Objective

Information technology service providers implement appropriate security measures to protect government information.

Scope

This section describes information on outsourcing general information technology services.

Context

General information technology services

In the context of this section, general information technology services encompasses business process services, application processes and infrastructure services. The range of information technology services that can be procured from a source outside an organisation is extensive.

Contracts and Service Level Agreements

The Attorney-General's Department's Australian Government Protective Security Policy Framework (PSPF) mandatory requirement GOV 12 requires agencies ensure any service provider complies with Australian Government protective security policies and procedures where there is access to, or control over, Australian Government personnel, information or assets.

PSPF Protective security governance guidelines - Security of outsourced services and functions provides agencies with guidance for incorporating protective security requirements into contracts when outsourcing agency functions.

Controls

Topic Link
Risks of outsourced general information technology services

Outsourcing can be a cost-effective option for providing general information technology services in an agency, as well as potentially delivering a superior service; however, it can also affect an agency's risk profile. Storing information in multiple disparate locations and allowing more people to access it can significantly increase the potential for information compromise.

Control: 0873; Revision: 4; Updated: May-16; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies intending to use service providers not on ASD's Certified Cloud Services List (CCSL) must ensure that service providers are located in Australia.

Control: 1073; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must not; Authority: AA

Agency data and computing environments must not be accessed, configured or administered from outside Australian borders by a service provider unless a contractual arrangement exists between the service provider and customer to do so.

Topic Link
Accrediting service providers' services

Information technology service providers can be provided with government information as long as their systems are accredited to process, store and communicate that information. Further information on accrediting systems can be found in the System Accreditation chapter of this manual.

Control: 0872; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Service providers' systems that are used to provide information technology services, including outsourced cloud services, must be accredited prior to handling government information.

Topic Link
Due diligence

Agency privacy and security obligations for protecting government information are no different when using an outsourced information technology service, including a cloud computing service. The contract or service agreement between a vendor and their customer must address mitigations to governance, privacy and security risks, otherwise the customer only has vendor promises and marketing claims that can be hard to verify and may be unenforceable.

Control: 0072; Revision: 4; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Any measures associated with the protection of information entrusted to another party must be documented in contract provisions, a memorandum of understanding or equivalent formal agreement between parties.

Although data ownership resides with the agency, this can become less clear in some circumstances, such as when legal action is taken and a vendor is asked to provide access to, or data from, their assets. To mitigate the risk of agency data being unavailable or compromised, agencies can explicitly retain ownership of their data through contract provisions.

Control: 1451; Revision: 0; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

When entering into a contract or other agreement for information technology services, agencies should explicitly retain contractual ownership over their data.

Considering the risks that arise as systems and software are being built and delivered, as well as the degree of risk that a particular supplier may introduce into the delivery of a contracted service, will assist agencies in determining whether security measures need to be taken to mitigate the threats arising from potential supply chain exploitation. The globalised nature of ICT products increases the difficulty in evaluating supply chain integrity. Adopting a risk management approach will assist in circumstances where agencies are not able to acquire all the information necessary to do a complete risk assessment.

Control: 1452; Revision: 0; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should perform a due diligence review of suppliers, including their country of origin, before obtaining software, hardware or services, to assess the potential increase to agency security risk profiles.

References

Information on Australian Government expectations when outsourcing services and functions can be found in the Attorney-General's Department's Security of outsourced services and functions guidelines publication at http://www.protectivesecurity.gov.au/governance/contracting/Pages/Supporting-guidelines-for-contracting.aspx.

The National Institute of Standards and Technology (NIST) Special Publication 800-161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations can be found at http://csrc.nist.gov/publications/PubsDrafts.html.

Outsourced Cloud Services

Objective

Cloud service providers implement appropriate security measures to protect government information in cloud services.

Scope

This section describes information on outsourcing information technology services in a cloud computing model.

Context

Cloud computing terminology and definitions

The terminology and definitions used in this section are consistent with The NIST Definition of Cloud Computing, Special Publication 800-145, September 2011. This section also applies to cloud services that have a payment model which differs to the NIST pay-per-use measured service characteristic.

Controls

Topic Link
Risks of outsourced cloud computing services

Using outsourced cloud services can affect an agency's risk profile. Cloud services located offshore may be subject to lawful and covert collection, without the information owner's knowledge. Additionally, use of offshore cloud services introduces jurisdictional risks as foreign countries' laws could change with little warning. Further, foreign owned cloud service providers operating in Australia may be subject to a foreign government's lawful access. A comprehensive risk assessment is essential in identifying and managing jurisdictional, governance, privacy, technical and security risks.

Control: 1210; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The risks of using outsourced cloud services, including those in ASD's cloud computing advice, must be assessed and documented.

Topic Link
The Certified Cloud Services List

ASD maintains a list of cloud services certified against security and governance requirements. This can be found via the ASD website at http://www.asd.gov.au.

Control: 1395; Revision: 0; Updated: Apr-15; Applicability: UD, P; Compliance: must; Authority: AA

Agencies must only use outsourced cloud services listed on ASD's Certified Cloud Services List (CCSL).

Control: 1396; Revision: 0; Updated: Apr-15; Applicability: UD, P; Compliance: must; Authority: ASD

Agencies proposing to use outsourced cloud services not listed on ASD's CCSL must notify ASD in writing at the earliest opportunity and certainly before entering into or renewing a contract with a cloud service provider.

Control: 1397; Revision: 0; Updated: Apr-15; Applicability: C, S, TS; Compliance: must; Authority: ASD

Agencies must notify ASD in writing at the earliest opportunity during the initial stages of considering using a cloud service and certainly prior to entering or renewing a contract with a cloud service provider.

References

ASD's cloud computing advice and Certified Cloud Services List is available on ASD's public website at http://www.asd.gov.au.

Whole-of-government policy and guidance on cloud computing, including detailed legal and financial considerations for contracts, can be found on the Department of Finance's website at http://www.finance.gov.au/cloud/.

The Attorney-General's Department's Risk management of outsourced ICT arrangements (including Cloud) is available at http://www.protectivesecurity.gov.au/informationsecurity/Pages/RiskManagementOfOutsourcedICTArrangements-IncludingCloud.aspx.

The NIST Definition of Cloud Computing, Special Publication 800-145, can be accessed from the NIST website at http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.

Roles and Responsibilities

The Chief Information Security Officer

Objective

The Chief Information Security Officer (CISO) sets the strategic direction for information security for their agency.

Scope

This section describes the information security role of a CISO.

Context

The Security Executive and their CISO role

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 (PSPF). The introduction of the CISO role outside of PSPF requirements is intended to provide a more meaningful title for the Security Executive's responsibilities that relate specifically to information security.

Controls

Topic Link
Requirement for a CISO

The role of the CISO is based on industry best practice and has been introduced to ensure that information security is managed at the senior executive level.

    The CISO is typically responsible for:
  • facilitating communications between security personnel, ICT personnel and business personnel to ensure alignment of business and security objectives
  • providing strategic level guidance for the agency security program
  • ensuring compliance with national policy, standards, regulations and legislation.
Control: 0714; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

References

Nil.

The Information Technology Security Advisor

Objective

The Information Technology Security Advisor (ITSA) coordinates information technology security for their agency.

Scope

This section describes the information security role of an Information Technology Security Manager (ITSM) when designated as the ITSA.

Context

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.

Controls

Topic Link
Requirement for an ITSA

An ITSM, when fulfilling the designation of ITSA, still maintains full responsibility 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.

Control: 0013; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must designate an ITSM as the ITSA, to have responsibility for information technology security management across the agency.

Topic Link
Contacting ITSAs

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.

Control: 0025; Revision: 3; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should maintain an email address for their ITSA in the form of ITSA@agency.

References

Nil.

Information Technology Security Managers

Objective

Information Technology Security Managers (ITSMs) provide information security leadership and management for their agency.

Scope

This section describes the information security role of ITSMs.

Context

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.

Controls

Topic Link
Requirement for ITSMs
    ITSMs are generally considered information security experts and are typically responsible for:
  • managing the implementation of security measures
  • monitoring information security for systems and responding to any cyber security incidents
  • identifying and incorporating appropriate security measures in the development of ICT projects and the information security program
  • establishing contracts and service level agreements on behalf of the CISO, or equivalent
  • assisting the CISO or equivalent to develop security budget projections and resource allocations
  • providing regular reports on cyber security incidents and other areas of particular concern
  • helping system owners to understand and respond to reported audit failures
  • guiding the selection of appropriate strategies to achieve the direction set by the CISO or equivalent with respect to disaster recovery policies and standards
  • delivering information security awareness and training programs to personnel.
Control: 0741; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

References

Further information on the role of ITSAs is available in the Attorney-General's Department's Protective Security Governance Guidelines, available at http://www.protectivesecurity.gov.au.

Information Technology Security Officers

Objective

ITSOs provide information security operational support for their agency.

Scope

This section describes information security role of ITSOs.

Context

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.

Appointing ITSOs

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.

Controls

Topic Link
Requirement for ITSOs

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.

    Other responsibilities often include:
  • conducting vulnerability assessments and taking actions to mitigate threats and remediate vulnerabilities
  • working with ITSMs to respond to cyber security incidents
  • assisting ITSMs with technical remediation activities required as a result of audits
  • assisting in the selection of security measures to achieve the strategies selected by ITSMs with respect to disaster recovery
  • raising awareness of information security issues with system owners and personnel.
Control: 0768; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

References

Nil.

System Owners

Objective

System owners obtain and maintain accreditation of their systems.

Scope

This section describes the information security role of system owners.

Context

The system owner is the person responsible for an information resource.

Controls

Topic Link
Requirement for system owners

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.

Control: 1071; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Each system must have a system owner who is responsible for the operation of the system.

Control: 1072; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

System owners should be a member of the Senior Executive Service or in an equivalent management position.

Topic Link
Accreditation responsibilities

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.

References

Nil.

Information Security Documentation

Documentation Fundamentals

Objective

Information security documentation is produced for systems to support the accurate and consistent application of policy and procedures within an agency.

Scope

This section describes the information security documentation that government agencies should develop and maintain.

Context

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.

Controls

Topic Link
Information Security Policy

The Information Security Policy (ISP) is a statement of high-level information security policies and is therefore an essential part of information security documentation.

Topic Link
Security Risk Management Plan

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.

Topic Link
System Security Plan

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.

Topic Link
Standard Operating Procedures

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.

Topic Link
Incident Response Plan

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.

Control: 0043; Revision: 1; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must develop, maintain and implement an IRP and supporting procedures.

Topic Link
Developing content

It is likely that personnel who are most knowledgeable about both information security issues and the business requirements will develop the most useful and accurate information security documentation.

Control: 0886; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should ensure that information security documentation is developed by personnel with a good understanding of both the subject matter and the business requirements.

Topic Link
Documentation content

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.

Control: 0044; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should ensure that their SRMP, SSP, SOPs and IRP are logically connected and consistent for each system and with the ISP.

Topic Link
Using a documentation framework

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.

Control: 0787; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should create and maintain a document framework including a hierarchical listing of all information security documentation and their relationships.

Control: 0885; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should adopt the naming conventions provided in this manual for their information security documentation.

Topic Link
Outsourcing development of content

Agencies outsourcing the development of information security documentation still need to review and control the contents to make sure it meets their requirements.

Control: 0046; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    When information security documentation development is outsourced, agencies should:
  • review the documents for suitability
  • retain control over the content
  • ensure that all policy requirements are met.
Topic Link
Obtaining formal approval

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.

Control: 0047; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

All information security documentation should be formally approved by a person with an appropriate level of seniority and authority.

Control: 0887; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should ensure that:
  • all high-level information security documentation is approved by the agency head or their delegate
  • all system-specific documentation is approved by the system owner and an ITSM.
Topic Link
Publication of documentation

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.

Control: 1153; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Once information security documentation has been approved it should be published and communicated to all stakeholders.

Topic Link
Documentation maintenance

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.

Control: 0888; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should review information security documentation:
  • at least annually
  • in response to significant changes in the environment, business or system.
Control: 1154; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should record the date of the most recent review on each information security document.

References

Nil.

Information Security Policy

Objective

The ISP sets the strategic direction for information security for an agency.

Scope

This section describes the development of an ISP.

Context

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.

Controls

Topic Link
Contents of an ISP
    Agencies may wish to consider the following when developing their ISP:
  • the policy objectives
  • how the policy objectives will be achieved
  • the guidelines and legal framework under which the policy will operate
  • the stakeholders
  • what resourcing will be available to support the implementation of the policy
  • what performance measures will be established to ensure that the policy is being implemented effectively.

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.

Control: 0049; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The ISP should describe information security policies, standards and responsibilities.

Control: 0890; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    The ISP should cover topics such as:
  • accreditation processes
  • personnel responsibilities
  • configuration control
  • access control
  • networking and connections with other systems
  • physical security and media control
  • emergency procedures and cyber security incident management
  • change management
  • information security awareness and training.

References

Nil.

Security Risk Management Plan

Objective

A SRMP identifies security risks and appropriate mitigation measures for systems.

Scope

This section describes the development of a SRMP, focusing on security risks related to the operation of systems.

Context

A SRMP is a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.

This section should be read in conjunction with the Information Security Risk Management section of the About Information Security chapter.

Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.

Controls

Topic Link
Contents of a SRMP

Security risks cannot be managed if they are not known. Even if they are known, failing to deal with them is a failure of security risk management. For this reason a SRMP consists of two components, a security risk assessment and a corresponding risk treatment strategy.

Control: 0788; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The SRMP should contain a security risk assessment and a corresponding risk treatment strategy.

Topic Link
Agency risk management

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.

Control: 0893; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should incorporate their SRMP into their wider agency risk management plan.

Topic Link
Risk management standards
    Security risk management is of most value to an agency when:
  • it relates to the specific circumstances of an agency and its systems, and
  • it is based on an industry-recognised approach to risk management, such as those produced by Standards Australia and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC).

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.

Control: 0894; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should develop their SRMP in accordance with Australian or international standards for risk management.

References

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/.

System Security Plan

Objective

A SSP specifies the security measures for systems.

Scope

This section describes the development of a SSP.

Context

A SSP is a component of an agency's Information Security Management Framework, as mandated in the Australian Government Information Security Management Protocol.

Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.

Further information to be included in a SSP about specific functionality or technologies that could be implemented for a system can be found in the applicable areas of this manual.

Stakeholders
    There can be many stakeholders involved in defining a SSP, including representatives from the:
  • project, who must deliver the capability (including contractors)
  • owners of the information to be handled
  • users for whom the capability is being developed
  • management audit authority
  • information management planning areas
  • infrastructure management.

Controls

Topic Link
Contents of a SSP

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 release 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.

Control: 0895; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 0067; Revision: 4; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must use the latest release of this manual when developing, and updating, their SSPs as part of accreditation and reaccreditation of their systems.

References

Further information on the Australian Government Information Security Management Protocol can be found at http://www.protectivesecurity.gov.au.

Standard Operating Procedures

Objective

SOPs ensure security procedures are followed in an appropriate and repeatable manner.

Scope

This section describes the development of security related SOPs.

Context

SOPs 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.

Controls

Topic Link
Development of SOPs

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.

Control: 0051; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should develop SOPs for each of the following roles:
  • ITSM
  • ITSO
  • system administrator
  • user.
Topic Link
ITSM SOPs

The ITSM SOPs cover the management and leadership activities related to system operations.

Control: 0789; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The following procedures should be documented in the ITSM's SOPs.

TopicProcedures to be Included
Cyber security incidentsReporting and managing cyber security incidents
Topic Link
ITSO SOPs

The ITSO SOPs cover the operationally focused activities related to system operations.

Control: 0790; Revision: 2; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The following procedures should be documented in the ITSO's SOPs.

TopicProcedures to be Included
Access controlAuthorising access rights to applications and data
Asset mustersLabelling, registering and mustering assets, including media
Audit logsReviewing system audit trails and manual logs, particularly for privileged users
Configuration controlApproving and releasing changes to the system software or configurations
Cyber security incidentsDetecting 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 transfersManaging 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 equipmentManaging the destruction of unserviceable ICT equipment and media
System integrity auditReviewing 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 maintenanceManaging 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 managementAuthorising new users
Topic Link
System administrator SOPs

The system administrator SOPs support the ITSO SOPs; however, they focus on the administrative activities related to system operations.

Control: 0055; Revision: 2; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The following procedures should be documented in the system administrator's SOPs.

TopicProcedures to be Included
Access controlImplementing access rights to applications and data
Configuration controlImplementing changes to the system software or configurations
System backup and recoveryBacking up data, including audit logs
Securing backup tapes
Recovering from system failures
User account managementAdding and removing users
Setting user privileges
Cleaning up directories and files when a user departs or changes roles
Topic Link
User SOPs

The user SOPs focus on day-to-day activities that users need to know about, and comply with, when using systems.

Control: 0056; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The following procedures should be documented in the user's SOPs.

TopicProcedures to be Included
Cyber security incidentsWhat to do in the case of a suspected or actual cyber security incident
End of dayHow to secure systems at the end of the day
Media controlProcedures for handling and using media
PassphrasesChoosing and protecting passphrases
Temporary absenceHow to secure systems when temporarily absent
Topic Link
Agreement to abide by SOPs

When SOPs are produced, the intended audience needs to be made aware of their existence and acknowledge that they have read, understood and agree to abide by their contents. Additionally, the intended audience needs to be made aware of any consequences for deviating from the agreed SOP.

Control: 0057; Revision: 2; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

ITSMs, ITSOs, system administrators and users should sign a statement that they have read and agree to abide by their respective SOPs.

References

Nil.

Incident Response Plan

Objective

An IRP outlines actions to take in response to a cyber security incident.

Scope

This section describes the development of an IRP to address cyber security incidents. It does not cover physical security incidents.

Context

An IRP 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.

Controls

Topic Link
Contents of an IRP

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.

Control: 0058; Revision: 3; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    Agencies must include, as a minimum, the following content in their IRP:
  • broad guidelines on what constitutes a cyber security incident
  • the minimum level of cyber security incident response and investigation training for users and system administrators
  • the authority responsible for initiating investigations of a cyber security incident
  • the steps necessary to ensure the integrity of evidence supporting a cyber security incident
  • the steps necessary to ensure that critical systems remain operational
  • how to formally report cyber security incidents.
Control: 0059; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should include the following content in their IRP:
  • clear definitions of the types of cyber security incidents that are likely to be encountered
  • the expected response to each cyber security incident type
  • the authority responsible for responding to cyber security incidents
  • the criteria by which the responsible authority would initiate or request formal, police or Australian Security Intelligence Organisation investigations of a cyber security incident
  • other authorities which need to be informed in the event of an investigation being undertaken
  • the details of the system contingency measures or a reference to these details if they are located in a separate document.

References

Nil.

Emergency Procedures

Objective

Information and systems are, where safe, secured before personnel evacuate a facility in the event of an emergency.

Scope

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.

Context

Emergency procedures 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.

Controls

Topic Link
Evacuating facilities

During the evacuation of a facility it is important that personnel secure information and systems as they would at the end of operational hours. This includes, but is not limited to, securing media and logging off workstations. This is important as a malicious actor could use such an opportunity to gain access to applications or databases that a user had already authenticated to, or use another user's credentials, for a malicious purpose.

Control: 0062; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Topic Link
Preparing for the evacuation of facilities

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.

Control: 1159; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should include in evacuation procedures the requirement to secure information and systems during the warning phase before the evacuation.

References

Nil.

Business Continuity and Disaster Recovery Plans

Objective

Business continuity and disaster recovery plans help minimise the disruption to the availability of information and systems after an event or disaster.

Scope

This section describes the role of business continuity and disaster recovery plans in ensuring continuing operation of agencies' critical systems.

Context

Business continuity and disaster recovery plans work to maintain security in the face of unexpected events and changes.

Additional information relating to business continuity can be found in the Service Continuity for Online Services section of the Network Security chapter.

Controls

Topic Link
Availability requirements

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.

Control: 0118; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must determine availability requirements for their systems and implement appropriate security measures to support these requirements.

Topic Link
Backup strategy

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. Where practical, backups should be stored offline to mitigate the risk of agency data being unavailable due to compromise or deletion.

Control: 0119; Revision: 4; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    Agencies must:
  • back up all information identified as critical to their business
  • store backups of critical information, with associated documented recovery procedures, at a remote location secured in accordance with the requirements for the sensitivity or classification of the information
  • test backup and restoration processes regularly to confirm their effectiveness.
Topic Link
Business continuity plans

Developing a business continuity plan can help ensure that critical functions of systems continue to operate when the system is in a degraded state. For example, when limited bandwidth is available on networks, agencies may choose to strip all large attachments from emails. This is a mandatory requirement of the PSPF.

Topic Link
Disaster recovery plans

Developing a disaster recovery plan will reduce the time between a disaster occurring and critical functions of systems being restored.

References

Additional information relating to business continuity is contained in HB 221:2004, Business Continuity Management.

System Accreditation

Accreditation Framework

Objective

The accreditation process allows for formal recognition and acceptance of the residual security risk a system and the information that it processes, stores or communicates.

Scope

This section details an agency's accreditation responsibilities. For the purposes of this Manual, 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.

Context

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.

    The accreditation framework comprises three layers:
  • accreditation:
    • formally accepting the residual security risk
    • awarding approval to operate the system.
  • certification:
    • providing independent assurance and acceptance of the audit
    • determining the residual security risk relating to the operation of the system.
  • security assessment or audit:
    • reviewing the system architecture
    • assessing the actual implementation and effectiveness of security measures.

Detailed information about the processes and the requirements for conducting accreditations, certification and security assessments or audits is given in the Conducting Accreditations, Conducting Certifications and Conducting Security Assessments or Audits sections of this chapter.

Controls

Topic Link
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.

Developing and implementing an accreditation framework ensures that accreditation activities are conducted in a repeatable and consistent manner across the agency.

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.

Control: 0064; Revision: 6; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Systems must be awarded accreditation before they are used to process, store or communicate sensitive or classified information.

Control: 0076; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must not; Authority: AA

Agencies must not allow a system to process, store or communicate information above the sensitivity or classification for which the system has received accreditation.

Control: 0077; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must not; Authority: AA

Systems must not process, store or communicate caveated or compartmented information unless specifically accredited for such purposes.

Topic Link
Determining authorities

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.

Control: 0793; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

For multinational and multi-agency systems, the certification and accreditation authorities should be determined by a formal agreement between the parties involved.

Topic Link
Notifying authorities

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.

Control: 0082; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

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.

Topic Link
Reaccreditation

Threat environments and business needs are dynamic. Agencies should reaccredit their systems every two years to ensure their security measures are appropriate in the current environment, as security measures and processes may cease to be effective over time.

Once three years have elapsed since the last accreditation, the agency needs to either reaccredit the system or seek approval for non-compliance from their accreditation authority.

While regular accreditation activities are highly beneficial in maintaining the security posture of a system, other activities may necessitate a need for an accreditation outside of regularly scheduled timeframes. This may include:

  • changes in information security policies
  • detection of new or emerging threats to systems
  • the discovery that security measures are not operating as effectively as planned
  • the occurence of a major cyber security incident
  • architectural changes to the system
  • changes to the system risk profile
  • changes to an agency's risk appetite, ICT resourcing or senior support.

To assist in the reaccreditation of systems, agencies are encouraged to reuse as much information from previous accreditations as possible including, where appropriate, concentrating on the delta between the security posture of the system at the time of the last accreditation and the current security posture of the system.

Control: 0069; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should ensure that the period between accreditations of systems does not exceed two years.

Control: 0070; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must ensure that the period between accreditations of systems does not exceed three years.

References

For agencies wishing to gain a physical security certification for Sensitive Compartmented Information Facility (SCIF) areas in addition to their ICT certification, a SCIF Support Pack is available from ASD on request.

Conducting Accreditations

Objective

The accreditation process allows for formal recognition and acceptance of the residual security risk a system and the information that it processes, stores or communicates.

Scope

This section describes conducting an accreditation for a system.

Context

Accreditation authorities

For TOP SECRET systems the accreditation authority is ASD.

For systems SECRET and below, the accreditation authority is the agency head or their formal delegate, which is strongly recommended to be the CISO or equivalent.

For systems that process, store or communicate caveated or compartmented information there may be a mandated accreditation authority external to the agency operating the system.

For multinational and multi-agency systems the accreditation authority is determined by a formal agreement between the parties involved.

For commercial providers providing services to agencies, the accreditation authority is the head of that 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.

Accreditation outcomes

Accreditation for a system is awarded when the accreditation authority formally recognises and accepts the residual security risk to a system and its information, and gives formal approval for the system to operate. However, in some cases the accreditation authority may not accept the residual security risk due to security risks and measures being inadequately scoped for the system. In such cases the accreditation authority may request that further work be undertaken by the system owner before reconsidering the system for accreditation. In the intervening time, the accreditation authority may choose to issue an interim approval to operate with caveats placed on the system's use.

Accreditation process

The following diagram shows, at a high level, the process of accreditation.

Controls

Topic Link
Accreditation Process

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.

Control: 0795; Revision: 3; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

All systems must undergo certification as part of the accreditation process; unless the accreditation authority is satisfied that if the system is not immediately operational it would have a devastating and potentially long-lasting effect on operations.

Topic Link
Awarding accreditation

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 accreditation decision, the accreditation authority may review:
  • the SRMP for the system
  • the report of compliance from the audit
  • the certification report from the certification authority
  • any decisions to be non-compliant with any controls specified in this manual
  • any additional security risk reduction strategies that have been implemented.

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.

Control: 0808; Revision: 1; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The accreditation authority must accept the residual security risk to a system and the information it processes, stores or communicates in order to award accreditation.

Control: 1229; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S; Compliance: must; Authority: AA

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.

Control: 1230; Revision: 1; Updated: Feb-14; Applicability: TS; Compliance: must; Authority: ASD

For TOP SECRET systems, the accreditation authority must be ASD.

References

Nil.

Conducting Certifications

Objective

Certification allows for formal recognition and acceptance that the chosen security measures for a system have been implemented effectively.

Scope

This section describes conducting a certification as part of the accreditation process for a system.

Context

Certification aim

The aim of certification is to ensure the security assessment or audit for a system was conducted in an appropriate manner and to a sufficiently high standard.

Certification outcome

The outcome of certification is a certification report to the accreditation authority outlining the security measures that have been implemented for a system and the residual risk it poses to the system and the information that it processes, stores or communicates.

Certification authorities

For TOP SECRET systems the certification authority is ASD.

For SECRET or below systems the certification authority is the agency ITSA.

For systems that process, store or communicate caveated or compartmented information there may be a mandated certification authority external to the agency operating the system.

For multinational and multi-agency systems the certification authority is determined by a formal agreement between the parties involved.

For commercial providers providing services to agencies, the certification authority is the ITSA of the agency sponsoring the provider.

For providers of gateway services, either government or commercial, intended for use by multiple agencies across government, ASD performs the role of the certification authority as an independent third party.

Controls

Topic Link
Certification process

A security assessment, or audit, reviews the system architecture and assesses the actual implementation and effectiveness of security measures.

Control: 1141; Revision: 1; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

All systems must undergo a security assessment, also known as an audit, as part of the certification process.

Topic Link
Awarding certification

To award certification for a system the certification authority needs to be satisfied that the security measures identified by the system owner have been implemented and are operating effectively. However, certification only acknowledges that the identified security measures were implemented and are operating effectively and not that the residual security risk is acceptable or an approval to operate has been awarded.

Control: 1142; Revision: 0; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The certification authority must accept the effectiveness of controls for the system in order to award certification.

Topic Link
Certification outcomes

To assist the accreditation authority in determining whether to award accreditation for a system or not, the certification authority will need to produce a certification report outlining the security measures that have been implemented for the system and an assessment of the residual security risk relating to the system and information that it processes, stores or communicates.

Control: 0807; Revision: 3; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

The certification authority should produce a certification report for the accreditation authority outlining the security measures that have been implemented for a system and an assessment of the residual security risk relating to the system and the information that it processes, stores or communicates.

Topic Link
Certification of gateway services

Agencies may provide their own gateway services, or outsource this function to a commercial provider. In either case, gateway services intended for use by multiple agencies are required to undergo a security assessment, also known as an audit, conducted by an Information Security Registered Assessor and be awarded certification from ASD. Even though ASD may award certification to a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.

Control: 0100; Revision: 6; Updated: Apr-15; Applicability: UD, P; Compliance: must; Authority: AA

Commercial or government-provided gateway services intended for use by multiple agencies must undergo an Information Security Registered Assessor Program Audit and be awarded certification by ASD annually.

Topic Link
Certification of cloud services

Cloud services are required to undergo a security assessment, also known as an audit, conducted by an Information Security Registered Assessor and be awarded certification from ASD. Even though ASD may award certification to a cloud service, agencies using the cloud service still need to decide whether accreditation should be awarded or not. Cloud services are only permitted to handle Australian government information if they have been certified by ASD and accredited by agencies intending to use the cloud service.

Control: 1459; Revision: 0; Updated: Apr-15; Applicability: UD, P; Compliance: must; Authority: AA
    Cloud services storing, processing or communicating Australian government information must undergo an Information Security Registered Assessor Program Audit and be awarded certification by ASD at least every two years, or sooner in the event of:
  • significant changes in information security policies
  • detection of new or emerging threats to systems
  • the discovery that security measures are not operating as effectively as planned
  • a major cyber security incident
  • changes to the system architecture or its security risk profile.

References

ASD's cloud computing advice and Certified Cloud Services List is available on ASD's public website at http://www.asd.gov.au.

Conducting Security Assessments or Audits

Objective

The implementation and effectiveness of security measures for a system is assessed.

Scope

This section describes conducting a security assessment, also known as an audit, as part of the certification process for a system.

Context

Terminology
Security assessment or audit aim

The aim of a security assessment, also known as an audit, is to review the system architecture and assess the actual implementation and effectiveness of security measures.

Security assessment or audit outcome

The outcome of asecurity assessment, also known as an audit, is a report to the certification authority describing the implementation and effectiveness of security measures for a system. This includes areas of compliance and non-compliance for a system and any suggested remediation actions.

Who can conduct a security assessment or audit

Security assessments, also known as audits, for TOP SECRET systems can only be undertaken by ASD and Information Security Registered Assessors.

Security assessments, also known as audits, for SECRET and below systems can be undertaken by agency ITSMs and Information Security Registered Assessors.

Who can assist with a security assessment or audit

A number of agencies and personnel are often consulted during a security assessment, also known as an audit.

    Agencies or personnel who can be consulted on physical security aspects of systems include:
  • the Australian Security Intelligence Organisation for TOP SECRET sites
  • the Department of Foreign Affairs and Trade for systems located at overseas posts and missions
  • the Agency Security Advisor (ASA) for all other systems.

The ASA can also be consulted on personnel security aspects of systems.

An ITSM or communications security officer can be consulted on communications security aspects of systems.

Independent security assessments or audits

A security assessment, also known as an audit, can be conducted by an agency's own assessors. However, the agency may choose to add an extra level of objectivity by engaging the services of an Information Security Registered Assessor to undertake the security assessment or audit.

Connections to certain inter-agency systems could require an independent security assessment or audit from an Information Security Registered Assessor as a prerequisite to certification. Such requirements can be obtained from the inter-agency system owners.

Controls

Topic Link
Independence of assessors

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.

Control: 0902; Revision: 4; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should not; Authority: AA

Assessors of systems should not also be the system owner or certification authority.

Topic Link
Preparing for a security assessment or audit

Ensuring that the system owner has approved the system architecture and associated information security documentation assists assessors in understanding the scope of work for the first stage of the audit.

Control: 0797; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Before undertaking the security assessment, also known as an audit, the system owner must approve the system architecture and associated documentation.

Control: 0904; Revision: 3; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Before undertaking a security assessment, also known as an audit, the system owner should provide a statement of applicability for the system which includes:
  • the version of this manual, and any complementary publications, used for determining security measures
  • controls from this manual that are, and are not, applicable to the system
  • controls from this manual that are applicable but are not being implemented (including the rationale behind these decisions)
  • any additional security measures being implemented.
Topic Link
The process for a security assessment or audit

The purpose of a security assessment, also known as an audit, is two-fold: to determine that the system architecture is based on sound security principles and to determine whether the security measures chosen have been implemented and are operating effectively.

Control: 0798; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    The system architecture, including associated documentation, must be reviewed by the assessor to determine whether it is based on sound security principles. This includes:
  • determining whether appropriate policies have been developed to protect information that is processed, stored or communicated by the system
  • determining whether the SRMP, SSP, SOPs and IRP are comprehensive and appropriate for the environment the system is to operate in
  • determining whether all relevant controls specified in this manual and supplementary publications are addressed.
Control: 0805; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The security measures for the system must be reviewed by the assessor to determine whether they have been implemented and are operating effectively.

Control: 0806; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The assessor must ensure that, where applicable, a currently valid physical security certification has been awarded by an appropriate physical security certification authority.

Topic Link
Outcomes of a security assessment or audit

To assist the certification authority in determining whether to award certification for a system or not the assessor will need to produce a report outlining areas of concern for the system including any suggested remediation actions.

Control: 1140; Revision: 1; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The assessor must produce a report for the certification authority outlining areas of non-compliance for a system and any suggested remediation actions.

References

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/irap.

Information Security Monitoring

Vulnerability Management

Objective

Vulnerability management activities contribute to the security of systems.

Scope

This section describes agencies' requirements for conducting vulnerability management activities for their systems.

Context

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.

Controls

Topic Link
Vulnerability management strategy

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.

Control: 1163; Revision: 1; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should implement a vulnerability management strategy by:
  • conducting vulnerability assessments on systems throughout their life cycle to identify vulnerabilities
  • analysing identified vulnerabilities to determine their potential impact and appropriate mitigations or treatments based on effectiveness, cost and existing security controls
  • using a risk-based approach to prioritise the implementation of identified mitigations or treatments
  • monitoring new information on new or updated vulnerabilities in operating systems, software and devices as well as other elements which may adversely impact on the security of a system.
Topic Link
Conducting vulnerability assessments

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.

Control: 0909; Revision: 4; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should have vulnerability assessments conducted by suitably skilled personnel independent to the target of the assessment or by an independent third party.

    An agency may choose to undertake a vulnerability assessment either:
  • as a result of a specific cyber security incident
  • after a change to a system or its environment that significantly impacts on the agreed and implemented system architecture and information security policy
  • as part of a regular scheduled assessment.

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.

    Depending on the scope and subject of the vulnerability assessment, agencies may gather information on areas such as:
  • agency priorities, risk appetite and business requirements
  • system functional and security requirements
  • risk assessments, including threat data, likelihood and consequence estimates, and existing controls in place
  • effectiveness of existing controls
  • other possible controls
  • vendor and other security best practices.
    Vulnerability assessments can consist of:
  • conducting documentation-based security reviews of systems' designs before they are implemented
  • detailed manual testing to provide a detailed, in-depth assessment of a system once implemented
  • supplementing manual testing with automated tools to perform routine, repeatable security testing. These tools should be from a reputable and trusted source.
Control: 0911; Revision: 4; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should conduct vulnerability assessments on systems:
  • before the system is deployed, this includes conducting assessments during the system design and development stages
  • after a significant change to the system
  • after significant changes to the threats or risks faced by a system, for example, a software vendor announces a critical vulnerability in a product used by the agency
  • at least annually, or as specified by an ITSM or the system owner.
Topic Link
Analysing and mitigating vulnerabilities

Agencies are encouraged to monitor information about new vulnerabilities that could affect their systems. However, if no vulnerabilities are disclosed in specific products used in their systems it is important agencies are not complacent.

Vulnerabilities can be introduced as a result of poor security practices, implementations or accidental activities. Therefore, even if no new vulnerabilities in deployed products have been disclosed there is still value to be gained from conducting regular vulnerability analysis.

Furthermore, by monitoring vulnerability sources/alerts, conducting vulnerability analysis, keeping up to date with industry and product advances, and keeping up to date with changes to this manual, agencies will become aware of factors which may adversely impact the security risk profile of their systems.

Agencies may wish to consider that discovered vulnerabilities could be a result of their security practices, accidental activities or malicious activities and not just as the result of a technical issue.

To determine the potential impact and possible mitigations to a system, comprehensive documentation and an understanding of the system are required. External sources that can be monitored for information on new vulnerabilities are vendor published vulnerability information, other open sources and subscription services.

Mitigation efforts are best prioritised using a risk-based approach in order to address the most significant vulnerabilities first. Where two or more vulnerabilities are of similar importance, the mitigations with lower cost (in time, staff and capital) can be implemented first.

Control: 0112; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must analyse any vulnerabilities to determine their potential impact on the agency and determine appropriate mitigations or other treatments.

Control: 0113; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must mitigate or otherwise treat identified vulnerabilities as soon as possible.

References

A high-level summary of vulnerability assessment, analysis and management can be found in ASD's Protect publication Know and minimise your vulnerabilities before they are used against you. Protect publications can be accessed through the ASD public website at http://www.asd.gov.au

Change Management

Objective

Information security is an integral part of change management policy and process.

Scope

This section describes the importance of maintaining the security of systems when implementing routine and urgent changes.

Context

Identifying the need for change
    The need for change can be identified in various ways, including:
  • identification of security vulnerabilities, new threats and associated mitigations
  • users identifying problems or need for enhancements
  • vendors notifying upgrades to software or ICT equipment
  • vendors notifying the end of life for software or ICT equipment
  • advances in technology in general
  • implementing new systems that necessitate changes to existing systems
  • business process change
  • identifying new tasks requiring updates or new systems
  • organisational change
  • standards evolution
  • government policy or Cabinet directives
  • other incidents or continuous improvement activities.
Types of system change
    A proposed change to a system could involve either:
  • an upgrade to, or introduction of, ICT equipment
  • an upgrade to, or introduction of, software
  • major changes to security controls.

Controls

Topic Link
Change management process

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.

Control: 0912; Revision: 4; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should ensure their change management process includes:
  • a policy which identifies which changes need to go through the formal change management process
  • documenting the changes to be implemented
  • formal approval of the change request
  • maintaining and auditing logs of all changes
  • conducting vulnerability management activities when significant changes have been made to the system
  • testing and implementing the approved changes
  • updating the relevant information security documentation including the SRMP, SSP and SOPs
  • notifying and educating users of the changes that have been implemented as close as possible to the time the change is applied
  • continually educating users in regard to changes.
Control: 0115; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    Agencies must ensure that for routine and urgent changes:
  • the change management process, as defined in the relevant information security documentation, is followed
  • the proposed change is approved by the relevant authority
  • any proposed change that could impact the security of a system is submitted to the accreditation authority for approval
  • all associated information security documentation is updated to reflect the change.
Control: 0117; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

The change management process must define appropriate actions to be followed before and after urgent changes are implemented.

Topic Link
Changes impacting the security of a system

The accreditation for a system is the acceptance of the residual security risk relating to the operation of the system. It is important therefore that, when a change occurs that affects the overall security risk for the system, the accreditation authority is consulted on whether that residual security risk is still acceptable.

Control: 0809; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

References

Nil.

Cyber Security Incidents

Detecting Cyber Security Incidents

Objective

Tools and appropriate procedures are in place to detect cyber security incidents.

Scope

This section describes controls aimed at detecting cyber security incidents. It does not cover detecting physical and personnel security incidents.

Context

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.

    Additional information relating to detecting cyber security incidents can be found in the following chapters and sections:
  • Information Security Monitoring: Vulnerability Management
  • Personnel Security for Systems: Information Security Awareness and Training
  • Access Control: Event Logging and Auditing
  • Network Security: Network Design and Configuration.

Controls

Topic Link
Preventing and detecting cyber security incidents

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.

ToolDescription
Anomaly detection systemsMonitor network and host activities that do not conform to normal system activity.
Intrusion Detection SystemsSome 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 analysisInvolves collecting and analysing event logs using pattern recognition to detect anomalous activities.
Network and host IDSsMonitor and analyse network and host activity, usually relying on a list of known malicious signatures to recognise potential cyber security incidents.
System integrity verificationUsed 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.
Control: 0120; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA
    Agencies must develop, implement and maintain tools and procedures covering the detection of potential cyber security incidents, incorporating:
  • counter-measures against malicious code
  • intrusion detection strategies
  • audit analysis
  • system integrity checking
  • vulnerability assessments.
Control: 0121; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

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.

References

Nil.

Reporting Cyber Security Incidents

Objective

Reported cyber security incidents assist in maintaining an accurate threat environment picture for government systems.

Scope

This section describes agencies' responsibilities for reporting cyber security incidents. It does not cover reporting physical or personnel security incidents.

Context

Cyber security incidents and outsourcing

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.

Categories of cyber security incidents

The Cyber Security Incident Reporting (CSIR) scheme defines cyber security incidents that are reportable to ASD.

Controls

Topic Link
Reporting cyber security incidents

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.

Control: 0123; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must direct personnel to report cyber security incidents to an ITSM as soon as possible after the cyber security incident is discovered.

Control: 0124; Revision: 3; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should:
  • encourage personnel to note and report any observed or suspected security weaknesses in, or threats to, systems or services
  • establish and follow procedures for reporting software malfunctions
  • put mechanisms in place to enable the types, volumes and costs of cyber security incidents and malfunctions to be quantified and monitored
  • manage the violation of information security policies and procedures by personnel through a formal disciplinary process.
Topic Link
Reporting cyber security incidents to ASD

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.

Reporting cyber security incidents to ASD via a CSIR (available from ASD's website) will enable ASD triage, mitigation and containment of the threat if required. Reporting ensures that appropriate and timely assistance can be provided and allows ASD to maintain an accurate threat environment picture for government systems through the CSIR scheme.

Control: 0140; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should formally report cyber security incidents using the CSIR scheme.

Topic Link
Outsourcing and cyber security incidents

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.

Control: 0141; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Topic Link
Cryptographic keying material

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.

Control: 0142; Revision: 1; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must notify all communications security custodians of any suspected loss or compromise of keying material.

Topic Link
High Assurance Cryptographic Equipment keying material

ACSI 107 applies to all agencies including contractors. Its requirements cover all High Assurance Cryptographic Equipment products used to process classified information.

For security incidents involving the suspected loss or compromise of keying material for High Assurance products, ASD will investigate the possibility of compromise and, where possible, initiate action to reduce the impact of the compromise.

Control: 0143; Revision: 6; Updated: May-16; Applicability: UD, P, C, S, TS; Compliance: must; Authority: ASD

Agencies must notify ASD of any suspected loss or compromise of High Assurance Cryptographic Equipment or keying material associated with High Assurance Cryptographic Equipment in accordance with ACSI 107.

References

Further information on reporting cyber security incidents is located on the ASD website at http://www.asd.gov.au/infosec/reportincident.htm.

Managing Cyber Security Incidents

Objective

Appropriate remedies assist in preventing future cyber security incidents.

Scope

This section describes agencies' responsibilities for managing cyber security incidents.

Context

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).

Controls

Topic Link
Cyber security incident management documentation

Documenting responsibilities and procedures for cyber security incidents in relevant SSPs, SOPs and the IRP ensures that when a cyber security incident does occur, personnel can respond in an appropriate manner. In addition, ensuring that users are aware of reporting procedures assists in capturing any cyber security incidents that an ITSM, ITSO or system owner fails to notice.

Control: 0122; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must detail cyber security incident responsibilities and procedures for each system in the relevant SSP, SOPs and IRP.

Topic Link
Recording cyber security incidents

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.

Control: 0125; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should ensure that all cyber security incidents are recorded in a register.

Control: 0126; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should include, at a minimum, the following information in their register:
  • the date the cyber security incident was discovered
  • the date the cyber security incident occurred
  • a description of the cyber security incident, including the personnel and locations involved
  • the action taken
  • to whom the cyber security incident was reported
  • the file reference.
Control: 0916; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should use their register as a reference for future security risk assessments.

Topic Link
Handling data spills

Assuming that information is compromised as a result of a cyber security incident allows an agency to apply procedures in response to the incident that has occurred. A worst case scenario would entail an intruder gaining access to a range of classified documentation and should be handled accordingly.

Control: 0129; Revision: 1; Updated: Sep-09; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

When a data spill occurs agencies must assume that the information has been compromised.

Control: 0130; Revision: 1; Updated: Sep-09; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 0131; Revision: 1; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must document procedures for managing data spills in their IRP.

Control: 0132; Revision: 2; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must treat any data spill as a cyber security incident and follow the IRP to manage it.

Control: 0133; Revision: 0; Updated: Sep-08; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

When a data spill occurs, agencies must report the details of the data spill to the information owner.

Topic Link
Containing data spills

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.

Control: 0134; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must not; Authority: AA

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.

Control: 0135; Revision: 3; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: should not; Authority: AA

When information is introduced onto a system not accredited to handle the information, personnel should not copy, print or email the information.

Control: 0136; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

When information is introduced onto a system not accredited to handle the information, agencies should segregate the affected system from the network.

Topic Link
Handling malicious code infection

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.

Control: 0917; Revision: 5; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should follow the steps described below when malicious code is detected:
  • isolate the infected system
  • decide whether to request assistance from ASD, and if such assistance is requested and agreed to, delay any further action until advised by ASD to continue
  • scan all previously connected systems, and any media used in a set period leading up to the cyber security incident, for malicious code
  • isolate all infected systems and media to prevent reinfecting the system
  • change all passwords and key material stored or potentially accessed from compromised systems
  • advise users of any relevant aspects of the compromise, including changing all passphrases on the compromised systems and any other system that uses the same passphrase
  • use current antivirus or other Internet security software to remove the infection from the systems or media
  • report the cyber security incident and perform any other activities specified in the IRP
  • where possible, restore a compromised system from a known good backup or rebuild the affected machine.

Upon reporting the incident to ASD, agencies are likely to be asked to provide information to ASD regarding the incident that will assist ASD investigations and response. If agencies have an understanding of the types of information that ASD might request then this can significantly shorten incident investigation and response times.

    ASD might request:
  • event logs
  • application whitelisting logs
  • antivirus logs
  • proxy logs
  • VPN logs
  • DNS logs
  • DHCP logs
  • mail server logs.

For more information on event logging, including required retention periods, see the Event Logging and Auditing section of the Access Control chapter.

Topic Link
Allowing continued intrusions for the purpose of scoping the incident

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.

Control: 1212; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of scoping the intrusion should inform their accreditation authority.

Topic Link
Allowing continued intrusions for the purpose of gathering information

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).

Control: 0137; Revision: 1; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of seeking further information or evidence must seek legal advice.

Topic Link
Integrity of evidence

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.

Control: 0138; Revision: 2; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies should:
  • transfer a copy of raw audit trails onto media for secure archiving, as well as securing manual log records for retention
  • ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation.
Topic Link
Seeking assistance

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.

Control: 0915; Revision: 4; Updated: Feb-14; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

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.

Topic Link
Post-incident analysis

System analysis after a successful intrusion helps to ensure the incident has been contained and removed from the system. After an incident has occurred, agencies may wish to perform post-incident analysis on their system by conducting a full network traffic capture. Agencies will be able to identify anomalous behaviour that may indicate an intruder persisting on the system, perform post-incident analysis and ensure mitigations put in place are effective.

Control: 1213; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should perform a post-incident analysis of successful intrusions, storing network traffic for at least seven days after the incident.

References

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
Physical
Security

Physical Security

Physical Security for Systems

Facilities and Network Infrastructure

Objective

Physical security measures are applied to facilities and network infrastructure to protect systems.

Scope

This section describes the requirements for the physical security of facilities and network infrastructure.

Context

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.

Facilities

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.

Physical security certification authorities
    The certification of physical security measures is undertaken by:
  • the ASA for Zone Two to Zone Four security areas
  • ASIO for Zone Five security areas.

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 providing services, the certification authority is the ASA of the sponsoring agency.

Physical security accreditation authorities

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.

Controls

Topic Link
Facilities located outside of Australia
Control: 1214; Revision: 0; Updated: Sep-12; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies operating sites in posts or missions located outside of Australia should contact the Department of Foreign Affairs and Trade to determine requirements.

Topic Link
Facility and network infrastructure physical security

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 without 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.

Control: 0810; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Topic Link
Network infrastructure in unsecured spaces

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 Cryptographic Equipment.

Control: 0157; Revision: 4; Updated: Feb-14; Applicability: UD, P, C, S; Compliance: must; Authority: AA

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.

Control: 1358; Revision: 1; Updated: Apr-15; Applicability: TS; Compliance: must; Authority: ASD

Agencies communicating TOP SECRET or codeword information outside a Zone Five security area boundary must encrypt information using High Assurance Cryptographic Equipment.

Topic Link
Preventing observation by unauthorised people

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.

Control: 0164; Revision: 1; Updated: Sep-09; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA

Agencies should prevent unauthorised people from observing systems, in particular, displays and keyboards.

References

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.

Servers and Network Devices

Objective

Server and communication rooms protect servers and network devices.

Scope

This section describes the requirements for the physical security of servers and network devices.

Context

Information relating to the physical security of facilities, network infrastructure and ICT equipment and media can be found in other sections of this chapter.

Server and communications rooms

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.

Controls

Topic Link
Controlling physical access to network devices

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.

Control: 1296; Revision: 1; Updated: Apr-15; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must implement physical security measures to protect network devices, especially those in public areas, from physical damage or unauthorised access.

Topic Link
Securing server rooms, communications rooms and security containers

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.

Control: 1053; Revision: 1; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Control: 0813; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must not; Authority: AA

Agencies must not leave server rooms, communications rooms and security containers or rooms in an unsecured state.

Control: 1074; Revision: 1; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must ensure that keys or equivalent access mechanisms to server rooms, communications rooms and security containers or rooms are appropriately controlled.

Topic Link
No-lone zones

Areas containing particularly sensitive materials or ICT equipment can be provided with additional security through the use of a designated no-lone zone. The aim of this designation is to enforce two-person integrity, where all actions are witnessed by at least one other qualified or knowledgeable person.

Control: 0150; Revision: 1; Updated: Nov-10; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies operating no-lone zones must suitably signpost the area and have all entry and exit points appropriately secured.

References

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

Objective

ICT equipment and media is physically secured during operational and non-operational hours.

Scope

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.

Context

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.

Controls

Topic Link
Accounting for ICT equipment and media
Control: 0159; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must account for all sensitive and classified ICT equipment and media.

Control: 0336; Revision: 2; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

Agencies must register all ICT equipment and media with a unique identifier in an appropriate register.

Topic Link
Securing ICT equipment and media

During operational and non-operational hours, ICT equipment and media needs to be stored in accordance with the Australian Government Physical Security Management Protocol.

    The physical security requirements of the Australian Government Physical Security Management Protocol can be achieved by:
  • ensuring ICT equipment and media always resides in an appropriate security zone
  • storing ICT equipment and media during non-operational hours in an appropriate security container or room
  • using ICT equipment with a removable hard drive which is stored during non-operational hours in an appropriate security container or room as well as sanitising the ICT equipment's Random Access Memory (RAM)
  • using ICT equipment without a hard drive as well as sanitising the ICT equipment's RAM
  • using an encryption product to reduce the physical storage requirements of the hard drive in ICT equipment to an unclassified level as well as sanitising the ICT equipment's RAM.
Control: 0161; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: must; Authority: AA

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.

Topic Link
Reducing the physical storage requirements for ICT equipment

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.

Control: 0162; Revision: 3; Updated: Sep-11; Applicability: UD, P, C, S, TS; Compliance: should; Authority: AA
    Agencies preventing the storage of sensitive or classified information on hard drives and enforcing scrubbing of the operating system's swap files and other temporary data at logoff or shutdown should:
  • assess the security risks associated with such a practice
  • in the SSP specify the processes and conditions for their application.

References

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.