Skip to main content

Last updated on 11 November 2018. Version 3.1 View Updates

img of download icon
Download full doc: PDF | XML | CSV

1. About information security

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

1.1. Understanding and using this Manual

Objective

1.1.1.

The New Zealand Information Security Manual details processes and controls essential for the protection of all New Zealand Government information and systems. Controls and processes representing good practice are also provided to enhance the essential, baseline controls. Baseline controls are minimum acceptable levels of controls. Essential controls are often described as “systems hygiene”. 

Context

Scope

1.1.2.

This manual is intended for use by New Zealand Government departments, agencies and organisations. Crown entities, local government and private sector organisations are also encouraged to use this manual.

1.1.3.

This section provides information on how to interpret the content and the layout of content within this manual.

1.1.4.

Information that is Official Information or protectively marked UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE or RESTRICTED is subject to a single set of controls in this NZISM.  These are essential or minimum acceptable levels of controls (baseline controls) and have been consolidated into a single set for simplicity, effectiveness and efficiency.  

1.1.5.

All baseline controls will apply to all government systems, related services and information. In addition, information classified CONFIDENTIAL, SECRET or TOP SECRET has further controls specified in this NZISM.

1.1.6.

Where the category “All Classifications” is used to define the scope of rationale and controls in the Manual, it includes any information that is Official Information, UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET or any endorsements, releasability markings or other qualifications appended to these categories and classifications.

The purpose of this Manual

1.1.7.

The purpose of this manual is to provide a set of essential or baseline controls and additional good and recommended practice controls for use by government agencies.  The use or non-use of good practice controls MUST be based on an agency’s assessment and determination of residual risk related to information security.

Target audience

1.1.8.

The target audience for this manual is primarily security personnel and practitioners within, or contracted to, an agency.  This includes, but is not limited to:

  • security executives;
  • security and information assurance practitioners;
  • IT Security Managers; 
  • Departmental Security Officers; and
  • service providers.

Structure of this Manual

1.1.9.

This manual seeks to present information in a consistent manner.  There are a number of headings within each section, described below.

  • Objective – the desired outcome when controls within a section are implemented.
  • Context – the scope, applicability and any exceptions for a section.
  • References – references to external sources of information that can assist in the interpretation or implementation of controls.
  • Rationale & Controls 
    • Rationale – the reasoning behind controls and compliance requirements.
    • Control – risk reduction measures with associated compliance requirements.
1.1.10.

This section provides a summary of key structural elements of this manual.  The detail of processes and controls is provided in subsequent chapters.  It is important that reference is made to the detailed processes and controls in order to fully understand key risks and appropriate mitigations.

The New Zealand Government Security Classification System

1.1.11.

The requirements for classification of government documents and information are based on the Cabinet Committee Minute EXG (00) M 20/7 and CAB (00) M42/4G(4).  The Protective Security Requirements (PSR) INFOSEC2 require agencies to use the NZ Government Security Classification System and the NZISM for the classification, protective marking and handling of information assets.  For more information on classification, protective marking and handling instructions, refer to the Protective Security Requirements, NZ Government Security Classification System.

Key definitions

Accreditation Authority

1.1.12.

The Agency Head is generally the Accreditation Authority for that agency for all systems and related services up to and including those classified RESTRICTED.  See also Chapter 3 – Roles and Responsibilities and Section 4.4 – Accreditation Framework.

1.1.13.

Agency heads may choose to delegate this authority to a member of the agency’s executive.  The Agency Head remains accountable for ICT risks accepted and the information security of their agency. 

1.1.14.

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

1.1.15.

For multi-national and multi-agency systems the Accreditation Authority is determined by a formal agreement between the parties involved.  Consultation with the Office of the Government Chief Information Officer (GCIO) may also be necessary.

1.1.16.

For agencies with systems that process, store or communicate NZEO or information compartmented for national security reasons, the Director-General of the GCSB is the Accreditation Authority irrespective of the classification level of that information.

Certification and Accreditation Processes

1.1.17.

Certification and accreditation of information systems is the fundamental governance process by which the risk owners and agency head derives assurance over the design, implementation and management of information systems and related services provided to government agencies.   This process is described in detail in Chapter 4 – System Certification and Accreditation.

1.1.18.

Certification and Accreditation are two distinct processes.

1.1.19.

Certification is the formal assertion that an information system and related services comply with minimum standards and agreed design, including any security requirements.

1.1.20.

In all cases, certification and the supporting documentation or summary of other evidence will be prepared by, or on behalf of, the host or lead agency.  The certification is then provided to the Accreditation Authority.

1.1.21.

Accreditation is the formal authority to operate an information system and related services, and requires the recognition and acceptance of associated risk and residual risks.

1.1.22.

A waiver is NOT an exception (see below).  A waiver is the formal acknowledgement that a particular compliance requirement of the NZISM cannot currently be met.  A waiver is granted by the Accreditation Authority on the basis that full compliance with the NZISM is achieved or compensating controls are implemented within a time specified by the Accreditation Authority.  Waivers are valid in the short term only and full accreditation cannot be granted until all conditions of the waiver have been met.  The need for a waiver may occur when specified controls cannot be practically implemented because of technology, resource or other serious limitations.  It is essential that risk is managed through the application of specified conditions.

1.1.23.

An exception is NOT a waiver (see preceding paragraph).  An exception is the formal acknowledgement that a requirement of the NZISM cannot be met and that a dispensation from the particular compliance requirement is granted by the Accreditation Authority.  This exception is valid for the term of the Accreditation Certificate or some lesser time as determined by the Accreditation Authority.  This may occur, for example, the system is to be in use for a very short time (usually measured in hours), or the requirement cannot be met and there is no viable alternative.  It is essential that any consequential risk is acknowledged and appropriate measures are taken to manage any increased risk.

1.1.24.

The requirements described above are summarised in the table below.  Care MUST be taken when using this table as there are numerous endorsements, caveats and releasability instructions in the New Zealand Government Security Classification System that may change where the authority for accreditation lies.

Information Classification MUST and MUST NOT controls SHOULD and SHOULD NOT controls Accreditation Authority
Information classified RESTRICTED and below, including UNCLASSIFIED and Official Information 

Controls are baseline or “systems hygiene” controls and are essential for the secure use of a system or service. Non-use is high risk and mitigation is essential. 

If the control cannot be directly implemented, suitable compensating controls MUST be selected to manage identified risks.

The Accreditation Authority may grant a Waiver or Exception from a specific requirement if the level of residual risk is within the agency’s risk appetite.

Some baseline controls cannot be individually risk managed by agencies without jeopardising multi-agency, All-of-Government or international systems and related information.

Control represents good and recommended practice. Non-use may be medium to high risk.

Non-use of controls is formally recorded, compensating controls selected as required and residual risk acknowledged to be within the agency’s risk appetite and formally agreed and signed off by the Accreditation Authority.

Agency Head/Chief Executive/Director General (or formal delegate)
All systems or services classified CONFIDENTIAL and above.

This is a baseline for any use of High Grade Cryptographic Equipment or the establishment of any compartments or the handling of any endorsed information (see below).

The Controls are baseline or “systems hygiene” controls and are essential for the secure use of a system or service. Non-use is high or very high risk and mitigation is essential.

If the control cannot be directly implemented and suitable compensating controls MUST be selected to manage identified risks.

The Accreditation Authority may grant a Waiver or Exception from a specific requirement if the level of residual risk is within the agency’s risk appetite.

Some baseline controls cannot be individually risk managed by agencies without jeopardising multi-agency, All-of-Government or international systems and related information.

This is a baseline for any use of High Grade Cryptographic Equipment or the establishment of any compartments or the handling of any endorsed information (See below).

Control represents good and recommended practice. Non-use may be high risk

Non-use of controls is formally recorded, compensating controls selected as required and residual risk formally acknowledged to be within the agency’s risk appetite and agreed and signed off by the Accreditation Authority

Agency Head/Chief Executive/Director General (or formal delegate)

All use of High Grade Cryptographic Equipment (HGCE)

All systems or services with compartmented or caveated information classified CONFIDENTIAL and above.

Accreditation based on work conducted by the agency and authority to operate by the Agency Head.

Controls are baseline or “systems hygiene” controls and are essential for the secure use of a system or service. Non-use is high or very high risk and mitigation is essential.

If the control cannot be directly implemented and suitable compensating controls MUST be selected to manage identified risks.

The Accreditation Authority may grant a Waiver or Exception from a specific requirement if the level of residual risk is within the agency’s risk appetite.

Some baseline controls cannot be individually risk managed by agencies without jeopardising multi-agency, All-of-Government or international systems and related information.

Accreditation based on work conducted by the agency and authority to operate by the Agency Head.

Control represents good and recommended practice. Non-use may be high risk

Non-use of controls is formally recorded, compensating controls selected as required and residual risk formally acknowledged to be within the agency’s risk appetite and agreed and signed off by the Accreditation Authority.

Director GCSB (or formal delegate)

“All Classifications” category

1.1.25.

The “All Classifications” category is used to describe the applicability of controls for any information that is Official Information or protectively marked UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE, RESTRICTED, CONFIDENTIAL, SECRET or TOP SECRET, including any caveats or releasability endorsements associated with the respective document classification.

Compartmented Information

1.1.26.

Compartmented information is information requiring special protection through separation or is “compartmented” from other information stored and processed by the agency.

Concept of Operations (ConOp) Document

1.1.27.

Systems, operations, campaigns and other organisational activities are generally developed from an executive directive or organisational strategy.  The ConOp is a document describing the characteristics of a proposed operation, process or system and how they may be employed to achieve particular objectives.  It is used to communicate the essential features to all stakeholders and obtain agreement on objectives and methods.  ConOps should be written in a non-technical language to facilitate agreement on understanding and knowledge and provide clarity of purpose.  ConOp is a term widely used in the military, operational government agencies and other defence, military support and aerospace enterprises.

Information

1.1.28.

The New Zealand Government requires information important to its functions, resources and classified equipment to be adequately safeguarded to protect public and national interests and to preserve personal privacy.  Information is defined as any communication or representation of knowledge such as facts, data, and opinions in any medium or form, electronic as well as physical.  Information includes any text, numerical, graphic, cartographic, narrative, or any audio or visual representation.

Information Asset

1.1.29.

An information asset is any information or related equipment that has value to an agency or organisation.  This includes equipment, facilities, patents, intellectual property, software and hardware.  Information Assets also include services, information, and people, and characteristics such as reputation, brand, image, skills, capability and knowledge.

Information Assurance (IA)

1.1.30.

Confidence in the governance of information systems and that effective measures are implemented to manage, protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation.

Information Security

1.1.31.

Although sometimes described as cyber security, Information security is considered a higher level of abstraction than cyber security relating to the protection of information regardless of its form (electronic or physical).  The accepted definition of information security within government is: “measures relating to the confidentiality, availability and integrity of information”.

1.1.32.

A number of specialised security areas contribute to information security within government; these include: physical security, personnel security, communications security and information and communications technology (ICT) security along with their associated governance and assurance measures.

Information Systems

1.1.33.

The resources and assets for the collection, storage, processing, maintenance, use sharing, dissemination, disposition, display, and transmission of information. This includes necessary and related services provided as part of the information system, for example; Telecommunication or Cloud Services.

Information Systems Governance

1.1.34.

An integral part of enterprise governance consists of the leadership and organisational structures and processes to ensure that the agency’s information systems support and sustain the agency’s and Government’s strategies and objectives.  Information Systems Governance is the responsibility of the Agency Head and the Executive team.

Secure Area

1.1.35.

In the context of the NZISM a secure area is defined as any area, room, group of rooms, building or installation that processes, stores or communicates information classified CONFIDENTIAL, SECRET, TOP SECRET or any compartmented or caveated information at these classifications.  A secure area may include a SCIF (see below).  The physical security requirements for such areas are specified in the Protective Security Requirements (PSR) Security Zones.

Security Posture

1.1.36.

The Security Posture of an organisation describes and encapsulates the security status and overall approach to identification and management of the security of an organisation’s networks, information, systems, processes and personnel.  It includes risk assessment, threat identification, technical and non-technical policies, procedures, controls and resources that safeguard the organisation from internal and external threats.

Sensitive Compartmented Information Facility (SCIF)

1.1.37.

Any accredited area, room, or group of rooms, buildings, or installation where Sensitive Compartmented Information (SCI) is stored, used, discussed, processed or communicated.  The Accreditation Authority for a SCIF is the Director GCSB or formal delegate.

System Owner

1.1.38.

A System Owner is the person within an agency responsible for the information resource and for the maintenance of system accreditation. This may include such outsourced services such as telecommunications or cloud. Their responsibilities are described in more detail in Section 3.4 – System Owners.

Interpretation of controls

Controls language

1.1.39.

The definition of controls in this manual is based on language as defined by the Internet Engineering Task Force (IETF)’s Request For Comment (RFC) 2119 to indicate differing degrees of compliance.

Applicability of controls

1.1.40.

Whilst this manual provides controls for specific technologies, not all systems will use all of these technologies.  When a system is developed, the agency will determine the appropriate scope of the system and which controls within this manual are applicable.

1.1.41.

If a control within this manual is outside the scope of the system then non-compliance processes do not apply.  However, if a control is within the scope of the system yet the agency chooses not to implement the control, then they are required to follow the non-compliance procedures as outlined below in order to provide appropriate governance and assurance.

1.1.42.

The procedures and controls described in the NZISM are designed, not only to counter or prevent known common attacks, but also to protect from emerging threats.

Identification and Selection of controls

1.1.43.

In all cases controls have been selected as the most effective means of mitigating identified risks and threats.  Each control has been carefully researched and risk assessed against a wide range of factors, including useability, threat levels, likelihood, rapid technology changes, sustainability, effectiveness and cost.  

Controls with a “MUST” or “MUST NOT” requirement

1.1.44.

A control with a “MUST” or “MUST NOT” requirement indicates that use, or non-use, of the control is essential in order to effectively manage the identified risk, unless the control is demonstrably not relevant to the respective system.  These controls are baseline controls, sometimes described as systems hygiene controls.

1.1.45.

The rationale for non-use of essential controls MUST be clearly demonstrated to the Accreditation Authority as part of the certification process, before approval for exceptions is granted.  MUST and MUST NOT controls take precedence over SHOULD and SHOULD NOT controls.

Controls with a “SHOULD” or “SHOULD NOT” requirement

1.1.46.

A control with a “SHOULD” or “SHOULD NOT” requirement indicates that use, or non-use, of the control is considered good and recommended practice. Valid reasons for not implementing a control could exist, including:

  1. A control is not relevant in the agency;
  2. A system or ICT capability does not exist in the agency; or 
  3. A process or control(s) of equal strength has been substituted.
1.1.47.

While some cases may require a simple record of fact, agencies must recognise that non-use of any control, without due consideration, may increase residual risk for the agency. This residual risk needs to be agreed and acknowledged by the Accreditation Authority. In particular an agency should pose the following questions:

  1. Is the agency willing to accept additional risk?
  2. Have any implications for All-of-Government systems been considered?
  3. If, so, what is the justification?
1.1.48.

A formal auditable record of this consideration and decision is required as part of the IA governance and assurance processes within an agency.

Non-compliance

1.1.49.

Non-compliance is a risk to the agency and may also pose risks to other agencies and organisations.  Good governance requires these risks are clearly articulated, measures are implemented to manage and reduce the identified risks to acceptable levels, that the Accreditation Authority is fully briefed, acknowledges any residual and additional risk and approves the measures to reduce risk. 

1.1.50.

In some circumstances, full compliance with this manual may not be possible, for example some legacy systems may not support the configuration of particular controls.  In such circumstances, a risk assessment should clearly identify compensating controls to reduce risks to an acceptable level.  Acceptance of risk or residual risk, without due consideration is NOT adequate or acceptable.

1.1.51.

It is recognised that agencies may not be able to immediately implement all controls described in the manual due to resource, budgetary, capability or other constraints.  Good practice risk management processes will acknowledge this and prepare a timeline and process by which the agency can implement all appropriate controls described in this manual.  

1.1.52.

Simply acknowledging risks and not providing the means to implement controls does not represent effective risk management.

1.1.53.

Where multiple controls are not relevant or an agency chooses not to implement multiple controls within this manual the system owner may choose to logically group and consolidate controls when following the processes for non-compliance.

Rationale Statements

1.1.54.

A short rationale is provided with each group of controls.  It is intended that this rationale is read in conjunction with the relevant controls in order to provide context and guidance.

Risk management

Risk Management Standards

1.1.55.

For security risk management to be of true value to an agency it MUST relate to the specific circumstances of an agency and its systems, as well as being based on an industry recognised approach or risk management guidelines.  For example, guidelines and standards produced by Standards New Zealand and the International Organization for Standardization (ISO).

1.1.56.

The International Organization for Standardization has published an international risk management standard, including principles and guidelines on implementation, outlined in ISO 31000:2018 - Risk Management - Guidelines.  Refer to the tables below for additional reference materials.

The NZISM and Risk Management

1.1.57.

The ISM encapsulates good and recommended best-practice in managing technology risks and mitigating or minimising threat to New Zealand government information systems.

1.1.58.

Because there is a broad range of systems across government and the age and technological sophistication of these systems varies widely, there is no single governance, assurance, risk or controls model that will accommodate all agencies information and technology security needs. 

1.1.59.

The NZISM contains guidance on governance and assurance processes and technological controls based on comprehensive risk and threat assessments, research and environmental monitoring.

1.1.60.

The NZISM encourages agencies to take a similar risk-based approach to information security.  This approach enables the flexibility to allow agencies to conduct their business and maintain resilience in the face of a changing threat environment, while recognising the essential requirements and guidance provided by the NZISM.

References

1.1.61.

This manual is updated regularly.  It is therefore important that agencies ensure that they are using the latest version of this Manual.

References Publisher Source
The NZISM and additional information, tools and discussion topics can be accessed from the GCSB website GCSB http://www.gcsb.govt.nz
Protective Security Requirements (PSR) NZSIS http://www.protectivesecurity.govt.nz
Another definitive reference is the ISO standard ISO/IEC 27000:2014 Information Technology – Security Techniques – Information Security Management Systems – Overview and Vocabulary (third edition)

ISO / IEC

Standards NZ

http://www.iso27001security.com/html/27000.html 

http://www.standards.co.nz

CNSS Instruction No. 4009 26 April 2010 – National Information Assurance (IA) Glossary, (US),  Committee on National Security Systems (CNSS)

http://www.ncsc.gov/nittf/docs/CNSSI-4009_National_Information_Assurance.pdf 

 

NISTIR 7298 Revision 2 – Glossary of Key Information Security Terms, May 2013 NIST

http://nvlpubs.nist.gov/nistpubs/ir/2013/NIST.IR.7298r2.pdf 

1.1.62.

Supplementary information to this manual can be found in the following documents.

Topic Documentation Source
Approved Products Common Criteria ISO/IEC 15408, parts 1,2 & 3

ISO

http://www.iso.org

   AISEP Evaluated Products List

ASD

http://www.asd.gov.au

  Other Evaluated Products Lists

NSA

http://www.nsa.gov

NCSC UK

http://www.ncsc.gov.uk/

CSEC

https://www.cse-cst.gc.ca

Common Criteria

https://www.commoncriteriaportal.org/

Archiving of information Public Records Act 2005 (as amended) Archives New Zealand or http://www.legislation.govt.nz 
  Archives, Culture, and Heritage Reform Act 2000 (as amended) Archives New Zealand or http://www.legislation.govt.nz 
Business continuity ISO 22301:2012, Business Continuity  Standards New Zealand

http://www.standards.govt.nz

Cable security NZCSS 400: New Zealand Communications Security Standard No 400 (Document classified CONFIDENTIAL) GCSB

CONFIDENTIAL document available on application to authorised personnel

Emanation security NZCSS 400: New Zealand Communications Security Standard No 400 (Document classified CONFIDENTIAL) GCSB

CONDFIDENTIAL document available on application to authorised personnel

Information classification Protective Security Requirements (New Zealand Government Security Classification System Handling Requirements for protectively marked information and equipment) NZSIS

http://www.protectivesecurity.govt.nz

Information security management  ISO/IEC 27001:2013 ISO / IEC

http://www.iso27001security.com/html/27001.html
Standards New Zealand
http://www.standards.govt.nz

  ISO/IEC 27002:2013 ISO / IEC

http://www.iso27001security.com/html/27001.html
Standards New Zealand
http://www.standards.govt.nz

  Other standards and guidelines in the ISO/IEC 270xx series, as appropriate ISO / IEC

http://www.iso27001security.com/html/27001.html
Standards New Zealand
http://www.standards.govt.nz

Key management – commercial grade AS 11770.1:2003, Information Technology – Security Techniques – Key Management – Framework Standards New Zealand
http://www.standards.govt.nz
Cryptographic Security NZCSS 300: New Zealand Communications Security Standard No 300 (Document classified RESTRICTED) GCSB

RESTRICTED document available on application to authorised personnel

Management of electronic records that may be used as evidence HB 171:2003, Guidelines for the Management of Information Technology Evidence Standards New Zealand
http://www.standards.govt.nz
Personnel security PSR, Protective Security Requirements NZSIS

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/personnel-security/

Physical security PSR, Protective Security Requirements NZSIS

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/physical-security/

Privacy requirements Privacy Act 1993 (the Privacy Act) Office of The Privacy Commissioner

http://www.privacy.org.nz

Risk management ISO 31000:2018 - Risk Management -- Guidelines Standards New Zealand
http://www.standards.govt.nz
  ISO 27005:2011, Information Security Risk Management  Standards New Zealand
http://www.standards.govt.nz
  HB 436:2013, Risk Management Guidelines Standards New Zealand
http://www.standards.govt.nz
  ISO/IEC Guide 73, Risk Management – Vocabulary – Guidelines for use in Standards Standards New Zealand
http://www.standards.govt.nz
  NIST SP 800-30, Risk Management Guide for Information Technology Systems http://www.nist.gov
Security Management HB167, Security Risk Management Standards New Zealand
http://www.standards.govt.nz
Security And Intelligence Legislation Intelligence and Security Act 2017 http://www.legislation.govt.nz 
  Telecommunications (Interception Capability and Security) Act 2013 (as amended) http://www.legislation.govt.nz 

Rationale & Controls

1.1.63. Non-compliance

1.1.63.R.01.Rationale

Controls for classified systems and information within this manual with a “MUST” or “MUST NOT” compliance requirement cannot be effectively individually risk managed by agencies without jeopardising their own, multi-agency or All-of-Government information assurance.

1.1.63.R.02.Rationale

Controls within this manual with a “SHOULD” and “SHOULD NOT” requirement may be risk managed by agencies. As the individual control security risk for non-compliance is not as high as those controls with a ‘MUST’ or ‘MUST NOT’ requirement, the Accreditation Authority can consider the justification for the acceptance of risks, consider any mitigations then acknowledge and accept any residual risks.

1.1.63.R.03.Rationale

Deviations from the procedures and controls in the NZISM may represent risks in themselves. It is important that governance and assurance is supported by evidence, especially where deviations from the procedures and controls in the NZISM are accepted.  In this case a formal approval or signoff by the Accreditation Authority is essential. Ultimately, the Agency Head remains accountable for the ICT risks and information security of their agency.

1.1.63.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:127]

System owners seeking a dispensation for non-compliance with any essential controls in this manual MUST be granted a dispensation by their Accreditation Authority. Where High Grade Cryptographic Systems (HGCS) are implemented, the Accreditation Authority will be the Director-General GCSB or a formal delegate.

1.1.64. Justification for non-compliance

1.1.64.R.01.Rationale

Without sufficient justification and consideration of security risks by the system owner when seeking a dispensation, the agency head or their authorised delegate will lack the appropriate range of information to the make an informed decision on whether to accept the security risk and grant the dispensation or not.

1.1.64.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:131]

System owners seeking a dispensation for non-compliance with essential controls MUST complete an agency risk assessment which documents:

  • the reason(s) for not being able to comply with this manual;
  • the effect on any of their own, multi-agency or All-of-Government system;
  • the alternative mitigation measure(s) to be implemented;
  • The strength and applicability of the alternative mitigations;
  • an assessment of the residual security risk(s); and
  • a date by which to review the decision.

1.1.65. Consultation on non-compliance

1.1.65.R.01.Rationale

When an agency stores information on their systems that belongs to a foreign government they have an obligation to inform and seek agreement from that third party when they do not apply all appropriate controls in this manual. These third parties will place reliance on the application of controls from the NZISM. If the agency fails to implement all appropriate controls, the third party will be unaware that their information may have been placed at a heightened risk of compromise. As such, the third party is denied the opportunity to consider their own additional risk mitigation measures for their information in light of the agency’s desire to risk manage controls from this manual.

1.1.65.R.02.Rationale

Most New Zealand Government agencies will store or processes information on their systems that originates from another New Zealand Government Agency. The use of the NZ Government Security Classification System, and implementation of its attendant handling instructions, provides assurance to the originating agency that the information is adequately safeguarded.

1.1.65.R.03.Rationale

Additional controls, not described or specified in this manual, are welcomed as a means of improving and strengthening security of information systems, provided there are no obvious conflicts or contradictions with the controls in this manual. A comprehensive risk assessment of the additional controls is a valuable means of determining the effectiveness of additional controls.

1.1.65.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:137]

If a system processes, stores or communicates classified information from another agency, that agency MUST be consulted before a decision to be non-compliant with the NZ Government Security Classification System is made.

1.1.65.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:138]

If a system processes, stores or communicates classified information from a foreign government, that government MUST be consulted before a decision to be non-compliant with NZISM controls is made.

1.1.66. All-of-Government Systems

1.1.66.R.01.Rationale

All-of-Government systems, because they are connected to multiple agencies, have the potential to cause significant and widespread disruption should system failures, cyber-attacks or other incidents occur.

1.1.66.R.02.Rationale

Any deviation from the essential controls specified in the NZISM MUST necessarily be carefully considered and their implication and risk for all government systems understood and agreed by all interested parties.

1.1.66.R.03.Rationale

Interested parties may include the lead agency, the Government CIO and key service providers, such as with cloud services.

1.1.66.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:143]

If a system processes, stores or communicates data and information with multiple agencies or forms part of an All-of-Government system, interested parties MUST be formally consulted before non-compliance with any essential controls.

1.1.67. Reviewing non-compliance

1.1.67.R.01.Rationale

As part of the process of providing justification for a dispensation to the Accreditation Authority, an assessment of the degree of compliance, identification of areas of non-compliance and determination of residual security risk is undertaken by the agency or lead agency. This assessment is based on the risk environment at the time the dispensation is sought. As the risk environment will continue to evolve over time it is important that agencies revisit the assessment on an annual basis and update it according to the current risk environment, and if necessary reverse any decisions to grant a dispensation if the security risk is no longer of an acceptable level.

1.1.67.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:146]

Agencies SHOULD review decisions to be non-compliant with any controls at least annually.

1.1.68. Recording non-compliance

1.1.68.R.01.Rationale

Without appropriate records of decisions to risk manage controls from this manual, agencies have no record of the status of information security within their agency.  Furthermore, a lack of such records will hinder any governance, compliance or auditing activities that may be conducted.  

1.1.68.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:151]

Agencies MUST retain a copy and maintain a record of the supporting risk assessment and decisions to be non-compliant with any essential controls from this manual.

1.1.68.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:152]

Where good and recommended practice controls are NOT implemented, agencies MUST record and formally recognise that non-use of any controls without due consideration may increase residual risk for the agency. This residual risk MUST be agreed and acknowledged by the Accreditation Authority.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

1.2. Applicability, Authority and Compliance

Objective

1.2.1.

Agencies understand and follow the requirements of the New Zealand Information Security Manual. Protection of government information and systems is a core accountability.

Context

Scope

1.2.2.

The NZISM provides guidance and specific ICT controls that form part of a suite of requirements produced by GCSB relating to information security.  Its role is to promote a consistent approach to information assurance and information security across all New Zealand Government agencies.  It is based on security risk assessments for any information that is processed, stored or communicated by government systems with corresponding risk treatments (control sets) to reduce the level of security risk to an acceptable level.

Applicability

1.2.3.

This manual applies to:

  • New Zealand Government departments, agencies and organisations as listed in:
    • Parts 1 and 2 of Schedule 1 to the Ombudsmen Act 1975 (as amended); and
    • Schedule 1 to the Official Information Act 1982.
  • any other organisations that have entered into a formal Agreement with the New Zealand Government to have access to classified information.

Authority

1.2.4.

The Intelligence and Security Act 2017 provides that one of the functions of the GCSB is to co-operate with, and provide advice and assistance to, any public authority whether in New Zealand or overseas, or to any other entity authorised by the Minister responsible for the GCSB on any matters relating to the protections, security and integrity of communications; and information structures of importance to the Government of New Zealand.  The NZISM is one aspect of the GCSB’s advice and assistance to government agencies on information security. 

1.2.5.

This function furthers the objective of the GCSB to contribute to:

  • The national security of New Zealand; and
  • The international relations and well-being of New Zealand; and
  • The economic well-being of New Zealand.
1.2.6.

The NZISM is intended to structure and assist the implementation of government policy that requires departments and agencies to protect the privacy, integrity and confidentiality of the information they collect, process, store and archive.  While these overarching requirements are mandatory for departments and agencies, compliance with the NZISM is not required as a matter of law.  The controls in the NZISM could be made binding on departments and agencies, either by legislation, or Cabinet direction.

1.2.7.

The Protective Security Requirements Framework provides a specific authority and mandate through a Cabinet Directive CAB MIN (14) 39/38.

Compliance by smaller agencies

1.2.8.

As smaller agencies may not always have sufficient staffing or budgets to comply with all the requirements of this manual, they may choose to consolidate their resources with another larger host agency to undertake a joint approach.

1.2.9.

In such circumstances smaller agencies may choose to either operate on systems fully hosted by another agency using their information security policies and information security resources or share information security resources to jointly develop information security policies and systems for use by both agencies.  The requirements within this manual can be interpreted as either relating to the host agency or to both agencies, depending on the approach taken.

1.2.10.

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 regarding their information security responsibilities.

Legislation and other government policy

1.2.11.

While this manual does contain examples of relevant legislation (see Tables 1.1.59 and 1.1.60), there is no comprehensive consideration of such issues.  Accordingly, agencies should rely on their own inquiries in that regard.

1.2.12.

All controls within this manual may be used as the basis for internal and external annual audit programmes, any review or investigation by the Controller and Auditor-General or referenced for assurance purposes by the Government Chief Information Officer (GCIO).

Rationale & Controls

1.2.13. Compliance

1.2.13.R.01.Rationale

In complying with the latest version of this manual agencies awareness of the current threat environment for government systems and the associated acceptable level of security risk is vital. Furthermore, if a system is designed to an out-dated standard, agencies may need additional effort to obtain accreditation for their systems.

1.2.13.R.02.Rationale

GCSB continuously monitors technology developments in order to identify business risks, technology risks and security threats.  If a significant risk is identified, research may be undertaken, additional controls identified and implementation timeframes specified.

1.2.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:177]

Agencies undertaking system design activities for in-house or out-sourced projects MUST use the latest version of this manual for information security requirements.

1.2.13.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:178]

When GCSB makes a determination that newly introduced standard, policy or guideline within this manual, or any additional information security policy, is of particular importance, agencies MUST comply with any new specified requirements and implementation timeframes.

2. Information Security within Government

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

2.1. Government Engagement

Objective

2.1.1.

Security personnel are aware of and use information security services offered within the New Zealand Government.

Context

Scope

2.1.2.

This section covers information on organisations involved in providing information security advice to agencies.

Government Communications Security Bureau

2.1.3.

GCSB is required to perform various functions, including the provision of material, advice and other assistance to New Zealand government departments on matters relating to the security of classified information that is processed, stored or communicated by electronic or similar means.  GCSB also provides assistance to New Zealand government departments in relation to cryptography, communications and computer technologies.

2.1.4.

An agency can contact GCSB for advice and assistance relating to the implementation of the NZISM by emailing ism@gcsb.govt.nz or phone the GCSB’s Information Assurance Directorate on (04) 472-6881.

2.1.5.

An agency can contact GCSB to provide feedback on the NZISM via email as above.

2.1.6.

Agencies can also contact GCSB for advice and assistance on the reporting and management of information security incidents.  GCSB’s response will be commensurate with the nature and urgency of the information security incident.  There is a 24 hour, seven day a week service available if necessary.  

2.1.7.

Finally, agencies can contact GCSB for advice and assistance on the purchasing, provision, deployment, operation and disposal of High Grade Cryptographic Equipment (HGCE).  The cryptographic liaison can be contacted by email at products.systems@gcsb.govt.nz.

Other organisations

2.1.8.

The table below contains a brief description of the other organisations which have a role in relating to information security within government.

Organisation Services
Archives New Zealand  Provides information on the archival of government information.
Auditor General Independent assurance over the performance and accountability of public sector organisations.
Audit New Zealand Performance audits and better practice guides for areas including information security.
Department of Internal Affairs Guidance on risk management, Authentication Standards, One.govt and i-govt services.
Department of Prime Minister and Cabinet National security advice to government.
Ministry of Business, Innovation & Employment (MBIE) Development, coordination and oversight of New Zealand Government policy on electronic commerce, online services and the Internet.
Ministry of Foreign Affairs and Trade  Policy and advice for security overseas.
National Cyber Security Centre (NCSC) Provides enhanced services to government agencies and critical infrastructure providers to assist them to defend against cyber-borne threats.
New Zealand Police  Law enforcement in relation to electronic crime and other high tech crime.
New Zealand Security Intelligence Service 

Personnel and Physical security advice

Maintenance of the New Zealand Government Security Classification System.

Office of the Government Chief Information Officer (DIA) Advice, guidance and management for sector and All-of-Government systems and ICT processes.  ICT assurance (including privacy and security).
Privacy Commissioner Advice on how to comply with the Privacy Act and related legislation.
State Services Commission Monitoring of Public Service organisations and Chief Executives’ performance.
DIA Government Chief Privacy Office (GCPO).
NZCERT General reporting of Cyber Security problems.

References

2.1.9.

The following websites can be used to obtain additional information about the security of government systems:

Organisation   Source
Government Communications Security Bureau   http://www.gcsb.govt.nz 
Archives New Zealand   http://www.archives.govt.nz  
Audit New Zealand   http://www.auditnz.govt.nz  
Auditor General   http://www.oag.govt.nz  
Department of Internal Affairs  

http://www.dia.govt.nz
http://www.ict.govt.nz

Department of Prime Minister and Cabinet   http://www.dpmc.govt.nz  
Ministry of Business, Innovation & Employment (MBIE)   http://www.mbie.govt.nz
Ministry of Foreign Affairs and Trade   http://www.mfat.govt.nz
National Cyber Security Centre (NCSC)   http://www.ncsc.govt.nz
New Zealand Security Intelligence Service   http://www.nzsis.govt.nz 
New Zealand Police   http://www.police.govt.nz
Privacy Commissioner   http://www.privacy.org.nz
Protective Security Requirements   http://www.protectivesecurity.govt.nz
Standards NZ   http://www.standards.co.nz
State Services Commission   http://www.ssc.govt.nz

Rationale & Controls

2.1.10. Organisations providing information security services

2.1.10.R.01.Rationale

If security personnel are unaware of the role government organisations play with regards to information security they could be missing out on valuable insight and assistance in developing an effective information security posture for their agency.

2.1.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:199]

Security personnel SHOULD familiarise themselves with the information security roles and services provided by New Zealand Government organisations.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

2.2. Industry Engagement and Outsourcing

Objective

2.2.1.

Industry handling classified information implements the same security measures as government agencies.

Context

Scope

2.2.2.

This section covers information on outsourcing information technology services and functions to contractors as well as providing those partners with classified information in order to undertake their contracted duties.

Cloud computing

2.2.3.

Cloud computing is a form of outsourcing information technology services and functions usually over the Internet.  The requirements within this section for outsourcing equally apply to providers of cloud computing services.

PSR References

Rationale & Controls

2.2.5. Outsourcing information technology services and functions

2.2.5.R.01.Rationale

In the context of this section, outsourcing is defined as contracting an outside entity to provide essential business functions and processes that could be undertaken by the Agency itself.

Outsourcing may present elevated levels of risk and additional risks. Outsourcing therefore, requires greater consideration, demonstrable governance, and higher levels of assurance before committing to such contracts.

2.2.5.R.02.Rationale

A distinction is drawn between important business functions and the purchase of services such as power, water, building maintenance, stationery and telecommunications. These services are not usually provided by the agency itself.

Purchased services, as identified above, do NOT require accreditation or a third party review as defined in the NZISM. However, normal contract due diligence should be exercised before committing to these supply contracts.

2.2.5.R.03.Rationale

Contractors can be provided with classified information as long as their systems are accredited to an appropriate classification in order to process, store and communicate that information. Contractors and all staff with access to the classified systems must also be cleared to the level of the information being processed. This ensures that when they are provided with classified information that it receives an appropriate level of protection.

2.2.5.R.04.Rationale

New Zealand, in common with most developed countries, has agreements with other nations on information exchange on a variety of topics, including arms control, border control, biosecurity, policing and national security. The lead agency in each sector will usually be the controlling agency for each agreement. While the detail and nature of these agreements is sometimes classified, the agreements invariably require the protection of any information provided, to the level determined by the originator. Agencies that receive such information will be fully briefed by the relevant controlling agency or authority, before information is provided. It is important to note that there is no single list or source of such agreements.

2.2.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:216]

Agencies engaging industry for the provision of off-site information technology services and functions MUST accredit the systems used by the contractor to at least the same minimum standard as the agency’s systems. This may be achieved through a third party review report utilising the ISAE 3402 Assurance Reports on Controls at a Third Party Service Organisation.

2.2.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:217]

Agencies SHOULD NOT engage industry for the provision of off-site information technology services and functions in countries that New Zealand does not have a multilateral or bilateral security agreement with for the protection of classified information of the government of New Zealand. If there is any doubt, the agency’s CISO should be consulted.

2.2.6. Independence of ITSMs from outsourced companies

2.2.6.R.01.Rationale

If an agency engages an organisation for the provision of information technology services and functions, and where that organisation also provides the services of an Information Technology Security Manager, they need to ensure that there is no actual or perceived conflict of interest (See also Section 3.3 - Information Technology Security Manager).

2.2.6.R.02.Rationale

When an agency engages a company for the provision of information technology services and functions having a central point of contact for information security matters within the company will greatly assist with incident response and reporting procedures.

2.2.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:221]

Where an agency has outsourced information technology services and functions, any ITSMs within the agency SHOULD be independent of the company providing the information technology services and functions.

2.2.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:222]

Where an agency has outsourced information technology services and functions, they SHOULD ensure that the outsourced organisation provides a single point of contact within the organisation for all information assurance and security matters.

2.2.7. Developing a contractor management program

2.2.7.R.01.Rationale

The development of a contractor management program will assist the agency in undertaking a coordinated approach to the engagement and use of contractors for outsourcing and provision of information technology services and functions.

2.2.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:225]

Agencies SHOULD develop a program to manage contractors that have been accredited for the provision of off-site information technology services and functions.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

2.3. Approach to Cloud Services

Objective

2.3.1.

Agencies understand and manage their approach to cloud services securely, effectively and efficiently. 

Context

Scope

2.3.2.

This section provides guidance on approaches to cloud services. 

2.3.3.

It is important that agencies identify cloud systems risks and that Official Information and agency information systems are protected in accordance with Cabinet Directives, the Protective Security Requirements (PSR), the New Zealand Goverment Security Classification System, the NZISM and with other government security requirements and guidance.

2.3.5.

Detailed controls for Cloud Computing are provided in Section 22.1 – Cloud Computing.

Mandates, Directives and Requirements

2.3.6.

In 2012, Cabinet directed government agencies to adopt public cloud services in preference to traditional IT systems. Offshore-hosted office productivity services were excluded [CAB Min (12) 29/8A]

2.3.7.

In August 2013, the Government introduced their approach to cloud computing, establishing a ‘cloud first’ policy and an All-of-Government direction to cloud services development and deployment.  This is enabled by the Cabinet Minute [CAB Min (13) 37/6B].  Under the ‘cloud first’ policy state service agencies are expected to adopt approved cloud services either when faced with new procurements, or a contract extension decision.  

2.3.8.

Cabinet also incorporated the cloud risk assessment process into the system-wide ICT assurance framework [CAB Min (13) 20/13].

2.3.9.

The New Zealand Government ICT Strategy released in October 2015 requires agencies to outsource their IT functions using common capabilities and public cloud services where this was feasible and practical.

2.3.10.

In 2014 The Government Chief Information Officer published Cloud Computing Information Security and Privacy Considerations.  This guidance is designed to assist agencies systematically identify, analyse, and evaluate information security and privacy risks related to individual public cloud services.

2.3.11.

In July 2016, new measures were confirmed to accelerate the adoption of public cloud services by New Zealand’s government agencies.  The new measures complement existing policies and risk assessment processes and provide appropriate checks and balances.

Background

2.3.12.

The adoption of cloud technologies and services, the hosting of critical data in the cloud and the risk environment requires that agencies exercise caution.  Many cloud users are driven by the need for performance, scalability, resource sharing and cost saving so a comprehensive risk assessment is essential in identifying and managing jurisdictional, sovereignty, governance, assurance, technical and security risks.

2.3.13.

Security requirements and drivers in the cloud differ significantly from traditional data centre environments requiring new security models and architectures.  Key factors include:

  • The dynamic nature of the cloud and its related infrastructure;
  • No customer ownership or control of infrastructure;
  • Limited visibility of architectures and transparency of operations; 
  • Shared (multi-tenanted) physical and virtual environments; and
  • May require re-architecting of agency system to optimise use of cloud services.
2.3.14.

While there is potential for significant benefit, flexibility and cost saving, any use of cloud services carries risk.  All cloud computing decisions should be made on a case-by-case basis after a proper risk assessment, the agency technology architecture is developed and security is properly considered and incorporated.

2.3.15.

There is also likely to be a significant mismatch in service-level agreements (SLAs) between existing systems and outsourcing arrangements and those of cloud-based services.

2.3.16.

It is important to note that although agencies can outsource operational responsibilities to a service provider for implementing, managing and maintaining security controls, they cannot outsource their accountability for ensuring their data is appropriately protected, including any system or service decommissioning or termination.

2.3.17.

The GCIO has developed a risk and assurance framework for cloud computing, which agencies are required to follow when they are considering using cloud services. 

References

2.3.18.

Additional guidance on cloud services can be found at:

Reference/Title

Publisher Source

CAB Min (12_ 29/8A Managing The Government’s Adoption of Cloud Computing

Cabinet Office

https://www.ict.govt.nz/assets/Uploads/Documents/CabMin12-cloud-computing.pdf

CAB Min (13) 20/13 Improving Government Information and Communications Technology Assurance

Cabinet Office

https://www.ict.govt.nz/assets/Cabinet-Papers/Cab-Minute-Improving-Govt-ICT-Assurance-June-2013.pdf

Cloud Computing – Information Security and Privacy Considerations April 2014

DIA

https://www.ict.govt.nz/assets/ICT-System-Assurance/Cloud-Computing-Information-Security-and-Privacy-Considerations-FINAL2.pdf

Government ICT Strategy 2015

DIA

https://www.ict.govt.nz/strategy-and-action-plan/strategy/

Accelerating the Adoption of Public Cloud Services

DIA

https://www.ict.govt.nz/assets/Cloud-computing/Accelerating-the-Adoption-of-Public-Cloud-Services-Redacted.pdf

Cloud Risk Assessment Tool [Excel Spreadsheet]

DIA

https://www.ict.govt.nz/assets/Guidance-and-Resources/Cloud-ICT-Assurance/Cloud-Risk-Assessment-Tool-v1-1-1.xlsx

Risk Assessment Process

DIA

https://www.ict.govt.nz/assets/ICT-System-Assurance/Risk-Assessment-Process-Information-Security.pdf

PSR References

Rationale & Controls

2.3.20. Risk Assessment

2.3.20.R.01.Rationale

The adoption of cloud technologies will introduce a wide range of technology and information system risks in addition to the risks that already exist for agency systems. It is vital that these additional risks are identified and assessed in order to select appropriate controls and countermeasures. Trust boundaries must be defined to assist in determining effective controls and where these controls can best be applied. The geographic location of agency data should be identified as this may include offshore data centres.

2.3.20.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:255]

Agencies intending to adopt cloud technologies or services MUST conduct a comprehensive risk assessment, in accordance with the guidance provided by the GCIO before implementation or adoption.

2.3.20.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:256]

Agencies MUST ensure cloud risks for any cloud service adopted are identified, understood and formally accepted by the Agency Head or Chief Executive and the agency’s Accreditation Authority.

2.3.21. Security Architecture

2.3.21.R.01.Rationale

The adoption of cloud technologies will introduce a wide range of technology and information system risks in addition to the risks that already exist for agency systems.  It is vital that these additional risks are identified and assessed in order to select appropriate controls and countermeasures.

2.3.21.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:259]

Agencies intending to adopt cloud services SHOULD review and enhance existing security architectures and systems design to prudently manage the changed risk, technology and security environment in adopting cloud services.

2.3.22. Selection of Services

2.3.22.R.01.Rationale

A number of cloud related service, contracts and other arrangements have been negotiated on behalf of the New Zealand Government with a number of cloud service providers. Agencies must consider these services before negotiating individual contracts or supply contract with cloud service providers.

2.3.22.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:4935]

Agencies MUST consider the use of any All of Government contracts with cloud service providers before negotiating individual contracts.

2.3.23. System Decommissioning and Contract Termination

2.3.23.R.01.Rationale

It is important that agencies understand how and where their data is processed, managed, stored, backed up and archived within the cloud service provider’s environment.  This may result in multiple copies of agency data in several data centres, possibly also in several countries.

2.3.23.R.02.Rationale

When an agency system or service is decommissioned or a service provider’s contract terminated, it is important that agencies ensure data is returned to the agency and no copies are retained by the service provider.

2.3.23.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:263]

Agency system architectures and supply arrangements and contracts SHOULD include provision for the safe return of agency data in the event of system or service termination or contract termination.

3. Information security governance - roles and responsibilities

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

3.1. The Agency Head

Objective

3.1.1.

The agency head endorses and is accountable for information security within their agency.

Context

Scope

3.1.2.

This section covers the role of an agency head with respect to information security.

Chief executive officer /or other title

3.1.3.

In some agencies and bodies, the person responsible for the agency or body may also be referred to as the CEO, Director General, Director or similar title specific to that agency.  In such cases the policy for the agency head is equally applicable.

Devolving authority

3.1.4.

When the agency head’s authority in this area has been devolved to a board, committee or panel, the requirements of this section relate to the chair or head of that body.

3.1.5.

The Agency Head is also the Accreditation Authority for that agency. See also Section 4.4 – Accreditation Framework.

3.1.6.

Smaller agencies may not be able to satisfy all segregation of duty requirements because of scalability and small personnel numbers. In such cases, potential conflicts of interest should be clearly identified, declared and actively managed for the protection of the individual and of the agency.

3.1.7.

Refer also to Compliance By Smaller Agencies in 1.2.8 for information on joint approaches and resource pooling.

Rationale & Controls

3.1.8. Delegation of authority

3.1.8.R.01.Rationale

When an agency head chooses to delegate their authority as the Agency’s Accreditation Authority they should do so with careful consideration of all the associated risks, as they remain responsible for the decisions made by their delegate.

3.1.8.R.02.Rationale

The CISO is the most appropriate choice for delegated authority as they should be a senior executive and hold specialised knowledge in information security and security risk management.

3.1.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:282]

Where the agency head devolves their authority the delegate MUST be at least a member of the Senior Executive Team or an equivalent management position.

3.1.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:283]

When the agency head devolves their authority the delegate SHOULD be the CISO.

3.1.8.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:284]

Where the head of a smaller agency is not able to satisfy all segregation of duty requirements because of scalability and small personnel numbers, all, potential conflicts of interest SHOULD be clearly identified, declared and actively managed.

3.1.9. Support for information security

3.1.9.R.01.Rationale

Without the full support of the agency head, security personnel are less likely to have access to sufficient resources and authority to successfully implement information security within their agency.

3.1.9.R.02.Rationale

If an incident, breach or disclosure of classified information occurs in preventable circumstances, the relevant agency head will ultimately be held accountable.

3.1.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:288]

The agency head MUST provide support for the development, implementation and ongoing maintenance of information security processes within their agency.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

3.2. The Chief Information Security Officer

Objective

3.2.1.

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

Context

Scope

3.2.2.

This section covers the role of a CISO with respect to information security within an agency.

Appointing a CISO

3.2.3.

The requirement to appoint a member of the Senior Executive Team or an equivalent management position, to the role of CISO does not require a new dedicated position be created in each agency.

3.2.4.

The introduction of the CISO role and associated responsibilities is aimed at providing a more meaningful title for a subset of the security executive’s responsibilities that relate to information security within their agency.

3.2.5.

The CISO should bring accountability and credibility to information security management and appointees should be suitably qualified and experienced.

3.2.6.

Where multiple roles are held by the CISO, for example CIO, or manager of a business unit, conflicts of interest may occur where operational imperatives conflict with security requirements. Good practice separates these roles. Where multiple roles are held by an individual, potential conflicts of interest should be clearly identified and a mechanism implemented to allow independent decision making in areas where conflict may occur.

PSR references

Rationale & Controls

3.2.8. Requirement for a CISO

3.2.8.R.01.Rationale

The role of the CISO is based on industry and governance good practice and has been introduced to ensure that information security is managed at the senior executive level within agencies. Without a CISO there is a risk that an agency may not be resourced to effectively manage information security.

3.2.8.R.02.Rationale

The CISO within an agency is responsible predominately for facilitating communications between security personnel, ICT personnel and business personnel to ensure alignment of business and security objectives within the agency.

3.2.8.R.03.Rationale

The CISO is also responsible for providing strategic level guidance for the agency security program and ensuring compliance with national policy, standards, regulations and legislation.

3.2.8.R.04.Rationale

Some agencies may outsource the CISO function. In such cases conflicts of interest, availability and response times should be identified and carefully managed so the agency is not disadvantaged. Conflicts of interest may also be apparent where the outsourced CISO deals with other vendors.

3.2.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:307]

The CISO MUST be:

  • cleared for access to all classified information processed by the agency’s systems, and
  • able to be briefed into any compartmented information on the agency’s systems.
3.2.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:308]

Agencies SHOULD appoint a person to the role of CISO or have the role undertaken by an existing person within the agency.

3.2.8.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:309]

The CISO role SHOULD be undertaken by a member of the Senior Executive Team or an equivalent management position.

3.2.8.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:310]

The CISO SHOULD be responsible for overseeing the management of security personnel within the agency.

3.2.8.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:311]

Where the role of the CISO is outsourced, potential conflicts of interest in availability, response times or working with vendors SHOULD be identified and carefully managed.

3.2.9. Responsibilities – Reporting

3.2.9.R.01.Rationale

As the CISO is responsible for the overall management of information security within an agency it is important that they report directly to the agency head on any information security issues.

3.2.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:314]

The CISO SHOULD report directly to the agency head on matters of information security within the agency.

3.2.10. Responsibilities – Security programs

3.2.10.R.01.Rationale

Without a comprehensive strategic level information security and security risk management program an agency will lack high-level direction on information security issues and may expose the agency to unnecessary risk.

3.2.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:317]

The CISO SHOULD develop and maintain a comprehensive strategic level information security and security risk management program within the agency aimed at protecting the agency’s official and classified information.

3.2.10.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:318]

The CISO SHOULD be responsible for the development of an information security communications plan.

3.2.10.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:319]

The CISO SHOULD create and facilitate the agency security risk management process.

3.2.11. Responsibilities – Ensuring compliance

3.2.11.R.01.Rationale

Without having a person responsible for ensuring compliance with the information security policies and standards within the agency, security measures of the agency are unlikely to meet minimum government requirements and may expose the agency to unnecessary risk.

3.2.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:322]

The CISO SHOULD be responsible for ensuring compliance with the information security policies and standards within the agency.

3.2.11.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:323]

The CISO SHOULD be responsible for ensuring agency compliance with the NZISM through facilitating a continuous program of certification and accreditation based on security risk management.

3.2.11.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:324]

The CISO SHOULD be responsible for the implementation of information security measurement metrics and key performance indicators within the agency.

3.2.12. Responsibilities – Coordinating security

3.2.12.R.01.Rationale

One of the core roles of the CISO is to ensure appropriate communication between business and information security teams within their agency. This includes interpreting information security concepts and language into business concepts and language as well as ensuring that business teams consult with information security teams to determine appropriate security measures when planning new business projects for the agency.

3.2.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:327]

The CISO SHOULD facilitate information security and business alignment and communication through an information security steering committee or advisory board which meets formally and on a regular basis, and comprises key business and ICT executives.

3.2.12.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:328]

The CISO SHOULD be responsible for coordinating information security and security risk management projects between business and information security teams.

3.2.12.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:329]

The CISO SHOULD work with business teams to facilitate security risk analysis and security risk management processes, including the identification of acceptable levels of risk consistently across the agency.

3.2.13. Responsibilities – Working with ICT projects

3.2.13.R.01.Rationale

As the CISO is responsible for the development of the strategic level information security program within an agency they are best placed to advise ICT projects on the strategic direction of information security within the agency.

3.2.13.R.02.Rationale

As the CISO is responsible for the overall management of information security within an agency, they are best placed to recommend to the accreditation authority the acceptance of residual security risks associated with the operation of agency systems.

3.2.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:333]

The CISO SHOULD provide strategic level guidance for agency ICT projects and operations.

3.2.13.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:334]

The CISO SHOULD liaise with agency architecture teams to ensure alignment between security and agency architectures.

3.2.14. Responsibilities – Working with vendors

3.2.14.R.01.Rationale

Having the CISO coordinate the use of external information security resources will ensure that a consistent approach is being applied across the agency.

3.2.14.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:337]

The CISO SHOULD coordinate the use of external information security resources to the agency including contracting and managing the resources.

3.2.15. Responsibilities – Budgeting

3.2.15.R.01.Rationale

Controlling the information security budget will ensure that the CISO has sufficient access to funding to support information security projects and initiatives.

3.2.15.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:341]

The CISO SHOULD be responsible for controlling the information security budget.

3.2.16. Responsibilities – Information security incidents

3.2.16.R.01.Rationale

To ensure that the CISO is able to accurately report to the agency head on information security issues within their agency it is important that they remain fully aware of all information security incidents within their agency.

3.2.16.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:345]

The CISO SHOULD be fully aware of all information security incidents within the agency.

3.2.17. Responsibilities – Disaster recovery

3.2.17.R.01.Rationale

Restoring business-critical services to an operational state after a disaster is an important function of business continuity. As such it will need high level support from the CISO.

3.2.17.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:348]

The CISO SHOULD coordinate the development of disaster recovery policies and standards within the agency to ensure that business-critical services are supported appropriately and that information security is maintained in the event of a disaster.

3.2.18. Responsibilities – Training

3.2.18.R.01.Rationale

To ensure personnel within an agency are actively contributing to the information security posture of the agency, an information security awareness and training program will need to be developed. As the CISO is responsible for information security within the agency they will need to oversee the development and operation of the program.

3.2.18.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:351]

The CISO SHOULD be responsible for overseeing the development and operation of information security awareness and training programs within the agency.

3.2.19. Responsibilities – Providing security knowledge

3.2.19.R.01.Rationale

The CISO is not expected to be a technical expert on information security matters; however, knowledge of national and international standards and good practice will assist in communicating with technical experts within their agency on information security matters.

3.2.19.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:354]

The CISO SHOULD provide authoritative security advice and have familiarity with a range of national and international standards and good practice.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

3.3. Information Technology Security Managers

Objective

3.3.1.

Information Technology Security Managers (ITSM) provide information security leadership and management within their agency.

Context

Scope

3.3.2.

This section covers the role of an ITSM with respect to information security within an agency.

Information technology security managers

3.3.3.

ITSMs are executives within an agency that act as a conduit between the strategic directions provided by the CISO and the technical efforts of systems administrators. The main area of responsibility of an ITSM is that of the administrative and process controls relating to information security within the agency.

Rationale & Controls

3.3.4. Requirement for ITSMs

3.3.4.R.01.Rationale

When agencies outsource their ICT services, ITSMs should be independent of any company providing ICT services. This will prevent any conflict of interest for an ITSM in conducting their duties.

3.3.4.R.02.Rationale

Ensure that the agency has a point of presence at sites to assist with monitoring information security for systems and responding to any information security incidents.

3.3.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:367]

Agencies MUST appoint at least one ITSM within their agency.

3.3.4.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:368]

ITSMs MUST be:

  • cleared for access to all classified information processed by the agency’s systems; and
  • able to be briefed into any compartmented information on the agency’s systems.
3.3.4.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:369]

Where an agency is spread across a number of geographical sites, it is recommended that the agency SHOULD appoint a local ITSM at each major site.

3.3.4.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:370]

The ITSM role SHOULD be undertaken by personnel with an appropriate level of authority and training based on the size of the agency or their area of responsibility within the agency.

3.3.4.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:371]

ITSMs SHOULD NOT have additional responsibilities beyond those needed to fulfil the role as outlined within this manual.

3.3.5. Responsibilities – Security programs

3.3.5.R.01.Rationale

As ITSMs undertake operational management of information security within an agency they can provide valuable input to the development of the information security program by the CISO.

3.3.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:375]

ITSMs SHOULD work with the CISO to develop an information security program within the agency.

3.3.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:376]

ITSMs SHOULD undertake and manage projects to address identified security risks.

3.3.6. Responsibilities – Working with ICT projects

3.3.6.R.01.Rationale

As ITSMs have knowledge of all aspects of information security they are best placed to work with ICT projects within the agency to identify and incorporate appropriate information security measures.

3.3.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:379]

ITSMs MUST be responsible for assisting system owners to obtain and maintain the accreditation of their systems.

3.3.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:380]

ITSMs SHOULD identify systems that require security measures and assist in the selection of appropriate information security measures for such systems.

3.3.6.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:381]

ITSMs SHOULD consult with ICT project personnel to ensure that information security is included in the evaluation, selection, installation, configuration and operation of IT equipment and software.

3.3.6.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:382]

ITSMs SHOULD work with agency enterprise architecture teams to ensure that security risk assessments are incorporated into system architectures and to identify, evaluate and select information security solutions to meet the agency’s security objectives.

3.3.6.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:383]

ITSMs SHOULD work with system owners, systems certifiers and systems accreditors to determine appropriate information security policies for their systems and ensure consistency with the Protective Security Requirements (PSR) and in particular the relevant NZISM components.

3.3.6.C.06.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:384]

ITSMs SHOULD be included in the agency’s change management and change control processes to ensure that risks are properly identified and controls are properly applied to manage those risks.

3.3.6.C.07.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:385]

ITSMs SHOULD notify the Accreditation Authority of any significant change that may affect the accreditation of that system.

3.3.7. Responsibilities – Working with vendors

3.3.7.R.01.Rationale

The CISO will coordinate the use of external information security resources to the agency, whilst ITSMs will be responsible for establishing contracts and service-level agreements on behalf of the CISO.

3.3.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:388]

ITSMs SHOULD liaise with vendors and agency purchasing and legal areas to establish mutually acceptable information security contracts and service-level agreements.

3.3.8. Responsibilities – Implementing security

3.3.8.R.01.Rationale

The CISO will set the strategic direction for information security within the agency, whereas ITSMs are responsible for managing the implementation of information security measures within the agency.

3.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:391]

ITSMs MUST be responsible for ensuring the development, maintenance, updating and implementation of Security Risk Management Plans (SRMPs), Systems Security Plans (SecPlan) and any Standard Operating Procedures (SOPs) for all agency systems.

3.3.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:392]

ITSMs SHOULD conduct security risk assessments on the implementation of new or updated IT equipment or software in the existing environment and develop treatment strategies if necessary.

3.3.8.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:393]

ITSMs SHOULD select and coordinate the implementation of controls to support and enforce information security policies.

3.3.8.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:394]

ITSMs SHOULD provide leadership and direction for the integration of information security strategies and architecture with agency business and ICT strategies and architecture.

3.3.8.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:395]

ITSMs SHOULD provide technical and managerial expertise for the administration of information security management tools.

3.3.9. Responsibilities – Budgeting

3.3.9.R.01.Rationale

As ITSMs are responsible for the operational management of information security projects and functions within their agency, they will be aware of their funding requirements and can assist the CISO to develop information security budget projections and resource allocations.

3.3.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:398]

ITSMs SHOULD work with the CISO to develop information security budget projections and resource allocations based on short-term and long-term goals and objectives.

3.3.10. Responsibilities – Reporting

3.3.10.R.01.Rationale

To ensure the CISO remains aware of all information security issues within their agency, and can brief their agency head when necessary, ITSMs will need to provide regular reports on policy developments, proposed system changes and enhancements, information security incidents and other areas of particular concern to the CISO.

3.3.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:401]

ITSMs SHOULD coordinate, measure and report on technical aspects of information security management.

3.3.10.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:402]

ITSMs SHOULD monitor and report on compliance with information security policies, as well as the enforcement of information security policies within the agency.

3.3.10.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:403]

ITSMs SHOULD provide regular reports on information security incidents and other areas of particular concern to the CISO.

3.3.10.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:404]

ITSMs SHOULD assess and report on threats, vulnerabilities, and residual security risks and recommend remedial actions.

3.3.11. Responsibilities – Auditing

3.3.11.R.01.Rationale

As system owners may not understand the results of audits against their systems ITSMs will need to assist them in understanding and responding to reported audit failures. ITSM's should also refer to 5.8 Independent Assurance Reports.  

3.3.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:407]

ITSMs SHOULD assist system owners and security personnel in understanding and responding to audit failures reported by auditors.

3.3.12. Responsibilities – Disaster recovery

3.3.12.R.01.Rationale

Whilst the CISO will coordinate the development of disaster recovery policies and standards within the agency, ITSMs will need to guide the selection of appropriate strategies to achieve the direction set by the CISO.

3.3.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:410]

ITSMs SHOULD assist and guide the disaster recovery planning team in the selection of recovery strategies and the development, testing and maintenance of disaster recovery plans.

3.3.13. Responsibilities – Training

3.3.13.R.01.Rationale

The CISO will oversee the development and operation of information security awareness and training programs within the agency. ITSMs will arrange delivery of that training to personnel within the agency.

3.3.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:413]

ITSMs SHOULD provide or arrange for the provision of information security awareness and training for all agency personnel.

3.3.13.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:414]

ITSMs SHOULD develop technical information materials and workshops on information security trends, threats, good practices and control mechanisms as appropriate.

3.3.14. Responsibilities – Providing security knowledge

3.3.14.R.01.Rationale

ITSMs will often have a strong knowledge of information security topics and can provide advice for the information security steering committee, change management committee and other agency and inter-agency committees.

3.3.14.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:418]

ITSMs SHOULD maintain a current and up-to-date security knowledge base comprising of a technical reference library, security advisories and alerts, information on information security trends and practices, and relevant laws, regulations, standards and guidelines.

3.3.14.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:419]

ITSMs SHOULD provide expert guidance on security matters for ICT projects.

3.3.14.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:420]

ITSMs SHOULD provide technical advice for the information security steering committee, change management committee and other agency and inter-agency committees as required.

3.3.15. Responsibilities

3.3.15.R.01.Rationale

ITSMs are generally considered the information security experts within an agency and as such their contribution to improving the information security of systems, providing input to agency ICT projects, assisting other security personnel within the agency, contributing to information security training and responding to information security incidents is a core aspect of their work.

3.3.15.R.02.Rationale

An ITSM is likely to have the most up to date and accurate understanding of the threat environment relating to systems. As such, it is essential that this information is passed to system owners to ensure that it is considered during accreditation activities.

3.3.15.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:424]

The ITSM SHOULD keep the CISO and system owners informed with up-to-date information on current threats.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

3.4. System Owners

Objective

3.4.1.

System owners obtain and maintain accreditation of their systems, including any directly related services such as cloud.

Context

Scope

3.4.2.

This section covers the role that system owners undertake with respect to information security.

Assertions in Certification and Accreditation

3.4.3.

Originating in financial auditing, assertions are now widely used as the basis for assurance processes covering a wide range of business activities and the related technology.

3.4.4.

Assertions are formal statements by management or system owners. They are claims on the completeness, accuracy and validity of events, presentations, disclosure, transactions and related assurance, risk and governance aspects of certification and accreditation.

3.4.5.

It is the responsibility of the management (or system owner) to prepare and validate assertions relating to the governance, assurance and security of information systems, in accordance with national policy and related standards.

3.4.6.

When such assertions are made it means management (or system owners) have presented and disclosed information appropriately giving a true, fair and balanced view of the activities. In preparing assertions, implicit and explicit claims are made on the validity and completeness of the assertions.

3.4.7.

Assertions are typically characterised as follows:

Transactions and events

  • Occurrence — the activities recorded have actually taken place.
  • Completeness — all aspects are properly recorded.
  • Accuracy — the assets and activities are accurately allocated and recorded.
  • Cutoff — the activities have been recorded in the correct time period.
  • Classifications — are accurate and appropriate.

Position on project completion

  • Existence — assets, liabilities and equity balances exist.
  • Rights and Obligations — the entity legally controls rights to its assets and its liabilities and accurately records obligations.
  • Completeness — all aspects are properly recorded.
  • Valuation and Allocation — costs and assets appropriately valued and allocated.

Presentation and disclosure

  • Occurrence — the events and implementations have actually occurred.
  • Rights and Obligations — contracts, licences, support and supply agreements
  • Completeness — all disclosures have been included in the statements.
  • Classification — statements are clear and appropriately presented.
  • Accuracy and Valuation — information is disclosed at the appropriate amounts.

Rationale & Controls

3.4.8. Requirement for system owners

3.4.8.R.01.Rationale

The system owner is responsible for the overall operation of the system, including any directly related support or outsourced service such as cloud. They may delegate the day-to-day management and operation of the system to a system manager or managers.

3.4.8.R.02.Rationale

All systems should have a system owner in order to ensure IT governance processes are followed and that business requirements are met.

3.4.8.R.03.Rationale

It is strongly recommended that a system owner be a member of the Senior Executive Team or in an equivalent management position, however this does not imply that the system manager(s) should also be at such a level.

3.4.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:442]

Each system MUST have a system owner who is responsible for the operation and maintenance of the system.

3.4.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:443]

System owners SHOULD be a member of the Senior Executive Team or an equivalent management position, for large or critical agency systems.

3.4.9. Accreditation responsibilities

3.4.9.R.01.Rationale

The system owner is responsible for the operation of their system and as such they need to ensure that systems are accredited to meet the agency’s operational requirements. If modifications are undertaken to a system the system owner will need to ensure that the changes are undertaken in an appropriate manner, documented adequately and that any necessary reaccreditation activities are completed.

3.4.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:446]

System owners MUST obtain and maintain accreditation of their system(s).

3.4.10. Documentation responsibilities

3.4.10.R.01.Rationale

While the system owner is responsible for ensuring the development, maintenance and implementation of Systems Information Security documentation, in particular the Security Risk Management Plans (SRMPs), System Security Plans (SecPlans) and Standard Operating Procedures (SOPs), their exposure to information security issues can be too narrowly focused and restricted to the systems with which they are familiar. Involving security personnel in the process ensures that a holistic approach to information security can be mapped to the system owner’s understanding of security risks for their specific system. Refer to Chapter 5 - Information Security documentation and Chapter 4 - System Certification and Accreditation.

3.4.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:449]

System owners MUST ensure the development, maintenance and implementation of complete, accurate and up to date Information Security documentation for systems under their ownership. Such actions MUST be documented.

3.4.10.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:450]

System Owners MUST involve the ITSM in the redevelopment and updates of the Information Security documentation.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

3.5. System Users

Objective

3.5.1.

System users comply with information security policies and procedures within their agency.

Context

Scope

3.5.2.

This section covers the role that system users undertake with respect to information security.

Types of system users

3.5.3.

This section covers responsibilities for all system users i.e. users with general access (general users), and users with privileged access (privileged users).

Rationale & Controls

3.5.4. Responsibilities of system users

3.5.4.R.01.Rationale

If agencies fail to develop and maintain a security culture where system users are complying with relevant security policies and procedures for the systems they are using, there is an increased security risk of a system user unwittingly assisting with an attack against a system.

3.5.4.R.02.Rationale

Security policies, procedures and mechanisms aim to cover all situations that may arise within an agency. However there may be legitimate reasons for a system user to bypass security policies, procedures or mechanisms. If this is the case, the system user MUST seek formal authorisations from the CISO or the ITSM (if this authority has been specifically delegated to the ITSM) before any actions are undertaken.

3.5.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:466]

All system users MUST comply with the relevant security policies and procedures for the systems they use.

3.5.4.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:467]

All system users MUST:

  • protect account authenticators at the same classification of the system it secures;
  • not share authenticators for accounts without approval;
  • be responsible for all actions under their accounts; and
  • use their access to only perform authorised tasks and functions.
3.5.4.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:468]

System users that need to bypass security policies, procedures or mechanisms for any reason MUST seek formal authorisation from the CISO or the ITSM if this authority has been specifically delegated to the ITSM.

4. System Certification and Accreditation

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

4.1. The Certification and Accreditation Process

Objective

4.1.1.

Executives and Security Practitioners understand and enforce the use of the Certification and Accreditation (C&A) process and its role in information security governance and assurance.

Context

Scope

4.1.2.

This section provides a short, high-level description of the C&A process.

4.1.3.

This section must be read in conjunction with the Roles and Responsibilities described in Chapter 3. Subsequent sections of this chapter describe elements of the C&A process in more detail.

The Process

4.1.4.

Certification and Accreditation is a fundamental governance and assurance process, designed to provide the Board, Chief Executive and senior executives confidence that information and its associated technology are well-managed, that risks are properly identified and mitigated and that governance responsibilities can demonstrably be met. It is essential for credible and effective information assurance governance.

4.1.5.

C&A has two important stages where certification must be completed before accreditation can take place. It is based on an assessment of risk, the application of controls described in the NZISM and determination of any residual risk.

4.1.6.

Certification and Accreditation are separate and distinct elements, demonstrate segregation of duties and assist in managing any potential conflicts of interest. These are important attributes in good governance systems.

4.1.7.

The acceptance of residual risk lies with the Chief Executive of each agency, or lead agency where sector, multi-agency or All-of-Government (AoG) systems are implemented.

4.1.8.

An exception applies where high grade cryptographic equipment (HGCE) is required or caveated or compartmented information is processed, stored or communicated. In this case the Director-General, GCSB is the Accreditation Authority.

4.1.9.

The complete C&A process has several elements and stages, illustrated in the Block Diagram at the end of this section.

Key Participants

4.1.10.

There are four groups of participants:

  • System Owners, responsible for the design, development, system documentation and system maintenance, including any requests for recertification or reaccreditation.
  • The Certification Authority, responsible for the review of information and documentation provided by the system owner to ensure the ICT system complies with minimum standards and the agreed design.
  • The Assessor or Auditor, who will conduct inspections, audits and review as instructed by the Certification Authority.
  • The Accreditation Authority will consider the recommendation of the Certification Authority. If the level of residual risk is acceptable, the Accreditation Authority will issue the system accreditation (the formal authority to operate a system).

Certification

4.1.11.

Certification is the assertion that an ICT system including any related or support services such as Telecommunications or cloud comply with the minimum standards and controls described in the NZISM, any relevant legislation and regulation and other relevant standards. It is based on a comprehensive evaluation or systems audit. This process is described in Section 4.2 – Conducting Certifications.

4.1.12.

Certification is evidence that due consideration has been paid to risk, security, functionality, business requirements and is a fundamental part of information systems governance and assurance.

Certification Authorities

4.1.13.

For all agency information systems the certification authority is the CISO unless otherwise delegated by the Agency Head.

4.1.14.

For external organisations or service providers supporting agencies, the certification authority is the CISO of the agency.

4.1.15.

For multi-national, multi-agency, and AoG systems the certification authority is determined by a formal agreement between the parties involved. Within NZ this is usually the lead agency.

Accreditation

4.1.16.

Accreditation is the formal authority to operate a system, evidence that governance requirements have been addressed and that the Chief Executive has fulfilled the requirement to manage risk on behalf of the organisation and stakeholders. This element of the C&A process is described in Section 4.4 – Accreditation Framework.

4.1.17.

Accreditation ensures that either sufficient security measures have been put in place to protect information that is processed, stored or communicated by the system or that deficiencies in such measures have been identified, assessed and acknowledged, including the acceptance of any residual risk.

Accreditation Authority

4.1.18.

For agencies the Accreditation Authority is the agency head or their delegate.

4.1.19.

For multi-national, multi-agency systems or AoG systems, the Accreditation Authority is determined by a formal agreement between the parties involved.

4.1.20.

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.

4.1.21.

Depending on the circumstances and practices of an agency, the agency head could choose to delegate their authority to multiple senior executives who have the authority to accept security risks for the specific business functions within the agency, for example the CISO and the system owner.

Conflicts of Interest

4.1.22.

A conflict of interest is a situation in which a person has duties or responsibilities to more than one person, organisation or elements of a process, but is placed in a position where they cannot do justice to all. This includes, for example, when an individual's vested interests or concerns are inconsistent with organisational outcomes, or when an official has conflicting responsibilities. In the context of the C&A process, a conflict of interest can occur when an individual has multiple roles, such as being both the system owner and the Accreditation Authority.

4.1.23.

A conflict of interest has the potential to undermine impartiality and integrity of a process and the people involved in a process. It will also undermine the integrity of governance and information assurance derived from the C&A process.

4.1.24.

Conflicts of interest are normally managed though segregation of duties, the division of roles and responsibilities in order to reduce the ability or opportunity for an individual to compromise a critical process. Segregation of duties also reduces errors of interpretation or judgement and better manages risk.

4.1.25.

It is important to note that in the C&A process in the NZISM, the Certification Authority, System Owner and Accreditation Authority are independent of each other. In smaller agencies, the Assessor may also be the Certification Authority. Ideally this role will also be segregated.

Penetration Testing

4.1.26.

Penetration tests are an effective method of identifying vulnerabilities that in a system or network testing existing security measures and testing the implementation of controls. Penetration testing is also very useful in validating the effectiveness of the defensive mechanisms. This testing provides an increased level of assurance when system certification and accreditation is undertaken. It also demonstrates prudent risk management.

4.1.27.

A penetration test usually involves the use of intrusive methods or attacks conducted by trusted individuals, methods similar to those used by intruders or hackers. Care must be taken not to adversely affect normal operations while these tests are conducted.

4.1.28.

Organisations may conduct their own tests and regular simple tests are effective in maintaining the organisation’s security posture. Because of the level of expertise required to effectively conduct more complex testing, comprehensive penetration tests are often outsourced to specialist organisations.

4.1.29.

Penetration tests can range from simple scans of IP addresses in order to identify devices or systems offering services with known vulnerabilities, to exploiting known vulnerabilities that exist in an unpatched operating system, applications or other software. The results of these tests or attacks are recorded, analysed, documented and presented to the owner of the system. Any deficiencies should then be addressed.

System Certification and Accreditation Diagram

4.1.30.

System Certification and Accreditation Block Diagram

References

4.1.31.

Additional information relating to systems governance, certification and accreditation can be found at:

Title Publisher Source

ISO/IEC 27000:2014 Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary

ISO

http://www.standards.co.nz
http://www.iso.org

ISO/IEC 27001:2013 Information technology -- Security techniques -- Information security management systems -- Requirements

ISO http://www.standards.co.nz
http://www.iso.org

ISO/IEC 27002:2013 Information technology - Security techniques - Code of practice for information security controls

ISO http://www.standards.co.nz
http://www.iso.org

ISO/IEC_27006:2011 Information Technology – Security Techniques - Requirements for bodies providing audit and certification of information security management systems

ISO

http://www.iso27001security.com/html/27006.html
http://www.standards.co.nz

ISO/IEC_27007:2011 Information Technology – Security Techniques - Guidelines for information security management systems auditing

ISO

http://www.iso27001security.com/html/27007.html
http://www.standards.co.nz

NIST SP 800-37 Rev. 1, Feb 2010 Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach

NIST http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf  
NIST SP 800-171, June  2015 Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations NIST http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171.pdf  

Mitre Engineering Guide - Create and Assess Certification and Accreditation Strategies

MITRE

http://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/test-and-evaluation/

 RAND National Defense Research Institute - Implications of Aggregated DoD Information Systems for Information Assurance Certification and Accreditation  RAND Corporation http://www.rand.org/content/dam/rand/pubs/monographs/2010/RAND_MG951.pdf
 An Introduction to Certification and Accreditation  SANS Institute  https://www.sans.org/reading-room/whitepapers/accreditation/introduction-certification-accreditation-1259

A Certification and Accreditation Plan for Information Systems Security Programs (Evaluating the Eff)

 SANS Institute  https://www.sans.org/reading-room/whitepapers/accreditationcertification-accreditation-plan-information-systems-security-programs-evaluating-ef-597

Office of the Auditor-General - Managing conflicts of interest: Guidance for public entities

 Office of the Auditor-General  http://www.oag.govt.nz/2007/conflicts-public-entities/docs/oag-conflicts-public-entities.pdf

Managing Conflict of Interest in the Public Service - OECD GUIDELINES AND COUNTRY EXPERIENCES

 OECD  http://www.oecd.org/gov/ethics/48994419.pdf
Data Security Standard (DSS) Information Supplement, March 2008, PCI Security Standards Council, PCI Security Standards  https://www.pcisecuritystandards.org/documents/information_supplement_11.3.pdf

SANS Institute InfoSec Reading Room, Conducting a Penetration Test on an Organization,

 SANS Institute  http://www.sans.org/reading-room/whitepapers/auditing/conducting-penetration-test-organization-67

Commercially Available Penetration Testing Best Practice Guide, 8 May 2006, CPNI,

 CPNI  http://www.cpni.gov.uk/Documents/Publications/2006/2006030-GPG_Penetration_testing.pdf
Beyond Best Practices: Web Application Security in the Real World, OWASP, June 2004,  OWASP Link to App Sec 2004 Dave Aitel Beyond Best Practices
 International Standard on Assurance Engagements (ISAE) 3402 - Assurance Reports on Controls at a Service Organization  International Federation of Accountants (IFAC)  http://www.ifac.org/system/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf

 

 

PSR references

4.1.32.

Relevant PSR requirements can be found at:

Reference

Title

Source

PSR Mandatory Requirements

GOV2, GOV6, GOV7, GOV8INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4PHYSEC1 and PHYSEC2

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/

https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

PSR content protocols

Management protocol for information security

Management protocol for physical security

https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

PSR requirements sections

Take a risk based approach to information security

Applying Business impact levels

Reporting incidents and conducting security investigations

Self assessment and reporting

Validate your security measures

https://www.protectivesecurity.govt.nz/information-security/take-a-risk-based-approach-to-information-security/

https://www.protectivesecurity.govt.nz/governance/business-impact-levels/

https://www.protectivesecurity.govt.nz/governance/reporting-incidents-and-conducting-security-investigations/

https://www.protectivesecurity.govt.nz/self-assessment-and-reporting/

https://www.protectivesecurity.govt.nz/information-security/understand-the-information-security-lifecycle/validate-your-security-measures/

Managing specific scenarios

Physical Security for ICT systems

Secure your ICT facilities

Transacting online with the public

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/transacting-online-with-the-public/

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

4.2. Conducting Certifications

Objective

4.2.1.

The security posture of the organisation has been incorporated into its system security design, controls are correctly implemented, are performing as intended and that changes and modifications are reviewed for any security impact or implications.

Context

Scope

4.2.2.

This section covers information on the process of undertaking a certification as part of the accreditation process for a system.

Certification

4.2.3.

Certification is the assertion that a given ICT system complies with minimum standards and the agreed design. It is based on a comprehensive evaluation and may involve:

  • development and review of security documentation;
  • assurance over externally provided services such as Telecommunications and Cloud;
  • a physical inspection;
  • a technical review of the system and environment; and/or
  • technical testing.
4.2.4.

Certification is a prerequisite for accreditation. The Accreditation Authority for a specific system MUST NOT accredit that system until all relevant certifications have been provided.

Certification outcome

4.2.5.

The outcome of certification is a certificate to the system owner acknowledging that the system has been appropriately audited and that the findings have been found to be of an acceptable standard.

Certification authorities

4.2.6.

For all agency information systems the certification authority is the CISO unless otherwise delegated by the Agency Head.

4.2.7.

For external organisations or service providers supporting agencies, the certification authority is the CISO of the agency.

4.2.8.

For multi-national, multi-agency, and AoG systems the certification authority is determined by a formal agreement between the parties involved. Within NZ this is usually the lead agency.

References

4.2.9.

Additional information relating to system auditing is contained in:

 

Reference Title Source
ISO/IEC_27006:2011

Information Technology – Security Techniques - Requirements for bodies providing audit and certification of information security management systems.

http://www.iso27001security.com/html/27006.html

http://www.standards.co.nz

ISO/IEC_27007:2011

Information Technology – Security Techniques - Guidelines for information security management systems auditing.

http://www.iso27001security.com/html/27006.html

http://www.standards.co.nz

ISO 19011:2011

Guidelines for auditing management systems

https://www.iso.org/standard/50675.html

Rationale & Controls

4.2.10. Certification Audit

4.2.10.R.01.Rationale

The purpose of a Certification Audit is to assess the actual implementation and effectiveness of controls for a system against the agency’s risk profile, security posture, design specifications, agency policies and compliance with the Protective Security Requirements (PSR) and in particular the relevant NZISM components.

4.2.10.R.02.Rationale

The extent and scope of the Certification Audit should consider the feasibility and cost-effectiveness of the audit against the risks and benefits of the system under review. Major or high-risk systems will require more detailed and extensive review than low-risk or minor systems.  See also Section 4.3 Conducting Audits.

4.2.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:535]

All systems MUST undergo an audit as part of the certification process.

4.2.11. Certification decision

4.2.11.R.01.Rationale

To award certification for a system the certification authority will need to be satisfied that the selected controls are appropriate, are consistent with the Protective Security Requirements (PSR) and in particular the relevant NZISM components, have been properly implemented and are operating effectively.

4.2.11.R.02.Rationale

To cater for the different responsibilities for physical and technical Certification & Accreditation, separate reports and recommendations may be required.

4.2.11.R.03.Rationale

Certification acknowledges only that controls were appropriate, properly implemented and are operating effectively. Certification does NOT imply that the residual security risk is acceptable or an approval to operate has been granted.

4.2.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:540]

The certification authority MUST accept that the controls are appropriate, effective and comply with the Protective Security Requirements (PSR) and in particular the relevant NZISM components, in order to award certification.

4.2.12. Residual security risk assessment

4.2.12.R.01.Rationale

The purpose of the residual security risk assessment is to assess the risks, controls and residual security risk relating to the operation of a system. In situations where the system is non-conformant, the system owner may have taken corrective actions. The residual risk may not be great enough to preclude a certification authority recommending to the Accreditation Authority that accreditation be awarded but the risk MUST be acknowledged and appropriate qualifications or limitations documented.

4.2.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:543]

Following the audit, the certification authority SHOULD produce an assessment for the Accreditation Authority outlining the residual security risks relating to the operation of the system and a recommendation on whether to award accreditation or not.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

4.3. Conducting Audits

Objective

4.3.1.

The effectiveness of information security measures for systems is periodically reviewed and validated.

Context

Scope

4.3.2.

This section covers information on the process of undertaking a certification and accreditation audit.

Audit objectives, scope and criteria

4.3.3.

The aim of an audit is to review and assess:

  • the risk identification and assessment;
  • design and complexity (including the system and security architectures);
  • any available assurance reports on support or outsourced services;
  • controls selection;
  • actual implementation and effectiveness of controls for a system; and
  • supporting information security documentation.
4.3.4.

Only information that is verifiable should be accepted as audit evidence.  Audit evidence should be recorded.

Audit outcome

4.3.5.

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

4.3.6.

Part of this audit is an assessment of whether the control systems adequately identify and address risk and information security requirements.

Who can assist with an audit

4.3.7.

A number of other agencies and personnel within agencies are often consulted during an audit. Agencies or personnel that can be consulted on physical security aspects of information security may include:

  • The NZSIS for Physical Security;
  • GCSB for TOP SECRET sites and Sensitive Compartmented Information Facilities (SCIFs);
  • MFAT for systems located at overseas posts and missions;
  • The Chief Security Officer (CSO) may be consulted on personnel and physical security aspects of information security;
  • The CISO, ITSM or communications security officer may be consulted on COMSEC aspects of information security; and
  • The ITSM and System Owner on aspects of secure system design configuration and operation.

Independent audits

4.3.8.

An audit may be conducted by agency auditors or an independent security organisation.

Audit Evidence

4.3.9.

Audit evidence can be obtained from documentation described in Chapter 5 – Information Security Documentation. 

Other sources may include:

Source

Agency Strategies and Statements of Intent.

Any additional process documentation referenced in the documentation described in the NZISM Chapter 5.

Third party service provider agreements.

Independent risk assessments or security evaluations, such as penetration tests by an internal team or an external organization.

The agency risk identification and assessment   process.

Any internal audit reports, assessments and reviews.

Any statements of applicability.

Any relevant incident reports.

 

 

Audit evidence reliability

4.3.10.

The reliability of audit evidence is influenced by its source, nature and the circumstances under which the evidence is gathered.  In general terms documentary evidence is more reliable than oral evidence, self-generated evidence less reliable than evidence gathered elsewhere and externally generated evidence is more reliable than internally generated evidence as internally generated evidence may be more susceptible to selective presentation. 

4.3.11.

Confirmation should be obtained that:

  • Risk owners have been identified; and
  • Each risk owner has sufficient accountability and authority to manage their identified risks.
4.3.12.

Audit evidence can be gathered through the following methods in order of preference:

Method

Description

Inspection

Physical inspections can provide an independent confirmation of the physical condition of the site or systems, its implementation and its management.

Analytical review

Reviews of records and documents will provide evidence of varying degrees of reliability depending on their nature and source.  A review of the risk identification and selection of risk treatments is invaluable.

Enquiry

Here audit evidence is gathered by interview.  Enquiries can be formal or informal and oral or written.  It is essential that the auditor creates a written record of any enquiries conducted.

Observation

Observation of operations or procedures being performed by others with the aim of determining the manner of its performance only at that particular time.  This may include checks on system configurations, change management processes or other key elements.

Computations

Rarely used for non-financial records but may include, for example, asset registers and validation of holdings of accountable equipment and software.

Audit evidence sufficiency

4.3.13.

The Sufficiency is the measure of the quality (not the quantity) of audit evidence.  It is important, however, that a balance is struck between the extent of the audit, the nature of the system under review, agency risk and the cost, effort and benefit of the audit.  Sufficient evidence should be obtained to allow the auditor to be able to draw reasonable conclusions on which to base the audit opinion.  For evidence to be deemed sufficient, the following aspects should be considered:

  • Materiality.  Materiality is the threshold where any distorted, missing and incorrect information is likely to have an impact on the risk and security of a system.  Where it becomes clear that there are material deficiencies in the evidence presented more substantive tests may be required or the audit suspended until corrective action has been taken by the agency.
  • Risk assessment: It is almost impossible to validate every risk identification and selection of risk treatments.  For larger systems a more practical approach may be to validate the identification and treatment of major risks and use sampling techniques for the balance.
  • Economy: Before gathering or requesting additional audit evidence, it is important to consider whether or not it is feasible or cost-effective to generate this evidence against the benefits, assessed value and time required.

References

4.3.14.

Further references can be found at:

 Title  Publisher  Source

ISO 19011:2011 - Guidelines for auditing management systems

 ISO  https://www.iso.org

ISO/IEC 27000:2014 Information technology -- Security techniques -- Information security management systems -- Overview and vocabulary

 ISO

 http://www.standards.co.nz

 http://www.iso.org

ISO/IEC 27001:2013 Information technology -- Security techniques -- Information security management systems -- Requirements

 ISO  http://www.iso27001security.com/html/27006.html

 http://www.standards.co.nz

 http://www.iso.org
ISO/IEC 27002:2013 Information technology - Security techniques - Code of practice for information security controls  ISO

 http://www.standards.co.nz

 http://www.iso.org

ISO/IEC_27006:2011 Information Technology – Security Techniques- Requirements for bodies providing audit and certification of information security management systems  ISO  http://www.standards.co.nz

 http://www.iso.org

ISO/IEC_27007:2011 Information Technology – Security Techniques - Guidelines for information security management systems auditing  ISO  http://www.standards.co.nz

 http://www.iso.org

International Standard On Auditing (New Zealand) 500 - Audit Evidence  External Reporting Board, NZ Audit and Assurance
Standards Board
 https://www.xrb.govt.nz/standards-for-assurance-practitioners/auditing-standards/isa-nz-500/

PSR references

Rationale & Controls

4.3.16. Independence of auditors

4.3.16.R.01.Rationale

As there can be a perceived conflict of interest in the system owner assessing the security of their own system it is important that the auditor is demonstrably independent. This does not preclude an appropriately qualified system owner from assessing the security of a system that they are not responsible for.

4.3.16.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:562]

Agencies SHOULD ensure that auditors conducting audits are able to demonstrate independence and are not also the system owner or certification authority.

4.3.17. Audit preparation

4.3.17.R.01.Rationale

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

4.3.17.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:565]

Prior to undertaking the audit the system owner MUST approve the system architecture and associated information security documentation.

4.3.18. Audit (first stage)

4.3.18.R.01.Rationale

Auditing against the risk assessment and subsequent controls selection is preferable to a ‘checklist’ approach where all controls in the NZISM are checked for selection and implementation irrespective of applicability.

4.3.18.R.02.Rationale

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

4.3.18.R.03.Rationale

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

4.3.18.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:569]

The SecPol, SRMP, SecPlan, SOPs and IRP documentation MUST be reviewed by the auditor to ensure that it is comprehensive and appropriate for the environment the system is to operate within.

4.3.18.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:570]

The Information Security Policy (SecPol) MUST be reviewed by the auditor to ensure that all relevant controls specified in this manual are addressed.

4.3.18.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:571]

The system and security architecture (including information security documentation) SHOULD be reviewed by the auditor to ensure that it is based on sound information security principles and meets information security requirements, including the NZISM.

4.3.18.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:572]

The Information Security Policy (SecPol) SHOULD be reviewed by the auditor to ensure that policies have been developed or identified by the agency to protect classified information that is processed, stored or communicated by its systems.

4.3.18.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:573]

The system owner SHOULD provide a statement of applicability for the system which includes the following topics:

  • the baseline of this manual used for determining controls;
  • controls that are, and are not, applicable to the system;
  • controls that are applicable but are not being complied with; and
  • any additional controls implemented as a result of the SRMP.

4.3.19. Implementing controls

4.3.19.R.01.Rationale

System testing is most effective on working systems. Desk checks have limited effectiveness in these situations.

4.3.19.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:576]

Prior to undertaking any system testing in support of the certification process, the system owner MUST implement the controls for the system.

4.3.20. Audit (second stage)

4.3.20.R.01.Rationale

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

4.3.20.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:579]

The implementation of controls MUST be assessed to determine whether they have been implemented correctly and are operating effectively.

4.3.20.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:580]

The auditor MUST ensure that, where applicable, a physical security certification has been awarded by an appropriate physical security certification authority.

4.3.20.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:581]

The physical security certification SHOULD be less than three (3) years old at the time of the audit.

4.3.21. Report of compliance

4.3.21.R.01.Rationale

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

4.3.21.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:584]

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

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

4.4. Accreditation Framework

Objective

4.4.1.

Accreditation is the formal authority for a system to operate, and an important element in fundamental information system governance. Accreditation requires risk identification and assessment, selection and implementation of baseline and other appropriate controls and the recognition and acceptance of residual risks relating to the operation of a system including any outsourced services such as Telecommunications or Cloud. Accreditation relies on the completion of system certification procedures.

Context

Scope

4.4.2.

This section covers information on the accreditation framework for systems.

4.4.3.

All types of government held information are covered, including Official Information and information subject to privacy requirements.

Rationale & Controls

4.4.4. Accreditation framework

4.4.4.R.01.Rationale

The development of an accreditation framework within the agency will ensure that accreditation activities are conducted in a repeatable and consistent manner across the agency and that consistency across government systems is maintained. This requirement is a fundamental part of a robust governance model and provides a sound process to demonstrate good governance of information systems.

4.4.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:595]

Agencies MUST develop an accreditation framework for their agency.

4.4.5. Accreditation

4.4.5.R.01.Rationale

Accreditation ensures that either sufficient security measures have been put in place to protect information that is processed, stored or communicated by the system or that deficiencies in such measures have been identified, assessed and acknowledged by an appropriate authority. As such, when systems are awarded accreditation the Accreditation Authority accepts that the residual security risks relating to the system are appropriate for the information that it processes, stores or communicates.

4.4.5.R.02.Rationale

Once systems have been accredited, conducting on-going monitoring activities will assist in assessing changes to its environment and operation and to determine the implications for the security risk profile and accreditation status of the system.

4.4.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:599]

Agencies MUST ensure that each of their systems is awarded accreditation.

4.4.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:600]

Agencies MUST ensure that all systems are awarded accreditation before they are used operationally.

4.4.5.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:601]

Agencies MUST ensure that all systems are awarded accreditation prior to connecting them to any other internal or external system.

4.4.5.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:602]

Agencies SHOULD ensure information security monitoring, logging and auditing is conducted on all accredited systems.

4.4.6. Determining authorities

4.4.6.R.01.Rationale

Determining the certification and accreditation authorities for multi-national and multi-agency systems via a formal agreement between the parties will ensure that the system owner has identified appropriate points of contact and that risk is appropriately managed. See Section 4.5 – Conducting Accreditations.

4.4.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:605]

For multi-national and multi-agency systems, the Certification and Accreditation Authorities SHOULD be determined by a formal agreement between the parties involved.

4.4.7. Notifying authorities

4.4.7.R.01.Rationale

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

4.4.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:608]

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

4.4.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:609]

Agencies SHOULD confirm governance arrangements with the certification authorities, and with the accreditation authorities.

4.4.8. Due diligence

4.4.8.R.01.Rationale

When an agency is connecting a system to another party they need to be aware of the security measures the other party has implemented to protect their information. More importantly, the agency needs to know where the other party may have varied from controls in this manual. This is vital where different classification systems are applied, such as in the use of multiple national classification systems.

4.4.8.R.02.Rationale

Methods that an agency may use to ensure that other agencies and third parties comply with the agency’s information security expectations include:

  • assurance and confirmation that the certification and accreditation process described in the NZISM is adhered to;
  • conducting or utilising any third party reviewed assurance reports;
  • conducting an accreditation of the system being connected to; and/or
  • seeking a copy of existing accreditation deliverables in order to make their own accreditation determination.
4.4.8.R.03.Rationale

Ultimately, the agency MUST accept any security risks associated with connecting their system to the other party’s system. This includes the risks of other party’s system potentially being used as a platform to attack their system or “spilling” information requiring subsequent clean up processes.

4.4.8.R.04.Rationale

Special care MUST be taken for multi- national, multi-agency and All-of-Government systems.

4.4.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:615]

Where an agency’s system exchanges information with a third-party system, the agency MUST ensure that the receiving party has appropriate measures in place to provide a level of protection commensurate with the classification or privacy requirements of their information and that the third party is authorised to receive that information.

4.4.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:616]

An agency MUST ensure that a third party is aware of the agency’s information security expectations and national security requirements by defining expectations in documentation that includes, but is not limited to:

  • contract provisions; 
  • a memorandum of understanding;
  • non-disclosure agreements.
4.4.8.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:617]

An agency MUST ensure that a third party complies with the agency’s information security expectations through a formal process providing assurance to agency management that the operation of information security within the third party meets, and continues to meet, these expectations.

4.4.8.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:618]

Agencies SHOULD review accreditation deliverables when determining whether the receiving party has appropriate measures in place to provide a level of protection commensurate with the classification of their information.

4.4.9. Processing restrictions

4.4.9.R.01.Rationale

When security is applied to systems, protective measures are put in place based on the highest classification that will be processed, stored or communicated by the system. As such, any classified information placed on the system above the level for which it has been accredited will receive an inappropriate level of protection and could be exposed to a greater risk of compromise.

4.4.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:621]

Agencies MUST NOT allow a system to process, store or communicate classified information above the classification for which the system has received accreditation.

4.4.10. Accrediting systems bearing a compartment marking

4.4.10.R.01.Rationale

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

4.4.10.R.02.Rationale

Compartments are invariably established for the additional protection of information of National security significance, over and above the protection provided by the primary classification.  It is extremely unlikely that such compartments would be established at a classification below CONFIDENTIAL.

4.4.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:624]

A system that processes, stores or communicates compartmented information MUST be accredited by the GCSB.

4.4.11. Requirement for New Zealand control

4.4.11.R.01.Rationale

NZEO systems process, store and communicate information that is particularly sensitive to the government of New Zealand. When agencies are dealing with New Zealand Eyes Only (NZEO) information they need to be aware of the requirement for a New Zealand national to remain in control of the system and information at all times. It is, therefore, essential that control of such systems is maintained by New Zealand citizens working for the government of New Zealand.

4.4.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:627]

Agencies MUST ensure that systems processing, storing or communicating NZEO information remain under the control of a New Zealand national working for the New Zealand government, at all times.

4.4.12. Reaccreditation

4.4.12.R.01.Rationale

Agencies should reaccredit their systems at least every two years; however, they can exercise an additional one year’s grace if they follow the procedures in this manual for non-compliance with a ‘SHOULD’ requirement, namely conducting a comprehensive security risk assessment, obtaining sign-off by senior management and formal acceptance of residual risk.

4.4.12.R.02.Rationale

Accreditations should be commenced at least six months before due date to allow sufficient time for the certification and accreditations processes to be completed. Once three years has elapsed between accreditations, the authority to operate the system (the accreditation) will lapse and the agency will need to either reaccredit the system or request a dispensation to operate without accreditation. It should be noted that operating a system without accreditation is considered extremely risky. This will be exacerbated when multiple agency or All-of-Government systems are involved.

4.4.12.R.03.Rationale

Additional reasons for conducting reaccreditation activities could include:

  • changes in the agency’s information security policies or security posture;
  • detection of new or emerging threats to agency systems;
  • the discovery that controls are not operating as effectively as planned; 
  • a major information security incident; and
  • a significant change to systems, configuration or concept of operation for the accredited system.
4.4.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:632]

Agencies MUST ensure that the period between accreditations of each of their systems does not exceed three years.

4.4.12.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:633]

Agencies MUST notify associated agencies where multiple agencies are connected to agency systems operating with expired accreditations.

4.4.12.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:634]

Agencies MUST notify the Government CIO where All-of-Government systems are connected to agency systems operating with expired accreditations.

4.4.12.C.04.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:635]

Agencies MUST NOT operate a system without accreditation or with a lapsed accreditation unless the accreditation authority has granted a dispensation.

4.4.12.C.05.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:636]

Agencies SHOULD ensure that the period between accreditations of each of their systems does not exceed two years.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

4.5. Conducting Accreditations

Objective

4.5.1.

As a governance good practice, systems are accredited before they are used operationally.

Context

Scope

4.5.2.

This section covers information accreditation processes.

Accreditation aim

4.5.3.

The aim of accreditation is to give formal recognition and acceptance of the residual security risk to a system and the information it processes, stores or communicates as part of the agency’s governance arrangements.

Accreditation outcome

4.5.4.

The outcome of accreditation is an approval to operate issued by the Accreditation Authority to the system owner.

Accreditation Authorities

4.5.5.

For agencies the Accreditation Authority is the agency head or their formally authorised delegate.

4.5.6.

For organisations supporting agencies the Accreditation Authority is the head of the supported agency or their authorised delegate.

4.5.7.

For multi-national and multi-agency systems the Accreditation Authority is determined by a formal agreement between the parties involved.

4.5.8.

For agencies with systems that process, store or communicate endorsed or compartmented information, or the use of High Grade Cryptographic Equipment (HGCE), the Director-General GCSB is the Accreditation Authority.

4.5.9.

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.

4.5.10.

Depending on the circumstances and practices of an agency, the agency head could choose to delegate their authority to multiple senior executives who have the authority to accept security risks for the specific business functions within the agency, for example the CISO and the system owner.

4.5.11.

More information on the delegation of the agency head’s authority can be found in Section 3.1 - Agency Head.

Accreditation outcomes

4.5.12.

Accreditation is awarded when the systems comply with the NZISM, the Accreditation Authority understands and accepts the residual security risk relating to the operation of the system and the Accreditation Authority gives formal approval for the system to operate.

4.5.13.

In some cases the Accreditation Authority may not accept the residual security risk relating to the operation of the system. This outcome is predominately caused by security risks being insufficiently considered and documented within the SRMP resulting in an inaccurate scoping of security measures within the SecPlan. In such cases the Accreditation Authority may request that the SRMP and SecPlan be amended and security measures reassessed before accreditation is awarded.

4.5.14.

In awarding accreditation for a system the Accreditation Authority may choose to define a reduced timeframe before reaccreditation, less than that specified in this manual, or place restrictions on the use of the system which are enforced until reaccreditation or until changes are made to the system within a specified timeframe.

Exception for undertaking certification

4.5.15.

In exceptional circumstances the Accreditation Authority may elect not to have a certification conducted on a system before making an accreditation decision. The test to be satisfied in such circumstances is that if the system is not operated immediately it would have a devastating and potentially long lasting effect on the operations of the agency. This exception MUST be formally recorded and accepted.

4.5.16.

Certification MUST occur as soon as possible as this is an essential part of the governance and assurance mechanism.

Rationale & Controls

4.5.17. Certification

4.5.17.R.01.Rationale

Certification is an essential component of the governance and assurance process and assists and supports risk management.

4.5.17.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:666]

All systems MUST be certified as part of the accreditation process.

4.5.18. Accreditation decision

4.5.18.R.01.Rationale

In order to determine the agency’s security posture, a system accreditation:

  • examines the risks to systems identified in the certification process;
  • reviews the controls applied to manage those risks; and then
  • determines the acceptability of any residual risk.
4.5.18.R.02.Rationale

The accreditation process should also examine compliance with national policy, relevant international standards and good practice so that residual risk is managed prudently and pragmatically.

4.5.18.R.03.Rationale

It is especially important that All-of-Government systems and effects on systems of other agencies are also considered in the examination of risk and determination of residual risk.

4.5.18.R.04.Rationale

To assist in making an accreditation decision the Accreditation Authority may choose to review:

  • Information Security Documentation as described in Chapter 5;
  • any interaction with systems of other agencies or All-of-Government systems;
  • compliance audit reports;
  • the accreditation recommendation from the certification authority;
  • supporting documentation for any decisions to be non-compliant with any controls specified in this manual; 
  • any additional security risk reduction strategies that have been implemented; and
  • any third party reviews or assurance reports available.
4.5.18.R.05.Rationale

The Accreditation Authority may also choose to seek the assistance of one or more technical experts in understanding the technical components of information presented to them during the accreditation process to assist in making an informed accreditation decision.

4.5.18.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:673]

The Accreditation Authority MUST accept the residual security risk relating to the operation of a system in order to award accreditation.

4.5.18.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:674]

The Accreditation Authority MUST advise other agencies where the accreditation decision may affect those agencies.

4.5.18.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:675]

The Accreditation Authority MUST advise the GCIO where the accreditation decision may affect any All-of-Government systems.

5. Information security documentation

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.1. Documentation Fundamentals

Objective

5.1.1.

Information security documentation is produced for systems, to support and demonstrate good governance.

Context

Scope

5.1.2.

This section is an overview of the information security documentation that each agency will need to develop. More specific information on each document can be found in subsequent sections of this chapter.

5.1.3.

While this section describes a number of different but essential documents, it may be more advantageous and efficient to provide agency wide documentation for some elements (for example Physical Security) which can then be re-used for all agency systems.

5.1.4.

Similarly some consolidation may be appropriate, for example, SOPs IRPs and EPs can easily be combined into a single document.

Note: For smaller agencies and smaller systems it is acceptable that all documentation elements are combined into a single document provided each documentation element is clearly identifiable.

Note: Agencies may choose to name the documentation in different terms. This is acceptable provided the required level of detail is captured.  Naming conventions presented in the NZISM are not mandatory.

Information Security Documentation

5.1.5.

Information Security Documentation requirements are summarised in the table below.

Title Abbreviation Reference

Information Security Policy

SecPol 5.1.6
Systems Architecture - 5.1.7

Security Risk Management Plan

SRMP

5.1.8

System Security Plan

SecPlan 5.1.9
Site Security Plan SitePlan 8.2.7
Standard Operating Procedures

SOPs

5.1.10

Incident Response Plan

IRP

5.1.11

Emergency Procedures

EP

5.1.12

Independent Assurance reports for externally provided services

-

5.8

PSR references

5.1.6.

 Relevant PSR requirements can be found at:

Reference

Title

Source

PSR Mandatory Requirements

GOV2, GOV6, GOV7, INFOSEC1, INFOSEC2, INFOSEC4, and PHYSEC1

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/

https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

PSR content protocols 

Management protocol for information security

Management protocol for physical security

https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

PSR requirements sections

Take a risk based approach to information security

Applying Business impact levels

Reporting incidents and conducting security investigations

Self assessment and reporting

NZ Government security classification system

https://www.protectivesecurity.govt.nz/information-security/take-a-risk-based-approach-to-information-security/

https://www.protectivesecurity.govt.nz/governance/business-impact-levels/

https://www.protectivesecurity.govt.nz/governance/reporting-incidents-and-conducting-security-investigations/

https://www.protectivesecurity.govt.nz/self-assessment-and-reporting/

https://www.protectivesecurity.govt.nz/information-security/security-classification-system-and-handling-requirements/new-zealand-government-security-classification-system/

Managing specific scenarios

Physical Security for ICT systems

Secure your ICT facilities

Transacting online with the public

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/transacting-online-with-the-public/

Rationale & Controls

5.1.7. Information Security Policy (SecPol)

5.1.7.R.01.Rationale

The SecPol is an essential part of information security documentation as it outlines the high-level policy objectives. The SecPol can form part of the overall agency security policy.

5.1.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:692]

Agencies MUST have a SecPol for their agency. The SecPol is usually sponsored by the Chief Executive and managed by the CISO or Chief Information Officer (CIO). The ITSM should be the custodian of the SecPol. The SecPol should include an acceptable use policy for any agency technology equipment, systems, resources and data.

5.1.8. Systems Architecture

5.1.8.R.01.Rationale

The systems architecture illustrates the design of the system (including any outsourced services), consistency with the SecPol and provides the basis for the Security Risk Management Plan (SRMP).

5.1.8.R.02.Rationale

In this context Systems Architecture includes Security Architecture.

5.1.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:696]

All systems MUST have a documented Systems Architecture.

5.1.9. Security Risk Management Plan (SRMP)

5.1.9.R.01.Rationale

The SRMP is considered to be a good practice approach to identifying and reducing identified security risks. Depending on the documentation framework chosen, multiple systems can refer to, or build upon, a single SRMP.

5.1.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:699]

Agencies MUST ensure that every system is covered by a Security Risk Management Plan, which includes identification of risk owners.

5.1.10. System Security Plan (SecPlan)

5.1.10.R.01.Rationale

The SecPlan describes the implementation and operation of controls within the system derived from the NZISM and the SRMP. Depending on the documentation framework chosen, some details common to multiple systems can be consolidated in a higher level SecPlan.

5.1.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:702]

Agencies MUST ensure that every system is covered by a SecPlan.

5.1.11. Standard Operating Procedures (SOPs)

5.1.11.R.01.Rationale

SOPs provide step-by-step guides to undertaking information security related tasks and processes. They provide assurance that tasks can be undertaken in a secure and repeatable manner, even by system users without strong technical knowledge of the system’s mechanics. Depending on the documentation framework chosen, some procedures common to multiple systems could be consolidated into a higher level SOP.

5.1.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:705]

Agencies MUST ensure that Standard Operating Procedures (SOPs) are developed for systems.

5.1.12. Incident Response Plan (IRP)

5.1.12.R.01.Rationale

The purpose of developing an IRP is to ensure that information security incidents are appropriately managed. In most situations the aim of the response will be to contain the incident and prevent the information security incident from escalating. The preservation of any evidence relating to the information security incident for criminal, forensic and process improvement purposes is also an important consideration.

5.1.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:708]

Agencies MUST develop an Incident Response Plan and supporting procedures.

5.1.12.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:709]

Agency personnel MUST be trained in and periodically exercise the Incident Response Plan.

5.1.13. Emergency Procedures (EP)

5.1.13.R.01.Rationale

Classified information and systems are secured if a building emergency or evacuation is required.

5.1.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:712]

Agencies SHOULD document procedures relating to securing classified information and systems when required to evacuate a facility in the event of an emergency.

5.1.14. Developing content

5.1.14.R.01.Rationale

Ensuring personnel developing information security documentation are sufficiently knowledgeable of information security issues and business requirements will assist in achieving the most useful and accurate set of documentation.

5.1.14.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:715]

Agencies SHOULD ensure that information security documentation is developed by personnel with a good understanding of policy requirements, the subject matter, essential processes and the agency’s business and operations

5.1.15. Documentation content

5.1.15.R.01.Rationale

As the SRMP, Systems Architecture, SecPlan, SOPs and IRP are developed as a documentation suite for a system it is essential that they are logically connected and consistent within themselves and with other agency systems. Furthermore, each documentation suite developed for a system will need to be consistent with the agency’s overarching SecPol.

5.1.15.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:718]

Agencies SHOULD ensure that their SRMP, Systems Architecture, SecPlan, SOPs and IRP are logically connected and consistent for each system, other agency systems and with the agency’s SecPol.

5.1.16. Documentation framework

5.1.16.R.01.Rationale

The implementation of an overarching information security document framework ensures that all documentation is accounted for, complete and maintained appropriately. Furthermore, it can be used to describe linkages between documents, especially when higher level documents are used to avoid repetition of information in lower level documents.

5.1.16.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:721]

Agencies SHOULD create and maintain an overarching document describing the agency’s documentation framework, including a complete listing of all information security documentation that shows a document hierarchy and defines how each document is related to the other.

5.1.16.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:722]

Where an agency lacks an existing, well-defined documentation framework, they SHOULD use the document names defined in this manual.

5.1.17. Documentation Consistency

5.1.17.R.01.Rationale

Consistency in approach, terminology and documentation simplifies the use and interpretation of documentation for different systems and agencies.

5.1.17.R.02.Rationale

Factors which should be taken into account when determining the classification of systems documentation include:

  • Highest classification of information stored, processed or communicated over that system;
  • Sensitivity including existence of the facility;
  • Inclusion of vulnerability information, security mechanisms or special processing capability in the systems documentation;
  • Potential data aggregation;
  • Risk and threat levels; and
  • Scope and use of the system.
5.1.17.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:726]

Where an agency uses alternative documentation names to those defined within this manual for their information security documentation they SHOULD convert the documentation names to those used in this manual.

5.1.18. Documentation Classification

5.1.18.R.01.Rationale

Systems documentation will usually reflect the importance or sensitivity of particular systems.

5.1.18.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:729]

Agencies MUST ensure that their SecPol, SRMP, SecPlan, SOPs and IRP are appropriately classified.

5.1.19. Outsourcing development of content

5.1.19.R.01.Rationale

Agencies outsourcing the development of information security documentation need to be aware of the contents of the documentation produced. As such, they will still need to review and control the documentation contents to make sure it is appropriate and meets their requirements.

5.1.19.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:732]

When information security documentation development is outsourced, agencies SHOULD:

  • review the documents for suitability;
  • retain control over the content; and
  • ensure that all policy requirements are met.

5.1.20. Obtaining formal sign-off

5.1.20.R.01.Rationale

Without appropriate sign-off of information security documentation within an agency, the security personnel will have a reduced ability to ensure appropriate security procedures are selected and implemented. Having sign-off at an appropriate level assists in reducing this security risk as well as ensuring that senior management is aware of information security issues and security risks to the agency’s business.

5.1.20.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:735]

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

5.1.20.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:736]

Agencies SHOULD ensure that:

  • all high-level information security documentation is approved by the CISO and the agency head or their delegate; and
  • all system-specific documents are reviewed by the ITSM and approved by the system owner.

5.1.21. Documentation Maintenance

5.1.21.R.01.Rationale

The threat environment and agencies’ businesses are dynamic. If an agency fails to keep their information security documentation up to date to reflect the changing environment, they do not have a means of ascertaining that their security measures and processes continue to be effective.

5.1.21.R.02.Rationale

Changes to risk and technology may dictate a reprioritisation of resources in order to maximise the effectiveness of security measures and processes.

5.1.21.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:767]

Agencies SHOULD develop a regular schedule for reviewing all information security documentation.

5.1.21.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:768]

Agencies SHOULD ensure that information security documentation is reviewed:

  • at least annually; or
  • in response to significant changes in the environment, business or system; and
  • with the date of the most recent review being recorded on each document.
img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.2. Information Security Policies

Objective

5.2.1.

Information security policies (SecPol) set the strategic direction for information security.

Context

Scope

5.2.2.

This section relates to the development of Information Security Policies and any supporting plans. Information relating to other mandatory documentation can be found in Section 5.1 - Documentation Fundamentals.

Rationale & Controls

5.2.3. The Information Security Policy (SecPol)

5.2.3.R.01.Rationale

To provide consistency in approach and documentation, agencies should consider the following when developing their SecPol:

  • policy objectives;
  • how the policy objectives will be achieved;
  • the guidelines and legal framework under which the policy will operate;
  • stakeholders;
  • education and training;
  • what resourcing will be available to support the implementation of the policy; 
  • what performance measures will be established to ensure that the policy is being implemented effectively; and
  • a review cycle.
5.2.3.R.02.Rationale

In developing the contents of the SecPol, agencies may also consult any agency-specific directives that are applicable to information security within their agency.

5.2.3.R.03.Rationale

Agencies should also avoid outlining controls for systems within their SecPol. The controls for a system will be determined by this manual and based on the scope of the system, along with any additional controls as determined by the SRMP, and documented within the SecPlan.

5.2.3.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:780]

The Information Security Policy (SecPol) SHOULD document the information security, guidelines, standards and responsibilities of an agency.

5.2.3.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:781]

The Information Security Policy (SecPol) SHOULD include topics such as:

  • accreditation processes;
  • personnel responsibilities;
  • configuration control;
  • access control;
  • networking and connections with other systems;
  • physical security and media control;
  • emergency procedures and information security incident management;
  • change management; and
  • information security awareness and training.
img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.3. Security Risk Management Plans

Objective

5.3.1.

Security Risk Management Plans (SRMP) identify security risks and appropriate treatment measures for systems.

Context

Scope

5.3.2.

This section relates to the development of SRMPs, focusing on risks associated with the security of systems. Information relating to other mandatory documentation can be found in Section 5.1 - Documentation Fundamentals.

5.3.3.

SRMPs may be developed on a functional basis, systems basis or project basis. For example, where physical elements will apply to all systems is use within that agency, a single SRMP covering all physical elements is acceptable. Generally each system will require a separate SRMP.

5.3.4.

The agency’s risk identification and assessment process should include:

  • How risks are found, recognised and described; and
  • How sources of possible risks are to be considered.

References

5.3.5.

Information on the development of SRMPs can be found in:

Title Publisher Source
ISO 27005:2011, Information Security Risk Management  Standards New Zealand http://www.standards.co.nz
HB 436:2013, Risk Management Guidelines

Standards New Zealand

http://www.standards.co.nz
ISO 22301:2012, Business Continuity Standards New Zealand http://www.standards.co.nz
ISO 31000:2018, Risk Management - Guidelines

Standards New Zealand

ISO

http://www.standards.co.nz

http://www.iso.org

ISO 31010:2009, Risk Management – Risk Assessment Techniques

Standards New Zealand

ISO

http://www.standards.co.nz

http://www.iso.org

ISO Guide 73:2009, Risk Management  - Vocabulary

Standards New Zealand

ISO

http://www.standards.co.nz

http://www.iso.org

ISO 19011:2011 - Guidelines for auditing management systems ISO http://www.iso.org
ISO/IEC 27000:2014 Information technology - Security techniques - Information security management systems - Overview and vocabulary ISO

http://www.iso.org

http://www.standards.co.nz 

ISO/IEC 27001:2013 Information technology - Security techniques - Information security management systems - Requirements ISO

http://www.iso.org

http://www.standards.co.nz

http://www.iso27001security.com/html/27006.html

ISO/IEC_27006:2011 Information technology - Security techniques - Requirements for boies providing audit and certification of information security management systems ISO

http://www.iso.org

http://www.standards.co.nz

ISO/IEC_27007:2011 Information technology - Security techniques - Guidelines for information security management systems auditing ISO

http://www.iso.org

http://www.standards.co.nz

ISO/IEC TR 27008, Guidelines for auditors on information security controls ISO http://www.iso.org
ISO/IEC 27017, Code of practice for information security ISO http://www.iso.org
ISO/IEC 27018:2014 Information technology - Security techniques - Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors ISO http://www.iso.org

Rationale & Controls

5.3.6. Agency and system specific security risks

5.3.6.R.01.Rationale

While a baseline of security risks with associated levels of security risk and corresponding risk treatments are provided in this manual, agencies will almost certainly have variations to those considered during the security risk assessment. Such variations could be in the form of differing risk sources and threats, assets and vulnerabilities, or exposure and severity. In such cases an agency will need to follow its own risk management procedures to determine its risk appetite and associated risk acceptance, risk avoidance and risk tolerance thresholds. Risk owners must be identified.

5.3.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:802]

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

5.3.7. Contents of SRMPs

5.3.7.R.01.Rationale

Risks within an agency can be managed if they are not known, and if they are known, failing to treat or accept them is also a failure of risk management. For this reason SRMPs consist of two components, a security risk assessment and a corresponding treatment strategy.

5.3.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:805]

The Security Risk Management Plan SHOULD contain a security risk assessment and a corresponding treatment strategy.

5.3.8. Agency risk management

5.3.8.R.01.Rationale

If an agency fails to incorporate SRMPs 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.

5.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:808]

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

5.3.9. Risk Management standards

5.3.9.R.01.Rationale

For security risk management to be of true value to an agency there must be direct relevance to the specific circumstances of an agency and its systems, as well as being based on an industry recognised approach or risk management guidelines. For example, guidelines and standards produced by Standards New Zealand and the International Organization for Standardization.

The Protective Security Requirements requires that agencies adopt risk management approaches in accordance with ISO 31000:2018. Refer to PSR governance requirement GOV2.

5.3.9.R.02.Rationale

The International Organization for Standardization has developed an international risk management standard, including principles and guidelines on implementation, outlined in ISO 31000:2018, Risk Management – Guidlines. The terms and definitions for this standard can be found in ISO/IEC Guide 73, Risk Management – Vocabulary – Guidelines. The ISO/IEC 2700x series of standards also provides guidance.

5.3.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:812]

Agencies SHOULD develop their SRMP in accordance with international standards for risk management.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.4. System Security Plans

Objective

5.4.1.

System Security Plans (SecPlan) specify the information security measures for systems.

Context

Scope

5.4.2.

This section relates to the development of SecPlans. Information relating to other mandatory documentation can be found in Section 5.1 - Documentation Fundamentals.

5.4.3.

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

Stakeholders

5.4.4.

There can be many stakeholders involved in defining a SecPlan, including representatives from the:

  • project, who MUST deliver the capability (including contractors);
  • owners of the information to be handled;
  • system users for whom the capability is being developed;
  • management audit authority;
  • CISO, ITSM and system owners;
  • system certifiers and accreditors;
  • information management planning areas; and
  • infrastructure management.

Rationale & Controls

5.4.5. Contents of SecPlans

5.4.5.R.01.Rationale

The NZISM 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 will need to determine which controls are in scope of the system and translate those controls to the SecPlan. These controls will then be assessed on their implementation and effectiveness during an information security assessment as part of the accreditation process.

5.4.5.R.02.Rationale

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

5.4.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:828]

Agencies MUST select controls from this manual to be included in the SecPlan based on the scope of the system with additional system specific controls being included as a result of the associated SRMP. Encryption Key Management requires specific consideration; refer to Chapter 17 – Cryptography.

5.4.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:829]

Agencies SHOULD use the latest baseline of this manual when developing, and updating, their SecPlans as part of the certification, accreditation and reaccreditation of their systems.

5.4.5.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:831]

Agencies SHOULD include a Key Management Plan in the SecPlan.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.5. Standard Operating Procedures

Objective

5.5.1.

Standard Operating Procedures (SOPs) ensure security procedures are followed in an appropriate and repeatable manner.

Context

Scope

5.5.2.

This section relates to the development of security related SOPs. Information relating to other mandatory documentation can be found in Section 5.1 - Documentation Fundamentals.

Rationale & Controls

5.5.3. Development of SOPs

5.5.3.R.01.Rationale

In order to ensure that personnel undertake their duties in an appropriate manner, with a minimum of confusion, it is important that the roles of ITSMs, system administrators and system users are covered by SOPs. Furthermore, taking steps to ensure that SOPs are consistent with SecPlans will reduce the potential for confusion resulting from conflicts in policy and procedures.

5.5.3.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:844]

Agencies SHOULD develop SOPs for each of the following roles:

  • ITSM;
  • system administrator; and
  • system user.

5.5.4. ITSM SOPs

5.5.4.R.01.Rationale

The ITSM SOPs are intended to cover the management and leadership of information security functions within the agency.

5.5.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:849]

The following procedures SHOULD be documented in the ITSMs 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.
Information security incidents Detecting, reporting and managing potential information security incidents.
  Establishing the cause of any information security incident, whether accidental or deliberate.
  Actions to be taken to recover and minimise the exposure from an information security incident.
  Additional actions to prevent reoccurrence.
Data transfers Managing the review of media containing classified information that is to be transferred off-site.
  Managing the review of incoming media for malware or unapproved software.
IT equipment Managing the disposal & destruction of unserviceable IT equipment and media.
System Patching Advising and recommending system patches, updates and version changes based on security notices and related advisories.
System integrity audit Reviewing system user accounts, system parameters and access controls to ensure that the system is secure.
  Checking the integrity of system software.
  Testing access controls.
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 system users.

5.5.5. System Administrator SOPs

5.5.5.R.01.Rationale

The system administrator SOPs focus on the administrative activities related to system operations.

5.5.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:865]

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 system users.
  Setting system user privileges.
  Cleaning up directories and files when a system user departs or changes roles.
Incident response Detecting, reporting and managing potential information security incidents.
  Establishing the cause of any information security incident, whether accidental or deliberate.
  Actions to be taken to recover and minimise the exposure from information security incident.
  Additional actions to prevent reoccurrence.

5.5.6. System User SOPs

5.5.6.R.01.Rationale

The system user SOPs focus on day to day activities that system users need to be made aware of, and comply with, when using systems.

5.5.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:884]

The following procedures SHOULD be documented in the system user’s SOPs.

Topic

Procedures to be included

Acceptable Use  Acceptable uses of the system(s).
End of day How to secure systems at the end of the day.

Information security incidents

What to do in the case of a suspected or actual information security incident.
Media control Procedures for handling and using media.
Passwords

Choosing and protecting passwords.

Temporary absence How to secure systems when temporarily absent.

5.5.7. Agreement to abide by SOPs

5.5.7.R.01.Rationale

When SOPs are produced the intended audience should be made aware of their existence and acknowledge that they have read, understood and agree to abide by their contents.

5.5.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:889]

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

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.6. Incident Response Plans

Objective

5.6.1.

Incident Response Plans (IRP) outline actions to take in response to an information security incident.

Context

Scope

5.6.2.

This section relates to the development of IRPs to address information security, and not physical incidents within agencies. Information relating to other mandatory documentation can be found in Section 5.1 - Documentation Fundamentals.

Rationale & Controls

5.6.3. Contents of IRPs

5.6.3.R.01.Rationale

The guidance provided on the content of IRPs will ensure that agencies have a baseline to develop an IRP with sufficient flexibility, scope and level of detail to address the majority of information security incidents that could arise.

5.6.3.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:902]

Agencies MUST include, as a minimum, the following content within their IRP:

  • broad guidelines on what constitutes an information security incident;
  • the minimum level of information security incident response and investigation training for system users and system administrators;
  • the authority responsible for initiating investigations of an information security incident;
  • the steps necessary to ensure the integrity of evidence supporting an information security incident;
  • the steps necessary to ensure that critical systems remain operational; 
  • when and how to formally report information security incidents; and
  • national policy requirements for incident reporting (see Chapter 7 – Information Security Incidents).
5.6.3.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:904]

Agencies SHOULD include the following content within their IRP:

  • clear definitions of the types of information security incidents that are likely to be encountered;
  • the expected response to each information security incident type;
  • the authority within the agency that is responsible for responding to information security incidents;
  • the criteria by which the responsible authority would initiate or request formal, police investigations of an information security incident;
  • which other agencies or authorities need to be informed in the event of an investigation being undertaken; and
  • the details of the system contingency measures or a reference to these details if they are located in a separate document.
img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.7. Emergency Procedures

Objective

5.7.1.

Classified information and systems are secured before personnel evacuate a facility in the event of an emergency.

Context

Scope

5.7.2.

This section covers information relating to the securing of classified information and systems as part of the procedures for evacuating a facility in the event of an emergency.

5.7.3.

The safety of personnel is of paramount importance.

Rationale & Controls

5.7.4. Evacuating facilities

5.7.4.R.01.Rationale

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

5.7.4.R.02.Rationale

During an evacuation, the safety of staff is of primary importance.  Where it is immediately obvious to wardens and/or staff that the securing of classified information and systems prior to the evacuation of a facility would lead to, or exacerbate, serious injury or loss of life to personnel, the facility may be evacuated without personnel following the necessary procedures to secure classified information and systems.

5.7.4.R.03.Rationale

Where facilities are evacuated and classified information and systems have NOT been secured, the Chief Warden or Floor Warden MUST be notified as soon as possible.  Steps should be taken to secure the site as soon as it is safe to do so.

5.7.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:922]

Agencies MUST include in procedures for personnel evacuating a facility the requirement to secure classified information and systems prior to the evacuation.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

5.8. Independent Assurance Reports

Objective

5.8.1.

To provide assurance to System Owners, Certifiers, Practitioners and Accreditors and to assist system designers, enterprise and security architects where assurance reviews cannot be directly undertaken on service providers.

Context

Scope

5.8.2.

Independent assurance reports are also variously referred to as third party assurance reporting, third party reviews, attestation reports and SAS 70 reports. It is important to note that SAS 70 has been superseded by the ISAE 3402 and SSAE 16 standards encompassing Type I and 2 and SOC 1, 2 and 3 reports. For reviews conducted in New Zealand the ISAE (NZ) 3402 or ISAE (NZ) 3000 standards are used. These various standards and report types are discussed later in this section. Agencies are likely to encounter a variety of report types, depending on the country of residence or country of jurisdiction of the service provider, or the geographic location of the data centre.

Purpose

5.8.3.

Many organisations are outsourcing key components of their business such as telecommunications, data storage and cloud based services. Managing third-party relationships is particularly challenging with services provided from outside New Zealand. The global nature of these services and the global nature of associated risks must be recognised by organisations. As outsourced services are becoming more integrated with organisation’s operations, they will have a larger impact on organisation’s governance, assurance and control frameworks. It is important to note that risk ownership and accountability remains with agencies and respective risk owners, even when responsibility for specific functions have been outsourced.

5.8.4.

Independent assurance reports provide customers and other interested parties with information on policies, procedures and controls related to the service provider’s internal frameworks, control objectives and controls in cases where physical inspections and reviews by customers are impractical or not feasible. Service providers may also use the findings of such reports for their own purposes. These reports are used to understand the adequacy and effectiveness of the service provider’s frameworks, control objectives, controls and implementation of controls. They allow:

  • Business owners to identify and understand the risks associated with the service delivery;
  • System owners to more fully assess system risks;
  • System designers and security architects to make informed judgements on system structures, controls, defensive measures, and enterprise integration; and
  • Regulators, certifiers and accreditors to obtain assurance over the service providers internal control structures and assess the suitability of system structures, controls and defensive measures.
5.8.5.

An independent assurance review or third-party audit is invariably undertaken by independent auditors who are not employees of the service provider or their customers. There are two common types of independent third-party reviews: attestation reviews and direct non-attestation reviews.

5.8.6.

Attestation reviews, such as an ISAE 3402 review (see below), are generally conducted by accounting or consulting organisations and are based upon recognised attestation standards issued by professional bodies such as the American Institute of Certified Public Accounts (AICPA) or the New Zealand External Reporting Board (XRB).

5.8.7.

Direct or non-attestation reviews include those performed by IT consultants or others and may not follow standards referred to previously. They may be based upon other external standards or industry developed criteria such as ISO 2700x, ISACA’s COBIT, the IIA, NIST, or the Cloud Security Alliance (CSA).

Assurance

5.8.8.

Assurance is derived from an assessment of:

  • A description of the service provider’s business and control environment;
  • Terms and conditions of the service contract or other legally binding agreement;
  • Assertions supplied by the service provider (self-assessments);
  • An independent validation of service provider assertions;
  • Independent testing of controls implementation and effectiveness;
  • Assurance in the service design and security architecture; and
  • Assurance in the service components.
5.8.9.

In general terms, the more ICT services that are outsourced in an agency, the less direct control and visibility the CE and management have over enterprise operations. Therefore, there is an increased reliance on assurance reporting from suppliers.  Unless this is recognised in service contracts or legal agreements, agencies may find they are unable to obtain sufficient levels of assurance over the business services and enterprise operations.

Assurance Standards and schemes

ISAE (NZ) 3000

5.8.10.

ISAE (NZ) 3000 (Revised) is issued by the External Reporting Board (XRB) of the New Zealand Audit and Assurance Standards Board and is the umbrella standard for other (non-financial) assurance engagements conducted in New Zealand. The standard covers a wide variety of engagements, ranging from assurance on statements about the effectiveness of internal control, for example, to assurance on sustainability reports and possible future engagements addressing integrated reporting. It is a principle-based standard that underpins current and future subject-specific ISAEs (NZ).

ISAE (NZ) 3402

5.8.11.

In New Zealand the XRB issued the ISAE (NZ) 3402 in 2014, revised in 2016.  This standard has essentially the same requirements as the international standard ISAE 3402 (see below), with some New Zealand specific adaptations.  Australia, Singapore and many other jurisdictions have adopted this approach in the issue of this standard with some jurisdiction specific adaptations.

ISAE 3402

5.8.12.

The most commonly used international standard for independent assurance reports is the International Standard on Assurance Engagements (ISAE) No. 3402, Assurance Reports on Controls at a Service Organization, issued in December 2009 by the International Auditing and Assurance Standards Board (IAASB), part of the International Federation of Accountants (IFAC).

5.8.13.

Based on its predecessor standard SAS 70 (1992), ISAE 3402 was developed to provide an international assurance standard for allowing public accountants to issue a report for use by user organisations and their auditors (user auditors) on the controls at a service organisation that are likely to impact or be a part of the user organisation’s system of internal control over financial reporting.

5.8.14.

Auditing and associated consulting firms were required to use ISAE 3402 for all related work after June 2011.

ISAE 3402 Report Types

5.8.15.

The ISAE 3402 provides for a report on controls at a point in time (Type 1 Report) or covering a specified period of time, usually between six and twelve months (Type 2 Report).

5.8.16.

A Type 1 report is of limited use as it cannot cover the operating effectiveness of controls and is generally used for new operations where there is no evidence or documented history.

5.8.17.

A Type 2 report not only includes the service organisation's description of controls, but also includes detailed testing of the service organisation's controls over a minimum six month period.

5.8.18.

It is important to note that the descriptions Type 1 and Type 2 represent an audit approach and should not be confused with SOC 1, 2 and 3 reports under SSAE 16 (see below).

ISAE 3402 Report Uses and Limitations

5.8.19.

This standard is used to obtain reasonable assurance about whether:

  • The service organisation’s description of its system fairly presents the system as designed and implemented throughout a specified period or a specific date;
  • The controls related to the control objectives stated in the service organisation’s description of its system were suitably designed throughout the specified period or at the specified date;
  • Where included in the scope of the engagement, the controls were implemented and operated effectively to provide reasonable assurance that the control objectives stated in the service organisation’s description of its system were achieved throughout the specified period.
5.8.20.

This ISAE applies only when the service organisation is responsible for, or otherwise able to make an assertion about, the suitable design of controls. It does not cover situations where:

  • reporting only whether controls at a service organisation operated as described; or
  • reporting on controls at a service organisation other than those related to a service relevant to user entities.

ISAE 3402 Report Content

5.8.21.

The ISAE 3402 report usually comprises:

  • The service auditor’s report;
  • Assertions by the service provider;
  • A description of control objectives and controls provided by the service organisation;
  • Results of any tests and other information provided by the independent auditor; and
  • Any other information provided by the service provider.

US Standard SSAE 16

5.8.22.

The Statement on Standards for Attestation Engagements No. 16 (SSAE 16) is issued by the Auditing Standards Board (ASB) of the American Institute of Certified Public Accountants (AICPA). It includes additional requirements to the superseded SAS 70 standard by requiring management to provide a written assertion (see below) regarding the design and operating effectiveness of the controls being reviewed. It is possible that agencies may encounter an SSAE16 based report for a US-based entity.

5.8.23.

SSAE 16 is the US equivalent of the international ISAE 3402 and came into effect on
15 June 2011. While the SSAE 16 and ISAE 3402 standards have a common purpose and intent, , there are nine very specific requirements in SSAE 16, not covered in ISAE 3402:

  • Intentional acts by the service providers staff;
  • Anomalies;
  • Direct assistance;
  • Subsequent events;
  • Statement restricting use of the service auditor’s report;
  • Disclaimer of Opinion;
  • Documentation completion;
  • Engagement acceptance and continuance; and
  • Elements of the SSAE 16 report that are not required in the ISAE 3402 report.
5.8.24.

These differences are summarised in the table below:

  SSAE 16 ISAE 3402
Use of report Report specifically states it is restricted to intended users. Report intended for user entities and their auditors but may include other restrictive use conditions.

Intentional Acts

Consideration of the impact of intention acts. No requirement stated.
Subsequent Events Auditors must consider Type 2 events after the report date. Events after the report date are not considered.
Reporting Sample deviations may not be discarded even when considered non-representative. Sample deviations are assessed and may be discarded as not representative of the sample population.
5.8.25.

The SSAE 16 standard specifies Type 1 and 2 audits (as does ISAE 3402).

5.8.26.

A Type 1 is a report on a description of a service organisation’s system and the suitability of the design of controls. A Type 1 report will test the design effectiveness of defined controls by examining a sample of one item per control. This provides a basic level of assurance that the organisation has some controls in place. It does not measure the completeness or effectiveness of these controls and represents a point in time.

5.8.27.

A Type2 report is a report on policies and procedures placed in operation and tests of operating effectiveness for a specified period of time. A Type 2 report undertakes the tests in a Type 1 report together with an evaluation of the operating effectiveness of the controls for a period of at least six consecutive calendar months.

AICPA Service Organisation Control Reporting (SOC Reports)

5.8.28.

Service Organization Control (SOC) Reports, often known as SOC 1, SOC 2, and SOC 3 Reports, are derived from a framework published by the American Institute of Certified Public Accountants (AICPA) for reporting on controls at service organisations.

5.8.29.

In New Zealand, SOC 1 reports follow the ISAE (NZ) 3402 standard and SOC 2 reports are follow the ISAE (NZ) 3000 standard, in conjunction with the NZ Standard for Assurance Engagements SAE 3150, for assurance engagements on controls.

5.8.30.

Each of the three SOC reports are designed to meet specific needs and reporting requirements for service organisations themselves, rather than being designed to provide assurance to third parties (customers). It is important to note that these reports follow the US (SSAE 16) and Canadian accounting standards, rather than the international ISAE 3402.

SOC 1 Report – Report on Controls at a Service Organization Relevant to User Entities’ Internal Control over Financial Reporting. Reporting on controls relevant to internal control over financial reporting and usually conducted in accordance with Statement on Standards for Attestation Engagements (SSAE) No. 16 and AT 801 – Reporting on Controls at a Service Organization. A SOC 1 report can be based on a Type 1 or a Type 2 audit.

SOC 2 Report— Report on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality or Privacy. SOC 2 Reporting follows the AICPA AT Section 101 (not SSAE 16) and encompasses controls at service organisations on security, availability, processing Integrity, confidentiality and privacy. SOC 2 reports assist in comparing two or more data centres or service providers.

SOC 3 Report— Trust Services Report for Service Organizations. As well as reporting on controls relevant to security, availability, processing integrity, confidentiality and privacy a SOC 3 report provides the same level of assurance about controls over security, availability, processing integrity, confidentiality and/or privacy as a SOC 2 report. The key difference is that a SOC 3 report is intended for general release and does not include the detailed description of the testing performed by the auditor. In place of the detailed description a summary opinion regarding the effectiveness of the controls in place at the data centre or service organisation is provided.

SOC Reports Summary

Report Standards Content Audience
SOC1 – Type 1

ISAE (NZ) 3402/
SAE 3150
or
SSAE 16/AT 801

Internal controls over financial reporting at a point in time. User auditors, organisation finance team, management.
SOC1 – Type 2

ISAE (NZ) 3402/
SAE 3150
or
SSAE 16/AT 801

Internal controls over financial reporting over a specified time period, minimum 6 months. User auditors, organisation finance team, management.
 SOC2 – Type 1  ISAE (NZ) 3000/

SAE 3150
or
AT 101

Security, availability, processing integrity, confidentiality and privacy controls at a point in time. Management, regulators, third parties under Non-Disclosure Agreement.
 SOC2 – Type 2  ISAE (NZ) 3000/

SAE 3150
or
AT 101

Security, availability, processing integrity, confidentiality, privacy controls and operating effectiveness over a specified time period, minimum 6 months. Management, regulators, third parties under Non-Disclosure Agreement.
 SOC3  ISAE (NZ) 3000/

SAE 3150
or
AT 101

Security, availability, processing integrity, confidentiality, privacy controls and operating effectiveness. Public/general use version of SOC 2, excludes details of testing.  Is less detailed and has less technical content than a SOC 2 report.

Management Assertions

5.8.31.

See Assertions in Certification and Accreditation (NZISM 3.4.3 to 3.4.7) for a short discussion on the nature and purpose of assertions.

5.8.32.

The SSAE 16 requires a written assertion by management. Also known as a management’s assertion or service organisation assertion it is essentially an assertion made by the service organisation representing and asserting to a number of elements, including:

  • The description fairly presents the service organisation's system;
  • That the control objectives were suitably designed (SSAE 16 Type 1) and operating effectively (SSAE 16 Type 2) during the dates and/or periods covered by the report; and
  • The criteria used for making these assertions, (which are additional statements with supporting matter regarding risk factors relating to control objectives and underlying controls) were in place (Type 1) and were consistently applied (Type 2).

ISO/IEC 27001 Certification

5.8.33.

ISO/IEC 27001 is an international standard that provides a framework for Information Security Management Systems. The standard is designed to help organisations of all sizes and types to select suitable and proportionate security controls for information. It provides a structured approach to assist in managing risk by identifying information security vulnerabilities and selecting appropriate controls.

5.8.34.

This standard enables independent, external certification bodies to audit the ISMS and certify that the requirements of the standard have been met. Such certification is another means of deriving assurance over the operations of service providers. The requirements for certification are described in the ISO/IEC 27006:2015 standard. Certification is based on two reviews:

  • Stage 1 audit (also called Documentation review) checking the systems documentation is compliant with ISO 27001;
  • Stage 2 audit (also called Main audit) checking that all the organisation’s activities are compliant with both ISO 27001 and the systems documentation.

Other Guidance

Cloud Security Alliance’s Security, Trust and Assurance Registry (STAR) Attestation

5.8.35.

STAR Certification is a rigorous third party independent assessment of the security of a cloud service provider. It is based on the ISAE 3402 and SSAE 16 standards, supplemented by the criteria in the Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM).

5.8.36.

STAR is a free, publicly accessible registry that documents the security controls provided by various cloud computing service providers. The registry lists three levels of assurance:

  1. Self-assessment;
  2. Third party assessment based attestation or certification; and
  3. Continuous monitoring based certification.

Note: Agencies should note that a self-assessment does not necessarily provide substantive assurance.

5.8.37.

As at March 2017, the STAR scheme is still to be fully implemented although there are a number of cloud service providers listed in the registry.

5.8.38.

Agencies can use this registry to further inform their judgement on the robustness of assurance over cloud service provider’s internal operations and implementation of security controls.

Cloud Security Alliance’s Cloud Controls Matric (CCM)

5.8.39.

The CCM covers 16 control domains and provides fundamental security principles to guide cloud service providers and to assist prospective cloud customers in assessing the overall security risk of a cloud service provider.

5.8.40.

The CCM references and maps its controls to internationally accepted industry standards, regulations, and control frameworks, such as ISO 27001/2/17/18, PCI: DSS v3, and AICPA 2014 Trust Service Principles and Criteria, Germany’s BIS, Canada’s PIPEDA, ISACA’s COBIT, the US FedRAMP, HIPAA, Jericho Forum, NIST and the NZISM.

Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ)

5.8.41.

The CAIQ is an extension to the CCM that provides exemplar control assertion questions that can be asked of service providers in the context of each CCM control, and can be tailored to suit each unique cloud customer’s evidentiary requirements. GCIO maintain a mapping of the CAIQ questions to the GCIO Cloud Security and Privacy Considerations question set to further aid agencies in use of the CAIQ as an alternative to equivalent GCIO questions.

ISACA IT Audit and Assurance Program for Cloud Computing

5.8.42.

Based on ISACA’s IT Assurance Framework (ITAF), the Cloud Computing Assurance Program was developed as a comprehensive and good-practice model, aligned with the ISACA COBIT 5 framework. Building on the generic assurance program, the cloud computing guidance identifies a number of cloud specific risk areas encompassing:

  • Greater dependency on third parties;
  • Increased complexity of compliance with national and international laws and regulations;
  • Reliance on the Internet as the primary conduit to the enterprise’s data; and
  • Risk due to the dynamic nature of cloud computing.
5.8.43.

The ITAF assurance focus is on:

  • The governance affecting cloud computing;
  • The contractual compliance between the service provider and customer;
  • Privacy and regulation issues concerning cloud computing; and
  • Cloud computing specific attention points.
5.8.44.

It is important to note that this cloud computing assurance review is not designed to provide assurance on the design and operational effectiveness of the cloud computing service provider’s internal controls, as this assurance is often provided through ISAE 3604 or similar reviews.

5.8.45.

The cloud computing assurance review focusses on the agency’s or organisation’s systems design and operational effectiveness in relation to cloud services. It is also important to note that this is dependent on the effectiveness of the underlying system design and controls and how well these are implemented and managed.

ASD Certified Cloud Services

5.8.46.

The Australian Signals Directorate (ASD) conducts certification of cloud services based in Australia for Australian government use. ASD Certifications are based on the Australian Government Information Security Manual (ISM). It is important to note that there are detail differences between the Australian ISM and the NZISM and these documents have a different legislative and regulatory basis.

5.8.47.

The ASD Cloud Computing Security documents describe security risk mitigations associated with cloud computing. Australian Government agencies are also required to perform due diligence reviews of the legal, financial and privacy risks associated with procuring cloud services, aspects which are not covered by the ASD certification.

NIST 800-53

5.8.48.

The NIST Special Publication 800-53 Revision 4 - Security and Privacy Controls for Federal Information Systems and Organizations is the US unified information security framework for US federal government agencies. The New Zealand equivalent is the NZISM.

5.8.49.

The underlying mandates are in FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems and FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems. US federal government agencies are required to categorise and analyse their system in terms of FIPS 199 and 200 then apply appropriate controls from NIST 800-53.

FedRAMP

5.8.50.

The US Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program intended to provide a standardised approach to security assessment, authorisation, and continuous monitoring for cloud products and services. This approach is designed to provide reusable cloud security assessments in order to reduce cost, resource and time.

5.8.51.

FedRAMP is a collaboration of cybersecurity and cloud experts from the General Services Administration (GSA), National Institute of Standards and Technology (NIST), Department of Homeland Security (DHS), Department of Defense (DOD), National Security Agency (NSA), Office of Management and Budget (OMB), the Federal Chief Information Officer (CIO) Council and its working groups, as well as private industry.

5.8.52.

FedRAMP authorises cloud systems in a three step process:

  1. Security Assessment: The security assessment process uses a standardised set of requirements in accordance with FISMA using a baseline set of NIST 800-53 controls to grant security authorisations.
  2. Leveraging and Authorisation: Federal agencies view security authorisation packages in the FedRAMP repository and leverage the security authorisation packages to grant a security authorisation at their own agency.
  3. Ongoing Assessment & Authorisation: Once an authorisation is granted, ongoing assessment and authorisation activities are required to maintain the security authorisation.
5.8.53.

Again it is important to note that the FedRAMP assessments are conducted on a different legislative and regulatory basis to assessments conducted in New Zealand.

PCI DSS

5.8.54.

The Payment Card Industry Security Standards Council was formed by major credit card organisations and is a global open body formed to develop and promote understanding of essential security standards for payment account security. It develops, maintains and promotes the Payment Card Industry Data Security Standards (PCI DSS). It also provides tools to assist the implementation of the standards such as assessment and scanning qualifications, self-assessment questionnaires, training and education, and product certification programs.

5.8.55.

This standard is designed to protect cardholder data (credit and debit cards) held by merchants, banks and other financial organisations. It applies to all organisations that accept, store, process and transmit credit cardholder data.

5.8.56.

This standard is narrowly focussed and has specific applicability to New Zealand Government agencies that operate financial transaction services (e.g. AoG Banking services and citizen fee-paying services; such as vehicle registration, passport renewal, etc.). The PCI has published an information supplement on Third-Party Security Assurance (updated March 2016).

COSO

5.8.57.

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) initially developed the COSO Internal Control-Integrated Framework in 1992. A revised framework was published in 2013 which included guidance on “outsourced service providers” and how they impact risk assessment, controls, monitoring, information flows and assurance. The 2013 Framework incorporates how organisations should manage IT innovation in light of globalisation, complex business processes, regulatory demands and security risk assessments. It is frequently used as the basis for SSAE16 assignments and the production of SOC reports.

References – Assurance Standards

5.8.58.

Further information on Assurance Standards can be found in:

Title Publisher Source

International Standard on Assurance Engagements (ISAE) 3402 - Assurance Reports on Controls at a Service Organization

International Federation of Accountants (IFAC)

http://www.ifac.org/system/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf

Reporting on Controls at a Service Organization - SSAE No. 16

AICPA http://www.aicpastore.com/AST/Main/CPA2BIZ_Primary/InformationManagementTechnologyAssurance/PRDOVR~PC-023035/PC-023035.jsp

Service Organization Controls (SOC) Reports for Service Organizations 

AICPA http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/pages/serviceorganization'smanagement.aspx

AT Section 101 Attest Engagements

AICPA http://www.aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AT-00101.pdf

AT Section 801 Reporting on Controls at a Service Organization

AICPA http://www.aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AT-00801.pdf

COBIT 5 Framework

ISACA http://www.isaca.org/cobit/Pages/CobitFramework.aspx

ISAE (NZ) 3000 (Revised) - Assurance Engagements Other than Audits or Reviews of Historical Financial Information 

XRB https://xrb.govt.nz/Site/Auditing_Assurance_Standards/Current_Standards/Other_Assurance_Engagements_Standards.aspx

ISAE (NZ) 3402 - Assurance Reports on Controls at a Service Organisation

XRB https://xrb.govt.nz/Site/Auditing_Assurance_Standards/Current_Standards/Other_Assurance_Engagements_Standards.aspx

SAE 3150 - Standard on Assurance Engagements 3150

XRB https://xrb.govt.nz/Site/Auditing_Assurance_Standards/Current_Standards/Other_Assurance_Engagements_Standards.aspx

NIST Special Publication 800-53 Revision 4 Security and Privacy Controls for Federal Information Systems and Organizations

NIST

http://csrc.nist.gov/publications/nistpubs

NIST Special Publication 500-299 (Draft) NIST Cloud Computing Security Reference Architecture

NIST

http://csrc.nist.gov/publications/nistpubs 

Information Supplement: Third-Party Security Assurance

PCI Security Standards Council

https://www.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf

ISO 19011:2011, Guidlines for Auditing Management Systems

ISO https://www.iso.org/standard/50675.html  

ISO/IEC 27000, Information security management systems — Overview and vocabulary

ISO http://www.iso.org/

ISO/IEC 27001: 2013, Information security management systems — Requirements

ISO http://www.iso.org/

ISO/IEC 27006, Requirements for bodies providing audit and certification of information security management systems

ISO http://www.iso.org/

ISO/IEC 27007, Guidelines for information security management systems auditing

ISO http://www.iso.org/

ISO/IEC TR 27008, Guidelines for auditors on information security controls

ISO http://www.iso.org/

ISO/IEC 27014, Governance of information security

ISO http://www.iso.org/

ISO/IEC 27017, Code of practice for information security controls based on ISO/IEC 27002 for cloud services

ISO http://www.iso.org/

ISO/IEC 27018:2014 Information technology -- Security techniques -- Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors

ISO http://www.iso.org/

References – Assurance Guidance

5.8.59.
Title Publisher Source

FAQs — New Service Organization Standards and Implementation Guidance

American Institute of Certified Public Accountants (AICPA) http://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/downloadabledocuments/faqs_service_orgs.pdf

The Federal Risk and Authorization Management Program (FedRAMP)

General Services Administration, US Federal Government https://www.fedramp.gov/

Controls and Assurance in the Cloud Using COBIT 5

ISACA http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Controls-and-Assurance-in-the-Cloud-Using-COBIT-5.aspx

Special Publication 800-115 Technical Guide to Information Security Testing and Assessment

NIST http://csrc.nist.gov/publications/nistpubs

Cloud Security Guidance

NCSC UK https://www.ncsc.gov.uk/guidance/cloud-security-collection

Cloud Security Guidance: Implementing Cloud Security Principles

NCSC UK https://www.ncsc.gov.uk/guidance/implementing-cloud-security-principles

ASD Certified Cloud Services

ASD http://www.asd.gov.au/infosec/irap/certified_clouds.htm

Security Framework for Governmental Clouds

ENISA https://www.enisa.europa.eu/publications/security-framework-for-governmental-clouds

Good Practice Guide for securely deploying Governmental Clouds

ENISA https://www.enisa.europa.eu/publications/good-practice-guide-for-securely-deploying-governmental-clouds

Security & Resilience in Governmental Clouds

ENISA https://www.enisa.europa.eu/publications/security-and-resilience-in-governmental-clouds

Assurance on non-financial information Existing practices and issues, July 2008, ISBN 978-1-84152-604-1

Institute of Chartered Accountants in England and Wales (ICAEW). Assurance on non-financial information existing practices and issues (PDF)

IIA Position Paper: The Three Lines of Defense in Effective Risk Management and Control, January 2013

The Institute of Internal Auditors (IIA) The three lines of defense in effective risk management and control (PDF)

Cloud Security Alliance Reference Architecture

Cloud Security Alliance https://downloads.cloudsecurityalliance.org/initiatives/tci/TCI_Reference_Architecture_v2.0.pdf

Cloud Controls Matrix v3.0.1 (6-6-16 Update)

Cloud Security Alliance https://cloudsecurityalliance.org/download/cloud-controls-matrix-v3-0-1/

Consensus Assessments Initiative Questionnaire (CAIQ) v3.0.1

Cloud Security Alliance https://cloudsecurityalliance.org/media/news/ccm-caiq-v3-0-1-soft-launch/

Security Guidance for Critical Areas of Focus in Cloud Computing V3.0

Cloud Security Alliance https://downloads.cloudsecurityalliance.org/initiatives/guidance/csaguide.v3.0.pdf

About CSA STAR Attestation

Cloud Security Alliance https://cloudsecurityalliance.org/star/attestation/

Guidelines for CPAs Providing CSA STAR Attestation

Cloud Security Alliance https://cloudsecurityalliance.org/download/guidelines-for-cpas-providing-csa-star-attestation/

CSA Security, Trust & Assurance Registry (STAR)

Cloud Security Alliance https://cloudsecurityalliance.org/star/#star_m

Payment Card Industry (PCI) Data Security Standard - Requirements and Security Assessment Procedures Version 3.

02 April 2016

PCI Security Standards Council

https://www.pcisecuritystandards.org/
Enterprise Risk Management — Integrated Framework COSO http://www.coso.org/documents/coso_erm_executivesummary.pdf

Internal Control – Integrated Framework

COSO http://www.coso.org/documents/990025P_Executive_Summary_final_may20_e.pdf

Rationale & Controls

5.8.60. Risk Assessment

5.8.60.R.01.Rationale

The Security Risk Management Plan (SRMP – Section 5.3) encompasses all risks associated with the security of agency systems. The growth in outsourced services, particularly cloud services, has created situations where risk, controls and assurance cannot be directly examined and assessed. In such cases independent assurance reports are an effective means, possibly the only means, of obtaining some assurance on the service provider’s operations.

5.8.60.R.02.Rationale

No single independent assurance scheme/standard covers the full range of considerations and control requirements of the NZISM. Agencies may find duplication of aspects analysed if multiple schemes are applied. . It is also important to note that none of the common mature assurance schemes cover specific government requirements and handling of Official Information; such as the personnel aspects (PERSEC) of user and administration vetting and security clearances, or sovereignty aspects of the information/data. Careful selection and consideration is required when placing reliance on reports available for a particular outsourced or cloud service.

5.8.60.R.03.Rationale

Reports from different assurance scheme have varying levels of detail as well as risk area coverage. Selection and usage of reports should be considered in the context of the intended service/system business and information value.

Understanding the business and technical risk context will drive the size and depth of a risk assessment, and the associated assurance process. Though even a lighter-weight risk assurance process will follow the C&A process model, such that the CE or authorised delegate is still formally accountable and responsible.

Re-use of assessments completed by other agencies is encouraged, noting the business or information value context may differ. To assist agencies and promote efficiency, the GCIO facilitates the sharing and re-use of existing cloud assessment materials among agencies.

5.8.60.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1019]

Agencies MUST conduct a risk assessment in order to determine the type and level of independent assurance required to satisfy certification and accreditation requirements.

5.8.60.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1020]

In all cases where assurance on service provider operations cannot be obtained directly, agencies SHOULD obtain independent assurance reports.

5.8.60.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1021]

In order to address identified risk areas, agencies SHOULD obtain relevant assurance reports and service provider certifications to inform a risk assessment and Certification activities as well as other aspects of the certification processes such as evidence of controls effectiveness and remediation plans.

5.8.61. Independent Assurance

5.8.61.R.01.Rationale

Independent assurance can be obtained directly from the service provider through Service Organisation Control (SOC) reports, as well as other internationally recognised assurance frameworks. It will be important to corroborate individual reports by comparison with other reporting mechanisms and independent certifications.

5.8.61.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1024]

Agencies MUST incorporate the results of any independent assurance reports into the agency Certification process, to understand the residual risk position and controls required to manage risk appropriately.

6. Information security monitoring

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

6.1. Information Security Reviews

Objective

6.1.1.

Information security reviews maintain the security of agency systems and detect gaps and deficiencies.

Context

Scope

6.1.2.

This section covers information on conducting reviews of any agency’s information security posture and security implementation.

Information security reviews

6.1.3.

An information security review:

  • identifies any changes to the business requirements or concept of operation for the subject of the review;
  • identifies any changes to the security risks faced by the subject of the review;
  • assesses the effectiveness of the existing counter-measures;
  • validates the implementation of controls and counter-measures; and
  • reports on any changes necessary to maintain an effective security posture.
6.1.4.

An information security review can be scoped to cover anything from a single system to an entire agency’s systems.

References

6.1.5.

Additional information relating to system auditing is contained in:

Reference Title Source
ISO/IEC_27006:2011 Information Technology – Security Techniques - Requirements for bodies providing audit and certification of information security management systems.

http://www.iso27001security.com/html/27006.html
http://www.standards.co.nz

ISO/IEC_27007:2011 Information Technology – Security Techniques - Guidelines for information security management systems auditing.

http://www.iso27001security.com/html/27007.html 

http://www.standards.co.nz

ISO/IEC_27008:2011 Information Technology – Security Techniques - Guidelines for Auditors on information security controls.

http://www.iso27001security.com/html/27008.html

http://www.standards.co.nz

PSR references

Rationale & Controls

6.1.7. Conducting information security reviews

6.1.7.R.01.Rationale

Annual reviews of an agency’s information security posture can assist with ensuring that agencies are responding to the latest threats, environmental changes and that systems are properly configured in accordance with any changes to information security documentation and guidance.

6.1.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1040]

Agencies SHOULD undertake and document information security reviews of their systems at least annually.

6.1.8. Managing Conflicts of Interest

6.1.8.R.01.Rationale

Reviews may be undertaken by personnel independent of the target of evaluation or by an independent third party to ensure that there is no (perceived or actual) conflict of interest and that an information security review is undertaken in an objective manner.

6.1.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1043]

Agencies SHOULD have information security reviews conducted by personnel independent to the target of the review or by an independent third party.

6.1.9. Focus of information security reviews

6.1.9.R.01.Rationale

Incidents, significant changes or an aggregation of minor changes may require a security review to determine and support any necessary changes and to demonstrate good systems governance. An agency may choose to undertake an information security review:

  • as a result of a specific information security incident;
  • because a change to a system or its environment that significantly impacts on the agreed and implemented system architecture and information security policy; or
  • as part of a regular scheduled review.
6.1.9.R.02.Rationale

In order to review risk, an information security review should analyse the threat environment and the highest classification of information that is stored, processed or communicated by that system.

6.1.9.R.03.Rationale

Depending on the scope and subject of the information security review, agencies may gather information on areas including:

  • agency priorities, business requirements and/or concept of operations;
  • threat data;
  • risk likelihood and consequence estimates;
  • effectiveness of existing counter-measures;
  • other possible counter-measures; 
  • changes to standards, policies and guidelines;
  • recommended good practices; and
  • significant system incidents and changes.
6.1.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1048]

Agencies SHOULD review the components detailed in the table below.

Component Review
Information security documentation The SecPol, Systems Architecture, SRMPs, SecPlans, SitePlan, SOPs the IRP, and any third party assurance reports.
Dispensations Prior to the identified expiry date.
Operating environment When an identified threat emerges or changes, an agency gains or loses a function or the operation of functions are moved to a new physical environment.
Procedures After an information security incident or test exercise.
System security Items that could affect the security of the system on a regular basis.
Threats Changes in threat environment and risk profile.
NZISM Changes to baseline or other controls, any new controls and guidance.
img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

6.2. Vulnerability Analysis

Objective

6.2.1.

Exploitable information system weaknesses can be identified by vulnerability analyses and inform assessments and controls selection.

Context

Scope

6.2.2.

This section covers information on conducting vulnerability assessments on systems as part of the suite of good IT governance activities.

Changes as a result of a vulnerability analysis

6.2.3.

It is important that normal change management processes are followed where changes are necessary in order to address security risks identified in a vulnerability analysis.

Rationale & Controls

6.2.4. Vulnerability analysis strategy

6.2.4.R.01.Rationale

Vulnerabilities may be unintentionally introduced and new vulnerabilities are constantly identified, presenting ongoing risks to information systems security.

6.2.4.R.02.Rationale

While agencies are encouraged to monitor the public domain for information related to vulnerabilities that could affect their systems, they should not remain complacent if no specific vulnerabilities relating to deployed products are disclosed.

6.2.4.R.03.Rationale

In some cases, vulnerabilities can be introduced as a result of poor information security practices or as an unintended consequence of activities within an agency. As such, even if no new public domain vulnerabilities in deployed products have been disclosed, there is still value to be gained from regular vulnerability analysis activities.

6.2.4.R.04.Rationale

Furthermore, monitoring vulnerabilities, conducting analysis and being aware of industry and product changes and advances, including NZISM requirements, provides an awareness of other changes which may adversely impact the security risk profile of the agency’s systems.

6.2.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1063]

Agencies SHOULD implement a vulnerability analysis strategy by:

  • monitoring public domain information about new vulnerabilities in operating systems and application software;
  • considering the use of automated tools to perform vulnerability assessments on systems in a controlled manner;
  • running manual checks against system configurations to ensure that only allowed services are active and that disallowed services are prevented; 
  • using security checklists for operating systems and common applications; and
  • examining any significant incidents on the agency’s systems.

6.2.5. Conducting vulnerability assessments

6.2.5.R.01.Rationale

A baseline or known point of origin is the basis of any comparison and allows measurement of changes and improvements when further information security monitoring activities are conducted.

6.2.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1066]

Agencies SHOULD conduct vulnerability assessments in order to establish a baseline:

  • before a system is first used;
  • after any significant incident;
  • after a significant change to the system;
  • after changes to standards, policies and guidelines; and/or
  • as specified by an ITSM or the system owner.

6.2.6. Resolving vulnerabilities

6.2.6.R.01.Rationale

Vulnerabilities may occur as a result of poorly designed or implemented information security practices, accidental activities or malicious activities, and not just as the result of a technical issue.

6.2.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1069]

Agencies SHOULD analyse and treat all vulnerabilities and subsequent security risks to their systems identified during a vulnerability assessment.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

6.3. Change Management

Objective

6.3.1.

To ensure information security is an integral part of the change management process, it should be incorporated into the agency’s IT maintenance governance and management activities.

Context

Scope

6.3.2.

This section covers information on identifying and managing routine and urgent changes to systems.

Identifying the need for change

6.3.3.

The need for change can be identified in various ways, including:

  • system users identifying problems or enhancements;
  • vendors notifying of upgrades to software or IT equipment;
  • vendors notifying of the end of life to software or IT equipment;
  • advances in technology in general;
  • implementing new systems that necessitate changes to existing systems;
  • identifying new tasks or functionality requiring updates or new systems;
  • organisational change;
  • business process or concept of operation change;
  • standards evolution;
  • government policy or Cabinet directives;
  • threat or vulnerability identification and notification; and
  • other incidents or continuous improvement activities.

Types of system change

6.3.4.

A proposed change to a system could involve:

  • an upgrade to, or introduction of IT equipment;
  • an upgrade to, or introduction of software;
  • environment or infrastructure change; or
  • major changes to access controls.

PSR references

Rationale & Controls

6.3.6. Change management

6.3.6.R.01.Rationale

A considered and accountable process requires consultation with all stakeholders before any changes are implemented. In the case of changes that will affect the security or accreditation status of a system, the Accreditation Authority is a key stakeholder and will need to be consulted and grant approval for the proposed changes.

6.3.6.R.02.Rationale

Change management processes are most likely to be bypassed or ignored when an urgent change needs to be made to a system. In these cases it is essential that the agency’s change management process strongly enforces appropriate actions to be taken before and after an urgent change is implemented.

6.3.6.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1088]

Agencies MUST ensure that for routine and urgent changes:

  • the change management process, as defined in the relevant information security documentation, is followed;
  • the proposed change is approved by the relevant authority;
  • any proposed change that could impact the security or accreditation status of a system is submitted to the Accreditation Authority for approval; and
  • all associated information security documentation is updated to reflect the change.
6.3.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1089]

Agencies SHOULD ensure that for routine and urgent changes:

  • the change management process, as defined in the relevant information security documentation, is followed;
  • the proposed change is approved by the relevant authority;
  • any proposed change that could impact the security of a system or accreditation status is submitted to the Accreditation Authority for approval; and
  • all associated information security documentation is updated to reflect the change.

6.3.7. Change management process

6.3.7.R.01.Rationale

Uncontrolled changes pose risks to information systems as well as the potential to cause operational disruptions.  A change management process is fundamental to ensure a considered and accountable approach with appropriate approvals.  Furthermore, the change management process provides an opportunity for the security impact of the change to be considered and if necessary, reaccreditation processes initiated.

6.3.7.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1093]

An agency’s change management process MUST define appropriate actions to be followed before and after urgent changes are implemented.

6.3.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1094]

An agency’s change management process SHOULD define appropriate actions to be followed before and after urgent changes are implemented.

6.3.7.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1095]

Agencies SHOULD follow this change management process outline:

  • produce a written change request;
  • submit the change request to all stakeholders for approval;
  • document the changes to be implemented;
  • test the approved changes;
  • notification to user of the change schedule and likely effect or outage;
  • implement the approved changes after successful testing;
  • update the relevant information security documentation including the SRMP, SecPlan and SOPs
  • notify and educate system users of the changes that have been implemented as close as possible to the time the change is applied; and
  • continually educate system users in regards to changes.

6.3.8. Changes impacting the security of a system

6.3.8.R.01.Rationale

The accreditation of a system accepts residual security risk relating to the operation of that system. Changes may impact the overall security risk for the system. It is essential that the Accreditation Authority is consulted and accepts the changes and any changes to risk.

6.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1098]

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 agency MUST reaccredit the system.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

6.4. Business Continuity and Disaster Recovery

Objective

6.4.1.

To ensure business continuity and disaster recovery processes are established to assist in meeting the agency’s business requirements, minimise any disruption to the availability of information and systems, and assist recoverability.

Context

Scope

6.4.2.

This section covers information on business continuity and disaster recovery relating specifically to systems.

References

6.4.3.

Additional information relating to business continuity is contained in:

Reference Title Source
ISO/IEC_22301:2012 Societal Security – Business Continuity Management Systems - Requirements.

http://www.iso.org
http://www.standards.co.nz

ISO/IEC 27001:2013 Information Technology – Security Techniques - Information Security Management Systems - Requirements

http://www.iso27001security.com/html/27001.html
http://www.standards.co.nz

SAA/SNZ HB 221:2004 Business Continuity Management. http://www.standards.co.nz 
ISO/IEC_27002:2013 Information Technology – Security Techniques – Code of Practice for  Information Security Controls

http://www.iso27001security.com/html/27002.html
http://www.standards.co.nz

ISO/IEC_27005:2011 Information Technology – Security Techniques - Information Security Risk Management

http://www.iso27001security.com/html/27005.html
http://www.standards.co.nz

ISO/IEC_27031:2011 Information Technology – Security Techniques - Guidelines for Information and Communication Technology readiness for Business Continuity

http://www.iso27001security.com/html/27005.html
http://www.standards.co.nz

PSR references

Rationale & Controls

6.4.5. Availability requirements

6.4.5.R.01.Rationale

Availability and recovery requirements will vary based on each agency’s business needs and are likely to be widely variable across government. Agencies will determine their own availability and recovery requirements and implement appropriate measures to achieve them as part of their risk management and governance processes.

6.4.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1120]

Agencies MUST determine availability and recovery requirements for their systems and implement appropriate measures to support them.

6.4.6. Backup strategy

6.4.6.R.01.Rationale

Having a backup strategy in place is a fundamental part of business continuity planning. The backup strategy ensures that critical business information is recoverable if lost. Vital records are defined as any information, systems data, configurations or equipment requirements necessary to restore normal operations.

6.4.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1123]

Agencies SHOULD:

  • Identify vital records;
  • backup all vital records;
  • store copies of critical information, with associated documented recovery procedures, offsite and secured in accordance with the requirements for the highest classification of the information; and
  • test backup and restoration processes regularly to confirm their effectiveness.

6.4.7. Business Continuity plan

6.4.7.R.01.Rationale

It is important to develop a business continuity plan to assist in ensuring that critical systems and data functions can be maintained when the system is operating under constraint, for example, when bandwidth is unexpectedly limited below established thresholds.

6.4.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1126]

Agencies SHOULD develop and document a business continuity plan.

6.4.8. Disaster recovery plan

6.4.8.R.01.Rationale

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

6.4.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1129]

Agencies SHOULD develop and document a disaster recovery plan.

7. Information Security Incidents

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

7.1. Detecting Information Security Incidents

Objective

7.1.1.

To ensure that appropriate tools, processes and procedures are implemented to detect information security incidents, to minimise impact and as part of the suite of good IT governance activities.

Context

Scope

7.1.2.

This section covers information relating to detecting information security incidents. Detecting physical and personnel security incidents is out of scope of this section, refer to Chapter 8 - Physical Security and Chapter 9 - Personnel Security.

7.1.3.

Additional information relating to detecting information security incidents, and topics covered in this section, can be found in the following sections of this manual:

PSR references

Rationale & Controls

7.1.5. Preventing and detecting information security incidents

7.1.5.R.01.Rationale

Processes for the detection of information security incidents will assist in mitigating the most common vectors used to attack and exploit systems.

7.1.5.R.02.Rationale

Many potential information security incidents are noticed by personnel rather than automated or other software tools. Personnel should be well trained and aware of information security issues and indicators of possible information security incidents.

7.1.5.R.03.Rationale

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

 

Tool Description
Network and host Intrusion Detection Systems (IDSs) Monitor and analyse network and host activity, usually relying on a list of known attack signatures to recognise/detect malicious activity and potential information security incidents.
Anomaly detection systems Monitor network and host activities that do not conform to normal system activity.
Intrusion Prevention Systems (IPS) and Host Based Intrusion Prevention Systems (HIPS) Some IDSs are combined with functionality to counter detected attacks or anomalous activity (IDS/IPS).  
System integrity verification and integrity checking 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 attack on the system and inadvertent system changes that render the system open to attack.
Log analysis Involves collecting and analysing event logs using pattern recognition to detect anomalous activities.
White Listing Lists the authorised activities and applications and permits their usage.
Black Listing Lists the non-authorised activities and applications and prevents their usage.
Data Loss Prevention (DLP) Data Egress monitoring and control.
7.1.5.R.04.Rationale

Automated tools are only as good as the level of analysis they perform. If tools are not configured to assess all areas of potential security risk then some vulnerabilities will not be detected. In addition, if tools are not regularly updated, including updates for new vulnerabilities and attack methods, their effectiveness will be reduced.

7.1.5.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:1153]

Agencies MUST develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:

  • counter-measures against malicious code;
  • intrusion detection strategies;
  • data egress monitoring & control;
  • access control anomalies;
  • audit analysis;
  • system integrity checking; and
  • vulnerability assessments.
7.1.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1154]

Agencies SHOULD develop, implement and maintain tools and procedures covering the detection of potential information security incidents, incorporating:

  • counter-measures against malicious code;
  • intrusion detection strategies;
  • data egress monitoring & control;
  • access control anomalies;
  • audit analysis;
  • system integrity checking; and
  • vulnerability assessments.
7.1.5.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1155]

Agencies SHOULD use the results of the security risk assessment to determine the appropriate balance of resources allocated to prevention versus detection of information security incidents.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

7.2. Reporting Information Security Incidents

Objective

7.2.1.

Reporting information security incidents, assists in maintaining an accurate threat environment picture for government systems, particularly All-of-Government or multi-agency systems.

Context

Scope

7.2.2.

This section covers information relating specifically to the reporting of information security incidents. It does not cover the reporting of physical or personnel security incidents.

Information security incidents and outsourcing

7.2.3.

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

Categories of information security incidents

7.2.4.

The security threat and intelligence landscape continues to evolve driven by more advanced, capable, well -resourced and motivated adversaries. To assist in managing this threat a standardized form of threat information exchange is essential.

7.2.5.

Incident categories, incident types and resolution types were previously defined in the Incident Object Description Exchange Format (IODEF) standard. IODEF was an e-GIF standard.

7.2.6.

IODEF has been superseded by a group of protocols designed to automate and structure operational cybersecurity information sharing techniques on a global basis. International in scope and free for public use, TAXII, STIX and CybOX are community-driven technical specifications designed to enable automated information sharing for cybersecurity situational awareness, real-time network defense and sophisticated threat analysis. These protocols are:

  • TAXII™, the Trusted Automated eXchange of Indicator Information;
  • STIX™, the Structured Threat Information eXpression; and
  • CybOX™, the Cyber Observable eXpression.
7.2.7.

TAXII defines a set of services and message exchanges that enable sharing of actionable cyber threat information. It is not an information sharing programme itself and does not define trust agreements, governance, or other non-technical aspects of collaboration. It does allow organisations to share the information they choose with the partners they choose.

7.2.8.

STIX is a standardised, structured language to represent cyber threat information, covering the full range of potential cyber threat data elements. It is designed to be flexible, extensible, automatable, and human-readable.

7.2.9.

CybOX is a standardised schema for the specification, capture, characterisation, and communication of events in system and network operations providing a common structure and content types to improve consistency and interoperability. A wide variety of cybersecurity use cases rely on such information including event management/logging, malware characterisation, intrusion detection/prevention, incident response, and digital forensics.

7.2.10.

New Zealand’s National Cyber Security Centre has adopted this suite of protocols as the basis for incident reports to the NCSC and for reports issued by the NCSC.

References

7.2.11.

Additional information relating to information security incidents can be found at:

Title Publisher Source

The Incident Object Description Exchange Format, RFC 5070, December 2007

The Internet Engineering Taskforce (IETF)

http://www.ietf.org/rfc/rfc5070.txt

Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry, ISSN: 2070-1721, RFC 6685, July 2012

IETF http://tools.ietf.org/html/rfc6685

Detect, SHARE, Protect Solutions for Improving Threat Data Exchange among CERTs, October 2013

ENISA http://www.enisa.europa.eu/activities/cert/support/data-sharing/detect-share-protect-solutions-for-improving-threat-data-exchange-among-certs
Computer Security Incident Handling Guide, Special Publication 800-61:  Revision 2, August 2012  NIST http://dx.doi.org/10.6028/NIST.SP.800-61r2

NIST Special Publication 800-60 Volume l Revision 1, Guide for Mapping Types of Information and Information Systems to Security Categories

NIST

http://www.csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf

NIST Special Publication 800-60 Volume ll Revision 1, Guide for Mapping Types of Information and Information Systems to Security Categories, Volume ll: Appendices

NIST http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf

The National Cyber Security Centre Voluntary Cyber Security Standards for Industrial Control Systems v1.0

GCSB NCSC

http://www.gcsb.govt.nz/assets/GCSB-Documents/NCSC-voluntary-cyber-security-standards-for-ICD-v.1.0.pdf

http://www.ncsc.govt.nz/resources/

The New Zealand Security Incident Management Guide for Computer Security Incident Response Teams (CIRSTs)

NCSC https://www.ncsc.govt.nz/resources/

Information Sharing Specifications for Cybersecurity

DHS https://www.us-cert.gov/Information-Sharing-Specifications-Cybersecurity

Rationale & Controls

7.2.12. Reporting information security incidents

7.2.12.R.01.Rationale

Reporting information security incidents provides management with a means to assess and minimise damage to a system and to take remedial actions. Incidents should be reported to an ITSM, as soon as possible. The ITSM may seek advice from GCSB as required.

7.2.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1203]

Agencies MUST direct personnel to report information security incidents to an ITSM as soon as possible after the information security incident is discovered in accordance with agency procedures.

7.2.12.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1205]

Agencies SHOULD:

  • encourage personnel to note and report any observed or suspected security weaknesses in, or threats to, systems or services;
  • establish and follow procedures for reporting software malfunctions;
  • put mechanisms in place to enable the types, volumes and costs of information security incidents and malfunctions to be quantified and monitored; and
  • deal with the violation of agency information security policies and procedures by personnel through a formal disciplinary process.

7.2.13. Responsibilities when reporting an information security incident

7.2.13.R.01.Rationale

The CISO is required to keep the CSO and/or Agency Head informed of information security incidents within their agency. The ITSM actively manages information security incidents and MUST ensure the CISO has sufficient awareness of and information on any information security incidents within an agency.

7.2.13.R.02.Rationale

Reporting on low-level incidents can be adequately managed through periodic (at least monthly) reports. Serious incidents will require more immediate attention.

7.2.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1211]

The ITSM MUST keep the CISO fully informed of information security incidents within an agency.

7.2.14. Reporting significant information security incidents to National Cyber Security Centre (NCSC)

7.2.14.R.01.Rationale

The NCSC uses significant information security incident reports as the basis for identifying and responding to information security events across government. Reports are also used to develop new policy, procedures, techniques and training measures to prevent the recurrence of similar information security incidents across government.

7.2.14.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1216]

The Agency ITSM, MUST report significant information security incidents, or incidents related to multi-agency or government systems, to the NCSC (see below).

7.2.15. Reporting non-significant information security incidents to National Cyber Security Centre (NCSC)

7.2.15.R.01.Rationale

The NCSC uses non-significant information security incident reports as the basis for identifying trends in information security incident occurrences and for developing new policy, procedures, techniques and training measures to prevent the recurrence of similar information security incidents across government.

7.2.15.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1220]

Agencies SHOULD, through an ITSM, report non-significant information security incidents to the NCSC.

7.2.16. How to report information security incidents to National Cyber Security Centre (NCSC)

7.2.16.R.01.Rationale

Reporting of information security incidents to the NCSC through the appropriate channels ensures that appropriate and timely assistance can be provided to the agency. In addition, it allows the NCSC to maintain an accurate threat environment picture for government systems.

7.2.16.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1223]

Agencies SHOULD formally report information security incidents using the NCSC adoption of the TAXII, STIX and CyBox protocols.

7.2.17. Outsourcing and information security incidents

7.2.17.R.01.Rationale

In the case of outsourcing of information technology services and functions, the agency is still responsible for the reporting of all information security incidents. As such, the agency MUST ensure that the service provider informs them of all information security incidents to allow them to formally report these to the NCSC.

7.2.17.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1226]

Agencies that outsource their information technology services and functions MUST ensure that the service provider consults with the agency when an information security incident occurs.

7.2.18. Cryptographic keying material

7.2.18.R.01.Rationale

Reporting any information security incident involving the loss or misuse of cryptographic keying material is particularly important. Systems users in this situation are those that rely on the use of cryptographic keying material for the confidentiality and integrity of their secure communications.

7.2.18.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1233]

Agencies MUST notify all system users of any suspected loss or compromise of keying material.

7.2.19. High Grade Cryptographic Equipment (HGCE) keying material

7.2.19.R.01.Rationale

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

7.2.19.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1237]

Agencies MUST notify GCSB of any suspected loss or compromise of keying material associated with HGCE.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

7.3. Managing Information Security Incidents

Objective

7.3.1.

To identify and implement processes for incident analysis and selection of appropriate remedies which will assist in preventing future information security incidents.

Context

Scope

7.3.2.

This section covers information relating primarily to managing information security incidents. The management of physical and personnel security incidents is considered to be out of scope unless it directly impacts on the protection of systems (e.g. the breaching of physical protection for a server room).

References

7.3.3.

Additional information relating to the management of ICT evidence is contained in:

Reference Title Source

ISO/IEC_27037

Information Technology – Security Techniques – Guidelines for identification, collection, acquisition and preservation of digital evidence.

http://www.iso27001security.com/html/27037.html

http://www.standards.co.nz/

HB 171:2003

Guidelines for the Management of Information Technology Evidence

http://www.standards.co.nz/
 

The New Zealand Security Incident Management Guide for Computer Security Incident Response Teams (CIRSTs)

http://www.ncsc.govt.nz/resources/

Rationale & Controls

7.3.4. Information security incident management documentation

7.3.4.R.01.Rationale

Ensuring responsibilities and procedures for information security incidents are documented in relevant Information Security Documentation will ensure that when a information security incident does occur, agency personnel can respond in an appropriate manner. In addition, ensuring that system users are aware of reporting procedures will assist in identifying any information security incidents that an ITSM, or system owner fail to notice.

7.3.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1260]

Agencies MUST detail information security incident responsibilities and procedures for each system in the relevant Information Security Documents.

7.3.5. Recording information security incidents

7.3.5.R.01.Rationale

The purpose of recording information security incidents is to highlight the nature and frequency of information security incidents so that corrective action can be taken. This information can subsequently be used as an input to security risk assessments of systems.

7.3.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1263]

Agencies MUST follow the NZ implementation of the STIXX / TAXII and CyBox protocols and SHOULD include the following information in their register:

  • the date the information security incident was discovered;
  • the date the information security incident occurred;
  • a description of the information security incident, including the personnel, systems and locations involved;
  • the action taken;
  • to whom the information security incident was reported; and
  • the file reference.
7.3.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1264]

Agencies SHOULD ensure that all information security incidents are recorded in a register.

7.3.5.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1266]

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

7.3.6. Handling data spills

7.3.6.R.01.Rationale

A data spill is defined as the unauthorised or unintentional release, transmission or transfer of data. If there is a possibility that classified information may be compromised as a result of an information security incident, agencies MUST be able to respond in a timely fashion to limit damage and contain the incident.

7.3.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1271]

Agencies MUST implement procedures and processes to detect data spills.

7.3.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1273]

When a data spill occurs agencies MUST assume that data at the highest classification held on or processed by the system, has been compromised.

7.3.6.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1274]

Agency SOPs MUST include procedure for:

  • all personnel with access to systems; 
  • notification to the ITSM of any data spillage; and
  • notification to the ITSM of access to any data which they are not authorised to access.
7.3.6.C.04.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1275]

Agencies MUST document procedures for dealing with data spills in their IRP.

7.3.6.C.05.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1276]

Agencies MUST treat any data spill as an information security incident and follow the IRP to deal with it.

7.3.6.C.06.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1277]

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

7.3.7. Containing data spills

7.3.7.R.01.Rationale

The spillage of classified information onto a system not accredited to handle the information is considered a significant information security incident.

7.3.7.R.02.Rationale

Isolation may include disconnection from other systems and any external connections. In some cases system isolation may not be possible for architectural or operational reasons.

7.3.7.R.03.Rationale

Segregation may be achieved by isolation, enforcing separation of key elements of a virtual system, removing network connectivity to the relevant device or applying access controls to prevent or limit access.

7.3.7.R.04.Rationale

It is important to note that powering off a system can destroy information that may be useful in forensics analysis or other investigative work.

7.3.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1283]

When classified information is introduced onto a system not accredited to handle the information, the following actions MUST be followed:

  1. Immediately seek the advice of an ITSM;
  2. Segregate or isolate the affected system and/or data spill;
  3. Personnel MUST NOT delete the higher classified information unless specifically authorised by an ITSM.
7.3.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1284]

When classified information is introduced onto a system not accredited to handle the information, personnel MUST NOT copy, view, print or email the information.

7.3.7.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1285]

When a data spill occurs and systems cannot be segregated or isolated agencies SHOULD immediately contact the GCSB for further advice.

7.3.8. Handling malicious code infection

7.3.8.R.01.Rationale

The guidance for handling malicious code infections is provided to assist in preventing the spread of the infection and to prevent reinfection. Important details include:

  • the infection date of the machine;
  • the possibility that system records and logs could be compromised; and
  • the period of infection.
7.3.8.R.02.Rationale

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

7.3.8.R.03.Rationale

Agencies SHOULD be aware that some malicious code infections may be categorised as Advanced Persistent Threats (APTs) which may have been present for some time before detection. Specialist assistance may be required to deal with APTs.

7.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1290]

Agencies SHOULD follow the steps described below when malicious code is detected:

  • isolate the infected system;
  • decide whether to request assistance from GCSB;
  • if such assistance is requested and agreed to, delay any further action until advised by GCSB;
  • scan all previously connected systems and any media used within a set period leading up to the information security incident, for malicious code;
  • isolate all infected systems and media to prevent reinfection;
  • change all passwords and key material stored or potentially accessed from compromised systems, including any websites with password controlled access;
  • advise system users of any relevant aspects of the compromise, including a recommendation to change all passwords on compromised systems;
  • use up-to-date anti-malware software to remove the malware from the systems or media;
  • monitor network traffic for malicious activity; 
  • report the information security incident and perform any other activities specified in the IRP; and
  • in the worst case scenario, rebuild and reinitialise the system.

7.3.9. Allowing continued attacks

7.3.9.R.01.Rationale

Agencies allowing an attacker to continue an attack against a system in order to seek further information or evidence will need to establish with their legal advisor(s) whether the actions are breaching the Telecommunications (Interception Capability and Security) Act 2013.

7.3.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1294]

Agencies considering allowing an attacker to continue some actions under controlled conditions for the purpose of seeking further information or evidence SHOULD seek legal advice.

7.3.10. Integrity of evidence

7.3.10.R.01.Rationale

While gathering evidence it is important to maintain the integrity of the information and the chain of evidence. 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.

7.3.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1297]

Agencies SHOULD:

  • transfer a copy of raw audit trails and other relevant data onto media for secure archiving, as well as securing manual log records for retention; and
  • ensure that all personnel involved in the investigation maintain a record of actions undertaken to support the investigation.

7.3.11. Seeking assistance

7.3.11.R.01.Rationale

If the integrity of evidence relating to an information security incident is compromised, it reduces GCSB’s ability to assist agencies. As such, GCSB requests that no actions which could affect the integrity of the evidence are carried out prior to GCSB’s involvement.

7.3.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1300]

Agencies SHOULD ensure that any requests for GCSB assistance are made as soon as possible after the information security incident is detected and that no actions which could affect the integrity of the evidence are carried out prior to GCSB’s involvement.

8. Physical Security

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

8.1. Facilities

Objective

8.1.1.

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

Context

Scope

8.1.2.

This section covers information on the physical security of facilities. Information on physical security controls for servers and network devices, network infrastructure and IT equipment can be found in the following sections of this chapter.

Physical security requirements for storing classified information

8.1.3.

Many of the physical controls in this manual are derived from the management protocol for physical security within the Protective Security Requirements (PSR). In particular from the minimum standard for security containers, secure rooms or lockable commercial cabinets needed for storing classified information.

Secure and unsecure areas

8.1.4.

In the context of this manual a secure area may be a single room or a facility that has security measures in place for the processing of classified information, or may encompass an entire building.

Physical security certification authorities

8.1.5.

The certification of an agency’s physical security measures is an essential part of the certification and accreditation process. The authority and responsibility are listed in the table below:

Classification Authority Responsibility
SECRET CSO Physical
TOP SECRET NZSIS Physical
TOP SECRET SCIF GCSB

Network Infrastructure

Technical Security

Surveillance Counter Measures

8.1.6.

Top Secret (TS) physical certification should be completed before any Technical inspections and certifications occur.

Facilities located outside of New Zealand

8.1.7.

Agencies operating sites located outside of New Zealand can contact GCSB to determine any additional requirements which may exist such as technical surveillance and oversight counter-measures and testing.

References

8.1.8.

High-level information relating to physical security is also contained in:

Title Publisher Source

ISO/IEC 27002:2013, Section 11 - Physical and Environmental Security

ISO /IEC

Standards NZ

http://www.iso27001security.com/html/27002.html

http://www.standards.co.nz/

PSR references

8.1.9.

Relevant PSR requirements can be found at:

Reference

Title

Source

PSR Mandatory Requirements

GOV2, GOV6, GOV7, INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1, PHYSEC2, PHYSEC3 and PHYSEC4

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/

https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

PSR content protocols 

Management protocol for information security

Management protocol for physical security

https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

PSR requirements sections

Creating a security culture

Understand the physical security lifecycle

https://www.protectivesecurity.govt.nz/physical-security/creating-a-security-culture/

https://www.protectivesecurity.govt.nz/physical-security/understand-the-physical-security-lifecycle/ 

Managing specific scenarios

Secure your ICT facilities

Physical Security for ICT systems

Mobile and remote working

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/mobile-and-remote-working/

Rationale & Controls

8.1.10. Facility physical security

8.1.10.R.01.Rationale

The application of defence-in-depth to the protection of systems and infrastructure is enhanced through the use of successive layers of physical security.

Typically the layers of security are:

  • site;
  • building;
  • room;
  • racks;
  • approved containers;
  • operational hours; and
  • manning levels.
8.1.10.R.02.Rationale

All layers are designed to control and limit access to those with the appropriate authorisation for the site, infrastructure and system. Deployable platforms need to meet physical security certification requirements as with any other system. Physical security certification authorities dealing with deployable platforms may 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.

8.1.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1323]

Agencies MUST ensure that any facility containing a system or its associated infrastructure, including deployable systems, are certified and accredited in accordance with the PSR.

8.1.11. Preventing observation by unauthorised people

8.1.11.R.01.Rationale

Agency facilities without sufficient perimeter security are often exposed to the potential for observation through windows or open doors. This is sometimes described as the risk of oversight. Ensuring classified information on desks and computer screens is not visible will assist in reducing this security risk.

8.1.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1326]

Agencies SHOULD prevent unauthorised people from observing systems, in particular desks, screens and keyboards.

8.1.11.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1327]

Agencies SHOULD position desks, screens and keyboards so that they cannot be seen by unauthorised people, or fix blinds or drapes to the inside of windows and away from doorways.

8.1.12. Bringing non-agency owned devices into secure areas

8.1.12.R.01.Rationale

No non-agency owned devices are to be brought into TOP SECRET areas without their prior approval of the Accreditation Authority.

8.1.12.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST NOT [CID:1330]

Agencies MUST NOT permit non-agency owned devices to be brought into TOP SECRET areas without prior approval from the Accreditation Authority.

8.1.13. Technical Inspection and surveillance counter-measure testing

8.1.13.R.01.Rationale

Technical surveillance counter-measure testing is conducted as part of the physical security certification to ensure that facilities do not have any unauthorised listening devices or other surveillance devices installed and that physical security measures are compatible with technical controls. This testing and inspection will normally occur AFTER the physical site accreditation has been completed (in accordance with the PSR). Further testing may also be necessary after uncleared access to the secure facility, such as contractors or visitors.

8.1.13.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:1333]

Agencies MUST ensure that technical surveillance counter-measure tests are conducted as a part of the physical security certification.

8.1.13.C.02.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:1334]

Agencies MUST determine if further technical surveillance counter-measure testing is required, particularly if visitors or contractors have entered secure areas.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

8.2. Servers And Network Devices

Objective

8.2.1.

Secured server and communications rooms provide appropriate physical security for servers and network devices.

Context

Scope

8.2.2.

This section covers the physical security of servers and network devices. Information relating to network infrastructure and IT equipment can be found in other sections of this chapter.

Secured server and communications rooms

8.2.3.

In order to reduce storage physical security requirements for information systems infrastructure, other network devices and servers, agencies may choose to certify and accredit the physical security of the site or IT equipment room to the standard specified in the PSR. This has the effect of providing an additional layer of physical security.

8.2.4.

Agencies choosing NOT to certify and accredit the physical security of the site or IT equipment room, must continue to meet the full storage requirements specified in the PSR.

Rationale & Controls

8.2.5. Securing servers and network devices

8.2.5.R.01.Rationale

Security containers for IT infrastructure, network devices or servers situated in an unsecure area must be compliant with the requirements of the PSR. Installing IT infrastructure, network devices or servers in a secure facility can lower the storage requirements, provided multiple layers of physical security have been implemented, certified and accredited.

8.2.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1349]

Agencies MUST ensure that servers and network devices are secured within cabinets as outlined in PSR Management protocol for physical security, with supporting document – Storage requirements for electronic information in ICT facilities.

8.2.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1350]

Agencies SHOULD use a secured server or communications room within a secured facility.

8.2.6. Securing server rooms, communications rooms and security containers

8.2.6.R.01.Rationale

If personnel decide to leave server rooms, communications rooms or security containers with keys in locks, unlocked or with security functions disabled it negates the purpose of providing security in the first place. Such activities will compromise the security efforts of the agencies and should not be permitted by the agency.

8.2.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1353]

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

8.2.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1354]

Agencies MUST NOT leave server rooms, communications rooms or security containers in an unsecured state unless the server room is occupied by authorised personnel.

8.2.7. Administrative measures

8.2.7.R.01.Rationale

Site security plans (SitePlan), the physical security equivalent of the SecPlan and SOPs for systems, are used to document all aspects of physical security for systems. Formally documenting this information ensures that standards, controls and procedures can easily be reviewed by security personnel.

8.2.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1357]

Agencies MUST develop a Site Security Plan (SitePlan) for each server and communications room. Information to be covered includes, but is not limited to:

  • a summary of the security risk review for the facility the server or communications room is located in;
  • roles and responsibilities of facility and security personnel;
  • the administration, operation and maintenance of the electronic access control system or security alarm system;
  • key management, the enrolment and removal of system users and issuing of personal identification number codes and passwords;
  • personnel security clearances, security awareness training and regular briefings;
  • regular inspection of the generated audit trails and logs;
  • end of day checks and lockup;
  • reporting of information security incidents; and
  • what activities to undertake in response to security alarms.

8.2.8. No-lone-zones

8.2.8.R.01.Rationale

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

8.2.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1360]

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

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

8.3. Network Infrastructure

Objective

8.3.1.

Network infrastructure is protected by secure facilities and the use of encryption technologies.

Context

Scope

8.3.2.

This section covers information relating to the physical security of network infrastructure. Information relating to servers, network devices and IT equipment can be found in other sections of this chapter. Additionally, information on using encryption for infrastructure in unsecure areas can be found in Section 17.1 - Cryptographic Fundamentals.

Rationale & Controls

8.3.3. Network infrastructure in secure areas

8.3.3.R.01.Rationale

Network infrastructure is considered to process information being communicated across it and as such needs to meet the minimum physical security requirements for processing classified information as specified in the PSR Management protocol for physical security, with supporting document – Storage requirements for electronic information in ICT facilities.

8.3.3.R.02.Rationale

The physical security requirements for network infrastructure can be lowered if encryption is being applied to classified information communicated over the infrastructure (i.e. data in transit encryption). Note this does NOT change the classification of the data itself, only the physical protection requirements.

8.3.3.R.03.Rationale

It is important to note that physical controls do not provide any protection against malicious software or other malicious entities that may be residing on or have access to the system.

8.3.3.R.04.Rationale

If classified information being communicated over the infrastructure is not encrypted the malicious entry can capture, corrupt or modify the traffic to assist in furthering any attempts to exploit the network and the information being communicated across it.

8.3.3.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1373]

Agencies MUST certify the physical security of facilities containing network infrastructure to the highest classification of information being communicated over the network infrastructure.

8.3.3.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1374]

Agencies communicating classified information over infrastructure in secure areas SHOULD encrypt their information with at least an Approved Cryptographic Protocol. See Section 17.3 – Approved Cryptographic Protocols.

8.3.4. Protecting network infrastructure

8.3.4.R.01.Rationale

In order to prevent tampering with patch panels, fibre distribution panels and structured wiring, any such enclosures need to be placed within at least lockable commercial cabinets. Furthermore, keys for such cabinets should not be remain in locks as this defeats the purpose of using lockable commercial cabinets in the first place.

8.3.4.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1377]

Agencies MUST locate patch panels, fibre distribution panels and structured wiring enclosures within at least lockable commercial cabinets.

8.3.4.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1378]

Agencies SHOULD locate patch panels, fibre distribution panels and structured wiring enclosures within at least lockable commercial cabinets.

8.3.5. Network infrastructure in unsecure areas

8.3.5.R.01.Rationale

As agencies lose control over classified information when it is communicated over unsecure public network infrastructure or over infrastructure in unsecure areas they MUST ensure that it is encrypted to a sufficient level that if it was captured that it would be sufficiently difficult to determine the original information from the encrypted information.

8.3.5.R.02.Rationale

Encryption does not change the class level of the information itself but allows reduced handling requirements to be applied.

8.3.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1382]

Agencies communicating classified information over public network infrastructure or over infrastructure in unsecure areas MUST use encryption to lower the handling instructions to be equivalent to those for unclassified networks.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

8.4. IT Equipment

Objective

8.4.1.

IT equipment is secured outside of normal working hours, is non-operational or when work areas are unoccupied.

Context

Scope

8.4.2.

This section covers information relating to the physical security of IT equipment containing media. This includes but is not limited to workstations, printers, photocopiers, scanners and multi-function devices (MFDs).

8.4.3.

Additional information relating to IT equipment and media can be found in the following chapters and sections of this manual:

Handling IT equipment containing media

8.4.4.

During non-operational hours agencies need to store media containing classified information that resides within IT equipment in accordance with the requirements of the PSR. Agencies can comply with this requirement by undertaking one of the following processes:

  • ensuring IT equipment always reside in an appropriate class of secure room;
  • storing IT equipment during non-operational hours in an appropriate class of security container or lockable commercial cabinet;
  • using IT equipment with removable non-volatile media which is stored during non-operational hours in an appropriate class of security container or lockable commercial cabinet as well as securing its volatile media;
  • using IT equipment without non-volatile media as well as securing its volatile media;
  • using an encryption product to reduce the physical storage requirements of the non-volatile media as well as securing its volatile media; or
  • configuring IT equipment to prevent the storage of classified information on the non-volatile media when in use and enforcing scrubbing of temporary data at logoff or shutdown as well as securing its volatile media.
8.4.5.

The intent of using cryptography or preventing the storage of classified information on non-volatile media is to enable agencies to treat the media within IT equipment in accordance with the storage requirements of a lower classification, as specified in the PSR, during non-operational hours. Temporary data should be deleted at log off or shut down and volatile media secured.

8.4.6.

As the process of using cryptography and preventing the storage of classified information on non-volatile media does not constitute the sanitisation and reclassification of the media, the media retains its classification for the purposes of reuse, reclassification, declassification, sanitisation, destruction and disposal requirements as specified in this manual.

IT equipment using hybrid hard drives or solid state drives

8.4.7.

The process of preventing the storage of classified information on non-volatile media, and enforcing deletion of temporary data at logoff or shutdown, is NOT approved as a method of lowering the storage requirements, when hybrid hard drives or solid state drives are used.

Rationale & Controls

8.4.8. Accounting for IT equipment

8.4.8.R.01.Rationale

Ensuring that IT equipment containing media is accounted for by using asset registers, equipment registers, operational & configuration records and regular audits will assist in preventing loss or theft, or in the cases of loss or theft, alerting appropriate authorities to its loss or theft.

8.4.8.R.02.Rationale

Asset registers may not provide a complete record as financial limits may result in smaller value items not being recorded. In such cases other registers and operational information can be utilised to assist in building a more complete record.

8.4.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1400]

Agencies MUST account for all IT equipment containing media.

8.4.9. Processing requirements

8.4.9.R.01.Rationale

As the media within IT equipment takes on the classification of the information it is processing, the area that it is used within needs to be certified to a level that is appropriate for the classification of that information.

8.4.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1407]

Agencies MUST certify the physical security of facilities containing IT equipment to the highest classification of information being processed, stored or communicated by the equipment within the facilities.

8.4.10. Storage requirements

8.4.10.R.01.Rationale

The PSR states that either Class C, B or A secure rooms or Class C, B or A security containers or lockable commercial cabinets can be used to meet physical security requirements for the storage of IT equipment containing media. The class of secure room or security container will depend on the physical security certification of the surrounding area and the classification of the information.

8.4.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1403]

Agencies MUST ensure that when secure areas are non-operational or when work areas are unoccupied IT equipment with media is secured in accordance with the minimum physical security requirements for storing classified information as specified in the PSR Management protocol for physical security – Physical Security of your ICT assets and facilities, with supporting document – Storage requirements for electronic information in ICT facilities.

8.4.11. Securing non-volatile media for storage

8.4.11.R.01.Rationale

The use of techniques to prevent the storage of classified information on non-volatile media and processes to delete temporary data at logoff or shutdown may sound secure but there is no guarantee that they will always work effectively or will not be bypassed in unexpected circumstances such as a loss of power. As such, agencies need to consider these risks when implementing such a solution.

8.4.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1409]

Agencies choosing to prevent the storage of classified information on non-volatile media and enforcing scrubbing of temporary data at logoff or shutdown SHOULD:

  • assess the security risks associated with such a decision; and
  • specify the processes and conditions for their application within the system’s SecPlan.

 

8.4.12. Securing volatile media for storage

8.4.12.R.01.Rationale

If agencies need to conduct a security risk assessment as part of the procedure for storing IT equipment containing media during non-operation hours, they should consider security risks such as:

  • an attacker gaining access to the IT equipment immediately after power is removed and accessing the contents of volatile media to recover encryption keys or parts thereof. This is sometimes described as a data remanence attack;
  • extreme environmental conditions causing data to remain in volatile media for extended periods after the removal of power; and
  • the physical security of the locations in which the IT equipment will reside.
8.4.12.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1412]

Agencies securing volatile media for IT equipment during non-operational hours SHOULD:

  • disconnect power from the equipment the media resides within;
  • assess the security risks if not sanitising the media; and
  • specify any additional processes and controls that will be applied within the system’s SecPlan.

8.4.13. Encrypting media within IT equipment

8.4.13.R.01.Rationale

Current industry good practice is to encrypt all media within IT equipment. Newer operating systems provide this functionality and older operating systems can be supported with the use of open source or proprietary applications.

8.4.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1415]

Agencies SHOULD encrypt media within IT equipment with an Approved Cryptographic Algorithm. See Section 17.2 - Approved Cryptographic Algorithms.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

8.5. Tamper Evident Seals

Objective

8.5.1.

Tamper evident seals and associated auditing processes identify attempts to bypass the physical security of systems and their infrastructure.

Context

Scope

8.5.2.

This section covers information on tamper evident seals that can be applied to assets.

Rationale & Controls

8.5.3. Recording seal usage

8.5.3.R.01.Rationale

Recording information about seals in a register and on which asset they are used assists in reducing the security risk that seals could be substituted without security personnel being aware of the change.

8.5.3.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1425]

Agencies MUST record the usage of seals in a register that is appropriately secured.

8.5.3.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1426]

Agencies MUST record in a register, information on:

  • issue and usage details of seals and associated tools;
  • serial numbers of all seals purchased; and
  • the location or asset on which each seal is used.
8.5.3.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1427]

Agencies SHOULD record the usage of seals in a register that is appropriately secured.

8.5.3.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1428]

Agencies SHOULD record in a register information on:

  • issue and usage details of seals and associated tools;
  • serial numbers of all seals purchased; and
  • the location or asset on which each seal is used.

8.5.4. Purchasing seals

8.5.4.R.01.Rationale

Using uniquely numbered seals ensures that a seal can be uniquely mapped to an asset. This assists security personnel in reducing the security risk that seals could be replaced without anyone being aware of the change.

8.5.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1431]

Agencies SHOULD consult with the seal manufacturer to ensure that, if available, any purchased seals and sealing tools display a unique identifier or image appropriate to the agency.

8.5.4.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1432]

Seals and any seal application tools SHOULD be secured when not in use.

8.5.4.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:1433]

Agencies SHOULD NOT allow contractors to independently purchase seals and associated tools on behalf of the government.

8.5.5. Reviewing seal usage

8.5.5.R.01.Rationale

Users of assets with seals should be encouraged to randomly check the integrity of the seals and to report any concerns to security personnel. In addition, conducting at least annual reviews will allow for detection of any tampering to an asset and ensure that the correct seal is located on the correct asset.

8.5.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1436]

Agencies SHOULD review seals for differences with a register at least annually. At the same time seals SHOULD be examined for any evidence of tampering.

9. Personnel Security

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

9.1. Information Security Awareness and Training

Objective

9.1.1.

A security culture is fostered through induction training and ongoing security education tailored to roles, responsibilities, changing threat environment and sensitivity of information, systems and operations.

Context

Scope

9.1.2.

This section covers information relating specifically to information security awareness and training.

PSR references

Rationale & Controls

9.1.4. Information security awareness and training responsibility

9.1.4.R.01.Rationale

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

9.1.4.R.02.Rationale

Awareness and knowledge degrades over time without ongoing refresher training and updates. Providing ongoing information security awareness and training will assist in keeping personnel aware of issues and their responsibilities.

9.1.4.R.03.Rationale

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

9.1.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1449]

Agency management MUST ensure that all personnel who have access to a system have sufficient information security awareness and training.

9.1.5. Information security awareness and training

9.1.5.R.01.Rationale

Information security awareness and training programs are designed to help system users:

  • become familiar with their roles and responsibilities;
  • understand any legislative or regulatory mandates and requirements;
  • understand any national or agency policy mandates and requirements;
  • understand and support security requirements; 
  • assist in maintaining security; and
  • learn how to fulfil their security responsibilities.
9.1.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1452]

Agencies MUST provide ongoing information security awareness and training for personnel on topics such as responsibilities, legislation and regulation, consequences of non-compliance with information security policies and procedures, and potential security risks and counter-measures.

9.1.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1453]

Agencies MUST provide information security awareness training as part of their employee induction programmes.

9.1.6. Degree and content of information security awareness and training

9.1.6.R.01.Rationale

The detail, content and coverage of information security awareness and training will depend on the objectives of the organisation. Personnel with responsibilities beyond that of a general user should have tailored training to meet their needs.

9.1.6.R.02.Rationale

As part of the guidance provided to system users, there should be sufficient emphasis placed on the activities that are NOT allowed on systems. The minimum list of content will also ensure that personnel are sufficiently exposed to issues that could cause an information security incident through lack of awareness or through lack of knowledge.

9.1.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1457]

Agencies SHOULD align the detail, content and coverage of information security awareness and training to system user responsibilities.

9.1.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1458]

Agencies SHOULD ensure that information security awareness and training includes information on:

  • the purpose of the training or awareness program;
  • any legislative or regulatory mandates and requirements;
  • any national or agency policy mandates and requirements;
  • agency security appointments and contacts;
  • the legitimate use of system accounts, software and classified information;
  • the security of accounts, including shared passwords;
  • authorisation requirements for applications, databases and data;
  • the security risks associated with non-agency systems, particularly the Internet;
  • reporting any suspected compromises or anomalies;
  • reporting requirements for information security incidents, suspected compromises or anomalies;
  • classifying, marking, controlling, storing and sanitising media;
  • protecting workstations from unauthorised access;
  • informing the support section when access to a system is no longer needed; 
  • observing rules and regulations governing the secure operation and authorised use of systems; and
  • supporting documentation such as SOPs and user guides.
9.1.6.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1459]

Agencies SHOULD ensure that information security awareness and training includes advice to system users not to attempt to:

  • tamper with the system;
  • bypass, strain or test information security mechanisms;
  • introduce or use unauthorised IT equipment or software on a system;
  • replace items such as keyboards, pointing devices and other peripherals with personal equipment;
  • assume the roles and privileges of others;
  • attempt to gain access to classified information for which they have no authorisation; or
  • relocate equipment without proper authorisation.

9.1.7. System familiarisation training

9.1.7.R.01.Rationale

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

9.1.7.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1462]

Agencies MUST provide all system users with familiarisation training on the information security policies and procedures and the secure operation of the system before being granted unsupervised access to the system.

9.1.8. Disclosure of information while on courses

9.1.8.R.01.Rationale

Government personnel attending courses with non-government personnel may not be aware of the consequences of disclosing information relating to the security of their agency’s systems. Raising awareness of such consequences in personnel will assist in preventing disclosures that could lead to a targeted attack being launched against an agency’s systems.

9.1.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1465]

Agencies SHOULD advise personnel attending courses along with non-government personnel not to disclose any details that could be used to compromise agency security.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

9.2. Authorisations, Security Clearances And Briefings

Objective

9.2.1.

Only appropriately authorised, cleared and briefed personnel are allowed access to systems.

Context

Scope

9.2.2.

This section covers information relating to the authorisations, security clearances and briefings required by personnel to access systems. Information on the technical implementation of access controls for systems can be found in Section 16.2 - System Access.

Security clearances – New Zealand and foreign

9.2.3.

Where this manual refers to security clearances, the reference applies to a national security clearance granted by a New Zealand government agency. Foreign nationals may be granted a national security clearance if risks can be mitigated. Refer to PSR Personnel Security for more information. 

PSR References

9.2.4.

Additional policy and information on granting and maintaining security clearances can be found in:

Reference Title Source

PSR Mandatory Requirements

GOV4, INFOSEC1, PERSEC1, PERSEC2, PERSEC3, PERSEC4, PHYSEC1 and PHYSEC2

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/

https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

https://www.protectivesecurity.govt.nz/personnel-security/mandatory-requirements/

https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

PSR content protocols 

Management protocol for information security

Management protocol for personnel security

Management Protocol for physical security 

https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

https://www.protectivesecurity.govt.nz/personnel-security/management-protocol-for-personnel-security

https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

PSR requirements sections

Creating a security culture

Build security awareness

Security zones

Recruiting and managing national security clearance holders 

https://www.protectivesecurity.govt.nz/personnel-security/creating-a-security-culture/

https://www.protectivesecurity.govt.nz/governance/build-security-awareness/

https://www.protectivesecurity.govt.nz/security-zones/ 

https://www.protectivesecurity.govt.nz/personnel-security/national-security-clearances/recruiting-and-managing-national-security-and-clearance-holders/

Rationale & Controls

9.2.5. Documenting authorisations, security clearance and briefing requirements

9.2.5.R.01.Rationale

Ensuring that the requirements for access to a system are documented and agreed upon will assist in determining if system users have appropriate authorisations, security clearances and need-to-know to access the system.

9.2.5.R.02.Rationale

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

9.2.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1480]

Agencies MUST specify in the System Security Plan (SecPlan) any authorisations, security clearances and briefings necessary for system access.

9.2.6. Authorisation and system access

9.2.6.R.01.Rationale

Personnel seeking access to a system will need to have a genuine business requirement to access the system as verified by their supervisor or manager. Once a requirement to access a system is established, the system user should be given only the privileges that they need to undertake their duties. Providing all system users with privileged access when there is no such requirement can cause significant security vulnerabilities in a system.

9.2.6.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1483]

Agencies MUST:

  • limit system access on a need-to-know/need-to-access basis;
  • provide system users with the least amount of privileges needed to undertake their duties; and
  • have any requests for access to a system authorised by the supervisor or manager of the system user.
9.2.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1484]

Agencies MUST:

  • limit system access on a need-to-know/need-to-access basis;
  • provide system users with the least amount of privileges needed to undertake their duties; and
  • have any requests for access to a system authorised by the supervisor or manager of the system user.

9.2.7. Recording authorisation for personnel to access systems

9.2.7.R.01.Rationale

In many cases, the requirement to maintain a secure record of all personnel authorised to access a system, their user identification, who provided the authorisation and when the authorisation was granted, can be met by retaining a completed system account request form signed by the supervisor or manager of the system user.

9.2.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1487]

Agencies SHOULD:

  • maintain a secure record of:
    • all authorised system users;
    • their user identification;
    • why access is required;
    • role and privilege level,
    • who provided the authorisation to access the system;
    • when the authorisation was granted; and
  • maintain the record, for the life of the system or the length of employment whichever is the longer, to which access is granted.

9.2.8. Security clearance for system access

9.2.8.R.01.Rationale

Information classified as CONFIDENTIAL and above requires personnel to have been granted a formal security clearance before access is granted. Refer to the PSR Personnel Security Mandatory Requirements.

9.2.8.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:1490]

System users MUST NOT be granted access to systems or information classified CONFIDENTIAL or above unless vetting procedures have been completed and formal security clearance granted.

9.2.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1491]

All system users MUST:

  • hold a security clearance at least equal to the system classification; or
  • have been granted access in accordance with the requirements in the PSR for emergency access.

9.2.9. System access briefings

9.2.9.R.01.Rationale

Some systems process endorsed or compartmented information. As such, unique briefings may exist that system users need to receive before being granted access to the system. All system users will require a briefing on their responsibilities on access to and use of the system to which they have been granted access to avoid inadvertent errors and security breaches. Specialised system training may also be required.

9.2.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1494]

All system users MUST have received any necessary briefings before being granted access to compartmented or endorsed information or systems.

9.2.10. Access by foreign nationals to NZEO systems

9.2.10.R.01.Rationale

NZEO information is restricted to New Zealand nationals.

9.2.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1497]

Where systems process, store or communicate unprotected NZEO information, agencies MUST NOT allow foreign nationals, including seconded foreign nationals, to have access to the system.

9.2.10.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1498]

Where agencies protect NZEO information on a system by implementing controls to ensure that NZEO information is not passed to, or made accessible to, foreign nationals, agencies MUST NOT allow foreign nationals, including seconded foreign nationals, to have access to the system.

9.2.11. Access by foreign nationals to New Zealand systems

9.2.11.R.01.Rationale

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

9.2.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1501]

Where systems process, store or communicate classified information with nationality releasability markings, agencies MUST NOT allow foreign nationals, including seconded foreign nationals, to have access to such information that is not marked as releasable to their nation.

9.2.12. Granting limited higher access

9.2.12.R.01.Rationale

Under exceptional circumstances, temporary access to systems classified RESTRICTED and below may be granted.

9.2.12.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:1504]

Agencies MUST NOT permit limited higher access for systems and information classified CONFIDENTIAL or above.

9.2.12.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1505]

Agencies granting limited higher access to information or systems MUST ensure that:

  • the requirement to grant limited higher access is temporary in nature and is an exception rather than the norm;
  • an ITSM has recommended the limited higher access;
  • a cessation date for limited higher access has been set;
  • the access period does not exceed two months;
  • the limited higher access is granted on an occasional NOT non-ongoing basis;
  • the system user is not granted privileged access to the system;
  • the system user’s access is formally documented; and
  • the system user’s access is approved by the CISO.

9.2.13. Controlling limited higher access

9.2.13.R.01.Rationale

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

9.2.13.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1508]

Agencies granting limited higher access to a system MUST ensure that:

  • effective controls are in place to restrict access to only classified information that is necessary to undertake the system user’s duties; or
  • the system user is continually supervised by another system user who has the appropriate security clearances to access the system.

9.2.14. Granting emergency access

9.2.14.R.01.Rationale

Emergency access to a system may be granted where there is an immediate and critical need to access information for which personnel do not have the appropriate security clearances. Such access will need to be granted by the agency head or their delegate and be formally documented.

9.2.14.R.02.Rationale

It is important that appropriate debriefs take place at the conclusion of any emergency in order to manage the ongoing security of information and systems and to identify “lessons learned”.

9.2.14.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:1512]

Emergency access MUST NOT be granted unless personnel have a security clearance to at least CONFIDENTIAL level.

9.2.14.C.02.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:1513]

Emergency access MUST NOT be used on reassignment of duties while awaiting completion of full security clearance procedures.

9.2.14.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1514]

Agencies granting emergency access to a system MUST ensure that:

  • the requirements to grant emergency access is due to an immediate and critical need to access classified information and there is insufficient time to complete clearance procedures;
  • the agency head or their delegate has approved the emergency access;
  • the system user’s access is formally documented;
  • the system user’s access is reported to the CISO; 
  • appropriate briefs and debriefs for the information and system are conducted;
  • access is limited to information and systems necessary to deal with the particular emergency and is governed by strict application of the “need to know” principle; 
  • emergency access is limited to ONE security clearance level higher than the clearance currently held; and
  • the security clearance process is completed as soon as possible.
9.2.14.C.04.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:1515]

Personnel granted emergency access MUST be debriefed at the conclusion of the emergency.

9.2.15. Accessing endorsed or compartmented information

9.2.15.R.01.Rationale

Limited higher access to systems processing, storing or communicating endorsed or compartmented information is not permitted.

9.2.15.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:1518]

Agencies MUST NOT grant limited higher access to systems that process, store or communicate endorsed or compartmented information.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

9.3. Using The Internet

Objective

9.3.1.

Personnel use Internet services in a responsible and security conscious manner, consistent with agency policies.

Context

Scope

9.3.2.

This section covers information relating to personnel using Internet services such as the Web, Web-based email, news feeds, subscriptions and other services. Whilst this section does not address Internet services such as IM, IRC, IPT and video conferencing, agencies need to remain aware that unless applications using these communications methods are evaluated and approved by GCSB they are NOT approved for communicating classified information over the Internet.

9.3.3.

Additional information on using applications that can be used with the Internet can be found in Section 14.3 - Web Applications and Section 15.1 - Email Applications.

Rationale & Controls

9.3.4. Using the Internet

9.3.4.R.01.Rationale

Agencies will need to determine what constitutes suspicious activity, questioning or contact in relation to their own work environment. Suspicious activity, questioning or contact may relate to the work duties of personnel or the specifics of projects being undertaken by personnel within the agency.

9.3.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1529]

Agencies MUST ensure personnel are instructed to report any suspicious activity, questioning or contact when using the Internet, to an ITSM.

9.3.5. Awareness of Web usage policies

9.3.5.R.01.Rationale

Users MUST be familiar with and formally acknowledge agency Web usage policies for system users in order to follow the policy and guidance.

9.3.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1532]

Agencies MUST make their system users aware of the agency’s Web usage policies.

9.3.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1533]

Personnel MUST formally acknowledge and accept agency Web usage policies.

9.3.6. Monitoring Web usage

9.3.6.R.01.Rationale

Agencies may choose to monitor compliance with aspects of Web usage policies, such as access attempts to blocked websites, pornographic and gambling websites, as well as compiling a list of system users that excessively download and/or upload data without an obvious or known legitimate business requirement.

9.3.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1536]

Agencies SHOULD implement measures to monitor their personnel, visitor and contractor compliance with their Web usage policies.

9.3.7. Posting information on the Web

9.3.7.R.01.Rationale

Personnel need to take special care not to accidentally post information on the Web, especially in forums and blogs. Even Official Information or UNCLASSIFIED information that appears to be benign in isolation could, in aggregate, have a considerable security impact on the agency, government sector or wider government.

9.3.7.R.02.Rationale

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

9.3.7.R.03.Rationale

Accessing personal accounts from an agency’s systems is discouraged.

9.3.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1541]

Agencies MUST ensure personnel are instructed to take special care when posting information on the Web.

9.3.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:1542]

Agencies MUST ensure personnel posting information on the Web maintain separate professional accounts from any personal accounts they have for websites.

9.3.7.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1543]

Agencies SHOULD monitor websites where personnel post information and if necessary remove or request the removal of any inappropriate information.

9.3.7.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1544]

Accessing personal accounts from agency systems SHOULD be discouraged.

9.3.8. Posting personal information on the Web

9.3.8.R.01.Rationale

Personnel need to be aware that any personal interest or other information they post on websites can be used to develop a detailed profile of their families, lifestyle, interest and hobbies in order to attempt to build a trust relationship with them or others. This relationship could then be used to attempt to elicit information from them or implant malicious software on systems by inducing them to, for instance, open emails or visit websites with malicious content.

9.3.8.R.02.Rationale

Profiling is a common marketing and targeting technique facilitated by the internet.

9.3.8.R.03.Rationale

Individuals who work for high-interest agencies, who hold security clearances or who are involved in high-profile projects are of particular interest to profilers, cyber criminals and other users of this information.

9.3.8.R.04.Rationale

The following is of particular interest to profilers:

  • photographs;
  • past and present employment details;
  • personal details, including DOB, family members, birthdays, address and contact details;
  • schools and institutions;
  • clubs, hobbies and interests;
  • educational qualifications;
  • current work duties;
  • details of work colleagues and associates; and
  • work contact details.
9.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1550]

Agencies SHOULD ensure that personnel are informed of the security risks associated with posting personal information on websites, especially for those personnel holding higher level security clearances.

9.3.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1551]

Personnel SHOULD be encouraged to use privacy settings for websites to restrict access to personal information they post to only those they authorise to view it.

9.3.8.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:1552]

Personnel SHOULD be encouraged to undertake a Web search of themselves to determine what personal information is available and contact an ITSM if they need assistance in determining if the information is appropriate to be viewed by the general public or potential adversaries.

9.3.9. Peer-to-peer applications

9.3.9.R.01.Rationale

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

9.3.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:1555]

Agencies SHOULD NOT allow personnel to use peer-to-peer applications over the Internet.

9.3.10. Receiving files via the Internet

9.3.10.R.01.Rationale

When personnel receive files via peer-to-peer file sharing, IM or IRC applications they are often bypassing security mechanisms put in place by the agency to detect and quarantine malicious code. Personnel should be encouraged to send files via established methods such as email, to ensure they are appropriately scanned for malicious code.

9.3.10.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:1558]

Agencies SHOULD NOT allow personnel to receive files via peer-to-peer, IM or IRC applications.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

9.4. Escorting Uncleared Personnel

Objective

9.4.1.

Uncleared personnel are escorted within secure areas.

Context

Scope

9.4.2.

This section covers information relating to the escorting of uncleared personnel without security clearances in secure areas.

PSR references

Rationale & Controls

9.4.4. Unescorted access

9.4.4.R.01.Rationale

Ensuring that personnel have correct security clearances to access sensitive areas and that access by escorted personnel is recorded for auditing purposes is widely considered a standard security practice.

9.4.4.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1569]

Agencies MUST ensure that all personnel with unescorted access to TOP SECRET areas have appropriate security clearances and briefings.

9.4.5. Maintaining an unescorted access list

9.4.5.R.01.Rationale

Maintaining an unescorted access list reduces the administrative overhead of determining if personnel can enter a TOP SECRET area without an escort. Personnel with approval for unescorted access must be able to verify their identity at all times while within the secure area.

9.4.5.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1572]

Agencies MUST maintain an up to date list of personnel entitled to enter a TOP SECRET area without an escort.

9.4.5.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1573]

Personnel MUST display identity cards at all times while within the secure area.

9.4.6. Displaying the unescorted access list

9.4.6.R.01.Rationale

Displaying an unescorted access list allows staff to quickly verify if personnel are entitled to be in a TOP SECRET area without an escort. Care should be taken not to reveal the contents of the access list to non-cleared personnel.

9.4.6.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:1576]

Agencies SHOULD display within a TOP SECRET area, an up to date list of personnel entitled to enter the area without an escort.

9.4.6.C.02.Control: 
System Classification(s): Top Secret; Compliance: SHOULD NOT [CID:1577]

The unescorted access list SHOULD NOT be visible from outside of the secure area.

9.4.7. Visitors

9.4.7.R.01.Rationale

Visitors to secure areas should be carefully supervised to ensure the need-to-know principle is strictly adhered to.

9.4.7.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:1580]

Visitors SHOULD be carefully supervised to ensure they do not gain access to or have oversight of information above the level of their clearance or outside of their need-to-know.

9.4.8. Recording visits in a visitor log

9.4.8.R.01.Rationale

Recording visitors to a TOP SECRET area ensures that the agency has a record of visitors should an investigation into an incident need to take place in the future.

9.4.8.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST NOT [CID:1583]

Agencies MUST NOT permit personnel not on the unescorted access list to enter a TOP SECRET area unless their visit is recorded in a visitor log and they are escorted by a person on the unescorted access list.

9.4.9. Content of the visitor log

9.4.9.R.01.Rationale

The contents of the visitor log ensure that security personnel have sufficient details to conduct an investigation into an incident if required.

9.4.9.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1586]

Agencies MUST, at minimum, record the following information in a visitor log for each entry:

  • name;
  • organisation;
  • person visiting;
  • contact details for person visiting; and
  • date and time in and out.

9.4.10. Separate visitor logs

9.4.10.R.01.Rationale

Maintaining a separate visitor log for TOP SECRET areas assists in enforcing the need-to-know principle. General visitors do not need-to-know of personnel that have visited TOP SECRET areas.

9.4.10.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:1589]

Agencies with a TOP SECRET area within a larger facility MUST maintain a separate log from any general visitor log.

10. Infrastructure

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.1. Cable Management Fundamentals

Objective

10.1.1.

Cable management systems are implemented to allow easy integration of systems across government and minimise the opportunity for tampering or unauthorised change.

Context

Scope

10.1.2.

This section covers information relating to cable distribution systems used in facilities within New Zealand. When designing cable management systems, Section 10.5 - Cable Labelling and Registration and Section 10.6 - Cable Patching of this chapter also apply.

Applicability of controls within this section

10.1.3.

The controls within this section are applicable only to communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside of New Zealand Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual MUST be consulted.

Common implementation scenarios

10.1.4.

This section provides common requirements for non-shared facilities. Specific requirements for facilities shared between agencies and facilities shared with non-government entities can be found in subsequent sections of this chapter.

Red/Black Concept and Cable Separation

10.1.5.

The RED/BLACK concept is the separation of electrical and electronic circuits, devices, equipment cables, connectors, components and systems that transmit store or process national security information (RED) from non-national security information (BLACK).  The RED/BLACK concept is sometimes described as RED/BLACK architecture or RED/BLACK engineering.

10.1.6.

The RED/BLACK concept should not be confused with the generic description HIGH/LOW or HIGH SIDE/LOW SIDE.  In this context, HIGH refers to information and equipment classified CONFIDENTIAL and above and LOW refers to information and equipment classified RESTRICTED and below.  While these concepts are similar and often used interchangeably, it is important to recognise that information does not usually change classification. The signal or transmission, however, may transit both RED and BLACK systems in order to reach its intended destination.

10.1.7.

An example is the use of radio transmissions or Wi-Fi where the information may hold a HIGH classification and originate in RED equipment but once transmission occurs the signal is BLACK as radio and Wi-Fi signals can be detected by anyone within range.

10.1.8.

This also leads to the situation where some equipment may have both RED and BLACK elements.  Examples include Wi-Fi Access Points and encryption devices.  RED Information in a BLACK environment is invariably protected by encryption and a variety of technical countermeasures.

10.1.9.

All cables with metal conductors (the signal carrier, the grounding element, the strengthening member or an armoured outer covering) can act as fortuitous signal conductors allowing signals to escape or to cross-contaminate other cables and signals.  This provides a path for the exploitation of signals, data and information.

10.1.10.

A fundamental control is the separation of cables and related equipment with sufficient distance between them to prevent cross-contamination.

Cable trays

10.1.11.

Where copper or a combination of copper and fibre cables are used, cable trays will provide separation, assist cable management and enhance cable protection.  While preferable to separate RED cables of different systems for cable management purposes, the most important element is to maintain RED/BLACK separation. 

10.1.12.

It is preferable that cable trays contain dividers.  Some cable trays provide only a single receptacle for cables (no dividers). If dividers are not available, multi-core fibre cables should be used.  Cables of similar classifications should be bundled.  A typical cable tray layout with dividers is depicted below:

 

 

Catenary

10.1.13.

The use of catenary (wire, rope, nylon cord or similar cable support mechanisms) is becoming more widespread in place of cable trays.  Care MUST be taken to maintain RED/BLACK separation if this method of cable support is used.

Earthing

10.1.14.

It is important that any metal trays or metal catenary are earthed for both safety and to avoid creating any fortuitous conductors.  All earthing points MUST be equipotentially bonded.

Fibre optic cabling

10.1.15.

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

10.1.16.

Many more fibres can be run per cable diameter than wired cables thereby reducing cable infrastructure costs. Fibre Optic cable is usually constructed with a glass core, cladding on the core and a further, colour coded coating. Multiple cores can be bundled into a single cable and multiple cables can be bundled into a high capacity cable. This is illustrated in Figures 1 below. Cables also have a central strength member of mylar or some similar high strength, non-conductive material

10.1.17.

Fibre cable is considered the best method to future proof against unforeseen threats.

10.1.18.

Cable trays for fibre only cable may be of any suitable material.  If metal trays are used they MUST be earthed.

Ribbon Fibre Optic Cable

10.1.19.

In the context of this discussion, traditional and ribbon fibre optic cables are subject to identical controls, restrictions in installation and use and any operational caveats.

10.1.20.

Unlike traditional beam optical cable, ribbon fibre optic cable is arranged into a strip.  Because the ribbon contains only coated optical fibres, this type of cable takes up much less space and is generally lighter (weight) than individually buffered optical fibres.  As a result, ribbon cables are denser than any other fibre cable design.  They are ideal for applications where space is limited, such as in an existing conduit that has very little room left for an additional cable.  Ribbon fibre optic cable is a convenient solution for space and weight challenges.

 

Figure 2: Typical Ribbon Cable

10.1.21.

Ribbon cables enable the migration to high fibre count systems required to support high bandwidth applications including 10, 40 and 100Gb/s.  Ribbon cables are rarely used in long distance fibre optic trunk cable but are typically used in data centres, campus, commercial buildings and large industrial sites.  Fibre counts can range from 2 to over 1700.

10.1.22.

The cable ribbons are coated optical fibres placed side by side, encapsulated in Mylar tape, similar to a miniature version of wire ribbons used in computer wiring.  A single ribbon many contain 4, 8, 12 or 24 optical fibres with ribbons stacked up to 22 high.  At present 12-fiber ribbons are readily accessible and identifiable with ribbon identification numbers, TIA-598 compliant fibre colour coding and are available with non-flame-retardant or formulated flame-retardant outer jacket.  They are also available in several configurations including all-dielectric, armoured and aerial self-supporting cables.

10.1.23.

Because the cable profile is different to older round cable type, new cable strippers, cleavers, and fusion splicers are required for installation and maintenance.

10.1.24.

Fibre optic ribbon cable comes in two basic configurations: loose tube ribbon cable and jacket ribbon.  Loose tube cables are where fibre ribbons are stacked on top of one another inside a loose-buffered tube.  This arrangement can hold several hundred fibres in close quarters. The buffer, strength members, and cable jacket carry any strain while the fibre ribbons move freely inside the buffer tube.

10.1.25.

Jacket ribbon cable is similar to a regular tight-buffered cable, but it is elongated to contain a fibre ribbon. This type of cable typically features a small amount of strength member and a ripcord to tear through the jacket.

 

 

 

Figure 3: Jacket Cable                                              Figure 4: Loose Tube Cable

10.1.26.

Infrastructure cables contain multiple fibre ribbon units inside a central tube with dielectric strength members for tensile strength and colour coded fibres with individual ribbon unit ID numbers for clear identification.  Ribbon fibre optic cables are available in configurations supporting high-speed, applications such as Gigabit Ethernet, 10 Gigabit Ethernet, Gigabit ATM and Fibre Channel.

 

Figure 5: Infrastructure (High Cable Count) Ribbon Cable

Armoured Fibre optic cabling

10.1.27.

Some fibre optic cable also includes conductive metal cable strengtheners and conductive metal armoured sheaths which may be wire-wound or stainless steel mesh for external cable protection and steel wire cores as core strength members. This strengthening and armouring is conductive and specialist advice may be needed to avoid earth loops, cross-coupling, inductive coupling or the introduction of other compromising signals and currents. Fibre optic cable with metal cable strengtheners or conductive armoured sheaths is considered unsuitable for secure installations.

 


 

image diagram of Typical Cable Construction for an Armoured Cable

                    Figure 6 - Armoured Ribbon Fibre Cable

 

Backbone

10.1.28.

A backbone or core is the central cabling that connects the infrastructure (servers, databases, gateways, equipment and telecommunication rooms etc.) to local areas networks, workstations and other devices, such as MFD’s. Smaller networks may also be connected to the backbone.

10.1.29.

A backbone can span a geographic area of any size including an office, a single building, multi-story buildings, campus, national and international infrastructure. In the context of the NZISM the term backbone generally refers to the central cabling within a building or a campus.

10.1.30.

Backbones can be defined in terms of six criteria:

  • transmission media;
  • topology;
  • security required;
  • access control;
  • transmission technique; 
  • transmission speed and capability.

Diagram of Access Network

TOP SECRET cabling

10.1.31.

For TOP SECRET cabling the cable’s non-conductive protective sheath IS NOT considered to be a conduit. For TOP SECRET fibre optic cables with sub-units, the cable’s outer protective sheath IS considered to be a conduit.

Power Filters

10.1.32.

A power filter is an electronic filter placed between an external power source and electronic devices.  It is used in order to attenuate external transients, conducted radio frequencies (RF) or electromagnetic interference (EMI) between the AC or DC power line and the equipment.  Filters can also reduce radiated interference to assist in managing emissions or susceptibility to interference.

10.1.33.

The power lines entering an electronic device can act both as an antenna and as a low impedance conduction path for signals that exist inside the device.  These signals may couple into the power line, either through inductance or capacitance, from internal circuitry, other internal wiring or from other components such as transformers, coils or adjacently routed wires.  To a lesser degree, but still problematic, the power lines can also pickup induced current signals from magnetic fields inside the enclosure.

10.1.34.

The purpose of power supply filters is to smooth the power supply and provide a degree of isolation from the external power supply for connected electronic devices.  RF/EMI filters are designed to reduce line - to - ground (common mode) interference, EMI and anomalous RF.  Best practice is to solve or suppress EMI and RF emissions at source, rather than after emission.

10.1.35.

There are international and national regulations on frequencies and signal levels that a device is permitted to produce in order to minimise or prevent interference with other equipment.  Practically no modern equipment, with fast digital circuits and switch-mode power supply regulators can meet electromagnetic compatibility (EMC) requirements without efficient filtering, particularly when operating in close proximity.  While most devices are designed by manufacturers to meet regulation, not all devices filter EMI or RF to levels acceptable for secure environments.  It may be necessary to use a power line filter to keep signals inside the enclosure as much as possible and keep any generated signals to less than the legal or required limits for conducted emissions.

10.1.36.

Power filters have a variety of capabilities depending on their specification.  It is important the filters are selected correctly for the power supply, expected load and required attenuation capacity. It is important to note that an Uninterruptible Power Supply (UPS) is NOT considered an RF/EMI filter.

10.1.37.

Common usage of filters is for computer systems, laboratory and testing equipment, medical devices, consumer electronics, and to protect any equipment where good quality power supply and protection of the electronic devices and data is required.  Devices can be within buildings, vehicle, ships, aircraft or portable.

10.1.38.

Power filters often include EMC/ RFI filters which channel emissions to earth to prevent them from being conducted back down the supply cables.  This can be detected as an earth leakage current which may cause Residual Current Devices (RCDs) to trip.  This problem can be corrected by using the correct specification of power filter or installing low leakage current devices.  Agencies should consult the GCSB if such problems occur.

References

10.1.39.

Title

Publisher

Source

NZCSS 400: New Zealand Communications Security Standard No 400 (Document classified CONFIDENTIAL)

GCSB

GCSB

CONFIDENTIAL document available on application to authorised personnel

AS/NZS 3000:2007/Amdt 2:2012 - Electrical Installations (Known as the Australia/New Zealand Wiring Rules,

Standards NZ

Standards New Zealand

http://www.standards.co.nz/  

ANSI/TIA-568-C.3 – Optical Fiber Cabling Components

American National Standards Institute (ANSI)

http://www.ansi.org/

IEEE 802 – Local and Metropolitan Area Networks: Overview and Architecture

Institute of Electrical and Electronics Engineers (IEEE)

http://ieeexplore.ieee.org/document/6847097/

References - Fibre Standards

10.1.40.

Fibre Standards.

Title Description Source
AS/NZS 2967:2014

Optical fibre communication cabling systems safety.

Provides rules for safe practices in the handling, installation, testing, use and disposal of optical fibre cabling and associated materials and equipment.

https://shop.standards.govt.nz/catalog

IEC/ISO 11801

Information technology - Generic cabling for customer premises.

Specifies general-purpose telecommunication cabling systems (structured cabling), including several classes of optical fibre interconnections.
https://webstore.iec.ch/home
IEC 60793 Series

Optical fibres.

A list of all parts in the IEC 60793 series, published under the general title Optical fibres, can be found on the IEC website.
https://webstore.iec.ch/home
IEC 60794 Series

Optical fibre cables.

A list of all parts in the IEC 60794 series, published under the general title Optical fibre cables, can be found on the IEC website.
https://webstore.iec.ch/home
ANSI/TIA-568-C.3 Optical Fibre Cabling Components https://webstore.ansi.org
ANSI/TIA-598-D (Revision of TIA-598-C) July 2014

Optical Fibre Cable Colour Coding

This standard defines the recommended identification scheme or system for individual fibres, fibre units, and groups of fibre units within a cable structure.
https://webstore.ansi.org
ITU-T G.657 – 659 series

Optical Fibre Cables

Characteristics and recommendations for selection, use and installation.
https://www.itu.int/en/ITU-T/publications/Pages/recs.aspx

PSR references

Rationale & Controls

10.1.42. Backbone

10.1.42.R.01.Rationale

The design of a backbone requires consideration of a number of criteria including the capacity of the cable to carry the predicted volume of data at acceptable speeds. An element of “future proofing” is also required as re-cabling to manage capacity issues can be costly. Fibre optic cable provides a convenient means of securing and “future proofing” backbones.

10.1.42.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2216]

Agencies MUST use fibre optic cable for backbone infrastructures and installations.

10.1.42.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2217]

Agencies SHOULD use fibre optic cable for backbone infrastructures and installations.

10.1.43. Use of Fibre Optic Cable

10.1.43.R.01.Rationale

Fibre optic cable is considered more secure than copper cables and provides electrical isolation of signals. Fibre will also provide higher bandwidth and speed to allow a degree of future-proofing in network design.

10.1.43.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2220]

Agencies SHOULD use fibre optic cabling.

10.1.43.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2221]

Agencies SHOULD consult with the GCSB where fibre optic cable incorporating conductive metal strengtheners or sheaths is specified.

10.1.43.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2222]

Agencies SHOULD consult with the GCSB where copper cables are specified.

10.1.43.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:2223]

Agencies SHOULD NOT use fibre optic cable incorporating conductive metal strengtheners or sheaths except where essential for cable integrity.

10.1.44. Cabling Standards

10.1.44.R.01.Rationale

Unauthorised personnel could inadvertently or deliberately access system cabling. This could result in loss or compromise of classified information. Non-detection of covert tampering or access to system cabling may result in long term unauthorised access to classified information by a hostile entity.

10.1.44.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2226]

Agencies MUST install all cabling in accordance with the relevant New Zealand standards as directed by AS/NZS 3000:2007 and NZCSS400.

10.1.45. Cable colours

10.1.45.R.01.Rationale

To facilitate cable management, maintenance and security cables and conduit should be colour-coded to indicate the classification of the data carried and/or classification of the compartmented data.

10.1.45.R.02.Rationale

Cables and conduit may be the distinguishing colour for their entire length or display a distinguishing label marking and colour at each end and at a maximum of two metre intervals along the cable.

10.1.45.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2230]

Agencies MUST comply with the cable and conduit colours specified in the following table.

Classification Cable colour
Compartmented Information (SCI) Orange/Yellow/Teal or other colour 
TOP SECRET Red
SECRET Blue
CONFIDENTIAL Green
RESTRICTED and all lower classifications Black
10.1.45.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2231]

Additional colours may be used to delineate special networks and compartmented information of the same classification. These networks MUST be labelled and covered in the agency’s SOPs.

10.1.46. Cable colours for foreign systems in New Zealand facilities

10.1.46.R.01.Rationale

Foreign systems should be segregated and separated from other agency systems for security purposes. Colour-coding will facilitate installation, maintenance, certification and accreditation.

10.1.46.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2234]

The cable colour to be used for foreign systems MUST be agreed between the host agency, the foreign system owner and the Accreditation Authority.

10.1.46.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST NOT [CID:2235]

Agencies MUST NOT allow cable colours for foreign systems installed in New Zealand facilities to be the same colour as cables used for New Zealand systems.

10.1.46.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2236]

The cable colour to be used for foreign systems SHOULD be agreed between the host agency, the foreign system owner and the Accreditation Authority.

10.1.46.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:2237]

Agencies SHOULD NOT allow cable colours for foreign systems installed in New Zealand facilities to be the same colour as cables used for New Zealand systems.

10.1.47. Cable groupings

10.1.47.R.01.Rationale

Grouping cables provides a method of sharing conduits and cable reticulation systems in the most efficient manner. These conduits and reticulation system must be inspectable and cable separations must be obvious.

10.1.47.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2240]

Agencies MUST contact GCSB for advice when combining the cabling of special networks.

10.1.47.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:2241]

Agencies MUST NOT deviate from the approved fibre cable combinations for shared conduits and reticulation systems as indicated below.

Group

Approved combination

1 UNCLASSIFIED
  RESTRICTED
2 CONFIDENTIAL
  SECRET
3 TOP SECRET
 

Other Special Networks

10.1.48. Fibre optic cables sharing a common conduit

10.1.48.R.01.Rationale

The use of multi-core fibre optic cables can reduce installation costs. The principles of separation and containment of cross-talk and leakage must be adhered to.

10.1.48.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2244]

With fibre optic cables the arrangements of fibres within the cable sheath, as illustrated in Figure 3, MUST carry a single classification only.

Typical Cable Construction Duplex

Typical Cable Construction Twin Flex

Typical Cable Construction Multi-core Cable

 

10.1.48.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2245]

If a fibre optic cable contains subunits, as shown in Figure 4, each subunit MUST carry only a single classification.

Typical Cable Construction Multi-core with Subunits

10.1.48.C.03.Control: 
System Classification(s): All Classifications; Compliance: MUST NOT [CID:2246]

Agencies MUST NOT mix classifications up to RESTRICTED with classifications of CONFIDENTIAL and above in a single cable.

10.1.49. Audio secure areas

10.1.49.R.01.Rationale

Audio secure areas are designed to prevent audio conversation from being heard outside the walls. Penetrating an audio secure area for cables in an unapproved manner can degrade this. Consultation with GCSB needs to be undertaken before any modifications are made to audio secure areas.

10.1.49.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2249]

When penetrating an audio secure area for cables, agencies MUST comply with all directions provided by GCSB.

10.1.50. Wall outlet terminations

10.1.50.R.01.Rationale

Wall outlet boxes are the preferred method of connecting cable infrastructure to workstations and other equipment. They allow the management of cabling and can utilise a variety of connector types for allocation to different classifications.

10.1.50.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2253]

Cable groups sharing a wall outlet MUST use different connectors for systems of different classifications.

10.1.50.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2254]

In areas containing outlets for both TOP SECRET systems and systems of other classifications, agencies MUST ensure that the connectors for the TOP SECRET systems are different to those of the other systems.

10.1.50.C.03.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2255]

Cable outlets MUST be labelled with the system classification and connector type.

10.1.50.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2256]

Cable outlets SHOULD be labelled with the system classification and connector type.

10.1.51. Power Filters

10.1.51.R.01.Rationale

Power filters are used to provide a filtered (clean) power supply and reduce opportunity for technical attacks.

10.1.51.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:5899]

Power filters SHOULD be used to provide a filtered power supply and reduce opportunity for technical attacks.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.2. Cable Management for Non-Shared Government Facilities

Objective

10.2.1.

Cable management systems in non-shared government facilities are implemented in a secure and easily inspectable and maintainable way.

Context

Scope

10.2.2.

This section provides specific requirements for cabling installed in facilities solely occupied by a single agency. This section is to be applied in addition to common requirements for cabling as outlined in the Section 10.1 - Cable Management Fundamentals.

Applicability of controls within this section

10.2.3.

The controls within this section are only applicable to communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside of New Zealand, Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual will need to be consulted.

References

10.2.4.

Further references can be found at:

Title Publisher Source
NZCSS 400: New Zealand Communications Security Standard No 400 (Document classified CONFIDENTIAL) GCSB

GCSB

CONFIDENTIAL document available on application to authorised personnel

AS/NZS 3000:2007/Amdt 2:2012 - Electrical Installations (Known as the Australia/New Zealand Wiring Rules,

Standards NZ

http://www.standards.co.nz/

Rationale & Controls

10.2.5. Cabling Inspection

10.2.5.R.01.Rationale

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

10.2.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2270]

In TOP SECRET areas or zones, all cabling MUST be inspectable at a minimum of five-metre intervals.

10.2.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2271]

Cabling SHOULD be inspectable at a minimum of five-metre intervals.

10.2.6. Cables sharing a common reticulation system

10.2.6.R.01.Rationale

Laying cabling in a neat and controlled manner, observing separation requirements, allows for inspections and reduces the need for individual cable trays for each classification.

10.2.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2274]

Approved cable groups may share a common reticulation system but SHOULD have either a dividing partition or a visible gap between the differing cable groups or bundles.

10.2.7. Cabling in walls

10.2.7.R.01.Rationale

Cabling run correctly in walls allows for neater installations while maintaining separation and inspectability requirements.

10.2.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2277]

Flexible or plastic conduit SHOULD be used in walls to run cabling from cable trays to wall outlets.

10.2.8. Cabinet separation

10.2.8.R.01.Rationale

Having a definite gap between cabinets allows for ease of inspections for any unauthorised or malicious cabling or cross patching.

10.2.8.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:2280]

TOP SECRET cabinets SHOULD have a visible inspectable gap between themselves and lower classified cabinets.

10.2.9. Power Filters

10.2.9.R.01.Rationale

Power filters are used to provide a filtered (clean) power supply and reduce opportunity for technical attacks.

10.2.9.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:5902]

Power filters SHOULD be used to provide a filtered power supply and reduce opportunity for technical attacks.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.3. Cable Management for Shared Government Facilities

Objective

10.3.1.

Cable management systems in shared government facilities are implemented in a secure and easily inspectable and maintainable way.

Context

Scope

10.3.2.

This section provides specific requirements for cabling installed in facilities shared exclusively by agencies. This section is to be applied in addition to common requirements for cabling as outlined in Section 10.1 - Cable Management Fundamentals.

Applicability of controls within this section

10.3.3.

The controls within this section are applicable only to communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside of New Zealand, Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual will need to be consulted.

Rationale & Controls

10.3.4. Use of fibre optic cabling

10.3.4.R.01.Rationale

Fibre optic cabling does not produce and is not influenced by electromagnetic emanations; as such it offers the highest degree of protection from electromagnetic emanation effects especially in a shared facility where you do not have total control over other areas of the facility.

10.3.4.R.02.Rationale

It is more difficult to tap than copper cabling.

10.3.4.R.03.Rationale

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

10.3.4.R.04.Rationale

Fibre cable is the best method to future proof against unforseen threats.

10.3.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2295]

Agencies SHOULD use fibre optic cabling.

10.3.5. Cabling inspection

10.3.5.R.01.Rationale

In a shared facility it is important that cabling systems are inspected for illicit tampering and damage on a regular basis and have stricter controls than a non-shared facility.

10.3.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2299]

In TOP SECRET areas, cables MUST be fully inspectable for their entire length.

10.3.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2298]

Cabling SHOULD be inspectable at a minimum of five-metre intervals.

10.3.6. Cables sharing a common reticulation system

10.3.6.R.01.Rationale

In a shared facility with another government agency, tighter controls may be required for sharing reticulation systems. Note also the red/black separation requirements in paragraph 10.1.5.

10.3.6.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2302]

Approved cable groups SHOULD have either a dividing partition or a visible gap between the individual cable groups. If the partition or gap exists, cable groups may share a common reticulation system.

10.3.7. Enclosed cable reticulation systems

10.3.7.R.01.Rationale

In a shared facility with another government agency, TOP SECRET cabling is enclosed in a sealed reticulation system to restrict access and control cable management.

10.3.7.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:2305]

The front covers of conduits, ducts and cable trays in floors, ceilings and of associated fittings that contain TOP SECRET cabling, SHOULD be clear plastic.

10.3.8. Cabling in walls

10.3.8.R.01.Rationale

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

10.3.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2308]

Cabling from cable trays to wall outlets SHOULD run in flexible or plastic conduit.

10.3.9. Wall penetrations

10.3.9.R.01.Rationale

Wall penetrations by cabling, requires the integrity of the classified area to be maintained. All cabling is encased in conduit with no gaps in the wall around the conduit. This prevents any visual access to the secure area.

10.3.9.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:2311]

For wall penetrations that exit into a lower classified area, cabling SHOULD be encased in conduit with all gaps between the conduit and the wall filled with an appropriate sealing compound.

10.3.10. Power reticulation

10.3.10.R.01.Rationale

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

10.3.10.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:2314]

TOP SECRET facilities SHOULD have a power distribution board, separately reticulated, located within the TOP SECRET area and supply UPS power to all equipment.

10.3.11. Power Filters

10.3.11.R.01.Rationale

Power filters are used to provide a filtered (clean) power supply and reduce opportunity for technical attacks.

10.3.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2317]

Power filters SHOULD be used to provide a filtered power supply and reduce opportunity for technical attacks.

10.3.12. Cabinet separation

10.3.12.R.01.Rationale

Having a visible gap between cabinets facilitates inspection for any unauthorised, malicious or cross patch cabling.

10.3.12.C.01.Control: 
System Classification(s): Top Secret; Compliance: SHOULD [CID:2320]

TOP SECRET cabinets SHOULD have a visible gap to separate them from lower classified cabinets.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.4. Cable Management for Shared Non-Government Facilities

Objective

10.4.1.

Cable management systems are implemented in shared non-government facilities to minimise risks to data and information.

Context

Scope

10.4.2.

This section provides specific requirements for cabling installed in facilities shared by agencies and non-government organisations. This section is to be applied in addition to common requirements for cabling as outlined in Section 10.1 - Cable Management Fundamentals section.

Applicability of controls within this section

10.4.3.

The controls within this section are applicable only to communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside New Zealand, Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual MUST be consulted.

Rationale & Controls

10.4.4. Use of fibre optic cabling

10.4.4.R.01.Rationale

Fibre optic cabling is essential in a shared non-government facility. Fibre optic cabling does not produce and is not influenced by electromagnetic emanations; as such it offers the highest degree of protection from electromagnetic emanation effects especially in a shared non-government facility where an agency’s controls may have a limited effect outside the agency controlled area.

10.4.4.R.02.Rationale

Fibre optic cable is more difficult to tap than copper cabling and anti-tampering monitoring can be employed to detect tampering.

10.4.4.R.03.Rationale

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

10.4.4.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2335]

In TOP SECRET areas, agencies MUST use fibre optic cabling.

10.4.4.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2336]

Agencies SHOULD use fibre optic cabling.

10.4.5. Cabling inspection

10.4.5.R.01.Rationale

In a shared non-government facility, it is imperative that cabling systems be inspectable for tampering and damage on a regular basis particularly where higher threat levels exist or where threats are unknown.

10.4.5.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2340]

In TOP SECRET areas, cables MUST be fully inspectable for their entire length.

10.4.5.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2341]

Cabling SHOULD be inspectable at a minimum of five-metre intervals.

10.4.6. Cables sharing a common reticulation system

10.4.6.R.01.Rationale

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

10.4.6.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2344]

In TOP SECRET areas, approved cable groups can share a common reticulation system but MUST have either a dividing partition or a visible gap between the differing cable groups.

10.4.6.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2345]

TOP SECRET cabling MUST run in a non-shared, enclosed reticulation system.

10.4.6.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2346]

Approved cable groups can share a common reticulation system but SHOULD have either a dividing partition or a visible gap between the differing cable groups.

10.4.7. Enclosed cable reticulation systems

10.4.7.R.01.Rationale

In a shared non-government facility, TOP SECRET cabling is enclosed in a sealed reticulation system to prevent access and control cable management.

10.4.7.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2349]

In TOP SECRET areas, the front covers for conduits and cable trays in floors, ceilings and of associated fittings MUST be clear plastic or be inspectable and have tamper proof seals fitted.

10.4.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2350]

The front covers of conduits, ducts and cable trays in floors, ceilings and of associated fittings SHOULD be clear plastic or be inspectable and have tamper proof seals fitted.

10.4.8. Cabling in walls or party walls

10.4.8.R.01.Rationale

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

10.4.8.R.02.Rationale

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

10.4.8.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2354]

Cabling MUST NOT run in a party wall.

10.4.9. Sealing reticulation systems

10.4.9.R.01.Rationale

In a shared non-government facility, where the threats of access to cable reticulation systems is increased, GCSB endorsed anti-tamper seals are required to provide evidence of any tampering or illicit access.

10.4.9.R.02.Rationale

In a shared non-government facility, all conduit joints and wall penetrations are sealed with a visible smear of glue or sealant to prevent access to cabling.

10.4.9.C.01.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2358]

Agencies MUST use GCSB endorsed tamper evident seals to seal all removable covers on reticulation systems, including:

  • conduit inspection boxes;
  • outlet and junction boxes; and
  • T-pieces.
10.4.9.C.02.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2359]

Tamper evident seals MUST be uniquely identifiable and a register kept of their unique number and location.

10.4.9.C.03.Control: 
System Classification(s): Top Secret; Compliance: MUST [CID:2360]

Conduit joints MUST be sealed with glue or sealant.

10.4.9.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2361]

Conduit joints SHOULD be sealed with glue or sealant.

10.4.10. Wall penetrations

10.4.10.R.01.Rationale

A cable wall penetration into a lesser-classified area requires the integrity of the classified area be maintained. All cabling is encased in conduit with no gaps in the wall around the conduit. This prevents any visual access to the secure area.

10.4.10.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2365]

Wall penetrations that exit into a lower classified area, cabling MUST be encased in conduit with all gaps between the conduit and the wall filled with an appropriate sealing compound.

10.4.11. Power reticulation

10.4.11.R.01.Rationale

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

10.4.11.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2368]

Secure facilities MUST have a power distribution board located within the secure area and supply UPS power all equipment.

10.4.12. Power Filters

10.4.12.R.01.Rationale

Power filters should be used to provide filtered (clean) power and reduce opportunity for technical attacks. Consult the GCSB for technical advice.

10.4.12.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2371]

Power filters MUST be used to provide filtered (clean) power and reduce opportunity for technical attacks.

10.4.13. Equipment Cabinet separation

10.4.13.R.01.Rationale

A visible gap between equipment cabinets will make any cross-cabling obvious and will simplify inspections for unauthorised or compromising changes.

10.4.13.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2374]

Equipment cabinets MUST have a visible gap or non-conductive isolator between cabinets of different classifications.

10.4.13.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2375]

There SHOULD be a visible inspectable gap or non-conductive isolator between equipment cabinets of different classifications.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.5. Cable Labelling and Registration

Objective

10.5.1.

To facilitate cable management, and identify unauthorised additions or tampering.

Context

Scope

10.5.2.

This section covers information relating to the labelling of cabling infrastructure installed in secure areas.

Applicability of controls within this section

10.5.3.

The controls within this section are applicable only to communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside New Zealand, Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual MUST be consulted.

Rationale & Controls

10.5.4. Conduit label specifications

10.5.4.R.01.Rationale

Conduit labelling of a specific size and colour will facilitate identifying secure conduits.

10.5.4.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2387]

Agencies MUST comply with the conduit label colours specified in the following table.

Classification

Cable colour

Compartmented Information (SCI)

Orange/Yellow/Teal or other colour

TOP SECRET

Red

SECRET

Blue
CONFIDENTIAL Green

RESTRICTED and all lower classifications

Black

10.5.5. Installing conduit labelling

10.5.5.R.01.Rationale

Conduit labelling in public or reception areas should not draw undue attention to the level of classified processing or any other agency capability.

10.5.5.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:2390]

Conduit labels installed in public or visitor areas SHOULD NOT be labelled in such a way as to draw attention to or reveal classification of data processed or other agency capability.

10.5.6. Labelling wall outlet boxes

10.5.6.R.01.Rationale

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

10.5.6.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2393]

Wall outlet boxes MUST denote the classification, cable and outlet numbers.

10.5.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2394]

Wall outlet boxes SHOULD denote the classification, cable and outlet numbers.

10.5.7. Standard operating procedures

10.5.7.R.01.Rationale

Recording labelling conventions in SOPs facilitates maintenance and fault finding.

10.5.7.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2397]

The SOPs SHOULD record the site conventions for labelling and registration.

10.5.8. Labelling cables

10.5.8.R.01.Rationale

Labelling cables with the correct socket number, equipment type, source or destination minimises the likelihood of improperly cross connecting equipment and can assist in fault finding and configuration management.

10.5.8.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2400]

Agencies MUST label cables at each end, with sufficient information to enable the physical identification and inspection of the cable.

10.5.8.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2401]

Agencies SHOULD label cables at each end, with sufficient information to enable the physical identification and inspection of the cable.

10.5.9. Cable register

10.5.9.R.01.Rationale

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

10.5.9.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2404]

Agencies MUST maintain a register of cables.

10.5.9.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2405]

Agencies SHOULD maintain a register of cables.

10.5.10. Cable register contents

10.5.10.R.01.Rationale

Cable registers allow installers and assessors to trace cabling for inspection, tampering or accidental damage. It tracks all cable management changes through the life of the system.

10.5.10.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2408]

The cable register MUST record at least the following information:

  • cable identification number;
  • classification;
  • socket number, equipment type, source or destination site/floor plan diagram; and
  • seal numbers if applicable.
10.5.10.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2409]

The cable register SHOULD record at least the following information:

  • cable identification number;
  • classification;
  • socket number, equipment type, source or destination site/floor plan diagram; and
  • seal numbers if applicable.

10.5.11. Cable inspections

10.5.11.R.01.Rationale

Regular cable inspections, are a method of checking the cable management system against the cable register as well as detecting tampering, damage, breakages or other anomalies.

10.5.11.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2412]

Agencies SHOULD inspect cables for inconsistencies with the cable register in accordance with the frequency defined in the SecPlan.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.6. Patch Panels and Patch Cables

Objective

10.6.1.

Cable termination, patch panels and patch cables are designed to prevent emanations, cross-connecting or cross-patching systems of differing classifications as well as following good engineering practice.

Context

Scope

10.6.2.

This section covers information relating to the configuration and installation of patch panels, patch cables and fly leads associated with communications systems.

Applicability of controls within this section

10.6.4.

The controls within this section are applicable to all communications infrastructure located within facilities in New Zealand. For deployable platforms or facilities outside New Zealand the Emanation Security Threat Assessments (Section 10.7) of this chapter of this manual MUST be consulted.

Exception for patch cable and fly lead connectors

10.6.5.

For patch cables, the same connectors can be used for different classifications if the length of the higher classified patch cables is less than the distance between the higher classified patch panel and any patch panel of a lower classification.

Fibre optic patch panels

10.6.6.

For Fibre optic patch panels are sometimes also described as fibre distribution panels.  Their principal function is to safety terminate the fibre optic cable and provide connection access to the cable’s individual fibres.

10.6.7.

Fibre patch panels are termination units, providing a secure, organised chamber for housing connectors and splice units while organising, managing and protecting fibre optic cable, splices and connectors.

10.6.8.

Fibre patch panels can be either rack mounted or wall mounted and are usually placed near terminating equipment and connected with patch cables.  Free standing patch panel racks are also available.  Patch panels may also be mounted within standard equipment racks.

10.6.9.

Rack mount panels may have flat or angled faces to assist in organising the cables themselves.  Angled panels are intended to direct patch cables into vertical cable managers on either side of the rack.  This facilitates maintenance and reduces the requirement for horizontal cable management.

10.6.10.

Fibre patch panels can accommodate fibre adapter panels (also called connector panels), associated trunk cables, connectors, patch cords, and usually integrate cable management.

10.6.11.

There are several components in a fibre patch panel which may include:

  • Chassis or frame;
  • Drawer to facilitate access for installation and maintenance;
  • Cassette;
  • Coupler panels (adapter panels) – to hold the connector couplers;
  • The connector couplers (connector adapters);
  • Splice tray – organises and secures splice modules;
  • Patch cable management trays.
10.6.12.

While well over 80 different fibre optic cable connector types have been manufactured, there are between 15 and 20 types in common use.

Multimedia Patch Panels

10.6.13.

A multimedia modular panel allows copper and fibre cables to be terminated in the same rack mount space.  It accommodates several different adapters, suited for Cat6a/6/5e/5 Ethernet cables and fibre patch cables.

Rack Layout and Cable Management

10.6.14.

Standardised rack layouts and cable management are important for engineering support, security, equipment cooling and to minimise accidental or unnecessary outages.  Many data centres will dictate a hotside (hot air out) and coldside (cold air in).  The hotside is generally the rear of equipment and the rack.  The coldside is generally the front panel of equipment and rack.  The ducting of hot/cold air is often also standardised. 

10.6.15.

 Standardising rack layout and cable management minimises problems caused by:

  • Accidently not being able to locate end points of network and patch cables without tracing the cable end to end.
  • Physically impeding access to equipment.
  • Positioning of equipment and cables such that airflow (cooling) is impeded.  As the density of equipment in racks increases, cooling becomes an increasingly important factor.  Poor rack design combined with dense rack utilization can contribute to internal rack temperatures significantly higher than ambient room temperatures.
10.6.16.

Standardising rack layout and cable management also assists in the maintenance of separation and segregation between RED/BLACK systems.

Standardised Rack Configuration

10.6.17.

Separate RED/BLACK racks are easier to manage, build and maintain and reduce the opportunity for accidental or deliberate cross-connection of RED/BLACK systems.  Ideally separate RED/BLACK racks should be used.

10.6.18.

In small installations (typically single workstation) shared racks are unavoidable.  In such cases a shared rack configuration is permissible provided separation elements and controls are properly implemented.  Extra care must be taken to avoid accidental cross-connection of systems.  The following illustrates a standardised shared rack configuration where RED/BLACK and power systems are separated:

References

10.6.19.

Further References avaliable below:

Title   Publisher  Source 
 ISO/IEC 11801-5:2017 - Data centres  ISO/IEC  https://www.iso.org/standards.html

ISO/IEC TR 14763-2-1 - Information technology -- Implementation and operation of customer premises cabling -- Part 2-1: Planning and installation - Identifiers within administration systems

 ISO/IEC  https://www.iso.org/standards.html

TIA-606-B- Administration Standard for the Telecommunications Infrastructure of Commercial Buildings

 ANSI  https://www.ansi.org

ANSI/TIA-942 Telecommunications Infrastructure Standard for Data Centers

 ANSI  https://www.ansi.org

PD IEC/TR 62691:2016-Optical fibre cables. Guidelines to the installation of optical fibre cables

International Electrotechnical
Commission (IEC) Available through Standards New Zealand

 https://www.standards.govt.nz
PD IEC/TR 62362:2010 - Selection of optical fibre cable specifications relative to mechanical, ingress, climatic or electromagnetic characteristics.

Guidance

International Electrotechnical
Commission (IEC) Available through Standards New Zealand

 https://www.standards.govt.nz
IEC 60794-2-31 Ed. 2.0 b(2012) - Optical fibre cables - Part 2-31: Indoor cables - Detailed specification for optical fibre

ribbon cables for use in premises cabling

International Electrotechnical
Commission (IEC) Available through Standards New Zealand

 https://www.standards.govt.nz

IEC 60794-2-11 Ed. 2.0 b(2012)-Optical fibre cables - Part 2-11: Indoor optical fibre cables - Detailed specification for simplex and duplex cables for use in premises cabling

International Electrotechnical
Commission (IEC) Available through Standards New Zealand

 https://www.standards.govt.nz
AS/NZS 2967:2014 Optical fibre communication cabling systems safety

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS 14763.3:2017 Information technology - Implementation and operation of customer premises cabling - Part 3: Testing of optical fibre cabling

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS IEC 60825.2:2011 Safety of laser products - Part 2: Safety of optical fibre communication systems (OFCS)

Standards New Zealand

 
https://www.standards.govt.nz 

AS/NZS ISO/IEC 24764:2012 - Generic cabling systems for data centres

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS 61386.1:2015 - Conduit systems for cable management - Part 1: General requirements

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS 61386.21:2015 - Conduit systems for cable management - Part 21: Particular requirements - Rigid conduit systems

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS 61386.22:2015 - Conduit systems for cable management - Part 22: Particular requirements - Pliable conduit systems

Standards New Zealand  https://www.standards.govt.nz

AS/NZS 61386.23:2015 - Conduit systems for cable management - Part 23: Particular requirements - Flexible conduit systems

Standards New Zealand

 https://www.standards.govt.nz

AS/NZS ISO/IEC 29125:2012 - Telecommunications cabling requirements for remote powering of data terminal equipment

Standards New Zealand

 https://www.standards.govt.nz

BS EN 61300-2-37:2016 - Fibre optic interconnecting devices and passive components. Basic test and measurement procedures. Tests. Cable bending for fibre optic closures

British Standards Institution (BSI) Available through Standards New Zealand

 https://www.standards.govt.nz

BS EN 60794-2-31:2013 - Optical fibre cables. Indoor cables. Detailed
specification for optical fibre ribbon cables for use in premises cabling

British Standards Institution (BSI) Available through Standards New Zealand

 https://www.standards.govt.nz
BS EN 50411-2:2008 - Fibre organisers and closures to be used in optical fibre

communication systems. Product specifications. General and guidance
for optical fibre cable joint closures, protected microduct closures, and
microduct connectors

British Standards Institution (BSI) Available through Standards New Zealand

 https://www.standards.govt.nz

BS EN 60794-2-30:2008 - Optical fibre cables. Indoor cables. Family
specification for ribbon cables

British Standards Institution (BSI) Available through Standards New Zealand

 https://www.standards.govt.nz

BS EN 60794-2-21:2012 - Optical fibre cables. Indoor optical fibre cables.
Detailed specification for multi-fibre optical distribution cables for use in
premises cabling

British Standards Institution (BSI) Available through Standards New Zealand

 https://www.standards.govt.nz

Rationale & Controls

10.6.20. Terminations to patch panels

10.6.20.R.01.Rationale

Cross-connecting a system to another system of a lesser classification through a patch panel may result in a data spill. A data spill could result in the following issues:

  • inadvertent or deliberate access to information and systems by non-cleared personnel; and/or
  • information spilling to a system of another classification.
10.6.20.R.02.Rationale

Cross-connecting Cables run to patch panels are best managed by bundling similar classifications or groups together.  RED/BLACK separations should be maintained at all times.  A simple approach to this is to bundle and run RED cables up vertical rails of the cabinet and BLACK cables up the opposite side.  Where multiple cabinets are installed sides may be alternated to ensure RED/RED and BLACK/BLACK groupings are maintained by running cables groups up/down/across separate rails in the cabinet or in separate conduits.

10.6.20.C.01.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2425]

Agencies MUST ensure that only approved cable groups terminate on a patch panel.

10.6.20.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:5607]

RED and BLACK cables must be separated and bundled.

10.6.21. Patch cable and fly lead connectors

10.6.21.R.01.Rationale

Cables equipped with connectors specific to a classification will prevent inadvertent cross-connection. These connectors can be keyed or have specific profiles to prevent connection to other systems.

10.6.21.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2428]

In areas containing cabling for multiple classifications, agencies MUST ensure that the connectors for each classification are distinct and different to those of the other classifications.

10.6.21.C.02.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2429]

In areas containing cabling for multiple classifications, agencies MUST document the selection of connector types for each classification.

10.6.21.C.03.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2430]

In areas containing cabling for systems of different classifications, agencies SHOULD ensure that the connectors for each system are different to those of the other systems.

10.6.21.C.04.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2431]

In areas containing cabling for systems of different classifications, agencies SHOULD document the selection of connector types.

10.6.22. Physical separation of patch panels

10.6.22.R.01.Rationale

Appropriate physical separation between systems classified CONFIDENTIAL or above and a system of a lesser
classification (RESTRICTED and below) will:

  • reduce or eliminate the chances of cross patching between the systems; and
  • reduce or eliminate the possibility of unauthorised personnel or personnel gaining access to classified system elements.

Refer also to 10.1 – Cable Management Fundamentals for the discussion on RED/BLACK concept and cable separation.

10.6.22.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:2434]

Agencies SHOULD physically separate patch panels of different classifications by installing them in separate cabinets.

10.6.22.C.02.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2435]

Where spatial constraints demand patch panels of different classification are located in the same cabinet, agencies MUST:

  • provide a physical barrier within the cabinet to separate patch panels;
  • ensure that only personnel cleared to the highest classification of the circuits in the panel have access to the cabinet; and
  • obtain approval from the relevant Accreditation Authority prior to installation.

10.6.23. Cabinet Arrangement

10.6.23.R.01.Rationale

Standardised layout of rack and cabinets facilitates maintenance and reduces risk of accidental cross-connects.  Cabinets may also include UPS or other power supply equipment which is most appropriately housed at the bottom of the cabinet.  RED/BLACK separations of equipment and cables should be maintained.  Refer to 10.6.16 in the Context above.

10.6.23.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:5610]

Agencies SHOULD arrange the installation of cabinets as follows:

  • RED equipment at the top;
  • BLACK equipment in the centre;
  • Power equipment at the bottom.

10.6.24. Rack Diagrams

10.6.24.R.01.Rationale

A rack diagram is a two-dimensional elevation drawing showing the layout or arrangement of equipment on a rack.  It may show the front and the rear elevation of the rack layout.  It does not have to be drawn to scale.   This provides essential information when maintenance or development is undertaken or new equipment installed.

10.6.24.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:5613]

Agencies SHOULD record equipment layouts and other relevant information on rack diagrams.

10.6.25. Fly lead installation

10.6.25.R.01.Rationale

Keeping the lengths of fly leads to a minimum prevents clutter around desks, prevents damage to fibre optic cabling and reduces the chance of cross patching and tampering. If lengths become excessive then agencies will need to treat the cabling as infrastructure and run it in conduit or fixed infrastructure such as desk partitioning. Secure patch cords properly to keep them off the floor or the base of racks, where they can be stepped on.

10.6.25.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:2438]

Agencies SHOULD ensure that the fibre optic fly leads used to connect wall outlets to IT equipment either:

  • do not exceed 5m in length; or
  • if they exceed 5m in length:
    • are run in the facility’s fixed infrastructure in a protective and easily inspected pathway;
    • are clearly labelled at the equipment end with the wall outlet designator; and
    • are approved by the Accreditation Authority.

 

10.6.26. Earthing and Bonding

10.6.26.R.01.Rationale

It is important that any metal trays or metal catenary are earthed for both safety and to avoid creating any fortuitous conductors.  Effective earthing also depends on properly bonding all conductive elements of a cabinet, rack or case housing any equipment.  Bonding requires good mechanical and electrical connection between conductive elements through bolts and nuts and/or earth straps or jump leads.  Specialist bonding hardware is widely available.

10.6.26.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:5621]

All earthing points MUST be equipotentially bonded.

10.6.26.C.02.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:5623]

All conductive elements of a cabinet, rack or case housing any equipment MUST be earth bonded.

10.6.27. Cable Management

10.6.27.R.01.Rationale

Good cable management facilitates maintenance, promotes air flow and cooling, reduces risk of accidental cross-connects or disconnects and supports safe operation.

10.6.27.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:5626]

Cabinet rails MUST be installed to

  • § provide adequate room for patch cables and wire managers
  • § Adequate space for cable management at front, sides, and rear
  • § Arrange switches and patch panels to minimize patching between cabinets & racks

10.6.28. Labelling Cables

10.6.28.R.01.Rationale

The labelling principles include the following:

  • Labelling is logical and consistent, across all locations, matching the project drawings.
  • The labelling scheme identifies any associated physical locations (building, room, cabinet, rack, port, etc.)
  • Labelling is easily read, durable, and capable of surviving for the life of the component that was labelled.
  • The labelling system, and the identifiers used, are agreed upon by all stakeholders .
  • Labelling is all-encompassing and include cables, connecting hardware, conduits, firestops, grounding and bonding locations, racks, cabinets, ports, and telecommunications spaces.
10.6.28.R.02.Rationale

Specific labelling requirements include:

  • All labels use a permanent identifier;
  • The labelling/numbering scheme is logical in its organisation, using alphanumeric characters for ease of reference.
  • Each cable and each pathway is labelled on each end, and each label identifies the termination points of both ends of the cable.
  • All labels are legible, defacement resistance, and have high adhesion characteristics and durability.
  • Labels are placed so they can be read without disconnecting a cable.
  • Labels for station connections may appear on the face plate.
  • All jack, connector, and block hardware are be labelled on either the outlet or panel.
  • All labels match with the any installation and maintenance records.
10.6.28.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:5627]

Agencies SHOULD implement the principles and specific cable labelling requirements described above.

10.6.29. Power Cords

10.6.29.R.01.Rationale

It is important to separate copper data cables and power cables as all power feeds, line and connectors have the potential to emanate, create magnetic fields and cause interference with copper data cables if laid in close proximity to each other.  Good practice is to:

  • Label power cords at both ends to minimise the risk inadvertently disconnecting the wrong power cord;
  • Colour code power cords and power strips;
  • Use locking power cords, receptacles, or retention clips.
10.6.29.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:5619]

Agencies SHOULD follow best practice described above for the installation of power cables.

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.7. Emanation Security Threat Assessments

Objective

10.7.1.

In order to minimise compromising emanations or the opportunity for a technical attack, a threat assessment is used to determine appropriate countermeasures.

Context

Scope

10.7.2.

This section relates to emanation security threat assessment advice and identification of appropriate countermeasures to minimise the loss of classified information through compromising emanations or a technical attack.

10.7.3.

This section is applicable to:

  • agencies located outside New Zealand;
  • secure facilities within New Zealand; and
  • mobile platforms and deployable assets that process classified information.

References

10.7.4.

Information on conducting an emanation security threat assessment and additional information on cabling and separation standards, as well as the potential dangers of operating RF transmitters in proximity to classified systems, is documented in:

Title Publisher Source

NZCSS400 Installation Engineering

GCSB

CONFIDENTIAL document available on application to authorised personnel

NZCSI 403B TEMPEST Threat and Countermeasures Assessment

GCSB

CONFIDENTIAL document available on application to authorised personnel

NZCSI 420 Laboratory Tempest Test Standard for Equipment in Controlled Environments

GCSB

CONFIDENTIAL document available on application to authorised personnel

PSR references

10.7.5.

Relevant PSR requirements can be found at:

Reference Title Source

PSR Mandatory Requirements

INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2

http://www.protectivesecurity.govt.nz

https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

PSR content protocols

Management protocol for information security

Management protocol for physical security

https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

PSR requirements sections

Security zones

Validate your security measures

Use multiple layers of security - 'defence in depth'

https://www.protectivesecurity.govt.nz/security-zones/

https://www.protectivesecurity.govt.nz/information-security/understand-the-information-security-lifecycle/validate-your-security-measures/

https://www.protectivesecurity.govt.nz/information-security/understand-the-information-security-lifecycle/design-fit-for-purpose-information-security-measures/use-multiple-layers-of-security-defence-in-depth/

Managing specific scenarios

Secure your ICT facilities

Physical Security for ICT systems

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

Resource centre

Email fraud: an INFOSEC case study

 

Rationale & Controls

10.7.6. Emanation security threat assessments within New Zealand

10.7.6.R.01.Rationale

Obtaining the current threat advice from GCSB on potential adversaries and threats and applying the appropriate countermeasures is vital in maintaining the confidentiality of classified systems from an emanation security attack.

10.7.6.R.02.Rationale

Failing to implement recommended countermeasures against an emanation security attack can lead to compromise. Having a good cable infrastructure and installation methodology will provide a strong backbone that will not need updating if the threat increases. Infrastructure is very expensive and time consuming to retro-fit.

10.7.6.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2454]

Agencies designing and installing systems with RF transmitters within or co-located with their facility MUST:

  • contact GCSB for guidance on conducting an emanation security threat assessment; and
  • install cabling and equipment in accordance with this manual plus any specific installation criteria derived from the emanation security threat assessment.
10.7.6.C.02.Control: 
System Classification(s): All Classifications; Compliance: MUST [CID:2455]

Agencies designing and installing systems with RF transmitters that co-locate with systems of a classification CONFIDENTIAL and above MUST:

  • contact GCSB for guidance on conducting an emanation security threat assessment; and
  • install cabling and equipment in accordance with this manual plus any specific installation criteria derived from the emanation security threat assessment.

 

10.7.7. Emanation security threat assessment outside New Zealand

10.7.7.R.01.Rationale

Fixed sites and deployed military platforms are more vulnerable to emanation security attack and require a current threat assessment and countermeasure implementation. Failing to implement recommended countermeasures and standard operating procedures to reduce threats could result in the platform emanating compromising signals which, if intercepted and analysed, could lead to platform compromise with serious consequences.

10.7.7.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2458]

Agencies deploying systems overseas in temporary, mobile or fixed locations MUST:

  • contact GCSB for assistance with conducting an emanation security threat assessment; and
  • install cabling and equipment in accordance with this manual plus any specific installation criteria derived from the emanation security threat assessment.
10.7.7.C.02.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2459]

Agencies deploying systems overseas SHOULD:

  • contact GCSB for assistance with conducting an emanation security threat advice; and
  • install cabling and equipment in accordance with this document plus any specific installation criteria derived from the emanation security threat assessment.

10.7.8. Early identification of emanation security issues

10.7.8.R.01.Rationale

The identification of emanation security controls that need to be implemented for a system at an early stage in the project lifecycle. This can significantly affect project costs. Costs are invariably greater where changes are necessary once the system had been designed or has been implemented.

10.7.8.C.01.Control: 
System Classification(s): All Classifications; Compliance: SHOULD [CID:2463]

Agencies SHOULD conduct an emanation security threat assessment as early as possible in project lifecycles.

10.7.9. IT equipment in SECURE areas

10.7.9.R.01.Rationale

All equipment must conform to applicable industry and government standards, including NZCSI 420; Laboratory Tempest Test Standard for Equipment in Controlled Environments. Not all equipment within a secure facility in New Zealand requires testing against TEMPEST standards.

10.7.9.C.01.Control: 
System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2465]

Agencies MUST ensure that IT equipment within secure areas meet industry and government standards relating to electromagnetic interference/electromagnetic compatibility. 

img of download icon
Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

10.8. Network Design, Architecture and IP Address Management

Objective

10.8.1.

IP Address architecture, allocation and addressing schemes enable and support system security and data protection.

Context

Scope

10.8.2.

This section includes discussion of the principles of separation and segregation as network design and network architecture characteristics.  It also discusses how IP addresses can be used to support these principles for improved security of larger or multi-classification agency systems.

Background

10.8.3.

The larger the network, the more difficult it is to protect.  A large, unsegmented network presents a large attack surface with greater susceptibility to the rapid spread and dissemination of system faults, weaknesses, vulnerabilities and attacks.  In a non-segmented network, traffic and applications generally have access to the entire network. If a fault occurs or an attacker gains entry, the fault or attacker can move laterally through the network causing disruption, network outages and enabling access to critical operational or classified data.

10.8.4.

A large network is also more difficult to monitor and control.  Segmenting the network limits an attacker’s ability to move through the network by preventing lateral movement between zones.  Segmentation also enhances the ability to detect, monitor, control, isolate and correct faults.

10.8.5.

A fundamental construct in the management of risk in networks is that of Trust Zones and Trust Boundaries.  A Trust Zone is a zoning construct based on levels of trust, classification, information asset value and essential information security.  A Trust Boundary is the interface between two or more Trust Zones. Trust Zones use the principles of separation and segregation to manage sensitive information assets and ensure security policies are consistently applied to all assets in a particular Trust Zone.  Refer also to Section 22.1 – Cloud Computing and Section 22.2 – Virtualisation.

Separation and Segregation

10.8.6.

Separation and Segregation are determined by system function and the sensitivity of the data the system stores, processes and transmits.  One common example is placing systems that require a connection to the Internet into a demilitarized zone (DMZ) that is separated and segregated (isolated) from more sensitive systems. Another example is the use of compartments.

10.8.7.

Separation and Segregation limits the ability of an intruder to exploit a vulnerability with the intent of elevating privileges to gain access to more sensitive systems on the internal network.  VLANs may be used to further separate systems by controlling access and providing segregation thus giving additional protection.

10.8.8.

Network segmentation is an effective strategy for protecting access to key data assets, and impeding the lateral movement of system faults, threats and malicious activity.  Segregation has the following benefits:

  • Enhanced performance: with fewer hosts per subnet, there is a reduced signalling and traffic overhead allowing more bandwidth for data communication.
  • Improved security: with less signalling traffic going through all network segments, it is more difficult for an attacker to analyse the addressing scheme and network structure.  Failures in one segment are less likely to propagate and more robust access control can be established and enforced.
10.8.9.

Effective segregation also requires:

  • Specialised knowledge: networks may support many devices with complex policies and rule sets.  Support staff must be properly educated and trained to ensure the network segmentation is maintained.
  • Administrative effort: changes in infrastructure, such as new applications and new technologies, can extend the time required to make changes and ensure the integrity of network segments.
  • Infrastructure Investment: segregation may require more equipment, new equipment with advanced functionalities, or specific software to deal with multiple segments.  These requirements should be considered during budget planning.

ISO 27001 and ISO 27002 implementation recommendations for network segregation

10.8.10.

These ISO Standards require the implementation of network segregation.  In particular they recommend that groups of information services, users, and information systems are segregated on networks.  Specific recommendations are summarised below:

  • Divide large networks into separate network domains (segments);
  • Consider physical and logical segregation;
  • Define domain perimeters;
  • Define traffic rules between domains;
  • Use authentication, encryption, and user-level network access control technologies;
  • Consider integration of the organisation’s network and segments with those of business partners.
10.8.11.

The following structures and techniques should be considered:

  • Criteria-based segmentation: Pre-define rules to establish perimeters and create new segments in order to reduce unnecessary redesign and future administrative overheads.  Examples of criteria are trust level (e.g., external public segment, staff segment, server segment, database segment, suppliers segment, etc.), organisational unit (e.g., Operations, Service Desk, Outreach, etc.), and combinations (e.g., external public access).
  • Use of physical and logical segmentation: Depending upon the risk level identified in the risk assessment, it may be necessary to use physically separated infrastructures to protect the organisation’s information and assets (e.g., classified data flowing through a dedicated fibre), or you may use solutions based on logical segmentation like Virtual Private Network (VPN).
  • Access rules for traffic flowing: Traffic between segments, including those of permitted external parties, should be controlled according to the need to access information.  Gateways should be configured based on information classification and risk assessment. A specific case of access control applies to wireless networks, since they have poor perimeter definition.  The recommendation is to treat wireless communication as an external connection until the traffic can reach a proper wired gateway before granting access to internal network segments. Refer also to Chapter 19 – Gateway Security.

Network Design

10.8.12.

A poorly designed network has increased support costs, reduced availability, security risks, and limited support for new applications and solutions.  Less-than-optimal performance affects end users and access to central resources. Some of the issues that stem from a poorly designed network may include the following:

  • Failure domains: One of the most important reasons to implement an effective network design is to minimise the spread and extent of faults.  When Layer 2 and Layer 3 boundaries are not clearly defined, failure in one network area can have a far-reaching effect.
  • Broadcast domains: Broadcasts exist in every network.  Many applications and network operations require broadcasts to function correctly; therefore, it is not possible to eliminate them completely.  In the same way that avoiding failure domains involves clearly defining boundaries, broadcast domains should have clear boundaries and include an optimal number of devices to minimise the negative impact of broadcasts.
  • MAC unicast flooding: Some switches limit unicast frame forwarding to ports that are associated with the specific unicast address.  However, when frames arrive at a destination MAC address that is not recorded in the MAC table, they are flooded out of the switch ports in the same VLAN except for the port that received the frame.  This behaviour is called unknown MAC unicast flooding.
  • Because this type of flooding causes excessive traffic on all the switch ports, network interface cards (NIC) must contend with a larger number of frames on the wire.  When data is propagated on a connection or network segment for which it was not intended, security can be compromised.
  • Multicast traffic on ports where it is not intended: IP multicast is a technique that allows IP traffic to be propagated from one source to a multicast group that is identified by a single IP and MAC destination-group address pair.  Similar to unicast flooding and broadcasting, multicast frames are flooded out all the switch ports. A robust design allows for the containment of multicast frames while allowing them to be functional.
  • Difficulty in management and support: Traffic flows can be difficult to identify in a poorly designed network.  This can make support, maintenance, and problem resolution time-consuming and difficult as well as creating security risks.
  • Possible security vulnerabilities: A switched network that has been designed with little attention to security requirements at the access layer can compromise the integrity of the entire network.
  • Criteria-based segmentation: Pre-define rules to establish perimeters and create new segments in order to reduce unnecessary redesign and future administrative overheads.  Examples of criteria are trust level (e.g., external public segment, staff segment, server segment, database segment, suppliers segment, etc.), organisational unit (e.g., Operations, Service Desk, Outreach, etc.), and combinations (e.g., external public access).

Design Implementation

10.8.13.

To assist in the implementation of separation and segregation as network design and architectural principles, the following aspects should be considered:

  • Classification;
  • Security Zones;
  • IP Address Management;
  • Central Information Repository;
  • Private Use of Reserved Addresses;
  • Devices with Default IP Addresses; and
  • Connector types and cable colours.

Classification

10.8.14.

Classified systems should, by definition, be segregated.  This is particularly important where network elements have access to compartments and compartmented data.

10.8.15.

Ideally compartmented elements of systems should be segregated and separated from the main network.  This may include the use of a reserved address space, monitored to detect violations or unauthorised attempts to connect to compartments or to access compartmented data.

Security Zones

10.8.16.

A security zone is a group of one or more physical or virtual firewall interfaces and the network segments connected to the zone’s interfaces.  Protection for each zone is individually specified and controlled so that each zone receives the specific protections it requires according to classification, endorsement, compartment and sensitivity of data.

IP Address Management

10.8.17.

The fundamental goal of an IP addressing scheme is to ensure network devices are uniquely addressed.  IP Address Schemes are a fundamental part of any network’s security architecture and should support network separation and segregation.  There are a number of techniques to assist in separating and segregating network elements. It is also useful to consider how to segregate and control network traffic through:

  • Defined network perimeters and boundaries; and
  • Defined network traffic rules.
10.8.18.

A well-structured IP addressing scheme promotes the ability to quickly identify node properties from an IP address which assist in network management and fault finding and rectification.

Address Block Allocation

10.8.19.

There are two main difficulties when assigning address blocks for types of devices.  First is that over time there is insufficient provision for additional devices and network growth.  When the allocated address block is exhausted, the addressing scheme is compromised (broken). The second is that you have a small number of devices in an address block, but are running out of addresses in other parts of the network.  If you “borrow” from a pre-assigned address range, the addressing scheme is also compromised.

10.8.20.

Internal IP address ranges are defined by the IETF.  Commonly known as RFC 1918 addresses, the most recent RFC is 6761.  These RFC’s define private IP address ranges which cannot be used for external (Internet) IP addressing.  Three address ranges (blocks) are defined:

IPv4 Address Range Network IPv4 address Block Directed Broadcast IPv4 address IPv4 Addresses
10.0.0.0 to 10.255.255.255 10.0.0.0/8 10.255.255.255 16,777,216
172.16.0.0 to 172.31.255.255 172.16.0.0/12 172.31.255.255 1,048,576
192.168.0.0 to 192.168.255.255 192.168.0.0/16 192.168.255.255 65,536
10.8.21.

IPv4 addresses are 32-bit binary addresses, divided into 4-Octets and normally represented in a decimal format.  An example of IPv4 address is 192.168.100.10.  IPv6 addresses are so much larger than IPv4 addresses and impractical to clearly represent in decimals.  IPv6 addresses are usually represented in hexadecimal numbers, separated by a colon.  An example of an IPv6 address is 2001:0DB8:0000:0002:0022:2217:FF3B:118C.  Private IPv6 addresses are specified in RFC 4193

10.8.22.

Private addressing is a means of distinguishing networks, assisting in separation and segregation.

Private use of reserved addresses

10.8.23.

Some IP addresses have been reserved in IETF standards.  Despite official warnings, some organisations use parts of the reserved IP address space for their internal networks where address space is exhausted or poorly designed.  This creates conflicts with devices and signalling traffic protocols which can create network faults, anomalies and network outages. This practice is strongly discouraged.

Devices which have default IP addresses

10.8.24.

Some devices are supplied with default IP addresses.  If using the IETF RFC 1918 addressing protocol (e.g. 10.0.x.x) some devices may have been allocated the same (duplicate) IP address.

10.8.25.

It is important to change default addresses to new addresses that conform with the addressing scheme selected for the agency.

DHCP

10.8.26.

In theory, there is only one network device that absolutely needs a true static address, the DHCP server.  In practice, it is preferable to assign address blocks to major groups of devices for control, fault isolation and security purposes.  Traditionally static devices are provided with a reserved address. These devices may include:

  • DCHP Server;
  • Gateway devices;
  • Firewalls;
  • Routers; and
  • Switches.
10.8.27.

The majority of other devices can be allocated a DHCP address.

10.8.28.

It is important to identify the essential device groups using a risk assessment, operational characteristics, level of security, system classification and other relevant architectural features, business requirements and operational constraints.

Connector Types and Cable Colours

10.8.29.

Cable management is discussed in detail earlier in this chapter.  In particular note the discussion (10.1.4) of Red/Black concepts which includes separation of electrical and electronic circuits, devices, equipment cables, connectors and systems that transmit store or process national security information (Red) from non-national security information (Black)

10.8.30.

Wherever practical and possible, connectors for systems of different classifications should be distinct and be selected to avoid accidental cross-connection of systems of different classifications.  This can be achieved through the use of colour and keyed connectors where the colour and keying is different for each classification level or compartment (refer also to 10.1.30 and 10.6.6).

Central Information Repository

10.8.31.

Creating a central repository of all the information on networks, IP addresses and devices, is critical to maintaining control of the network.  The challenge with traditional tools is that there are often specific tools for each category of devices: one system to track virtual machines, one system to track wireless users, one system to track Windows servers, one system to track Linux machines, etc.

10.8.32.

A single repository where all the data relevant to networks, hosts, servers, dynamic clients, and virtual environments can be tracked and synchronised is essential for larger networks.  The ability to search across all this information will enable network teams to quickly track changing network landscapes and rapidly troubleshoot issues as they arise. In addition, business data related to a network resource helps bind together the logical network construct and the reality of IT resources.

References

10.8.33.

Further references can be found at:

    Title Publisher Source
    Network Segmentation and Segregation ASD https://www.asd.gov.au/publications/protect/network_segmentation_segregation.htm
    Cisco on Cisco Best Practices – Cisco IP Addressing Policy Cisco https://www.cisco.com/c/dam/en_us/about/ciscoitatwork/downloads/ciscoitatwork/pdf/Cisco_IT_IP_Addressing_Best_Practices.pdf
    IP Addressing and Subnetting for New Users, Document ID: 13788 Cisco https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13788-3.pdf
    IP Addressing: IPv4 Addressing Configuration Guide, Cisco IOS Release 15S Cisco https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_ipv4/configuration/15-s/ipv4-15-s-book.html
    Introduction to Server and Domain Isolation Microsoft https://technet.microsoft.com/en-us/library/cc725770(v=WS.10).aspx
    ISO/IEC 27001:2013  - Information technology -- Security techniques -- Information security management systems -- Requirements ISO https://www.iso.org
    ISO/IEC 27002:2013  - Information technology -- Security techniques -- Code of practice for information security controls ISO https://www.iso.org
    RFC-1518 - An Architecture for IP Address Allocation with CIDR IETF https://tools.ietf.org/html/rfc1518
    RFC-1918 – Address Allocation for Private Internets IETF https://tools.ietf.org/html/rfc1918
    RFC 2036 – Observations on the use of Components of the Class A Address Space within the Internet IETF https://tools.ietf.org/html/rfc2036
    RFC 2050 – Internet Registry IP Allocation Guidelines IETF https://tools.ietf.org/html/rfc2050
    RFC 2101 – IPv4 Address Behaviour Today IETF https://tools.ietf.org/html/rfc2101
     RFC 2401 - Security Architecture for the Internet Protocol IETF https://tools.ietf.org/html/rfc4301
    RFC 2663 – IP Network Address Translator (NAT) Terminology and Considerations IETF https://tools.ietf.org/html/rfc2663
    RFC 2894 - Router Renumbering for IPv6 IETF https://tools.ietf.org/html/rfc2894
    RFC 3022 – Traditional IP Network Address Translator (Traditional NAT) IETF https://tools.ietf.org/html/rfc3022
    RFC 3053 - IPv6 Tunnel Broker IETF https://tools.ietf.org/html/rfc3053
    RFC 3056 - Connection of IPv6 Domains via IPv4 Clouds IETF https://tools.ietf.org/html/rfc3056
    RFC 3232 - Assigned Numbers IETF https://tools.ietf.org/html/rfc3232
    RFC 3260 – New Terminology and Clarifications for Diffserv IETF https://tools.ietf.org/html/rfc3260
    RFC 3330 – Special-Use IPv4 Addresses" (superseded) IETF https://tools.ietf.org/html/rfc3330
    FC 3879 – Deprecating Site Local Addresses  IETF https://tools.ietf.org/html/rfc3879
    RFC 3927 – Dynamic Configuration of IPv4 Link-Local Addresses IETF https://tools.ietf.org/html/rfc3927 
    RFC 3956 - Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address IETF https://tools.ietf.org/html/rfc3956
    RFC 4193 – Unique Local IPv6 Unicast Addresses  IETF https://tools.ietf.org/html/rfc4193 
    RFC-4632 - Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan  IETF https://tools.ietf.org/html/rfc4632 
    RFC 5214 - Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)  IETF https://tools.ietf.org/html/rfc5214 
    RFC 5737 - IPv4 Address Blocks Reserved for Documentation  IETF https://tools.ietf.org/html/rfc5737
    RFC 6040 - Tunnelling of Explicit Congestion Notification  IETF https://tools.ietf.org/html/rfc6040
    RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators  IETF https://tools.ietf.org/html/rfc6052
    RFC 6081 - Teredo Extensions  IETF https://tools.ietf.org/html/rfc6081
    RFC 6434 - IPv6 Node Requirements IETF https://tools.ietf.org/html/rfc6434
    RFC 6598 – Reserved IPv4 Prefix for Shared Address Space IETF https://tools.ietf.org/html/rfc6598
    RFC 6761 - Special-Use Domain Names IETF https://tools.ietf.org/html/rfc6761
    RFC 6890 – Special-Purpose IP Address Registries  IETF https://tools.ietf.org/html/rfc6890
    RFC 7371 - Updates to the IPv6 Multicast Addressing Architecture  IETF https://tools.ietf.org/html/rfc7371
    RFC 7619 - The NULL Authentication Method
    in the Internet Key Exchange Protocol Version 2 (IKEv2)
     
    IETF https://tools.ietf.org/html/rfc7619
    RFC 8012 - Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) IETF https://tools.ietf.org/html/rfc8012
    RFC 8190 - Updates to the Special-Purpose IP Address Registries  IETF https://tools.ietf.org/html/rfc8190

    Rationale & Controls

    10.8.34. Risk Assessment

    10.8.34.R.01.Rationale

    A risk assessment is a fundamental tool in the architecture and design of a network. 

    10.8.34.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:5815]

    Agencies MUST conduct and document a risk assessment before creating an architecture, and designing an agency network.

    10.8.34.C.02.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:5816]

    The principles of separation and segregation as well as the system classification MUST be incorporated into the risk assessment.

    10.8.35. Security Architecture

    10.8.35.R.01.Rationale

    It is important that the principles of separation and segregation as well as the system classification are incorporated into the overall security architecture to maximise design and operational efficiency and to provide and support essential security to the network design.

    10.8.35.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:5820]

    Security architectures MUST apply the principles of separation and segregation.

    10.8.36. Identification of major classifications/categories of network segments

    10.8.36.R.01.Rationale

    Identified in the risk assessment, it is essential that the classification of systems is clearly identified and is apparent in all architecture and design elements and systems documentation.

    10.8.36.R.02.Rationale

    Clear distinction of networks of different classifications is reinforced through the use of different IP addressing schemes as well as the application of Red/Black, separation and segregation concepts and principles.  Refer also to section 10.1.

    10.8.36.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:5825]

    The classification and other restrictions on the security and control of information MUST be clearly identified for each part of the Agency network.

    10.8.37. Visibility

    10.8.37.R.01.Rationale

    Clear identification and visibility of the classifications or category of a network segment is essential in minimising accidental cross-connections, incident management and in limiting the propagation of errors form one segment to others.  This also assists in network maintenance and management.

    10.8.37.R.02.Rationale

    Clear visual identification is supported by the use of IP addressing and cable colour schemes as well as the use of different types of cable connectors for different network segments.

    10.8.37.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:5843]

    Systems of different classifications MUST be visually distinct.

    10.8.38. Information Repository

    10.8.38.R.01.Rationale

    Clear documentation and records of changes to the architecture and construct of a network are essential in change management, planning, design of network modifications, incident management and maintenance of a strong security posture.

    10.8.38.R.02.Rationale

    A single repository where all the data relevant to networks, hosts, servers, dynamic clients, and virtual environments can be tracked and synchronised is essential for larger networks.  The ability to search across all this information will enable network teams to quickly track changing network landscapes and rapidly troubleshoot issues as they arise.

    10.8.38.R.03.Rationale

    The repository should also contain business data related to a network resource which helps manage necessary changes and upgrades to a network in a fashion that appropriately allocates IT resources and recognises business needs.

    10.8.38.C.01.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:5831]

    An information repository, containing essential network information, change records and business requirements SHOULD be established and maintained.

    11. Communications Systems and Devices

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.1. Radio Frequency and Infrared Devices

    Objective

    11.1.1.

    To maintain the integrity of secure areas, only approved radio frequency (RF) and infrared devices (IR) are brought into secure areas.

    Context

    Scope

    11.1.2.

    This section covers information relating to the use of RF and infrared devices in secure areas. Information on the use of RF devices outside secure areas can be found in Chapter 21 - Working Off-Site.

    11.1.3.

    RF devices include any transmitter on any frequency, including mobile phones, cordless phones, Bluetooth, Wi-Fi, RFID and other similar devices.

    Exemptions for the use of infrared and laser devices

    11.1.4.

    An infrared device and laser device can be used in a secure area provided it does not have the potential to communicate classified information.

    Exemptions for the use of RF devices

    11.1.5.

    The following devices, at the discretion of the Accreditation Authority, can be exempted from the controls associated with RF transmitters:

    • pagers that can only receive messages;
    • garage door openers;
    • car lock/alarm keypads; 
    • medical and exercise equipment that uses RF to communicate between sub-components;
    • access control sensors; and
    • laser pointers.

    References

    11.1.6.
    Title Publisher Source

    NIST 800-121 Guide to Bluetooth Security

    NIST http://csrc.nist.gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf

    PSR references

    11.1.7.

    Relevant PSR requirements can be found at:

    Reference Title Source
     PSR Mandatory Requirements GOV2, INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2

    http://www.protectivesecurity.govt.nz

    https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/ 

    https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

    https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

     PSR content protocols

    Management protocol for information security

    Management protocol for physical security

    https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

    https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/

     PSR requirements sections

    Security zones

     

    https://www.protectivesecurity.govt.nz/security-zones/

     Managing specific scenarios

    Secure your ICT facilities

    Mobile and remote working

    Physical Security for ICT systems

    Communication security

    https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

    https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/mobile-and-remote-working/

    https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

    https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/communications-security/

    Rationale & Controls

    11.1.8. Pointing devices

    11.1.8.R.01.Rationale

    Wireless RF pointing devices can pose an emanation security risk. They are not to be used in secure areas unless within a RF screened building.

    11.1.8.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2483]

    Wireless RF pointing devices MUST NOT be used in secure areas unless used within a RF screened building or RF mitigations are implemented.

    11.1.9. Infrared keyboards

    11.1.9.R.01.Rationale

    When using infrared keyboards with CONFIDENTIAL or SECRET systems, drawn opaque curtains are an acceptable method of protecting windows and managing line of sight and reflected transmissions.

    11.1.9.R.02.Rationale

    When using infrared keyboards with a TOP SECRET system, windows with curtains that can be opened are NOT acceptable as a method of permanently blocking infrared transmissions. While infrared transmissions are generally designed for short range (5 to 10 metres) manufacturing and design variations and some environmental conditions can amplify and reflect infrared over much greater distances.

    11.1.9.C.01.Control: 
    System Classification(s): Confidential, Secret; Compliance: MUST NOT [CID:2487]

    Agencies using infrared keyboards MUST NOT allow:

    • line of sight and reflected communications travelling into an unsecure area;
    • multiple infrared keyboards at different classifications in the same area;
    • other infrared devices to be brought into line of sight of the keyboard or its receiving device/port; and
    • infrared keyboards to be operated in areas with unprotected windows.
    11.1.9.C.02.Control: 
    System Classification(s): Top Secret; Compliance: MUST NOT [CID:2488]

    Agencies using infrared keyboards MUST NOT allow:

    • line of sight and reflected communications travelling into an unsecure area;
    • multiple infrared keyboards at different classifications in the same area;
    • other infrared devices within the same area; and
    • infrared keyboards in areas with windows that have not had a permanent method of blocking infrared transmissions applied to them.
    11.1.9.C.03.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2489]

    Agencies using infrared keyboards SHOULD ensure that infrared ports are positioned to prevent line of sight and reflected communications travelling into an unsecure area.

    11.1.10. Bluetooth and wireless keyboards

    11.1.10.R.01.Rationale

    As the Bluetooth protocol provides little security and wireless keyboards often provide no security, they cannot be relied upon for the protection of classified information. As with infrared transmissions Bluetooth transmissions can reach considerable distances.

    11.1.10.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2492]

    Agencies MUST complete a technical evaluation of the secure area before the use of Bluetooth keyboards or other Bluetooth devices are permitted.

    11.1.10.C.02.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2494]

    Agencies using Bluetooth keyboards or other Bluetooth devices MUST NOT allow:

    • line of sight and reflected communications travelling into an unsecure area;
    • multiple keyboards or other devices at different classifications in the same area;
    • other Bluetooth or infrared devices to be brought into range of the keyboard or its receiving device/port; and
    • Bluetooth keyboards or other devices to be operated in areas with unprotected (non-shielded/curtained) windows.
    11.1.10.C.03.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2495]

    Agencies MUST NOT use Bluetooth or wireless keyboards unless within a RF screened building.

    11.1.11. RF devices in secure areas

    11.1.11.R.01.Rationale

    RF devices pose security threat as they are capable of picking up and transmitting classified background conversations. Furthermore, many RF devices can connect to IT equipment and act as unauthorised data storage devices or bridge “air gaps”.

    11.1.11.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2497]

    Agencies MUST prevent RF devices from being brought into secure areas unless authorised by the Accreditation Authority.

    11.1.11.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2498]

    Agencies SHOULD prevent RF devices from being brought into secure areas unless authorised by the Accreditation Authority.

    11.1.12. Detecting RF devices in secure areas

    11.1.12.R.01.Rationale

    As RF devices are prohibited in secure areas, agencies should deploy technical measures to detect and respond to the unauthorised use of such devices.

    11.1.12.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:2501]

    Agencies SHOULD deploy measures to detect and respond to active RF devices within secure areas.

    11.1.13. RF controls

    11.1.13.R.01.Rationale

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

    11.1.13.C.01.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2504]

    Agencies SHOULD limit the effective range of communications outside the agency’s area of control by:

    • minimising the output power level of wireless devices; 
    • RF shielding; and
    • Physical layout and separation.

     

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.2. Fax Machines, Multifunction Devices and Network Printers

    Objective

    11.2.1.

    Fax machines, multifunction devices (MFD’s) and network printers are used in a secure manner.

    Context

    Scope

    11.2.2.

    This section covers information relating to fax machines, MFDs and network printers connected to either the ISDN, PSTN, HGCE or other networks. Further information on MFDs communicating via network gateways can be found in Section 20.2 - Data Import and Export.

    Rationale & Controls

    11.2.3. Fax machine, MFD and network printer usage policy

    11.2.3.R.01.Rationale

    Fax machines, MFDs and network printers are capable of communicating classified information, and are a potential source of information security incidents. It is therefore essential that agencies develop a policy governing their use.

    11.2.3.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2537]

    Agencies MUST develop a policy governing the use of fax machines, MFDs, and network printers.

    11.2.4. Sending fax messages

    11.2.4.R.01.Rationale

    Once a fax machine or MFD has been connected to cryptographic equipment and used to send a classified fax message it can pose risks if subsequently connected directly to unsecured telecommunications infrastructure or the public switched telephone network (PSTN). For example, if a fax machine fails to send a classified fax message the device will continue attempting to send the fax message even if it has been disconnected from the cryptographic device and connected directly to the public switched telephone network. In such cases the fax machine could then send the classified fax message in the clear causing an information security incident.

    11.2.4.R.02.Rationale

    Non-encrypted communications may be exposed in transmission and, if incorrectly addressed or an incorrect recipient number is entered, may cause a data breach.

    11.2.4.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2543]

    Agencies sending classified fax messages MUST ensure that the fax message is encrypted to an appropriate level when communicated over unsecured telecommunications infrastructure or the public switched telephone network.

    11.2.4.C.02.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2545]

    Agencies MUST have separate fax machines or MFDs for sending classified fax messages and messages classified RESTRICTED and below.

    11.2.5. Sending fax messages using HGCE

    11.2.5.R.01.Rationale

    The establishment and use of appropriate procedures for sending a classified fax message will ensure that it is sent securely to the correct recipient.

    11.2.5.R.02.Rationale

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

    11.2.5.R.03.Rationale

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

    11.2.5.R.04.Rationale

    Overseeing the receipt and transmission of fax messages, clearing equipment memory after use and then powering off the equipment will prevent unauthorised access to this information.

    11.2.5.R.05.Rationale

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

    11.2.5.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2557]

    Agencies intending to use fax machines or MFDs to send classified information MUST comply with additional requirements. Contact the GCSB for further details.

    11.2.6. Receiving fax messages

    11.2.6.R.01.Rationale

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

    11.2.6.C.01.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2562]

    The sender of a fax message SHOULD make arrangements for the receiver to:

    • collect the fax message as soon as possible after it is received; and
    • notify the sender immediately if the fax message does not arrive when expected.

    11.2.7. Connecting MFDs to telephone networks

    11.2.7.R.01.Rationale

    When a MFD is connected to a computer network and a telephone network the device can act as a bridge between the networks. As such the telephone network needs to be accredited to the same classification as the computer network the MFD is connected to.

    11.2.7.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2568]

    Agencies MUST NOT enable a direct connection from a MFD to a telephone network unless the telephone network is accredited to at least the same classification as the computer network to which the device is connected.

    11.2.7.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD NOT [CID:2570]

    Agencies SHOULD NOT enable a direct connection from a MFD to a telephone network unless the telephone network is accredited to at least the same classification as the computer network to which the device is connected.

    11.2.8. Connecting MFDs to computer networks

    11.2.8.R.01.Rationale

    As network connected MFDs are considered to be devices that reside on a computer network they need to be able to process the same classification of information that the network is capable of processing.

    11.2.8.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2575]

    Where MFDs connected to computer networks have the ability to communicate via a gateway to another network, agencies MUST ensure that:

    • each MFD applies user identification, authentication and audit functions for all classified information communicated by that device;
    • these mechanisms are of similar strength to those specified for workstations on that network; and
    • each gateway can identify and filter the classified information in accordance with the requirements for the export of data through a gateway.

    11.2.9. Copying documents on MFDs

    11.2.9.R.01.Rationale

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

    11.2.9.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST NOT [CID:2578]

    Agencies MUST NOT permit MFDs connected to computer networks to be used to copy classified documents above the classification of the connected network.

    11.2.10. Observing fax machine and MFD use

    11.2.10.R.01.Rationale

    Placing fax machines and MFDs in public areas can assist in reducing the likelihood that any suspicious use of fax machines and MFDs by personnel will go unnoticed.

    11.2.10.C.01.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2581]

    Agencies SHOULD ensure that fax machines and MFDs are located in an area where their use can be observed.

    11.2.11. Servicing and Maintenance

    11.2.11.R.01.Rationale

    Network and MFD printers invariably use hard disk drives, flash drives or other reusable storage which can contain copies of classified information. Any maintenance or servicing should be conducted under supervision or by cleared personnel.

    11.2.11.R.02.Rationale

    Copiers and laser printers may use electrostatic drums as part of the reproduction and printing process. These drums can retain a “memory” of recent documents which can be recovered. Any storage devices or drums replaced during maintenance should follow the prescribed media disposal and destruction processes (See Chapter 13 – Decommissioning and Disposal).

    11.2.11.R.03.Rationale

    Toner cartridges and other components may incorporate a memory chip, often used to track pages numbers and estimate print capacity. These chips have read/write capability and may pose a risk to classified systems. Once chips have been removed, the toner cartridges themselves may be disposed of through supplier recycling or other approved disposal channels.

    11.2.11.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2589]

    Any maintenance or servicing MUST be conducted under supervision or by cleared personnel.

    11.2.11.C.02.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2590]

    Any storage devices, drums or cartridges with memory chips removed during maintenance or servicing MUST be disposed of following the processes prescribed in Chapter 13 - Decommissioning and Disposal.

    11.2.11.C.03.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2591]

    Toner cartridges MUST have the memory chip removed before the cartridge is recycled or otherwise disposed of. The memory chip MUST be disposed of following the processes prescribed in Chapter 13 - Decommissioning and Disposal.

    11.2.11.C.04.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2592]

    Any maintenance or servicing SHOULD be conducted under supervision or by cleared personnel.

    11.2.11.C.05.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2593]

    Any storage devices, drums or cartridges with memory chips removed during maintenance or servicing SHOULD be disposed of following the processes prescribed in Chapter 13 - Decommissioning and Disposal.

    11.2.12. USB Devices

    11.2.12.R.01.Rationale

    MFDs may also be equipped with USB ports for maintenance and software updates. It is possible to copy data from installed storage devices to USB devices. Any use of USB capabilities must be carefully managed.

    11.2.12.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2596]

    The use of any USB capability MUST be conducted under supervision or by cleared personnel.

    11.2.12.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2597]

    The use of any USB capability SHOULD be conducted under supervision or by cleared personnel.

    11.2.13. Decommissioning and Disposal

    11.2.13.R.01.Rationale

    The use of storage media and the characteristics of electrostatic drums allow the recovery of information from such devices and components. To protect the information, prescribed disposal procedures should be followed.

    11.2.13.R.02.Rationale

    The use of storage media and the characteristics of electrostatic drums allow the recovery of information from such devices and components. To protect the information, prescribed disposal procedures should be followed.

    11.2.13.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2604]

    Any storage devices, drums, cartridge memory chips or other components that may contain data or copies of documents MUST be disposed of following the processes prescribed in Chapter 13 - Decommissioning and Disposal.

    11.2.13.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2606]

    Any storage devices, drums, cartridge memory chips or other components that may contain data or copies of documents SHOULD be disposed of following the processes prescribed in Chapter 13 - Decommissioning and Disposal.

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.3. Telephones and Telephone Systems

    Objective

    11.3.1.

    Telephone systems are prevented from communicating unauthorised classified information.

    Context

    Scope

    11.3.2.

    This section covers information relating to the secure use of fixed, including cordless, telephones, as well as the systems they use to communicate information.

    11.3.3.

    Information regarding Voice over Internet Protocol (VoIP) and encryption of data in transit is covered in Section 18.3 – Video & Telephony Conferencing and Internet Protocol Telephony and Section 17.1 - Cryptographic Fundamentals.

    11.3.4.

    It MUST be noted that VOIP and cellular phones have some of the same vulnerabilities as wired and cordless phones.

    Rationale & Controls

    11.3.5. Telephones and telephone systems usage policy

    11.3.5.R.01.Rationale

    All unsecure telephone networks are subject to interception. The level of expertise needed to do this varies greatly. Accidentally or maliciously revealing classified information over a public telephone networks can lead to interception.

    11.3.5.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2627]

    Agencies MUST develop a policy governing the use of telephones and telephone systems.

    11.3.6. Personnel awareness

    11.3.6.R.01.Rationale

    There is a high risk of unintended disclosure of classified information when using telephones. It is important that personnel are made aware of what levels of classified information they discuss on particular telephone systems as well as the audio security risk associated with the use of telephones.

    11.3.6.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2630]

    Agencies MUST advise personnel of the maximum permitted classification for conversations using both internal and external telephone connections.

    11.3.6.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2631]

    Agencies SHOULD advise personnel of the audio security risk posed by using telephones in areas where classified conversations can occur.

    11.3.7. Visual indication

    11.3.7.R.01.Rationale

    When single telephone systems are approved to hold conversations at different classifications, alerting the user to the classification level they can speak at when using their phone will assist in the reducing the risk of unintended disclosure of classified information.

    11.3.7.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2637]

    Agencies permitting different levels of conversation for different types of connections MUST use telephones that give a visual indication of the classification of the connection made.

    11.3.8. Use of telephone systems

    11.3.8.R.01.Rationale

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

    11.3.8.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2643]

    Agencies intending to use telephone systems for the transmission of classified information MUST ensure that:

    • the system has been accredited for the purpose; and
    • all classified traffic that passes over external systems is appropriately encrypted.

    11.3.9. Cordless telephones

    11.3.9.R.01.Rationale

    Cordless telephones have little or no effective transmission security, therefore should not be used for classified or sensitive communications. They also operate in an unlicensed part of the radio spectrum used for a wide range of other devices.

    11.3.9.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2648]

    Agencies MUST NOT use cordless telephones for classified conversations.

    11.3.9.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2649]

    Agencies SHOULD NOT use cordless telephones for classified or sensitive conversations.

    11.3.10. Cordless telephones with secure telephony devices

    11.3.10.R.01.Rationale

    As the data between cordless handsets and base stations is not secure, cordless telephones MUST NOT be used for classified communications even if the device is connected to a secure telephony device.

    11.3.10.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST NOT [CID:2652]

    Agencies MUST NOT use cordless telephones in conjunction with secure telephony devices.

    11.3.11. Speakerphones

    11.3.11.R.01.Rationale

    Speakerphones are designed to pick up and transmit conversations in the vicinity of the device they should not be used in secure areas as the audio security risk is extremely high.

    11.3.11.R.02.Rationale

    If the agency is able to reduce the audio security risk through the use of appropriate countermeasures then an exception may be approved by the Accreditation Authority.

    11.3.11.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2656]

    If a speakerphone is to be used on a secure telephone system within a secure area, agencies MUST apply the following controls:

    • it is located in a room rated as audio secure;
    • the room is audio secure during any conversations; 
    • only cleared personnel involved in discussions are present in the room; and
    • ensure approval for this exception is granted by the Accreditation Authority.

    11.3.12. Off-hook audio protection

    11.3.12.R.01.Rationale

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

    11.3.12.R.02.Rationale

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

    11.3.12.R.03.Rationale

    Many new digital desk phones control these functions through software, rather than a mechanical switch.

    11.3.12.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2661]

    Agencies MUST ensure that off-hook audio protection features are used on all telephones that are not accredited for the transmission of classified information in areas where such information could be discussed.

    11.3.12.C.02.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: SHOULD [CID:2662]

    Agencies SHOULD use push-to-talk handsets to meet the requirement for off-hook audio protection.

    11.3.12.C.03.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2663]

    Agencies SHOULD ensure that off-hook audio protection features are used on all telephones that are not accredited for the transmission of classified information in areas where such information could be discussed.

    11.3.13. Electronic Records Retention and Voicemail

    11.3.13.R.01.Rationale

    Voicemail and other messages and communications may fall within the legal definition of electronic records. If so retention and archive requirements are prescribed.

    11.3.13.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2666]

    Agencies MUST remove unused voice mailboxes.

    11.3.13.C.02.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2667]

    Agencies MUST expire and archive or delete voicemail messages after the retention period determined by the agency’s electronic records retention policy.

    11.3.13.C.03.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2669]

    Agencies SHOULD develop and implement a policy to manage the retention and disposal of such electronic records, including voicemail, email and other electronic records.

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.4. Mobile Telephony

    Objective

    11.4.1.

    Mobile telephone systems and devices are prevented from communicating unauthorised classified information.

    Context

    Scope

    11.4.2.

    This section covers information relating to the secure use of mobile telephones, tablets and other mobile, voice communication capable devices, as well as the systems they use to communicate information.

    11.4.3.

    Mobile devices use RF in various parts of the spectrum to communicate including Wi-Fi, cellular, satellite, RFID, and NFC frequencies. All such mobile devices are considered to be transmitters.

    11.4.4.

    Mobile devices with cellular capability will regularly “poll” for the strongest signal and base or relay station. Monitoring such activity can be used for later interception of transmissions.

    11.4.5.

    Information regarding Voice over Internet Protocol (VoIP) and encryption of data in transit is covered in Section 18.3 – Video & Telephony Conferencing and Internet Protocol Telephony and Section 17.1 - Cryptographic Fundamentals.

    11.4.6.

    It is important to note that VoIP phones have some of the same vulnerabilities as the mobile devices discussed in this section.

    11.4.7.

    Mobile devices can be equipped with a variety of capabilities including internet connectivity, cameras, speakerphones, recording and remote control. Such devices are also susceptible to Internet malware and exploits. All risks related to the use of the Internet will apply to mobile devices with 3G/4G capability.

    PSR references

    11.4.8.

    Relevant PSR requirements can be found at:

    Reference Title Source
    PSR Mandatory Requirements GOV2, INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4,  PHYSEC1 and PHYSEC2

    http://www.protectivesecurity.govt.nz

    https://www.protectivesecurity.govt.nz/governance/mandatory-requirements-2/ 

    https://www.protectivesecurity.govt.nz/information-security/mandatory-requirements-2/   

    https://www.protectivesecurity.govt.nz/physical-security/physical-security-mandatory-requirements-2/

    PSR content protocols 

    Management protocol for information security

    Management protocol for physical security

    https://www.protectivesecurity.govt.nz/information-security/management-protocol-for-information-security/ 

    https://www.protectivesecurity.govt.nz/physical-security/management-protocol-for-the-physical-security/ 

    PSR requirements sections

    Security zones

     

    https://www.protectivesecurity.govt.nz/security-zones/ 

    Managing specific scenarios

    Secure your ICT facilities

    Mobile and remote working

    Physical Security for ICT systems

    Communication security

    https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/secure-your-ict-facilities/

    https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/mobile-and-remote-working/

    https://www.protectivesecurity.govt.nz/physical-security/specific-scenarios/physical-security-for-ict/

    https://www.protectivesecurity.govt.nz/information-security/managing-specific-scenarios/communications-security/

    Rationale & Controls

    11.4.9. Mobile device usage policy

    11.4.9.R.01.Rationale

    All mobile devices are subject to interception. The required level of expertise needed varies greatly. Accidentally or maliciously revealing classified information over mobile devices can be intercepted leading to a security breach.

    11.4.9.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2691]

    Agencies MUST develop a policy governing the use of mobile devices.

    11.4.10. Personnel awareness

    11.4.10.R.01.Rationale

    There is a high risk of unintended disclosure of classified information when using mobile devices. It is important that personnel are aware of what levels of classified information they discuss as well as the wide range of security risks associated with the use of mobile devices.

    11.4.10.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2694]

    Agencies MUST advise personnel of the maximum permitted classification for conversations using both internal and external mobile devices.

    11.4.10.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2695]

    Agencies SHOULD advise personnel of all known security risks posed by using mobile devices in areas where classified conversations can occur.

    11.4.11. Use of mobile devices

    11.4.11.R.01.Rationale

    When classified conversations are to be held using mobile devices the conversation needs to be appropriately protected through the use of encryption measures and a secure network.

    11.4.11.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2698]

    Agencies intending to use mobile devices for the transmission of classified information MUST ensure that:

    • the network has been certified and accredited for the purpose; 
    • all classified traffic that passes over mobile devices is appropriately encrypted; and
    • users are aware of the area, surroundings, potential for overhearing and potential for oversight when using the device.

    11.4.12. Mobile Device Physical Security

    11.4.12.R.01.Rationale

    Mobile devices are invariably software controlled and are subject to malware or other means of compromise. No “off-hook” or “power off” security can be effectively provided, creating vulnerabilities for secure areas. Secure areas are defined in Chapter 1 at 1.1.33.

    11.4.12.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST [CID:2701]

    Mobile devices MUST be prevented from entering secure areas.

    11.4.12.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2702]

    Agencies SHOULD provide a storage area or lockers where mobile devices can be stored before personnel enter secure or protected areas.

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.5. Personal Wearable Devices

    Objective

    11.5.1.

    Wearable devices are prevented from unauthorised communication or from compromising secure areas.

    Context

    Scope

    11.5.2.

    This section covers information relating to the use of personal wearable devices, fitness devices, smart watches, devices embedding in clothing and similar wearable devices.

    11.5.3.

    These devices can use RF in various parts of the spectrum to communicate including Wi-Fi, cellular, satellite, RFID, NFC and Bluetooth frequencies as well as providing data storage capability, audio and video recording and USB connectivity. All such wearable or mobile devices are considered to be transmitters.

    11.5.4.

    Personal wearable devices can be equipped with a variety of capabilities including smart phone pairing, internet connectivity, cameras, speakerphones, audio and video recording and remote control. Some devices (for example Narrative and Autographer) will automatically take snapshots at intervals during the day. In some cases the snapshots are geotagged.

    11.5.5.

    Such devices are also susceptible to Internet malware and exploits. All risks related to the use of the Internet will apply to these devices.

    11.5.6.

    Merely disabling the capabilities described above is not a sufficient mitigation and is not acceptable, posing a high risk of compromise, whether intentional or accidental. The device MUST NOT have such capabilities installed if the device is to enter a secure area.

    11.5.7.

    There is a wide variety of devices now available with upgrades and new models appearing frequently. There are many hundreds of models with a variety of custom operating systems and programmes and other applications. Some industry surveys and predications are forecasting explosive growth in the use of wearable devices, reaching over 100 million devices by 2020. Checking the capabilities and vulnerabilities of each device and subsequent security testing or validation will be an onerous task for agencies and may be infeasible.

    Key Risk Areas

    11.5.8.

    Personal wearable devices are not only about the technological aspects, the human factor is equally important. Users often forget about personal information security and their own safety, which enables social engineering attacks on the devices. The main protective measure for users is awareness, but even the trust-but-verify rule is not completely reliable in this situation. Accordingly, the information gathered by wearable devices should be appropriately secured to maintain privacy and personal security.

    11.5.9.

    There are four important risk groups to be considered when managing personal wearable devices:

    1. Data leaks and breaches;
    2. Network security compromises;
    3. Personally Identifiable Information (PII) leaks; and
    4. Privacy violations.

    Personally Identifiable Information (PII)

    11.5.10.

    In most cases, the protection of PII will be the responsibility of the individual. In cases where the use of devices is permitted under a medical exemption, agencies MAY be required to ensure that devices that collect and store data comply with relevant regulation and guidance, such as the Privacy Act and the HIPAA.

    PSR references

    References

    11.5.12.

    Further references can be found at:

    References Publisher Source

    ITL bulletin for April 2010 - Guide to protecting personally identifiable information

    NIST http://csrc.nist.gov/publications/nistbul/april-2010_guide-protecting-pii.pdf

    NIST Special Publication 800-122

    Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) - Recommendations of the National Institute of Standards and Technology

    NIST http://csrc.nist.gov/publications/nistpubs/800-122/sp800-122.pdf
    Privacy Act 1993 (the Privacy Act)  

    Office of The Privacy Commissioner

    http://www.privacy.org.nz/

    http://www.legislation.govt.nz/

    The Health Insurance Portability and Accountability Act of 1996 (USA)

    US Congress

    https://www.gpo.gov/fdsys/pkg/PLAW-104publ191/html/PLAW-104publ191.htm

    http://www.hhs.gov/hipaa

    Health Information Technology for Economic and Clinical Health Act (HITECH Act) (USA)

    US Congress

    https://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf

    http://www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/index.html 

    Technology, Media and Telecommunications Predictions, 2014 Deloitte http://www2.deloitte.com/content/dam/Deloitte/global/Documents/Technology-Media-Telecommunications/gx-tmt-predictions-2014-interactive.pdf
    Technology, Media and Telecommunications Predictions, 2015 Deloitte http://www2.deloitte.com/au/en/pages/technology-media-and-telecommunications/articles/tmt-predictions.html 
    Study: Wearable Technology & Preventative Healthcare

    Technology Advice Research

    http://technologyadvice.com/
    Security Analysis of Wearable Fitness Devices (Fitbit)

    Massachusetts Institute of Technology

    https://courses.csail.mit.edu/6.857/2014/files/17-cyrbritt-webbhorn-specter-dmiao-hacking-fitbit.pdf
    Fit and Vulnerable: Attacks and Defenses for a Health Monitoring Device

    School of Computing and Information Sciences, Florida International University

    https://arxiv.org/pdf/1304.5672.pdf

    Survey of Security and Privacy Issues of Internet of Things

       http://arxiv.org/ftp/arxiv/papers/1501/1501.02211.pdf

    Rationale & Controls

    11.5.13. Personal Wearable Device usage policy

    11.5.13.R.01.Rationale

    Any device that uses part of the RF spectrum to communicate is subject to interception. The required level of expertise to conduct intercepts needed varies greatly. Other capabilities of Personal Wearable Devices can be used for malicious purposes, including the theft of classified information and revealing the identities of personnel. Accidentally or maliciously revealing classified information through Personal Wearable Devices can lead to a security breach.

    11.5.13.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2736]

    Agencies MUST develop a policy governing the use of personal wearable devices, including fitness devices.

    11.5.14. Personnel awareness

    11.5.14.R.01.Rationale

    There is a high risk of unintended disclosure of classified information when using personal wearable devices. It is important that personnel are aware of the level of classified information they discuss, the environment in which they are operating as well as the wide range of security risks associated with the use of mobile and personal wearable devices.

    11.5.14.C.01.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2750]

    Agencies MUST advise personnel of the maximum permitted classification for conversations where any personal wearable or mobile device may be present.

    11.5.14.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2752]

    Agencies SHOULD advise personnel of all known security risks posed by using personal wearable devices in secure areas or other areas where classified conversations can occur.

    11.5.15. Mobile Device Physical Security

    11.5.15.R.01.Rationale

    Personal wearable devices are invariably software controlled and can be infected with malware or other means of compromise. No “off-hook” or “power off” security can be effectively provided, creating vulnerabilities for secure areas. Secure areas are defined in Chapter 1 at 1.1.33.

    11.5.15.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2758]

    Personal wearable devices MUST NOT be allowed to enter secure areas.

    11.5.15.C.02.Control: 
    System Classification(s): All Classifications; Compliance: SHOULD [CID:2759]

    Agencies SHOULD provide a storage area or lockers where personal wearable devices can be stored before personnel enter secure or protected areas.

    11.5.16. Medical Exemptions

    11.5.16.R.01.Rationale

    In some isolated cases personal wearable devices are necessary for the medical well-being of the individual. In such cases personal wearable devices MAY be permitted with the written authority of the Agency’s Accreditation Authority. Such devices MUST NOT have any of the following capabilities:

    • Camera;
    • Microphone;
    • Voice/video/still photograph recording; 
    • Cellular, Wi-Fi or other RF.

    Merely disabling such capabilities is not acceptable. The device MUST NOT have such capabilities installed. Permitted device capabilities are:

    • Accelerometer;
    • Altimeter;
    • Gyroscope; 
    • Heart Activity monitor;
    • Vibration feature for the personal notification purposes.
    11.5.16.C.01.Control: 
    System Classification(s): Confidential, Secret, Top Secret; Compliance: MUST NOT [CID:2763]

    Any personal wearable devices approved on medical grounds MUST NOT have any of the following capabilities:
    Camera;
    Microphone;
    Voice/video/still photograph recording;
    Cellular, Wi-Fi or other RF means of transmission.

    11.5.16.C.02.Control: 
    System Classification(s): Confidential, Top Secret, Secret; Compliance: MUST [CID:2765]

    Where personal wearable devices are exempted on medical grounds and used in secure areas agencies MUST ensure that:

    • the agency networks in secure areas have been certified and accredited for the purpose; and
    • users are aware of the area, surroundings, potential for overhearing and potential for oversight.
    11.5.16.C.03.Control: 
    System Classification(s): All Classifications; Compliance: MUST [CID:2767]

    Where the use of personal wearable devices is permitted on medical grounds and used within a corporate or agency environment, agencies MUST ensure any relevant legislation and regulation pertaining to the protection of Personally Identifiable Information (PII) is properly managed and protected.

    img of download icon
    Download full doc: PDF | XML | CSV Download section: PDF | XML | CSV

    11.6. Radio Frequency Identification Devices

    Objective

    11.6.1.

    To ensure Radio Frequency Identification (RFID) devices are used safely and securely in order to protect privacy, prevent unauthorised access and to prevent the compromise of secure spaces.

    Context

    Scope

    11.6.2.

    This section provides information relating to the risks, security and secure use of RFID devices. Access Control Systems incorporating RFID or smart cards are discussed in more detail in Section 11.7 - Access Control Systems.

    Background

    11.6.3.

    This section contains a short description of the history, formats, operating frequencies, risks, controls and countermeasures related to the use of RFID.

    11.6.4.

    In practical use since the 1970’s, RFID is now widely used for product identification, stock control, as anti-theft in manufacturing and retail organisations, payment cards (smart ATM and paywave cards) and access control systems. They are useful tools in improving logistics, profoundly changing cost structures for business, and improving levels of safety and authenticity in a wide range of applications such as access control, passports, payment cards, vehicle immobilisers, toll roads, pharmaceuticals tracking, management of high value items and weapons control. RFID tags are now produced in a wide variety of types and sizes, from the size of a grain of rice or printed on paper to much larger devices incorporating a battery or other power supply.

    11.6.5.

    Unlike bar coding systems, RFID devices can communicate without requiring line of sight and over distances ranging from a few centimetres to kilometres. They can be equipped with sensors to collect data on temperature changes, sudden shocks, humidity or other factors affecting product safety and quality.

    11.6.6.

    RFID devices typically use radio signals to transmit identifying information such as product or serial numbers, manufacture date, origin and batch number. This identifying information is invariably in the form of an Electronic Product Code (EPC) following the standards and conventions published by GS1. GS1 is a global group that also develops standards for other identifiers such as barcodes. The GS1 standards and conventions are now incorporated into ISO standards, see references table at 11.6.55.

    Basic Formats

    11.6.7.

    The basic format of an Electronic Product Code (EPC) is illustrated below:

    Diagram of Electronic Product Code Type 1: 96-bit

    11.6.8.

    11.6.1. RFID devices are often referred to as “tags”. Passive tags are unpowered and harvest power from the RFID reader. Active tags incorporate a power supply, usually a battery. Tags are produced in Classes 0 to 5 and are now generally produced to Generation 2 specifications. The EPCGen2 standard for Class 1 tags focuses on reliability and efficiency but supports only very basic security. Features of the Gen 2 specification include:

    • a 96 bit EPC number with read/write capability and can be designated used for other data ;
    • a 32/64 bit tag identifier (TID) – identifies the manufacturer of the tag, also with read/write capabilities; 
    • 32 bit kill password to permanently disable the tag; 
    • 32 bit access password to lock the read/write characteristics of the tag and also set the tag for disabling ;
    • User memory – dependant on the manufacturer and can be as little as 0 bits to 2048 bits. Larger user memory is in development.
    11.6.9.

    The distance from which a tag can be read is termed the read range. A read range will depend on a number of factors, including the radio frequency used for reader/tag/reader communication, the size and orientation of the antennae, the power output of the reader, and whether the tags have a battery or other power supply. Battery-powered tags typically have a read range of 100 meters (approximately 300 feet) although this can extend to kilometres under favourable conditions. It is possible that powered RFID tags, typically used on cargo containers, railway wagons, vehicles and other large assets, could be read from a satellite if there is little background “noise” and the broadcast signal is sufficiently powerful.

    11.6.10.

    11.6.1. RFID tags are divided into classes 0 to 5:

    Class Description
    0 Read only, passive tags
    1 Write once passive tags.  128-bit memory.
    2 Read/Write with up to 65Kb read/write memory and authenticated access control.  Can monitor temperature, pressure, vibration.
    3 Semi-Passive. Own power source but cannot initiate communication.  Remains passive until activated by a reader.  Up to 65 Kb read/write memory and integrated sensor circuitry.
    4 Active tags (own power source) with integrated transmitter.  Can communicate with readers and other tags operating in the same RF band.  Rewritable memory and ad hoc networking capability.  Read range >100 metres (approx. 300’).
    5 Reader tags, can power class 1 to 3 tags and communicate with all classes.  Includes all the capabilities of class 4 tags.

    Operating Frequencies

    11.6.11.

    RFID operates in several parts of the Radio Spectrum. Not all frequencies are authorised for use in all countries and will depend on the radio spectrum allocation authority in each country. It is important to note, however, that some RFID tags designed to operate at frequencies not used in the importing country may be attached to imported goods. This can represent a risk from scanning at frequencies not authorised or normally monitored in the importing country.

    11.6.12.

    Depending on the design and intended application, RFID tag can operate at different frequencies. It is important to note that longer range RFID tags operate at frequencies close to or within allocated Wi-Fi frequencies. Allocated frequencies are:

    Band Frequency

    Typical Range

    LF 125-134.2 kHz and 140-148.5 kHz 

    Up to 1/2 metre

    HF

    13.553 - 13.567 MHz and 26.957 - 27.283 MHz

    Up to 1 metre

    UHF

    433 MHz, 858 - 930 MHz, 2.400 - 2.483 GHz, 2.446 - 2.454GHz

    1 to 10 metres

    SHF

    5.725 - 5.875 GHz

    > 100 metres

    11.6.13.

    As RFID devices are deployed in more sophisticated applications such as matching hospital patients with laboratory test results or tracking systems for dangerous materials, concerns have been raised about protecting such systems against eavesdropping, unauthorised uses and privacy breaches.

    Smart Cards

    11.6.14.

    Smart cards typically comprise an embedded integrated circuit incorporating a microchip with internal memory, a read-only CSN (Card Serial Number) or a UID (User Identification). The card connects to a reader with direct physical contact or a contactless radio frequency (RFID) interface. With an embedded microchip, smart cards can store large amounts of data, carry out on-card functions (such as encryption and authentication) and interact intelligently with a smart card reader. Smart card technology can be found in a variety of form factors, including plastic cards, key fobs, watches, subscriber identification modules used in mobile phones, and USB-based tokens. Smart cards are widely used in payment card (debit and credit cards and electronic wallets) and access control systems.

    11.6.15.

    The ISO/IEC 14443 standard for contactless smart card communications defines two types of contactless cards ("A" and "B") and allows for communications at distances up to 10 cm operating at 13.56 MHz. The alternative ISO/IEC 15693 standard allows communications at distances up to 50 cm. The ISO/IEC 7816 standard (in 15 parts) defines the physical, electrical interface and operating characteristics of these cards.

    11.6.16.

    In common with other RFID devices, smart cards incorporate an antenna embedded in the body of the card (or key fob, watch or token). When the card is brought within range of the reader, the chip in the card is powered on. Once powered on, an RF communication protocol is initiated and communication established between the card and the reader for data transfer.

    11.6.17.

    Smart cards typically incorporate protective mechanisms including authentication, secure data storage, encryption, tamper-resistance and secure communication. Support for biometric authentication may also be incorporated.

    Threats and Vulnerabilities

    11.6.18.

    Some important characteristics of RFID, inherent in the design and properties of the technology are:

    • RFID tags are powered by the field emitted by an RFID reader, so whenever a tag is placed in a reader field it is activated and available. In general terms, class 0 and class 1 tags cannot be powered off, only permanently deactivated;
    • RFID tags automatically respond to reader interactions without explicit control of the tag owner, so RFID tags can be operated without their owner’s consent;
    • It is trivial to establish a communication with an RFID tag and there is no visual confirmation of a tag/reader interaction (i.e., no physical connection or manual operation is required), so it is possible to interact with an RFID tag without being detected.
    11.6.19.

    Specific threats and vulnerabilities in the use of RFID technologies include:

    • Legitimate data-mining: This risk predates the use of RFID technology, but the volume of data provided by RFID tags, loyalty cards, Near Field Communication (NFC) for bank cards and for electronic wallets increases the risk. Some data collection methods keep to ethical use of data-mining techniques to discover the characteristics and habits of an individual or an organisation. This can pose a business intelligence risk. At times, however, this may challenge the bounds of privacy and data ownership. For example, customer loyalty card data used to discover medical information about an individual or RFID tags to track shipments or deliveries to an organisation by a competitor. 
    • Eavesdropping and Data theft: This risk is similar to the data-mining risk but employs unethical and possibly illegal methods of data collection or obtaining data for nefarious or malicious purposes. RFID tags are designed to broadcast information and data theft by easily concealable RFID scanners is technically trivial. Data theft can pose a risk to business processes.
    • Skimming: Occurs when an unauthorised reader gains access to data stored on a token. This type of attack is particularly dangerous where contactless access or payment cards are used.
    • Relay Attacks: Relay attacks use eavesdropping to intercept legitimate tag/reader transmissions and relay these to a device at some distance from the legitimate tag. The device can then behave as the genuine tag. Again this type of attack is particularly dangerous where contactless access or payment cards are used.
    • Insert Attacks: Insert attacks insert system commands where normal data is expected and relies on a lack of data validation. It is possible that a tag can have legitimate data replaced by a malicious command.
    • Tag Cloning: Clones replicate the functionality of legitimate tags and can be used to access controlled areas, abuse private data, or make an unauthorised electronic transaction. Tag authentication using a challenge-response protocol is a defence against cloning as the information that attackers can obtain through the air interface (such as by eavesdropping) is insufficient to provide a legitimate response. The design of the tag can also incorporate measures at the circuit manufacturing stage to protect tags from duplication by reverse engineering.
    • Data corruption: Most RFID tags are rewritable by design. This feature may be locked (turning the tag into a write-once, read-many device) or left active, depending on application and security sensitivity. For example, in libraries, the RFID tags are frequently left unlocked for the convenience of librarians in reusing the tags on different books or to track check-ins and check-outs. If tags are not protected, it creates an opportunity for malicious users to overwrite data, typically in the theft of high-value goods by marking them as low-value items or in the case of weapons monitoring, changing the weapon identification.
    • Shipment or People tracking: While RFID tags are designed to assist in stock control and supply chain management, unauthorised tracking of shipments or of people is undesirable and may even be dangerous. It is possible to follow individuals carrying tags using several techniques, including placing fake readers at building access points, deploying unauthorised readers near legitimate readers and creating relay points along expected routes.
    • Tag Blocking: This is a form of denial of service by introducing a blocker tag which is designed to simulate all possible tags in an allocated range. This causes readers to continually perform multiple reads on non-existent and non-responsive tags. Blocker tags are sometimes used where privacy or confidentiality are required.
    • Denial of Service (DOS): Also known as flooding attacks where a signal is flooded with more data than it is designed to handle. Similar in many respects to RF Jamming.

    Attack Vectors

    11.6.20.

    Attack vectors for RFID devices include:

    • interception of legitimate transmissions (man-in-the-middle [MITM] attacks);
    • interception of authorised reader data by an unauthorised device;
    • unauthorised access to tags and readers;
    • rogue/cloned tags;
    • rogue and unauthorised RFID readers; 
    • side-channel attacks (timing measurements, electromagnetic radiations etc.); 
    • attacks on back-end systems;
    • jamming of legitimate signals.
    11.6.21.

    Because RFID devices incorporate antennas, there is a possibility of radiation hazards from high –powered devices, particularly active tags and readers. It is important to note however that these cases are rare, occur in high powered devices only and that the vast majority of RFID devices do not pose radiation hazards. Related hazards include electromagnetic radiation hazards to personnel (HERP), fuel (HERF) and ordnance (HERO).

    11.6.22.

    Threats and Vulnerabilities of RFID systems are summarised in the table below:

    Threat/Vulnerability

    Tag RF Reader Network

    Back-End

    People

    Eavesdropping  Bullet marker  Bullet marker    Bullet marker  Bullet marker  

    Relay Attack

       Bullet marker        

    Unauthorised Tag Reading (skimming)

     Bullet marker  Bullet marker  Bullet marker      

    People Tracking

     Bullet marker  Bullet marker        Bullet marker

    Shipment Tracking

     Bullet marker  Bullet marker        

    Tag Cloning

     Bullet marker  Bullet marker        

    Replay Attack

     Bullet marker  Bullet marker        

    Insert Attack

     Bullet marker    Bullet marker  Bullet marker  Bullet marker  

    Tag Content Modification

     Bullet marker          

    Malware

     Bullet marker    Bullet marker  Bullet marker  Bullet marker  

    RFID System Failure

         Bullet marker  Bullet marker  Bullet marker  Bullet marker
    Tag Destruction  Bullet marker          

    Tag Blocking

     Bullet marker  Bullet marker        
    Denial of Service (DoS)  Bullet marker    Bullet marker  Bullet marker    

    RF Jamming

     Bullet marker  Bullet marker        Bullet marker
    Back-End Attacks        Bullet marker  Bullet marker  
    Radiation Hazard   Bullet marker  Bullet marker  Bullet marker      Bullet marker
    11.6.23.

    It is important to note that attacks are often used in combination creating blended attacks. Blended attacks may be a combination of attack types, use of multiple attack vectors, the targeting of individual sub-systems or combinations of all three elements.

    Good Practices and Countermeasures

    11.6.24.

    Good practice for ensuring the security and privacy of RFID systems includes:

    • a risk assessment to determine the nature and extent of risk and threat in the proposed use of RFID;
    • strong security architecture to protect RFID databases and communication systems;
    • authentication of approved users of RFID systems;
    • encryption of radio signals when feasible;
    • temporarily or permanently disabling tags when not required;
    • shielding RFID tags and tag reading areas to prevent unauthorised access or modification;
    • incident management, audit procedures, logging and time stamping to help detect and manage security breaches; and
    • tag disposal and recycling procedures that permanently disable or destroy sensitive data.

    Authentication

    11.6.25.

    By design and usage, RFID technologies are item, product or shipment identification but not authentication technologies. Authentication of a reader or tag requires a common secret (key) shared when establishing communication, and before data is exchanged. Currently, only RFID tags with microprocessors have sufficient computation resources to use authentication techniques. These can be found in such applications as e-passports, or payment or ticketing applications (public transport, for example).

    11.6.26.

    With a challenge/response authentication mechanism the reader issues an enquiry to the tag which results in a response. The secret tag information is computed information from internal cryptographic algorithms by both the tag and reader and the results are sent. Correct responses are required for a successful information exchange. The system is essentially the same as encrypting data over a standard radio link.

    11.6.27.

    The ISO/JTC1/SC31 committee is in the process of establishing new standards to support the use of simple RFID authentication and encryption protocols.

    Keyed-Hash Message Authentication Code (HMAC)

    11.6.28.

    HMAC is a protocol where both an RFID reader and RFID tag share a common secret key that can be used in combination with a hash algorithm to provide one-way or mutual authentication between tag and reader. When HMAC is applied to messages, it also assures the integrity of data in the messages.

    11.6.29.

    HMAC is not specified in any RFID standard, but the capability is generally available in vendor products. HMAC is often used where the risk of eavesdropping is high and passwords alone are considered to offer an inadequate authentication mechanism. This will be determined by the risk assessment. HMAC is also used where applications require evidence of a tag’s authenticity.

    Digital Signatures

    11.6.30.

    Digital signatures are compatible with existing RFID tag standards. In authenticated RFID systems, tags can receive, store, and transmit digital signatures with existing read and write commands because the complexity is managed by readers or back-end systems. However, the use of digital signatures to support authentication of readers to tags would require tags to support relatively complex cryptographic functions, beyond the capacity of common tag designs.

    11.6.31.

    In addition, digital signatures that are not generated by the tag itself are subject to replay attacks. An adversary could query a tag to obtain its evidence of authenticity (i.e., the digital signature created by a previous reader) and then replicate that data on a cloned tag. Consequently, password or symmetric key authentication systems likely will support tag access control, as opposed to tag authenticity verification, for the immediate future.

    Encryption

    11.6.32.

    Data stored in the memory of an RFID tag is intended to be freely shared with the various tag users (manufacturers, stock controllers, shipping agents, etc.). Only an RFID reader is required to access the data which raises the question of data security. Memory and computational power of an RFID tag is limited, but data elements can be password-protected or reserved for nominated usage. Several levels of authorisation (read-only, read and write, delete, etc.) can be determined. It is also advisable to encrypt the data entered onto the tag, the encryption/decryption taking place at the RFID reader or back-end system.

    Cover-Coding

    11.6.33.

    Cover-coding is a method of hiding information from eavesdroppers. In the EPCglobal Class-1 Generation-2 standard, cover-coding is used to obscure passwords and information written to a tag using the write command. Some proprietary technologies also support similar features. Cover-coding is an example of minimalist cryptography because it operates within the challenging power and memory constraints of passive RFID tags.

    11.6.34.

    Cover-coding is a useful mitigation where eavesdropping is a risk, but adversaries are expected to be at a greater distance from the tags than readers. Cover-coding helps prevent the execution of unauthorised commands that could disable a tag or modify the tag’s data. Cover-coding mitigates business process, business intelligence, and privacy risks.

    Rolling Code

    11.6.35.

    A rolling code approach is a scheme where the identifier given by the RFID tag changes after each read action. It requires the RFID reader and RFID tag to use identical algorithms. If multiple readers are used, they must be linked so that tracking of code changes can be monitored. This scheme reduces the usefulness of any responses that may be observed unless the pattern of change can be detected or deduced.

    Other Defensive Measures

    11.6.36.

    Other defensive measures, sometimes described as palliative techniques, include shielding, blocker tags, tag “kill” commands, tamper resistance and temporary deactivation. It is important to note these techniques do not use encryption.

    Shielding

    11.6.37.

    RF shielding is designed to limit the propagation of RF signals outside of the shielded area. Shielding helps to prevent unauthorised reading, access to or modification of the RFID tag data or interfering with RFID readers. Shielding can be applied to small, individual items, such as passports and credit cards or to large elements such as shipping containers.

    11.6.38.

    Shielding is also important where interference is present or detected. This may be caused by environmental conditions, such as operating in a port area, or by deliberate attempts to access readers or tags.

    11.6.39.

    Engineering assessments will determine the requirement for shielding from adverse environmental conditions and the risk assessment will determine the likelihood and threat from unauthorised and deliberate attempts to access readers, tags and data.

    11.6.40.

    RFID blocking wallets and RFID card sleeves are available to block RFID frequencies. These are typically used for credit and other payment, access and transit cards and e-passports, as a countermeasure for skimming attacks or unauthorised tracking.

    Blocker Tags

    11.6.41.

    A special tag, called a “blocker” tag, blocks an RFID reader by simultaneously answering with 0 and 1 to every reader’s request during the identification protocol. The reader is then incapable of distinguishing individual tags. The blocker tag may block a reader universally or within ranges.

    11.6.42.

    This furnishes privacy by shielding consumers from the unwanted scanning of RFID tags that they may carry or wear. It also protects against unauthorised readers and eavesdroppers. The blocker tag is an alternative to more simple solutions such as the kill command, shielding and active jamming. It is important to note that active jamming may be illegal (see 11.6.53).

    11.6.43.

    Blocker tags can also implement one or more privacy policies and multiple blocker tags may cover multiple zones.  The blocker tag has a very low-cost of implementation and standard tags need no modification and little support for password-protected bit flipping.  A threat is that blocker tags can be used to mount DoS attacks in which a malicious blocker tag universally blocks readers.

    Tag “Kill” Command

    11.6.44.

    The “kill” command is a password-protected command specified in the EPC Gen-1 and EPC Gen-2 standards intended to make a tag non-operational. A typical application is anti-theft where the kill command is activated at a point-of-sale terminal, after goods have been paid for. Kill commands can be password protected.

    11.6.45.

    Kill commands function by fusing a ROM component or antenna connection by applying a large amount of power to the tag at the point of sale reader/terminal. It is important to note that the antenna deactivation method does not completely kill the tag but rather disable its RF interface. Once in the disabled state, the tag still retains data and can still function.

    11.6.46.

    The kill feature can represent a threat to an RFID system if the password is compromised. This risk is particularly apparent where the same password is used for multiple tags. If a weak (e.g., short or easily guessed) password is assigned to the kill command, tags can be disabled at will. Also important is the longer a tag uses the same password, the more likely it is that the password will be compromised.

    11.6.47.

    Data stored on the tag is still present in the tag’s memory after it is disabled (although it can no longer be accessed wirelessly), and, therefore, still may be accessible with physical access to the tag.

    Tamper Resistance

    11.6.48.

    Some RFID tags are designed with tamper resistant or tamper-evident features to help prevent unauthorised alteration of removal of tags from the objects to which they are attached. A simple type of tamper resistance is the use of a frangible, or easily broken, antenna. If this tag is removed, the connection with the antenna is severed, rendering the tag inoperable. Other, more complex types of RFID systems monitor the integrity of objects associated with the tags to ensure that the objects have not been compromised, altered, or subjected to extreme conditions.

    11.6.49.

    Simple forms of tamper resistance may leave data intact and subject to the same threats described above. In addition it is possible to circumvent tamper resistance mechanisms by repairing a frangible antenna. It is important to note that tamper-resistance and tamper-evidence technologies do not prevent the theft or destruction of the tag or its associated items.

    Temporary Deactivation

    11.6.50.

    Some tags allow the RF interface to be temporarily deactivated.  Methods vary amongst manufacturers with some methods requiring physical intervention.  Typically tags would be activated inside a designated area and deactivated when shipped, preventing eavesdropping or other unauthorised transactions during shipment.  When the tags arrive at their destination, they can be reactivated, for example for inventory management.  Conversely, tags can be used for tracking during shipment and may be deactivated on delivery.

    RFID Risks and Controls Summary

    11.6.51.

    A summary of RFID Risks and Controls is presented in the Table below:

    Risk Control

    Business Process

    Business Intelligence

    Privacy

    Electro-Magnetic Radiation

    Back-End System Attack

    Tag Access Controls

    Bullet marker Bullet marker Bullet marker   Bullet marker

    Password Authentication

    Bullet marker Bullet marker Bullet marker   Bullet marker

    HMAC

    Bullet marker Bullet marker Bullet marker   Bullet marker

    Digital Signature

    Bullet marker Bullet marker     Bullet marker

    Cover-Coding

      Bullet marker     Bullet marker

    Encryption – Data in Transit

      Bullet marker Bullet marker    

    Encryption – Data at Rest

      Bullet marker     Bullet marker

    Encryption – Data on Tag

    Bullet marker Bullet marker Bullet marker    
    Shielding Bullet marker Bullet marker Bullet marker Bullet marker  

    Blocker Tags

      Bullet marker Bullet marker    

    Tag Kill Feature

      Bullet marker Bullet marker    

    Tamper Resistance

    Bullet marker Bullet marker      

    Temporary Deactivation

    Bullet marker Bullet marker Bullet marker    

    RF Engineering and Frequency Selection