Purpose of the Australian Government Information Security Manual

The purpose of this manual is to assist Australian government agencies, organisations and entities in applying a risk-based approach to protecting their information and systems. While there are other standards and guidelines designed to protect information and systems, the advice in this manual is specifically based on ASD's experience in providing cyber and information security advice and assistance to the Australian government. The controls are therefore designed to mitigate the most likely threats to Australian government agencies.

Applicability

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

Non-government organisations and entities may also use the ISM in its entirety or as a list of controls for alternative compliance frameworks.

Authority

• 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 that do not hold official, sensitive or security classified information can determine their own security measures based on their business needs, risk appetite and security risks to their systems. However, ASD encourages such agencies to use this manual, particularly the objectives, as a guide when determining security measures for their systems.

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 and are vulnerable to interception or manipulation, should be treated as public network infrastructure in the context of relevant ISM controls.

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

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 [b]Executive Companion[/b] 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 [b]Principles[/b] 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 [b]Controls[/b] 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.

• [b]Objective[/b] - the desired outcome of complying with the controls specified in the section, expressed as if the outcome has already been achieved
• [b]Scope and Context[/b] - the scope and applicability of the section. It can also include definitions, legislative context, related ISM sections and background information
• [b]Controls[/b] - procedures with associated compliance requirements for mitigating security risks to an agency's information and systems
• [b]References[/b] - 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.

• 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 agency's risk assessment.

James Mouat maintains a complete checklist (for all classifications) and is avaliable for free along with additional tools from his website: [link]james.mouat.net.au/ism/[/link]

Taking a risk-based approach to Information Security

The [i]Australian Government Protective Security Policy Framework[/i] requires that agencies adopt a risk management approach to cover all areas of protective security activity across their agency. ASD recommends information security forms a part of an agency's broader risk management processes.

The ISM represents best practice in mitigating or minimising the threat to Australian government information and systems. However, due to the differences between government agencies, there is no one-size-fits-all model for information security. Taking a risk-based approach to information security provides agencies the flexibility to conduct their business and develop resilience in the face of a changing threat environment.

It may not be possible or appropriate for an agency to implement all controls included in this manual. Agencies will have different security requirements, business needs and risk appetites from one another. The ISM aims to assist agencies in understanding the potential consequences of non-compliance-and whether such non-compliance presents an acceptable level of risk-as well as selecting appropriate risk mitigation strategies.

Agencies should consult best practice risk assessment advice appropriate to their agency provided by the [i]Australian Government Protective Security Policy[/i] or national and international standards.

Applicability of controls

While this manual provides controls for various technologies, not all systems will use all of the technologies mentioned. When agencies develop or procure systems they will need to determine the appropriate scope of the systems and which controls in this manual are applicable.

Not all ISM requirements can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.

This section should be read in conjunction with the Security Risk Management Plans section of the Information Security Documentation chapter. Further information on vulnerability assessments and managing change can be found in the Information Security Monitoring chapter.

Identifying and analysing information security risks

• 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?

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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 and territory authorities on matters relating to the security of information that is processed, stored or communicated by electronic or similar means.

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

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

Contacting ASD

ASD can be contacted for advice and assistance on implementing the controls in this manual through agency Information Technology Security Managers (ITSMs) or Information Technology Security Advisors (ITSAs).

ITSMs and ITSAs can contact ASD using the following means:
• email at [link]asd.assist@defence.gov.au[/link]
• 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 [link]asd.assist@defence.gov.au[/link]. ASD’s incident response service is available 24 hours, 7 days a week.

ASD can be contacted by email at [link]asd.assist@defence.gov.au[/link] 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.

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.

General information technology services

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

Cloud computing services

The terminology and definitions used in this section for cloud computing services are consistent with [i]The National Institute of Standards and Technology (NIST) Definition of Cloud Computing[/i], 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 [i]measured service[/i] characteristic.

Contracts and Service Level Agreements

Where service providers have access to, or control over, Australian government personnel, information or assets, agencies are required to ensure that the service providers comply with Australian government protective security policies and procedures, as described in mandatory requirement GOV 12 in the Australian Government Protective Security Policy Framework (PSPF) produced by the Attorney-General’s Department.

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

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.

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.

The Certified Cloud Services List (CCSL)

ASD maintains a Certified Cloud Services List (CCSL), which lists cloud services certified against security and governance requirements.

This can be found via the ASD website at [link]http://www.asd.gov.au[/link].

Accrediting service providers' services

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

Due diligence

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

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

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

The Security Executive and their CISO role

The CISO role is intended to be performed by the Security Executive, which is a position mandated by the Australian Government Protective Security Policy Framework (PSPF) in each agency at Senior Executive Service (or equivalent) level. Agencies are not required to create a new dedicated position to perform the CISO role. The CISO role was introduced in addition to the other PSPF requirements to provide a more meaningful title for the Security Executive’s responsibilities that relate specifically to information security.

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 security policy, standards, regulations and legislation.

The ITSA

The ITSA is responsible for information technology security management across the agency, and acts as the first point of contact for the CISO or equivalent, and external agencies on any information technology security management issues.

The ITSA is also an Information Technology Security Manager (ITSM) - see the [i]Information Technology Security Managers[/i] section of this chapter. The ITSA is the particular ITSM who has been designated as having these additional agency-wide technology security management responsibilities.

Requirement for an ITSA

The ITSA retains full responsibility for their role as an ITSM in addition to ITSA responsibilities, and has the added responsibility of coordinating other ITSMs to ensure that security measures and efforts are undertaken in a coordinated manner.

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.

ITSMs

ITSMs are executives that coordinate the strategic directions provided by the CISO and the technical efforts of Information Technology Security Officers (ITSOs). The main area of responsibility of an ITSM is the day-to-day management of information security within an agency.

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

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.

Requirement for ITSOs

Appointing a person with responsibility for ensuring the technical security of systems is essential to manage compliance and non-compliance with the controls in this manual. The main responsibility of ITSOs is the implementation and monitoring of technical security measures for systems.

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 security assessments
• 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.

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

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.

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.

The suite of documents outlined in this chapter forms the Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].

Documentation is vital to any information security regime as it supports the accurate and consistent application of policy and procedures within an agency. Documentation also provides increased accountability and a standard against which compliance can be measured.

Documentation that has been created for alternative compliance frameworks but fulfils the purpose specified in this chapter can be used to satisfy the controls in this chapter. Rather, the documentation framework should make this apparent.

Documentation may be presented in a number of formats including dynamic content such as wikis, intranets or other forms of document repositories. More detailed information about each document can be found in the relevant sections of this chapter.

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.

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.

System Security Plan

The System Security Plan (SSP) describes the implementation and operation of controls for a system. It is derived by selecting relevant controls from the ISM with additional controls based on the security risks identified in the associated SRMP. Depending on the documentation framework chosen, some details common to multiple systems could be consolidated in a higher level SSP.

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 detailed knowledge of the system. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.

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.

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.

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.

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.

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.

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.

Publication of documentation

Stakeholders will not be able to make required changes to security measures if they are not made aware of new information security documentation or changes to existing information security documentation.

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.

ISPs are a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].

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

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.

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

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

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

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.

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.

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, [i]Risk Management - Principles and guidelines[/i] while the ISO/IEC has developed the risk management standard ISO/IEC 27005:2011, [i]Information technology - Security techniques - Information security risk management[/i], as part of the ISO/IEC 27000 family of standards.

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

Information about other mandatory documentation can be found in the [i]Documentation Fundamentals[/i] 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.

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.

ASD continually monitors the threat environment and conducts research into the security impact of emerging trends. With each release of this manual, controls can be added, rescinded or modified depending on changes in the threat environment. When performing accreditations against the latest release of this manual, agencies are ensuring that they are taking the most recent threat environment into consideration.

SOPs are a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].

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

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.

ITSM SOPs

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

ITSO SOPs

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

System administrator SOPs

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

User SOPs

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

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.

An IRP is a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].

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

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.

Emergency procedures are a component of an agency’s Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].

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

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.

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.

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 [i]Service Continuity for Online Services[/i] section of the [i]Network Security[/i] chapter.

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.

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. Mechanisms must be implemented to mitigate the risk of agency data being unavailable due to compromise or deletion. Such mechanisms include storing backups offline where practical.

Where backups are stored online, such mechanisms include:
• ensuring that only the account used to perform backups has write permissions to the backups.
• denying all other users write access (and unnecessary read access) to the backups.
• ensuring that this backup account isn’t used for browsing the Internet or reading potentially malicious emails.
• requiring human intervention by the backup administrator (e.g. perhaps via use of a multi-factor authentication token) to modify or delete backups.

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.

Disaster recovery plans

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

Accreditation aim

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.

Accreditation process

The accreditation process comprises three layers:
• accreditation
  • formally recognises and accepts the residual security risk to a system and the information it processes, stores or communicates
• certification
  • formally recognises and accepts, through an independent security assessment, that the security measures for a system have been implemented effectively and determines the residual security risk relating to the operation of the system.
• security assessment
  • reviews the system architecture and assesses the actual implementation and effectiveness of security measures.

Detailed information about the processes and the requirements for conducting accreditations is given in this section. Information about certification and security assessments or audits is given in the [i]Conducting Certifications[/i] and [i]Conducting Security Assessments[/i] sections of this chapter.

Accreditation authorities

For TOP SECRET systems the accreditation authority is ASD.

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

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

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

For commercial providers providing services to organisations the accreditation authority is the head of the supported organisation or their authorised delegate, which is strongly recommended to be the CISO or equivalent.

In all cases the accreditation authority will be at least a senior executive who has an appropriate level of understanding of the security risks they are accepting on behalf of the organisation.

Depending on the circumstances and practices of an organisation, the organisation head can choose to delegate their authority to multiple senior executives who have the authority to accept security risks for specific business functions.

Accreditation 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 identified or implemented for the system. In such cases the accreditation authority may request that further work be undertaken by the system owner before reconsidering the system for accreditation. In the intervening time, the accreditation authority may choose to issue an interim approval to operate with caveats placed on the system’s use.

Accreditation process

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

Accreditation framework

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

Determining authorities

To ensure the accreditation authority can appropriately perform their duties, they will need to hold a senior position within the organisation and have an appropriate level of understanding of the security risks they are accepting for a system.

For multinational and multi-agency systems, determining the certification and accreditation authorities through a formal agreement between the parties ensures that the system owner has appropriate points of contact and does not receive conflicting advice from different authorities.

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.

Requirement for certification

