Purpose of the Australian Government Information Security Manual

The purpose of this manual is to assist Australian government agencies in applying a risk-based approach to protecting their information and systems. While there are other standards and guidelines designed to protect information systems, the advice in this manual is specifically based on activity observed by the Defence Signals Directorate (DSD) on Australian government networks. The security controls are therefore designed to mitigate the most significant threats to Australian government agencies.

Applicability

This manual applies to:
• Australian government agencies that are subject to the Financial Management and Accountability Act 1997
• bodies that are subject to the Commonwealth Authorities and Companies Act 1997 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 hold or accessfederal sensitive or classified information
• organisations that have entered a Deed of Agreement with the government to have access to sensitive or classified information.

DSD encourages Australian government agencies, whether Commonwealth, state or territory, which do not fall within this list to apply the considered advice contained within this manual when selecting security controls on a case-by-case basis.

Authority

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

This manual represents the considered advice of DSD 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 over-ride 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 enquiries in that regard.

Public systems

Agencies deploying public systems can determine their own security measures based on their business needs, risk appetite and security risks to their systems. However, DSD encourages such agencies to use this manual, particularly the objectives, as a guide when determining security measures for their systems.

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

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

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

The Controls Manual is aimed at Information Technology Security Advisors, Information Technology Security Managers, infosec-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.

DSD 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 products 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 DSD may take precedence over the platform non-specific advice in this manual.

Framework

This manual uses a framework to present information in a consistent manner. The framework consists of a number of headings in each section:
• [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
• [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. The applicability indicator has up to five elements, indicating whether the control applies to:
• G: Baseline security controls advised for Australian government systems holding information which requires some level of protection. Applicable to government systems containing unclassified but sensitive or official information not intended for public release, such as Dissemination Limiting Marker information Unclassified (DLM) systems). Unclassified (DLM) and 'Government' are not classifications 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.

DSD maintains a System Controls Checklist to facilitate the incorporation of ISM advice into agencies' risk assessments.

Taking a risk-based approach to Information Security

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

It is a mandatory requirement of the Australian Government Protective Security Policy Framework that agencies adopt a risk management approach to cover all areas of protective security activity across their organisation. DSD recommends information security forms a part of an agency's broader risk management processes.

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

Applicability of controls

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

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

This section should be read in conjunction with Security Risk Management Plans in 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

Risk can be identified and analysed in terms of:
• What could happen? How could resources and activities central to the operation of an agency be affected?
• How would it happen? What weaknesses could be exploited to make this happen? What security controls are already in place? Are they adequate?
• How likely is it to happen? Is there opportunity and intent? How frequent is it likely to be?
• What would the consequence be? What possible effect could it have on an agency's operations, services or credibility?

Evaluating and treating information security risks

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

This decision can be made by balancing the risk against an agency's business needs and risk appetite, for example:
• What equipment and functionality is necessary for your agency to operate?
• Will the risk mitigation strategies affect your agency's ability to perform its core duties?
• What are the resource constraints 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 security controls included in this manual provide strategies of how 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 agency 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 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 three possible approvers:
• DSD: Director DSD
• AH: agency head
• AA: accreditation authority.

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. While the majority of controls can be risk managed within an agency, the compliance requirements provide an indication of the appropriate level within the agency where any residual security risks must be accepted in order to grant non-compliance. The full implications need to be considered before granting non-compliance with a control.

The use of 'must' and 'should' for controls are based on incident reporting received by DSD's Cyber Security Operations Centre (CSOC) and what DSD assesses the risk level to be. Agencies may have a differing risk environment and requirements, and may have other mitigations in place to reduce the residual risk to an acceptable level.

Non-compliance with multiple controls

When an agency is non-compliant with multiple controls, they may choose to logically group the areas of non-compliance when following the processes for non-compliance.

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 are capable of being audited for compliance by the Australian National Audit Office (ANAO).

Complying with the Australian Government Information Security Manual

By using the latest baseline of this manual for system design activities, agencies will be taking steps to protect themselves from the current threats to Australian government systems.

DSD 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 government information and systems, and accordingly may take precedence over the platform non-specific advice 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. Therefore, the agency head, in association with the accreditation authority, is required to consider the justification for non-compliance and accept the associated residual security risk. Non-compliance with controls relating to High Grade Cryptographic Equipment must be granted by the Director DSD. These controls are marked accordingly in this manual.

Non-compliance with 'should' and 'should not' controls are likely to represent a medium-to-low security risk to information and systems. As the risk for non-compliance is not as high as those with a 'must' and 'must not' compliance requirement, the accreditation authority can consider the justification for non-compliance and accept the associated residual security risk without the input of the agency head.

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 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 by the Cyber Security Operations Centre (CSOC)
• 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 Australian National Audit Office (ANAO). Failing to maintain such records is also a breach of the Archives Act 1983 (the Archives Act).

DSD

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

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

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

DSD can be contacted for advice and assistance on implementing this manual through agency Information Technology Security Managers (ITSMs) or Information Technology Security Advisors (ITSAs). ITSMs and ITSAs can send questions to DSD by email at dsd.assist@defence.gov.au or phone on 1300 CYBER1 (1300 292 371).

DSD can be contacted for advice and assistance on cyber security incidents. DSD's response will be commensurate with the urgency of the cyber security incident. Urgent and operational enquiries can be submitted through DSD's OnSecure website or by phoning 1300 CYBER1 (1300 292 371) and selecting 1 at any time. Non-urgent and general enquiries can be submitted through the OnSecure website, by phoning 1300 CYBER1 (1300 292 371) and selecting 2 at any time or emailing the Cyber Security Operations Centre at dsd.assist@defence.gov.au. DSD's incident response service is available 24 hours, 7 days a week.

DSD can be contacted for advice and assistance on the purchasing, provision, deployment, operation and disposal of HGCE. The Cryptographic Services Liaison section can also be contacted by email at dsd.assist@ defence.gov.au.

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.

Cloud computing

Cloud computing is a form of outsourcing information technology services and functions over the Internet. The requirements in this section equally apply to providers of cloud computing services. However, due to the Internet-connected nature of cloud computing, additional information security issues need to be considered. DSD's Cloud Computing Security Considerations document provides guidance for agencies considering implementing a cloud solution.

Accrediting service providers' systems

Service providers can be provided with information as long as their systems are accredited to process, store and communicate the information. This ensures that when they are provided with information that it receives an appropriate level of protection.

Service providers' systems

Outsourcing can be a cost-effective option for providing information technology services and functions in an agency, as well as potentially delivering a superior service. However, it can also affect an agency's risk profile and control over its threat environment. Storing data in multiple disparate locations and allowing more people to access agency information can significantly increase the potential for network infection and information loss or compromise.

DSD recommends against outsourcing information technology services and functions outside of Australia, unless agencies are handling data considered publicly available. DSD strongly encourages agencies to choose a vendor (either locally or foreign owned) that is located in Australia and stores, processes and manages sensitive data only within Australian borders. The risk of a malicious actor accessing agency information greatly increases if the information is stored or transmitted outside Australian borders. Agencies should also be aware that foreign owned vendors operating in Australia may be subject to foreign laws such as a foreign government's lawful access to data held by the vendor.

Cloud Computing

There is a variety of information security risks that need to be considered when engaging cloud computing providers. Data stored in cloud infrastructure is vulnerable to malicious cyber activity, due to the Internet- connected nature of cloud computing. Moreover, the physical data storage location - and the people responsible - will not necessarily be known to the agency. This diminishes agency control over threat mitigation and response and increases the threat from malicious insiders. Risks will vary depending on the sensitivity of agency data to be stored and processed and how the chosen cloud vendor has implemented their specific cloud services.

Service providers' ITSM

When an agency engages a service provider for the provision of information technology services and functions, having a central point of contact for information security issues will greatly assist incident response and reporting procedures.

Developing an industry engagement plan

Developing an information security industry security engagement plan will help ensure an agency has a clear and coordinated approach when engaging and using service providers for outsourcing and provision of information technology services and functions.

The Security Executive and their Chief Information Security Officer role

The requirement to appoint a member of the Senior Executive Service, or in an equivalent management position, to the role of CISO does not require a new dedicated position to be created in each agency. This role is intended to be performed by the Security Executive, which is a position in each agency mandated by the Australian Government Protective Security Policy Framework. The introduction of the CISO role is aimed at providing a more meaningful title for a subset of the Security Executive's responsibilities that relate to information security.

Requirement for a Chief Information Security Officer

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, Information and Communications Technology (ICT) personnel and business personnel to ensure alignment of business and security objectives
• providing strategic-level guidance for the agency security program
• ensuring compliance with national policy, standards, regulations and legislation.

The ITSA

The ITSM who has responsibility for information technology security management across the agency is designated as the ITSA. This title reflects the responsibility this ITSM has as the first point of contact for the CISO, or equivalent, and external agencies on any information technology security management issues.

Information on the responsibilities of ITSMs can be found in the Information Technology Security Managers section of this chapter.

Requirement for an ITSA

An ITSM, when fulfilling the designation of ITSA, still maintains full responsibilities for their role as an ITSM in addition to ITSA responsibilities. An ITSA traditionally has the added responsibility of coordinating other ITSMs to ensure that security measures and efforts are undertaken in a coordinated manner.

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 that of 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 audit failures
• guiding the selection of appropriate strategies to achieve the direction set by the CISO or equivalent with respect to disaster recovery policies and standards
• delivering information security awareness and training programs to personnel.

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 whose responsibility is to ensure the technical security of systems is essential to manage compliance and non-compliance with the controls in this manual. The main responsibility of ITSOs is the implementation and monitoring of technical security measures for systems. Other responsibilities often include:
• conducting vulnerability assessments and taking actions to mitigate threats and remediate vulnerabilities
• working with ITSMs to respond to cyber security incidents
• assisting ITSMs with technical remediation activities required as a result of audits
• assisting in the selection of security measures to achieve the strategies selected by ITSMs with respect to disaster recovery
• raising awareness of information security issues with system owners and personnel.

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 Australian Government Information Security Management Protocol.

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

More detailed information about each document can be found in the relevant sections of this chapter.

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) is derived from this manual and the SRMP and describes the implementation and operation of controls for a system. Depending on the documentation framework chosen, some details common to multiple systems could be consolidated in a higher level SSP.

Standard Operating Procedures

Standard Operating Procedures (SOPs) provide a step-by-step guide to undertaking security related tasks. They provide assurance that tasks can be undertaken in a repeatable manner, even by users without strong knowledge of the system. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.

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 the most useful and accurate information security documentation will be developed by personnel who are knowledgeable about both information security issues and the business requirements.

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

If stakeholders are not made aware of new information security documentation, or changes to existing information security documentation, they will not know about any changes they may need to make to the security measures for their systems.

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 Australian Government Information Security Management Protocol.

Information about other mandatory documentation can be found in the Documentation Fundamentals 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 Australian Government Information Security Management Protocol.

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

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

Contents of an 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 an 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

For security risk management to be of true value to an agency it should relate to the specific circumstances of an agency and its systems, as well as being based on an industry recognised approach to risk management, such as those produced by Standards Australia and the International Organization for Standardization (ISO) / International Electrotechnical Commission (IEC).

Standards Australia produces AS/NZS ISO 31000:2009, Risk Management - Principles and guidelines while the ISO/IEC has developed the risk management standard ISO/IEC 27005:2011, Information technology - Security techniques - Information security risk management, as part of the ISO/IEC 27000 family of standards.

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

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

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

Stakeholders

There can be many stakeholders involved in defining an 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 an SSP

This manual provides a list of controls that are potentially applicable to a system based on its classification, its functionality and the technology it is implementing. Agencies need to determine which controls are in scope of the system and translate those controls to the SSP. These controls will then be assessed on their implementation and effectiveness during the accreditation process for the system.

