The Australian Signals Directorate

Under the Defence White Paper 2013, the Defence Signals Directorate (DSD) was renamed the Australian Signals Directorate (ASD). For legal and policy purposes, all references to ASD should be taken to be references to DSD.

Purpose of the Australian Government Information Security Manual

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

Applicability

• 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 implement the Australian Government Protective Security Policy Framework
• organisations that have entered a Deed of Agreement with the Government to have access to sensitive or classified information.

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

Authority

• to provide material, advice and other assistance to Commonwealth and state authorities on matters relating to the security and integrity of information that is processed, stored or communicated by electronic or similar means
• to provide assistance to Commonwealth and state authorities in relation to cryptography, and communication and computer technologies.

This manual represents the considered advice of ASD provided in accordance with its designated functions under the ISA. Therefore agencies are not required as a matter of law to comply with this manual, unless legislation, or a direction given under legislation or by some other lawful authority, compels them to comply with it.

Legislation and legal considerations

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

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

Public systems

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

Format of the Australian Government Information Security Manual

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

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

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

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

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

Framework

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

System applicability

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

• G: Baseline 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 (i.e. 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.

ASD 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 information and systems. However, due to the differences between government agencies, there is no one-size-fits-all model for information security. The ISM aims to encourage agencies to take a risk-based approach to information security. This approach enables the flexibility to allow agencies to conduct their business and develop resilience in the face of a changing threat environment.

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

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

Applicability of controls

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

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

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

Identifying and analysing information security risks

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

Evaluating and treating information security risks

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

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

Treating a risk means that the consequences and/or likelihood of that risk is reduced. The controls included in this manual provide strategies to achieve this in different circumstances (in generic, agency and device non-specific terms).

Because an agency's risk owner - the agency head or their formal delegate - is accountable for an information or cyber security incident, they need to be made aware of any residual security risks to their information and systems through a formal approval process. Agency risk profiles will change over time as the threat environment, technology and agency business needs evolve, so it is important that any residual security risks are monitored.

System-specific security risks

While a baseline of controls is provided in this manual, agencies may have differing circumstances to those considered during the development of this manual. In such cases an agency needs to follow its own security risk management processes to determine its risk appetite and associated risk acceptance, risk avoidance and risk tolerance thresholds.

Documentation

Documenting information security risk management activities can help an agency ensure security risks are managed in a coordinated and consistent manner. Documentation also provides a standard against which compliance can be measured.

Authority to approve non-compliance

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

• ASD: Director ASD
• AA: Accreditation Authority

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

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

Compliance language

There are two categories of compliance associated with the controls in this manual - 'must' and 'should'. These compliance requirements are determined according to the degree of security risk an agency will be accepting by not implementing the associated control.

ASD's assessment of whether a controls is a 'must' or a 'should' is based on ASD's experience in providing cyber and information security advice and assistance for the Australian government and reflect what ASD assesses the risk level to be. Agencies may have differing risk environments and requirements, and may have other mitigations in place to reduce the residual risk to an acceptable level.

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 may be audited for compliance by the Australian National Audit Office (ANAO).

Complying with the Australian Government Information Security Manual

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

ASD produces information security policies and guidance in addition to this manual, such as the ACSI suite, consumer guides, hardening guides and Protect publications. These may address device- and scenario-specific security risks to information and systems, and accordingly may take precedence over the controls in this manual. Distinct time frames for compliance may also be specified.

Granting non-compliance

Non-compliance with 'must' and 'must not' controls are likely to represent a high security risk to information and systems. Non-compliance with 'should' and 'should not' controls are likely to represent a medium-to-low security risk to information and systems. The accreditation authority (the agency head or their formal delegate in most circumstances) is able to consider the justification for non-compliance and accept any associated residual security risk.

Non-compliance with controls where the authority is marked 'ASD' must be granted by the Director ASD.

If the agency head and accreditation authority form separate roles in an agency, the accreditation authority will need to ensure the agency head has appropriate oversight of the security risks being accepted on behalf of the agency. This helps to meet the PSPF's Protective Security Principles, which stipulate that agency heads need to understand, prioritise and manage security risks to prevent harm to official resources and disruption to business objectives. The authority for this control is listed as N/A as non-compliance approval cannot be sought under the ISM framework.

Justification for non-compliance

Without sufficient justification, and consideration of the security risks, the agency head or their authorised delegate will lack the appropriate information to make an informed decision on whether to accept the residual security risk and grant non-compliance to the system owner.

Consultation on non-compliance

When an agency processes, stores or communicates information on their systems that belongs to another agency or foreign government they have an obligation to inform that third party when they desire to risk manage the controls specified in this manual. If the agency fails to do so, the third party will be unaware that their information has been placed at a heightened risk of compromise. The third party is thus denied the opportunity to consider additional security measures for their information.

• 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

• to ensure that an accurate picture of the state of information security across government can be maintained
• to help inform incident response
• to use as feedback for the ongoing refinement of this manual.

Reviewing non-compliance

When seeking approval for non-compliance, the system owner must provide a justification for non-compliance, outline any alternative mitigation measures to be implemented and conduct an assessment of the security risks. As the justification for non-compliance may change, and the risk environment will continue to evolve over time, it is important that the system owner update their approval for non-compliance at least every two years. This allows for the appropriate authority to have any decision to grant non-compliance either reaffirmed or, if necessary, rejected if the justification or residual security risk is no longer acceptable.

Recording non-compliance

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

ASD

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

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

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

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

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

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

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.

Outsourced cloud computing

Cloud computing is a delivery model for information technology services. Where these services are provided by a third party (i.e. outsourced) cloud computing service provider, additional information security issues need to be considered. ASD's Cloud Computing Security Considerations document provides guidance for agencies considering implementing cloud computing services.

Additionally, the Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements establishes whole-of-government guidelines for outsourcing agency ICT functions and offshoring unclassified government information.

For further information on the use of virtualisation technologies to achieve functional separation, see the Standard Operating Environments section of the Software Security chapter.

A public cloud arrangement involves infrastructure which is shared via the Internet with many other organisations and other members of the public.

Risks of outsourcing ICT services

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

Outsourcing information technology services and functions outside of Australia, unless agencies are handling data considered publicly available, presents a high risk of unauthorised disclosure of agency information. chooseChoosing a vendor (either locally or foreign owned) that is located in Australia and stores, processes and manages sensitive data only within Australian borders minimises this risk. An additional risk is that foreign owned vendors operating in Australia may be subject to foreign laws such as a foreign government's lawful access to data held by the vendor.

Attorney-General's Department's Australian Government Policy and Risk management guidelines for the storage and processing of Australian Government information in outsourced or offshore ICT arrangements establishes a whole-of-government approach to how different categories of information are treated when considering offshore or outsourced ICT arrangements.

When agency functions and services are outsourced, agencies can lose oversight of how their information is handled and stored. Ensuring service providers seek agency approval before transmitting, processing or storing information offshore will minimise the risk of agencies losing control of their information.

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.

ASD expects that agencies using cloud computing services can meet the principles and objectives set out in the ISM. In some circumstances, agencies might need to seek a waiver for controls that aren't applicable to a specific cloud computing implementation or usage scenario. The accreditation process should involve communication from the provider to the client agency on areas of non-compliance to inform their risk decision. This is no different to the expectations leveraged on government agencies when using this manual. If a service provider is changing its system architecture to meet ISM controls for certification purposes, which is in turn weakening security in other parts of the implementation scenario, then it is likely not meeting the intent of the ISM. In such circumstances, ASD should be contacted for ISM interpretation advice.

Cloud Computing

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

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 engagement plan will help ensure an agency has a clear and coordinated approach when engaging and using service providers for the outsourcing and provision of information technology services and functions.

The Security Executive and their CISO role

The requirement to appoint a member of the Senior Executive Service, or in an equivalent management position, to the role of CISO does not require a new dedicated position to be created in each agency. This role is intended to be performed by the Security Executive, which is a position in each agency mandated by the Australian Government Protective Security Policy Framework. 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 CISO

• facilitating communications between security personnel, ICT personnel and business personnel to ensure alignment of business and security objectives
• providing strategic-level guidance for the agency security program
• ensuring compliance with national policy, standards, regulations and legislation.

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

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

• 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

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

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

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

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

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

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

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

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

• 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. ASD continually monitors the threat environment and conducts research into the security impact of emerging trends. With each release of this manual, controls can be added, rescinded or modified depending on changes in the threat environment.

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 of an IRP ensures that agencies have a baseline to develop an IRP with sufficient flexibility, scope and level of detail to address the majority of cyber security incidents that could arise.

Emergency procedures are a component of an agency's Information Security Management Framework, as mandated in the 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.

• audit:
  • reviewing the information security documentation
  • assessing the appropriateness of the controls applied to the system
  • assessing the effectiveness of the implementation of the controls
• certification:
  • providing independent assurance and acceptance of the audit
  • determining the residual security risk relating to the operation of the system
• accreditation:
  • formally accepting the residual security risk
  • awarding approval to operate the system.

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

This chapter details the ICT system accreditation process.

A system is defined as a related set of hardware and software used for the processing, storage or communication of information and the governance framework in which it operates.

TOP SECRET physical security certifications

This chapter does not discuss physical security certifications. Further information on TOP SECRET physical security certifications can be provided by ASD on request.

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.

• conducting an accreditation of the non-agency system
• having an information security review performed by an Information Security 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.

It should be noted that for Special Compartmented Information Facilities (SCIFs), ICT security is only one part of the requirements for gaining accreditation. Further information on gaining SCIF accreditation can be provided upon request from ASD.

Requirement for Australian control

Due to sensitivities associated with Australian Eyes Only (AUSTEO) and Australian Government Access Only (AGAO) systems, it is essential that control of such systems is maintained by Australian citizens working for the government of Australia.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Information Security Registered Assessor and received certification from ASD. Even though ASD may certify a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.

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 ASD and Information Security Registered Assessors.

Audits for SECRET and below systems can be undertaken by agency ITSMs and Information Security Registered Assessors.

Who can assist with an audit

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

• 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 Information Security Registered Assessor to undertake the audit.

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

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

Undertaking vulnerability management activities such as regular vulnerability assessments, analysis and mitigation are important as threat environments change over time. Vulnerability assessments allow agencies to identify security weaknesses caused by misconfigurations, bugs or flaws.

Conducting vulnerability assessments

Conducting vulnerability assessments prior to systems being used, and after significant changes, can allow the agency to establish a baseline for further information security monitoring activities.

Conducting vulnerability assessments annually can help ensure that the latest threat environment is being addressed and that systems are configured in accordance with associated information security documentation.

It is recommended that vulnerability assessments are conducted by suitably skilled personnel independent of the target of the assessment. Such personnel can be internal to an agency, such as an IT security team, or a third party such as an Information Security Registered Assessor. Where possible, it is advisable that system managers do not conduct vulnerability assessments themselves. This ensures that there is no conflict of interest, perceived or otherwise, and that the assessment is undertaken in an objective manner.

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

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

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

Analysing and mitigating vulnerabilities

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

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

• 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

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

• 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, this can only occur if personnel are well trained and aware of information security issues and know how to recognise possible cyber security incidents.

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

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

Cyber security incidents and outsourcing

The requirement to lodge a cyber security incident report applies even when an agency has outsourced some or all of its information technology functions and services.

Categories of cyber security incidents

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

Reporting cyber security incidents

Reporting cyber security incidents to an ITSM as soon as possible after it occurs provides management with a means to assess the overall damage to a system and to take remedial action, including seeking advice from ASD if necessary.

Reporting cyber security incidents to ASD

ASD uses cyber security incident reports as the basis for identifying and responding to cyber security events across government. Cyber security incident reports can also be used for developing new policies, procedures, techniques and training measures to prevent the recurrence of similar cyber security incidents across government. Agencies are recommended to coordinate their reporting of cyber security incidents to ASD e.g. through their ITSA.

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

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

Outsourcing and cyber security incidents

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

Cryptographic keying material

Reporting any cyber security incident involving the loss or misuse of cryptographic keying material is particularly important, as the confidentiality and integrity of secure communications relies on the secure use of keying material.

High Assurance cryptographic keying material

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

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

The management of physical and personnel security incidents is not covered in this section unless it directly impacts on the protection of systems (for example, breaching physical protection for a server room).

Cyber security incident management documentation

Documenting responsibilities and procedures for cyber security incidents in relevant SSPs, SOPs and the IRP ensures that when a cyber security incident does occur, personnel can respond in an appropriate manner. In addition, ensuring that users are aware of reporting procedures assists in capturing any cyber security incidents that an ITSM, ITSO or system owner 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 ASD CSIR scheme.

An affected system can be segregated by powering off the system, removing network connectivity to the device or applying access controls on information associated with the data spill to prevent access. However, it should be noted that powering off the system could destroy information that would be useful for forensics activities at a later date.

Handling malicious code infection

The guidance for handling malicious code infections is provided to help prevent the spread of the infection and to prevent reinfecting the system. An important consideration is the infection date of the machine. However, when determining the infection date, it is important to bear in mind that the record could be inaccurate as a result of the infection.

A complete operating system reinstallation, or an extensive comparison of characterisation information, is the only reliable way to ensure that malicious code is eradicated.

Taking immediate steps after the discovery of a malicious code infection can minimise the time and cost spent eradicating and recovering from the incident.

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

• Event logs
• Application whitelisting logs
• Antivirus logs
• Proxy logs
• VPN Logs
• DNS logs
• DHCP logs
• Mail server logs.

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

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 ASD's ability to assist agencies. ASD therefore requests that no actions which could affect the integrity of the evidence be carried out before ASD's involvement.

Post-incident analysis

System analysis after a successful intrusion helps to ensure the incident has been contained and removed from the system. After an incident has occurred, agencies may wish to perform post-incident analysis on their system by conducting a full network traffic capture. Agencies will be able to identify anomalous behaviour that may indicate an intruder persisting on the system, 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 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). For this reason, it is imperative information is encrypted to a sufficient level that if it was captured it would not be cost-effective to retrieve the original information.