Certification (described in the [i]Conducting Certifications[/i] 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.

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.

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 difference between the security posture of the system at the time of the last accreditation and the current security posture of the system.

Certification aim

Certification is the process by which a certification authority formally recognises and accepts that the security measures for a system have been implemented effectively.

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.

Certification process

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

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.

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.

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, conducted by a member of the Information Security Registered Assessor Program (IRAP) and be awarded certification from ASD. However, even though ASD may award certification to a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.

Certification of cloud services

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

Security assessment aim

The aim of a security assessment is to review the system architecture and assess the actual implementation and effectiveness of security measures.

Security assessment outcome

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

Who can conduct a security assessment

Security assessments for TOP SECRET systems can only be undertaken by ASD or IRAP Assessors.

Security assessments for SECRET and below systems can be undertaken by organisation ITSMs and IRAP Assessors.

Who can assist with a security assessment

A number of agencies and personnel are often consulted during a security assessment.

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

A security assessment can be conducted by an agency’s own assessors. However, the agency may choose to add an extra level of objectivity by engaging the services of an IRAP Assessor to undertake the security assessment.

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

Independence of assessors

As there can be a perceived conflict of interest if the system owner assesses the security of their own system, the assessor should be independent of the system owner and certification authority. This does not preclude an appropriately qualified system owner from assessing the security of a system that they are not responsible for.

Preparing for a security assessment

It is important that the system owner has approved the system architecture and associated information security documentation before a security assessment is undertaken. This assists assessors in understanding the scope of work for the first stage of the assessment.

The process for a security assessment

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.

Outcomes of a security assessment

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.

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.

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.

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 IRAP Assessor. Where possible, it is advisable that system managers do not conduct vulnerability assessments themselves. This ensures that there is no conflict of interest, perceived or otherwise, and that the assessment is undertaken in an objective manner.

An agency may choose to undertake a vulnerability assessment in any of the following circumstances:
• 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; or
• 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.

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.

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
• business process 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 one or more of:
• an upgrade to, or introduction of, ICT equipment
• an upgrade to, or introduction of, software
• major changes to security controls.

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.

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.

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.

Detecting cyber security incidents

Many potential cyber security incidents are noticed by personnel rather than software tools. As such, successful incident detection is based around trained cyber security staff with access to data, complemented with key tools supporting both manual and automated analysis.

One of the core elements of cyber incident detection and subsequent investigation is the availability of key data sources about system usage. Many of these key data sources can be extracted from existing systems without requiring new or specialised capabilities. Efforts should be made to consolidate the various data sources to allow for greater analysis and correlation.

These data sources can support a real-time tool-based detection capability while their retention allows for the manual and automated investigation and identification of historic malicious activity.

The following table describes some of the data sources and tools that organisations may use for detecting and investigating cyber security incidents.

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.

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.

Reporting cyber security incidents to ASD

ASD uses the cyber security incident reports it receives as the basis for identifying and responding to cyber security events across government. Cyber security incident reports are also used by ASD to identify trends and maintain an accurate threat environment picture for government systems. ASD utilises this understanding to assist in the development of new or updated security guidance, capability and techniques to better prevent and respond to changing cyber threats. Agencies are recommended to internally coordinate their reporting of cyber security incidents to ASD e.g. through their ITSA.

Where agencies have outsourced information technology services and functions, they may request that the service provider report cyber security incidents directly to ASD. This could be specified in either a memorandum of understanding or as part of the contract of services. In such cases it is recommended that the agency’s ITSA be made aware of all reporting of cyber security incidents to ASD by the service provider.

Reporting cyber security incidents to ASD via a CSIR scheme ensures that ASD receives the incident information it requires in a timely fashion enabling subsequent incident triage and response. Incidents not reported through the CSIR scheme are at risk of not being responded to in an efficient and effective manner.

Outsourcing and cyber security incidents

When an agency outsources information technology services and functions, it is still responsible for reporting cyber security incidents. It is up to the agency to ensure the service provider informs them of all cyber security incidents.

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.

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.

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

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.

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.

Handling data spills

When a cyber security incident occurs, agencies must assume that a data spill has occurred, until proven otherwise, and follow appropriate procedures. A worst case scenario would entail an intruder gaining access to a range of classified documentation.

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.

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.

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 [i]Event Logging and Auditing[/i] section of the [i]Access Control[/i] chapter.

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.

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

Integrity of evidence

While gathering evidence it is important to maintain the integrity of the information, including metadata about the information, who used it, and how it was used. Even though in most cases an investigation does not directly lead to a police prosecution, it is important that the integrity of evidence such as manual logs, automatic audit trails and intrusion detection tool outputs be protected.

When storing raw audit trails onto media it is important that it is done in accordance with relevant retention requirements as documented in the National Archives of Australia’s (NAA) Administrative Functions Disposal Authority.

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.

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.

Information about securing servers, network devices, ICT equipment and media can be found in various sections of this chapter. Information on encryption requirements can be found in the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.

Facilities

In the context of this manual, a facility is a physical space where government business is performed. For example, a facility can be a building, a floor of a building, or a designated space on the floor of a building.

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

Facilities located outside of Australia

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 people without the appropriate authorisation to access the systems and infrastructure at the facility.

Deployable platforms need to meet physical security certification requirements as per any other system. physical security certification authorities dealing with deployable platforms can have specific requirements that supersede the requirements of this manual and, as such, security personnel should contact their appropriate physical security certification authority to seek guidance.

In the case of deployable platforms, physical security requirements may also include perimeter controls, building standards and manning levels.

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 that information is encrypted to a sufficient level that if it were captured, it would not be cost-effective to decrypt the information.

The PSPF’s [i]Physical Security Management Guidelines - Security Zones and Risk Mitigation Control Measures[/i] 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.

Preventing observation by unauthorised people

Facilities without sufficient perimeter security are often exposed to potential observation through windows. Ensuring information on workstation screens is not visible will assist in reducing this security risk. This can be achieved by using blinds or curtains on the windows.

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 in accordance with the requirements of the [i]Australian Government Physical Security Management Protocol[/i]. In such cases, the additional layer of security described in this manual allows the requirements for physical storage of server and communications equipment provided in the [i]Australian Government Physical Security Management Protocol[/i] to be reduced in line with the physical security of ICT equipment systems and facilities guideline.

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 with the intention of interrupting services.

Physical access to network devices can allow an intruder to reset devices to factory default settings by pressing a physical reset button, connecting a serial interface to a device, or connecting directly to a device to bypass any access controls. Resetting a network device back to factory default settings may disable security settings on the device including authentication and encryption functions as well as resetting administrator accounts and passwords to known defaults. Even if access to a network device is not gained by resetting it, it is highly likely a denial of service event will occur.

Physical access to network devices can be restricted through methods such as physical enclosures that prevent access to console ports and factory reset buttons, mounting devices on ceilings or behind walls, or placing devices in locked rooms or cabinets.

Securing server rooms, communications rooms and security containers

Actions such as personnel leaving server and communication rooms and security containers unlocked, or with keys in the locks, or with security functions disabled, negates physical security measures. Such actions compromise security efforts and must not be permitted.

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.

Additional information relating to ICT equipment and media can be found in the [i]Fax Machines and Multifunction Devices[/i] section of the [i]Communications Systems and Devices[/i] chapter as well as in the [i]Product Security and Media Security[/i] chapters. Information on the encryption of media can be found in the [i]Cryptography[/i] chapter.

Accounting for ICT equipment and media

Securing ICT equipment and media

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

The physical security requirements of the [i]Australian Government Physical Security Management Protocol[/i] 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.

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.

The following sections of this chapter contain information on areas that specifically need to be covered by the training provided.

Information security awareness and training

Tailored education plays a major role in protecting agency systems and information from intrusion or compromise by fostering an effective security culture and sound decision-making practices.

Information security awareness and training programs are designed to help personnel to:
• become familiar with their roles and responsibilities
• understand and support security requirements
• learn how to fulfil their security responsibilities.

Information security awareness and training responsibility

Agencies are responsible for ensuring that an appropriate information security awareness and training program is provided to personnel. Without management support, security personnel might not have sufficient resources to facilitate awareness and training for other personnel.

Personnel will naturally lose awareness or forget training over time. Providing ongoing information security awareness and training helps keep personnel aware of issues and their responsibilities.

Methods that can be used to continually promote awareness include logon banners, system access forms and departmental bulletins or memoranda.

Degree and content of information security awareness and training

The exact degree and content of information security awareness and training depends on the objectives of the agency. Personnel with responsibilities beyond that of a general user will require tailored training to meet their needs.

When providing guidance to personnel it is important to emphasise which activities are not allowed on systems. The minimum list of content given below ensures that personnel are sufficiently exposed to issues that, if they are ignorant of them, could cause a cyber security incident.

System familiarisation training

A TOP SECRET system needs increased awareness by personnel. Ensuring familiarisation with information security policies and procedures, the secure operation of the system and basic information security training, provides them with specific knowledge relating to these types of systems.

Security clearances - Australian and foreign

Where this manual refers to security clearances, the reference applies to Australian security clearances or security clearances from a foreign government which are recognised by Australia under a security of information arrangement.

Documenting authorisations, security clearance and briefing requirements

Ensuring that the requirements for access to a system are documented and agreed upon helps determine if personnel have the appropriate authorisations, security clearances and need-to-know to access the system.

Types of system accounts for which access requirements need to be documented include general users, privileged users, contractors and visitors.

Authorisation and system access

Personnel seeking access to a system need to have a genuine business requirement to access the system as verified by their manager. Once a requirement to access a system is established, giving personnel only the privileges that they need to undertake their duties is imperative. Providing all personnel with privileged access when there is no requirement for privileged access can be a significant threat to a system.

Recording authorisation for personnel to access systems

Retaining records of completed system account request forms signed by each user’s manager will assist with maintaining user accountability. This is required to ensure there is a record of all personnel authorised to access a system, their user identification, who provided the authorisation, when the authorisation was granted and when the access was last reviewed.

System access

A security clearance provides assurance that personnel can be trusted with access to sensitive or classified information that is processed, stored or communicated by a system. The [i]Australian Government Personnel Security Management Protocol[/i] communicates agency requirements for personnel who access Australian Government resources.

System access briefings

Some systems may contain caveated or compartmented information. There may be specific briefings that personnel need before being granted access to such systems.

Temporary access to classified information

Under strict circumstances access to systems may be granted to personnel who lack the appropriate security clearance.

Controlling temporary access

When personnel are granted access to a system under the provisions of temporary access they need to be closely supervised or have their access controlled in such a way that they only have access to information they require to undertake their duties.

Granting emergency access

Emergency access to a system may be granted where there is an immediate and critical need to access information for which personnel do not have the appropriate security clearance.

Accessing systems without necessary security clearances and briefings

Temporary or emergency access to systems processing, storing or communicating caveated or compartmented information is not permitted.

In this section the term online services applies to services using the internet such as social networks, online collaboration tools, web browsing, instant messaging (IM), Internet Relay Chat (IRC), Internet Protocol (IP) telephony, video conferencing, file sharing sites and peer–to–peer applications. Agencies need to be aware, and ensure their personnel are aware, that unless applications using these communications methods are evaluated and approved by ASD they must not be used for communicating sensitive or classified information over the internet.

Additional technical information and controls are in the [i]Software Security[/i] and [i]Email Security[/i] chapters, and the [i]Video Conferencing and Internet Protocol Telephony[/i] section of the [i]Network Security[/i] chapter.

Using online services

Agencies need to determine what constitutes suspicious contact in their own work environment such as being contacted by an unknown source and ensure personnel know how to report these events. Suspicious contact may relate to questions regarding the work duties of personnel or the specifics of projects being undertaken by personnel.

Awareness of web usage policies

There is little value in having online services and usage policies if personnel are not made aware of their existence.

Monitoring online services usage

Monitoring breaches of online services usage policies, for example attempts to access blocked websites such as pornographic and gambling websites, as well as compiling a list of personnel who download or upload unusually large quantities of data, without a legitimate business requirement, will assist agencies in enforcing their online services usage policies.

Posting official information to online services

Personnel need to take special care not to accidentally post sensitive or classified information to public online services, especially in collaboration tools, forums, blogs and social networking sites that are not accredited to handle sensitive or classified information. Even unclassified information that appears to be benign in isolation, such as the Global Positioning System information in a picture, could, along with other information, have a considerable security impact on the government.

To ensure that personal opinions of personnel are not interpreted as official policy, personnel will need to maintain separate professional and personal accounts when using online services, especially when using social networks.

Posting personal information to online services

Personnel need to be aware that any personal information they post to online services such as social networks could be used to develop a detailed profile of their lifestyle and hobbies in order to attempt to build a trust relationship with them or others. This relationship could then be used to attempt to elicit sensitive or classified information from them or to implant malicious software on systems by having them, for example, open emails or visit websites with malicious content.

Encouraging personnel to use the privacy settings on online services to restrict who can view their information and not allow public access will minimise who can view their interactions on websites. The privacy settings of the online service should be regularly reviewed for policy changes to ensure the settings maintain privacy.

Peer-to-peer applications

Personnel using peer–to–peer file sharing applications are often unaware of the extent of files that are being shared from their workstation. In most cases peer–to–peer file sharing applications will scan workstations for common file types and share them automatically for public consumption. Examples of peer–to–peer file sharing applications include Shareaza, eMule and μTorrent.

Some peer–to–peer IP telephony applications, such as skype, use proprietary protocols and make heavy use of encrypted tunnels to bypass firewalls. Because of this their use cannot be regulated or monitored. It is important that agencies implementing an IP telephony solution over the internet choose applications that use protocols that are open to inspection by IDSs.

Sending and receiving files via peer-to-peer applications

When personnel send or receive files via peer–to–peer file sharing, including IM and IRC applications, they bypass security measures put in place to detect and quarantine malicious code. Encouraging personnel to send and receive files via agency established methods such as email will ensure they are appropriately marked and scanned for malicious code.

Applicability of controls in this section

The controls in this section only apply to new cable installations or upgrades. When designing cable management systems, the [i]Cable Labelling[/i] and [i]Registration and Cable Patching[/i] sections of this chapter also apply. Agencies are not required to retrofit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Common implementation scenarios

This section provides common requirements for non-shared government facilities, shared government facilities and shared non-government facilities. Further specific requirements for each scenario can be found in the other sections of this chapter.

Cables

The cable’s protective sheath is not considered to be a conduit. For fibre-optic cables with subunits, the cable’s outer protective sheath is considered to be a conduit.

Unclassified (DLM) system controls

All references to ‘Unclassified (DLM)’ systems in the tables here relate to systems containing unclassified, but sensitive, information not intended for public release—such as Dissemination Limiting Marker (DLM) information. Unclassified and Unclassified (DLM) are not classifications under the [i]Australian Government Security Classification System[/i] as mandated by the Attorney-General’s Department.

Cable standards

All cables must be installed by an endorsed cable installer to the relevant Australian standards to ensure personnel safety and system availability.

Cable colours

The use of defined cable colours provides an easily recognisable cable management system.

Cable colours for foreign systems in Australian facilities

Different cable colours for foreign systems in Australian facilities helps prevent unintended patching of Australian and foreign systems.

Cable colour non-compliance

In certain circumstances it is not possible to use the correct cable colours to match the classification. Where the accreditation authority has approved non-compliance, cables are still required to be associated with their classification. Under these circumstances agencies are to band the cables with the appropriate colour for its classification. The banding of cables is to comply with the inspection points for the cables. The size of the cable bands must be easily visible from the inspection point. For large bundles on cable reticulation systems, band and label the entire bundle. It is important bands are robust and stand the test of time. Examples of appropriate cable bands include stick-on coloured labels, colour heat shrink, coloured ferrules or short lengths of banded conduit.

Cable groupings

Grouping cables provides a method of sharing conduits and cable reticulation systems in the most efficient manner.

Fibre optic cables sharing a common conduit

Fibre optic cables of various cable groups can share a common conduit to reduce installation costs.

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

With fibre optic cables the fibres in the sheath, as shown below, must only carry a single group.

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

If a fibre optic cable contains subunits, as shown below, each subunit must only carry a single group; however, each subunit in the cable can carry a different group.

Terminating cables in cabinets

Having individual or divided cabinets for each classification prevents accidental or deliberate cross patching and makes visual inspection of cables and patching easier.

Connecting cable reticulation systems to cabinets

Strictly controlling the routing from cable management systems to cabinets prevents unauthorised modifications and tampering and provides easy inspection of cables.

Audio secure spaces

Audio secure spaces are designed to prevent audio conversations from being heard outside the walls. Penetrating an audio secure space in an unapproved manner can degrade this. Consultation with ASIO needs to be undertaken before any modifications are made to audio secure spaces. For physical security measures regarding Security Zone requirements, refer to the [i]Australian Government Physical Security Management Protocol[/i].

Wall outlet terminations

Wall outlet boxes are the main method of connecting cable infrastructure to workstations. They allow the management of cables and the type of connectors allocated to various systems.

Wall outlet colours

The colouring of wall outlets makes it easy to identify TOP SECRET infrastructure.

Wall outlet covers

Transparent covers on wall outlets allows for inspection of cables for cross patching and tampering.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables, as outlined in the [i]Cable Management Fundamentals[/i] section of this chapter. The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retrofit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Use of fibre optic cables

Fibre-optic cables do not produce, and are not influenced by, electromagnetic emanations, and therefore offer the highest degree of protection from electromagnetic emanation effects.

Fibre cables are more difficult to tap than copper cables.

Many more fibres can be run per cable diameter than wired cables, reducing cable infrastructure costs.

Fibre cable is the best method to future-proof cable infrastructure, it protects against unforeseen threats and facilitates upgrading secure cables to higher classifications in the future.

Inspecting cables

Regular inspections of cable installations are necessary to detect any illicit tampering or degradation.

Cables sharing a common reticulation system

Laying cables in a neat and controlled manner that allows for inspections reduces the need for individual cable trays for each classification.

Cables in walls

Cables run correctly in walls allows for neater installations while maintaining separation and inspection requirements.

Cabinet separation

Having a definite gap between cabinets allows for ease of inspections for any illicit cables or cross-patching.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables as outlined in the [i]Cable Management Fundamentals[/i] section of this chapter. The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retrofit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Use of fibre-optic cables

Fibre-optic cables do not produce, and are not influenced by, electromagnetic emanations, and therefore offer the highest degree of protection from electromagnetic emanation effects.

Fibre-optic cables are more difficult to tap than copper cables.

Many more fibres can be run per cable diameter than wired cables, reducing cable infrastructure costs.

Fibre-optic cable is the best method to future-proof cable infrastructure, it protects against unforeseen threats and facilitates upgrading secure cables to higher classifications in the future.

Inspecting cables

In a shared government facility it is important that cable systems be inspected for illicit tampering and damage on a regular basis and that they have tighter controls than in a non-shared government facility.

Cables sharing a common reticulation system

In a shared government facility, tighter controls are placed on sharing reticulation systems.

Cables in walls

In a shared government facility, cables run correctly in walls allow for neater installations while maintaining separation and requirements for inspecting cables.

Wall penetrations

Penetrating a wall into a lesser-classified space by cables requires the integrity of the classified space to be maintained. All cables are encased in conduit with no gaps in the wall around the conduit. This prevents any visual access to the secure space. For physical security measures regarding Security Zone requirements refer to the [i]Australian Government Physical Security Management Protocol[/i].

Power reticulation

In a shared government facility with lesser-classified systems, it is important that TOP SECRET systems have control over the power system to prevent denial of service by deliberate or accidental means.

Cabinet separation

Having a definite gap between cabinets allows for ease of inspections for any illicit cables or cross patching.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables as outlined in the [i]Cable Management Fundamentals[/i] section of this chapter. The controls in this section only apply to new cable installations or upgrades where a government agency has significant control over the installation or upgrade in the non-government facility. Agencies are not required to retrofit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Use of fibre optic cables

Due to the higher degree of associated risk, greater consideration should be applied to the use of fibre-optic cables in shared non-government facilities. Fibre-optic cables do not produce, and are not influenced by, electromagnetic emanations, and therefore offer the highest degree of protection from electromagnetic emanation effects.

Fibre-optic cables are more difficult to tap than copper cables.

Many more fibres can be run per cable diameter than wired cables, reducing cable infrastructure costs.

Fibre-optic cable is the best method to future-proof cable infrastructure—it protects against unforeseen threats and facilitates upgrading secure cables to higher classifications in the future.

Inspecting cables

In a shared non-government facility it is imperative that cable systems be inspected for illicit tampering and damage on a regular basis and that they have tighter controls where the threats are closer and unknown.

Cables sharing a common reticulation system

In a shared non-government facility, tighter controls are placed on sharing reticulation systems as the threats to tampering and damage are increased.

Enclosed cable reticulation systems

In a shared non-government facility, TOP SECRET cables are enclosed in a sealed reticulation system to prevent access and enhance cable management.

Covers for enclosed cable reticulation systems

Clear covers on enclosed reticulation systems are a convenient method of maintaining inspection and control requirements. Having clear covers face inwards increases their inspection.

Cables in walls

In a shared non-government facility, cables run correctly in walls allows for neater installations, while maintaining separation and inspection requirements. Controls are more stringent than in a government facility (shared or non-shared).

Cables in party walls

In a shared non-government facility, cables are not allowed in a party wall. A party wall is a wall shared with an unsecured space where there is no control over access. An inner wall can be used to run cables where the space is sufficient for inspection of the cables.

Sealing conduits

In a shared non-government facility, where the threat of access to cables is increased, all conduits are sealed with a visible smear of glue to prevent access to cables.

Sealing reticulation systems

In a shared non-government facility, where the threats of access to cable reticulation systems is increased, Security Construction and Equipment Committee (SCEC) endorsed seals are required to provide evidence of any tampering or illicit access.

Wall penetrations

Penetrating a wall to a lesser-classified space by cables requires the integrity of the classified space be maintained. All cables are encased in conduit with no gaps in the wall around the conduit. This prevents any visual access to the secure space. For physical security measures regarding Security Zone requirements refer to the Australian Government Physical Security Management Protocol.

Power reticulation

In a shared non-government facility, it is important that TOP SECRET systems have control over the power system to prevent denial of service by deliberate or accidental means. The addition of a UPS is required to maintain availability of the TOP SECRET systems.

Cabinet separation

Having a definite gap between cabinets allows for ease of inspections for any illicit cables or cross patching.

Applicability of controls in this section

The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Conduit label specifications

Conduit labels must be a specific size and colour to allow easy identification of secure conduits carrying cables.

Installing conduit labelling

Conduit labelling in public or reception areas could draw unwanted attention to the level of classified processing and lead to a disclosure of capabilities.

Labelling wall outlet boxes

Clear labelling of wall outlet boxes diminishes the possibility of incorrectly attaching ICT equipment of a lesser classification to the wrong outlet.

SOPs

Documenting labelling conventions in SOPs makes cable and fault finding easier.

Labelling cables

Labelling cables with the correct source and destination information minimises the likelihood of cross patching and aids in fault finding and configuration management.

Cable register

Cable registers provide a source of information that assessors can view to verify compliance.

Cable register contents

Cable registers allow installers and assessors to trace cable for inspections, malice or accidental damage. Cable registers track all cable management changes through the life of the system.

Cable inspections

Cable inspections, at predefined periods, are a method of checking the cable management system with the cable register.

Applicability of controls in this section

The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retrofit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the [i]Emanation Security Threat Assessments[/i] section of this chapter.

Terminations to patch panels

Connecting a system to another system of a lesser classification will result in a data spill, possibly resulting in the following issues:
• inadvertent or deliberate access by non-cleared personnel
• the lesser system not meeting the appropriate requirements to secure the classified information from unauthorised access or tampering.

Patch cable and fly lead connectors

Ensuring that cables are equipped with connectors of a different configuration to all other cables prevents inadvertent connection to systems of lower classifications.

Physical separation of patch panels

Appropriate physical separation between a TOP SECRET system and a system of a lesser classification:
• reduces or eliminates the chances of cross patching between the systems
• reduces or eliminates the possibility of unauthorised personnel gaining access to TOP SECRET system elements.

Fly lead installation

Keeping the lengths of fly leads to a minimum prevents clutter around desks, prevents damage to fibre optic cables and reduces the chance of cross patching and tampering. If lengths become excessive, cable needs to be treated as infrastructure and run in conduit or fixed infrastructure such as desk partitioning.

This section is only applicable to:
• agencies located outside of Australia
• facilities in Australia that have transmitters
• facilities that are shared with non-Australian government entities
• mobile platforms and deployable assets that process sensitive or classified information.

Emanation security threat assessments in Australia

Obtaining the current threat advice from ASD on potential adversaries and applying the appropriate counter-measures is vital in protecting the confidentiality of sensitive and classified systems from emanation security threats.

Implementing required counter-measures against emanation security threats can prevent compromise. Having a good cable infrastructure and installation methodology will provide a strong backbone that will not need updating if the threat increases. Infrastructure costs are expensive and time consuming to retro fit.

Emanation security threat assessments outside Australia

Fixed sites outside Australia and deployed military platforms are more vulnerable to emanation security threats and require a current threat assessment and counter-measure implementation. Failing to implement recommended counter-measures and SOPs to reduce threats could result in the platform emanating compromising signals, which if intercepted and analysed, could lead to platform compromise with serious consequences.

Early identification of emanation security issues

It is important to identify the need for emanation security controls for a system early in the project life cycle as this can reduce costs for the project. Costs are much greater if changes have to be made once the system has been designed and deployed.

ICT equipment in highly sensitive areas

While ICT equipment in a TOP SECRET area in Australia may not need certification to TEMPEST standards, the equipment still needs to meet applicable industry and government standards.

Exemptions for the use of infrared devices

An infrared device can be used in a secured space provided it does not communicate sensitive or classified information.

Exemptions for the use of RF devices

The following devices, at the discretion of the accreditation authority, can be exempted from the controls associated with RF transmitters:
• pagers that can only receive messages
• garage door openers
• car lock/alarm keypads
• medical and exercise equipment that uses RF to communicate between sub-components
• communications radios that are secured by approved cryptography.

Pointing devices

Since wireless RF pointing devices can pose an emanation security risk, they are not to be used in TOP SECRET areas unless in an RF screened building.

Infrared keyboards

When using infrared keyboards with CONFIDENTIAL or SECRET systems, drawn curtains that block infrared transmissions are an acceptable method of protection.

When using infrared keyboards with a TOP SECRET system, windows with curtains that can be opened are not acceptable as a method of permanently blocking infrared transmissions.

Bluetooth and wireless keyboards

Bluetooth has a number of known weaknesses in the protocol that potentially enable exploitation. While there have been a number of revisions to the protocol that have made incremental improvements to security, there have been trade-offs that have limited the improvements. These include maintaining backward compatibility to earlier versions of the protocol and limits to the capabilities of some devices.

Though newer revisions of the Bluetooth protocol have addressed many of the historical security concerns, it is still very important that agencies consider the security risks posed by enabling Bluetooth technology.

As part of an agency's security risk assessment, things to consider are:
• using the strongest security modes available
• educating users of the known weaknesses of the technology and their responsibilities in complying with policy in the absence of strong technical controls
• man-in-the-middle pairing
• maintaining an inventory of all Bluetooth devices addresses (BD_ADDRs).

Bluetooth version 2.1 and subsequent versions introduced secure simple pairing and extended inquiry response. Secure simple pairing improves the pairing experience for Bluetooth devices, while increasing the strength as it uses a form of public key cryptography. Extended inquiry response provides more information during the inquiry procedure to allow better filtering of devices before connecting.

The device class can be used to restrict the range that the Bluetooth communications will operate over. Typically Bluetooth class 1 devices can communicate up to 100 metres, class 2 devices can communicate up to 10 metres and class 3 devices can communicate up to 5 metres.

RF devices in secured spaces

RF devices with voice capability pose an audio security threat to secured spaces as they are capable of picking up and transmitting sensitive or classified background conversations. Furthermore, many RF devices can connect to ICT equipment and act as unauthorised data storage devices.

Detecting RF devices in secured spaces

As RF devices are prohibited in highly classified environments, agencies are encouraged to deploy security measures that detect and respond to the unauthorised use of such devices.

RF controls

Minimising the output power of wireless devices and using RF shielding on facilities will assist in limiting the wireless communications to areas under the control of the agency.

Further information on MFDs communicating via network gateways can be found in the [i]Cross Domain Security[/i] chapter.

Fax machine and MFD usage policy

As fax machines and MFDs are capable of communicating sensitive or classified information, and are a potential source of cyber security incidents, it is important that agencies develop a policy governing their use.

Sending fax messages

Once a fax machine or MFD has been connected to cryptographic equipment and used to send a sensitive or classified fax message, it can no longer be trusted when connected directly to unsecured telecommunications infrastructure or the PSTN. For example, if a fax machine fails to send a sensitive or classified fax message the device will continue attempting to send the fax message even if it has been disconnected from the cryptographic device and connected directly to the PSTN. In such cases, the fax machine could then send the sensitive or classified fax message in the clear, causing a data spill.

Sending fax messages using High Assurance products

Using the correct procedure for sending a classified fax message will ensure that it is sent securely to the correct recipient.

Using the correct memory erase procedure will prevent a classified fax message being sent in the clear.

Implementing the correct procedure for establishing a secure call will prevent sending a classified fax message in the clear.

Witnessing the receipt of a fax message and powering down the receiving machine or clearing the memory after transmission will prevent someone without a need-to-know from accessing the fax message.

Ensuring fax machines and MFDs are not connected to unsecured phone lines will prevent accidentally sending classified messages stored in memory.

Receiving fax messages

While the communications path between fax machines and MFDs may be appropriately protected, personnel need to be aware who has the need to know the information that is being communicated. It is therefore important that fax messages are collected from the receiving fax machine or MFD as soon as possible. Furthermore, if an expected fax message is not received it may indicate that there was a problem with the original transmission or the fax message has been taken by an unauthorised person.

Connecting MFDs to telephone networks

When an MFD is connected to a computer network and a digital telephone network the device can act as a bridge between the two. The telephone network therefore needs to be accredited to the same level as the computer network.

Connecting MFDs to computer networks

As network connected MFDs are considered to be devices that reside on a computer network, they need to have the same security measures as other devices on the computer network.

Copying documents on MFDs

As networked MFDs are capable of sending scanned or copied documents across a connected network, personnel need to be aware that if they scan or copy documents at a level higher than that of the network the device is connected to, it will cause a data spill.

Observing fax machine and MFD use

Placing fax machines and MFDs in public areas can help reduce the likelihood of any suspicious use going unnoticed.

Information regarding mobile phones is covered in the [i]Mobile Devices[/i] section of the [i]Working Off-Site[/i] chapter, while information regarding IP telephony, including Voice over Internet Protocol (VoIP), and encryption of data in transit is covered in the [i]Video Conferencing and Internet Protocol Telephony[/i] section of the [i]Network Security[/i] chapter and the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.

Telephones and telephone systems usage policy

All non-secure telephone networks are subject to interception. Accidentally or maliciously revealing sensitive or classified information over a public telephone network can lead to interception.

Personnel awareness

As there is a high risk of unintended disclosure of sensitive or classified information when using telephones, it is important that personnel are made aware of what they can discuss on particular telephone systems, as well as the audio security risk associated with the use of telephones.

Visual indication

When single telephone systems are approved to hold conversations at different levels, alerting the user to the sensitive or classified information that can be discussed will assist in reducing the risk of unintended disclosure of sensitive or classified information.

Use of telephone systems

When sensitive or classified conversations are to be held using telephone systems, the conversation needs to be appropriately protected through the use of encryption measures.

Cordless telephones

Cordless telephones have minimal transmission security and are susceptible to interception. Using cordless telephones for sensitive or classified communications can result in disclosure of information to an unauthorised party through interception.

Cordless telephones with secure telephony devices

As the data between cordless handsets and base stations is not appropriately secured, using cordless telephones for sensitive or classified communications can result in unauthorised disclosure of the information, even if the device is connected to a secure telephony device.

Speakerphones

As speakerphones are designed to pick up and transmit conversations in the vicinity of the device, using speakerphones in TOP SECRET areas presents a high audio security risk. However, if the agency is able to reduce the audio security risk through the use of an audio secure room that is secured during conversations, then they may be used. For physical security measures regarding Security Zone requirements refer to the [i]Australian Government Physical Security Management Protocol[/i].

Off-hook audio protection

Providing off-hook security minimises the chance of sensitive and classified conversations being accidentally coupled into handsets and speakerphones. Limiting the time an active microphone is open limits this threat.

Simply providing an off-hook audio protection feature is not sufficient to meet the requirement for its use. To ensure that the protection feature is used appropriately, personnel need to be made aware of the protection feature and trained in its proper use.

The core requirements of the PSPF controls safeguarding information from cyber threats require agencies to mitigate targeted cyber incidents and emerging cyber threats. This includes implementing the Strategies to Mitigate Cyber Security Incidents as outlined in this manual.

To satisfy the mandatory mitigation requirements of the PSPF, agencies are required to implement the following strategies:
• implement application whitelisting
• patch applications
• patch operating systems
• restrict administrative privileges.

These strategies, formally referred to as the Top 4 are effective in mitigating at least 85% of techniques used in targeted cyber intrusions that ASD can detect. The eight mitigation strategies with an ‘essential’ rating, which incorporates the Top 4, are so effective in mitigating targeted cyber intrusions and ransomware ASD considers them to be the cyber security baseline for all agencies. The implementation of the remaining strategies is also strongly recommended; however, agencies can prioritise these depending on business requirements and the risk profile of each system.

Compliance reporting against PSPF mandatory requirements must be provided to relevant Ministers annually in accordance with PSPF requirements.

Applicability and implementation priority

The applicability of ASD’s Top 4 Strategies should be determined by the specific risks agencies are trying to mitigate. The Strategies are directed at the most common cyber threats being faced by Australian government agencies: targeted cyber intrusions from the internet to the workstation, ransomware and to a lesser extent malicious insiders and business email compromise. Guidance is also provided to mitigate threats to industrial control systems. These intrusions purposefully target specific government agencies, seeking to gain access to sensitive information through content-based intrusions (that is email and web pages). These intrusions easily bypass perimeter defences, because they look like legitimate business traffic and therefore gain access to the workstation. From the workstation they spread, gaining access to other computing and network resources and the data they contain.

The Strategies are designed with this scenario in mind. They form part of a layered defence, primarily designed to protect the workstation, and by extension the corporate network.

Priority for implementing the Top 4 Strategies should therefore be placed on Australian government systems that are able to receive emails or browse web content originating from a different security domain, particularly from the internet.

Other systems will benefit from implementing the Top 4, the Essential Eight and the remaining Strategies. However, there may be circumstances where the risks or business impact of implementing particular Strategies outweighs the benefits, and other security controls may have greater relevance. In such circumstances, agencies should apply appropriate risk management practices as outlined in this manual.

Further information on risk management can be found in the [i]Information Security Risk Management[/i] chapter.

The Top 4 mandatory controls

Existing ISM controls satisfy the mandatory requirement to implement ASD's Top 4 Strategies.

[i]Note: Some controls are duplicated between 'patch applications' and 'patch operating systems' as they satisfy both strategies.[/i]

Implementation of the Top 4 controls is mandatory for all systems able to receive emails or browse web content originating in a different security domain. Under the PSPF, noncompliance with any mandatory requirements must be reported to an agency’s relevant portfolio Minister, and also to ASD for matters relating to the ISM.

However, some technologies and systems may lack functionality or available products to feasibly implement the mandatory controls specified in this manual. For example, implementing the Top 4 on mobile devices can be achieved using platform-specific controls that meet the general principles behind the Top 4 (described in ASD publication [i]Risk Management of Enterprise Mobility including Bring Your Own Device (BYOD)[/i]). In circumstances where the Top 4 mandatory controls cannot be implemented, and product-specific guidance does not exist, agencies should apply appropriate risk management practices as outlined in this manual.

Other applicable controls

The following controls relate to the Top 4 Strategies. Although not considered mandatory under the PSPF, these controls are best practice for a Top 4 implementation and complement the mandatory controls listed above. Agencies may take a risk-based approach to these controls, as is the norm for the ISM. See each control for compliance and authority information.

Compliance reporting

Under the PSPF, non-compliance with any mandatory requirements must be reported to an agency’s relevant portfolio Minister, and also to ASD for matters relating to the ISM. Compliance reporting to the relevant portfolio Minister is not designed to be an extra step in the system accreditation process, nor is it assumed compliance must be gained before authority to operate can be granted to a system.

ASD, along with the Attorney-General’s Department, is responsible for assessing and reporting on Australian government agency implementation of the Top 4 controls and their overarching strategies. ASD intends to conduct an annual survey to collate more detailed information from agencies to help meet new reporting requirements.

Agencies need assurance that products perform as claimed by the vendor and provide the security necessary to mitigate contemporary threats. This assurance can be achieved through a formal, and impartial, evaluation of the product by an independent entity. ASD manages and operates a number of evaluation programs and the results are listed on the Evaluated Products List (EPL).

ASD evaluation programs

ASD performs security evaluations through several programs:
• The Common Criteria scheme through the Australasian Information Security Evaluation Program (AISEP) using licensed commercial facilities to perform evaluation of products.
• Cryptographic product evaluations called an ASD Cryptographic Evaluation (ACE) for products which contain cryptographic functions.
• The High Assurance evaluation program for assessment of products protecting highly classified information.

These programs have been established to manage the different characteristics of families of security enforcing technologies.

The Evaluated Products List

ASD maintains a list of products that have been formally and independently evaluated by one of ASD's Evaluation Programs on the EPL, which can be found via the ASD website at [link]http://www.asd.gov.au/infosec/epl[/link].

Through the AISEP, ASD recognises evaluations from foreign Common Criteria schemes with equal standing. These products are listed on the Common Criteria portal found at [link]http://www.commoncriteriaportal.org[/link].

The product listing on the EPL will also include important evaluation documentation that will provide specific requirements and guidance on the secure use of the product.

Protection Profiles

A Protection Profile is a technology specific document that mandates the security function requirements that must be included in a Common Criteria evaluation to meet a range of predefined threats. A Protection Profile defines the assurance activities to be undertaken to assess the security functionality of a particular technology type.

Protection Profiles can be published by either a recognized Common Criteria Recognition Arrangement (CCRA) Scheme or by the CCRA body itself. Protection Profiles published by the CCRA body are referred to as collaborative Protection Profiles.

ASD mutually recognises Common Criteria evaluations against all Protection Profiles listed on the Common Criteria Portal.

ASD also endorses select Protection Profiles to evaluate products against within the AISEP. The AISEP will only accept products for evaluation that comply with an ASD endorsed Protection Profile. Where a Protection Profile does not exist, an EAL based evaluation capped at EAL2+ represents the best balance between completion time and meaningful security assurance gains.

ASD approved Protection Profiles are published on the ASD web site.

Product selection

Agencies can determine that an evaluated product from the EPL or the Common Criteria portal is suitable by reviewing its evaluation documentation. This documentation includes the Protection Profile or Security Target, Certification Report and Consumer Guide. In particular, agencies need to determine if the scope or target of evaluation (including security functionality and the operational environment) is suitable for their needs.

When selecting a product with security functionality, whether it has or has not been evaluated, it is imperative that agencies implement best practice security measures. New vulnerabilities are regularly discovered in products. For this reason, even evaluated products from the EPL will need to have a program of continuous security management.

For Protection Profile evaluated products, the scope of the evaluation has been predefined to meet minimum security requirements for the given technology area.

Products that are in evaluation will not yet have published evaluation documentation. For a Common Criteria evaluation, a draft Security Target can be obtained from ASD for products that are in evaluation through the AISEP. For products that are in evaluation through a foreign scheme, the product vendor can be contacted directly for further information.

Product selection preference order

A Common Criteria evaluation is traditionally conducted at a specified EAL. However, Protection Profile evaluations exist outside of this scale.

While products evaluated against a Protection Profile will fulfil the Common Criteria EAL requirements, the EAL number will not be published. This is intended to facilitate the transition from EAL numbering to Protection Profiles.

If agencies select a product that has not completed an evaluation, documenting this decision, assessing the security risks and accepting those risks ensures the decision is appropriate for an agency’s business requirements and risk profile.

Product specific requirements and evaluation documentation

As products move towards greater convergence and inter-connectivity, more require third party hardware or software to operate, which may introduce new vulnerabilities, which are outside evaluation scope. Documentation associated with each evaluation can assist agencies in determining exactly what the evaluation covered and any recommendations for the product’s secure use.

Evaluation documentation, provided on the EPL, gives specific guidance on evaluated product use. Documentation may also contain specific requirements for the evaluated product, which take precedence over those in this manual.

Product-specific requirements may also be produced for High Assurance products.

Technology convergence

The integration of a number of discrete technologies into one product, such as mobile devices that integrate voice and data services is referred to as ‘convergence’. Converged solutions can include the advantages of each technology, but can also present the vulnerabilities of each discrete technology at the same time. Furthermore, some vulnerabilities may be unique to converged products, due to the combination of technologies present in the product and their interaction with each other. When products have converged elements, the areas of this manual relevant to each of the discrete elements are applicable.

Delivery of products

It is important that agencies ensure that the product that is intended for use is the actual product that is received. For evaluated products, if the product received differs from the evaluated version, then the assurance gained from any evaluation may not necessarily apply. For unevaluated products that do not have evaluated delivery procedures, it is recommended agencies assess whether the vendor’s delivery procedures are sufficient to maintain the integrity of the product.

Other factors to consider when assessing delivery procedures include:
• the intended environment of the product
• the types of intrusions that the product will defend against
• the resources of any potential intruders
• the likelihood of an intrusion
• the importance of maintaining confidentiality of the product purchase
• the importance of ensuring adherence to delivery time frames.

Delivery procedures can vary greatly from product to product. For most products the standard commercial practice for packaging and delivery could be sufficient for agencies’ requirements. Examples of other secure delivery procedures can include tamper-evident seals, cryptographic checksums and signatures, and secure transportation.

Agencies will also need to confirm the integrity of the software that has been delivered before deploying it on an operational system to ensure that no unintended software is installed at the same time. Software delivered on physical media, and software delivered over the Internet, could contain malicious code or malicious content that is installed along with the legitimate software.

Leasing arrangements

Agencies should consider security and policy requirements when entering into a leasing agreement for products in order to avoid potential cyber security incidents during maintenance, repairs or disposal processes.

Ongoing maintenance of assurance

Developers that have demonstrated a commitment to continuous evaluation of product versions are more likely to ensure that security updates and changes are independently assessed.

A developer’s commitment to continuity of assurance can be gauged through the number of evaluations undertaken and whether assurance maintenance has been performed on previous evaluations.

Evaluated configuration

An evaluated product is considered to be operating in its evaluated configuration if:
• functionality that it uses was in the scope or target of evaluation and it is implemented in the specified manner
• only product updates that have been assessed through a formal assurance continuity process have been applied
• the environment complies with assumptions or organisational security policies stated in the product's Security Target or similar document.

Unevaluated configuration

An evaluated product is considered to be operating in an unevaluated configuration when it does not meet the requirements of the evaluated configuration and guidance provided from the certification report.

Patching evaluated products

Agencies need to consider that evaluated products may have had patches applied since the time they were evaluated. In most cases, the latest patched product version is more secure than the older evaluated product version. While the application of security patches will normally not place a product in an unevaluated configuration, some product vendors incorporate new functionality with security patches, which has not been evaluated. In such cases, agencies will need to use their judgement to determine whether the product remains in an evaluated configuration or whether the extent of new functionality incorporated in the product means it no longer remains in an evaluated configuration.

Installation and configuration of evaluated products

Evaluation of products provides assurance that the product will work as expected in a clearly defined configuration. The scope or target of evaluation specifies the security functionality that can be used and how the product is configured and operated.

Using an evaluated product in a manner for which it was not intended could result in the introduction of new vulnerabilities that were not considered as part of the evaluation.

For products evaluated under the Common Criteria scheme, information is available from the product vendor regarding the product’s installation, administration and use. Additional information is available in the Security Target and Certification Report. Configuration guidance for High Assurance products can be obtained from ASD.

Use of evaluated products in unevaluated configurations

When using a product in a manner for which it was not intended, a security risk assessment must be conducted upon the unevaluated configuration. The further a product deviates from its evaluated configuration, the more it diminishes the original assurance gained from the evaluation.

Given the potential threat vectors and the value of the information being protected, High Assurance products must be configured in accordance with ASD’s guidance.

Non-essential labels

Non-essential labels are labels other than protective marking and asset labels.

Classifying ICT equipment

When media is used in ICT equipment there is no guarantee that the equipment has not automatically accessed information from the media and stored it locally without the knowledge of the user. The ICT equipment therefore needs to be afforded the same degree of protection as that of the associated media.

Labelling ICT equipment

The purpose of applying protective markings to all ICT equipment in an area is to reduce the likelihood that a user will accidentally input sensitive or classified information into another system residing in the same area that is not accredited to handle that information.

Applying protective markings to assets helps determine the appropriate sanitisation, disposal or destruction requirements of the ICT equipment based on its sensitivity or classification.

Labelling High Assurance products

High Assurance products often have tamper-evident seals placed on their external surfaces. To assist users in noticing changes to the seals, and to prevent functionality being degraded, agencies must only place seals on equipment when approved by ASD to do so.

Information relating to the sanitisation of ICT equipment and media can be found in the [i]Product Sanitisation and Disposal[/i] section of this chapter and the [i]Media Sanitisation[/i] section of the [i]Media Security[/i] chapter.

Maintenance and repairs

Making unauthorised repairs to products and ICT equipment could impact the integrity of the product or equipment.

Using cleared technicians on-site is considered the most appropriate approach to maintaining and repairing ICT equipment. This ensures that if sensitive or classified information is disclosed during the course of maintenance or repairs, the technicians are aware of the protection requirements for the information.

Maintenance and repairs by an uncleared technician

Agencies choosing to use uncleared technicians to maintain or repair ICT equipment need to be aware of the requirement for cleared personnel to escort the uncleared technicians during maintenance or repair activities.

Off-site maintenance and repairs

Agencies choosing to have ICT equipment maintained or repaired off-site need to be aware of requirements for the company’s off-site facilities to be approved to process and store the products at an appropriate level as specified by the Australian Government Physical Security Management Protocol.

Agencies choosing to have ICT equipment maintained or repaired off-site can sanitise and reclassify or declassify the equipment prior to transport and subsequent maintenance or repair activities to lower the physical transfer, processing and storage requirements specified by the [i]Australian Government Information Security Management Protocol[/i] and [i]Australian Government Physical Security Management Protocol[/i].

Maintenance and repair of ICT equipment from secured spaces

When ICT equipment resides in an area that also contains ICT equipment of a higher classification, a technician could modify the lower classified ICT equipment in an attempt to compromise co-located ICT equipment of a higher classification.

Additional information on the sanitisation, destruction and disposal of media can be found in the Media Security chapter.

Sanitisation removes data from storage media, so that there is complete confidence the data will not be retrieved and reconstructed.

With the convergence of technology, sanitisation requirements are becoming increasingly complex. For example, some televisions and even electronic whiteboards now contain non volatile media.

When sanitising and disposing of ICT equipment, it is the storage media component of the equipment that must be sanitised.

Disposal of ICT equipment can also include recycling, reusing or donating ICT equipment.

• electrostatic memory devices, such as laser printer cartridges used in Multifunction Device (MFD) and Multifunction Printers (MFP)
• non-volatile magnetic memory, such as hard disks and solid state drives
• non-volatile semiconductor memory, such as flash cards
• volatile memory, such as RAM sticks.

Disposal of ICT equipment

When disposing of ICT equipment, agencies need to sanitise any media in the equipment that is capable of storing sensitive or classified information, remove the media from the equipment and dispose of it separately or destroy the equipment in its entirety. Removing labels and markings indicating the classification, codewords, caveats and owner details will ensure the sanitised unit does not display indications of its prior use.

Once the media in ICT equipment has been sanitised or removed, the equipment can be considered sanitised. Following subsequent declassification approval from the owner of the information previously processed by the ICT equipment, it can be disposed of into the public domain or disposed of through unclassified material waste management services.

ASD provides specific advice on how to securely dispose of High Assurance products and TEMPEST-rated ICT equipment. There are a number of security risks that can arise due to improper disposal, including providing an intruder with an opportunity to gain insight into government capabilities.

ICT equipment located overseas that has processed or stored Australian Eyes Only (AUSTEO) and Australian Government Access Only (AGAO) material has more severe consequences for Australian interests if not sanitised and disposed of appropriately. Taking appropriate steps will assist in providing complete assurance that caveated information on ICT equipment is not recoverable.

For sanitisation and disposal of any memory devices present in products, see the [i]Media Security[/i] chapter.

Sanitising printers and MFDs

When sanitising and disposing of the entire printer or MFD, extra steps must be taken to ensure no residual sensitive or classified information is left on the unit. The risk posed by a hard drive or SSD containing hundreds of print jobs is higher than that of a latent image in the printing system. Hard drives and SSD’s should be sanitised as specified in the Media Sanitisation section of the Media Security chapter. The printer cartridge or MFD print drum should be sanitised as described below, with the additional following controls.

For sanitisation and disposal of any memory devices present in the printer or MFD, see the Media Security chapter.

Printing random text with no blank areas on each colour printer cartridge or MFD print drum ensures that no residual information exists within the print path. ASD is able to, upon request; to provide a suitable sanitisation file to use.

Transfer rollers and platens can become imprinted with text and images over time, which could allow an intruder to retrieve information after the unit has been decommissioned from use. (In the case of a flatbed scanner, photocopier or MFD, the glass where a document is placed is the platen.) Similarly, paper jammed in the paper path provides a similar risk of retrieval of information after disposal.

Printers and photocopiers can then be considered sanitised, and may be disposed of through unclassified material waste management services.

Destroying printer cartridges and MFD print drums

When printer cartridges and MFD print drums cannot be sanitised due to a hardware failure, or when they are empty, there is no other option available but to destroy them. Printer ribbons cannot be sanitised and must be destroyed.

Sanitising televisions and computer monitors

All types of televisions and computer monitors are capable of retaining information on the screen if appropriate mitigation measures are not taken during the lifetime of the screen. Cathode ray tube (CRT) monitors and plasma screens can be affected by burn-in, while liquid Crystal display (LCD) screens can be affected by image persistence.

For sanitisation and disposal of any memory devices present in televisions and monitors, see the [i]Media Security[/i] chapter.

If burn-in or image persistence is removed through these measures, televisions and computer monitors can then be considered sanitised, and may be disposed of through unclassified waste management services.

If burn-in or persistence is not removed through these measures, televisions and computer monitors cannot be sanitised and must be destroyed.

If the television or computer monitor cannot be powered on (e.g. due to a faulty power supply) the unit cannot be sanitised and must be destroyed. Additionally, if the screen retains a compromising burnt-in image, the unit must be destroyed.

Sanitising network devices

Routers, switches, network interface cards and firewalls contain memory that is used in the operation of the network device. This memory can often retain sensitive network configuration information such as passwords, encryption keys and certificates. The correct method to sanitise the network device will depend on the configuration of the device and the type of memory within the device. Agencies should consult ASD device-specific advice or vendor sanitisation guidance to determine the most appropriate method to remove the information from the device’s memory. For further guidance on sanitisation of different types of memory, see the [i]Media Sanitisation[/i] section of the [i]Media Security[/i] chapter.

Sanitising fax machines

Fax machines store information such as phone number directories and stored pages ready for transmission. Sanitising fax machines ensures no residual information exists on the unit.

For sanitisation of non-volatile media, see the Media Security chapter.

Information relating to classifying and labelling ICT equipment can be found in the [i]Product Classifying and Labelling[/i] section of the [i]Product Security[/i] chapter. Information on accounting for ICT media can be found in the [i]ICT Equipment and Media section[/i] of the [i]Physical Security[/i] chapter.

Removable media policy

Establishing an agency removable media policy will allow sound oversight and accountability of agency information transported or transferred between systems on removable media.

A well-enforced media policy can decrease the likelihood and consequence of accidental data spills and information theft or loss.

This policy could form part of broader risk management or policy documents of the agency.

Reclassification and declassification procedures

When reclassifying or declassifying media, the process is based on an assessment of relevant issues, including:
• the consequences of damage from unauthorised disclosure or misuse
• the effectiveness of any sanitisation or destruction procedure used
• the intended destination of the media.

Classifying media storing information

Media that is not correctly classified could be stored, identified and handled inappropriately or accessed by a person who does not have the appropriate security clearance.

Classifying media connected to systems

There is no guarantee that sensitive or classified information has not been copied to media while connected to a system unless either read-only devices or read-only media are used.

Reclassifying media

The media will always need to be protected according to the sensitivity or classification of the information it stores. If the sensitivity or classification of the information on the media changes, then so will the protection afforded to the media.

The following diagram shows an overview of the mandated reclassification process.

Labelling media

Labelling helps personnel to identify the sensitivity or classification of media and ensure that they apply appropriate security measures when handling or using it.

Labelling sanitised media

It is not possible to apply the sanitisation and reclassification process to non-volatile media in a cascaded manner. Therefore, SECRET media that has been sanitised and reclassified to a CONFIDENTIAL level must be labelled as to avoid inadvertently being reclassified to a lower classification.

Further information on using media to transfer data between systems can be found in the [i]Data Transfers and Content Filtering[/i] chapter. More information on reducing storage and physical transfer requirements can be found in the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.

Using media with systems

To prevent data spills agencies need to prevent sensitive or classified media from being connected to, or used with, systems not accredited to process, store or communicate the information on the media.

Storage of media

The requirements for the storage and physical transfer of sensitive or classified media are specified in the [i]Australian Government Physical Security Management Protocol[/i] and [i]Australian Government Information Security Management Protocol[/i] of the [i]Australian Government Protective Security Policy Framework[/i].

Connecting media to systems

Some operating systems provide the functionality to automatically execute certain types of programs that reside on optical media and flash drives. While this functionality was designed with a legitimate purpose in mind—such as automatically loading a graphical user interface for the user to browse the contents of the media, or to install software residing on the media—it can also be used for malicious purposes.

An intruder can create a file on media that the operating system believes it should automatically execute. When the operating system executes the file, it can have the same effect as when a user explicitly executes malicious code. However, in this case the user is taken out of the equation, as the operating system executes the file without explicitly asking the user for permission.

Some operating systems will cache information on media to improve performance. Using media with a system could therefore cause data to be read from the media without user intervention.

Device access control and data loss prevention software allows greater control over media that can be connected to a system and the manner in which it can be used. This assists in preventing unauthorised media being connected to a system and, if desired, preventing information from being written to it.

Media can also be prevented from connecting to a system by physical means including, using wafer seals or applying epoxy to the connection ports. If physical means are used to prevent media connecting to a system, then procedures covering detection and reporting processes are needed in order to respond to attempts to bypass these controls.

External interface connections that allow Direct Memory Access

Known vulnerabilities have been demonstrated where adversaries can connect media to a locked workstation via a communications port that allows direct Memory access (DMA) and subsequently gain access to encryption keys in memory. Furthermore, with DMA an intruder can read or write any content to memory that they desire. The best defence against this vulnerability is to disable access to communication ports using either software controls or physically preventing access to the communication ports so that media cannot be connected. Communication ports that can connect media that use DMA are IEEE 1394 (FireWire), ExpressCard and Thunderbolt.

Transferring media

As media are often transferred through areas not certified and accredited to process the sensitive or classified information on the media, protection mechanisms need to be put in place to protect that information. Applying encryption to media may reduce the requirements for storage and physical transfer as outlined in the [i]Australian Government Physical Security Management Protocol[/i] and [i]Australian Government Information Security Management Protocol[/i] of the [i]Australian Government Protective Security Policy Framework[/i]. Any reduction in requirements needs to be based on the original sensitivity or classification of information residing on the media and the level of assurance in the cryptographic product being used to encrypt the media.

Further information on reducing storage and physical transfer requirements can be found in the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.

Using media for data transfers

Agencies transferring data between systems of different security domains, sensitivities or classifications are strongly encouraged to use write-once optical media. This will ensure that information from one of the systems cannot be accidently transferred onto the media then onto another system when the media is reused for the next transfer.

Media in secured areas

Ensuring certain types of media - including Universal Serial Bus (USB), FireWire, Thunderbolt and eSATA capable media - are explicitly approved in a TOP SECRET environment to provide an additional level of user awareness. Additionally, using device access control software on workstations provides a technical control to enforce the policy in case users are unaware of, or choose to ignore, security requirements for media.

Additional information relating to sanitising ICT equipment can be found in the [i]Product Sanitisation and Disposal[/i] section of the [i]Product Security[/i] chapter.

Sanitising media

Sanitisation is the process of removing information from media. It does not automatically change the sensitivity or classification of the media, nor does it involve the destruction of media.

Product selection

Agencies are permitted to use non-evaluated products to sanitise media. However, the product still needs to conform to the requirements for sanitising media as outlined in this section.

Media in Devices

Modern devices will often contain modules that are quite small and may not be immediately recognisable as memory devices. Examples of these devices include M.2 or mSATA. When sanitising M.2 or mSATA devices, the sanitisation and post-sanitisation requirements for flash memory devices apply. If a module contains persistent storage, it is likely that the sanitisation and post-sanitisation requirements for flash memory will be applicable.

Hybrid hard drives

When sanitising hybrid hard drives, the sanitisation and post sanitisation requirements for flash memory devices apply.

Solid state drives

When sanitising solid state drives, the sanitisation and post sanitisation requirements for flash memory devices apply.

Media that cannot be sanitised

When attempts to sanitise media are unsuccessful, the only way to provide complete assurance the data is erased is to destroy the media. Additionally, some types of media cannot be sanitised and therefore must be destroyed. Refer to the [i]Media Destruction[/i] section of this chapter for information on media that cannot be sanitised.

Sanitisation procedures

Sanitising media prior to reuse in a different environment ensures that information is not inadvertently accessed by unauthorised personnel or protected by insufficient security measures.

Using approved sanitisation methods provides a high level of assurance that no remnant data is left on the media.

The procedures used in this manual are designed not only to prevent common intrusions that are currently feasible, but also to protect from those that could emerge in the future.

When sanitising media, it is necessary to read back the contents of the media to verify that the overwrite process was completed successfully.

Volatile media sanitisation

When sanitising volatile media, the specified time to wait following removal of power is based on applying a safety factor to times recommended in research on recovering the contents of volatile media.

If read back cannot be achieved or classified information persists on the media, destroying the media as prescribed in the [i]Media Destruction[/i] section of this chapter is the only way to provide complete assurance classified information no longer persists.

Treatment of volatile media following sanitisation

Published literature suggests that short-term remanence effects (residual information that remains on media after erasure) are likely in volatile media. Data retention times are reported to be measured in minutes (at normal room temperatures) and up to hours (in extreme cold). Further, published literature has shown that some volatile media can suffer from long-term remanence effects resulting from physical changes to the media due to continuous storage of static data for an extended period of time. It is for these reasons that under certain circumstances TOP SECRET volatile media is required to remain at this classification, even after sanitisation.

Circumstances preventing reclassification of volatile media

Typical circumstances preventing the reclassification of TOP SECRET volatile media include a static cryptographic key being stored in the same memory location during every boot of a device and a static image being displayed on a device and stored in volatile media for a period of months.

Non-volatile magnetic media sanitisation

Both the host-protected area and device configuration overlay table of non-volatile magnetic hard disks are normally not visible to the operating system or the computer’s basic input/output system. Hence any sanitisation of the readable sectors on the media will not overwrite these hidden sectors leaving any information contained in these locations untouched. Some sanitisation programs include the ability to reset devices to their default state removing any host-protected areas or device configuration overlays. This allows the sanitisation program to see the entire contents of the media during the subsequent sanitisation process.

Modern non-volatile magnetic hard disks automatically reallocate space for bad sectors at a hardware level. These bad sectors are maintained in what is known as the growth defects table or ‘g-list’. If information was stored in a sector that is subsequently added to the g-list, sanitising the media will not overwrite these non-addressable bad sectors. While these sectors may be considered bad by the device, quite often this is due to the sectors no longer meeting expected performance norms for the device and not due to an inability to read/write to the sector. The Advanced Technology Attachment (ATA) secure erase command was built into the firmware of post-2001 devices and is able to access sectors that have been added to the g-list. Modern non-volatile magnetic hard disks also contain a primary defects table or ‘p-list’. The p-list contains a list of bad sectors found during post-production processes. No information is ever stored in sectors on the p-list for a device as they are inaccessible before the media is used for the first time.

Treatment of non-volatile magnetic media following sanitisation

Highly classified non-volatile magnetic media cannot be sanitised below its original classification due to concerns with the sanitisation of the host-protected area, device configuration overlay table and growth defects table. The sanitisation of TOP SECRET nonvolatile media does not allow for the reduction of its classification.

Non-volatile Erasable Programmable Read-only Memory media sanitisation

When erasing non-volatile erasable Programmable read-only Memory (EPROM), the manufacturer’s specification for ultraviolet erasure time must be multiplied by a factor of three to provide an additional level of certainty in the process.

Non-volatile Electrically Erasable Programmable Read-only Memory media sanitisation

A single overwrite with a random pattern is considered best practice for sanitising nonvolatile electrically erasable Programmable read-only Memory (EEPROM) media.

Treatment of non-volatile EPROM and EEPROM media following sanitisation

As little research has been conducted on the ability to recover data on non-volatile EPROM or EEPROM media after sanitisation, highly classified media retains its original classification.

Non-volatile flash memory media sanitisation

In flash memory media, a technique called wear levelling ensures that writes are distributed evenly across each memory block in flash memory. This feature necessitates flash memory being overwritten with a random pattern twice, rather than once, as this helps ensure that all memory blocks are overwritten during sanitisation.

Treatment of non-volatile flash memory media following sanitisation

Due to the use of wear levelling in flash memory, it is possible that not all physical memory locations are written to when attempting to overwrite the media. Information can therefore remain on the media. This is why TOP SECRET, SECRET and CONFIDENTIAL flash memory media must always remain at their respective classification, even after sanitisation.

Sanitising media prior to reuse

Sanitising media prior to reuse assists with enforcing the need-to-know principle.

Encrypted media

When applied appropriately, the use of data at rest encryption can reduce the exposure of information and provide additional assurance during sanitisation, device reuse, warranty and disposal. Unless otherwise stated in product guides, the use of encryption does not reduce the post-sanitisation handling requirements for media.

Additional information relating to the destruction of ICT equipment can be found in the Product Sanitisation and Disposal section of the Product Security chapter.

Media that cannot be sanitised and must be destroyed

It is not possible to use some types of media while maintaining a high level of assurance that no previous data can be recovered.

Destruction procedures

Documenting procedures for media destruction will ensure that agencies carry out media destruction in an appropriate and consistent manner.

Media destruction

The destruction methods given are designed to ensure that recovery of information is impossible or impractical.

Very small characters can be produced on microform. Using equipment that is capable of reducing microform to a fine powder (with resultant particles not showing more than five consecutive characters per particle upon microscopic inspection) will prevent data recovery from destroyed microform.

Media destruction equipment

The National Security Agency/Central Security Service’s EPL Degausser (EPLD) contains a list of certified degaussers.

The Government Communications Headquarters/Communications-Electronics Security Group’s certified data erasure products list also contains a list of certified degaussers.

When using a degausser to destroy media, checking its field strength regularly will confirm the degausser is functioning correctly.

When physically destroying media, using approved equipment will give agencies complete assurance that information residing on the media is destroyed.

This includes destruction equipment:
• listed in the ASIO Security Equipment Catalogue; or
• meeting the ASIO Security equipment Guides, (i.e. SEG–009 optical Media Shredders, and SEG–018 destructors).

The ASIO Security Equipment Catalogue may be ordered via the SCEC website ([link]http://www.scec.gov.au[/link]). The ASIO Security Equipment guides are available from the Protective Security Policy Govdex Community or ASIO—T4 by email request.

Storage and handling of media waste particles

Following destruction, normal accounting and auditing procedures do not apply for media. Due to the increasing density of media and the reduction in physical sizes for electronic components, it is essential that when media is recorded as being destroyed, destruction is ensured.

Degaussers

Degaussing magnetic media changes the alignment of magnetic domains in the media. Data contained on the media becomes unrecoverable. Degaussing renders magnetic media unusable as the storage capability for the media is permanently corrupted.

Coercivity varies between media types and between brands and models of the same type of media. Care is needed when determining the desired coercivity since a degausser of insufficient strength will not be effective. The National Security Agency/Central Security Service’s EPLD contains a list of common types of media and their associated coercivity ratings.

Since 2006, perpendicular magnetic media have become available. Some degaussers are only capable of sanitising longitudinal magnetic media. Care therefore needs to be taken to ensure that a suitable degausser is used when sanitising perpendicular magnetic media.

Agencies will need to comply with any product-specific directions provided by product manufacturers and certification authorities to ensure that degaussers are being used in the correct manner to achieve an effective destruction outcome.

Supervision of destruction

To ensure that media is appropriately destroyed, the process needs to be supervised by at least one person cleared to the sensitivity or classification of the media being destroyed to verify that destruction is successfully completed.

Supervision of accountable material destruction

Since accountable material is more sensitive than standard classified media, it needs to be supervised by at least two personnel and have a destruction certificate signed by the personnel supervising the process.

Outsourcing media destruction

ASIO-T4 Protective Security maintains a list of external destruction services that are approved to destroy media in an approved manner. The ASIO Protective Security Circular 144 External Destruction of Australian Government Official Information provides additional advice on the use of external destruction services. The Protective Security Circular and the list of external destruction services are available from the Protective Security Policy Govdex Community or ASIO-T4 following an email request.

Transporting media for external destruction

Requirements for the physical transfer of media between agencies and external destruction services can be found in the [i]Australian Government Information Security Management Guidelines - Protectively marking and handling sensitive and security classified information[/i].

Additional information relating to the disposal of ICT equipment can be found in the [i]Product Sanitisation and Disposal[/i] section of the [i]Product Security[/i] chapter.

Disposal procedures

The following diagram shows an overview of the typical disposal process. In the diagram there are two starting points, one for classified media and one for sensitive media. Also note that declassification is the entire process, including any reclassifications and administrative decisions, that must be completed before media and media waste can be released into the public domain.

Declassifying media

The process of reclassifying, sanitising or destroying media is not sufficient for media to be declassified and released into the public domain. In order to declassify media a formal administrative decision will need to be made to release the media or waste into the public domain.

Disposal of media

Disposing of media in a manner that does not draw undue attention ensures that previously sensitive or classified media is not subjected to additional scrutiny over that of regular waste.

Supporting information

Further information on patching operating systems can be found in the [i]Software Patching[/i] section of this chapter.

Further information on identifying, authenticating and authorising users of operating systems can be found in the [i]Authorisations, Security Clearances and Briefings[/i] section of the [i]Personnel Security for Systems[/i] chapter and the [i]Identification, Authentication and Authorisation[/i] section of the [i]Access Control[/i] chapter.

Further information on the use of privileged accounts for operating systems can be found in the [i]Privileged Access[/i] section of the [i]Access Control[/i] chapter.

Further information on logging and auditing of operating system events can be found in the [i]Event Logging and Auditing[/i] section of the [i]Access Control[/i] chapter.

Developing SOEs

Allowing users to setup, configure and maintain their own workstations can create an inconsistent and unsecure environment where particular workstations are more vulnerable than others. This type of environment can easily allow an adversary to gain an initial foothold on a network. The [i]Common Operating Environment Policy[/i] produced by the Department of Finance is applicable to Commonwealth entities developing new SOEs and was designed to ensure a consistent and secure baseline for operating systems across government. The [i]Common Operating Environment Policy[/i] is vendor agnostic.

New versions of operating systems often introduce improvements in security functionality over previous versions. This can make it more difficult for an adversary to craft reliable exploits for security vulnerabilities they discover. Using older versions of operating systems, especially those no longer supported by vendors, exposes agencies to exploit techniques that have since been mitigated in newer versions of the operating system.

The x64 (64-bit) versions of Microsoft Windows include additional security functionality that the x86 (32-bit) versions lack. This includes native hardware-based data execution Prevention (DEP) kernel support, Kernel Patch Protection (PatchGuard), mandatory device driver signing and lack of support for malicious 32-bit drivers or 16-bit code. Using x86 (32-bit) versions of Microsoft Windows exposes agencies to exploit techniques mitigated by x64 (64-bit) versions of Microsoft Windows.

Hardening SOE configurations

When operating systems are deployed in their default state it can easily lead to an unsecure operating environment allowing an adversary to gain an initial foothold on a network. Many options exist within operating systems to allow them to be configured in a secure state to minimise this risk. The SOE Build Guidelines developed by the Department of Finance as part of the Common Operating Environment Policy are designed to assist Commonwealth entities in deploying hardened Microsoft Windows 7 and later SOE configurations.

When local administrator accounts are used with common account names and passphrases it can allow an adversary that compromises these credentials on one workstation or server to easily transfer across the network to other workstations or servers. Even if local administrator accounts have unique names and have unique passphrases, an adversary can still identify those accounts based on their security identifier and use this information to focus any attempts to use brute force to discover credentials for a workstation or server if they can get access to the Security Accounts Manager (SAM) database.

While the ability to install applications may be a business requirement for users, this privilege can be exploited by an adversary. An adversary can email a malicious application, or host a malicious application on a compromised website, and use social engineering techniques to convince users to install the application. Even if privileged access is required to install applications, users will use their privileged access if they believe, or can be convinced that, the requirement to install the application is legitimate. Additionally, if applications are configured to install using elevated privileges, an adversary can exploit this by creating a Windows Installer installation package to create a new account that belongs to the local administrators group or to install a malicious application.

Allowing devices, particularly privately owned mobile devices, that are connected to an agency’s network to simultaneously connect to another network allows the devices to act as an unauthorised gateway between the two networks. For example, a laptop connecting to an agency’s network by ethernet while simultaneously connecting to a telecommunication provider’s mobile broadband network via a 3G/4G dongle is capable of bridging the two networks and opening a backdoor into the agency’s network from the internet. Often this can be prevented by disabling operating system functionality such as ad hoc networks, network bridging and internet connection sharing.

Hardening application configurations

By default, many applications enable functionality that is not required by users while security functionality may be disabled or set at a lower security level. This is especially risky for key applications such as office productivity suites (e.g. Microsoft Office), PDF readers (e.g. Adobe Reader), web browsers (e.g. Microsoft Internet Explorer, Mozilla Firefox or Google Chrome), common web browser plugins (e.g. Adobe Flash), email clients (Microsoft Outlook) and software platforms (e.g. Oracle Java Platform and Microsoft .Net Framework) that are likely to be targeted by an adversary. To assist in securely configuring their products, vendors may provide security guides. For example, Microsoft provides Microsoft Office security guides as part of the Microsoft Security Compliance Manager tool.

Application whitelisting

An adversary can email malicious code, or host malicious code on a compromised website, and use social engineering techniques to convince users into executing it. Such malicious code often aims to exploit security vulnerabilities in existing applications and does not need to be installed to be successful. Application whitelisting, when implemented in its most effective form (e.g. using hashes for executables, dynamic link libraries (DLLs), scripts and installers) can be an extremely effective mechanism in not only preventing malicious code from executing, but also ensuring only authorised applications can be installed. Less effective implementations of application whitelisting (e.g. using approved paths for installed applications, in combination with access controls requiring privileged access to write to these locations) can be used as a first step towards implementing a more comprehensive application whitelisting solution.

When developing application whitelisting rule sets, defining a list of approved programs, DLLs, scripts and installers from scratch is a more secure method than relying on a list of those currently residing on a workstation or server. Furthermore, it is preferable that agencies define their own approved list of programs, DLLs, scripts and installers rather than relying on lists from application whitelisting vendors.

It is important that application whitelisting does not replace antivirus and other internet security software already in place on workstations and servers.

Enhanced Mitigation Experience Toolkit

An adversary who develops exploits for Microsoft Windows will be more successful exploiting security vulnerabilities in workstations and servers where Enhanced Mitigation Experience Toolkit (EMET) software has not been implemented. The EMET was designed by the Microsoft Security Research Center (MSRC) engineering team to provide a number of system-wide mitigation measures, such as DEP, ASLR, SEHOP and SSL/TLS certificate trust pinning, while also providing additional application-specific mitigation measures. Mitigation measures that can be defined on an application-by-application basis include: null page pre-allocation, common heap spray address pre-allocation, export address table access filtering, bottom-up virtual memory randomisation, checking and preventing LoadLibary calls against UNC paths, special checking on memory protection APIs, ROP mitigation for critical functions, simulating execution flows, and checking if a stack pointer was pivoted.

Host-based intrusion prevention systems

Many endpoint security applications rely on signatures to detect malicious code. This approach is only effective when a particular piece of malicious code has already been profiled and signatures are current. Unfortunately, an adversary can create variants of known malicious code, or develop new unseen malicious code, to bypass traditional signature-based detection mechanisms. A host-based intrusion prevention system (HIPS) can use behaviour-based detection schemes to assist in identifying and blocking anomalous behaviour, such as process injection, keystroke logging, driver loading and call hooking, as well as detecting malicious code that has yet to be identified by antivirus vendors. Accordingly, some antivirus products are evolving into converged, endpoint security products that incorporate HIPS functionality.

Software-based application firewalls

Network firewalls often fail to prevent the propagation of malicious code on a network, or an adversary from extracting sensitive information, as they generally only control which ports or protocols can be used between segments on a network. Many forms of malicious code are designed specifically to take advantage of this by using common protocols such as HTTP, HTTPS, SMTP and DNS. Software-based firewalls are more effective than network firewalls as they can control which applications and services can communicate to and from workstations. The in-built Windows firewall (from Microsoft Windows 7 onwards) can be used to control both inbound and outbound traffic for specific applications.

Antivirus and internet security software

When vendors develop software they often forgo secure coding practices or rush their products to market without sufficiently comprehensive testing. An adversary can take advantage of this to develop malicious code to exploit security vulnerabilities in software not detected and remedied by vendors. As significant time and effort is often involved in the development of functioning and reliable exploits, an adversary will often reuse their exploits as much as possible before being forced to develop new exploits by antivirus vendors that profile their exploits and develop detection signatures. Whilst exploits may be profiled by antivirus vendors, they often remain a variable intrusion method in agencies that don't have any measures in place to detect them.

Endpoint device control

The use of endpoint device control software to control the use of unauthorised removable media and devices adds value as part of a defence-in-depth approach to the protection of workstations and servers. Further information on the use of removable media with systems can be found in the [i]Media Usage[/i] section of the [i]Media Security[/i] chapter.

Patching approaches

Patches for security vulnerabilities are provided by vendors in many forms, such as: fixes that can be applied to pre-existing application versions, fixes incorporated into new applications or drivers that require pre-existing versions to be replaced, or as fixes that require the overwriting of firmware on hardware devices.

Supporting information

Further information on patching evaluated products can be found in the [i]Product Installation and Configuration[/i] section of the [i]Product Security[/i] chapter.

Patching security vulnerabilities

Applying patches to operating systems, applications, drivers and hardware devices is a critical activity in ensuring the security of systems. Patching therefore needs to be considered as part of any risk management program. To assist in this, information sources will need to be monitored for information about new security vulnerabilities and associated patches.

When to patch security vulnerabilities

There are multiple information sources that organisations can use to assess the applicability and risk of security vulnerabilities in the context of their environment. This can include information published in vendor security bulletins or in severity ratings assigned to security vulnerabilities using standards such as the Common Vulnerability Scoring System (CVSS).

Once a patch is released by a vendor, and the associated security vulnerability has been assessed for its applicability and importance, the patch should be deployed in a timeframe that is commensurate with the risk posed to systems. Doing so ensures that resources are spent in an effective and efficient manner by focusing effort on the most significant risks first.

Temporary workarounds may provide the only effective protection, if there are no patches available from vendors for security vulnerabilities. These workarounds may be published in conjunction with, or soon after, security vulnerability announcements. Temporary workarounds may include disabling the vulnerable functionality within the operating system, application or device, or restricting or blocking access to the vulnerable service using firewalls or other access controls. The decision as to whether a temporary workaround is implemented should be risk-based, as with patching.

If a patch is released for a High Assurance product, ASD will conduct an assessment of the patch and may revise the product’s usage guidance. Where required, ASD will conduct an assessment of any cryptographic security vulnerability and may revise usage guidance in the Consumer Guide for the product or in any product-specific doctrine. If a patch for a High Assurance product is approved for deployment, ASD will inform agencies of the timeframe in which the patch is to be deployed.

How to patch security vulnerabilities

To ensure that patches are applied consistently across an agency’s workstation and server fleet, it is essential that agencies use a centralised and managed approach. This will assist in ensuring the integrity and authenticity of patches being applied to workstations and servers.

When patches are not available

When a patch is not available for a security vulnerability there are a number of approaches that can be undertaken to reduce the risk to a system. In priority order this includes: mitigating access to the vulnerability through alternative means, preventing exploitation of the security vulnerability, containing the exploitation of the security vulnerability or detecting exploitation of the security vulnerability.

Cessation of support

When operating systems, applications and hardware devices reach their cessation date for support, agencies will find it increasingly difficult to protect against security vulnerabilities as patches, or other forms of support, will not be made available by the vendor. While the cessation date for support for operating systems is generally advised many years in advance by vendors, other applications may cease to receive support immediately after a newer version is released by the vendor.

[b]--[ CONTEXT MISSING - The following context is included from the 2014 release of the ISM ]--[/b]

By following the guidelines in this section, the software flaws and vulnerabilities which are able to be exploited by an intruder will be considered and addressed.

Software development environments

Segregating software development environments into development, testing and production environments limits the spread of malicious code and minimises the likelihood of faulty code being put into production. Furthermore, limiting access to software development and testing environments will reduce the information that can be obtained by a malicious insider.

Secure software design

Threat modelling is an important part of secure software design. Threat modelling identifies at risk components of software enabling security measures to be identified to reduce risks.

Secure programming practices

Once a secure software design has been identified, secure programming practices will need to be followed during software development. examples of secure programming practices includes performing correct input validation and handling, robust and fault-tolerant programming and ensuring the software uses the smallest number of privileges required.

Software testing

Software testing will lessen the possibility of security vulnerabilities in software being introduced into a production environment. Software testing can be performed using both static testing, such as code analysis, as well as dynamic testing, such as input validation and fuzzing. Using an independent party for software testing will remove any bias that can occur when a software developer tests their own software.

Protecting web applications

Even when web applications only contain unclassified information there remains a need to protect the integrity and availability of the information processed by the web application and the system it is hosted on.

Supporting information

Further information on auditing requirements for web applications can be found in the Event Logging and Auditing section of the Access Control chapter.

Web application frameworks

Web application frameworks can be leveraged by software developers to enhance the security of a web application while decreasing development time. These resources can assist software developers to securely implement complex components such as session management, input handling and cryptographic operations.

Input handling

Most web application vulnerabilities are caused by the lack of secure input handling by web applications. It is essential that web applications do not trust any input such as the URL and its parameters, HTML form data, cookie values and HTTP request headers without validating or sanitising it.

Examples of validation and sanitisation include:
• ensuring a telephone form field contains only numerals
• ensuring data used in an SQL query is sanitised properly
• ensuring Unicode input is handled appropriately.

Output encoding

The risk of cross-site scripting and other content injection attacks can be reduced through the use of contextual output encoding. The most common example of output encoding is the use of HTML entities. Performing HTML entity encoding causes potentially dangerous HTML characters such as '<', '>' and '&' to be converted into their encoded equivalents '&lt;', '&gt;' and '&amp;'.

Output encoding is particularly useful where external data sources, which may not be subject to the same level of input filtering, are output to users.

Web browser-based security controls

Web browser-based security controls such as Content Security Policy, HTTP Strict transport Security and Frame options can be leveraged by web applications to help protect the web application and its users.

These security controls are implemented by the web application via the insertion of HTTP headers containing security policy in outgoing responses. Web browsers then apply the control according to the defined policy. Since the controls are applied via HTTP headers it makes it possible to apply the controls to legacy or proprietary web applications where changes to the source code are impractical.

Open Web Application Security Project

The [i]Open Web Application Security Project[/i] provides a comprehensive resource to consult when developing web applications.

Supporting information

Further information on developing standard operating environments for database servers can be found in the [i]Standard Operating Environments[/i] section of this chapter.

Further information on patching DBMS software can be found in the [i]Software Patching[/i] section of this chapter.

Further information on identifying, authenticating and authorising users of database systems can be found in the [i]Authorisations, Security Clearances and Briefings[/i] section of the [i]Personnel Security for Systems[/i] chapter and the [i]Identification, Authentication and Authorisation[/i] section of the [i]Access Control[/i] chapter.

Further information on the use of privileged accounts for database systems can be found in the [i]Privileged Access[/i] section of the [i]Access Control[/i] chapter.

Further information on logging and auditing of database system events can be found in the [i]Event Logging and Auditing[/i] section of the [i]Access Control[/i] chapter.

Further information on using cryptography with database systems can be found in the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.

Maintaining an accurate inventory of databases

Without knowledge of all the databases in an agency, and the sensitive or classified information they contain, an agency will be unable to apply protection to these assets.

DBMS software installation and configuration

DBMS software will often leave temporary installation files and logs during the installation process, in case an administrator needs to troubleshoot a failed installation. Information in these files, which can include passphrases in the clear, could provide valuable information to an adversary.

Poorly configured DBMS software could provide an opportunity for an adversary to gain unauthorised access to database content. To assist agencies in deploying DBMS software, vendors often provide guidance on how to securely configure their DBMS software.

DBMS software is often installed with most features enabled by default as well as being pre-configured with a sample database and anonymous accounts for testing purposes. Additional functionality often brings with it an increased risk.

If DBMS software, which is operating as a local administrator or root account, is compromised by an adversary, it can present a significant risk to the underlying operating system.

DBMS software is often capable of accessing files that it has read access to on the local database server.

For example, an adversary using an SQL injection could use the command LOAD DATA LOCAL INFILE ‘etc/passwd’ INTO TABLE Users or SELECT load_file(“/etc/passwd”) to access the contents of a Linux password file. Disabling the ability of the DBMS software to read local files from a server will prevent such SQL injection from succeeding. This could be performed, for example, by disabling use of the LOAD DATA LOCAL INFILE command.

Protecting authentication credentials in databases

Storing authentication credentials such as usernames and passphrases as plaintext in databases poses a significant risk. An adversary that manages to gain access to a database’s contents could extract these authentication credentials to gain access to users’ accounts. In addition, it is possible that a user could have reused a username and passphrase for their workstation posing an additional risk.

Protecting databases

Database contents can be protected from unauthorised copying and subsequent offline analysis by applying file-based access controls to database files. However, should an adversary gain access to database files by, for example, the physical theft of a database server, compromised administrative credentials on a database server or failure to sanitise database server hardware before disposal, an additional layer of protection is required.

Protecting database contents

Database administrators and database users need to know the sensitivity or classification associated with a database and its contents to ensure that sufficient security measures are applied to databases. In cases where all of the database’s contents are the same sensitivity or classification an agency may choose to protectively mark the entire database at this level. Alternatively, in cases where the database’s contents are of varying sensitivity or classification levels, and database users have differing levels of access to such information, an agency may choose to apply protective markings at a more granular level within the database.

Limiting database user’s ability to access, insert, modify or remove content from databases based on their work duties will ensure the need-to-know principle is applied and the risk of unauthorised modifications is reduced.

Aggregation of database contents

Where concerns exist that the sum, or aggregation, of separate pieces of sensitive or classified information from within databases could lead to an adversary determining more highly sensitive or classified information, database views in combination with database user access roles should be implemented. Alternatively, the information of concern could be separated by implementing multiple databases, each with restricted data sets. If implemented properly, this will ensure an adversary cannot access the sum of information components leading to the aggregated information.

Database administrator accounts

DBMS software often comes pre-configured with default database administrator accounts and passphrases that are listed in vendor documentation, for example, sa/<blank> for SQL Server, root/<blank> for MySQL, scott/tiger for Oracle and db2admin/db2admin for dB2.

When sharing database administrator accounts for the performance of administrative tasks, any actions undertaken will not be attributable to an individual database administrator. This can hinder investigations relating to an attempted, or successful, cyber intrusion. Furthermore, database administrator accounts shared across different databases can exacerbate any compromise of a database administrator account by an adversary.

When creating new database administrator accounts, the accounts are often allocated all privileges available to administrators. Most database administrators will only need a subset of all available privileges to undertake their authorised duties.

Database accounts

DBMS software often comes pre-configured with anonymous database accounts with blank passphrases which could be exploited by an adversary.

Databases often contain information and metadata of varying sensitivities or classifications. It is important users are only granted access to information in databases for which they have the required security clearance, briefings and a need-to-know.

Network environment

Placing database systems used by web applications on the same physical server as a web server can expose them to an increased risk of compromise by an adversary.

Placing database servers on the same network segment as an agency's workstations and allowing them to communicate with other network resources exposes them to an increased risk of compromise by an adversary.

In cases where database systems will only be accessed from their own database server, allowing remote access to the database server poses an unnecessary risk.

Separation of production, test and development environments

Using production databases for test and development activities could result in accidental damage to their integrity or contents.

Using sensitive or classified information from production databases in test or development databases could result in inadequate protection being applied to the information.

Interacting with database systems from web applications

SQL injection is a significant threat to database confidentiality, integrity and availability. SQL injections can allow an adversary to steal information from databases, modify database contents, delete an entire database or even in some circumstances gain control of the underlying database server.

Information communicated between database systems and web applications, especially over the Internet, is susceptible to capture by an adversary.

When database queries by web applications fail they are capable of displaying detailed error information to users of the web application. This can include the DBMS software version and patch levels. In addition, the failed database query can be displayed revealing information about the database schema. This can be used by an adversary to exploit published vulnerabilities in DBMS software, or further tailor SQL injection attempts.

Information on ISPs can be found in the [i]Information Security Policy[/i] section of the [i]Information Security Documentation[/i] chapter.

Email usage policy

There are many security risks associated with the non-secure nature of email that are often overlooked. Documenting them will inform information owners about these risks and how they might affect business operations.

Awareness of email usage policies

There is little value in having email usage policies for personnel if they are not made aware of their existence.

Monitoring email usage

Monitoring breaches of email usage policies; for example, attempts to send prohibited file types or executables, attempts to send excessively large attachments or attempts to send sensitive or classified information without appropriate protective markings will help enforce email usage policy.

Web-based email services

Allowing staff to access web-based email services can pose a security risk, if the web content filtering controls in place to mitigate malicious web mail attachments are inadequate; and this can be further complicated by the prevalent use of Secure Socket Layer/Transport Layer Security by webmail providers. Additionally, the agency is reliant upon the web mail provider implementing mitigations such as Sender Policy Framework (SPF) and DomainKeys.

Web-based email is email accessed using a web browser, examples of which include Gmail, Outlook.com and email portals provided by Internet Service Providers.

Socially engineered emails

Socially engineered emails are one of the most common techniques used to spread malicious software. Agencies need to ensure their users are aware of the threat and educated on how to detect and report suspicious emails.

Additional requirements and guidance for email protective markings can be found in the Department of Finance's [i]Email Protective Marking Standard for the Australian Government[/i].

Marking emails

As for paper-based information, all electronic-based information needs to be marked with an appropriate protective marking. This ensures that appropriate security measures are applied to the information and helps prevent unauthorised information being released into the public domain. When a protective marking is applied to an email it is important that it reflects the sensitivity or classification of the information in the body of the email and in any attachments to the email.

This supports the requirements outlined in the [i]Australian Government Information Security Management Protocol[/i].

Emails from outside the government

If an email is received from outside government the user has an obligation to determine the appropriate security measures for the email if it is to be responded to, forwarded on or printed out.

Marking personal emails

Applying incorrect protective markings to emails that do not contain government information places an extra burden on protecting emails that do not need protection.

Emails that do not contain official government information should be marked with an UNOFFICIAL protective marking to clearly indicate the email is of a personal nature.

Receiving unmarked emails

If an email is received without a protective marking the user has an obligation to contact the originator to seek clarification on the appropriate security measures for the email. Alternatively, where the user receives unmarked non-government emails as part of its business practice the application of protective markings can be automated by a system.

Receiving emails with unknown protective markings

If an email is received with a protective marking that the user is not familiar with, they have an obligation to contact the originator to clarify the protective marking and the appropriate security measures for the email.

Preventing unmarked or inappropriately marked emails

Unmarked or inappropriately marked emails can be blocked at two points, the workstation or the email server. The email server is the preferred location to block emails as it is a single location, under the control of system administrators, where the requirements for the entire network can be enforced. In addition, email servers can apply controls for emails generated by applications.

While blocking at the email server is considered the most appropriate control there is still an advantage in blocking at the workstation. This adds an extra layer of security and will also reduce the likelihood of a data spill occurring on the email server.

Blocking inbound emails

Blocking an inbound email with a protective marking higher than the sensitivity or classification that the receiving system is accredited to will prevent a data spill from occurring on the receiving system.

Blocking outbound emails

Blocking an outbound email with a protective marking higher than the sensitivity or classification of the path over which it would be communicated stops data spills that could occur due to interception or storage of the email at any point along the path.

Agencies may remove protective markings from emails destined for private citizens and businesses once they have been approved for release from their gateways.

Protective marking standard

Applying markings that reflect the protective requirements of an email informs the recipient on how to appropriately handle the email.

The application of protective markings as per the Department of Finance standard facilitates interoperability across government.

Printing protective markings

The [i]Australian Government Information Security Management Protocol[/i] requires that paper-based information have the protective marking of the information placed at the top and bottom of each piece of paper.

Protective marking tools

Requiring user intervention in the marking of user-generated emails assures a conscious decision by the user, lessening the chance of incorrectly marked emails.

Allowing users to choose only protective markings for which the system is accredited lessens the chance of a user inadvertently over-classifying an email. It also reminds users of the maximum sensitivity or classification of information permitted on the system.

Email gateway filters generally only check the most recent protective marking applied to an email. Therefore, when users are forwarding or responding to an email, forcing them to apply a protective marking, which is at least as high as that of the email they received, will help email gateway filters prevent emails being sent to systems that are not accredited to handle the original sensitivity or classification of the email.

Caveated email distribution

Often the membership and nationality of members of email distribution lists is unknown. Therefore users sending emails with AUSTEO, AGAO or other nationality releasability marked information to distribution lists could accidentally cause a data spill.

Information on usage policies for personnel is located in the [i]Email Policy[/i] section of this chapter, and the [i]Using the Internet[/i] section of the [i]Personnel Security for Systems[/i] chapter.

Undeliverable messages

Undeliverable or bounce emails are commonly sent by email servers to the original sender when the email cannot be delivered, usually because the destination address is invalid. Due to the common spamming practice of spoofing sender addresses, this often results in a large amount of bounce emails being sent to an innocent third party. Sending bounces only to senders that can be verified via SPF, or other trusted means avoids contributing to this problem and allows trusted parties to receive legitimate bounce messages.

Automatic forwarding of emails

Automatic forwarding of emails, if left unsecured, can pose a security risk of the unauthorised disclosure of sensitive or classified information. For example, a user could setup a server-side rule to automatically forward all emails received on an internet-connected system to their personal email account outside work.

Open relay email servers

An open relay email server (or open mail relay) is a server that is configured to allow anyone on the internet to send emails through the server. Such configurations are highly undesirable as they allow spammers and worms to exploit this functionality.

Email server maintenance activities

Email servers perform a critical business function. It is important that agencies perform regular email server auditing, security reviews and vulnerability analysis activities.

Centralised email gateways

Without a centralised email gateway it is exceptionally difficult to deploy SPF, DomainKeys Identified Mail (DKIM) and outbound email protective marking verification.

Adversaries will almost invariably avoid using the primary email server when sending malicious emails. This is because the backup or alternative email gateways are often poorly maintained in terms of out–of–date blacklists and content filtering.

Email server transport encryption

Email can be intercepted anywhere between the originating email server and the destination email server. Enabling Transport Layer Security (TLS) on the originating and accepting email server will defeat passive intrusions on the network, with the exception of cryptanalysis against email traffic. TLS encryption between email servers will not interfere with email content filtering schemes. Email servers will remain compatible with other email servers as Internet Engineering Task Force (IETF) Request for Comments (RFC) 3207 specifies the encryption as opportunistic.

Email is a common vector for cyber intrusions. Email content filtering is an effective approach to preventing network compromise through cyber intruders' use of malicious emails.

Information on specific content filtering controls can be found in the [i]Data Transfers and Content Filtering[/i] chapter.

Filtering malicious and suspicious emails and attachments

Blocking specific types of emails reduces the likelihood of phishing emails and emails containing malicious code entering an agency network.

Active web addresses in emails

Spoofed emails often contain an active web address directing users to a malicious website to either illicit information or infect their workstation with malicious code. To reduce the success rate of such intrusions agencies can strip active web addresses from emails and replace them with non-active versions that a user can type or copy and paste into their web browser.

SPF

SPF, and alternative implementations such as Sender Id, aid in the detection of spoofed emails. The SPF record specifies a list of IP addresses or domains that are allowed to send email from a specific domain. If the email server that sent the email is not in the list, the verification fails. There are a number of different fail types available.

DKIM

DKIM enables a method of determining spoofed email content. The DKIM record specifies a public key that will sign the content of the message. If the signed digest in the email header does not match the signed content of the email, the verification fails.

Authentication methods

Authentication can be achieved by various methods. Methods of authentication include: passphrases or passwords, biometrics, cryptographic tokens and smart cards.

Multi-factor authentication

Multi-factor authentication uses independent means to confirm a user’s identity.

Multi-factor authentication may include the following methods:
• something a user knows, such as a passphrase or a response to a security question
• something a user has, such as a passport, physical token or an identity card
• something unique about a user, such as biometric data, like a fingerprint or face geometry.

Any two of these authentication methods must be used to have multi-factor authentication. If something a user knows, such as the passphrase, is written down or typed into a file and stored in plain text, this evidence becomes something that a user has, which defeats the purpose of multi-factor authentication.

Service accounts

When this manual refers to passphrase policies, it is equally applicable to all account types including user accounts, privileged accounts and service accounts.

Supporting information

Additional information on privileged access can be found in the Privileged Access section of this chapter. Further information can also be found in the Authorisations, Security Clearances and Briefings section of the Personnel Security for Systems chapter.

Policies and procedures

Developing policies and procedures will ensure consistency in user identification, authentication and authorisation.

User identification

Having uniquely identifiable users ensures accountability.

Where systems contain AUSTEO, AGAO or other nationality-based releasability marked information, and foreign nationals have access to the systems, it is important that security measures are implemented to ensure foreign nationals are identified as such.

Shared non-user specific accounts

Using shared non-user specific accounts can hamper efforts to attribute actions on a system to specific personnel. When allowing the use of shared non-user specific accounts, a method of attributing actions undertaken by such accounts to specific personnel will need to be implemented. For example, a logbook may be used to document the date and time that a person takes responsibility for using a shared non-user specific account.

Authentication methods

A significant threat to the compromise of authentication information is offline passphrase cracking tools and rainbow tables (lists of pre-computed passphrase hashes). When an adversary gains access to a list of usernames and hashed passphrases from a system, they can attempt to recover passphrases by comparing the hash of a known passphrase with the hashes from the list of hashed passphrases that they obtained. By finding a match, an adversary will know the passphrase associated with a given username. Combined, this often forms a complete set of authentication information for an account. In order to reduce the risk of accounts being compromised in such a manner, agencies can implement multi-factor authentication. Alternatively, an agency may attempt to increase the time on average it takes an adversary to compromise a passphrase by increasing both its complexity and length while decreasing the time it remains valid.

System administrators, database administrators and other privileged users are more likely to be targeted by an adversary as their credentials can potentially allow access to an entire system. In addition, a position of trust, such as a user that is able to approve financial transactions is also more likely to be targeted by an adversary. For this reason, it is important that multi-factor authentication is used for these accounts.

When multi-factor authentication is used, the requirements for passphrases can be relaxed due to the additional protection afforded by a second, and different, authentication method.

The benefit of implementing multi-factor authentication can be diminished when credentials are reused on other systems. For example, when usernames and passphrases used as part of multi-factor authentication for remote access are the same as those used for corporate workstations. In such circumstances, if an adversary had compromised the device used for remote access they could capture the username and passphrase for reuse against a corporate workstation that did not require the use of multi-factor authentication.

Passphrase management practices

Good passphrase management practices provide a means of limiting the likelihood or consequences of the disclosure of passphrases to an adversary.

Account lockouts

Locking an account after a specified number of failed logon attempts reduces the risk of online passphrase guessing attacks. However, implementing account lockout functionality in a web application can increase the risk of a denial of service. This can occur if an adversary deliberately inputs wrong passphrases enough times to lock out accounts. Implementing account and passphrase reset functionality can help mitigate this risk.

Resetting passphrases

To reduce the likelihood of social engineering being used to compromise accounts, users should provide sufficient evidence to verify their identity when requesting a passphrase reset.

This evidence could be in the form of the user either:
• physically presenting themselves and their security pass to service desk personnel who then reset their passphrase
• physically presenting themselves to a known colleague who uses an approved online tool to reset their passphrase
• establishing their identity by responding correctly to a number of challenge response questions before resetting their own passphrase.

Issuing accounts with unique complex reset passphrases ensures the security of the account is maintained during the passphrase reset process.

Passphrase authentication

Local Area Network (LAN) Manager’s authentication mechanism uses a very weak hashing algorithm known as the LAN Manager hash algorithm. Passphrases hashed using the LAN Manager hash algorithm can easily be compromised using rainbow tables or brute force attacks.

Protecting stored authentication information

Storing authentication information with the system that it grants access to, increases the risk of an adversary gaining access to the system. For example, a laptop should not be stored with its passphrase written down and stored in the laptop bag.

If storing authentication information on a system, sufficient protection will need to be implemented to prevent the authentication information from being compromised as part of a targeted cyber intrusion. For example, usernames and passphrases for databases should be stored in a password vault on a system rather than in a Microsoft Word document.

Protecting authentication data in transit

Secure transmission of authentication information reduces the risk of an adversary intercepting and using the authentication information to access a system under the guise of a valid user.

Session and screen locking

Session and screen locking prevents unauthorised access to a system which a user has already been authenticated to access.

Suspension of access

Removing or suspending an account can prevent it from being accessed when there is no longer a legitimate business requirement for its use such as when a user changes duties or leaves an agency.

Investigating repeated account lockouts

Repeated account lockouts may be an indication of malicious activity being directed towards a particular account.

Logon banner

A logon banner reminds users of their responsibilities when using a system.

Access to Australian systems

Due to sensitivities associated with AUSTEO and AGAO systems, it is essential that control of such systems is maintained by Australian citizens working for the Australian Government and that such systems can only be accessed from facilities under the sole control of the Australian Government.

Access by foreign nationals to Australian systems

Enforcing authorisations on systems

Enforcing authorisations of users through the use of access controls on a system decreases the risk of unauthorised disclosure of sensitive or classified information.

The following process can assist in developing access controls:
• establish groups of all system resources based on similar security objectives
• determine the information owner for each group of resources
• establish groups encompassing all users based on similar functions or security objectives
• determine the group owner or manager for each group of users
• determine the degree of access to the resource for each user group
• decide on the degree of delegation for security administration, based on the internal security policy.

Privileged access

Privileged access is considered to be access which can give a user one or more of:
• the ability to change key system configurations
• the ability to change control parameters
• access to audit and security monitoring information
• the ability to circumvent security measures
• access to data, files and accounts used by other users, including backups and media
• special access for troubleshooting a system.

Use of privileged accounts

Users of privileged accounts are often targeted by an adversary as their accounts can potentially give full access to a system. Ensuring that users of privileged accounts do not have access to read emails, open attachments, browse the web or obtain files via internet services such as instant messaging or social media, minimises opportunities for these accounts to be compromised. To further assist in minimising the risk to privileged accounts, their use will need to be restricted.

Privileged access to systems by foreign nationals

As privileged users often have the ability to bypass controls on a system it is strongly encouraged that foreign nationals are not given privileged access to systems, particularly those processing AUSTEO or AGAO information.

Remote privileged access to systems

The risk to the compromise of remote systems and accounts can be reduced by ensuring remote administration is conducted over a secure communications medium from a secure device. Further information on system administration can be found in the [i]Secure Administration[/i] chapter while further information on working off-site can be found in the [i]Working Off-Site[/i] chapter.

Security events

A security event is an evident change to the normal behaviour of a network, system or user.

Supporting information

Information on event logging associated with a cyber security incident can be found in the [i]Cyber Security Incidents[/i] chapter.

Event logging strategy

By developing an event logging strategy an agency can increase the security posture of a system by ensuring the accountability of all user actions, thereby improving the chances that malicious behaviour will be detected. Furthermore, conducting audits of event logs will help detect, attribute and respond to any violations of information security policy, including cyber security incidents, breaches and intrusions.

Secure centralised logging facility

A secure centralised logging facility can be used to correlate and protect event logs from multiple sources. This functionality may be provided by existing systems such as a Security Information and Event Management solution.

Events to be logged

The events to be logged are listed in their importance to monitoring the security posture of systems and contributing to reviews, audits and investigations.

The additional events to be logged below can be useful for reviewing, auditing or investigating software components of systems.

Event details

For each event logged, sufficient detail needs to be recorded in order for the logs to be useful when reviewed.

Event log protection

Effective log protection and storage will help ensure the integrity and availability of captured event logs.

Event log retention

Since event logs can assist in reviews, audits and investigations, event logs should ideally be retained for the life of the system and potentially longer. The retention requirement for these records under National Archives of Australia's (NAA's) Administrative Functions Disposal Authority is a minimum of 7 years.

Event log auditing

Conducting audits of event logs is an integral part of the maintenance of systems, since they help detect and attribute any violations of information security policy, including cyber security incidents, breaches and intrusions.

Secure enterprise administration allows agencies to be resilient in the face of malicious cyber intrusions by protecting privileged machines and accounts from compromise, as well as making adversary movement throughout a network more difficult. If a secure administration system withstands a cyber intrusion and remains clean after other areas of the environment have been compromised, incident response will be far more agile, the damage will be limited and remediation work will be completed faster. The controls in this chapter are designed to protect the administration of a network even if an adversary has already compromised unprivileged elements of the network.

A jump server (also known as a jump host or jump box) is a computer which is used to manage sensitive or critical resources in a separate security domain.

With the increased use of cloud-based resources, agencies may require administrative assets to communicate with external assets on the internet. In this scenario it is still important that controls are put in place to prevent unnecessary communication with arbitrary hosts and protocols.

Further information on remote access to privileged accounts and multi-factor authentication can be found in the [i]Identification, Authentication and Authorisation[/i] section of the [i]Access Control[/i] chapter. Further information about network segmentation for security purposes can be found in the [i]Network Design and Configuration[/i] section of the [i]Network Security[/i] chapter.

Separate privileged user workstations

One of the greatest threats to the security of a network as a whole is the compromise of a workstation used for IT administration.

Providing a physically separate, hardened workstation to privileged users in addition to their workstation used for unprivileged user access provides greater assurance that privileged activities and credentials will not be compromised.

Utilising separate hardened physical machines is the most secure solution; however a risk management approach may determine that a virtualisation-based solution is sufficient.

The use of the same credentials on both the dedicated administration workstation and regular use workstation puts the dedicated workstation at risk if the regular workstation is compromised. The table below provides clarification on the different accounts.

Multi-factor authentication

Multi-factor authentication is a vital component of any secure administration implementation. Multi-factor authentication can limit the consequences of a compromise by preventing or slowing the adversary’s ability to gain unrestricted access to assets secured using multi-factor authentication.

Multi-factor authentication can be implemented as part of the jump server authentication process rather than performing multi-factor authentication on all critical assets and actions, some of which may not support multi-factor authentication.

Agencies should refer to the [i]Identification, Authentication and Authorisation[/i] section of the [i]Access Control[/i] chapter for further multi-factor authentication guidance.

Dedicated administration zones and communication restrictions

Administration security can be improved by segregating privileged user workstations from the wider network.

There are a number of ways through which this segregation can be achieved, including:
• Virtual Local Area Networks
• firewalls
• network access control
• IPsec Server and Domain Isolation.

It is recommended that segmentation and segregation be applied regardless of whether privileged users have a physically separate workstation for administrative purposes, or a regular workstation.

Restriction of management traffic flows

Limiting the flow of management traffic to those network elements and segments explicitly required to communicate can reduce the consequences of a network compromise and make such a compromise easier to detect.

Although regular user workstations will have a need to communicate with critical assets such as web servers or domain controllers in order to function, it is highly unlikely that they will need to send or receive management traffic (such as RDP, SSH and similar protocols) to these critical assets.

When designing a network for secure administration, agencies should follow the recommendations outlined in the [i]Network Design and Configuration[/i] section of the [i]Network Security[/i] chapter.

The following diagram outlines how management traffic filtering could be implemented between a network comprising different zones.

• the ‘Privileged Workstation Zone’ and the ‘Jump Server Zone’
• the ‘Jump Server Zone’ and the ‘Asset Zone’.

All other traffic is blocked as there is no reason for management traffic to flow between the other zones because the jump server solution has been implemented with a dedicated privileged workstation zone.

Jump servers

The use of jump servers as a form of ‘management proxy’ can be an effective way of simplifying and securing privileged activities.

Implementing a jump server can yield the following benefits:
• an efficient and effective focal point to perform multi-factor authentication
• a single place to store and patch management tools
• simplified implementation of management traffic filtering
• a focal point for logging, monitoring and alerting.

In a typical scenario, if a privileged user wants to perform administrative activities, they would connect directly to the target server using RDP or SSH, for example.

In a jump server setup the privileged user would first connect and authenticate to the jump server, then RDP, SSH, or use remote administration tools to access the target server.

When implementing a jump server it is recommended that agencies first implement multi-factor authentication, enforce strict device communication restrictions and harden administrative infrastructure, otherwise a jump server will yield little security benefit.

Network management practices

Networks can be structured and configured to reduce the number of potential entry and exit points that could be used to gain unauthorised access, make unauthorised changes or disrupt access to information and services. Network management practices and procedures can assist in identifying and addressing network vulnerabilities.

Centralised network management

If the network is not centrally managed it will be more difficult for network administrators to maintain the network and for incident responders to respond to any cyber intrusions on the network.

Change management

Approval of all changes by representatives from all parties involved in the management of the network ensures that changes are understood by all parties and reduces the likelihood of unexpected impacts on the network or its services.

Network documentation

It is important that network documentation accurately depicts the current state of the network. This typically includes network devices such as firewalls, data diodes, intrusion detection and prevention systems, routers, switches and critical servers and services. Further, as this documentation could be used by an adversary to assist in compromising a network, it is important that it is protected.

Accounting for network devices

Maintaining and regularly auditing an inventory of authorised network devices will assist in determining whether devices such as switches, routers and wireless access points on a network are rogue.

Supporting information

This section should be read in conjunction with the [i]Servers and Network Devices[/i] section of the [i]Physical Security[/i] chapter. Additional information specific to wireless networks can be found in the [i]Wireless Local Area Networks[/i] section of this chapter, while additional information on gateways can be found in the [i]Cross Domain Security[/i] chapter.

Multi-protocol Label Switching

For the purposes of this section, Multi-protocol Label Switching (MPLS) is considered to be equivalent to Virtual Local Area Networks (VLANs) and is subject to the same controls.

Network segmentation and segregation

Network segmentation and segregation is one of the most effective controls to prevent an adversary from propagating through a network once they have gained access. Well-implemented network segmentation and segregation can significantly increase the difficulty for an adversary to find and access their target information and move undetected around the network. Technologies to enforce network segmentation and segregation contain logging functionality that can prove extremely valuable in detecting an intrusion and, in the event of a compromise, isolating a compromised device from the rest of the network.

Network segmentation and segregation involves separating a network into multiple functional zones, with a view to protecting sensitive information and critical services (such as user authentication and user directory information). For example, one network zone may contain user workstations while authentication servers are in a separate zone. The growth of social engineering as a method to target networks is making it increasingly important to separate sensitive information from the environment where users access the internet and external email.

Proper network segmentation and segregation assists in the creation and maintenance of proper network access control lists.

Functional separation between servers

Implementing functional separation between servers can reduce the risk that a server compromised by an adversary will pose an increased risk to other servers running from within the same operating environment.

Functional separation between server-side computing environments

Software-based isolation mechanisms are commonly used to share a physical server’s hardware among multiple computing environments, which are isolated from each other and from the underlying operating system running on the physical server. Benefits of using such isolation mechanisms to share a physical server’s hardware include increasing the range of purposes that the physical server can be used for, and maximising the utilisation of the physical server’s hardware.

A computing environment could consist of an entire operating system installed in a virtual machine, where the isolation mechanism is a hypervisor, as is commonly used in cloud services providing Infrastructure as a Service. Alternatively, a computing environment could consist of a software application which uses the shared kernel of the underlying operating system running on the physical server, where the isolation mechanisms are application containers or application sandboxes. These isolation mechanisms are commonly used in cloud services providing Platform as a Service.

For the purposes of these controls, the logical separation of data within a single application, which is commonly used in cloud services providing Software as a Service, is not considered to be the same as multiple computing environments.

In the case of a public cloud service or community cloud service, each computing environment is typically controlled by a different person or organisation, and the agency does not own or control the physical server.

An adversary who has compromised a single computing environment, or who legitimately controls a single computing environment (as is the case of a public cloud service), might exploit a misconfiguration or other vulnerability in the isolation mechanism to either compromise other computing environments on the same physical server, or compromise the underlying operating system running on the physical server.

Management traffic

Implementing security measures specifically for management traffic provides another layer of defence on a network should an adversary find an opportunity to connect to the network. This also makes it more difficult to enumerate a target network.

Limiting network access

If an adversary has limited opportunities to connect to a target network, they have limited opportunities to compromise that network. Network access controls, for example 802.1X, not only prevent unauthorised access to a network but also prevent users carelessly connecting a network to another network.

Network access controls are also useful in segregating sensitive information for specific users with a need-to-know or limiting the flow of information between network segments. For example, computer management traffic can be permitted between workstations and systems used for administration purposes, but not permitted between workstations.

Circumventing some network access controls can be trivial. However, their use is primarily aimed at the protection they provide against accidental connection to other networks.

Connecting to non-agency systems

When an agency connects to a system not under their control they need to be aware of the security measures that the other party has implemented to protect the agency’s information. More importantly, the agency needs to accept the risks associated with the other party before connecting to their system.

To assist in identifying risks associated with another party, an agency may request to review any available accreditation documentation for a system or, with the agreement of the other party, seek to have a security assessment for a system conducted by an independent party such as an Information Security Registered Assessor.

Disabling unused physical ports

Disabling unused physical ports on network devices such as switches, routers and wireless access points reduces the attack surface from which intrusions could be launched.

Default accounts for network devices

Network devices such as switches, routers and wireless access points come pre-configured with default accounts and passphrases that are freely available in product documentation and online forums. For example, it is common for wireless access points to come pre-configured with an administrator account named “admin” and a passphrase of either “admin” or “password”. Ensuring default accounts are disabled, renamed or have their passphrase changed before they are deployed in a network will decrease the risk of the accounts being exploited to gain unauthorised access to network devices.

Time synchronisation between network devices

When intrusions occur on networks it is critical that any events logged can be correlated with other network devices and their event logs. Synchronising all clocks between network devices will enable accurate correlation. This is generally achieved through the use of a dedicated time server on the network.

Securing devices accessing networks

Devices, particularly privately owned devices and mobile devices, used to access networks have potentially been exposed to viruses, or malicious software or code when previously connected to non-agency networks such as the internet and mobile networks. These devices could inadvertently infect other devices on secure networks, leveraging a user’s legitimate access to steal sensitive or classified information or impacting the availability of networks. Validating a device as secure through the use of network access controls before being granted access to networks will assist in reducing the risk of network compromise.

Using network access control, system administrators can set policies for system health requirements. This can include a check that all operating system patches are up to date, an antivirus program is installed, all signatures are up to date, and that a software firewall is installed and being used. Devices that comply with all health requirements can be granted access to networks, while devices that do not comply can be quarantined or granted limited access.

Using network-based intrusion detection and prevention systems

Network-based intrusion detection systems (NIDS) and network-based intrusion prevention systems (NIPS) when configured correctly, kept current, and supported by suitable processes and resources can be an effective way of identifying and responding to known intrusion profiles.

Generating alerts for information flows that contravene any rule in the firewall rule set helps security personnel respond to suspicious or malicious traffic entering a network due to a failure or configuration change to firewalls.

Using Virtual Local Area Networks

VLANs can be used to implement network segmentation and segregation as long as the networks are either all unclassified or all the same classification. In such cases, if a data spill occurs between the networks the impact will be lesser than if a data spill occurred between two networks of different classifications or between a classified network and a public network.

Using Internet Protocol version 6

Internet Protocol version 6 (IPv6) functionality can introduce additional risks to a network that must be managed. Disabling IPv6 functionality until it is intended to be used will minimise the attack surface of the network. This will ensure that any IPv6 functionality that is not intended to be used cannot be exploited before security measures have been put in place.

To aid in the transition from IPv4 to IPv6, numerous tunnelling protocols have been developed that are designed to allow interoperability between the protocols. Disabling IPv6 tunnelling protocols on network devices and ICT equipment that do not explicitly require tunnelling functionality will prevent an adversary bypassing traditional network defences by encapsulating IPv6 data inside IPv4 packets.

Stateless Address Autoconfiguration (SLAAC) is a method of stateless IP address configuration in IPv6 networks. SLAAC reduces the ability of an organisation to maintain effective logs of IP address assignment on the network. For this reason, stateless IP addressing should be avoided.

Once a transition to a dual-stack environment or completely to an IPv6 environment has been completed, reaccreditation will assist in ensuring that the associated security measures for IPv6 are working effectively.

Use of Simple Network Management Protocol

The Simple Network Management Protocol (SNMP) can be used to monitor the status of network devices such as switches, routers and wireless access points. The first two iterations of SNMP were inherently unsecure as they used trivial authentication methods. Furthermore, changing all default SNMP community strings on network devices and limiting access to read-only access is strongly encouraged.

Denial of service

A denial of service is designed to disrupt or degrade online services such as website, email and DNS services.

To conduct a denial of service, adversaries may use a number of approaches to deny access to legitimate users of online services such as:
• using multiple computers to launch a large volume of unwanted network traffic at online services in an attempt to consume all available network bandwidth
• using multiple computers to launch tailored traffic at online services in an attempt to consume the processing resources of online services
• hijacking online services in an attempt to redirect legitimate users away from those services to other services that the adversary controls.

Although it can be difficult to mitigate a denial of service entirely, there are a number of measures that can be implemented to prepare for and potentially reduce the impact if one occurs. Preparing for a denial of service before it occurs is by far the best strategy. It is very difficult to attempt to respond once they begin and efforts at this stage are unlikely to be effective.

Supporting information

Additional information on business continuity and disaster recovery can be found in the [i]Information Security Monitoring[/i] chapter while additional information on cloud service providers can be found in the [i]Outsourced Cloud Services[/i] section of the [i]Information Security Engagement[/i] chapter.

Determining essential online services

Service provider denial of service strategies

Domain name registrar locking

Establishing contact details with service providers

Monitoring with real-time alerting for online services

Segregation of critical online services

Multiple internet links

Cloud-based hosting of online services

Using content delivery networks

Denial of service mitigation services

Supporting information

Information covering wireless communications other than 802.11 Wi-Fi, such as 802.15 Bluetooth, can be found in the [i]Communications Systems and Devices[/i] chapter.

Additional information on implementing segregation using virtual local area networks can be found in the [i]Network Design and Configuration[/i] section of this chapter.

Additional information on encryption and key management requirements for wireless networks can be found in the [i]Cryptography[/i] chapter.

Additional information on implementing gateways can be found in the [i]Gateway Security[/i] chapter.

Wireless networks for public access

When an agency introduces a wireless network for public access, connecting such a wireless network to, or sharing infrastructure with, any network that communicates or stores sensitive or classified information creates an additional entry point for an adversary to target the connected network to steal sensitive or classified information or disrupt services.

Choosing wireless access points

Wireless access points that have been certified against a Wi-Fi Alliance certification program provide an agency with the assurance that they conform to wireless standards. Deploying wireless access points that are guaranteed to be interoperable with other wireless access points on a wireless network will prevent any problems on the wireless network. This is due to incompatibility of wireless standards supported or incorrect implementation of wireless standards by vendors.

Administrative interfaces for wireless access points

Administrative interfaces allow users to modify the configuration and security settings of wireless access points. Often wireless access points by default allow users to access the administrative interface over methods such as fixed network connections, wireless network connections and serial connections directly on the device. Disabling the administrative interface for wireless connections on wireless access points will assist in preventing unauthorised connections.

Default service set identifiers

All wireless access points come with a default Service Set Identifier (SSID). The SSID is commonly used to identify the name of a wireless network to users. As the default SSIDs of wireless access points are well documented on online forums, along with default accounts and passphrases, it is important to change the default SSID of wireless access points.

When changing the default SSID, it is important that the new SSID does not bring undue attention to an agency's wireless network. In doing so, the SSID of a wireless network should not be readily associated with an agency, the location of their premises, or the functionality of the wireless network.

A method commonly recommended to lower the profile of wireless networks is disabling SSID broadcasting. While this ensures that the existence of wireless networks are not broadcast overtly using beacon frames, the SSID is still broadcast in probe requests, probe responses, association requests and re-association requests for the wireless network. Some adversaries will still be able to determine the SSID of wireless networks by capturing these requests and responses. Additionally, by disabling SSID broadcasting agencies will make it more difficult for users to connect to wireless networks as legacy operating systems only have limited support for hidden SSIDs. Furthermore, a risk exists where an adversary could configure a wireless access point to broadcast the same SSID as the hidden SSID used by a legitimate wireless network.

In this scenario, devices will automatically connect to the wireless access point that is broadcasting the SSID they are configured to use before probing for a wireless access point that accepts the hidden SSID. Once the device is connected to the adversary's wireless access point, the adversary can steal authentication credentials from the device to perform a man-in-the-middle attack to capture legitimate wireless network traffic or to later reuse to gain access to the legitimate wireless network. For these reasons, it is recommended agencies enable SSID broadcasting.

Static addressing

Assigning static IP addresses for devices accessing wireless networks can prevent a rogue device when connecting to a wireless network from being assigned a routable IP address. However, some adversaries will be able to determine IP addresses of legitimate users and use this information to guess or spoof valid IP address ranges for wireless networks. Configuring devices to use static IP addresses introduces a management overhead without any tangible security benefit.

Media Access Control address filtering

Devices that connect to wireless networks have a unique Media Access Control (MAC) address. It is possible to use MAC address filtering on wireless access points to restrict which devices can connect to wireless networks. while this approach will introduce a management overhead of configuring whitelists of approved MAC addresses, it can prevent rogue devices from connecting to wireless networks. However, some adversaries will be able to determine valid MAC addresses of legitimate users already on wireless networks. Adversaries can then use this information to spoof valid MAC addresses and gain access to a wireless network. MAC address filtering introduces a management overhead without any real tangible security benefit.

802.1X authentication

When an agency chooses to deploy a secure wireless network, they can choose from a number of Extensible Authentication Protocol (EAP) methods that are supported by the Wi-Fi Protected Access 2 (WPA2) protocol. These EAP methods include WPA2-Enterprise with EAP-Transport Layer Security (EAP-TLS), WPA2-Enterprise with EAP-Tunnelled Transport Layer Security (EAP-TTLS) or WPA2-Enterprise with Protected EAP (PEAP).

WPA2-Enterprise with EAP-TLS is considered one of the most secure EAP methods. Due to its inclusion in the initial release of the WPA2 standard, it enjoys wide support in wireless access points and in numerous operating systems such as Microsoft Windows, Linux and Apple OS X. EAP-TLS uses a public key infrastructure (PKI) to secure communications between devices and a Remote Access Dial In User Service (RADIUS) server through the use of X.509 certificates. While EAP-TLS provides strong mutual authentication, it requires an agency to have established a PKI. This involves either deploying their own certificate authority and issuing certificates, or purchasing certificates from a commercial certificate authority, for every device that accesses the wireless network. While this introduces additional costs and management overheads to an agency, the security advantages are significant.

Evaluation of 802.1X authentication implementation

The security of 802.1X authentication is dependent on three main elements and how they interact with each other. These three elements include supplicants (clients) that support the 802.1X authentication protocol; authenticators (wireless access points) that facilitate communication between supplicants and the authentication server; and the authentication server (RADIUS server) that is used for authentication, authorisation and accounting purposes. To provide assurance that these elements have been implemented correctly, supplicants, authenticators and the authentication server must have completed an evaluation.

Issuing certificates for authentication

Certificates for authenticating to wireless networks can be issued to either or both devices and users. For assurance, certificates must be generated using a certificate authority product or hardware security module that has completed an evaluation.

When issuing certificates to devices accessing wireless networks, agencies need to be aware of the risk that these certificates could be stolen by malicious software. Once compromised, the certificate could be used on another device to gain unauthorised access to the wireless network. Agencies also need to be aware that in only issuing a certificate to a device, any actions taken by a user will only be attributable to the device and not a specific user.

When issuing certificates to users accessing wireless networks, they can either be in the form of a certificate that is stored on a device or a certificate that is stored within a smart card. Issuing certificates on smart cards provides increased security, but at a higher cost. This is because a user is more likely to notice a missing smart card and alert their local security team, who is then able to revoke the credentials on the RADIUS server. This can minimise the time an adversary has access to a wireless network. In addition, to reduce the likelihood of a stolen smart card from being used to gain unauthorised access to a wireless network, two-factor authentication can be implemented through the use of Personal Identification Numbers (PINs) on smart cards. This is particularly important when a smart card grants a user any form of administrative access on a wireless network or attached network resource.

For the highest level of security, unique certificates should be issued for both devices and users. In addition, the certificates for a device and user must not be stored on the same device. Finally, certificates for users accessing wireless networks should be issued on smart cards with access PINs and not stored with a device when not in use.

Using commercial certification authorities for certificate generation

A risk exists with EAP-TTLS and PEAP when a commercial certificate authority's certificates are automatically trusted by devices using vendor trusted certificate stores. This trust can be exploited by obtaining certificates from a commercial certificate authority under false pretences, as devices can be tricked into trusting their signed certificate. This will allow the capture of authentication credentials presented by devices, which in the case of EAPMSCHAPv2 can be cracked using a brute force attack granting not only network access but most likely Active Directory credentials as well. To reduce this risk, devices can be configured to validate the server certificate, disable any trust for certificates generated by commercial certificate authorities that are not trusted and disable the ability to prompt users to authorise new servers or commercial certificate authorities. Additionally, setting devices to enable identity privacy will prevent usernames being sent prior to being authenticated by the RADIUS server.

Caching 802.1X authentication outcomes

When 802.1X authentication is used, a shared secret key known as the Pairwise Master Key (PMK) is generated. Upon successful authentication of a device, the PMK is capable of being cached to assist with fast roaming between wireless access points. when a device roams away from a wireless access point that it has authenticated to, it will not need to perform a full re-authentication should it roam back while the cached PMK remains valid. To further assist with roaming, wireless access points can be configured to pre-authenticate a device to other neighbouring wireless access points that the device might roam to. Although requiring full authentication for a device each time it roams between wireless access points is ideal, agencies can chose to use PMK caching and pre-authentication if they have a business requirement for fast roaming. If PMK caching is used, the PMK caching period should not be set to greater than 1440 minutes (24 hours).

Remote Authentication Dial In User Service authentication

Separate to the 802.1X authentication process is the RADIUS authentication process that occurs between wireless access points and a RADIUS server. To protect authentication information communicated between wireless access points and a RADIUS server, communications must be encapsulated with an additional layer of encryption using an encryption product.

Encryption

As wireless transmissions are capable of radiating outside of secured areas, agencies cannot rely on the traditional approach of physical security to protect against unauthorised access to sensitive or classified information on wireless networks. Using the AES based Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) helps protect the confidentiality and integrity of all wireless network traffic.

