In recent years, the Australian Government has made great advances in bringing its business online. The benefits of government information and communications technology (ICT) systems and services becoming increasingly connected will continue as the government makes the most of new technologies. However, this new, connected way of doing business also creates opportunities for adversaries to gain an advantage by exploiting these technologies to access information of national importance.
As our intrusion detection, response, mitigation and threat assessment capabilities continue to improve, so too do the skills of cyber threat actors. This requires us to be vigilant, flexible and proactive in our approach to cyber and information security.
A strong security posture is not a trivial process-it requires ongoing vigilance and resources. By continually hardening our defences, we have a greater chance of protecting the information entrusted to us.
The Australian Government Information Security Manual (ISM) comprises three complementary documents designed to provide greater accessibility and understanding at all levels of government. This Controls document details the technical security controls which can be implemented to help mitigate security risks to agencies' information and systems.
I commend you on your agency's efforts to strengthen your cyber and information security and trust you'll continue to keep security as an agency priority.
The Australian Government Information Security Manual (ISM) is used for the risk-based application of information security controls.
This section describes how to interpret the content and layout of this manual.
The purpose of this manual is to assist Australian government agencies in applying a risk-based approach to protecting their information and systems. while there are other standards and guidelines designed to protect information and systems, the advice in this manual is specifically based on ASD's experience in providing cyber and information security advice and assistance to the Australian government. The controls are therefore designed to mitigate the most likely threats to Australian government agencies.
ASD encourages Australian government agencies, whether Commonwealth, state or territory, which do not fall within this list to apply the considered advice contained within this manual when selecting security controls on a case-by-case basis.
This manual represents the considered advice of ASD provided in accordance with its designated functions under the ISA. Therefore agencies are not required as a matter of law to comply with this manual, unless legislation, or a direction given under legislation or by some other lawful authority, compels them to comply with it.
This manual does not override any obligations imposed by legislation or law. Furthermore, if this manual conflicts with legislation or law the latter takes precedence.
While this manual contains examples of when legislation or laws may be relevant for agencies, there is no comprehensive consideration of such issues. Accordingly, agencies should rely on their own inquiries in that regard.
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.
This manual uses the term 'public network infrastructure', defined as network infrastructure that an agency has no or limited control over (for example the Internet). Conversely, private network infrastructure is that which an agency controls exclusively.
However, there may be cases where a network does not precisely meet either of these definitions, a common example being the Intra Government Communications Network (ICON). ICON provides dedicated network connectivity between Australian Government agencies and has a different risk profile than both public and private network infrastructure. ICON provides additional physical and personnel security measures over general public network infrastructure. Agencies will need to consider which security mitigations to implement commensurate with their assessed level of risk. ASD recommends that, where feasbile, networks whose infrastructure and devices are not wholly controlled by your agency, should be treated as if public network infrastructure in the context of relevant ISM controls.
Further information on ICOn can be found at [link]http://www.finance.gov.au/collaboration-services-skills/icon/[/link].
The three parts of the ISM are designed to complement each other and provide agencies with the necessary information to conduct informed risk-based decisions according to their own business requirements, specific circumstances and risk appetite.
The [b]Executive Companion[/b] is aimed at the most senior executives in each agency, such as Secretaries, Chief Executive Officers and Deputy Secretaries, and comprises broader strategic messages about key cyber and information security issues.
The [b]Principles[/b] document is aimed at Security Executives, Chief Information Security Officers, Chief Information Officers and other senior decision makers across government and focuses on providing them with a better understanding of the cyber threat environment. This document contains information to assist them in developing informed security policies within their agencies.
The [b]Controls[/b] manual is aimed at Information Technology Security Advisors, Information Technology Security Managers, Information Security Registered Assessors and other security practitioners across government. This manual provides a set of detailed controls which, when implemented, will help agencies adhere to the higher level Principles document.
ASD provides further information security advice in the form of device-specific guides, Australian Communications Security Instructions (ACSIs) and Protect publications-such as the Strategies to Mitigate Targeted Cyber Intrusions . While these publications reflect the policy specified in this manual, not all requirements in this manual can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.
This manual uses a framework to present information in a consistent manner.
Each control in this manual has an applicability indicator that indicates the information and systems to which the control applies.
ASD maintains a System Controls Checklist to facilitate the incorporation of ISM advice into agencies' risk assessments.
Information on the applicability of the Protective Security Policy Framework can be found at [link]http://www.protectivesecurity.gov.au[/link].
Agencies select and implement information security controls from the ISM as part of a formal risk management process.
This section describes the expectations on Australian government agencies to include the controls contained in this manual in their wider agency risk management process. Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.
The ISM represents best practice in mitigating or minimising the threat to Australian government information and systems. However, due to the differences between government agencies, there is no one-size-fits-all model for information security. The ISM aims to encourage agencies to take a risk-based approach to information security. This approach enables the flexibility to allow agencies to conduct their business and develop resilience in the face of a changing threat environment.
It is a mandatory requirement of the Australian Government Protective Security Policy Framework that agencies adopt a risk management approach to cover all areas of protective security activity across their organisation. ASD recommends information security forms a part of an agency's broader risk management processes.
The ISM is developed as a tool to assist Australian government agencies to risk-manage the protection of their information and systems. It may not be possible or appropriate for an agency to implement all controls included in this manual. Agencies will have different security requirements, business needs and risk appetites from one another. The ISM aims to assist agencies in understanding the potential consequences of non-compliance-and whether such non-compliance presents an acceptable level of risk-as well as selecting appropriate risk mitigation strategies.
While this manual provides controls for various technologies, not all systems will use all of the technologies mentioned. when agencies develop systems they will need to determine the appropriate scope of the systems and which controls in this manual are applicable.
Not all ISM requirements can be implemented on all devices or in all environments. In these cases, device-specific advice issued by ASD may take precedence over the controls in this manual.
This section should be read in conjunction with the Security Risk Management Plans section of the Information Security Documentation chapter. Further information on vulnerability assessments and managing change can be found in the Information Security Monitoring chapter.
Agencies must identify and analyse security risks to their information and systems.
Once information security risks have been identified and analysed, agencies will need to determine whether they are acceptable or not.
Treating a risk means that the consequences and/or likelihood of that risk is reduced. The controls included in this manual provide strategies to achieve this in different circumstances (in generic, agency and device non-specific terms).
Security risks deemed unacceptable must be treated.
Agencies must incorporate the controls contained in the Australian Government Information Security Manual in their security risk management processes.
Because an agency's risk owner-the agency head or their formal delegate-is accountable for an information or cyber security incident, they need to be made aware of any residual security risks to their information and systems through a formal approval process. Agency risk profiles will change over time as the threat environment, technology and agency business needs evolve, so it is important that any residual security risks are monitored.
Security risks deemed acceptable must be formally accepted by the responsible authority, as indicated for each control in this manual, and continually monitored by the agency.
Agencies should mitigate residual security risks through the implementation of alternative security measures.
While a baseline of controls is provided in this manual, agencies may have differing circumstances to those considered during the development of this manual. In such cases an agency needs to follow its own security risk management processes to determine its risk appetite and associated risk acceptance, risk avoidance and risk tolerance thresholds.
Agencies must determine system specific security risks that could warrant additional controls to those specified in this manual.
Documenting information security risk management activities can help an agency ensure security risks are managed in a coordinated and consistent manner. Documentation also provides a standard against which compliance can be measured.
Agencies must document identified information security risks, as well as the evaluation of those risks and mitigation strategies, in their Security Risk Management Plan.
The Australian Government Protective Security Policy Framework can be found at [link]http://www.protectivesecurity.gov.au.[/link]
For further guidance please refer to the Australian Standard for Risk Management AS/NZS ISO 31000:2009, the Australian Standards HB 167:2006 Security risk management and HB 327:2010 Communicating and consulting about risk.
The Protective Security Training College, managed by the Attorney-General's Department, provides formal training opportunities on the subject of security risk management: [link]http://www.ag.gov.au/nationalSecurity/ProtectiveSecurityTraining/Pages/default.aspx[/link]
Agencies comply with ISM controls where appropriate, in accordance with their business needs, threat environment and risk appetite. non-compliance is formally accepted by the appropriate authority.
This section explains the compliance language used in this manual and the appropriate authorities for non-compliance with ISM controls.
Each control specifies the authority that must provide approval for non-compliance with the control.
In most circumstances, the accreditation authority is the agency head or their formal delegate. For information on accreditation authorities, see the Conducting Accreditations section of the System Accreditation chapter.
Some controls will also require non-compliance notification to the relevant portfolio minister(s), the Attorney-General and the Auditor General as detailed in the Australian Government Protective Security Policy Framework (PSPF). These can be found in the PSPF Mandatory Requirement INFOSEC 4 Explained chapter.
There are two categories of compliance associated with the controls in this manual-'must' and 'should'. These compliance requirements are determined according to the degree of security risk an agency will be accepting by not implementing the associated control. ASD's assessment of whether a control is a 'must' or a 'should' is based on ASD's experience in providing cyber and information security advice and assistance to the Australian government and reflect what ASD assesses the risk level to be. Agencies may have differing risk environments and requirements, and may have other mitigations in place to reduce the residual risk to an acceptable level.
Where an agency is non-compliant with multiple controls for similar reasons, they may group together these controls in their report to simplify the reporting process.
As smaller agencies may not always have sufficient personnel or budgets to comply with this manual, they may choose to consolidate their resources with another larger host agency to undertake a joint approach to compliance.
In such circumstances, smaller agencies may choose to either operate on systems fully hosted by another agency using their information security policies and security resources, or share security resources to jointly develop information security policies and systems for use by both agencies. In these cases, the requirements in this manual can be interpreted as either relating to the host agency or to both agencies, depending on the approach taken.
In situations where agencies choose a joint approach to compliance, especially when an agency agrees to fully host another agency, the agency heads may choose to seek a memorandum of understanding to formalise their security responsibilities.
All controls in this manual may be audited for compliance by the Australian national Audit Office (ANAO).
By using the latest release of this manual for system design activities, agencies will be taking steps to protect themselves from the current threats to Australian government systems.
Agencies undertaking system design activities for in-house or outsourced projects must use the latest release of this manual for security requirements.
ASD produces information security policies and guidance in addition to this manual, such as the ACSI suite, consumer guides, hardening guides and Protect publications. These may address device and scenario-specific security risks to information and systems, and accordingly may take precedence over the controls in this manual. Distinct time frames for compliance may also be specified.
Agencies must comply with additional or alternative controls as stipulated in device and scenario-specific guidance issued by ASD.
Non-compliance with 'must' and 'must not' controls are likely to represent a high security risk to information and systems. Non-compliance with 'should' and 'should not' controls are likely to represent a medium-to-low security risk to information and systems. The accreditation authority (the agency head or their formal delegate in most circumstances) is able to consider the justification for non-compliance and accept any associated residual security risk.
Non-compliance with controls where the authority is marked 'ASD' must be granted by the Director ASD.
For any control where the authority field is 'ASD', system owners must seek and be granted approval for non-compliance from the Director ASD in consultation with their accreditation authority.
System owners seeking approval for non-compliance with any control in this manual must be granted non-compliance from their accreditation authority.
If the agency head and accreditation authority form separate roles in an agency, the accreditation authority will need to ensure the agency head has appropriate oversight of the security risks being accepted on behalf of the agency. This helps to meet the PSPF's Protective Security Principles, which stipulate that agency heads need to understand, prioritise and manage security risks to prevent harm to official resources and disruption to business objectives. The authority for this control is listed as N/A as non-compliance approval cannot be sought under the ISM framework.
In circumstances where the agency head and accreditation authority roles are separate, the accreditation authority must ensure the agency head has appropriate oversight of the security risks being accepted on behalf of the agency.
Without sufficient justification, and consideration of the security risks, the agency head or their authorised delegate will lack the appropriate information to make an informed decision on whether to accept the residual security risk and grant non-compliance to the system owner.
When an agency processes, stores or communicates information on their systems that belongs to another agency or foreign government they have an obligation to inform that third party when they desire to risk manage the controls specified in this manual. If the agency fails to do so, the third party will be unaware that their information has been placed at a heightened risk of compromise. The third party is thus denied the opportunity to consider additional security measures for their information.
If a system processes, stores or communicates information from another agency, that agency should be consulted as part of granting non-compliance with any control.
Agencies should provide a copy of their compliance and non-compliance reports to ASD.
When seeking approval for non-compliance, the system owner must provide a justification for non-compliance, outline any alternative mitigation measures to be implemented and conduct an assessment of the security risks. As the justification for non-compliance may change, and the risk environment will continue to evolve over time, it is important that the system owner update their approval for non-compliance at least every two years. This allows for the appropriate authority to have any decision to grant non-compliance either reaffirmed or, if necessary, rejected if the justification or residual security risk is no longer acceptable.
Agencies must review decisions to grant non-compliance with any control, including the justification, any mitigation measures and security risks, at least every two years or when significant changes occur to ensure its continuing relevance, adequacy and effectiveness.
Without appropriate records of decisions to grant non-compliance with controls, agencies have no record of the status of their security posture. Furthermore, a lack of such records will hinder any auditing activities that may be conducted by the agency or by external parties such as the ANAO. Failing to maintain such records is also a breach of the Archives Act 1983 (the Archives Act).
Agencies must retain a copy of decisions to grant non-compliance with any control from this manual.
ASD contact details can be found at [link]http://www.asd.gov.au/contact.htm[/link].
The PSPF's Protective Security Principles can be found at [link]http://www.protectivesecurity.gov.au[/link].
Security personnel are aware of and use security services offered in the Australian Government.
This section describes the government agencies and bodies involved in providing information security advice.
Australian Signals Directorate (ASD) is required under the [i]Intelligence Services Act 2001[/i] (the ISA) to perform various functions, including the provision of material, advice and other assistance to Commonwealth and State authorities on matters relating to the security of information that is processed, stored or communicated by electronic or similar means.
ASD provides assistance to Commonwealth and State authorities in relation to cryptography, communications and computer technologies.
ASD works with industry to develop new cryptographic products. It has established the Australasian Information Security Evaluation Program (AISEP) to assist with the increasing requirement to evaluate products with security functionality.
ASD can be contacted for advice and assistance on implementing this manual through agency Information Technology Security Managers (ITSMs) or Information Technology Security Advisors (ITSAs). ITSMs and ITSAs can send questions to ASD by email at [link]firstname.lastname@example.org[/link] or phone on 1300 CYBER1 (1300 292 371).
ASD can be contacted for advice and assistance on cyber security incidents. ASD's response will be commensurate with the urgency of the cyber security incident. Urgent and operational enquiries can be submitted through ASD's OnSecure website or by phoning 1300 CYBER1 (1300 292 371) and selecting 1 at any time. non-urgent and general enquiries can be submitted through the OnSecure website, by phoning 1300 CYBER1 (1300 292 371) and selecting 2 at any time or by emailing at [link]email@example.com[/link]. ASD's incident response service is available 24 hours, 7 days a week.
ASD can be contacted by email at [link]firstname.lastname@example.org[/link] for advice and assistance on the purchasing, provision, deployment, operation and disposal of High Assurance key material and High Assurance Cryptographic Equipment.
The following table contains a brief description of the other government agencies and bodies that have a role in information security in government.
|AGENCY OR BODY||SERVICES|
|Attorney-General's Department (AGD)||Responsible for information security policy and cyber security incident preparedness, response and recovery arrangements across government.|
|Attorney-General's Department - Protective Security Training College||Provides protective security training to government agencies and contractors.|
|Australian Federal Police (Australian High Tech Crime Centre)||Law enforcement in relation to electronic and other high tech crimes.|
|Australian Cyber Security Centre (ACSC)||The role of the ACSC is to lead the Australian Government's operational response to cyber security incidents, organise national cyber security operations and resources, encourage and receive reporting of cyber security incidents, raise awareness of the threat to Australia and study and investigate cyber threats. The ACSC includes representatives from ASD, the Australian Crime Commission (ACC), the Australian Defence Force (ADF), the Australian Federal Police (AFP), the Australian Security Intelligence Organisation (ASIO), the Computer Emergency Response Team (CERT) Australia and the Defence Intelligence Organisation (DIO).|
|Australian National Audit Office (ANAO)||Performance audits on information security.|
|Australian Security Intelligence Organisation (ASIO)||ASIO is responsible for collecting, analysing and reporting intelligence on threats to security.|
|Australian Security Intelligence Organisation (ASIO) - T4 Protective Security||ASIO-T4 Protective Security section provides advice and training, technical surveillance counter-measures, physical security certifications, protective security risk reviews and physical security equipment testing.|
|CERT Australia||Provides the private sector with information and assistance to help them protect their Information and Communications Technology (ICT) infrastructure from cyber threats and vulnerabilities. CERT Australia also provides a coordination role during a serious cyber incident.|
|Cyber Security Operations Board||Provides strategic direction and oversight of operational cyber security matters. Chairmanship and Secretariat support provided by the Attorney General's Department.|
|Cyber Security Policy and Coordination Committee||Coordinates the development of cyber security policy for the Australian Government.|
|Department of Communications||Responsible for initiatives to educate and protect home users, students and small business from electronic intrusions and fraud.|
|Department of Finance||Development and oversight of whole-of-government policy on the Australian Government's use of information and communications technology.|
|Department of Foreign Affairs and Trade||Policy and advice for security overseas.|
|Department of the Prime Minister and Cabinet||Coordination of cyber and information security policy and activities across government. Responsible for implementation of the national Security Information Environment Roadmap: 2020 Vision.|
|National Archives of Australia||Provides standards and advice on capturing and managing records to ensure their integrity as evidence is maintained. The national Archives also authorises the disposal of all Commonwealth records, including those relating to ICT and security processes and incidents.|
|Protective Security Policy Committee||Coordinates the development of protective security policy. Chairmanship and Secretariat support provided by the Attorney-General's Department.|
|Security Construction and Equipment Committee||Oversees the evaluation of physical security equipment.|
If security personnel are unaware of the roles government organisations play in the information security space, they could miss out on valuable insight and assistance in developing effective security measures.
Security personnel should familiarise themselves with the information security roles and services provided by Australian government agencies and bodies.
Information technology service providers implement appropriate security measures to protect government information.
This section describes information on outsourcing general information technology services.
In the context of this section, general information technology services encompasses business process services, application processes and infrastructure services. The range of information technology services that can be procured from a source outside an organisation is extensive.
The Attorney-General's Department's [i]Australian Government Protective Security Policy Framework[/i] (PSPF) mandatory requirement GOV 12 requires agencies ensure any service provider complies with Australian Government protective security policies and procedures where there is access to, or control over, Australian Government personnel, information or assets.
PSPF Protective security governance guidelines-Security of outsourced services and functions provides agencies with guidance for incorporating protective security requirements into contracts when outsourcing agency functions.
Outsourcing can be a cost-effective option for providing general information technology services in an agency, as well as potentially delivering a superior service; however, it can also affect an agency's risk profile. Storing information in multiple disparate locations and allowing more people to access it can significantly increase the potential for information compromise.
Agencies must ensure that service providers' systems are located in Australia if they store or process government information and are not listed on ASD's Certified Cloud Services List.
Agency data and computing environments must not be accessed, configured or administered from outside Australian borders by a service provider unless a contractual arrangement exists between the service provider and customer to do so.
Information technology service providers can be provided with government information as long as their systems are accredited to process, store and communicate that information. Further information on accrediting systems can be found in the System Accreditation chapter of this manual.
Service providers' systems that are used to provide information technology services, including outsourced cloud services, must be accredited prior to handling government information.
Agency privacy and security obligations for protecting government information are no different when using an outsourced information technology service, including a cloud computing service. The contract or service agreement between a vendor and their customer must address mitigations to governance, privacy and security risks, otherwise the customer only has vendor promises and marketing claims that can be hard to verify and may be unenforceable.
Any measures associated with the protection of information entrusted to another party must be documented in contract provisions, a memorandum of understanding or equivalent formal agreement between parties.
Although data ownership resides with the agency, this can become less clear in some circumstances, such as when legal action is taken and a vendor is asked to provide access to, or data from, their assets. To mitigate the risk of agency data being unavailable or compromised, agencies can explicitly retain ownership of their data through contract provisions.
When entering into a contract or other agreement for information technology services, agencies should explicitly retain contractual ownership over their data.
Considering the risks that arise as systems and software are being built and delivered, as well as the degree of risk that a particular supplier may introduce into the delivery of a contracted service, will assist agencies in determining whether security measures need to be taken to mitigate the threats arising from potential supply chain exploitation. The globalised nature of ICT products increases the difficulty in evaluating supply chain integrity. Adopting a risk management approach will assist in circumstances where agencies are not able to acquire all the information necessary to do a complete risk assessment.
Agencies should perform a due diligence review of suppliers, including their country of origin, before obtaining software, hardware or services, to assess the potential increase to agency security risk profiles.
Information on Australian Government expectations when outsourcing services and functions can be found in the Attorney-General's Department's Security of outsourced services and functions guidelines publication at [link]http://www.protectivesecurity.gov.au/governance/contracting/Pages/Supporting-guidelines-for-contracting.aspx[/link].
The National Institute of Standards and Technology (NIST) Special Publication 800-161 Supply Chain Risk Management Practices for Federal Information Systems and Organizations can be found at [link]http://csrc.nist.gov/publications/PubsDrafts.html[/link].
Cloud service providers implement appropriate security measures to protect government information in cloud services.
This section describes information on outsourcing information technology services in a cloud computing model.
The terminology and definitions used in this section are consistent with [i]The NIST Definition of Cloud Computing[/i], Special Publication 800-145, September 2011. This section also applies to cloud service that have a payment model which differs to the NIST pay-per-use [i]measured service[/i] characteristic.
Using outsourced cloud services can affect an agency's risk profile. Cloud services located offshore may be subject to lawful and covert collection, without the information owner's knowledge. Additionally, use of offshore cloud services introduces jurisdictional risks as foreign countries' laws could change with little warning. Further, foreign owned cloud service providers operating in Australia may be subject to a foreign government's lawful access. A comprehensive risk assessment is essential in identifying and managing jurisdictional, governance, privacy, technical and security risks.
The risks of using outsourced cloud services, including those in ASD's cloud computing advice, must be assessed and documented.
ASD maintains a list of cloud services certified against security and governance requirements. This can be found via the ASD website at [link]http://www.asd.gov.au[/link].
Agencies must only use outsourced cloud services listed on ASD's Certified Cloud Services List (CCSL).
Agencies proposing to use outsourced cloud services not listed on ASD's CCSL must notify ASD in writing at the earliest opportunity and certainly before entering into or renewing a contract with a cloud service provider.
Agencies must notify ASD in writing at the earliest opportunity during the initial stages of considering using a cloud service and certainly prior to entering or renewing a contract with a cloud service provider.
ASD's cloud computing advice and Certified Cloud Services List is available on ASD's public website at [link]http://www.asd.gov.au[/link].
Whole-of-government policy and guidance on cloud computing, including detailed legal and financial considerations for contracts, can be found on the Department of Finance's website at [link]http://www.finance.gov.au/cloud/[/link].
The Attorney-General's Department's Risk management of outsourced ICT arrangements (including Cloud) is available at [link]http://www.protectivesecurity.gov.au/informationsecurity/Pages/RiskManagementOfOutsourcedICTArrangements-IncludingCloud.aspx[/link]
The NIST Definition of Cloud Computing, Special Publication 800-145, can be accessed from the NIST website at [link]http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf[/link].
The Chief Information Security Officer (CISO) sets the strategic direction for information security for their agency.
This section describes the information security role of a CISO.
The requirement to appoint a member of the Senior Executive Service, or in an equivalent management position, to the role of CISO does not require a new dedicated position to be created in each agency. This role is intended to be performed by the Security Executive, which is a position in each agency mandated by the [i]Australian Government Protective Security Policy Framework[/i] (PSPF). The introduction of the CISO role outside of PSPF requirements is intended to provide a more meaningful title for the Security Executive's responsibilities that relate specifically to information security.
The role of the CISO is based on industry best practice and has been introduced to ensure that information security is managed at the senior executive level.
Agencies must appoint a senior executive, commonly referred to as the CISO, who is responsible for coordinating communication between security and business functions as well as overseeing the application of controls and security risk management processes.
The Information Technology Security Advisor (ITSA) coordinates information technology security for their agency.
This section describes the information security role of an Information Technology Security Manager (ITSM) when designated as the ITSA.
The ITSM who has responsibility for information technology security management across the agency is designated as the ITSA. This title reflects the responsibility this ITSM has as the first point of contact for the CISO, or equivalent, and external agencies on any information technology security management issues.
Information on the responsibilities of ITSMs can be found in the [i]Information Technology Security Managers[/i] section of this chapter.
An ITSM, when fulfilling the designation of ITSA, still maintains full responsibilities for their role as an ITSM in addition to ITSA responsibilities. An ITSA traditionally has the added responsibility of coordinating other ITSMs to ensure that security measures and efforts are undertaken in a coordinated manner.
Agencies must designate an ITSM as the ITSA, to have responsibility for information technology security management across the agency.
As security personnel in agencies need to communicate with security personnel from other agencies, often to provide warnings of threats to their systems, it is important that a consistent contact method is available across government to facilitate such communication.
Agencies should maintain an email address for their ITSA in the form of ITSA@agency.
Information Technology Security Managers (ITSMs) provide information security leadership and management for their agency.
This section describes the information security role of ITSMs.
ITSMs are executives that coordinate the strategic directions provided by the CISO and the technical efforts of Information Technology Security Officers (ITSOs). The main area of responsibility of an ITSM is that of the day-to-day management of information security within an agency.
Agencies must appoint at least one executive, commonly referred to as an ITSM, to manage the day-to-day operations of information security within the agency, in line with the strategic directions provided by the CISO or equivalent.
Further information on the role of ITSAs is available in the Attorney-General's Department's [i]Protective Security Governance Guidelines[/i], available at http://www.protectivesecurity.gov.au.
ITSOs provide information security operational support.
This section describes information security role of ITSOs.
ITSOs implement technical solutions under the guidance of an ITSM to ensure that the strategic direction for information security within the agency is achieved.
The ITSO role may be combined with that of the ITSM. Small agencies may choose to assign both ITSM and ITSO responsibilities to one person under the title of the ITSA. Furthermore, agencies may choose to have this role performed by existing system administrators with an additional reporting chain to an ITSM for the security aspects of their role.
Appointing a person whose responsibility is to ensure the technical security of systems is essential to manage compliance and non-compliance with the controls in this manual. The main responsibility of ITSOs is the implementation and monitoring of technical security measures for systems.
Agencies must appoint at least one expert, commonly referred to as an ITSO, in administering and configuring a broad range of systems as well as analysing and reporting on information security issues.
System owners obtain and maintain accreditation of their systems.
This section describes the information security role of system owners.
The system owner is the person responsible for an information resource.
While the system owner is responsible for the operation of the system, they will delegate the day-to-day management and operation of the system to a system manager or managers.
While it is strongly recommended that a system owner is a member of the Senior Executive Service, or in an equivalent management position, it does not imply that the system managers should also be at such a level.
Each system must have a system owner who is responsible for the operation of the system.
System owners should be a member of the Senior Executive Service or in an equivalent management position.
The system owner is responsible for the secure operation of their system and needs to ensure it is accredited. If modifications are undertaken to a system the system owner will need to ensure that the changes are undertaken and documented in an appropriate manner, and that any necessary reaccreditation activities are completed.
System owners must obtain and maintain accreditation for their systems.
Information security documentation is produced for systems to support the accurate and consistent application of policy and procedures within an agency.
This section describes the information security documentation that government agencies should develop and maintain.
The suite of documents outlined in this chapter forms the Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
Documentation is vital to any information security regime as it supports the accurate and consistent application of policy and procedures within an agency. Documentation also provides increased accountability and a standard against which compliance can be measured.
More detailed information about each document can be found in the relevant sections of this chapter.
The Information Security Policy (ISP) is a statement of high-level information security policies and is therefore an essential part of information security documentation.
Agencies must have an ISP.
The Security Risk Management Plan (SRMP) is a best practice approach to identifying and reducing potential security risks. Depending on the documentation framework chosen, multiple systems could refer to, or build upon, a single SRMP.
Agencies must ensure that every system is covered by an SRMP.
The System Security Plan (SSP) is derived from this manual and the SRMP and describes the implementation and operation of controls for a system. Depending on the documentation framework chosen, some details common to multiple systems could be consolidated in a higher level SSP.
Agencies must ensure that every system is covered by an SSP.
Standard Operating Procedures (SOPs) provide a step-by-step guide to undertaking security related tasks. They provide assurance that tasks can be undertaken in a repeatable manner, even by users without strong knowledge of the system. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.
Agencies should ensure that SOPs are developed for systems.
Having an Incident Response Plan (IRP) ensures that when a cyber security incident occurs, a plan is in place to respond appropriately to the situation. In most situations, the aim of the response will be to preserve any evidence relating to the cyber security incident and to prevent the incident escalating.
Agencies must develop, maintain and implement an IRP and supporting procedures.
It is likely that the most useful and accurate information security documentation will be developed by personnel who are knowledgeable about both information security issues and the business requirements.
Agencies should ensure that information security documentation is developed by personnel with a good understanding of both the subject matter and the business requirements.
As the SRMP, SSP, SOPs and IRP form a documentation suite for a system, it is essential that they are logically connected and consistent. Furthermore, each documentation suite developed for a system will need to be consistent with the ISP.
Agencies should ensure that their SRMP, SSP, SOPs and IRP are logically connected and consistent for each system and with the ISP.
Having a documentation framework for information security documents ensures that they are accounted for and maintained appropriately. Furthermore, the framework can be used to describe relationships between documents, especially when higher level documents are used to avoid repetition of information in lower level documents.
Agencies should create and maintain a document framework including a hierarchical listing of all information security documentation and their relationships.
Agencies should adopt the naming conventions provided in this manual for their information security documentation.
Agencies outsourcing the development of information security documentation still need to review and control the contents to make sure it meets their requirements.
If information security policy does not have formal approval, security personnel will have difficulty ensuring appropriate systems security procedures are in place. Having formal approval not only assists in the implementation of procedures, it also ensures senior managers are aware of information security issues and security risks.
All information security documentation should be formally approved by a person with an appropriate level of seniority and authority.
If stakeholders are not made aware of new information security documentation, or changes to existing information security documentation, they will not know about any changes they may need to make to the security measures for their systems.
Once information security documentation has been approved it should be published and communicated to all stakeholders.
The threat environment and agencies' businesses are dynamic. If an agency fails to keep their information security documentation current to reflect the changing environment, their security measures and processes may cease to be effective. In that situation, resources could be devoted to areas that have reduced effectiveness, or are no longer relevant.
Agencies should record the date of the most recent review on each information security document.
The ISP sets the strategic direction for information security for an agency.
This section describes the development of an ISP.
ISPs are a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
Information about other mandatory documentation can be found in the Documentation Fundamentals section of this chapter.
In developing the contents of the ISP, agencies may also consult any agency-specific directives that could be applicable to information security.
Agencies should avoid including controls for systems in their ISP. Instead, they should be documented in the SSP.
The ISP should describe information security policies, standards and responsibilities.
A SRMP identifies security risks and appropriate mitigation measures for systems.
This section describes the development of a SRMP, focusing on security risks related to the operation of systems.
A SRMP is a component of an agency's [i]Information Security Management Framework[/i], as mandated in the [i]Australian Government Information Security Management Protocol[/i].
This section should be read in conjunction with the [i]Information Security Risk Management[/i] section of the [i]About Information Security[/i] chapter.
Information about other mandatory documentation can be found in the [i]Documentation Fundamentals[/i] section of this chapter.
Security risks cannot be managed if they are not known. Even if they are known, failing to deal with them is a failure of security risk management. For this reason a SRMP consists of two components, a security risk assessment and a corresponding risk treatment strategy.
The SRMP should contain a security risk assessment and a corresponding risk treatment strategy.
If an agency fails to incorporate the SRMP for systems into their wider agency risk management plan then the agency will be unable to manage risks in a coordinated and consistent manner across the agency.
Agencies should incorporate their SRMP into their wider agency risk management plan.
Standards Australia produces AS/NZS ISO 31000:2009, [i]Risk Management-Principles and guidelines[/i] while the ISO/IEC has developed the risk management standard ISO/IEC 27005:2011, [i]Information technology-Security techniques-Information security risk management[/i], as part of the ISO/IEC 27000 family of standards.
Agencies should develop their SRMP in accordance with Australian or international standards for risk management.
For further guidance please refer to the [i]Australian Standard for Risk Management[/i] AS/NZS ISO 31000:2009, the Australian Standards HB 167:2006 [i]Security risk management[/i] and HB 327:2010 [i]Communicating and consulting about risk[/i].
Information on the development of SRMPs can be found in HB 231:2004, [i]Information security risk management guidelines[/i]. In particular, section 5 discusses documentation. It is available from Standards Australia at [link]http://www.standards.org.au/[/link].
A SSP specifies the security measures for systems.
This section describes the development of an SSP.
A SSP is a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
Information about other mandatory documentation can be found in the [i]Documentation Fundamentals[/i] section of this chapter.
Further information to be included in a SSP about specific functionality or technologies that could be implemented for a system can be found in the applicable areas of this manual.
This manual provides a list of controls that are potentially applicable to a system based on its classification, its functionality and the technology it is implementing. Agencies need to determine which controls are in scope of the system and translate those controls to the SSP. These controls will then be assessed on their implementation and effectiveness during the accreditation process for the system.
In performing accreditations against the latest release of this manual, agencies are ensuring that they are taking the most recent threat environment into consideration. ASD continually monitors the threat environment and conducts research into the security impact of emerging trends. With each release of this manual, controls can be added, rescinded or modified depending on changes in the threat environment.
Agencies must select controls from this manual to be included in the SSP based on the scope of the system with additional system specific controls being included as a result of the associated SRMP or higher level SSP.
Agencies must use the latest release of this manual when developing, and updating, their SSPs as part of accreditation and reaccreditation of their systems.
Further information on the Australian Government Information Security Management Protocol can be found at [link]http://www.protectivesecurity.gov.au[/link].
SOPs ensure security procedures are followed in an appropriate and repeatable manner.
This section describes the development of security related SOPs.
SOPs are a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
Information about other mandatory documentation can be found in the [i]Documentation Fundamentals[/i] section of this chapter.
To ensure that personnel undertake their duties appropriately, with a minimum of confusion, it is important that the roles of ITSMs, ITSOs, system administrators and users are covered by SOPs. Furthermore, ensuring that SOPs are consistent with SSPs reduces the potential for confusion resulting from conflicts in policy and procedures.
The ITSM SOPs cover the management and leadership activities related to system operations.
The following procedures should be documented in the ITSM's SOPs.
|Topic||Procedures to be Included|
|Cyber security incidents||Reporting and managing cyber security incidents|
The ITSO SOPs cover the operationally focused activities related to system operations.
The following procedures should be documented in the ITSO's SOPs.
|Topic||Procedures to be Included|
|Access control||Authorising access rights to applications and data|
|Asset musters||Labelling, registering and mustering assets, including media|
|Audit logs||Reviewing system audit trails and manual logs, particularly for privileged users|
|Configuration control||Approving and releasing changes to the system software or configurations|
|Cyber security incidents||Detecting potential cyber security incidents|
|Establishing the cause of any cyber security incident, whether accidental or deliberate|
|Actions to be taken to recover and minimise the exposure from a cyber security incident|
|Data transfers||Managing the review of media containing information that is to be transferred off-site|
|Managing the review of incoming media for viruses or unapproved software|
|ICT equipment||Managing the destruction of unserviceable ICT equipment and media|
|System integrity audit||Reviewing user accounts, system parameters and access controls to ensure that the system is secure|
|Checking the integrity of system software|
|Testing access controls|
|Inspecting ICT equipment and cables|
|System maintenance||Managing the ongoing security and functionality of system software, including: maintaining awareness of current software vulnerabilities, testing and applying software patches/updates/signatures, and applying appropriate hardening techniques|
|User account management||Authorising new users|
The system administrator SOPs support the ITSO SOPs; however, they focus on the administrative activities related to system operations.
The following procedures should be documented in the system administrator's SOPs.
|Topic||Procedures to be Included|
|Access control||Implementing access rights to applications and data|
|Configuration control||Implementing changes to the system software or configurations|
|System backup and recovery||Backing up data, including audit logs|
|Securing backup tapes|
|Recovering from system failures|
|User account management||Adding and removing users|
|Setting user privileges|
|Cleaning up directories and files when a user departs or changes roles|
The user SOPs focus on day-to-day activities that users need to know about, and comply with, when using systems.
The following procedures should be documented in the user's SOPs.
|Topic||Procedures to be Included|
|Cyber security incidents||What to do in the case of a suspected or actual cyber security incident|
|End of day||How to secure systems at the end of the day|
|Media control||Procedures for handling and using media|
|Passphrases||Choosing and protecting passphrases|
|Temporary absence||How to secure systems when temporarily absent|
When SOPs are produced, the intended audience needs to be made aware of their existence and acknowledge that they have read, understood and agree to abide by their contents. Additionally, the intended audience needs to be made aware of any consequences for deviating from the agreed SOP.
ITSMs, ITSOs, system administrators and users should sign a statement that they have read and agree to abide by their respective SOPs.
An IRP outlines actions to take in response to a cyber security incident.
This section describes the development of an IRP to address cyber security incidents. It does not cover physical security incidents.
An IRP is a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
The guidance provided on the content of an IRP ensures that agencies have a baseline to develop an IRP with sufficient flexibility, scope and level of detail to address the majority of cyber security incidents that could arise.
Information and systems are, where safe, secured before personnel evacuate a facility in the event of an emergency.
This section describes the requirements for securing information and systems as part of the procedures for evacuating a facility in the event of an emergency.
Emergency procedures are a component of an agency's Information Security Management Framework, as mandated in the [i]Australian Government Information Security Management Protocol[/i].
During the evacuation of a facility it is important that personnel secure information and systems as they would at the end of operational hours. This includes, but is not limited to, securing media and logging off workstations. This is important as a malicious actor could use such an opportunity to gain access to applications or databases that a user had already authenticated to, or use another user's credentials, for a malicious purpose.
Agencies must include in evacuation procedures the requirement to secure information and systems before the evacuation; unless the chief warden, to avoid serious injury or loss of life, authorises personnel to evacuate immediately without securing information and systems.
The warning phase before the evacuation of a facility alerts personnel that they may be required to evacuate the facility. This warning phase is the ideal time for personnel to begin securing information and systems to ensure that if they need to evacuate the facility they can do so immediately.
Agencies should include in evacuation procedures the requirement to secure information and systems during the warning phase before the evacuation.
Business continuity and disaster recovery plans help minimise the disruption to the availability of information and systems after an event or disaster.
This section describes the role of business continuity and disaster recovery plans in ensuring continuing operation of agencies' critical systems.
Business continuity and disaster recovery plans work to maintain security in the face of unexpected events and changes.
Additional information relating to business continuity can be found in the Service Continuity for Online Services section of the [i]Network Security[/i] chapter.
As availability requirements will vary based on business requirements they cannot be stipulated in this manual. Agencies will need to determine their own availability requirements and implement appropriate security measures to achieve them.
Agencies must determine availability requirements for their systems and implement appropriate security measures to support these requirements.
Having a backup strategy in place is an important part of business continuity planning. The backup strategy ensures that critical business information is not accidentally lost. Where practical, backups should be stored offline to mitigate the risk of agency data being unavailable due to compromise or deletion.
Developing a business continuity plan can help ensure that critical functions of systems continue to operate when the system is in a degraded state. For example, when limited bandwidth is available on networks, agencies may choose to strip all large attachments from emails. This is a mandatory requirement of the PSPF.
Agencies must develop a business continuity plan.
Developing a disaster recovery plan will reduce the time between a disaster occurring and critical functions of systems being restored.
Agencies should develop a disaster recovery plan.
Additional information relating to business continuity is contained in HB 221:2004, [i]Business Continuity Management[/i].
The accreditation process allows for formal recognition and acceptance of the residual security risk a system and the information that it processes, stores or communicates.
This section details an agency's accreditation responsibilities. For the purposes of this Manual, a system is defined as a related set of hardware and software used for the processing, storage or communication of information and the governance framework in which it operates.
Accreditation is the process by which the accreditation authority formally recognises and accepts the residual security risk to a system and the information it processes, stores and communicates.
Detailed information about the processes and the requirements for conducting accreditations, certification and security assessments or audits is given in the [i]Conducting Accreditations, Conducting Certifications[/i] and [i]Conducting Security Assessments or Audits[/i] sections of this chapter.
Accreditation of a system ensures that either sufficient security measures have been put in place or that deficiencies in such measures have been accepted by an appropriate authority. when systems are awarded accreditation, the accreditation authority accepts that the residual security risks are appropriate for the sensitivity or classification of the information that the system processes, stores or communicates.
Developing and implementing an accreditation framework ensures that accreditation activities are conducted in a repeatable and consistent manner across the agency.
Monitoring the accredited systems will assist in assessing changes to the environment and operation and to determine the implications for the security risk profile and accreditation status of the system.
Agencies must develop and implement an accreditation framework.
Systems must be awarded accreditation before they are used to process, store or communicate sensitive or classified information.
Agencies must not allow a system to process, store or communicate information above the sensitivity or classification for which the system has received accreditation.
Systems must not process, store or communicate caveated or compartmented information unless specifically accredited for such purposes.
For multinational and multi-agency systems, determining the certification and accreditation authorities through a formal agreement between the parties ensures that the system owner has appropriate points of contact and does not receive conflicting advice from different authorities.
For multinational and multi-agency systems, the certification and accreditation authorities should be determined by a formal agreement between the parties involved.
In advising the certification and accreditation authorities of their intent to seek certification and accreditation for a system, the system owner can seek information on the latest processes and requirements for their system.
The list of accreditation and certification authorities is given in the Conducting Accreditations and [i]Conducting Certifications[/i] sections of this chapter.
Before beginning the accreditation process, the system owner should advise the certification and accreditation authorities of their intent to seek certification and accreditation for their system.
Threat environments and business needs are dynamic. Agencies should reaccredit their systems every two years to ensure their security measures are appropriate in the current environment, as security measures and processes may cease to be effective over time.
Once three years have elapsed since the last accreditation, the agency needs to either reaccredit the system or seek approval for non-compliance from their agency head.
While regular accreditation activities are highly beneficial in maintaining the security posture of a system, other activities may necessitate a need for an accreditation outside of regularly scheduled timeframes.
To assist in the reaccreditation of systems, agencies are encouraged to reuse as much information from previous accreditations as possible including, where appropriate, concentrating on the delta between the security posture of the system at the time of the last accreditation and the current security posture of the system.
Agencies should ensure that the period between accreditations of systems does not exceed two years.
Agencies must ensure that the period between accreditations of systems does not exceed three years.
For agencies wishing to gain a physical security certification for SCIF areas in addition to their ICT certification, a SCIF Support Pack is available from ASD on request.
The accreditation process allows for formal recognition and acceptance of the residual security risk a system and the information that it processes, stores or communicates.
This section describes conducting an accreditation for a system.
For TOP SECRET systems the accreditation authority is ASD.
For systems SECRET and below, the accreditation authority is the agency head or their formal delegate, which is strongly recommended to be the CISO or equivalent.
For systems that process, store or communicate caveated or compartmented information there may be a mandated accreditation authority external to the agency operating the system.
For multinational and multi-agency systems the accreditation authority is determined by a formal agreement between the parties involved.
For commercial providers providing services to agencies, the accreditation authority is the head of that agency or their authorised delegate, which is strongly recommended to be the CISO or equivalent.
In all cases the accreditation authority will be at least a senior executive who has an appropriate level of understanding of the security risks they are accepting on behalf of the agency.
Depending on the circumstances and practices of an agency, the agency head can choose to delegate their authority to multiple senior executives who have the authority to accept security risks for the specific business functions.
Accreditation for a system is awarded when the accreditation authority formally recognizes and accepts the residual security risk to a system and its information, and gives formal approval for the system to operate. However, in some cases the accreditation authority may not accept the residual security risk due to security risks and measures being inadequately scoped for the system. In such cases the accreditation authority may request that further work be undertaken by the system owner before reconsidering the system for accreditation. In the intervening time, the accreditation authority may choose to issue an interim approval to operate with caveats placed on the system's use.
The following diagram shows, at a high level, the process of accreditation.
Certification (described in the [i]Conducting Certifications[/i] section of this chapter) provides the accreditation authority with information on the security posture of a system. This allows the accreditation authority to make an informed decision on whether the residual security risk of allowing the system to operate is acceptable.
All systems must undergo certification as part of the accreditation process; unless the accreditation authority is satisfied that if the system is not immediately operational it would have a devastating and potentially long-lasting effect on operations.
The purpose of conducting an accreditation of a system is to determine the security posture of the system and the security risk that it poses to information. In giving approval for the system to operate, the accreditation authority is accepting the residual security risk to information that is processed, stored or communicated by the system.
To assist in making an informed accreditation decision, the accreditation authority may also seek advice from technical experts on the technical components of information presented to them during the accreditation process.
The accreditation authority must accept the residual security risk to a system and the information it processes, stores or communicates in order to award accreditation.
An agency's accreditation authority must be at least a senior executive with an appropriate level of understanding of the security risks they are accepting on behalf of the agency.
For TOP SECRET systems, the accreditation authority must be ASD.
Certification allows for formal recognition and acceptance that the chosen security measures for a system have been implemented effectively.
This section describes conducting a certification as part of the accreditation process for a system.
The aim of certification is to ensure the security assessment or audit for a system was conducted in an appropriate manner and to a sufficiently high standard.
The outcome of certification is a certification report to the accreditation authority outlining the security measures that have been implemented for a system and the residual risk it poses to the system and the information that it processes, stores or communicates.
For TOP SECRET systems the certification authority is ASD.
For SECRET or below systems the certification authority is the agency ITSA.
For systems that process, store or communicate caveated or compartmented information there may be a mandated certification authority external to the agency operating the system.
For multinational and multi-agency systems the certification authority is determined by a formal agreement between the parties involved.
For commercial providers providing services to agencies, the certification authority is the ITSA of the agency sponsoring the provider.
For providers of gateway services, either government or commercial, intended for use by multiple agencies across government, ASD performs the role of the certification authority as an independent third party.
A security assessment, or audit, reviews the system architecture and assesses the actual implementation and effectiveness of security measures.
All systems must undergo a security assessment, also known as an audit, as part of the certification process.
To award certification for a system the certification authority needs to be satisfied that the security measures identified by the system owner have been implemented and are operating effectively. However, certification only acknowledges that the identified security measures were implemented and are operating effectively and not that the residual security risk is acceptable or an approval to operate has been awarded.
The certification authority must accept the effectiveness of controls for the system in order to award certification.
To assist the accreditation authority in determining whether to award accreditation for a system or not, the certification authority will need to produce a certification report outlining the security measures that have been implemented for the system and an assessment of the residual security risk relating to the system and information that it processes, stores or communicates.
The certification authority should produce a certification report for the accreditation authority outlining the security measures that have been implemented for a system and an assessment of the residual security risk relating to the system and the information that it processes, stores or communicates.
Agencies may provide their own gateway services, or outsource this function to a commercial provider. In either case, gateway services intended for use by multiple agencies are required to undergo a security assessment, also known as an audit, conducted by an Information Security Registered Assessor and be awarded certification from ASD. Even though ASD may award certification to a gateway service from a commercial provider, agencies using the service still need to decide whether accreditation should be awarded or not.
Commercial or government-provided gateway services intended for use by multiple agencies must undergo an Information Security Registered Assessor Program Audit and be awarded certification by ASD annually.
Cloud services are required to undergo a security assessment, also known as an audit, conducted by an Information Security Registered Assessor and be awarded certification from ASD. Even though ASD may award certification to a cloud service, agencies using the cloud service still need to decide whether accreditation should be awarded or not. Cloud services are only permitted to handle Australian government information if they have been certified by ASD and accredited by agencies intending to use the cloud service.
ASD's cloud computing advice and Certified Cloud Services List is available on ASD's public website at [link]http://www.asd.gov.au[/link].
The implementation and effectiveness of security measures for a system is assessed.
This section describes conducting a security assessment, also known as an audit, as part of the certification process for a system.
The aim of a security assessment, also known as an audit, is to review the system architecture and assess the actual implementation and effectiveness of security measures.
The outcome of asecurity assessment, also known as an audit, is a report to the certification authority describing the implementation and effectiveness or security measures for a system. This includes areas of compliance and non-compliance for a system and any suggested remediation actions.
Security assessments, also known as audits, for TOP SECRET systems can only be undertaken by ASD and Information Security Registered Assessors.
Security assessments, also known as audits, for SECRET and below systems can be undertaken by agency ITSMs and Information Security Registered Assessors.
A number of agencies and personnel are often consulted during a security assessment, also known as an audit.
The ASA can also be consulted on personnel security aspects of systems.
An ITSM or communications security officer can be consulted on communications security aspects of systems.
A security assessment, also known as an audit, can be conducted by an agency's own assessors. However, the agency may choose to add an extra level of objectivity by engaging the services of an Information Security Registered Assessor to undertake the security assessment or audit.
Connections to certain inter-agency systems could require an independent security assessment or audit from an Information Security Registered Assessor as a prerequisite to certification. Such requirements can be obtained from the inter-agency system owners.
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.
Assessors of systems should not also be the system owner or certification authority.
Ensuring that the system owner has approved the system architecture and associated information security documentation assists assessors in understanding the scope of work for the first stage of the audit.
Before undertaking the security assessment, also known as an audit, the system owner must approve the system architecture and associated documentation.
The purpose of a security assessment, also known as an audit, is two-fold: to determine that the system architecture is based on sound security principles and to determine whether the security measures chosen have been implemented and are operating effectively.
The security measures for the system must be reviewed by the assessor to determine whether they have been implemented and are operating effectively.
The assessor must ensure that, where applicable, a currently valid physical security certification has been awarded by an appropriate physical security certification authority.
To assist the certification authority in determining whether to award certification for a system or not the assessor will need to produce a report outlining areas of concern for the system including any suggested remediation actions.
The assessor must produce a report for the certification authority outlining areas of non-compliance for a system and any suggested remediation actions.
[i]Policy and Procedures for the Information Security Registered Assessors Program[/i] contains a definition of the range of activities Information Security Registered Assessors are authorised to perform. It can be obtained from ASD's website at [link]http://www.asd.gov.au/irap[/link].
Vulnerability management activities contribute to the security of systems.
This section describes agencies' requirements for conducting vulnerability management activities for their systems.
Information security monitoring practices can help ensure that new vulnerabilities are addressed and security is maintained through unforeseen events and changes, whether internal to the system or in the system's operating environment. Such practices allow agencies to be proactive in identifying, prioritising and responding to security risks. Measures to monitor and manage vulnerabilities in, and changes to, a system can provide an agency with a wealth of valuable information about its level of exposure to threats, as well as assisting agencies in keeping up to date with industry and product advances.
Vulnerability management activities will feed into an agency's wider risk management processes. Further information on risk management can be found in the [i]About Information Security[/i] chapter and the [i]Security Risk Management Plans[/i] section of the [i]Information Security Documentation[/i] chapter.
Undertaking vulnerability management activities such as regular vulnerability assessments, analysis and mitigation are important as threat environments change over time. Vulnerability assessments allow agencies to identify security weaknesses caused by misconfigurations, bugs or flaws.
Conducting vulnerability assessments prior to systems being used, and after significant changes, can allow the agency to establish a baseline for further information security monitoring activities.
Conducting vulnerability assessments annually can help ensure that the latest threat environment is being addressed and that systems are configured in accordance with associated information security documentation.
It is recommended that vulnerability assessments are conducted by suitably skilled personnel independent of the target of the assessment. Such personnel can be internal to an agency, such as an IT security team, or a third party such as an Information Security Registered Assessor. where possible, it is advisable that system managers do not conduct vulnerability assessments themselves. This ensures that there is no conflict of interest, perceived or otherwise, and that the assessment is undertaken in an objective manner.
Agencies should have vulnerability assessments conducted by suitably skilled personnel independent to the target of the assessment or by an independent third party.
Agencies will find it useful to gather appropriate information before they start a vulnerability assessment. This will help to ensure that the assessment is undertaken to a degree that is commensurate with the threat environment, and if applicable, the sensitivity or classification of information that is involved.
Agencies are encouraged to monitor information about new vulnerabilities that could affect their systems. However, if no vulnerabilities are disclosed in specific products used in their systems it is important agencies are not complacent.
Vulnerabilities can be introduced as a result of poor security practices, implementations or accidental activities. Therefore, even if no new vulnerabilities in deployed products have been disclosed there is still value to be gained from conducting regular vulnerability analyses.
Furthermore, by monitoring vulnerability sources/alerts, conducting vulnerability analyses, keeping up to date with industry and product advances, and keeping up to date with changes to this manual, agencies will become aware of factors which may adversely impact the security risk profile of their systems.
Agencies may wish to consider that discovered vulnerabilities could be a result of their security practices, accidental activities or malicious activities and not just as the result of a technical issue.
To determine the potential impact and possible mitigations to a system, comprehensive documentation and an understanding of the system are required. External sources that can be monitored for information on new vulnerabilities are vendor published vulnerability information, other open sources and subscription services.
Mitigation efforts are best prioritised using a risk-based approach in order to address the most significant vulnerabilities first. Where two or more vulnerabilities are of similar importance, the mitigations with lower cost (in time, staff and capital) can be implemented first.
Agencies must analyse any vulnerabilities to determine their potential impact on the agency and determine appropriate mitigations or other treatments.
Agencies must mitigate or otherwise treat identified vulnerabilities as soon as possible.
A high-level summary of vulnerability assessment, analysis and management can be found in ASD's Protect publication [i]Know and minimise your vulnerabilities before they are used against you[/i]. Protect publications can be accessed through the ASD public website at [link]http://www.asd.gov.au[/link].
Information security is an integral part of change management policy and process.
This section describes the importance of maintaining the security of systems when implementing routine and urgent changes.
As part of any change process it is important that all stakeholders are consulted before the change is implemented. In the case of changes that will affect the security of a system, the accreditation authority will need to be consulted and approval sought prior to the change taking place.
The change management process ensures that changes to systems are made in an accountable manner with due consideration and with appropriate approval. Furthermore, the change management process provides an opportunity for the security impact of the change to be considered and, if necessary, reaccreditation processes initiated.
The most likely scenario for bypassing change management processes is when an urgent change needs to be made to a system. Before and after an urgent change is implemented, it is essential that the change management process strongly enforces appropriate actions to be taken.
Agencies must have a formal change management process in place.
The change management process must define appropriate actions to be followed before and after urgent changes are implemented.
The accreditation for a system is the acceptance of the residual security risk relating to the operation of the system. It is important therefore that, when a change occurs that impacts the overall security risk for the system, the accreditation authority is consulted on whether that residual security risk is still acceptable.
When a configuration change impacts the security of a system, and is subsequently assessed as having changed the overall security risk for the system, the system must undergo reaccreditation.
Tools and appropriate procedures are in place to detect cyber security incidents.
This section describes controls aimed at detecting cyber security incidents. It does not cover detecting physical and personnel security incidents.
A cyber security event is an identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be relevant to security.
A cyber security incident is a single or series of unwanted or unexpected cyber security events that have a significant probability of compromising business operations and threatening information security.
The activities listed for assisting in detecting cyber security incidents will assist in mitigating the most common methods used to exploit systems.
Many potential cyber security incidents are noticed by personnel rather than software tools. However, this can only occur if personnel are well trained and aware of information security issues and know how to recognise possible cyber security incidents.
Automated tools are only as good as the quality of the analysis they provide. If tools are not adequately configured to assess potential security risks, it will not be evident when a weakness emerges. Additionally, if the tools are not regularly updated to include knowledge of new vulnerabilities their effectiveness will be reduced.
Agencies may consider some of the tools described in the following table for detecting potential cyber security incidents.
|Anomaly detection systems||Monitor network and host activities that do not conform to normal system activity.|
|Intrusion Detection Systems||Some Intrusion Detection Systems (IDSs) are combined with functionality to repel detected intrusions. Caution and assessment of the potential impact need to be exercised if this capability is to be used.|
|Log analysis||Involves collecting and analysing event logs using pattern recognition to detect anomalous activities.|
|Network and host IDSs||Monitor and analyse network and host activity, usually relying on a list of known malicious signatures to recognise potential cyber security incidents.|
|System integrity verification||Used to detect changes to critical system components such as files, directories or services. These changes may alert a system administrator to unauthorised changes that could signify an intrusion on the system and inadvertent system changes that render the system vulnerable to intrusion.|
Agencies should use the results of the security risk assessment to determine the appropriate balance of resources allocated to prevention as opposed to detection of cyber security incidents.
Reported cyber security incidents assist in maintaining an accurate threat environment picture for government systems.
This section describes agencies' responsibilities for reporting cyber security incidents. It does not cover reporting physical or personnel security incidents.
The requirement to lodge a cyber security incident report applies even when an agency has outsourced some or all of its information technology functions and services.
The Cyber Security Incident Reporting (CSIR) scheme defines cyber security incidents that are reportable to ASD.
Reporting cyber security incidents to an ITSM as soon as possible after it occurs provides management with a means to assess the overall damage to a system and to take remedial action, including seeking advice from ASD if necessary.
Agencies must direct personnel to report cyber security incidents to an ITSM as soon as possible after the cyber security incident is discovered.
ASD uses cyber security incident reports as the basis for identifying and responding to cyber security events across government. Cyber security incident reports can also be used for developing new policies, procedures, techniques and training measures to prevent the recurrence of similar cyber security incidents across government. Agencies are recommended to coordinate their reporting of cyber security incidents to ASD e.g. through their ITSA.
Where agencies have outsourced information technology services and functions, they may request that the service provider report cyber security incidents directly to ASD. This could be specified in either a memorandum of understanding or as part of the contract of services. In such cases it is recommended that the agency's ITSA be made aware of all reporting of cyber security incidents to ASD by the service provider.
Agencies must report cyber security incidents to ASD.
Reporting cyber security incidents to ASD via a CSIR (available from ASD's website) will enable ASD triage, mitigation and containment of the threat if required. Reporting ensures that appropriate and timely assistance can be provided and allows ASD to maintain an accurate threat environment picture for government systems through the CSIR scheme.
Agencies should formally report cyber security incidents using the CSIR scheme.
When an agency outsources information technology services and functions, they are still responsible for the reporting of cyber security incidents. It is up to the agency to ensure the service provider informs them of all cyber security incidents.
Agencies that outsource their information technology services and functions must ensure that the service provider consults with the agency when a cyber security incident occurs.
Reporting any cyber security incident involving the loss or misuse of cryptographic keying material is particularly important, as the confidentiality and integrity of secure communications relies on the secure use of keying material.
Agencies must notify all communications security custodians of any suspected loss or compromise of keying material.
ACSI 107 applies to all agencies including contractors. Its requirements cover all High Assurance Cryptographic Equipment products used to process classified information.
For security incidents involving the suspected loss or compromise of keying material for High Assurance products, ASD will investigate the possibility of compromise and, where possible, initiate action to reduce the impact of the compromise.
Agencies must notify ASD of any suspected loss or compromise of High Assurance Cryptographic Equipment or keying material associated with High Assurance Cryptographic Equipment products in accordance with ACSI 107.
Further information on reporting cyber security incidents is located on the ASD website at [link]http://www.asd.gov.au/infosec/reportincident.htm[/link].
Appropriate remedies assist in preventing future cyber security incidents.
This section describes agencies' responsibilities for managing cyber security incidents.
The management of physical and personnel security incidents is not covered in this section unless it directly impacts on the protection of systems (for example, breaching physical protection for a server room).
Documenting responsibilities and procedures for cyber security incidents in relevant SSPs, SOPs and the IRP ensures that when a cyber security incident does occur, personnel can respond in an appropriate manner. In addition, ensuring that users are aware of reporting procedures assists in capturing any cyber security incidents that an ITSM, ITSO or system owner fail to notice.
Agencies must detail cyber security incident responsibilities and procedures for each system in the relevant SSP, SOPs and IRP.
The purpose of recording cyber security incidents in a register is to highlight the nature and frequency of the cyber security incidents so that corrective action can be taken. This information can subsequently be used as an input into future security risk assessments of systems.
Agencies should ensure that all cyber security incidents are recorded in a register.
Agencies should use their register as a reference for future security risk assessments.
Assuming that information is compromised as a result of a cyber security incident allows an agency to apply procedures in response to the incident that has occurred. A worst case scenario would entail an intruder gaining access to a range of classified documentation and should be handled accordingly.
When a data spill occurs agencies must assume that the information has been compromised.
Agencies must include in standard procedures for all personnel with access to systems a requirement that they notify an ITSM of any data spillage and access to any data which they are not authorised to access.
Agencies must document procedures for managing data spills in their IRP.
Agencies must treat any data spill as a cyber security incident and follow the IRP to manage it.
When a data spill occurs, agencies must report the details of the data spill to the information owner.
The spillage of information onto a system not accredited to handle it is considered a cyber security incident under the ASD CSIR scheme.
An affected system can be segregated by powering off the system, removing network connectivity to the device or applying access controls on information associated with the data spill to prevent access. However, it should be noted that powering off the system could destroy information that would be useful for forensics activities at a later date.
When information is introduced onto a system not accredited to handle the information, personnel must not delete the information until advice is sought from an ITSM.
When information is introduced onto a system not accredited to handle the information, personnel should not copy, print or email the information.
When information is introduced onto a system not accredited to handle the information, agencies should segregate the affected system from the network.
The guidance for handling malicious code infections is provided to help prevent the spread of the infection and to prevent reinfecting the system. An important consideration is the infection date of the machine. However, when determining the infection date, it is important to bear in mind that the record could be inaccurate as a result of the infection.
A complete operating system reinstallation, or an extensive comparison of characterisation information, is the only reliable way to ensure that malicious code is eradicated.
Taking immediate steps after the discovery of a malicious code infection can minimise the time and cost spent eradicating and recovering from the incident.
Upon reporting the incident to ASD, agencies are likely to be asked to provide information to ASD regarding the incident that will assist ASD investigations and response. If agencies have an understanding of the types of information that ASD might request then this can significantly shorten incident investigation and response times.
For more information on event logging, including required retention periods, see the [i]Event Logging and Auditing[/i] section of the [i]Access Control[/i] chapter.
Agencies may wish to allow an intrusion to continue against their system for a short period of time in order to allow time for the agency to fully understand the scope of the incident.
Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of scoping the intrusion should inform their accreditation authority.
Agencies allowing an intrusion to continue against a system in order to seek further information or evidence will need to establish with their legal advisors whether the actions are breaching the [i]Telecommunications (Interception and Access) Act 1979[/i] (the TIA Act).
Agencies considering allowing intrusion activity to continue under controlled conditions for the purpose of seeking further information or evidence must seek legal advice.
While gathering evidence it is important to maintain the integrity of the information, this includes maintaining metadata about the information, who used it, and how it was used. Even though in most cases an investigation does not directly lead to a police prosecution, it is important that the integrity of evidence such as manual logs, automatic audit trails and intrusion detection tool outputs be protected.
When storing raw audit trails onto media it is important that it is done in accordance with relevant retention requirements as documented in the national Archives of Australia's (NAA) [i]Administrative Functions Disposal Authority[/i].
If the integrity of evidence of a cyber security incident is compromised, it reduces ASD's ability to assist agencies. ASD therefore requests that no actions which could affect the integrity of the evidence be carried out before ASD's involvement.
Agencies should ensure that any requests for ASD assistance are made as soon as possible after the cyber security incident is detected and that no actions, which could affect the integrity of the evidence, are carried out before ASD's involvement.
System analysis after a successful intrusion helps to ensure the incident has been contained and removed from the system. After an incident has occurred, agencies may wish to perform post-incident analysis on their system by conducting a full network traffic capture. Agencies will be able to identify anomalous behaviour that may indicate an intruder persisting on the system, perform post-incident analysis and ensure mitigations put in place are effective.
Agencies should perform a post-incident analysis of successful intrusions, storing network traffic for at least seven days after the incident.
Further information relating to the management of ICT evidence is contained in HB 171:2003, [i]Guidelines for the management of information technology evidence[/i].
Physical security measures are applied to facilities and network infrastructure to protect systems.
This section describes the requirements for the physical security of facilities and network infrastructure.
Information on servers, network devices, ICT equipment and media can be found in other sections of this chapter. Information on encryption requirements can be found in the [i]Cryptographic Fundamentals[/i] section of the [i]Cryptography[/i] chapter.
In the context of this manual a facility is an area that facilitates government business. For example, a facility can be a building, a floor of a building or a designated space on the floor of a building.
For facilities that process or store caveated or compartmented information there may be a certification authority external to the agency operating the facility.
For multinational and multi-agency facilities the certification authority is determined by a formal agreement between the parties involved.
For commercial providers of gateway services intended for use by multiple agencies across government, ASIO performs the role of the certification authority as an independent third party.
For commercial providers providing services, the certification authority is the ASA of the sponsoring agency.
The accreditation of physical security measures for Zone Two to Zone Five security areas is undertaken by the ASA.
For facilities that process or store caveated or compartmented information there may be an accreditation authority external to the agency operating the facility.
For multinational and multi-agency facilities the accreditation authority is determined by a formal agreement between the parties involved.
For gateway services of commercial providers the accreditation authority is the ASA.
For commercial providers supporting agencies the accreditation authority is the ASA.
Agencies operating sites in posts or missions located outside of Australia should contact the Department of Foreign Affairs and Trade to determine requirements.
The application of defence-in-depth to the protection of systems is enhanced through the use of successive layers of physical security. The first layer of security is the use of Security Zones for the facility, the second layer is the use of a higher Security Zone or security room for the server room and the final layer is the use of security containers or lockable commercial cabinets. All layers are designed to limit access to those with the appropriate authorisation to access the system and infrastructure.
Deployable platforms need to meet physical security certification requirements as per any other system. Physical security certification authorities dealing with deployable platforms can have specific requirements that supersede the requirements of this manual and as such security personnel should contact their appropriate physical security certification authority to seek guidance.
In the case of deployable platforms, physical security requirements may also include perimeter controls, building standards and manning levels.
Agencies must ensure that any facility containing a system, including deployable systems, is certified and accredited against the requirements in the [i]Australian Government Physical Security Management Protocol[/i].
Agencies do not have control over sensitive or classified information when it is communicated over public network infrastructure or over infrastructure in unsecured spaces (Zone One security areas). For this reason, it is imperative information is encrypted to a sufficient level that if it was captured it would not be cost-effective to retrieve the original information.
The PSPF's Physical Security Management Guidelines-Security Zones and Risk Mitigation Control Measures states a Zone Five security area is required for the storage of codeword and TOP SECRET information. Secure transmission of this information is also a key consideration. Transmission of TOP SECRET or codeword information through lower security zone areas without encryption could allow a malicious actor to successfully access and exploit TOP SECRET infrastructure with relative ease. The only way to mitigate this threat is to apply strong encryption through the use of High Assurance Cryptographic Equipment.
Agencies communicating sensitive or classified information over public network infrastructure or over infrastructure in unsecured spaces (Zone One security areas) must use encryption approved for communicating such information over public network infrastructure.
Agencies communicating TOP SECRET or codeword information outside a Zone Five security area boundary must encrypt information using High Assurance Cryptographic Equipment.
Facilities without sufficient perimeter security are often exposed to the potential for observation through windows. Ensuring information on workstation screens is not visible will assist in reducing this security risk. This can be achieved by using blinds or drapes on the inside of the windows.
Agencies should prevent unauthorised people from observing systems, in particular, displays and keyboards.
Further information relating to physical security is contained in the [i]Australian Government Physical Security Management Protocol[/i]. This document can be found at [link]http://www.protectivesecurity.gov.au[/link].
Server and communication rooms protect servers and network devices.
This section describes the requirements for the physical security of servers and network devices.
Information relating to the physical security of facilities, network infrastructure and ICT equipment and media can be found in other sections of this chapter.
Agencies must certify and accredit the physical security of a facility and server or communications room against the requirements in the [i]Australian Government Physical Security Management Protocol[/i]. 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 [i]Australian Government Physical Security Management Protocol[/i] can be lowered according to the [i]Physical security of ICT equipment systems and facilities[/i] guideline.
Adequate physical protection must be provided to network devices, especially those in public areas, to prevent a malicious actor physically damaging a network device in order to cause a denial of service to a network.
Physical access to network devices can allow an intruder to reset devices to factory default settings by pressing a physical reset button, using a serial interface on a device or connecting directly to a device to bypass any access controls. Resetting a network device back to factory default settings may disable security settings on the device including authentication and encryption functions as well as resetting administrator accounts and passwords to known defaults. Even if access to a network device is not gained by resetting it, it is highly likely a denial of service will occur.
Physical access to network devices can be restricted through methods such as physical enclosures that prevent access to console ports and factory reset buttons, mounting devices on ceilings or behind walls, or placing devices in locked rooms or cabinets.
Agencies must implement physical security measures to protect network devices, especially those in public areas, from physical damage or unauthorised access.
If personnel leave server rooms, communications rooms and security containers or rooms unlocked, with keys in the locks or with security functions disabled, it negates the purpose of providing security. Such activities will compromise the security efforts and must not be permitted.
Agencies must ensure that servers and network devices are secured in either security containers or rooms as specified in the [i]Australian Government Physical Security Management Protocol[/i].
Agencies must not leave server rooms, communications rooms and security containers or rooms in an unsecured state.
Agencies must ensure that keys or equivalent access mechanisms to server rooms, communications rooms and security containers or rooms are appropriately controlled.
Areas containing particularly sensitive materials or ICT equipment can be provided with additional security through the use of a designated no-lone zone. The aim of this designation is to enforce two-person integrity, where all actions are witnessed by at least one other qualified or knowledgeable person.
Agencies operating no-lone zones must suitably signpost the area and have all entry and exit points appropriately secured.
Further information relating to physical security is contained in the [i]Australian Government Physical Security Management Protocol[/i]. This document can be found at [link]http://www.protectivesecurity.gov.au[/link].
ICT equipment and media is physically secured during operational and non-operational hours.
This section describes the physical security of ICT equipment and media. This includes but is not limited to workstations, printers, photocopiers, scanners, Multifunction Devices (MFDs), optical media, flash drives, portable hard drives and memory cards.
Additional information relating to ICT equipment and media can be found in the Fax Machines and Multifunction Devices section of the Communications Systems and Devices chapter as well as in the Product Security and Media Security chapters. Information on the encryption of media can be found in the Cryptography chapter.
Agencies must account for all sensitive and classified ICT equipment and media.
Agencies must register all ICT equipment and media with a unique identifier in an appropriate register.
During operational and non-operational hours, ICT equipment and media needs to be stored in accordance with the [i]Australian Government Physical Security Management Protocol[/i].
Agencies must ensure that ICT equipment and media with sensitive or classified information is secured in accordance with the requirements for storing sensitive or classified information in the [i]Australian Government Physical Security Management Protocol[/i].
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 [i]Australian Government Physical Security Management Protocol[/i] 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 [i]Media Sanitisation[/i] section of the [i]Media Security[/i] chapter, the logical controls described above are not approved as a method of lowering the physical storage requirements of the ICT equipment.
There is no guarantee that techniques such as preventing the storage of sensitive or classified information on hard drives and scrubbing the operating system swap file and other temporary data at logoff or shutdown will always work effectively or will not be bypassed due to unexpected circumstances such as an unexpected loss of power to the workstation. As such these security risks need to be considered when implementing such a solution and documented in the SSP.
For further information on physical security and media security see the [i]Australian Government Physical Security Management Protocol[/i] and [i]Australian Government Information Security Management Protocol[/i]. These documents can be found at [link]http://www.protectivesecurity.gov.au[/link].