The PSPF's Physical Security Management Guidelines - Security Zones and Risk Mitigation Control Measures states a Zone Five security area is required for the storage of codeword and TOP SECRET information. Secure transmission of this information is also a key consideration. Transmission of TOP SECRET or codeword information through lower security zone areas without encryption could allow a malicious actor to successfully access and exploit TOP SECRET infrastructure with relative ease. The only way to mitigate this threat is to apply strong encryption through the use of High Assurance products.

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. Information on the encryption of media can be found in the Cryptography 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.

• 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 Video Conferencing and 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.

• become familiar with their roles and responsibilities
• understand and support security requirements
• learn how to fulfil their security responsibilities.

Information security awareness and training responsibility

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

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

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

Degree and content of information security awareness and training

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

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

System familiarisation training

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

Security clearances - Australian and foreign

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

Documenting authorisations, security clearance and briefing requirements

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

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

Authorisation and system access

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

Recording authorisation for personnel to access systems

Retaining records of completed system account request forms signed by each user's manager will assist with maintaining user accountability. This is required to ensure there is a record of all personnel authorised to access a system, their user identification, who provided the authorisation, when the authorisation was granted and when the access was 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 ASD 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 Video Conferencing and 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

Monitoring 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 will assist agencies in enforcing their web usage policies.

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.

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