CCMP was introduced in WPA2 to address feasible attacks against the Temporal Key Integrity Protocol (TKIP) used by the Wi-Fi Protected Access (WPA) protocol as well as the original wireless Encryption Protocol (WEP). An adversary looking to exploit vulnerabilities in TKIP and WEP can attempt to connect to wireless access points using one of these protocols. By default, wireless access points will attempt to accommodate this request by falling back to a legacy protocol that the device supports. Disabling or removing TKIP and WEP support from wireless access points ensures that wireless access points do not fall back to an insecure encryption protocol.

Interference between wireless networks

Where multiple wireless networks are deployed in close proximity, there is the potential for interference to impact on the availability of a wireless network, especially when operating on commonly used 802.11b/g (2.4GHz) default channels of 1 and 11. Sufficiently separating wireless networks through the use of frequency separation can help reduce this risk. This can be achieved by using wireless networks that are configured to operate on channels that minimise overlapping frequencies or by using both 802.11b/g (2.4GHz) channels and 802.11n (5GHz) channels. It is important to note though, if implementing a mix of 2.4GHz and 5GHz channels, not all devices may be compatible with 802.11n and able to connect to 5GHz channels.

Protecting management frames on wireless networks

An effective denial of service can be performed by exploiting unprotected management frames using inexpensive commercial hardware. The latest release of the 802.11 standard provides no protection for management frames and therefore does not prevent spoofing or denial of service. However, 802.11w was ratified in 2009 and specifically addresses the protection of management frames on wireless networks. As such, upgrading wireless access points to support the 802.11w amendment will address this risk.