In performing accreditations against the latest baseline of this manual, agencies are ensuring that they are taking the most recent threat environment into consideration. DSD 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.

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

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

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.

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

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

Contents of an IRP

The guidance provided on the content 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 Australian Government Information Security Management Protocol.

Information about other mandatory documentation can be found in the Documentation Fundamentals 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 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 Ensuring Service Continuity section of the Network Security 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.

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.

Disaster recovery plans

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

Accreditation is the process by which the accreditation authority formally recognises and accepts the residual security risk to a system and the information it processes, stores and communicates.

The accreditation framework comprises three layers:

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

Accreditation framework

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

Accreditation

Accreditation of a system ensures that either sufficient security measures have been put in place or that deficiencies in such measures have been accepted by an appropriate authority. When systems are awarded accreditation the accreditation authority accepts that the residual security risks are appropriate for the sensitivity or classification of the information that the system processes, stores or communicates.

Monitoring the accredited systems will assist in assessing changes to the environment and operation and to determine the implications for the security risk profile and accreditation status of the system.

Determining authorities

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

Notifying authorities

In advising the certification and accreditation authorities of their intent to seek certification and accreditation for a system, the system owner can seek information on the latest processes and requirements for their system.

The list of accreditation and certification authorities is given in the Conducting Accreditations and Conducting Certifications sections of this chapter.

Due diligence

When an agency is connecting to a system not under their control or passing information to another party, the agency needs to be aware of the security measures that have been implemented to protect the agency's information. More importantly, the agency needs to accept the security risks associated with non-compliance with controls in this manual by the other party before connecting or passing information to them. The security risks include the system potentially being used as a platform to launch an intrusion on the agency's system or spilling information onto a system not under their control and requiring subsequent clean up of the spilled information.

Methods that an agency may use to ensure compliance with security requirements, and to assist in security risks being identified and accepted by the agency, include:
• conducting an accreditation of the non-agency system
• having an information security review performed by an infosec-registered assessor on the non-agency system
• reviewing a copy of an existing certification report for the non-agency system in order to make an accreditation decision on the non-agency system.

Processing restrictions

When security is applied to systems, security measures are put in place based on the sensitivity or classification of information that will be processed, stored or communicated by the system. If information is placed on a system, and its sensitivity or classification is higher than the level of accreditation for the system, the information will be inadequately protected and will be exposed to a greater risk of compromise.

Accrediting systems bearing a caveat or compartment

When processing caveated or compartmented information on a system, agencies need to ensure that the system has received accreditation for the caveated or compartmented information.

Requirement for Australian control

As Australian Eyes Only (AUSTEO) and Australian Government Access Only (AGAO) systems process, store and communicate information that is particularly sensitive to the government of Australia, it is essential that control of such systems is maintained by Australian citizens working for the government of Australia.

Reaccreditation

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

Agencies may have an additional year's grace if they follow the procedures defined in this manual for non- compliance with 'should' requirements: that is, providing a suitable justification, conducting a security risk assessment and obtaining formal approval from the accreditation authority.

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

Other reasons an agency could seek reaccreditation include:
• changes in information security policies
• detection of new or emerging threats to systems
• the discovery that controls are not operating as effectively as planned
• a major cyber security incident
• changes to the system or the security risk profile.

Accreditation aim

The aim of accreditation is to formally recognise and accept the residual security risk to a system and the information it processes, stores or communicates.

Accreditation authorities

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

For TOP SECRET systems the accreditation authority is DSD.

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

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

For gateway services of commercial providers the accreditation authority is the agency head or their delegate, which is strongly recommended to be the CISO or equivalent.

For commercial providers supporting agencies the accreditation authority is the head of the supported agency or their authorised delegate, which is strongly recommended to be the CISO or equivalent.

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

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

Accreditation outcomes

Accreditation is awarded when the accreditation authority accepts the residual security risk relating to the operation of the system and gives formal approval for the system to operate. However, in some cases the accreditation authority may not accept the residual security risk relating to the operation of the system. This is predominantly due to security risks being insufficiently considered and documented in the SRMP, resulting in security measures being inaccurately scoped in the SSP. In such cases the accreditation authority may request that the SRMP and SSP be amended and security measures reassessed before reconsidering the system for accreditation.

In awarding accreditation for a system, the accreditation authority may specify a shorter period before reaccreditation than that specified in this manual. The accreditation authority may also place restrictions on the use of the system which must be enforced until reaccreditation takes place or until required changes are made to the system.

Accreditation process

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

Certification

Certification (described in the Conducting Certifications section of this chapter) provides the accreditation authority with information on the security posture of a system. This allows the accreditation authority to make an informed decision on whether the residual security risk of allowing the system to operate is acceptable.

Accreditation decision

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.

Certification aim

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

Certification outcome

The outcome of certification is a certificate to the system owner acknowledging that the system has been appropriately audited and that the controls identified by the system owner have been implemented effectively.

Certification authorities

For TOP SECRET systems the certification authority is DSD.

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

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

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

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

For commercial providers supporting agencies the certification authority is the ITSA of the agency sponsoring the organisation.

Audit

The aim of an audit is to assess the actual implementation and effectiveness of controls for a system. The process of conducting an audit is described in the Conducting Audits section of this chapter.

Certification decision

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

Assessment of residual security risks

Before the certification authority can make a recommendation to the accreditation authority, an assessment of the residual security risk must be done. The purpose of the assessment is to assess the residual security risk relating to the operation of a system following the audit.

Even if, after the audit, the system does not conform, the certification authority may be able to recommend to the accreditation authority that accreditation be awarded. For example, since the audit, the system owner may have taken corrective actions to address areas of non-compliance, or the residual security risk may not be great enough to preclude accreditation.

Certification of gateway services

Commercial providers of gateway services may be used by multiple agencies across government, agencies must ensure gateway services of commercial providers have undergone an audit conducted by an infosec-registered assessor and received certification from DSD. Even though DSD may certify a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.

Audit aim

The aim of an audit is to review the system architecture (including the information security documentation) and assess the actual implementation and effectiveness of controls for a system.

Audit outcome

The outcome of an audit is a report to the certification authority describing areas of compliance and non-compliance for a system and any suggested remediation actions.

Who can conduct an audit

Audits for TOP SECRET systems can only be undertaken by DSD and infosec-registered assessors.

Audits for SECRET and below systems can be undertaken by agency ITSMs and infosec-registered assessors.

Who can assist with an audit

A number of agencies and personnel are often consulted during an audit.

Agencies or personnel who can be consulted on physical security aspects of information security 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 be consulted on physical and personnel security aspects of information security.

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

Independent audits

An audit can be conducted by agency assessors; however, the agency may choose to add an extra level of objectivity by engaging the services of an infosec-registered assessor to undertake the audit.

Connections to certain inter-agency systems could require an independent audit from an infosec-registered assessor as a prerequisite to certification of the system. Such requirements can be obtained from the inter-agency system owners.

Independence of assessors

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

Audit preparation

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

Audit (first stage)

The purpose of the first stage of the audit is to determine that the system architecture (including information security documentation) is based on sound security principles and has addressed all applicable controls from this manual. During this stage, the statement of applicability for the system will also be assessed along with any justification for non-compliance with applicable controls from this manual.

Implementing controls

Without implementing the controls for a system, their effectiveness cannot be assessed during the second stage of the audit.

Audit (second stage)

The purpose of the second stage of the audit is to determine whether the controls, as approved by the system owner and reviewed during the first stage of the audit, have been implemented and are operating effectively.

Report of compliance

The report of compliance helps the certification authority assess the residual security risk relating to the operation of a system following the audit and any remediation activities the system owner may have undertaken.

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

Agencies should maintain vulnerability management activities such as regular vulnerability assessments, analysis and mitigation 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. Where possible, system managers should 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 either:
• as a result of a specific cyber security incident
• after a change to a system or its environment that significantly impacts on the agreed and implemented system architecture and information security policy
• as part of a regular scheduled assessment.

Agencies will find it useful to gather appropriate information before they start a vulnerability assessment. This will help to ensure that the assessment is undertaken to a degree that is commensurate with the threat environment, and if applicable, the sensitivity or classification of information that is involved.

Depending on the scope and subject of the vulnerability assessment, agencies may gather information on areas such as:
• agency priorities, risk appetite and business requirements
• system functional and security requirements
• risk assessments, including threat data, likelihood and consequence estimates, and existing controls in place
• effectiveness of existing controls
• other possible controls
• vendor and other security best practices.

Vulnerability assessments can consist of:
• conducting documentation-based security reviews of systems' designs before they are implemented
• detailed manual testing to provide a detailed, in-depth assessment of a system once implemented
• supplementing manual testing with automated tools to perform routine, repeatable security testing. These tools should be from a reputable and trusted source.

Analysing and mitigating vulnerabilities

Agencies are encouraged to monitor information about new vulnerabilities that could affect their systems. However, they should not be complacent if no vulnerabilities are disclosed in specific products used in their systems.

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

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

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

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

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

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
• 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 either:
• 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 impacts 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: Intrusion Detection and Prevention.

Preventing and detecting cyber security incidents

The activities listed for assisting in detecting cyber security incidents will assist in mitigating the most common methods used to exploit systems.

Many potential cyber security incidents are noticed by personnel rather than software tools. However, for this to happen, personnel must be well trained and aware of information security issues and know how to recognise possible cyber security incidents.

Automated tools are only as good as the quality of the analysis they provide. If tools are not adequately configured to assess potential security risks, it will not be evident when a weakness emerges. Additionally, if the tools are not regularly updated to include knowledge of new vulnerabilities their effectiveness will be reduced.

Agencies may consider some of the tools described in the following table for detecting potential cyber security incidents.

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 should be reported to DSD.

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 DSD if necessary.

Reporting cyber security incidents to DSD

DSD uses cyber security incident reports as the basis for identifying and responding to cyber security events across government. Cyber security incident reports can also be used for developing new policies, procedures, techniques and training measures to prevent the recurrence of similar cyber security incidents across government. Agencies are recommended to coordinate their reporting of cyber security incidents to DSD 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 DSD. 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 DSD by the service provider.

Reporting cyber security incidents to DSD

Reporting cyber security incidents to DSD through the appropriate channels ensures that appropriate and timely assistance can be provided. In addition, it allows DSD to maintain an accurate threat environment picture for government systems through the Cyber Security Incident Reporting scheme.

Outsourcing and cyber security incidents

When an agency outsources information technology services and functions, they are still responsible for the reporting of cyber security incidents. The agency must ensure that the service provider informs them of all cyber security incidents to allow them to formally report these to DSD.

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 grade cryptographic keying material

ACSI 107 applies to all agencies including contractors. Its requirements cover all HGCE used to process classified information.

For cyber security incidents involving the suspected loss or compromise of HGCE keying material, DSD will investigate the possibility of compromise and, where possible, initiate action to reduce the impact of the compromise.

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

Assuming that information is compromised as a result of a cyber security incident allows an agency to apply procedures in response to a worst case scenario.

Containing data spills

The spillage of information onto a system not accredited to handle it is considered a cyber security incident under the DSD 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.

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, this includes maintaining metadata about the information, who used it, and how it was used. Even though in most cases an investigation does not directly lead to a police prosecution, it is important that the integrity of evidence such as manual logs, automatic audit trails and intrusion detection tool outputs be protected.

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

Seeking assistance

If the integrity of evidence of a cyber security incident is compromised, it reduces DSD's ability to assist agencies. DSD therefore requests that no actions which could affect the integrity of the evidence be carried out before DSD'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, and ensure mitigations put in place are effective.

Information on servers, network devices, ICT equipment and media can be found in other sections of this chapter. Information on encryption requirements can be found in the Cryptographic Fundamentals section of the Cryptography chapter.