Peer-to-peer applications

Personnel using peer-to-peer file sharing applications are often unaware of the extent of files that are being shared from their workstation. In most cases peer-to-peer file sharing applications will scan workstations for common file types and share them automatically for public consumption. Examples of peer-to-peer file sharing applications include Shareaza, 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. Encouraging personnel to send and receive files via agency established methods such as email will ensure they are appropriately marked and scanned for malicious code.

Applicability of controls in this section

The controls in this section only apply to new cable installations or upgrades. When designing cable management systems, the Cable Labelling and Registration and Cable Patching sections of this chapter also apply. Agencies are not required to retro fit existing cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities. For deployable platforms or facilities outside of Australia, consult the 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.

Cables

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

Unclassified (DLM) 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. ASD 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.

Cable standards

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

Cable colours

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

Cable colours for foreign systems in Australian facilities

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

Cable colour non-compliance

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

Cable groupings

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

Fibre optic cables sharing a common conduit

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

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

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

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

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

Terminating cables in cabinets

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

Connecting cable reticulation systems to cabinets

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

Audio secure spaces

Audio secure spaces are designed to prevent audio conversations from being heard outside the walls. Penetrating an audio secure space in an unapproved manner can degrade this. Consultation with ASIO needs to be undertaken before any modifications are made to audio secure spaces. For physical security measures regarding Security Zone requirements, refer to the 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 cables and the type of connectors allocated to various systems.

Wall outlet colours

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

Wall outlet covers

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

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables as outlined in the 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 cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cables

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

Fibre cables are more difficult to tap than copper cables.

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

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

Inspecting cables

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

Cables sharing a common reticulation system

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

Cables in walls

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

Cabinet separation

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

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables as outlined in the 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 cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cables

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

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

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

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

Inspecting cables

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

Cables sharing a common reticulation system

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

Cables in walls

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

Wall penetrations

Penetrating a wall into a lesser-classified space by cables requires the integrity of the classified space to be maintained. All cables are encased in conduit with no gaps in the wall around the conduit. This prevents any visual access to the secure space. For physical security measures regarding Security Zone requirements refer to the 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 cables or cross patching.

Applicability of controls in this section

This section is to be applied in addition to common requirements for cables as outlined in the 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 cable infrastructure to align with changes to controls in this manual. The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the Emanation Security Threat Assessments section of this chapter.

Use of fibre optic cables

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

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

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

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

Inspecting cables

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

Cables sharing a common reticulation system

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

Enclosed cable reticulation systems

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

Covers for enclosed cable reticulation systems

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

Cables in walls

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

Cables in party walls

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

Sealing conduits

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

Sealing reticulation systems

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

Wall penetrations

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

Power reticulation

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

Cabinet separation

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

Applicability of controls in this section

The controls are applicable to all facilities that process sensitive or classified information. For deployable platforms or facilities outside of Australia, consult the 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 cable and fault finding easier.

Labelling cables

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

Cable register

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

Cable register contents

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

Cable inspections

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

Applicability of controls in this section

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

Terminations to patch panels

• 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

• reduces or eliminates the chances of cross patching between the systems
• reduces or eliminates the possibility of unauthorised personnel gaining access to TOP SECRET system elements.

Fly lead installation

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

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

Emanation security threat assessments in Australia

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

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

Emanation security threat assessments outside Australia

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

Early identification of emanation security issues

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

ICT equipment in highly sensitive areas

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

Exemptions for the use of infrared devices

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

Exemptions for the use of RF devices

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

• using the strongest security modes available
• educating users of the known weaknesses of the technology and their responsibilities in complying with policy in the absence of strong technical controls
• man-in-the-middle pairing
• maintaining an inventory of all Bluetooth devices addresses (BD_ADDRs).

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

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

RF devices in secured spaces

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

Detecting RF devices in secured spaces

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

RF controls

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

Further information on MFDs communicating via network gateways can be found in the Cross Domain 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 High Assurance products

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

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

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

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

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

Receiving fax messages

While the communications path between fax machines and MFDs may be appropriately protected, personnel need to be aware 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 MFD use

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

Information regarding mobile phones is covered in the 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 Video Conferencing and 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 and are susceptible to interception;. Using cordless telephones for sensitive or classified communications can result in disclosure of information to an unauthorised party through interception.

Cordless telephones with secure telephony devices

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

Speakerphones

As speakerphones are designed to pick up and transmit conversations in the vicinity of the device, using speakerphones in TOP SECRET areas presents a high audio security risk. However, if the agency is able to reduce the audio security risk through the use of an audio secure room that is secured during conversations, then they may be used. For physical security measures regarding Security Zone requirements refer to the 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.

PSPF mandatory requirement INFOSEC 4 requires agencies to implement the Strategies to Mitigate Targeted Cyber Intrusions (the Strategies) as outlined in this manual. 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.

• Application whitelisting
• Patch applications
• Patch operating systems
• Minimise administrative privileges.

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

Applicability and implementation priority

The applicability of ASD's Top 4 Strategies should be determined by the specific risks agencies are trying to mitigate. The Strategies are directed at the most common cyber 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 intrusions 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 this manual.

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 ASD'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 ASD for matters relating to the ISM.

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

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

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

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

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

ASD Evaluation Programs

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

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

The Evaluated Products List

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

Through the AISEP, ASD recognises evaluations from foreign Common Criteria schemes with equal standing. These products are listed on 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.

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

Protection Profiles

To assist agencies in selecting appropriate security products, ASD 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 ASD approved Protection Profile does address the defined threats in the required manner. ASD approved Protection Profiles are published on the ASD web site.

Products entered into the AISEP for evaluation against a ASD 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 ASD approved Protection Profile. ASD is currently establishing cryptographic testing as part of the AISEP Common Criteria evaluations. When this is established, evaluations against a ASD approved Protection Profile may undergo a simplified ACE process. This will assist in reducing the completion time taken to perform the evaluation.

To facilitate the transition to ASD approved Protection Profiles, a cap of Evaluation Assurance Level (EAL) 2 applies for all traditional EAL based evaluations performed in the AISEP, including those technologies with no existing ASD approved Protection Profile. EAL 2 represents the best balance between completion time and meaningful security assurance gains.

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

Product selection

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

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

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

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

Product selection preference order

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

While products evaluated against an ASD 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 ASD approved Protection Profiles.

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

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 and High Assurance products.

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.

• the intended environment of the product
• the types of intrusions that the product will defend against
• the resources of any potential intruders
• the likelihood of an intrusion
• the importance of maintaining confidentiality of the product purchase
• the importance of ensuring adherence to delivery time frames.

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

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

Leasing arrangements

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

Ongoing maintenance of assurance

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

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

Evaluated configuration

• 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 scheme, information is available from the product vendor regarding the product's installation, administration and use. Additional information is available in the Security Target and Certification Report. Configuration guidance for High Assurance products can be obtained from ASD.

Use of evaluated products in unevaluated configurations

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

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

Non-essential labels

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

Classifying ICT equipment

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

Labelling ICT equipment

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

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

Labelling High Assurance products

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

Information relating to the sanitisation of ICT equipment and media can be found in the 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 companys 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.

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

Disposal of ICT equipment

When disposing of ICT equipment, agencies need to sanitise any media in the equipment that is capable of storing sensitive or classified information, remove the media from the equipment and dispose of it separately or destroy the equipment in its entirety. Removing labels and markings indicating the classification, 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.

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

ICT equipment located overseas that has processed or stored 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 caveated information on ICT equipment is not recoverable.

Sanitising printers and MFDs