Bridging networks

When connecting devices via Ethernet to an agency's fixed network, agencies need to be aware of the risks posed by active wireless functionality on devices. Devices will often automatically connect to any open wireless networks they have previously connected to, which an adversary can masquerade as and establish a connection to the device. This device could then be used as a bridge to access the agency's fixed network. Disabling wireless functionality on devices, preferably by a hardware switch, whenever connected to a fixed network can prevent this from occurring. Furthermore, disabling a device's ability to remember and automatically connect to open wireless networks will assist in reducing this risk.

Wireless network footprint

Minimising the output power of wireless access points will reduce the footprint of wireless networks. Instead of deploying a small number of wireless access points that broadcast on high power, it is recommended that more wireless access points that use minimal broadcast power be deployed to achieve the desired wireless network footprint. This has the added benefit of providing redundancy for a wireless network should a wireless access point become unserviceable. In such a case, the output power of other wireless access points can be increased to cover the footprint gap until the unserviceable wireless access point can be replaced.

An additional method to limit a wireless network's footprint is through the use of radio frequency shielding on an agency's premises. while expensive, this will limit the wireless communications to areas under the control of an agency. Radio frequency shielding on an agency's premises has the added benefit of preventing the jamming of wireless networks from outside of the premises in which wireless networks are operating.