Facilities

In the context of this manual a facility is an area that facilitates government business. For example, a facility can be a building, a floor of a building or a designated space on the floor of a building.

Physical security certification authorities

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

For facilities that process or store caveated or compartmented information there may be a certification authority external to the agency operating the facility.

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

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

For commercial providers supporting agencies the certification authority is the ASA of the agency sponsoring the organisation.

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 those with the appropriate authorisation to access the system and infrastructure.

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

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

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). They must ensure information is encrypted to a sufficient level that if it was captured it would not be cost-effective to retrieve the original information.

Preventing observation by unauthorised people

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

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

Server and communications rooms

Agencies must certify and accredit the physical security of a facility and server or communications room against the requirements in the Australian Government Physical Security Management Protocol. In such cases, because of the additional layer of security described in this manual, the requirements for physical storage of server and communications equipment in the Australian Government Physical Security Management Protocol can be lowered according to the Physical security of ICT equipment systems and facilities guideline.

Controlling physical access to network devices

Adequate physical protection must be provided to network devices, especially those in public areas, to prevent a malicious actor physically damaging a network device in order to cause a denial of service to a network.

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

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

Securing server rooms, communications rooms and security containers

If personnel leave server rooms, communications rooms and security containers or rooms unlocked, with keys in the locks or with security functions disabled, it negates the purpose of providing security. Such activities will compromise the security efforts and must not be permitted.

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

Additional information relating to ICT equipment and media can be found in the Fax Machines and Multifunction Devices section of the Communications Systems and Devices chapter as well as in the Product Security and Media Security chapters. Sanitisation information can be found in the Media Sanitisation section of the Media Security chapters. Information on the encryption of media can be found in the Cryptographic 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 Australian Government Physical Security Management Protocol.

The physical security requirements of the Australian Government Physical Security Management Protocol can be achieved by:
• ensuring ICT equipment and media always resides in an appropriate security zone
• storing ICT equipment and media during non-operational hours in an appropriate security container or room
• using ICT equipment with a removable hard drive which is stored during non-operational hours in an appropriate security container or room as well as sanitising the ICT equipment's Random Access Memory (RAM)
• using ICT equipment without a hard drive as well as sanitising the ICT equipment's RAM
• using an encryption product to reduce the physical storage requirements of the hard drive in ICT equipment to an unclassified level as well as sanitising the ICT equipment's RAM.

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.

Additional information that should be included in information security awareness and training is provided in the Web Content and Connections of the Software Security chapter, Email Applications section of the Email Security chapter, the Internet Protocol Telephony section of the Network Security chapter and the Using the Internet section of this chapter.

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 should have tailored training to meet their needs.

Guidance provided to personnel should include sufficient emphasis on activities that 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.

Disclosure of information while on courses

Government personnel attending courses with non-government personnel may not be aware of the consequences of disclosing information relating to the security of their systems. Raising awareness of such consequences should prevent any disclosure that could lead to a targeted intrusion being launched against their 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, personnel should only be given the privileges that they need to undertake their duties. 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

A record of a completed system account request form signed by the person's manager should be retained. 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 reviewed.

Security clearance for 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.

System access briefings

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

Access by foreign nationals to particularly sensitive systems

AUSTEO information is restricted to Australian nationals.

AGAO information is restricted to Australian nationals, with the exception of seconded foreign nationals, who may access such information to undertake their assigned duties.

Access by foreign nationals to Australian systems

When information from foreign nations is entrusted to the Australian Government, care needs to be taken to ensure that foreign nationals do not have access to such information unless it has also been released to their country.

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.

This section applies to services utilising the Internet such as web browsing, Instant Messaging (IM), Internet Relay Chat (IRC), Internet Protocol (IP) telephony, video conferencing and peer-to-peer applications. Agencies need to be aware and educate personnel that unless applications using these communications methods are evaluated and approved by DSD they must not be used for communicating sensitive or classified information over the Internet.

Additional technical information and controls are in the Web Content and Connections section of the Software Security chapter, the Email Applications section of the Email Security chapter and the Internet Protocol Telephony section of the Network Security chapter.

Using the Internet

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 web usage policies if personnel are not made aware of their existence.

Monitoring web usage

Agencies should monitor breaches of web usage policies - for example, attempts to access blocked websites such as pornographic and gambling websites - as well as compiling a list of personnel who excessively download or upload data without a legitimate business requirement.

Posting official information on websites

Personnel need to take special care not to accidentally post sensitive or classified information on public websites, especially in forums, blogs and social networking sites. 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 websites, especially when using online social networks.

Posting personal information on websites

Personnel need to be aware that any personal information they post on websites 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 implant malicious software on systems by having them, for example, open emails or visit websites with malicious content.

Personnel should use the privacy settings on websites to restrict who can view their information and not allow public access. The privacy settings should be regularly reviewed for changes to the website policy and ensure the settings maintain privacy.

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

Agencies should monitor breaches of email usage policies - for example, attempts to send prohibited file types or executables, attempts to send excessively sized attachments or attempts to send sensitive or classified information without appropriate protective markings.

Public web-based email services

Using public web-based email services allows personnel to bypass security measures that agencies have put in place to protect against malicious code or phishing attempts distributed via email. Web-based email is email accessed using a web browser; examples of web-based email services include Gmail, Hotmail and email portals provided by Internet service providers.

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, KaZaA, eMule and uTorrent.

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. Personnel should be encouraged to send and receive files via agency established methods such as email to 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 Cable Labelling and Registration and Cable Patching sections of this chapter also apply. Agencies are not required to retro fit existing cabling 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 Emanation Security Threat Assessments 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.

Cabling

For cabling, 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) and Government 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. DSD advises that government system (G) controls in the ISM are applied as a baseline to ICT equipment storing or processing Unclassified (DLM) information. Unclassified, Unclassified (DLM) and 'Government' are not classifications under the Australian Government Security Classification System as mandated by the Attorney-General's Department.

Cabling standards

All cabling 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, cabling is still required to be associated with its classification. Under these circumstances agencies should band the cabling with the appropriate colour for its classification. The banding of cables is to comply with the inspection points for the cabling. 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. Bands must be 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: G, P, C, S, TS; Compliance: must; Authority: AH

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: G, P, C, S, TS; Compliance: must; Authority: AH

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 cabling in cabinets

Having individual or divided cabinets for each classification prevents accidental or deliberate cross patching and makes visual inspection of cabling 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 cabling.

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 done to audio secure spaces. For physical security measures regarding Security Zone requirements, refer to the Australian Government Physical Security Management Protocol.

Wall outlet terminations

Wall outlet boxes are the main method of connecting cable infrastructure to workstations. They allow the management of cabling 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 cabling for cross patching and tampering.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cabling as outlined in the Cable Management Fundamentals section of this chapter. The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retro fit existing cabling 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 Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cabling

Fibre optic cabling does not produce, and is not influenced by, electromagnetic emanations, and therefore offers the highest degree of protection from electromagnetic emanation effects.

Fibre cabling is more difficult to tap than copper cabling.

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 cabling infrastructure - it protects against unforeseen threats and facilitates upgrading secure cabling 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 cabling in a neat and controlled manner that allows for inspections reduces the need for individual cable trays for each classification.

Cabling in walls

Cabling 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 cabling or cross patching.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cabling as outlined in the Cable Management Fundamentals section of this chapter. The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retro fit existing cabling 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 Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cabling

Fibre optic cabling does not produce, and is not influenced by, electromagnetic emanations, and therefore offers the highest degree of protection from electromagnetic emanation effects.

Fibre optic cabling is more difficult to tap than copper cabling.

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 cabling infrastructure - it protects against unforeseen threats and facilitates upgrading secure cabling to higher classifications in the future.

Inspecting cables

In a shared government facility it is important that cabling 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.

Cabling in walls

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

Wall penetrations

Penetrating a wall into a lesser-classified space by cabling requires the integrity of the classified space to be maintained. All cabling is 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 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 cabling or cross patching.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cabling as outlined in the Cable Management Fundamentals section of this chapter. The controls in this section only apply to new cable installations or upgrades. Agencies are not required to retro fit existing cabling 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 Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cabling

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

Fibre optic cabling is more difficult to tap than copper cabling

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 cabling infrastructure - it protects against unforeseen threats and facilitates upgrading secure cabling to higher classifications in the future.

Inspecting cables

In a shared non-government facility it is imperative that cabling 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 cabling is 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.

Cabling in walls

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

Cabling in party walls

In a shared non-government facility, cabling is 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 cabling where the space is sufficient for inspection of the cabling.

Sealing conduits

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

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 cabling requires the integrity of the classified space be maintained. All cabling is 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 cabling 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 Emanation Security Threat Assessments 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

Recording labelling conventions in SOPs makes cabling 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 cabling 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 retro fit existing cabling 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 Emanation Security Threat Assessments 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 cabling and reduces the chance of cross patching and tampering. If lengths become excessive, cabling 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 DSD 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).

Agencies must use Bluetooth version 2.1 or later as secure simple pairing and extended inquiry response was introduced. 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 Data Import and Export section of the Gateway Security 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 HGCE

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 of the need-to-know of 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 Multifunction Device 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 Mobile Devices section of the Working Off-Site chapter while information regarding IP telephony, including Voice over Internet Protocol (VoIP), and encryption of data in transit is covered in the Internet Protocol Telephony section of the Network Security chapter and the Cryptographic Fundamentals section of the Cryptography 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; therefore they must not be used for sensitive or classified communications.

Cordless telephones with secure telephony devices

As the data between cordless handsets and base stations is not appropriately secured, cordless telephones must not be used for sensitive or classified communications 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, they must not be used in TOP SECRET areas as the audio security risk is too high. 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 Australian Government Physical Security Management Protocol.

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.

In April 2013, the Australian Government Protective Security Policy Framework (PSPF) was updated on the recommendation of the Attorney-General. PSPF mandatory requirement INFOSEC 4 now requires agencies to implement the Strategies to Mitigate Targeted Cyber Intrusions (the Strategies) as outlined in the ISM.

To satisfy INFOSEC 4, agencies are required to implement the 'Top 4' Strategies. 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.

The 'Top 4' Strategies are:
• Application whitelisting
• Patch applications
• Patch operating systems
• Minimise administrative privileges.

As of August 2013, compliance reporting against PSPF mandatory requirements must be provided to relevant Ministers annually in accordance with PSPF requirements. Agencies are not expected to be fully compliant with the 'Top 4' Strategies by August 2013, or within any specific timeframe. Timeframes will need to be determined by agencies themselves as part of their implementation planning.

Applicability and implementation priority

The applicability of DSD'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 threat being faced by Australian government agencies at this point in time: targeted cyber intrusions from the Internet to the workstation. These intrusions purposefully target specific government agencies, seeking to gain access to sensitive information through content-based intrusions (i.e. email and web pages). These intruions easily bypass perimeter defences, because they look like legitimate business traffic, to 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', and the 'Top 35' Strategies more broadly, however there may be circumstances where the risks or business impact of implementing the Strategies outweighs the benefit, and other security controls may have greater relevance. In such circumstances, agencies should apply appropriate risk management practices as outlined in the ISM.

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

The 'Top 4' mandatory controls

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

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

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, non-compliance with any mandatory requirements must be reported to an agency's relevant portfolio Minister, and also to DSD for matters relating to the ISM.

Agencies must implement the controls indicated in the following table on all systems able to receive emails or browse web content originating in a different security domain.