Printing random text with no blank areas on each colour printer cartridge or MFD print drum ensures that no residual information exists within the print path. ASD is able to, upon request, 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 following controls.

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 fax machines

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

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

Information relating to classifying and labelling ICT equipment can be found in the 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.

Removable media policy

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

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

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

Reclassification and declassification procedures

• the consequences of damage from unauthorised disclosure or misuse
• the effectiveness of any sanitisation or destruction procedure used
• the intended destination of the media.

Classifying media storing information

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

Classifying media connected to systems

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

Reclassifying media

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

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

Labelling media

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

Labelling sanitised media

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

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 control and data loss prevention software allows greater control over media that can be connected to a system and the manner in which it can be used. This assists in preventing unauthorised media being connected to a system and, if desired, preventing information from being written to it.

Media can also be prevented from connecting to a system by physical means including, 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. Applying encryption to media 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. Additionally, using device access control software on workstations in case users are unaware of, or choose to ignore, security requirements for media provides a technical control to enforce the policy.

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 sensitivity or classification of the media, nor does it involve the destruction of media.

Product selection

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

Hybrid hard drives

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

Solid state drives

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

Government systems

All references to 'Unclassified (DLM)' in the tables in this section relate to media containing unclassified but official/sensitive information not intended for public release, such as DLM information. ASD 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

When attempts to sanitise media are unsuccessful, the only way to provide complete assurance the data is erased is to destroy the media. Additionally, some types of media cannot be sanitised and therefore must be destroyed. Refer to the 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, destroying the media as prescribed in the Media Destruction section of this chapter is the only way to provide complete assurance classified information no longer persists.

Treatment of volatile media following sanitisation

Published literature 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 is required to remain at this classification, even after sanitisation.

Circumstances preventing reclassification of volatile media

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

Non-volatile magnetic media sanitisation

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

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

Treatment of non-volatile magnetic media following sanitisation

Highly classified non-volatile magnetic media cannot be sanitised below its original classification due to concerns with the sanitisation of the host protected area, device configuration overlay table and growth defects table. The sanitisation of TOP SECRET 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. ASD 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.

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

Media destruction equipment

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

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

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

• Listed in the ASIO Security Equipment Catalogue; or
• Meeting the ASIO Security Equipment Guides, (i.e. SEG-009 Optical Media Shredders, and SEG-018 Destructors).

The ASIO Security Equipment Catalogue may be ordered via the SCEC website (scec.gov.au). The ASIO Security Equipment Guides are available from the Protective Security Policy GOVDEX Community or ASIO - T4 by email request.

Storage and handling of media waste particles

Following destruction, normal accounting and auditing procedures do not apply for media. 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 material destruction

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

Outsourcing media destruction

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

Transporting media external destruction

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

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 recorders, removable media interfaces, 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.

• 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. ASD 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. It is recommended agencies consult ASD's Protect publication Assessing Security Vulnerabilities and Patches for guidance on patching, available on the ASD website.

It is recommended that patches that address extreme-risk vulnerabilities, such as vulnerabilities enabling unauthorised code execution by an intruder using the Internet are deployed within two days. 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 often incorporate newer security technologies and mitigate known vulnerabilities. The latest versions of operating systems can offer significant improvements in security features and stability.

Patching servers is not a trivial task and involves testing and planning. Agencies should weigh up the risk of holding off on patching while patches are tested against the threat of intrusion in this interim period.

As firmware provides the underlying functionality for hardware it is essential that the integrity of any firmware images or updates are maintained. Since firmware controls the low-level operations of a device, 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, ASD will conduct an assessment of the patch and might revise the product's usage guidance. Where required, ASD will subsequently conduct an assessment of the cryptographic vulnerability and might revise usage guidance in the Consumer Guide for the product or product-specific doctrine.

If a patch for a High Assurance product is approved for deployment, ASD will inform agencies of the timeframe in which the patch is to be deployed.

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 mitigating access to 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 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. Due to vulnerabilities in virtualised environments, virtualisation is not approved as a domain separation method.

Specifically, an intruder could achieve privilege escalation in guest operating system through the exploitation of vulnerabilities in virtualisation products. This can be performed without breaching the separation. Additionally, vulnerabilities in virtualisation products can allow a malicious actor to gain access to one virtual machine from another residing on the same hardware, breaching the security boundary. This could also occur as a result of a misconfiguration of the virtualisation software by the agency which, unbeknownst to the agency, results in the weakening or elimination of the security boundary between two virtual machines.

Guidance on the agency use of virtualisation in cloud computing scenarios can be found in the Industry Engagement and Outsourcing section of the Information Security Governance chapter.

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.

• 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

• 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. It is preferable that agencies are proactive in defining the applications permitted to execute, rather than using default lists in application whitelisting software. It is important that application whitelisting does not replace antivirus and other Internet security software already in place on a 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

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.

• the URL and URL parameters
• HTML form data
• cookie values
• HTTP request headers.

• 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 AACAs 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 is often installed with most features enabled by default as well as being pre-configured with a sample database and anonymous user accounts for testing purposes. Additional functionality often brings with it an increased risk. Thus, disabling or removing DBMS software features and stored procedures that are not required will minimise the risk. Furthermore, removing all sample databases on database servers will minimise the attack surface of the 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 AACAs 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 ASD'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.

Monitoring email usage

Monitoring 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 will help enforce email usage policy.

Public web-based email services

Allowing staff to access web-based email services can pose a security risk if there are insufficient malicious web content filtering controls in place to mitigate malicious web mail attachments. Additionally the agency is reliant upon the web mail provider implementing mitigations such as SPF and DomainKeys.

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

Socially engineered emails

Socially engineered emails are one of the most common techniques used to spread malicious software. 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 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 common vector for cyber intrusion. 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.

• 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 AUSTEO and AGAO 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 through 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. For this reason, it is important stronger authentication is also used for positions of trust, such as an account that is able to approve financial transactions or accounts that have access to sensitive information. Using multi-factor authentication for positions of trust, including access to sensitive information and databases, and privileged accounts provides a secure authentication mechanism.

The use of multi-factor authentication for remote access does not fully mitigate users entering their passphrase on a compromised computing device. An adversary may obtain a user's passphrase when it is entered into a less trustworthy computing device used for remote access. The adversary may then use this passphrase as part of a subsequent intrusion, for example, by either gaining physical access to a corporate workstation and simply logging in as the user, or by using this passphrase to access sensitive corporate resources as part of a remote intrusion against the corporate network. Mitigations include using multi-factor authentication for all user logins including corporate workstations in the office, or ensuring that user passphrases for remote access are different to passphrases used for corporate workstations in the office. 'Remote access' constitutes remote desktop access, and does not include web-based access to DMZ resources (for example, web portal access).

Some methods of multi-factor authentication are more effective than others. It is therefore essential to correctly implement and configure your multi-factor authentication solution on your network to ensure vulnerabilities are minimised. Further guidance can be found in ASD'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

Good passphrase management practices provide a means of limiting the consequences of the disclosure of passphrases to unauthorised users. Requiring a passphrase to be changed at least every 90 days limits the time period in which a disclosed password could be used by an authorised user.

For the enforcement of password changing policies to be effective, steps also need to be taken to ensure users choose strong passwords and prevent users reverting to their old password or selecting new passwords which could be easily guessed based on knowledge of the user's previous password.

• 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.
• Disallowing predictable reset passphrases reduces the security risk of brute force attacks and passphrase guessing attacks.
• 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.
• 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.

• 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 users of their responsibilities when using the system.

Displaying when a 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.

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

• 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 AUSTEO or AGAO information.

Remote access

Remote access is user access to agency systems originating outside an agency network. It does not include web-based access to DMZ resources.

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.