Supporting information

Additional information on topics covered in this section can be found in the [i]Product Security[/i] chapter, the [i]Telephones and Telephone Systems[/i] section of the [i]Communications Systems and Devices[/i] chapter, the [i]Mobile Devices[/i] section of the [i]Working Off-Site[/i] chapter, the [i]Cross Domain Security[/i] chapter and any section relating to the protection of data networks in this manual.

Video and voice-aware firewall requirement

Where a video conferencing or IP telephony network is connected to another video conferencing or IP telephony network in a different security domain the [i]Gateways[/i] section of the [i]Cross Domain Security[/i] chapter applies.

Where an analog telephone network, such as the PSTN, is connected to a data network the [i]Gateways[/i] section of the [i]Cross Domain Security[/i] chapter does not apply.

Hardening video conferencing and IP telephony infrastructure

Video conferencing and IP telephony traffic in a data network consists of IP packets and should be treated the same as any other data. As such, hardening can be applied to video conferencing units, handsets, software, servers, firewalls and gateways.

For example, additional security could be added by using a Session Initiation Protocol (SIP) server that:
• has a fully patched operating system
• has fully patched software
• runs only required services
• uses encrypted non-replayable authentication
• applies network restrictions that only allow secure SIP traffic and secure Real-time Transport Protocol (RTP) traffic from video conferencing units and IP phones on a VLAN to reach the server.