However, some technologies and systems may lack available products to enforce these mandatory controls (for example, Linux-based operating systems). Additionally, some technologies or scenarios will not allow enforcement of the mandatory controls (for example, a Bring-Your-Own-Device scenario significantly reduces an agency's ability to apply technical security measures). In these circumstances, agencies should apply appropriate risk management practices as outlined in the ISM.

Other applicable controls

The following controls relate to the 'Top 4' Strategies. These are not considered mandatory under the PSPF requirement INFOSEC 4 and 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

DSD, 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. DSD intends to conduct an annual survey to collate more detailed information from agencies to help meet new reporting requirements.

Agencies need confidence that products perform as claimed by the vendor. This confidence is best achieved through a formal, and impartial, assessment of the product by an independent entity. DSD manages and operates a number of evaluation programs and the results are listed on the Evaluated Products List (EPL).

DSD evaluation programs

DSD manages and operates the following independent evaluation programs:
• The Common Criteria scheme through the AISEP using licensed commercial facilities to perform evaluation of products
• Cryptographic product evaluations called a DSD Cryptographic Evaluation (DCE) for products which contain cryptographic functions
• The High Assurance evaluation program for assessment of products protecting highly classified information
• Cross domain evaluation for systems interconnecting multiple security domains in classified information environments. Refer to the Cross Domain Security chapter for further information.

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

The EPL

DSD maintains a list of products that have been formally and independently evaluated on the EPL, which can be found via the DSD website at http://www.dsd.gov.au/infosec/epl.

Agencies can select products from the EPL, as well as from any of DSD's recognised evaluation programs. Through the AISEP, DSD recognises evaluations from foreign Common Criteria schemes with equal standing. These products are listed on the Common Criteria portal which agencies can also select from without the need for the product to also be listed on the EPL. The Common Criteria portal can be found at http://www.commoncriteriaportal.org.

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

To assist agencies in selecting appropriate security products, DSD has introduced approved Protection Profiles for specific technologies. A Protection Profile is a document that stipulates the security functionality that must be included in a Common Criteria evaluation to meet a range of defined threats. Protection Profiles also define the activities to be taken to assess the security function of a product. Agencies can have confidence that a product evaluated against a DSD approved Protection Profile does address the defined threats in the required manner. DSD approved Protection Profiles are published on the EPL.

Products entered into the AISEP for evaluation against a DSD approved Protection Profile will be given the highest priority for evaluation. The aim is for these evaluations to take less time than those against the traditional criteria, which will enable the AISEP to keep pace with evaluating current security products and updates.

Cryptographic security functionality is also included in the scope of products evaluated against a DSD approved Protection Profile. DSD is currently establishing cryptographic testing as part of the AISEP Common Criteria evaluations. When this is established, evaluations against a DSD approved Protection Profile may undergo a simplified DCE process. This will assist in reducing the completion time taken to perform the evaluation.

To facilitate the transition to DSD approved Protection Profiles, a cap of Evaluation Assurance Level (EAL) 2 applies for all traditional EAL based evaluations overseen by DSD, including for technologies with no existing DSD approved Protection Profile. EAL 2 represents a sensible trade-off between completion time and meaningful security assurance gains.

Evaluations conducted in other nations' Common Criteria schemes will still be recognised by DSD.

Product selection

Agencies can determine that an evaluated product from the EPL is suitable by reviewing its evaluation documentation. This documentation includes the 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 DSD 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.

In cases where an agency finds that a product they wish to use is not evaluated, agencies can recommend that DSD evaluate the product through a letter of recommendation. This evaluation will be either against an approved Protection Profile, where one exists, or up to maximum of an EAL 2.

Product selection preference order

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

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

This order of preference is depicted in the following flow chart:

Product specific requirements and evaluation documentation

As products move toward 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 cross domain solutions, high assurance products and HGCE.

Technology convergence

Convergence is the integration of a number of discrete technologies into one product, such as mobile devices that integrate voice and data services. 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 relevant areas of this manual for 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 intrusions
• 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 the majority of 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 have 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 sufficiently new functionality has been incorporated into the product such that 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, information is available from the product vendor in the product's installation, administrator and user guidance documentation. Further information is also available in the Security Target and Certification Report. For high assurance products and HGCE configuration guidance, documents can be obtained from DSD.

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 less assurance can be gained from the evaluation.

Given the potential threat vectors and the value of the information being protected, high assurance products and HGCE must be configured in accordance with DSD'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 limit the use of non-essential labels.

Labelling HGCE

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

Information relating to the sanitisation of ICT equipment and media can be found in the Product Sanitisation and Disposal section of this chapter and the Media Sanitisation section of the Media Security 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 desired 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 Australian Government Information Security Management Protocol and Australian Government Physical Security Management Protocol.

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 which must be sanitised.

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

Media typically found in ICT equipment includes:
• electrostatic memory devices such as laser printer cartridges, MFD and Multifunction Printers (MFP)
• non-volatile magnetic memory such as hard disks and solid state disks
• 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, code words, 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.

DSD provides specific advice on how to securely dispose of high assurance products, HGCE 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 AUSTEO and 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 highly sensitive information on ICT equipment is not recoverable.

Sanitising printers and multifunction devices

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. DSD is able to, upon request, provide a suitable sanitisation file to use.

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 printer cartridge or MFD print drum should be sanitised as described above, with the additional controls below.

For sanitisation and disposal of any hard disk drives present in the printer or MFD, see the Media Security chapter.

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.

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 which is used in the operation of the network device. Resetting the device and loading a dummy config (or equivalent) will exercise the device memory and provide a read back to verify the reset was successful.

Sanitising facsimile machines

Facsimile machines store information such as phone number directories and stored pages ready for transmission. Sanitising facsimile 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 Product Classifying and Labelling section of the Product Security chapter. Information on accounting for ICT media can be found in the ICT Equipment and Media section of the Physical Security chapter.

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 can 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 a second time.

The sanitisation of TOP SECRET non-volatile media does not allow for the reduction of its classification. The classification of TOP SECRET non-volatile media can only be reduced via destruction.

Further information on using media to transfer data between systems can be found in the Data Transfers and Content Filtering chapter. More information on reducing storage and physical transfer requirements can be found in the Cryptographic Fundamentals section of the Cryptography 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 Australian Government Physical Security Management Protocol and Australian Government Information Security Management Protocol of the Protective Security Policy Framework.

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 controland data loss prevention softwareallowsgreater control overmedia that can be connected toasystemand 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, but not limited to, 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 is 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. When applying encryption to media it may reduce the requirements for storage and physical transfer as outlined in the Australian Government Physical Security Management Protocol and Australian Government Information Security Management Protocol of the Protective Security Policy Framework. Any reduction in requirements is 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 Cryptographic Fundamentals section of the Cryptography 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 the 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 provides an additional level of user awareness. This practice should be used in addition to device access control software on workstations 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 Product Sanitisation and Disposal section of the Product Security chapter.

Sanitising media

Sanitisation is the process of removing information from media. It does not automatically change the 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.

Hybrid hard drives

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

Solid state drives

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

Government systems

All references to 'Unclassified (DLM)' in the tables here relate to media containing unclassified but official/sensitive information not intended for public release, such as DLM information. DSD advises that government system (G) controls in the ISM are applied as a baseline to ICT equipment storing or processing Unclassified (DLM) information. Unclassified (DLM) and 'Government' are not classifications under the Australian Government Security Classification System as mandated by the Attorney-General's Department.

Media that cannot be sanitised

Attempts to sanitise media may sometimes be unsuccessful, in which case the media must be destroyed. Additionally, some types of media cannot be sanitised and therefore must be destroyed. Refer to the Media Destruction 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 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, the media must be destroyed as prescribed in the Media Destruction section of this chapter.

Treatment of volatile media following sanitisation

Published literature supports short-term remanence effects (residual information that remains on media after erasure) in volatile media. Data retention times are reported to be in the magnitude of minutes (at normal room temperatures) 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 must always 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 non-volatile 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 is 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 non-volatile 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.

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

Government systems

All references to 'Unclassified (DLM)' in the tables here relate to media containing unclassified but official/sensitive information not intended for public release, such as DLM information. DSD advises that government system (G) controls in the ISM are applied as a baseline to ICT equipment storing or processing Unclassified (DLM) information. Unclassified (DLM) and 'Government' are not classifications under the Australian Government Security Classification System as mandated by the Attorney-General's Department.

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.

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.

Storage and handling of media waste particles

Following destruction, normal accounting and auditing procedures do not apply for media. It is therefore essential that when media is recorded as being destroyed, destruction is assured.

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 it needs to be supervised to the point of destruction and have its destruction overseen by at least one person cleared to the sensitivity or classification of the media being destroyed.

Supervision of accountable materiel destruction

Since accountable materiel 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 commercial providers that are accredited to destroy media in an approved manner. The list of providers is available from ASIO - T4 on request.

Transporting media for off-site destruction

Requirements for the physical transfer of media between agencies and commercial facilities can be found in the Australian Government Information Security Management Protocol.

Additional information relating to the disposal of ICT equipment can be found in the Product Sanitisation and Disposal section of the Product Security 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.

The standards endorsed by the Whole-of-Government Common Operating Environment Policy come into effect when an agency is ready to deploy a new version of their base SOE. Agencies are now required to build the SOE in accordance with the standards endorsed by the Australian Government Information Management Office (AGIMO).

Developing hardened SOEs

Removing or disabling unneeded software and operating system components and functionality from a system reduces its attack surface. This could include removing hardware such as optical media burners, or drivers for undesired inbuilt hardware components such as Bluetooth, wireless and webcams.

Antivirus and other Internet security software, while important, can be defeated by malicious code that has yet to be identified by vendors. This can include targeted intrusions, where new malicious software is engineered or existing malicious software is modified to defeat the signature-based detection schemes used by most software.

The use of antivirus and other Internet security software adds value to the defence of workstations and servers, but it cannot be relied upon by itself to protect them. Hardened SOEs still need to be deployed to help protect against a broader range of risks.

Maintaining hardened SOEs

While a SOE can be sufficiently hardened when it is deployed, its security will progressively degrade over time.

Agencies can address the degradation of the security of an SOE by ensuring that:
• users do not have the ability to install or disable software
• users cannot disable or bypass security functionality
• antivirus and other Internet security software is appropriately maintained with the latest signatures.

Vulnerabilities and patch availability awareness

It is important that agencies monitor relevant sources for information about new vulnerabilities and security patches. This will enable agencies to take proactive steps to address vulnerabilities in their systems.

Patching vulnerabilities

Applying patches to operating systems, applications and devices is a critical activity in ensuring the security of systems. DSD rates this activity as one of the most effective security practices agencies can perform. Patching therefore needs to be considered as part of an agency's risk management program. Security fixes for some applications are released as new versions of the application, rather than security patches.

Critical patches are patches that address high-risk vulnerabilities, such as vulnerabilities enabling unauthorised code execution by an intruder using the Internet. Vendors use different means of communicating vulnerability severity. The severity may be derived from a standard such as the Common Vulnerability Scoring System or based on vendor-defined categorisation such as 'Critical' or 'Important'. Regardless of the rating system the vendor uses, these severity ratings can allow agencies to quickly conduct an initial assessment of importance in their environment.

The latest versions of applications typically incorporate newer security technologies and mitigate known vulnerabilities. The latest versions of operating systems offer can significant improvements in security features, functionality and stability.

As firmware provides the underlying functionality for hardware it is essential that the integrity of any firmware images or updates are maintained. Since firmware can contain the control program for a device (in wireless routers for one example), firmware vulnerabilities can have serious consequences if exploited. It is therefore important to consider firmware patching as part of your agency's patch management strategy.

If a patch is released for a high assurance product, DSD will conduct an assessment of the patch and might revise the product's usage guidance. Likewise, for patches released for HGCE, DSD will subsequently conduct an assessment of the cryptographic vulnerability and might revise usage guidance in the Consumer Guide for the product.

When security patches are not available

When a security patch is not available for a known vulnerability there are a number of approaches to reduce the security risk to a system. This includes resolving the vulnerability through alternative means, preventing exploitation of the vulnerability, containing the exploit or implementing security measures to detect intrusions attempting to exploit the vulnerability.

Unsupported software and products

Once a cessation date for support is announced for software or ICT equipment, agencies will find it increasingly difficult to protect against vulnerabilities found in the software or equipment as no security patches will be made available by the vendor. Once a cessation date for support is announced agencies should investigate new solutions that will be appropriately supported.

Default passphrases and accounts

Default passphrases and accounts for operating systems are often exploited as they are well documented in product manuals and can be easily checked in an automated manner with little effort required. When default passphrases are changed they must meet the requirements outlined in the Access Control chapter of this manual.

Functional separation between servers

Servers with a high value include those in a gateway environment such as web, email, file and Internet Protocol (IP) telephony servers.

Agencies may also implement separation through the use of techniques to restrict a process to a limited portion of the file system, but this is less effective.

Using virtualisation for functional separation between servers

Virtualisation is approved as a method of achieving functional separation between servers if the servers reside in the same security domain. Virtualisation is not approved as a domain separation method.

Characterisation

Characterisation is a technique used to analyse and record a system's configuration. It is important since it can be used to verify the system's integrity at a later date.

Methods of characterising files and directories include:
• performing a cryptographic checksum on files/directories when they are known to be virus/malicious software free
• documenting the name, type, size and attributes of legitimate files and directories, along with any changes to this information expected under normal operating conditions
• for a Windows system, taking a system difference snapshot.

There are known techniques for defeating basic characterisations. Therefore other methods of intrusion detection are also needed, particularly in situations where it is impractical to use a trusted operating environment for the generation of the characterisation data. However, it is very useful in post-intrusion forensic investigations where an infected disk can be compared to stored characterisation data in order to determine what files have been changed or introduced.

Automated outbound connections by software

Examples of applications that include beaconing functionality are applications that initiate a connection to the vendor website over the Internet (a continuous signalling of error or location information) and applications for inbound remote management.

Knowledge of software used on systems

Information about installed software that could be disclosed includes:
• user agent on web requests disclosing the web browser type
• network and email client information in email headers
• email server software headers.

This information could provide a malicious entity with knowledge of how to tailor intrusions to exploit vulnerabilities in the systems.

Application whitelisting is an approach by which all executables and applications are prevented from executing by default unless explicitly specified. These whitelisted executables and applications are allowed to execute.

Application whitelisting

Application whitelisting can be an effective mechanism to prevent the compromise of a system resulting from the exploitation of vulnerabilities in an application or from the execution of malicious code.

Defining a list of trusted executables - a whitelist - is a more practical and secure method of securing a system than relying on a list of bad executables to be prevented from running - a blacklist.

Application whitelisting is just one part of a defence-in-depth strategy for preventing intrusions and reducing their consequences.

User permissions

An average user requires access to only a few applications, or groups of applications, in order to conduct their work. Restricting the user's permissions to this limited set of applications reduces the opportunities for compromising the system.

System administrator permissions

Since the consequences of running malicious code as a privileged user are much more severe than as an unprivileged user, application whitelisting must also be enforced for system administrators.

Application whitelisting configuration

A decision to execute should be made based on cryptographic hash as it is more secure than a decision based on the executable's signature, path or parent folder.

In order for application whitelisting to be effective, an agency must initially gather information on necessary executables and applications in order to ensure that the implementation is fully effective.

Different application whitelisting controls, such as restricting execution based on cryptographic hash or folder, have various advantages and disadvantages. Agencies need to be aware of this when implementing application whitelisting.

Application whitelisting based on parent folder or executable path is futile if access control list permissions allow a user to write to the folders or overwrite permitted executables.

Adequate logging information can allow system administrators to further refine the application whitelisting implementation and detect patterns or occurrences of users being denied access.

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 development, testing and production environments limits the spread of malicious code and minimises the likelihood of faulty code being put into production.

Limiting access to development and testing environments will reduce the information that can be obtained by an internal intruder.

Secure software design

Proper security design is a key step in producing secure software. Threat modelling is an important part of secure software design. Threat modelling identifies at-risk components of software, enabling appropriate security controls to be identified to mitigate risk.

Secure programming

Once the secure software design has been identified, the secure technical implementation of the controls during development is essential.

Examples of secure programming includes performing correct input validation and handling, robust and fault-tolerant programming and ensuring the software uses the least amount of privileges required.

Software testing

Software security testing will lessen the possibility of vulnerabilities being introduced into a production environment. Software security 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 developer tests their own software.

Protecting web applications

Even though web applications may only contain information authorised for release into the public domain there still remains a need to protect the integrity and availability of the information and the systems it is hosted on and connected to. Web applications and servers are therefore to be treated in accordance with the requirements of the sensitivity or classification of the system they are connected to.

Web application frameworks and libraries

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

Secure input handling

The majority of web application vulnerabilities are due to the lack of secure input handling by the web application. It is essential that web applications do not trust any user controlled input without first properly validating and/or sanitising it in an appropriate manner.

User controlled input includes:
• the URL and URL parameters
• HTML form data
• cookie values
• HTTP request headers.

Examples of validation and sanitisation include, but are not limited to:
• 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 threat of cross-site scripting and other content injection attacks can be further mitigated through the use of appropriate, 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.

Browser based security controls

Security controls applied at the web application or server that leverage security functionality present in web browsers can help secure web applications.

These security controls are implemented by inserting HTTP headers in outgoing responses. This makes them possible to be applied to legacy or proprietary web applications where changes to the web server are possible but changes to the source code are not.

Additional resources

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

The following controls can be applied to production, test and development database systems and their environment to increase their security posture. Doing so will enable agencies to conduct their business with a reduced risk of theft, corruption, loss, or unauthorised access and exposure of, information critical to their business.

Further information on DACAs can be found in the Cryptography chapter of this manual.

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 appropriate protection to these assets. For this reason, it is important an accurate inventory of all databases deployed by an agency and their contents is maintained and regularly reviewed.

DBMS software versions and patching

Using unsupported or unpatched DBMS software can expose databases to publicly known vulnerabilities. These vulnerabilities can be exploited by an intruder to gain access to database content or even the underlying operating system. Deploying the latest security patches and product updates from vendors to DBMS software in a timely manner will assist in protecting databases. Furthermore, agencies may choose to deploy the latest versions of DBMS software as it is released. This will allow agencies to take advantage of any new security functionality and continued vendor support for their DBMS software.

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 passwords in the clear, could provide valuable information to an intruder. Removing all temporary installation files and logs after DBMS software has been installed will minimise this risk.

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

DBMS software operating as a local administrator or root account can present a significant risk to the underlying operating system if compromised by an intruder. Therefore, it is important to configure DBMS software to run as a separate account with the minimum privileges needed to perform its functions. In addition, limiting access of the account under which the DBMS server runs to non-essential areas of the database server's file system will limit the impact of any compromise of the DBMS software.

DBMS software is often capable of accessing files that it has read access to on the local database server. For example, an intruder 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 passwords as plaintext in databases poses a significant risk to agencies. An intruder that manages to gain access to database contents can extract these authentication credentials to gain access to users' accounts. In addition, it is possible that a user could have reused a username and password for their corporate workstation posing an additional risk to an agency. To prevent authentication credentials from being exposed, usernames and passwords stored in databases must be hashed with a strong hashing algorithm which is uniquely salted. Further guidance on DACAs can be found in the Cryptography chapter of this manual.

Protecting database contents

Storing particularly sensitive content on databases can worsen the consequences if the database is compromised. Carefully considering the business requirement for storing sensitive content on databases and its effect on the agency's risk profile is imperative. In addition, to ensure that appropriate protective measures are applied to such information, database administrators and database users need to know what level of sensitivity is associated with the database and its contents. This can be achieved by using appropriate protective markings to information stored in databases.

Implementing database user roles that limit user's access to content needed to perform their work duties will ensure the need-to-know principle is applied. Restricting database user roles to selecting, updating and inserting content into databases based on the essential business requirement and work duties of users will further improve database security.

Database contents can be protected from unauthorised copying and subsequent offline analysis by applying appropriate file-based access controls to database files. However, should an intruder gain access to database files, for example, cases of 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. Appropriately encrypting particularly sensitive content within databases, for example, using Advanced Encryption Standard (AES) before being stored in a database will assist in addressing this risk. Further guidance can be found in the Cryptography chapter. In addition to preventing unauthorised access to particularly sensitive information using offline analysis, encrypting particularly sensitive content before storing it in a database, as opposed to encrypting database columns or tablespaces using transparent encryption, has the added benefit of preventing unauthorised access to particularly sensitive information as part of an SQL injection against a database.

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 intruder 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 intruder cannot access the sum of information components leading to the aggregated information.

Hardening database server SOE

Using a hardened SOE for database servers will make it more difficult for an intruder to compromise database servers in order to exploit database systems.

Database administrator accounts

DBMS software often comes pre-configured with default database administrator accounts and passwords that are listed in product documentation, for example, sa/<blank> for SQL Server, root/<blank> for MySQL, scott/tiger for Oracle and db2admin/db2admin for DB2. To assist in preventing an intruder from exploiting this, default database administrator accounts must be removed or have their passwords changed to strong complex passwords. Furthermore, passwords should not be shared across separate database instances as doing so can exacerbate any password compromise by an intruder.

When sharing database administrator accounts for the performance of administrative tasks on databases, any actions undertaken cannot be attributed to an individual database administrator. Ensuring database administrators have unique and identifiable accounts will assist in auditing activities on databases. This is particularly helpful during investigations relating to an attempted (or successful) cyber intrusion. Furthermore, it is important to use database administrator accounts exclusively for administrative tasks with standard database user accounts used for general purpose interactions with databases.

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. Therefore, for improved security, database administrator access can be restricted to defined roles rather than accounts with default administrative permissions, or all permissions.

Even though database administrators may use strong complex passwords for their accounts, an intruder could still install a key logger on their workstations to capture their usernames and passwords. The use of multi-factor authentication can minimise the threat of key logging. This will assist in preventing the compromise of databases by an intruder should a database administrator's password be compromised. In addition, implementing the top four of DSD's Strategies to Mitigate Targeted Cyber Intrusions on workstations used to administer databases will assist in protecting database administrators' passwords by minimising the risk that their workstations are compromised.

Database user accounts

DBMS software often comes pre-configured with anonymous database user accounts with blank passwords. Removing anonymous database user accounts will assist in preventing an intruder from exploiting this feature.

Databases often contain information and metadata of varying sensitivities, classifications and compartments. It is important users are only granted access to information in databases for which they have the appropriate security clearance, briefings and a need-to-know. The need-to-know principle can be enforced through the application of minimum privileges, database views and database roles.

Network environment

Placing database systems used by web applications on the same physical server as a web server in the demilitarised zone of a gateway environment can expose them to an increased risk of cyber intrusion over the Internet. Locating database systems used by web applications on a physically separate database server in a separate demilitarised zone to web servers will reduce this risk.

Placing database servers on the same network segment as the rest of an agency's corporate workstations and allowing them to communicate with other network resources exposes them to an increased risk of compromise. Placing database servers on a different network segment to the rest of an agency's corporate workstations will make it more difficult for an intruder that manages to compromise a workstation or server to interact with database servers. Additionally, implementing network access controls to restrict database servers' communications to strictly defined network resources such as web servers, application servers and storage area networks will improve security.

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. If only local access to a database system is required, networking functionality of DBMS software should be disabled or directed to listen solely to the localhost interface.

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. As such, it is imperative information in production databases is not used in test or development databases unless appropriately sanitised of sensitive or classified information first.

Interacting with database systems from web applications

SQL injections pose a significant threat to database confidentiality, integrity and availability. SQL injections can allow an intruder to steal information from databases, modify database contents, delete an entire database or even in some circumstances gain control of the underlying database server. To protect against SQL injections, all queries to database systems from web applications must be filtered for legitimate content and correct syntax. Furthermore, to prevent against injection of content into dynamically generated queries, stored procedures should be used for database interaction instead of dynamically generated queries.

Information communicated between database systems and web applications, especially over the Internet, is susceptible to capture by an intruder. Appropriately encrypting sensitive or classified information communicated between databases systems and web applications (for example, using Secure Sockets Layer (SSL) and Transport Layer Security (TLS)) will prevent an intruder from capturing such information.

When database queries by web applications fail they are capable of displaying detailed error information. 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. To prevent an intruder from using such information to exploit published vulnerabilities in DBMS software, or further tailor SQL injections, it is important web applications are be designed to provide as little error information as possible about DBMS software and database schemas.

Event logging and auditing

Logging and auditing database events can assist in monitoring for unusual activity, unauthorised actions or in conducting investigations after an attempted, or successful, cyber intrusion.

To assist in the coordination of audits of event logs from multiple sources, and in identifying patterns of activity that might not be noticeable when reviewing event logs from a single source, database event logs should be centrally logged to a secure logging server. Furthermore, database event logs should be time- stamped using a trusted time source.

While DBMS software may appropriately log database events for unusual activity or unauthorised actions, an intruder may attempt to cover signs of a cyber intrusion by modifying or deleting the database event logs. As such, it is imperative database event logs be appropriately protected from unauthorised access, modification, deletion or loss.

While an agency may sufficiently log and correlate database events, if they are not audited on a regular basis cyber intrusions may go unnoticed for an extended period of time.

Information on ISPs can be found in the Information Security Policies section of the Information Security Documentation 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.

Socially engineered emails

Socially engineered emails are one of the most common techniques used to spread malicious software. Should technical measures fail, users are the last line of defence in ensuring a socially engineered email does not lead to malicious software being installed on a workstation. 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 AGIMO's Email Protective Marking Standard for the Australian Government.

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 Australian Government Information Security Management Protocol.

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 are recommended to 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 to 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 AGIMO standard facilitates interoperability across government.

Printing protective markings

The Australian Government Information Security Management Protocol 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 that 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 sensitive emails with AUSTEO, AGAO or other nationality releasability marked information to distribution lists could accidentally cause a data spill.

Information on using email applications can be found in the Email Applications section of this chapter. Information on usage policies for personnel is located in the Email Policy section of this chapter, and the Using the Internet section of the Personnel Security for Systems 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 Sender Policy Framework (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 to 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 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 prevalent cyber intrusion vector. 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 Content Filtering 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.

Although most effective email content filtering controls are applied at the email server or email content filter, applying security controls at the email client software helps create a defence in depth approach.

Information on email infrastructure is located in the Email Infrastructure section of this chapter. Information on usage policies for personnel is located in the Email Policy section of this chapter and the Using the Internet section of the Personnel Security for Systems chapter.

Automatically generated emails

The requirements for emails in this section apply equally to automatically generated emails.

Email active content

Controlling the software that runs on systems helps prevent malicious software and unauthorised applications running. Constraining active content delivered through email, especially on Internet facing systems, ensures that it cannot arbitrarily access users' files or deliver malicious code. Unfortunately the implementation of email permits such activity.

If active content is displayed automatically in the preview pane it can run even though an email item has not been explicitly opened. If active content is allowed, restricting the preview pane to only render content as plaintext ensures emails from a suspicious source would need a user to make a conscious decision to open an email before the active content is displayed.

Methods for user identification and authentication

User authentication can be achieved by various means, including biometrics, cryptographic tokens, passphrases, passwords and smart cards. Where this manual refers to passphrases it equally applies to passwords.

Multi-factor authentication uses independent means of evidence to assure an entity's identity. The three authentication methods are:
• something one knows, such as a passphrase or a response to a challenge
• something one has, such as a passport, physical token or an identity card
• something one is, such as biometric data, like a fingerprint or face geometry.

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

Strong identification and authentication mechanisms significantly reduce the security risk that unauthorised users will gain access to a system.

Policies and procedures

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

User identification

Having uniquely identifiable users ensures accountability.

Identification of foreign nationals

Where systems contain AUSTEO, AGAO or other nationality releasability marked information, with foreign nationals having access to such systems, it is important that agencies implement appropriate security measures to ensure identification of users who are foreign nationals. Such security measures can help prevent the release of particularly sensitive information to those not authorised to access it.

Shared accounts

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

Using passphrases for user identification and authentication

A numerical password (or personal identification number) employs a small character set (0-9), making it susceptible to brute force attacks that will be successful in a short period of time.

A simple six character password can be susceptible to brute force attacks in minutes by software available on the Web. Passphrases with at least nine characters using upper and lower case alphabetic characters, numeric characters and special characters are more resistant to brute force attacks.

Due to the computer processing technology available, passphrases not meeting the requirements in this manual are able to be retrieved using brute force attacks in a short period of time. Passphrases will have to increase in length and complexity as better processing technology becomes available.

Multi-factor authentication

Multi-factor authentication is one of the most effective controls an agency can implement to prevent a cyber intruder from propagating on a network and identifying and accessing sensitive information during a targeted cyber intrusion. Intruders frequently attempt to steal legitimate user or administrative credentials when they compromise a network. These credentials allow them to easily propagate on a network and conduct malicious activities without requiring additional exploits, thereby reducing the likelihood of detection.

To provide a secure authentication mechanism that is not as susceptible to brute force attacks, multi- factor authentication should be used for all accounts. Using multi-factor authentication will also reduce the demands on users to remember long passphrases.

Privileged accounts are targeted by adversaries as they can potentially allow access to the entire system. Stronger authentication must also be used for positions of trust, such as an account that is able to approve financial transactions or accounts that have access to sensitive information. Positions of trust, including access to sensitive information and databases, and privileged accounts must use multi-factor authentication to provide a secure authentication mechanism.

As privileged access should not be used off-site, and if the access for positions of trust is not required remotely, the multi-factor evidence used for something one has should be kept in the office and physically secured according to the requirements in the Australian Government Physical Security Management Protocol as per the sensitivity or classification of the system that it is used to access.

Some methods of multi-factor authentication are more effective than others. It is therefore essential to correctly implement and configure it on your network to ensure vulnerabilities are minimised. Further guidance can be found in DSD's Protect publication Multi-factor Authentication.

Protecting stored authentication information

Limiting the storage of unprotected authentication information reduces the security risk of an intruder finding and using the information to access a system under the guise of a valid user.

Protecting authentication data in transit

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

Passphrase management

Requiring a passphrase to be changed at least every 90 days limits the time period in which a disclosed passphrase could be used by an unauthorised user.

Preventing a user from changing their passphrase more than once a day stops the user from immediately changing their passphrase back to their old passphrase.

Checking passphrases for compliance with the passphrase selection policy allows system administrators to detect unsafe passphrase selection and ensure that the user changes it.

Forcing a user to change a passphrase when resetting accounts ensures that the user changes the passphrase and it is a passphrase that only they know and remember.

Disallowing predictable reset passphrases reduces the security risk of brute force attacks and passphrase guessing attacks.

Using different passphrases when resetting multiple accounts prevents a user whose account has been recently reset from logging into another such account.

Disallowing passphrases from being reused within eight changes prevents a user from cycling between a small subset of passphrases.

Disallowing sequential passphrases reduces the security risk of an intruder easily guessing a user's next passphrase based on their knowledge of the user's previous passphrase.

Resetting passphrases

To reduce the likelihood of social engineering attacks aimed at service desks, agencies need to ensure that users provide sufficient evidence to verify their identity when requesting a passphrase reset for their system account.

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 users with complex reset passphrases ensures the security of the user account is maintained during the passphrase reset process. This also represents a good opportunity for service desk staff to demonstrate to users an example of a good passphrase.

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.

Session termination

Developing a policy to automatically logout and shutdown workstations after an appropriate time of inactivity helps prevent the compromise of a workstation that has been authenticated to and contains sensitive or classified information in memory. Such a policy also reduces the power consumption of systems during non-operational hours.

Session and screen locking

Screen and session locking prevents unauthorised access to a system to which an authorised user has already been authenticated to.

Ensuring that the screen does not appear to be turned off while in the locked state prevents users forgetting they are still logged in and will prevent other users mistakenly thinking there is a problem with a workstation and resetting it.

Suspension of access

Locking a user account after a specified number of failed logon attempts reduces the security risk of brute force attacks. Removing a user account when it is no longer required prevents personnel accessing their old account and reduces the number of accounts that can be targeted. Suspending inactive accounts after a specified number of days reduces the number of accounts that can be targeted. Investigating repeated account lockouts reduces the security risk of any ongoing brute force logon attempts and allows security management to act accordingly.

Implementing account lockout functionality in a web application can increase the risk of a DoS attack. This is because this function makes it simple for a malicious actor to deliberately input wrong passwords enough times to lock users out of their accounts. Implementing an appropriate password reset functionality can help mitigate DoS effects if a web application has locked out a user.

Investigating repeated account lockouts

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

Logon banner

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

Displaying when a system user last logged in

Displaying when a user has last logged onto a system helps users identify any unauthorised use of their account. Accordingly, when any case of unauthorised use of an account is identified, it should be reported to an ITSM immediately so that it can be investigated.

Additional information on security clearance, briefing and authorisation requirements can be found in the Privileged Access section of this chapter and the Authorisations, Security Clearances and Briefings section of the Personnel Security for Systems chapter.

Access from foreign controlled systems and facilities

If an Australian system is to be accessed from overseas, it needs to be from at least a facility owned by a foreign government with which Australia has a security of information arrangement. Furthermore, due to the sensitivities involved with AUSTEO and AGAO systems, such systems can only be accessed from facilities under the sole control of the Australian Government.

Enforcing authorisations on systems

Enforcing authorisations of users through the use of access controls on a system decreases the risk of unauthorised disclosure of classified or sensitive information. Agencies should follow a process for developing an access control list, such as
• 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.

Protecting compartmented information on systems

Compartmented information is particularly sensitive. Therefore, extra security measures need to be put in place on systems to restrict access to those with sufficient authorisations, briefings and a demonstrated need-to-know.

In this section, 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 the system.

The requirements for using multi-factor authentication for privileged access are included in the Identification and Authentication section of this chapter.

Use of privileged accounts

Inappropriate use of any feature or facility of a system that enables a privileged user to override system or application controls can be a major contributory factor to failures on systems that lead to cyber security incidents.

Privileged access allows system-wide changes to be made. An appropriate and effective mechanism to log privileged users will provide greater accountability and auditing capabilities.

Privileged accounts are targeted by adversaries as these can potentially give full access to the system. Ensuring that privileged accounts do not have a channel from inside the agency to the Internet minimises opportunities for these accounts to be compromised.

Privileged system access 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 processing particularly sensitive information.

Remote access

Remote access is considered to be any access that originates from outside an agency network and enters the network through an Internet gateway.

Further information on working off-site can be found in the Working Off-Site chapter. The requirements for using multi-factor authentication for remote access are included in the Identification and Authentication section of this chapter.

Authentication

Authenticating remote users and devices ensures that only authorised users and devices are allowed to connect to systems.

Remote privileged access

The extent of a compromise of remote access to a system can be limited by preventing the use of remote privileged access.

Information on event logging associated with a cyber security incident can be found in the Cyber Security Incidents section.

A security event is an evident change to the normal behaviour of a network, system or user. Event logging helps raise the security posture of a system by increasing the accountability of all user actions, thereby improving the chances that malicious behaviour will be detected. Agencies should ensure sufficient detail is recorded in order for the logs to be useful when reviewed and determine an appropriate length of time for them to be retained. Conducting audits of event logs should be seen as an integral part of the maintenance of systems, since they will help detect and attribute any violations of information security policy, including cyber security incidents, breaches and intrusions.

Logging requirements

Event logging helps raise the security posture of a system by increasing the accountability for all user actions.

Event logging increases the chances that malicious behaviour will be detected by logging the actions of a malicious party.

Well configured event logging allows for easier and more effective auditing if a cyber security incident occurs.

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.

Additional events to be logged

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

Event log facility

The act of logging events is not enough in itself. 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 (possibly involving the use of a dedicated event log server) will help ensure the integrity and availability of the collected logs when they are audited.

Event log retention

It is important that agencies determine an appropriate length of time to retain event logs for systems. Since event logs can assist in reviews, audits and investigations, 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 after action is completed.

Event log auditing

Conducting audits of event logs should be seen as an integral part of the maintenance of systems, since they will help detect and attribute any violations of information security policy, including cyber security incidents, breaches and intrusions. Agencies can use a Security Information and Event Management solution to correlate logs from multiple sources to identify patterns of suspicious behaviour. Automated solutions are available to help agencies proactively identify such patterns.

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

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

Purpose of cryptography

The purpose of cryptography is to provide confidentiality, integrity, authentication and non-repudiation 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 system 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.

Care needs to be taken, with encryption systems that do not encrypt the entire media content, 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 of 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 such information can be reduced. However, as the sensitivity or classification of the unencrypted information does not change, the lowered security requirements cannot be used as a baseline to further lower requirements with an additional cryptographic product.

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 a DCE. Such requirements supplement this manual and where conflict occurs the product specific requirements take precedence.

Using products with DACAs and Protocols

Where this manual states a requirement for a product that implements a DACA or DSD Approved Cryptographic Protocol (DACP) to be used to provide protection for information at rest or in transit, the product does not need to have undergone a DCE.

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 applies to both FIPS 140-1 and FIPS 140-2. The third iteration, FIPS 140-3, has been released in draft and this section also applies to that iteration.

FIPS 140 is not a substitute for a DCE of a product with cryptographic functionality. 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 DSD. Where a product's cryptographic functionality has been validated under FIPS 140, DSD can, at its discretion, and in consultation with the vendor, reduce the scope of a DCE.

DSD will review the FIPS 140 validation report to confirm compliance with Australia's national cryptographic policy.

Reducing storage and physical transfer requirements

When encryption is applied to media, whether the media resides in ICT equipment or not, 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 can be treated at an unclassified 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

As AUSTEO and AGAO information is particularly sensitive, it 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 as per the sensitivity or classification of the information it processes, stores or communicates.

Reducing network infrastructure requirements

When encryption is applied to sensitive or classified information being communicated over networks, less assurance needs to be placed in the protection of the network infrastructure. In some cases, where no security can be applied to the network infrastructure - for example where information is in the public domain - 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

As AUSTEO and AGAO information is particularly sensitive it needs to be encrypted when being communicated across network infrastructure.

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

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

DACAs

There is no guarantee or proof of security of an algorithm against presently unknown intrusion methods. 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 intrusion. There have been some cases where theoretically impressive vulnerabilities have been found, however these results are not of practical application.

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

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 number factorisation could render the use of smaller RSA moduli a vulnerability.

Suite B

Suite B is the collective name for the following set of four well-established, public domain cryptographic algorithms:
• Encryption: AES
• Hashing: SHA-2
• Digital Signature: ECDSA
• Key Exchange: ECDH.

When used in combination, these four algorithms can provide adequate information assurance for classified information.

Suite B has been approved by DSD in specific configurations and evaluated implementations for the protection of highly classified (CONFIDENTIAL, SECRET and TOP SECRET) information.

Using DACAs

If a product implementing a DACA has been inappropriately configured, it is possible that relatively weak cryptographic algorithms could be selected 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 unevaluated products that implement a DACA, agencies can ensure that only the DACA can be used by disabling the unapproved algorithms in the products (which is preferred) or advising users not to use them 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 modulus of at least 1024 bits for DH is considered best practice by the cryptographic community.

Using the Digital Signature Algorithm

A modulus of at least 1024 bits for DSA is considered best practice by the cryptographic community.

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 modulus of at least 1024 bits for RSA is considered best practice by the cryptographic community.

Approved hashing algorithms

Recent research conducted by the cryptographic community suggests that SHA-1 may be susceptible to collision attacks. While no practical collision attacks have been published for SHA-1, they may become feasible in the near future.

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 clear text, 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 the most secure option, while using two distinct keys in the order key 1, key 2, key 1 is also deemed secure for practical purposes. All other keying options are equivalent to single DES, which is not deemed secure for practical purposes.

Protecting highly classified information

Suite B, a set of public domain cryptographic algorithms, has been approved by DSD for use in specific configurations and evaluated implementations for the protection of CONFIDENTIAL, SECRET and TOP SECRET information.

DSD has approved classified cryptographic algorithms for the protection of highly classified information. As with Suite B, these are only approved when used in an evaluated implementation. Please consult DSD for information on HGCE and classified algorithms.

Implementations of the protocols in this section need to undergo a DCE before they can be approved to protect classified information.

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

DACPs

In general, DSD only approves the use of cryptographic products that have passed a formal evaluation. However, DSD approves the use of some commonly available cryptographic protocols even though their implementations in specific products have not been formally evaluated by DSD. This approval is limited to cases where they are used in accordance with the requirements in this manual.

The DACPs are:
• SSL and TLS
• Secure Shell (SSH)
• Secure Multipurpose Internet Mail Extension (S/MIME)
• OpenPGP Message Format
• Internet Protocol Security (IPSec).
• WPA2 (when used in accordance with the advice contained in the Wireless Local Area Networks section of the Network Security chapter).

Using DACPs

If a product implementing a DACP has been inappropriately configured, it is possible that relatively weak cryptographic algorithms could be selected 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 unevaluated products that implement a DACP, agencies can ensure that only the DACA can be used by disabling the unapproved algorithms in the products (which is preferred) or advising users not to use them via a policy.

While many DACPs support authentication, agencies should be aware that these authentication mechanisms are not fool proof. To be effective, these mechanisms must also be securely implemented and protected. This can be achieved by:
• providing an assurance of private key protection
• ensuring the correct management of certificate authentication processes including certificate revocation checking
• using a legitimate identity registration scheme.

When using a product that implements SSL and TLS, requirements for using DACPs also need to be consulted in the DSD Approved Cryptographic Protocols section of this chapter.

Further information on handling SSL and TLS traffic through gateways can be found in the Web Content and Connections section of the Software Security chapter.

Using Secure Sockets Layer and Transport Layer Security

Version 1.0 of SSL was never released and version 2.0 had significant security flaws leading to the development of SSL 3.0. SSL has since been superseded by TLS, with the latest version being TLS 1.2 which was released in August 2008.

When using a product that implements SSH, requirements for using DACPs also need to be consulted in the DSD Approved Cryptographic Protocols section of this chapter.

Using Secure Shell

The configuration directives provided are based on the OpenSSH implementation of SSH. Agencies implementing SSH will need to adapt these settings to suit other SSH implementations.

SSH version 1 is known to have vulnerabilities. In particular, it is susceptible to a man-in-the-middle attack, where someone who can intercept the protocol in each direction can make each node believe they are talking to the other. SSH version 2 does not have this vulnerability.

SSH has the ability to forward connections and access privileges in a variety of ways. This means if any of these features can be exploited, unauthorised access to a potentially large amount of information can also be gained.

Host-based authentication requires no credentials (for example, passphrase or public key) to authenticate (though in some cases it might make use of a host key). This renders SSH vulnerable to an IP spoofing attack.

An intruder who gains access to a system with system administrator privileges will have the ability to not only access information but to control that system completely. Given the clearly more serious consequences of this, system administrator login should not be permitted.

Authentication mechanisms

Public key-based systems have greater potential for strong authentication - put simply, people cannot remember particularly strong passphrases. Passphrase-based authentication schemes are also more susceptible to interception than public key-based authentication schemes.

Passphrases are more susceptible to guessing attacks, therefore if passphrases are used in a system, counter-measures should be put into place to reduce the chance of a successful brute force attack.

Automated remote access

If passphrase-less authentication is enabled, allowing access from unknown IP addresses would allow untrusted parties to automatically authenticate to systems without needing to know the passphrase.

If port forwarding is not disabled, or it is not configured securely, access may be gained to forwarded ports, thereby creating a communication channel between the intruder and the host.

If agent credential forwarding is enabled, an intruder could connect to the stored authentication credentials and then use them to connect to other trusted hosts or even intranet hosts, if port forwarding has been allowed as well.

X11 is a computer software system and network protocol that provides a graphical user interface for networked computers. Failing to disable X11 display remoting could result in an intruder being able to gain control of the computer displays as well as keyboard and mouse control functions.

Allowing console access allows every user who logs into the console to run programs that are normally restricted to the root user.

SSH-agent

SSH-agent or other similar key caching programs hold and manage private keys stored on workstations and respond to requests from remote systems to verify these keys. When an SSH-agent launches, it will request the user's passphrase. This passphrase is used to unlock the user's private key. Subsequent access to remote systems is performed by the agent and does not require the user to re-enter their passphrase. Screen locks and expiring key caches ensure that the user's private key is not left unlocked for long periods of time.

Agent credential forwarding is required when multiple SSH connections are chained to allow each system in the chain to authenticate the user.

When using a product that implements S/MIME, requirements for using DACPs also need to be consulted in the DSD Approved Cryptographic Protocols section of this chapter.

Information relating to the development of passphrase selection policies and passphrase requirements can be found in the Identification and Authentication section of the Access Control chapter.

Using Secure Multipurpose Internet Mail Extension

S/MIME 2.0 required the use of weaker cryptography (40-bit keys) than is approved for use in this manual. Version 3.0 was the first version to become an Internet Engineering Task Force standard.

Agencies choosing to implement S/MIME should be aware of the inability of many content filters to inspect encrypted messages and any attachments for inappropriate content, and for server-based antivirus and other Internet security software to scan for viruses and other malicious code.

When using a product that implements IPsec, requirements for using DACPs also need to be consulted in the DSD Approved Cryptographic Protocols section of this chapter.

Modes of operation

IPsec can be operated in two modes: transport mode or tunnel mode.

Cryptographic protocols

IPsec contains two major protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP).

Cryptographic algorithms

Most IPsec implementations can handle a number of cryptographic algorithms for encrypting data when the ESP protocol is used. These include 3DES and AES.

Key exchange

Most IPsec implementations handle a number of methods for sharing keying material used in hashing and encryption processes. Available methods are manual keying and Internet Key Exchange (IKE), versions 1 and 2, using the Internet Security Association Key Management Protocol (ISAKMP).

Internet Security Association Key Management Protocol authentication

Most IPsec implementations handle a number of methods for authentication as part of ISAKMP. These can include digital certificates, encrypted nonces or pre-shared keys. These methods are considered suitable for use.

IKE Extended Authentication

Agencies should disable the use of IKE Extended Authentication (XAUTH) for IPSec connections using IKEv1.

Internet Security Association Key Management Protocol modes

Agencies using ISKMP in IKEv1 should disable aggressive mode.

Mode of operation

The tunnel mode of operation provides full encapsulation of IP packets while the transport mode of operation only encapsulates the payload of the IP packet.

Protocols

In order to provide a secure Virtual Private Network style connection, both authentication and encryption are needed. AH and ESP can provide authentication for the entire IP packet and the payload respectively. However, ESP is generally preferred for authentication since AH by its nature has network address translation limitations. ESP is the only way of providing encryption.

If, however, maximum security is desired at the expense of network address translation functionality, then ESP can be wrapped inside of AH which will then authenticate the entire IP packet and not just the encrypted payload.

Key Exchange

There are several methods for establishing shared key material for an IPsec connection. IKE supersedes and addresses a number of risks associated with manual keying. For this reason, IKE is the preferred method for key establishment.

Internet Security Association Key Management Protocol modes

Using ISAKMP main mode instead of aggressive mode provides greater security since all exchanges are protected.

Security association lifetimes

Using a secure association lifetime of four hours, or 14400 seconds, provides a balance between security and usability.

Hashed Message Authentication Code algorithms

MD5 and SHA-1 are no longer DACAs that can be used with Hashed Message Authentication Code (HMAC). The approved HMAC algorithms are HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512.

Diffie-Hellman groups

Using a larger DH group provides more entropy for the key exchange.

Perfect Forward Secrecy

Using Perfect Forward Secrecy reduces the impact of the compromise of a security association.

IKE Extended Authentication

XAUTH using IKEv1 has documented vulnerabilities associated with its use.

Due to the wide variety of cryptographic systems and technologies available, and the varied security risks for each, only general key management guidance can be provided in this manual.

If HGCE is being used, agencies are advised to consult the respective ACSI for the equipment.

Cryptographic systems

In general, the requirements specified for systems apply equally to cryptographic systems. Where the requirements for cryptographic systems are different, the variations are contained in this section, and overrule all requirements specified elsewhere in this manual.

Compromise of key material

If the private certificate and associated key used for encrypting messages is suspected of being compromised (that is, stolen, lost or transmitted over the Internet), then no assurance can be placed in the integrity of subsequent messages that are signed by that private key. Likewise no assurance can be placed in the confidentiality of a message encrypted using the public key, since third parties could intercept the message and decrypt it using the private key.

HGCE

ACSI 53 and ACSI 105 provide product specific policy for HGCE.

Transporting commercial grade cryptographic equipment

Transporting commercial grade cryptographic equipment in a keyed state exposes the equipment to the potential for interception and compromise of the key stored in the equipment. Therefore, when commercial grade cryptographic equipment is transported in a keyed state, it needs to be done according to the requirements for the sensitivity or classification of the key stored in the equipment.

Communications security custodian access

Since communications security custodian access involves granting privileged access to a cryptographic system, extra precautions need to be put in place surrounding the personnel chosen to be cryptographic system administrators.

Accounting

As cryptographic equipment, and the keys it store, provides a significant security function for systems, it is important that agencies are able to account for all cryptographic equipment.

Audits

Cryptographic system audits are used as a process to account for cryptographic equipment.

Area security and access control

As cryptographic equipment contains particularly sensitive information, additional physical security measures need to be applied to the equipment. Further information relating to physical security is contained in the Australian Government Physical Security Management Protocol.

Developing Key Management Plans for cryptographic systems

Most modern cryptographic systems are designed to be highly resistant to cryptographic analysis but it must be assumed that a determined malicious actor could obtain details of the cryptographic logic either by stealing or copying relevant material directly or by suborning an Australian national or allied national. The safeguarding of cryptographic system material by using adequate personnel, physical, documentation and procedural security measures is therefore crucial.

Contents of Key Management Plans

When agencies implement the recommended contents for KMPs they will have a good starting point for the protection of cryptographic systems and their material.

Access register

Access registers can assist in documenting personnel who have privileged access to cryptographic systems along with previous accounting and audit activities for the system.

Agencies can structure and configure their networks to reduce the number of potential entry points that could be used to gain unauthorised access to information or disrupt agency services. Appropriate network management practices and procedures can assist in identifying and addressing network vulnerabilities.

Further information regarding the appropriate selection of products such as automated tools can be found in the Product Selection and Acquisition section of the Product Security chapter.

Configuration management

If the network is not centrally managed there could be sections of the network that do not comply with information security policies.

Changes should be approved by a change management process involving representatives from all parties involved in the management of the network. This process ensures that changes are understood by all parties and reduces the likelihood of an unexpected impact on the network.

Network documentation

Detailed network documentation and configuration details can contain information about IP addresses, software version numbers and patch status, security enforcing devices and information about enclaves contain highly valuable information. This information could be used by a malicious actor to compromise an agency's network.

Network diagrams

A network diagram illustrates all network devices such as firewalls, IDSs and Intrusion Prevention Systems (IPSs), routers and switches. It does not need to illustrate all ICT equipment on the network, such as workstations or printers, although the inclusion of significant devices such as servers could aid in its interpretation.

As most decisions are made on the documentation that illustrates the network, it is important that:
• a network diagram exists
• the network diagram is an accurate depiction of the network
• the network diagram indicates when it was last updated.

Updating network diagrams

Due to the importance of the network diagram, and decisions made based upon its contents, the network diagram should be updated as changes are made to the network. This will assist system administrators to completely understand and adequately protect the network.

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.

Manual methods that may be used to detect network devices include network scans and physical inspections while automated methods include network access controls and IDSs and IPSs. The audit method is should be able to detect the presence of network devices inserted into or hidden inside systems, portable devices connected to workstations via USB ports and devices attached to a network port. It is important to note that network scans conducted over a network may not be able to detect network devices hidden inside workstations or connected via USB ports.

Auditing of network devices that are being added or removed from networks should be implemented. This may indicate an attempt to introduce a backdoor into a network or to conduct a DoS attack against the network.

This section should be read in conjunction with the Servers and Network Devices section of the Physical Security chapter. Additional information specific to wireless networks can be found in the Wireless Local Area Networks section of this chapter, while additional information on deploying IDSs and IPSs can be found in the Intrusion Detection and Prevention section of this chapter.

Separation of networks in the same security domain

A single network, managed in accordance with a single SSP, for which some separation is needed for administrative or similar reasons, can use VLANs to achieve that separation.

VLANs can also be used to separate IP telephony traffic from data traffic at the same sensitivity or classification.

Multi Protocol Label Switching

For the purposes of this section, Multi Protocol Label Switching is considered to be equivalent to VLANs and is subject to the same controls.

Network segmentation

Network segmentation is one of the most effective controls to prevent an intruder from propagating through an agency's network once they have gained access. Well-implemented network segmentation can significantly increase the difficulty for an intruder to find and access their target information and move undetected around the network. Technologies to enforce network segmentation contain logging functionality which 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 involves separating a network into multiple functional zones, with a view to protect 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 directly target internal agency networks is making it increasingly important for agencies to separate sensitive information from the environment where their users access the Internet and email.

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

Limiting network access

If a malicious actor has limited opportunities to connect to a given 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 or compartmented 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 workstation to workstation.

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

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 usernames and passwords for network devices

Network devices such as switches, routers and wireless access points come pre-configured with default accounts and passwords 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 password of either “admin” or “password”. Ensuring default usernames and passwords are changed before they are deployed in a network will decrease the risk of the names and passwords being exploited to gain unauthorised access to network devices.

Time synchronisation between network devices

When intrusions or attacks occur against 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.

Updating firmware for network devices

The operation of network devices is controlled by software known as firmware. Periodically network device vendors will release updated firmware to fix software bugs, resolve security issues and add new functionality and features. A security risk exists for agencies that do not update the firmware for network devices as known software bugs and security issues may be exploited to gain access to their networks. Keeping firmware for network devices up to date will assist in reducing this risk.

Securing devices accessing networks

Devices, particularly privately owned devices and mobile devices, used to access networks have the potential to have been exposed to viruses, malicious software or code when previously connected to non- agency networks such as the Internet and mobile networks. This presents a security risk as these devices could inadvertently be infecting other devices on networks, leveraging a user's legitimate access to steal an agency's sensitive or classified information or impacting the availability of networks. Validating a device as secure through the use of network access control before being granting access to networks will assist in reducing this risk. 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 anti-virus 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.

Bridging networks

Allowing devices that are connected to an agency controlled network to simultaneously connect to another non-agency controlled network allows the devices to act as a gateway by bridging the two networks. This opens an attack vector into an agency controlled network.

Intrusion detection and prevention

Special anomaly detection techniques can be used by IDSs and IPSs. IDSs will raise alerts to system administrators when any anomalous activity is detected on networks; while IPSs are capable of automatically quarantining suspected rogue devices from networks until they can be assessed by system administrators. Either an IDS or IPS should be used on networks. Further information on implementing these systems can be found in the Intrusion Detection and Prevention section of this chapter.

Using Virtual Local Area Networks

Limiting the sharing of a common switch between VLANs of differing security domains reduces the chance of data leaks that could occur due to VLAN vulnerabilities. Furthermore, disabling trunking on network devices that carry VLANs of differing security domains will also reduce the security risk of data leakage across the VLANs.

Configuration and administration of network devices

When administrative access is limited to originating from the most trusted network on a network device using VLANs, the risk of a data spill is reduced.

Using IP version 6

Introducing IP version 6 (IPv6) functionality into a network can potentially introduce additional security risks for an agency. 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 appropriate security measures have been put in place. Once agencies have completed the transition to a dual-stack environment or completely to an IPv6 environment, reaccreditation will assist in ensuring that the associated security measures for IPv6 are working effectively and redundant IPv4 systems are disabled.

Management traffic

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

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 insecure as they used trivial authentication methods. For this reasons, if an agency requires the use of SNMP, SNMPv3 should be used, otherwise SNMP should be disabled. Furthermore, all default SNMP community strings should be changed on network devices and access should be limited to read only access.

Additional information on business continuity and disaster recovery can be found in the Information Security Monitoring chapter.

Contacting Internet service providers

Internet service providers are in a unique position to assist in the mitigation of distributed denial-of-Service (DDoS) attacks. Proper coordination between agencies and their Internet service providers is essential to ensure resilience against such attacks.

Planning

Effective planning with an Internet service provider is a key part of defending against DDoS attacks.

Maintaining multiple Internet links

The use of multiple Internet links increases an agency's options for responding to DDoS attacks, and increases the complexity required for a successful DDoS attack.

Information covering wireless communications other than 802.11 Wi-Fi, such as 802.15 Bluetooth, can be found in the Communications Systems and Devices chapter. Additional information on encryption and key management requirements for wireless networks can be found in the Cryptography chapter.

Using wireless communications

DSD is the accreditation authority for TOP SECRET systems, which includes wireless TOP SECRET networks.

Wireless networks for public access

When an agency introduces wireless networks for public access, e.g. a public hotspot, such wireless networks must not be connected to, or share infrastructure with, any networks that communicate or store sensitive or classified information. Allowing a connection between such networks could provide an entry point for an intruder to target a connected network to steal sensitive or classified information or disrupt services.

Connecting wireless networks to fixed networks

When an agency has a business requirement to connect a wireless network to a fixed network, it is important that they consider the security risks. While fixed networks are often afforded a certain degree of physical security, wireless networks are often easily accessible outside of the controlled perimeter of an agency. Treating connections between wireless networks and fixed networks in the same way agencies would treat connections between fixed networks and the Internet can help protect against an intrusion originating from a wireless network against a fixed network. For example, by implementing a gateway to inspect and control the flow of information between the two networks.

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 network 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 on wireless access points will prevent 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 passwords, it is important to change the default SSID of wireless access points.

When changing the default SSID, it is important that it lowers the profile of 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 or within their premises, or the functionality of the 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 network. Some malicious actors will still be able to determine the SSID of wireless networks by capturing these requests and responses. 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. In addition, a risk exists where an intruder 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 intruder's wireless access point the intruder 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.

Static addressing

Assigning static IP addresses for devices accessing wireless networks can prevent a rogue device when connecting to a network from being assigned a routable IP address. However, some malicious actors 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.