Remote privileged access

Remote privileged access by a privileged user to an agency system via a less trusted security domain (for example, the Internet) may represent additional risk to the system. Controls in this section aim to prevent escalation of user privileges from a compromised remote access account.

Remote privileged access does not include privileged access across disparate physical sites that are within the same security domain or privileged access across remote sites that are connected via trusted infrastructure. Privileged access of this nature faces different threats to those discussed above. Ensuring robust processes and procedures are in place within an agency to monitor and detect the threat of a malicious insider are the most important measure for this scenario.

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

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 centralised audit system to correlate logs from multiple sources to identify patterns of suspicious behaviour. This functionality may be provided by existing systems such as the Security Information and Event Management solution. Automated solutions are available to help agencies proactively identify such patterns.

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

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

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

Further information on remote access to privileged accounts can be found in the Remote Access section of the Access Control chapter. The requirements for using multi-factor authentication for remote access are included in the Identification and Authentication section of the Access Control Chapter. Further information about network segmentation for security purposes can be found in the Network Design and Configuration section of the Network Security chapter.

Separate administrator workstations

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

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

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

Multi-factor authentication

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

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

Agencies should refer to the Identification and Authentication section of the Access Control chapter for further multi-factor authentication guidance.

Dedicated administration zones and communication restrictions

• virtual LANs
• firewalling
• Network Access Control
• IPsec Server and Domain Isolation

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

Restriction of management traffic flows

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

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

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

• between the 'Administrator Workstation Zone' and the 'Jump Host Zone', and;
• between the 'Jump Host Zone' and the 'Critical Asset Zone'.

All other traffic is blocked as there is no reason for management traffic to flow between the other zones since jump hosts have been implemented and a dedicated administrator workstation zone has been created.

Jump boxes

The use of jump boxes as a form of 'management proxy' can be an effective way of simplifying and securing administration activities.

• An efficient and effective focal point to perform multi-factor authentication
• A single place to store and patch management tools
• Simplifies the implementation of the management traffic filtering
• A focal point for logging, monitoring and alerting.

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

In a jump box setup and administrator would first connect and authenticate to the jump box, then RDP or SSH to the target server.

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

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.

Approval of all changes by a change management process involving representatives from all parties involved in the management of the network 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 which is 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.

• 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, it is important to update the network diagram 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. These audit methods aim 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 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 protecting sensitive information and critical services (such as user authentication and user directory information). For example, one network zone may contain user workstations while authentication servers are in a separate zone. The growth of social engineering as a method to 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.

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.

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, or 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. Using either an IDS or IPS on networks is an effective way of identifying and responding to known intrusions profiles. Further information on implementing these systems can be found in the Intrusion Detection and Prevention section of this chapter.

Using Virtual Local Area Networks

Using network devices to only manage VLANs of different security domains at the same classification and not to manage VLANs of different security classifications or sensitivities will assist in reducing the security risk of data spills across VLANs. 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.

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. Disabling SNMP, or if required using SNMPv3, mitigates this risk. Furthermore, changing all default SNMP community strings on network devices and limiting access to read only access is desirable.

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

ASD 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, connecting such wireless networks to, or sharing infrastructure with any networks that communicate or store sensitive or classified information creates 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 the new SSID 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. Additionally, by disabling SSID broadcasting agencies will make it more difficult for users to connect to wireless networks as legacy operating systems only have limited support for hidden SSIDs. Furthermore, a risk exists where an 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. For these reasons, it is recommended agencies enable SSID broadcasting.

Static addressing

Assigning static IP addresses for devices accessing wireless networks can prevent a rogue device when connecting to a 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.

Media Access Control address filtering

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

802.1X authentication

Where an agency chooses to deploy a secure a wireless network, they can choose from a number of Extensible Authentication Protocol (EAP) methods that are supported by the Wi-Fi Protected Access 2 (WPA2) protocol.

Agencies deploying a secure wireless network can choose WPA2-Enterprise with EAP-Transport Layer Security (EAP-TLS), WPA2-Enterprise with EAP-Tunnelled Transport Layer Security (EAP-TTLS) or WPA2-Enterprise with Protected EAP (PEAP) to perform mutual authentication.

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

The EAP-TTLS/MSCHAPv2, or simply EAP-TTLS, method used with WPA2-Enterprise is generally supported through the use of third party software. It has support in multiple operating systems but does not have native support in Microsoft Windows. EAP-TTLS is different to EAP-TLS in that devices do not authenticate to the server when the initial TLS tunnel is created. Only the server authenticates to devices. Once the TLS tunnel has been created, mutual authentication occurs through the use of another EAP method. An advantage of EAP-TTLS over PEAP is that a username is never transmitted in the clear outside of the TLS tunnel. Another advantage of EAP-TTLS is that it provides support for many legacy EAP methods, while PEAP is generally limited to the use of EAP-MSCHAPv2.

PEAPv0/EAP-MSCHAPv2, or simply PEAP, is the second most widely supported EAP method after EAP-TLS. It enjoys wide support in wireless access points and in numerous operating systems such as Microsoft Windows, Linux and Apple OS X. PEAP operates in a very similar way to EAP-TTLS by creating a TLS tunnel which is used to protect another EAP method. PEAP differs from EAP-TTLS in that when the EAP-MSCHAPv2 method is used within the TLS tunnel, only the password portion is protected and not the username. This may allow an intruder to capture the username and replay it with a bogus password in order to lockout the user's account, causing a denial of service for that user. While EAP-MSCHAPv2 within PEAP is the most common implementation, Microsoft Windows supports the use of EAP-TLS within PEAP, known as PEAP-EAP-TLS. This approach is very similar in operation to traditional EAP-TLS yet provides increased protection, as parts of the certificate that are not encrypted with EAP-TLS are encrypted with PEAP-EAP-TLS. The downside to PEAP-EAP-TLS is its support is limited to Microsoft products.

Ultimately, an agency's choice in authentication method will often be based on the size of their wireless deployment, their security requirements and any existing authentication infrastructure they plan on utilising. If an agency is primarily motivated by security they can implement either PEAP-EAP-TLS or EAP-TLS. If they are primarily motivated by flexibility and legacy support they can implement EAP-TTLS. If they are primarily motivated by simplicity they can implement PEAP with EAP-MSCHAPv2.

Evaluation of 802.1X authentication implementation

The security of 802.1X authentication is dependent on three main elements and how they interact with each other. These three elements include supplicants (clients) that support the 802.1X authentication protocol, authenticators (wireless access points) that facilitate communication between supplicants and the authentication server, and the authentication server (RADIUS server) that is used for authentication, authorisation and accounting purposes. To provide assurance that these elements have been implemented appropriately, supplicants, authenticators and the authentication server used in wireless networks must have completed an appropriate evaluation. For PROTECTED networks this entails choosing products that have successfully completed an ACE, while for networks classified CONFIDENTIAL and above this entails choosing High Assurance products.

Issuing certificates for authentication

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

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

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

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

Using commercial certification authorities for certificate generation

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

Caching 802.1X authentication outcomes

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

Remote Authentication Dial In User Service authentication

Separate to the 802.1X authentication process is the RADIUS authentication process that occurs between wireless access points and the RADIUS server. During the initial configuration of wireless networks using 802.1X authentication, a shared secret is entered into either the wireless access points or the RADIUS server. If configured on the wireless access points, the shared secret is sent to the RADIUS server via the RADIUS protocol, and vice versa if configured on the RADIUS server. This shared secret is used for both RADIUS authentication and confidentiality of RADIUS traffic. An intruder that is able to gain access to the RADIUS traffic sent between wireless access points and the RADIUS server may be able to perform an offline dictionary attack to recover the shared secret. This in turn allows the intruder to decrypt all communications between wireless access points and the RADIUS server. To mitigate this security risk, communications between wireless access points and a RADIUS server must be encapsulated with an additional layer of encryption using an appropriate encryption product.