Video and voice-aware firewalls

The use of video and voice-aware firewalls ensures that only video and voice traffic (e.g. signalling and data traffic) is allowed for a given call and that the session state is maintained throughout the transaction.

The requirement to use a video or voice-aware firewall does not necessarily require separate firewalls to be deployed for video conferencing, IP telephony and data traffic. If possible, organisations are encouraged to implement one firewall that is either video and data-aware; voice and data-aware; or video, voice and data-aware depending on their needs.

Protecting video conferencing and IP telephony traffic

Video conferencing and IP telephony traffic is vulnerable to eavesdropping but can be easily protected with encryption. This helps protect against denial of service, man-in-the-middle attacks and call spoofing attacks made possible by inherent weaknesses in the video conferencing and IP telephony protocols.

When protecting video conferencing and IP telephony traffic, voice control signalling can be protected using Transport Layer Security (TLS) and the ‘sips://’ identifier to force the encryption of all legs of the connection. Similar protections are available for RTP and the Real-time Control Protocol.

Establishment of secure signalling and data protocols

Use of secure signalling and data protocols protect against eavesdropping, some types of denial of service, man-in-the-middle attacks and call spoofing attacks.

Video conferencing unit and IP phone authentication

Blocking unauthorised or unauthenticated devices by default will reduce the risk of unauthorised access to a video conferencing or IP telephony network.

Local area network traffic separation

Video conferencing and IP telephony networks need to be logically or physically separated from data networks to ensure availability and sufficient quality of service.

Lobby and shared area phones

Lobby IP phones in public areas may give an adversary the opportunity to access the internal data network (depending on separation arrangements) by replacing the IP phone with another device, or installing a device in-line. Alternatively, the IP phone could be used for social engineering purposes (since the call may appear to be internal) or to access poorly protected voicemail boxes.

For further information on what constitutes a 'public area', refer to the [i]Physical security management guidelines - Security zones and risk mitigation control measures[/i] document, published by the Attorney-General’s Department.

Microphones and webcams

Microphones (including headsets and USB handsets) and webcams used with workstations can pose a risk in highly classified areas. An adversary can email a malicious application, or host a malicious application on a compromised website, and use social engineering techniques to convince users into installing the application on their workstation. Such malicious applications are often capable of remotely activating microphones or webcams that are attached to the workstation to act as remote listening and recording devices. In addition, when using webcams, users will need to take special care that webcams do not point towards any material that is classified higher than the workstation to which the webcam is connected. For example, a webcam connected to an Unclassified (DLM) workstation which points towards a whiteboard with PROTECTED information on it.

Developing a denial of service response plan

Telephony is considered a critical service for any organisation. A denial of service response plan will assist in responding to a video conferencing and IP telephony denial of service, signalling floods, and established call teardown and RTP data floods.