Encryption

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

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

Interference between wireless networks

Where multiple wireless networks are deployed in close proximity, there is the potential for interference to impact on the availability of the network, especially when networks are operating on commonly used default channels of 1 and 11. Sufficiently separating wireless networks through the use of channel separation can help reduce this risk. This can be achieved by using wireless networks that are configured to operate on channels that are at least one apart. For example, channels 1, 3 and 5 could be used to separate three wireless networks.

Protecting management frames on wireless networks

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

Bridging networks

When connecting devices via Ethernet to an agency's fixed network, agencies need to be aware of the security risks posed by active wireless functionality on devices. Devices will often automatically connect to any open wireless networks they have previously connected to, which a malicious actor can use to masquerade and establish a connection to the device. This device could then be used as a bridge to access the agency's fixed network. Disabling wireless functionality on devices, preferably by a hardware switch, whenever connected to a fixed network can prevent this from occurring. Additionally, devices do not have to be configured to remember and automatically connect to open wireless networks that they have previously connected to.

Wireless network footprint

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

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

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

Video and voice-aware firewall requirement

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

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

Hardening video conferencing and IP telephony infrastructure

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

• have a fully patched operating system
• have fully patched software
• run only required services
• use encrypted non-replayable authentication
• apply network restrictions that only allow secure SIP traffic and secure Real-time Transport Protocol (RTP) traffic from video conferencing units and IP phones on a VLAN to reach the server.

Video and voice-aware firewalls

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

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

Protecting video conferencing and IP telephony traffic

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

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

Establishment of secure signalling and data protocols

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

Local area network traffic separation

Availability and quality of service are the main drivers for logical and physical separation.

Video conferencing unit and IP phone setup

Video conferencing units and IP phones need to be hardened and logically or physically separated from the data network to ensure they do not provide an easy entry point to the network for an intruder. USB ports on video conferencing units and IP phones may be used to circumvent USB workstation policy while unprotected management interfaces may be used to upload malicious firmware for call recording/spoofing and entry into the data network. Blocking by default unauthorised devices and unauthenticated devices will reduce the security risk of a denial of service.

Video conferencing unit and IP phone connections to workstations

Availability and quality of service are the main drivers for logical and physical separation.

Lobby and shared area phones

Lobby IP phones are in public areas and may give an intruder the opportunity to access the internal data network (depending on separation arrangements) by replacing the IP phone with another device, or installing a device in-line. There are also the security risks of social engineering (since the call may appear to be internal) and data leakage from poorly protected voicemail boxes.

For further information on what constitutes a 'public area', refer to the Attorney-General's Department's Security zones and risk mitigation control levels document.

Software used for softphones and webcams

Software used for softphones and webcams can introduce additional vulnerabilities into the network as they are exposed to threats from the data network via the workstation and can subsequently be used to gain access to the video conferencing or IP telephony network.

Softphones and webcams typically require workstation to workstation communication on (potentially) a number of randomly assigned ports to facilitate RTP data exchange. This presents a security risk as workstations generally should be separated, using host-based firewalls that deny all connections between workstations, to make malicious code propagation inside the network difficult.

On workstations using softphones and webcams, separate network cards can facilitate a simple VLAN separation. Host-based firewalls ensure a minimal set of ports are exposed to a minimal set of workstations.

Workstations using USB phones and webcams

Adding USB phones and webcams to a whitelist of allowed USB devices on a workstation will assist with restricting access to only authorised devices, and allowing the Standard Operating Environment to maintain defences against removable media storage and other unauthorised USB devices.

Developing a denial of service response plan

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

• how to identify the source of the denial of service, either internal or external (location and content of logs)
• how to minimise the effect on video conferencing and IP telephony of a denial of service of the data network (for example, Internet or internal denial of service), including separate links to other office locations and quality of service prioritisation
• strategies that can mitigate the denial of service (banning certain devices/IPs at the call controller and firewalls, implementing quality of service, changing authentication, changing dial-in authentication
• alternative communication options (such as personal mobile phones) that have been identified for use in case of an emergency.

Methods of infections or delivery

• files containing macro viruses or worms
• email attachments and web downloads with malicious active content
• executable code in the form of applications
• security weaknesses in a system
• security weaknesses in an application
• contact with an infected system or media.

Intrusion detection and prevention strategy

An IDS/IPS when configured correctly, kept current and supported by appropriate processes can be an effective way of identifying and responding to known intrusion profiles. Appropriate resources need to be allocated to an IDS/IPS to allow maintenance and monitoring including training and time assigned to the validation of alerts and the tuning of rules.

IDSs and IPSs in gateways

If a firewall is configured to block all traffic on a particular range of port numbers, then IDSs/IPSs should inspect traffic for these port numbers and generate an alert if they are detected.

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

Signature-based intrusion detection and prevention

When signature-based intrusion detection and prevention is used the effectiveness of IDSs/IPSs will degrade over time as new intrusion methods are developed. It is for this reason that signatures for IDSs/IPSs need to be kept current to identify the latest intrusion methods.

Configuring IDSs and IPSs

Testing IDS/IPS rule sets prior to implementation can assist in ensuring they perform as expected and do not cause any undesired activity on the network.

Event management and correlation

Deploying tools to manage the archival and correlation of events of interest across all networks helps identify suspicious patterns in information flows.

Host-based IDSs and IPSs

Host-based IDSs (HIDSs) and Host-based IPSs (HIPSs) use behaviour-based detection schemes and can therefore assist agencies in identifying anomalous behaviour, such as process injection, keystroke logging, driver loading and call hooking, as well as detecting malicious code that has yet to be identified by vendors. Importantly, however, some antivirus products are evolving into converged endpoint security products that incorporate HIDS/HIPS functionality.

For more information on ASD's EPL see the Product Security section.

Peripheral switches

The level f assurance needed in a peripheral switch is determined by the highest and lowest sensitivity or classification of systems connected to the switch.

When accessing systems through a peripheral switch it is important that sufficient assurance is available in the operation of the switch to ensure that information does not accidently pass between the connected systems.

Peripheral switches for particularly sensitive systems

AUSTEO and AGAO systems require additional security measures to be put in place when connecting to other systems.

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 ASD Approved Cryptographic Algorithms and ASD 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 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 an ASD Cryptographic Evaluation (ACE). Such requirements supplement this manual and where conflict occurs the product specific requirements take precedence.

Using products with ASD Approved Cryptographic Algorithms and Protocols

Where this manual states a requirement for a product that implements an ASD Approved Cryptographic Algorithm (AACA) or ASD Approved Cryptographic Protocol (AACP) to be used to provide protection for information at rest or in transit, the product does not need to have undergone a ACE.

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

ASD 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

Due to the sensitivities associated with AUSTEO and AGAO information, 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

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

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

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

AACAs

There is no guarantee 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.

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

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

• Secure Hashing Algorithm 2 (SHA-224, SHA-256, SHA-384 and SHA-512).

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

Suite B

• 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 ASD in specific configurations and evaluated implementations for the protection of highly classified (CONFIDENTIAL, SECRET and TOP SECRET) information.

Using AACAs

If a product implementing an AACA 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 an AACA, agencies can ensure that only the AACA 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 Elliptic Curve Diffie-Hellman

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 ASD for use in specific configurations and evaluated implementations for the protection of CONFIDENTIAL, SECRET and TOP SECRET information.

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

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

High Assurance 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 Assurance evaluation by ASD. Further information on High Assurance protocols can be obtained by contacting ASD.

AACPs

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

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

If a product implementing an AACP 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 an AACP, agencies can ensure that only the AACA 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 AACPs 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.

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

The terms SSL and TLS have traditionally been used interchangeably. As SSL 3.0 is no longer a AACP, for the purposes of this document instances of 'SSL' refer to SSL version 3.0 and below, and 'TLS' refers to TLS 1.0 and beyond.

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

Further information on handling 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 AACPs also need to be consulted in the ASD 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 AACPs also need to be consulted in the ASD 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 S/MIME

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 AACPs also need to be consulted in the ASD 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 AACAs 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 a High Assurance product is being used, agencies are advised to consult the respective equipment ACSI.

Cryptographic systems

Cryptographic systems comprise of equipment, either High Assurance or commercial and keying material. Keying material will be symmetric, asymmetric or certificates in nature. 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 keying material

If keying material or certificates used for encrypting messages is suspected of being compromised (that is, stolen, lost, copied, loss of control or transmitted over the Internet), then no assurance can be placed in the integrity of subsequent messages that are encrypted in that 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.

In accordance with ACSI 107 and the equipment specific doctrine, agencies are to immediately report to ASD any High Assurance keying material or certificates when they are suspected of being compromised.

High Assurance Equipment

ACSI 53 and ACSI 105 provide product specific policy for High Assurance equipment.

Transporting commercial grade cryptographic equipment

Transporting High Assurance cryptographic equipment in a keyed state is permitted provided, the movement of the equipment complies with the requirements of the equipment specific doctrine and ACSI 103.

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 keying material and High Assurance equipment, and the keys it stores, provides a significant security function for cryptographic systems, agencies must be able to account for all keying material and High Assurance cryptographic equipment.

Compliance checks

High Assurance cryptographic systems compliance checks are used to verify that all account personnel are following proper safeguarding and accounting procedures for keying material and High Assurance equipment.

Inventory

An inventory (also referred to as a muster) is a list of all keying material and High Assurance COMSEC equipment on a COMSEC account which is submitted to the issuing authority for comparison and acquittal. In accordance with ACSI 53, Communications Security Handbook (Rules and Procedures for the Agency COMSEC Officer and Custodian), an inventory is required to be summited twice yearly to the issuing authority.

Area security and access control

As High Assurance cryptographic systems protect contains particularly sensitive information, additional physical security measures need to be applied. 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 High Assurance 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 High Assurance 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 High Assurance cryptographic systems and their material.

Access register

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

Gateways act as information flow control mechanisms at the network layer and may also control information at the transport, session, presentation and application layers of the Open System Interconnect (OSI) model.

• System Accreditation
• Information Security Monitoring
• Cyber Security Incidents
• Physical Security for Systems
• Product Security
• Access Control
• Network Security
• Data Transfers and Content Filtering.

Deploying gateways

This section describes a baseline for deploying gateways. Agencies need to consult additional sections of this manual depending on the specific type of gateways deployed.

For devices used to control data flow in bi-directional gateways the Firewalls section of this chapter needs to be consulted.

For devices used to control data flow in uni-directional gateways the Diodes section of this chapter needs to be consulted.

For both bi-directional and uni-directional gateways the Data Transfers and Content Filtering chapter needs to be consulted for requirements on appropriately controlling data flows.

Using gateways

The system owner of the higher security domain of connected security domains would be most familiar with the controls required to protect the more sensitive information and as such is best placed to manage any shared components of gateways. However, in some cases where multiple security domains from different agencies are connected to a gateway it may be more appropriate to have a qualified third party manage the gateway on behalf of all connected agencies.

Configuration of gateways

Given the criticality of gateways in controlling the flow of information between security domains, any failure - particularly at the higher classifications - may have serious consequences. Hence mechanisms for alerting personnel to situations that may cause cyber security incidents are especially important for gateways.

Operation of gateways

Providing a sufficient logging and auditing capability helps detect cyber security incidents including attempted network intrusions, allowing the agency to implement counter-measures to reduce the security risk of future attempts.

Storing event logs on a separate secure log server increases the difficulty for intruders to delete logging information in an attempt to destroy evidence of their intrusion.

Demilitarised zones

Demilitarised zones are used to prevent direct access to information and services on internal networks. Agencies that require certain information and services to be accessed from the Internet can place them in the less trusted demilitarised zone instead of on internal networks.

Security risk assessment

Performing a security risk assessment on the gateway and its configuration before its implementation assists in the early identification and mitigation of security risks.

Security risk transfer

Gateways can connect networks in different security domains including across agency boundaries. As a result, all system owners must understand and accept the security risks from all other networks before gateways are implemented.

Configuration control

Changes that could introduce vulnerabilities, new security risks or increase security risks in a gateway need to be appropriately considered and documented before being implemented.

Testing of gateways

Testing security measures on gateways assists in ensuring that the integrity of the gateway is being maintained. Intruders may be aware of regular testing activities. Therefore, performing testing at irregular intervals will reduce the risk that an intruder could exploit regular testing activities.

Shared ownership of gateways

As changes to a security domain connected to a gateway potentially affects the security posture of other connected security domains, system owners need to formally agree to be active information stakeholders in other security domains to which they are connected via a gateway.

User training

It is important that users know how to use gateways securely. This can be achieved through appropriate training before being granted access.

Administration of gateways

Administrator privileges need to be minimised and roles need to be separated to minimise the security risk posed by a malicious user with extensive access to the gateway.

Providing system administrators with formal training will ensure they are fully aware of and accept their roles and responsibilities regarding the management of gateways. Formal training could be through commercial providers, or simply through SOPs or reference documents bound by a formal agreement.

User authentication

Authentication to networks as well as gateways can reduce the security risk of unauthorised access and provide an auditing capability to support the investigation of cyber security incidents. Additional information on multi-factor authentication is in the Access Control chapter.

ICT equipment authentication

Authenticating ICT equipment to networks accessed through gateways assists in preventing unauthorised ICT equipment connecting to a network. For example, using 802.1x.

CDS provide information flow control mechanisms at each layer of the OSI model with a higher level of assurance than typical gateways. This section extends the preceding Gateways section. CDS systems must apply controls from both the Gateways and Cross Domain Solutions section.

• System Accreditation
• Information Security Monitoring
• Physical Security for Systems
• Product Security
• Access Control
• Network Security
• Data Transfers and Content Filtering.

Deploying CDS

This section describes a baseline for deploying CDS. Agencies need to consult additional sections of this manual depending on the specific type of CDS deployed.

Agency personnel involved in the planning, analysis, design, implementation or assessment of CDS should refer to the ASD document Guide to the Secure Configuration of Cross Domain Solutions, available from https://members.onsecure.gov.au/ or on request from asd.assist@defence.gov.au. This contains a detailed, comprehensive description of controls specific to CDS that are essential for applying a risk-based approach to CDS implementations.

For devices used to control data flow in bi-directional gateways the Firewalls section of this chapter needs to be consulted.

For devices used to control data flow in uni-directional gateways the Diodes section of this chapter needs to be consulted.

For both bi-directional and uni-directional gateways the Data Transfers and Content Filtering chapter needs to be consulted for requirements on appropriately controlling data flows.

Types of CDS

This manual defines three types of CDS: Access CDS, Multilevel CDS and Transfer CDS.

An Access CDS provides the user with access to multiple security domains from a single device.

A Transfer CDS facilitates the transfer of information, in one (uni-directional) or multiple (bi-directional) directions between different security domains.

A Multilevel CDS enables access, based on authorisations, to data at multiple classifications and sensitivity levels.

Applying the controls

For the purposes of gateways and CDS, the gateway assumes the highest sensitivity or classification of the connected security domains.

Allowable CDS

There are significant security risks associated with connecting highly classified systems to the Internet or to a sensitive or lesser classified system. A malicious actor having control of or access to a gateway can invoke a serious security risk.

Implementing CDS

CDS should implement products that have completed a High Assurance evaluation. ASD's EPL includes products that have been evaluated in the High Assurance scheme. However, the EPL is not an exhaustive list of products which are suitable for use in a given CDS. While CDS are not listed on the EPL, ASD can provide guidance on agency implementation in response to a formal request for advice and assistance.

Connecting multiple sets of gateways and CDS increases the threat surface and, consequently, the likelihood and consequence of a network compromise. When a gateway and a CDS share a common network, it exposes the higher security domain (such as a classified agency network) to exploitation from the lower security domain (such as the Internet).

Operation of CDS

In addition to the controls listed in the Event Logging and Auditing section in the Access Control chapter, CDS have comprehensive logging requirements to establish accountability for all actions performed by users. Effective logging practices can increase the likelihood that malicious behaviour will be detected.

Separation of data flows

Gateways connecting highly classified systems to other potentially Internet-connected systems need to implement diodes, content filtering and physically separate paths to provide stronger control of information flows. Such gateways are generally restricted to highly formatted formal messaging traffic.

Trusted sources

Trusted sources include security personnel such as the CISO, the ITSA, ITSMs and ITSOs.

When a control specifies a requirement for a diode or filter, the appropriate information can be found in the Diodes section of this chapter. Additional information that also applies to topics covered in this section can be found in the Data Transfers and Content Filtering chapter. The Product Security chapter provides advice on selecting evaluated products.

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

Firewalls

Where an agency connects to another agency over public network infrastructure both agencies need to implement traffic flow filtering in their gateway environment to protect themselves from intrusions that originate outside of their environment.

• the public network infrastructure is used only as a transport medium
• the public network infrastructure is not a logical source or destination of data
• link encryption is used in accordance with the Cryptography chapter.

A proxy is a proxy server that acts as an intermediary for requests from within the agency seeking resources external to the agency. A client connects to the proxy server, requesting some service, such as a file, connection, website, or other resource, available from a source external to the agency. The proxy server evaluates the request according to its filtering rules.

The Network Device Protection Profile (NDPP), defined by the United States' National Information Assurance Partnership, outlines the security requirements for a network device (as opposed to an end-user device) that can be connected to a network.

Firewalls for particularly sensitive networks

As AUSTEO and AGAO networks are particularly sensitive, additional security measures need to be put in place when connecting them to other networks.

Additional information can be found in the Data Transfers and Content Filtering chapter. The Product Security chapter provides advice on selecting evaluated products.

As no ASD Protection Profile exists for data diodes, diodes are to be selected in accordance with the following controls.

Diodes

A diode enforces one-way flow of network traffic thus requiring separate paths for incoming and outgoing data. This makes it much more difficult for a malicious actor to use the same path to both launch an intrusion/attack and release the information.

Diodes for AUSTEO and AGAO networks

While diodes between networks at the same classification generally are not needed, AUSTEO and AGAO networks are particularly sensitive and additional security measures need to be put in place when connecting them to other networks.

Volume checking

Monitoring the volume of data being transferred across a diode ensures that it conforms to expectations. It can also alert the agency to potential malicious activity if the volume of data suddenly changes from the norm. Further information on monitoring can be found in the Information Security Monitoring and Data Transfers and Content Filtering chapters of this manual.

This section covers factors that need to be taken into consideration when creating policy for allowing web access to ensure the confidentiality, integrity and availability of information and to protect against the execution and spread of malicious software. This section also applies Internet-connected networks and to inter-network connections (that may not be Internet-connected) equally.

Web usage policy

If agencies allow users to access the web they will need to define the extent of web access that is granted. This can be achieved through a web usage policy and education of users.

Web proxy

Web proxies are a key component in detecting and responding to malicious software incidents. Comprehensive web proxy logs are valuable in responding to a malicious software incident or user violation of web usage policies.

Web browsers and add-ons

Many web browsers can be extended with the inclusion of add-ons. These add-ons can have access to sensitive or classified information such as page content and cookie information. A malicious or poorly written add-on may leak this sensitive information to external parties or communicate sensitive information over insecure channels.

Secure Sockets Layer and Transport Layer Security filtering

Since Secure Sockets Layer (SSL) and Transport Layer Security (TLS) web traffic travelling over Hypertext Transfer Protocol Secure (HTTPS) connections can deliver content without any filtering, agencies can reduce this security risk by using SSL and TLS inspection so that web traffic can be filtered.

An alternative to SSL and TLS inspection for HTTPS websites is to allow websites that have a low risk of delivering malicious code and have a high privacy requirement, such as Internet banking, to continue to have end-to-end encryption.

Inspection of Secure Sockets Layer and Transport Layer Security traffic

As encrypted SSL and TLS traffic may contain personally identifiable information agencies are recommended to seek legal advice on whether inspecting such traffic could be in breach of the Privacy Act 1988.

Whitelisting websites

Defining a whitelist of permitted websites and blocking all unlisted websites effectively removes one of the most common data delivery and exfiltration techniques used by malicious code. However, if users have a legitimate requirement to access a numerous and rapidly changing list of websites, agencies will need to consider the costs of such an implementation.

Even a relatively permissive whitelist offers better security than relying on blacklists, or no restriction at all, while still reducing implementation costs.

• whitelist the entire Australian subdomain, that is *.au
• whitelist the top 1,000 sites from the Alexa site ranking (after filtering dynamic DNS domains and other inappropriate domains).

Categorising websites

Websites can be grouped into categories and non-work related categories can be blocked via a web content filter.

Blacklisting websites

Blacklists are collections of websites that have been deemed to be inappropriate due to their content or hosting of malicious content. Sites are listed individually and can be categorised.

Intrusions commonly use dynamic or other domains where domain names can be registered anonymously for free due to their lack of attribution.

Web content filter

An effective web content filter greatly reduces the risk of a malicious code infection or other inappropriate content from being accessed. Web content filters can also disrupt or prevent an intruder from communicating with their malicious software.

Some content filtering performed by a web content filter is the same as that performed by email or other content filters, other types of filtering is specific to the web domain.

Further information on web content filtering can be found in the Data Transfers and Content Filtering chapter.

Additional requirements for data transfers using removable media can be found in the Media Usage section of the Media Security chapter. Additional requirements for data transfers via gateways or security domains can be found in the Content Filtering section of this chapter.

User responsibilities

When users transfer data to or from a system they need to be aware of the potential consequences of their actions. This could include data spills of sensitive or classified data onto systems not accredited to handle the data, or the unintended introduction of malicious code to a system. Accordingly, users need to be held accountable for all data transfers that they make.

Data transfer authorisation

• checking protective markings to ensure that the destination system is appropriate for the data being transferred
• performing antivirus checks on data to be transferred to and from a system
• following all processes and procedures for the transfer of data.

Trusted sources

Trusted sources include security personnel such as the CISO, the ITSA, ITSMs and ITSOs.

Import of data

Scanning imported data for malicious content reduces the security risk of a system being infected, thus allowing the continued confidentiality, integrity and availability of the system.

Format checks provide a method to prevent known malicious formats from entering the system. Keeping and regularly auditing these logs allow for the system to be checked for any unusual usage.

Export of data

When data is exported between systems, protective marking checks can reduce the security risk of data being transferred to a system that is not accredited to handle it or into the public domain.

Additional requirements for data transfers using removable media can be found in the Media Usage section of the Media Security chapter. Additional requirements for data transfers via gateways or security domains can be found in the Content Filtering section of this chapter.

Data transfer procedures