Resources and services that can be used to monitor for signs of a denial of service can include:
• router and switch logging and flow data
• packet captures
• proxy and call manager logs and access control lists
• video and voice-aware firewalls and gateways
• network redundancy
• load balancing
• PSTN failover.

Information on product security such as product selection, acquisition, installation and configuration can be found in the [i]Product Security[/i] chapter.

Detailed information on algorithms and protocols approved to protect sensitive or classified information can be found in the [i]ASD Approved Cryptographic Algorithms[/i] and [i]ASD Approved Cryptographic Protocols[/i] sections of this chapter.

Purpose of cryptography

The purpose of cryptography is to provide confidentiality, integrity, authentication and nonrepudiation of information.

Confidentiality is one of the most common cryptographic functions, with encryption providing protection to information by making it unreadable to all but authorised users.

Integrity is concerned with protecting information from accidental or deliberate manipulation. It provides assurance that the information has not been modified.

Authentication is the process of ensuring that a person or entity is who they claim to be. A robust authentication system is essential for protecting access to systems.

Non-repudiation provides proof that a user performed an action, such as sending a message, and prevents them from denying that they did so.

Using approved encryption generally reduces the likelihood of an unauthorised party gaining access to the encrypted information. However, it does not reduce the consequences of a successful intrusion.

With regard to encryption systems that do not encrypt the entire media content, care needs to be taken to ensure that either all of the data is encrypted or that the media is handled in accordance with the sensitivity or classification of the unencrypted data.

Using encryption

Encryption of data at rest can be used to reduce the physical storage and handling requirements for media or systems containing sensitive or classified information to an unclassified level.

Encryption of data in transit can be used to provide protection for sensitive or classified information being communicated over public network infrastructure.

When agencies use encryption for data at rest, or in transit, they are not reducing the sensitivity or classification of the information. However, because the information is encrypted, the consequences of the encrypted information being accessed by unauthorised parties are considered to be less. Therefore, the security requirements applied to the encrypted information can be reduced. As the sensitivity or classification of the unencrypted information does not change, additional layers of encryption cannot be used to further lower the security requirements.

Product specific cryptographic requirements

This section describes the use of cryptography to protect sensitive or classified information. Additional requirements can exist in consumer guides for products once they have completed an ASD Cryptographic Evaluation (ACE). Such requirements supplement this manual and where conflict occur the product-specific requirements take precedence.

Federal Information Processing Standard 140

The Federal Information Processing Standard (FIPS) 140 is a United States standard for the validation of both hardware and software cryptographic modules.

FIPS 140 is in its second iteration and is formally referred to as FIPS 140–2. This section refers to the standard as FIPS 140, but it applies to FIPS 140–1 and FIPS 140–2, as well as the third iteration, FIPS 140–3, which has been released in a draft version.

FIPS 140 is not a substitute for an ACE. FIPS 140 is concerned solely with the cryptographic functionality of a module and does not consider any other security functionality.

Cryptographic evaluations of products will normally be conducted by ASD. Where a product’s cryptographic functionality has been validated under FIPS 140, ASD can, at its discretion, and in consultation with the vendor, reduce the scope of an ACE.

High Assurance Cryptographic Equipment

High Assurance Cryptographic Equipment (HACE) is used by government agencies to protect highly classified information. HACE is designed to lower the handling requirements of highly classified information using cryptography. Due to the sensitive nature of this equipment, agencies should contact ASD before using these devices.

Reducing storage and physical transfer requirements

When encryption is applied to information, it provides an additional layer of defence. Encryption does not change the sensitivity or classification of the information, but when encryption is used, the storage and physical transfer requirements of the ICT equipment or media may be reduced to a lower classification level.

Encrypting information at rest

Full disk encryption provides a greater level of protection than file-based encryption. While file-based encryption may encrypt individual files there is the possibility that unencrypted copies of the file may be left in temporary locations used by the operating system.

Encrypting particularly sensitive information at rest

Due to the sensitivities associated with AUSTEO and AGAO information, this information needs to be encrypted when at rest.

Data recovery

The requirement for an encryption product to provide a key escrow function, where practical, was issued under a Cabinet directive in July 1998.

Handling encrypted ICT equipment

When a user authenticates to ICT equipment employing encryption functionality, all information becomes accessible. At such a time, the ICT equipment will need to be handled according to the sensitivity or classification of the information it processes, stores or communicates.

Reducing network infrastructure requirements

Where no security can be applied to the network infrastructure, for example where information is transmitted over public network infrastructure, encryption of sensitive or classified information is the only mechanism to prevent the information being compromised.

In some cases, agencies may have a business requirement to send unclassified but sensitive, official government information to stakeholders over public network infrastructure without applying encryption. Unencrypted information sent over the internet should be considered unprotected and uncontrolled. Agencies need to understand and accept this risk if considering non-compliance with the below controls due to their business needs.

Encrypting particularly sensitive information in transit

Due to the sensitivities associated with AUSTEO and AGAO information, it needs to be encrypted when being communicated across network infrastructure.

Implementations of the algorithms in this section need to undergo an ACE before they can be approved to protect classified information.

High Assurance cryptographic algorithms, which are not covered in this section, can be used for the protection of classified information if they are suitably implemented in a product that has undergone a High Assurance evaluation by ASD. Further information on High Assurance algorithms can be obtained by contacting ASD.

AACAs

There is no guarantee of an algorithm’s resistance against currently unknown attacks. However, the algorithms listed in this section have been extensively scrutinised by industry and academic communities in a practical and theoretical setting and have not been found to be susceptible to any feasible attack. There have been some cases where theoretically impressive vulnerabilities have been found; however, these results are not of practical application.

AACAs fall into three categories: asymmetric/public key algorithms, hashing algorithms and symmetric encryption algorithms.

The approved asymmetric/public key algorithms are:
• Diffie-Hellman (DH) for agreeing on encryption session keys
• Digital Signature Algorithm (DSA) for digital signatures
• Elliptic Curve Diffie-Hellman (ECDH) for agreeing on encryption session keys
• Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signatures
• Rivest-Shamir-Adleman (RSA) for digital signatures and passing encryption session keys or similar keys.

The approved hashing algorithm is:
• Secure Hashing Algorithm 2 (SHA-224, SHA-256, SHA-384 and SHA-512).

The approved symmetric encryption algorithms are:
• AES using key lengths of 128, 192 and 256 bits
• Triple Data Encryption Standard (3DES) using three distinct keys.

Where there is a range of possible key sizes for an algorithm, some of the smaller key sizes do not provide an adequate safety margin against intrusion methods that might be found in the future. For example, future advances in integer factorisation methods could render smaller RSA moduli vulnerable to feasible attacks.

Suite B

In late 2015, The Committee on National Security Systems released advice (CNSSAM 02-15) on changes to the Suite B algorithms which are approved for use in US National Security Systems (NSS). These changes are intended to assist industry partners in their shift towards post-quantum security, while taking into account the practical considerations of architectural changes.

Suite B consisted of the following algorithms:
• Encryption AES
• Hashing: SHA-2
• Digital Signature: ECDSA
• Key Exchange: ECDH

CNSSAM 02-15 made the following changes in its advice for protecting information up to TOP SECRET in NSS:
• Encryption: AES-256
• Hashing: SHA-384
• Digital Signature: ECDSA (P-384) and/or RSA (3072-bit or larger)
• Key Exchange: Diffie-Hellman (3072-bit or larger) and/or ECDH (P-384) and/or RSA (3072-bit or larger).

Both the Suite B and CNSSAM 02-15 algorithms fall within the set of ASD Approved Cryptographic Algorithms (AACAs), and evaluated configurations are hence suitable for use in Australian Government. For UNCLASSIFIED//DLM and PROTECTED systems, no changes to compliant systems are advised as a result of CNSSAM 02-15.

Agencies are advised to consider the impacts to their systems of a feasible quantum computer, and any resultant architectural changes which may be required. Such changes might include increased key sizes or altered key exchange algorithms. Systems transmitting and/or storing CONFIDENTIAL, SECRET and/or TOP SECRET information are advised to consult ASD for advice on post-quantum security.

Using AACAs

If a product implements unapproved algorithms as well as AACAs, it is possible that these unapproved algorithms could be configured without the user’s knowledge. In combination with an assumed level of security confidence, this can represent a significant level of security risk.

When configuring products that implement an AACA, agencies can ensure that only the AACA can be used by either disabling the unapproved algorithms (which is preferred) or advising users not to use the unapproved algorithms via a policy.

Approved asymmetric/public key algorithms

Over the last decade, DSA and DH cryptosystems have been subject to increasingly successful sub-exponential index-calculus based attacks. ECDH and ECDSA offer more security per bit increase in key size than either DH or DSA and are considered more secure alternatives.

Using Diffie-Hellman

A 1024-bit modulus for DH is no longer considered appropriate within the cryptographic community. The modulus for DH should be at least 2048 bits.

Using the Digital Signature Algorithm

A 1024-bit modulus for DSA is no longer considered appropriate within the cryptographic community. The modulus for DSA should be at least 2048 bits.

Using Elliptic Curve Cryptography

The curve used within an elliptic curve algorithm can affect the security of the algorithm. Only approved curves may be used.

Using Elliptic Curve Diffie-Hellman

A field/key size of at least 160 bits for ECDH is considered best practice by the cryptographic community.

Using the Elliptic Curve Digital Signature Algorithm

A field/key size of at least 160 bits for ECDSA is considered best practice by the cryptographic community.

Using Rivest-Shamir-Adleman

A 1024-bit modulus for RSA is no longer considered appropriate within the cryptographic community. The modulus for RSA should be at least 2048 bits.

Approved hashing algorithms

Research conducted by the cryptographic community has shown that SHA-1 is susceptible to collision attacks. In 2017, cryptographic researchers demonstrated a SHA-1 collision with PDF files. A hashing algorithm from the SHA-2 family should be used instead of SHA-1.

Approved symmetric encryption algorithms

The use of Electronic Code Book mode in block ciphers allows repeated patterns in plaintext to appear as repeated patterns in the ciphertext. Most plaintext, including written language and formatted files, contains significant repeated patterns. A malicious actor can use this to deduce possible meanings of ciphertext by comparison with previously intercepted data. The use of other modes such as Cipher Block Chaining, Cipher Feedback, Output Feedback or Counter prevents such attacks.

Using the Triple Data Encryption Standard

Using three distinct keys is deemed the only secure option for practical purposes. All other keying options are susceptible to attacks that reduce the security of 3DES and are therefore not deemed secure for practical purposes. Where practical, agencies should use an approved implementation of AES, instead of 3DES.

Protecting highly classified information

Suite B is a set of public domain cryptographic algorithms which have been approved by ASD for use in specific configurations and evaluated implementations for the protection of CONFIDENTIAL, SECRET and TOP SECRET information. CNSSAM 02-15 advised of changes to some of these algorithms, and agencies are advised to give preference to these algorithms over the older Suite B algorithms.