urn: urn:defend:risk:library:nzism-v3
locale: en
ref_id: NSIZM-v3
name: NZISM v3
description: New Zealand Information Security Manual v3
copyright: "Except where specifically noted, all material on this site is \xA9 Crown\
  \ copyright.\n\nYou can reproduce Crown copyright material free of charge without\
  \ requiring specific permission, provided that the material is reproduced accurately\
  \ and on the condition that the source of the material and its copyright status\
  \ are acknowledged.\n\nThis licence does not apply to any logos, emblems and trade\
  \ marks on the website or to the website\u2019s design elements or to any photography\
  \ and imagery. Those items may not be used without our express permission.\n\nThe\
  \ permission to reproduce Crown copyright protected material does not extend to\
  \ any material on this site that is identified as being the copyright of a third\
  \ party. Authorisation to reproduce such material must be obtained from the copyright\
  \ holders concerned.\n\nThe NZISM is licensed under the Creative Commons Attribution\
  \ 4.0 New Zealand licence, available at https://creativecommons.org/licenses/by/4.0/(external\
  \ link). You are free to copy, distribute, and adapt the work, as long as you attribute\
  \ the work and abide by any other licence terms. For the avoidance of doubt, this\
  \ means this licence applies only to material as set out in the NZISM."
version: 2
publication_date: 2025-05-02
provider: New Zealand Government Communications Security Bureau
packager: DEFEND
objects:
  framework:
    urn: urn:defend:risk:framework:nzism-v3
    ref_id: NSIZM-v3
    name: NZISM v3
    description: New Zealand Information Security Manual v3
    scores_definition:
    - score: 0
      name: Non Compliant
      description: null
    - score: 1
      name: Compliant
      description: null
    implementation_groups_definition:
    - ref_id: All Classifications - MUST
      name: All Classifications - MUST
      description: null
    - ref_id: All Classifications - MUST NOT
      name: All Classifications - MUST NOT
      description: null
    - ref_id: All Classifications - SHOULD
      name: All Classifications - SHOULD
      description: null
    - ref_id: All Classifications - SHOULD NOT
      name: All Classifications - SHOULD NOT
      description: null
    - ref_id: Restricted/Sensitive - MUST
      name: Restricted/Sensitive - MUST
      description: null
    - ref_id: Restricted/Sensitive - MUST NOT
      name: Restricted/Sensitive - MUST NOT
      description: null
    - ref_id: Restricted/Sensitive - SHOULD
      name: Restricted/Sensitive - SHOULD
      description: null
    - ref_id: Restricted/Sensitive - SHOULD NOT
      name: Restricted/Sensitive - SHOULD NOT
      description: null
    - ref_id: Confidential - MUST
      name: Confidential - MUST
      description: null
    - ref_id: Confidential - MUST NOT
      name: Confidential - MUST NOT
      description: null
    - ref_id: Confidential - SHOULD
      name: Confidential - SHOULD
      description: null
    - ref_id: Confidential - SHOULD NOT
      name: Confidential - SHOULD NOT
      description: null
    - ref_id: Secret - MUST
      name: Secret - MUST
      description: null
    - ref_id: Secret - MUST NOT
      name: Secret - MUST NOT
      description: null
    - ref_id: Secret - SHOULD
      name: Secret - SHOULD
      description: null
    - ref_id: Secret - SHOULD NOT
      name: Secret - SHOULD NOT
      description: null
    - ref_id: Top Secret - MUST
      name: Top Secret - MUST
      description: null
    - ref_id: Top Secret - MUST NOT
      name: Top Secret - MUST NOT
      description: null
    - ref_id: Top Secret - SHOULD
      name: Top Secret - SHOULD
      description: null
    - ref_id: Top Secret - SHOULD NOT
      name: Top Secret - SHOULD NOT
      description: null
    requirement_nodes:
    - urn: urn:defend:risk:req_node:nzism-v3:1
      assessable: false
      depth: 1
      ref_id: '1'
      name: About information security
    - urn: urn:defend:risk:req_node:nzism-v3:1.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:1
      ref_id: '1.1'
      name: Understanding and using the NZISM
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:1
      ref_id: 1.1.1
      description: "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 baseline controls. Baseline controls are\
        \ minimum acceptable levels of controls and are often described as \u201C\
        systems hygiene\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      ref_id: 1.1.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      ref_id: 1.1.3
      description: This section provides information on how to interpret the content
        and the layout of content within this manual.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      ref_id: 1.1.4
      description: "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. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      ref_id: 1.1.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:1
      ref_id: 1.1.6
      description: "Where the category \u201CAll Classifications\u201D 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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      description: The purpose of this Manual
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:2
      ref_id: 1.1.7
      description: "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\u2019s assessment and determination of residual\
        \ risk related to information security."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:2
      ref_id: 1.1.8
      description: "This manual is updated regularly. \_It is therefore important\
        \ that agencies ensure that they are using the latest version of this Manual."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      description: Target audience
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:3
      ref_id: 1.1.9
      description: "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:\nsecurity executives;\nsecurity and information assurance\
        \ practitioners;\nIT Security Managers;\_\nDepartmental Security Officers;\
        \ and\nservice providers.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      description: Structure of this Manual
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:4
      ref_id: 1.1.10
      description: "This manual seeks to present information in a consistent manner.\
        \ \_There are a number of headings within each section, described below.\n\
        Objective \u2013 the desired outcome when controls within a section are implemented.\n\
        Context \u2013 the scope, applicability and any exceptions for a section.\n\
        References \u2013 references to external sources of information that can assist\
        \ in the interpretation or implementation of controls.\nRationale & Controls\_\
        \n\nRationale \u2013 the reasoning behind controls and compliance requirements.\n\
        Control \u2013 risk reduction measures with associated compliance requirements.\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:4
      ref_id: 1.1.11
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2
      description: The New Zealand Government Security Classification System
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:2:5
      ref_id: 1.1.12
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Key definitions
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Accreditation Authority
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      ref_id: 1.1.13
      description: "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 \u2013 Roles and Responsibilities and Section\
        \ 4.4 \u2013 Accreditation Framework."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      ref_id: 1.1.14
      description: "Agency heads may choose to delegate this authority to a member\
        \ of the agency\u2019s executive. \_The Agency Head remains accountable for\
        \ ICT risks accepted and the information security of their agency.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      ref_id: 1.1.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      ref_id: 1.1.16
      description: "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 Digital Officer (GCDO)\
        \ may also be necessary."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:1
      ref_id: 1.1.17
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Certification and Accreditation Processes
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.18
      description: "Certification and accreditation of information systems is the\
        \ fundamental governance process by which the risk owners and agency head\
        \ derive assurance over the design, implementation and management of information\
        \ systems and related services provided to or by government agencies. \_ This\
        \ process is described in detail in Chapter 4 \u2013 System Certification\
        \ and Accreditation."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.19
      description: Certification and Accreditation are two distinct processes.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.20
      description: Certification is the formal assertion that an information system
        and related services comply with minimum standards and agreed design, including
        any security requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.21
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.22
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.23
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.24
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:2
      ref_id: 1.1.25
      description: "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.\n\n\nInformation Classification\nMUST and MUST NOT controls\nSHOULD\
        \ and SHOULD NOT controls\nAccreditation Authority\n\n\n\nInformation classified\
        \ RESTRICTED and below,\n\_\n including UNCLASSIFIED \nand Official Information\_\
        \n\n\nControls are baseline or \u201Csystems hygiene\u201D controls and are\
        \ essential for the secure use of a system or service. Non-use is high risk\
        \ and mitigation is essential.\_\nIf the control cannot be directly implemented,\
        \ suitable compensating controls MUST be selected to manage identified risks.\n\
        The Accreditation Authority may grant a Waiver or Exception from a specific\
        \ requirement if the level of residual risk is within the agency\u2019s risk\
        \ appetite.\nSome baseline controls cannot be individually risk managed by\
        \ agencies without jeopardising multi-agency, All-of-Government or international\
        \ systems and related information.\n\n\nControl represents good and recommended\
        \ practice. Non-use may be medium to high risk.\nNon-use of controls is formally\
        \ recorded, compensating controls selected as required and residual risk acknowledged\
        \ to be within the agency\u2019s risk appetite and formally agreed and signed\
        \ off by the Accreditation Authority.\n\nAgency Head/Chief Executive/Director\
        \ General (or formal delegate)\n\n\nAll systems or services classified CONFIDENTIAL\
        \ and above.\n\nThis is a baseline for any use of High Assurance Cryptographic\
        \ Equipment (HACE) or the establishment of any compartments or the handling\
        \ of any endorsed information (see below).\nThe Controls are baseline or \u201C\
        systems hygiene\u201D 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.\n\
        If the control cannot be directly implemented and suitable compensating controls\
        \ MUST be selected to manage identified risks.\nThe Accreditation Authority\
        \ may grant a Waiver or Exception from a specific requirement if the level\
        \ of residual risk is within the agency\u2019s risk appetite.\nSome baseline\
        \ controls cannot be individually risk managed by agencies without jeopardising\
        \ multi-agency, All-of-Government or international systems and related information.\n\
        \n\nThis is a baseline for any use of High Assurance Cryptographic Equipment\
        \ (HACE) or the establishment of any compartments or the handling of any\_\
        endorsed information (See below).\nControl represents good and recommended\
        \ practice. Non-use may be high risk\nNon-use of controls is formally recorded,\
        \ compensating controls selected as required and residual risk formally acknowledged\
        \ to be within the agency\u2019s risk appetite and agreed and signed off by\
        \ the Accreditation Authority\n\nAgency Head/Chief Executive/Director General\
        \ (or formal delegate)\n\n\n\nAll use of High Assurance Cryptographic Equipment\
        \ (HACE)\nAll systems or services with compartmented or caveated information\
        \ classified CONFIDENTIAL and above.\n\n\nAccreditation based on work conducted\
        \ by the agency and authority to operate by the Agency Head.\nControls are\
        \ baseline or \u201Csystems hygiene\u201D 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.\nIf the control cannot be directly implemented\
        \ and suitable compensating controls MUST be selected to manage identified\
        \ risks.\nThe Accreditation Authority may grant a Waiver or Exception from\
        \ a specific requirement if the level of residual risk is within the agency\u2019\
        s risk appetite.\nSome baseline controls cannot be individually risk managed\
        \ by agencies without jeopardising multi-agency, All-of-Government or international\
        \ systems and related information.\n\n\nAccreditation based on work conducted\
        \ by the agency and authority to operate by the Agency Head.\nControl represents\
        \ good and recommended practice. Non-use may be high risk\nNon-use of controls\
        \ is formally recorded, compensating controls selected as required and residual\
        \ risk formally acknowledged to be within the agency\u2019s risk appetite\
        \ and agreed and signed off by the Accreditation Authority.\n\nDirector GCSB\
        \ (or formal delegate)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: "\u201CAll Classifications\u201D category"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:3
      ref_id: 1.1.26
      description: "The \u201CAll Classifications\u201D 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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Compartmented Information
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:4
      ref_id: 1.1.27
      description: "Compartmented information is information requiring special protection\
        \ through separation or is \u201Ccompartmented\u201D from other information\
        \ stored and processed by the agency."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Concept of Operations (ConOp) Document
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:5
      ref_id: 1.1.28
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:6
      ref_id: 1.1.29
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information Asset
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:7
      ref_id: 1.1.30
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information Assurance (IA)
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:8
      ref_id: 1.1.31
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information Security
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:9
      ref_id: 1.1.32
      description: "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:\
        \ \u201Cmeasures relating to the confidentiality, availability and integrity\
        \ of information\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:9
      ref_id: 1.1.33
      description: '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.'
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information Systems
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:10
      ref_id: 1.1.34
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Information Systems Governance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:11
      ref_id: 1.1.35
      description: "An integral part of enterprise governance consists of the leadership\
        \ and organisational structures and processes to ensure that the agency\u2019\
        s information systems support and sustain the agency\u2019s and Government\u2019\
        s strategies and objectives. \_Information Systems Governance is the responsibility\
        \ of the Agency Head and the Executive team."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Secure Area
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:12
      ref_id: 1.1.36
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Security Posture
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:13
      ref_id: 1.1.37
      description: "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\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: Sensitive Compartmented Information Facility (SCIF)
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:14
      ref_id: 1.1.38
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:3:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3
      description: System Owner
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:3:15
      ref_id: 1.1.39
      description: "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\
        \ \u2013 System Owners."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Interpretation of controls
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: Controls language
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:1
      ref_id: 1.1.40
      description: "The definition of controls in this manual is based on language\
        \ as defined by the Internet Engineering Task Force (IETF)\u2019s Request\
        \ For Comment (RFC) 2119 to indicate differing degrees of compliance."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: Applicability of controls
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:2
      ref_id: 1.1.41
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:2
      ref_id: 1.1.42
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:2
      ref_id: 1.1.43
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: Identification and Selection of controls
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:3
      ref_id: 1.1.44
      description: "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. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: "Controls with a \u201CMUST\u201D or \u201CMUST NOT\u201D requirement"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:4
      ref_id: 1.1.45
      description: "A control with a \u201CMUST\u201D or \u201CMUST NOT\u201D 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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.46
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:4
      ref_id: 1.1.46
      description: "The rationale for non-use of baseline 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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: "Controls with a \u201CSHOULD\u201D or \u201CSHOULD NOT\u201D requirement"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.47
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:5
      ref_id: 1.1.47
      description: "A control with a \u201CSHOULD\u201D or \u201CSHOULD NOT\u201D\
        \ 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:\nA control is not relevant in the agency;\nA system\
        \ or ICT capability does not exist in the agency; or\_\nA process or control(s)\
        \ of equal strength has been substituted.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.48
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:5
      ref_id: 1.1.48
      description: '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:

        Is the agency willing to accept additional risk?

        Have any implications for All-of-Government systems been considered?

        If, so, what is the justification?

        '
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.49
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:5
      ref_id: 1.1.49
      description: A formal auditable record of this consideration and decision is
        required as part of the IA governance and assurance processes within an agency.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: Non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.50
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      ref_id: 1.1.50
      description: "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.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.51
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      ref_id: 1.1.51
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.52
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      ref_id: 1.1.52
      description: "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. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.53
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      ref_id: 1.1.53
      description: Simply acknowledging risks and not providing the means to implement
        controls does not represent effective risk management.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.54
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:6
      ref_id: 1.1.54
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4
      description: Rationale Statements
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.55
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:4:7
      ref_id: 1.1.55
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Risk management
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5
      description: Risk Management Standards
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.56
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:1
      ref_id: 1.1.56
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.57
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:1
      ref_id: 1.1.57
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5
      description: 'The NZISM and Risk Management '
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.58
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:2
      ref_id: 1.1.58
      description: The NZISM encapsulates good and recommended best-practice in managing
        technology risks and mitigating or minimising threat to New Zealand government
        information systems.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.59
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:2
      ref_id: 1.1.59
      description: "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.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.60
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:2
      ref_id: 1.1.60
      description: The NZISM contains guidance on governance and assurance processes
        and technological controls based on comprehensive risk and threat assessments,
        research and environmental monitoring.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.61
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:5:2
      ref_id: 1.1.61
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.62
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:6
      ref_id: 1.1.62
      description: "Key Standards\n\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\
        \nNZISM\n\_\n\nNew Zealand Information Security Manual\nGCSB\n\nhttps://www.nzism.gcsb.govt.nz/\_\
        \_\n\n\n\nPSR\nProtective Security Requirements\_\nNZSIS\nhttps://protectivesecurity.govt.nz\n\
        \n\nISO/IEC 27000:2018\_\nInformation Technology \u2013 Security Techniques\
        \ \u2013 Information Security Management Systems \u2013 Overview and Vocabulary\
        \ (fifth edition)\n\nISO\n\_\n\n\nhttps://www.iso.org/standard/73906.html\n\
        \n\n\nCNSS Instruction No. 4009 6 April 2015\n\_National Information Assurance\
        \ (IA) Glossary, (US)\_\nCommittee on National Security Systems (CNSS)\n\n\
        https://rmf.org/wp-content/uploads/2017/10/CNSSI-4009.pdf [PDF, 1.04 MB]\n\
        \_\n\n\n\nNISTIR 7298 Revision 3, July 2019\n\_Glossary of Key Information\
        \ Security Terms\nNIST\n\nhttps://csrc.nist.gov/publications/detail/nistir/7298/rev-3/final\_\
        \n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.63
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:6
      ref_id: 1.1.63
      description: "Additional Guidance\n\n\n\nReference\nTitle\nPublisher\_\nSource\n\
        \n\n\nApproved Products\n\n\n\nISO/IEC 15408-1:2009\_\n\nInformation technology\
        \ \u2014 Security techniques \u2014 Evaluation criteria for IT security \u2014\
        \ Part 1: Introduction and general model\n\n\nISO\n\n\nhttps://www.iso.org/standard/50341.html\n\
        \n\n\nISO/IEC 15408-2:2008\n\nInformation technology \u2014 Security techniques\
        \ \u2014 Evaluation criteria for IT security \u2014 Part 2: Security functional\
        \ components\n\nISO\nhttps://www.iso.org/standard/46414.html\n\n\nISO/IEC\
        \ 15408-3:2008\n\nInformation technology \u2014 Security techniques \u2014\
        \ Evaluation criteria for IT security \u2014 Part 3: Security assurance components\n\
        \nISO\nhttps://www.iso.org/standard/46413.html\n\n\n\_\_\nAISEP Evaluated\
        \ Products List\n\nASD\n\n\nhttps://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-evaluated-products\_\
        \n\n\n\n\_\nOther Evaluated Products Lists\n\nNSA\nNCSC UK\nCSEC\nCommon Criteria\n\
        \n\nhttps://nsa.gov\nhttps://ncsc.gov.uk/\nhttps://cse-cst.gc.ca\nhttps://commoncriteriaportal.org/products\n\
        \n\n\n\nArchiving of information\n\n\n\n\_\nPublic Records Act 2005 (as amended)\n\
        \nArchives New Zealand\nParliamentary Counsel Office\n\n\nhttps://archives.govt.nz\_\
        \_\nhttps://legislation.govt.nz/\n\n\n\n\_\nArchives, Culture, and Heritage\
        \ Reform Act 2000 (as amended)\n\nParliamentary Counsel Office\n\n\nhttps://legislation.govt.nz/\n\
        \n\n\n\nBusiness continuity\n\n\n\nISO 22301:2019\n\nSecurity and Resilience\
        \ - Business Continuity Management Systems - Requirements\n\n\nISO\n\n\nhttps://www.iso.org/standard/75106.html\n\
        \n\n\n\nCable security\n\n\n\nNZCSS 400\nNew Zealand Communications Security\
        \ Standard No 400 (Document classified CONFIDENTIAL)\nGCSB\n\nCONFIDENTIAL\
        \ document available on application to authorised personnel\n\n\n\n\nCryptographic\
        \ Security\n\n\n\nNZCSP 301\nNew Zealand Communications Security Policy No\
        \ 301 (Document classified RESTRICTED)\nGCSB\n\nRESTRICTED document available\
        \ on application to authorised personnel\n\n\n\n\nEmanation security\n\n\n\
        \nNZCSS 400\nNew Zealand Communications Security Standard No 400 (Document\
        \ classified CONFIDENTIAL)\nGCSB\n\nCONDFIDENTIAL document available on application\
        \ to authorised personnel\n\n\n\n\nInformation classification\n\n\n\n\_\n\
        Protective Security Requirements (New Zealand Government Security Classification\
        \ System Handling Requirements for protectively marked information and equipment)\n\
        NZSIS\n\nhttps://protectivesecurity.govt.nz\n\n\n\n\nInformation security\
        \ management\_\n\n\n\nISO/IEC 27001:2013\n\nInformation technology \u2014\
        \ Security techniques \u2014 Information security management systems \u2014\
        \ Requirements\n\nISO\n\nhttps://www.iso.org/standard/54534.html\n\n\n\nISO/IEC\
        \ 27002:2022\n\nInformation security, cybersecurity, and privacy protection\
        \ \u2014 Information security controls\n\nISO\n\nhttps://www.iso.org/standard/75652.html\n\
        \n\n\nISO/IEC 270xx series\nOther standards and guidelines in the ISO/IEC\
        \ 270xx series, as appropriate\nISO\n\nhttps://www.iso.org/standards.html\_\
        \n\n\n\n\nKey management \u2013 commercial grade\n\n\n\nISO/IEC 11770\nISO/IEC\
        \ 11770 Parts 1-6: Information Technology \u2013 Security Techniques \u2013\
        \ Key Management\nIS0\n\nhttps://www.iso.org/standards.html\_\n\n\n\n\nManagement\
        \ of electronic records that may be used as evidence\n\n\n\nISO/IEC 27037:2012\_\
        \n\nInformation Technology \u2013 Security Techniques - Guidelines for Identification,\
        \ Collection, Acquisition and Preservation of Digital Evidence\n\n\nISO\n\n\
        \nhttps://www.iso.org/standard/44381.html\n\n\n\nPersonnel security\n\n\n\
        PSR\nProtective Security Requirements\nNZSIS\n\nhttps://protectivesecurity.govt.nz/personnel-security/\n\
        \n\n\n\nPhysical security\n\n\n\nPSR\nProtective Security Requirements\nNZSIS\n\
        \nhttps://protectivesecurity.govt.nz/physical-security/\n\n\n\n\nPrivacy requirements\n\
        \n\n\n\_\nPrivacy Act 2020\n\nOffice of The Privacy Commissioner\nParliamentary\
        \ Counsel Office\n\n\nhttps://privacy.org.nz\n\_\nhttps://legislation.govt.nz/\n\
        \n\n\n\_\nPrivacy advice, guidance and tools to help government agencies improve\
        \ their privacy capability and maturity.\n\nGCPO\n\n\nhttps://digital.govt.nz/standards-and-guidance/privacy-security-and-risk/privacy/\n\
        \n\n\n\nRisk management\n\n\n\nISO 31000:2018\nRisk Management -- Guidelines\n\
        \nISO\n\n\nhttps://www.iso.org/standard/65694.html\n\n\n\nISO/IEC 27005:2018\n\
        Information technology \u2014 Security techniques \u2014 Information security\
        \ risk management\nISO\nhttps://www.iso.org/standard/75281.html\_\n\n\nHB\
        \ 436:2013\n\nRisk Management Guidelines (Companion to withdrawn standard\
        \ ISO 31000:2009)\n\nStandards NZ\nhttps://standards.govt.nz\n\n\nISO Guide\
        \ 73:2009\nRisk Management \u2013 Vocabulary \u2013 Guidelines for use in\
        \ Standards\nISO\nhttps://www.iso.org/standard/44651.html\_\n\n\nNIST SP 800-30\
        \ rev. 1\_\nGuide for conducting Risk Assessments\n\nNIST\n\n\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf\
        \ [PDF, 807 KB]\n\n\n\nSecurity Management\n\n\nHB 167:2006\nSecurity Risk\
        \ Management\nStandards NZ\nhttps://standards.govt.nz\n\n\n\nSecurity And\
        \ Intelligence Legislation\n\n\n\n\_\nIntelligence and Security Act 2017\n\
        \nParliamentary Counsel Office\n\n\nhttps://legislation.govt.nz/\_\n\n\n\n\
        \_\nTelecommunications (Interception Capability and Security) Act 2013 (as\
        \ amended)\n\nParliamentary Counsel Office\n\n\nhttps://legislation.govt.nz/\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: Non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.64.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:1
      ref_id: 1.1.64.R.01
      description: "Controls for classified systems and information within this manual\
        \ with a \u201CMUST\u201D or \u201CMUST NOT\u201D compliance requirement cannot\
        \ be effectively individually risk managed by agencies without jeopardising\
        \ their own, multi-agency or All-of-Government information assurance."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.64.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:1
      ref_id: 1.1.64.R.02
      description: "Controls within this manual with a \u201CSHOULD\u201D and \u201C\
        SHOULD NOT\u201D 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 \u2018MUST\u2019 or \u2018MUST NOT\u2019 requirement, the Accreditation\
        \ Authority can consider the justification for the acceptance of risks, consider\
        \ any mitigations then acknowledge and accept any residual risks."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.64.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:1
      ref_id: 1.1.64.R.03
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.64.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:1
      ref_id: 1.1.64.C.01
      name: 'Control -  All Classifications - Must [CID: 127]'
      description: System owners seeking a dispensation for non-compliance with any
        baseline controls in this manual MUST be granted a dispensation by their Accreditation
        Authority. Where High Assurance Cryptographic Systems (HACS) are implemented,
        the Accreditation Authority will be the Director-General GCSB or a formal
        delegate.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: Justification for non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.65.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:2
      ref_id: 1.1.65.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.65.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:2
      ref_id: 1.1.65.C.01
      name: 'Control -  All Classifications - Must [CID: 131]'
      description: 'System owners seeking a dispensation for non-compliance with baseline
        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.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: Consultation on non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.66.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      ref_id: 1.1.66.R.01
      description: "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\u2019s desire to risk\
        \ manage controls from this manual."
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.66.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      ref_id: 1.1.66.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.66.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      ref_id: 1.1.66.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.66.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      ref_id: 1.1.66.C.01
      name: 'Control -  All Classifications - Must [CID: 137]'
      description: "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."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.66.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:3
      ref_id: 1.1.66.C.02
      name: 'Control -  All Classifications - Must [CID: 138]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: All-of-Government Systems
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.67.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:4
      ref_id: 1.1.67.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.67.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:4
      ref_id: 1.1.67.R.02
      description: Any deviation from the baseline controls specified in the NZISM
        MUST be carefully considered and their implication and risk for all government
        systems understood and agreed by all interested parties.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.67.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:4
      ref_id: 1.1.67.R.03
      description: Interested parties may include the lead agency, the Government
        CIO and key service providers, such as with cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.67.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:4
      ref_id: 1.1.67.C.01
      name: 'Control -  All Classifications - Must [CID: 143]'
      description: 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 baseline
        controls.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: Reviewing non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.68.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:5
      ref_id: 1.1.68.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.68.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:5
      ref_id: 1.1.68.C.01
      name: 'Control -  All Classifications - Should [CID: 146]'
      description: Agencies SHOULD review decisions to be non-compliant with any controls
        at least annually.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:1.1:7:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7
      description: Recording non-compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.69.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:6
      ref_id: 1.1.69.R.01
      description: "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. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.69.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:6
      ref_id: 1.1.69.C.01
      name: 'Control -  All Classifications - Must [CID: 151]'
      description: Agencies MUST retain a copy and maintain a record of the supporting
        risk assessment and decisions to be non-compliant with any baseline controls
        from this manual.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.1.69.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.1:7:6
      ref_id: 1.1.69.C.02
      name: 'Control -  All Classifications - Must [CID: 152]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:1
      ref_id: '1.2'
      name: Applicability, Authority and Compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:1
      ref_id: 1.2.1
      description: Agencies understand and follow the requirements of the New Zealand
        Information Security Manual (NZISM). Protection of government information
        and systems is a core accountability.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:1
      ref_id: 1.2.2
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      description: Applicability
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:2
      ref_id: 1.2.3
      description: 'The NZISM applies to information and systems operated by, or on
        behalf of:


        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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      description: Authority
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.4
      description: "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\u2019s advice and assistance to government\
        \ agencies on information security.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.5
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.6
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.7
      description: The Protective Security Requirements Framework provides a specific
        authority and mandate through a Cabinet Directive CAB MIN (14) 39/38.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.8
      description: "The NZISM is published by the Government Chief Information Security\
        \ Officer (GCISO). See 2.1.20 for more information about the GCISO.\_The GCISO\
        \ mandate:\n\nconfirms the GCISO's ability to set information security standards\
        \ for GCISO mandated agencies;\nclarifies the expectation for the GCISO to\
        \ set assurance activities, and develop assurance methodologies, to meet standards\
        \ and guidelines;\nconfirms GCISO access to information security investment\
        \ information (along with joint System Leads for Data and Digital) from GCISO\
        \ mandated agencies, including baseline spending; and\nconfirms the expectation\
        \ of the GCISO to provide investment advice and guidance to the government\
        \ on cyber security matters for the public sector.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:3
      ref_id: 1.2.9
      description: Agencies mandated under the GCISO authority are those set out as
        mandated agencies in the Protective Security Requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      description: Compliance by smaller agencies
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:4
      ref_id: 1.2.10
      description: As smaller agencies may not always have sufficient staffing or
        budgets to comply with all the requirements of the NZISM, they may choose
        to consolidate their resources with another larger host agency to undertake
        a joint approach.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:4
      ref_id: 1.2.11
      description: "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 the NZISM can be interpreted\
        \ as either relating to the host agency or to both agencies, depending on\
        \ the approach taken."
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:4
      ref_id: 1.2.12
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2
      description: Legislation and other government policy
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:5
      ref_id: 1.2.13
      description: "Agencies should rely on their own inquiries. While the NZISM does\
        \ contain examples of relevant legislation (see table 1.1.63), there is no\
        \ comprehensive consideration of legislation.\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:2:5
      ref_id: 1.2.14
      description: All controls within the NZISM 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 Digital Officer (GCDO).
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:1.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:3
      description: Compliance
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:3:1
      ref_id: 1.2.15.R.01
      description: In complying with the latest version of the NZISM 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.
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:3:1
      ref_id: 1.2.15.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:3:1
      ref_id: 1.2.15.C.01
      name: 'Control -  All Classifications - Must [CID: 177]'
      description: Agencies undertaking system design activities for in-house or out-sourced
        projects MUST use the latest version of the NZISM for information security
        requirements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:1.2.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:1.2:3:1
      ref_id: 1.2.15.C.02
      name: 'Control -  All Classifications - Must [CID: 178]'
      description: When GCSB makes a determination that newly introduced standard,
        policy or guideline within the NZISM, or any additional information security
        policy, is of particular importance, agencies MUST comply with any new specified
        requirements and implementation timeframes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2
      assessable: false
      depth: 1
      ref_id: '2'
      name: Information Security Services within Government
    - urn: urn:defend:risk:req_node:nzism-v3:2.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:2
      ref_id: '2.1'
      name: Overview of Key Agencies
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:1
      ref_id: 2.1.1
      description: Agency security personnel and senior management are aware of and
        utilise information security services offered by the New Zealand Government.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:1
      ref_id: 2.1.2
      description: "This section provides an overview of the GCSB and other government\
        \ organisations providing information security advice to agencies.\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: Government Communications Security Bureau
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:2
      ref_id: 2.1.3
      description: "The Government Communications Security Bureau (GCSB) has two statutory\
        \ missions: intelligence, and cyber security.\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:2
      ref_id: 2.1.4
      description: "Intelligence mission\nThe GCSB uses signals intelligence collection\
        \ capabilities to produce intelligence that provides decision advantage to\
        \ government agencies in conduct of their legislatively mandated functions.\
        \ The provision of this intelligence is one way that the GCSB contributes\
        \ to the safety and security of New Zealand and New Zealand\u2019s interests.\n\
        \_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:2
      ref_id: 2.1.5
      description: "Cyber security mission\nNew Zealand needs cyber security to:\_\
        \n\nprotect and maintain the digital services that the country relies on;\
        \ \_\nprotect its intellectual property; \_\nmaintain its reputation as a\
        \ stable and secure place to do business; and\_\nensure that governmental\
        \ and democratic processes remain free from interference.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:2
      ref_id: 2.1.6
      description: "The National Cyber Security Centre (NCSC) supports the GCSB\u2019\
        s cyber security mission, including the Director-General\u2019s system leadership\
        \ and GCISO responsibilities. \_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: National Cyber Security Centre
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.7
      description: "As the Government\u2019s lead operational cyber security agency,\
        \ the NCSC performs a range of functions, offers services, and supports New\
        \ Zealand government agencies undertake their cyber security responsibilities.\
        \ \_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.8
      description: "The NCSC responds to cyber incidents that potentially affect New\
        \ Zealand\u2019s security or economic wellbeing. It provides advanced cyber\
        \ security services and advice to government agencies and nationally significant\
        \ organisations to help defend them against cyber threats.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.9
      description: On 31 August 2023 CERT NZ was transferred to the NCSC to create
        a single operational cyber security agency.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.10
      description: "The combined agency engages across the economy to improve the\
        \ nation\u2019s cyber resilience. Supporting\_nationally significant organisations,\
        \ businesses, organisations, and individuals who are, or may be, affected\
        \ by cyber security incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.11
      description: "Agencies can contact the NCSC for advice and assistance on the\
        \ reporting and management of information security incidents.\_ The NCSC\u2019\
        s response will be commensurate with the nature and urgency of the information\
        \ security incident (see Section 7.2 \u2013 Reporting information security\
        \ incidents).\_ There is a 24 hour, seven day a week service available if\
        \ necessary, by emailing ncscincidents@ncsc.govt.nz.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.12
      description: The NCSC provides specialist advice and assistance to New Zealand
        government departments in relation to cryptography, communications, and various
        information processing technologies.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.13
      description: "The NCSC publishes the NZISM which sets out the information security\
        \ requirements for New Zealand government organisations. An agency can contact\
        \ the NCSC for advice and assistance relating to the interpretation of the\
        \ NZISM by emailing: nzism@ncsc.govt.nz.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.14
      description: "The NCSC supports regulatory regimes by providing risk assessments\
        \ and advice to identify and manage risks to New Zealand\u2019s national security.\
        \ Network operators can contact the Regulatory Unit by email: ticsa@ncsc.govt.nz.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.15
      description: "The NCSC provides specialised technical security services focussed\
        \ on countering unauthorised surveillance techniques and emanation security\
        \ services focussed on preventing spread of unintentional signals. Contact\
        \ the technical security services team by email:\_techliaison@gcsb.govt.nz.\
        \ \_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.16
      description: "Finally, agencies can contact the NCSC for advice and assistance\
        \ on the purchasing, provision, deployment, operation, and disposal of High\
        \ Assurance Cryptographic Equipment. \_The cryptographic liaison can be contacted\
        \ by email at cryptohelpdesk@gcsb.govt.nz.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:3
      ref_id: 2.1.17
      description: "For general enquiries the NCSC can be contacted on info@ncsc.govt.nz.\_\
        \n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: Government Chief Information Security Officer
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.18
      description: "The Government Chief Information Security Officer (GCISO) is responsible\
        \ for the strategic direction and prioritisation of the New Zealand Government\u2019\
        s approach to information security and offers services to protect the Government's\
        \ most sensitive information."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.19
      description: "The role was created in response to the ongoing evolution of the\
        \ cyber threat environment, emerging vulnerabilities, and technological change\
        \ for the New Zealand Government.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.20
      description: The GCISO role was established by the Te Kawa Mataaho Public Service
        Commission in 2018. In July 2022, the Public Service Commissioner formally
        appointed the GCISO as System Lead for Information Security.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.21
      description: The GCSB Director-General holds the role of GCISO.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.22
      description: "The GCISO draws on the technical expertise, relationships, and\
        \ unique insights of both the NCSC and the GCSB to uplift information security\
        \ practice across government.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.23
      description: "The objective of the GCISO is to uplift cyber resilience in the\
        \ Public Service, and enable secure digital transformation through specific\
        \ initiatives, which focus on:\_\n\npromoting standards and policy.\_\nproviding\
        \ guidance.\_\npromoting secure by design.\_\ntechnical advice.\_\nincreasing\
        \ service delivery.\_\_\nbuilding assurance; and \_\nsupporting the information\
        \ security workforce.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.24
      description: "The NZISM is a key part of the GCISO's standards setting role.\
        \ It is developed by the NCSC as part of its support of the GCISO.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:4
      ref_id: 2.1.25
      description: "The GCISO coordinates its system leadership role with other Te\
        \ Kawa Mataaho Public Service Commission appointed system leaders, particularly\
        \ the Government Chief Digital Officer (GCDO) and the Government Chief Data\
        \ Steward (GCDS).\_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: Government System Leadership
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.26
      description: "Government Chief Digital Officer\nThe GCDO is the government system\
        \ lead for digital. This role oversees the development and management of digital\
        \ for the state sector. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.27
      description: "The GCDO is responsible for:\_\n\nsetting digital policy and standards,\_\
        \nimproving investments,\_\nestablishing and managing services,\_\ndeveloping\
        \ capability, and\_\nsystem assurance (assuring digital government outcomes).\_\
        \n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.28
      description: "Government Chief Data Steward\nThe GCDS is the\_government system\
        \ lead for data. This role supports the use of data as a resource across government\
        \ to help deliver better services to New Zealanders.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.29
      description: "The GCDS responds to new and emerging data issues, and ensures\
        \ that government agencies have the capability and skills to maximise the\
        \ value of data. This is achieved through setting data standards, establishing\
        \ common capabilities, developing data policy, strategy, and planning.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.30
      description: "Government Protective Security Lead\nThe Government Protective\
        \ Security Lead (GPSL) is the functional lead for protective security.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.31
      description: The GPSL provides the formal, system-level, functional leadership
        for government protective security.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.32
      description: 'Government Chief Privacy Officer

        The Government Chief Privacy Officer (GCPO) is the government practice lead
        for privacy. This role leads an all-of-government approach to privacy to raise
        public sector privacy maturity and capability.'
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.33
      description: "The GCPO\_is responsible for: \_\n\nproviding leadership by setting\
        \ the vision for privacy across government,\_\nbuilding capability by supporting\
        \ agencies to lift their capability to meet their privacy responsibilities,\
        \ \_\nproviding assurance on public sector privacy performance,\_and\_\nengaging\
        \ with the Office of the Privacy Commissioner and New Zealanders about privacy.\
        \ \_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.34
      description: "Government Procurement Lead\nThe Government Procurement Lead is\
        \ responsible for strengthening leadership and oversight of suppliers and\
        \ agencies in key procurement sectors.\_ A core part of this role is helping\
        \ to ensure that agencies collaborate around sourcing and purchasing common\
        \ goods and services.\_ New Zealand Government Procurement and Property supports\
        \ the Chief Executive of MBIE in their role as Procurement system lead."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:5
      ref_id: 2.1.35
      description: 'Procurement system leadership works towards a procurement system
        that delivers better value for New Zealand and helps people, communities and
        businesses to thrive. This includes redesigning and repositioning the government
        procurement system to:


        make it easy for government agencies and suppliers to work together.

        lift procurement capability.

        improve the visibility of procurement activities and system performance; and

        facilitate and coordinate cross-agency collaboration.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2
      description: Other government organisations
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.36
      description: "Archives NZ\_ Te Rua Mahara o te K\u0101wanatanga\_\nArchives\
        \ NZ is the regulator of information created by the public sector, and reports\
        \ to Cabinet on the state of Government recordkeeping."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.37
      description: "Controller and Auditor-General\_ Tumuaki o te Mana Arotake\_\n\
        The Controller and Auditor-General has two business units, the Office of the\
        \ Auditor-General, and Audit NZ. Together they give Parliament and the public\
        \ an independent view of how public organisations are operating."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.38
      description: "Department of Internal Affairs\_ Te Tari Taiwhenua\nThe Department\
        \ of Internal Affairs has a range of relevant functions, including digital\
        \ identity and digital safety, and regulatory functions including spam prevention\
        \ and messaging compliance and money laundering. DIA provides guidance to\
        \ support government organisations to use generative AI, cloud, enterprise\
        \ architecture, government domain names, and APIs."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.39
      description: "Department of the Prime Minister and Cabinet\_ Te Tari o te Pirimia\
        \ me te Komiti Matua\nThe Department of the Prime Minister and Cabinet\u2019\
        s purpose is to advance an ambitious, resilient, and well-governed New Zealand.\
        \ The National Security Group business unit provides leadership across New\
        \ Zealand\u2019s national security community towards a secure and resilient\
        \ Aotearoa New Zealand. The DPMC works on the Christchurch Call, critical\
        \ infrastructure, and the National Security Intelligence Priorities."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.40
      description: "Ministry of Business, Innovation & Employment\_ H\u012Bkina Whakatutuki\n\
        The MBIE works to ensure that telecommunications markets operate efficiently,\
        \ and the commerce and ICT infrastructure is well developed. It is responsible\
        \ for maintaining a robust regulatory environment for the ICT sector, and\
        \ works to improve broadband and mobile connectivity for New Zealanders."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.41
      description: "Ministry of Foreign Affairs and Trade\_ Manat\u016B Aorere\nMFAT\
        \ ensures that New Zealander\u2019s can live, do business, travel and communicate\
        \ more safely at home and offshore."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.42
      description: "New Zealand Police\_ Ng\u0101 Pirihimana o Aotearoa \_\nThe Police\
        \ can investigate cybercrime and harmful digital communications.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.43
      description: "New Zealand Security Intelligence Service\_ Te P\u0101 Whakamarumaru\n\
        NZSIS\u2019 mission is to keep NZ and New Zealanders safe and secure. The\
        \ Director-General is the Government Protective Security Lead, and the NZSIS\
        \ manages the Protective Security Requirements framework and maintains the\
        \ Information Security Classification System."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.44
      description: "Office of the Privacy Commissioner\_ Te Mana M\u0101t\u0101pono\
        \ Matatapu\nThe Office of the Privacy Commissioner works to develop and promote\
        \ a culture in which personal information is protected and respected."
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:2:6
      ref_id: 2.1.45
      description: "Public Services Commission\_ Te Kawa Mataaho\nThe Public Services\
        \ Commission monitors Public Service organisations and Chief Executives\u2019\
        \ performance.\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.46
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:3
      ref_id: 2.1.46
      description: "The following websites can be used to obtain additional information\
        \ about the security of government systems:\n\n\n\nOrganisation\nSource\n\n\
        \nArchives New Zealand\nhttps://archives.govt.nz \_\n\n\nAudit New Zealand\n\
        https://auditnz.parliament.nz/\n\n\nOffice of the Auditor-General\nhttps://oag.parliament.nz/\n\
        \n\nDepartment of Internal Affairs\n\nhttps://dia.govt.nz https://digital.govt.nz\n\
        \n\n\nDepartment of Prime Minister and Cabinet\nhttps://dpmc.govt.nz \_\n\n\
        \nGovernment Communications Security Bureau\nhttps://gcsb.govt.nz\_\n\n\n\
        Ministry of Business, Innovation & Employment\nhttps://mbie.govt.nz\n\n\n\
        Ministry of Foreign Affairs and Trade\nhttps://mfat.govt.nz\n\n\nNational\
        \ Cyber Security Centre\nhttps://ncsc.govt.nz\n\n\nNew Zealand Security Intelligence\
        \ Service\nhttps://nzsis.govt.nz\_\n\n\nNew Zealand Police\nhttps://police.govt.nz\n\
        \n\nPrivacy Commissioner\nhttps://privacy.org.nz\n\n\nProtective Security\
        \ Requirements\nhttps://protectivesecurity.govt.nz\n\n\nPublic Service Commission\n\
        https://publicservice.govt.nz\n\n\n\_\n\_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:2.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:4
      description: Organisations providing information security services
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.47.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:4:1
      ref_id: 2.1.47.R.01
      description: If security personnel and senior management are not aware 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.1.47.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.1:4:1
      ref_id: 2.1.47.C.01
      name: 'Control -  All Classifications - Must [CID: 199]'
      description: Security personnel MUST familiarise themselves with the information
        security roles and services provided by New Zealand Government organisations.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:2
      ref_id: '2.2'
      name: Non-Government Engagement and Outsourcing
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:1
      ref_id: 2.2.1
      description: Non-government organisations handling classified information implement
        the same information security and protective measures as government agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:2:1
      ref_id: 2.2.2
      description: This section covers information on outsourcing information technology
        services and functions to contractors and commercial entities as well as providing
        those partners with necessary classified information in order to undertake
        their contracted duties.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:2
      description: Cloud computing
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:2:2
      ref_id: 2.2.3
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:3
      ref_id: 2.2.4
      description: "Additional information on third party service providers is supplied\
        \ in the PSR.\n\n\n\nReference\nTitle\nSource\n\n\nPSR Mandatory Requirements\n\
        GOV4, GOV5,\_INFOSEC1, INFOSEC2,\_PERSEC1,\_ PERSEC2, PERSEC3, and PERSEC4\n\
        \nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements\nPersonnel security (PERSEC) | Protective Security Requirements\n\
        \n\nPSR content protocols\n\nManagement protocol for information security\n\
        Management protocol for personnel security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\n\n\nPSR\_requirements sections\n\
        \nSupply chain security\n\nSupply chain security | Protective Security Requirements\n\
        \n\nManaging specific scenarios\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nOutsourcing, Offshoring and supply chains\n\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4
      description: Outsourcing information technology services and functions
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.R.04
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 216]'
      description: "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\u2019s 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."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:1
      ref_id: 2.2.5.C.02
      name: 'Control -  All Classifications - Should Not [CID: 217]'
      description: "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\u2019s CISO should be consulted."
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4
      description: Independence of ITSMs from outsourced companies
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:2
      ref_id: 2.2.6.R.01
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:2
      ref_id: 2.2.6.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:2
      ref_id: 2.2.6.C.01
      name: 'Control -  All Classifications - Should [CID: 221]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:2
      ref_id: 2.2.6.C.02
      name: 'Control -  All Classifications - Should [CID: 222]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4
      description: Developing a contractor management program
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:3
      ref_id: 2.2.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.2:4:3
      ref_id: 2.2.7.C.01
      name: 'Control -  All Classifications - Should [CID: 225]'
      description: Agencies SHOULD develop a program to manage contractors that have
        been accredited for the provision of off-site information technology services
        and functions.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:2
      ref_id: '2.3'
      name: Using Cloud Services
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3
      name: 'Objective '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:1
      ref_id: 2.3.1
      description: "Agencies understand and manage their cloud services to ensure\
        \ they are secure, effective and efficient.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3
      name: 'Context '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2
      description: 'Scope '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:1
      ref_id: 2.3.2
      description: "This section provides guidance on agency responsibilities when\
        \ using cloud services.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:1
      ref_id: 2.3.3
      description: "It is important that agencies understand their responsibilities\
        \ with respect to the use of cloud services.\_ Agency official and classified\
        \ information, regardless of the system that it is held in (including cloud\
        \ services), is still required to be protected in accordance with Cabinet\
        \ directives, the\_Protective Security Requirements\_(PSR), the NZISM, the\_\
        New Zealand Government Security Classification System and with other government\
        \ security requirements and guidance"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:1
      ref_id: 2.3.4
      description: "Reference should also be made to the following sections in the\
        \ NZISM:\nChapter 4 \u2013 System Certification and Accreditation\nChapter\
        \ 5 \u2013 Information Security Documentation\nChapter 13 \u2013 Decommissioning\
        \ and Disposal\nChapter 16 \u2013 Access Control\nChapter 17 \u2013 Cryptography\n\
        Chapter 19 \u2013 Gateway Security\nChapter 20 \u2013 Data Management\nChapter\
        \ 22 \u2013 Enterprise Systems Security\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:1
      ref_id: 2.3.5
      description: "Detailed controls for Cloud Computing are provided in Section\
        \ 22.1 \u2013 Cloud Computing. Detailed controls for Public Cloud services\
        \ are provided in Chapter 23 - Public Cloud Security."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2
      description: 'Mandates, Directives and Requirements '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.6
      description: 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]
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.7
      description: "In August 2013, the Government introduced their approach to cloud\
        \ computing, establishing a \u2018cloud first\u2019 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 \u2018cloud first\u2019\
        \ policy state service agencies are expected to adopt approved cloud services\
        \ either when faced with new procurements, or a contract extension decision.\
        \ \_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.8
      description: Cabinet also incorporated the cloud risk assessment process into
        the system-wide ICT assurance framework [CAB Min (13) 20/13].
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.9
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.10
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:2
      ref_id: 2.3.11
      description: "In July 2016, new measures were confirmed to accelerate the adoption\
        \ of public cloud services by New Zealand\u2019s government agencies. \_The\
        \ new measures complement existing policies and risk assessment processes\
        \ and provide appropriate checks and balances."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.12
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.13
      description: "Security requirements and drivers in the cloud differ significantly\
        \ from traditional data centre environments requiring new security models\
        \ and architectures. \_Key factors include:\nThe dynamic nature of the cloud\
        \ and its related infrastructure;\nNo customer ownership or control of infrastructure;\n\
        Limited visibility of architectures and transparency of operations;\_\nShared\
        \ (multi-tenanted) physical and virtual environments; and\nMay require re-architecting\
        \ of agency system to optimise use of cloud services.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.14
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.16
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:3
      ref_id: 2.3.17
      description: "The Government Chief Digital Officer (GCDO) has developed a risk\
        \ and assurance framework for cloud computing, which agencies are required\
        \ to follow when they are considering using cloud services.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2
      description: Information Security and Zero Trust
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      ref_id: 2.3.18
      description: "Information security relates to the protection of information\
        \ regardless of its form (electronic or physical).\_ Within government, information\
        \ security has traditionally been construed using the concepts of confidentiality,\
        \ availability and integrity of information."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      ref_id: 2.3.19
      description: 'Relating these concepts to people who access, manage and use that
        information requires the use of methods to provide:

        Authentication;

        Authorisation; and

        Non-repudiation.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      ref_id: 2.3.20
      description: "With the growth of the internet and cloud services, the proliferation\
        \ of data and the growth in malicious and cyber-criminal activities, older\
        \ methods of enabling information security are \u201Cfragile\u201D, can be\
        \ fragmented, and are in some cases, ineffective."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      ref_id: 2.3.21
      description: "Zero Trust is a security concept based around the idea that systems\
        \ and users should not be given access to any information without verification,\
        \ even when they are connected to internal networks.\_ Zero Trust looks to\
        \ acknowledge that the previous concept and approach of using perimeter defences\
        \ and providing free access within the secure perimeter is no longer practical\
        \ or appropriate for securing information assets. As such, it should be replaced\
        \ with robust authentication and verification steps being continuously performed."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:2:4
      ref_id: 2.3.22
      description: "The concept of Zero Trust provides a more complete means of providing\
        \ information security in an internet and cloud environment.\_ Understanding,\
        \ planning for and preparing to adopt cloud services is an ideal time to incorporate\
        \ Zero Trust concepts and principles into an agency\u2019s information security\
        \ policies, operations and information handling, processing storage and disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.23
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:3
      ref_id: 2.3.23
      description: "Additional guidance on cloud services can be found at:\n\n\n\n\
        \nReference\n\n\nTitle\n\nPublisher\nSource\n\n\n\nCAB Min (12) 29/8A\_\n\n\
        \nManaging The Government\u2019s Adoption of Cloud Computing\n\n\nCabinet\
        \ Office\n\nManaging the Government\u2019s adoption of cloud computing | NZ\
        \ Digital government\n\n\n\nCAB Min (13) 20/13\n\n\nImproving Government Information\
        \ and Communications Technology Assurance\n\n\nCabinet Office\n\nCabinet Minute:\
        \ Improving Government Information and Communications Technology (digital.govt.nz)\n\
        \n\n\_\n\nZero Trust Maturity Model\_\_\n\n\nCISA (Cybersecurity and Infrastructure\
        \ Security Agency) Cybersecurity Division\n\nZero Trust Maturity Model | CISA\n\
        \n\n\_\n\nCloud Computing \u2013 Information Security and Privacy Considerations\
        \ April 2014\n\n\nDIA\n\nhttps://digital.govt.nz/assets/Documents/1Cloud-Computing-Information-Security-and-Privacy-Considerations-FINAL2.pdf\
        \ [PDF, 185 KB]\n\n\n\_\n\nStrategy for a Digital Public Service\n\n\nDIA\n\
        \nhttps://digital.govt.nz/digital-government/strategy/strategy-summary/\n\n\
        \n\_\n\nAccelerating the Adoption of Public Cloud Services\n\n\nDIA\n\nhttps://digital.govt.nz/dmsdocument/15-accelerating-the-adoption-of-public-cloud-services/html\n\
        \n\n\_\n\nCloud Risk Assessment Tool [Excel Spreadsheet]\n\n\nDIA\n\nRisk\
        \ assessment tool for public cloud services | NZ Digital government\n\n\n\_\
        \n\nRisk Assessment Process\n\n\nDIA\n\nAssess the risks of using a public\
        \ cloud service | NZ Digital government\n\n\n\_\n\nBuild Security Into Your\
        \ Network\u2019s DNA: The Zero Trust Network Architecture by John Kindervag\_\
        \n\n\nForrester\n\nhttps://virtualstarmedia.com/downloads/Forrester_zero_trust_DNA.pdf\
        \ [PDF 1.06 MB]\n\n\n\_\n\nZero Trust Architectures and Solutions\n\n\nGartner\n\
        \nhttps://gartner.com/teamsiteanalytics/servePDF?g=/imagesrv/media-products/pdf/Qi-An-Xin/Qi-An-Xin-1-1OKONUN2.pdf\n\
        \n\nNIST SP800-207\n\nZero Trust Architecture\n\n\nNIST\n\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf\
        \ [PDF, 944 KB]\n\n\n\_\n\nDeveloping a Framework to improve Critical Infrastructure\
        \ Cybersecurity\n\n\nNIST\n\nhttps://nist.gov/system/files/documents/2017/06/05/040813_forrester_research.pdf\
        \ [PDF, 430 KB]\n\n\n\_\n\nImplementing a Zero Trust Architecture\n\n\nNIST/NCCoE\n\
        \nhttps://nccoe.nist.gov/projects/implementing-zero-trust-architecture\_\n\
        \n\n\_\n\nEmbracing a Zero Trust Security Model\n\n\nNSA\n\nhttps://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF\
        \ [PDF, 643 KB]\n\n\n\_\n\nEvolving Zero Trust \u2013 Microsoft Position Paper\n\
        \n\nMicrosoft\n\nhttps://microsoft.com/en-nz/security/business/zero-trust\_\
        \_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3
      name: 'PSR References '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.24
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:4
      ref_id: 2.3.24
      description: "Additional information on third party providers is provided in\
        \ the PSR.\_\n\n\n\nReference\nTitle\nSource\n\n\nPSR Mandatory Requirements\n\
        \nGOV4, GOV5, INFOSEC1, INFOSEC2, PERSEC1, PERSEC2, PERSEC3 and PERSEC4\n\n\
        \nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements\nPersonnel security (PERSEC) | Protective Security Requirements\n\
        \n\nPSR content protocols\_\n\nManagement protocol for information security\n\
        Management protocol for personnel security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\n\n\nPSR requirements sections\n\
        \nSupply chain security\n\nSupply chain security | Protective Security Requirements\n\
        \n\nManaging specific scenarios\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nOutsourcing, Offshoring and supply chains\nCloud\
        \ Computing\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3
      name: 'Rationale & Controls '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: Cloud Adoption Strategy
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.R.01
      description: "Cloud technologies require a different mindset for the delivery\
        \ of ICT services, as compared to traditional agency-owned IT servers. \_\
        Increasingly, ICT will be available only in \u2018as-a-service\u2019 delivery\
        \ models, which may lead to agencies adopting cloud services in an ad-hoc\
        \ manner unless an overarching strategy is developed and put in place.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.R.02
      description: 'This will introduce new and different risks, including:

        where information is located;

        where it is able to be accessed from;

        who is able to access information; and

        how ICT services are funded and sustained.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.R.03
      description: "Cloud providers are more likely to adopt modern security and development\
        \ approaches, including agile development techniques (e.g. DevOps), Zero Trust\
        \ Networking, serverless computing and continuous integration / continuous\
        \ deployment (CI/CD) pipelines for automation.\_ These approaches are likely\
        \ to be incompatible with existing ICT processes that focus on legacy delivery\
        \ models and may present significant challenges to agencies that are not adequately\
        \ prepared.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.R.04
      description: Developing a strategy that outlines how an agency will look to
        exploit the opportunities presented by cloud while managing the risks and
        change required in ICT governance and management processes is essential to
        the successful adoption of cloud services for agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.C.01
      name: 'Control -  All Classifications - Must [CID: 7045]'
      description: "Agencies intending to adopt public cloud technologies or services\
        \ MUST develop a plan for how they intend to use these services.\_ This plan\
        \ can be standalone or part of an overarching ICT strategy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.25.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:1
      ref_id: 2.3.25.C.02
      name: 'Control -  All Classifications - Should [CID: 7046]'
      description: "An agency\u2019s cloud adoption plan SHOULD cover:\nOutcomes and\
        \ benefits that the adoption of cloud technologies will bring;\nRisks introduced\
        \ or mitigated through the use of cloud, and the agency\u2019s risk tolerance;\n\
        Financial and cost accounting models;\nShared responsibility models;\nCloud\
        \ deployment models;\nCloud security strategy;\nResilience and recovery approaches;\n\
        Data recovery on contract termination;\nCloud exit strategy and other contractual\
        \ arrangements; and\nA high level description of the foundation services that\
        \ enable cloud adoption, including:\n\nUser, device and system identity;\n\
        Encryption and key management;\nInformation management;\nLogging and alerting;\n\
        Incident management;\nManaging privileged activities; and\nCost management.\n\
        \n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: Zero Trust
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:2
      ref_id: 2.3.26.R.01
      description: "Zero Trust is becoming the de-facto approach to ICT system security\
        \ and is recommended by GCSB as the approach agencies should take, particularly\
        \ as part of the adoption of cloud services.Zero Trust is a set of principles\
        \ and outcomes, not an architecture or a solution.\_ You cannot \u2018buy\u2019\
        \ Zero Trust.Zero Trust is compatible with other ICT outcomes, such as improved\
        \ access to information, increased agility and better security.Key aspects\
        \ of Zero Trust focus on:\nVisibility (through telemetry) and analytics of\
        \ how services are functioning \u2013 this comes through as focus on monitoring,\
        \ event gathering and machine learning based analysis; and\nAutomation of\
        \ service delivery and security actions.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.26.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:2
      ref_id: 2.3.26.R.02
      description: Public cloud services are often built following Zero Trust principles,
        and agencies will find adoption of this approach will lead to more successful
        security outcomes than trying to recreate legacy perimeter security controls
        in the cloud.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:2
      ref_id: 2.3.26.C.01
      name: 'Control -  All Classifications - Should [CID: 7049]'
      description: Agencies intending to adopt public cloud technologies or services
        SHOULD incorporate Zero Trust philosophies and concepts.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:2
      ref_id: 2.3.26.C.02
      name: 'Control -  All Classifications - Should [CID: 7050]'
      description: Agencies SHOULD leverage public cloud environment native security
        services as part of legacy system migrations, in preference to recreating
        application architectures that rely on legacy perimeter controls for security.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:3
      ref_id: 2.3.27.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:3
      ref_id: 2.3.27.C.01
      name: 'Control -  All Classifications - Must [CID: 255]'
      description: Agencies intending to adopt cloud technologies or services MUST
        conduct a comprehensive risk assessment, in accordance with the guidance provided
        by the Government Chief Digital Officer (GCDO) before implementation or adoption.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.27.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:3
      ref_id: 2.3.27.C.02
      name: 'Control -  All Classifications - Must [CID: 256]'
      description: "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\u2019s Accreditation Authority."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: Security Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:4
      ref_id: 2.3.28.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:4
      ref_id: 2.3.28.C.01
      name: 'Control -  All Classifications - Should [CID: 259]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: Selection of Services
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:5
      ref_id: 2.3.29.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:5
      ref_id: 2.3.29.C.01
      name: 'Control -  All Classifications - Must [CID: 4935]'
      description: Agencies MUST consider the use of any All of Government contracts
        with cloud service providers before negotiating individual contracts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:2.3:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5
      description: System Decommissioning and Contract Termination
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:6
      ref_id: 2.3.30.R.01
      description: "It is important that agencies understand how and where their data\
        \ is processed, managed, stored, backed up and archived within the cloud service\
        \ provider\u2019s environment (systems architecture). \_This may result in\
        \ multiple copies of agency data in several data centres, possibly also in\
        \ several countries."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:6
      ref_id: 2.3.30.R.02
      description: "When an agency system or service is decommissioned or a service\
        \ provider\u2019s contract terminated, it is important that agencies ensure\
        \ data is returned to the agency and no copies are retained by the service\
        \ provider."
    - urn: urn:defend:risk:req_node:nzism-v3:2.3.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.3:5:6
      ref_id: 2.3.30.C.01
      name: 'Control -  All Classifications - Should [CID: 263]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:2
      ref_id: '2.4'
      name: Preparation for Post-Quantum Cryptography
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:1
      ref_id: 2.4.1
      description: Agencies are prepared for the impacts that widespread availability
        of quantum computing will have on information security.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:1
      ref_id: 2.4.2
      description: This section provides information for agencies to assist with preparation
        for the impacts of quantum computing on information security, and more specifically
        impacts related to encryption.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.3
      description: "There has been a substantial amount of research on quantum computers\
        \ \u2013 machines that exploit quantum mechanical phenomena to solve mathematical\
        \ problems that are difficult or intractable for conventional computers. The\
        \ pace of this research is accelerating."
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.4
      description: The development of quantum computing is a rapidly advancing area
        with multiple innovations being announced regularly, often eclipsing previous
        forecasts.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.5
      description: "Quantum computers are not expected to fully replace classical\
        \ computers as quantum effects are currently useful only on particular tasks.\
        \ However quantum computers will be able to rapidly solve highly complex problems,\
        \ well beyond the capabilities of today\u2019s supercomputers."
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.6
      description: A prominent area of quantum computing applicability is in the field
        of cryptanalysis, and it is expected that they will be able to compromise
        or render ineffective many of the public-key cryptosystems currently in use.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.7
      description: "It is important that agencies are aware of the potential impact\
        \ developments in quantum computing are likely to have on critical security\
        \ controls such as encryption.\_ It is also important that they are preparing\
        \ to act to minimise the disruptions that could be caused during migrations\
        \ to post-quantum cryptography (cryptographic systems that remain secure after\
        \ the widespread availability of quantum computing)."
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:2
      ref_id: 2.4.8
      description: Currently there are no post-quantum cryptographic systems approved
        for use in the NZISM, however there are actions that agencies can undertake
        to prepare for the time when such systems are approved.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2
      description: Post-Quantum Cryptographic Standards
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:3
      ref_id: 2.4.9
      description: "International organisations are evaluating potential candidates\
        \ for standardisation in post-quantum cryptography.\_ GCSB will review applicable\
        \ standards and consider them for incorporation into the NZISM when they are\
        \ published."
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:3
      ref_id: 2.4.10
      description: When standards for quantum-resistant public key cryptography become
        available, GCSB may deprecate or withdraw support for existing classical cryptographic
        standards. Agencies should therefore be prepared to transition away from these
        algorithms possibly in the next 2-3 years, even though the standards to migrate
        to are still to be developed.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:2:3
      ref_id: 2.4.11
      description: Until new quantum-resistant algorithms are standardised, agencies
        should maintain or strengthen their existing cryptographic position using
        the algorithms, protocols and key lengths specified in Chapter 17 - Cryptography.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:3
      ref_id: 2.4.12
      description: "Additional guidance on post-quantum cryptography can be found\
        \ at:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_\nGetting Ready for\
        \ Post-Quantum Cryptography\n\nNIST\nNational Institute for Standards and\
        \ Technology\n\nhttps://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04282021.pdf\
        \ [PDF, 401 KB]\n\n\n\_\nPost-Quantum Cryptography Project (NIST)\n\nNIST\n\
        National Institute for Standards and Technology\n\nhttps://csrc.nist.gov/projects/post-quantum-cryptography\n\
        \n\n\_\nPost-Quantum Cryptography\nDepartment of Homeland Security (US DHS)\n\
        https://dhs.gov/quantum\n\n\n\_\n\nMigration To\_Post-Quantum Cryptography\n\
        \nNational Cybersecurity Center of Excellence (US NCCoE)\nhttps://nccoe.nist.gov/sites/default/files/library/project-descriptions/pqc-migration-project-description-final.pdf\
        \ [PDF, 386 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4
      description: Post-Quantum Cryptography Preparation
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.R.01
      description: International organisations are in the process of developing standards
        for post-quantum cryptographic algorithms. The standards will be reviewed
        and incorporated into the NZISM as they are published.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.R.02
      description: "As standards are still under development the form of post-quantum\
        \ cryptography is not fully determined at this point in time.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.R.03
      description: It is recognised that providing guidance on the concrete and achievable
        steps that can be taken now to prepare for the transition to post-quantum
        cryptography will help ensure a smooth and efficient transition to any new
        standards that become available.
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.01
      name: 'Control -  All Classifications - Should [CID: 7206]'
      description: "Agencies SHOULD ensure they are aware of the latest developments\
        \ in post-quantum cryptography.\_ GCSB is tracking these developments and\
        \ will continue to provide advice through the NZISM."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.02
      name: 'Control -  All Classifications - Should [CID: 7207]'
      description: "Agencies SHOULD maintain an inventory of sensitive and critical\
        \ datasets that must be secured for an extended amount of time.\_ This will\
        \ ensure datasets that may be at risk now and decrypted once a cryptographically\
        \ relevant quantum computer is available are not secured solely through the\
        \ use of quantum vulnerable cryptography."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.03
      name: 'Control -  All Classifications - Should [CID: 7208]'
      description: Agencies SHOULD conduct an inventory of systems using cryptographic
        technologies to determine the potential size and scope of future transition
        work once post-quantum cryptographic systems become available.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.04
      name: 'Control -  All Classifications - Should [CID: 7209]'
      description: Agencies SHOULD identify which systems in their inventory rely
        on public key cryptography and note them as quantum vulnerable in agency risk
        assessments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.05
      name: 'Control -  All Classifications - Should [CID: 7210]'
      description: Agencies SHOULD determine a priority order for quantum vulnerable
        systems to be transitioned from classical cryptography to post-quantum cryptography.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.06
      name: 'Control -  All Classifications - Should [CID: 7211]'
      description: 'Agencies SHOULD consider the following factors when prioritising
        the quantum vulnerable systems:


        Is the system a high value asset based on agency requirements?

        Does the system protect sensitive information (e.g., key stores, passwords,
        root keys, signing keys, personal information, and classified information)?

        Do other systems (internal or external to the agency) depend on the cryptographic
        protections in place on the quantum vulnerable system?

        How long does the data need to be protected?

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:2.4.13.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:2.4:4:1
      ref_id: 2.4.13.C.07
      name: 'Control -  All Classifications - Should [CID: 7212]'
      description: Using the inventory and prioritisation information, agencies SHOULD
        develop a plan for system transitions upon publication of the new post-quantum
        cryptographic standard.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3
      assessable: false
      depth: 1
      ref_id: '3'
      name: Information security governance - roles and responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:3.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:3
      ref_id: '3.1'
      name: The Agency Head
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:1
      ref_id: 3.1.1
      description: The agency head is accountable for information security within
        their agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:1
      ref_id: 3.1.2
      description: This section covers the role of an agency head with respect to
        information security.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2
      description: Chief executive officer /or other title
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:2
      ref_id: 3.1.3
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2
      description: Devolving authority
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:3
      ref_id: 3.1.4
      description: "When the agency head\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:3
      ref_id: 3.1.5
      description: "The Agency Head is also the Accreditation Authority for that agency.\
        \ See\_Section 4.4 \u2013 Accreditation Framework."
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:3
      ref_id: 3.1.6
      description: "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 both the individual\
        \ and of the agency."
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:2:3
      ref_id: 3.1.7
      description: Refer also to Compliance By Smaller Agencies in 1.2.8 for information
        on joint approaches and resource pooling.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3
      description: Delegation of authority
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      ref_id: 3.1.8.R.01
      description: "Where an agency head chooses to delegate their authority as the\
        \ Agency\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      ref_id: 3.1.8.R.02
      description: The most suitable choice for delegated authority is a senior executive
        who has an appropriate level of understanding of the security risks they are
        accepting on behalf of the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      ref_id: 3.1.8.C.01
      name: 'Control -  All Classifications - Must [CID: 282]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      ref_id: 3.1.8.C.02
      name: 'Control -  All Classifications - Should [CID: 283]'
      description: When the agency head delegates their authority, the delegate SHOULD
        be a senior executive who understands the consequences and potential impact
        to the business of the acceptance of residual risk.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:1
      ref_id: 3.1.8.C.03
      name: 'Control -  All Classifications - Should [CID: 284]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.1:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3
      description: Support for information security
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:2
      ref_id: 3.1.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:2
      ref_id: 3.1.9.R.02
      description: If an incident, breach or disclosure of classified information
        occurs in preventable circumstances, the relevant agency head will ultimately
        be held accountable.
    - urn: urn:defend:risk:req_node:nzism-v3:3.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.1:3:2
      ref_id: 3.1.9.C.01
      name: 'Control -  All Classifications - Must [CID: 288]'
      description: The agency head MUST provide support for the development, implementation
        and ongoing maintenance of information security processes within their agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:3
      ref_id: '3.2'
      name: The Chief Information Security Officer
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:1
      ref_id: 3.2.1
      description: The Chief Information Security Officer (CISO) sets the strategic
        direction for information security within their agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2:1
      ref_id: 3.2.2
      description: This section covers the role of a CISO with respect to information
        security within an agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2
      description: Appointing a CISO
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2:2
      ref_id: 3.2.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2:2
      ref_id: 3.2.4
      description: "The introduction of the CISO role and associated responsibilities\
        \ is aimed at providing a more meaningful title for a subset of the security\
        \ executive\u2019s responsibilities that relate to information security within\
        \ their agency."
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2:2
      ref_id: 3.2.5
      description: The CISO should bring accountability and credibility to information
        security management and appointees should be suitably qualified and experienced.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:2:2
      ref_id: 3.2.6
      description: "Where multiple roles are held by the CISO, conflicts of interest\
        \ may occur particularly where operational imperatives conflict with security\
        \ requirements.\_ Good governance and assurance practices 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 can occur."
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:3
      ref_id: 3.2.7
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV1, GOV3, GOV4, GOV8,\_\
        INFOSEC1, INFOSEC2, INFOSEC4,\_PERSEC1, PERSEC2,\_PERSEC3, and\_PERSEC4\n\n\
        \nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements\nPersonnel security (PERSEC) | Protective Security Requirements\n\
        \n\n\nPSR content protocols\n\n\nManagement protocol for information security\n\
        Management protocol for personnel security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \n\nBuild security awareness\nSelf assessment & reporting\nProtective security\
        \ roles & responsibilities\n\_\n\n\nBuilding security awareness | Protective\
        \ Security Requirements\nSelf-assessment and reporting | Protective Security\
        \ Requirements\nRoles and responsibilities | Protective Security Requirements\n\
        \n\n\n\_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: Requirement for a CISO
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.R.01
      description: "The role of the CISO is based on industry and governance good\
        \ practice, and relevant international standards, 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."
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.R.04
      description: "Where multiple roles are held by the CISO, potential conflicts\
        \ of interest should be identified and carefully managed so the agency is\
        \ not disadvantaged.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.R.05
      description: Conflicts of interest may also be apparent where the agency outsources
        the CISO function and that CISO deals with other vendors and organisations.
        In particular required availability, response times and related operational
        criteria should be identified and carefully managed to ensure the agency is
        not disadvantaged.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.C.01
      name: 'Control -  All Classifications - Must [CID: 307]'
      description: "The CISO MUST be:\ncleared for access to all classified information\
        \ processed by the agency\u2019s systems, and\nable to be briefed into any\
        \ compartmented information on the agency\u2019s systems.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.C.02
      name: 'Control -  All Classifications - Should [CID: 308]'
      description: Agencies SHOULD appoint a person to the role of CISO or have the
        role undertaken by an existing person within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.C.03
      name: 'Control -  All Classifications - Should [CID: 309]'
      description: The CISO role SHOULD be undertaken by a member of the Senior Executive
        Team or an equivalent management position.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.C.04
      name: 'Control -  All Classifications - Should [CID: 310]'
      description: The CISO SHOULD be responsible for overseeing the management of
        security personnel within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.8.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:1
      ref_id: 3.2.8.C.05
      name: 'Control -  All Classifications - Should [CID: 311]'
      description: Where multiple roles are held by the CISO any potential conflicts
        of interest SHOULD be identified and carefully managed.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Reporting"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:2
      ref_id: 3.2.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:2
      ref_id: 3.2.9.C.01
      name: 'Control -  All Classifications - Should [CID: 314]'
      description: The CISO SHOULD report directly to the agency head on matters of
        information security within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Security programs"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.R.02
      description: Working with system owners, assessors and accreditors will facilitate
        the determination of appropriate information security policies consistent
        with agency strategies, the requirements of the PSR and in particular the
        NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.C.01
      name: 'Control -  All Classifications - Should [CID: 317]'
      description: "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\u2019s official and classified information."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.C.02
      name: 'Control -  All Classifications - Should [CID: 318]'
      description: The CISO SHOULD be responsible for the development of an information
        security communications plan.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.C.03
      name: 'Control -  All Classifications - Should [CID: 319]'
      description: The CISO SHOULD create and facilitate the agency security risk
        management process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:3
      ref_id: 3.2.10.C.04
      name: 'Control -  All Classifications - Should [CID: 7084]'
      description: "The CISO SHOULD work with system owners, system certifiers and\
        \ system 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."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Ensuring compliance"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:4
      ref_id: 3.2.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:4
      ref_id: 3.2.11.C.01
      name: 'Control -  All Classifications - Should [CID: 322]'
      description: The CISO SHOULD be responsible for establishing mechanisms and
        programs to ensure compliance with the information security policies and standards
        within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:4
      ref_id: 3.2.11.C.02
      name: 'Control -  All Classifications - Should [CID: 323]'
      description: The CISO SHOULD be responsible for ensuring agency compliance with
        the NZISM through facilitating a continuous program of certification and accreditation
        of all agency systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:4
      ref_id: 3.2.11.C.03
      name: 'Control -  All Classifications - Should [CID: 324]'
      description: The CISO SHOULD be responsible for the implementation of information
        security measurement metrics and key performance indicators within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Coordinating security"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:5
      ref_id: 3.2.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:5
      ref_id: 3.2.12.C.01
      name: 'Control -  All Classifications - Should [CID: 327]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:5
      ref_id: 3.2.12.C.02
      name: 'Control -  All Classifications - Should [CID: 328]'
      description: The CISO SHOULD be responsible for coordinating information security
        and security risk management projects between business and information security
        teams.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:5
      ref_id: 3.2.12.C.03
      name: 'Control -  All Classifications - Should [CID: 329]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Working with ICT projects"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:6
      ref_id: 3.2.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:6
      ref_id: 3.2.13.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:6
      ref_id: 3.2.13.C.01
      name: 'Control -  All Classifications - Should [CID: 333]'
      description: The CISO SHOULD provide strategic level guidance for agency ICT
        projects and operations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:6
      ref_id: 3.2.13.C.02
      name: 'Control -  All Classifications - Should [CID: 334]'
      description: The CISO SHOULD liaise with agency technology architecture teams
        to ensure alignment between security and agency architectures.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Working with vendors"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:7
      ref_id: 3.2.14.R.01
      description: Having the CISO coordinate the use of external information security
        resources will ensure that a consistent approach is being applied across the
        agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:7
      ref_id: 3.2.14.C.01
      name: 'Control -  All Classifications - Should [CID: 337]'
      description: The CISO SHOULD coordinate the use of external information security
        resources to the agency including contracting and managing the resources.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Budgeting"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:8
      ref_id: 3.2.15.R.01
      description: Controlling the information security budget will ensure that the
        CISO has sufficient access to funding to support information security projects
        and initiatives.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:8
      ref_id: 3.2.15.C.01
      name: 'Control -  All Classifications - Should [CID: 341]'
      description: The CISO SHOULD be responsible for controlling the information
        security budget.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Information security incidents "
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:9
      ref_id: 3.2.16.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:9
      ref_id: 3.2.16.C.01
      name: 'Control -  All Classifications - Should [CID: 345]'
      description: The CISO SHOULD be fully aware of all information security incidents
        within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Disaster recovery"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:10
      ref_id: 3.2.17.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:10
      ref_id: 3.2.17.C.01
      name: 'Control -  All Classifications - Should [CID: 348]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Training"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:11
      ref_id: 3.2.18.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:11
      ref_id: 3.2.18.C.01
      name: 'Control -  All Classifications - Should [CID: 351]'
      description: The CISO SHOULD be responsible for overseeing the development and
        operation of information security awareness and training programs within the
        agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.2:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4
      description: "Responsibilities \u2013 Providing security knowledge"
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:12
      ref_id: 3.2.19.R.01
      description: The CISO is not expected to be a technical expert on all 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
    - urn: urn:defend:risk:req_node:nzism-v3:3.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.2:4:12
      ref_id: 3.2.19.C.01
      name: 'Control -  All Classifications - Should [CID: 354]'
      description: The CISO SHOULD provide authoritative security advice and have
        familiarity with a range of national and international standards and good
        practice.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:3
      ref_id: '3.3'
      name: Information Technology Security Managers
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:1
      ref_id: 3.3.1
      description: Information Technology Security Managers (ITSM) provide information
        security leadership and management within their agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:2:1
      ref_id: 3.3.2
      description: This section covers the role of an ITSM with respect to information
        security within an agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:2
      description: Information technology security managers
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:2:2
      ref_id: 3.3.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: Requirement for ITSMs
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.C.01
      name: 'Control -  All Classifications - Must [CID: 367]'
      description: Agencies MUST appoint at least one ITSM within their agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.C.02
      name: 'Control -  All Classifications - Must [CID: 368]'
      description: "ITSMs MUST be:\ncleared for access to all classified information\
        \ processed by the agency\u2019s systems; and\nable to be briefed into any\
        \ compartmented information on the agency\u2019s systems.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.C.03
      name: 'Control -  All Classifications - Should [CID: 369]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.C.04
      name: 'Control -  All Classifications - Should [CID: 370]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.4.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:1
      ref_id: 3.3.4.C.05
      name: 'Control -  All Classifications - Should Not [CID: 371]'
      description: ITSMs SHOULD NOT have additional responsibilities beyond those
        needed to fulfil the role as outlined within this manual.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Security programs"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:2
      ref_id: 3.3.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:2
      ref_id: 3.3.5.C.01
      name: 'Control -  All Classifications - Should [CID: 375]'
      description: ITSMs SHOULD work with the CISO to develop an information security
        program within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:2
      ref_id: 3.3.5.C.02
      name: 'Control -  All Classifications - Should [CID: 376]'
      description: ITSMs SHOULD undertake and manage projects to address identified
        security risks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Working with ICT projects"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 379]'
      description: ITSMs MUST be responsible for assisting system owners to obtain
        and maintain the accreditation of their systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 380]'
      description: ITSMs SHOULD identify systems that require security measures and
        assist in the selection of appropriate information security measures for such
        systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.03
      name: 'Control -  All Classifications - Should [CID: 381]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.04
      name: 'Control -  All Classifications - Should [CID: 382]'
      description: "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\u2019s security objectives."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.05
      name: 'Control -  All Classifications - Should [CID: 384]'
      description: "ITSMs SHOULD be included in the agency\u2019s change management\
        \ and change control processes to ensure that risks are properly identified\
        \ and controls are properly applied to manage those risks."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.6.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:3
      ref_id: 3.3.6.C.06
      name: 'Control -  All Classifications - Should [CID: 385]'
      description: ITSMs SHOULD notify the Accreditation Authority of any significant
        change that may affect the accreditation of that system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Working with vendors"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:4
      ref_id: 3.3.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:4
      ref_id: 3.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 388]'
      description: ITSMs SHOULD liaise with vendors and agency purchasing and legal
        areas to establish mutually acceptable information security contracts and
        service-level agreements.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Implementing security"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.C.01
      name: 'Control -  All Classifications - Must [CID: 391]'
      description: ITSMs MUST be responsible for ensuring the development, maintenance,
        updating and implementation of Security Risk Management Plans (SRMPs), Systems
        Security Plans (SSP) and any Standard Operating Procedures (SOPs) for all
        agency systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.C.02
      name: 'Control -  All Classifications - Should [CID: 392]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.C.03
      name: 'Control -  All Classifications - Should [CID: 393]'
      description: ITSMs SHOULD select and coordinate the implementation of controls
        to support and enforce information security policies.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.C.04
      name: 'Control -  All Classifications - Should [CID: 394]'
      description: ITSMs SHOULD provide leadership and direction for the integration
        of information security strategies and architecture with agency business and
        ICT strategies and architecture.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.8.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:5
      ref_id: 3.3.8.C.05
      name: 'Control -  All Classifications - Should [CID: 395]'
      description: ITSMs SHOULD provide technical and managerial expertise for the
        administration of information security management tools.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Budgeting"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:6
      ref_id: 3.3.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:6
      ref_id: 3.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 398]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Reporting"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      ref_id: 3.3.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      ref_id: 3.3.10.C.01
      name: 'Control -  All Classifications - Should [CID: 401]'
      description: ITSMs SHOULD coordinate, measure and report on technical aspects
        of information security management.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      ref_id: 3.3.10.C.02
      name: 'Control -  All Classifications - Should [CID: 402]'
      description: ITSMs SHOULD monitor and report on compliance with information
        security policies, as well as the enforcement of information security policies
        within the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      ref_id: 3.3.10.C.03
      name: 'Control -  All Classifications - Should [CID: 403]'
      description: ITSMs SHOULD provide regular reports on information security incidents
        and other areas of particular concern to the CISO.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:7
      ref_id: 3.3.10.C.04
      name: 'Control -  All Classifications - Should [CID: 404]'
      description: ITSMs SHOULD assess and report on threats, vulnerabilities, and
        residual security risks and recommend remedial actions.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Auditing"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:8
      ref_id: 3.3.11.R.01
      description: "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.\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:8
      ref_id: 3.3.11.C.01
      name: 'Control -  All Classifications - Should [CID: 407]'
      description: ITSMs SHOULD assist system owners and security personnel in understanding
        and responding to audit failures reported by auditors.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Disaster recovery"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:9
      ref_id: 3.3.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:9
      ref_id: 3.3.12.C.01
      name: 'Control -  All Classifications - Should [CID: 410]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Training"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:10
      ref_id: 3.3.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:10
      ref_id: 3.3.13.C.01
      name: 'Control -  All Classifications - Should [CID: 413]'
      description: ITSMs SHOULD provide or arrange for the provision of information
        security awareness and training for all agency personnel.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:10
      ref_id: 3.3.13.C.02
      name: 'Control -  All Classifications - Should [CID: 414]'
      description: ITSMs SHOULD develop technical information materials and workshops
        on information security trends, threats, good practices and control mechanisms
        as appropriate.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: "Responsibilities \u2013 Providing security knowledge"
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:11
      ref_id: 3.3.14.R.01
      description: ITSMs will often have an extensive 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:11
      ref_id: 3.3.14.C.01
      name: 'Control -  All Classifications - Should [CID: 418]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:11
      ref_id: 3.3.14.C.02
      name: 'Control -  All Classifications - Should [CID: 419]'
      description: ITSMs SHOULD provide expert guidance on security matters for ICT
        projects.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.14.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:11
      ref_id: 3.3.14.C.03
      name: 'Control -  All Classifications - Should [CID: 420]'
      description: ITSMs SHOULD provide technical advice for the information security
        steering committee, change management committee and other agency and inter-agency
        committees as required.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.3:3:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3
      description: Responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:12
      ref_id: 3.3.15.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:12
      ref_id: 3.3.15.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.3.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.3:3:12
      ref_id: 3.3.15.C.01
      name: 'Control -  All Classifications - Should [CID: 424]'
      description: The ITSM SHOULD keep the CISO and system owners informed with up-to-date
        information on current threats.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:3
      ref_id: '3.4'
      name: System Owners
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:1
      ref_id: 3.4.1
      description: All systems are allocated a system owner who has responsibility
        for the overall operation, including obtaining and maintaining any certification
        and accreditation, of the allocated system(s).
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:1
      ref_id: 3.4.2
      description: This section covers the role that system owners undertake with
        respect to information security.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:1
      ref_id: 3.4.3
      description: System owners are responsible for the overall operation of the
        system, including any outsourced services such as support, telecommunications
        and cloud.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:1
      ref_id: 3.4.4
      description: "System owners MUST ensure their systems are certified and accredited\
        \ to meet their agency\u2019s operational requirements and that this status\
        \ in maintained."
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2
      description: Assertions in Certification and Accreditation
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      ref_id: 3.4.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      ref_id: 3.4.6
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      ref_id: 3.4.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      ref_id: 3.4.8
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:2:2
      ref_id: 3.4.9
      description: "Assertions are typically characterised as follows:Transactions\
        \ and events\nOccurrence \u2014 the activities recorded have actually taken\
        \ place.\nCompleteness \u2014 all aspects are properly recorded.\nAccuracy\
        \ \u2014 the assets and activities are accurately allocated and recorded.\n\
        Cutoff \u2014 the activities have been recorded in the correct time period.\n\
        Classifications \u2014 are accurate and appropriate.\nPosition on project\
        \ completion\nExistence \u2014 assets, liabilities and equity balances exist.\n\
        Rights and Obligations \u2014 the entity legally controls rights to its assets\
        \ and its liabilities and accurately records obligations.\nCompleteness \u2014\
        \ all aspects are properly recorded.\nValuation and Allocation \u2014 costs\
        \ and assets appropriately valued and allocated.\nPresentation and disclosure\n\
        Occurrence \u2014 the events and implementations have actually occurred.\n\
        Rights and Obligations \u2014 contracts, licences, support and supply agreements\n\
        Completeness \u2014 all disclosures have been included in the statements.\n\
        Classification \u2014 statements are clear and appropriately presented.\n\
        Accuracy and Valuation \u2014 information is disclosed at the appropriate\
        \ amounts.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3
      description: Requirement for system owners
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      ref_id: 3.4.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      ref_id: 3.4.10.R.02
      description: All systems should have a system owner in order to ensure IT governance
        processes are followed and that business requirements are met.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.10.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      ref_id: 3.4.10.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      ref_id: 3.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 442]'
      description: Each system MUST have a system owner who is responsible for the
        operation and maintenance of the system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:1
      ref_id: 3.4.10.C.02
      name: 'Control -  All Classifications - Should [CID: 443]'
      description: System owners SHOULD be a member of the Senior Executive Team or
        an equivalent management position, for large or critical agency systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3
      description: Accreditation responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:2
      ref_id: 3.4.11.R.01
      description: "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\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:2
      ref_id: 3.4.11.C.01
      name: 'Control -  All Classifications - Must [CID: 446]'
      description: System owners MUST obtain and maintain accreditation of their system(s).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3
      description: Documentation responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:3
      ref_id: 3.4.12.R.01
      description: 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 (SSPs) and
        Standard Operating Procedures (SOPs).
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:3
      ref_id: 3.4.12.R.02
      description: "The system owner should involve security personnel in the process\
        \ of developing, redeveloping or updating Systems Information Security documentation,\
        \ to ensure that a holistic approach to information security is mapped to\
        \ the system owner\u2019s understanding of security risks for their specific\
        \ system. Information security documentation is detailed in\_Chapter 5 - Information\
        \ Security documentation. Refer also to\_Chapter 4 - System Certification\
        \ and Accreditation."
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:3
      ref_id: 3.4.12.C.01
      name: 'Control -  All Classifications - Must [CID: 449]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.4.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.4:3:3
      ref_id: 3.4.12.C.02
      name: 'Control -  All Classifications - Must [CID: 450]'
      description: System Owners MUST involve the ITSM in the redevelopment and updates
        of the Information Security documentation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:3
      ref_id: '3.5'
      name: System Users
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:1
      ref_id: 3.5.1
      description: System users comply with information security policies and procedures
        within their agency.
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:2:1
      ref_id: 3.5.2
      description: This section covers the role that system users undertake with respect
        to information security.
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:2
      description: Types of system users
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:2:2
      ref_id: 3.5.3
      description: This section covers responsibilities for all system users i.e.
        users with general access (general users), and users with privileged access
        (privileged users).
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3
      description: Responsibilities of system users
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      ref_id: 3.5.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      ref_id: 3.5.4.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      ref_id: 3.5.4.C.01
      name: 'Control -  All Classifications - Must [CID: 466]'
      description: All system users MUST comply with the relevant security policies
        and procedures for the systems they use.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      ref_id: 3.5.4.C.02
      name: 'Control -  All Classifications - Must [CID: 467]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:3.5.4.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:3.5:3:1
      ref_id: 3.5.4.C.03
      name: 'Control -  All Classifications - Must [CID: 468]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4
      assessable: false
      depth: 1
      ref_id: '4'
      name: System Certification and Accreditation
    - urn: urn:defend:risk:req_node:nzism-v3:4.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:4
      ref_id: '4.1'
      name: The Certification and Accreditation Process
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:1
      ref_id: 4.1.1
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:1
      ref_id: 4.1.2
      description: This section provides a short, high-level description of the C&A
        process.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:1
      ref_id: 4.1.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: The Process
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.6
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.8
      description: An exception applies where High Assurance Cryptographic Equipment
        (HACE) is required or caveated or compartmented information is processed,
        stored or communicated. In this case the Director-General, GCSB is the Accreditation
        Authority.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:2
      ref_id: 4.1.9
      description: The complete C&A process has several elements and stages, illustrated
        in the Block Diagram at the end of this section.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Key Participants
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:3
      ref_id: 4.1.10
      description: '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).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Certification
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:4
      ref_id: 4.1.11
      description: "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 \u2013 Conducting Certifications."
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:4
      ref_id: 4.1.12
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Certification Authorities
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:5
      ref_id: 4.1.13
      description: For all agency information systems the certification authority
        is the CISO unless otherwise delegated by the Agency Head.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:5
      ref_id: 4.1.14
      description: For external organisations or service providers supporting agencies,
        the certification authority is the CISO of the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:5
      ref_id: 4.1.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Accreditation
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:6
      ref_id: 4.1.16
      description: "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 \u2013 Accreditation Framework."
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:6
      ref_id: 4.1.17
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Accreditation Authority
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:7
      ref_id: 4.1.18
      description: For agencies the Accreditation Authority is the agency head or
        their formally authorised delegate.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:7
      ref_id: 4.1.19
      description: For multi-national, multi-agency systems or AoG systems, the Accreditation
        Authority is determined by a formal agreement between the parties involved.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:7
      ref_id: 4.1.20
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:7
      ref_id: 4.1.21
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Conflicts of Interest
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:8
      ref_id: 4.1.22
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:8
      ref_id: 4.1.23
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:8
      ref_id: 4.1.24
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:8
      ref_id: 4.1.25
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2
      description: Penetration Testing
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:9
      ref_id: 4.1.26
      description: Penetration tests are an effective method of identifying vulnerabilities
        in a system or network, and testing existing security measures and 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:9
      ref_id: 4.1.27
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:9
      ref_id: 4.1.28
      description: "Organisations may conduct their own tests and regular simple tests\
        \ are effective in maintaining the organisation\u2019s security posture. Because\
        \ of the level of expertise required to effectively conduct more complex testing,\
        \ comprehensive penetration tests are often outsourced to specialist organisations."
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:2:9
      ref_id: 4.1.29
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1
      name: System Certification and Accreditation Diagram
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.30
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:3
      ref_id: 4.1.30
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.31
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:4
      ref_id: 4.1.31
      description: "Additional information relating to systems governance, certification\
        \ and accreditation can be found at:\n\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\nOffice of the Auditor-General - Managing conflicts of interest:\
        \ A Guide for the public sector\n\n\_Office of the Auditor-General\nhttps://oag.parliament.nz/2020/conflicts/docs/conflicts-of-interest.pdf\
        \ [PDF, 445 KB]\n\n\n\nISO/IEC 27000:2018\n\n\nInformation technology -- Security\
        \ techniques -- Information security management systems -- Overview and vocabulary\n\
        \nISO\n\nISO - ISO/IEC 27000:2018 - Information technology \u2014 Security\
        \ techniques \u2014 Information security management systems \u2014 Overview\
        \ and vocabulary\n\n\n\n\nISO/IEC 27001:2013\_\n\n\nInformation technology\
        \ -- Security techniques -- Information security management systems -- Requirements\n\
        \nISO\nISO - ISO/IEC 27001:2013 - Information technology \u2014 Security techniques\
        \ \u2014 Information security management systems \u2014 Requirements\n\n\n\
        \nISO/IEC 27002:2022\n\nInformation security, cybersecurity, and privacy protection\
        \ \u2014 Information security controls\nISO\nISO - ISO/IEC 27002:2022 - Information\
        \ security, cybersecurity and privacy protection \u2014 Information security\
        \ controls\n\n\n\nISO/IEC 27006:2015\n\n\nInformation Technology \u2013 Security\
        \ Techniques - Requirements for bodies providing audit and certification of\
        \ information security management systems\n\nISO\n\nISO - ISO/IEC 27006:2015\
        \ - Information technology \u2014 Security techniques \u2014 Requirements\
        \ for bodies providing audit and certification of information security management\
        \ systems\n\n\n\n\nISO/IEC 27007:2020\n\n\nInformation Technology \u2013 Security\
        \ Techniques - Guidelines for information security management systems auditing\n\
        \nISO\n\nISO - ISO/IEC 27007:2020 - Information security, cybersecurity and\
        \ privacy protection \u2014 Guidelines for information security management\
        \ systems auditing\n\n\n\n\nNIST SP 800-37 Rev. 1, Feb 2010\_\n\n\nGuide for\
        \ Applying the Risk Management Framework to Federal Information Systems: A\
        \ Security Life Cycle Approach\n\nNIST\nhttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37r1.pdf\
        \ [PDF, 1.51 MB]\n\n\nNIST SP 800-171, Feb\_ 2020\_\nProtecting Controlled\
        \ Unclassified Information in Nonfederal Information Systems and Organizations\n\
        NIST\nhttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf\
        \ [PDF, 880 KB]\n\n\n\_\n\nMitre Engineering Guide - Create and Assess Certification\
        \ and Accreditation Strategies\n\nMITRE\n\nhttp://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/test-and-evaluation/\n\
        \n\n\n\_\nRAND National Defense Research Institute - Implications of Aggregated\
        \ DoD Information Systems for Information Assurance Certification and Accreditation\n\
        \_RAND Corporation\nhttp://www.rand.org/content/dam/rand/pubs/monographs/2010/RAND_MG951.pdf\
        \ [PDF, 662 KB]\n\n\n\_\nAn Introduction to Certification and Accreditation\n\
        \_SANS Institute\nhttps://www.sans.org/white-papers/1259/\n\n\n\_\n\nA Certification\
        \ and Accreditation Plan for Information Systems Security Programs (Evaluating\
        \ the Eff)\n\n\_SANS Institute\nhttps://www.sans.org/white-papers/597/\n\n\
        \n\_\n\nSANS Institute InfoSec Reading Room, Conducting a Penetration Test\
        \ on an Organization,\n\n\_SANS Institute\nhttps://www.sans.org/white-papers/67/\n\
        \n\n\_\n\nManaging Conflict of Interest in the Public Service - OECD GUIDELINES\
        \ AND COUNTRY EXPERIENCES\n\n\_OECD\nhttp://www.oecd.org/gov/ethics/48994419.pdf\
        \ [PDF, 2.59 MB]\n\n\n\_\nData Security Standard (DSS) Information Supplement,\
        \ March 2008, PCI Security Standards Council,\nPCI Security Standards\nhttps://www.pcisecuritystandards.org/documents/information_supplement_11.3.pdf\
        \ [PDF, 1.44 MB]\n\n\n\_\nOWASP Top Ten for 2021\nOWASP\nOWASP Top Ten | OWASP\
        \ Foundation\n\n\n\_\nOWASP Web security testing guide\n\_OWASP\nOWASP Web\
        \ Security Testing Guide | OWASP Foundation\n\n\nInternational Standard on\
        \ Assurance Engagements (ISAE)\_3402\nAssurance Reports on Controls at a Service\
        \ Organization\nInternational Federation of Accountants (IFAC)\nhttps://www.ifac.org/system/files/downloads/b014-2010-iaasb-handbook-isae-3402.pdf\
        \ [PDF, 212 KB]\n\n\n\n\_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:4.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:4.1.32
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.1:5
      ref_id: 4.1.32
      description: "Relevant PSR requirements can be found at:\n\n\n\n\nReference\n\
        \n\nTitle\n\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV2, GOV6, GOV7,\
        \ GOV8,\_INFOSEC1, INFOSEC2,\_INFOSEC3, INFOSEC4,\_PHYSEC1\_and\_PHYSEC2\n\
        \nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements\nPhysical security (PHYSEC) | Protective Security Requirements\n\
        \n\n\n\nPSR\_content protocols\n\n\nManagement protocol for information security\n\
        Management protocol for physical security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\n\nPSR requirements sections\n\
        \n\nTake a risk based approach to information security\nApplying Business\
        \ impact levels\nReporting incidents and conducting security investigations\n\
        Self assessment and reporting\n\_\nProtective security measures\n\nTaking\
        \ a risk-based approach to information security | Protective Security RequirementsApplying\
        \ Business Impact Levels | Protective Security Requirements\nReporting incidents\
        \ and conducting security investigations | Protective Security Requirements\n\
        Self-assessment and reporting | Protective Security Requirements\nComplying\
        \ with the Protective Security Requirements | Protective Security Requirements\n\
        \n\n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nPhysical Security for ICT systems\nTransacting\
        \ online with the public\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:4
      ref_id: '4.2'
      name: Conducting Certifications
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:1
      ref_id: 4.2.1
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:1
      ref_id: 4.2.2
      description: This section covers information on the process of undertaking a
        certification as part of the accreditation process for a system.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2
      description: Certification
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:2
      ref_id: 4.2.3
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:2
      ref_id: 4.2.4
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2
      description: Certification outcome
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:3
      ref_id: 4.2.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2
      description: Certification authorities
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:4
      ref_id: 4.2.6
      description: For all agency information systems the certification authority
        is the CISO unless otherwise delegated by the Agency Head.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:4
      ref_id: 4.2.7
      description: For external organisations or service providers supporting agencies,
        the certification authority is the CISO of the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:2:4
      ref_id: 4.2.8
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:3
      ref_id: 4.2.9
      description: "Additional information relating to system auditing is contained\
        \ in:\_\n\n\nReference\nTitle\nPublisher\nSource\n\n\nISO/IEC 27006:2015\n\
        \nInformation Technology \u2013 Security Techniques - Requirements for bodies\
        \ providing audit and certification of information security management systems\n\
        \n\nISO\n\n\nhttps://www.iso.org/standard/62313.html\n\_\n\n\n\n\nISO/IEC\
        \ 27007:2020\_\n\n\nInformation Technology \u2013 Security Techniques - Guidelines\
        \ for information security management systems auditing\n\n\nISO\n\n\nhttps://www.iso.org/standard/77802.html\n\
        \_\n\n\n\n\nISO 19011:2018\_\n\n\nGuidelines for auditing management systems\n\
        \n\nISO\n\n\nhttps://www.iso.org/standard/70017.html\n\n\n\n\nAS/NZ ISO 19011:2019\n\
        \n\nGuidelines for auditing management systems\n\n\nStandards NZ\n\n\nhttps://standards.govt.nz/\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4
      description: Certification Audit
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:1
      ref_id: 4.2.10.R.01
      description: "The purpose of a Certification Audit is to assess the actual implementation\
        \ and effectiveness of controls for a system against the agency\u2019s risk\
        \ profile, security posture, design specifications, agency policies and compliance\
        \ with the Protective Security Requirements (PSR)\_and in particular the relevant\
        \ NZISM components."
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:1
      ref_id: 4.2.10.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:1
      ref_id: 4.2.10.C.01
      name: 'Control -  All Classifications - Must [CID: 535]'
      description: All systems MUST undergo an audit as part of the certification
        process.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4
      description: Certification decision
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:2
      ref_id: 4.2.11.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:2
      ref_id: 4.2.11.R.02
      description: To cater for the different responsibilities for physical and technical
        Certification & Accreditation, separate reports and recommendations may be
        required.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.11.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:2
      ref_id: 4.2.11.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:2
      ref_id: 4.2.11.C.01
      name: 'Control -  All Classifications - Must [CID: 540]'
      description: "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."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4
      description: Residual security risk assessment
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:3
      ref_id: 4.2.12.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.2:4:3
      ref_id: 4.2.12.C.01
      name: 'Control -  All Classifications - Should [CID: 543]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:4
      ref_id: '4.3'
      name: Conducting Audits
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:1
      ref_id: 4.3.1
      description: "The effectiveness\_of information security measures for systems\
        \ is periodically reviewed and validated."
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:1
      ref_id: 4.3.2
      description: This section covers information on the process of undertaking a
        certification and accreditation audit.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      description: Audit objectives, scope and criteria
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:2
      ref_id: 4.3.3
      description: "The aim of an audit is to review and assess:\nthe risk identification\
        \ and assessment;\ndesign and complexity\_(including the system and security\
        \ architectures);\nany available assurance reports on support or outsourced\
        \ services;\ncontrols selection;\nactual implementation and effectiveness\
        \ of controls for a system; and\nsupporting information security documentation.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:2
      ref_id: 4.3.4
      description: "Only information that is verifiable should be accepted as audit\
        \ evidence.\_ Audit evidence should be recorded."
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      description: Audit outcome
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:3
      ref_id: 4.3.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:3
      ref_id: 4.3.6
      description: Part of this audit is an assessment of whether the control systems
        adequately identify and address risk and information security requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      description: Who can assist with an audit
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:4
      ref_id: 4.3.7
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2
      description: Independent audits
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:2:5
      ref_id: 4.3.8
      description: An audit may be conducted by agency auditors or an independent
        security organisation.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: Audit Evidence
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3
      ref_id: 4.3.9
      description: "Audit evidence can be obtained from documentation described in\
        \ Chapter 5 \u2013 Information Security Documentation.\_Other sources may\
        \ include:\n\n\n\nSource\n\n\n\n\nAgency Strategies and Statements of Intent.\n\
        \n\nAny\_additional process documentation referenced in the documentation\
        \ described in\_the NZISM Chapter 5.\n\n\n\n\nThird party service provider\
        \ agreements.\n\n\nIndependent\_risk assessments or security evaluations,\
        \ such as penetration tests by an\_internal team or an external organization.\n\
        \n\n\n\nThe agency risk identification and assessment \_ process.\n\n\nAny\_\
        internal audit reports, assessments and reviews.\n\n\n\n\nAny statements of\
        \ applicability.\n\n\nAny\_relevant incident reports.\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3
      description: Audit evidence reliability
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3:1
      ref_id: 4.3.10
      description: "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.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3:1
      ref_id: 4.3.11
      description: 'Confirmation should be obtained that:

        Risk owners have been identified; and

        Each risk owner has sufficient accountability and authority to manage their
        identified risks.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3:1
      ref_id: 4.3.12
      description: "Audit evidence can be gathered through the following methods in\
        \ order of preference:\n\n\n\nMethod\n\n\nDescription\n\n\n\n\nInspection\n\
        \n\nPhysical\_inspections can provide an independent confirmation of the physical\
        \ condition\_of the site or systems, its implementation and its management.\n\
        \n\n\n\nAnalytical review\n\n\nReviews\_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.\n\n\n\n\nEnquiry\n\n\nHere\_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.\n\n\n\n\nObservation\n\n\nObservation\_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.\n\n\n\n\
        \nComputations\n\n\nRarely\_used for non-financial records but may include,\
        \ for example, asset registers\_and validation of holdings of accountable\
        \ equipment and software.\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3
      description: Audit evidence sufficiency
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:3:2
      ref_id: 4.3.13
      description: "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:\nMateriality.\_\
        \ 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.\nRisk 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.\nEconomy: 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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:4
      ref_id: 4.3.14
      description: "Further references can be found at:\n\n\nReference\n\_Title\n\_\
        Publisher\n\_Source\n\n\n\nAS/NZ ISO 19011:2019\_\n\n\nGuidelines for auditing\
        \ management systems\n\n\nStandards NZ\n\n\_https://standards.govt.nz/\n\n\
        \n\nISO 19011:2018\n\n\nGuidelines for auditing management systems\n\n\_ISO\n\
        \_https://www.iso.org/standard/70017.html\n\n\n\nISO/IEC 27000:2018\_\n\n\n\
        Information technology -- Security techniques -- Information security management\
        \ systems -- Overview and vocabulary\n\n\_ISO\n\n\_https://www.iso.org/standard/73906.html\n\
        \n\n\n\nISO/IEC 27001:2013\_\n\n\nInformation technology -- Security techniques\
        \ -- Information security management systems -- Requirements\n\n\_ISO\n\_\
        https://www.iso.org/standard/54534.html\n\n\nISO/IEC 27002:2022\n\nInformation\
        \ security, cybersecurity and privacy protection \u2014 Information security\
        \ controls\n\n\_ISO\n\n\_https://www.iso.org/standard/75652.html\n\n\n\nISO/IEC\
        \ 27006:2015\nInformation Technology \u2013 Security Techniques- Requirements\
        \ for bodies providing audit and certification of information security management\
        \ systems\n\_ISO\n\_https://www.iso.org/standard/62313.html\n\n\nISO/IEC 27007:2020\_\
        \nInformation Technology \u2013 Security Techniques - Guidelines for information\
        \ security management systems auditing\n\_ISO\n\_https://www.iso.org/standard/77802.html\n\
        \n\nInternational Standard On Auditing (New Zealand) 500\_\nAudit Evidence\n\
        \n\_External Reporting Board, NZ Audit and Assurance\_Standards Board\n\n\
        https://xrb.govt.nz/standards-for-assurance-practitioners/auditing-standards/isa-nz-500/\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:5
      ref_id: 4.3.15
      description: '



        Reference

        Title

        Source




        PSR Mandatory Requirements



        GOV3, GOV8, INFOSEC1, INFOSEC2, INFOSEC3 and INFOSEC4



        Home | Protective Security Requirements

        Security governance (GOV) | Protective Security Requirements

        Information security (INFOSEC) | Protective Security Requirements





        PSR content protocols



        Management protocol for information security



        Management protocol for information security | Protective Security Requirements





        PSR requirements sections



        Self assessment & reporting



        Self-assessment and reporting | Protective Security Requirements





        Managing specific scenarios


        Managing specific scenarios | Protective Security Requirements

        Transacting online with the public



        '
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: Independence of auditors
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:1
      ref_id: 4.3.16.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:1
      ref_id: 4.3.16.C.01
      name: 'Control -  All Classifications - Should [CID: 562]'
      description: Agencies SHOULD ensure that auditors conducting audits are able
        to demonstrate independence and are not also the system owner or certification
        authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: Audit preparation
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:2
      ref_id: 4.3.17.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:2
      ref_id: 4.3.17.C.01
      name: 'Control -  All Classifications - Must [CID: 565]'
      description: Prior to undertaking the audit the system owner MUST approve the
        system architecture and associated information security documentation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: Audit (first stage)
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.R.01
      description: "Auditing against the risk assessment and subsequent controls selection\
        \ is preferable to a \u2018checklist\u2019 approach where all controls in\
        \ the NZISM are checked for selection and implementation irrespective of applicability."
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.R.03
      description: Without implementing the controls for a system their effectiveness
        cannot be assessed during the second stage of the audit.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.C.01
      name: 'Control -  All Classifications - Must [CID: 569]'
      description: The SecPol, SRMP, SSP, 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.C.02
      name: 'Control -  All Classifications - Must [CID: 570]'
      description: The Information Security Policy (SecPol) MUST be reviewed by the
        auditor to ensure that all applicable controls specified in this manual are
        addressed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.C.03
      name: 'Control -  All Classifications - Should [CID: 571]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.C.04
      name: 'Control -  All Classifications - Should [CID: 572]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.18.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:3
      ref_id: 4.3.18.C.05
      name: 'Control -  All Classifications - Should [CID: 573]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: Implementing controls
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:4
      ref_id: 4.3.19.R.01
      description: System testing is most effective on working systems. Desk checks
        have limited effectiveness in these situations.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:4
      ref_id: 4.3.19.C.01
      name: 'Control -  All Classifications - Must [CID: 576]'
      description: Prior to undertaking any system testing in support of the certification
        process, the system owner MUST implement the controls for the system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: Audit (second stage)
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:5
      ref_id: 4.3.20.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:5
      ref_id: 4.3.20.C.01
      name: 'Control -  All Classifications - Must [CID: 579]'
      description: The implementation of controls MUST be assessed to determine whether
        they have been implemented correctly and are operating effectively.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:5
      ref_id: 4.3.20.C.02
      name: 'Control -  All Classifications - Must [CID: 580]'
      description: The auditor MUST ensure that, where applicable, a physical security
        certification has been awarded by an appropriate physical security certification
        authority.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:5
      ref_id: 4.3.20.C.03
      name: 'Control -  All Classifications - Should [CID: 581]'
      description: The physical security certification SHOULD be less than three (3)
        years old at the time of the audit.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.3:6:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6
      description: 'Report of compliance '
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:6
      ref_id: 4.3.21.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.3.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.3:6:6
      ref_id: 4.3.21.C.01
      name: 'Control -  All Classifications - Must [CID: 584]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:4
      ref_id: '4.4'
      name: Accreditation Framework
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:1
      ref_id: 4.4.1
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:2:1
      ref_id: 4.4.2
      description: This section covers information on the accreditation framework
        for systems.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:2:1
      ref_id: 4.4.3
      description: All types of government held information are covered, including
        Official Information and information subject to privacy requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Accreditation framework
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:1
      ref_id: 4.4.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:1
      ref_id: 4.4.4.C.01
      name: 'Control -  All Classifications - Must [CID: 595]'
      description: Agencies MUST develop an accreditation framework for their agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Accreditation
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.C.01
      name: 'Control -  All Classifications - Must [CID: 599]'
      description: Agencies MUST ensure that each of their systems is awarded accreditation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.C.02
      name: 'Control -  All Classifications - Must [CID: 600]'
      description: Agencies MUST ensure that all systems are awarded accreditation
        before they are used operationally.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.C.03
      name: 'Control -  All Classifications - Must [CID: 601]'
      description: Agencies MUST ensure that all systems are awarded accreditation
        prior to connecting them to any other internal or external system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.5.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:2
      ref_id: 4.4.5.C.04
      name: 'Control -  All Classifications - Should [CID: 602]'
      description: Agencies SHOULD ensure information security monitoring, logging
        and auditing is conducted on all accredited systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Determining authorities
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:3
      ref_id: 4.4.6.R.01
      description: "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 \u2013\
        \ Conducting Accreditations."
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:3
      ref_id: 4.4.6.C.01
      name: 'Control -  All Classifications - Should [CID: 605]'
      description: For multi-national and multi-agency systems, the Certification
        and Accreditation Authorities SHOULD be determined by a formal agreement between
        the parties involved.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Notifying authorities
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:4
      ref_id: 4.4.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:4
      ref_id: 4.4.7.C.01
      name: 'Control -  All Classifications - Should [CID: 608]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:4
      ref_id: 4.4.7.C.02
      name: 'Control -  All Classifications - Should [CID: 609]'
      description: Agencies SHOULD confirm governance arrangements with the certification
        authorities, and with the accreditation authorities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Due diligence
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.R.02
      description: "Methods that an agency may use to ensure that other agencies and\
        \ third parties comply with the agency\u2019s information security expectations\
        \ include:\nassurance and confirmation that the certification and accreditation\
        \ process described in the NZISM is adhered to;\nconducting or utilising any\
        \ third party reviewed assurance reports;\nconducting an accreditation of\
        \ the system being connected to; and/or\nseeking a copy of existing accreditation\
        \ deliverables in order to make their own accreditation determination.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.R.03
      description: "Ultimately, the agency MUST accept any security risks associated\
        \ with connecting their system to the other party\u2019s system. This includes\
        \ the risks of other party\u2019s system potentially being used as a platform\
        \ to attack their system or \u201Cspilling\u201D information requiring subsequent\
        \ clean up processes."
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.R.04
      description: Special care MUST be taken for multi- national, multi-agency and
        All-of-Government systems.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.C.01
      name: 'Control -  All Classifications - Must [CID: 615]'
      description: "Where an agency\u2019s 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."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.C.02
      name: 'Control -  All Classifications - Must [CID: 616]'
      description: "An agency MUST ensure that a third party is aware of the agency\u2019\
        s information security expectations and national security requirements by\
        \ defining expectations in documentation that includes, but is not limited\
        \ to:\ncontract provisions;\_\na memorandum of understanding;\nnon-disclosure\
        \ agreements.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.C.03
      name: 'Control -  All Classifications - Must [CID: 617]'
      description: "An agency MUST ensure that a third party complies with the agency\u2019\
        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."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.8.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:5
      ref_id: 4.4.8.C.04
      name: 'Control -  All Classifications - Should [CID: 618]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Processing restrictions
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:6
      ref_id: 4.4.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:6
      ref_id: 4.4.9.C.01
      name: 'Control -  All Classifications - Must Not [CID: 621]'
      description: Agencies MUST NOT allow a system to process, store or communicate
        classified information above the classification for which the system has received
        accreditation.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Accrediting systems bearing a compartment marking
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:7
      ref_id: 4.4.10.R.01
      description: When processing compartmented information on a system, agencies
        need to ensure that the system has received accreditation.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:7
      ref_id: 4.4.10.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:7
      ref_id: 4.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 624]'
      description: A system that processes, stores or communicates compartmented information
        MUST be accredited by the GCSB.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Requirement for New Zealand control
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:8
      ref_id: 4.4.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:8
      ref_id: 4.4.11.C.01
      name: 'Control -  All Classifications - Must [CID: 627]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3
      description: Reaccreditation
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.R.01
      description: "Agencies should reaccredit their systems at least every two years;\
        \ however, they can exercise an additional one year\u2019s grace if they follow\
        \ the procedures in this manual for non-compliance with a \u2018SHOULD\u2019\
        \ requirement, namely conducting a comprehensive security risk assessment,\
        \ obtaining sign-off by senior management and formal acceptance of residual\
        \ risk."
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.R.03
      description: "Additional reasons for conducting reaccreditation activities could\
        \ include:\nchanges in the agency\u2019s information security policies or\
        \ security posture;\ndetection of new or emerging threats to agency systems;\n\
        the discovery that controls are not operating as effectively as planned;\_\
        \na major information security incident; and\na significant change to systems,\
        \ configuration or concept of operation for the accredited system.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.C.01
      name: 'Control -  All Classifications - Must [CID: 632]'
      description: Agencies MUST ensure that the period between accreditations of
        each of their systems does not exceed three years.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.C.02
      name: 'Control -  All Classifications - Must [CID: 633]'
      description: Agencies MUST notify associated agencies where multiple agencies
        are connected to agency systems operating with expired accreditations.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.C.03
      name: 'Control -  All Classifications - Must [CID: 634]'
      description: Agencies MUST notify the Government Chief Digital Officer (GCDO)
        where All-of-Government systems are connected to agency systems operating
        with expired accreditations.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.C.04
      name: 'Control -  All Classifications - Must Not [CID: 635]'
      description: Agencies MUST NOT operate a system without accreditation or with
        a lapsed accreditation unless the accreditation authority has granted a dispensation.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:4.4.12.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.4:3:9
      ref_id: 4.4.12.C.05
      name: 'Control -  All Classifications - Should [CID: 636]'
      description: Agencies SHOULD ensure that the period between accreditations of
        each of their systems does not exceed two years.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:4.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:4
      ref_id: '4.5'
      name: Conducting Accreditations
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:1
      ref_id: 4.5.1
      description: As a governance good practice, systems are accredited before they
        are used operationally.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:1
      ref_id: 4.5.2
      description: This section covers information accreditation processes.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Accreditation aim
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:2
      ref_id: 4.5.3
      description: "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\u2019s governance arrangements."
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Accreditation outcome
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:3
      ref_id: 4.5.4
      description: The outcome of accreditation is an approval to operate issued by
        the Accreditation Authority to the system owner.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Accreditation Authorities
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.5
      description: For agencies the Accreditation Authority is the agency head or
        their formally authorised delegate.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.6
      description: For organisations supporting agencies the Accreditation Authority
        is the head of the supported agency or their authorised delegate.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.7
      description: For multi-national and multi-agency systems the Accreditation Authority
        is determined by a formal agreement between the parties involved.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.8
      description: "For agencies with systems that process, store or communicate\_\
        endorsed or compartmented information, or the use of High Assurance Cryptographic\
        \ Equipment (HACE), the Director-General GCSB is the Accreditation Authority."
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.9
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.10
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:4
      ref_id: 4.5.11
      description: "More information on the delegation of the agency head\u2019s authority\
        \ can be found in Section 3.1 - Agency Head."
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Accreditation outcomes
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:5
      ref_id: 4.5.12
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:5
      ref_id: 4.5.13
      description: 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
        SSP. In such cases the Accreditation Authority may request that the SRMP and
        SSP be amended and security measures reassessed before accreditation is awarded.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:5
      ref_id: 4.5.14
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2
      description: Exception for undertaking certification
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:6
      ref_id: 4.5.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:2:6
      ref_id: 4.5.16
      description: Certification MUST occur as soon as possible as this is an essential
        part of the governance and assurance mechanism.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3
      description: Certification
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:1
      ref_id: 4.5.17.R.01
      description: Certification is an essential component of the governance and assurance
        process and assists and supports risk management.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:1
      ref_id: 4.5.17.C.01
      name: 'Control -  All Classifications - Must [CID: 666]'
      description: All systems MUST be certified as part of the accreditation process.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3
      description: Accreditation decision
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.R.01
      description: "In order to determine the agency\u2019s security posture, a system\
        \ accreditation:\nexamines the risks to systems identified in the certification\
        \ process;\nreviews the controls applied to manage those risks; and then\n\
        determines the acceptability of any residual risk.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.R.04
      description: "To assist in making an accreditation decision the Accreditation\
        \ Authority may choose to review:\nInformation Security Documentation as described\
        \ in Chapter 5;\nany interaction with systems of other agencies or All-of-Government\
        \ systems;\ncompliance audit reports;\nthe accreditation recommendation from\
        \ the certification authority;\nsupporting documentation for any decisions\
        \ to be non-compliant with any controls specified in this manual;\_\nany additional\
        \ security risk reduction strategies that have been implemented; and\nany\
        \ third party reviews or assurance reports available.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.R.05
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.C.01
      name: 'Control -  All Classifications - Must [CID: 673]'
      description: The Accreditation Authority MUST accept the residual security risk
        relating to the operation of a system in order to award accreditation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.C.02
      name: 'Control -  All Classifications - Must [CID: 674]'
      description: The Accreditation Authority MUST advise other agencies where the
        accreditation decision may affect those agencies.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:4.5.18.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:4.5:3:2
      ref_id: 4.5.18.C.03
      name: 'Control -  All Classifications - Must [CID: 675]'
      description: The Accreditation Authority MUST advise the GCDO where the accreditation
        decision may affect any All-of-Government systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5
      assessable: false
      depth: 1
      ref_id: '5'
      name: Information security documentation
    - urn: urn:defend:risk:req_node:nzism-v3:5.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.1'
      name: Documentation Fundamentals
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:1
      ref_id: 5.1.1
      description: "Information\_security documentation is produced for systems, to\
        \ support and demonstrate good governance."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2:1
      ref_id: 5.1.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2:1
      ref_id: 5.1.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2:1
      ref_id: 5.1.4
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2
      description: Information Security Documentation
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:2:2
      ref_id: 5.1.5
      description: 'Information Security Documentation requirements are summarised
        in the table below.



        Title

        Abbreviation

        Reference




        Information Security Policy (incorporates the vulnerability disclosure policy)



        SecPol

        VDP



        5.1.7

        5.9




        Systems Architecture

        -

        5.1.8




        Security Risk Management Plan


        SRMP


        5.1.9





        System Security Plan


        SSP

        5.1.10



        Site Security Plan

        SitePlan

        8.2.7



        Standard Operating Procedures


        SOPs



        5.1.11





        Incident Response Plan


        IRP


        5.1.12





        Emergency Procedures


        EP


        5.1.13





        Independent Assurance reports for externally provided services


        -


        5.8




        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:3
      ref_id: 5.1.6
      description: "Additional information on third party providers is provided in\
        \ the PSR.\_\n\n\n\nReference\nTitle\nSource\n\n\nPSR Mandatory Requirements\n\
        \nGOV4, GOV5, INFOSEC1, INFOSEC2, PERSEC1, PERSEC2, PERSEC3 and PERSEC4\n\n\
        \nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements/\_\_\_\nPersonnel security (PERSEC) | Protective Security Requirements\n\
        \n\nPSR content protocols\_\n\nManagement protocol for information security\n\
        Management protocol for personnel security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\n\_\nManagement protocol for\
        \ personnel security | Protective Security Requirements\n\n\nPSR requirements\
        \ sections\n\nSupply chain security\n\nSupply chain security | Protective\
        \ Security Requirements\n\n\nManaging specific scenarios\n\n\_Managing specific\
        \ scenarios | Protective Security Requirements\n\n\nOutsourcing, Offshoring\
        \ and supply chains\nCloud Computing\n\n\n\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Information Security Policy (SecPol)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:1
      ref_id: 5.1.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:1
      ref_id: 5.1.7.C.01
      name: 'Control -  All Classifications - Must [CID: 692]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Systems Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:2
      ref_id: 5.1.8.R.01
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:2
      ref_id: 5.1.8.R.02
      description: In this context Systems Architecture includes Security Architecture.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:2
      ref_id: 5.1.8.C.01
      name: 'Control -  All Classifications - Must [CID: 696]'
      description: All systems MUST have a documented Systems Architecture.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Security Risk Management Plan (SRMP)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:3
      ref_id: 5.1.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:3
      ref_id: 5.1.9.C.01
      name: 'Control -  All Classifications - Must [CID: 699]'
      description: Agencies MUST ensure that every system is covered by a Security
        Risk Management Plan, which includes identification of risk owners.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: System Security Plan (SSP)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:4
      ref_id: 5.1.10.R.01
      description: The SSP 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 SSP.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:4
      ref_id: 5.1.10.C.01
      name: 'Control -  All Classifications - Must [CID: 702]'
      description: Agencies MUST ensure that every system is covered by a SSP.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Standard Operating Procedures (SOPs)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:5
      ref_id: 5.1.11.R.01
      description: "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\u2019s mechanics. Depending on the documentation\
        \ framework chosen, some procedures common to multiple systems could be consolidated\
        \ into a higher level SOP."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:5
      ref_id: 5.1.11.C.01
      name: 'Control -  All Classifications - Must [CID: 705]'
      description: Agencies MUST ensure that Standard Operating Procedures (SOPs)
        are developed for systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Incident Response Plan (IRP)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:6
      ref_id: 5.1.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:6
      ref_id: 5.1.12.C.01
      name: 'Control -  All Classifications - Must [CID: 708]'
      description: Agencies MUST develop an Incident Response Plan and supporting
        procedures.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:6
      ref_id: 5.1.12.C.02
      name: 'Control -  All Classifications - Must [CID: 709]'
      description: Agency personnel MUST be trained in and periodically exercise the
        Incident Response Plan.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Emergency Procedures (EP)
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:7
      ref_id: 5.1.13.R.01
      description: Classified information and systems are secured if a building emergency
        or evacuation is required.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:7
      ref_id: 5.1.13.C.01
      name: 'Control -  All Classifications - Should [CID: 712]'
      description: Agencies SHOULD document procedures relating to securing classified
        information and systems when required to evacuate a facility in the event
        of an emergency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Developing content
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:8
      ref_id: 5.1.14.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:8
      ref_id: 5.1.14.C.01
      name: 'Control -  All Classifications - Should [CID: 715]'
      description: "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\u2019s business and\
        \ operations"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Documentation content
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:9
      ref_id: 5.1.15.R.01
      description: "As the SRMP, Systems Architecture, SSP, 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\u2019s overarching SecPol."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:9
      ref_id: 5.1.15.C.01
      name: 'Control -  All Classifications - Should [CID: 718]'
      description: "Agencies SHOULD ensure that their SRMP, Systems Architecture,\
        \ SSP, SOPs and IRP are logically connected and consistent for each system,\
        \ other agency systems and with the agency\u2019s SecPol."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Documentation framework
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:10
      ref_id: 5.1.16.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:10
      ref_id: 5.1.16.C.01
      name: 'Control -  All Classifications - Should [CID: 721]'
      description: "Agencies SHOULD create and maintain an overarching document describing\
        \ the agency\u2019s 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."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:10
      ref_id: 5.1.16.C.02
      name: 'Control -  All Classifications - Should [CID: 722]'
      description: Where an agency lacks an existing, well-defined documentation framework,
        they SHOULD use the document names defined in this manual.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Documentation Consistency
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:11
      ref_id: 5.1.17.R.01
      description: Consistency in approach, terminology and documentation simplifies
        the use and interpretation of documentation for different systems and agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.17.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:11
      ref_id: 5.1.17.R.02
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:11
      ref_id: 5.1.17.C.01
      name: 'Control -  All Classifications - Should [CID: 726]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Documentation Classification
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:12
      ref_id: 5.1.18.R.01
      description: Systems documentation will usually reflect the importance or sensitivity
        of particular systems.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:12
      ref_id: 5.1.18.C.01
      name: 'Control -  All Classifications - Must [CID: 729]'
      description: Agencies MUST ensure that their SecPol, SRMP, SSP, SOPs and IRP
        are appropriately classified.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Outsourcing development of content
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:13
      ref_id: 5.1.19.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:13
      ref_id: 5.1.19.C.01
      name: 'Control -  All Classifications - Should [CID: 732]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Obtaining formal sign-off
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:14
      ref_id: 5.1.20.R.01
      description: "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\u2019s business."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:14
      ref_id: 5.1.20.C.01
      name: 'Control -  All Classifications - Should [CID: 735]'
      description: All information security documentation SHOULD be formally approved
        and signed off by a person with an appropriate level of seniority and authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:14
      ref_id: 5.1.20.C.02
      name: 'Control -  All Classifications - Should [CID: 736]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1:4:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4
      description: Documentation Maintenance
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:15
      ref_id: 5.1.21.R.01
      description: "The threat environment and agencies\u2019 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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.21.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:15
      ref_id: 5.1.21.R.02
      description: Changes to risk and technology may dictate a reprioritisation of
        resources in order to maximise the effectiveness of security measures and
        processes.
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:15
      ref_id: 5.1.21.C.01
      name: 'Control -  All Classifications - Should [CID: 767]'
      description: Agencies SHOULD develop a regular schedule for reviewing all information
        security documentation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.1.21.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.1:4:15
      ref_id: 5.1.21.C.02
      name: 'Control -  All Classifications - Should [CID: 768]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.2'
      name: Information Security Policies
    - urn: urn:defend:risk:req_node:nzism-v3:5.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:1
      ref_id: 5.2.1
      description: Information security policies (SecPol) set the strategic direction
        for information security.
    - urn: urn:defend:risk:req_node:nzism-v3:5.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:2:1
      ref_id: 5.2.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3
      description: The Information Security Policy (SecPol)
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      ref_id: 5.2.3.R.01
      description: "To provide consistency in approach and documentation, agencies\
        \ should consider the following when developing their SecPol:\npolicy objectives;\n\
        how the policy objectives will be achieved;\nthe guidelines and legal framework\
        \ under which the policy will operate;\nstakeholders;\neducation and training;\n\
        what resourcing will be available to support the implementation of the policy;\_\
        \nwhat performance measures will be established to ensure that the policy\
        \ is being implemented effectively; and\na review cycle.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.3.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      ref_id: 5.2.3.R.02
      description: In developing the contents of the SecPol, agencies may also consult
        any agency-specific directives that are applicable to information security
        within their agency.
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.3.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      ref_id: 5.2.3.R.03
      description: 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 SSP.
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      ref_id: 5.2.3.C.01
      name: 'Control -  All Classifications - Should [CID: 780]'
      description: The Information Security Policy (SecPol) SHOULD document the information
        security guidelines, standards and responsibilities of an agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.2.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.2:3:1
      ref_id: 5.2.3.C.02
      name: 'Control -  All Classifications - Should [CID: 781]'
      description: '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;

        vulnerability disclosure;

        change management; and

        information security awareness and training.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.3'
      name: Security Risk Management Plans
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:1
      ref_id: 5.3.1
      description: Security Risk Management Plans (SRMP) identify security risks and
        appropriate treatment measures for systems.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:2:1
      ref_id: 5.3.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:2:1
      ref_id: 5.3.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:2:1
      ref_id: 5.3.4
      description: "The agency\u2019s risk identification and assessment process should\
        \ include:\nHow risks are found, recognised and described; and\nHow sources\
        \ of possible risks are to be considered.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:3
      ref_id: 5.3.5
      description: "Information on the development of SRMPs can be found in:\n\n\n\
        Reference\_\nTitle\nPublisher\nSource\n\n\nHB 436:2013\n\nRisk management\
        \ guidelines - Companion to AS/NZS ISO 31000:2009\n\nStandards NZ\nhttps://standards.govt.nz/\n\
        \n\nISO\_22301:2019\nBusiness Continuity\n\nISO\n\nhttps://www.iso.org/standard/75106.html\n\
        \n\nISO\_31000:2018\nRisk Management - Guidelines\n\nISO\n\n\nhttps://www.iso.org/standard/65694.html\n\
        \n\n\nIEC\_31010:2019\nRisk Management \u2013 Risk Assessment Techniques\n\
        \nISO\n\n\nhttps://www.iso.org/standard/72140.html\n\n\n\nISO\_Guide 73:2009\n\
        Risk Management \_- Vocabulary\n\nISO\n\n\nhttps://www.iso.org/standard/44651.html\n\
        \n\n\nISO\_19011:2018\nGuidelines for auditing management systems\nISO\nhttps://www.iso.org/standard/70017.html\n\
        \n\nISO/IEC 27000:2018\nInformation technology - Security techniques - Information\
        \ security management systems - Overview and vocabulary\nISO\n\nhttps://www.iso.org/standard/73906.html\n\
        \n\n\nISO/IEC 27001:2013\nInformation technology - Security techniques -\_\
        Information security management systems - Requirements\nISO\n\nhttps://www.iso.org/standard/54534.html\n\
        \n\n\nISO/IEC\_27005:2018\nInformation Security Risk Management\_\nISO\nhttps://www.iso.org/standard/75281.html\n\
        \n\nISO/IEC 27006:2015\nInformation technology - Security techniques - Requirements\
        \ for bodies providing audit and certification of information security management\
        \ systems\nISO\n\nhttps://www.iso.org/standard/62313.html\n\n\n\nISO/IEC 27007:2020\n\
        Information technology - Security techniques - Guidelines for information\
        \ security management systems auditing\nISO\n\nhttps://www.iso.org/standard/77802.html\n\
        \n\n\nISO/IEC TS 27008:2019\n\nInformation technology - Security techniques\
        \ - Guidelines for the assessment of information security controls\n\nISO\n\
        https://www.iso.org/standard/67397.html\n\n\nISO/IEC 27017:2015\n\nInformation\
        \ technology - Security techniques - Code of practice for information security\
        \ controls based on ISO/IEC 27002 for cloud services\n\nISO\nhttps://www.iso.org/standard/43757.html\n\
        \n\nISO/IEC 27018:2019\nInformation technology - Security techniques - Code\
        \ of practice for protection of personally identifiable information (PII)\
        \ in public clouds acting as PII processors\nISO\nhttps://www.iso.org/standard/76559.html\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4
      description: Agency and system specific security risks
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:1
      ref_id: 5.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:1
      ref_id: 5.3.6.C.01
      name: 'Control -  All Classifications - Should [CID: 802]'
      description: Agencies SHOULD determine agency and system specific security risks
        that could warrant additional controls to those specified in this manual.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4
      description: Contents of SRMPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:2
      ref_id: 5.3.7.R.01
      description: Risks within an agency cannot 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:2
      ref_id: 5.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 805]'
      description: The Security Risk Management Plan SHOULD contain a security risk
        assessment and a corresponding treatment strategy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4
      description: Agency risk management
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:3
      ref_id: 5.3.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:3
      ref_id: 5.3.8.C.01
      name: 'Control -  All Classifications - Should [CID: 808]'
      description: Agencies SHOULD incorporate their SRMP into their wider agency
        risk management plan.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.3:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4
      description: Risk Management standards
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:4
      ref_id: 5.3.9.R.01
      description: "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.\n\
        The Protective Security Requirements\_requires that agencies adopt risk management\
        \ approaches in accordance with ISO 31000:2018. Refer to PSR governance requirement\
        \ GOV2."
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:4
      ref_id: 5.3.9.R.02
      description: "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 \u2013 Guidelines.\
        \ The terms and definitions for this standard can be found in ISO/IEC 31073:2022,\
        \ Risk Management \u2013 Vocabulary. The ISO/IEC 2700x series of standards\
        \ also provides guidance."
    - urn: urn:defend:risk:req_node:nzism-v3:5.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.3:4:4
      ref_id: 5.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 812]'
      description: Agencies SHOULD develop their SRMP in accordance with international
        standards for risk management.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.4'
      name: System Security Plans
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:1
      ref_id: 5.4.1
      description: System Security Plans (SSPs) specify the information security measures
        for systems.
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:2:1
      ref_id: 5.4.2
      description: This section relates to the development of SSPs. Information relating
        to other mandatory documentation can be found in Section 5.1 - Documentation
        Fundamentals.
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:2:1
      ref_id: 5.4.3
      description: Further information to be included in SSPs relating to specific
        functionality or technologies that could be implemented for a system can be
        found in the applicable areas of this manual.
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:2
      description: Stakeholders
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:2:2
      ref_id: 5.4.4
      description: 'There can be many stakeholders involved in defining a SSP including
        representatives from the:

        project, who MUST deliver the capability (including contractors);

        owners of the information to be handled;

        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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3
      description: Contents of System Security Plans (SSPs)
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      ref_id: 5.4.5.R.01
      description: 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 SSP. These controls
        will then be assessed on their implementation and effectiveness during an
        information security assessment as part of the accreditation process.
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      ref_id: 5.4.5.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      ref_id: 5.4.5.C.01
      name: 'Control -  All Classifications - Must [CID: 828]'
      description: "Agencies MUST select controls from this manual to be included\
        \ in the SSP based on the scope of the system with additional system specific\
        \ controls being included as a result of the associated SRMP. Encryption Key\
        \ Management requires specific consideration; refer to Chapter 17 \u2013 Cryptography."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      ref_id: 5.4.5.C.02
      name: 'Control -  All Classifications - Should [CID: 829]'
      description: Agencies SHOULD use the latest baseline of this manual when developing,
        and updating, their SSPs as part of the certification, accreditation and reaccreditation
        of their systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.4.5.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.4:3:1
      ref_id: 5.4.5.C.03
      name: 'Control -  All Classifications - Should [CID: 831]'
      description: Agencies SHOULD include a Key Management Plan in the SSP.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.5'
      name: Standard Operating Procedures
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:1
      ref_id: 5.5.1
      description: Standard Operating Procedures (SOPs) ensure security procedures
        are followed in an appropriate and repeatable manner.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:2:1
      ref_id: 5.5.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      description: Development of SOPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:1
      ref_id: 5.5.3.R.01
      description: 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 SSPs will
        reduce the potential for confusion resulting from conflicts in policy and
        procedures.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:1
      ref_id: 5.5.3.C.01
      name: 'Control -  All Classifications - Should [CID: 844]'
      description: 'Agencies SHOULD develop SOPs for each of the following roles:

        ITSM;

        system administrator; and

        system user.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      description: ITSM SOPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:2
      ref_id: 5.5.4.R.01
      description: The ITSM SOPs are intended to cover the management and leadership
        of information security functions within the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:2
      ref_id: 5.5.4.C.01
      name: 'Control -  All Classifications - Should [CID: 849]'
      description: "The following procedures SHOULD be documented in the ITSMs SOPs.\n\
        \n\nTopic\nProcedures to be included\n\n\nAccess control\nAuthorising access\
        \ rights to applications and data.\n\n\nAsset Musters\nLabelling, registering\
        \ and mustering assets, including media.\n\n\nAudit logs\nReviewing system\
        \ audit trails and manual logs, particularly for privileged users.\n\n\nConfiguration\
        \ control\nApproving and releasing changes to the system software or configurations.\n\
        \n\nInformation security incidents\nDetecting, reporting and managing potential\
        \ information security incidents.\n\n\n\_\nEstablishing the cause of any information\
        \ security incident, whether accidental or deliberate.\n\n\n\_\nActions to\
        \ be taken to recover and minimise the exposure from an information security\
        \ incident.\n\n\n\_\nAdditional actions to prevent reoccurrence.\n\n\nData\
        \ transfers\nManaging the review of media containing classified information\
        \ that is to be transferred off-site.\n\n\n\_\nManaging the review of incoming\
        \ media for malware or unapproved software.\n\n\nIT equipment\nManaging the\
        \ disposal & destruction of unserviceable IT equipment and media.\n\n\nSystem\
        \ Patching\nAdvising and recommending system patches, updates and version\
        \ changes based on security notices and related advisories.\n\n\nSystem integrity\
        \ audit\nReviewing system user accounts, system parameters and access controls\
        \ to ensure that the system is secure.\n\n\n\_\nChecking the integrity of\
        \ system software.\n\n\n\_\nTesting access controls.\n\n\nSystem maintenance\n\
        \nManaging 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.\n\n\n\nUser account management\nAuthorising new system users.\n\
        \n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      description: System Administrator SOPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:3
      ref_id: 5.5.5.R.01
      description: The system administrator SOPs focus on the administrative activities
        related to system operations.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:3
      ref_id: 5.5.5.C.01
      name: 'Control -  All Classifications - Should [CID: 865]'
      description: "The following procedures SHOULD be documented in the system administrator\u2019\
        s SOPs.\_\n\n\nTopic\nProcedures to be included\n\n\nAccess control\nImplementing\
        \ access rights to applications and data.\n\n\nConfiguration control\nImplementing\
        \ changes to the system software or configurations.\n\n\nSystem backup and\
        \ recovery\nBacking up data, including audit logs.\n\n\n\_\nSecuring backup\
        \ tapes.\n\n\n\_\nRecovering from system failures.\n\n\nUser account management\n\
        Adding and removing system users.\n\n\n\_\nSetting system user privileges.\n\
        \n\n\_\nCleaning up directories and files when a system user departs or changes\
        \ roles.\n\n\nIncident response\nDetecting, reporting and managing potential\
        \ information security incidents.\n\n\n\_\nEstablishing the cause of any information\
        \ security incident, whether accidental or deliberate.\n\n\n\_\nActions to\
        \ be taken to recover and minimise the exposure from information security\
        \ incident.\n\n\n\_\nAdditional actions to prevent reoccurrence.\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      description: System User SOPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:4
      ref_id: 5.5.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:4
      ref_id: 5.5.6.C.01
      name: 'Control -  All Classifications - Should [CID: 884]'
      description: "The following procedures SHOULD be documented in the system user\u2019\
        s SOPs.\n\n\nTopic\n\nProcedures to be included\n\n\n\nAcceptable Use\_\n\
        Acceptable uses of the system(s).\n\n\nEnd of day\nHow to secure systems at\
        \ the end of the day.\n\n\n\nInformation security incidents\n\nWhat to do\
        \ in the case of a suspected or actual information security incident.\n\n\n\
        Media control\nProcedures for handling and using media.\n\n\nPasswords\n\n\
        Choosing and protecting passwords.\n\n\n\nTemporary absence\nHow to secure\
        \ systems when temporarily absent.\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.5:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3
      description: Agreement to abide by SOPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:5
      ref_id: 5.5.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.5.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.5:3:5
      ref_id: 5.5.7.C.01
      name: 'Control -  All Classifications - Should [CID: 889]'
      description: ITSMs, system administrators and system users SHOULD sign a statement
        that they have read and agree to abide by their respective SOPs.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.6'
      name: Incident Response Plans
    - urn: urn:defend:risk:req_node:nzism-v3:5.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:1
      ref_id: 5.6.1
      description: Incident Response Plans (IRP) outline actions to take in response
        to an information security incident.
    - urn: urn:defend:risk:req_node:nzism-v3:5.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:2:1
      ref_id: 5.6.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.6:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:3
      description: Contents of IRPs
    - urn: urn:defend:risk:req_node:nzism-v3:5.6.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:3:1
      ref_id: 5.6.3.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.6.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:3:1
      ref_id: 5.6.3.C.01
      name: 'Control -  All Classifications - Must [CID: 902]'
      description: "Agencies MUST include, as a minimum, the following content within\
        \ their IRP:\nbroad guidelines on what constitutes an information security\
        \ incident;\nthe minimum level of information security incident response and\
        \ investigation training for system users and system administrators;\nthe\
        \ authority responsible for initiating investigations of an information security\
        \ incident;\nthe steps necessary to ensure the integrity of evidence supporting\
        \ an information security incident;\nthe steps necessary to ensure that critical\
        \ systems remain operational;\_\nwhen and how to formally report information\
        \ security incidents; and\nnational policy requirements for incident reporting\
        \ (see Chapter 7 \u2013 Information Security Incidents).\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.6.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.6:3:1
      ref_id: 5.6.3.C.02
      name: 'Control -  All Classifications - Should [CID: 904]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.7'
      name: Emergency Procedures
    - urn: urn:defend:risk:req_node:nzism-v3:5.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:1
      ref_id: 5.7.1
      description: Classified information and systems are secured before personnel
        evacuate a facility in the event of an emergency.
    - urn: urn:defend:risk:req_node:nzism-v3:5.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:2:1
      ref_id: 5.7.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:2:1
      ref_id: 5.7.3
      description: The safety of personnel is of paramount importance.
    - urn: urn:defend:risk:req_node:nzism-v3:5.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.7:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:3
      description: Evacuating facilities
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:3:1
      ref_id: 5.7.4.R.01
      description: "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\u2019s credentials for a malicious purpose."
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:3:1
      ref_id: 5.7.4.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.4.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:3:1
      ref_id: 5.7.4.R.03
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.7.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.7:3:1
      ref_id: 5.7.4.C.01
      name: 'Control -  All Classifications - Must [CID: 922]'
      description: Agencies MUST include in procedures for personnel evacuating a
        facility the requirement to secure classified information and systems prior
        to the evacuation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.8
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.8'
      name: Independent Assurance Reports
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:1
      ref_id: 5.8.1
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: 'Context '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:1
      ref_id: 5.8.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2
      description: Purpose
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      ref_id: 5.8.3
      description: "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\u2019s operations,\
        \ they will have a larger impact on organisation\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      ref_id: 5.8.4
      description: "Independent assurance reports provide customers and other interested\
        \ parties with information on policies, procedures and controls related to\
        \ the service provider\u2019s 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\u2019s frameworks,\
        \ control objectives, controls and implementation of controls. They allow:\n\
        Business owners to identify and understand the risks associated with the service\
        \ delivery;\nSystem owners to more fully assess system risks;\nSystem designers\
        \ and security architects to make informed judgements on system structures,\
        \ controls, defensive measures, and enterprise integration; and\nRegulators,\
        \ certifiers and accreditors to obtain assurance over the service providers\
        \ internal control structures and assess the suitability of system structures,\
        \ controls and defensive measures.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      ref_id: 5.8.5
      description: '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.'
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      ref_id: 5.8.6
      description: 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 Accountants (AICPA) or the New
        Zealand External Reporting Board (XRB).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:2
      ref_id: 5.8.7
      description: "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\u2019s COBIT, the IIA, NIST, or the Cloud Security\
        \ Alliance (CSA)."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2
      description: Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:3
      ref_id: 5.8.8
      description: "Assurance is derived from an assessment of:\nA description of\
        \ the service provider\u2019s business and control environment;\nTerms and\
        \ conditions of the service contract or other legally binding agreement;\n\
        Assertions supplied by the service provider (self-assessments);\nAn independent\
        \ validation of service provider assertions;\nIndependent testing of controls\
        \ implementation and effectiveness;\nAssurance in the service design and security\
        \ architecture; and\nAssurance in the service components.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:2:3
      ref_id: 5.8.9
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: Assurance Standards and schemes
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE (NZ) 3000
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:1
      ref_id: 5.8.10
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE (NZ) 3402
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:2
      ref_id: 5.8.11
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE 3402
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:3
      ref_id: 5.8.12
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:3
      ref_id: 5.8.13
      description: "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\u2019s system of internal\
        \ control over financial reporting."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:3
      ref_id: 5.8.14
      description: Auditing and associated consulting firms were required to use ISAE
        3402 for all related work after June 2011.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE 3402 Report Types
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:4
      ref_id: 5.8.15
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:4
      ref_id: 5.8.16
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:4
      ref_id: 5.8.17
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:4
      ref_id: 5.8.18
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE 3402 Report Uses and Limitations
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:5
      ref_id: 5.8.19
      description: "This standard is used to obtain reasonable assurance about whether:\n\
        The service organisation\u2019s description of its system fairly presents\
        \ the system as designed and implemented throughout a specified period or\
        \ a specific date;\nThe controls related to the control objectives stated\
        \ in the service organisation\u2019s description of its system were suitably\
        \ designed throughout the specified period or at the specified date;\nWhere\
        \ 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\u2019s description of its system were\
        \ achieved throughout the specified period.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:5
      ref_id: 5.8.20
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISAE 3402 Report Content
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:6
      ref_id: 5.8.21
      description: "The ISAE 3402 report usually comprises:\nThe service auditor\u2019\
        s report;\nAssertions by the service provider;\nA description of control objectives\
        \ and controls provided by the service organisation;\nResults of any tests\
        \ and other information provided by the independent auditor; and\nAny other\
        \ information provided by the service provider.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: US Standard SSAE 16
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.22
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.23
      description: "SSAE 16 is the US equivalent of the international ISAE 3402 and\
        \ came into effect on15 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:\nIntentional acts by the service providers\
        \ staff;\nAnomalies;\nDirect assistance;\nSubsequent events;\nStatement restricting\
        \ use of the service auditor\u2019s report;\nDisclaimer of Opinion;\nDocumentation\
        \ completion;\nEngagement acceptance and continuance; and\nElements of the\
        \ SSAE 16 report that are not required in the ISAE 3402 report.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.24
      description: "These differences are summarised in the table below:\n\n\n\_\n\
        SSAE 16\nISAE 3402\n\n\nUse of report\nReport specifically states it is restricted\
        \ to intended users.\nReport intended for user entities and their auditors\
        \ but may include other restrictive use conditions.\n\n\n\nIntentional Acts\n\
        \nConsideration of the impact of intention acts.\nNo requirement stated.\n\
        \n\nSubsequent Events\nAuditors must consider Type 2 events after the report\
        \ date.\nEvents after the report date are not considered.\n\n\nReporting\n\
        Sample deviations may not be discarded even when considered non-representative.\n\
        Sample deviations are assessed and may be discarded as not representative\
        \ of the sample population.\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.25
      description: The SSAE 16 standard specifies Type 1 and 2 audits (as does ISAE
        3402).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.26
      description: "A Type 1 is a report on a description of a service organisation\u2019\
        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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:7
      ref_id: 5.8.27
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: AICPA Service Organisation Control Reporting (SOC Reports)
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:8
      ref_id: 5.8.28
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:8
      ref_id: 5.8.29
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:8
      ref_id: 5.8.30
      description: "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\
        \ \u2013 Report on Controls at a Service Organization Relevant to User Entities\u2019\
        \ 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 \u2013 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\u2014 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\u2014 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\n\n\nReport\nStandards\nContent\nAudience\n\n\nSOC1 \u2013\
        \ Type 1\n\nISAE (NZ) 3402/SAE 3150orSSAE 16/AT 801\n\nInternal controls over\
        \ financial reporting at a point in time.\nUser auditors, organisation finance\
        \ team, management.\n\n\nSOC1 \u2013 Type 2\n\nISAE (NZ) 3402/SAE 3150orSSAE\
        \ 16/AT 801\n\nInternal controls over financial reporting over a specified\
        \ time period, minimum 6 months.\nUser auditors, organisation finance team,\
        \ management.\n\n\n\_SOC2 \u2013 Type 1\n\_ISAE (NZ) 3000/\nSAE 3150orAT 101\n\
        \nSecurity, availability, processing integrity, confidentiality and privacy\
        \ controls at a point in time.\nManagement, regulators, third parties under\
        \ Non-Disclosure Agreement.\n\n\n\_SOC2 \u2013 Type 2\n\_ISAE (NZ) 3000/\n\
        SAE 3150orAT 101\n\nSecurity, availability, processing integrity, confidentiality,\
        \ privacy controls and operating effectiveness over a specified time period,\
        \ minimum 6 months.\nManagement, regulators, third parties under Non-Disclosure\
        \ Agreement.\n\n\n\_SOC3\n\_ISAE (NZ) 3000/\nSAE 3150orAT 101\n\nSecurity,\
        \ availability, processing integrity, confidentiality, privacy controls and\
        \ operating effectiveness.\nPublic/general use version of SOC 2, excludes\
        \ details of testing. \_Is less detailed and has less technical content than\
        \ a SOC 2 report.\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: Management Assertions
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:9
      ref_id: 5.8.31
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:9
      ref_id: 5.8.32
      description: "The SSAE 16 requires a written assertion by management. Also known\
        \ as a management\u2019s assertion or service organisation assertion it is\
        \ essentially an assertion made by the service organisation representing and\
        \ asserting to a number of elements, including:\nThe description fairly presents\
        \ the service organisation's system;\nThat 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\nThe 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).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3
      description: ISO/IEC 27001 Certification
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:10
      ref_id: 5.8.33
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:3:10
      ref_id: 5.8.34
      description: "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:\nStage 1 audit (also called Documentation review) checking\
        \ the systems documentation is compliant with ISO 27001;\nStage 2 audit (also\
        \ called Main audit) checking that all the organisation\u2019s activities\
        \ are compliant with both ISO 27001 and the systems documentation.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: Other Guidance
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: "Cloud Security Alliance\u2019s Security, Trust and Assurance Registry\
        \ (STAR) Attestation"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:1
      ref_id: 5.8.35
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:1
      ref_id: 5.8.36
      description: '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:

        Self-assessment;

        Third party assessment based attestation or certification; and

        Continuous monitoring based certification.

        Note: Agencies should note that a self-assessment does not necessarily provide
        substantive assurance.'
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:1
      ref_id: 5.8.37
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:1
      ref_id: 5.8.38
      description: "Agencies can use this registry to further inform their judgement\
        \ on the robustness of assurance over cloud service provider\u2019s internal\
        \ operations and implementation of security controls."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: "Cloud Security Alliance\u2019s Cloud Controls Matric (CCM)"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:2
      ref_id: 5.8.39
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:2
      ref_id: 5.8.40
      description: "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\u2019\
        s BIS, Canada\u2019s PIPEDA, ISACA\u2019s COBIT, the US FedRAMP, HIPAA, Jericho\
        \ Forum, NIST and the NZISM."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: "Cloud Security Alliance\u2019s Consensus Assessments Initiative\
        \ Questionnaire (CAIQ)"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:3
      ref_id: 5.8.41
      description: "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\u2019\
        s evidentiary requirements. The Government Chief Digital Officer (GCDO) 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 GCDO questions."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: 'ISACA IT Audit and Assurance Program for Cloud Computing '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:4
      ref_id: 5.8.42
      description: "Based on ISACA\u2019s 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:\nGreater dependency on third parties;\n\
        Increased complexity of compliance with national and international laws and\
        \ regulations;\nReliance on the Internet as the primary conduit to the enterprise\u2019\
        s data; and\nRisk due to the dynamic nature of cloud computing.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:4
      ref_id: 5.8.43
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:4
      ref_id: 5.8.44
      description: "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\u2019s internal controls, as this\
        \ assurance is often provided through ISAE 3604 or similar reviews."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:4
      ref_id: 5.8.45
      description: "The cloud computing assurance review focusses on the agency\u2019\
        s or organisation\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: ASD Certified Cloud Services
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.46
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:5
      ref_id: 5.8.46
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.47
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:5
      ref_id: 5.8.47
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: NIST 800-53
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.48
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:6
      ref_id: 5.8.48
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.49
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:6
      ref_id: 5.8.49
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: FedRAMP
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.50
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      ref_id: 5.8.50
      description: 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. In addition it was
        intended to minimise cybersecurity risk for Federal Agencies as they move
        operations to the cloud, provide consistent baseline security policies and
        streamline the procurement process.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.51
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      ref_id: 5.8.51
      description: 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.The FedRAMP programme is run by the FedRAMP
        Program Management Office as part of the GSA.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.52
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      ref_id: 5.8.52
      description: "FedRAMP is mandatory for Federal Agency cloud deployments at all\
        \ risk impact levels.\_ Private cloud deployments from single agencies and\
        \ fully implemented within federal facilities are an exception to this mandate.\_\
        \ Quarterly reporting by each agency on their cloud portfolio is required."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.53
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      ref_id: 5.8.53
      description: 'FedRAMP authorises cloud systems in a three step process:

        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 with additional controls specific to cloud deployments, in order
        to grant security authorisations. Cryptographic elements are governed by the
        FIPS 140-2 standards.

        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.

        Ongoing Assessment & Authorisation: Once an authorisation is granted, ongoing
        assessment and authorisation activities are required to maintain the security
        authorisation.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.54
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:7
      ref_id: 5.8.54
      description: 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. A variety of guidance, controls, templates and other documentation
        is available online from the GSA (see References - Assurance Guidance )
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: PCI DSS
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.55
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:8
      ref_id: 5.8.55
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.56
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:8
      ref_id: 5.8.56
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.57
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:8
      ref_id: 5.8.57
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4
      description: COSO
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.58
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:4:9
      ref_id: 5.8.58
      description: "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 \u201Coutsourced service providers\u201D 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."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: "References \u2013 Assurance Standards"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.59
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:5
      ref_id: 5.8.59
      description: "Further information on Assurance Standards can be found in:\n\n\
        \nReference\nTitle\nPublisher\nSource\n\n\n\_SSAE No. 16\n\nStatement on Standards\
        \ for Attestation Engagements -\_Reporting on Controls at a Service Organization\n\
        \nAICPA\nhttps://competency.aicpa.org/media_resources/208710-statement-on-standards-for-attestation-engagements\n\
        \n\n\_\n\nService Organization Controls (SOC) Reports for Service Organizations\_\
        \n\nAICPA\nSOC for Service Organizations: Information for Service Organizations\
        \ (aicpa.org)\n\n\n\_AT Section 101\_\n\nAttest Engagements\n\nAICPA\n\nhttps://aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AT-00101.pdf\n\
        \n\n\n\_AT Section 801\n\nReporting on Controls at a Service Organization\n\
        \nAICPA\n\nhttps://aicpa.org/Research/Standards/AuditAttest/DownloadableDocuments/AT-at-00801.pdf\n\
        \n\n\n\_\n\nCOBIT 5 Framework\n\nISACA\nhttps://www.isaca.org/resources/cobit/cobit-5\n\
        \n\n\nISAE (NZ) 3000 (Revised)\n\n\nInternational Standard on Assurance Engagements\_\
        \ -\_Assurance Engagements Other than Audits or Reviews of Historical Financial\
        \ Information\_\n\nXRB\nhttps://xrb.govt.nz/standards/assurance-standards/other-assurance-engagement-standards/\n\
        \n\n\nISAE (NZ) 3402\n\n\nInternational Standard on Assurance Engagements\_\
        \ -\_Assurance Reports on Controls at a Service Organisation\n\nXRB\nhttps://xrb.govt.nz/standards/assurance-standards/other-assurance-engagement-standards/\n\
        \n\n\nSAE 3150\n\n\nStandard on Assurance Engagements - Assurance Engagement\
        \ on Controls\n\nXRB\nhttps://xrb.govt.nz/standards/assurance-standards/other-assurance-engagement-standards/\n\
        \n\n\nNIST Special Publication 800-53 Revision 4\_\n\n\nSecurity and Privacy\
        \ Controls for Federal Information Systems and Organizations\n\n\nNIST\n\n\
        https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf\
        \ [PDF, 5.05 MB]\n\n\n\nNIST Special Publication\_500-291, Revision 2, July\
        \ 2013\n\n\nNIST Cloud Computing Standards Roadmap\n\n\nNIST\n\nhttps://www.nist.gov/system/files/documents/itl/cloud/NIST_SP-500-291_Version-2_2013_June18_FINAL.pdf\
        \ [PDF, 2.2 MB]\n\n\n\_\n\nPCI DSS\_Information Supplement: Third-Party Security\
        \ Assurance\n\n\nPCI Security Standards Council\n\nhttps://www.pcisecuritystandards.org/documents/ThirdPartySecurityAssurance_March2016_FINAL.pdf\
        \ [PDF, 1.16 MB]\n\n\n\nISO 19011:2018\n\n\nGuidelines for auditing management\
        \ systems\n\nISO\nISO - ISO 19011:2018 - Guidelines for auditing management\
        \ systems \n\n\n\nISO/IEC 27000:2018\n\n\nInformation technology \u2014 Security\
        \ techniques \u2014 Information security management systems \u2014 Overview\
        \ and vocabulary\n\nISO\nhttps://www.iso.org/standard/73906.html\n\n\n\nISO/IEC\
        \ 27001:2013\n\n\nInformation technology \u2014 Security techniques \u2014\
        \ Information security management systems \u2014 Requirements\n\nISO\nhttps://www.iso.org/standard/54534.html\n\
        \n\n\nISO/IEC 27006:2015\n\n\nInformation technology \u2014 Security techniques\
        \ \u2014 Requirements for bodies providing audit and certification of information\
        \ security management systems\n\nISO\nhttps://www.iso.org/standard/62313.html\n\
        \n\n\nISO/IEC 27007:2020\n\n\nInformation security, cybersecurity and privacy\
        \ protection \u2014 Guidelines for information security management systems\
        \ auditing\n\nISO\nhttps://www.iso.org/standard/77802.html\n\n\n\nISO/IEC\
        \ TS 27008:2019\n\n\nInformation technology \u2014 Security techniques \u2014\
        \ Guidelines for the assessment of information security controls\n\nISO\n\
        https://www.iso.org/standard/67397.html\n\n\n\nISO/IEC 27014:2020\n\n\nInformation\
        \ security, cybersecurity and privacy protection \u2014 Governance of information\
        \ security\n\nISO\nhttps://www.iso.org/standard/74046.html\n\n\n\nISO/IEC\
        \ 27017:2015\n\n\nInformation technology \u2014 Security techniques \u2014\
        \ Code of practice for information security controls based on ISO/IEC 27002\
        \ for cloud services\n\nISO\nhttps://www.iso.org/standard/43757.html\n\n\n\
        \nISO/IEC 27018:2019\_\n\n\nInformation technology -- Security techniques\
        \ -- Code of practice for protection of personally identifiable information\
        \ (PII) in public clouds acting as PII processors\n\nISO\nhttps://www.iso.org/standard/76559.html\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: "References \u2013 Assurance Guidance"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.60
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:6
      ref_id: 5.8.60
      description: "\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_\nAll-Of-Government\
        \ Portfolio, Programme and Project Assurance Framework\nDIA\nhttps://digital.govt.nz/standards-and-guidance/governance/system-assurance/all-of-government-portfolio-programme-and-project-assurance-framework/\_\
        \n\n\n\_\nAll-Of-Government ICT Operations Assurance Framework\nDIA\nhttps://digital.govt.nz/standards-and-guidance/governance/system-assurance/all-of-government-ict-operations-assurance-framework/\n\
        \n\n\_\n\nAll-Of-Government Enterprise Risk Maturity Assessment Framework\
        \ (gERMAF)\n\nDIA\nhttps://digital.govt.nz/standards-and-guidance/governance/system-assurance/enterprise-risk-maturity/\n\
        \n\n\_\n\nFAQs \u2014 New Service Organization Standards and Implementation\
        \ Guidance\n\nAmerican Institute of Certified Public Accountants (AICPA)\n\
        https://docplayer.net/13378742-Faqs-new-service-organization-standards-and-implementation-guidance.html\n\
        \n\n\_\n\nThe Federal Risk and Authorization Management Program (FedRAMP)\n\
        \nGeneral Services Administration, US Federal Government\nhttps://www.fedramp.gov/\n\
        \n\n\_\n\nFedRAMP Documents & Templates\n\nGeneral Services Administration,\
        \ US Federal Government\nhttps://www.fedramp.gov/documents-templates/\n\n\n\
        \_\n\nControls and Assurance in the Cloud Using COBIT 5\n\nISACA\nStore -\
        \ Controls & Assurance in the Cloud: Using COBIT 5 | Digital | English - ISACA\
        \ Portal\n\n\n\_\n\nIIA Position Paper:THE THREE LINES OF DEFENSE IN EFFECTIVE\
        \ RISK MANAGEMENT AND CONTROLJANUARY 2013\n\nIIA\n121691 PROF-Position Paper\
        \ 3 Lines of Defense_Digital Version_CX.indd (theiia.fi)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:7
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7
      description: 'Risk Assessment '
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.R.01
      description: "The Security Risk Management Plan (SRMP \u2013 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\u2019\
        s operations."
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.R.03
      description: 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 Government Chief Digital Officer (GCDO) facilitates
        the sharing and re-use of existing cloud assessment materials among agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.C.01
      name: 'Control -  All Classifications - Must [CID: 1019]'
      description: Agencies MUST conduct a risk assessment in order to determine the
        type and level of independent assurance required to satisfy certification
        and accreditation requirements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.C.02
      name: 'Control -  All Classifications - Should [CID: 1020]'
      description: In all cases where assurance on service provider operations cannot
        be obtained directly, agencies SHOULD obtain independent assurance reports.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.61.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:1
      ref_id: 5.8.61.C.03
      name: 'Control -  All Classifications - Should [CID: 1021]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.8:7:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7
      description: Independent Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.62.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:2
      ref_id: 5.8.62.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:5.8.62.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.8:7:2
      ref_id: 5.8.62.C.01
      name: 'Control -  All Classifications - Must [CID: 1024]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.9
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:5
      ref_id: '5.9'
      name: Vulnerability Disclosure Policy (VDP)
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:1
      ref_id: 5.9.1
      description: "Agencies implement a Vulnerability Disclosure Policy (VDP) to\
        \ enable members of the public to report vulnerabilities in the agency\u2019\
        s public-facing systems and applications and receive feedback on such reports."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:1
      ref_id: 5.9.2
      description: "This section provides information on vulnerability disclosure\
        \ for all externally-facing agency systems, including public-facing systems.\_\
        \ Vulnerability disclosure relating to internal systems is covered in Chapter\
        \ 12 \u2013 Product Security.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:1
      ref_id: 5.9.3
      description: "When selecting which systems, applications and data are within\
        \ scope of a VDP, agencies may consider:\n\nThe sensitivity of information\
        \ on the agency\u2019s systems, including financial data, medical information,\
        \ proprietary information, customer data or other personal information.\n\
        Security safeguards that are already in place on the system, such as encryption\
        \ of data at rest.\nThe agency\u2019s ability to segment its network or otherwise\
        \ segregate sensitive information stored on its systems.\nRegulatory, contractual,\
        \ privacy or other restrictions placed on disclosure of protected classes\
        \ of information (such as within the New Zealand Classification System).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:1
      ref_id: 5.9.4
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\nChapter 4 - System Certification and Accreditation;\nChapter\
        \ 5 \u2013 Information Security Documentation;\nSection 6.2 - Vulnerability\
        \ Analysis;\nSection 6.3 - Change Management;\nChapter 7 \u2013 Information\
        \ Security Incidents;\nSection 12.4 \u2013 Product Patching and Updating;\n\
        Chapter 14 - Software Security.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Agencies must expect vulnerabilities
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:2
      ref_id: 5.9.5
      description: "Invariably all software, operating systems and applications have\
        \ the potential to house exploitable vulnerabilities.\_ Many vulnerabilities\
        \ are identified by users and other third parties. Some vulnerabilities may\
        \ be undiscovered or inherent in the application or software.\_ Others may\
        \ be introduced during upgrades, patches, configuration or other changes.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:2
      ref_id: 5.9.6
      description: It is essential that agencies establish a policy and processes
        to identify and remediate such vulnerabilities.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Agencies must establish a vulnerability reporting mechanism
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      ref_id: 5.9.7
      description: Published VDPs demonstrate that an agency has a mature and constructive
        approach when they receive a vulnerability report and also demonstrates openness
        and transparency in the management of agency systems.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      ref_id: 5.9.8
      description: "Agencies should establish a process to allow any user (whether\
        \ a member of the public, business partners, other agencies or agency staff),\
        \ to report potential vulnerabilities.\_ Any such reporting is on a \u201C\
        no blame\u201D basis, without fear of repercussion or penalty, provided the\
        \ agency\u2019s disclosure policy is followed and no illegal activity is undertaken."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      ref_id: 5.9.9
      description: "The VDP must clearly state the conditions under which reports\
        \ are received.\_ In general terms this also includes a \u201Cno bug bounty\u201D\
        \ clause as well as limits on web site, system or application probing."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      ref_id: 5.9.10
      description: "An agency\u2019s VDP will necessarily reflect that they may not\
        \ control or own all of the software they use or the maintenance and development\
        \ of underlying software (such as compilers, programming or scripting languages\
        \ and so on).\_ The VDP should clearly state that while the agency can receive\
        \ reports about software, systems or services run on their behalf by third\
        \ parties, providers or vendors, they may have to work with the reporting\
        \ party to report the vulnerability to the relevant vendor."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:3
      ref_id: 5.9.11
      description: "Where specific legislation applies, for example a reported vulnerability\
        \ may breach the Privacy Act, agencies must adhere to the legislation.\_ This\
        \ may change how reports are managed and action communicated to the finder\
        \ or reporter.\_ This does not change the requirement to maintain communication\
        \ with the reporter/finder."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Agencies are expected to find and remediate vulnerabilities
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:4
      ref_id: 5.9.12
      description: The Protective Security Requirements places clear expectations
        on agencies to maintain awareness of vulnerabilities (see mandatory requirement
        INFOSEC4).
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:4
      ref_id: 5.9.13
      description: "The NZISM section 12.4 - Patching & updating\_sets out expectations\
        \ and controls to ensure security patches are applied in a timely manner."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:4
      ref_id: 5.9.14
      description: "The disclosure period commonly used by many vendors, manufacturers\
        \ and government agencies is 90 days.\_ Vulnerabilities will be either patched,\
        \ mitigated or managed within this period.\_ In some cases earlier notification\
        \ is provided to allow users to take mitigating actions until a patch or other\
        \ solution is available."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:4
      ref_id: 5.9.15
      description: VDPs are expected to include a timeframe within which patches will
        be applied or remedial action taken when a vulnerability is reported to the
        agency.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Agencies to create a vulnerability reporting point
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:5
      ref_id: 5.9.16
      description: When security risks in agency services are discovered and reported
        to the agency, it is vital that a robust communication channel is available
        to receive the report.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:5
      ref_id: 5.9.17
      description: "This is commonly described as a \u201Csecurity.txt\u201D.\_ A\
        \ draft standard has been published (see References below) to help agencies\
        \ (and other organisations) outline a process for security researchers to\
        \ securely report security vulnerabilities."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Vulnerability disclosure policies are a normal part of learning
        about and patching vulnerabilities
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:6
      ref_id: 5.9.18
      description: "Vulnerability disclosure (sometimes also referred to as responsible\
        \ disclosure or coordinated vulnerability disclosure) is now an internationally\
        \ accepted practice for technology organisations.\_ The practice of vulnerability\
        \ disclosure in modern computing dates to the late 1980s.\_ There are related\
        \ examples (non-computing) which appeared in the mid-1800s when locksmiths\
        \ exchanged vulnerability information."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Bug Bounties
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:7
      ref_id: 5.9.19
      description: "\u201CBug bounties\u201D are a monetary reward to security researchers\
        \ for the discovery and reporting of software and other information system\
        \ vulnerabilities to the agency.\_ Bug Bounties are separate to VDPs and should\
        \ only be covered if the agency has a bug bounty programme in place."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2
      description: Vulnerability disclosure policy (VDP) Content
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:2:8
      ref_id: 5.9.20
      description: "A VDP will typically include:\nA scoping statement setting out\
        \ which systems the policy applies to (e.g. the agency\u2019s website and\
        \ other public-facing systems);\nDetails of how finders can contact the agency\u2019\
        s security team (including any public keys for encrypting reports);\nPermitted\
        \ activities;\nAcknowledgement of reports and a response time (typically 60\
        \ or 90 days) for corrections, adjustments, or other \u201Cfixes\u201D;\n\
        Reporters/finders agreeing to not share information about the vulnerability\
        \ until the end of the disclosure period, to let the organisation fix the\
        \ issues before it becomes public;\nIllegal activities are not permitted (specifying\
        \ any relevant legislation, such as the Crimes Act, the Privacy Act etc.);\
        \ and\nEither a statement that bug bounties will not be paid for any discoveries,\
        \ or information about the agency\u2019s bug bounty programme.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:3
      ref_id: 5.9.21
      description: "Additional information relating to system auditing is contained\
        \ in:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_ISO 29147\nInformation\
        \ technology \u2014 Security techniques \u2014 Vulnerability disclosure\n\
        ISO\nhttps://www.iso.org/standard/72311.html\n\n\nISO 30111\nInformation technology\
        \ \u2014 Security techniques \u2014 Vulnerability handling processes\nISO\n\
        https://www.iso.org/standard/69725.html\n\n\nIEFT draft protocol for Security.txt\n\
        A File Format to Aid in Security Vulnerability Disclosure\nITEF\nhttps://datatracker.ietf.org/doc/draft-foudil-securitytxt\n\
        \n\n\_\nA proposed standard which allows websites to define security policies\n\
        \nsecurity.txt\n\nhttps://securitytxt.org/\n\n\n\_\nCERT NZ coordinated vulnerability\
        \ disclosure policy\nCERT NZ\nhttps://www.cert.govt.nz/it-specialists/guides/reporting-a-vulnerability/cert-nz-coordinated-vulnerability-disclosure-policy/\n\
        \n\n\_\nNZITF Coordinated Disclosure guidelines\nNZITF\nhttps://nzitf.org.nz/coordinated-disclosure\n\
        \n\n\_BOD 20-01\nBinding Operational Directive 20-01: Develop and Publish\
        \ a Vulnerability Disclosure Policy\nUS Department of Homeland Security\n\
        https://cyber.dhs.gov/bod/20-01/\n\n\n\_\nVulnerability Disclosure Policy\
        \ Template\nUS Department of Homeland Security\nhttps://cyber.dhs.gov/bod/20-01/vdp-template/\n\
        \n\n\_\nCISA announces new vulnerability disclosure policy (VDP) platform,\
        \ July 2021\nUS Cybersecurity & Infrastructure Security Agency\nhttps://www.cisa.gov/blog/2021/07/29/cisa-announces-new-vulnerability-disclosure-policy-vdp-platform\n\
        \n\n\_\nCISA Coordinated Vulnerability Disclosure (CVD) Process\nUS Cybersecurity\
        \ & Infrastructure Security Agency\nhttps://www.cisa.gov/coordinated-vulnerability-disclosure-process\n\
        \n\nList of US Federal agencies VDPs\nVDPs in the US Government's executive\
        \ branch\nCISA\nhttps://github.com/cisagov/vdp-in-fceb\n\n\n\_\nA Framework\
        \ for a Vulnerability Disclosure Program for Online Systems1 Version 1.0 (July\
        \ 2017)\nCybersecurity Unit Computer Crime & Intellectual Property Section\
        \ Criminal Division U.S. Department of Justice\nhttps://www.justice.gov/criminal-ccips/page/file/983996/download\n\
        \n\n\_\nVulnerability Disclosure Toolkit\n\_NCSC UK\nhttps://www.ncsc.gov.uk/information/vulnerability-disclosure-toolkit\n\
        \n\n\_\nSee Something, Say Something - Coordinating the Disclosure of Security\
        \ Vulnerabilities in Canada\nCanada \u2013 Cybersecure policy exchange\nhttps://www.cybersecurepolicy.ca/vulnerability-disclosure\n\
        \n\n\_\nVulnerability Disclosure Cheat Sheet\n\_OWASP\nhttps://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html\n\
        \n\n\_\nResponsible Disclosure Policy Example\nDutch National Cyber Security\
        \ Centre (NCSC)\n\_https://responsibledisclosure.nl/en/\n\n\n\_\nVulnerability\
        \ disclosure policy\_\nIncibe Cert (Spain)\n\_https://www.incibe-cert.es/en/what-is-incibe-cert/vulnerability-disclosure-policy\
        \ \_\n\n\n\_\nVulnerability disclosure policy\nOffice of the Privacy Commissioner\
        \ New Zealand\nhttps://www.privacy.org.nz/assets/New-order/About-us/Transparency-and-accountability-/Vulnerability-Disclosure-Policy-December-2015.pdf\n\
        \n\n\_\nResponsible disclosure guidelines\nNZ \u2013 The Ministry of Social\
        \ Development\nhttps://www.msd.govt.nz/about-msd-and-our-work/tools/responsible-disclosure-guidelines.html\n\
        \n\n\_\nMinistry of Health Responsible disclosure guidelines\nNZ \u2013 Ministry\
        \ of Health\nhttps://www.health.govt.nz/our-work/digital-health/digital-health-sector-architecture-standards-and-governance/responsible-disclosure-guidelines\n\
        \n\n\_\nVulnerability disclosure policy\nBank of England\nhttps://www.bankofengland.co.uk/vulnerability-disclosure-policy\_\
        \_\n\n\n\_\nVulnerability disclosure policy\nCrown Commercial Service (UK)\n\
        https://www.crowncommercial.gov.uk/about-ccs/vulnerability-disclosure-policy/\n\
        \n\n\_\nVulnerability Disclosure Policy\nMet Office (UK)\nhttps://www.metoffice.gov.uk/about-us/legal/vulnerability-disclosure-policy\n\
        \n\n\_\nHistory of Vulnerability Disclosure, 3 August 2015\nDuo\nhttps://duo.com/labs/research/history-of-vulnerability-disclosure\n\
        \n\n\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.22
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:4
      ref_id: 5.9.22
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\nPSR Mandatory Requirements\nGOV3, INFOSEC1, INFOSEC2, INFOSEC3\
        \ and INFOSEC4\nHome | Protective Security Requirements\_\n\n\nPSR content\
        \ protocols\_\n\nManagement protocol for information security\n\nHome | Protective\
        \ Security Requirements\n\n\nPSR requirements sections\nReview your security\
        \ measures\nHome | Protective Security Requirements\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      description: ' Vulnerability disclosure policy (VDP) Risk Assessment'
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:1
      ref_id: 5.9.23.R.01
      description: Selection of public-facing systems and services included in any
        VDP will be based on a risk assessment undertaken by the agency. Considerations
        for such selection are discussed in the Context section above.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:1
      ref_id: 5.9.23.C.01
      name: 'Control -  All Classifications - Must [CID: 7130]'
      description: "An agency MUST undertake a risk assessment to determine which\
        \ systems and services to include in the agency\u2019s VDP."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      description: ' Vulnerability disclosure policy (VDP) Essential Content'
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:2
      ref_id: 5.9.24.R.01
      description: 'In order to demonstrate a mature and constructive approach to
        vulnerability discovery, management and remediation, an agency requires a
        VDP to inform the public about:

        the scope of public-facing systems covered by its VDP; and

        the nature of vulnerabilities which can be reported under its VDP.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.24.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:2
      ref_id: 5.9.24.R.02
      description: To aid consistency, it is important that government agencies have
        a core set of content in their VDP.
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:2
      ref_id: 5.9.24.C.01
      name: 'Control -  All Classifications - Must [CID: 7133]'
      description: An agency MUST develop and publish a VDP.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:2
      ref_id: 5.9.24.C.02
      name: 'Control -  All Classifications - Must [CID: 7134]'
      description: "An agency\u2019s VDP MUST contain at least the following core\
        \ content:\nA scoping statement listing the systems the policy applies to;\n\
        Contact details;\nSecure communication options (including any public keys);\n\
        Information the finder should include in the report;\nAcknowledgement of reports\
        \ and a response time;\nGuidance on what forms of vulnerability testing are\
        \ out of scope for reporters/finders (permitted activities);\nReporters/finders\
        \ agreeing to not share information about the vulnerability until the end\
        \ of the disclosure period, in order to allow the agency to address any issues\
        \ before they become public;\nIllegal activities are not permitted (specifying\
        \ the relevant legislation, such as the Crimes Act); and\nEither that \u201C\
        Bug bounties\u201D will not be paid for any discoveries, or it should provide\
        \ information about the agency\u2019s bug bounty programme.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      description: ' Vulnerability disclosure policy (VDP) Additional Content'
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:3
      ref_id: 5.9.25.R.01
      description: "As well as mandatory content listed above, additional information\
        \ that agencies may consider providing includes guidance for reporters/finders\
        \ to locate the agency\u2019s policy and how to confidentially communicate\
        \ technical details to the agency\u2019s security experts."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:3
      ref_id: 5.9.25.C.01
      name: 'Control -  All Classifications - Should [CID: 7136]'
      description: "An agency SHOULD publish a security.txt to permit secure communications\
        \ and direct any reports to a specific agency resource, in accordance with\
        \ the agency\u2019s VDP."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      description: ' Vulnerability disclosure policy (VDP) Setting Expectations'
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:4
      ref_id: 5.9.26.R.01
      description: "Agencies must set clear expectations for reporters/finders on\
        \ the timeframe within which agencies intend to address and remediate vulnerabilities\
        \ that have been reported to them.\_ The industry standard for a vulnerability\
        \ disclosure policy is 90 days."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:4
      ref_id: 5.9.26.C.01
      name: 'Control -  All Classifications - Must [CID: 7138]'
      description: An agency MUST commit to addressing disclosed vulnerabilities within
        the timeframe it sets in its policy.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:4
      ref_id: 5.9.26.C.02
      name: 'Control -  All Classifications - Should [CID: 7139]'
      description: "An agency\u2019s vulnerability disclosure timeframe SHOULD be\
        \ set to no more than 90 days."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:5.9:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5
      description: ' Vulnerability disclosure policy (VDP) Integration'
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:5
      ref_id: 5.9.27.R.01
      description: "It is essential that a VDP is integrated and consistent with an\
        \ agency\u2019s information security documentation and its policies, processes\
        \ and procedures for Incident Management, Product Security and Software Security\
        \ (Chapters 5, 7, 12, 14)."
    - urn: urn:defend:risk:req_node:nzism-v3:5.9.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:5.9:5:5
      ref_id: 5.9.27.C.01
      name: 'Control -  All Classifications - Must [CID: 7141]'
      description: Agencies MUST ensure they integrate their VDP with other elements
        of their information security policies.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:6
      assessable: false
      depth: 1
      ref_id: '6'
      name: Information security monitoring
    - urn: urn:defend:risk:req_node:nzism-v3:6.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:6
      ref_id: '6.1'
      name: Information Security Reviews
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:1
      ref_id: 6.1.1
      description: Information security reviews maintain the security of agency systems
        and detect gaps and deficiencies.
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:2:1
      ref_id: 6.1.2
      description: "This section covers information on conducting reviews of any agency\u2019\
        s information security posture and security implementation."
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:2
      description: Information security reviews
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:2:2
      ref_id: 6.1.3
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:2:2
      ref_id: 6.1.4
      description: "An information security review can be scoped to cover anything\
        \ from a single system to an entire agency\u2019s systems."
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:3
      ref_id: 6.1.5
      description: "Additional information relating to system auditing is contained\
        \ in:\n\n\nReference\nTitle\_\nPublisher\nSource\n\n\nISO/IEC 27006:2015\_\
        \n\nInformation technology \u2014 Security techniques \u2014 Requirements\
        \ for bodies providing audit and certification of information security management\
        \ systems\n\nISO\n\nhttps://www.iso.org/standard/62313.html\n\n\n\nISO/IEC\
        \ 27007:2020\_\n\nInformation security, cybersecurity and privacy protection\
        \ \u2014 Guidelines for information security management systems auditing\n\
        \nISO\n\nhttps://www.iso.org/standard/77802.html\n\n\n\nISO/IEC TS 27008:2019\_\
        \n\nInformation technology \u2014 Security techniques \u2014 Guidelines for\
        \ the assessment of information security controls\n\nISO\n\nhttps://www.iso.org/standard/67397.html\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:4
      ref_id: 6.1.6
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV3, INFOSEC1, INFOSEC2,\
        \ INFOSEC3 and INFOSEC4\n\n\nHome | Protective Security Requirements\nSecurity\
        \ governance (GOV) | Protective Security Requirements\nInformation security\
        \ (INFOSEC) | Protective Security Requirements/\_ \_\n\n\n\n\nPSR content\
        \ protocols\_\n\n\nManagement protocol for information security\n\n\nManagement\
        \ protocol for information security | Protective Security Requirements\n\n\
        \n\n\nPSR requirements sections\n\n\nSelf assessment & reporting\nProtective\
        \ security measures\n\n\nSelf-assessment and reporting | Protective Security\
        \ Requirements\nComplying with the Protective Security Requirements | Protective\
        \ Security Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5
      description: Conducting information security reviews
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:1
      ref_id: 6.1.7.R.01
      description: "Annual reviews of an agency\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:1
      ref_id: 6.1.7.C.01
      name: 'Control -  All Classifications - Should [CID: 1040]'
      description: Agencies SHOULD undertake and document information security reviews
        of their systems at least annually.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5
      description: Managing Conflicts of Interest
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:2
      ref_id: 6.1.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:2
      ref_id: 6.1.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1043]'
      description: Agencies SHOULD have information security reviews conducted by
        personnel independent to the target of the review or by an independent third
        party.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5
      description: 'Focus of information security reviews '
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:3
      ref_id: 6.1.9.R.01
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:3
      ref_id: 6.1.9.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.9.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:3
      ref_id: 6.1.9.R.03
      description: "Depending on the scope and subject of the information security\
        \ review, agencies may gather information on areas including:\nagency priorities,\
        \ business requirements and/or concept of operations;\nthreat data;\nrisk\
        \ likelihood and consequence estimates;\neffectiveness of existing counter-measures;\n\
        other possible counter-measures;\_\nchanges to standards, policies and guidelines;\n\
        recommended good practices; and\nsignificant system incidents and changes.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.1:5:3
      ref_id: 6.1.9.C.01
      name: 'Control -  All Classifications - Should [CID: 1048]'
      description: 'Agencies SHOULD review the components detailed in the table below.
        Agencies SHOULD also ensure that any adjustments and changes as a result of
        any vulnerability analysis are consistent with the vulnerability disclosure
        policy.



        Component

        Review



        Information security documentation

        The SecPol, Systems Architecture, SRMPs, SSPs, SitePlan, SOPs, the VDP, 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.



        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:6
      ref_id: '6.2'
      name: Vulnerability Analysis
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:1
      ref_id: 6.2.1
      description: "Exploitable information system weaknesses can be identified by\
        \ vulnerability analyses and inform assessments\_and controls selection."
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:2:1
      ref_id: 6.2.2
      description: This section covers information on conducting vulnerability assessments
        on systems as part of the suite of good IT governance activities.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:2
      description: Changes as a result of a vulnerability analysis
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:2:2
      ref_id: 6.2.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3
      description: Vulnerability analysis strategy
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      ref_id: 6.2.4.R.01
      description: Vulnerabilities may be unintentionally introduced and new vulnerabilities
        are constantly identified, presenting ongoing risks to information systems
        security.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      ref_id: 6.2.4.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.4.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      ref_id: 6.2.4.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.4.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      ref_id: 6.2.4.R.04
      description: "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\u2019s systems."
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:1
      ref_id: 6.2.4.C.01
      name: 'Control -  All Classifications - Should [CID: 1063]'
      description: "Agencies SHOULD implement a vulnerability analysis strategy by:\n\
        monitoring public domain information about new vulnerabilities in operating\
        \ systems and application software;\nconsidering the use of automated tools\
        \ to perform vulnerability assessments on systems in a controlled manner;\n\
        running manual checks against system configurations to ensure that only allowed\
        \ services are active and that disallowed services are prevented;\_\nusing\
        \ security checklists for operating systems and common applications; and\n\
        examining any significant incidents on the agency\u2019s systems.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3
      description: Conducting vulnerability assessments
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:2
      ref_id: 6.2.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:2
      ref_id: 6.2.5.C.01
      name: 'Control -  All Classifications - Should [CID: 1066]'
      description: "Agencies SHOULD conduct vulnerability assessments in order to\
        \ establish a baseline. This SHOULD be done:\nbefore a system is first used;\n\
        after any significant incident;\nafter a significant change to the system;\n\
        after changes to standards, policies and guidelines;\_\nwhen specified by\
        \ an ITSM or system owner.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3
      description: Resolving vulnerabilities
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:3
      ref_id: 6.2.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.2:3:3
      ref_id: 6.2.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1069]'
      description: Agencies SHOULD analyse and treat all vulnerabilities and subsequent
        security risks to their systems identified during a vulnerability assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:6
      ref_id: '6.3'
      name: Change Management
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:1
      ref_id: 6.3.1
      description: "To ensure information security is an integral part of the change\
        \ management process, it should be incorporated into the agency\u2019s IT\
        \ maintenance governance and management activities."
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2:1
      ref_id: 6.3.2
      description: This section covers information on identifying and managing routine
        and urgent changes to systems.
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2
      description: Identifying the need for change
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2:2
      ref_id: 6.3.3
      description: '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 notifications received or issued;
        and

        other incidents or continuous improvement activities.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2
      description: Types of system change
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:2:3
      ref_id: 6.3.4
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:3
      ref_id: 6.3.5
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV3, INFOSEC1, INFOSEC2,\
        \ INFOSEC3 and INFOSEC4\n\n\nHome | Protective Security Requirements\nSecurity\
        \ governance (GOV) | Protective Security Requirements\nInformation security\
        \ (INFOSEC) | Protective Security Requirements\n\n\n\n\nPSR content protocols\_\
        \n\n\nManagement protocol for information security\n\n\nManagement protocol\
        \ for information security | Protective Security Requirements\n\n\n\n\nPSR\
        \ requirements sections\n\n\nSelf assessment & reporting\nProtective security\
        \ measures\nMaintain your business continuity\_programme\n\n\nSelf-assessment\
        \ and reporting | Protective Security Requirements\nComplying with the Protective\
        \ Security Requirements | Protective Security Requirements\nManaging business\
        \ continuity | Protective Security Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4
      description: Change management
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:1
      ref_id: 6.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:1
      ref_id: 6.3.6.R.02
      description: "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\u2019s change management process strongly\
        \ enforces appropriate actions to be taken before and after an urgent change\
        \ is implemented."
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:1
      ref_id: 6.3.6.C.01
      name: 'Control -  Top Secret - Must [CID: 1088]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:1
      ref_id: 6.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1089]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4
      description: Change management process
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:2
      ref_id: 6.3.7.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:2
      ref_id: 6.3.7.C.01
      name: 'Control -  Top Secret - Must [CID: 1093]'
      description: "An agency\u2019s change management process MUST define appropriate\
        \ actions to be followed before and after urgent changes are implemented."
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:2
      ref_id: 6.3.7.C.02
      name: 'Control -  All Classifications - Should [CID: 1094]'
      description: "An agency\u2019s change management process SHOULD define appropriate\
        \ actions to be followed before and after urgent changes are implemented."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:2
      ref_id: 6.3.7.C.03
      name: 'Control -  All Classifications - Should [CID: 1095]'
      description: '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,
        SSP 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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4
      description: Changes impacting the security of a system
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:3
      ref_id: 6.3.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.3:4:3
      ref_id: 6.3.8.C.01
      name: 'Control -  All Classifications - Must [CID: 1098]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:6.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:6
      ref_id: '6.4'
      name: Business Continuity and Disaster Recovery
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:1
      ref_id: 6.4.1
      description: "To ensure business continuity and disaster recovery processes\
        \ are established to assist in meeting the agency\u2019s business requirements,\
        \ minimise any disruption to the availability of information and systems,\
        \ and assist recoverability."
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:2:1
      ref_id: 6.4.2
      description: "This section covers information on business continuity and disaster\
        \ recovery relating\_specifically to systems."
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:3
      ref_id: 6.4.3
      description: "Additional information relating to business continuity is contained\
        \ in:\n\n\nReference\nTitle\nPublisher\nSource\n\n\nISO 22301:2019\n\nSecurity\
        \ and resilience \u2014 Business continuity management systems \u2014 Requirements\n\
        \n\_ISO\n\nhttps://www.iso.org/standard/75106.html\n\n\n\nISO/IEC 27001:2013\n\
        Information Technology \u2013 Security Techniques - Information Security Management\
        \ Systems - Requirements\n\_ISO\n\nhttps://www.iso.org/standard/54534.html\n\
        \n\n\nISO/IEC 27002:2022\n\nInformation security, cybersecurity and privacy\
        \ protection \u2014 Information security controls\n\n\_ISO\n\nhttps://www.iso.org/standard/75652.html\n\
        \n\n\nISO/IEC 27005:2018\nInformation Technology \u2013 Security Techniques\
        \ - Information Security Risk Management\n\_ISO\n\nhttps://www.iso.org/standard/75281.html\n\
        \n\n\nISO/IEC 27031:2011\n\nInformation technology \u2014 Security techniques\
        \ \u2014 Guidelines for information and communication technology readiness\
        \ for business continuity\n\n\_ISO\n\nhttps://www.iso.org/standard/44374.html\n\
        \n\n\nSAA/SNZ HB 221:2004\nBusiness Continuity Management\n\_Standards NZ\n\
        \nhttps://standards.govt.nz/\_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:4
      ref_id: 6.4.4
      description: "Relevant PSR requirements can be found at:\n\_\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV3, GOV7, INFOSEC1 and\
        \ PHYSEC1\n\nHome | Protective Security Requirements\nSecurity governance\
        \ (GOV) | Protective Security Requirements\nInformation security (INFOSEC)\
        \ | Protective Security Requirements/\_\_\_\nPhysical security (PHYSEC) |\
        \ Protective Security Requirements\n\n\n\nPSR content protocols\_\n\nManagement\
        \ protocol for information security\nManagement protocol for physical security\n\
        \n\nManagement protocol for information security | Protective Security Requirements\n\
        Management protocol for physical security | Protective Security Requirements\n\
        \n\n\nPSR requirements sections\n\nBusiness continuity management\n\n\nManaging\
        \ business continuity | Protective Security Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5
      description: Availability requirements
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:1
      ref_id: 6.4.5.R.01
      description: "Availability and recovery requirements will vary based on each\
        \ agency\u2019s business needs and are likely to be widely variable across\
        \ government. Agencies will determine their own availability and recovery\
        \ requirements and implement measures consistent with the agency's SRMP to\
        \ achieve them as part of their risk management and governance processes."
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:1
      ref_id: 6.4.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1120]'
      description: "Agencies MUST determine availability and recovery requirements\
        \ for their systems and implement measures consistent\_with the agency's SRMP\
        \ to support them."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5
      description: Backup strategy
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:2
      ref_id: 6.4.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:2
      ref_id: 6.4.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1123]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5
      description: Business Continuity plan
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:3
      ref_id: 6.4.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:3
      ref_id: 6.4.7.C.01
      name: 'Control -  All Classifications - Should [CID: 1126]'
      description: Agencies SHOULD develop and document a business continuity plan.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:6.4:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5
      description: Disaster recovery plan
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:4
      ref_id: 6.4.8.R.01
      description: Developing and documenting a disaster recovery plan, will reduce
        the time between a disaster occurring, and critical functions of systems being
        restored.
    - urn: urn:defend:risk:req_node:nzism-v3:6.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:6.4:5:4
      ref_id: 6.4.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1129]'
      description: Agencies SHOULD develop and document a disaster recovery plan.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7
      assessable: false
      depth: 1
      ref_id: '7'
      name: Information Security Incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:7
      ref_id: '7.1'
      name: Detecting Information Security Incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:1
      ref_id: 7.1.1
      description: Organisations have implemented tools, processes and procedures
        to detect information security incidents, minimise their impact and have these
        activities embedded as part of IT governance.
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:2:1
      ref_id: 7.1.2
      description: "This section covers information relating to detecting information\
        \ security incidents.\_ Detecting physical and personnel security incidents\
        \ is out of scope of this section, unless there is an impact on information\
        \ systems. Refer to Chapter 8 - Physical Security\_and\_Chapter 9 - Personnel\
        \ Security.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:2:1
      ref_id: 7.1.3
      description: It is important to note that in most cases, information systems
        are likely to be affected.
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:2:1
      ref_id: 7.1.4
      description: "Additional information relating to detecting information security\
        \ incidents, and topics covered in this section, can be found in the following\
        \ sections of this manual:\nSection 5.9 - Vulnerability Disclosure Policy;\n\
        Section 6.1 - Information Security Reviews;\nSection 6.2 - Vulnerability Analysis;\n\
        Section 7.2 \u2013 Reporting Information Security Incidents;\nSection 7.3\
        \ \u2013 Managing Information Security Incidents;\nSection 9.1 - Information\
        \ Security Awareness and Training;\nSection 16.6 - Event Logging and Auditing;\n\
        Section 17.9 \u2013 Key Management; and\nSection 18.4 - Intrusion Detection\
        \ and Prevention.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:3
      ref_id: 7.1.5
      description: "Standards and guidance published by Standards Bodies and industry\
        \ groups include:\n\n\n\nReference\_\nTitle\nPublisher\nSource\n\n\nISO/IEC\
        \ 27035-1:2023\n\_Information technology \u2014 Security techniques \u2014\
        \ Information security incident management \u2014 Part 1: Principles and Process\n\
        ISO\nISO/IEC 27035-1:2023 - Information technology \u2014 Information security\
        \ incident management \u2014 Part 1: Principles and process\_\n\n\nISO/IEC\
        \ 27035-2:2023\nInformation technology \u2014 Security techniques \u2014 Information\
        \ security incident management \u2014 Part 2: Guidelines to plan and prepare\
        \ for incident response\nISO\nISO/IEC 27035-2:2023 - Information technology\
        \ \u2014 Information security incident management \u2014 Part 2: Guidelines\
        \ to plan and prepare for incident response\n\n\n\_\nDefinitions of Computer\
        \ Security Incident\nNIST\nhttps://csrc.nist.gov/glossary/term/Computer_Security_Incident\_\
        \_\n\n\nSP 800-61 rev.2\nComputer Security Incident Handling Guide\nNIST\n\
        https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf\
        \ [PDF, 1.5 MB]\n\n\n\_\nUS-CERT Federal Incident Notification Guidelines\n\
        CISA\nhttps://us-cert.cisa.gov/incident-notification-guidelines\_\n\n\n\_\n\
        NCSC Incident Management Be Resilient Be Prepared\nNCSC\n\_NCSC-Incident-Management-Be-Resilient-Be-Prepared.pdf\n\
        \n\n\_\nIncident Handler's Handbook\nSANS\nhttps://www.sans.org/reading-room/whitepapers/incident/incident-handlers-handbook-33901\_\
        \n\n\n\_\nITIL \u2013 A guide to incident management\nITIL\nhttps://www.bmc.com/blogs/itil-v3-incident-management/\n\
        \n\n\_\nIncident Management and Response\nISACA\nhttps://www.isaca.org/bookstore/bookstore-wht_papers-digital/whpimr\n\
        \n\n\_\nCyber Security Incident Response Guide\nCREST\nCSIR-Procurement-Guide-1.pdf\
        \ (crest-approved.org)\n\n\n\_\nGood Practice Guide for Incident Management\n\
        ENISA\nhttps://www.enisa.europa.eu/publications/good-practice-guide-for-incident-management\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:4
      ref_id: 7.1.6
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV6, GOV7,\_INFOSEC1\_\
        and\_INFOSEC4\nHome | Protective Security Requirements\nSecurity governance\
        \ (GOV) | Protective Security Requirements\nInformation security (INFOSEC)\
        \ | Protective Security Requirements\n\n\n\n\nPSR content protocols\_\n\n\n\
        Management protocol for information security\n\n\nManagement protocol for\
        \ information security | Protective Security Requirements\n\n\n\n\nPSR requirements\
        \ sections\n\n\nReporting incidents and conducting security investigations\n\
        \n\nReporting incidents and conducting security investigations | Protective\
        \ Security Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5
      description: Preventing and detecting information security incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.R.01
      description: Processes and procedures for the detection of information security
        incidents will assist in mitigating attacks using the most common vectors
        in systems exploits.
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.R.02
      description: New or advanced attacks and exploits can frequently be detected
        through other metrics and effects, rather than direct identification. For
        example, unexpected spike in network traffic or network latency, unapproved
        changes in file permissions, unexpected high utilisation of computing resources
        etc.
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.R.03
      description: 'Potential information security incidents are detected by both
        personnel and automated incident detection tools.


        Personnel should be well trained and aware of information security issues.

        Automated incident detection tools should be utilised to assist in developing
        use cases and a known baseline. Management and operation of the tools should
        be undertaken by experienced information security personnel.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.R.04
      description: "Agencies may consider some of the tools described in the table\
        \ below for detecting potential information security incidents.\n\_\n\n\n\n\
        Tool\nDescription\n\n\nNext-Generation Firewall (NGFW)\n\nNGFWs can provide\
        \ dynamic network defence by combining application/cloud service level control\
        \ and dynamic threat feeds with signature or other anomaly detection to help\
        \ prevent malicious connections to the network, or users connecting to malicious\
        \ or non-approved cloud services. NGFWs may be deployed as cloud services\
        \ (i.e. cloud firewall or firewall-as-a-service) or as a hardware or software\
        \ appliance.\n\n\n\nProtective DNS\nProtective DNS provides real-time secure\
        \ DNS resolver checks for domains and IP addresses against known malicious\
        \ entities.\n\n\nThreat Intelligence Platform (TIP)\nTIPs enable an automated\
        \ means to collect, analyse and manage threat data received from various intelligence\
        \ sources to enrich prevention and detection capabilities.\n\n\nNetwork and\
        \ host Intrusion Detection Systems (IDSs)\nMonitor 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.\n\n\nCloud\
        \ threat detection capabilities\nEnable, monitor and tune the threat detection\
        \ capabilities of respective cloud services to detect threats and create high-quality\
        \ alerts from log data or agents for cloud workloads and identity providers.\n\
        \n\nAnomaly detection systems\nBaselines normal host and network activity\
        \ and identifies events that deviate from expected patterns of activity .\n\
        \n\nEndpont Detection and Response (EDR) /Extended Detection and Response\
        \ (XDR\nEndpoint Detection and Response (EDR) provide host based threat detection\
        \ and response that provide real-time monitoring and analytics. Extended Detection\
        \ and Response expands on the functions of EDR to distinct security capabilities\
        \ within your organisation.\n\n\nLog analysis\nInvolves collecting and analysing\
        \ event logs using pattern recognition to detect anomalous activities.\n\n\
        \nApplication Allow listing\nLists the authorised activities and applications\
        \ and permits their usage.\n\n\nSecurity Information and Event Management\
        \ (SIEM)\nSIEM solutions provide centralised platform for log collection,\
        \ storage, alerting and detection of security threats.\n\n\nData Loss Prevention\
        \ (DLP)\nDLP solutions identify and prevent sharing or transfer of sensitive\
        \ information.\n\n\nsecurity.txt\nInternet standard RFC 9116 defines a way\
        \ for organisations to disclose their vulnerability disclosure practices.\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.R.05
      description: "Automated tools are only as good as their implementation and the\
        \ level of analysis they perform.\_ If tools are not configured to assess\
        \ all areas of potential security risk then some vulnerabilities or attacks\
        \ will not be detected. \_Maintenance of the tools is important to ensure\
        \ that emerging threats and vulnerabilities are able to be identified. Failure\
        \ to do so will reduce the effectiveness to identify vulnerabilities."
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 1153]'
      description: 'Agencies MUST develop, implement and maintain tools and procedures
        covering the detection of potential information security incidents, incorporating:

        user awareness and training;

        counter-measures against malicious code, known attack methods and types;

        intrusion detection strategies;

        data egress monitoring & control;

        access control anomalies;

        audit analysis;

        system integrity checking; and

        vulnerability assessments.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.C.02
      name: 'Control -  All Classifications - Should [CID: 1154]'
      description: 'Agencies SHOULD develop, implement and maintain tools and procedures
        covering the detection of potential information security incidents, incorporating:


        user awareness and training;

        counter-measures against malicious code, known attack methods and types;

        intrusion detection strategies;

        dynamic network defence (i.e. protective DNS and/or NGFW)

        data egress monitoring & control;

        access control anomalies;

        audit analysis;

        system integrity checking; and

        vulnerability assessments.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.1.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.1:5:1
      ref_id: 7.1.7.C.03
      name: 'Control -  All Classifications - Should [CID: 1155]'
      description: Agencies SHOULD use the results of the security risk assessment
        to determine the appropriate balance of resources allocated to prevention
        versus resources allocated to detection of information security incidents.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:7
      ref_id: '7.2'
      name: Reporting Information Security Incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:1
      ref_id: 7.2.1
      description: "Reporting of information security incidents is incorporated as\
        \ an essential part of incident management, whether the reporting is within\
        \ an agency or reports are provided to another government agency.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:1
      ref_id: 7.2.2
      description: Reporting helps to maintain an accurate threat environment picture
        for government systems, particularly when All-of-Government (AoG) or multi-agency
        systems are involved.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:1
      ref_id: 7.2.3
      description: "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 unless there is an impact on information\
        \ systems.For example, keypads and access cards are part of a wider information\
        \ technology system, where physical key locks are not."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:1
      ref_id: 7.2.4
      description: It is important to note that, in most cases, information systems
        are likely to be affected.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      description: Requirement for information security incident reporting
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:2
      ref_id: 7.2.5
      description: The requirement to report an information security incident report
        applies irrespective of whether incident management is internally managed
        or if an agency has outsourced some or all of its information technology functions
        and services.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:2
      ref_id: 7.2.6
      description: "The information security threat and intelligence landscape continues\
        \ to evolve, partly \_driven by more advanced, capable, well-resourced and\
        \ motivated adversaries, as well as the need to improve management and governance\
        \ of information systems.\_ To assist in managing these requirements, a standardised\
        \ form of information exchange is essential."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:2
      ref_id: 7.2.7
      description: "Agencies must have a comprehensive understanding of their assets,\
        \ both physical and intellectual. By establishing clear boundaries, they can\
        \ effectively manage their scope, ensuring informed decisions and efficient\
        \ incident response.\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:2
      ref_id: 7.2.8
      description: "Agencies need to consider that vendor contract(s) and agreement(s)\
        \ enable sharing of information relating to incidents with the NCSC.\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      description: Definition of a Security Incident
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:3
      ref_id: 7.2.9
      description: "A security incident is a violation, breach or infringement of\
        \ a security policy or an attempt to gain unauthorised access to official\
        \ resources. It is important to note that security incidents include physical\
        \ incidents (such as lost documents) as well as \u201Ccyber\u201D incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      description: Definition of a Cyber Security Incident
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:4
      ref_id: 7.2.10
      description: "A cyber security incident is any event that jeopardises or may\
        \ jeopardise the confidentiality, integrity, or availability of an information\
        \ system or the information a system processes, stores, or communicates.\_\
        \ This includes a violation or potential violation of security policies, security\
        \ procedures, acceptable use policies or any relevant regulation or legislation."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.11
      description: "The detection,\_triaging, recording, management and response to\
        \ an incident depends primarily on effective prevention and detection mechanisms\
        \ and a robust response plan.\_ Effective detection and response mechanisms\
        \ also provide an important record of events and assist in preventing repeat\
        \ events, improving defences and streamlining response measures."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.12
      description: "A key part of the detection and response is incident reporting,\
        \ including internal security system reports as well as any essential external\
        \ reporting.\_ It is essential that response is timely and methodical in order\
        \ to minimise the effects of the incident.\_ In all cases it is vital that\
        \ steps are taken to quickly contain the incident, minimise damage and implement\
        \ measures to prevent or contain any reoccurrence."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.13
      description: "Not\_every cybersecurity event is serious enough to warrant detailed\
        \ investigation and reporting, for example a single multi-factor authentication\
        \ challenge failure from an employee on premises.\_ Multiple multi-factor\
        \ challenge failures, however, may indicate a malicious access attempt.\_\
        \ Thresholds should be established which will trigger an incident response.\_\
        \ In all cases, once an incident has been determined, it should be recorded\
        \ to support analysis and reporting."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.14
      description: "It\_is also important to categorise incidents in order to better\
        \ manage allocation of resources to the containment and remediation of the\
        \ incident.\_ A three-tier categorisation is suggested:\n\nCritical: Incident\
        \ affecting critical systems or information with potential to impact operations,\
        \ revenue, customers or information disclosed in data breach.For example,\
        \ distributed denial of service attack, unauthorised access to system, multi-system\
        \ ransomware.\nSerious: Incident affecting noncritical systems or information,\
        \ impact on operations, revenue, customers or information disclosed in data\
        \ breach.For example, execution of malware on a single system, potentially\
        \ compromised credentials.\nLow: Possible incident affecting noncritical systems.\_\
        \ Incidents or employee investigations that are not time sensitive.\_ For\
        \ example, blocked phishing attempts.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.15
      description: Incidents where the scope or cause of activity has not yet been
        determined should be categorised as serious or critical and actioned accordingly.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:2:5
      ref_id: 7.2.16
      description: "Factors that assist in determining the severity of an incident\
        \ include:\n\nWhether the incident affects a single agency or multiple agencies;\n\
        Functional impact of the incident (availability);\nInformation impact of the\
        \ incident (confidentiality, integrity);\nRecoverability from the incident;\n\
        Whether a breach of personal information held by the agency has occurred;\n\
        Whether unauthorised access to agency information systems may have occurred;\n\
        Reputational risk to the agency;\nImpact on any MOUs, MOAs and similar formal\
        \ agreements;\nImpact on the disclosure of information theft of data.\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:3
      ref_id: 7.2.17
      description: "Additional information relating to information security incidents\
        \ can be found at:\n\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\nRFC 5070\n\
        \n\nThe Incident Object Description Exchange Format, December 2007\_\n\n\n\
        The Internet Engineering Taskforce (IETF)\n\nhttps://datatracker.ietf.org/doc/html/rfc5070\n\
        \n\n\nRFC 6685\n\n\nExpert Review for Incident Object Description Exchange\
        \ Format (IODEF) Extensions in IANA XML Registry, July 2012, ISSN: 2070-1721\n\
        \nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6685\n\n\n\_\n\nDetect, SHARE,\
        \ Protect Solutions for Improving Threat Data Exchange among CERTs, October\
        \ 2013\n\nENISA\nhttp://www.enisa.europa.eu/activities/cert/support/data-sharing/detect-share-protect-solutions-for-improving-threat-data-exchange-among-certs\n\
        \n\nSP 800-61 rev2\_\nComputer Security Incident Handling Guide,\_rev2, August\
        \ 2012\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final\n\
        \n\n\nSP\_800-60 Volume l Revision 1\n\n\nGuide for Mapping Types of Information\
        \ and Information Systems to Security Categories\n\n\nNIST\n\nhttps://csrc.nist.gov/publications/detail/sp/800-60/vol-1-rev-1/final\n\
        \n\n\nSP\_800-60 Volume ll Revision 1\n\n\nGuide for Mapping Types of Information\
        \ and Information Systems to Security Categories, Volume ll: Appendices\n\n\
        NIST\nhttps://csrc.nist.gov/publications/detail/sp/800-60/vol-2-rev-1/final\n\
        \n\n\_\n\nThe National Cyber Security Centre Voluntary Cyber Security Standards\
        \ for Industrial Control Systems v1.0\n\n\nGCSB NCSC\n\n\nhttps://www.gcsb.govt.nz/assets/GCSB-Documents/NCSC-voluntary-cyber-security-standards-for-ICD-v.1.0.pdf\n\
        \_\n\n\n\n\_\n\nThe New Zealand Security Incident Management Guide for Computer\
        \ Security Incident Response Teams (CIRSTs)\n\nNCSC\nhttps://www.ncsc.govt.nz/assets/NCSC-Documents/New-Zealand-Security-Incident-Management-Guide-for-Computer-Security-Incident-Response-Teams-CSIRTs.pdf\n\
        \n\n\_\n\nInformation Sharing Specifications for Cybersecurity\n\nDHS\nhttps://www.us-cert.gov/Information-Sharing-Specifications-Cybersecurity\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Reporting information security incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:1
      ref_id: 7.2.18.R.01
      description: "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 or\
        \ CISO may seek advice from NCSC as required.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:1
      ref_id: 7.2.18.C.01
      name: 'Control -  All Classifications - Must [CID: 1203]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:1
      ref_id: 7.2.18.C.02
      name: 'Control -  All Classifications - Should [CID: 1205]'
      description: '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 system, software or other 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 training and, where warranted, a formal disciplinary
        process.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Responsibilities when reporting an information security incident
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:2
      ref_id: 7.2.19.R.01
      description: "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.\nThe CISO is required to keep the CSO\
        \ and/or Agency Head informed of information security incidents within their\
        \ agency.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.19.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:2
      ref_id: 7.2.19.R.02
      description: "Reporting on Critical and Serious incidents requires immediate\
        \ action.\nReporting on incidents categorised as Low can usually be adequately\
        \ managed through periodic (weekly or monthly) reports.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:2
      ref_id: 7.2.19.C.01
      name: 'Control -  All Classifications - Must [CID: 1211]'
      description: The ITSM MUST keep the CISO fully informed of information security
        incidents within an agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Reporting information security incidents to National Cyber Security
        Centre (NCSC)
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.R.01
      description: The NCSC uses significant information security incident reports
        as the basis for identifying and responding to information security events
        across government, and New Zealand. Reports are also used to develop new policy,
        procedures, techniques and training measures to prevent the recurrence of
        similar information security incidents across government.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.R.02
      description: "Reporting on Critical and Serious incidents requires immediate\
        \ action.\nReporting of Critical or Serious 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 view across government\
        \ systems."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.R.03
      description: "Reporting\_on incidents categorised as Low can be scheduled to\
        \ a suitable timeframe e.g. weekly.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.C.01
      name: 'Control -  All Classifications - Must [CID: 1216]'
      description: "The Agency ITSM, MUST report information security incidents categorised\
        \ as:\n\nCritical;\nSerious; or\nincidents related to multi-agency or government\
        \ systems;\n\nto the NCSC as soon as possible.\nA Report Form is provided\
        \ on the NCSC website under Reporting an Incident at Report an incident and\
        \ request support | National Cyber Security Centre\n\_"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.C.02
      name: 'Control -  All Classifications - Should [CID: 1220]'
      description: 'Agencies SHOULD report information security incidents categorised
        as Low to the NCSC.

        A Report Form is provided on the NCSC website under Reporting an Incident
        at Report an incident and request support | National Cyber Security Centre'
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:3
      ref_id: 7.2.20.C.03
      name: 'Control -  All Classifications - Should [CID: 7536]'
      description: Agencies SHOULD formally share post-incident review reports by
        emailing them to incidents@ncsc.govt.nz.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Outsourcing and information security incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:4
      ref_id: 7.2.21.R.01
      description: "In the case of outsourcing of information technology services\
        \ and functions, the agency remains responsible for the reporting of all information\
        \ security incidents.\_ This includes any outsourced cloud services used by\
        \ the agency.\_ As such, the agency MUST ensure that the service provider\
        \ informs them of all information security incidents to enable them to assess\
        \ the incident and provide formal reporting."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:4
      ref_id: 7.2.21.C.01
      name: 'Control -  All Classifications - Must [CID: 1226]'
      description: Agencies that outsource their information technology services and
        functions MUST ensure that the service provider advises and consults with
        the agency when an information security incident occurs.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Cryptographic keying material
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:5
      ref_id: 7.2.22.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.22.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:5
      ref_id: 7.2.22.R.02
      description: It is important to note that a loss or compromise of keying material
        is a Critical or Serious information security incident and strict procedures
        must be followed to minimise the impact of the incident.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:5
      ref_id: 7.2.22.C.01
      name: 'Control -  All Classifications - Must [CID: 1233]'
      description: Agencies MUST notify all system users of any suspected or confirmed
        loss or compromise of keying material.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: Replacement of Cryptographic Key (HACE) keying material
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:6
      ref_id: 7.2.23.R.01
      description: "If an encryption key is compromised, there is no need to attack\
        \ the algorithm itself and it is a trivial matter to decrypt any encrypted\
        \ data.\_ This is why strong key management is vital in order to protect the\
        \ encryption keying materials.\_ If a compromise of keying materials is known\
        \ or even suspected, the cryptographic key must be replaced as a matter of\
        \ urgency and measures taken to reduce the impact of the key compromise.\_\
        \ See also Section 17.9 \u2013 Key Management."
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:6
      ref_id: 7.2.23.C.01
      name: 'Control -  All Classifications - Must [CID: 6592]'
      description: Agencies MUST replace compromised cryptographic keys as a matter
        of urgency and record the replacement in the incident reporting.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.2:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4
      description: High Assurance Cryptographic Equipment (HACE) keying material
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:7
      ref_id: 7.2.24.R.01
      description: For information security incidents involving the suspected loss
        or compromise of HACE keying material, GCSB will investigate the possibility
        of compromise, and where possible, initiate action to reduce the impact of
        the compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:7.2.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.2:4:7
      ref_id: 7.2.24.C.01
      name: 'Control -  All Classifications - Must [CID: 1237]'
      description: Agencies MUST urgently notify GCSB of any suspected loss or compromise
        of keying material associated with HACE.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:7
      ref_id: '7.3'
      name: Managing Information Security Incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:1
      ref_id: 7.3.1
      description: Organisations have processes implemented for incident identification,
        management and analysis of information security incidents, including selection
        of appropriate remedies which will assist in preventing or reducing the impact
        of future information security incidents.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:2:1
      ref_id: 7.3.2
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:2:1
      ref_id: 7.3.3
      description: It is important to note that, in most cases, information systems
        are likely to be affected.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:3
      ref_id: 7.3.4
      description: "Additional information relating to the management of ICT evidence\
        \ is contained in:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\nISO/IEC\
        \ 27037:2012\n\n\nInformation Technology \u2013 Security Techniques \u2013\
        \ Guidelines for identification, collection, acquisition and preservation\
        \ of digital evidence.\n\n\nISO\n\n\nhttps://www.iso.org/standard/44381.html\n\
        \n\n\n\nHB 171:2003\n\n\nGuidelines for the Management of Information Technology\
        \ Evidence\n\nStandards Australia\_\nhttps://www.saiglobal.com/PDFTemp/Previews/OSH/as/misc/handbook/HB171.PDF\
        \ [PDF, 350 KB]\n\n\n\_\n\n\_Incident Response\_\n\nNCSC\_\nIncidents | National\
        \ Cyber Security Centre (ncsc.govt.nz)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Information security incident management documentation
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:1
      ref_id: 7.3.5.R.01
      description: Ensuring responsibilities and procedures for information security
        incidents are documented in relevant Information Security Documentation will
        ensure that when an 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.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:1
      ref_id: 7.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1260]'
      description: Agencies MUST detail information security incident responsibilities
        and procedures for each system in the relevant Information Security Documents.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:1
      ref_id: 7.3.5.R.02
      description: Alternative communications efforts should be established to avoid
        using potentially compromised infrastructure to communicate during an incident.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Recording information security incidents
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:2
      ref_id: 7.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:2
      ref_id: 7.3.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1264]'
      description: Agencies SHOULD ensure that all information security incidents
        are recorded in a register.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:2
      ref_id: 7.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1266]'
      description: Agencies SHOULD use their incidents register as a reference for
        future security risk assessments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Handling data spills or data breach
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.R.01
      description: 'A data spill or data breach is defined as the unauthorised or
        unintentional release, transmission or transfer of data. If there is a possibility
        that sensitive or classified information may be compromised as a result of
        an information security incident, agencies need to be able to respond in a
        timely fashion to limit damage and contain the incident.

        For example, Data Loss Prevention (DLP) techniques and tools such as network
        activity monitoring, endpoint DLP tools, data classification can aid in detecting
        and preventing data spills or data breaches.'
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.01
      name: 'Control -  All Classifications - Must [CID: 1271]'
      description: Agencies MUST implement procedures and processes to detect data
        spills or data breach.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.02
      name: 'Control -  All Classifications - Must [CID: 1273]'
      description: When a data spill occurs agencies MUST assume that data at the
        highest classification held on or processed by the system, has been compromised.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.03
      name: 'Control -  All Classifications - Must [CID: 1274]'
      description: "Agency SOPs MUST include procedure for:\n\nall personnel with\
        \ access to systems;\_\nnotification to the ITSM of any data spillage\_or\
        \ breaches;\_and\nnotification to the ITSM of access to any data which they\
        \ are not authorised to access.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.04
      name: 'Control -  All Classifications - Must [CID: 1275]'
      description: "Agencies MUST document procedures for dealing with data spills\_\
        or data breaches in their IRP."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.05
      name: 'Control -  All Classifications - Must [CID: 1276]'
      description: "Agencies MUST treat any data spill\_or data breach as an information\
        \ security incident and follow the IRP to deal with it."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.7.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:3
      ref_id: 7.3.7.C.06
      name: 'Control -  All Classifications - Must [CID: 1277]'
      description: When a data spill or data breach occurs agencies MUST report the
        details to the Privacy Commissioner and information owner in accordance with
        the Privacy Act 2020.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Containing data spills
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.R.01
      description: "The spillage of classified information onto a system not accredited\
        \ to handle the information is considered a serious information security incident.\_\
        \ It may be a critical information security incident if personal information\
        \ or particularly sensitive information is spilled.\_ Refer to Section 7.2\
        \ \u2013 Reporting Information Security Incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.R.04
      description: It is important to note that powering off a system can destroy
        information that may be useful in forensics analysis or other investigative
        work. In large, inter-connected systems, powering off a system may not be
        feasible.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.C.01
      name: 'Control -  All Classifications - Must [CID: 1283]'
      description: 'When classified information is introduced onto a system not accredited
        to handle the information, the following actions MUST be followed:

        Immediately seek the advice of an ITSM;

        Segregate or isolate the affected system and/or data spill;

        Personnel MUST NOT delete the higher classified information unless specifically
        authorised by an ITSM.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.C.02
      name: 'Control -  All Classifications - Must Not [CID: 1284]'
      description: When classified information is introduced onto a system not accredited
        to handle the information, personnel MUST NOT copy, view, print or email the
        information.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:4
      ref_id: 7.3.8.C.03
      name: 'Control -  All Classifications - Should [CID: 1285]'
      description: "When a data spill or data breach involving classified or sensitive\
        \ information or contamination of classified systems occurs and systems cannot\
        \ be segregated, or isolated agencies SHOULD immediately contact the\_NCSC\
        \ for further advice."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Handling malicious code infection
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:5
      ref_id: 7.3.9.R.01
      description: 'Malicious code or malware is defined as software that attempts
        to compromise the confidentiality, integrity or availability of a system.
        This guidance for handling malicious code infections assists organisations
        have the procedures and processes in place to manage potential infections,
        further spread and similar future infections. Important details include:


        the infection date/time of the machine;

        any observed effects and source details;

        the possibility that system records and logs could be compromised; and

        the period of infection.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:5
      ref_id: 7.3.9.R.02
      description: "Positive detection of malicious code will require the below steps\
        \ to occur:\n\nIsolation of infected systems to prevent further spread. Check\
        \ connected systems and media for infections and isolate as required;\nRemoval\
        \ of the malicious code should be performed with appropriate malware removal\
        \ tools;\_\nEradication and recovery in some cases would require restoring\
        \ systems with original media. \n"
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.9.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:5
      ref_id: 7.3.9.R.03
      description: Agencies should be aware that some malicious code infections such
        as rootkits, employ persistence mechanisms. This will require specialist assistance
        or advice to detect and eradicate .
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:5
      ref_id: 7.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 1290]'
      description: "Agencies SHOULD follow the steps described below when malicious\
        \ code is detected:\n\n\_ \_ \_ isolate the infected system;\ndecide whether\
        \ to request assistance from NCSC;\nif such assistance is requested and agreed\
        \ to, delay any further action until advised by NCSC;\ncheck connected systems\
        \ and media including backups for malicious code;\_\nisolate all infected\
        \ systems and media to prevent reinfection;\nchange all passwords and key\
        \ material stored or potentially accessed from compromised systems, including\
        \ any websites with password controlled access;\nadvise system users of any\
        \ relevant aspects of the compromise, including a recommendation to change\
        \ all passwords on compromised systems;\nrevoke all session tokens associated\
        \ with user and/or device;\nuse up-to-date anti-malware software to remove\
        \ the malware from the systems or media;\nmonitor network traffic for malicious\
        \ activity;\nrecord and report the information security incident and perform\
        \ any other activities specified in the IRP; and\nin certain scenarios rebuilding\
        \ and reinitialising the system and/or user profile may be required.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Allowing continued attacks
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:6
      ref_id: 7.3.10.R.01
      description: 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 business owner(s) and legal advisor(s) whether the actions are breaching
        any business service level agreements or contractual obligations.
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:6
      ref_id: 7.3.10.C.01
      name: 'Control -  All Classifications - Must [CID: 1294]'
      description: "Agencies considering allowing an attacker to continue some actions\
        \ under controlled conditions for the purpose of seeking further information\
        \ or evidence MUST\_seek legal advice."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Integrity of evidence
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:7
      ref_id: 7.3.11.R.01
      description: "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.\_This may also include\
        \ a record of activities taken by the agency to contain the incident."
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:7
      ref_id: 7.3.11.C.01
      name: 'Control -  All Classifications - Should [CID: 1297]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:7.3:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4
      description: Seeking assistance
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:8
      ref_id: 7.3.12.R.01
      description: "After detecting an information security incident, organisations\
        \ need to preserve the evidence prior to taking any remediation steps. For\
        \ example, snapshots including memory of virtual machines. This greatly increases\
        \ NCSC\u2019s ability to provide assistance."
    - urn: urn:defend:risk:req_node:nzism-v3:7.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:7.3:4:8
      ref_id: 7.3.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1300]'
      description: "Agencies SHOULD ensure that any requests for NCSC 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 NCSC\u2019s involvement."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8
      assessable: false
      depth: 1
      ref_id: '8'
      name: Physical Security
    - urn: urn:defend:risk:req_node:nzism-v3:8.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:8
      ref_id: '8.1'
      name: Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:1
      ref_id: 8.1.1
      description: "Physical security measures are applied to facilities in order\
        \ to protect systems\_and their infrastructure."
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:1
      ref_id: 8.1.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      description: Physical security requirements for storing classified information
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:2
      ref_id: 8.1.3
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      description: Secure and unsecure areas
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:3
      ref_id: 8.1.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      description: Physical security certification authorities
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:4
      ref_id: 8.1.5
      description: "The certification of an agency\u2019s physical security measures\
        \ is an essential part of the certification and accreditation process. The\
        \ authority and responsibility are listed in the table below:\n\n\nClassification\n\
        Authority\nResponsibility\n\n\nSECRET\nCSO\nPhysical\n\n\nTOP SECRET\nNZSIS\n\
        Physical\n\n\nTOP SECRET SCIF\nGCSB\n\nNetwork Infrastructure\nTechnical Security\n\
        Surveillance Counter Measures\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:4
      ref_id: 8.1.6
      description: Top Secret (TS) physical certification should be completed before
        any Technical inspections and certifications occur.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2
      description: Facilities located outside of New Zealand
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:2:5
      ref_id: 8.1.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:3
      ref_id: 8.1.8
      description: "High-level information relating to physical security is also contained\
        \ in:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\nISO/IEC 27002:2022\n\
        \_\n\n\_Information security, cybersecurity and privacy protection \u2014\
        \ Information security controls\n\nISO\n\_\n\n\nhttps://www.iso.org/standard/75652.html\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:4
      ref_id: 8.1.9
      description: "Relevant PSR requirements can be found at:\n\n\n\n\nReference\n\
        \n\nTitle\n\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV2, GOV6, GOV7,\
        \ INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1, PHYSEC2, PHYSEC3 and PHYSEC4\n\
        \n\nHome | Protective Security Requirements\nSecurity governance (GOV) | Protective\
        \ Security Requirements\nInformation security (INFOSEC) | Protective Security\
        \ Requirements\nPhysical security (PHYSEC) | Protective Security Requirements\n\
        \n\n\n\nPSR content protocols\_\n\n\nManagement protocol for information security\n\
        Management protocol for physical security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\n\nPSR requirements sections\n\
        \n\nCreating a security culture\nUnderstand the physical security lifecycle\n\
        \n\nCreating a security culture | Protective Security Requirements\nUnderstanding\
        \ the physical security lifecycle | Protective Security Requirements\n\n\n\
        \n\nManaging specific scenarios\n\n\n\_\nManaging specific scenarios | Protective\
        \ Security Requirements\n\_\n\n\nMobile and remote working\n\_\nPhysical Security\
        \ for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5
      description: Facility physical security
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:1
      ref_id: 8.1.10.R.01
      description: '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

        staffing levels.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:1
      ref_id: 8.1.10.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:1
      ref_id: 8.1.10.C.01
      name: 'Control -  All Classifications - Must [CID: 1323]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5
      description: Preventing observation by unauthorised people
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:2
      ref_id: 8.1.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:2
      ref_id: 8.1.11.C.01
      name: 'Control -  All Classifications - Should [CID: 1326]'
      description: Agencies SHOULD prevent unauthorised people from observing systems,
        in particular desks, screens and keyboards.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:2
      ref_id: 8.1.11.C.02
      name: 'Control -  All Classifications - Should [CID: 1327]'
      description: "Agencies SHOULD position desks, screens and keyboards away from\
        \ windows and doorways so that they cannot be overseen by unauthorised persons.\_\
        \ If required, blinds or drapes SHOULD be fixed to the inside of windows,\
        \ and doors kept closed to avoid oversight."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5
      description: Bringing non-agency owned devices into secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:3
      ref_id: 8.1.12.R.01
      description: No non-agency owned devices are to be brought into TOP SECRET areas
        without their prior approval of the Accreditation Authority.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:3
      ref_id: 8.1.12.C.01
      name: 'Control -  Top Secret - Must Not [CID: 1330]'
      description: Agencies MUST NOT permit non-agency owned devices to be brought
        into TOP SECRET areas without prior approval from the Accreditation Authority.
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:8.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5
      description: Technical Inspection and surveillance counter-measure testing
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:4
      ref_id: 8.1.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:4
      ref_id: 8.1.13.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 1333]'
      description: Agencies MUST ensure that technical surveillance counter-measure
        tests are conducted as a part of the physical security certification.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.1.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.1:5:4
      ref_id: 8.1.13.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 1334]'
      description: Agencies MUST determine if further technical surveillance counter-measure
        testing is required, particularly if visitors or contractors have entered
        secure areas.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:8
      ref_id: '8.2'
      name: Servers And Network Devices
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:1
      ref_id: 8.2.1
      description: "Secured server and communications\_rooms provide appropriate physical\
        \ security for servers and network devices."
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:2:1
      ref_id: 8.2.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:2
      description: Secured server and communications rooms
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:2:2
      ref_id: 8.2.3
      description: "In order to reduce 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. See PSR - Physical Security,\_\
        Protective Security Requirements - Physical security planning; Protective\
        \ Security Requirements \u2013 Physical Security for ICT Systems;\_Storage\
        \ requirements for electronic information in ICT facilities [PDF 73 KB]"
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:2:2
      ref_id: 8.2.4
      description: "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.\_ See PSR - Physical Security,\_Protective\
        \ Security Requirements - Physical security planning; Protective Security\
        \ Requirements \u2013 Physical Security for ICT Systems;\_Storage requirements\
        \ for electronic information in ICT facilities [PDF, 73 KB]"
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3
      description: Securing servers and network devices
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:1
      ref_id: 8.2.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:1
      ref_id: 8.2.5.R.02
      description: The establishment of a secure communications room to house IT infrastructure,
        network devices, and other related equipment will provide a further physical
        security layer.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:1
      ref_id: 8.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1349]'
      description: "Agencies MUST ensure that servers and network devices are secured\
        \ within cabinets as outlined in PSR Management protocol for physical security,\
        \ with supporting document \u2013 Storage requirements for electronic information\
        \ in ICT facilities."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3
      description: Securing server rooms, communications rooms and security containers
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:2
      ref_id: 8.2.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:2
      ref_id: 8.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 1353]'
      description: Agencies MUST ensure that keys or equivalent access mechanisms
        to server rooms, communications rooms and security containers are appropriately
        controlled.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:2
      ref_id: 8.2.6.C.02
      name: 'Control -  All Classifications - Must Not [CID: 1354]'
      description: Agencies MUST NOT leave server rooms, communications rooms or security
        containers in an unsecured state unless the server room is occupied by authorised
        personnel.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3
      description: Administrative measures - Site security plans
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:3
      ref_id: 8.2.7.R.01
      description: Site security plans (SitePlan), the physical security equivalent
        of the SSP 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:3
      ref_id: 8.2.7.C.01
      name: 'Control -  All Classifications - Must [CID: 1357]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.2:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3
      description: No-lone-zones
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:4
      ref_id: 8.2.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.2:3:4
      ref_id: 8.2.8.C.01
      name: 'Control -  All Classifications - Must [CID: 1360]'
      description: Agencies operating no-lone-zones MUST suitably signpost the area
        and have all entry and exit points appropriately secured.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:8
      ref_id: '8.3'
      name: Network Infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:1
      ref_id: 8.3.1
      description: Network infrastructure is protected by secure facilities and the
        use of encryption technologies.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:2:1
      ref_id: 8.3.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3
      description: Network infrastructure in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.R.01
      description: "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 \u2013\
        \_Storage requirements for electronic information in ICT facilities."
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.R.04
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.C.01
      name: 'Control -  All Classifications - Must [CID: 1373]'
      description: Agencies MUST certify the physical security of facilities containing
        network infrastructure to the highest classification of information being
        communicated over the network infrastructure.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:1
      ref_id: 8.3.3.C.02
      name: 'Control -  All Classifications - Should [CID: 1374]'
      description: "Agencies communicating classified information over infrastructure\
        \ in secure areas SHOULD encrypt their information with at least an Approved\
        \ Cryptographic Protocol. See Section 17.3 \u2013 Approved Cryptographic Protocols."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3
      description: Protecting network infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:2
      ref_id: 8.3.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:2
      ref_id: 8.3.4.C.01
      name: 'Control -  Top Secret - Must [CID: 1377]'
      description: Agencies MUST locate patch panels, fibre distribution panels and
        structured wiring enclosures within at least lockable commercial cabinets.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:2
      ref_id: 8.3.4.C.02
      name: 'Control -  All Classifications - Should [CID: 1378]'
      description: Agencies SHOULD locate patch panels, fibre distribution panels
        and structured wiring enclosures within at least lockable commercial cabinets.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3
      description: Network infrastructure in unsecure areas
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:3
      ref_id: 8.3.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:3
      ref_id: 8.3.5.R.02
      description: Encryption does not change the class level of the information itself
        but allows reduced handling requirements to be applied.
    - urn: urn:defend:risk:req_node:nzism-v3:8.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.3:3:3
      ref_id: 8.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1382]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:8
      ref_id: '8.4'
      name: IT Equipment
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:1
      ref_id: 8.4.1
      description: IT equipment is secured outside of normal working hours, is non-operational
        or when work areas are unoccupied.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:1
      ref_id: 8.4.2
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:1
      ref_id: 8.4.3
      description: "Additional information relating to IT equipment and media can\
        \ be found in the following chapters and sections of this manual:\nSection\
        \ 11.2 - Fax Machines, Multifunction Devices and Network Printers;\nChapter\
        \ 12 - Product Security; and\nChapter 13 \u2013 Decommissioning and Disposal.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2
      description: Handling IT equipment containing media
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:2
      ref_id: 8.4.4
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:2
      ref_id: 8.4.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:2
      ref_id: 8.4.6
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2
      description: IT equipment using hybrid hard drives or solid state drives
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:2:3
      ref_id: 8.4.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Accounting for IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:1
      ref_id: 8.4.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:1
      ref_id: 8.4.8.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:1
      ref_id: 8.4.8.C.01
      name: 'Control -  All Classifications - Must [CID: 1400]'
      description: Agencies MUST account for all IT equipment containing media.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Processing requirements
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:2
      ref_id: 8.4.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:2
      ref_id: 8.4.9.C.01
      name: 'Control -  All Classifications - Must [CID: 1407]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Storage requirements
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:3
      ref_id: 8.4.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:3
      ref_id: 8.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 1403]'
      description: "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\_\
        with supporting document \u2013 Storage requirements for electronic information\
        \ in ICT facilities."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Securing non-volatile media for storage
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:4
      ref_id: 8.4.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:4
      ref_id: 8.4.11.C.01
      name: 'Control -  All Classifications - Should [CID: 1409]'
      description: "Agencies choosing to prevent the storage of classified information\
        \ on non-volatile media and enforcing scrubbing of temporary data at logoff\
        \ or shutdown SHOULD:\nassess the security risks associated with such a decision;\
        \ and\nspecify the processes and conditions for their application within the\
        \ system\u2019s SSP.\n\_"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Securing volatile media for storage
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:5
      ref_id: 8.4.12.R.01
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:5
      ref_id: 8.4.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1412]'
      description: "Agencies securing volatile media for IT equipment during non-operational\
        \ hours SHOULD:\ndisconnect power from the equipment the media resides within;\n\
        assess the security risks if not sanitising the media; and\nspecify any additional\
        \ processes and controls that will be applied within the system\u2019s SSP.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.4:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3
      description: Encrypting media within IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:6
      ref_id: 8.4.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.4:3:6
      ref_id: 8.4.13.C.01
      name: 'Control -  All Classifications - Should [CID: 1415]'
      description: Agencies SHOULD encrypt media within IT equipment with an Approved
        Cryptographic Algorithm. See Section 17.2 - Approved Cryptographic Algorithms.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:8
      ref_id: '8.5'
      name: Tamper Evident Seals
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:1
      ref_id: 8.5.1
      description: Tamper evident seals and associated auditing processes identify
        attempts to bypass the physical security of systems and their infrastructure.
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:2:1
      ref_id: 8.5.2
      description: This section covers information on tamper evident seals that can
        be applied to assets.
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3
      description: Recording seal usage
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      ref_id: 8.5.3.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      ref_id: 8.5.3.C.01
      name: 'Control -  Top Secret - Must [CID: 1425]'
      description: Agencies MUST record the usage of seals in a register that is appropriately
        secured.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      ref_id: 8.5.3.C.02
      name: 'Control -  Top Secret - Must [CID: 1426]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.3.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      ref_id: 8.5.3.C.03
      name: 'Control -  All Classifications - Should [CID: 1427]'
      description: Agencies SHOULD record the usage of seals in a register that is
        appropriately secured.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.3.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:1
      ref_id: 8.5.3.C.04
      name: 'Control -  All Classifications - Should [CID: 1428]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3
      description: Purchasing seals
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:2
      ref_id: 8.5.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:2
      ref_id: 8.5.4.C.01
      name: 'Control -  All Classifications - Should [CID: 1431]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:2
      ref_id: 8.5.4.C.02
      name: 'Control -  All Classifications - Should [CID: 1432]'
      description: Seals and any seal application tools SHOULD be secured when not
        in use.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.4.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:2
      ref_id: 8.5.4.C.03
      name: 'Control -  All Classifications - Should Not [CID: 1433]'
      description: Agencies SHOULD NOT allow contractors to independently purchase
        seals and associated tools on behalf of the government.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:8.5:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3
      description: Reviewing seal usage
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:3
      ref_id: 8.5.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:8.5.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:8.5:3:3
      ref_id: 8.5.5.C.01
      name: 'Control -  All Classifications - Should [CID: 1436]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9
      assessable: false
      depth: 1
      ref_id: '9'
      name: Personnel Security
    - urn: urn:defend:risk:req_node:nzism-v3:9.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:9
      ref_id: '9.1'
      name: Information Security Awareness and Training
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:1
      ref_id: 9.1.1
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:2:1
      ref_id: 9.1.2
      description: This section covers information relating specifically to information
        security awareness and training.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:3
      ref_id: 9.1.3
      description: "Relevant PSR requirements can be found at:\n\n\n\n\nReference\n\
        \nSource\n\n\n\nPSR Mandatory Requirements\n\nHome | Protective Security RequirementsThe\
        \ policy | Protective Security Requirements\nInformation security (INFOSEC)\
        \ | Protective Security Requirements \_\nPersonnel security (PERSEC) | Protective\
        \ Security Requirements\n\n\n\nPSR content protocols\_\n\n\nManagement protocol\
        \ for information security | Protective Security Requirements\nManagement\
        \ protocol for personnel security | Protective Security Requirements\n\n\n\
        \nPSR requirements sections\n\n\nCreating a security culture | Protective\
        \ Security Requirements\nBuilding security awareness | Protective Security\
        \ Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      description: Information security awareness and training responsibility
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:1
      ref_id: 9.1.4.R.01
      description: Agency management is responsible for ensuring that an appropriate
        information security awareness and a training program is provided for all
        personnel. Without management support, security personnel might not have sufficient
        resources to facilitate awareness and training for other personnel.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:1
      ref_id: 9.1.4.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.4.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:1
      ref_id: 9.1.4.R.03
      description: Methods that can be used to continually promote awareness include
        logon banners, system access forms and departmental bulletins and memoranda.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:1
      ref_id: 9.1.4.C.01
      name: 'Control -  All Classifications - Must [CID: 1449]'
      description: Agency management MUST ensure that all personnel who have access
        to a system have sufficient training and ongoing information security awareness.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      description: Information security awareness and training
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:2
      ref_id: 9.1.5.R.01
      description: "Information security awareness and training programs are designed\
        \ to help system users:\nbecome familiar with their roles and responsibilities;\n\
        understand any legislative or regulatory mandates and requirements;\nunderstand\
        \ any national or agency policy mandates and requirements;\nunderstand and\
        \ support security requirements;\_\nassist in maintaining security; and\n\
        learn how to fulfil their security responsibilities.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:2
      ref_id: 9.1.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1452]'
      description: Agencies MUST provide ongoing information security awareness and
        a training programme 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.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:2
      ref_id: 9.1.5.C.02
      name: 'Control -  All Classifications - Must [CID: 1453]'
      description: Agencies MUST provide information security awareness training as
        part of their employee induction programmes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      description: Degree and content of information security awareness and training
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      ref_id: 9.1.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      ref_id: 9.1.6.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      ref_id: 9.1.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1457]'
      description: Agencies SHOULD align the detail, content and coverage of information
        security awareness and training programmes to system user responsibilities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      ref_id: 9.1.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1458]'
      description: "Agencies SHOULD ensure that information security awareness and\
        \ training includes information on:\nthe purpose of the training or awareness\
        \ program;\nany legislative or regulatory mandates and requirements;\nany\
        \ national or agency policy mandates and requirements;\nagency security appointments\
        \ and contacts;\nthe legitimate use of system accounts, software and classified\
        \ information;\nthe security of accounts, including shared passwords;\nauthorisation\
        \ requirements for applications, databases and data;\nthe security risks associated\
        \ with non-agency systems, particularly the Internet;\nreporting any suspected\
        \ compromises or anomalies;\nreporting requirements for information security\
        \ incidents, suspected compromises or anomalies;\nclassifying, marking, controlling,\
        \ storing and sanitising media;\nprotecting workstations from unauthorised\
        \ access;\ninforming the support section when access to a system is no longer\
        \ needed;\_\nobserving rules and regulations governing the secure operation\
        \ and authorised use of systems; and\nsupporting documentation such as SOPs\
        \ and user guides.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:3
      ref_id: 9.1.6.C.03
      name: 'Control -  All Classifications - Should [CID: 1459]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      description: System familiarisation training
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:4
      ref_id: 9.1.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:4
      ref_id: 9.1.7.C.01
      name: 'Control -  Top Secret - Must [CID: 1462]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4
      description: Disclosure of information while on courses
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:5
      ref_id: 9.1.8.R.01
      description: "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\u2019s 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\u2019s systems."
    - urn: urn:defend:risk:req_node:nzism-v3:9.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.1:4:5
      ref_id: 9.1.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1465]'
      description: Agencies SHOULD advise personnel attending courses along with non-government
        personnel not to disclose any details that could be used to compromise agency
        security.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:9
      ref_id: '9.2'
      name: Authorisations, Security Clearances And Briefings
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:1
      ref_id: 9.2.1
      description: Only appropriately authorised, cleared and briefed personnel are
        allowed access to systems.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:1
      ref_id: 9.2.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2
      description: "Security clearances \u2013 New Zealand and foreign"
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.3
      description: "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\
        \ identified risks can be mitigated. Refer to PSR\_Personnel Security for\
        \ more information.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.4
      description: "Such security clearances are required for many roles worldwide\
        \ by government, commercial and other organisations where there is a requirement\
        \ for assurance of the ability of an individual and organisation to securely\
        \ access, manage, and protect confidential, sensitive or classified information.\_\
        \ Not all security clearances will grant the same level or types of access."
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.5
      description: "The process invariably includes background or security checks\
        \ on the individual, a briefing and then signing documents, in which the individual\
        \ formally acknowledges the legal requirements to\_not share such information\
        \ with unauthorised individuals or organisations.\_ This will include a requirement\
        \ not to inappropriately remove, store or access classified documents or other\
        \ sensitive information."
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.6
      description: 'In New Zealand there are two security authorisation processes:

        for information classified CONFIDENTIAL and above; and

        for information classified RESTRICTED and below.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.7
      description: "For information classified\_CONFIDENTIAL and above\_a formal vetting\
        \ process is required to gain a National Security Clearance.\_ Refer to the\_\
        PSR\_for more detail of vetting requirements and the process for applying\
        \ for National Security Clearance."
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:2:2
      ref_id: 9.2.8
      description: "For information classified RESTRICTED and below, the authorisations,\
        \ security checks and supporting briefings form part of the Agency\u2019s\
        \ recruitment and induction processes for all staff.\_ These authorisations,\
        \ security checks and briefings are evidenced by a formal record of approval\
        \ of the authorisation, the requirement for a security check and a signed\
        \ acknowledgement from the individual staff member. The level of detail for\
        \ the agency's process will depend on the role, tasks and position of the\
        \ agency employee."
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:3
      ref_id: 9.2.9
      description: "Additional policy and information on granting and maintaining\
        \ security clearances can be found in:\n\n\n\nReference\nTitle\nSource\n\n\
        \n\nPSR Mandatory Requirements\n\n\nGOV4, INFOSEC1, PERSEC1, PERSEC2, PERSEC3,\
        \ PERSEC4, PHYSEC1 and PHYSEC2\n\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements\nPersonnel security\
        \ (PERSEC) | Protective Security Requirements\nPhysical security (PHYSEC)\
        \ | Protective Security Requirements\n\n\nPSR content protocols\_\n\nManagement\
        \ protocol for information security\nManagement protocol for personnel security\n\
        Management Protocol for physical security\_\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \nManaging specific scenarios | Protective Security Requirements\n\n\nCreating\
        \ a security culture | Protective Security Requirements\nBuilding security\
        \ awareness | Protective Security Requirements\nPhysical security zones |\
        \ Protective Security Requirements\nUnderstanding the physical security lifecycle\
        \ | Protective Security Requirements\nRecruiting and managing national security\
        \ clearance holders | Protective Security Requirements\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Documenting authorisations, security clearance and briefing requirements
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:1
      ref_id: 9.2.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:1
      ref_id: 9.2.10.R.02
      description: Types of system users for which access requirements will need to
        be documented include general users, privileged users, system administrators,
        contractors and visitors.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:1
      ref_id: 9.2.10.C.01
      name: 'Control -  All Classifications - Must [CID: 1480]'
      description: Agencies MUST specify in the System Security Plan (SSP) any authorisations,
        security clearances and briefings necessary for system access.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Authorisation and system access
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:2
      ref_id: 9.2.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:2
      ref_id: 9.2.11.C.01
      name: 'Control -  Top Secret - Must [CID: 1483]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:2
      ref_id: 9.2.11.C.02
      name: 'Control -  All Classifications - Should [CID: 1484]'
      description: "Agencies SHOULD:\nlimit system access on a need-to-know/need-to-access\
        \ basis;\nprovide system users with the least amount of privileges needed\
        \ to undertake their duties;\nhave any requests for access to a system authorised\
        \ by the supervisor or manager of the system user;\_and\nensure a formal acknowledgement\
        \ of the security briefing is obtained and recorded.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Recording authorisation for personnel to access systems
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:3
      ref_id: 9.2.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:3
      ref_id: 9.2.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1487]'
      description: "Agencies SHOULD:\nmaintain a secure record of:\n\nall authorised\
        \ system users;\ntheir user identification;\nwhy access is required;\nrole\
        \ and privilege level,\nwho provided the authorisation to access the system;\n\
        when the authorisation was granted; and\n\n\nkeep a copy of\_the acknowledgement\
        \ signed by the individual granted a clearance; and\nmaintain the record,\
        \ for the life of the system or information to which access is granted, or\
        \ the length of employment, whichever is the longer.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Security clearance for system access
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:4
      ref_id: 9.2.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:4
      ref_id: 9.2.13.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 1490]'
      description: 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.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:4
      ref_id: 9.2.13.C.02
      name: 'Control -  All Classifications - Must [CID: 1491]'
      description: 'All system users MUST:

        hold a security clearance or other authorisation appropriate for the system
        classification; or

        have been granted access in accordance with the requirements in the PSR for
        emergency access.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: System access briefings
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:5
      ref_id: 9.2.14.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:5
      ref_id: 9.2.14.C.01
      name: 'Control -  All Classifications - Must [CID: 1494]'
      description: All system users MUST have received any necessary briefings before
        being granted access to compartmented or endorsed information or systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Access by foreign nationals to NZEO systems
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:6
      ref_id: 9.2.15.R.01
      description: NZEO information is restricted to New Zealand nationals.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:6
      ref_id: 9.2.15.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1497]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:6
      ref_id: 9.2.15.C.02
      name: 'Control -  All Classifications - Must Not [CID: 1498]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Access by foreign nationals to New Zealand systems
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:7
      ref_id: 9.2.16.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:7
      ref_id: 9.2.16.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1501]'
      description: 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.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Granting limited higher access
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:8
      ref_id: 9.2.17.R.01
      description: Under exceptional circumstances, temporary access to systems classified
        RESTRICTED and below may be granted.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:8
      ref_id: 9.2.17.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 1504]'
      description: Agencies MUST NOT permit limited higher access for systems and
        information classified CONFIDENTIAL or above.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.17.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:8
      ref_id: 9.2.17.C.02
      name: 'Control -  All Classifications - Must [CID: 1505]'
      description: "Agencies granting limited higher access to information or systems\
        \ MUST ensure that:\nthe requirement to grant limited higher access is temporary\
        \ in nature and is an exception rather than the norm;\nan ITSM has recommended\
        \ the limited higher access;\na cessation date for limited higher access has\
        \ been set;\nthe access period does not exceed two months;\nthe limited higher\
        \ access is granted on an occasional NOT non-ongoing basis;\nthe system user\
        \ is not granted privileged access to the system;\nthe system user\u2019s\
        \ access is formally documented; and\nthe system user\u2019s access is approved\
        \ by the CISO.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Controlling limited higher access
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:9
      ref_id: 9.2.18.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:9
      ref_id: 9.2.18.C.01
      name: 'Control -  All Classifications - Must [CID: 1508]'
      description: "Agencies granting limited higher access to a system MUST ensure\
        \ that:\nthe approval for access is formally acknowledged and recorded; and\
        \ either\n\neffective controls are in place to restrict access only to classified\
        \ information that is necessary to undertake the system user\u2019s duties;\
        \ or\nthe system user is continually supervised by another system user who\
        \ has the appropriate security clearances to access the system.\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Granting emergency access
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.R.02
      description: "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 \u201Clessons learned\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 1512]'
      description: Emergency access MUST NOT be granted unless personnel have a security
        clearance to at least CONFIDENTIAL level.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 1513]'
      description: Emergency access MUST NOT be used on reassignment of duties while
        awaiting completion of full security clearance procedures.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.C.03
      name: 'Control -  All Classifications - Must [CID: 1514]'
      description: "Agencies granting emergency access to a system MUST ensure that:\n\
        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;\nthe agency head or their delegate has approved\
        \ the emergency access;\nthe system user\u2019s access is formally documented;\n\
        the system user\u2019s access is reported to the CISO;\_\nappropriate briefs\
        \ and debriefs for the information and system are conducted;\naccess is limited\
        \ to information and systems necessary to deal with the particular emergency\
        \ and is governed by strict application of the \u201Cneed to know\u201D principle;\_\
        \nemergency access is limited to ONE security clearance level higher than\
        \ the clearance currently held; and\nthe security clearance process is completed\
        \ as soon as possible.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.19.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:10
      ref_id: 9.2.19.C.04
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 1515]'
      description: Personnel granted emergency access MUST be debriefed at the conclusion
        of the emergency.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.2:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4
      description: Accessing endorsed or compartmented information
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:11
      ref_id: 9.2.20.R.01
      description: Limited higher access to systems processing, storing or communicating
        endorsed or compartmented information is not permitted.
    - urn: urn:defend:risk:req_node:nzism-v3:9.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.2:4:11
      ref_id: 9.2.20.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1518]'
      description: Agencies MUST NOT grant limited higher access to systems that process,
        store or communicate endorsed or compartmented information.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:9
      ref_id: '9.3'
      name: Using The Internet
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:1
      ref_id: 9.3.1
      description: Personnel use Internet services in a responsible and security conscious
        manner, consistent with agency policies.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:2:1
      ref_id: 9.3.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:2:1
      ref_id: 9.3.3
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Using the Internet
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:1
      ref_id: 9.3.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:1
      ref_id: 9.3.4.C.01
      name: 'Control -  All Classifications - Must [CID: 1529]'
      description: Agencies MUST ensure personnel are instructed to report any suspicious
        activity, questioning or contact when using the Internet, to an ITSM.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Awareness of Web usage policies
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:2
      ref_id: 9.3.5.R.01
      description: Users MUST be familiar with and formally acknowledge agency Web
        usage policies for system users in order to follow the policy and guidance.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:2
      ref_id: 9.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1532]'
      description: "Agencies MUST make their system users aware of the agency\u2019\
        s Web usage policies."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:2
      ref_id: 9.3.5.C.02
      name: 'Control -  All Classifications - Must [CID: 1533]'
      description: Personnel MUST formally acknowledge and accept agency Web usage
        policies.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Monitoring Web usage
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:3
      ref_id: 9.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:3
      ref_id: 9.3.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1536]'
      description: Agencies SHOULD implement measures to monitor their personnel,
        visitor and contractor compliance with their Web usage policies.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Posting information on the Web
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.R.03
      description: "Accessing personal accounts from an agency\u2019s systems is discouraged."
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.C.01
      name: 'Control -  All Classifications - Must [CID: 1541]'
      description: Agencies MUST ensure personnel are instructed to take special care
        when posting information on the Web.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.C.02
      name: 'Control -  All Classifications - Must [CID: 1542]'
      description: Agencies MUST ensure personnel posting information on the Web maintain
        separate professional accounts from any personal accounts they have for websites.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.C.03
      name: 'Control -  All Classifications - Should [CID: 1543]'
      description: Agencies SHOULD monitor websites where personnel post information
        and if necessary remove or request the removal of any inappropriate information.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.7.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:4
      ref_id: 9.3.7.C.04
      name: 'Control -  All Classifications - Should [CID: 1544]'
      description: Accessing personal accounts from agency systems SHOULD be discouraged.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Posting personal information on the Web
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.R.02
      description: Profiling is a common marketing and targeting technique facilitated
        by the internet.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.R.04
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1550]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.C.02
      name: 'Control -  All Classifications - Should [CID: 1551]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:5
      ref_id: 9.3.8.C.03
      name: 'Control -  All Classifications - Should [CID: 1552]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Peer-to-peer applications
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:6
      ref_id: 9.3.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:6
      ref_id: 9.3.9.C.01
      name: 'Control -  All Classifications - Should Not [CID: 1555]'
      description: Agencies SHOULD NOT allow personnel to use peer-to-peer applications
        over the Internet.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.3:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3
      description: Receiving files via the Internet
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:7
      ref_id: 9.3.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.3:3:7
      ref_id: 9.3.10.C.01
      name: 'Control -  All Classifications - Should Not [CID: 1558]'
      description: Agencies SHOULD NOT allow personnel to receive files via peer-to-peer,
        IM or IRC applications.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:9
      ref_id: '9.4'
      name: Escorting Uncleared Personnel
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:1
      ref_id: 9.4.1
      description: Uncleared personnel are escorted within secure areas.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:2:1
      ref_id: 9.4.2
      description: This section covers information relating to the escorting of uncleared
        personnel without security clearances in secure areas.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:3
      ref_id: 9.4.3
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV4, INFOSEC1, PERSEC1,\
        \ PERSEC2, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements\nPersonnel security\
        \ (PERSEC) | Protective Security Requirements\nPhysical security (PHYSEC)\
        \ | Protective Security Requirements\n\n\n\nPSR content protocols\n\n\nManagement\
        \ protocol for information security\nManagement protocol for personnel security\n\
        Management Protocol for physical security\_\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\n\nPSR requirements sections\n\
        \n\nManaging specific scenarios | Protective Security Requirements\n\n\nCreating\
        \ a security culture | Protective Security Requirements\nBuilding security\
        \ awareness | Protective Security Requirements\nPhysical security zones |\
        \ Protective Security Requirements\nUnderstanding the physical security lifecycle\
        \ | Protective Security Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Unescorted access
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:1
      ref_id: 9.4.4.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:1
      ref_id: 9.4.4.C.01
      name: 'Control -  Top Secret - Must [CID: 1569]'
      description: Agencies MUST ensure that all personnel with unescorted access
        to TOP SECRET areas have appropriate security clearances and briefings.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Maintaining an unescorted access list
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:2
      ref_id: 9.4.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:2
      ref_id: 9.4.5.C.01
      name: 'Control -  Top Secret - Must [CID: 1572]'
      description: Agencies MUST maintain an up to date list of personnel entitled
        to enter a TOP SECRET area without an escort.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:2
      ref_id: 9.4.5.C.02
      name: 'Control -  Top Secret - Must [CID: 1573]'
      description: Personnel MUST display identity cards at all times while within
        the secure area.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Displaying the unescorted access list
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:3
      ref_id: 9.4.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:3
      ref_id: 9.4.6.C.01
      name: 'Control -  Top Secret - Should [CID: 1576]'
      description: Agencies SHOULD display within a TOP SECRET area, an up to date
        list of personnel entitled to enter the area without an escort.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:3
      ref_id: 9.4.6.C.02
      name: 'Control -  Top Secret - Should Not [CID: 1577]'
      description: The unescorted access list SHOULD NOT be visible from outside of
        the secure area.
      implementation_groups:
      - Top Secret - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Visitors
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:4
      ref_id: 9.4.7.R.01
      description: Visitors to secure areas should be carefully supervised to ensure
        the need-to-know principle is strictly adhered to.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:4
      ref_id: 9.4.7.C.01
      name: 'Control -  Top Secret - Should [CID: 1580]'
      description: 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.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Recording visits in a visitor log
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:5
      ref_id: 9.4.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:5
      ref_id: 9.4.8.C.01
      name: 'Control -  Top Secret - Must Not [CID: 1583]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Content of the visitor log
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:6
      ref_id: 9.4.9.R.01
      description: The contents of the visitor log ensure that security personnel
        have sufficient details to conduct an investigation into an incident if required.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:6
      ref_id: 9.4.9.C.01
      name: 'Control -  Top Secret - Must [CID: 1586]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:9.4:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4
      description: Separate visitor logs
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:7
      ref_id: 9.4.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:9.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:9.4:4:7
      ref_id: 9.4.10.C.01
      name: 'Control -  Top Secret - Must [CID: 1589]'
      description: Agencies with a TOP SECRET area within a larger facility MUST maintain
        a separate log from any general visitor log.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10
      assessable: false
      depth: 1
      ref_id: '10'
      name: Infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:10.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.1'
      name: Cable Management Fundamentals
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:1
      ref_id: 10.1.1
      description: "Cable management systems are designed to support the integration\
        \ of systems across government facilities, assist maintenance and engineering\
        \ changes, as well as minimise the opportunity for tampering or unauthorised\
        \ changes to\_cable systems."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:1
      ref_id: 10.1.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:2
      ref_id: 10.1.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Common implementation scenarios
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:3
      ref_id: 10.1.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Red/Black Concept and Cable Separation
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.5
      description: 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 from non-national
        security information. The RED/BLACK concept is sometimes described as RED/BLACK
        architecture or RED/BLACK engineering.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.6
      description: "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\_systems classified CONFIDENTIAL and above and LOW refers to\_systems\
        \ 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.\
        \ It is important to note that systems carrying a particular classification\
        \ may also carry information at ALL lower classifications BUT NOT\_any higher\
        \ classifications."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.8
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.9
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:4
      ref_id: 10.1.10
      description: A fundamental control is the separation of cables and related equipment
        with sufficient distance between them to prevent cross-contamination.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Cable trays
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:5
      ref_id: 10.1.11
      description: "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.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:5
      ref_id: 10.1.12
      description: "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:\n\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Catenary
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:6
      ref_id: 10.1.13
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Earthing
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:7
      ref_id: 10.1.14
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Fibre optic cabling
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:8
      ref_id: 10.1.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:8
      ref_id: 10.1.16
      description: 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
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:8
      ref_id: 10.1.17
      description: Fibre cable is considered the best method to future proof against
        unforeseen threats.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:8
      ref_id: 10.1.18
      description: "Cable trays for fibre only cable may be of any suitable material.\_\
        \ If metal trays are used they MUST be earthed."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Ribbon Fibre Optic Cable
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.19
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.20
      description: "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"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.21
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.22
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.23
      description: Because the cable profile is different to older round cable type,
        new cable strippers, cleavers, and fusion splicers are required for installation
        and maintenance.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.24
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.25
      description: "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.\n\_\n\_\n\_\nFigure 3: Jacket Cable\_\_\_\_\_\_\_\_\_\_\_\_\_\
        \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ Figure 4:\
        \ Loose Tube Cable"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:9
      ref_id: 10.1.26
      description: "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.\n\_\nFigure 5: Infrastructure (High Cable Count) Ribbon\
        \ Cable"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Armoured Fibre optic cabling
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:10
      ref_id: 10.1.27
      description: "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.\n\_\n \n\_\n\n\_\_\_\_\_\_\_\_\_\_\_\
        \_\_\_\_\_\_\_\_ Figure 6 - Armoured Ribbon Fibre Cable\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Backbone
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:11
      ref_id: 10.1.28
      description: "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\u2019\
        s. Smaller networks may also be connected to the backbone."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:11
      ref_id: 10.1.29
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:11
      ref_id: 10.1.30
      description: "Backbones can be defined in terms of six criteria:\ntransmission\
        \ media;\ntopology;\nsecurity required;\naccess control;\ntransmission technique;\_\
        \ntransmission speed and capability.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: TOP SECRET cabling
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:12
      ref_id: 10.1.31
      description: "For TOP SECRET cabling the cable\u2019s non-conductive protective\
        \ sheath IS NOT considered to be a conduit. For TOP SECRET fibre optic cables\
        \ with sub-units, the cable\u2019s outer protective sheath IS considered to\
        \ be a conduit."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2
      description: Power Filters
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.32
      description: "A power filter is a device 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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.33
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.34
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.35
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.36
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.37
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:2:13
      ref_id: 10.1.38
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.39
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:3
      ref_id: 10.1.39
      description: "Fibre Standards:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\
        AS/NZS 2967:2014\n\nOptical fibre communication cabling systems safety.\n\
        Provides rules for safe practices in the handling, installation, testing,\
        \ use and disposal of optical fibre cabling and associated materials and equipment.\n\
        \nStandards NZ\n\nhttps://www.standards.govt.nz/shop/asnzs-29672014/\n\n\n\
        ISO/IEC 11801\n\nInformation technology - Generic cabling for customer premises.\n\
        Specifies general-purpose telecommunication cabling systems (structured cabling),\
        \ including several classes of optical fibre interconnections.\n\nISO\n\n\
        https://www.iso.org/standard/66182.html\n\n\nIEC 60793 Series\n\nOptical fibres.\n\
        A list of all parts in the IEC 60793 series, published under the general title\
        \ Optical fibres, can be found on the IEC website.\n\nISO\n\nhttps://webstore.iec.ch/home\n\
        \n\nIEC 60794\_Series\n\nOptical fibre cables.\nA list of all parts in the\
        \ IEC 60794 series, published under the general title Optical fibre cables,\
        \ can be found on the IEC website.\n\nISO\n\nhttps://webstore.iec.ch/home\n\
        \n\nANSI/TIA-568-C.3\nOptical Fibre Cabling Components\nTIA\nhttps://webstore.ansi.org\n\
        \n\nANSI/TIA-598-D (Revision of TIA-598-C) July 2014\n\nOptical Fibre Cable\
        \ Colour Coding\nThis standard defines the recommended identification scheme\
        \ or system for individual fibres, fibre units, and groups of fibre units\
        \ within a cable structure.\n\nTIA\n\nhttps://webstore.ansi.org\n\n\nITU-T\
        \ G.657 \u2013 659 series\n\nOptical Fibre Cables\nCharacteristics and recommendations\
        \ for selection, use and installation.\n\nITU-T\n\nhttps://www.itu.int/en/ITU-T/publications/Pages/recs.aspx\n\
        \n\n\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: References - Fibre Standards
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.40
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:4
      ref_id: 10.1.40
      description: "Further references can be found at:\n\n\n\nReference\n\n\nTitle\n\
        \n\nPublisher\n\n\nSource\n\n\n\n\nNZCSS 400\n\n\nNew Zealand Communications\
        \ Security Standard No 400 (Document classified CONFIDENTIAL)\n\nGCSB\n\n\
        CONFIDENTIAL document available on application to authorised personnel\n\n\
        \n\n\nAS/NZS 3000:2007/Amdt 2:2012\n\n\nElectrical Installations (Known as\
        \ the Australia/New Zealand Wiring Rules,\n\n\nStandards NZ\n\n\nhttps://standards.govt.nz/\_\
        \_\n\n\n\n\nANSI/TIA-568-C.3\_\n\n\nOptical Fiber Cabling Components\n\n\n\
        American National Standards Institute (ANSI)\n\n\nhttps://www.ansi.org/\n\n\
        \n\n\nIEEE 802-2014\n\n\nLocal and Metropolitan Area Networks: Overview and\
        \ Architecture\n\n\nInstitute of Electrical and Electronics Engineers (IEEE)\n\
        \nhttps://ieeexplore.ieee.org/document/6847097\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.41
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:5
      ref_id: 10.1.41
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nINFOSEC1, INFOSEC2, INFOSEC3,\
        \ INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols\n\
        \nManagement protocol for information security\n\_\nManagement protocol for\
        \ physical security\n\n\nManagement protocol for information security | Protective\
        \ Security Requirements\n\_\nManagement protocol for physical security | Protective\
        \ Security Requirements\n\n\n\nPSR requirements sections\n\nSecurity zones\n\
        \n\nPhysical security zones | Protective Security Requirements\n\n\n\nManaging\
        \ specific scenarios\n\nManaging specific scenarios | Protective Security\
        \ Requirements\n\n\nPhysical security for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Backbone
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.42.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:1
      ref_id: 10.1.42.R.01
      description: "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 \u201Cfuture proofing\u201D\
        \ is also required as re-cabling to manage capacity issues can be costly.\
        \ Fibre optic cable provides a convenient means of securing and \u201Cfuture\
        \ proofing\u201D backbones."
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.42.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:1
      ref_id: 10.1.42.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2216]'
      description: Agencies MUST use fibre optic cable for backbone infrastructures
        and installations.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.42.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:1
      ref_id: 10.1.42.C.02
      name: 'Control -  All Classifications - Should [CID: 2217]'
      description: Agencies SHOULD use fibre optic cable for backbone infrastructures
        and installations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Use of Fibre Optic Cable
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.43.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      ref_id: 10.1.43.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.43.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      ref_id: 10.1.43.C.01
      name: 'Control -  All Classifications - Should [CID: 2220]'
      description: Agencies SHOULD use fibre optic cabling.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.43.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      ref_id: 10.1.43.C.02
      name: 'Control -  All Classifications - Should [CID: 2221]'
      description: Agencies SHOULD consult with the GCSB where fibre optic cable incorporating
        conductive metal strengtheners or sheaths is specified.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.43.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      ref_id: 10.1.43.C.03
      name: 'Control -  All Classifications - Should [CID: 2222]'
      description: Agencies SHOULD consult with the GCSB where copper cables are specified.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.43.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:2
      ref_id: 10.1.43.C.04
      name: 'Control -  All Classifications - Should Not [CID: 2223]'
      description: Agencies SHOULD NOT use fibre optic cable incorporating conductive
        metal strengtheners or sheaths except where essential for cable integrity.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Cabling Standards
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.44.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:3
      ref_id: 10.1.44.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.44.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:3
      ref_id: 10.1.44.C.01
      name: 'Control -  All Classifications - Must [CID: 2226]'
      description: Agencies MUST install all cabling in accordance with the relevant
        New Zealand standards as directed by AS/NZS 3000:2007 and NZCSS400.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Cable colours
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.45.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:4
      ref_id: 10.1.45.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.45.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:4
      ref_id: 10.1.45.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.45.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:4
      ref_id: 10.1.45.C.01
      name: 'Control -  All Classifications - Must [CID: 2230]'
      description: "Agencies MUST comply with the cable and conduit colours specified\
        \ in the following table.\n\n\nClassification\nCable colour\n\n\nCompartmented\
        \ Information (SCI)\nOrange/Yellow/Teal or other colour\_\n\n\nTOP SECRET\n\
        Red\n\n\nSECRET\nBlue\n\n\nCONFIDENTIAL\nGreen\n\n\nRESTRICTED and all lower\
        \ classifications\nBlack\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.45.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:4
      ref_id: 10.1.45.C.02
      name: 'Control -  All Classifications - Must [CID: 2231]'
      description: "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\u2019s SOPs."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Cable colours for foreign systems in New Zealand facilities
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.46.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      ref_id: 10.1.46.R.01
      description: Foreign systems should be segregated and separated from other agency
        systems for security purposes. Colour-coding will facilitate installation,
        maintenance, certification and accreditation.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.46.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      ref_id: 10.1.46.C.01
      name: 'Control -  Top Secret - Must [CID: 2234]'
      description: The cable colour to be used for foreign systems MUST be agreed
        between the host agency, the foreign system owner and the Accreditation Authority.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.46.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      ref_id: 10.1.46.C.02
      name: 'Control -  Top Secret - Must Not [CID: 2235]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.46.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      ref_id: 10.1.46.C.03
      name: 'Control -  All Classifications - Should [CID: 2236]'
      description: The cable colour to be used for foreign systems SHOULD be agreed
        between the host agency, the foreign system owner and the Accreditation Authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.46.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:5
      ref_id: 10.1.46.C.04
      name: 'Control -  All Classifications - Should Not [CID: 2237]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Cable groupings
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.47.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:6
      ref_id: 10.1.47.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.47.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:6
      ref_id: 10.1.47.C.01
      name: 'Control -  All Classifications - Must [CID: 2240]'
      description: Agencies MUST contact GCSB for advice when combining the cabling
        of special networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.47.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:6
      ref_id: 10.1.47.C.02
      name: 'Control -  All Classifications - Must Not [CID: 2241]'
      description: "Agencies MUST NOT deviate from the approved fibre cable combinations\
        \ for shared conduits and reticulation systems as indicated below.\n\n\nGroup\n\
        \nApproved combination\n\n\n\n1\nUNCLASSIFIED\n\n\n\_\nRESTRICTED\n\n\n2\n\
        CONFIDENTIAL\n\n\n\_\nSECRET\n\n\n3\nTOP SECRET\n\n\n\_\n\nOther Special Networks\n\
        \n\n\n"
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Fibre optic cables sharing a common conduit
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.48.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:7
      ref_id: 10.1.48.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.48.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:7
      ref_id: 10.1.48.C.01
      name: 'Control -  All Classifications - Must [CID: 2244]'
      description: "With fibre optic cables the arrangements of fibres within the\
        \ cable sheath, as illustrated in Figure 3, MUST carry a single classification\
        \ only.\_"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.48.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:7
      ref_id: 10.1.48.C.02
      name: 'Control -  All Classifications - Must [CID: 2245]'
      description: If a fibre optic cable contains subunits, as shown in Figure 4,
        each subunit MUST carry only a single classification.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.48.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:7
      ref_id: 10.1.48.C.03
      name: 'Control -  All Classifications - Must Not [CID: 2246]'
      description: Agencies MUST NOT mix classifications up to RESTRICTED with classifications
        of CONFIDENTIAL and above in a single cable.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Audio secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.49.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:8
      ref_id: 10.1.49.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.49.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:8
      ref_id: 10.1.49.C.01
      name: 'Control -  Top Secret - Must [CID: 2249]'
      description: When penetrating an audio secure area for cables, agencies MUST
        comply with all directions provided by GCSB.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Wall outlet terminations
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.50.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      ref_id: 10.1.50.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.50.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      ref_id: 10.1.50.C.01
      name: 'Control -  All Classifications - Must [CID: 2253]'
      description: Cable groups sharing a wall outlet MUST use different connectors
        for systems of different classifications.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.50.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      ref_id: 10.1.50.C.02
      name: 'Control -  Top Secret - Must [CID: 2254]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.50.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      ref_id: 10.1.50.C.03
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 2255]'
      description: Cable outlets MUST be labelled with the system classification and
        connector type.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.50.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:9
      ref_id: 10.1.50.C.04
      name: 'Control -  All Classifications - Should [CID: 2256]'
      description: Cable outlets SHOULD be labelled with the system classification
        and connector type.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.1:6:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6
      description: Power Filters
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.51.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:10
      ref_id: 10.1.51.R.01
      description: Power filters are used to provide a filtered (clean) power supply
        and reduce opportunity for technical attacks. See also 10.1.32.
    - urn: urn:defend:risk:req_node:nzism-v3:10.1.51.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.1:6:10
      ref_id: 10.1.51.C.01
      name: 'Control -  All Classifications - Should [CID: 5899]'
      description: Power filters SHOULD be used to provide a filtered power supply
        and reduce opportunity for technical attacks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.2'
      name: Cable Management for Non-Shared Government Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:1
      ref_id: 10.2.1
      description: "Cable management\_systems in non-shared government facilities\
        \ are implemented in a secure and easily inspectable and maintainable way."
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:2:1
      ref_id: 10.2.2
      description: "This section provides specific requirements for cabling installed\
        \ in non-shared Government facilities.\nA non-shared facility is a facility\
        \ occupied solely by a single agency.\nA shared facility is a facility occupied\
        \ by more than one agency.\_ A shared facility should have stricter physical\
        \ and technical security controls than a non-shared facility.\_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:2:1
      ref_id: 10.2.3
      description: This section is to be applied in addition to common requirements
        for cabling as outlined in the Section 10.1 - Cable Management Fundamentals.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:2:2
      ref_id: 10.2.4
      description: 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 manual will need to be consulted.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:3
      ref_id: 10.2.5
      description: 'Further references can be found at:



        Reference

        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


        https://standards.govt.nz/



        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      description: Cabling Inspection
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:1
      ref_id: 10.2.6.R.01
      description: Regular inspections of cable installations are necessary to detect
        any unauthorised or malicious tampering or cable degradation.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:1
      ref_id: 10.2.6.C.01
      name: 'Control -  Top Secret - Must [CID: 2270]'
      description: In TOP SECRET areas or zones, all cabling MUST be inspectable at
        a minimum of five-metre intervals.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:1
      ref_id: 10.2.6.C.02
      name: 'Control -  All Classifications - Should [CID: 2271]'
      description: Cabling SHOULD be inspectable at a minimum of five-metre intervals.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      description: Cables sharing a common reticulation system
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:2
      ref_id: 10.2.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:2
      ref_id: 10.2.7.C.01
      name: 'Control -  All Classifications - Should [CID: 2274]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      description: Cabling in walls
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:3
      ref_id: 10.2.8.R.01
      description: Cabling run correctly in walls allows for neater installations
        while maintaining separation and inspectability requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:3
      ref_id: 10.2.8.C.01
      name: 'Control -  All Classifications - Should [CID: 2277]'
      description: Flexible or plastic conduit SHOULD be used in walls to run cabling
        from cable trays to wall outlets.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      description: Cabinet separation
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:4
      ref_id: 10.2.9.R.01
      description: Having a definite gap between cabinets allows for ease of inspections
        for any unauthorised or malicious cabling or cross patching.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:4
      ref_id: 10.2.9.C.01
      name: 'Control -  Top Secret - Should [CID: 2280]'
      description: TOP SECRET cabinets SHOULD have a visible inspectable gap between
        themselves and lower classified cabinets.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4
      description: Power Filters
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:5
      ref_id: 10.2.10.R.01
      description: Power filters are used to provide a filtered (clean) power supply
        and reduce opportunity for technical attacks. See also 10.1.32.
    - urn: urn:defend:risk:req_node:nzism-v3:10.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.2:4:5
      ref_id: 10.2.10.C.01
      name: 'Control -  All Classifications - Should [CID: 5902]'
      description: Power filters SHOULD be used to provide a filtered power supply
        and reduce opportunity for technical attacks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.3'
      name: Cable Management for Shared Government Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:1
      ref_id: 10.3.1
      description: "Cable management\_systems in shared government facilities are\
        \ implemented in a secure and easily inspectable and maintainable way."
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:2:1
      ref_id: 10.3.2
      description: "This section provides specific requirements for cabling installed\
        \ in\_shared\_Government facilities.\nA\_shared\_facility is a facility occupied\
        \ by\_more than one\_agency.\_ A shared facility should have stricter physical\
        \ and technical security controls than a non-shared facility.\_\nA\_non-shared\_\
        facility is a facility occupied\_solely\_by a single agency.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:2:1
      ref_id: 10.3.3
      description: "This section is to be applied in addition to common requirements\
        \ for cabling as outlined in the\_Section 10.1 - Cable Management Fundamentals."
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:2:2
      ref_id: 10.3.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Use of fibre optic cabling
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      ref_id: 10.3.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      ref_id: 10.3.5.R.02
      description: It is more difficult to tap than copper cabling.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.5.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      ref_id: 10.3.5.R.03
      description: Many more fibres can be run per cable diameter than wired cables
        thereby reducing cable infrastructure costs.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.5.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      ref_id: 10.3.5.R.04
      description: Fibre cable is the best method to future proof against unforeseen
        threats.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:1
      ref_id: 10.3.5.C.01
      name: 'Control -  All Classifications - Should [CID: 2295]'
      description: Agencies SHOULD use fibre optic cabling.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Cabling inspection
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:2
      ref_id: 10.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:2
      ref_id: 10.3.6.C.01
      name: 'Control -  Top Secret - Must [CID: 2299]'
      description: In TOP SECRET areas, cables MUST be fully inspectable for their
        entire length.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:2
      ref_id: 10.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 2298]'
      description: Cabling SHOULD be inspectable at a minimum of five-metre intervals.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Cables sharing a common reticulation system
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:3
      ref_id: 10.3.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:3
      ref_id: 10.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 2302]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Enclosed cable reticulation systems
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:4
      ref_id: 10.3.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:4
      ref_id: 10.3.8.C.01
      name: 'Control -  Top Secret - Should [CID: 2305]'
      description: 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.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Cabling in walls
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:5
      ref_id: 10.3.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:5
      ref_id: 10.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 2308]'
      description: Cabling from cable trays to wall outlets SHOULD run in flexible
        or plastic conduit.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Wall penetrations
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:6
      ref_id: 10.3.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:6
      ref_id: 10.3.10.C.01
      name: 'Control -  Top Secret - Should [CID: 2311]'
      description: 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.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Power reticulation
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:7
      ref_id: 10.3.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:7
      ref_id: 10.3.11.C.01
      name: 'Control -  Top Secret - Should [CID: 2314]'
      description: TOP SECRET facilities SHOULD have a power distribution board, separately
        reticulated, located within the TOP SECRET area and supply UPS power to all
        equipment.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Power Filters
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:8
      ref_id: 10.3.12.R.01
      description: Power filters are used to provide a filtered (clean) power supply
        and reduce opportunity for technical attacks. See also 10.1.32.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:8
      ref_id: 10.3.12.C.01
      name: 'Control -  All Classifications - Should [CID: 2317]'
      description: Power filters SHOULD be used to provide a filtered power supply
        and reduce opportunity for technical attacks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.3:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3
      description: Cabinet separation
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:9
      ref_id: 10.3.13.R.01
      description: Having a visible gap between cabinets facilitates inspection for
        any unauthorised, malicious or cross patch cabling.
    - urn: urn:defend:risk:req_node:nzism-v3:10.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.3:3:9
      ref_id: 10.3.13.C.01
      name: 'Control -  Top Secret - Should [CID: 2320]'
      description: TOP SECRET cabinets SHOULD have a visible gap to separate them
        from lower classified cabinets.
      implementation_groups:
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.4'
      name: Cable Management for Shared Non-Government Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:1
      ref_id: 10.4.1
      description: "Cable management systems are implemented in shared non-government\
        \ facilities to minimise risks to\_data and information."
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:2:1
      ref_id: 10.4.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:2:2
      ref_id: 10.4.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Use of fibre optic cabling
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      ref_id: 10.4.4.R.01
      description: "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\u2019s controls may have a limited effect outside the agency controlled\
        \ area."
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      ref_id: 10.4.4.R.02
      description: Fibre optic cable is more difficult to tap than copper cabling
        and anti-tampering monitoring can be employed to detect tampering.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.4.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      ref_id: 10.4.4.R.03
      description: Many more fibres can be run per cable diameter than wired cables,
        reducing cable infrastructure costs.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      ref_id: 10.4.4.C.01
      name: 'Control -  Top Secret - Must [CID: 2335]'
      description: In TOP SECRET areas, agencies MUST use fibre optic cabling.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:1
      ref_id: 10.4.4.C.02
      name: 'Control -  All Classifications - Should [CID: 2336]'
      description: Agencies SHOULD use fibre optic cabling.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Cabling inspection
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:2
      ref_id: 10.4.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:2
      ref_id: 10.4.5.C.01
      name: 'Control -  Top Secret - Must [CID: 2340]'
      description: In TOP SECRET areas, cables MUST be fully inspectable for their
        entire length.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:2
      ref_id: 10.4.5.C.02
      name: 'Control -  All Classifications - Should [CID: 2341]'
      description: Cabling SHOULD be inspectable at a minimum of five-metre intervals.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Cables sharing a common reticulation system
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:3
      ref_id: 10.4.6.R.01
      description: In a shared non-government facility, tighter controls are placed
        on sharing reticulation systems as the threats attributable to tampering and
        damage are increased.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:3
      ref_id: 10.4.6.C.01
      name: 'Control -  Top Secret - Must [CID: 2344]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:3
      ref_id: 10.4.6.C.02
      name: 'Control -  Top Secret - Must [CID: 2345]'
      description: TOP SECRET cabling MUST run in a non-shared, enclosed reticulation
        system.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:3
      ref_id: 10.4.6.C.03
      name: 'Control -  All Classifications - Should [CID: 2346]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Enclosed cable reticulation systems
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:4
      ref_id: 10.4.7.R.01
      description: In a shared non-government facility, TOP SECRET cabling is enclosed
        in a sealed reticulation system to prevent access and control cable management.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:4
      ref_id: 10.4.7.C.01
      name: 'Control -  Top Secret - Must [CID: 2349]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:4
      ref_id: 10.4.7.C.02
      name: 'Control -  All Classifications - Should [CID: 2350]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Cabling in walls or party walls
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:5
      ref_id: 10.4.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:5
      ref_id: 10.4.8.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:5
      ref_id: 10.4.8.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 2354]'
      description: Cabling MUST NOT run in a party wall.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Sealing reticulation systems
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.C.01
      name: 'Control -  Top Secret - Must [CID: 2358]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.C.02
      name: 'Control -  Top Secret - Must [CID: 2359]'
      description: Tamper evident seals MUST be uniquely identifiable and a register
        kept of their unique number and location.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.C.03
      name: 'Control -  Top Secret - Must [CID: 2360]'
      description: Conduit joints MUST be sealed with glue or sealant.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.9.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:6
      ref_id: 10.4.9.C.04
      name: 'Control -  All Classifications - Should [CID: 2361]'
      description: Conduit joints SHOULD be sealed with glue or sealant.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Wall penetrations
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:7
      ref_id: 10.4.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:7
      ref_id: 10.4.10.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 2365]'
      description: 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.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Power reticulation
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:8
      ref_id: 10.4.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:8
      ref_id: 10.4.11.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 2368]'
      description: Secure facilities MUST have a power distribution board located
        within the secure area and supply UPS power all equipment.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Power Filters
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:9
      ref_id: 10.4.12.R.01
      description: Power filters are used to provide filtered (clean) power and reduce
        opportunity for technical attacks. Refer to 10.1.32 or consult the GCSB for
        technical advice.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:9
      ref_id: 10.4.12.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2371]'
      description: Power filters MUST be used to provide filtered (clean) power and
        reduce opportunity for technical attacks.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3
      description: Equipment Cabinet separation
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:10
      ref_id: 10.4.13.R.01
      description: A visible gap between equipment cabinets will make any cross-cabling
        obvious and will simplify inspections for unauthorised or compromising changes.
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:10
      ref_id: 10.4.13.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 2374]'
      description: Equipment cabinets MUST have a visible gap or non-conductive isolator
        between cabinets of different classifications.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.4.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.4:3:10
      ref_id: 10.4.13.C.02
      name: 'Control -  All Classifications - Should [CID: 2375]'
      description: There SHOULD be a visible inspectable gap or non-conductive isolator
        between equipment cabinets of different classifications.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.5'
      name: Cable Labelling and Registration
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:1
      ref_id: 10.5.1
      description: To facilitate cable management, and identify unauthorised additions
        or tampering.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:2:1
      ref_id: 10.5.2
      description: This section covers information relating to the labelling of cabling
        infrastructure installed in secure areas.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:2:2
      ref_id: 10.5.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Conduit label specifications
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:1
      ref_id: 10.5.4.R.01
      description: Conduit labelling of a specific size and colour will facilitate
        identifying secure conduits.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:1
      ref_id: 10.5.4.C.01
      name: 'Control -  All Classifications - Must [CID: 2387]'
      description: '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



        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Installing conduit labelling
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:2
      ref_id: 10.5.5.R.01
      description: Conduit labelling in public or reception areas should not draw
        undue attention to the level of classified processing or any other agency
        capability.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:2
      ref_id: 10.5.5.C.01
      name: 'Control -  All Classifications - Should Not [CID: 2390]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Labelling wall outlet boxes
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:3
      ref_id: 10.5.6.R.01
      description: Clear labelling of wall outlet boxes reduces the possibility of
        incorrectly attaching IT equipment of a lesser classification to the wrong
        outlet.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:3
      ref_id: 10.5.6.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2393]'
      description: Wall outlet boxes MUST denote the classification, cable and outlet
        numbers.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:3
      ref_id: 10.5.6.C.02
      name: 'Control -  All Classifications - Should [CID: 2394]'
      description: Wall outlet boxes SHOULD denote the classification, cable and outlet
        numbers.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Standard operating procedures
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:4
      ref_id: 10.5.7.R.01
      description: Recording labelling conventions in SOPs facilitates maintenance
        and fault finding.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:4
      ref_id: 10.5.7.C.01
      name: 'Control -  All Classifications - Should [CID: 2397]'
      description: The SOPs SHOULD record the site conventions for labelling and registration.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Labelling cables
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:5
      ref_id: 10.5.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:5
      ref_id: 10.5.8.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2400]'
      description: Agencies MUST label cables at each end, with sufficient information
        to enable the physical identification and inspection of the cable.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:5
      ref_id: 10.5.8.C.02
      name: 'Control -  All Classifications - Should [CID: 2401]'
      description: Agencies SHOULD label cables at each end, with sufficient information
        to enable the physical identification and inspection of the cable.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Cable register
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:6
      ref_id: 10.5.9.R.01
      description: Cable registers provide a source of information that assessors
        can view to verify compliance.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:6
      ref_id: 10.5.9.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2404]'
      description: Agencies MUST maintain a register of cables.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:6
      ref_id: 10.5.9.C.02
      name: 'Control -  All Classifications - Should [CID: 2405]'
      description: Agencies SHOULD maintain a register of cables.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Cable register contents
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:7
      ref_id: 10.5.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:7
      ref_id: 10.5.10.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2408]'
      description: '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.

        '
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:7
      ref_id: 10.5.10.C.02
      name: 'Control -  All Classifications - Should [CID: 2409]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.5:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3
      description: Cable inspections
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:8
      ref_id: 10.5.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.5.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.5:3:8
      ref_id: 10.5.11.C.01
      name: 'Control -  All Classifications - Should [CID: 2412]'
      description: Agencies SHOULD inspect cables for inconsistencies with the cable
        register in accordance with the frequency defined in the SSP.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.6'
      name: Patch Panels, Patch Cables and Racks
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:1
      ref_id: 10.6.1
      description: Cable termination, patch panels, patch cables and racks are designed
        to prevent emanations, cross-connecting or cross-patching systems of differing
        classifications as well as following good engineering practice.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:1
      ref_id: 10.6.2
      description: This section covers information relating to the configuration and
        installation of patch panels, patch cables and fly leads associated with communications
        systems.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:1
      ref_id: 10.6.3
      description: "Reference should also be made to:\nSection 8.5 \u2013 Tamper-evident\
        \ seals;\nSection 10.1 \u2013 Cable management fundamentals;\nSection 10.7\
        \ \u2013 Emanation Security Threat Assessments.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Applicability of controls within this section
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:2
      ref_id: 10.6.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Exception for patch cable and fly lead connectors
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:3
      ref_id: 10.6.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Fibre optic patch panels
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.6
      description: "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\u2019s individual\
        \ fibres."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.8
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.9
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.10
      description: Fibre patch panels can accommodate fibre adapter panels (also called
        connector panels), associated trunk cables, connectors, patch cords, and usually
        integrate cable management.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.11
      description: "There are several components in a fibre patch panel which may\
        \ include:\nChassis or frame;\nDrawer to facilitate access for installation\
        \ and maintenance;\nCassette;\nCoupler panels (adapter panels) \u2013 to hold\
        \ the connector couplers;\nThe connector couplers (connector adapters);\n\
        Splice tray \u2013 organises and secures splice modules;\nPatch cable management\
        \ trays.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:4
      ref_id: 10.6.12
      description: While well over 80 different fibre optic cable connector types
        have been manufactured, there are between 15 and 20 types in common use.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Multimedia Patch Panels
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:5
      ref_id: 10.6.13
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Rack Layout and Cable Management
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:6
      ref_id: 10.6.14
      description: "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.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:6
      ref_id: 10.6.15
      description: "\_Standardising rack layout and cable management minimises problems\
        \ caused by:\nAccidently not being able to locate end points of network and\
        \ patch cables without tracing the cable end to end.\nPhysically impeding\
        \ access to equipment.\nPositioning 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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:6
      ref_id: 10.6.16
      description: Standardising rack layout and cable management also assists in
        the maintenance of separation and segregation between RED/BLACK systems.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Standardised Rack Configuration
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:7
      ref_id: 10.6.17
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:7
      ref_id: 10.6.18
      description: "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:Figure 11: Separation of RED/BLACK"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Separation of Cable Runs
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:8
      ref_id: 10.6.19
      description: "In order to maintain the integrity of RED/BLACK separation, cables\
        \ for power and data should be separately bundled as power RED or BLACK and\
        \ data RED or BLACK.\_ Cables should be run with as much distance between\
        \ the bundles as can be practically managed, within the constraints of cable\
        \ feeds and rack configuration.\_ Ideally RED and BLACK should be on opposite\
        \ sides of the rack. Cables should be no longer than required to avoid overlength\
        \ cables compromising separation."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2
      description: Access to BLACK equipment and components by uncleared staff and
        contractors
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:2:9
      ref_id: 10.6.20
      description: "In some instances there may be a requirement for external technical\
        \ or other uncleared personnel to access BLACK equipment and components for\
        \ servicing, repair or replacement.\_ Care must be taken to maintain the integrity\
        \ of RED equipment and components.\_ This can be especially problematic in\
        \ shared rack configurations as described above.This requirement should be\
        \ identified before installation takes place and segregation measures implemented.\_\
        \ Ideally physical separation of BLACK from RED is the best solution, recognising\
        \ however, this may not always be possible or practical. Other solutions may\
        \ include, for example, a shared rack that has two doors with the RED door\
        \ locked and alarmed so that BLACK equipment can be accessed without compromising\
        \ the security of RED equipment.\_ Discussion with the GCSB may identify other\
        \ practical solutions."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:3
      ref_id: 10.6.21
      description: "Further References available below:\n\n\nReference\nTitle\_\_\n\
        Publisher\_\nSource\_\n\n\nISO/IEC 11801-5:2017\nData centres\n\_ISO\nhttps://www.iso.org/standard/62247.html\n\
        \n\n\nISO/IEC TR 14763-2-1:2011\n\n\nInformation\_technology -- Implementation\
        \ and\_operation of customer premises cabling\_-- Part 2-1: Planning and installation\
        \ -\_Identifiers within administration\_systems\n\n\_ISO\nhttps://www.iso.org/standard/55236.html\n\
        \n\n\nANSI/TIA-606-B\n\n\nAdministration Standard for\_the Telecommunications\
        \ Infrastructure\_of Commercial Buildings\n\n\_ANSI\nhttps://www.ansi.org\n\
        \n\n\nANSI/TIA-942\n\n\nTelecommunications\_Infrastructure Standard for Data\_\
        Centers\n\n\_ANSI\nhttps://www.ansi.org\n\n\n\nPD IEC/TR 62691:2016\n\n\n\
        Optical fibre\_cables. Guidelines to the installation of\_optical fibre cables\n\
        \n\nInternational\_ElectrotechnicalCommission (IEC)\_Available through\_Standards\
        \ New\_Zealand\n\nhttps://standards.govt.nz\n\n\nPD IEC/TR 62362:2010\nSelection\
        \ of optical fibre cable specifications relative to mechanical, ingress, climatic\
        \ or electromagnetic characteristics.\nGuidance\n\n\nInternational\_ElectrotechnicalCommission\
        \ (IEC)\_Available through\_Standards New\_Zealand\n\nhttps://standards.govt.nz\n\
        \n\nIEC 60794-2-31 Ed. 2.0 b(2012)\nOptical fibre cables - Part 2-31: Indoor\
        \ cables - Detailed specification for optical fibre\nribbon cables for use\
        \ in premises\_cabling\n\n\nInternational\_ElectrotechnicalCommission (IEC)\_\
        Available through\_Standards New\_Zealand\n\nhttps://standards.govt.nz\n\n\
        \n\nIEC 60794-2-11 Ed. 2.0 b(2012)\n\n\nOptical\_fibre cables - Part 2-11:\
        \ Indoor optical\_fibre cables - Detailed specification for\_simplex and duplex\
        \ cables for use in\_premises cabling\n\n\nInternational\_ElectrotechnicalCommission\
        \ (IEC)\_Available through\_Standards New\_Zealand\n\nhttps://standards.govt.nz\n\
        \n\nAS/NZS 2967:2014\nOptical fibre communication cabling systems safety\n\
        \nStandards New\_Zealand\n\nhttps://standards.govt.nz\n\n\n\nAS/NZS 14763.3:2017\n\
        \n\nInformation technology - Implementation\_and operation of customer premises\
        \ cabling\_- Part 3: Testing of optical fibre cabling\n\n\nStandards New\_\
        Zealand\n\nhttps://standards.govt.nz\n\n\n\nAS/NZS IEC 60825.2:2011\n\n\n\
        Safety of laser products - Part 2: Safety of\_optical fibre communication\
        \ systems (OFCS)\n\n\nStandards New\_Zealand\n\_\nhttps://standards.govt.nz\_\
        \n\n\n\nAS/NZS ISO/IEC 24764:2012\n\n\nGeneric\_cabling systems for data centres\n\
        \n\nStandards New\_Zealand\n\nhttps://standards.govt.nz\n\n\n\nAS/NZS 61386.1:2015\n\
        \n\nConduit systems\_for cable management - Part 1: General\_requirements\n\
        \n\nStandards New\_Zealand\n\nhttps://standards.govt.nz\n\n\n\nAS/NZS 61386.21:2015\n\
        \n\nConduit systems\_for cable management - Part 21: Particular\_requirements\
        \ - Rigid conduit systems\n\n\nStandards New\_Zealand\n\nhttps://standards.govt.nz\n\
        \n\n\nAS/NZS 61386.22:2015\n\n\nConduit systems\_for cable management - Part\
        \ 22: Particular\_requirements - Pliable conduit systems\n\nStandards New\_\
        Zealand\nhttps://standards.govt.nz\n\n\n\nAS/NZS 61386.23:2015\n\n\nConduit\
        \ systems for cable management -\_Part 23: Particular requirements - Flexible\_\
        conduit systems\n\n\nStandards New\_Zealand\n\nhttps://standards.govt.nz\n\
        \n\n\nAS/NZS ISO/IEC 29125:2012\n\n\nTelecommunications cabling\_requirements\
        \ for remote powering of\_data terminal equipment\n\n\nStandards New\_Zealand\n\
        \nhttps://standards.govt.nz\n\n\n\nBS EN 61300-2-37:2016\n\n\nFibre optic\_\
        interconnecting devices and passive\_components. Basic test and\_measurement\
        \ procedures. Tests. Cable\_bending for fibre optic closures\n\n\nBritish\
        \ Standards\_Institution (BSI)\_Available through\_Standards New\_Zealand\n\
        \nhttps://standards.govt.nz\n\n\n\nBS EN 60794-2-31:2013\n\n\nOptical fibre\_\
        cables. Indoor cables. Detailedspecification for optical fibre ribbon\_cables\
        \ for use in premises cabling\n\n\nBritish Standards\_Institution (BSI)\_\
        Available through\_Standards New\_Zealand\n\nhttps://standards.govt.nz\n\n\
        \nBS EN 50411-2:2008\nFibre organisers and closures to be used in optical\
        \ fibre\ncommunication systems. Product\_specifications. General and guidancefor\
        \ optical fibre cable joint closures,\_protected microduct closures, andmicroduct\
        \ connectors\n\n\nBritish Standards\_Institution (BSI)\_Available through\_\
        Standards New\_Zealand\n\nhttps://standards.govt.nz\n\n\n\nBS EN 60794-2-30:2008\n\
        \n\nOptical fibre\_cables. Indoor cables. Familyspecification for ribbon cables\n\
        \n\nBritish Standards\_Institution (BSI)\_Available through\_Standards New\_\
        Zealand\n\nhttps://standards.govt.nz\n\n\n\nBS EN 60794-2-21:2012\n\n\nOptical\
        \ fibre\_cables. Indoor optical fibre cables.Detailed specification for multi-fibre\_\
        optical distribution cables for use inpremises cabling\n\n\nBritish Standards\_\
        Institution (BSI)\_Available through\_Standards New\_Zealand\n\nhttps://standards.govt.nz\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Terminations to patch panels
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:1
      ref_id: 10.6.22.R.01
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.22.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:1
      ref_id: 10.6.22.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:1
      ref_id: 10.6.22.C.01
      name: 'Control -  All Classifications - Must [CID: 2425]'
      description: Agencies MUST ensure that only approved cable groups terminate
        on a patch panel.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.22.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:1
      ref_id: 10.6.22.C.02
      name: 'Control -  All Classifications - Must [CID: 5607]'
      description: RED and BLACK cables must be separated and bundled.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Patch cable and fly lead connectors
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      ref_id: 10.6.23.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      ref_id: 10.6.23.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2428]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.23.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      ref_id: 10.6.23.C.02
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2429]'
      description: In areas containing cabling for multiple classifications, agencies
        MUST document the selection of connector types for each classification.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.23.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      ref_id: 10.6.23.C.03
      name: 'Control -  All Classifications - Should [CID: 2430]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.23.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:2
      ref_id: 10.6.23.C.04
      name: 'Control -  All Classifications - Should [CID: 2431]'
      description: In areas containing cabling for systems of different classifications,
        agencies SHOULD document the selection of connector types.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Physical separation of patch panels
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:3
      ref_id: 10.6.24.R.01
      description: "Appropriate physical separation between systems classified CONFIDENTIAL\
        \ or above and a system of a lesserclassification (RESTRICTED and below) will:\n\
        reduce or eliminate the chances of cross patching between the systems; and\n\
        reduce or eliminate the possibility of unauthorised personnel or personnel\
        \ gaining access to classified system elements.\nRefer also to 10.1 \u2013\
        \ Cable Management Fundamentals for the discussion on RED/BLACK concept and\
        \ cable separation."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:3
      ref_id: 10.6.24.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Should [CID: 2434]'
      description: Agencies SHOULD physically separate patch panels of different classifications
        by installing them in separate cabinets.
      implementation_groups:
      - Confidential - SHOULD
      - Secret - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:3
      ref_id: 10.6.24.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 2435]'
      description: '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.

        '
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Cabinet Arrangement
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:4
      ref_id: 10.6.25.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:4
      ref_id: 10.6.25.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Should [CID: 5610]'
      description: 'Agencies SHOULD arrange the installation of cabinets as follows:

        RED equipment at the top;

        BLACK equipment in the centre;

        Power equipment at the bottom.

        '
      implementation_groups:
      - Secret - SHOULD
      - Confidential - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Rack Diagrams
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:5
      ref_id: 10.6.26.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:5
      ref_id: 10.6.26.C.01
      name: 'Control -  All Classifications - Should [CID: 5613]'
      description: Agencies SHOULD record equipment layouts and other relevant information
        on rack diagrams.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Fly lead installation
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:6
      ref_id: 10.6.27.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:6
      ref_id: 10.6.27.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Should [CID: 2438]'
      description: "Agencies SHOULD ensure that the fibre optic fly leads used to\
        \ connect wall outlets to IT equipment either:\ndo not exceed 5m in length;\
        \ or\nif they exceed 5m in length:\n\nare run in the facility\u2019s fixed\
        \ infrastructure in a protective and easily inspected pathway;\nare clearly\
        \ labelled at the equipment end with the wall outlet designator; and\nare\
        \ approved by the Accreditation Authority.\n\n\n\_"
      implementation_groups:
      - Confidential - SHOULD
      - Top Secret - SHOULD
      - Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Earthing and Bonding
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:7
      ref_id: 10.6.28.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:7
      ref_id: 10.6.28.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 5621]'
      description: All earthing points MUST be equipotentially bonded.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.28.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:7
      ref_id: 10.6.28.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 5623]'
      description: All conductive elements of a cabinet, rack or case housing any
        equipment MUST be earth bonded.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Cable Management
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:8
      ref_id: 10.6.29.R.01
      description: Good cable management facilitates maintenance, promotes air flow
        and cooling, reduces risk of accidental cross-connects or disconnects and
        supports safe operation.
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:8
      ref_id: 10.6.29.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 5626]'
      description: 'Cabinet rails MUST be installed to:

        provide adequate room for patch cables and wire managers;

        provide adequate space for cable management at front, sides, and rear; and

        arrange switches and patch panels to minimize patching between cabinets &
        racks.

        '
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Labelling Cables
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:9
      ref_id: 10.6.30.R.01
      description: '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;
        and

        Labelling is all-encompassing and include cables, connecting hardware, conduits,
        firestops, grounding and bonding locations, racks, cabinets, ports, and telecommunications
        spaces.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:9
      ref_id: 10.6.30.R.02
      description: '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; and

        All labels match with the any installation and maintenance records.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:9
      ref_id: 10.6.30.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Should [CID: 5627]'
      description: Agencies SHOULD implement the principles and specific cable labelling
        requirements described above.
      implementation_groups:
      - Top Secret - SHOULD
      - Confidential - SHOULD
      - Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.6:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4
      description: Power Cords
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:10
      ref_id: 10.6.31.R.01
      description: "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:\nLabel power cords\
        \ at both ends to minimise the risk inadvertently disconnecting the wrong\
        \ power cord;\nColour code power cords and power strips;\nUse locking power\
        \ cords, receptacles, or retention clips.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.6.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.6:4:10
      ref_id: 10.6.31.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Should [CID: 5619]'
      description: Agencies SHOULD follow best practice described above for the installation
        of power cables.
      implementation_groups:
      - Confidential - SHOULD
      - Secret - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.7'
      name: Emanation Security Threat Assessments
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:1
      ref_id: 10.7.1
      description: In order to minimise compromising emanations or the opportunity
        for a technical attack, a threat assessment is used to determine appropriate
        countermeasures.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:2:1
      ref_id: 10.7.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:2:1
      ref_id: 10.7.3
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:3
      ref_id: 10.7.4
      description: "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:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\
        \nNZCSS 400\_\n\n\nInstallation Engineering\n\nGCSB\n\nCONFIDENTIAL document\
        \ available on application to authorised personnel\n\n\n\n\nNZCSI 403B\_\n\
        \n\nTEMPEST Threat and Countermeasures Assessment\n\nGCSB\n\nCONFIDENTIAL\
        \ document available on application to authorised personnel\n\n\n\n\nNZCSI\
        \ 420\n\n\nLaboratory Tempest Test Standard for Equipment in Controlled Environments\n\
        \nGCSB\n\nCONFIDENTIAL document available on application to authorised personnel\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:4
      ref_id: 10.7.5
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nINFOSEC1, INFOSEC2, INFOSEC3,\
        \ INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols\n\
        \nManagement protocol for information security\nManagement protocol for physical\
        \ security\n\n\nManagement protocol for information security | Protective\
        \ Security Requirements\n\_\nManagement protocol for physical security | Protective\
        \ Security Requirements\n\n\n\nPSR requirements sections\n\nSecurity zones\n\
        Validate your security measures\nUse multiple layers of security - 'defence\
        \ in depth'\n\nPhysical security zones | Protective Security Requirements\n\
        \_\nUnderstanding the information security lifecycle | Protective Security\
        \ Requirements\n\n\n\nManaging specific scenarios\n\nManaging specific scenarios\
        \ | Protective Security Requirements\n\n\nPhysical security for ICT systems\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5
      description: Emanation security threat assessments within New Zealand
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:1
      ref_id: 10.7.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:1
      ref_id: 10.7.6.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:1
      ref_id: 10.7.6.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2454]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:1
      ref_id: 10.7.6.C.02
      name: 'Control -  All Classifications - Must [CID: 2455]'
      description: "Agencies designing and installing systems with RF transmitters\
        \ that co-locate with systems of a classification CONFIDENTIAL and above MUST:\n\
        contact GCSB for guidance on conducting an emanation security threat assessment;\
        \ and\ninstall cabling and equipment in accordance with this manual plus any\
        \ specific installation criteria derived from the emanation security threat\
        \ assessment.\n\_"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5
      description: Emanation security threat assessment outside New Zealand
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:2
      ref_id: 10.7.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:2
      ref_id: 10.7.7.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2458]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:2
      ref_id: 10.7.7.C.02
      name: 'Control -  All Classifications - Should [CID: 2459]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5
      description: Early identification of emanation security issues
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:3
      ref_id: 10.7.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:3
      ref_id: 10.7.8.C.01
      name: 'Control -  All Classifications - Should [CID: 2463]'
      description: Agencies SHOULD conduct an emanation security threat assessment
        as early as possible in project lifecycles.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:10.7:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5
      description: IT equipment in SECURE areas
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:4
      ref_id: 10.7.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.7.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.7:5:4
      ref_id: 10.7.9.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2465]'
      description: "Agencies MUST ensure that IT equipment within secure areas meet\
        \ industry and government standards relating to electromagnetic interference/electromagnetic\
        \ compatibility.\_"
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:10
      ref_id: '10.8'
      name: Network Design, Architecture and IP Address Management
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:1
      ref_id: 10.8.1
      description: IP Address architecture, allocation and addressing schemes enable
        and support system security and data protection.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:1
      ref_id: 10.8.2
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:2
      ref_id: 10.8.3
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:2
      ref_id: 10.8.4
      description: "A large network is also more difficult to monitor and control.\
        \ \_Segmenting the network limits an attacker\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:2
      ref_id: 10.8.5
      description: "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 \u2013 Cloud Computing and Section 22.2 \u2013\
        \ Virtualisation."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2
      description: Separation and Segregation
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:3
      ref_id: 10.8.6
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:3
      ref_id: 10.8.7
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:3
      ref_id: 10.8.8
      description: "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:\n\
        Enhanced performance: with fewer hosts per subnet, there is a reduced signalling\
        \ and traffic overhead allowing more bandwidth for data communication.\nImproved\
        \ 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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:3
      ref_id: 10.8.9
      description: "Effective segregation also requires:\nSpecialised 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.\nAdministrative 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.\nInfrastructure 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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2
      description: ISO 27001 and ISO 27002 implementation recommendations for network
        segregation
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:4
      ref_id: 10.8.10
      description: "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:\nDivide large networks into separate network domains\
        \ (segments);\nConsider physical and logical segregation;\nDefine domain perimeters;\n\
        Define traffic rules between domains;\nUse authentication, encryption, and\
        \ user-level network access control technologies;\nConsider integration of\
        \ the organisation\u2019s network and segments with those of business partners.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:2:4
      ref_id: 10.8.11
      description: "The following structures and techniques should be considered:\n\
        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).\nUse 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\u2019s 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).\nAccess 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 \u2013 Gateway Security.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8
      name: Network Design
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      ref_id: 10.8.12
      description: "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:\nFailure 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\
        \ de\uFB01ned, failure in one network area can have a far-reaching effect.\n\
        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 de\uFB01ning boundaries, broadcast\
        \ domains should have clear boundaries and include an optimal number of devices\
        \ to minimise the negative impact of broadcasts.\nMAC unicast \uFB02ooding:\
        \ Some switches limit unicast frame forwarding to ports that are associated\
        \ with the speci\uFB01c unicast address. \_However, when frames arrive at\
        \ a destination MAC address that is not recorded in the MAC table, they are\
        \ \uFB02ooded out of the switch ports in the same VLAN except for the port\
        \ that received the frame. \_This behaviour is called unknown MAC unicast\
        \ \uFB02ooding.\nBecause this type of \uFB02ooding causes excessive traf\uFB01\
        c 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.\n\
        Multicast traf\uFB01c on ports where it is not intended: IP multicast is a\
        \ technique that allows IP traf\uFB01c to be propagated from one source to\
        \ a multicast group that is identi\uFB01ed by a single IP and MAC destination-group\
        \ address pair. \_Similar to unicast \uFB02ooding and broadcasting, multicast\
        \ frames are \uFB02ooded out all the switch ports. A robust design allows\
        \ for the containment of multicast frames while allowing them to be functional.\n\
        Dif\uFB01culty in management and support: Traf\uFB01c \uFB02ows 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.\nPossible 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.\nCriteria-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).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Design Implementation
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:1
      ref_id: 10.8.13
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Classification
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:2
      ref_id: 10.8.14
      description: "Classified systems should, by definition, be segregated. \_This\
        \ is particularly important where network elements have access to compartments\
        \ and compartmented data."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:2
      ref_id: 10.8.15
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Security Zones
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:3
      ref_id: 10.8.16
      description: "A security zone is a group of one or more physical or virtual\
        \ firewall interfaces and the network segments connected to the zone\u2019\
        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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: IP Address Management
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:4
      ref_id: 10.8.17
      description: "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\u2019s 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:\nDefined network perimeters and boundaries;\
        \ and\nDefined network traffic rules.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:4
      ref_id: 10.8.18
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Address Block Allocation
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:5
      ref_id: 10.8.19
      description: "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 \u201C\
        borrow\u201D from a pre-assigned address range, the addressing scheme is also\
        \ compromised."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:5
      ref_id: 10.8.20
      description: "Internal IP address ranges are defined by the IETF. \_Commonly\
        \ known as RFC 1918 addresses, the most recent RFC is 6761. \_These RFC\u2019\
        s define private IP address ranges which cannot be used for external (Internet)\
        \ IP addressing. \_Three address ranges (blocks) are defined:\n\n\n\nIPv4\
        \ Address Range\nNetwork IPv4 address Block\nDirected Broadcast IPv4 address\n\
        IPv4 Addresses\n\n\n10.0.0.0 to 10.255.255.255\n10.0.0.0/8\n10.255.255.255\n\
        16,777,216\n\n\n172.16.0.0 to 172.31.255.255\n172.16.0.0/12\n172.31.255.255\n\
        1,048,576\n\n\n192.168.0.0 to 192.168.255.255\n192.168.0.0/16\n192.168.255.255\n\
        65,536\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:5
      ref_id: 10.8.21
      description: "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"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:5
      ref_id: 10.8.22
      description: Private addressing is a means of distinguishing networks, assisting
        in separation and segregation.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Private use of reserved addresses
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:6
      ref_id: 10.8.23
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Devices which have default IP addresses
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:7
      ref_id: 10.8.24
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:7
      ref_id: 10.8.25
      description: It is important to change default addresses to new addresses that
        conform with the addressing scheme selected for the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: DHCP
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:8
      ref_id: 10.8.26
      description: "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:\nDCHP Server;\nGateway devices;\n\
        Firewalls;\nRouters; and\nSwitches.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:8
      ref_id: 10.8.27
      description: The majority of other devices can be allocated a DHCP address.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:8
      ref_id: 10.8.28
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Connector Types and Cable Colours
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:9
      ref_id: 10.8.29
      description: "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)"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:9
      ref_id: 10.8.30
      description: "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)."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3
      description: Central Information Repository
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:10
      ref_id: 10.8.31
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:3:10
      ref_id: 10.8.32
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.33
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:4
      ref_id: 10.8.33
      description: "Further references can be found at:\n\n\n\nReference\_\nTitle\n\
        Publisher\nSource\n\n\n\_\nNetwork Segmentation and Segregation\nASD\nImplementing\
        \ Network Segmentation and Segregation | Cyber.gov.au\n\n\n\_\nCisco on Cisco\
        \ Best Practices \u2013 Cisco IP Addressing Policy\nCisco\nCisco IT IP Addressing\
        \ Best Practices\n\n\n\_\nIP Addressing and Subnetting for New Users, Document\
        \ ID: 13788\nCisco\nConfigure IP Addresses and Unique Subnets for New Users\
        \ (cisco.com)\n\n\n\_\nIP Addressing: IPv4 Addressing Configuration Guide,\
        \ Cisco IOS Release 15S\nCisco\nIP Addressing: IPv4 Addressing Configuration\
        \ Guide, Cisco IOS Release 15S - Cisco\n\n\n\_\nIntroduction to Server and\
        \ Domain Isolation\nMicrosoft\nIntroduction to Server and Domain Isolation\
        \ | Microsoft Learn\n\n\nISO/IEC 27001:2013\_\nInformation technology -- Security\
        \ techniques -- Information security management systems -- Requirements\n\
        ISO\nhttps://www.iso.org/standard/54534.html\n\n\nISO/IEC 27002:2022\n\nInformation\
        \ security, cybersecurity and privacy protection \u2014 Information security\
        \ controls\n\nISO\nhttps://www.iso.org/standard/75652.html\n\n\nRFC 1518\n\
        An Architecture for IP Address Allocation with CIDR\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc1518\n\
        \n\nRFC 1918\nAddress Allocation for Private Internets\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc1918\n\
        \n\nRFC 2036\nObservations on the use of Components of the Class A Address\
        \ Space within the Internet\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2036\n\
        \n\nRFC 2050\nInternet Registry IP Allocation Guidelines\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2050\n\
        \n\nRFC 2101\nIPv4 Address Behaviour Today\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2101\n\
        \n\nRFC 2401\nSecurity Architecture for the Internet Protocol\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2401\n\
        \n\nRFC 2663\nIP Network Address Translator (NAT) Terminology and Considerations\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc2663\n\n\nRFC 2894\nRouter\
        \ Renumbering for IPv6\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2894\n\
        \n\nRFC 3022\nTraditional IP Network Address Translator (Traditional NAT)\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc3022\n\n\nRFC 3053\nIPv6 Tunnel\
        \ Broker\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3053\n\n\nRFC 3056\n\
        Connection of IPv6 Domains via IPv4 Clouds\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3056\n\
        \n\nRFC 3232\nAssigned Numbers\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3232\n\
        \n\nRFC 3260\nNew Terminology and Clarifications for Diffserv\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3260\n\
        \n\nRFC 3330\_\nSpecial-Use IPv4 Addresses\" (superseded)\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3330\n\
        \n\nRFC 3879\_\nDeprecating Site Local Addresses\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3879\n\
        \n\nRFC 3927\nDynamic Configuration of IPv4 Link-Local Addresses\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3927\n\
        \n\nRFC 3956\nEmbedding the Rendezvous Point (RP) Address in an IPv6 Multicast\
        \ Address\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3956\n\n\nRFC 4193\n\
        Unique Local IPv6 Unicast Addresses\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc4193\n\
        \n\nRFC 4632\nClassless Inter-domain Routing (CIDR): The Internet Address\
        \ Assignment and Aggregation Plan\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc4632\n\
        \n\nRFC 5214\_\nIntra-Site Automatic Tunnel Addressing Protocol (ISATAP)\_\
        \nIETF\nhttps://datatracker.ietf.org/doc/html/rfc5214\n\n\nRFC 5737\_\nIPv4\
        \ Address Blocks Reserved for Documentation\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc5737\n\
        \n\nRFC 6040\nTunnelling of Explicit Congestion Notification\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6040\n\
        \n\nRFC 6052\nIPv6 Addressing of IPv4/IPv6 Translators\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6052\n\
        \n\nRFC 6081\_\nTeredo Extensions\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6081\n\
        \n\nRFC 6434\_\nIPv6 Node Requirements\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6434\n\
        \n\nRFC 6598\_\nReserved IPv4 Prefix for Shared Address Space\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6598\n\
        \n\nRFC 6761\_\nSpecial-Use Domain Names\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6761\n\
        \n\nRFC 6890\_\nSpecial-Purpose IP Address Registries\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6890\n\
        \n\nRFC 7371\nUpdates to the IPv6 Multicast Addressing Architecture\_\nIETF\n\
        https://datatracker.ietf.org/doc/html/rfc7371\n\n\nRFC 7619\_\nThe NULL Authentication\
        \ Methodin the Internet Key Exchange Protocol Version 2 (IKEv2)\_\nIETF\n\
        https://datatracker.ietf.org/doc/html/rfc7619\n\n\nRFC 8012\_\nLabel Switched\
        \ Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy\
        \ Labels (ELs)\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc8012\n\n\n\
        RFC 8190\nUpdates to the Special-Purpose IP Address Registries\_\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc8190\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:1
      ref_id: 10.8.34.R.01
      description: "A risk assessment is a fundamental tool in the architecture and\
        \ design of a network.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:1
      ref_id: 10.8.34.C.01
      name: 'Control -  All Classifications - Must [CID: 5815]'
      description: Agencies MUST conduct and document a risk assessment before creating
        an architecture, and designing an agency network.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.34.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:1
      ref_id: 10.8.34.C.02
      name: 'Control -  All Classifications - Must [CID: 5816]'
      description: The principles of separation and segregation as well as the system
        classification MUST be incorporated into the risk assessment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      description: Security Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.35.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:2
      ref_id: 10.8.35.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.35.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:2
      ref_id: 10.8.35.C.01
      name: 'Control -  All Classifications - Must [CID: 5820]'
      description: Security architectures MUST apply the principles of separation
        and segregation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      description: Identification of major classifications/categories of network segments
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:3
      ref_id: 10.8.36.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.36.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:3
      ref_id: 10.8.36.R.02
      description: "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 - Cable Management fundamentals."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:3
      ref_id: 10.8.36.C.01
      name: 'Control -  All Classifications - Must [CID: 5825]'
      description: The classification and other restrictions on the security and control
        of information MUST be clearly identified for each part of the Agency network.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      description: Visibility
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:4
      ref_id: 10.8.37.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.37.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:4
      ref_id: 10.8.37.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:4
      ref_id: 10.8.37.C.01
      name: 'Control -  All Classifications - Must [CID: 5843]'
      description: Systems of different classifications MUST be visually distinct.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:10.8:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5
      description: Information Repository
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.38.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:5
      ref_id: 10.8.38.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.38.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:5
      ref_id: 10.8.38.R.02
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.38.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:5
      ref_id: 10.8.38.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:10.8.38.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:10.8:5:5
      ref_id: 10.8.38.C.01
      name: 'Control -  All Classifications - Should [CID: 5831]'
      description: An information repository, containing essential network information,
        change records and business requirements SHOULD be established and maintained.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11
      assessable: false
      depth: 1
      ref_id: '11'
      name: Communications Systems and Devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.1'
      name: Bluetooth Communications
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:1
      ref_id: 11.1.1
      description: Bluetooth is used securely and Bluetooth communications are protected.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:2
      ref_id: 11.1.2
      description: Bluetooth radios are commonly found in end user devices, including
        laptops, mobile phones, and peripherals such as speakers, headphones, keyboards,
        and mice. More recently Bluetooth has been integrated into medical devices
        and personal devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:2
      ref_id: 11.1.3
      description: "It is important to be aware of all risks associated with Bluetooth\
        \ technology. The specific threats to Bluetooth communications, that the controls\
        \ in this section address, relate to are:\n\neavesdropping on the Bluetooth\
        \ communications between paired devices, and\_\nconnection interception attacks\
        \ that leverage the network communications channel (including during establishment)\
        \ of Bluetooth devices.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: Background
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.4
      description: "The Bluetooth specification has evolved over time and is regularly\
        \ updated. Version 4.0 of the specification introduced Bluetooth Low Energy\
        \ (LE) which offers a different feature set than the original Bluetooth Basic\
        \ Rate/Enhanced Data Rate (BR/EDR) standard. Version 4.1 and 4.2 of the specification\
        \ introduced enhanced security features for Bluetooth BR/EDR and LE respectively.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.5
      description: "Determining the security level being provided depends on several\
        \ factors, including the capabilities and Bluetooth version supported by the\
        \ devices being paired together. The actual security provided between devices\
        \ is a combination of:\na. \_ \_ \_the version of the Bluetooth specification\
        \ supported by each device,\nb. \_ \_ the capabilities of the devices to accept\
        \ user input (eg, through a keyboard, or camera) and to display output (eg,\
        \ through a screen or character display), and\nc. \_ \_ \_whether the devices\
        \ are using Bluetooth BR/EDR or Bluetooth LE."
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.6
      description: "The following table summarises the security protections expected\
        \ based on the pairing Bluetooth device capabilities where devices are Bluetooth\
        \ BR/EDR using Secure Connections (version 4.1 or later) or Bluetooth LE using\
        \ Secure Connections (version 4.2 or later) \u2013 refer to NIST SP 800-121\
        \ REV.2 Guide to Bluetooth.\n\n\n\nDisplay or input capabilities of the devices\n\
        Association mode used\nProtected against connection interception\nProtected\
        \ against eavesdropping\n\n\nBoth devices can display and accept input\nNumeric\
        \ Comparison\nYes\nYes\n\n\nOne device has input, one has display\nPasskey\
        \ Entry\nYes\nYes\n\n\nAt least one device has no display or input\nJust Works\n\
        No\nYes\n\n\nExternal channel for matching devices (eg, QR codes or NFC)\n\
        Out of Band\nYes\nYes\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.7
      description: Particular care is required when associating Bluetooth devices
        using the Just Works association mode (eg, with headsets) due to the risk
        of the pairing connection being intercepted, and encryption keys being discovered.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.8
      description: Since Bluetooth LE v4.2, released in 2014, versions of the Bluetooth
        protocol have included more advanced security features including authentication,
        authorisation, and encryption through the Secure Connections functionality.
        Encryption protocols are used to protect data from interception and authentication
        protocols ensure that only authorised devices can connect.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.9
      description: "The table below displays the key differences between Bluetooth\
        \ Basic Rate/Enhanced Data Rate (BR/EDR) and Bluetooth Low Energy (LE).\n\n\
        \n\n\nCharacteristic\n\n\nBluetooth BR/EDR\n\n\nBluetooth Low Energy\n\n\n\
        \n\nPrior to 4.1\n\n\n4.1 onwards\n\n\nPrior to 4.2\n\n\n4.2 onwards\n\n\n\
        \n\nRF Physical Channels\n\n\n79 channels with 1 MHz channel spacing\n\n\n\
        40 channels with 2 MHz channel spacing\n\n\n\n\nDiscovery / Connect\n\n\n\
        Inquiry / Paging\n\n\nAdvertising\n\n\n\n\nNumber of Piconet Slaves\n\n\n\
        7 (active) / 3255 (total)\n\n\nUnlimited\n\n\n\n\nDevice Address Privacy\n\
        \n\nNone\n\n\nPrivate device addressing available\n\n\n\n\nMax Data Rate\n\
        \n\n1-3 Mbps\n\n\n1 Mbps via GFSK modulation\n\n\n\n\nPairing Algorithm\n\n\
        \nPrior to 2.1:\nE21/E22/SAFER+\n\n\nP-256 Elliptic Curve, HMAC-SHA-256\n\n\
        \nAES-128\n\n\nP-256 Elliptic Curve, AES-CMAC\n\n\n\n\n2.1-4.0:P-192\nElliptic\
        \ Curve9\nHMAC-SHA-256\n\n\n\n\nDevice Authentication Algorithm\n\n\nE1/SAFER\n\
        \n\nHMAC-SHA-256\n\n\nAES-CCM10\n\n\n\n\nEncryption Algorithm\n\n\nE0/SAFER+\n\
        \n\nAES-CCM\n\n\nAES-CCM\n\n\n\n\nTypical Range\n\n\n30m\n\n\n50m\n\n\n\n\n\
        Max Output Power\n\n\n100mW (20 dBm)\n\n\n10mW (10 dBm)11\n\n\n\n\nReference:\
        \ NIST SP 800-121 REV.2 Guide to Bluetooth Table2-2\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:3
      ref_id: 11.1.10
      description: 5.x Bluetooth versions have introduced faster data transfers, larger
        data capacity, greater range and optimised power consumption.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: Threats
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:4
      description: General wireless networking threats
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:4:1
      ref_id: 11.1.11
      description: "Bluetooth is susceptible to general wireless networking threats\
        \ such as:\n\ndenial-of-service (DoS) attacks: is a malicious attempt to overwhelm\
        \ an online service or network and render it unusable\neavesdropping; occurs\
        \ when a hacker intercepts, deletes, or modifies data that is transmitted\
        \ between two devices.\nadversary in the middle attacks: a threat actor puts\
        \ themselves in the middle of two parties to intercept data & use it for malicious\
        \ purposes\nmessage modification: an intruder alters packet header addresses\
        \ to direct a message to a different destination or to modify the data on\
        \ a target machine.\_\nresource misappropriation: is an attack in which the\
        \ attacker steals or makes unauthorised use of a service.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:4
      description: Bluetooth specific threats
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:4:2
      ref_id: 11.1.12
      description: "Connection Interception Attacks\nBluetooth connections can be\
        \ intercepted by a hacker who poses as a legitimate device to gain access\
        \ to sensitive information.\_\n\nBluesnarfing: \_is a hacking technique in\
        \ which a hacker accesses a wireless device through a Bluetooth connection.\
        \ It happens without the device user's permission and often results in the\
        \ theft of information or some other kind of damage to the device (and user).\n\
        Bluebugging: is a hacking technique that lets someone get into your device\
        \ through your discoverable Bluetooth connection.\nBluejacking: is a Bluetooth\
        \ attack in which a hacker spams your device with unsolicited phishing messages.\n\
        Car Whisperer: \_is a hacking technique that can be used by attackers to hack\
        \ a hands-free Bluetooth in-car system.\nFuzzing Attacks: consist of sending\
        \ malformed or otherwise non-standard data to a device's Bluetooth radio and\
        \ observing how the device reacts.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:4:2
      ref_id: 11.1.13
      description: 'Eavesdropping attacks

        When eavesdropping takes place on the Bluetooth communications between paired
        devices


        Pairing Eavesdropping: is an attack where Bluetooth devices are forced to
        re-pair in the open and this allow the pairing process to be eavesdropped.

        Secure Simple Pairing Attacks: During the Bluetooth pairing process, an attacker
        with physical proximity can gain unauthorised access via an adjacent network,
        and intercept traffic and send forged pairing messages between two vulnerable
        Bluetooth devices.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:5
      ref_id: 11.1.14
      description: "References are available at the following source:\n\n\n\nReference\n\
        Publisher\nTitle\n\n\n\nNIST 800-121, Rev.2, May 2017 \n(INCLUDES UPDATES\
        \ AS OF 1-19-2022) \n\nNIST\nGuide to Bluetooth Security (nist.gov)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      description: Bluetooth within agency environments
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.R.01
      description: "Bluetooth provides a convenient method of wirelessly connecting\
        \ devices and includes support for a wide variety of usage scenarios.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.R.02
      description: Bluetooth is commonly found in low powered consumer devices, medical
        devices, and peripherals. Bluetooth operates in the same 2.4GHz wireless band
        as other non-licenced spectrum services such as Wi-Fi.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.R.03
      description: "Bluetooth is generally suitable for connectivity between devices\
        \ in lower classification settings, and where adequate consideration is given\
        \ to the purpose of the connection, the type of information being transmitted,\
        \ the security capabilities of the devices, and the environment the devices\
        \ are operating in.\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.R.04
      description: Given the large number of potential situations Bluetooth could
        be used in, it is essential that agencies develop a considered position on
        where and where not to permit the use of Bluetooth connections.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.C.01
      name: 'Control -  All Classifications - Must [CID: 7524]'
      description: Agencies wishing to permit the use of Bluetooth MUST develop a
        policy that details the circumstances under which Bluetooth usage is permitted,
        and situations where it is not to be used.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:1
      ref_id: 11.1.15.C.02
      name: 'Control -  All Classifications - Must [CID: 7525]'
      description: The policy position MUST include information about Bluetooth security
        controls that are to be used, and methods for verifying that the controls
        are in place and are effective.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      description: Bluetooth connections
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.R.01
      description: Bluetooth connections between devices of different security protocol
        levels will result in a degradation of the security level.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.R.02
      description: Bluetooth connections between devices that can revert to weaker
        protocol options, and that do not support effective security features will
        increase risk of compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.C.01
      name: 'Control -  All Classifications - Must [CID: 7526]'
      description: Agencies MUST ensure that Bluetooth pairing is only established
        between authorised devices. (Unless a gateway is being used, paired devices
        are considered to operate at the same security classification level).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.C.02
      name: 'Control -  All Classifications - Should [CID: 7527]'
      description: Agencies SHOULD ensure that Bluetooth discovery of devices is disabled
        unless a new pairing connection is being established.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.C.03
      name: 'Control -  All Classifications - Should [CID: 7528]'
      description: Agencies SHOULD ensure that Bluetooth device pairing only occurs
        at a location where only authorised persons have access.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.16.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:2
      ref_id: 11.1.16.C.04
      name: 'Control -  All Classifications - Should [CID: 7529]'
      description: Agencies SHOULD ensure that Bluetooth pairings are removed when
        they are no longer required.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      description: Bluetooth versions
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      ref_id: 11.1.17.R.01
      description: "It is difficult to determine what Bluetooth security features\
        \ are being used for a connection between devices without capturing and decoding\
        \ the connection establishment packets.\_\nSince Bluetooth LE v4.2, versions\
        \ of the Bluetooth protocol have included more advanced security features\
        \ including authentication, authorisation, and encryption through the Secure\
        \ Connections functionality."
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.17.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      ref_id: 11.1.17.R.02
      description: Ensuring some end-user visible features are being used during the
        device pairing process can provide a level of understanding of the security
        between Bluetooth connected devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      ref_id: 11.1.17.C.01
      name: 'Control -  All Classifications - Must [CID: 7530]'
      description: Agencies using Bluetooth MUST use the most secure configuration
        supported by the paired devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.17.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      ref_id: 11.1.17.C.02
      name: 'Control -  All Classifications - Should [CID: 7531]'
      description: "Agencies SHOULD identify the:\n\nBluetooth type (BR/EDR or LE),\_\
        \nversion, and\nsecurity capabilities;\n\nfor devices used to form Bluetooth\
        \ connections, and ensure they are used to inform risk decisions on the use\
        \ of Bluetooth."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.17.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:3
      ref_id: 11.1.17.C.03
      name: 'Control -  All Classifications - Should [CID: 7532]'
      description: Agencies SHOULD ensure that new Bluetooth connections between devices
        are authenticated using explicit user actions, such as entry of a numeric
        code, confirmation of a matching PIN, or other affirming action, such as challenge-response
        process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      description: Encryption and authentication protocols
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      ref_id: 11.1.18.R.01
      description: When transferring information between Bluetooth devices, encryption
        protocols are used to protect data from interception and authentication protocols
        ensure that only authorised devices can connect.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.18.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      ref_id: 11.1.18.R.02
      description: Chapter 17 of the NZISM provides approved encryption algorithms.
        Even in the most secure operating model, Bluetooth specifications are currently
        unable to support these approved encryption methods. Whilst Bluetooth cannot
        meet these requirements, there may be organisational requirements to use Bluetooth
        to transfer Restricted or Sensitive information between devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      ref_id: 11.1.18.C.01
      name: 'Control -  Unclassified/In-Confidence - Should [CID: 7533]'
      description: "Agencies using Bluetooth between devices to transfer UNCLASSIFIED\
        \ or IN-CONFIDENCE information SHOULD ensure that connections meet NZISM standards\
        \ for authentication and use Approved Cryptographic Algorithms for encryption\
        \ and message integrity.\_"
      implementation_groups:
      - Unclassified/In-Confidence - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      ref_id: 11.1.18.C.02
      name: 'Control -  Restricted/Sensitive - Must [CID: 7534]'
      description: Agencies using Bluetooth between devices to transfer RESTRICTED
        or SENSITIVE information MUST ensure that connections meet NZISM standards
        for authentication and use Approved Cryptographic Algorithms for encryption
        and message integrity.
      implementation_groups:
      - Restricted/Sensitive - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.18.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:4
      ref_id: 11.1.18.C.03
      name: 'Control -  Restricted/Sensitive - Must [CID: 7535]'
      description: If Bluetooth specifications do not support these approved encryption
        methods, organisations MUST do a risk assessment and use the exception or
        waiver process to accept this risk.
      implementation_groups:
      - Restricted/Sensitive - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6
      description: Bluetooth in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      ref_id: 11.1.19.R.01
      description: "As with other wireless protocols, the level of security offered\
        \ by Bluetooth can vary widely depending on the capabilities of the devices\
        \ being connected.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.19.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      ref_id: 11.1.19.R.02
      description: Bluetooth devices will revert to older, less secure versions of
        the protocol to maintain compatibility, so careful consideration needs to
        be undertaken before approving the use of the Bluetooth protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      ref_id: 11.1.19.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 2492]'
      description: Agencies MUST complete a technical evaluation of the secure area,
        consult the relevant technical authority and seek approval from the Accreditation
        Authority before permitting the use of Bluetooth devices.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      ref_id: 11.1.19.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 2494]'
      description: 'Agencies using Bluetooth devices MUST NOT allow:


        line of sight and reflected communications travelling into an unsecure area.

        multiple Bluetooth devices at different classifications in the same area.

        '
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.1.19.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.1:6:5
      ref_id: 11.1.19.C.03
      name: 'Control -  Top Secret, Confidential, Secret - Must Not [CID: 2495]'
      description: Agencies MUST NOT allow Bluetooth devices into secure areas unless
        authorised by the Accreditation Authority.
      implementation_groups:
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.2'
      name: Radio frequency and infrared devices in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:1
      ref_id: 11.2.1
      description: To maintain the integrity of secure areas, only approved radio
        frequency (RF) and infrared (IR) devices are brought into secure areas.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:1
      ref_id: 11.2.2
      description: 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 - Distributed working.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:1
      ref_id: 11.2.3
      description: RF devices include any transmitter on any frequency, including
        mobile phones, cordless phones, Bluetooth, Wi-Fi, RFID and other similar devices.Requirements
        for Bluetooth devices are described in section 11.1
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:1
      ref_id: 11.2.4
      description: IR devices transmit data over variable distances using light waves;
        examples are infrared cameras; night vision devices; infrared computer ports;
        and remote controls.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:1
      ref_id: 11.2.5
      description: "A secure area, in the context of the NZISM, 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 Sensitive Compartmented Information Facility (SCIF).\n\
        The physical security requirements for such areas are specified in the Protective\
        \ Security Requirements (PSR) Security Zones."
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2
      description: Exemptions for the use of RF devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:2
      ref_id: 11.2.6
      description: At the discretion of the Accreditation Authority, RF devices can
        be used in a secure area provided they cannot communicate or compromise classified
        information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2
      description: Exemptions for the use of Medical devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:3
      ref_id: 11.2.7
      description: At the discretion of the Accreditation Authority, medical devices
        with RF transmitters and/or receivers can be used in secure areas provided
        they cannot communicate or compromise classified information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2
      description: Exemptions for the use of IR and laser devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:2:4
      ref_id: 11.2.8
      description: At the discretion of the Accreditation Authority, IR and laser
        devices can be used in a secure area provided they cannot communicate or compromise
        classified information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:3
      ref_id: 11.2.9
      description: "References are available at the following source:\n\n\n\nReference\n\
        Publisher\nTitle\n\n\n\nNIST 800-121, Rev.2, May 2017\n(INCLUDES UPDATES AS\
        \ OF 1-19-2022) \n\nNIST\nGuide to Bluetooth Security (nist.gov)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:4
      ref_id: 11.2.10
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\nPSR Mandatory Requirements\nGOV2, INFOSEC1, INFOSEC2, INFOSEC3,\
        \ INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols\n\
        \nManagement protocol for information security\n\_\nManagement protocol for\
        \ physical security\n\n\nManagement protocol for information security | Protective\
        \ Security Requirements\n\_\nManagement protocol for physical security | Protective\
        \ Security Requirements\n\n\n\nPSR requirements sections\n\nSecurity zones\n\
        \n\nPhysical security zones | Protective Security Requirements\n\n\n\nManaging\
        \ specific scenarios\n\nManaging specific scenarios | Protective Security\
        \ Requirements\n\n\nMobile and remote working\nCommunication security\nPhysical\
        \ security for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      description: RF devices in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:1
      ref_id: 11.2.11.R.01
      description: "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 \u201Cair gaps\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:1
      ref_id: 11.2.11.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2497]'
      description: Agencies MUST prevent RF devices from being brought into secure
        areas unless authorised by the Accreditation Authority.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:1
      ref_id: 11.2.11.C.02
      name: 'Control -  All Classifications - Should [CID: 2498]'
      description: Agencies SHOULD prevent RF devices from being brought into secure
        areas unless authorised by the Accreditation Authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      description: RF controls in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:2
      ref_id: 11.2.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:2
      ref_id: 11.2.12.C.01
      name: 'Control -  All Classifications - Should [CID: 2504]'
      description: "Agencies SHOULD limit the effective range of communications outside\
        \ the agency\u2019s area of control by:\n\nminimising the output power level\
        \ of wireless devices;\_\nRF shielding; and\nPhysical layout and separation.\n\
        \n\_"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      description: Detecting RF devices in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:3
      ref_id: 11.2.13.R.01
      description: As RF devices are prohibited in secure areas, agencies should deploy
        technical measures to detect and respond to the unauthorised use of such devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:3
      ref_id: 11.2.13.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Should [CID: 2501]'
      description: Agencies SHOULD deploy measures to detect and respond to active
        RF devices within secure areas.
      implementation_groups:
      - Confidential - SHOULD
      - Secret - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      description: Pointing devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:4
      ref_id: 11.2.14.R.01
      description: "Wireless RF or IR pointing devices can pose an emanation security\
        \ risk as well as introduce vulnerabilities to classified IT equipment and/or\
        \ systems.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:4
      ref_id: 11.2.14.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must Not [CID: 2483]'
      description: "Wireless RF or IR pointing devices MUST NOT be used in secure\
        \ areas unless approved by the Accreditation Authority and appropriate RF\
        \ or IR mitigations are implemented.\_"
      implementation_groups:
      - Top Secret - MUST NOT
      - Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5
      description: IR devices in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      ref_id: 11.2.15.R.01
      description: When using IR devices with CONFIDENTIAL, SECRET or TOP SECRET systems,
        IR mitigations including opaque curtains and/or IR window films are acceptable.
        Line of sight must be managed for direct and reflected 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      ref_id: 11.2.15.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      ref_id: 11.2.15.C.01
      name: 'Control -  Secret, Confidential - Must Not [CID: 2487]'
      description: '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.

        '
      implementation_groups:
      - Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      ref_id: 11.2.15.C.02
      name: 'Control -  Top Secret - Must Not [CID: 2488]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.2.15.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.2:5:5
      ref_id: 11.2.15.C.03
      name: 'Control -  All Classifications - Should [CID: 2489]'
      description: Agencies using IR devices SHOULD ensure that the IR receiver/port
        is positioned to prevent line of sight from the secure area boundary.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.3'
      name: Telephones and Telephone Systems
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:1
      ref_id: 11.3.1
      description: Telephone systems are prevented from communicating unauthorised
        classified information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:2:1
      ref_id: 11.3.2
      description: This section covers information relating to the secure use of fixed,
        including cordless, telephones, as well as the systems they use to communicate
        information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:2:1
      ref_id: 11.3.3
      description: "Information regarding Voice over Internet Protocol (VoIP) and\
        \ encryption of data in transit is covered in Section 18.3 \u2013 Video &\
        \ Telephony Conferencing and Internet Protocol Telephony and Section 17.1\
        \ - Cryptographic Fundamentals."
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:2:1
      ref_id: 11.3.4
      description: It MUST be noted that VOIP and cellular phones have some of the
        same vulnerabilities as wired and cordless phones.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Telephones and telephone systems usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:1
      ref_id: 11.3.5.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:1
      ref_id: 11.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 2627]'
      description: Agencies MUST develop a policy governing the use of telephones
        and telephone systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Personnel awareness
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:2
      ref_id: 11.3.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:2
      ref_id: 11.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 2630]'
      description: Agencies MUST advise personnel of the maximum permitted classification
        for conversations using both internal and external telephone connections.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:2
      ref_id: 11.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 2631]'
      description: Agencies SHOULD advise personnel of the audio security risk posed
        by using telephones in areas where classified conversations can occur.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Visual indication
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:3
      ref_id: 11.3.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:3
      ref_id: 11.3.7.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2637]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Use of telephone systems
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:4
      ref_id: 11.3.8.R.01
      description: When classified conversations are to be held using telephone systems,
        the conversation needs to be appropriately protected through the use of encryption
        measures.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:4
      ref_id: 11.3.8.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2643]'
      description: '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.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Cordless telephones
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:5
      ref_id: 11.3.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:5
      ref_id: 11.3.9.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must Not [CID: 2648]'
      description: Agencies MUST NOT use cordless telephones for classified conversations.
      implementation_groups:
      - Top Secret - MUST NOT
      - Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:5
      ref_id: 11.3.9.C.02
      name: 'Control -  All Classifications - Should [CID: 2649]'
      description: Agencies SHOULD NOT use cordless telephones for classified or sensitive
        conversations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Cordless telephones with secure telephony devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:6
      ref_id: 11.3.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:6
      ref_id: 11.3.10.C.01
      name: 'Control -  All Classifications - Must Not [CID: 2652]'
      description: Agencies MUST NOT use cordless telephones in conjunction with secure
        telephony devices.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Speakerphones
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:7
      ref_id: 11.3.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:7
      ref_id: 11.3.11.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:7
      ref_id: 11.3.11.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2656]'
      description: "If a speakerphone is to be used on a secure telephone system within\
        \ a secure area, agencies MUST apply the following controls:\nit is located\
        \ in a room rated as audio secure;\nthe room is audio secure during any conversations;\_\
        \nonly cleared personnel involved in discussions are present in the room;\
        \ and\nensure approval for this exception is granted by the Accreditation\
        \ Authority.\n"
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Off-hook audio protection
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.R.01
      description: 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. This is normally
        achieved with push-to-talk (PTT) mechanisms.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.R.02
      description: 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. Where PTT or some other similar functionality is installed,
        the activation mechanism (such as a button or switch) must be clearly labelled.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.R.03
      description: Many new digital desk phones control these functions through software,
        rather than a mechanical switch.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 2661]'
      description: 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.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2662]'
      description: Agencies MUST use push-to-talk mechanisms to meet the requirement
        for off-hook audio protection. PTT activation MUST be clearly labelled.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:8
      ref_id: 11.3.12.C.03
      name: 'Control -  All Classifications - Should [CID: 2663]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.3:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3
      description: Electronic Records Retention and Voicemail
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:9
      ref_id: 11.3.13.R.01
      description: Voicemail and other messages and communications may fall within
        the legal definition of electronic records. If so retention and archive requirements
        are prescribed.
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:9
      ref_id: 11.3.13.C.01
      name: 'Control -  All Classifications - Must [CID: 2666]'
      description: Agencies MUST remove unused voice mailboxes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:9
      ref_id: 11.3.13.C.02
      name: 'Control -  All Classifications - Must [CID: 2667]'
      description: "Agencies MUST expire and archive or delete voicemail messages\
        \ after the retention period determined by the agency\u2019s electronic records\
        \ retention policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.3.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.3:3:9
      ref_id: 11.3.13.C.03
      name: 'Control -  All Classifications - Should [CID: 2669]'
      description: Agencies SHOULD develop and implement a policy to manage the retention
        and disposal of such electronic records, including voicemail, email and other
        electronic records.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.4'
      name: Mobile Telephony
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:1
      ref_id: 11.4.1
      description: Mobile telephone systems and devices are prevented from communicating
        unauthorised classified information.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.2
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.4
      description: "Mobile devices with cellular capability will regularly \u201C\
        poll\u201D for the strongest signal and base or relay station. Monitoring\
        \ such activity can be used for later interception of transmissions."
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.5
      description: "Information regarding Voice over Internet Protocol (VoIP) and\
        \ encryption of data in transit is covered in Section 18.3 \u2013 Video &\
        \ Telephony Conferencing and Internet Protocol Telephony and Section 17.1\
        \ - Cryptographic Fundamentals."
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.6
      description: It is important to note that VoIP phones have some of the same
        vulnerabilities as the mobile devices discussed in this section.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:2:1
      ref_id: 11.4.7
      description: 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/5g
        capability.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:3
      ref_id: 11.4.8
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\nPSR Mandatory Requirements\nGOV2, INFOSEC1, INFOSEC2, INFOSEC3,\
        \ INFOSEC4,\_ PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols\_\
        \n\nManagement protocol for information security\n\_\nManagement protocol\
        \ for physical security\n\n\nManagement protocol for information security\
        \ | Protective Security Requirements\n\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \nSecurity zones\n\n\nPhysical security zones | Protective Security Requirements\n\
        \n\n\nManaging specific scenarios\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nMobile and remote working\nCommunication security\n\
        Physical security for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4
      description: Mobile device usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:1
      ref_id: 11.4.9.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:1
      ref_id: 11.4.9.C.01
      name: 'Control -  All Classifications - Must [CID: 2691]'
      description: Agencies MUST develop a policy governing the use of mobile devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4
      description: Personnel awareness
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:2
      ref_id: 11.4.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:2
      ref_id: 11.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 2694]'
      description: Agencies MUST advise personnel of the maximum permitted classification
        for conversations using both internal and external mobile devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:2
      ref_id: 11.4.10.C.02
      name: 'Control -  All Classifications - Should [CID: 2695]'
      description: Agencies SHOULD advise personnel of all known security risks posed
        by using mobile devices in areas where classified conversations can occur.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4
      description: Use of mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:3
      ref_id: 11.4.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:3
      ref_id: 11.4.11.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 2698]'
      description: "Agencies intending to use mobile devices for the transmission\
        \ of classified information MUST ensure that:\nthe network has been certified\
        \ and accredited for the purpose;\_\nall classified traffic that passes over\
        \ mobile devices is appropriately encrypted; and\nusers are aware of the area,\
        \ surroundings, potential for overhearing and potential for oversight when\
        \ using the device.\n"
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.4:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4
      description: Mobile Device Physical Security
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:4
      ref_id: 11.4.12.R.01
      description: "Mobile devices are invariably software controlled and are subject\
        \ to malware or other means of compromise. No \u201Coff-hook\u201D or \u201C\
        power off\u201D security can be effectively provided, creating vulnerabilities\
        \ for secure areas. Secure areas are defined in Chapter 1 at 1.1.36."
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:4
      ref_id: 11.4.12.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2701]'
      description: Mobile devices MUST be prevented from entering secure areas.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.4.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.4:4:4
      ref_id: 11.4.12.C.02
      name: 'Control -  All Classifications - Should [CID: 2702]'
      description: Agencies SHOULD provide a storage area or lockers where mobile
        devices can be stored before personnel enter secure or protected areas.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.5'
      name: Personal Wearable Devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:1
      ref_id: 11.5.1
      description: "Wearable\_devices are prevented from unauthorised communication\
        \ or from compromising secure areas."
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.2
      description: This section covers information relating to the use of personal
        wearable devices, fitness devices, smart watches, devices embedding in clothing
        and similar wearable devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.3
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.4
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.5
      description: Such devices are also susceptible to Internet malware and exploits.
        All risks related to the use of the Internet will apply to these devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.6
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:1
      ref_id: 11.5.7
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2
      description: Key Risk Areas
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:2
      ref_id: 11.5.8
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:2
      ref_id: 11.5.9
      description: 'There are four important risk groups to be considered when managing
        personal wearable devices:


        Data leaks and breaches;

        Network security compromises;

        Personal information leaks; and

        Privacy violations.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2
      description: Personal Information
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:2:3
      ref_id: 11.5.10
      description: In most cases, the protection of personal information 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:3
      ref_id: 11.5.11
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\nPSR Mandatory Requirements\nGOV2, INFOSEC1, INFOSEC2, INFOSEC3,\
        \ INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols\n\
        \nManagement protocol for information security\n\_\nManagement protocol for\
        \ physical security\n\n\nManagement protocol for information security | Protective\
        \ Security Requirements\n\_\nManagement protocol for physical security | Protective\
        \ Security Requirements\n\n\n\nPSR requirements sections\n\nSecurity zones\n\
        \nPhysical security zones | Protective Security Requirements\n\n\nManaging\
        \ specific scenarios\n\nManaging specific scenarios | Protective Security\
        \ Requirements\n\n\nMobile and remote working\nCommunication security\nPhysical\
        \ security for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:4
      ref_id: 11.5.12
      description: "Further references can be found at:\n\n\nReference\_\nTitle\n\
        Publisher\nSource\n\n\n\nITL bulletin for April 2010\n\n\nGuide to protecting\
        \ personally identifiable information\n\nNIST\nhttps://csrc.nist.gov/csrc/media/publications/shared/documents/itl-bulletin/itlbul2010-04.pdf\
        \ [PDF, 50 KB]\n\n\n\nSP\_800-122\n\n\nGuide to Protecting the Confidentiality\
        \ of Personally Identifiable Information (PII) - Recommendations of the National\
        \ Institute of Standards and Technology\n\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf\
        \ [PDF, 800 KB]\n\n\n\_\nPrivacy Act 2020\_\nOffice of The Privacy Commissioner\_\
        \n\nhttps://privacy.org.nz/\nhttps://legislation.govt.nz/\n\n\n\n\_\nThe Health\
        \ Insurance Portability and Accountability Act of 1996 (USA)\n\nUS Congress\n\
        \n\nhttps://www.gpo.gov/fdsys/pkg/PLAW-104publ191/html/PLAW-104publ191.htm\n\
        https://www.hhs.gov/hipaa/index.html\n\n\n\n\_\nHealth Information Technology\
        \ for Economic and Clinical Health Act (HITECH Act) (USA)\n\nUS Congress\n\
        \n\nhttps://www.gpo.gov/fdsys/pkg/FR-2013-01-25/pdf/2013-01073.pdf [PDF, 881\
        \ KB]\nhttp://www.hhs.gov/hipaa/for-professionals/special-topics/HITECH-act-enforcement-interim-final-rule/index.html\_\
        \n\n\n\n\_\nTechnology, Media and Telecommunications Predictions, 2014\nDeloitte\n\
        https://www2.deloitte.com/content/dam/Deloitte/global/Documents/Technology-Media-Telecommunications/gx-tmt-predictions-2014-interactive.pdf\
        \ [PDF, 1.05 MB]\n\n\n\_\nTechnology, Media and Telecommunications Predictions,\
        \ 2015\nDeloitte\nhttps://www2.deloitte.com/au/en/pages/technology-media-and-telecommunications/articles/tmt-predictions.html\n\
        \n\n\_\nStudy: Wearable Technology & Preventative Healthcare\n\nTechnology\
        \ Advice Research\n\nhttp://technologyadvice.com/\n\n\n\_\nSecurity Analysis\
        \ of Wearable Fitness Devices (Fitbit)\n\nMassachusetts Institute of Technology\n\
        \nhttps://courses.csail.mit.edu/6.857/2014/files/17-cyrbritt-webbhorn-specter-dmiao-hacking-fitbit.pdf\
        \ [PDF, 630 KB]\n\n\n\_\nFit and Vulnerable: Attacks and Defenses for a Health\
        \ Monitoring Device\n\nSchool of Computing and Information Sciences, Florida\
        \ International University\n\nhttps://arxiv.org/pdf/1304.5672.pdf [PDF, 541\
        \ KB]\n\n\n\_\n\nSurvey of Security and Privacy Issues of Internet of Things\n\
        \n\_\n\_http://arxiv.org/ftp/arxiv/papers/1501/1501.02211.pdf [PDF, 548 KB]\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5
      description: Personal Wearable Device usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:1
      ref_id: 11.5.13.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:1
      ref_id: 11.5.13.C.01
      name: 'Control -  All Classifications - Must [CID: 2736]'
      description: Agencies MUST develop a policy governing the use of personal wearable
        devices, including fitness devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5
      description: Personnel awareness
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:2
      ref_id: 11.5.14.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:2
      ref_id: 11.5.14.C.01
      name: 'Control -  All Classifications - Must [CID: 2750]'
      description: Agencies MUST advise personnel of the maximum permitted classification
        for conversations where any personal wearable or mobile device may be present.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:2
      ref_id: 11.5.14.C.02
      name: 'Control -  All Classifications - Should [CID: 2752]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5
      description: Mobile Device Physical Security
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:3
      ref_id: 11.5.15.R.01
      description: "Personal wearable devices are invariably software controlled and\
        \ can be infected with malware or other means of compromise. No \u201Coff-hook\u201D\
        \ or \u201Cpower off\u201D security can be effectively provided, creating\
        \ vulnerabilities for secure areas. Secure areas are defined in Chapter 1\
        \ at 1.1.36."
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:3
      ref_id: 11.5.15.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 2758]'
      description: Personal wearable devices MUST NOT be allowed to enter secure areas.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:3
      ref_id: 11.5.15.C.02
      name: 'Control -  All Classifications - Should [CID: 2759]'
      description: Agencies SHOULD provide a storage area or lockers where personal
        wearable devices can be stored before personnel enter secure or protected
        areas.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5
      description: Medical Exemptions
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      ref_id: 11.5.16.R.01
      description: "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\u2019\
        s Accreditation Authority. Such devices MUST NOT have any of the following\
        \ capabilities:\nCamera;\nMicrophone;\nVoice/video/still photograph recording;\_\
        \nCellular, Wi-Fi or other RF.\nMerely disabling such capabilities is not\
        \ acceptable. The device MUST NOT have such capabilities installed. Permitted\
        \ device capabilities are:\nAccelerometer;\nAltimeter;\nGyroscope;\_\nHeart\
        \ Activity monitor;\nVibration feature for the personal notification purposes.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.16.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      ref_id: 11.5.16.R.02
      description: "Personal wearable devices may contain personal information of\
        \ the individual using the device.\_ This may be on the device itself in printed\
        \ or electronic form, and also in the registers of tested, permitted or rejected\
        \ devices in use within the agency.\_ It is important that relevant legislation\
        \ and regulation pertaining to the protection of personal information is followed."
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      ref_id: 11.5.16.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 2763]'
      description: 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.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      ref_id: 11.5.16.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 2765]'
      description: '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.

        '
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.5.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.5:5:4
      ref_id: 11.5.16.C.03
      name: 'Control -  All Classifications - Must [CID: 2767]'
      description: 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 personal
        information is followed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.6'
      name: Radio Frequency Identification Devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:1
      ref_id: 11.6.1
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      description: 'Scope '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:1
      ref_id: 11.6.2
      description: This section provides information relating to the risks, security
        and secure use of RFID devices. Card access control systems incorporating
        RFID or smart cards are discussed in more detail in Section 11.7 - Card Access
        Control Systems.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:2
      ref_id: 11.6.3
      description: This section contains a short description of the history, formats,
        operating frequencies, risks, controls and countermeasures related to the
        use of RFID.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:2
      ref_id: 11.6.4
      description: "In practical use since the 1970\u2019s, 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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:2
      ref_id: 11.6.5
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:2
      ref_id: 11.6.6
      description: "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.57."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      description: Basic Formats
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:3
      ref_id: 11.6.7
      description: 'The basic format of an Electronic Product Code (EPC) is illustrated
        below:

        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:3
      ref_id: 11.6.8
      description: "RFID devices are often referred to as \u201Ctags\u201D. 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:\na 96\
        \ bit EPC number with read/write capability and can be designated used for\
        \ other data ;\na 32/64 bit tag identifier (TID) \u2013 identifies the manufacturer\
        \ of the tag, also with read/write capabilities;\_\n32 bit kill password to\
        \ permanently disable the tag;\_\n32 bit access password to lock the read/write\
        \ characteristics of the tag and also set the tag for disabling ;\nUser memory\
        \ \u2013 dependant on the manufacturer and can be as little as 0 bits to 2048\
        \ bits. Larger user memory is in development.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:3
      ref_id: 11.6.9
      description: "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 \u201Cnoise\u201D\
        \ and the broadcast signal is sufficiently powerful."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:3
      ref_id: 11.6.10
      description: "RFID tags are divided into classes 0 to 5:\n\n\nClass\nDescription\n\
        \n\n0\nRead only, passive tags\n\n\n1\nWrite once passive tags. \_128-bit\
        \ memory.\n\n\n2\nRead/Write with up to 65Kb read/write memory and authenticated\
        \ access control. \_Can monitor temperature, pressure, vibration.\n\n\n3\n\
        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.\n\n\n4\nActive 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\u2019).\n\n\n5\nReader tags, can power\
        \ class 1 to 3 tags and communicate with all classes. \_Includes all the capabilities\
        \ of class 4 tags.\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      description: Operating Frequencies
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:4
      ref_id: 11.6.11
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:4
      ref_id: 11.6.12
      description: "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:\n\n\nBand\nFrequency\n\nTypical Range\n\n\n\n\
        LF\n125-134.2 kHz and 140-148.5 kHz\_\n\nUp to 1/2 metre\n\n\n\nHF\n\n13.553\
        \ - 13.567 MHz and 26.957 - 27.283 MHz\n\n\nUp to 1 metre\n\n\n\nUHF\n\n433\
        \ MHz, 858 - 930 MHz, 2.400 - 2.483 GHz, 2.446 - 2.454GHz\n\n\n1 to 10 metres\n\
        \n\n\nSHF\n\n5.725 - 5.875 GHz\n\n\n> 100 metres\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:4
      ref_id: 11.6.13
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2
      description: Smart Cards
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:5
      ref_id: 11.6.14
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:5
      ref_id: 11.6.15
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:5
      ref_id: 11.6.16
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:2:5
      ref_id: 11.6.17
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Threats and Vulnerabilities
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.18
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3
      ref_id: 11.6.18
      description: "Some important characteristics of RFID, inherent in the design\
        \ and properties of the technology are:\nRFID 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;\nRFID tags automatically\
        \ respond to reader interactions without explicit control of the tag owner,\
        \ so RFID tags can be operated without their owner\u2019s consent;\nIt 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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.19
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3
      ref_id: 11.6.19
      description: "Specific threats and vulnerabilities in the use of RFID technologies\
        \ include:\nLegitimate 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.\_\nEavesdropping 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.\nSkimming: 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.\nRelay 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.\n\
        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.\nTag 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.\nData 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.\nShipment 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.\nTag 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.\n\
        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.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3
      description: Attack Vectors
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3:1
      ref_id: 11.6.20
      description: "Attack vectors for RFID devices include:\ninterception of legitimate\
        \ transmissions;\ninterception of authorised reader data by an unauthorised\
        \ device;\nunauthorised access to tags and readers;\nrogue/cloned tags;\n\
        rogue and unauthorised RFID readers;\_\nside-channel attacks (timing measurements,\
        \ electromagnetic radiations etc.);\_\nattacks on back-end systems;\njamming\
        \ of legitimate signals.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3:1
      ref_id: 11.6.21
      description: "Because RFID devices incorporate antennas, there is a possibility\
        \ of radiation hazards from high \u2013powered 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)."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3:1
      ref_id: 11.6.22
      description: "Threats and Vulnerabilities of RFID systems are summarised in\
        \ the table below:\n\n\n\nThreat/Vulnerability\n\nTag\nRF\nReader\nNetwork\n\
        \nBack-End\n\n\nPeople\n\n\n\nEavesdropping\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\n\
        Relay Attack\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nUnauthorised Tag Reading (skimming)\n\
        \n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nPeople Tracking\n\n\_\n\_\n\_\n\_\n\_\n\_\n\
        \n\n\nShipment Tracking\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nTag Cloning\n\n\_\
        \n\_\n\_\n\_\n\_\n\_\n\n\n\nReplay Attack\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\n\
        Insert Attack\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nTag Content Modification\n\n\
        \_\n\_\n\_\n\_\n\_\n\_\n\n\n\nMalware\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nRFID\
        \ System Failure\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\nTag Destruction\n\_\n\_\n\_\
        \n\_\n\_\n\_\n\n\n\nTag Blocking\n\n\_\n\_\n\_\n\_\n\_\n\_\n\n\nDenial of\
        \ Service (DoS)\n\_\n\_\n\_\n\_\n\_\n\_\n\n\n\nRF Jamming\n\n\_\n\_\n\_\n\_\
        \n\_\n\_\n\n\nBack-End Attacks\n\_\n\_\n\_\n\_\n\_\n\_\n\n\nRadiation Hazard\_\
        \n\_\n\_\n\_\n\_\n\_\n\_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:3:1
      ref_id: 11.6.23
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Good Practices and Countermeasures
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.24
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      ref_id: 11.6.24
      description: '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.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:1
      ref_id: 11.6.25
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:1
      ref_id: 11.6.26
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:1
      ref_id: 11.6.27
      description: The ISO/JTC1/SC31 committee is in the process of establishing new
        standards to support the use of simple RFID authentication and encryption
        protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Keyed-Hash Message Authentication Code (HMAC)
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:2
      ref_id: 11.6.28
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:2
      ref_id: 11.6.29
      description: "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\u2019\
        s authenticity."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Digital Signatures
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:3
      ref_id: 11.6.30
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:3
      ref_id: 11.6.31
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:4
      ref_id: 11.6.32
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Cover-Coding
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:5
      ref_id: 11.6.33
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:5
      ref_id: 11.6.34
      description: "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\u2019s data. Cover-coding mitigates\
        \ business process, business intelligence, and privacy risks."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4
      description: Rolling Code
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:4:6
      ref_id: 11.6.35
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Other Defensive Measures
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.36
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      ref_id: 11.6.36
      description: "Other defensive measures, sometimes described as palliative techniques,\
        \ include shielding, blocker tags, tag \u201Ckill\u201D commands, tamper resistance\
        \ and temporary deactivation. It is important to note these techniques do\
        \ not use encryption."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      description: Shielding
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:1
      ref_id: 11.6.37
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:1
      ref_id: 11.6.38
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:1
      ref_id: 11.6.39
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:1
      ref_id: 11.6.40
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      description: Blocker Tags
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:2
      ref_id: 11.6.41
      description: "A special tag, called a \u201Cblocker\u201D tag, blocks an RFID\
        \ reader by simultaneously answering with 0 and 1 to every reader\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:2
      ref_id: 11.6.42
      description: 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).
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:2
      ref_id: 11.6.43
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      description: "Tag \u201CKill\u201D Command "
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:3
      ref_id: 11.6.44
      description: "The \u201Ckill\u201D 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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:3
      ref_id: 11.6.45
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.46
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:3
      ref_id: 11.6.46
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.47
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:3
      ref_id: 11.6.47
      description: "Data stored on the tag is still present in the tag\u2019s 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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      description: Tamper Resistance
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.48
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:4
      ref_id: 11.6.48
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.49
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:4
      ref_id: 11.6.49
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5
      description: Temporary Deactivation
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.50
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:5:5
      ref_id: 11.6.50
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: RFID Risks and Controls Summary
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.51
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:6
      ref_id: 11.6.51
      description: "A summary of RFID Risks and Controls is presented in the Table\
        \ below:\n\n\n\nRisk Control\n\n\nBusiness Process\n\n\nBusiness Intelligence\n\
        \n\nPrivacy\n\n\nElectro-Magnetic Radiation\n\n\nBack-End System Attack\n\n\
        \n\n\nTag Access Controls\n\n\n\n\n\_\n\n\n\n\nPassword Authentication\n\n\
        \n\n\n\_\n\n\n\n\nHMAC\n\n\n\n\n\_\n\n\n\n\nDigital Signature\n\n\n\n\_\n\_\
        \n\n\n\n\nCover-Coding\n\n\_\n\n\_\n\_\n\n\n\n\nEncryption \u2013 Data in\
        \ Transit\n\n\_\n\n\n\_\n\_\n\n\n\nEncryption \u2013 Data at Rest\n\n\_\n\n\
        \_\n\_\n\n\n\n\nEncryption \u2013 Data on Tag\n\n\n\n\n\_\n\_\n\n\nShielding\n\
        \n\n\n\n\_\n\n\n\nBlocker Tags\n\n\_\n\n\n\_\n\_\n\n\n\nTag Kill Feature\n\
        \n\_\n\n\n\_\n\_\n\n\n\nTamper Resistance\n\n\n\n\_\n\_\n\_\n\n\n\nTemporary\
        \ Deactivation\n\n\n\n\n\_\n\_\n\n\n\nRF Engineering and Frequency Selection\n\
        \n\n\n\n\n\_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:7
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Relevant Legislation
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.52
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:7
      ref_id: 11.6.52
      description: In New Zealand, operation of radio and other equipment in the RF
        spectrum is controlled Radiocommunications Act 1989, Reprint as at 5 December
        2013 and administered by the Ministry of Business Innovation and Employment.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:7:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:7
      description: RF Jammers
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.53
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:7:1
      ref_id: 11.6.53
      description: "It is illegal to import, manufacture, sell or use a radio jammer\
        \ in New Zealand except with a licence issued by the Radio Spectrum Management\
        \ unit of the Ministry of Business, Innovation and Employment. The use and\
        \ management of RF jammers is governed by the Radiocommunications Regulations\
        \ (Prohibited Equipment \u2013 Radio Jammer Equipment) Notice 2011 under the\
        \ Regulation 32(1)(i) [a notice in the Gazette] of the Radiocommunications\
        \ Regulations 2001."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:7:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:7
      description: Secure Spaces
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.54
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:7:2
      ref_id: 11.6.54
      description: The use of RFID technology in secure areas must be carefully considered,
        recognising that an RFID tag or system incorporates antennae and transmitting
        capabilities which may compromise the security of such areas. Passive tags
        (classes 0 and 1) pose little risk in themselves as they require a reader
        to activate and have little on-board capability. Read/write tags (class 2)
        pose a higher risk as they have the capability to store data. Other tags (classes
        3 to 5) can pose a significant risk to secure spaces.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:8
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.55
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:8
      ref_id: 11.6.55
      description: "The relevant PSR Mandatory Requirements are:\n\n\n\nReferences\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV2, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\nPSR content protocols \n\
        \nManagement protocol for information security\n\_\nManagement protocol for\
        \ physical security\n\n\nManagement protocol for information security | Protective\
        \ Security Requirements\n\_\nManagement protocol for physical security | Protective\
        \ Security Requirements\n\n\n\nPSR requirements sections\n\nSecurity zones\n\
        \nPhysical security zones | Protective Security Requirements\n\n\nManaging\
        \ specific scenarios\nManaging specific scenarios | Protective Security Requirements\n\
        \nMobile and remote working\nCommunication security\nPhysical security for\
        \ ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:9
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: References - Guidance
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.56
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:9
      ref_id: 11.6.56
      description: "Further references on Guidance can be found at:\n\n\nReference\_\
        \nTitle\nPublisher\nSource\n\n\n\nSP 800-98\n\n\nGuidelines for Securing Radio\
        \ Frequency Identification (RFID) Systems\n\nNIST\nhttps://www.nist.gov/publications/guidelines-securing-radio-frequency-identification-rfid-systems\n\
        \n\n\nFIPS PUB 198-1\n\n\nThe Keyed-Hash Message Authentication Code (HMAC),\
        \ July 2008\n\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf\
        \ [PDF, 126 KB]\n\n\n\nFIPS PUB 180-4\n\n\nSecure Hash Standard (SHS)\n\n\
        NIST\nhttps://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf [PDF, 814\
        \ KB]\n\n\n\nEPC/RFID\n\n\nImplementation Guide for the use of GS1 EPCglobal\
        \ Standards in the Consumer Electronics Supply Chain\n\n\nGS1/EPCglobal\n\n\
        https://www.gs1.org/standards/epc-rfid\n\n\n\_\n\nSmart Border Alliance RFID\
        \ Feasibility Study Final Report Attachment D \u2013 RFID Technology Overview\n\
        \n\nUS Department of Homeland Security\n\nhttps://www.dhs.gov/xlibrary/assets/foia/US-VISIT_RFIDattachD.pdf\
        \ [PDF, 1.49 MB]\n\n\n\_\n\nSmart Border Alliance RFID Feasibility Study Final\
        \ Report Attachment E \u2013 RFID Security And Privacy White Paper\n\n\nUS\
        \ Department of Homeland Security\n\nhttps://www.dhs.gov/xlibrary/assets/foia/US-VISIT_RFIDattachE.pdf\
        \ [PDF, 1.8 MB]\n\n\n\_\n\nTest Operations Procedure (TOP) 03-2-616A Electromagnetic\
        \ Radiation Hazards Testing For Non-Ionizing Radio Frequency Transmitting\
        \ Equipment\n\n\nUS Defense Technical Information Center (DTIC),\n\n\_\n\n\
        \n\_\n\nElectromagnetic Environmental Effects Requirements for Systems \u2013\
        \ MIL-STD-46C\n\n\nUS Department of Defense Interface Standard\n\nhttp://everyspec.com/MIL-STD/MIL-STD-0300-0499/MIL-STD-464C_28312/\n\
        \n\n\_\n\nOECD Policy Guidance \u2013 A Focus on Information Security and\
        \ Privacy Applications, Impacts and Country Initiatives.\n\n\nOECD Directorate\
        \ for Science, Technology and Industry\n\nhttp://www.oecd.org/sti/ieconomy/40892347.pdf\
        \ [PDF, 1.78 MB]\n\n\n\_TR-03126-5\n\nTechnical Guidelines for the Secure\
        \ Use of RFID (TG RFID) Subdocument 5: Application area \u201CElectronic Employee\
        \ ID Card\u201D Version 1.0\n\n\nBSI \u2013 The German Federal Office for\
        \ Information Security\n\nhttps://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG03126/TG_03126_5_Application_area_Electronic_Employee_ID_Card.pdf?__blob=publicationFile\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:10
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: References - Standards
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.57
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:10
      ref_id: 11.6.57
      description: "Further references on standards can be found at:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\n\_\n\nEPC Tag Data Standard Version 1.9, Ratified,\
        \ Nov-2014\n\nGS1/EPCglobal\nhttp://www.gs1.org/epcrfid-epcis-id-keys/epc-rfid-tds/1-9\n\
        \n\n\_\n\nEPC\u2122 Radio-Frequency Identity Protocols Generation-2 UHF RFID\
        \ Specification for RFID Air Interface Protocol for Communications at 860\
        \ MHz \u2013 960 MHz Version 2.0.1\n\nGS1/EPCglobal\nhttps://www.icao.int/publications/pages/publication.aspx?docnum=9303\n\
        \n\nICAO Doc 9303\_\n\nMachine Readable Travel Documents Parts 1-12\n\nInternational\
        \ Civil Aviation Organization (ICAO)\nhttps://www.icao.int/publications/Documents/9303_p3_cons_en.pdf\
        \ [PDF, 2.24 MB]\n\n\nISO/IEC 7816-1:2011\n\nIdentification cards -- Integrated\
        \ circuit cards -- Part 1: Cards with contacts -- Physical characteristics\n\
        \n\_ISO\nhttps://www.iso.org/standard/54089.html\n\n\nISO/IEC 7816-2:2007\_\
        \n\nIdentification cards -- Integrated circuit cards -- Part 2: Cards with\
        \ contacts -- Dimensions and location of the contacts\n\n\_ISO\nhttps://www.iso.org/standard/45989.html\n\
        \n\nISO/IEC 7816-3:2006\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 3: Cards with contacts -- Electrical interface and transmission\
        \ protocols\n\n\_ISO\nhttps://www.iso.org/standard/38770.html\n\n\nISO/IEC\
        \ 7816-4:2020\n\nIdentification cards -- Integrated circuit cards -- Part\
        \ 4: Organization, security and commands for interchange\n\n\_ISO\nhttps://www.iso.org/standard/77180.html\n\
        \n\nISO/IEC 7816-5:2004\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 5: Registration of application providers\n\nISO\_\nhttps://www.iso.org/standard/34259.html\n\
        \n\nISO/IEC 7816-6:2016\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 6: Interindustry data elements for interchange\n\n\_ISO\nhttps://www.iso.org/standard/64598.html\n\
        \n\nISO/IEC 7816-7:1999\n\nIdentification cards -- Integrated circuit(s) cards\
        \ with contacts -- Part 7: Interindustry commands for Structured Card Query\
        \ Language (SCQL)\n\n\_ISO\nhttps://www.iso.org/standard/28869.html\n\n\n\
        ISO/IEC 7816-8:2004\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 8: Commands for security operations\n\n\_ISO\nhttps://www.iso.org/standard/37989.html\n\
        \n\nISO/IEC 7816-9:2017\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 9: Commands for card management\n\nISO\_\nhttps://www.iso.org/standard/67802.html\n\
        \n\nISO/IEC 7816-10:1999\n\nIdentification cards -- Integrated circuit(s)\
        \ cards with contacts -- Part 10: Electronic signals and answer to reset for\
        \ synchronous cards\n\n\_ISO\nhttps://www.iso.org/standard/30558.html\n\n\n\
        ISO/IEC 7816-11:2017\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 11: Personal verification through biometric methods\n\n\_ISO\nhttps://www.iso.org/standard/67799.html\n\
        \n\nISO/IEC 7816-12:2005\_\n\nIdentification cards - Integrated circuit cards\
        \ -- Part 12: Cards with contacts -- USB electrical interface and operating\
        \ procedures\n\n\_ISO\nhttps://www.iso.org/standard/40604.html\n\n\nISO/IEC\
        \ 7816-13:2007\_\n\nIdentification cards -- Integrated circuit cards -- Part\
        \ 13: Commands for application management in a multi-application environment\n\
        \n\_ISO\nhttps://www.iso.org/standard/40605.html\n\n\nISO/IEC 7816-15:2016\_\
        \n\nIdentification cards -- Integrated circuit cards -- Part 15: Cryptographic\
        \ information application\n\n\_ISO\nhttps://www.iso.org/standard/65250.html\n\
        \n\nISO 14443-1:2008\_\n\nIdentification cards \u2013 Contactless integrated\
        \ circuit cards \u2013 Proximity cards \u2013 Part 1: Physical characteristics\n\
        \n\_ISO\nhttps://www.iso.org/standard/39693.html\n\n\nISO/IEC 14443-2:2010\n\
        \nIdentification cards \u2013 Contactless integrated circuit cards \u2013\
        \ Proximity cards \u2013 Part 2: Radio frequency power and signal interface\n\
        \n\_ISO\nhttps://www.iso.org/standard/50941.html\n\n\nISO/IEC 14443-3:2011\_\
        \n\nIdentification cards \u2013 Contactless integrated circuit cards \u2013\
        \ Proximity cards \u2013 Part 3: Initialization and anticollision\n\n\_ISO\n\
        https://www.iso.org/standard/50942.html\n\n\nISO/IEC 14443-4:2008\_\n\nIdentification\
        \ cards \u2013 Contactless integrated circuit cards \u2013 Proximity cards\
        \ \u2013 Part 4: Transmission protocol\n\n\_ISO\nhttps://www.iso.org/standard/50648.html\n\
        \n\nISO/IEC 15961-1:2013\_\_\n\nInformation technology -- Radio frequency\
        \ identification (RFID) for item management: Data protocol -- Part 1: Application\
        \ interface\n\n\_ISO\nhttps://www.iso.org/home.html\n\n\nISO/IEC 15963:2009\_\
        \_\n\nInformation technology \u2013 Radio frequency identification for item\
        \ management \u2013 Unique identification for RF tags\n\n\_ISO\nhttps://www.iso.org/home.html\n\
        \n\nISO/IEC 18000-1:2008\_\_\n\nInformation technology -- Radio frequency\
        \ identification for item management -- Part 1: Reference architecture and\
        \ definition of parameters to be standardized\n\n\_ISO\nhttps://www.iso.org/home.html\n\
        \n\nISO/IEC 18000-2:2009\_\n\nInformation technology -- Radio frequency identification\
        \ for item management -- Part 2: Parameters for air interface communications\
        \ below 135 kHz\n\n\_ISO\nhttps://www.iso.org/home.html\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:11
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Legislation and Regulation
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.58
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:11
      ref_id: 11.6.58
      description: "Further references on Legislation and Regulation can be found\
        \ at:\n\n\nReferences\_\nTitle\nPublisher\nSource\n\n\n\_\n\nRadiocommunications\
        \ Act 1989\n\n\nParliamentary Counsel Office\n\nhttps://legislation.govt.nz\n\
        \n\n\nSR 2001/240\n\n\nRadiocommunications Regulations 2001, Reprint as at\
        \ 1 February 2015\n\n\nParliamentary Counsel Office\n\nhttps://legislation.govt.nz\n\
        \n\n\_\n\nRadiocommunications Regulations (Prohibited Equipment - Radio Jammer\
        \ Equipment) Notice 2011\n\n\nNew Zealand Gazette Office, Government Information\
        \ Services, Department of Internal Affairs\n\nhttps://gazette.govt.nz/notice/id/2011-go4051\n\
        \n\n\_\n\nRadio Spectrum Management\n\n\nMinistry of Business, Innovation\
        \ and Employment\n\nhttps://rsm.govt.nz/\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.59.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      ref_id: 11.6.59.R.01
      description: As with many technologies, adoption of RFID has the potential to
        introduce a wide range of risks in addition to the risks that already exist
        for agency systems. This may include privacy risks, depending on the use,
        information held and implementation of the RFID system. A risk assessment
        is an essential tool in determining and assessing the range and extent of
        risk and threat in the use of RFID devices.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.59.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      ref_id: 11.6.59.R.02
      description: Risks to RFID system vary according to the technology used, system
        engineering, the systems architecture, application, context and deployment
        scenario. A holistic approach to risk at each stage of the system life cycle
        and each for system component is essential if a robust security strategy is
        to be developed.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.59.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      ref_id: 11.6.59.R.03
      description: The identification of classes of tags is fundamental to managing
        the risks of RFID devices in secure spaces. Classes 0 and 1 pose little risk.
        Other classes of tag (2 to 5), however, have limited data storage capability
        and active tags include transmitter functionality which introduces higher
        levels of risk. RFID readers are, by definition, transmitters and are not
        permitted in secure spaces.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.59.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      ref_id: 11.6.59.C.01
      name: 'Control -  All Classifications - Must [CID: 2956]'
      description: Agencies MUST conduct and document a risk assessment before implementing
        or adopting an RFID solution.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.59.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:1
      ref_id: 11.6.59.C.02
      name: 'Control -  All Classifications - Must [CID: 2957]'
      description: This risk assessment MUST be the basis of a security architecture
        design.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Security Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.R.01
      description: "The foundation of strong security architecture in RFID follows\
        \ three important principles:\nControlled access to the data \u2013 only authorised\
        \ entities (people, systems, devices) can read and write information to and\
        \ from the RFID tags (EPC number, tag identifier, kill password, access password\
        \ and user memory) and RFID databases;\nControl over access to the system\
        \ \u2013 only authorised entities can configure or add devices to the system,\
        \ and all devices on the system are authentic and trustworthy;\nConfidence\
        \ and trust \u2013 back-end systems are designed and implemented in accordance\
        \ with the current version of the NZISM.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.R.02
      description: "Sensitive data should be held in a secure RFID Enterprise Subsystem\
        \ and retrieved using the tag\u2019s unique identifier with only an identifier\
        \ stored on the tag itself. The Enterprise RFID subsystem should be established\
        \ as a separate domain where data can be more adequately protected. This structure\
        \ makes it more difficult for adversaries to obtain information from the tag\
        \ through scanning or eavesdropping. Data encryption and access control is\
        \ often more cost-effectively performed in the enterprise subsystem than in\
        \ the RF subsystem."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.R.03
      description: Some RFID systems may cover several organisations, for example
        in supply chains. In such cases, multiple organisations may require access
        to databases that contain tag identifiers and passwords. The security architecture
        should incorporate strong security controls including the authentication of
        external entities, incident management, audit logging and other essential
        security controls.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.C.01
      name: 'Control -  All Classifications - Must [CID: 2962]'
      description: Agencies MUST develop a strong security architecture to protect
        RFID databases and RFID systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.C.02
      name: 'Control -  All Classifications - Must [CID: 2963]'
      description: Agencies MUST minimise the information stored on RFID tags and
        in the RFID subsystem.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.C.03
      name: 'Control -  All Classifications - Should [CID: 2964]'
      description: Agencies SHOULD disable any rewrite functions on RFID devices.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.60.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:2
      ref_id: 11.6.60.C.04
      name: 'Control -  All Classifications - Should [CID: 2965]'
      description: Agencies SHOULD apply the access control requirements of the NZISM
        (Chapter 11 - Communications Systems and Devices) to RFID systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.61.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:3
      ref_id: 11.6.61.R.01
      description: "An RFID Usage Policy is an essential component of an agency\u2019\
        s privacy policy, addressing topics such as how personal information is stored\
        \ and shared. The RFID usage policy should also address privacy issues associated\
        \ with the tag identifier formats and the potential disclosure of information\
        \ based solely on the tag identifier format selected. Agencies MAY be required\
        \ to ensure that devices that collect and store data comply with relevant\
        \ regulation and guidance, such as the Privacy Act. Refer also to\_Chapter\_\
        20 \u2013 Data Management."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.61.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:3
      ref_id: 11.6.61.R.02
      description: "Any RFID implementation should also be incorporated into the agency\u2019\
        s security policies. Refer also to Chapter 5 \u2013 Information Security Documentation."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.61.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:3
      ref_id: 11.6.61.C.01
      name: 'Control -  All Classifications - Should [CID: 2969]'
      description: Agencies SHOULD develop, implement and maintain an RFID Usage Policy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.61.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:3
      ref_id: 11.6.61.C.02
      name: 'Control -  All Classifications - Should [CID: 2970]'
      description: "Agencies SHOULD incorporate RFID into the agency\u2019s security\
        \ policies and information security documentation."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: 'Inspections '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.62.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:4
      ref_id: 11.6.62.R.01
      description: Many system component manufacturers use RFID tags to track shipments.
        RFID tags may be embedded in the packaging, printed on the reverse of labels,
        attached to or embedded in the device itself. The ability to identify and
        track devices may pose a security concern for secure areas or equipment deployed
        in high security applications.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.62.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:4
      ref_id: 11.6.62.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2973]'
      description: Agencies MUST conduct visual and technical inspections of packaging
        and devices to determine if RFID devices have been attached and either permanently
        disable or remove such devices.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.62.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:4
      ref_id: 11.6.62.C.02
      name: 'Control -  All Classifications - Should [CID: 2974]'
      description: Agencies SHOULD conduct visual inspections of packaging and devices
        to determine if RFID devices have been attached and if these RFID devices
        pose a security concern.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.62.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:4
      ref_id: 11.6.62.C.03
      name: 'Control -  All Classifications - Should [CID: 2975]'
      description: Agencies SHOULD conduct visual inspections of packaging and devices
        to determine if RFID devices or labelling have been tampered with and whether
        this is a security concern.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Shielding
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.63.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:5
      ref_id: 11.6.63.R.01
      description: 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. The requirement
        for shielding is determined by the risk assessment and an engineering assessment.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.63.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:5
      ref_id: 11.6.63.C.01
      name: 'Control -  All Classifications - Should [CID: 2978]'
      description: Agencies SHOULD consider undertaking an RF engineering assessment
        where security concerns exist or where the RFID systems are to be used in
        areas with high levels of RF activity.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.63.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:5
      ref_id: 11.6.63.C.02
      name: 'Control -  All Classifications - Should [CID: 2979]'
      description: Shielding SHOULD be considered where eavesdropping or RF radiation
        is a concern, as determined by the risk assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: 'Positioning of Tags and Readers '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.64.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:6
      ref_id: 11.6.64.R.01
      description: "In order to minimise unnecessary electromagnetic radiation tags\
        \ and readers should be carefully positioned. Care should be taken in use\
        \ of RFID readers in proximity to:\nFuel, ordnance, and other hazardous materials,\_\
        \nHumans and sensitive products (e.g., blood, medicine) that may be harmed\
        \ by sustained exposure to RF radiation,\_\nMetal and reflective objects that\
        \ can modify and amplify signals in unintended and potentially harmful ways,\
        \ and\_\nLegitimate radio and Wi-Fi systems to avoid interference.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.64.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:6
      ref_id: 11.6.64.R.02
      description: Tag location cannot always be controlled, such as when tags are
        used to track mobile items or goods in transit. Other difficulties occur with
        persistent radio interference. In these situations, relocation of readers
        and tags may provide a solution. Consideration should be given to alternative
        but cost-effective RF protection measures, such as grounded wire fencing.
        The engineering assessment undertaken to determine the shielding requirements
        will assist in determining such measures.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.64.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:6
      ref_id: 11.6.64.C.01
      name: 'Control -  All Classifications - Should [CID: 2983]'
      description: Agencies SHOULD consider placement of tags and location of readers
        to avoid unnecessary electromagnetic radiation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Encoding and Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.R.01
      description: If an adversary reads an identifier that is encoded with a published
        format, such as in the EPC standard, an adversary may be able to obtain useful
        information such as the manufacturer or issuer of the item, as well as the
        type of item. Because RFID tags hold limited information and identifier formats
        are published in standards, it may be important to use identifier formats
        that do not reveal any information about tagged items or the agency using
        the RFID system. This will be determined in the risk assessment. Encoding
        schemes to limit information revealed from unauthorised scanning may include
        serially or randomly assigning identifiers.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.R.02
      description: Adversaries can often obtain valuable information from the identifier
        alone. For example, knowledge of the EPC manager ID and object class bits
        may reveal the make and model of tagged objects in a container. If individual
        items or boxes of items are tagged, the quantities may also be discernible.
        An adversary might target containers based on their contents.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.R.03
      description: "The smallest tags generally used for consumer items, such as clothing,\
        \ do not have enough computing power to support data encryption. At best these\
        \ tags can cater for PIN-style or password-based protection. Data can, however,\
        \ be encrypted before it is stored on a tag. In these designs, encryption\
        \ is undertaken by the RFID subsystem or the RFID reader. This is an effective\
        \ means of protecting the data on a tag. Refer also to Chapter 17 \u2013 Cryptography."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.R.04
      description: The current Gen 2 standard provides for an on-chip 16-bit Pseudo-Random
        Number Generator (RNG) and a 16-bit Cyclic Redundancy Code (CRC-16) to protect
        tag/reader channels. Neither of these encryption methods is strong because
        of the short bit length in the RNG and because CRCs are not suitable for protection
        against malicious alteration of data.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.C.01
      name: 'Control -  All Classifications - Must [CID: 2989]'
      description: Agencies MUST follow the requirements of the NZISM in the selection
        and implementation of cryptographic protocols and algorithms, and in key management,
        detailed in Chapter 17 - Cryptography.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.C.02
      name: 'Control -  All Classifications - Should [CID: 2990]'
      description: Agencies SHOULD encrypt data before it is written to RFID tags.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.65.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:7
      ref_id: 11.6.65.C.03
      name: 'Control -  All Classifications - Should [CID: 2991]'
      description: Agencies SHOULD assign RFID identifiers using formats that limit
        information about tagged items or about the agency operating the RFID system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.66.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:8
      ref_id: 11.6.66.R.01
      description: "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. This is known as a Keyed-Hash Message\
        \ Authentication Code (HMAC). When HMAC is applied to messages, it also assures\
        \ the integrity of data in the messages. 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\u2019s authenticity."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.66.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:8
      ref_id: 11.6.66.C.01
      name: 'Control -  All Classifications - Should [CID: 2994]'
      description: Agencies SHOULD consider the use of HMAC when tag authenticity
        is required.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Password Management
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.67.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:9
      ref_id: 11.6.67.R.01
      description: "RFID tags generally require passwords before execution of commands\
        \ such as reading and writing of tag data, memory access control, and the\
        \ tag kill feature. Passwords are an important control in maintaining the\
        \ security and integrity of the RFID system. Refer also to Chapter 16 \u2013\
        \ Access Control and passwords."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.67.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:9
      ref_id: 11.6.67.R.02
      description: Tags should not share passwords, although this may not be practical
        in all cases. In applications such as supply chains, multiple organisations
        may require access to databases that contain tag identifiers and passwords.
        In such cases external entities must be authenticated and incident management,
        audit logging and other security controls are essential. While in traditional
        IT systems, passwords are often changed on a periodic basis, in RFID systems,
        such changes may be impractical, especially if the tags are not always accessible
        to the agency assigning the passwords.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.67.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:9
      ref_id: 11.6.67.C.01
      name: 'Control -  All Classifications - Must [CID: 2998]'
      description: Agencies MUST assign passwords for critical RFID functions.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.67.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:9
      ref_id: 11.6.67.C.02
      name: 'Control -  All Classifications - Should [CID: 2999]'
      description: "Agencies SHOULD follow the guidance for passwords management in\
        \ the NZISM (Chapter 16 \u2013 Access control and passwords)."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Temporary Deactivation of Tags
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.68.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:10
      ref_id: 11.6.68.R.01
      description: The RF interface on some tags can be temporarily deactivated. In
        a supply chain application, for example, tags may be turned off to prevent
        unauthorised access to the tags during shipment. This feature is useful when
        communication between readers and a tag is infrequent allowing the tag to
        be activated when required but limiting vulnerability to rogue transactions
        if left operational for extended periods with no authorised activity. Temporary
        deactivation can also extend battery life in powered tags.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.68.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:10
      ref_id: 11.6.68.C.01
      name: 'Control -  All Classifications - Should [CID: 3002]'
      description: Agencies SHOULD consider temporary deactivation of RFID tags where
        the tag is likely to be inactive for extended periods.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Incident Management
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.69.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:11
      ref_id: 11.6.69.R.01
      description: Incident management and audit procedures, logging and time stamps
        help detect and manage security breaches. These are important tools in protecting
        systems and managing security breaches.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.69.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:11
      ref_id: 11.6.69.C.01
      name: 'Control -  All Classifications - Must [CID: 3006]'
      description: "Agencies MUST develop and implement incident identification and\
        \ management processes in accordance with this manual (See Chapter 5 \u2013\
        \ Information Security Documentation, Chapter 6 \u2013 Information Security\
        \ Monitoring, Chapter 7 \u2013 Information Security Incidents, Chapter 9 \u2013\
        \ Personnel Security and Chapter 16 \u2013 Access Control and passwords)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.70.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:12
      ref_id: 11.6.70.R.01
      description: Tag disposal and recycling procedures that permanently disable
        or destroy sensitive data reduces the possibility that they could be used
        later for tracking or targeting, and prevents access to sensitive data stored
        on tags. In addition the continued operating presence of a tag after it has
        performed its intended function can pose a business intelligence or privacy
        risk, including tracking, targeting or access to sensitive data on the tag.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.70.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:12
      ref_id: 11.6.70.R.02
      description: "Disposal may be undertaken electronically by using a tag\u2019\
        s \u201Ckill\u201D feature or using a strong electromagnetic field to permanently\
        \ deactivate a tag\u2019s circuitry. Alternatively physical destruction can\
        \ be achieved by tearing or shredding. Where a tag supports an electronic\
        \ deactivation mechanism, tags should be electronically deactivated before\
        \ physical destruction."
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.70.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:12
      ref_id: 11.6.70.C.01
      name: 'Control -  All Classifications - Should [CID: 3010]'
      description: "Agencies SHOULD consider secure disposal procedures and incorporate\
        \ these into the RFID Usage Policy. Refer also to Chapter 13 \u2013 Media\
        \ and IT equipment management, decommissioning and disposal."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Operator Training and User Awareness
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.71.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:13
      ref_id: 11.6.71.R.01
      description: Operator training can help ensure that personnel using the RFID
        system have the necessary skills and knowledge follow appropriate guidelines
        and policies. If HERF/HERO/HERP risks are present, appropriate security training
        covers mitigation techniques, such as safe handling distances.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.71.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:13
      ref_id: 11.6.71.C.01
      name: 'Control -  All Classifications - Must [CID: 3047]'
      description: "Agencies MUST develop and implement user awareness and training\
        \ programmes to support and enable safe use of RFID services (See Section\
        \ 9.1 \u2013 Information Security Awareness and Training)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:12:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12
      description: Secure Spaces
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.72.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:14
      ref_id: 11.6.72.R.01
      description: The identification of classes of tags is fundamental to managing
        the risks of RFID devices in secure spaces. Classes 0 and 1 pose little risk.
        Other classes of tag (2 to 5), however, have limited data storage capability
        and active tags include transmitter functionality which introduces higher
        levels of risk. RFID readers are, by definition, transmitters and are not
        permitted in secure spaces. Some exceptions may be permitted for testing,
        and inspection and monitoring purposes. Any such exceptions must be carefully
        controlled and monitored.
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.72.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:14
      ref_id: 11.6.72.C.01
      name: 'Control -  All Classifications - Must Not [CID: 3052]'
      description: Any RFID tags of class 3, 4, or 5 MUST NOT be permitted in secure
        spaces.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.72.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:14
      ref_id: 11.6.72.C.02
      name: 'Control -  All Classifications - Must Not [CID: 3054]'
      description: RFID readers MUST NOT be permitted in secure spaces.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.72.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:12:14
      ref_id: 11.6.72.C.03
      name: 'Control -  All Classifications - Should Not [CID: 3055]'
      description: Class 2 RFID tags SHOULD NOT be permitted in secure spaces.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:13
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Abbreviations
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.73
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:13
      ref_id: 11.6.73
      description: '



        Term

        Meaning



        EMV


        Europay, MasterCard, and Visa technical standard




        EPC


        Electronic Product Code




        HERF


        Hazards of Electromagnetic Radiation to Fuel




        HERO


        Hazards of Electromagnetic Radiation to Ordnance




        HERP


        Hazards of Electromagnetic Radiation to Personnel




        HMAC


        Keyed-Hash Message Authentication Code




        RFID


        Radio Frequency Identification




        SAM


        Secure Access Module/ Secure Application Module




        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.6:14
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6
      name: Terms
    - urn: urn:defend:risk:req_node:nzism-v3:11.6.74
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.6:14
      ref_id: 11.6.74
      description: '



        Term

        Meaning



        EMV


        Europay, MasterCard, and Visa technical standard for payment cards, payment
        terminals and automated teller machines (ATMs)




        EPC


        An Electronic Product Code (EPC) is a universal identifier that gives a unique
        identity to a specific physical object. In most instances, EPCs are encoded
        on RFID tags attached to the object and used for stock tracking and management
        purposes. Many types of assets can be tagged including fixed assets, documents,
        transport containers and clothing items.





        Radio Frequency Identification (RFID)



        RFID is technology utilising electromagnetic or electrostatic coupling in
        the radio frequency (RF) portion of the electromagnetic spectrum to uniquely
        identify an object, item, animal, or person. RFID is increasingly used as
        replacement for bar codes. An RFID system consists of three components: an
        antenna, transceiver (usually the RFID reader) and a transponder (also known
        as a tag).





        Secure Access Module



        A Secure Access Module (or Secure Application Module) is used to enhance the
        security and cryptographic performance of devices. SAMs are commonly found
        in devices needing to perform secure transactions, such as payment terminals.
        It can be used for cryptographic computation and secure authentication against
        smart cards or contactless EMV cards.

        Physically a SAM card can either be a separate component and plugged into
        a device when required or incorporated into an integrated circuit.




        Tag


        The transponder in an RFID system, frequently found attached to an item or
        object to provide electronic identification.




        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.7'
      name: Card Access Control Systems
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:1
      ref_id: 11.7.1
      description: To ensure Access Control Systems incorporating contactless RFID
        or smart cards are used safely and securely in order to protect privacy, prevent
        unauthorised access and to prevent the compromise of secure spaces.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: 'Scope '
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:1
      ref_id: 11.7.2
      description: This section provides information relating to the risks, security
        and secure use of RFID or smart cards in access control systems. This section
        does not discuss biometric access control systems.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:1
      ref_id: 11.7.3
      description: The previous section (11.6. Radio Frequency Identification Devices)
        provides background information and technical detail of the RFID aspects and
        should be read in conjunction with this section.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.4
      description: "Contactless access control systems based on RFID (Radio Frequency\
        \ Identification) has largely replaced earlier technologies such as magnetic\
        \ swipe cards in almost all security-critical applications. Two generations\
        \ of RFID access cards exist:\nan earlier generation of cards, which use only\
        \ basic proprietary security mechanisms; and\_\na more recent generation that\
        \ incorporates advances in CMOS and smart card technology to implement cryptography\
        \ and other protective measures.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.5
      description: Older access control systems often incorporated a magnetic strip
        and were easily cloned. More recent systems support the use of PINs in addition
        to RFID. Unfortunately PINs are also sometimes stored on the cards, often
        unencrypted and unprotected, and thus facilitating attacks on both the card
        and the PIN.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.6
      description: 'Access control systems typically comprise four components:

        A reader that programmes the access cards for particular employees and their
        permitted access to parts of the site, building to secure areas.

        A transceiver at each control point to communicate with cards.

        A controller to control the locks of access points (doors).

        The backend system that hosts all permissions and authorised data and interfaces
        with the reader, transceiver and controllers.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.7
      description: "Traditionally access control systems were hosted by stand-alone\
        \ equipment. Modern access control system may be hosted on standard computer\
        \ equipment and hosted in the organisation\u2019s datacentre. It is possible\
        \ that a system intrusion can target access control systems, making the switches,\
        \ gates and locks remotely accessible."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.8
      description: Low frequency RFID badge systems use 125KHz, (ISO 11784/5 and ISO
        14223). Newer high frequency RFID cards use 13.56MHz (ISO 15693, ISO 14443
        and ISO 18000-3).
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.9
      description: Some cards also operate at UHF frequencies of 850-960Mhz (ISO 18000-6).
        Some cards are designed to operate at low and high frequencies by embedding
        multiple antennae in the cards.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.10
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.11
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:2
      ref_id: 11.7.12
      description: UHF cards follow the EPC Global Gen2 standard and the ISO 18000-6
        standards and are designed to operate at distances of up to 10 metres.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Smart Cards
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:3
      ref_id: 11.7.13
      description: Smart cards typically incorporate an embedded integrated circuit
        typically 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:3
      ref_id: 11.7.14
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:3
      ref_id: 11.7.15
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Near Field Communication (NFC)
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:4
      ref_id: 11.7.16
      description: "NFC is an RFID technology that enables two electronic devices\
        \ to establish communication by bringing them within 4 cm of each other. As\
        \ with other \"proximity\" technologies, NFC employs electromagnetic induction\
        \ between two loop antennae when NFC devices exchange information. NFC operates\
        \ in the globally available unlicensed radio frequency band of 13.56\_MHz\
        \ conforming to the ISO/IEC 18000-3 standard. In access control applications\
        \ these devices are sometimes known as \u201Cprox cards\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Attacks
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      ref_id: 11.7.17
      description: In addition to attacks on RFID components described in the previous
        section, access control cards can be susceptible to relay and chip hacking
        attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      ref_id: 11.7.18
      description: Relay attacks rely on rogue readers to activate the tag even when
        not in proximity to a legitimate reader. The card holder will be unaware that
        such an attack is underway. An effective defence is to incorporate distance-to-reader
        verification although few RFID systems incorporate this mechanism.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      ref_id: 11.7.19
      description: Signals between cards and a legitimate reader can be intercepted
        at distances of up to a metre. Greater distances are possible with higher
        powered equipment, special antennae and in low interference environments.
        The signals and data, including card credentials, are captured off-line and
        used to clone access cards. Again the card holder will be unaware that such
        an attack is underway.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      ref_id: 11.7.20
      description: Chip hacking is facilitated by physical access to the card but
        can be mitigated by second factor authentication, encryption of data on the
        card and card tamper detection.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:5
      ref_id: 11.7.21
      description: "Threats, vulnerabilities and mitigations of RFID access control\
        \ systems are summarised in the table below:\n\n\n\nThreat/Vulnerability\n\
        \nMitigation\_\n\n\n\nInterception of the RFID signals\n\n\nEncryption of\
        \ RF links\nHarden RFID elements\n\n\n\nImplants\n\nPhysical security\nCCTV\n\
        Tamper resistant readers\n\n\n\n\nCryptographic attacks\n\n\nUse of approved\
        \ cryptographic algorithms and protocols\nStrong key management\nIncident\
        \ detection and management\nUse of evaluated products\n\n\n\n\nReplay Authentications\n\
        \nRobust Random Number Generation on readers\n\n\n\nKey extraction reader\
        \ attacks through side channel analysis or fault injection\n\n\nUse of evaluated\
        \ products with SAM chips\nIncident detection and management\n\n\n\n\nAttack\
        \ on authentication keys on the card\n\n\nKey diversification\nStrong key\
        \ management\nIncident detection and management\n\n\n\n\nChip Hacking\n\n\n\
        Use of approved cryptographic algorithms and protocols on the card\nTamper\
        \ protection\nIncident detection and management\n\n\n\n\nMalware\n\n\nUpdate\
        \ and patching for all system components\nIncident detection and management\n\
        \n\n\n\nBackend systems\n\n\nSystem hardening\nUpdate and patching for all\
        \ system components\nIntrusion detection\nIncident detection and management\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Product Selection
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:6
      ref_id: 11.7.22
      description: "A number of protection profiles related to smartcards and related\
        \ devices and systems are provided on the Common Criteria website. Refer also\
        \ to Chapter 12 \u2013 Product Security."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Secure Access Module
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:7
      ref_id: 11.7.23
      description: A Secure Access Module (or Secure Application Module - SAM) is
        used to enhance the security and cryptographic performance of devices. SAMs
        are commonly found in devices needing to perform secure transactions, such
        as payment terminals. It can be used for cryptographic computation and secure
        authentication against smart cards or contactless payment cards.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:7
      ref_id: 11.7.24
      description: Physically a SAM card can either be a separate component and plugged
        into a device when required or incorporated into an integrated circuit. A
        typically use is for the secure storage of cryptographic keys or other sensitive
        data. SAM hardware and software are designed to prevent information leakage
        and incorporates countermeasures against electromagnetic radiation, timing
        measurements, and other side channel attacks. These properties mean that SAMs
        offer a much higher level of protection than the terminals and readers, which
        often utilise general-purpose computers.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:7
      ref_id: 11.7.25
      description: "SAM\u2019s typically support 3DES and AES cryptographic algorithms\
        \ and SHA hashing algorithms in their hardware cryptographic co-processor\
        \ implementations. Refer to Chapter 17 for information on approved cryptographic\
        \ algorithms and protocols. It is important to note that 3DES is approved\
        \ for use on legacy systems only and SHA-1 is not an approved hashing algorithm."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2
      description: Card Protection
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:2:8
      ref_id: 11.7.26
      description: RFID blocking wallets and RFID card sleeves are available to block
        RFID frequencies. These are typically used for the protection of credit and
        other payment, access, transit cards and e-passports as a countermeasure for
        skimming attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7
      name: References - Guidance
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.27
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:3
      ref_id: 11.7.27
      description: "Further references on Guidance can be found at:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\n\_\n\nCommon Criteria Protection Profiles\n\n\
        \nCommon Criteria\n\nhttps://www.commoncriteriaportal.org/pps/\n\n\nSP 800-82\n\
        \nNIST Special Publication 800-82 rev.2 Guide to Industrial Control\_Systems\
        \ (ICS) Security, May 2015\n\nNIST\nGuide to Industrial Control Systems (ICS)\
        \ Security (nist.gov)\n\n\n\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7
      name: References - Standards
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.28
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:4
      ref_id: 11.7.28
      description: "Further references on standards can be found at:\n\n\n\n\_Reference\n\
        Title\nPublisher\nSource\n\n\nISO/IEC 7816-1:2011\n\nIdentification cards\
        \ -- Integrated circuit cards -- Part 1: Cards with contacts -- Physical characteristics\n\
        \nISO\n\nhttps://www.iso.org/standard/54089.html\n\n\n\nISO/IEC 7816-2:2007\_\
        \n\nIdentification cards -- Integrated circuit cards -- Part 2: Cards with\
        \ contacts -- Dimensions and location of the contacts\n\nISO\nhttps://www.iso.org/standard/45989.html\n\
        \n\nISO/IEC 7816-3:2006\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 3: Cards with contacts -- Electrical interface and transmission\
        \ protocols\n\nISO\nhttps://www.iso.org/standard/38770.html\n\n\nISO/IEC 7816-4:2013\_\
        \nIdentification cards -- Integrated circuit cards -- Part 4: Organization,\
        \ security and commands for interchange\nISO\nhttps://www.iso.org/standard/54550.html\n\
        \n\nISO/IEC 7816-5:2004\_\nIdentification cards -- Integrated circuit cards\
        \ -- Part 5: Registration of application providers\nISO\nhttps://www.iso.org/standard/34259.html\n\
        \n\nISO/IEC 7816-6:2004\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 6: Interindustry data elements for interchange\n\nISO\nhttps://www.iso.org/standard/38780.html\_\
        \n\n\nISO/IEC 7816-7:1999\_\n\nIdentification cards -- Integrated circuit(s)\
        \ cards with contacts -- Part 7: Interindustry commands for Structured Card\
        \ Query Language (SCQL)\n\nISO\nhttps://www.iso.org/standard/28869.html\n\n\
        \nISO/IEC 7816-8:2019\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 8:\_Commands and mechanisms for security operations\n\nISO\nhttps://www.iso.org/standard/75844.html\_\
        \n\n\nISO/IEC 7816-9:2017\_\n\nIdentification cards -- Integrated circuit\
        \ cards -- Part 9: Commands for card management\n\nISO\nhttps://www.iso.org/standard/67802.html\n\
        \n\nISO/IEC 7816-10:1999\_\n\nIdentification cards -- Integrated circuit(s)\
        \ cards with contacts -- Part 10: Electronic signals and answer to reset for\
        \ synchronous cards\n\nISO\nhttps://www.iso.org/standard/30558.html\n\n\n\
        ISO/IEC 7816-11:2017\_\n\nIdentification cards -- Integrated circuit cards\
        \ -- Part 11: Personal verification through biometric methods\n\nISO\nhttps://www.iso.org/standard/67799.html\n\
        \n\nISO/IEC 7816-12:2005\_\n\nIdentification cards - Integrated circuit cards\
        \ -- Part 12: Cards with contacts -- USB electrical interface and operating\
        \ procedures\n\nISO\nhttps://www.iso.org/standard/40604.html\_\n\n\nISO/IEC\
        \ 7816-13:2007\_\n\nIdentification cards -- Integrated circuit cards -- Part\
        \ 13: Commands for application management in a multi-application environment\n\
        \nISO\nhttps://www.iso.org/standard/40605.html\n\n\nISO/IEC 7816-15:2016\_\
        \n\nIdentification cards -- Integrated circuit cards -- Part 15: Cryptographic\
        \ information application\n\nISO\nhttps://www.iso.org/standard/65250.html\n\
        \n\nISO/IEC 10373-7:2019\_\n\nIdentification cards -- Test methods -- Part\
        \ 7: Vicinity cards\n\nISO\nhttps://www.iso.org/standard/74958.html\_\n\n\n\
        ISO 11784:1996 Amdt 2:2010\_\n\nRadio frequency identification of animals\
        \ \u2014 Code structure \u2014 Amendment 2: Indication of an advanced transponder\n\
        \nISO\nhttps://www.iso.org/standard/45365.html\n\n\nISO 14223-1:2011\_\n\n\
        Radiofrequency identification of animals \u2014 Advanced transponders \u2014\
        \ Part 1: Air interface\n\nISO\nhttps://www.iso.org/standard/50979.html\n\n\
        \nISO 14223-2:2010\_\n\nRadiofrequency identification of animals -- Advanced\
        \ transponders -- Part 2: Code and command structure\n\nISO\nhttps://www.iso.org/standard/45364.html\n\
        \n\nISO 14443-1:2008\_\n\nIdentification cards \u2013 Contactless integrated\
        \ circuit cards \u2013 Proximity cards \u2013 Part 1: Physical characteristics\n\
        \nISO\nhttps://www.iso.org/standard/39693.html\_\n\n\nISO/IEC 14443-2:2010\_\
        \n\nIdentification cards \u2013 Contactless integrated circuit cards \u2013\
        \ Proximity cards \u2013 Part 2: Radio frequency power and signal interface\n\
        \n\_ISO\nhttps://www.iso.org/standard/50941.html\n\n\nISO/IEC 14443-3:2011\_\
        \n\nIdentification cards \u2013 Contactless integrated circuit cards \u2013\
        \ Proximity cards \u2013 Part 3: Initialization and anticollision\n\nISO\n\
        https://www.iso.org/standard/50942.html\_\n\n\nISO/IEC 14443-4:2008\_\_\n\n\
        Identification cards \u2013 Contactless integrated circuit cards \u2013 Proximity\
        \ cards \u2013 Part 4: Transmission protocol\n\nISO\nhttps://www.iso.org/standard/50648.html\n\
        \n\nISO/IEC 18000-3:2010\_\_\n\nInformation technology -- Radio frequency\
        \ identification for item management -- Part 3: Parameters for air interface\
        \ communications at 13,56 MHz\n\nISO\nhttps://www.iso.org/standard/53424.html\n\
        \n\nISO/IEC 18000-6:2013\_\_\n\nInformation technology -- Radio frequency\
        \ identification for item management -- Part 6: Parameters for air interface\
        \ communications at 860 MHz to 960 MHz General\n\nISO\nhttps://www.iso.org/standard/59644.html\_\
        \n\n\nISO/IEC TR 29123:2007\_\_\n\nIdentification Cards \u2013 Proximity Cards\
        \ \u2013 Requirements for the enhancement of interoperability\n\n\_ISO\nhttps://www.iso.org/standard/45146.html\n\
        \n\nISO/IEC 15693-1:2010\_\n\nIdentification cards -- Contactless integrated\
        \ circuit cards -- Vicinity cards -- Part 1: Physical characteristics\n\n\
        ISO\nhttps://www.iso.org/standard/39694.html\n\n\nISO/IEC 15693-2:2006\_\n\
        \nIdentification cards -- Contactless integrated circuit cards -- Vicinity\
        \ cards -- Part 2: Air interface and initialization\n\nISO\nhttps://www.iso.org/standard/39695.html\n\
        \n\nISO/IEC 15693-3:2019\_\n\nIdentification cards -- Contactless integrated\
        \ circuit cards -- Vicinity cards -- Part 3: Anticollision and transmission\
        \ protocol\n\nISO\nhttps://www.iso.org/standard/73602.html\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7
      name: Rationale and Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:1
      ref_id: 11.7.29.R.01
      description: As with many technologies, adoption of RFID access cards has the
        potential to introduce a wide range of risks in addition to the risks that
        already exist for agency systems. This may compromise the cards and enable
        unauthorised access, in addition to RFID risks discussed in the previous section.
        A risk assessment is an essential tool in determining and assessing the range
        and extent of risk and threat in the use of RFID access cards.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:1
      ref_id: 11.7.29.C.01
      name: 'Control -  All Classifications - Must [CID: 3130]'
      description: Agencies MUST conduct and document a risk assessment before implementing
        or adopting an RFID access card system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.29.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:1
      ref_id: 11.7.29.C.02
      name: 'Control -  All Classifications - Must [CID: 3131]'
      description: This risk assessment MUST be the basis of a security architecture
        design.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Security Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      ref_id: 11.7.30.R.01
      description: "The foundation of strong security architecture in RFID follows\
        \ these important principles:\nPhysical Security - over readers, secure areas,\
        \ issued and unissued access cards;\nControlled access to the data \u2013\
        \ only authorised entities (people, systems, devices) can read and write information\
        \ to the cards, card databases and backend systems;\nControl over access to\
        \ the system \u2013 only authorised entities can configure or add devices\
        \ to the system, and all devices on the system are authentic and trustworthy;\n\
        Confidence and trust \u2013 back-end systems are designed and implemented\
        \ in accordance with the current version of the NZISM. This includes intrusion\
        \ detection and incident management mechanisms and procedures.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      ref_id: 11.7.30.R.02
      description: Some access systems may cover several organisations or sites. In
        such cases, multiple organisations or sites may require access to databases
        that contain personnel identifiers, passwords and access permissions. The
        security architecture should incorporate strong security controls including
        the authentication of external entities, incident management, audit logging
        and other essential security controls.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      ref_id: 11.7.30.C.01
      name: 'Control -  All Classifications - Must [CID: 3138]'
      description: Agencies MUST develop a strong security architecture to protect
        access to databases and systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.30.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      ref_id: 11.7.30.C.02
      name: 'Control -  All Classifications - Should [CID: 3139]'
      description: Agencies SHOULD apply the NZISM access controls (Chapter 11) and
        cryptographic controls (Chapter 17) to access card systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.30.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:2
      ref_id: 11.7.30.C.03
      name: 'Control -  All Classifications - Should [CID: 3141]'
      description: "Agencies SHOULD consider the application of the following design\
        \ elements:\nImplement a Demilitarized Zone (DMZ) to isolate card systems\
        \ from other parts of the organisation\u2019s network and from high-risk Internet\
        \ Protocol (IP) network connections;\nSecure or remove connections between\
        \ the Internet and card system network segments;\nSecure or remove vulnerable\
        \ dialup modem links;\_\nSecure or remove vulnerable wireless radio links\
        \ and network access points; and\nNetwork activity monitoring for unusual\
        \ or anomalous access activity and well as intrusion detection.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:3
      ref_id: 11.7.31.R.01
      description: "An Access Card Usage Policy is an essential component addressing\
        \ topics such as how personal information is stored and shared, card holder\
        \ responsibilities and procedures to manage card loss or damage. Refer also\
        \ to Chapter\_20 \u2013 Data Management."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.31.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:3
      ref_id: 11.7.31.R.02
      description: "Any access card implementation should also be incorporated into\
        \ the agency\u2019s security policies. Refer also to Chapter 5 \u2013 Information\
        \ Security Documentation."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:3
      ref_id: 11.7.31.C.01
      name: 'Control -  All Classifications - Should [CID: 3156]'
      description: Agencies SHOULD develop, implement and maintain an Access Card
        Usage Policy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.31.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:3
      ref_id: 11.7.31.C.02
      name: 'Control -  All Classifications - Should [CID: 3157]'
      description: "Agencies SHOULD incorporate access cards into the agency\u2019\
        s security policies and information security documentation."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Physical Security
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.R.01
      description: Physical security over readers, door controls, cables and control
        systems, as well as the cards themselves is fundamental to the operation of
        a secure system.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.R.02
      description: "In order to minimise unnecessary electromagnetic radiation readers\
        \ and control equipment should be carefully positioned. Care should be taken\
        \ with the use of card readers in proximity to:\nFuel, ordnance, and other\
        \ hazardous materials,\_\nMetal and reflective objects that can modify and\
        \ amplify signals in unintended and potentially harmful ways, and\_\nLegitimate\
        \ radio systems to avoid interference.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.C.01
      name: 'Control -  All Classifications - Should [CID: 3162]'
      description: Agencies SHOULD select systems that provide resistance to physical
        or electronic tampering.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.C.02
      name: 'Control -  All Classifications - Should [CID: 3163]'
      description: Agencies SHOULD implement systems to minimise the risk of physical
        or electronic tampering.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.C.03
      name: 'Control -  All Classifications - Should [CID: 3165]'
      description: Agencies SHOULD consider placement of tags and location of readers
        to avoid unnecessary electromagnetic radiation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.32.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:4
      ref_id: 11.7.32.C.04
      name: 'Control -  All Classifications - Should [CID: 3166]'
      description: Agencies SHOULD consider and select other physical controls in
        accordance with the PSR.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Card Data Protection
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.33.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:5
      ref_id: 11.7.33.R.01
      description: Cards are invariably retained by the card holder and subject to
        loss, theft or being misplaced. Cards are also not always within the control
        of the card holder outside of normal office hours. Measures to protect cards
        in these situations are fundamental to the maintenance of the integrity and
        security of the access control system.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.33.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:5
      ref_id: 11.7.33.C.01
      name: 'Control -  All Classifications - Must [CID: 3171]'
      description: Agencies MUST follow the requirements of the NZISM in the selection
        and implementation of cryptographic protocols and algorithms, and in key management,
        detailed in Chapter 17 - Cryptography.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.33.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:5
      ref_id: 11.7.33.C.02
      name: 'Control -  All Classifications - Should [CID: 3173]'
      description: Agencies SHOULD encrypt data before it is written to cards.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.33.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:5
      ref_id: 11.7.33.C.03
      name: 'Control -  All Classifications - Should [CID: 3175]'
      description: Agencies SHOULD consider the use of cards systems incorporating
        Secure Access Modules (SAMs).
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Incident Management
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:6
      ref_id: 11.7.34.R.01
      description: Incident management and audit procedures, logging and time stamps
        help detect and manage security breaches. These are important tools in protecting
        systems and managing security breaches.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:6
      ref_id: 11.7.34.C.01
      name: 'Control -  All Classifications - Must [CID: 3180]'
      description: "Agencies MUST develop and implement incident identification and\
        \ management processes in accordance with this manual (See Chapter 5 \u2013\
        \ Information Security Documentation, Chapter 6 \u2013 Information Security\
        \ Monitoring, Chapter 7 \u2013 Information Security Incidents, Chapter 9 \u2013\
        \ Personnel Security and Chapter 16 \u2013 Access control and passwords)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.7:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5
      description: Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.35.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:7
      ref_id: 11.7.35.R.01
      description: Card disposal and recycling procedures that permanently disable
        or destroy sensitive data reduces the possibility that they could be used
        later for tracking or targeting, and prevents access to sensitive data stored
        on cards. In addition the continued operating presence of a card after it
        has performed its intended function can pose an unauthorised access, business
        intelligence or privacy risk, including tracking and targeting of personnel
        or access to sensitive data on the access card.
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.35.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:7
      ref_id: 11.7.35.R.02
      description: "Disposal may be undertaken by electronically by using a card\u2019\
        s wipe feature or using a strong electromagnetic field to permanently deactivate\
        \ a tag\u2019s circuitry. Alternatively physical destruction can be achieved\
        \ by tearing or shredding. Where a tag supports an electronic deactivation\
        \ mechanism, tags should be electronically deactivated before physical destruction."
    - urn: urn:defend:risk:req_node:nzism-v3:11.7.35.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.7:5:7
      ref_id: 11.7.35.C.01
      name: 'Control -  All Classifications - Should [CID: 3189]'
      description: Agencies SHOULD consider secure disposal procedures and incorporate
        these into the Access Card Usage Policy. Refer also to Media and IT equipment
        management, decommissioning and disposal.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:11
      ref_id: '11.8'
      name: Multifunction Devices, Network Printers and Fax Machines
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:1
      ref_id: 11.8.1
      description: "Multifunction devices (MFD\u2019s), network printers and fax machines\
        \ are used in a secure manner."
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:2:1
      ref_id: 11.8.2
      description: "This section covers information relating to MFDs, network printers\
        \ and fax machines connected to either the ISDN, PSTN, HACE or other networks.\
        \ Further information on MFDs communicating via network gateways can be found\
        \ in\_Section 20.2 - Data Import and Export."
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: MFD, network printer and fax machine usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:1
      ref_id: 11.8.3.R.01
      description: MFDs, network printers and fax machines, 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:1
      ref_id: 11.8.3.C.01
      name: 'Control -  All Classifications - Must [CID: 2537]'
      description: Agencies MUST develop a policy governing the use of MFDs, network
        printers and fax machines,
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Sending fax messages
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:2
      ref_id: 11.8.4.R.01
      description: "Once a MFD or fax machine 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."
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:2
      ref_id: 11.8.4.R.02
      description: Non-encrypted communications may be exposed in transmission and,
        if incorrectly addressed or an incorrect recipient number is entered, may
        cause a data breach.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:2
      ref_id: 11.8.4.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2543]'
      description: Agencies sending classified messages MUST ensure that the message
        is encrypted to an appropriate level when communicated over unsecured telecommunications
        infrastructure or the public switched telephone network.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:2
      ref_id: 11.8.4.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2545]'
      description: Agencies MUST have separate MFDs or fax machines for sending classified
        messages and messages classified RESTRICTED and below.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Receiving fax messages
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:3
      ref_id: 11.8.5.R.01
      description: Whilst the communications path between MFDs and fax machines 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 MFD or fax machine 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:3
      ref_id: 11.8.5.C.01
      name: 'Control -  All Classifications - Should [CID: 2562]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Connecting MFDs to telephone networks
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:4
      ref_id: 11.8.6.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:4
      ref_id: 11.8.6.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must Not [CID: 2568]'
      description: 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.
      implementation_groups:
      - Top Secret - MUST NOT
      - Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:4
      ref_id: 11.8.6.C.02
      name: 'Control -  All Classifications - Should Not [CID: 2570]'
      description: 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.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Connecting MFDs to computer networks
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:5
      ref_id: 11.8.7.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:5
      ref_id: 11.8.7.C.01
      name: 'Control -  All Classifications - Must [CID: 2575]'
      description: '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.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Copying documents on MFDs
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:6
      ref_id: 11.8.8.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:6
      ref_id: 11.8.8.C.01
      name: 'Control -  All Classifications - Must Not [CID: 2578]'
      description: Agencies MUST NOT permit MFDs connected to computer networks to
        be used to scan or copy classified documents above the classification of the
        connected network.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Observing MFD and fax machine use
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:7
      ref_id: 11.8.9.R.01
      description: Placing MFDs and fax machines in public areas can help reduce the
        likelihood of any suspicious use going unnoticed.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:7
      ref_id: 11.8.9.C.01
      name: 'Control -  All Classifications - Should [CID: 2581]'
      description: Agencies SHOULD ensure that MFDs and fax machines are located in
        areas where their use can be observed.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Servicing and Maintenance
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.R.02
      description: "Copiers and laser printers may use electrostatic drums as part\
        \ of the reproduction and printing process. These drums can retain a \u201C\
        memory\u201D 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 \u2013 Decommissioning\
        \ and Disposal)."
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.R.03
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 2589]'
      description: Any maintenance or servicing MUST be conducted under supervision
        or by cleared personnel.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.C.02
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 2590]'
      description: 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 - Media and IT equipment Management, Decommissioning
        and Disposal.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.C.03
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 2591]'
      description: 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 - Media and IT equipment
        Management, Decommissioning and Disposal.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.C.04
      name: 'Control -  All Classifications - Should [CID: 2592]'
      description: Any maintenance or servicing SHOULD be conducted under supervision
        or by cleared personnel.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.10.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:8
      ref_id: 11.8.10.C.05
      name: 'Control -  All Classifications - Should [CID: 2593]'
      description: "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 - Media and IT equipment Management, Decommissioning\
        \ and Disposal."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: USB Devices
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:9
      ref_id: 11.8.11.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:9
      ref_id: 11.8.11.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2596]'
      description: The use of any USB capability MUST be conducted under supervision
        or by cleared personnel.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.11.c-02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:9
      ref_id: 11.8.11.C-02
      name: 'Control -  All Classifications - Should [CID: 2597]'
      description: The use of any USB capability SHOULD be conducted under supervision
        or by cleared personnel.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Decommissioning and Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:10
      ref_id: 11.8.12.R.01
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:10
      ref_id: 11.8.12.R.02
      description: 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.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:10
      ref_id: 11.8.12.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 2604]'
      description: "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 - Media and IT equipment Management,\
        \ Decommissioning and Disposal."
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:10
      ref_id: 11.8.12.C.02
      name: 'Control -  All Classifications - Should [CID: 2606]'
      description: "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 - Media and IT equipment Management,\
        \ Decommissioning and Disposal."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:11.8:3:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3
      description: Logging multifunction device use
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:11
      ref_id: 11.8.13.R.01
      description: Centrally logging and analysing MFD events, which may include metadata
        and shadow copies of documents printed, scanned or copied by users, can assist
        in monitoring the security posture of systems, detecting malicious behaviour,
        and contributing to investigations following cyber security incidents. Logs
        are stored in a central system, such as a security information and event management
        tool or central database and can only be accessed or modified by authorised
        and authenticated users. Logs are stored for a duration informed by risk or
        regulatory guidelines.
    - urn: urn:defend:risk:req_node:nzism-v3:11.8.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:11.8:3:11
      ref_id: 11.8.13.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Should [CID: 7537]'
      description: Use of MFDs for printing, scanning, and copying purposes SHOULD
        be centrally logged.
      implementation_groups:
      - Top Secret - SHOULD
      - Secret - SHOULD
      - Confidential - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12
      assessable: false
      depth: 1
      ref_id: '12'
      name: Product Security
    - urn: urn:defend:risk:req_node:nzism-v3:12.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.1'
      name: Product Selection and Acquisition
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:1
      ref_id: 12.1.1
      description: Products providing security functions for the protection of classified
        information are formally evaluated in order to provide a degree of assurance
        over the integrity and performance of the product.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:1
      ref_id: 12.1.2
      description: This section covers information on the selection and acquisition
        of any product that provide security functionality for the protection of information.
        It DOES NOT provide information on the selection or acquisition of products
        that do not provide security functionality or physical security products.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2
      description: Selecting products without security functions
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:2
      ref_id: 12.1.3
      description: Agencies selecting products that do not provide a security function
        or selecting products that will not use their security functions are free
        to follow their own agency or departmental acquisition guidelines.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2
      description: Product specific requirements
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:3
      ref_id: 12.1.4
      description: Where consumer guides exist for evaluated products, agencies should
        identify and assess any potential conflicts with this manual. Where further
        advice is required, consult the GCSB.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2
      description: Convergence
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:4
      ref_id: 12.1.5
      description: Convergence is the integration of a number of discrete technologies
        into one product. Converged solutions can include the advantages and disadvantages
        of each discrete technology.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:4
      ref_id: 12.1.6
      description: Most products will exhibit some element of convergence. When products
        have converged elements, agencies will need to comply with the relevant areas
        of this manual for the discrete technologies when deploying the converged
        product.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:2:4
      ref_id: 12.1.7
      description: As an example, when agencies choose to use evaluated media, such
        as encrypted flash memory media, the requirements for evaluated products,
        media and cryptographic security apply.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      ref_id: 12.1.8
      description: In Common Criteria (CC), assurance is the confidence that a Target
        of Evaluation (TOE) meets the Security Functional Requirements (SFR) of the
        product.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Determining Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:1
      ref_id: 12.1.9
      description: 'In order to determine the level of assurance (the EAL), the CC
        standard requires tests, checks and evaluations in several areas. Higher levels
        of assurance require more extensive design, documentation, testing and evaluation.
        Determining assurance requires assessment of the following elements:

        Development;

        Guidance documents;

        Life-cycle support;

        Security Target evaluation;

        Tests; and

        Vulnerability assessment.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Augmented Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:2
      ref_id: 12.1.10
      description: "It is possible to \u201Caugment\u201D an evaluation to provide\
        \ additional assurance without changing the fundamental assurance level. This\
        \ mechanism allows the addition of assurance components not specifically required\
        \ for a specific level of evaluation or the substitution of assurance components\
        \ from the specification of another hierarchically higher assurance component.\
        \ Of the assurance constructs defined in the CC, only EALs may be augmented.\
        \ An augmented EAL is often indicated by a \u201D+\u201D-sign (for example\
        \ EAL4+). The concept of negative augmentation or an \u201CEAL minus\u201D\
        \ is not recognised by the standard."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: High Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:3
      ref_id: 12.1.11
      description: High Assurance is a generic term encompassing EAL levels 5, 6 and
        7. ASD run an independent High Assurance Evaluation scheme which is not related
        to AISEP or an EAL rating.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Evaluated Products List
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:4
      ref_id: 12.1.12
      description: 'The Certified Products List (CPL) records products that have been
        evaluated through one or more of the following schemes:


        Common Criteria;

        high assurance evaluation; or

        an Australian Information Security Evaluation Program (AISEP) approved evaluation.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:4
      ref_id: 12.1.13
      description: "AISEP certified products can be viewed\_on the Common Criteria\
        \ Certified Products List (CPL).\_IT security products that are\_currently\
        \ undergoing an evaluation in the AISEP are listed on the AISEP webpage under\
        \ the section Products in Evaluation."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Evaluation level mapping
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:5
      ref_id: 12.1.14
      description: The Information Technology Security Evaluation Criteria (ITSEC)
        and Common Criteria (CC) assurance levels used in the EPL are similar, but
        not identical, in their relationship. The table below shows the relationship
        between the two evaluation criteria.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:5
      ref_id: 12.1.15
      description: "This manual refers only to Common Criteria Evaluation Assurance\
        \ Levels (EALs). The table below maps ITSEC evaluation assurance levels to\
        \ Common Criteria EALs. EAL\u2019s are defined in the Common Criteria Standard\
        \ \u2013 part 3.\n\n\nCriteria\nAssurance level\n\n\n\nCommon Criteria\n\n\
        \nN/A\n\nEAL1\nEAL2\nEAL3\nEAL4\nEAL5\nEAL6\nEAL7\n\n\nITSEC\nE0\nN/A\nE1\n\
        E2\nE3\nE4\nE5\nE6\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Recognition arrangements
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:6
      ref_id: 12.1.16
      description: The AISEP programme has a number of recognition arrangements regarding
        evaluated products. Before choosing a product that has not been evaluated
        by the AISEP, agencies are encouraged to contact the GCSB to enquire whether
        the product will be recognised for New Zealand use once it has complete evaluation
        in a foreign scheme.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:6
      ref_id: 12.1.17
      description: "Two such recognition arrangements are for the Common Criteria\
        \ Recognition Arrangement up to the assurance level of EAL2 with the lifecycle\
        \ flaw remediation augmentation and for degausser products listed on the National\
        \ Security Agency/Central Security Service\u2019s EPLD."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Australian Information Security Evaluation Program (AISEP)
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:7
      ref_id: 12.1.18
      description: The AISEP exists to ensure that a range of evaluated products are
        available to meet the needs of Australian and New Zealand Government agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:7
      ref_id: 12.1.19
      description: "The AISEP performs the following functions:\n\nevaluation and\
        \ certification of products using the Common Criteria;\ncontinued maintenance\
        \ of the assurance of evaluated products; and\nrecognition of products evaluated\
        \ by a foreign scheme with which the AISEP has a mutual recognition agreement\
        \ (generally the Common Criteria Recognition Agreement \u2013 CCRA).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3
      description: Protection Profiles
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.20
      description: A Protection Profile (PP) describes the security functionality
        that must be included in a Common Criteria evaluation to meet a range of defined
        threats. PPs also define the activities to be taken to assess the security
        functions of a product. Agencies can have confidence that a product evaluated
        against an AISEP or GCSB approved PP addresses the defined threats. Approved
        PPs are published on the Certified Products List.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.21
      description: "The introduction of PP\u2019s is to reduce the time required for\
        \ evaluation, compared with the traditional approach to allow the AISEP to\
        \ keep pace with the rapid evolution, production and release of security products\
        \ and updates. \_Cryptographic security functionality is included in the scope\
        \ of evaluation against an approved Protection Profile.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.22
      description: To facilitate the transition to AISEP approved Protection Profiles,
        a cap of Evaluation Assurance Level (EAL) 2 applies for all traditional AISEP
        (EAL based evaluations), including for technologies with no existing approved
        Protection Profile. EAL 2 is considered to represent a sensible trade-off
        between completion time and meaningful security assurance gains.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.23
      description: "Evaluations conducted in other nations\u2019 Common Criteria schemes\
        \ will continue to be recognised by the GCSB under the AISEP."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.24
      description: Some High Assurance evaluations continue to be conducted in European
        Approved Testing Facilities and use the EAL rating scheme. ASD run an independent
        High Assurance Evaluation scheme which is not related to AISEP or an EAL rating.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.25
      description: It is important that Agencies check the evaluation has examined
        the security enforcing functions by reviewing the target of evaluation/security
        target and other testing documentation.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:3:8
      ref_id: 12.1.26
      description: The UK utilises several product evaluation schemes such as the
        CESG Assisted Products Service (CAPS), CESG Assured Service (CAS) and IT Security
        Evaluation Criteria (ITSEC). Agencies should consult the GCSB if further clarity
        on the utilisation of these evaluation schemes and products is required.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: Product Selection
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.27
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:4
      ref_id: 12.1.27
      description: 'The UK utilises several product evaluation schemes such as the
        CESG Assisted Products Service (CAPS), CESG Assured Service (CAS) and IT Security
        Evaluation Criteria (ITSEC). Agencies should consult the GCSB if further clarity
        on the utilisation of these evaluation schemes and products is required.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.28
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:5
      ref_id: 12.1.28
      description: "\n\n\n\nReference\n\n\nTitle\n\n\nPublisher\n\n\nSource\n\n\n\n\
        \_\n\nAISEP Policy Manual, August 2022\n\nASD\n2022_AUG_REL_AISEP_Policy_Manual_6.3.pdf\
        \ (cyber.gov.au)\n\n\n\_\n\nAustralian Information Security Evaluation Program\
        \ (AISEP)\n\nASD\nhttps://www.cyber.gov.au/acsc/view-all-content/programs/australasian-information-security-evaluation-program\n\
        \n\n\_\n\nCommon Criteria\n\n\nCC\n\nhttps://www.commoncriteriaportal.org\n\
        \n\n\_\n\nCommon Criteria Certified Products\n\nCC\n\nhttps://www.commoncriteriaportal.org/products\_\
        \n\n\n\n\_\n\nProduct & Services Marketplace\n\nNCSC, UK\n\nhttps://www.ncsc.gov.uk/marketplace\n\
        \n\n\n\_\n\nNational Information Assurance Partnership (NIAP)\n\nNIAP\nhttps://ww.niap-ccevs.org\n\
        \n\n\_\n\nGovernment Rules of Sourcing\n\n\nMinistry of Business Innovation\
        \ & Employment (MBIE)\n\n\nGovernment Procurement Rules - Rules for sustainable\
        \ and inclusive procurement\n\u200B\u200BGovernment Procurement Rules | New\
        \ Zealand Government Procurement and Property\n\n\n\n\_\nCommonwealth Procurement\
        \ Rules\nDepartment of Finance and deregulation (Financial Management Group)\_\
        \n\nCommonwealth Procurement Rules | Department of Finance \nhttps://www.finance.gov.au/sites/default/files/2022-06/CPRs\
        \ 1 July 2022.pdf\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.29
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:6
      ref_id: 12.1.29
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV5, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\n\nPSR content protocols\
        \ \n\n\nManagement protocol for information security\nManagement protocol\
        \ for physical security\n\n\nManagement protocol for information security\
        \ | Protective Security Requirements\n\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\n\_PSR requirements sections\n\
        \nSupply chain security\n\n\nSupply chain security | Protective Security Requirements\n\
        \n\n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nOutsourcing, Offshoring and supply chains\nPhysical\
        \ security for ICT systems\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Evaluated product selection preference order
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.R.01
      description: In selecting products for use, agencies should note that completed
        evaluations provide greater assurance than those products that are still undergoing
        evaluation or have not completed any formal evaluation activity. This assurance
        gradation is reflected in the preference order for selecting security products.
        If an agency selects a product that is ranked lower in the preference order,
        the justification for this decision MUST be recorded.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.R.02
      description: For products that are currently in evaluation, agencies should
        select those that are undergoing evaluation through AISEP in preference to
        those being conducted in a recognised foreign scheme. If a major vulnerability
        is found during the course of an AISEP evaluation, the GCSB may advise agencies
        on appropriate risk reduction strategies.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.R.03
      description: It is important to recognise that a product that is under evaluation
        has not, and might never, complete all relevant evaluation processes.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.R.04
      description: Agencies should be aware that while this section provides a product
        selection preference order, policy stated elsewhere in this manual, or product
        specific advice from the GCSB, could override this standard by specifying
        more rigorous requirements for particular functions and device use.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.R.05
      description: "Additionally, where an EAL rating is mandated for a product to\
        \ perform a cryptographic function for the protection of data at rest or in\
        \ transit, as specified within Chapter 17 \u2013 Cryptography, products that\
        \ have not completed an Approved Evaluation do not satisfy the requirement."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3284]'
      description: "Agencies MUST select products in the following order of preference:\n\
        a protection profile (PP) evaluated product;\nproducts having completed an\
        \ evaluation through the AISEP or recognised under the Common Criteria Recognition\
        \ Arrangement (CCRA);\nproducts in evaluation in the AISEP;\_\nproducts in\
        \ evaluation in a scheme where the outcome will be recognised by the GCSB\
        \ when the evaluation is complete; or\nIf products do not fall within any\
        \ of these categories, contact the GCSB.\n"
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.C.02
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3286]'
      description: When choosing a product, agencies MUST document the justification
        for any decision to choose a product that is still in evaluation and accept
        any security risk introduced by the use of such a product.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.30.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:1
      ref_id: 12.1.30.C.03
      name: 'Control -  All Classifications - Should [CID: 3287]'
      description: "Agencies SHOULD select products in the following order of preference:\n\
        a protection profile (PP) evaluated product;\nproducts having completed an\
        \ evaluation through the AISEP or recognised under the Common Criteria Recognition\
        \ Arrangement (CCRA);\nproducts in evaluation in the AISEP;\_\nproducts in\
        \ evaluation in a scheme where the outcome will be recognised by the GCSB\
        \ when the evaluation is complete; or\nIf products do not fall within any\
        \ of these categories, normal selection criteria (such as functionality and\
        \ security) will apply.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Evaluated product selection
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:2
      ref_id: 12.1.31.R.01
      description: "A certified product might not meet the security requirements of\
        \ an agency.\_ This could occur for a number of reasons, including that the\
        \ scope of the evaluation is inappropriate for the intended use or the operational\
        \ environment differs from that assumed in the evaluation.\_ As such, an agency\
        \ should ensure that a product is suitable by reviewing all available documentation.\_\
        \ In the case of Common Criteria certified products list, this documentation\
        \ includes the protection profile, target of evaluation, security target,\
        \ certification report, consumer guide along with any qualifications and limitations."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.31.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:2
      ref_id: 12.1.31.R.02
      description: Products that are in evaluation will not have a certification report
        and may not have a published security target. A protection profile will, as
        a rule, exist. A draft security target can be obtained from the GCSB for products
        that are in evaluation through AISEP. For products that are in evaluation
        through a foreign scheme, the vendor can be contacted directly for further
        information.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:2
      ref_id: 12.1.31.C.01
      name: 'Control -  All Classifications - Should [CID: 3294]'
      description: "Agencies SHOULD select products that have their desired security\
        \ functionality within the scope of the product\u2019s evaluation and are\
        \ applicable to the agency\u2019s intended environment."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Product specific requirements
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.32.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:3
      ref_id: 12.1.32.R.01
      description: "Whilst this manual may recommend a minimum level of assurance\
        \ in the evaluation of a product\u2019s security functionality not all evaluated\
        \ products may be found suitable for their intended purpose even if they pass\
        \ their Common Criteria evaluation. Typically such products will have cryptographic\
        \ functionality that is not covered in sufficient depth under the Common Criteria.\
        \ Where products have specific usage requirements, in addition to this manual,\
        \ or supersede requirements in this manual, they will be outlined in the product\u2019\
        s consumer guide."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.32.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:3
      ref_id: 12.1.32.C.01
      name: 'Control -  All Classifications - Must [CID: 3299]'
      description: Agencies MUST check consumer guides for products, where available,
        to determine any product specific requirements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.32.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:3
      ref_id: 12.1.32.C.02
      name: 'Control -  All Classifications - Must [CID: 3304]'
      description: Where product specific requirements exist in a consumer guide,
        agencies MUST comply with the requirements outlined in the consumer guide.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.32.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:3
      ref_id: 12.1.32.C.03
      name: 'Control -  All Classifications - Must [CID: 3306]'
      description: Agencies selecting high assurance products and HACE MUST contact
        the GCSB and comply with any product specific requirements, before any purchase
        is made.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Sourcing non-evaluated software
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.33.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:4
      ref_id: 12.1.33.R.01
      description: Software downloaded from websites on the Internet can contain malicious
        code or malicious content that is installed along with the legitimate software.
        Agencies need to confirm the integrity of the software they are installing
        before deploying it on a system to ensure that no unintended software is installed
        at the same time.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.33.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:4
      ref_id: 12.1.33.C.01
      name: 'Control -  All Classifications - Should [CID: 3310]'
      description: "Agencies SHOULD:\nobtain software from verifiable sources and\
        \ verify its integrity using vendor supplied checksums; and\nvalidate the\
        \ software\u2019s interaction with the operating systems and network within\
        \ a test environment prior to use on operational systems.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Delivery of evaluated products
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.R.01
      description: It is important that agencies ensure that the selected product
        is the actual product received. If the product differs from the evaluated
        version, then NO assurance can be gained from an evaluation being previously
        performed.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.R.02
      description: For products evaluated under the ITSEC or the Common Criteria scheme
        at EAL2 or higher, delivery information is available from the developer in
        the delivery procedures document.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.R.03
      description: "For products that do not have evaluated delivery procedures, it\
        \ is recommended that agencies assess whether the vendor\u2019s delivery procedures\
        \ are sufficient to maintain the integrity of the product."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.R.04
      description: 'Other factors that the assessment of the delivery procedures for
        products might consider include:

        the intended environment of the product;

        likely attack vectors;

        the types of attackers that the product will defend against;

        the resources of any potential attackers;

        the likelihood of an attack;

        the level of importance of maintaining confidentiality of the product purchase;
        and

        the level of importance of ensuring adherence to delivery timeframes.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.R.05
      description: Delivery procedures can vary greatly from product to product. For
        most products the standard commercial practice for packaging and delivery
        can be sufficient for agencies requirements. More secure delivery procedures
        can include measures to detect tampering or masquerading. Some examples of
        specific security measures include tamper evident seals, cryptographic checksums
        and signatures, and secure transportation.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.C.01
      name: 'Control -  All Classifications - Must [CID: 3318]'
      description: Agencies procuring high assurance products and HACE MUST contact
        the GCSB and comply with any product specific delivery procedures.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.34.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:5
      ref_id: 12.1.34.C.02
      name: 'Control -  All Classifications - Should [CID: 3320]'
      description: Agencies SHOULD ensure that products are delivered in a manner
        consistent with any delivery procedures defined in associated documentation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Delivery of non-evaluated products
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.35.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:6
      ref_id: 12.1.35.R.01
      description: When a non-evaluated product is purchased agencies should determine
        if the product has arrived in a state that they were expecting it to and that
        there are no obvious signs of tampering.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.35.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:6
      ref_id: 12.1.35.C.01
      name: 'Control -  All Classifications - Should [CID: 3325]'
      description: 'Agencies SHOULD ensure that products purchased without the delivery
        assurances provided through the use of formally evaluated procedures are delivered
        in a manner that provides confidence that they receive the product that they
        expect to receive in an unaltered state, including checking:

        any labelling changes;

        any damage; and

        any signs of tampering.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Leasing arrangements
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:7
      ref_id: 12.1.36.R.01
      description: Agencies should consider security and policy requirements when
        entering into a leasing agreement for IT equipment in order to avoid potential
        information security incidents during maintenance, repairs or disposal processes.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:7
      ref_id: 12.1.36.C.01
      name: 'Control -  All Classifications - Should [CID: 3330]'
      description: 'Agencies SHOULD ensure that leasing agreements for IT equipment
        takes into account the:

        difficulties that could be encountered when the equipment needs maintenance;

        control of remote maintenance, software updates and fault diagnosis;

        if the equipment can be easily sanitised prior to its return; and

        the possible requirement for destruction if sanitisation cannot be performed.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.1:7:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7
      description: Ongoing maintenance of assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:8
      ref_id: 12.1.37.R.01
      description: Developers that have demonstrated a commitment to ongoing maintenance
        or evaluation are more likely to be responsive to ensuring that security patches
        are independently assessed.
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.37.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:8
      ref_id: 12.1.37.R.02
      description: "A vendor\u2019s commitment to assurance continuity can be gauged\
        \ through the number of evaluations undertaken and whether assurance maintenance\
        \ has been performed on previous evaluations."
    - urn: urn:defend:risk:req_node:nzism-v3:12.1.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.1:7:8
      ref_id: 12.1.37.C.01
      name: 'Control -  All Classifications - Should [CID: 3337]'
      description: Agencies SHOULD choose products from developers that have made
        a commitment to the ongoing maintenance of the assurance of their product.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.2'
      name: Product Installation and Configuration
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:1
      ref_id: 12.2.1
      description: Evaluated products use evaluated configurations.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2:1
      ref_id: 12.2.2
      description: This section covers information on installing and configuring products
        providing security functionality. It does not provide information on the installation
        and configuration of general products or physical security products.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2
      description: Evaluated configuration
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2:2
      ref_id: 12.2.3
      description: "A product is considered to be operating in its evaluated configuration\
        \ if:\nfunctionality is used that was within the scope of the evaluation and\
        \ implemented in the specified manner;\nonly patches that have been assessed\
        \ through a formal assurance continuity process have been applied; and\nthe\
        \ environment complies with assumptions or organisational security policies\
        \ stated in the product\u2019s security target or similar document.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2
      description: Unevaluated configuration
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:2:3
      ref_id: 12.2.4
      description: A product is considered to be operating in an unevaluated configuration
        when it does not meet the requirements of an evaluated configuration.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3
      description: Installation and configuration of evaluated products
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      ref_id: 12.2.5.R.01
      description: An evaluation of products provides assurance that the product will
        work as expected with a clearly defined set of constraints. These constraints,
        defined by the scope of the evaluation, generally consist of what security
        functionality can be used, and how the products are configured and operated.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      ref_id: 12.2.5.R.02
      description: Using an evaluated product in manner which it was not intended
        could result in the introduction of new threats and vulnerabilities that were
        not considered by the initial evaluation.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.5.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      ref_id: 12.2.5.R.03
      description: "For products evaluated under the Common Criteria and ITSEC, information\
        \ is available from the developer in the product\u2019s installation, generation\
        \ and startup documentation. Further information is also available in the\
        \ security target and certification report."
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      ref_id: 12.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 3387]'
      description: Agencies MUST ensure that high assurance products and HACE are
        installed, configured, operated and administered in accordance with all product
        specific policy.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:1
      ref_id: 12.2.5.C.02
      name: 'Control -  All Classifications - Should [CID: 3389]'
      description: "Agencies SHOULD install, configure, operate and administer evaluated\
        \ products in accordance with available documentation resulting from the product\u2019\
        s evaluation."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3
      description: Use of evaluated products in unevaluated configurations
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:2
      ref_id: 12.2.6.R.01
      description: To ensure that a product will still provide the assurance desired
        by the agency when used in a manner for which it was not intended, a security
        risk assessment MUST be conducted upon the altered configuration. The further
        that a product deviates from its evaluated configuration, the less assurance
        can be gained from the evaluation.
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:2
      ref_id: 12.2.6.R.02
      description: "Given the potential threat vectors and the value of the classified\
        \ information being protected, high assurance products and HACE MUST be configured\
        \ in accordance with the GCSB\u2019s guidelines."
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:2
      ref_id: 12.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 3401]'
      description: 'Agencies wishing to use a product in an unevaluated configuration
        MUST undertake a security risk assessment including:

        the necessity of the unevaluated configuration;

        testing of the unevaluated configuration; and

        the environment in which the unevaluated product is to be used.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.2.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.2:3:2
      ref_id: 12.2.6.C.02
      name: 'Control -  All Classifications - Must Not [CID: 3404]'
      description: High assurance products and HACE MUST NOT be used in unevaluated
        configurations.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:12.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.3'
      name: Product Classifying and Labelling
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:1
      ref_id: 12.3.1
      description: IT equipment is classified and appropriately labelled.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:2:1
      ref_id: 12.3.2
      description: This section covers information relating to the classification
        and labelling of both evaluated and non-evaluated IT equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:2
      description: Non-essential labels
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:2:2
      ref_id: 12.3.3
      description: Non-essential labels are labels other than classification and asset
        labels.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3
      description: Classifying IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:1
      ref_id: 12.3.4.R.01
      description: "Much of today\u2019s technology incorporates an internal data\
        \ storage capability. When media is used in IT equipment there is no guarantee\
        \ that the equipment has not automatically accessed classified information\
        \ from the media and stored it locally to the device, without the knowledge\
        \ of the system user. As such, the IT equipment needs to be afforded the same\
        \ degree of protection as that of the associated media."
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:1
      ref_id: 12.3.4.C.01
      name: 'Control -  All Classifications - Must [CID: 3423]'
      description: Agencies MUST classify IT equipment based on the highest classification
        of information the equipment and any associated media within the equipment,
        are approved for processing, storing or communicating.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3
      description: Labelling IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:2
      ref_id: 12.3.5.R.01
      description: The purpose of applying protective markings to all assets in a
        secure area is to reduce the likelihood that a system user will accidentally
        input classified information into another system residing in the same area
        that is of a lower classification than the information itself.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:2
      ref_id: 12.3.5.R.02
      description: Applying protective markings to assets also assists in determining
        the appropriate usage, sanitisation, disposal or destruction requirements
        of the asset based on its classification. This is of particular importance
        in data centres and computer rooms.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:2
      ref_id: 12.3.5.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3427]'
      description: Agencies MUST clearly label all IT equipment capable of storing
        or processing classified information, with the exception of HACE, with the
        appropriate protective marking.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:2
      ref_id: 12.3.5.C.02
      name: 'Control -  All Classifications - Must [CID: 3428]'
      description: Agencies MUST clearly label all IT equipment in data centres or
        computer rooms with an asset identification and the level of classification
        to which that equipment has been accredited.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3
      description: Labelling high assurance products
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:3
      ref_id: 12.3.6.R.01
      description: High assurance products often have tamper-evident seals placed
        on their external surfaces. To assist system users in noticing changes to
        the seals, and to prevent functionality being degraded, agencies MUST limit
        the use of non-essential labels.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:3
      ref_id: 12.3.6.C.01
      name: 'Control -  All Classifications - Must Not [CID: 3431]'
      description: Agencies MUST NOT have any non-essential labels applied to external
        surfaces of high assurance products.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:12.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3
      description: Labelling HACE
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:4
      ref_id: 12.3.7.R.01
      description: HACE often have tamper-evident seals placed on their external surfaces.
        To assist system users in noticing changes to the seals, and to prevent functionality
        being degraded, agencies MUST only place seals on equipment with GCSB approval.
    - urn: urn:defend:risk:req_node:nzism-v3:12.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.3:3:4
      ref_id: 12.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 3434]'
      description: Agencies SHOULD seek GCSB authorisation before applying labels
        to external surfaces of HACE.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.4'
      name: Product Patching and Updating
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:1
      ref_id: 12.4.1
      description: "To ensure security patches are applied in a timely fashion to\
        \ manage software and firmware corrections, vulnerabilities and\_performance\
        \ risks."
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:2:1
      ref_id: 12.4.2
      description: This section covers information on patching both evaluated and
        non-evaluated software and IT equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      description: Vulnerabilities and patch availability awareness
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:1
      ref_id: 12.4.3.R.01
      description: It is important that agencies monitor relevant sources for information
        about new vulnerabilities and security patches. This way, agencies can take
        pro-active steps to address vulnerabilities in their systems.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:1
      ref_id: 12.4.3.C.01
      name: 'Control -  All Classifications - Should [CID: 3444]'
      description: Agencies SHOULD monitor relevant sources for information about
        new vulnerabilities and security patches for software and IT equipment used
        by the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      description: Patching vulnerabilities in products
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.R.01
      description: "The assurance provided by an evaluation is related to the date\
        \ at which the results were issued. Over the course of a normal product lifecycle,\
        \ patches are released to address known security vulnerabilities. Applying\
        \ these patches should be considered as part of an agency\u2019s overall risk\
        \ management strategy."
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.R.02
      description: "Given the potential threat vectors and the value of the classified\
        \ information being protected, high assurance products MUST NOT be patched\
        \ by an agency without specific direction from the GCSB. If a patch is released\
        \ for a high assurance product, the GCSB will conduct an assessment of the\
        \ patch and might revise the product\u2019s usage guidance. Likewise, for\
        \ patches released for HACE, the GCSB will subsequently conduct an assessment\
        \ of the cryptographic vulnerability and might revise usage guidance in the\
        \ consumer guide for the product."
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3448]'
      description: Agencies MUST apply all critical security patches as soon as possible
        and within two (2) days of the release of the patch or update.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.02
      name: 'Control -  All Classifications - Must [CID: 3449]'
      description: Agencies MUST implement a patch management strategy, including
        an evaluation or testing process.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.03
      name: 'Control -  All Classifications - Must Not [CID: 3450]'
      description: Agencies MUST NOT patch high assurance products or HACE without
        the patch being approved by the GCSB.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.04
      name: 'Control -  All Classifications - Should [CID: 3451]'
      description: Agencies SHOULD apply all critical security patches as soon as
        possible and preferably within two (2) days of the release of the patch or
        update.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.05
      name: 'Control -  All Classifications - Should [CID: 3452]'
      description: Agencies SHOULD apply all non-critical security patches as soon
        as possible.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.4.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:2
      ref_id: 12.4.4.C.06
      name: 'Control -  All Classifications - Should [CID: 3453]'
      description: Agencies SHOULD ensure that security patches are applied through
        a vendor recommended patch or upgrade process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      description: When security patches are not available
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:3
      ref_id: 12.4.5.R.01
      description: When a security patch is not available for a known vulnerability,
        there are a number of approaches to reducing the risk to a system. This includes
        resolving the vulnerability through alternative means, preventing exploitation
        of the vulnerability, containing the exploit or implementing measures to detect
        attacks attempting to exploit the vulnerability.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:3
      ref_id: 12.4.5.C.01
      name: 'Control -  All Classifications - Should [CID: 3455]'
      description: "Where known vulnerabilities cannot be patched, or security patches\
        \ are not available, agencies SHOULD implement:\ncontrols to resolve the vulnerability\
        \ such as:\n\ndisable the functionality associated with the vulnerability\
        \ though product configuration;\nask the vendor for an alternative method\
        \ of managing the vulnerability;\ninstall a version of the product that does\
        \ not have the identified vulnerability;\ninstall a different product with\
        \ a more responsive vendor; or\nengage a software developer to correct the\
        \ software.\n\n\ncontrols to prevent exploitation of the vulnerability including:\n\
        \napply external input sanitisation (if an input triggers the exploit);\n\
        apply filtering or verification on the software output (if the exploit relates\
        \ to an information disclosure);\napply additional access controls that prevent\
        \ access to the vulnerability; or\nconfigure firewall rules to limit access\
        \ to the vulnerable software.\n\n\ncontrols to contain the exploit including:\n\
        \napply firewall rules limiting outward traffic that is likely in the event\
        \ of an exploitation;\napply mandatory access control preventing the execution\
        \ of exploitation code; or\nset file system permissions preventing exploitation\
        \ code from being written to disk;\_\nallow and deny listing to prevent code\
        \ execution; and\n\n\ncontrols to detect attacks including:\n\ndeploy an IDS;\n\
        monitor logging alerts; or\nuse other mechanisms as appropriate for the detection\
        \ of exploits using the known vulnerability.\n\n\ncontrols to prevent attacks\
        \ including:\n\ndeploy an IPS or HIPS; or\nuse other mechanisms as appropriate\
        \ for the diversion of exploits using the known vulnerability, such as honey\
        \ pots and Null routers.\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      description: Firmware updates
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:4
      ref_id: 12.4.6.R.01
      description: As firmware provides the underlying functionality for hardware
        it is essential that the integrity of any firmware images or updates are maintained.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:4
      ref_id: 12.4.6.C.01
      name: 'Control -  All Classifications - Must [CID: 3460]'
      description: Agencies MUST ensure that any firmware updates are performed in
        a manner that verifies the integrity and authenticity of the source and of
        the updating process or updating utility.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.4:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3
      description: Unsupported products
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:5
      ref_id: 12.4.7.R.01
      description: Once a cessation date for support is announced for software or
        IT equipment, agencies will increasingly find it difficult to protect against
        vulnerabilities found in the software or IT equipment as no security patches
        will be made available by the manufacturer after support ceases.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:5
      ref_id: 12.4.7.R.02
      description: Once a cessation date for support is announced agencies should
        assess the timeline, investigate new solutions that will be appropriately
        supported and establish a plan to implement the new solution.
    - urn: urn:defend:risk:req_node:nzism-v3:12.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.4:3:5
      ref_id: 12.4.7.C.01
      name: 'Control -  All Classifications - Should [CID: 3465]'
      description: Agencies SHOULD assess the security risk of continued use of software
        or IT equipment when a cessation date for support is announced or when the
        product is no longer supported by the developer.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.5'
      name: Product Maintenance and Repairs
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:1
      ref_id: 12.5.1
      description: Products are repaired by cleared or appropriately escorted personnel.
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:2:1
      ref_id: 12.5.2
      description: This section covers information on maintaining and repairing both
        evaluated and non-evaluated IT equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3
      description: Maintenance and repairs
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:1
      ref_id: 12.5.3.R.01
      description: Making unauthorised repairs to high assurance products or HACE
        can impact the integrity of the product or equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.3.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:1
      ref_id: 12.5.3.R.02
      description: "Using cleared technicians on-site at an agency\u2019s facilities\
        \ is considered the most desired approach to maintaining and repairing IT\
        \ equipment. This ensures that if classified information is disclosed during\
        \ the course of maintenance or repairs, the technicians are aware of the protection\
        \ requirements for the information."
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:1
      ref_id: 12.5.3.C.01
      name: 'Control -  All Classifications - Must [CID: 3481]'
      description: Agencies MUST seek GCSB approval before undertaking any repairs
        to high assurance products or HACE.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:1
      ref_id: 12.5.3.C.02
      name: 'Control -  All Classifications - Should [CID: 3483]'
      description: Maintenance and repairs of IT equipment containing media SHOULD
        be carried out on-site by an appropriately cleared technician.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3
      description: Maintenance and repairs by an uncleared technician
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      ref_id: 12.5.4.R.01
      description: "Agencies choosing to use uncleared technicians to maintain or\
        \ repair IT equipment on-site at an agency\u2019s facilities, or off-site\
        \ at a company\u2019s facilities, should be aware of the requirement for cleared\
        \ personnel to escort the uncleared technicians during maintenance or repair\
        \ activities."
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      ref_id: 12.5.4.C.01
      name: 'Control -  All Classifications - Must [CID: 3492]'
      description: 'If an uncleared technician is used to undertake maintenance or
        repairs of IT equipment, the technician MUST be escorted by someone who:

        is appropriately cleared and briefed;

        takes due care to ensure that classified information is not disclosed;

        takes all responsible measures to ensure the integrity of the equipment; and

        has the authority to direct the technician.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      ref_id: 12.5.4.C.02
      name: 'Control -  All Classifications - Should [CID: 3493]'
      description: If an uncleared technician is used to undertake maintenance or
        repairs of IT equipment, agencies SHOULD sanitise and reclassify or declassify
        the equipment and associated media before maintenance or repair work is undertaken.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.4.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      ref_id: 12.5.4.C.03
      name: 'Control -  All Classifications - Should [CID: 3494]'
      description: Agencies SHOULD ensure that the ratio of escorts to uncleared technicians
        allows for appropriate oversight of all activities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.4.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:2
      ref_id: 12.5.4.C.04
      name: 'Control -  All Classifications - Should [CID: 3495]'
      description: If an uncleared technician is used to undertake maintenance or
        repairs of IT equipment, the technician SHOULD be escorted by someone who
        is sufficiently familiar with the product to understand the work being performed.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3
      description: Off-site maintenance and repairs
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:3
      ref_id: 12.5.5.R.01
      description: "Agencies choosing to have IT equipment maintained or repaired\
        \ off-site need to be aware of requirements for the company\u2019s off-site\
        \ facilities to be approved to process and store the products at the appropriate\
        \ classification."
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:3
      ref_id: 12.5.5.R.02
      description: Agencies choosing to have IT equipment maintained or repaired off-site
        can sanitise, declassify or lower the classification of the product prior
        to transport and subsequent maintenance or repair activities, to lower the
        physical transfer, processing and storage requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:3
      ref_id: 12.5.5.C.01
      name: 'Control -  All Classifications - Must [CID: 3498]'
      description: Agencies having IT equipment maintained or repaired off-site MUST
        ensure that the physical transfer, processing and storage requirements are
        appropriate for the classification of the product and are maintained at all
        times.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.5:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3
      description: Maintenance and repair of IT equipment from secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:4
      ref_id: 12.5.6.R.01
      description: Where equipment is maintained or repaired offsite, agencies should
        identify any co-located equipment of a higher classification. This higher
        classification equipment may be at risk of compromise from modifications or
        repairs to the lower classification equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:4
      ref_id: 12.5.6.C.01
      name: 'Control -  All Classifications - Should [CID: 3504]'
      description: Offsite repairs and maintenance SHOULD treat all equipment in accordance
        with the requirements for the highest classification of information processed,
        stored or communicated in the area that the equipment will be returned to.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.5.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.5:3:4
      ref_id: 12.5.6.C.02
      name: 'Control -  All Classifications - Should [CID: 3507]'
      description: Agencies SHOULD conduct or arrange to have technical inspections
        conducted on all equipment returned to the secure area after maintenance or
        repair.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.6'
      name: Product Sanitisation and Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:1
      ref_id: 12.6.1
      description: All IT equipment is sanitised and disposed of in an approved and
        secure manner.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:2:1
      ref_id: 12.6.2
      description: "This section covers information on sanitising and disposing of\
        \ both evaluated and non-evaluated IT equipment. Additional information on\
        \ the sanitisation, destruction and disposal of media can be found in Chapter\
        \ 13 \u2013 Media and IT equipment management, decommissioning and disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:2:1
      ref_id: 12.6.3
      description: Media typically found installed in IT equipment are electrostatic
        memory devices such as laser printer cartridges and photocopier drums, non-volatile
        magnetic memory such as hard disks, non-volatile semi-conductor memory such
        as flash cards and volatile memory such as RAM cards. Some technologies, such
        as an FPGA, may integrate memory capabilities.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Sanitisation or destruction of IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:1
      ref_id: 12.6.4.R.01
      description: "In order to prevent the disclosure of classified information into\
        \ the public domain agencies will need to ensure that IT equipment is either\
        \ sanitised or destroyed before being declassified and authorised for released\
        \ into the public domain. Refer also to Chapter 13 - Media and\_IT Equipment\
        \ Management, Decommissioning and Disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:1
      ref_id: 12.6.4.C.01
      name: 'Control -  All Classifications - Must [CID: 3537]'
      description: "Agencies MUST sanitise or destroy, then declassify, IT equipment\
        \ containing any\_media before disposal."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:1
      ref_id: 12.6.4.C.02
      name: 'Control -  All Classifications - Must [CID: 3540]'
      description: IT equipment and associated media that have processed or stored
        NZEO information, and cannot be sanitised, MUST be returned to New Zealand
        for sanitisation or destruction, declassification and disposal.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Disposal of IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.R.01
      description: When disposing of IT equipment, agencies need to sanitise or destroy
        and subsequently declassify any media within the product that are capable
        of storing classified information. Once the media have been removed from the
        product it can be considered sanitised. Following subsequent approval for
        declassification from the owner of the information previously processed by
        the product, it can be disposed of by the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.R.02
      description: The GCSB provides specific advice on how to securely dispose of
        high assurance products, HACE and TEMPEST rated equipment. There are a number
        of security risks that can occur due to improper disposal, including providing
        an attacker with an opportunity to gain insight into government capabilities.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.C.01
      name: 'Control -  All Classifications - Must [CID: 3545]'
      description: Agencies MUST have a documented process for the disposal of IT
        equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.C.02
      name: 'Control -  All Classifications - Must [CID: 3547]'
      description: Agencies MUST contact the GCSB and comply with any requirements
        for the disposal of high assurance products.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.C.03
      name: 'Control -  All Classifications - Must [CID: 3549]'
      description: Agencies MUST contact the GCSB and comply with any requirements
        for the disposal of HACE.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.C.04
      name: 'Control -  All Classifications - Must [CID: 3550]'
      description: Agencies MUST contact GCSB and comply with any requirements for
        the disposal of TEMPEST rated IT equipment or if the equipment is non-functional.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.5.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:2
      ref_id: 12.6.5.C.05
      name: 'Control -  All Classifications - Must [CID: 3552]'
      description: Agencies MUST formally sanitise and then authorise the disposal
        of IT equipment, or waste, into the public domain.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Sanitising printer cartridges and copier drums
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:3
      ref_id: 12.6.6.R.01
      description: Electrostatic drums can retain an image of recently printed documents
        providing opportunity for unauthorised access to information. Some printer
        cartridges may have integrated drums. Printing random text with no blank areas
        on each colour printer cartridge or drum ensures that no residual information
        will be kept on the drum or cartridge.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:3
      ref_id: 12.6.6.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3555]'
      description: Agencies MUST print at least three pages of random text with no
        blank areas on each colour printer cartridge with an integrated drum or separate
        copier drum.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:3
      ref_id: 12.6.6.C.02
      name: 'Control -  All Classifications - Should [CID: 3557]'
      description: Agencies SHOULD print at least three pages of random text with
        no blank areas on each colour printer cartridge with an integrated drum or
        separate copier drum.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Destroying printer cartridges and copier drums
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:4
      ref_id: 12.6.7.R.01
      description: When printer cartridges with integrated copier drums or discrete
        drums cannot be sanitised due to a hardware failure, or when they are empty,
        there is no other option available but to destroy them.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:4
      ref_id: 12.6.7.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3561]'
      description: Agencies unable to sanitise printer cartridges with integrated
        copier drums or discrete copier drums, MUST destroy the cartridge or drum.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:4
      ref_id: 12.6.7.C.02
      name: 'Control -  All Classifications - Should [CID: 3563]'
      description: Agencies unable to sanitise printer cartridges with integrated
        copier drums or discrete copier drums, SHOULD destroy the cartridge or drum.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Disposal of televisions and monitors
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:5
      ref_id: 12.6.8.R.01
      description: Turning up the brightness to the maximum level on video screens
        will allow agencies to easily determine if information has been burnt in or
        persists upon the screen.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:5
      ref_id: 12.6.8.C.01
      name: 'Control -  All Classifications - Must [CID: 3566]'
      description: Agencies MUST visually inspect video screens by turning up the
        brightness to the maximum level to determine if any classified information
        has been burnt into or persists on the screen, before redeployment or disposal.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: Sanitising televisions and monitors
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:6
      ref_id: 12.6.9.R.01
      description: All types of video screens are capable of retaining classified
        information on the screen if appropriate mitigation measures are not taken
        during the lifetime of the screen. CRT monitors and plasma screens can be
        affected by burn-in whilst LCD screens can be affected by image persistence
        which can led to LED/OLED burn-in.
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:6
      ref_id: 12.6.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3572]'
      description: Agencies MUST attempt to sanitise video screens with minor burn-in
        or image persistence by displaying a solid white image on the screen for an
        extended period of time. If burn-in cannot be corrected the screen MUST be
        processed through an approved destruction facility.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.6:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3
      description: LCD/LED, plasma and non-CRT monitor types
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:7
      ref_id: 12.6.10.R.01
      description: "Current generations of monitors incorporate controllers to manage\
        \ power up/power down, manage the display, operate any USB or other ports\
        \ and manage the video data stream.\_ The controller requires memory to operate\
        \ and it incorporates some data storage capability and full write/read access\
        \ to the display.\_ It also retains settings and configuration.\_ The underlying\
        \ technology is often based on an FPGA and invariably requires some form of\
        \ memory capability in order to operate.\_   Researchers have demonstrated\
        \ that images can be recovered by directly accessing the controller and associated\
        \ memory or analysing the orientation of the liquid crystals.In addition monitors\
        \ can be compromised to actively monitor or covertly steal data and even manipulate\
        \ what is displayed on the screen.\_ Other attacks exploiting monitors have\
        \ also been demonstrated."
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:7
      ref_id: 12.6.10.R.02
      description: "Refer to Chapter 12 \u2013 Product Security and Chapter 13 \u2013\
        \ Media & IT Equipment Management, Decommissioning and Disposal for additional\
        \ guidance."
    - urn: urn:defend:risk:req_node:nzism-v3:12.6.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.6:3:7
      ref_id: 12.6.10.C.01
      name: 'Control -  All Classifications - Must [CID: 6997]'
      description: Because of the risks that data can be recovered from monitors,
        it is essential that any redeployment or disposal of monitors MUST follow
        the guidance in the NZISM.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:12
      ref_id: '12.7'
      name: Supply Chain
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:1
      ref_id: 12.7.1
      description: "Technology\_supply chains are established and managed to ensure\
        \ continuity of supply and protection of sensitive related information."
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:1
      ref_id: 12.7.2
      description: The NZISM provides additional guidance for managing supply chain
        security risks associated with the acquisition (lease or purchase) of ICT
        equipment or services for use in NZ Government systems.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Supply chain
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:2
      ref_id: 12.7.3
      description: A supply chain is the movement of materials as they move from their
        source (raw materials) through manufacture to the end customer. A supply chain
        can include materials acquisition, purchasing, design, manufacturing, warehousing,
        transportation, customer service, and supply chain management. It requires
        people, information and resources to move a product from manufacturer to supplier
        to customer. Every supply chain carries some risk which may include product
        protection; counterfeit products and goods and defective products. ICT supply
        chains are invariably global and complex.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:2
      ref_id: 12.7.4
      description: 'Relationships with external service providers are established
        in a variety of ways, for example, through joint ventures, business partnerships,
        outsourcing arrangements (e.g. through supply contracts, interagency agreements,
        lines of business arrangements, service-level agreements), licensing agreements,
        and/or supply chain exchanges. The growing use of external service providers
        and new relationships being established with those providers present new and
        difficult challenges for organisations, especially in the area of information
        system security. These challenges include:

        Defining the types of external information system services provided to organisations;

        Describing how those external services are protected; and

        Obtaining the necessary assurances that the risks to organisational operations
        and assets, individuals, other organisations, and national security arising
        from the use of the external services are acceptable.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Supply chain risk
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:3
      ref_id: 12.7.5
      description: The degree of confidence that the risk from using external services
        is at an acceptable level depends on the assurance external organisations
        provide and trust that organisations place in external service providers.
        In some cases, the level of trust is based on the amount of direct control
        organisations are able to exert on external service providers in the use of
        security controls and assurance on the effectiveness of those controls.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:3
      ref_id: 12.7.6
      description: The level of control is usually established by the terms and conditions
        of the contracts or service-level agreements with the external service providers
        and can range from extensive control (e.g., negotiating contracts or agreements
        that specify detailed security requirements for the providers) to very limited
        control (e.g., using contracts or service-level agreements to obtain commodity
        services such as commercial telecommunications services).
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:3
      ref_id: 12.7.7
      description: "From an Information Assurance viewpoint, there are five key aspects\
        \ to supply chain risk:\nProtection of sensitive information and systems;\n\
        Continuity of supply;\_\nProduct assurance;\nSecurity validation; and\nNational\
        \ Procurement Policy\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Protection of sensitive information and systems
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:4
      ref_id: 12.7.8
      description: This relates to the security of the supply chain, products and
        information relating to the intended use, purchaser, location and type of
        equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Continuity of supply
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:5
      ref_id: 12.7.9
      description: This is the traditional set of risks associated with supply chain.
        As supply chains have globalised and components are sourced from a number
        of countries, a disruption to supply may have a global effect.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Product assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:6
      ref_id: 12.7.10
      description: This relates to assurance that the product, technology or device
        performs as designed and specified and includes the provenance of the product,
        equipment, or device.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: Security validation
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:7
      ref_id: 12.7.11
      description: Security validation checks the performance and security of the
        equipment. The security design elements and features of the equipment or product
        will need to be separately considered from any operational drivers.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2
      description: National procurement policy
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:2:8
      ref_id: 12.7.12
      description: "All agencies are required to follow the guidance of the Government\
        \ Rules of Procurement. Some exemptions are permitted under Rule 13 including\
        \ that of security, \u201Cessential security interests: Measures necessary\
        \ for the protection of essential security interests, procurement indispensable\
        \ for national security or for national defence\u2026\u201D. Care must be\
        \ taken to follow these rules wherever possible."
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:3
      ref_id: 12.7.13
      description: "While NOT an exhaustive list, further information on procurement\
        \ and supply chain can be found at:\n\n\nReference\_\nTitle\nPublisher\nSource\n\
        \n\n\_\n\nGovernment Use of Offshore Information and Communication Technologies\
        \ (ICT) Service Providers - Advice on Risk Management April 2009\n\nState\
        \ Services Commission\n1135964_1 (otago.ac.nz)\n\n\n\_\nThe new Government\
        \ Rules of Sourcing\nProcurement.govt.NZ\n\n\u200B\u200BGovernment Procurement\
        \ Rules - Rules for sustainable and inclusive procurement\nGovernment Procurement\
        \ Rules | New Zealand Government Procurement and Property\n\n\n\n\_\n\nGovernment\
        \ Rules of Sourcing - Rules for planning your procurement, approaching the\
        \ market and contracting\n\nMinistry of Business Innovation and Employment\n\
        Procurement | New Zealand Government Procurement and Property\n\n\n\nSP\_\
        800-161\n\n\nSpecial Publication, Supply Chain Risk Management\n\nComputer\
        \ Security Division, Information Technology Laboratory, National Institute\
        \ of Standards and Technology (NIST)\nhttp://csrc.nist.gov/publications/drafts/800-161/sp800_161_draft.pdf\
        \ [PDF, 3.1 MB]\n\n\nSP\_800-53 Revision 4\nSpecial Publication, Security\
        \ and Privacy Controls for Federal Information Systems and Organizations\n\
        NIST\nhttp://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf\
        \ [PDF, 5.1 MB]\n\n\nNISTIR 7622\nNotional Supply Chain Risk Practices for\
        \ Federal Information Systems\_\nNIST\nhttp://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7622.pdf\
        \ [PDF, 2.9 MB]\n\n\n\_\n\nCommercial Procurement & Relationships\_\n\nUK\
        \ Cabinet Office\nhttps://www.gov.uk/government/organisations/cabinet-office\n\
        \n\n\_\nCIO Council Government ICT Offshoring (International Sourcing) Guidance\n\
        UK Cabinet Office\nhttps://www.gov.uk/government/publications/government-ict-offshoring-international-sourcing-guidance\n\
        \n\n\_\nCommonwealth Procurement Rules\nDepartment of Finance and deregulation\
        \ (Financial Management Group)\n\nCommonwealth Procurement Rules | Department\
        \ of Finance \nhttps://www.finance.gov.au/sites/default/files/2022-06/CPRs\
        \ 1 July 2022.pdf\_\n\n\n\nISO 31000:2018\nRisk management \u2013 Guidelines\n\
        \nISO\n\_\n\nhttps://www.iso.org/standard/65694.html\n\_\n\n\n\nHB 231:2004\n\
        Information Security Risk Management Guidelines\n\nStandards NZ\n\nhttps://standards.govt.nz/shop/hb-2312004/\n\
        \n\nISO Guide 73:2009\nRisk management - Vocabulary\nISO\_\n\_\n\nhttps://www.iso.org/standard/44651.html\n\
        \_\n\n\n\nISO/IEC 31010:2009\nRisk management - Risk assessment techniques\n\
        ISO\n\_\n\n\nhttps://www.iso.org/standard/51073.html\n\n\n\nISO/IEC 27002:2022\n\
        \nInformation security, cybersecurity and privacy protection \u2014 Information\
        \ security controls\n\nISO/IEC\n\_\n\n\nhttps://www.iso.org/standard/75652.html\n\
        \n\n\n\nISO/IEC 27005:2012\nInformation technology - Security Techniques -\
        \ Information Security Risk Management\n\nAS/NZS\nISO/IEC\n\n\nhttps://standards.govt.nz/shop/asnzs-isoiec-270052012/\n\
        \n\n\n\nISO 28000:2007\_\nSpecification for security management systems for\
        \ the supply chain\nISO\n\_\n\n\nhttps://www.iso.org/standard/44641.html\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Risk Management
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:1
      ref_id: 12.7.14.R.01
      description: "ICT supply chains can introduce particular risks to an agency.\
        \ In order to manage these risks, in addition to other identified ICT risks,\
        \ supply chain risks are incorporated into an agency\u2019s assessment of\
        \ risk and the Security Risk Management Plan (SRMP). Identified risks are\
        \ managed through the procurement process and through technical checks and\
        \ controls (See Section 5.3 \u2013 Security Risk Management Plans and Chapter\
        \ 4 \u2013 System Certification and Accreditation)."
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:1
      ref_id: 12.7.14.C.01
      name: 'Control -  All Classifications - Should [CID: 3634]'
      description: Agencies SHOULD incorporate the consideration of supply chain risks
        into an organisation-wide risk assessment and management process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:1
      ref_id: 12.7.14.C.02
      name: 'Control -  All Classifications - Should [CID: 3638]'
      description: Agencies SHOULD monitor supply chain risks on an ongoing basis
        and adjust mitigations and controls appropriately.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.14.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:1
      ref_id: 12.7.14.C.03
      name: 'Control -  All Classifications - Should [CID: 3639]'
      description: Agencies SHOULD follow the Government Rules of Procurement.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Contractor or Supplier Capability
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:2
      ref_id: 12.7.15.R.01
      description: Agencies can assess the capability of a contractor and any subcontractors
        to meet their security of information, supply and product requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:2
      ref_id: 12.7.15.C.01
      name: 'Control -  All Classifications - Should [CID: 3644]'
      description: 'Agencies SHOULD require tenderers and contractors to provide information:

        identifying any restrictions on the disclosure, transfer or use of technology
        arising out of export controls or security arrangements; and

        demonstrating that their supply chains comply with the security of supply
        requirements set out in the contract documents.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:2
      ref_id: 12.7.15.C.02
      name: 'Control -  All Classifications - Should [CID: 3646]'
      description: Agencies SHOULD request information from contractors and subcontractors
        to assess their ability to protect information.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Security of Information
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:3
      ref_id: 12.7.16.R.01
      description: After conducting a risk assessment, agencies and suppliers have
        the means and capability to protect classified information throughout the
        tendering and contracting process.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:3
      ref_id: 12.7.16.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3651]'
      description: Agencies MUST include contractual obligations on all contractors
        and subcontractors to safeguard information throughout the tendering and contracting
        procedure.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:3
      ref_id: 12.7.16.C.02
      name: 'Control -  All Classifications - Should [CID: 3653]'
      description: Agencies SHOULD include contractual obligations to safeguard information
        throughout the tendering and contracting procedure.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:3
      ref_id: 12.7.16.C.03
      name: 'Control -  All Classifications - Should [CID: 3654]'
      description: Agencies SHOULD reject contractors and subcontractors where they
        do not possess the necessary reliability to exclude risks to national security;
        or have breached obligations relating to security of information during a
        previous contract in circumstances amounting to grave misconduct.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Continuity of Supply
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:4
      ref_id: 12.7.17.R.01
      description: 'You can also require suppliers to provide commitments on the continuity
        of supply. These can include commitments from the supplier to ensure:

        delivery time;

        stock levels;

        visibility of the supply chain; and

        supply chain resilience.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:4
      ref_id: 12.7.17.C.01
      name: 'Control -  All Classifications - Should [CID: 3658]'
      description: Agencies SHOULD ensure that changes in their supply chain during
        the performance of the contract will not adversely affect the continuity of
        supply requirements.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Product Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:5
      ref_id: 12.7.18.R.01
      description: In addition to the product selection and acquisition guidance in
        this section, agencies are able to identify and mitigate risks through supply
        chain visibility, provenance, security validation and pre-installation tests
        and checks.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.18.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:5
      ref_id: 12.7.18.R.02
      description: Agencies, with the cooperation of their suppliers, should establish
        the provenance of any products and equipment. Provenance is defined as a record
        of the origin, history, specification changes and supply path of the products
        or equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:5
      ref_id: 12.7.18.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3669]'
      description: Agencies MUST require suppliers and contractors to provide the
        provenance of any products or equipment.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:5
      ref_id: 12.7.18.C.02
      name: 'Control -  All Classifications - Should [CID: 3674]'
      description: Agencies SHOULD require suppliers and contractors to provide the
        provenance of any products or equipment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Security validation
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:6
      ref_id: 12.7.19.R.01
      description: Validation of the performance and security of the equipment is
        a vital part of the ongoing integrity and security of agency systems. The
        security design elements and features of the equipment or product will need
        to be separately considered from any operational drivers. Where compromises
        in security performance, capability or functionality are apparent, additional
        risk mitigation, controls and countermeasures may be necessary.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:6
      ref_id: 12.7.19.C.01
      name: 'Control -  All Classifications - Should [CID: 3691]'
      description: Agencies SHOULD validate the security of the equipment against
        security performance, capability and functionality requirements.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:6
      ref_id: 12.7.19.C.02
      name: 'Control -  All Classifications - Should [CID: 3693]'
      description: Where deficiencies in security performance, capability and functionality
        are identified, agencies SHOULD implement additional risk mitigation measures.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: 'Pre-Installation Tests and Checks '
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.R.01
      description: An essential part of quality and security assurance is the delivery
        inspection, pre-installation and functional testing of any equipment. In particular,
        large systems that integrate equipment from different suppliers or that have
        specialised configuration and operational characteristics may require additional
        testing to provide assurance that large scale disruptions and security compromises
        are avoided.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3698]'
      description: Agencies MUST consult with the GCSB on pre-installation, security
        verification and related tests before the equipment is used in an operational
        system.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.C.02
      name: 'Control -  All Classifications - Should [CID: 3700]'
      description: Agencies SHOULD inspect equipment on receipt for any obvious signs
        of tampering, relabelling or damage.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.C.03
      name: 'Control -  All Classifications - Should [CID: 3701]'
      description: Agencies SHOULD inspect equipment on receipt and test the operation
        before installation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.C.04
      name: 'Control -  All Classifications - Should [CID: 3703]'
      description: Agencies SHOULD conduct installation verification and related tests
        before the equipment is used in an operational system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.20.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:7
      ref_id: 12.7.20.C.05
      name: 'Control -  All Classifications - Should [CID: 3704]'
      description: Where any software, firmware or other forms of programme code are
        required for the initialisation, operation, servicing or maintenance of the
        equipment, malware checks SHOULD be conducted before the equipment is installed
        in an operational system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:12.7:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4
      description: Equipment Servicing
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:8
      ref_id: 12.7.21.R.01
      description: Some larger or complex systems can have dependencies on particular
        infrastructures, equipment, software or configurations. Although these types
        of systems can be less flexible in responding to the rapid changes in technologies,
        the risks are outweighed by the functionality of the system. In such cases,
        the continuing support and maintenance of essential components is vital.
    - urn: urn:defend:risk:req_node:nzism-v3:12.7.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:12.7:4:8
      ref_id: 12.7.21.C.01
      name: 'Control -  All Classifications - Should [CID: 3709]'
      description: 'For equipment that is expected to have an extended operational
        life in a critical system, and in the event that the supplier is no longer
        able to supply these, agencies SHOULD provide for the acquisition of:

        necessary licences;

        information to produce spare parts, components, assemblies;

        testing equipment; and

        technical assistance agreements.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13
      assessable: false
      depth: 1
      ref_id: '13'
      name: Media and IT Equipment Management, Decommissioning and Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:13.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.1'
      name: System Decommissioning
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:1
      ref_id: 13.1.1
      description: "To ensure systems\_are safely decommissioned and that software,\
        \ system logic and data are properly transitioned to new systems or archived\
        \ in accordance with agency, legal and statutory requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2:1
      ref_id: 13.1.2
      description: This section discusses the retirement and safe decommissioning
        of systems. Specific requirements on media handling, usage, sanitisation,
        destruction and disposal are discussed later in this chapter. System decommissioning
        is the retirement or termination of a system and its operations. System decommissioning
        does NOT deal with the theft or loss of equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2
      description: Definitions
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2:2
      ref_id: 13.1.3
      description: 'A system decommissioning will have one or more of the following
        characteristics:

        Ending a capability completely i.e. no migration, redevelopment or new version
        of a capability occurs;

        Combining parts of existing capabilities services into a new, different system;

        As part of wider redesign, where a capability is no longer provided and is
        decommissioned or merged with other capabilities or systems.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2:2
      ref_id: 13.1.4
      description: ICT requirements evolve as business needs change and technology
        advances. In some cases this will lead to the retirement and decommissioning
        of obsolete systems or systems surplus to requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2:2
      ref_id: 13.1.5
      description: 'Security requires a structured approach to decommissioning in
        order to cease information system operations in a planned, orderly and secure
        manner. It is also important that the approach for decommissioning systems
        is consistent and coordinated. Sanitisation is important to eliminate any
        remnant data that could be retrieved by unauthorised parties. These procedures
        include the following:

        A migration plan;

        A decommissioning plan;

        Archiving;

        Safe disposal of equipment and media;

        Robust procedures to manage any residual data and associated risk; and

        Audit and final signoff.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:2:2
      ref_id: 13.1.6
      description: As a final step, a review of the decommissioning should be undertaken
        to ensure no important elements, data or equipment have been overlooked.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:3
      ref_id: 13.1.7
      description: "\n\n\n\nReference\_\n\n\nTitle\n\nPublisher\nSource\n\n\n\_\n\n\
        Risk Management And Accreditation Of Information Systems Also Released As\
        \ HMG Infosec Standard No. 2, August 2005\n\n\nUK Centre for the Protection\
        \ of National Infrastructure (CPNI)\n\nhttp://www.cpni.gov.uk/Documents/Publications/2005/2005003-Risk_management.pdf\n\
        \n\n\nSP\_800-88\n\n\nNIST Special Publication 800-88 Guidelines for Media\
        \ Sanitization, Rev.1, December, 2014\n\n\nNational Institute of Standards\
        \ and Technology (NIST), U.S. Department of Commerce\n\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf\
        \ [PDF, 532 KB]\n\n\n\_\n\nBetter Practice Checklist \u2013 Decommissioning\
        \ Government Websites, March 2011\n\n\nAustralian Government Information Management\
        \ Office (AGIMO)\n\nhttp://agict.gov.au/policy-guides-procurement/better-practice-checklists-guidance/bpc-decommissioning\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:4
      ref_id: 13.1.8
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV3, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\n\nPSR content protocols\
        \ \n\n\nManagement protocol for information security\nManagement protocol\
        \ for physical security\n\n\n\_\nManagement protocol for information security\
        \ | Protective Security Requirements\n\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\_\n\n\n\n\nPSR requirements\
        \ sections\n\n\nHandling requirements for protectively marked information\
        \ and equipment\nSupply chain security\n\n\n\_\nClassification system | Protective\
        \ Security Requirements\n\_\n\_\nSupply chain security | Protective Security\
        \ Requirements\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Agency Policy
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:1
      ref_id: 13.1.9.R.01
      description: Information systems are often supported by service and supply contracts
        and may also be subject to obligations to provide a service, capability or
        information. Decommissioning of a system will require the termination of these
        contracts and service obligations. Other aspects of system decommission may
        be subject to security, regulatory or legislative requirements. An Agency
        policy will provide a comprehensive approach to system decommissioning from
        the inception of a system, thus facilitating the termination of supply contracts
        and service obligations while managing any risks to the Agency.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:1
      ref_id: 13.1.9.C.01
      name: 'Control -  All Classifications - Should [CID: 3829]'
      description: When the Information System reaches the end of its service life
        in an organisation, policy and procedures SHOULD be in place to ensure secure
        decommissioning and transfer or disposal, in order to satisfy corporate, legal
        and statutory requirements.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Migration plan
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      ref_id: 13.1.10.R.01
      description: Once the decision to decommission a system has been taken, it is
        important to migrate processes, data, users and licences to replacement systems
        or to cease activities in an orderly fashion. It is also important to carefully
        plan the decommissioning process in order to avoid disruption to other systems,
        ensure business continuity, ensure security, protect privacy and meet any
        archive and other regulatory and legislative requirements. The basis of a
        decommissioning plan is a risk assessment.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      ref_id: 13.1.10.C.01
      name: 'Control -  All Classifications - Should [CID: 3832]'
      description: 'Agencies SHOULD undertake a risk assessment with consideration
        given to proportionality in respect of:

        scale and impact of the processes;

        data;

        users;

        licences;

        usage agreements; and

        service to be migrated or decommissioned.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      ref_id: 13.1.10.C.02
      name: 'Control -  All Classifications - Should [CID: 3833]'
      description: 'The risk assessment SHOULD include the following elements:

        Evaluation of the applications inventory and identification of any redundancies;

        Identification of data owners and key stakeholders;

        Identification of types of information (Active or Inactive) processed and
        stored;

        Identification of software and other (including non-transferable) licences;

        Identification of access rights to be transferred or cancelled;

        Identification of any emanation control equipment or security enhancements;

        Consideration of short and long term reporting requirements;

        Assessment of equipment and hardware for redeployment or disposal;

        Identification of any cloud-based data and services; and

        User re-training.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      ref_id: 13.1.10.C.03
      name: 'Control -  All Classifications - Should [CID: 3834]'
      description: Agencies SHOULD consider the need for a Privacy Impact Assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:2
      ref_id: 13.1.10.C.04
      name: 'Control -  All Classifications - Should [CID: 3835]'
      description: Agencies SHOULD identify relevant service and legal agreements
        and arrange for their termination.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Decommissioning plan
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:3
      ref_id: 13.1.11.R.01
      description: The decommissioning of a system can be a complex process. A decommissioning
        plan is an important tool in properly managing the safe decommissioning of
        a system and in providing reasonable assurance that due process and agency
        policy has been followed.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:3
      ref_id: 13.1.11.C.01
      name: 'Control -  All Classifications - Should [CID: 3838]'
      description: 'The decommissioning plan will be based on the migration plan and
        SHOULD incorporate the following elements:

        An impact analysis;

        Issue of notification to service providers, users and customers;

        Issue of notification of decommissioning to all relevant interfaces and interconnections;

        Timeframe, plan and schedule;

        Data integrity and validation checks before archiving;

        Transfer or redeployment of equipment and other assets;

        Transfer or cancellation of licences;

        Removal of redundant equipment and software;

        Removal of redundant cables and termination equipment;

        Removal of any emanation control equipment or security enhancements;

        Return or safe disposal of any emanation control equipment or security enhancements;

        Updates to systems configurations (switches, firewalls etc.);

        Equipment and media sanitisation including any cloud-based data & services(discussed
        later in this chapter);

        Equipment and media disposal (discussed later in this chapter);

        Any legal considerations for supply or service contract terminations;

        Asset register updates; and

        Retraining for, or redeployment of, support staff.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Archiving
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      ref_id: 13.1.12.R.01
      description: Availability and integrity requirements in respect of information
        may persist for legal and other statutory or compliance reasons and require
        transfer to other ownership or custodianship for archive purposes. This will
        also require assurance that the data can continue to be accessed when required
        (availability) and assurance that it remains unchanged (integrity).
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      ref_id: 13.1.12.R.02
      description: Confidentiality requirements must also be considered. If an information
        system has been processing sensitive information or contains sensitive security
        components, which attract special handling requirements, it will require robust
        purging and overwrites or destruction. There are a number of methods and proprietary
        products available for such purposes.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      ref_id: 13.1.12.C.01
      name: 'Control -  All Classifications - Should [CID: 3842]'
      description: Agencies SHOULD identify data retention policies, regulation and
        legislation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      ref_id: 13.1.12.C.02
      name: 'Control -  All Classifications - Should [CID: 3844]'
      description: Agencies SHOULD ensure adequate system documentation is archived.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:4
      ref_id: 13.1.12.C.03
      name: 'Control -  All Classifications - Should [CID: 3845]'
      description: Agencies SHOULD archive essential software, system logic, system
        documentation and other system data to allow information to be recovered from
        archive.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Audit and Final signoff
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      ref_id: 13.1.13.R.01
      description: "Update the organisation\u2019s tracking and management systems\
        \ to identify the specific information system components that are being removed\
        \ from the inventory. To comply with governance, asset management and audit\
        \ requirements, the Agency\u2019s Accreditation Authority will certify that\
        \ appropriate processes have been followed. This demonstrates good governance\
        \ and avoids privacy breaches."
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      ref_id: 13.1.13.C.01
      name: 'Control -  All Classifications - Should [CID: 3850]'
      description: "The Agency\u2019s Accreditation Authority SHOULD confirm IA compliance\
        \ on decommissioning and disposal."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      ref_id: 13.1.13.C.02
      name: 'Control -  All Classifications - Should [CID: 3852]'
      description: "The Agency\u2019s Accreditation Authority SHOULD confirm secure\
        \ equipment and media disposal."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      ref_id: 13.1.13.C.03
      name: 'Control -  All Classifications - Should [CID: 3853]'
      description: "The Agency\u2019s Accreditation Authority SHOULD confirm asset\
        \ register updates."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:5
      ref_id: 13.1.13.C.04
      name: 'Control -  All Classifications - Should [CID: 3855]'
      description: "Once all security relevant activities associated with decommissioning\
        \ and disposal have been completed and verified, a Security Decommissioning\
        \ Compliance Certificate SHOULD be issued by the Agency\u2019s Accreditation\
        \ Authority."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.1:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5
      description: Final Review
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:6
      ref_id: 13.1.14.R.01
      description: As a final step, a review of the decommissioning should be undertaken
        to ensure no important elements, data, equipment, contractual or legislative,
        obligations have been overlooked.
    - urn: urn:defend:risk:req_node:nzism-v3:13.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.1:5:6
      ref_id: 13.1.14.C.01
      name: 'Control -  All Classifications - Should [CID: 3862]'
      description: Agencies SHOULD undertake a post-decommissioning review.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.2'
      name: Media Handling
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:1
      ref_id: 13.2.1
      description: Media is properly classified, labelled and registered in order
        to clearly indicate the required handling instructions and degree of protection
        to be applied.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:2:1
      ref_id: 13.2.2
      description: This section covers information relating to classifying, labelling
        and registering media. Information relating to classifying and labelling IT
        equipment can be found in Section 12.3 - Product Classifying and Labelling.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:2
      description: Exceptions for labelling and registering media
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:2:2
      ref_id: 13.2.3
      description: Labels are not needed for internally mounted fixed media if the
        IT equipment containing the media is labelled. Likewise fixed media does not
        need to be registered if the IT equipment containing the media is registered.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:3
      ref_id: 13.2.4
      description: "Additional information relating to media handling is contained\
        \ in:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\nISO/IEC 27001:2013\n\
        \n\n\_10.7, Media Handling\n\n\nISO\n\n\nhttps://www.iso.org/standard/54534.html\n\
        \_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:4
      ref_id: 13.2.5
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV3, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_\_\_\nPhysical security\
        \ (PHYSEC) | Protective Security Requirements\n\n\n\nPSR content protocols\
        \ \n\n\nManagement protocol for information security\nManagement protocol\
        \ for physical security\n\n\n\_\nManagement protocol for information security\
        \ | Protective Security Requirements\n\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\_\n\n\n\n\nPSR requirements\
        \ sections\n\n\nHandling requirements for protectively marked information\
        \ and equipment\nRetire information and assets securely\_\n\n\nClassification\
        \ system | Protective Security Requirements\n\_\n\_\nUnderstanding the information\
        \ security lifecycle | Protective Security Requirements\n\_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Reclassification and declassification procedures
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:1
      ref_id: 13.2.6.R.01
      description: "When reclassifying or declassifying media the process is based\
        \ on an assessment of risk, including:\nthe classification of the media and\
        \ associated handling instructions;\nthe effectiveness of any sanitisation\
        \ or destruction procedure used;\_\nthe planned redeployment; and\nthe intended\
        \ destination of the media.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:1
      ref_id: 13.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 3896]'
      description: Agencies MUST document procedures for the reclassification and
        declassification of media.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Classifying media storing information
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:2
      ref_id: 13.2.7.R.01
      description: Media that is not classified or not correctly classified may be
        stored, identified and handled inappropriately.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:2
      ref_id: 13.2.7.R.02
      description: Incorrect or no classification may result in access by a person
        or persons without the appropriate security clearance.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:2
      ref_id: 13.2.7.C.01
      name: 'Control -  All Classifications - Must [CID: 3904]'
      description: Agencies MUST classify media to the highest classification of data
        stored on the media.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Classifying media connected to systems of higher classifications
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:3
      ref_id: 13.2.8.R.01
      description: Unless connected through a data diode or similar infrastructure,
        there is no guarantee that classified information was not copied to the media
        while it was connected to a system of higher classification than the classification
        level of the media itself.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:3
      ref_id: 13.2.8.C.01
      name: 'Control -  All Classifications - Must [CID: 3910]'
      description: Agencies MUST classify any media connected to a system of a higher
        classification at the higher system classification until confirmed not to
        be the case.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Classifying media below that of the system
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:4
      ref_id: 13.2.9.R.01
      description: When sufficient assurance exists that information cannot be written
        to media that is used with a system, then the media can be treated in accordance
        with the handling instructions of the classification of the information it
        stores rather than the classification of the system it is connected to or
        used with.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:4
      ref_id: 13.2.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3915]'
      description: 'Agencies intending to classify media below the classification
        of the system to which it is connected to MUST ensure that:

        the media is read-only;

        the media is inserted into a read-only device; or

        the system has a mechanism through which read-only access can be assured such
        as approved data diodes, write-blockers or similar infrastructure.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Reclassifying media to a lower classification
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:5
      ref_id: 13.2.10.R.01
      description: "Agencies must follow the reclassification process as illustrated\
        \ in Section 13.6 \u2013 Media Disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:5
      ref_id: 13.2.10.C.01
      name: 'Control -  All Classifications - Must [CID: 3922]'
      description: 'Agencies wishing to reclassify media to a lower classification
        MUST ensure that:

        a formal decision is made to reclassify, or redeploy the media; and

        the reclassification of all information on the media has been approved by
        the originator, or the media has been appropriately sanitised or destroyed.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Reclassifying media to a higher classification
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:6
      ref_id: 13.2.11.R.01
      description: The media will always need to be protected in accordance with the
        classification of the information it stores. As such, if the classification
        of the information on the media changes, then so will the classification of
        the media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:6
      ref_id: 13.2.11.C.01
      name: 'Control -  All Classifications - Must [CID: 3979]'
      description: 'Agencies MUST reclassify media if:

        information copied onto the media is of a higher classification; or

        information contained on the media is subjected to a classification upgrade.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Labelling media
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      ref_id: 13.2.12.R.01
      description: Labelling helps all personnel to identify the classification of
        media and ensure that they afford the media the correct protection measures.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      ref_id: 13.2.12.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3982]'
      description: Agencies MUST label media with a marking that indicates the maximum
        classification and any endorsements applicable to the information stored.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      ref_id: 13.2.12.C.02
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3983]'
      description: Agencies MUST ensure that the classification of all media is easily
        visually identifiable.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      ref_id: 13.2.12.C.03
      name: 'Control -  All Classifications - Must [CID: 3984]'
      description: When using non-textual (colour, symbol) protective markings for
        operational security reasons, agencies MUST document the labelling scheme
        and train personnel appropriately.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.12.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:7
      ref_id: 13.2.12.C.04
      name: 'Control -  All Classifications - Should [CID: 3985]'
      description: Agencies SHOULD label media with a marking that indicates the maximum
        classification and any endorsements applicable to the information stored.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Labelling sanitised media
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:8
      ref_id: 13.2.13.R.01
      description: "It is not possible to effectively sanitise and subsequently reclassify\
        \ SECRET or TOP SECRET non-volatile media to a classification lower than SECRET.\
        \ Media of other classifications may be reclassified (See Section 13.6 \u2013\
        \ Media Disposal)."
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:8
      ref_id: 13.2.13.C.01
      name: 'Control -  Secret, Top Secret - Must [CID: 3988]'
      description: 'Agencies MUST label non-volatile media that has been sanitised
        and reclassified for redeployment with a notice similar to:Warning: media
        has been sanitised and reclassified from [classification] to [classification].
        Further lowering of classification only via destruction.'
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2:5:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5
      description: Registering media
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:9
      ref_id: 13.2.14.R.01
      description: If agencies fail to register media with an appropriate identifier
        they will not be able to effectively keep track of their classified media
        and there will be a greater likelihood of unauthorised disclosure of classified
        information.
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:9
      ref_id: 13.2.14.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3991]'
      description: Agencies MUST register all media with a unique identifier in an
        appropriate register.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.2.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.2:5:9
      ref_id: 13.2.14.C.02
      name: 'Control -  All Classifications - Should [CID: 3992]'
      description: Agencies SHOULD register all media with a unique identifier in
        an appropriate register.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.3'
      name: Media Usage
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:1
      ref_id: 13.3.1
      description: Media is used with systems in a controlled and accountable manner.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:2:1
      ref_id: 13.3.2
      description: This section covers information on using media with systems. Further
        information on using media to transfer data between systems can be found in
        Section 20.1 - Data Transfers.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:3
      ref_id: 13.3.3
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV3, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\n\nHome | Protective Security\
        \ Requirements\nSecurity governance (GOV) | Protective Security Requirements\n\
        Information security (INFOSEC) | Protective Security Requirements/\_\_\_\n\
        Physical security (PHYSEC) | Protective Security Requirements\n\n\nPSR content\
        \ protocols \n\nManagement protocol for information security\nManagement protocol\
        \ for physical security\n\n\nManagement protocol for information security\
        \ | Protective Security Requirements\n\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \nHandling requirements for protectively marked information and equipment\n\
        Retire information and assets securely\n\n\nClassification system | Protective\
        \ Security Requirements\n\_\n\_\nUnderstanding the information security lifecycle\
        \ | Protective Security Requirements\n\_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Using media with systems
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:1
      ref_id: 13.3.4.R.01
      description: To prevent classified data spills agencies will need to prevent
        classified media from being connected to, or used with, systems of a lesser
        classification than the protective marking of the media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:1
      ref_id: 13.3.4.R.02
      description: "Where media is used for backup purposes, the media will be certified\
        \ for use at the highest level of classification to be backed-up. Refer also\
        \ to Section 6.4 \u2013 Business Continuity and Disaster Recovery."
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:1
      ref_id: 13.3.4.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 4075]'
      description: Agencies MUST NOT use media containing classified information with
        a system that has a classification lower than the classification of the media.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Storage of media
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:2
      ref_id: 13.3.5.R.01
      description: The security requirements for storage and physical transfer of
        classified information and IT equipment are specified in the Protective Security
        Requirements (PSR).
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:2
      ref_id: 13.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 4078]'
      description: Agencies MUST ensure that storage facilities for media containing
        classified information meets the minimum physical security storage requirements
        as specified in the Protective Security Requirements (PSR).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Connecting media to systems
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.R.01
      description: Some operating systems provide functionality to automatically execute
        or read certain types of programs that reside on optical media and flash memory
        media when connected. While this functionality was designed with a legitimate
        purpose in mind, such as automatically loading a graphical user interface
        for the system user to browse the contents of the media, or to install software
        residing on the media, it can also be used for malicious purposes.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.R.02
      description: "An attacker can create a file on optical media or a connectable\
        \ device that the operating system will attempt to automatically execute.\
        \ \_When the operating system executes the file, it can have the same effect\
        \ as when a system user explicitly executes malicious code. \_The operating\
        \ system executes the file without asking the system user for permission."
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.R.03
      description: Some operating systems will cache information on media to improve
        performance. As such, inserting media of a higher classification into a system
        of a lower classification could cause data to be read and saved from the device
        without user intervention.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.R.04
      description: Using device access control software will prevent unauthorised
        media from being attached to a system. Using an allow listing approach gives
        security personnel greater control over what can, and what cannot, be connected
        to the system.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4086]'
      description: Agencies MUST disable any automatic execution features within operating
        systems for connectable devices and media.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.C.02
      name: 'Control -  All Classifications - Must [CID: 4089]'
      description: "Agencies MUST prevent unauthorised media from connecting to a\
        \ system via the use of:\ndevice access control software;\nseals;\nphysical\
        \ means; or\_\nother methods approved by the Accreditation Authority.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:3
      ref_id: 13.3.6.C.03
      name: 'Control -  All Classifications - Should [CID: 4091]'
      description: When writable media is connected to a writable communications port
        or device, agencies SHOULD implement controls to prevent the unintended writing
        of data to the media.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: IEEE 1394 (FIREWIRE) interface connections
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:4
      ref_id: 13.3.7.R.01
      description: Known vulnerabilities have been demonstrated where attackers can
        connect a FireWire capable device to a locked workstation and modify information
        in RAM to gain access to encryption keys. Furthermore, as FireWire provides
        direct access to the system memory, an attacker can read or write directly
        to memory.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:4
      ref_id: 13.3.7.R.02
      description: The best defence against this vulnerability is to disable access
        to FireWire ports using either software controls or physically disabling the
        FireWire ports so that devices cannot be connected. Alternatively select equipment
        without FireWire capability.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:4
      ref_id: 13.3.7.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 4096]'
      description: Agencies MUST disable IEEE 1394 interfaces.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:4
      ref_id: 13.3.7.C.02
      name: 'Control -  All Classifications - Should [CID: 4097]'
      description: Agencies SHOULD disable IEEE 1394 interfaces.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Transferring media
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      ref_id: 13.3.8.R.01
      description: As media is often transferred through areas not certified to process
        the level of classified information on the media, additional protection mechanisms
        need to be implemented.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      ref_id: 13.3.8.R.02
      description: Applying encryption to media may reduce the requirements for storage
        and physical transfer as outlined in the PSR. The reduction of any requirements
        is based on the original classification of information residing on the media
        and the level of assurance in the cryptographic product being used to encrypt
        the media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      ref_id: 13.3.8.R.03
      description: Further information on reducing storage and physical transfer requirements
        can be found in Section 17.1 - Cryptographic Fundamentals.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      ref_id: 13.3.8.C.01
      name: 'Control -  All Classifications - Must [CID: 4102]'
      description: Agencies MUST ensure that processes for transferring media containing
        classified information meets the minimum physical transfer requirements as
        specified in the PSR.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:5
      ref_id: 13.3.8.C.02
      name: 'Control -  All Classifications - Should [CID: 4103]'
      description: "Agencies SHOULD encrypt data stored on media with at least an\
        \ Approved Cryptographic Algorithm (See Section 17.2 \u2013 Approved Cryptographic\
        \ Algorithms) if it is to be transferred to another area or location."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Using media for data transfers
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:6
      ref_id: 13.3.9.R.01
      description: Agencies transferring data between systems of different security
        domains or classifications are strongly encouraged to use media such as write-once
        CDs and DVDs. This will limit opportunity for information from the higher
        classified systems to be accidently transferred to lower classified systems.
        This procedure will also make each transfer a single, auditable event.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:6
      ref_id: 13.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 4111]'
      description: Data transfers between systems of different classification SHOULD
        be logged in an auditable log or register.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:6
      ref_id: 13.3.9.C.02
      name: 'Control -  All Classifications - Should Not [CID: 4114]'
      description: Agencies transferring data manually between two systems of different
        security domains or classifications SHOULD NOT use rewriteable media.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.3:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4
      description: Media in secure areas
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:7
      ref_id: 13.3.10.R.01
      description: Certain types of media including USB, FireWire and eSATA capable
        devices MUST be disabled or explicitly approved as an exception by the Accreditation
        Authority for a TOP SECRET environment (the GCSB). This provides an additional
        level of system user awareness and security.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:7
      ref_id: 13.3.10.R.02
      description: This practice should be used in addition to device access control
        software on workstations in case system users are unaware of, or choose to
        ignore, security requirements for media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.3:4:7
      ref_id: 13.3.10.C.01
      name: 'Control -  Top Secret - Must Not [CID: 4121]'
      description: Agencies MUST NOT permit any media that uses external interface
        connections within a TOP SECRET area without prior written approval from the
        Accreditation Authority.
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.4'
      name: Media and IT Equipment Sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:1
      ref_id: 13.4.1
      description: Media and IT Equipment that is to be redeployed or is no longer
        required is sanitised.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:1
      ref_id: 13.4.2
      description: This section covers information relating to sanitising media and
        IT Equipment. Further information relating to sanitising IT equipment can
        be found in Section 12.6 - Product Sanitisation and Disposal.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: Definition
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:2
      ref_id: 13.4.3
      description: "Sanitisation is defined as the process of removal of data and\
        \ information from the storage device such that data recovery using any known\
        \ technique or analysis is prevented or made unfeasible. The process includes\
        \ the removal of all useful data from the storage device, including metadata,\
        \ as well as the removal of all labels, markings, classifications and\_activity\
        \ logs. Methods vary depending upon the nature, technology used and construction\
        \ of the storage device or equipment and may include degaussing, incineration,\
        \ shredding, grinding, knurling or embossing and chemical immersion."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: 'Sanitising media and IT Equipment '
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:3
      ref_id: 13.4.4
      description: "The process of sanitisation does not automatically change the\
        \ classification of the media\_or IT Equipment, nor does sanitisation necessarily\
        \ involve the destruction of media\_or IT Equipment."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: Product selection
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:4
      ref_id: 13.4.5
      description: Agencies are permitted to use non-evaluated products to sanitise
        media and IT Equipment. However, the product will still need to meet the specifications
        and achieve the requirements for sanitising media and IT Equipment as outlined
        in this section.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: Hybrid hard drives, Solid State Drives and Flash Memory Devices
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:5
      ref_id: 13.4.6
      description: Hybrid hard drives, solid state drives and flash memory devices
        are difficult or impossible to sanitise effectively. In most cases safe disposal
        will require destruction, this includes any equipment with integrated memory
        capability. The sanitisation and post sanitisation treatment requirements
        for redeployment of such devices should be carefully observed.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2
      description: New Zealand Eyes Only (NZEO) Materials
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:2:6
      ref_id: 13.4.7
      description: NZEO endorsed material requires additional protection at every
        level of classification. In general terms, media and IT Equipment containing
        NZEO material should be sanitised and redeployed or sanitised and destroyed
        in accordance with the procedures in this section. Media and IT Equipment
        that has contained NZEO material must not be disposed of to e-recyclers or
        sold to any third party.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:3
      ref_id: 13.4.8
      description: "\n\n\n\nReference\n\n\nTitle\n\nPublisher\nSource\n\n\n\_\n\n\
        Data Remanence in Semiconductor Devices\n\n\nPeter Gutmann\nIBM T.J.Watson\
        \ Research Center\n\nhttp://www.cypherpunks.to/~peter/usenix01.pdf\n\n\n\_\
        \n\nRAM testing tool memtest86+\n\n\_\nhttps://www.memtest.org/\n\n\n\_\n\n\
        MemtestG80 and MemtestCL: Memory Testers for CUDA- and OpenCL-enabled GPUs\n\
        \n\nSimbios project funded by the National Institutes of Health\n\nhttps://simtk.org/home/memtest\n\
        \n\n\_\n\nHDDerase \nCapable of calling the ATA secure erase command for non-volatile\
        \ magnetic hard disks. It is also capable of resetting host protected area\
        \ and device configuration overlay table information on the media.\n\n\nA\
        \ freeware tool developed by the Center for Magnetic Recording Research at\
        \ the University of California San Diego.\n\nhttps://cmrr.ucsd.edu/resources/secure-erase.html?_ga=2.231749531.545206853.1522881172-221519987.1522881172\n\
        \n\n\_\n\nAISEP Evaluated Products List (EPL)\n\n\nAustralasian Information\
        \ Security Evaluation Program\n\nhttps://www.cyber.gov.au/acsc/view-all-content/epl-products\n\
        \n\n\_\n\nATA Secure Erase\n\n\nATA ANSI specifications\n\nhttps://www.ansi.org/\n\
        \n\n\_\nSecure sanitisation of storage media\n\nNCSC, UK\n\nhttps://www.ncsc.gov.uk/guidance/secure-sanitisation-storage-media\n\
        \n\n\_\n\nReliably Erasing Data From Flash-Based Solid State Drives\n\n\n\
        Wei, Grupp, Spada and Swanson Department of Computer Science and Engineering,\
        \ University of California, San Diego\n\nhttps://www.usenix.org/legacy/event/fast11/tech/full_papers/Wei.pdf\
        \ [PDF, 1.96 MB]\n\n\n\_\n\nThe 2012 Analysis of Information Remaining on\
        \ Computer Hard Disks Offered for Sale on the Second Hand Market in the UAE\n\
        \n\nEdith Cowan University Research Online. Australian Digital Forensics Conference\n\
        \nhttps://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1110&context=adf\n\n\n\
        \_\n\n2010 Zombie Hard disks - Data from the Living Dead\n\n\nEdith Cowan\
        \ University Research Online. Australian Digital Forensics Conference\n\n\
        https://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1085&context=adf\n\n\n\_\
        \n\nThe 2009 Analysis of Information Remaining on Disks Offered for Sale on\
        \ the Second Hand Market\n\n\nEdith Cowan University Research Online. Australian\
        \ Digital Forensics Conference\n\nhttps://ro.ecu.edu.au/cgi/viewcontent.cgi?article=1079&context=adf\n\
        \n\n\_\n\nNSA/CSS Storage Device Declassification Manual December 2007\n\n\
        NSA\nhttps://www.nsa.gov/portals/75/documents/resources/everyone/Media-destruction/storage-device-declassification-manual.pdf\
        \ [PDF, 157 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Sanitisation procedures
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.01
      description: Sanitising media and IT Equipment prior to reuse or redeployment
        in a different environment ensures that classified information is not inadvertently
        accessed by an unauthorised individual or inadequately protected.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.02
      description: Using approved sanitisation methods provides a high level of assurance
        that no remnant data is on the media and IT Equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.03
      description: The procedures used in the NZISM are designed not only to prevent
        common attacks that are currently feasible, but also to protect from threats
        that could emerge in the future.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.04
      description: When sanitising media, it is necessary to read back the contents
        of the media to verify that the overwrite process completed successfully.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.05
      description: If the sanitising process cannot be successfully completed, destruction
        will be necessary.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.r.06
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.R.06
      description: It is important to note that "factory reset" or similar terms do
        not constitute sanitisation of media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:1
      ref_id: 13.4.9.C.01
      name: 'Control -  All Classifications - Must [CID: 4169]'
      description: Agencies MUST document conditions and procedures for the sanitisation
        of media and IT Equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Media that cannot be sanitised
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:2
      ref_id: 13.4.10.R.01
      description: Some types of media cannot be sanitised and therefore MUST be destroyed.
        It is not possible to use these types of media while maintaining a high level
        of assurance that no previous data can be recovered.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:2
      ref_id: 13.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4176]'
      description: "Agencies MUST destroy the following media types prior to disposal,\
        \ as they cannot be effectively sanitised:\nmicrofiche;\nmicrofilm;\noptical\
        \ discs;\nprinter ribbons and the impact surface facing the platen;\nprogrammable\
        \ read-only memory (PROM, EPROM, EEPROM);\nflash memory and solid state or\
        \ hybrid data storage devices;\nread-only memory; and\nfaulty magnetic media\
        \ that cannot be successfully sanitised.\n\_"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Volatile media sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:3
      ref_id: 13.4.11.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        When sanitising volatile media, the specified time to wait following removal\
        \ of power is based on applying a safety factor to research on recovering\
        \ the contents of volatile media."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:3
      ref_id: 13.4.11.C.01
      name: 'Control -  All Classifications - Must [CID: 4181]'
      description: 'Agencies MUST sanitise volatile media by:

        overwriting all locations of the media with an arbitrary pattern;

        followed by a read back for verification; and

        removing power from the media for at least 10 minutes.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Treatment of volatile media following sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:4
      ref_id: 13.4.12.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        There is published literature that supports the existence of short-term data\
        \ remanence effects in volatile media. Data retention time is reported to\
        \ range from minutes (at normal room temperatures) to hours (in extreme cold),\
        \ depending on the temperature of the volatile media. Further, published literature\
        \ has shown that some volatile media can suffer from long-term data remanence\
        \ effects resulting from physical changes to the media due to continuous storage\
        \ of static data for an extended period of time. It is for these reasons that\
        \ TOP SECRET volatile media MUST always remain at this classification, even\
        \ after sanitisation."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:4
      ref_id: 13.4.12.C.01
      name: 'Control -  All Classifications - Must [CID: 4184]'
      description: 'Following sanitisation, volatile media MUST be treated as indicated
        in the table below.




        Pre-sanitisation classification / Endorsement



        Post-sanitisation classification / Endorsement





        New Zealand Eyes Only (NZEO) Endorsement



        NZEO





        TOP SECRET



        TOP SECRET





        SECRET



        SECRET




        CONFIDENTIAL

        UNCLASSIFIED




        RESTRICTED and all lower classifications


        UNCLASSIFIED



        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Non-volatile magnetic media sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        Both the host protected area and device configuration overlay table of non-volatile\
        \ magnetic hard disks are normally not visible to the operating system or\
        \ the computer\u2019s BIOS. Hence any sanitisation of the readable sectors\
        \ on the media will not overwrite these hidden sectors leaving any classified\
        \ information contained in these locations untouched. Some sanitisation programs\
        \ include the ability to reset devices to their default state removing any\
        \ host protected areas or device configuration overlays. This allows the sanitisation\
        \ program to see the entire contents of the media during the subsequent sanitisation\
        \ process."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.R.02
      description: "Modern non-volatile magnetic hard disks automatically reallocate\
        \ space for bad sectors at a hardware level. These bad sectors are maintained\
        \ in what is known as the growth defects table or \u2018g-list\u2019. If classified\
        \ information was stored in a sector that is subsequently added to the g-list,\
        \ sanitising the media will not overwrite these non-addressable bad sectors,\
        \ and remnant data will exist in these locations. Whilst these sectors may\
        \ be considered bad by the device quite often this is due to the sectors no\
        \ longer meeting expected performance norms for the device and not due to\
        \ an inability to read/write to the sector."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.R.03
      description: "The ATA secure erase command is built into the firmware of post-2001\
        \ devices and is able to access sectors that have been added to the g-list.\
        \ Modern non-volatile magnetic hard disks also contain a primary defects table\
        \ or \u2018p-list\u2019. The p-list contains a list of bad sectors found during\
        \ post-production processes. No information is ever stored in sectors on the\
        \ p-list for a device as they are inaccessible before the media is used for\
        \ the first time."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.C.01
      name: 'Control -  All Classifications - Must [CID: 4189]'
      description: 'Agencies MUST sanitise non-volatile magnetic media by:

        if pre-2001 or under 15GB: overwriting the media at least three times in its
        entirety with an arbitrary pattern followed by a read back for verification;
        or

        if post-2001 or over 15GB: overwriting the media at least once in its entirety
        with an arbitrary pattern followed by a read back for verification.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.C.02
      name: 'Control -  All Classifications - Must [CID: 4190]'
      description: Agencies MUST boot from separate media to the media being sanitised
        when undertaking sanitisation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.C.03
      name: 'Control -  All Classifications - Should [CID: 4191]'
      description: Agencies SHOULD reset the host protected area and drive configuration
        overlay table of non-volatile magnetic hard disks prior to overwriting the
        media.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.C.04
      name: 'Control -  All Classifications - Should [CID: 4192]'
      description: Agencies SHOULD attempt to overwrite the growth defects table (g-list)
        on non-volatile magnetic hard disks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.13.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:5
      ref_id: 13.4.13.C.05
      name: 'Control -  All Classifications - Should [CID: 4193]'
      description: Agencies SHOULD use the ATA security erase command for sanitising
        non-volatile magnetic hard disks instead of using block overwriting software.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Treatment of non-volatile magnetic media following sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:6
      ref_id: 13.4.14.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        Highly classified non-volatile magnetic media cannot be sanitised below its\
        \ original classification because of concerns with the sanitisation of the\
        \ host protected area, device configuration overlay table and growth defects\
        \ table."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:6
      ref_id: 13.4.14.C.01
      name: 'Control -  All Classifications - Must [CID: 4200]'
      description: 'Following sanitisation, non-volatile magnetic media MUST be treated
        as indicated in the table below.




        Pre-sanitisation classification



        Post-sanitisation classification





        New Zealand Eyes Only (NZEO) Endorsement



        NZEO





        TOP SECRET



        TOP SECRET





        SECRET



        SECRET




        CONFIDENTIAL

        UNCLASSIFIED




        RESTRICTED


        UNCLASSIFIED



        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Non-volatile EPROM media sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:7
      ref_id: 13.4.15.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        When erasing non-volatile EPROM, the manufacturer\u2019s specified ultraviolet\
        \ erasure time is multiplied by a factor of three to provide an additional\
        \ level of certainty in the process. Verification is provided by read-back."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:7
      ref_id: 13.4.15.C.01
      name: 'Control -  All Classifications - Must [CID: 4205]'
      description: "Agencies MUST sanitise non-volatile EPROM media by erasing as\
        \ per the manufacturer\u2019s specification, increasing the specified ultraviolet\
        \ erasure time by a factor of three, then overwriting the media at least once\
        \ in its entirety with a pseudo random pattern, followed by a read back for\
        \ verification."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Non-volatile EEPROM media sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:8
      ref_id: 13.4.16.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        A single overwrite with a pseudo random pattern is considered good practice\
        \ for sanitising non-volatile EEPROM media."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:8
      ref_id: 13.4.16.C.01
      name: 'Control -  All Classifications - Must [CID: 4208]'
      description: Agencies MUST sanitise non-volatile EEPROM media by overwriting
        the media at least once in its entirety with a pseudo random pattern, followed
        by a read back for verification.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Treatment of non-volatile EPROM and EEPROM media following sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:9
      ref_id: 13.4.17.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        As little research has been conducted on the ability to recover data on non-volatile\
        \ EPROM or EEPROM media after sanitisation, highly classified media retains\
        \ its original classification."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:9
      ref_id: 13.4.17.C.01
      name: 'Control -  All Classifications - Must [CID: 4212]'
      description: 'Following sanitisation, non-volatile EPROM and EEPROM media MUST
        be treated as indicated in the table below.




        Pre-sanitisation classification



        Post-sanitisation classification





        New Zealand Eyes Only (NZEO) Endorsement


        NZEO




        TOP SECRET



        TOP SECRET




        SECRET

        SECRET



        CONFIDENTIAL

        UNCLASSIFIED



        RESTRICTED

        UNCLASSIFIED



        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Non-volatile flash memory & FPGA  media sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:10
      ref_id: 13.4.18.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        Wear levelling ensures that writes are distributed evenly across each memory\
        \ block in flash memory. Where possible flash memory SHOULD be overwritten\
        \ with a pseudo random pattern twice, rather than once, as this helps to ensure\
        \ that all memory blocks are overwritten during sanitisation. Verification\
        \ is provided by read-back."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:10
      ref_id: 13.4.18.C.01
      name: 'Control -  All Classifications - Must [CID: 4215]'
      description: Agencies MUST sanitise non-volatile flash memory media by overwriting
        the media at least twice in its entirety with a pseudo random pattern, followed
        by a read back for verification.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Treatment of non-volatile flash memory & FPCA media following sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:11
      ref_id: 13.4.19.R.01
      description: "The following guidance applies in cases where media is to be redeployed.\_\
        Owing to the use of wear levelling in flash memory, it is possible that not\
        \ all physical memory locations are written to when attempting to overwrite\
        \ the media. Classified information can therefore remain on the media. It\
        \ is for these reasons that TOP SECRET, SECRET and CONFIDENTIAL flash memory\
        \ media MUST always remain at their respective classification, even after\
        \ sanitisation."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.19.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:11
      ref_id: 13.4.19.R.02
      description: Non-volatile flash memory may be redeployed within systems of the
        same classification only after all manufacturer's sanitation procedures have
        been followed. Destruction and Disposal are covered in sections 13.5 - Media
        and IT equipment destruction and 13.6 - Media and IT equipment Disposal respectively.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:11
      ref_id: 13.4.19.C.01
      name: 'Control -  All Classifications - Must [CID: 4218]'
      description: 'Following sanitisation, non-volatile flash memory media MUST be
        treated as indicated in the table below.




        Pre-sanitisation classification



        Post-sanitisation classification





        New Zealand Eyes Only (NZEO) Endorsement


        NZEO




        TOP SECRET



        TOP SECRET




        SECRET

        SECRET



        CONFIDENTIAL

        CONFIDENTIAL



        RESTRICTED

        UNCLASSIFIED



        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:11
      ref_id: 13.4.19.C.02
      name: 'Control -  All Classifications - Must [CID: 5426]'
      description: Where manufacturer sanitation procedures cannot be determined,
        items MUST be destroyed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Sanitising solid state drives
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      ref_id: 13.4.20.R.01
      description: "Solid state drives operate a Flash Translation Layer (FTL) to\
        \ interface with the storage devices \u2013 usually NAND chips. Current sanitation\
        \ techniques address the FTL, rather than destroying the underlying data.\
        \ It is possible to bypass the FTL, thus accessing the underlying data. With\
        \ current technology, there is no effective means of sanitising solid state\
        \ drives."
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.20.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      ref_id: 13.4.20.R.02
      description: Solid state drives also use wear equalisation or levelling techniques
        which can leave data remnants.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      ref_id: 13.4.20.C.01
      name: 'Control -  All Classifications - Must [CID: 4222]'
      description: Solid state drives MUST be destroyed before disposal.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      ref_id: 13.4.20.C.02
      name: 'Control -  All Classifications - Must [CID: 4223]'
      description: Solid state drives MUST be sanitised using ATA Secure Erase sanitation
        software before redeployment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:12
      ref_id: 13.4.20.C.03
      name: 'Control -  Secret, Confidential, Top Secret - Must Not [CID: 4224]'
      description: Solid state drives MUST NOT be redeployed in a lower classification
        environment.
      implementation_groups:
      - Secret - MUST NOT
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Hybrid Drives
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:13
      ref_id: 13.4.21.R.01
      description: Hybrid drives combine solid state memory devices with magnetic
        disk technologies. As such they are subject to the same difficulties in effective
        sanitisation as solid state devices.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:13
      ref_id: 13.4.21.C.01
      name: 'Control -  All Classifications - Must [CID: 4227]'
      description: Hybrid drives MUST be treated as solid state drives for sanitisation
        purposes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: Sanitising media and IT Equipment  prior to reuse
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:14
      ref_id: 13.4.22.R.01
      description: Sanitising media and IT Equipment prior to reuse at the same or
        higher classification assists with enforcing the need-to-know principle within
        the agency. This includes any material with an NZEO endorsement.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:14
      ref_id: 13.4.22.C.01
      name: 'Control -  All Classifications - Should [CID: 4230]'
      description: Agencies SHOULD sanitise all media and IT Equipment prior to reuse
        at the same or higher classification.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.4:4:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4
      description: 'Verifying sanitised media and IT Equipment '
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:15
      ref_id: 13.4.23.R.01
      description: Verifying the sanitisation of media and IT Equipment with a different
        product to the one conducting the sanitisation process provides an independent
        level of assurance that the sanitisation process was conducted correctly.
    - urn: urn:defend:risk:req_node:nzism-v3:13.4.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.4:4:15
      ref_id: 13.4.23.C.01
      name: 'Control -  All Classifications - Should [CID: 4234]'
      description: Agencies SHOULD verify the sanitisation of media and IT Equipment
        using a different product from the one used to perform the initial sanitisation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.5'
      name: Media and IT Equipment Destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:1
      ref_id: 13.5.1
      description: To ensure media and IT equipment that cannot be sanitised is safely
        destroyed before disposal in an environmentally responsible manner.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:1
      ref_id: 13.5.2
      description: This section covers information relating to the destruction of
        media and IT equipment. Further information relating to the destruction of
        IT equipment can be found in Section 12.6 - Product Sanitisation and Disposal.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:1
      ref_id: 13.5.3
      description: "Any IT, electrical or electronic equipment MUST be destroyed and\
        \ disposed of in an environmentally safe and responsible manner.\_ This reflects\
        \ an increasing responsibility for improved equipment end-of-life treatment\
        \ and environmentally responsible disposal solutions, while continuing to\
        \ meet security and data protection requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: Evolution of electronic components and equipment
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:2
      ref_id: 13.5.4
      description: "The capability of various types of electronic equipment to store\
        \ data has increased significantly with technology advances such as solid-state\
        \ drives (SSDs) and on-board memory devices.\_ In turn these present a rich\
        \ target of opportunity to, amongst others, cyber-criminals, unauthorised\
        \ investigators, and foreign intelligence services.\_ Data may include, for\
        \ example, identity, account numbers, physical addresses, transactions, cryptographic\
        \ keys, strategic, financial or other private documents, and classified information."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:2
      ref_id: 13.5.5
      description: Where data from a discarded device is recovered, it may also result
        in a privacy or data breach - potentially incurring sanction from data regulators.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: Electronic Waste (Waste Electrical and Electronic Equipment (WEEE))
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      ref_id: 13.5.6
      description: "Media and IT equipment can contain a number of elements such as\
        \ arsenic, lead, mercury, barium, selenium and cadmium in their manufacture.\_\
        \ These elements can be poisonous, carcinogenic or toxic in particulate or\
        \ dust form.\_ If allowed to accumulate in dumps or poorly managed recycling\
        \ or disposal centres, they can create a serious health risk or environmental\
        \ hazard."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      ref_id: 13.5.7
      description: "Lead was traditionally used in solder on printed circuit boards,\
        \ although it has been banned in many countries in the last decade. Lead oxide\
        \ may still be found in cathode-ray tubes and older equipment.\_ Lead is toxic\
        \ to humans and medical research has raised concerns about the impact of low-level\
        \ exposure on the development of the brain and central nervous system in children."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      ref_id: 13.5.8
      description: Other elements used in the manufacture of IT and electronic equipment
        may include flame retardants and plasticisers, and should be treated with
        caution.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      ref_id: 13.5.9
      description: "Some flame-retardant materials used in computers can be toxic\
        \ if released as dust into the atmosphere.\_ Research has shown that they\
        \ interfere with brain and skeletal development."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:3
      ref_id: 13.5.10
      description: "Phthalates are probably best known as plasticisers and are widely\
        \ used in the electronics industry.\_ One of the most widely used phthalates,\
        \ DEHP, is classified by the EU as toxic to reproductive health. For example,\
        \ in 1999 an EU-wide ban was imposed on the use of six phthalates in children's\
        \ chewable toys."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: Incinerators
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      ref_id: 13.5.11
      description: There are many risks associated with the incineration of electronic
        waste. Up-to-date guidance is available on the Ministry for the Environment
        website (see reference table 13.5.21).
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      ref_id: 13.5.12
      description: "Incinerators discharge into the atmosphere and create emissions\
        \ and ash residue. There is potential for contamination of air, soil and water\
        \ through the release of pollutants such as hydrocarbons, heavy metals and\
        \ dioxins.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      ref_id: 13.5.13
      description: "There are two main by-products of incineration.\_ Firstly, inert\
        \ bottom ash which is primarily formed from inorganic elements, and secondly,\
        \ flue gases. These facilities must include gas cleaning systems designed\
        \ to contain pollutants and safely exhaust to the atmosphere.\_ Properly designed,\
        \ installed and operated facilities will be able to manage and safely dispose\
        \ of the waste, particulate matter and contaminants produced by incineration.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      ref_id: 13.5.14
      description: "It is essential that any incineration facility is properly rated,\
        \ inspected and authorised or licenced to process WEEE.\_ Any relevant national\
        \ environmental legislation and regulation must also be complied with.\_ In\
        \ particular the Resource Management Act and the National Environmental Standards\
        \ for Air Quality must be observed."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:4
      ref_id: 13.5.15
      description: "Some electrical and electronic waste materials cannot be safely\
        \ incinerated.\_ This includes:\nAlkaline batteries;\nGlass;\nLithium batteries;\
        \ and\nMobile phones.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: Destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:5
      ref_id: 13.5.16
      description: While sanitisation of media and IT equipment can be highly effective
        in controlled conditions and when applied for specific purposes, it does not
        provide the high level of assurances on the irrecoverably of data when the
        media and equipment has left the control of the owner, agency or other organisation.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:5
      ref_id: 13.5.17
      description: "Destruction provides considerably higher levels of assurance to\
        \ agencies where non-recoverability of any agency data is a consideration.\_\
        \ In many cases destruction is essential, rather than sanitisation and disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:5
      ref_id: 13.5.18
      description: "The GCSB approves destruction facilities (see also 13.6.11).\_\
        \ It is important to note that such approval is specific, confined to the\
        \ destruction process and DOES NOT endorse or approve the use of any sanitisation\
        \ process, method or software."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2
      description: New Zealand Eyes Only (NZEO) Materials
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:6
      ref_id: 13.5.19
      description: NZEO endorsed material requires additional protection at every
        level of classification.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:2:6
      ref_id: 13.5.20
      description: In general terms, media and IT Equipment containing NZEO material
        should be sanitised and redeployed or sanitised and destroyed in accordance
        with the procedures in this section. Media and IT Equipment that has contained
        NZEO material must not be disposed of, to e-recyclers or sold to any third
        party.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:3
      ref_id: 13.5.21
      description: "Further references can be found at:\n\n\n\nReference\n\n\nTitle\n\
        \n\nPublisher\n\n\nSource\n\n\n\n\n\_\n\n\nSecure Destruction of Sensitive\
        \ Items\n\n\nCPNI\n\n\nProtect sensitive information and assets from creation\
        \ to verified destruction. | CPNI\n\n\n\n\n\_\n\n\nProposed amendments to\
        \ National Environmental Standards for Air Quality: Particulate matter and\
        \ mercury emissions\n\n\nCabinet Paper June 2020\n\n\nhttps://environment.govt.nz/publications/approval-to-release-discussion-document-proposed-amendments-to-national-environmental-standards-for-air-quality-particulate-matter-and-mercury-emissions/\
        \ \_\n\n\n\n\n\_\n\n\n\_\n\n\nConsultation document\nFebruary 2020\n\n\nhttps://environment.govt.nz/publications/proposed-amendments-to-the-national-environmental-standards-for-air-quality-particulate-matter-and-mercury-emissions-consultation-document/\n\
        \n\n\n\n\_\n\n\n\_\n\n\nSummary of submissions\nDecember 2020\n\n\nhttps://environment.govt.nz/publications/proposed-amendments-to-the-national-environmental-standards-for-air-quality-summary-of-submissions/\n\
        \n\n\n\n\_\n\n\nGuidelines and recommendations for WEEE reuse and recycling\
        \ operators\n\n\nMinistry for the Environment\n\n\nhttps://environment.govt.nz/publications/waste-electrical-and-electronic-equipment-guidance-for-collection-reuse-and-recycling/guidelines-and-recommendations-for-weee-reuse-and-recycling-operators/\n\
        \n\n\n\n\_\n\n\nOverview of other WEEE good practice guidance/advice and standards\
        \ \n\n\nMinistry for the Environment\n\n\nhttps://environment.govt.nz/publications/waste-electrical-and-electronic-equipment-guidance-for-collection-reuse-and-recycling/overview-of-other-weee-good-practice-guidanceadvice-and-standards/\n\
        \n\n\n\n\_\n\n\nHealth and safety considerations when reusing or recycling\
        \ WEEE\n\n\nMinistry for the Environment\n\n\nhttps://environment.govt.nz/publications/waste-electrical-and-electronic-equipment-guidance-for-collection-reuse-and-recycling/health-and-safety-considerations-when-reusing-or-recycling-weee/\n\
        \n\n\n\n\_\n\n\nHazardous Air Pollutants\n\n\nMinistry for the Environment\n\
        \n\nhttps://environment.govt.nz/facts-and-science/air/air-pollutants/hazardous-air-pollutants-effects-health/\n\
        \n\n\n\n\_\n\n\nNew Zealand Waste list (L-Code)\n\n\nMinistry for the Environment\n\
        \n\nhttps://www.mfe.govt.nz/waste/guidance-and-resources/waste-list\_\n\n\n\
        \n\n\_\n\n\nEnvironmental Health Intelligence NZ \u2013 Air quality\n\n\n\
        Massey University\n\n\nhttps://www.ehinz.ac.nz/indicators/air-quality/\n\n\
        \n\n\n\_\n\n\nE-Waste Management\n\_\n\n\nNational Environmental Agency (US)\n\
        \n\nhttps://www.nea.gov.sg/our-services/waste-management/3r-programmes-and-resources/e-waste-management\n\
        \n\n\n\n\_\n\n\nHazardous Substances\n\_\n\n\nNational Environmental Agency\
        \ (US)\n\n\nhttps://www.nea.gov.sg/our-services/pollution-control/chemical-safety/hazardous-substances\n\
        \n\n\n\n\_\n\n\nA-Z Topics and Industry\n\n\nWorksafe NZ\n\n\nhttps://www.worksafe.govt.nz/\n\
        \n\n\n\n\_\n\n\nStewart, E. S., & Lemieux, P. M. (2003, May). Emissions from\
        \ the incineration of electronics industry waste. In IEEE International Symposium\
        \ on Electronics and the Environment, 2003. (pp. 271-275). IEEE.\n\n\nStewart\
        \ and Lemieux, Office of Research and Development, US EPA, 2003,IEEE\n\n\n\
        https://www.researchgate.net/publication/4020282_Emissions_from_the_incineration_of_electronics_industry_waste\n\
        \n\n\n\n\_\n\n\nGurgul, A., Szczepaniak, W., & Zab\u0142ocka-Malicka, M. (2017).\
        \ Incineration, pyrolysis and gasification of electronic waste. In E3S Web\
        \ of conferences (Vol. 22, p. 00060). EDP Sciences.\n\n\nGurgul et al, Wroclaw\
        \ University of Science and Technology, Poland, 2017,\n\n\nhttps://www.e3s-conferences.org/articles/e3sconf/pdf/2017/10/e3sconf_asee2017_00060.pdf\
        \ [PDF, 519 KB]\n\n\n\n\n\_\n\n\nBlack, H. (2005). Getting the lead out of\
        \ electronics. Environews,113(10).\n\n\nHarvey Black, published in Environmental\
        \ Health Perspectives, 2005 Oct; 113(10): A682\u2013A685,\n\n\nhttps://www.ncbi.nlm.nih.gov/pmc/articles/PMC1281311\n\
        \n\n\n\n\_\n\n\nEU bans baby toys containing phthalates. (1999). BMJ : British\
        \ Medical Journal, 319(7224), 1522.\n\n\nXavier Bosch, The Lancet, Volume\
        \ 354, Issue 9195, p2060, December 11, 1999,\n\n\nhttps://www.ncbi.nlm.nih.gov/pmc/articles/PMC1174644/\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Destruction procedures
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:1
      ref_id: 13.5.22.R.01
      description: Documenting procedures for media and IT equipment destruction will
        ensure that destruction is carried out in an appropriate, consistent and responsible
        manner within the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:1
      ref_id: 13.5.22.C.01
      name: 'Control -  All Classifications - Must [CID: 4270]'
      description: Agencies MUST document procedures for the destruction of media
        and IT Equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Media and IT Equipment destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:2
      ref_id: 13.5.23.R.01
      description: The destruction methods given are designed to ensure that recovery
        of data is impossible or impractical. Health and safety training and the use
        of safety equipment may be required with these methods.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:2
      ref_id: 13.5.23.C.01
      name: 'Control -  All Classifications - Must [CID: 4276]'
      description: "To destroy media and IT Equipment agencies MUST use at least one\
        \ of the methods shown in the following table.\n\n\nItem\n\nDestruction methods\n\
        \n\n\n\nFurnace/ Incinerator\n\n\nHammer mill\n\nDisintegrator\n\nGrinder/\
        \ Sander\n\nCutting\n\nDegausser\n\n\n\nMagnetic floppy disks\n\_Yes\n\_Yes\n\
        \_Yes\n\_No\n\_Yes\n\_Yes\n\n\nMagnetic hard disks\n\_Yes\n\_Yes\n\_Yes\n\_\
        Yes\n\_No\n\_Yes\n\n\nMagnetic tapes\n\_Yes\n\_Yes\n\_Yes\n\_No\n\_Yes\n\_\
        Yes\n\n\nOptical disks\n\_Yes\n\_Yes\n\_Yes\n\_Yes\n\_Yes\n\_No\n\n\nElectrostatic\
        \ memory devices\_\n\_Yes\nYes\_\n\_Yes\n\_Yes\n\_No\n\_No\n\n\nSemi-conductor\
        \ memory\n\_Yes\n\_Yes\n\_Yes\n\_No\n\_No\n\_No\n\n\nOther Circuit Boards\n\
        \_Yes\n\_Yes\n\_Yes\n\_No\n\_No\n\_No\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Destruction methods for media and IT equipment
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.R.01
      description: Where an agency does not perform its own destruction of media and
        IT equipment, an approved facility must be used. Agencies that do perform
        destruction of media and IT equipment must use equipment that complies with
        the NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.R.02
      description: A variety of equipment for media and IT Equipment destruction exists.
        Evaluated products will provide assurance that the product will be effective.
        Approved products are discussed in Chapter 12 - Product Security.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.R.03
      description: Where a product or service is not an evaluated product or is NOT
        listed in the PSR, agencies must consult the GCSB for advice.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.R.04
      description: "Equipment can be dismantled or pre-processed before disposal.\
        \ Care MUST be taken to ensure safe handling of any potential poisonous, carcinogenic\
        \ or toxic materials.\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.R.05
      description: "Where incineration is the disposal method of choice, users must\
        \ ensure the facility is properly rated for the incineration of electronic\
        \ waste (WEEE) and the safe handling of any poisonous, carcinogenic and toxic\
        \ materials produced in the incineration process.\_ The facility must also\
        \ be properly authorised or licenced to operate."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.C.01
      name: 'Control -  All Classifications - Must [CID: 4302]'
      description: Media and IT equipment destruction MUST be performed using approved
        destruction equipment, facilities and methods.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.C.02
      name: 'Control -  All Classifications - Must [CID: 4304]'
      description: Where agencies do not own their own destruction equipment, agencies
        MUST use an approved destruction facility for media and IT equipment destruction.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.C.03
      name: 'Control -  All Classifications - Must [CID: 7165]'
      description: Where a facility is NOT an approved facility, agencies MUST ensure
        any incineration equipment is rated for the destruction of electronic waste
        (WEEE) and the operator is properly authorised or licensed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.24.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:3
      ref_id: 13.5.24.C.04
      name: 'Control -  All Classifications - Must [CID: 7166]'
      description: Where a facility is NOT an approved facility, agencies MUST ensure
        processes are in place for the safe handling of electronic waste (WEEE), including
        any residual material from the destruction process.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Storage and handling of media and IT Equipment waste particles
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:4
      ref_id: 13.5.25.R.01
      description: Following destruction, normal accounting and auditing procedures
        do not apply. As such, it is essential that when an item is recorded as being
        destroyed, destruction is assured.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:4
      ref_id: 13.5.25.C.01
      name: 'Control -  All Classifications - Must [CID: 4343]'
      description: "Agencies MUST, at minimum, store and handle the resulting waste\
        \ for all methods, in accordance with the classification given in the table\
        \ below.\n\n\n\nInitial media or IT Equipment classification\n\n\nScreen aperture\
        \ size particles can pass through\n\n\n\n\nLess than or equal to 3mm\nTreat\
        \ as\n\n\nLess than or equal to 6mm\nTreat as\n\n\n\n\_TOP SECRET\n\nUNCLASSIFIED\n\
        \nRESTRICTED\n\n\nSECRET\n\nUNCLASSIFIED\n\nRESTRICTED\n\n\nCONFIDENTIAL\n\
        \nUNCLASSIFIED\n\nRESTRICTED\n\n\nRESTRICTED\n\nUNCLASSIFIED\n\n\nUNCLASSIFIED\n\
        \n\n\nParticle size: measured in any direction, should not exceed stated measurement."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Degaussers
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.R.01
      description: "Degaussers are effective ONLY on magnetic media or storage devices.\
        \ Coercivity varies between media and IT Equipment types and between brands\
        \ and models of the same type. Care is needed when determining the desired\
        \ coercivity as a degausser of insufficient strength will not be effective.\
        \ The National Security Agency/Central Security Service\u2019s EPLD contains\
        \ a list of common types of media and their associated coercivity ratings."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.R.02
      description: Since 2006 perpendicular magnetic media have become available.
        Some degaussers are only capable of sanitising longitudinal magnetic media.
        As such, care needs to be taken to ensure that a suitable degausser is used
        when sanitising perpendicular magnetic media.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.R.03
      description: Some degaussers will have product specific requirements. Agencies
        will need to comply with any directions provided by the GCSB to ensure that
        degaussers are being used in the correct manner to achieve an effective destruction
        outcome. Refer also to Chapter 12 - Product Security.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.C.01
      name: 'Control -  All Classifications - Must [CID: 4349]'
      description: Agencies MUST use a degausser of sufficient field strength for
        the coercivity of the media and IT Equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.C.02
      name: 'Control -  All Classifications - Must [CID: 4350]'
      description: Agencies MUST use a degausser which has been evaluated as capable
        for the magnetic orientation (longitudinal or perpendicular) of the media.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.26.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:5
      ref_id: 13.5.26.C.03
      name: 'Control -  All Classifications - Must [CID: 4352]'
      description: Agencies MUST comply with product specific directions provided
        by the manufacturers, along with any provided by the GCSB.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Supervision of destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:6
      ref_id: 13.5.27.R.01
      description: "To ensure that classified media and IT Equipment is appropriately\
        \ destroyed it will need to be supervised to the point of destruction and\
        \ have its destruction overseen by at least one person cleared to the highest\
        \ classification of the media being destroyed. To provide accountability and\
        \ traceability, a destruction register\_is essential."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:6
      ref_id: 13.5.27.C.01
      name: 'Control -  All Classifications - Must [CID: 4357]'
      description: "Agencies MUST perform the destruction of media and IT Equipment\_\
        under the supervision of at least one person cleared to the highest classification\
        \ of the media or IT Equipment\_being destroyed."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.27.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:6
      ref_id: 13.5.27.C.02
      name: 'Control -  All Classifications - Must [CID: 4358]'
      description: "Personnel supervising the destruction of media\_or IT Equipment\
        \ MUST:\nsupervise the handling of the media\_or IT Equipment to the point\
        \ of destruction; and\nensure that the destruction is completed successfully.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.27.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:6
      ref_id: 13.5.27.C.03
      name: 'Control -  All Classifications - Should [CID: 4359]'
      description: 'The Destruction Register SHOULD record:

        Destruction facility used;

        Destruction method used;

        Date of destruction;

        Operator and witnesses;

        Media and IT equipment classification; and

        Media and IT equipment type, characteristics and serial number.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Supervision of accountable material destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:7
      ref_id: 13.5.28.R.01
      description: "As accountable material is more sensitive than standard classified\
        \ media and IT equipment, it needs to be supervised by at least two personnel\
        \ and have a destruction certificate signed by both personnel supervising\
        \ the process.\_ This includes any NZEO material."
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:7
      ref_id: 13.5.28.C.01
      name: 'Control -  All Classifications - Must [CID: 4363]'
      description: "Agencies MUST perform the destruction of accountable material\
        \ under the supervision of at least two personnel cleared to the highest classification\
        \ of the media\_or IT Equipment being destroyed."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.28.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:7
      ref_id: 13.5.28.C.02
      name: 'Control -  All Classifications - Must [CID: 4364]'
      description: "Personnel supervising the destruction of accountable media and\
        \ IT Equipment MUST:\nsupervise the handling of the material to the point\
        \ of destruction;\nensure that the destruction is completed successfully;\_\
        \nsign a destruction certificate; and\ncomplete the relevant entries in the\
        \ destruction register.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Outsourcing media and IT Equipment destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:8
      ref_id: 13.5.29.R.01
      description: Agencies may wish to outsource media and IT Equipment destruction
        for efficiency and cost reasons.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:8
      ref_id: 13.5.29.C.01
      name: 'Control -  Top Secret - Must Not [CID: 4367]'
      description: Agencies MUST NOT outsource the supervision and oversight of the
        destruction of TOP SECRET or NZEO media and IT equipment or other accountable
        material to a non-government entity or organisation.
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.29.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:8
      ref_id: 13.5.29.C.02
      name: 'Control -  All Classifications - Must [CID: 4368]'
      description: Agencies outsourcing the destruction of media and IT Equipment
        to a commercial facility MUST use an approved facility and comply with the
        procedures and instructions in this Chapter.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.5:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4
      description: Transporting media and IT Equipment for offsite destruction
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:9
      ref_id: 13.5.30.R.01
      description: Requirements on the safe handling and physical transfer of media
        and IT Equipment between agencies or to commercial facilities can be found
        in the PSR.
    - urn: urn:defend:risk:req_node:nzism-v3:13.5.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.5:4:9
      ref_id: 13.5.30.C.01
      name: 'Control -  All Classifications - Should [CID: 4371]'
      description: Agencies SHOULD sanitise media and IT Equipment prior to transporting
        it to an offsite location for destruction.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:13.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:13
      ref_id: '13.6'
      name: Media and IT Equipment Disposal
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:1
      ref_id: 13.6.1
      description: Media and IT equipment is declassified and approved by the CISO,
        or delegate, for release before disposal into the public domain.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:2:1
      ref_id: 13.6.2
      description: This section covers information relating to the disposal of media
        and IT equipment. Further information relating to the disposal of IT equipment
        can be found in Section 12.6 - Product Sanitisation and Disposal.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:2:1
      ref_id: 13.6.3
      description: NZEO endorsed material requires additional protection at every
        level of classification.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:2:1
      ref_id: 13.6.4
      description: "In general terms, media and IT equipment containing NZEO material\
        \ should be sanitised and redeployed or sanitised and destroyed in accordance\
        \ with the procedures in this section. Media and IT equipment\_that has contained\
        \ NZEO material must not be disposed of, to e-recyclers or sold to any third\
        \ party."
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:2:1
      ref_id: 13.6.5
      description: Note the discussion in section 13.4 - Media and IT equipment sanitisation,
        on the challenges and difficulties in effectively sanitising media of all
        types.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Declassification prior to disposal
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:1
      ref_id: 13.6.6.R.01
      description: Prior to its disposal, media and IT equipment needs to be declassified
        to ensure that classified information is not accidentally released into the
        public domain.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:1
      ref_id: 13.6.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4385]'
      description: Agencies MUST declassify all media and IT equipment prior to disposing
        of it into the public domain.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:1
      ref_id: 13.6.6.C.02
      name: 'Control -  All Classifications - Must [CID: 4386]'
      description: Media and IT equipment that cannot be effectively sanitised or
        declassified MUST be destroyed and not released into the public domain.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Disposal procedures
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:2
      ref_id: 13.6.7.R.01
      description: The following diagram illustrates the mandated disposal process.
        Note declassification describes the entire process, including any reclassifications,
        approvals and documentation, before media and media waste can be released
        into the public domain.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:2
      ref_id: 13.6.7.C.01
      name: 'Control -  All Classifications - Must [CID: 4389]'
      description: 'Agencies MUST document procedures for the disposal of media and
        IT equipment.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Declassifying media
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:3
      ref_id: 13.6.8.R.01
      description: The process of reclassifying, sanitising or destroying media does
        not provide sufficient assurance for media to be declassified and released
        into the public domain. In order to declassify media, formal administrative
        approval is required before releasing the media or waste into the public domain.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:3
      ref_id: 13.6.8.C.01
      name: 'Control -  All Classifications - Must [CID: 4392]'
      description: 'Agencies declassifying media MUST ensure that:

        the reclassification of all classified information on the media has been approved
        by the originator, or the media has been appropriately sanitised or destroyed;
        and

        formal approval is granted before the media is released into the public domain.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Disposal of media
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:4
      ref_id: 13.6.9.R.01
      description: Disposing of media in a manner that does not draw undue attention
        ensures that media that was previously classified is not subjected to additional
        scrutiny over that of regular waste. This can include the removal of labels,
        markings and serial numbers.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:4
      ref_id: 13.6.9.C.01
      name: 'Control -  All Classifications - Must [CID: 4395]'
      description: Agencies MUST dispose of media in a manner that does not draw undue
        attention to its previous classification.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: New Zealand Eyes Only (NZEO) Materials
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:5
      ref_id: 13.6.10.R.01
      description: NZEO endorsed material requires additional protection at every
        level of classification and creates a special case in the destruction and
        disposal process.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:5
      ref_id: 13.6.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4398]'
      description: Media and IT equipment that has contained NZEO material MUST be
        sanitised and redeployed or sanitised and destroyed in accordance with the
        procedures in this chapter.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:5
      ref_id: 13.6.10.C.02
      name: 'Control -  All Classifications - Must [CID: 4399]'
      description: For disposal of all NZEO endorsed materials, an approved destruction
        facility MUST be used.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:5
      ref_id: 13.6.10.C.03
      name: 'Control -  All Classifications - Must Not [CID: 4400]'
      description: Media and IT equipment that has contained NZEO material MUST NOT
        be disposed of via e-recyclers or sold to any third party.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Approved Secure Destruction Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.01
      description: An approved secure destruction facility may be agency-owned or
        a commercial facility.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.02
      description: A number of regulatory and legislative requirements including those
        relating to health, safety, environmental protection, hazardous materials
        handling disposal and export, will have to be met by any such facility.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.03
      description: "It may not be economically viable for individual agencies to own\
        \ and maintain such facilities.\_ In such cases the use of a commercial facility\
        \ may be the only practical alternative."
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.04
      description: "To ensure secure destruction facilities have the capability, capacity\
        \ and equipment to securely destroy media and IT equipment to the specifications\
        \ detailed in the NZISM, a formal approval is required.\_ An inspection of\
        \ the facility and any necessary testing of the equipment will determine suitability\
        \ for operation as a secure destruction facility.\_ If the results of the\
        \ inspection and testing are satisfactory, a formal approval is issued.\_\
        \ Periodic re-inspections are conducted to ensure on-going compliance with\
        \ the NZISM requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.05
      description: Commercial organisations may apply to the GCSB for approval as
        a secure destruction facility under the NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.r.06
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.R.06
      description: "The Director-General of the GCSB will issue such approvals if\
        \ satisfied that the standards detailed in the NZISM have been satisfactorily\
        \ been met and can be maintained.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:6
      ref_id: 13.6.11.C.01
      name: 'Control -  All Classifications - Must [CID: 5711]'
      description: Where agencies establish their own disposal/destruction facilities,
        these facilities MUST be approved by the Director-General GCSB.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:13.6:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3
      description: Use of Approved Secure Destruction Facilities
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:7
      ref_id: 13.6.12.R.01
      description: "Agencies may not have the facilities to securely dispose of media\
        \ and IT equipment to the specifications detailed in the NZISM (Refer to 13.5.7\
        \ Media and IT Equipment Destruction and 13.5.9 Storage and handling of media\
        \ waste particles).\_ In these circumstances the use of an approved secure\
        \ disposal or destruction facility (agency owned or a commercial facility)\
        \ is permitted provided all other procedures in this Chapter are followed."
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:7
      ref_id: 13.6.12.R.02
      description: The GCSB maintains a register of approved secure disposal/destruction
        facilities.
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.12.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:7
      ref_id: 13.6.12.R.03
      description: "In practical terms this requires tracking, supervision and oversight\
        \ (witnessed) to the point where the disposal/destruction process is complete.\_\
        \ Procedures are detailed in Section 13.5 - Media and IT Equipment Destruction."
    - urn: urn:defend:risk:req_node:nzism-v3:13.6.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:13.6:3:7
      ref_id: 13.6.12.C.01
      name: 'Control -  All Classifications - Must [CID: 5716]'
      description: "\_Agencies MUST use an approved secure disposal/destruction facility\
        \ for the destruction of media and IT equipment."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:14
      assessable: false
      depth: 1
      ref_id: '14'
      name: Software security
    - urn: urn:defend:risk:req_node:nzism-v3:14.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:14
      ref_id: '14.1'
      name: Standard Operating Environments
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:1
      ref_id: 14.1.1
      description: Standard Operating Environments (SOE) are hardened in order to
        minimise attacks and compromise through known vulnerabilities and attack vectors.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2:1
      ref_id: 14.1.2
      description: This section covers information on the hardening of software used
        on workstations and servers on systems within agency control.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2
      description: Characterisation
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2:2
      ref_id: 14.1.3
      description: "Characterisation is a technique used to analyse and record a system\u2019\
        s configuration. It is important as it can be used as a baseline to verify\
        \ the system\u2019s integrity at a later date. It is also important that the\
        \ baseline has high levels of integrity and assurance to avoid reinfecting\
        \ systems or reintroducing compromises when restoring from baselines."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2:2
      ref_id: 14.1.4
      description: "In virtual environments a baseline is usually a \u201Csnapshot\u201D\
        \ or image take at a point in time. If the image or snapshot is infected,\
        \ then restoring from that image can result in further compromise. See also\
        \ Section 22.2 \u2013 Virtualisation and 22.3 \u2013 Virtual Local Area Networks."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:2:2
      ref_id: 14.1.5
      description: 'Methods of characterising files and directories include:

        performing a cryptographic checksum on the files/directories when they are
        known to be virus/contaminant free;

        documenting the name, type, size and attributes of legitimate files and directories,
        along with any changes to this information expected under normal operating
        conditions; or

        for a Windows system, taking a system difference snapshot.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:3
      ref_id: 14.1.6
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\nISO/IEC 27001:2013\_\n\n\nA.12.4.1,\_Control of Operational\
        \ Software\n\n\nISO\n\n\nhttps://www.iso.org/standard/54534.html\n\n\n\n\n\
        ISO/IEC 27001:2013\_\n\n\nA.12.6.1,\_Control of Technical Vulnerabilities\n\
        \n\nISO\n\n\nhttps://www.iso.org/standard/54534.html\n\n\n\n\_\n\nIndependent\
        \ testing of different antivirus software and their effectiveness\n\n\nAV\
        \ Comparatives\n\n\nhttps://www.av-comparatives.org/\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:4
      ref_id: 14.1.7
      description: "Relevant PSR requirements can be found at:\n\n\n\n\nReference\n\
        \n\nTitle\n\n\nSource\n\n\n\n\nPSR Mandatory Requirements\n\n\nGOV3, INFOSEC1,\
        \ INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\n\nHome | Protective\
        \ Security Requirements\nSecurity governance (GOV) | Protective Security Requirements\n\
        Information security (INFOSEC) | Protective Security Requirements \_\nPhysical\
        \ security (PHYSEC) | Protective Security Requirements\n\n\n\nPSR content\
        \ protocols \n\n\nManagement protocol for information security\nManagement\
        \ protocol for physical security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\_\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \n\nHandling requirements for protectively marked information and equipment\n\
        Analyse evolving threats and vulnerabilities\n\nClassification system | Protective\
        \ Security RequirementsUnderstanding the information security lifecycle |\
        \ Protective Security Requirements\n\n\n\nManaging specific scenarios\n\n\n\
        Managing specific scenarios | Protective Security Requirements\n\nTransacting\
        \ online with the public\n\_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Developing hardened SOEs
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:1
      ref_id: 14.1.8.R.01
      description: Antivirus and anti-malware software, while an important defensive
        measure, can be defeated by malicious code that has yet to be identified by
        antivirus vendors. This can include targeted attacks, where a new virus is
        engineered or an existing one modified to defeat the signature-based detection
        schemes.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:1
      ref_id: 14.1.8.R.02
      description: The use of antivirus and anti-malware software, while adding value
        to the defence of workstations, cannot be relied solely upon to protect the
        workstation. As such agencies still need to deploy appropriately hardened
        SOEs to assist with the protection of workstations against a broader range
        of security risks.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:1
      ref_id: 14.1.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1149]'
      description: "Agencies SHOULD develop a hardened SOE for workstations and servers,\
        \ covering:\nremoval of unneeded software and operating system components;\n\
        removal or disabling of unneeded services, ports and BIOS settings;\ndisabling\
        \ of unused or undesired functionality in software and operating systems;\n\
        implementation of access controls on relevant objects to limit system users\
        \ and programs to the minimum access required;\ninstallation of antivirus\
        \ and anti-malware software;\ninstallation of software-based firewalls limiting\
        \ inbound and outbound network connections;\_\nconfiguration of either remote\
        \ logging or the transfer of local event logs to a central server; and\nprotection\
        \ of audit and other logs through the use of a one way pipe to reduce likelihood\
        \ of compromise key transaction records.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Maintaining hardened SOEs
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      ref_id: 14.1.9.R.01
      description: Whilst a SOE can be sufficiently hardened when it is deployed,
        its security will progressively degrade over time. Agencies can address the
        degradation of the security of a SOE by ensuring that patches are continually
        applied, system users are not able to disable or bypass security functionality
        and antivirus and other security software is appropriately maintained with
        the latest signatures and updates.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      ref_id: 14.1.9.R.02
      description: End Point Agents monitor traffic and apply security policies on
        applications, storage interfaces and data in real-time. Administrators actively
        block or monitor and log policy breaches. The End Point Agent can also create
        forensic monitoring to facilitate incident investigation.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.9.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      ref_id: 14.1.9.R.03
      description: "End Point Agents can monitor user activity, such as the cut, copy,\
        \ paste, print, print screen operations and copying data to external drives\
        \ and other devices. \_The Agent can then apply policies to limit such activity."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      ref_id: 14.1.9.C.01
      name: 'Control -  All Classifications - Must [CID: 1158]'
      description: 'Agencies MUST ensure that for all servers and workstations:

        a technical specification is agreed for each platform with specified controls;

        a standard configuration created and updated for each operating system type
        and version;

        system users do not have the ability to install or disable software without
        approval; and

        installed software and operating system patching is up to date.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:2
      ref_id: 14.1.9.C.02
      name: 'Control -  All Classifications - Should [CID: 1159]'
      description: "Agencies SHOULD ensure that for all servers and workstations:\n\
        malware detection heuristics are set to a high level;\nmalware pattern signatures\
        \ are checked for updates on at least a daily basis;\nmalware pattern signatures\
        \ are updated as soon as possible after vendors make them available;\_\nall\
        \ disks and systems are regularly scanned for malicious code; and\nthe use\
        \ of End Point Agents is considered.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Default passwords and accounts
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:3
      ref_id: 14.1.10.R.01
      description: Default passwords and accounts for operating systems are often
        exploited by attackers as they are well documented in product manuals and
        can be easily checked in an automated manner with little effort required.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:3
      ref_id: 14.1.10.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 1162]'
      description: 'Agencies MUST reduce potential vulnerabilities in their SOEs by:

        removing unused accounts;

        renaming or deleting default accounts; and

        replacing default passwords before or during the installation process.

        '
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:3
      ref_id: 14.1.10.C.02
      name: 'Control -  All Classifications - Should [CID: 1163]'
      description: 'Agencies SHOULD reduce potential vulnerabilities in their SOEs
        by:

        removing unused accounts;

        renaming or deleting default accounts; and

        replacing default passwords, before or during the installation process.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Server separation
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:4
      ref_id: 14.1.11.R.01
      description: "Servers with a high security risk can include Web, email, file,\
        \ Internet Protocol Telephony (IPT) servers, Mobile Device Manager (MDM) servers\
        \ and gateway components. It is important to clearly identify all services\
        \ and connections to design a complete and secure server separation architecture.\
        \ Refer also to Chapter 19 \u2013 Gateway Security."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:4
      ref_id: 14.1.11.C.01
      name: 'Control -  All Classifications - Should [CID: 1169]'
      description: 'Where servers with a high security risk have connectivity to unsecure
        public networks, agencies SHOULD:

        use appropriately designed and configured gateways;

        consider the use of cross-domain solutions;

        segment networks;

        maintain effective functional segregation between servers allowing them to
        operate independently;

        minimise communications between servers at both the network and file system
        level as appropriate; and

        limit system users and programs to the minimum access needed to perform their
        duties.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Characterisation
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      ref_id: 14.1.12.R.01
      description: There are known techniques for defeating basic characterisations,
        therefore other methods of intrusion detection are also needed, particularly
        in situations where it is impractical to use a trusted environment for the
        generation of the characterisation data. Characterisation is very useful in
        post-intrusion forensic investigations where an infected disk can be compared
        to stored characterisation data in order to determine what files have been
        changed or introduced.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      ref_id: 14.1.12.R.02
      description: "Characterisation is also directly related to business continuity\
        \ and disaster recovery and is influenced by Business Impact Analyses and\
        \ Risk Assessments. \_Grouping elements by business applications and setting\
        \ priority and criticality of the elements to the business may assist in determining\
        \ the most appropriate and useful characterisations."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      ref_id: 14.1.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1185]'
      description: "Agencies SHOULD:\ncharacterise all servers whose functions are\
        \ critical to the agency, and those identified as being at a high security\
        \ risk of compromise;\nstore the characterisation information securely off\
        \ the server in a manner that maintains integrity;\nupdate the characterisation\
        \ information after every legitimate change to a system as part of the change\
        \ control process;\nas part of the agency\u2019s ongoing audit schedule, compare\
        \ the stored characterisation information against current characterisation\
        \ information to determine whether a compromise, or a legitimate but incorrectly\
        \ completed system modification, has occurred;\nperform the characterisation\
        \ from a trusted environment rather than the standard operating system wherever\
        \ possible; and\nresolve any detected changes in accordance with the agency\u2019\
        s information security incident management procedures.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      ref_id: 14.1.12.C.02
      name: 'Control -  All Classifications - Should [CID: 1189]'
      description: Agencies SHOULD use an Approved Cryptographic Algorithm to perform
        cryptographic checksums for characterisation purposes.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:5
      ref_id: 14.1.12.C.03
      name: 'Control -  All Classifications - Should [CID: 1190]'
      description: "Agencies SHOULD consider characterisations in the context of a\
        \ BCP or DRP and any related Business Impact Analyses and Risk Assessments.\_"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Automated outbound connections by software
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:6
      ref_id: 14.1.13.R.01
      description: Applications that include beaconing functionality include those
        that initiate a connection to the vendor site over the Internet and inbound
        remote management.
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:6
      ref_id: 14.1.13.C.01
      name: 'Control -  All Classifications - Should [CID: 1193]'
      description: Agencies SHOULD review all software applications to determine whether
        they attempt to establish any unauthorised or unplanned external connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:6
      ref_id: 14.1.13.C.02
      name: 'Control -  All Classifications - Should [CID: 1194]'
      description: If automated outbound connection functionality is included, agencies
        SHOULD make a business decision to determine whether to permit or deny these
        connections, including an assessment of the security risks involved in doing
        so.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:6
      ref_id: 14.1.13.C.03
      name: 'Control -  All Classifications - Should [CID: 1195]'
      description: If automated outbound connection functionality is included, agencies
        SHOULD consider the implementation of Data Loss Prevention (DLP) technologies.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.1:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5
      description: Knowledge of software used on systems
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:7
      ref_id: 14.1.14.R.01
      description: "Information about installed software, that could be disclosed\
        \ outside the agency, can include:\nuser agent on Web requests disclosing\
        \ the Web browser type;\nnetwork and email client information in email headers;\
        \ and\nemail server software headers.\nThis information could provide a malicious\
        \ entity with knowledge of how to tailor attacks to exploit vulnerabilities\
        \ in the agency\u2019s systems."
    - urn: urn:defend:risk:req_node:nzism-v3:14.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.1:5:7
      ref_id: 14.1.14.C.01
      name: 'Control -  All Classifications - Should [CID: 1198]'
      description: Agencies SHOULD limit information that could be disclosed outside
        the agency about what software, and software versions are installed on their
        systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:14
      ref_id: '14.2'
      name: Application Allow listing
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:1
      ref_id: 14.2.1
      description: Only approved applications are used on agency controlled systems.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:2:1
      ref_id: 14.2.2
      description: This section covers information on the use of technical controls
        to restrict the specific applications that can be accessed by a user or group
        of users.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:3
      ref_id: 14.2.3
      description: "Further information on software restriction policies as implemented\
        \ by Microsoft can be found at:\n\n\nReference\_\nTitle\nPublisher\nSource\n\
        \n\n\_\nUsing Software Restriction Policies to Protect Against Unauthorized\
        \ Software\nMicrosoft\nhttps://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb457006(v=technet.10)?redirectedfrom=MSDN\n\
        \n\n\_\nAPPLOCKER\nMicrosoft\nhttps://docs.microsoft.com/en-nz/windows/security/threat-protection/applocker/applocker-overview\_\
        \n\n\nSP\_800-167\nNIST Special Publication 800-167 - Guide to Application\
        \ Whitelisting\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf\
        \ [PDF, 622 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4
      description: Application allow listing
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:1
      ref_id: 14.2.4.R.01
      description: Application access control can be an effective mechanism to prevent
        the successful compromise of an agency system resulting from the exploitation
        of a vulnerability in an application or the execution of malicious code.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.4.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:1
      ref_id: 14.2.4.R.02
      description: Defining a list of trusted executables, an allow list, is a practical
        and secure method of securing a system rather than relying on a list of bad
        executables, a deny list, to be prevented from running.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.4.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:1
      ref_id: 14.2.4.R.03
      description: Application allow listing is considered only one part of a defence-in-depth
        strategy in order to prevent a successful attack, or to help mitigate consequences
        arising from an attack.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:1
      ref_id: 14.2.4.C.01
      name: 'Control -  All Classifications - Should [CID: 1234]'
      description: Agencies SHOULD implement application allow listing as part of
        the SOE for workstations, servers and any other network device.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4
      description: System user permissions
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      ref_id: 14.2.5.R.01
      description: "An average system user requires access to only a few applications,\
        \ or groups of applications, in order to conduct their work. Restricting the\
        \ system user\u2019s permissions to execute code to this limited set of applications\
        \ reduces the attack surface of the system."
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      ref_id: 14.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1242]'
      description: Agencies MUST ensure that a system user cannot disable the application
        allow listing mechanism.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      ref_id: 14.2.5.C.02
      name: 'Control -  All Classifications - Should [CID: 1246]'
      description: Agencies SHOULD prevent a system user from running arbitrary executables.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.5.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      ref_id: 14.2.5.C.03
      name: 'Control -  All Classifications - Should [CID: 896]'
      description: "Agencies SHOULD restrict a system user\u2019s rights in order\
        \ to permit them to only execute a specific set of predefined executables\
        \ as required for them to complete their duties."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.5.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:2
      ref_id: 14.2.5.C.04
      name: 'Control -  All Classifications - Should [CID: 898]'
      description: Agencies SHOULD ensure that application allow listing does not
        replace the antivirus and anti-malware software within a system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4
      description: System administrator permissions
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:3
      ref_id: 14.2.6.R.01
      description: Since the consequences of running malicious code as a privileged
        user are much more severe than an unprivileged user, an application allow
        list implementation should be strictly enforced for system administrators.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:3
      ref_id: 14.2.6.C.01
      name: 'Control -  All Classifications - Should [CID: 907]'
      description: Agencies SHOULD ensure that system administrators are not automatically
        exempt from application allow list policy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4
      description: Application allow listing configuration
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.01
      description: "A decision to execute a routine, application, or other programme\
        \ should be made based on a validated cryptographic hash as it is more secure\
        \ than a decision based on the executable\u2019s signature, path or parent\
        \ folder."
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.02
      description: In order for application allow listing to be effective an agency
        MUST initially gather information on necessary executables and applications
        in order to ensure that the implementation is fully effective.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.03
      description: "Different application allow listing controls, such as restricting\
        \ execution based on cryptographic hash, filename, pathname or folder, have\
        \ various advantages and disadvantages. \_Agencies need to be aware of this\
        \ when implementing application allow listing."
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.04
      description: Application allow listing based on parent folder or executable
        path is futile if access control list permissions allow a system user to write
        to the folders or overwrite permitted executables.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.05
      description: "Executables may create multiple processes in the course of execution.\_\
        \ These may be identified through examination of programme specifications,\
        \ testing in a \"sand-boxed\" environment before development, and logs of\
        \ any processes spawned or created."
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.06
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.06
      description: "Spawned processes may behave in ways that can compromise system\
        \ security, change security settings and modify access permissions.\_ Clearly\
        \ this can be undesirable behaviour."
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.07
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.07
      description: Adequate logging information can allow system administrators to
        further refine the application allow listing implementation and detect a pattern
        of deny decisions for a system user.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.r.08
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.R.08
      description: An example of relevant information that could be included in logs
        for application allow listing implementations would be decisions to deny execution
        incorporating information that would present a reviewer with evidence of misuse.
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.01
      name: 'Control -  All Classifications - Should [CID: 934]'
      description: Agencies SHOULD ensure that the default policy is to deny the execution
        of software.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.02
      name: 'Control -  All Classifications - Should [CID: 936]'
      description: Agencies SHOULD ensure that application allow listing is used in
        addition to a strong access control list model and the use of limited privilege
        accounts.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.03
      name: 'Control -  All Classifications - Should [CID: 940]'
      description: Agencies SHOULD plan and test application allow listing mechanisms
        and processes thoroughly prior to implementation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.04
      name: 'Control -  All Classifications - Should [CID: 942]'
      description: 'Agencies SHOULD restrict the decision whether to run an executable
        based on the following, in the order of preference shown:

        validates cryptographic hash;

        executable absolute path;

        digital signature; and

        parent folder.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.05
      name: 'Control -  All Classifications - Should [CID: 945]'
      description: Agencies SHOULD restrict the process creation permissions of any
        executables which are permitted to run by the application allow listing controls.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.06
      name: 'Control -  All Classifications - Should [CID: 5529]'
      description: Agencies SHOULD validate executable behaviour, in particular process
        creation, permission changes and access control modifications through examination,
        testing, monitoring and restriction of the permissions.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.2.7.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.2:4:4
      ref_id: 14.2.7.C.07
      name: 'Control -  All Classifications - Should [CID: 947]'
      description: Logs from the application allow listing implementation SHOULD include
        all relevant information.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:14
      ref_id: '14.3'
      name: Web Applications
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:1
      ref_id: 14.3.1
      description: Access to Web content is implemented in a secure and accountable
        manner.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:2:1
      ref_id: 14.3.2
      description: "This section covers information on Web browsers, plug-ins and\
        \ active content including the development and implementation of appropriate\
        \ use policies.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:2:1
      ref_id: 14.3.3
      description: The requirements in this section apply equally to the Web accessed
        via the Internet as well as websites accessed on an agency intranet.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:3
      ref_id: 14.3.4
      description: "An example of open source software\_that manages allow lists for\
        \ client-side JavaScript controls is available at:\n\n\nReference\nTitle\n\
        Publisher\nSource\n\n\n\_\nNoScript Firefox extension\nInform Action\n\nhttps://noscript.net/\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Web usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:1
      ref_id: 14.3.5.R.01
      description: If agencies allow system users to access the Web they will need
        to define the extent of Web access that is granted. This can be achieved through
        the development, and awareness raising amongst system users, of a Web usage
        policy.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:1
      ref_id: 14.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1272]'
      description: Agencies MUST develop and implement a policy governing appropriate
        Web usage.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Web proxy
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:2
      ref_id: 14.3.6.R.01
      description: Web proxies provide valuable information in determining if malicious
        code is performing regular interactions over Web traffic. Web proxies also
        provide usable information if system users are violating agency Web usage
        policies.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:2
      ref_id: 14.3.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1592]'
      description: Agencies SHOULD use a Web proxy for all Web browsing activities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:2
      ref_id: 14.3.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1593]'
      description: "An agency\u2019s Web proxy SHOULD authenticate system users and\
        \ provide logging that includes at least the following details about websites\
        \ accessed:\naddress (uniform resource locator);\ntime/date;\nsystem user;\n\
        internal IP address; and\nexternal IP address.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:2
      ref_id: 14.3.6.C.03
      name: 'Control -  All Classifications - Should Not [CID: 1594]'
      description: Agencies SHOULD NOT permit downloading of executable files from
        external websites unless there is a demonstrable and approved business requirement.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Applications and plug-ins
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:3
      ref_id: 14.3.7.R.01
      description: "Web browsers can be configured to allow the automatic launching\
        \ of downloaded files. \_This can occur with or without the system user\u2019\
        s knowledge thus making the workstation vulnerable to attack."
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:3
      ref_id: 14.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 1597]'
      description: Agencies SHOULD disable the automatic launching of files downloaded
        from external websites.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Inspection of TLS
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:4
      ref_id: 14.3.8.R.01
      description: As TLS encrypted Web traffic travelling over HTTPS connections
        can deliver content without any filtering, agencies can reduce this security
        risk by using TLS inspection so that the Web traffic can be filtered.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:4
      ref_id: 14.3.8.R.02
      description: An alternative of using an allow list for HTTPS websites can allow
        websites that have a low security risk of delivering malicious code and have
        a high privacy requirement like Web banking, to continue to have end-to-end
        encryption.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:4
      ref_id: 14.3.8.R.03
      description: It is however, important to note that there are many recorded cases
        of websites generally considered to be a low security risk that have been
        compromised.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:4
      ref_id: 14.3.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1602]'
      description: 'Agencies permitting TLS through their gateways SHOULD implement:

        a solution that decrypts and inspects the TLS traffic as per content filtering
        requirements; or

        an allow list specifying the addresses (uniform resource locators) to which
        encrypted connections are permitted, with all other addresses blocked.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Legal advice on the Inspection of TLS traffic
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:5
      ref_id: 14.3.9.R.01
      description: "Encrypted TLS traffic may contain personal information. Agencies\
        \ should seek legal advice on whether inspecting such traffic is in breach\
        \ of the Privacy Act or other legislation. User policies should incorporate\
        \ an explanation of the security drivers and acknowledgement from users on\
        \ the policy contents and requirements. Refer to Chapter 9 \u2013 Personnel\
        \ Security and Chapter 15 \u2013 Email Security."
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:5
      ref_id: 14.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 1605]'
      description: Agencies SHOULD seek legal advice regarding the inspection of encrypted
        TLS traffic by their gateways.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Allow listing / Deny listing websites
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      ref_id: 14.3.10.R.01
      description: Defining an allow list of permitted websites and blocking all unlisted
        websites limits one of the most common data delivery and exfiltration techniques
        used by malicious code. However, if agency personnel have a legitimate requirement
        to access a numerous and rapidly changing list of websites, agencies will
        need to consider the practicality and costs of such an implementation. In
        such cases deny listing is a limited but none-the-less effective measure.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      ref_id: 14.3.10.C.01
      name: 'Control -  All Classifications - Should [CID: 1609]'
      description: Agencies SHOULD implement allow listing for all HTTP traffic being
        communicated through their gateways.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      ref_id: 14.3.10.C.02
      name: 'Control -  All Classifications - Should [CID: 1608]'
      description: Agencies using an allow list on their gateways to specify the external
        addresses, to which encrypted connections are permitted, SHOULD specify allow
        list addresses by domain name or IP address.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      ref_id: 14.3.10.C.03
      name: 'Control -  All Classifications - Should [CID: 1610]'
      description: If agencies do not allow list websites they SHOULD deny list websites
        to prevent access to known malicious websites.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:6
      ref_id: 14.3.10.C.04
      name: 'Control -  All Classifications - Should [CID: 1611]'
      description: Agencies deny listing websites SHOULD update the deny list on a
        frequent basis to ensure that it remains effective.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Client-side active content
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:7
      ref_id: 14.3.11.R.01
      description: "Software that runs on agency systems SHOULD be controlled by the\
        \ agency. Active content delivered though websites should be constrained so\
        \ that it cannot arbitrarily access system users\u2019 files or deliver malicious\
        \ code. Unfortunately the implementations of Web browsers regularly contain\
        \ flaws that permit such activity."
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:7
      ref_id: 14.3.11.C.01
      name: 'Control -  All Classifications - Should [CID: 1614]'
      description: Agencies SHOULD block client-side active content, such as Java
        and ActiveX, which are assessed as having a limited business impact.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:7
      ref_id: 14.3.11.C.02
      name: 'Control -  All Classifications - Should [CID: 1615]'
      description: 'Agencies SHOULD:

        use client-side controls that allow JavaScript on a per website basis; and

        add JavaScript functions used only for malicious purposes to the agency Web
        content filter or IDS/IPS.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Web content filter
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:8
      ref_id: 14.3.12.R.01
      description: Using a Web proxy provides agencies with an opportunity to filter
        potentially harmful information to system users and their workstations.
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:8
      ref_id: 14.3.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1618]'
      description: Agencies SHOULD use the Web proxy to filter content that is potentially
        harmful to system users and their workstations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.3:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4
      description: Website Passwords
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:9
      ref_id: 14.3.13.R.01
      description: "Some websites require the use of a userID and password as the\
        \ authentication mechanism. The management of passwords on these websites\
        \ is often insecure and there are numerous examples of compromises where tens\
        \ of thousands, and sometimes millions of passwords are compromised in a single\
        \ incident. Where the same password is used on multiple websites, an incident\
        \ can potentially compromise the user\u2019s account on every website using\
        \ that password. It is important to treat these websites as insecure and manage\
        \ passwords appropriately."
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:9
      ref_id: 14.3.13.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1621]'
      description: Users MUST NOT use agency userID and login passwords as credentials
        for external websites.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:9
      ref_id: 14.3.13.C.02
      name: 'Control -  All Classifications - Should Not [CID: 1622]'
      description: Users SHOULD NOT store web site authentication credentials (userID
        and password) on workstations, remote access devices (such as laptops) or
        BYO devices.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:14.3.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.3:4:9
      ref_id: 14.3.13.C.03
      name: 'Control -  All Classifications - Should Not [CID: 1623]'
      description: Users SHOULD NOT use the same password for multiple websites.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:14.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:14
      ref_id: '14.4'
      name: Software Application Development
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:1
      ref_id: 14.4.1
      description: Secure programming methods and testing are used for application
        development in order to minimise the number of coding errors and introduction
        of security vulnerabilities.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:2:1
      ref_id: 14.4.2
      description: This section covers information relating to the development, upgrade
        and maintenance of application software used on agency systems.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:3
      ref_id: 14.4.3
      description: "Additional information relating to software development is contained\
        \ in:\n\n\nReference\_\nTitle\nPublisher\nSource\n\n\nISO/IEC 27001:2013\_\
        \nA.12.5,\_Security in Development and Support Processes\nISO\nhttps://www.iso.org/standard/54534.html\n\
        \n\n\_\n\nOWASP Secure Coding Practices - Quick Reference Guide\n\nOWASP\n\
        https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide\_\
        \n\n\n\_\n\nSecure Code Review\n\n\nMITRE Corporation\n\nhttps://www.mitre.org/publications/systems-engineering-guide/enterprise-engineering/systems-engineering-for-mission-assurance/secure-code-review\_\
        \n\n\n\_\n\nBuild Security In\n\n\nDHS \u2013 US-CERT\n\n\nhttps://www.us-cert.gov/bsi\n\
        \n\n\n\_\n\nApplication Security - Application Security & Development A To\
        \ Z\n\n\nUS Defense Information Security Agency (DISA)\n\n\nhttp://iase.disa.mil/stigs/app-security/app-security/Pages/index.aspx\n\
        \n\n\n\_\n\nWriting Secure Code - Michael Howard and David LeBlanc\n\n\nMicrosoft\
        \ Press\n\nISBN Book 978-0-7356-1722-3 ISBN eBook 978-0-7356-9146-9\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4
      description: Software development environments
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:1
      ref_id: 14.4.4.R.01
      description: Recognised good practice segregates development, testing and production
        environments to limit the spread of malicious code and minimise the likelihood
        of faulty code being put into production.Limiting access to development and
        testing environments will reduce the information that can be gained by an
        attacker.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:1
      ref_id: 14.4.4.C.01
      name: 'Control -  All Classifications - Should [CID: 1635]'
      description: 'Agencies SHOULD ensure that software development environments
        are configured such that:

        there are at least three separate environments covering:


        development;

        testing; and

        production.



        information flow between the environments is strictly limited according to
        a defined and documented change policy, with access granted only to system
        users with a clear business requirement;

        new development and modifications only take place in the development environment;
        and

        write access to the authoritative source for the software (source libraries
        & production environment) is disabled.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4
      description: Secure programming
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:2
      ref_id: 14.4.5.R.01
      description: Designing software to use the lowest privilege level needed to
        achieve its task will limit the privileges an attacker could gain in the event
        they subvert the software security.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:2
      ref_id: 14.4.5.R.02
      description: Validating all inputs will ensure that the input is within expected
        ranges, reducing the chance that malicious or erroneous input causes unexpected
        results.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:2
      ref_id: 14.4.5.C.01
      name: 'Control -  All Classifications - Should [CID: 1639]'
      description: 'Agencies SHOULD ensure that software developers use secure programming
        practices when writing code, including:

        designing software to use the lowest privilege level needed to achieve its
        task;

        denying access by default;

        checking return values of all system calls; and

        validating all inputs.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4
      description: Software testing
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      ref_id: 14.4.6.R.01
      description: Software reviewing and testing will reduce the possibility of introducing
        vulnerabilities into a production environment.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      ref_id: 14.4.6.R.02
      description: Using an independent party for software testing will limit any
        bias that can occur when a developer tests their own software.
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      ref_id: 14.4.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1643]'
      description: Software SHOULD be reviewed or tested for vulnerabilities before
        it is used in a production environment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      ref_id: 14.4.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1644]'
      description: Software SHOULD be reviewed or tested by an independent party as
        well as the developer.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.4.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.4:4:3
      ref_id: 14.4.6.C.03
      name: 'Control -  All Classifications - Should [CID: 1645]'
      description: Software development SHOULD follow secure coding practices and
        agency development standards.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:14
      ref_id: '14.5'
      name: Web Application Development
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:1
      ref_id: 14.5.1
      description: Security mechanisms are incorporated into all Web applications
        by design and implementation.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2:1
      ref_id: 14.5.2
      description: This section covers the deployment of agency Web applications and
        websites.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2
      description: Protecting Web servers
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2:2
      ref_id: 14.5.3
      description: "Even though Web servers may contain only information authorised\
        \ for release into the public domain, there still remains a need to protect\
        \ the integrity and availability of the information. \_As such, Web servers\
        \ are to be treated in accordance with the requirements of the classification\
        \ of the system they are connected to."
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2
      description: Web application components
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:2:3
      ref_id: 14.5.4
      description: Web application components at a high level consist of a Web server
        for presentation, a Web application for processing and a database for content
        storage. There can be more or fewer components, however in general there is
        a presentation layer, application layer and database layer.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:3
      ref_id: 14.5.5
      description: "Further information on Web application security is available from\
        \ the Open Web Application Security Project at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\nThe Open Web Application Security Project (OWASP) - Reference\n\
        \nOWASP\n\nhttps://owasp.org/\n\n\n\n\_\n\nNZ Digital Government - Security\
        \ and Privacy assurance\n\nDIA\nhttps://www.digital.govt.nz/standards-and-guidance/governance/managing-online-channels/security-and-privacy-for-websites/designing-for-security-and-privacy/security-and-privacy-assurance/\_\
        \n\n\n\_\n\nWeb Design and Applications\n\n\nW3C\n\n\nhttps://www.w3.org/standards/webdesign/\n\
        \n\n\n\_\n\nWeb Development \u2013 Patterns and Practices\n\n\nMicrosoft\n\
        \n\nhttps://msdn.microsoft.com/en-us/library/ff921348.aspx\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4
      description: Agency website content
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:1
      ref_id: 14.5.6.R.01
      description: Reviewing active content on agency Web servers will assist in identifying
        and mitigating information security issues.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:1
      ref_id: 14.5.6.C.01
      name: 'Control -  All Classifications - Should [CID: 1661]'
      description: Agencies SHOULD review all active content on their Web servers
        for known information security issues.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4
      description: Segregation of Web application components
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:2
      ref_id: 14.5.7.R.01
      description: Web applications are typically very exposed services that provide
        complex interactions with system users. This greatly increases the security
        risk of being compromised. By segregating components, the impact of potential
        application flaws or attacks is limited.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:2
      ref_id: 14.5.7.C.01
      name: 'Control -  All Classifications - Should [CID: 1664]'
      description: Agencies SHOULD minimise connectivity and access between each Web
        application component.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:14.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4
      description: Web applications
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:3
      ref_id: 14.5.8.R.01
      description: The Open Web Application Security Project guide provides a comprehensive
        resource to consult when developing Web applications.
    - urn: urn:defend:risk:req_node:nzism-v3:14.5.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:14.5:4:3
      ref_id: 14.5.8.C.01
      name: 'Control -  All Classifications - Should [CID: 1667]'
      description: Agencies SHOULD follow the documentation provided in the Open Web
        Application Security Project guide to building secure Web applications and
        Web services.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15
      assessable: false
      depth: 1
      ref_id: '15'
      name: Email security
    - urn: urn:defend:risk:req_node:nzism-v3:15.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:15
      ref_id: '15.1'
      name: Email Applications
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:1
      ref_id: 15.1.1
      description: Email messages have appropriate protective markings to facilitate
        the application of handling instructions.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2:1
      ref_id: 15.1.2
      description: "This section covers information on email policy and usage as it\
        \ applies to content and protective markings. \_Information on email infrastructure\
        \ is located in Section 15.2 - Email Infrastructure."
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2
      description: Automatically generated emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2:2
      ref_id: 15.1.3
      description: The requirements for emails within this section equally apply to
        automatically and manually generated emails.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2
      description: Exceptions for receiving unmarked email messages
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:2:3
      ref_id: 15.1.4
      description: Where an agency receives unmarked non-government emails as part
        of its business practice the application of protective markings can be automated.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:3
      ref_id: 15.1.5
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\nSP 800-45\n\n\nNIST publication SP 800-45 v2, Guidelines on\
        \ Electronic Mail Security\n\nNIST\n\nhttps://csrc.nist.gov/publications/detail/sp/800-45/version-2/final\n\
        \n\n\n\_\n\nDetecting socially engineered emails August 2012\n\nASD\n\nDetecting\
        \ Socially Engineered Messages | Cyber.gov.au\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:4
      ref_id: 15.1.6
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV2, GOV3, GOV4, INFOSEC1,\
        \ INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\n\nHome | Protective\
        \ Security Requirements\nSecurity governance (GOV) | Protective Security Requirements\n\
        Information security (INFOSEC) | Protective Security Requirements\_\_\_\n\
        Physical security (PHYSEC) | Protective Security Requirements/\n\n\n\n\nPSR\
        \ content protocols \n\n\nManagement protocol for information security\nManagement\
        \ protocol for physical security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \n\nHandling requirements for protectively marked information and equipment\n\
        Build security awareness\n\n\nClassification system | Protective Security\
        \ Requirements\nBuilding security awareness | Protective Security Requirements\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Email usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:1
      ref_id: 15.1.7.R.01
      description: There are many security risks associated with the unsecure nature
        of email that are often overlooked. Documenting them will inform information
        owners about these security risks and how they might affect business operations.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:1
      ref_id: 15.1.7.C.01
      name: 'Control -  All Classifications - Must [CID: 1684]'
      description: Agencies MUST develop and implement a policy governing the use
        of email.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Email distribution
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:2
      ref_id: 15.1.8.R.01
      description: Often the membership, clearance level and nationality of members
        of email distribution lists is unknown. As such, personnel sending sensitive
        emails with NZEO or other nationality releasability marked information could
        be accidentally causing an information security incident by sending such information
        to distribution lists.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:2
      ref_id: 15.1.8.C.01
      name: 'Control -  All Classifications - Must [CID: 1687]'
      description: Agencies MUST ensure that emails containing NZEO or other nationality
        releasability marked information are sent only to named recipients.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:2
      ref_id: 15.1.8.C.02
      name: 'Control -  All Classifications - Must Not [CID: 1688]'
      description: Agencies MUST NOT transmit emails or other documents, containing
        NZEO or other nationality releasability marks, to groups or distribution lists
        unless the nationality of all members of the distribution lists can be confirmed.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Protective marking standard
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:3
      ref_id: 15.1.9.R.01
      description: Applying markings that reflect the protective requirements of an
        email informs the recipient on how to appropriately handle the email and any
        related documents.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:3
      ref_id: 15.1.9.C.01
      name: 'Control -  All Classifications - Should [CID: 1691]'
      description: Agencies SHOULD comply with the national classification system
        for the application of protective markings.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Marking tools
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.R.01
      description: Requiring system user intervention in the marking of system user-generated
        emails assures a conscious decision by the system user, lessening the chance
        of incorrectly marked emails.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.R.02
      description: Limiting the protective markings a system user is allowed to choose,
        to those for which the system is accredited lessens the chance that a system
        user inadvertently over-classifies an email and reminds them of the maximum
        classification of information that is permitted on the system.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.R.03
      description: "Gateway filters usually check only the most recent protective\
        \ marking. \_Care MUST be taken when changing protective markings to a classification\
        \ lower than that of the original email as this can result in emails being\
        \ forwarded to systems or individuals NOT authorised and cleared to receive\
        \ them. \_ The instructions in the classification system on changing classifications\
        \ MUST be observed to avoid a security breach."
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1696]'
      description: Agencies MUST NOT allow system users to select protective markings
        that the system has not been accredited to process, store or communicate.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.C.02
      name: 'Control -  All Classifications - Should Not [CID: 1697]'
      description: Agencies SHOULD NOT allow a protective marking to be inserted into
        system user generated emails without their intervention.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:4
      ref_id: 15.1.10.C.03
      name: 'Control -  All Classifications - Should Not [CID: 1698]'
      description: Agencies SHOULD NOT permit system users replying to or forwarding
        an email to select a protective marking that indicates that the classification
        of the email is lower than a previous classification used for the email.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Marking classified and unclassified emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      ref_id: 15.1.11.R.01
      description: "As with paper-based information, all electronic-based information\
        \ should be marked with an appropriate protective marking in accordance with\
        \ the classification system. \_This ensures that appropriate security measures\
        \ are applied to the information and also assists in preventing the inadvertent\
        \ release of information into the public domain."
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      ref_id: 15.1.11.R.02
      description: When a protective marking is applied to an email it is important
        that it reflects the highest classification in the body of the email and any
        attachments within the email.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      ref_id: 15.1.11.C.01
      name: 'Control -  All Classifications - Must [CID: 1702]'
      description: All classified and unclassified emails MUST have a protective marking.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      ref_id: 15.1.11.C.02
      name: 'Control -  All Classifications - Must [CID: 1703]'
      description: Email protective markings MUST accurately reflect the highest classification
        of all elements in an email, including any attachments.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:5
      ref_id: 15.1.11.C.03
      name: 'Control -  All Classifications - Should [CID: 1704]'
      description: Agencies SHOULD include protective markings in the email subject
        line or header to facilitate early identification of the classification.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Emails from outside the government
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:6
      ref_id: 15.1.12.R.01
      description: If an email is received from outside government the system user
        has an obligation to determine the appropriate protective measures for the
        email if it is to be responded to, forwarded or printed.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:6
      ref_id: 15.1.12.C.01
      name: 'Control -  All Classifications - Must [CID: 1707]'
      description: Where an unmarked email has originated outside the government,
        the agency MUST assess the information and determine how it is to be handled
        in accordance with the classification system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Marking personal emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:7
      ref_id: 15.1.13.R.01
      description: Applying protective markings to personal emails may create system
        overheads and will be misleading.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:7
      ref_id: 15.1.13.R.02
      description: "Personal emails can be marked as \u201CPERSONAL\u201D or \u201C\
        UNOFFICIAL\u201D to avoid confusion with Official or Classified information."
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:7
      ref_id: 15.1.13.C.01
      name: 'Control -  All Classifications - Should Not [CID: 1711]'
      description: Where an email is of a personal nature and does not contain government
        information, protective markings SHOULD NOT be used.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Receiving unmarked emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:8
      ref_id: 15.1.14.R.01
      description: If an email is received from a New Zealand or overseas government
        agency without a protective marking the system user has an obligation to contact
        the originator to seek clarification on the appropriate protection measures
        for the email or follow established protocols and policy for protective markings.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:8
      ref_id: 15.1.14.C.01
      name: 'Control -  All Classifications - Should [CID: 1714]'
      description: Where an unmarked email has originated from a New Zealand or overseas
        government agency, personnel SHOULD contact the originator to determine how
        it is to be handled.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Receiving emails with unknown protective markings
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:9
      ref_id: 15.1.15.R.01
      description: If an email is received with a protective marking that the system
        user is not familiar with they have an obligation to contact the originator
        to seek clarification on the protective marking and the appropriate protection
        measures for the email.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:9
      ref_id: 15.1.15.C.01
      name: 'Control -  All Classifications - Should [CID: 1717]'
      description: Where an email is received with an unknown protective marking from
        a New Zealand or overseas government agency, personnel SHOULD contact the
        originator to determine appropriate protection measures.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Printing
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:10
      ref_id: 15.1.16.R.01
      description: The PSR requires that paper-based information have the classification
        of the information placed at the top and bottom of each piece of paper, in
        CAPITALS and appearing as the first and last item on each page.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:10
      ref_id: 15.1.16.C.01
      name: 'Control -  All Classifications - Should [CID: 1720]'
      description: Agencies SHOULD configure systems so that the protective markings
        appear at the top and bottom of every page when the email is printed, in CAPITALS
        and appearing as the first and last item on each page.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Active Web addresses within emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:11
      ref_id: 15.1.17.R.01
      description: Spoofed emails often contain an active Web address directing personnel
        to a malicious website to either elicit information or infect their workstation
        with malicious code. In order to reduce the success rate of such attacks agencies
        can choose to educate their personnel to neither send emails with active Web
        addresses or to click on Web addresses in emails that they receive.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:11
      ref_id: 15.1.17.C.01
      name: 'Control -  All Classifications - Should Not [CID: 1723]'
      description: Personnel SHOULD NOT send emails that contain active Web addresses
        or click on active Web addresses within emails they receive.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Awareness of email usage policies
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:12
      ref_id: 15.1.18.R.01
      description: In order to protect information and systems, system users will
        need to be familiar with email usage policies.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:12
      ref_id: 15.1.18.C.01
      name: 'Control -  All Classifications - Must [CID: 1726]'
      description: "Agencies MUST make their system users aware of the agency\u2019\
        s email usage policies."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Monitoring email usage
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:13
      ref_id: 15.1.19.R.01
      description: Agencies may choose to monitor compliance with aspects of email
        usage policies such as attempts to send prohibited file types or executables,
        attempts to send excessive sized attachments or attempts to send classified
        information without appropriate protective markings.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:13
      ref_id: 15.1.19.C.01
      name: 'Control -  All Classifications - Should [CID: 1729]'
      description: "Agencies SHOULD implement measures to monitor their personnel\u2019\
        s compliance with email usage policies."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:13
      ref_id: 15.1.19.C.02
      name: 'Control -  All Classifications - Should [CID: 1730]'
      description: Agencies SHOULD enforce the use of approved government email systems
        such as SEEMAIL.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.1:5:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5
      description: Public Web-based email services
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:14
      ref_id: 15.1.20.R.01
      description: Using public Web-based email services may allow personnel to bypass
        security measures that agencies will have put in place to protect against
        malicious code or phishing attempts distributed via email. Web based email
        services may also by-pass agency context filtering mechanisms.
    - urn: urn:defend:risk:req_node:nzism-v3:15.1.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.1:5:14
      ref_id: 15.1.20.C.01
      name: 'Control -  All Classifications - Should Not [CID: 1733]'
      description: Agencies SHOULD NOT allow personnel to use public Web-based email
        services, for processing, receiving or sending emails or attachments for official
        business.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:15.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:15
      ref_id: '15.2'
      name: Email Infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:1
      ref_id: 15.2.1
      description: Email infrastructure is hardened, email is secured, and protective
        marking of email messages is enforced.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2:1
      ref_id: 15.2.2
      description: This section covers information on email infrastructure security,
        specifically email authentication and secure email transport. Information
        on using email applications can be found in Section 15.1 - Email Applications
        and Section 9.3 - Using the Internet.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2:1
      ref_id: 15.2.3
      description: Email is a critical tool for communication, and is commonly targeted
        by cyber-attacks. It is hard to protect because email is historically insecure
        and subject to social engineering. This section covers email authentication,
        secure email transport, and securing non-email sending domains.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2
      description: Email authentication
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2:2
      ref_id: 15.2.4
      description: "Email authentication protects your email from impersonation attacks\
        \ like spoofing and phishing; phishing and malware distribution attacks are\
        \ common internet security threats.\_ To avoid agency domains being used fraudulently\
        \ (e.g. for spam or spear-phishing), the following should be implemented:\n\
        \nSender Policy Framework (SPF)\nDomainKeys Identified Mail (DKIM)\nDomain-based\
        \ Message Authentication, Reporting & Conformance (DMARC) records\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:2:2
      ref_id: 15.2.5
      description: "Implementation of these features will help other mail servers\
        \ authenticate the email they receive from your domains.\_ It is important\
        \ to note that DMARC is designed to protect against direct domain spoofing\
        \ only.\_ DMARC does not eliminate the need for additional forms of protection\
        \ and analysis.\_ It does, however, provide a way for participating senders\
        \ and receivers to coordinate protective activities and streamline security\
        \ processes."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: Domain-based Message Authentication, Reporting and Conformance (DMARC)
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: Vocabulary
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:1
      ref_id: 15.2.6
      description: "The terms \u201Cnone\u201D, \u201Creject\u201D and \u201Cquarantine\u201D\
        \ are used to describe DMARC actions based on policy modes.\_ In this usage:\n\
        \n\u201Cnone\u201D means no action on the transmission or receipt of the email\
        \ but continue to collect data and send reports;\nBy default, email under\
        \ a \u201Creject\u201D policy setting is not delivered.\_ \u201CReject\u201D\
        \ either:\n\nrefuses to accept non-compliant email, or\ninitially accepts\
        \ the non-compliant email but prevents an email reaching the user.\_ The acceptance\
        \ process can generate a Delivery Status Notification (block/\u201Cbounce\u201D\
        ) or simply delete/drop the email (block/delete);\n\n\n\u201Cquarantine\u201D\
        \ prevents an email from reaching the user but safely storing it so it can\
        \ be accessed if required (a potentially suspicious email and/or attachment\
        \ subject to additional scrutiny).\_ Quarantined items can be released following\
        \ a review and release process.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: What is DMARC
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:2
      ref_id: 15.2.7
      description: 'Domain-based Message Authentication, Reporting and Conformance
        (DMARC) is an email authentication policy and reporting protocol that:


        complements and unifies the existing validation checks performed by SPF and
        DKIM;

        checks the stated origin of inbound emails using a combination of Sender Policy
        Framework (SPF) and DomainKeys Identified Mail (DKIM);

        establishes a recipient email response for emails that fail the check;

        requests recipient email services to report email sources and origins;

        provides visibility over potentially illegitimate or fraudulent email.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:2
      ref_id: 15.2.8
      description: "DMARC builds on SPF and DKIM protocols, adding links to the author\
        \ (\u201CFrom:\u201D) domain name, published policies for recipient handling\
        \ of authentication failures, and reporting from receivers to senders, in\
        \ order to improve and monitor protection of the recipient domain from fraudulent\
        \ email."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:2
      ref_id: 15.2.9
      description: "Most email services will check your DMARC record and send aggregated\
        \ reports including details of all email the service received from the agency,\
        \ and its origin.\_ This assists in identifying if an individual within the\
        \ agency is sending email inappropriately or if the agency domain is being\
        \ spoofed."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: Background, Reference and Implementation Guidance Sources
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:3
      ref_id: 15.2.10
      description: "The IETF published RFC 7489, \u201CDomain-based Message Authentication,\
        \ Reporting, and Conformance (DMARC)\u201D 18 March 2015. This is the principal\
        \ standards guidance on the implementation and use of DMARC.\_Further guidance\
        \ is available from The Global Cyber Alliance (GCA) - see References below."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: Using DMARC
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.11
      description: "The combination of DMARC, SPF, and DKIM records in DNS automates\
        \ the ability of email service providers to confirm which servers should be\
        \ legitimately sending email from the agency\u2019s domain, and what action\
        \ to take with mail received from any other domains."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.12
      description: As a pre-requisite for implementing DMARC, agencies must publish
        an SPF and a DKIM record in DNS. Agencies must also ensure that emails sent
        by the agency (including from third party services sending on behalf of the
        agency) have a DKIM signature that matches the signature in the DKIM record.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.13
      description: "Agencies can choose to quarantine or reject messages that fail\
        \ checks.\_ More specifically:\n\nSender Policy Framework (SPF) is used to\
        \ specify legitimate locations of servers which can send email for your domain;\n\
        DomainKeys Identified Mail (DKIM) isn't supported by all mail servers, but\
        \ if it is, it can be used to cryptographically sign outgoing mail sent by\
        \ your servers to give email service providers further confidence that it's\
        \ legitimate;\nDMARC is used to inform email service providers what action\
        \ they should take if SPF or DKIM (or both) validation fails;\nOne important\
        \ aspect of DMARC is the action you ask email service providers to take when\_\
        SPF or DKIM validation fails:\n\na policy of p=none means that they should\
        \ allow non-compliant emails to be delivered but report the failure to the\
        \ agency;\na policy of p=quarantine requests that they mark the email as spam;\n\
        a policy of p=reject requests the email service provider to refuse to deliver\
        \ the email.\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.14
      description: 'A text record published in DNS is used to notify other organisations
        of the use of DMARC. The following demonstrates an example DMARC record:


        v=DMARC1;

        p=quarantine;

        rua=mailto:dmarc@agency.govt.nz (where agency is the name of the respective
        agency).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.15
      description: 'This informs email recipients that:


        you have a DMARC policy (v=DMARC1)

        any messages that fail DMARC checks should be treated as spam (p=quarantine)

        they should send reports of email received back to you (rua=mailto:dmarc@agency.govt.nz)

        '
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.16
      description: "It is not unusual to experience minor errors in syntax or other\
        \ elements of DMARC configuration when first implementing DMARC.\_ Some discussion\
        \ on common problems, issues and solutions can be found on the DMARC website\
        \ (see the References table below)."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:4
      ref_id: 15.2.17
      description: "For domains expected to be used for email, it is not recommended\
        \ to move directly to a full implementation of DMARC until there is certainty\
        \ that the configuration and implementation are stable and operating as intended.\
        \ The following implementation outline is recommended by the GCA and DMARC\
        \ organisations (see 15.2.19 References):\n\nDeploy DKIM & SPF;\nEnsure mailers\
        \ are correctly aligning the appropriate identifiers;\nPublish a DMARC record\
        \ with the \u201Cnone\u201D flag set for the policies, which requests data\
        \ reports;\nAnalyse the data and modify mail streams as appropriate; and\n\
        Modify DMARC policy flags from \u201Cnone\u201D to \u201Cquarantine\u201D\
        \ to \u201Creject\u201D as experience dictates.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: Securing non-email sending domains
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:5
      ref_id: 15.2.18
      description: "Threat actors may attempt to spoof a domain that is not intended\
        \ to send or receive email. Operators of domains that do not send mail can\
        \ publish Sender Policy Framework (SPF) \"-all\" policies to make an explicit\
        \ declaration that the domains send no mail. The following DNS entries create\
        \ blank SPF and DKIM entries effectively forcing every email sent (spoofed)\
        \ from a non-mail-enabled domain to fail all checks, giving the highest possible\
        \ chance of these emails not reaching their intended destination.\n\nSPF\_\
        \ \_ \_\u201Cv=spf1 -all\u201D\nDKIM \_ \u201Cv=DKIM1; p=\u201D\nDMARC\_ \u201C\
        V=DMARC1;p=reject;sp=reject;adkim-s;aspf=s;rua=mailto:<your dmarc report RUA\
        \ email address>;\u201D\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3
      description: DMARC Reporting
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:6
      ref_id: 15.2.19
      description: "DMARC reporting provides information to assist an agency\u2019\
        s IT system and email administrators.\_ It can also provide an email asset\
        \ inventory as well as providing data on spam, phishing and other email exploitation\
        \ techniques."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:3:6
      ref_id: 15.2.20
      description: "DMARC can be configured to produce an aggregate report and a forensic\
        \ report.\_ In some cases agencies may also send reports to an external organisation\
        \ such as a DMARC reporting service or a third-party IT service provider.\_\
        \ Discretion should be used when providing such information to third parties\
        \ in order to maintain security and privacy."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: Secure email transport
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      ref_id: 15.2.21
      description: Over time, several protocols have emerged to support the encryption
        of email traffic in transit. Secure email transport protects your email from
        person-in-the middle attacks like eavesdropping, manipulation, and cryptographic
        downgrade.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.22
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      ref_id: 15.2.22
      description: With parties that you contact regularly by email (eg, partner organisations),
        it is possible to configure connections so that TLS will always be used, and
        the certificates presented by both mail servers are authenticated, verifying
        the identities of both parties.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      description: STARTTLS, Opportunistic TLS
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:1
      ref_id: 15.2.23
      description: Opportunistic TLS is configured on the sending server. STARTTLS
        (RFC 3207) is a protocol command that upgrades an insecure connection to a
        secure connection using TLS. Agencies must enable opportunistic TLS encryption.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      description: Using MTA-STS
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.24
      description: SMTP MTA Strict Transport Security (MTA-STS) is a standard that
        adds support for strict encryption without relying on DNSSEC (RFC 8461). With
        MTA-STS, you can specify that mail traffic sent to a domain is encrypted with
        a specific public encryption key. Agencies should enable MTA-STS.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.25
      description: "The objectives of MTA-STS are to:\_\n\nmake it harder for an attacker\
        \ to intercept and redirect emails\_\nmake sure that TLS encryption is always\
        \ used,\nprevent attackers downgrading email encryption on emails to cleartext,\n\
        provide visibility reports through the TLS reporting protocol.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.26
      description: "To achieve this, MTA-STS works in the following ways:\n\nYour\
        \ organisation can advertise the mail server hostname on a separate secure\
        \ web page, which means an attacker cannot subvert your DNS entry (specifically\
        \ your MX record, which is the record that indicates how an email should be\
        \ routed using the Simple Mail Transfer Protocol).\nYour organisation can\
        \ publish an \u2018MTA-STS enforce policy\u2019, which tells any server sending\
        \ you emails to always send with TLS encryption, and to not allow connections\
        \ to be downgraded. If there is a failure to establish a secure TLS connection,\
        \ emails will not be delivered. Note that when your organisation sets up MTA-STS,\
        \ you are securing inbound connections only.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.27
      description: "MTA-STS is relatively simple to implement, but organisations must\
        \ step through their implementation with care; if you switch on controls too\
        \ quickly then inbound emails may not be delivered. To mitigate this risk,\
        \ we always recommend using MTA-STS in \u2018testing mode\u2019 first, and\
        \ to set up TLS-RPT (TLS Reporting) as a mechanism for getting feedback before\
        \ you progress."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.28
      description: "The goal ultimately is to work towards implementing an MTA-STS\
        \ policy of \u2018enforce\u2019. When a sending email service detects you\
        \ have an MTA-STS policy of \u2018enforce\u2019, they should only send email\
        \ to your domain if the connection is secure. Note however, that whilst many\
        \ major email providers have built support for MTA-STS, there is not yet complete\
        \ support from all vendors. For those that don\u2019t yet support it, emails\
        \ will continue to be delivered in all cases."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.29
      description: "While they achieve the same aim, DNS-based Authentication of Named\
        \ Entities (DANE) and MTA-STS do not conflict and can be implemented in parallel.\
        \ You can implement MTA-STS by deploying signed TLS certificates to a domain\u2019\
        s email and web servers, publishing an MTA-STS policy on the web server, and\
        \ publishing MTA-STS records in DNS. Like DMARC, MTA-STS supports the delivery\
        \ of aggregate reporting to system owners.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:2
      ref_id: 15.2.30
      description: "MTA-STS (Mail Transfer Agent \u2013 Strict Transport Security)\
        \ is configured on the receiving server, forcing inbound email connections\
        \ to use TLS if the sending server supports MTA-STS; there is no drop down\
        \ to cleartext. If the sending server does not support MTA-STS the connection\
        \ can use opportunistic TLS, or even send in the clear."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      description: TLS reporting
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:3
      ref_id: 15.2.31
      description: "Organisations should also enable TLS reporting when implementing\
        \ MTA-STS (RFC 8460). By implementing TLS reporting, organisations will be\
        \ able to see the performance of its domains, the success or failure rate,\
        \ and the impact of the organisation\u2019s MTA-STS and policies. This will\
        \ give organisations important insight into which mail services it needs to\
        \ configure to ensure no interruption in mail flow.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4
      description: Secure cryptography
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:4
      ref_id: 15.2.32
      description: Historically, network traffic between mail servers was unencrypted,
        leaving it vulnerable to interception or modification in transit. Although
        it is possible to encrypt individual emails using protocols like PGP or S/MIME,
        this requires the sender and recipient to have the necessary trust infrastructure
        in place. Approved implementation of S/MIME and OpenPGP are discussed in Chapter
        17, 17.6 Secure Multipurpose Internet Mail Extension, and 17.7 OpenPGP Message
        Format.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:4
      ref_id: 15.2.33
      description: This is not likely to be possible for all the parties you communicate
        with. So, your email servers should be configured to support encryption of
        the communications channel that the email is sent over. This task is best
        handled by TLS. Agencies should use the current version of TLS, see [CID:2598].
        When implementing MTA-STS, agencies should use TLS1.2 or above on email servers.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:4:4
      ref_id: 15.2.34
      description: 'Implementation details


        Configure all your email servers to support TLS, regardless of whether they
        are accessible from the internet or private networks only.

        Ensure your email servers present a certificate with suitable cryptographic
        properties and that it is signed by a trusted Certificate Authority.

        Ensure your email servers prefer to use a good cryptographic profile, but
        that lesser cryptographic profiles are supported too. You should support the
        case where TLS is not used at all, if you want to be confident you can receive
        emails from any entity.

        Where possible, consider configuring your email service to force TLS between
        you and organisations you regularly communicate with.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.35
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:5
      ref_id: 15.2.35
      description: "Further information on email security is available from the following\
        \ sources:\n\n\n\nReference\nTitle\nPublisher\nSource\n\n\nRFC 3207\nSMTP\
        \ Service Extension for Secure SMTP over Transport Layer Security\nIETF\n\
        RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security\
        \ (ietf.org)\n\n\nRFC 4686\nAnalysis of Threats Motivating DomainKeys Identified\
        \ Mail (DKIM)\nIETF\nRFC 4686 - Analysis of Threats Motivating DomainKeys\
        \ Identified Mail (DKIM) (ietf.org)\n\n\nRFC 6376\nDomainKeys Identified Mail\
        \ (DKIM) Signatures\nIETF\n\nRFC 6376 - DomainKeys Identified Mail (DKIM)\
        \ Signatures (ietf.org)\n\n\n\nRFC 5617\_\nDomainKeys Identified Mail (DKIM)\
        \ Author Domain Signing Practices (ADSP)\nIETF\n\nRFC 5617 - DomainKeys Identified\
        \ Mail (DKIM) Author Domain Signing Practices (ADSP) (ietf.org)\n\n\n\nRFC\
        \ 7817\nUpdated Transport Layer Security (TLS) Server Identity Check Procedure\
        \ for Email-Related Protocols\nIETF\n\nRFC 7817 - Updated Transport Layer\
        \ Security (TLS) Server Identity Check Procedure for Email-Related Protocols\
        \ (ietf.org)\n\n\n\nRFC 7208\nSender Policy Framework (SPF) for Authorizing\
        \ Use of Domains in Email, Version 1\nIETF\n\nRFC 7208 - Sender Policy Framework\
        \ (SPF) for Authorizing Use of Domains in Email, Version 1 (ietf.org)\n\n\n\
        \nRFC 7489\nDomain-based Message Authentication, Reporting, and Conformance\
        \ (DMARC)\nIETF\n\nRFC 7489 - Domain-based Message Authentication, Reporting,\
        \ and Conformance (DMARC) (ietf.org)\n\n\n\n\_RFC 7960\n\_Interoperability\
        \ Issues between Domain-based Message Authentication, Reporting, and Conformance\
        \ (DMARC) and Indirect Email Flows\nIETF\_\n\nRFC 7960 - Interoperability\
        \ Issues between Domain-based Message Authentication, Reporting, and Conformance\
        \ (DMARC) and Indirect Email Flows (ietf.org)\n\n\n\n\_RFC 8463\n\_A New Cryptographic\
        \ Signature Method for DomainKeys Identified Mail (DKIM)\nIETF\_\n\nRFC 8463\
        \ - A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)\
        \ (ietf.org)\n\n\n\nNIST SP 800-45 Version 2\nGuidelines on Electronic Mail\
        \ Security\nNIST\nSP 800-45 Version 2, Guidelines on Electronic Mail Security\
        \ | CSRC (nist.gov)\n\n\nNIST SP 800-177 Rev. 1\nTrustworthy Email\nNIST\n\
        SP 800-177 Rev. 1, Trustworthy Email | CSRC (nist.gov)\n\n\n\_\nEmail Authentication\
        \ Mechanisms: DMARC, SPF and DKIM\nNIST\nEmail Authentication Mechanisms:\
        \ DMARC, SPF and DKIM | NIST\n\n\n\_\nDMARC\nDMARC\ndmarc.org \u2013 Domain\
        \ Message Authentication Reporting & Conformance\n\n\n\_\nGuidelines for Email\n\
        ASD\nGuidelines for Email | Cyber.gov.au\n\n\n\_\nEnhance Email & Web Security\n\
        CISA\nEnhance Email & Web Security | CISA\n\n\n\_\nImplementation guidance:\
        \ email domain protection\nCCCS\nImplementation guidance: email domain protection\
        \ (ITSP.40.065 v1.1) - Canadian Centre for Cyber Security\n\n\n\_\nEmail security\
        \ and anti-spoofing\nNCSC-UK\nEmail security and anti-spoofing - NCSC.GOV.UK\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Domain-based Message Authentication, Reporting and Conformance
        (DMARC)
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.R.01
      description: "Phishing and malware distribution attacks are common internet\
        \ security threats.\_ To limit the possibility of agency domains being used\
        \ fraudulently (e.g. for spam or spear-phishing), agencies should implement:\n\
        \nA Sender Policy Framework (SPF);\nDomainKeys Identified Mail (DKIM); and\n\
        Domain-based Message Authentication, Reporting & Conformance (DMARC) records.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.R.02
      description: "It is important to note that DMARC depends on the proper implementation\
        \ of both SPF and DKIM.\_ DMARC records are published in the DNS and provide\
        \ guidance to the email receiver on actions to take when emails received do\
        \ not conform to the published record."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.C.01
      name: 'Control -  All Classifications - Must [CID: 6019]'
      description: 'Before implementing DMARC agencies MUST:


        Create a DMARC policy;

        List all domains, in particular those used for the sending and/or receiving
        of email;

        Review the configuration of SPF and DKIM for all active domains and all published
        domains; and

        Establish one or more monitored inboxes to receive DMARC reports.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.C.02
      name: 'Control -  All Classifications - Must [CID: 6020]'
      description: "Agencies MUST enable DMARC with\_a policy of p=reject for all\
        \ email originating from or received by their domain(s). See 15.2.16 for a\
        \ recommended approach where a domain is used for sending and/or receiving\
        \ email and disruption would cause a business impact."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.C.03
      name: 'Control -  All Classifications - Must [CID: 7519]'
      description: "Agencies MUST manage \u201Creceived DMARC messages\u201D in accordance\
        \ with the agency\u2019s published DMARC policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.C.04
      name: 'Control -  All Classifications - Must [CID: 6021]'
      description: Agencies MUST review DMARC reports on a regular basis and address
        any identified anomalies or security issues.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.36.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:1
      ref_id: 15.2.36.C.05
      name: 'Control -  All Classifications - Should [CID: 7520]'
      description: "Agencies SHOULD produce failure reports and aggregate reports\
        \ according to the agency\u2019s DMARC policies."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Filtering suspicious emails and attachments
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:2
      ref_id: 15.2.37.R.01
      description: "The intent of blocking specific types of emails is to reduce the\
        \ likelihood of phishing emails and emails or attachments containing malicious\
        \ code entering the agency\u2019s networks."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:2
      ref_id: 15.2.37.C.01
      name: 'Control -  All Classifications - Should [CID: 1745]'
      description: "Agencies SHOULD configure the following gateway filters:\n\ninbound\
        \ and outbound email, including any attachments, that contain:\n\nmalicious\
        \ code;\ncontent in conflict with the agency\u2019s email policy;\ncontent\
        \ that cannot be identified;\ndeny listed or unauthorised filetypes; and\n\
        \n\nencrypted content, when that content cannot be inspected for malicious\
        \ code or authenticated as originating from a trusted source;\nemails addressed\
        \ to internal-use only email aliases with source addresses located from outside\
        \ the domain; and\nall emails arriving via an external connection where the\
        \ source address uses an internal agency domain name.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Active web addresses (URL) embedded in emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.38.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:3
      ref_id: 15.2.38.R.01
      description: Spoofed emails often contain an active (embedded) email address
        directing users to a malicious website in order to infect the workstation
        or agency systems with malicious code.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.38.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:3
      ref_id: 15.2.38.R.02
      description: An effective defence is to strip and replace active addresses and
        hyperlinks with text only versions.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.38.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:3
      ref_id: 15.2.38.C.01
      name: 'Control -  All Classifications - Should [CID: 1749]'
      description: "Email servers SHOULD be configured to strip active addresses and\
        \ URL\u2019s and replace them with text only versions."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Preventing unmarked or inappropriately marked emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.R.01
      description: Unmarked or inappropriately marked emails can be blocked at two
        points, the workstation or the email server. The email server is often the
        preferred location to block emails as it is a single location under the control
        of system administrators that can enforce the requirement for the entire network.
        In addition email servers can apply controls for emails generated by applications.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.R.02
      description: Whilst blocking at the email server is considered the most appropriate
        control there is an advantage in also blocking at the workstation. This approach
        adds an extra layer of security and will also reduce the likelihood of a data
        spill occurring on the email server.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.R.03
      description: "For classified systems is it important to note that all emails\
        \ containing classified information MUST be protectively marked. \_This requirement\
        \ is outlined in Section 15.1 - Email Applications."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 1754]'
      description: Agencies MUST prevent unmarked and inappropriately marked emails
        being sent to intended recipients by blocking the email at the email server,
        originating workstation or both.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 1755]'
      description: Agencies MUST enforce protective marking of emails so that checking
        and filtering can take place.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.39.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:4
      ref_id: 15.2.39.C.03
      name: 'Control -  All Classifications - Should [CID: 1756]'
      description: Agencies SHOULD enforce protective marking of emails so that checking
        and filtering can take place.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Blocking of outbound emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.40.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:5
      ref_id: 15.2.40.R.01
      description: Blocking an outbound email with a valid protective marking or endorsement
        (e.g. NZEO) that indicates the email exceeds the classification of the communication
        path, stops data spills.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.40.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:5
      ref_id: 15.2.40.R.02
      description: "Agencies may remove protective markings from emails destined for\
        \ private citizens and businesses once they have been approved for release\
        \ from the agency\u2019s gateways."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.40.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:5
      ref_id: 15.2.40.C.01
      name: 'Control -  All Classifications - Must [CID: 1760]'
      description: Agencies MUST configure systems to block any outbound emails with
        a protective marking or endorsement indicating that the content of the email
        exceeds the classification of the communication path.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.40.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:5
      ref_id: 15.2.40.C.02
      name: 'Control -  All Classifications - Should [CID: 1761]'
      description: Agencies SHOULD configure systems to log every occurrence of a
        blocked email.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Blocking of inbound emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.41.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:6
      ref_id: 15.2.41.R.01
      description: Blocking an inbound email with a valid protective marking that
        indicates the email or its attachment exceeds the classification the receiving
        system is accredited to process will prevent a data spill from occurring on
        the receiving system.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.41.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:6
      ref_id: 15.2.41.C.01
      name: 'Control -  All Classifications - Must [CID: 1764]'
      description: Agencies MUST configure email systems to reject, log and report
        inbound emails with protective markings indicating that the content of the
        email exceeds the accreditation of the receiving system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.41.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:6
      ref_id: 15.2.41.C.02
      name: 'Control -  All Classifications - Should [CID: 1765]'
      description: Agencies SHOULD notify the intended recipient of any blocked emails.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Undeliverable messages
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.42.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:7
      ref_id: 15.2.42.R.01
      description: "Undeliverable or \u201Cbounce\u201D emails are commonly sent by\
        \ email servers to the original sender when the email cannot be delivered,\
        \ often because the destination address is invalid. \_Because of the common\
        \ spamming practice of spoofing sender addresses, this can result in a large\
        \ amount of bounce emails being sent to an innocent third party. \_Sending\
        \ bounces only to senders that can be verified via the Sender Policy Framework\
        \ (SPF) or other trusted means avoids contributing to this problem and allows\
        \ other government agencies and trusted parties to receive legitimate bounce\
        \ messages. See also 15.2.15 - Sender Policy Framework."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.42.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:7
      ref_id: 15.2.42.C.01
      name: 'Control -  All Classifications - Should [CID: 1768]'
      description: Agencies SHOULD only send notification of undeliverable, bounced,
        or blocked emails to senders that can be verified via SPF or other trusted
        means.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Automatic forwarding of emails
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.43.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:8
      ref_id: 15.2.43.R.01
      description: "Unsecured automatic forwarding of emails can pose a serious risk\
        \ to the unauthorised disclosure of classified information, for example, a\
        \ system user may set up a server-side rule to automatically forward all emails\
        \ to a personal email account. This can result in classified emails being\
        \ forwarded to the personal email account.\_This tactic may also be employed\
        \ when an email account is compromised."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.43.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:8
      ref_id: 15.2.43.C.01
      name: 'Control -  All Classifications - Must [CID: 1771]'
      description: Agencies MUST ensure that the requirements for blocking unmarked
        and outbound emails are also applied to automatically forwarded emails.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Open relay email servers
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.44.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:9
      ref_id: 15.2.44.R.01
      description: "An open relay email server (or open mail relay) is a server that\
        \ is configured to allow anyone on the Internet to send emails through the\
        \ server. \_Such configurations are highly undesirable as they allow spammers\
        \ and worms to exploit this functionality to send emails through the server.\_\
        Although no longer considered a significant vector for spam email, mail servers\
        \ identified as an open relay will still be added to reputation based block\
        \ lists."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.44.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:9
      ref_id: 15.2.44.C.01
      name: 'Control -  All Classifications - Must [CID: 1774]'
      description: "Agencies MUST disable open email relaying so that email servers\
        \ will only relay messages destined for the agency\u2019s domain(s) and those\
        \ originating from authorised systems or users within that domain."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Email server maintenance activities
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.45.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:10
      ref_id: 15.2.45.R.01
      description: Email servers perform a critical business function for many agencies;
        as such it is important that agencies perform regular email server auditing,
        security reviews and vulnerability analysis activities.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.45.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:10
      ref_id: 15.2.45.C.01
      name: 'Control -  All Classifications - Should [CID: 1777]'
      description: Agencies SHOULD perform regular email server auditing, security
        reviews and vulnerability analysis activities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Centralised email gateways
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.46.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:11
      ref_id: 15.2.46.R.01
      description: Without a centralised email gateway it is exceptionally difficult
        to deploy Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM)
        and outbound email protective markings verification.Attackers will almost
        invariably avoid using the primary email server when sending malicious emails.
        This is because the backup or alternative gateways are often poorly maintained
        with out-of-date deny lists and content filtering.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.46.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:11
      ref_id: 15.2.46.C.01
      name: 'Control -  All Classifications - Must [CID: 1780]'
      description: "Where an agency has system users that send email from outside\
        \ the agency\u2019s network, an authenticated and encrypted channel MUST be\
        \ configured to allow email to be sent via the centralised email gateway."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.46.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:11
      ref_id: 15.2.46.C.02
      name: 'Control -  All Classifications - Should [CID: 1781]'
      description: Agencies SHOULD route email through a centralised email gateway.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.46.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:11
      ref_id: 15.2.46.C.03
      name: 'Control -  All Classifications - Should [CID: 1782]'
      description: Where backup or alternative email gateways are in place, additional
        email gateways SHOULD be maintained at the same standard as the primary email
        gateway.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Transport Layer Security (TLS)
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.47.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:12
      ref_id: 15.2.47.R.01
      description: Email can be intercepted anywhere between the originating email
        server and the destination email server. Email transport between organisations
        and agencies is usually over the internet or other unsecured public infrastructure
        so it is important that email interception is carefully managed and suitable
        controls applied. One effective measure is to use TLS to encrypt the email
        traffic between email servers.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.47.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:12
      ref_id: 15.2.47.R.02
      description: "Enabling TLS on the originating and accepting email server will\
        \ defeat passive attacks on the network, with the exception of cryptanalysis\
        \ against email traffic. \_TLS encryption between email servers will not interfere\
        \ with email content filtering schemes. \_Email servers will remain compatible\
        \ with other email servers as IETF\u2019s RFC 3207 specifies the encryption\
        \ as opportunistic"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.47.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:12
      ref_id: 15.2.47.C.01
      name: 'Control -  All Classifications - Must [CID: 1786]'
      description: "Agencies MUST enable opportunistic TLS encryption as defined in\
        \ IETF\u2019s RFC 3207 on email servers that make incoming or outgoing email\
        \ connections over public infrastructure."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.47.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:12
      ref_id: 15.2.47.C.02
      name: 'Control -  All Classifications - Should [CID: 1787]'
      description: Agencies SHOULD implement TLS between email servers where significant
        volumes of classified information are passed via email to other agencies.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Mail transfer agent - strict transfer security
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.48.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      ref_id: 15.2.48.R.01
      description: "Where government-to-business and government-to-citizen communications\
        \ require a higher level of transport security, organisations should consider\
        \ implementing SMTP MTA Strict Transport Security (\u201CMTA-STS\u201D). MTA-STS\
        \ provides organisations with a mechanism to encrypt communications between\
        \ SMTP servers via TLS, preventing Person-In-The-Middle (PITM) attacks during\
        \ email delivery."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.48.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      ref_id: 15.2.48.R.02
      description: "Organisations should verify the following prior to deploying MTA-STS:\_\
        \n\ninternet-facing mail relays support SMTP over TLS version 1.2 or later,\n\
        web server hosting the policy file supports TLS (HTTPS),\ninternet-facing\
        \ mail relays use a TLS certificate issued by a root certificate authority\
        \ that is not expired and matches its domain name.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.48.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      ref_id: 15.2.48.C.01
      name: 'Control -  All Classifications - Should [CID: 7521]'
      description: Agencies SHOULD enable MTA-STS to prevent the unencrypted transfer
        of emails between complying servers.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.48.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      ref_id: 15.2.48.C.02
      name: 'Control -  All Classifications - Must [CID: 7522]'
      description: Agencies MUST use TLS 1.2 or above when implementing MTA-STS.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.48.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:13
      ref_id: 15.2.48.C.03
      name: 'Control -  All Classifications - Should [CID: 7523]'
      description: Agencies SHOULD enable TLS reporting when implementing MTA-STS.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: Sender Policy Framework (SPF)
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.R.01
      description: The Sender Policy Framework (SPF) is an open standard specifying
        a technical method to prevent sender address forgery.An SPF-protected domain
        is less attractive to spammers and phishers because the forged e-mails are
        more likely to be caught in spam filters which check the SPF record. Because
        an SPF-protected domain is less attractive as a spoofed address, it is less
        likely to be deny listed by spam filters and so is less disruptive to email
        traffic.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.R.02
      description: "Having a proper Sender Policy Framework (SPF) record increases\
        \ the chances people will get emails you send. \_Without one, your email has\
        \ a greater chance of being marked as Spam."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.R.03
      description: "SPF and alternatives such as Sender ID aid in the detection of\
        \ spoofed email server address domains. \_The SPF record specifies a list\
        \ of IP addresses or domains that are allowed to send mail from a specific\
        \ domain. \_If the email server that transmitted the email is not in the list,\
        \ the verification fails (there are a number of different fail types available)."
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.C.01
      name: 'Control -  All Classifications - Must [CID: 1792]'
      description: "Agencies MUST:\n\nspecify mail servers using SPF or Sender ID;\
        \ and\_\nmark, block or identify incoming emails that fail SPF checks for\
        \ notification to the email recipient.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.C.02
      name: 'Control -  All Classifications - Must [CID: 1793]'
      description: "Agencies MUST:\n\nuse a fail SPF record when specifying email\
        \ servers; and\_\nuse SPF or Sender ID to verify the authenticity of incoming\
        \ emails.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.49.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:14
      ref_id: 15.2.49.C.03
      name: 'Control -  All Classifications - Should [CID: 1794]'
      description: "Agencies SHOULD refer to the SPF recommendations in IETF\u2019\
        s RFC 7208."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6
      description: DomainKeys Identified Mail (DKIM)
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.50.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      ref_id: 15.2.50.R.01
      description: DKIM enables a method of determining spoofed email content. The
        DKIM record specifies a public key that will sign the content of the message.
        If the signed digest in the email header doesn't match the signed content
        of the email the verification fails.
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.50.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      ref_id: 15.2.50.C.01
      name: 'Control -  All Classifications - Must [CID: 1798]'
      description: Agencies MUST enable DKIM signing on all email originating from
        their domain.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.50.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      ref_id: 15.2.50.C.02
      name: 'Control -  All Classifications - Must [CID: 1797]'
      description: Agencies MUST use DKIM in conjunction with SPF.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.50.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      ref_id: 15.2.50.C.03
      name: 'Control -  All Classifications - Should [CID: 1799]'
      description: Agencies SHOULD verify DKIM signatures on emails received, taking
        into account that email distribution list software typically invalidates DKIM
        signatures.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:15.2.50.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:15.2:6:15
      ref_id: 15.2.50.C.04
      name: 'Control -  All Classifications - Should [CID: 1800]'
      description: "Where agencies operate email distribution list software used by\
        \ external senders, agencies SHOULD configure the software so that it does\
        \ not impair the validity of the sender\u2019s DKIM signature."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16
      assessable: false
      depth: 1
      ref_id: '16'
      name: Authentication and Access Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.1'
      name: Identification, Authentication and Authorisation
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:1
      ref_id: 16.1.1
      description: Access to information and systems is securely controlled and only
        provided to authorised entities, at all times.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:1
      ref_id: 16.1.2
      description: Identification and authentication requirements are implemented
        in order to provide a secure means of access to information and systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:2
      ref_id: 16.1.3
      description: The NZ Government Department of Internal Affairs (DIA) publishes
        a set of Identification Standards that work together to provide assurance
        that an organisation has the right information about the right entities and
        can use that to make access control decisions to ensure access is only provided
        to authorised entities.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:2
      ref_id: 16.1.4
      description: "Controls in these Identification Standards related to identification\
        \ and authentication are provided to facilitate credential provider\u2019\
        s ability to manage credentials to a level that will reduce the introduction\
        \ of systemic risk across the NZ Government. The controls are also broadly\
        \ acceptable to relying parties that are managing access to NZ Government\
        \ information and information systems."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:2
      ref_id: 16.1.5
      description: Access Controls can be defined as any mechanism by which an individual,
        system, or application grants or revokes the right to access a location, system,
        data, or perform an action.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:2
      ref_id: 16.1.6
      description: "Although access controls remain fundamentally the same in any\
        \ context, specific guidance and controls around virtualisation, cloud environments,\
        \ microservices and containerisation are documented in Chapter 22 \u2013 Enterprise\
        \ Systems Security and Chapter 23 \u2013 Public Cloud Security."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: New Zealand Government Identification Standards
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:3
      ref_id: 16.1.7
      description: 'The New Zealand Government publishes four Identification Standards:


        Information Assurance

        Binding Assurance

        Authentication Assurance

        Federation Assurance

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:3
      ref_id: 16.1.8
      description: The first three standards are relevant to Relying Parties; all
        standards are relevant to Credential Providers.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: Methods for user identification and authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:4
      ref_id: 16.1.9
      description: Authentication is detailed in the Authentication Assurance Standard
        and is the process by which an entity is verified before access permissions
        are confirmed, and access is granted to the entity requesting authentication.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:4
      ref_id: 16.1.10
      description: 'Authentication can be achieved by various means, including biometrics,
        cryptographic tokens, software tokens, passkeys, passphrases, passwords and
        smartcards.

        NB: Where the NZISM refers to passwords it equally applies to passphrases.'
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:4
      ref_id: 16.1.11
      description: "Authentication mechanisms are invariably described in terms of\
        \ factors of authentication as follows:\n\nSomething the entity has \u2013\
        \ the possession factor.\nSomething the entity knows \u2013 the knowledge\
        \ factor.\nSomething the entity is or does \u2013 the biometric factor.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:4
      ref_id: 16.1.12
      description: These authentication mechanisms may not provide sufficient protection
        when used in isolation. Using two or more authentication mechanisms provides
        additional security and is strongly advised.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: Methods for identification and authentication management
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:5
      ref_id: 16.1.13
      description: "There are two distinct roles performed for identification management\
        \ \u2013 a credential provider, and a relying party.\n\nCredential providers\
        \ establish credentials that are used by relying parties to identify and authenticate\
        \ users and systems. Entities expect these credentials to enable provision\
        \ of service to the right systems.\nRelying parties provide the services that\
        \ are being accessed by the authorised users (entities) and systems. Relying\
        \ parties use an entities\u2019 credentials to ensure the right authorisations\
        \ are in place prior to access of data or systems.\n\nNB: Entities (eg, a\
        \ person or system) use credentials from the credential provider to gain a\
        \ service from a relying party. The entity can either present their credentials\
        \ to a service provider or use the credential provider to directly present\
        \ the credentials to the relying party."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: Authenticating across multiple sign-ons
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:6
      ref_id: 16.1.14
      description: Federation allows credential service providers to provide authentication
        and subscriber attributes to a number of separately administered relying parties.
        These relying parties may use more than one credential service provider.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:6
      ref_id: 16.1.15
      description: 'Definitions relating to Federation include:


        Federated Identification Management (FIM) - Where a credential from a single
        credential provider may be used by a number of relying parties through an
        agreement that signifies trust between parties. This trust agreement is usually
        implemented through a process of federation between the parties.

        Single Sign On (SSO) - Where credentials, specifically authenticators, are
        used within the context of a single organisation/domain, system owners can
        exercise more discretion regarding the acceptance of risk associated with
        the selection of identification, authentication, and authorisation controls.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2
      description: 'Identification and authentication controls with Zero Trust '
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.16
      description: "Zero Trust (ZT) is a security concept based around a central principle\
        \ of \u2018never trust, always verify\u2019, being maintained through enforcing\
        \ accurate, least privilege per-request access decisions on systems, services\
        \ and networks."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.17
      description: ZT means continuous verification and enforcement of access controls,
        regardless of location. This includes continuous authentication of entities
        on internal network and zones.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.18
      description: "Implementation of ZT principles requires policy and procedure\
        \ changes within organisations. The principles also guide and control through\
        \ Network Access (ZTNA). \_Zero Trust implemented at a micro level (eg, segmentation\
        \ of networks, applications, environments, user and process-based) allows\
        \ more granular control of access enforcement of least privilege access policies."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.19
      description: SSO and FIM support ZT principles with a centralised model to approve
        and remove access to entities. The timely revocation of accesses when no longer
        required ensures strengthened security to services and data at a micro level.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.20
      description: Cloud services have been using a Zero Trust approach to security
        where policy decisions and policy enforcement points are used to control access
        based on authentication and privilege assignments. More information can be
        found in Chapter 23 - Public Cloud Security (reference 23.3.12).
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:2:7
      ref_id: 16.1.21
      description: "Successful implementation of Access Controls for ZT at an organisation\
        \ level can be supported by the following methods:\n\nImplementation of Multi-Factor\
        \ Authentication (MFA).\nUse of adaptive authentication based on contextual\
        \ factors (e.g. location, device, behaviour).\nLeast Privilege Access \u2013\
        \ enforced at a micro level within systems and networks. This may also include\
        \ just-in-time (JIT) delivery of privileges.\nCentralisation of user accounts\
        \ and accesses.\nPasswordless authentication models adopted within organisations.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.22
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:3
      ref_id: 16.1.22
      description: 'Additional information relating to Identification, Authentication
        and Authorisation can be found at:




        Title

        Publisher

        Source




        Identification Standards



        DIA



        Identification Management Standards | NZ Digital government





        Authentication Assurance Standard


        DIA

        Authentication Assurance Standard | NZ Digital government



        Assurance Services Panel

        GCDO

        GCDO Assurance Services Panel | NZ Digital government



        Mitigating the use of stolen credentials

        ASD

        PROTECT - Mitigating the Use of Stolen Credentials (October 2021).pdf (cyber.gov.au)



        Identity & Access Management

        NIST

        Identity & Access Management | NIST



        Implementing a Zero Trust Architecture

        NIST - NCCoE

        Implementing a Zero Trust Architecture | NCCoE



        Passwordless Authentication

        Microsoft Security

        Passwordless authentication | Microsoft Security



        AWS Identity and Access Management


        AWS


        Access Management- AWS Identity and Access Management (IAM) - AWS



        Identity and Network Access

        Microsoft

        Identity and Access Management System | Microsoft Security



        Password Storage Cheat Sheet

        OWASP

        Password Storage - OWASP Cheat Sheet Series



        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.23
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:4
      ref_id: 16.1.23
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\nPSR Mandatory Requirements\n\nGOV5,\_GOV6, GOV7,\_\nINFOSEC1,\
        \ INFOSEC2, INFOSEC3, INFOSEC4,\nPERSEC1, PERSEC2, PERSEC3, PERSEC4,\nPHYSEC1,\
        \ PHYSEC2\n\n\nHome | Protective Security Requirements\nSecurity governance\
        \ (GOV) | Protective Security Requirements\nInformation security (INFOSEC)\
        \ | Protective Security Requirements\nPersonnel security (PERSEC) | Protective\
        \ Security Requirements\nPhysical security (PHYSEC) | Protective Security\
        \ Requirements\n\n\n\n\nPSR content protocols \n\n\nManagement protocol for\
        \ information security\nManagement protocol for personnel security\nManagement\
        \ Protocol for physical security\_\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\n\_\nManagement protocol for\
        \ physical security | Protective Security Requirements\n\n\n\n\nPSR requirements\
        \ sections\n\n\nSecurity zones\nHandling requirements for protectively marked\
        \ information and equipment\nSupply chain security\nUnderstand the physical\
        \ security lifecycle\_\n\n\nPhysical security zones | Protective Security\
        \ Requirements\nClassification system | Protective Security Requirements\n\
        Supply chain security | Protective Security Requirements\n\_\nUnderstanding\
        \ the information security lifecycle | Protective Security Requirements\n\n\
        \n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nMobile and remote working\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Policies and procedures
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:1
      ref_id: 16.1.24.R.01
      description: "Developing policies and procedures will ensure consistency in\
        \ managing identification, authentication and authorisation across agency\
        \ systems. Refer also to\_Section 16.4 \u2013 Privileged Access Management."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:1
      ref_id: 16.1.24.C.01
      name: 'Control -  All Classifications - Must [CID: 1827]'
      description: "Agencies MUST:\n\ndevelop, implement and maintain a set of policies\
        \ and procedures covering all system users\u2019:\n\nidentification;\nauthentication;\_\
        \nauthorisation;\nprivileged access identification and management; and\n\n\
        \nmake their system users aware of the agency\u2019s policies and procedures.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Implement zero trust principles
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:2
      ref_id: 16.1.25.R.01
      description: Agencies can be especially vulnerable to threats when internal
        systems can be accessed externally from the organisation. Implementing access
        through Zero Trust principles and architecture provides organisations with
        an enhanced security posture to ensure potential access threats on systems
        are minimised.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:2
      ref_id: 16.1.25.C.01
      name: 'Control -  All Classifications - Should [CID: 7541]'
      description: Agencies SHOULD design and implement Zero Trust principles and
        architecture to strengthen identification management.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Unique system user identification
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:3
      ref_id: 16.1.26.R.01
      description: Having uniquely identifiable system users ensures accountability.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:3
      ref_id: 16.1.26.C.01
      name: 'Control -  All Classifications - Must [CID: 1829]'
      description: "Agencies MUST ensure that all system users are:\n\nuniquely identifiable;\
        \ and\nauthorised\_and authenticated on each occasion that access is granted\
        \ to a system.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Shared accounts
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:4
      ref_id: 16.1.27.R.01
      description: "Sharing of credentials (eg, passwords and UserIDs) may be convenient\
        \ but doing so is highly risky. Shared credentials can defeat accountability\
        \ and the attribution and non-repudiation principles of access controls.\_\
        \ The risk increases when shared credentials are used for administrative privileges\
        \ or access to classified information."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:4
      ref_id: 16.1.27.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must Not [CID: 1832]'
      description: Agencies MUST NOT use shared credentials to access accounts.
      implementation_groups:
      - Secret - MUST NOT
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.27.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:4
      ref_id: 16.1.27.C.02
      name: 'Control -  All Classifications - Must Not [CID: 7542]'
      description: 'Agencies MUST NOT use shared credentials to access administrator
        or privileged access accounts.

        NB: Break Glass accounts are exempt from this control. For further guidance
        on Break Glass accounts see Emergency accounts (Break Glass accounts section).'
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.27.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:4
      ref_id: 16.1.27.C.03
      name: 'Control -  All Classifications - Should Not [CID: 1833]'
      description: Agencies SHOULD NOT use shared credentials to access accounts.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: System user identification for shared accounts
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:5
      ref_id: 16.1.28.R.01
      description: "Agencies may have a compelling business reason for the use of\
        \ shared accounts.\_ These may include anonymous, guest and temporary employee\
        \ credentials."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.28.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:5
      ref_id: 16.1.28.R.02
      description: "As shared accounts are non-entity specific, agencies will need\
        \ to determine an appropriate method for attributing actions undertaken using\
        \ such accounts to specific personnel, and these are recorded or documented.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:5
      ref_id: 16.1.28.C.01
      name: 'Control -  All Classifications - Must [CID: 1837]'
      description: If agencies choose to allow shared, non user-specific accounts
        they MUST ensure that an independent means of determining the identification
        of the system user is implemented and logged.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Methods for system user identification and authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:6
      ref_id: 16.1.29.R.01
      description: A personal identification number (PIN) is typically short in length
        and employs a small character set, making it susceptible to brute force attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.29.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:6
      ref_id: 16.1.29.R.02
      description: Combining multiple methods when authenticating users can help to
        create a layered defence, making it harder for successful brute force attacks.
        Eg, a PIN connected to a hardware backed security measure like a trusted platform
        module (TPM) means the PIN is bound to a specific device.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:6
      ref_id: 16.1.29.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1840]'
      description: Agencies MUST NOT use a numerical password (or personal identification
        number) as the sole method of authenticating a system user to access a system.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.29.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:6
      ref_id: 16.1.29.C.02
      name: 'Control -  All Classifications - Should [CID: 1841]'
      description: Agencies SHOULD use multi-factor authentication (MFA) when identifying
        and authenticating system users.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Centralisation of Identification and Authentication Management
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:7
      ref_id: 16.1.30.R.01
      description: "Centralising authentication and the reliance on single credentials\
        \ to access multiple systems and wider organisations (eg, SSO, FIM) enhances\
        \ an organisation\u2019s security posture through:\n\ncentralisation to control\
        \ access (joiners, movers, leavers);\nreducing risk of password fatigue;\n\
        enforcing strong access controls;\nenforcing password policies; and\nreducing\
        \ the risk of misconfiguration.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:7
      ref_id: 16.1.30.R.02
      description: Centralised access management systems are beneficial to agencies;
        however, they also have the potential to introduce additional system risk
        to organisations. FIM may introduce additional risk due to sharing of credentials
        across external organisations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:7
      ref_id: 16.1.30.C.01
      name: 'Control -  All Classifications - Should [CID: 7543]'
      description: Agencies SHOULD assess and determine the risk of centralised access
        management systems, including SSO, to safely manage integration into systems
        and when using FIM.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Passwords and policies
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.01
      description: "Passwords have historically been the primary authentication mechanism\
        \ for almost all information systems and are a fundamental part of access\
        \ and authentication.\_ While there are other forms of authentication mechanisms\
        \ available that can provide more robust security to attack vectors and threats\
        \ in the environment, passwords remain a cost-effective baseline for authentication\
        \ systems."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.02
      description: "Passwords have traditionally been the terminology used for the\
        \ memorised secrets allowing access and authorisation onto systems. The term\
        \ \u2018passphrases\u2019 is often referred to in place of \u2018passwords\u2019\
        , as it denotes longer (more secure), easier to remember memorised secrets.\n\
        Where the NZISM references passwords, it equally applies to passphrases."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.03
      description: "Passwords are subject to three primary groups of risks:\n1.\_\_\
        \_\_\_\_ Intentional sharing.\n2.\_\_\_\_\_\_ Theft, loss or compromise.\n\
        3.\_\_\_\_\_\_ Guessing and cracking."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.04
      description: 'Associated with these risk groups are four principal methods of
        attacking passwords:


        Interactive attempts including brute force attacks or some knowledge of the
        user or organisation.

        Obtaining through social engineering or phishing.

        Compromising through oversight, observation, use of keyloggers, cameras etc.

        Decryption of network traffic interception, misconfiguration, data capture
        etc.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.05
      description: Password controls detailed in this section are designed to manage
        and mitigate these risk groups and attack methods. These controls will only
        be effective alongside organisation specific password policies and mandatory
        training for all system users.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.06
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.06
      description: Whilst passwords provide some security to systems, they still carry
        inherent risks. A layered approach to authentication is essential to ensuring
        systems and organisations are not made vulnerable from the authentication
        mechanisms used.This includes establishing additional system controls alongside
        passwords. For example, ensuring MFA is mandatory in organisations, or mandating
        secure storage of passwords within organisations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.07
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.07
      description: Mandatory training for all employees, including senior management,
        on these policies is essential to manage and mitigate risks associated with
        password attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.08
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.08
      description: 'While implementing long and complex passwords is regarded as a
        fundamental security practice, it does not fully mitigate the risks associated
        with password-related attacks. A primary challenge can come from human behaviours.
        Unless password generators are employed, users often create non-unique passwords
        based on predictable patterns, even for lengthy credentials.

        Multi-layered approaches such as MFA, passwordless authentication, and password
        expiries can help to mitigate these attacks.'
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.09
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.09
      description: Ensure a balance of security and usability considerations when
        deciding on implementing a password expiry policy for the organisation.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.r.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.R.10
      description: It is vital that the security posture of a system is not weakened
        through authentication mechanisms. This relies on increasing the authentication
        and authorisation controls, including moving to appropriate multi-factor authentication,
        and stronger identify access management.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.01
      name: 'Control -  All Classifications - Must [CID: 7544]'
      description: Agencies MUST ensure adequate password policies are implemented
        and enforced across all systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.02
      name: 'Control -  All Classifications - Must [CID: 7545]'
      description: Agencies MUST implement a password policy enforcing at least annual
        password changes on systems that have not implemented MFA or passwordless
        authentication.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.03
      name: 'Control -  All Classifications - Must [CID: 7546]'
      description: 'Agencies MUST implement a password policy enforcing:


        A minimum password length of 16 characters (e.g four words).

        Passwords must be long, strong and unique. This means passwords must be a
        minimum character length, and are a combination of unique random words, characters
        or numbers.


        NB: no explicit complexity requirements are enforced (e.g. numbers or special
        characters), however passwords must be unique, or random and may include special
        characters and numbers to achieve this.'
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.04
      name: 'Control -  All Classifications - Must [CID: 7547]'
      description: "To ensure security of systems are not weakened through authentication\
        \ mechanisms, at a minimum, agencies MUST:\n\napply MFA appropriately (refer\
        \ to controls in Section 16.7);\nensure authentication secrets (including\
        \ passwords) are securely stored;\nremove knowledge-based questions from authentication\
        \ process (eg, dog\u2019s name, first school etc.);\nnew passwords are screened\
        \ to reduce the likelihood of previously compromised passwords;\nremove hints\
        \ from authentication process; and\nchange passwords when a suspected or known\
        \ compromise of an account has occurred.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.05
      name: 'Control -  All Classifications - Must Not [CID: 1869]'
      description: 'Agencies MUST NOT:


        allow predictable reset passwords;

        store passwords in the clear on the system; and

        reuse passwords when resetting multiple accounts.

        '
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.06
      name: 'Control -  All Classifications - Should [CID: 7548]'
      description: Agencies SHOULD consider the use of location-based factors in the
        authentication process, (e.g., Users must be at an expected location (city,
        country, IP address) and provide the correct credentials for the authentication
        to succeed).
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.31.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:8
      ref_id: 16.1.31.C.07
      name: 'Control -  All Classifications - Should [CID: 7549]'
      description: When creating password policies, agencies SHOULD consider implementing
        annual password changes.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Protecting stored authentication information
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.32.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:9
      ref_id: 16.1.32.R.01
      description: "When moving to passwordless authentication, agencies SHOULD carry\
        \ out a risk assessment and evaluate passwordless authentication models to\
        \ choose authentication mechanisms and factors that best fit the organisation\u2019\
        s security and authentication requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.32.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:9
      ref_id: 16.1.32.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1844]'
      description: Agencies MUST NOT allow storage of unprotected authentication information
        that grants system access, or decrypts an encrypted device, to be located
        on, or with the system or device, to which the authentication information
        grants access.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Protecting authentication data in transit
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.33.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:10
      ref_id: 16.1.33.R.01
      description: Secure transmission of authentication information will reduce the
        risk of interception and subsequent use of the authentication information
        by an attacker to access a system under the guise of a valid system user.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.33.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:10
      ref_id: 16.1.33.C.01
      name: 'Control -  All Classifications - Must [CID: 1847]'
      description: Agencies MUST ensure that system authentication data is protected
        when in transit on organisation networks or All-of-Government systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Hashing
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:11
      ref_id: 16.1.34.R.01
      description: "Hashing is a means of protecting stored passwords or other authentication\
        \ secrets by cryptographically converting the password to fixed length ciphertext.\_\
        \ This protects against incidents where an unsanctioned copy of the password\
        \ or authentication database has been made, exported or the database otherwise\
        \ compromised.\_ Approved cryptographic protocols are discussed in Chapter\
        \ 17 - Cryptography. See also section\_17.2 - Approved Cryptographic Algorithms\_\
        for discussion on the use of salts to strengthen the cryptographic resistance\
        \ of a hash."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:11
      ref_id: 16.1.34.C.01
      name: 'Control -  All Classifications - Must [CID: 6553]'
      description: "Password and other authentication secrets MUST be hashed before\
        \ storage using an approved cryptographic protocol and algorithm. See Chapter\
        \ 17 \u2013 Cryptography. "
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.34.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:11
      ref_id: 16.1.34.C.02
      name: 'Control -  All Classifications - Must [CID: 7562]'
      description: "Passwords and other authentication secrets MUST be stored securely\
        \ including being:\n\nsalted (32 bits or more),\n\nsalts should be unique\
        \ to each password and should be randomly generated.\n\n\nhashed (HMAC using\
        \ SHA-2/3), and\n\u201Cstretched\u201D (such as PBKDF2 with at least:\n\n\
        600k iterations with internal hash function of HMAC-SHA-256; or\n210k iterations\
        \ with internal hash function of HMAC-SHA-512).\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Identification of foreign nationals
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.35.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:12
      ref_id: 16.1.35.R.01
      description: "Where systems contain NZEO or other nationalities releasability\
        \ marked or protectively marked information, and foreign nationals have access\
        \ to such systems, it is important that agencies implement appropriate security\
        \ measures to assist in identifying users that are foreign nationals. \_Such\
        \ measures will assist in preventing the release of sensitive information\
        \ to those not authorised to access it."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.35.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:12
      ref_id: 16.1.35.C.01
      name: 'Control -  All Classifications - Must [CID: 1850]'
      description: Where systems contain NZEO or other nationalities releasability
        marked or protectively marked information, agencies MUST provide a mechanism
        that allows system users and processes to identify users who are foreign nationals,
        including seconded foreign nationals.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.35.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:12
      ref_id: 16.1.35.C.02
      name: 'Control -  All Classifications - Should [CID: 1851]'
      description: Agencies using NZEO systems SHOULD ensure that identification includes
        specific nationality for all foreign nationals, including seconded foreign
        nationals.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Resetting passwords and authentication vectors
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      ref_id: 16.1.36.R.01
      description: "To reduce the likelihood of social engineering attacks aimed at\
        \ service desks, agencies will need to ensure that system users provide sufficient\
        \ evidence to prove they are the owner of the system account when requesting\
        \ a password reset for their system account.\_\nThis evidence could be in\
        \ the form of:\n\n\_ \_ \_ \_ \_the system user physically presenting themselves\
        \ and their security pass to service desk personnel who then reset their password;\n\
        physically presenting themselves to a known authorised colleague who uses\
        \ an approved online tool to reset their password; or\nproviding a MFA code.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.36.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      ref_id: 16.1.36.R.02
      description: "Issuing complex reset passwords maintains the security of the\
        \ user account during the reset process. \_This can also present an opportunity\
        \ to demonstrate the selection of strong passwords."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      ref_id: 16.1.36.C.01
      name: 'Control -  All Classifications - Must [CID: 1875]'
      description: Agencies MUST ensure system users provide sufficient evidence to
        prove they are the owner of the account when requesting a password reset for
        their system account or making changes to their multi-factor authenticators.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.36.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      ref_id: 16.1.36.C.02
      name: 'Control -  All Classifications - Must [CID: 7551]'
      description: Where passwords are not set by the account holder, agencies MUST
        use temporary passwords when resetting system user accounts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.36.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:13
      ref_id: 16.1.36.C.03
      name: 'Control -  All Classifications - Should Not [CID: 7552]'
      description: "Agencies SHOULD NOT use single factor authentication when changing\
        \ users\u2019 Multi-Factor Authentication details."
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Securing Passwords
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.R.01
      description: Security of passwords is fundamental to ensuring system security
        across organisations. Password policies need to include how passwords are
        kept secure while passwords are in transit, stored or being used.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.R.02
      description: Use of password managers within agencies provide employees a system
        to generate, secure, store, and distribute passwords. The paradigm behind
        a password manager is for an individual to store passwords and memorised secrets
        securely in a vault behind a single strong password. This generally means
        authentication secrets are at less risk of attacks and help to support a strengthened
        organisation security posture.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.R.03
      description: Password managers store highly sensitive data, therefore it is
        imperative that agencies have completed a risk analysis and due diligence
        to ensure that passwords are suitably protected with the password manager,
        and are not accessible to third parties.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.R.04
      description: When using password managers, passwords may be stored in an encrypted
        form rather than salted and hashed. This is required for a password manager
        to function, and the technical risks associated with this are considered acceptable
        when addressing the risks of password re-use due to users needing to remember
        many different passwords. To mitigate this additional technical risk we recommend
        using MFA on the password manager.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.C.01
      name: 'Control -  All Classifications - Must [CID: 7558]'
      description: Password managers provide no additional security to the sign-in
        password. Agencies using password managers MUST ensure sign-in passwords adhere
        to the password security policies used by the organisation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.37.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:14
      ref_id: 16.1.37.C.02
      name: 'Control -  All Classifications - Should [CID: 7559]'
      description: Agencies using password managers SHOULD consider the use of MFA
        to access the password manager.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Passwordless Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.01
      description: Use of passwords are a common method of authenticating entities.
        Due to high reliance (from organisations) on passwords to control accesses,
        threat actors commonly use passwords as an attack vector to gain access into
        networks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.02
      description: "Passwordless authentication provides additional security mechanisms\
        \ by moving away from \u2018something you know\u2019 and placing emphasis\
        \ on other verification factors such as \u2018something you have\u2019 or\
        \ \u2018something you are\u2019. These alternative authentication models can\
        \ rely on other factors such as something you are or something you have (eg,\
        \ biometrics, tokens, and authentication applications)."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.03
      description: "Implementation of these alternative authentication models can\
        \ be accomplished based on systems requirements and the access controls needs\
        \ of organisations and systems.\_ These alternative authentication models\
        \ provide a range of security levels. Security levels of these passwordless\
        \ authentication models, and how these are implemented in agencies have a\
        \ significant impact on the level of security provided."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.04
      description: Prior to moving to passwordless authentication, agencies will need
        to consider cost, risks, and benefits to identify which authentication models
        are best suited to their systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.05
      description: "Passwordless authentication does not mean \u2018no authentication\u2019\
        ."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.06
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.06
      description: Passwordless authentication moves systems toward possession factors
        (something you have or something you are) and away from using memorised secrets
        (something you know) as the primary way to authenticate users. This can provide
        additional security measures to ensure adequate authentication, and when used
        in conjunction with adequate controls and security policies, passwordless
        authentication can minimise the success of a phishing attack.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.r.07
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.R.07
      description: Security strength of passwordless authentication models rely on
        what and how organisations implement architecture to support this. Although
        implementation of passwordless authentication by itself can be more secure
        than passwords, MFA used in conjunction with this architecture will significantly
        minimise the risk of compromise within agencies by adding another layer of
        security.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.38.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:15
      ref_id: 16.1.38.C.01
      name: 'Control -  All Classifications - Should [CID: 7556]'
      description: "When moving to passwordless authentication, agencies SHOULD carry\
        \ out a risk assessment and evaluate passwordless authentication models to\
        \ choose authentication mechanisms and factors that best fit the organisation\u2019\
        s security and authentication requirements."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:16
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Disabling vulnerable authentication mechanisms
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.39.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:16
      ref_id: 16.1.39.R.01
      description: The use of adequate and secure authentication mechanisms is an
        essential part of ensuring and maintaining secure systems and user accounts.
        Replacing mechanisms with known vulnerabilities for products with stronger
        authentication protocols should be considered.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.39.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:16
      ref_id: 16.1.39.C.01
      name: 'Control -  All Classifications - Must [CID: 7554]'
      description: Agencies MUST ensure authentication methods that are susceptible
        to replay attacks are disabled.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.39.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:16
      ref_id: 16.1.39.C.02
      name: 'Control -  All Classifications - Must [CID: 1878]'
      description: Agencies MUST disable LAN Manager for password authentication on
        workstations and servers.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Session termination
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.40.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:17
      ref_id: 16.1.40.R.01
      description: Developing a policy to automatically logout workstations after
        an appropriate time of inactivity will assist in preventing the compromise
        of unattended workstations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.40.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:17
      ref_id: 16.1.40.R.02
      description: "Restarting of workstations after automatically logging out ensures\
        \ cached credentials, authentication tokens or session keys that may persist\
        \ after logging out are removed. It can also ensure any services and drivers\
        \ are securely reloaded on systems.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.40.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:17
      ref_id: 16.1.40.R.03
      description: "Session tokens are a vector for account compromise. \_The session\
        \ length of a session token is the lifespan of the token; specifically, how\
        \ long the user remains authenticated before reauthentication is required.\
        \ The length of these session tokens should be considered to minimise risk\
        \ of attacks through this mechanism. Length of session tokens will be different\
        \ across organisations and systems, based on risk appetite and specific requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.40.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:17
      ref_id: 16.1.40.C.01
      name: 'Control -  All Classifications - Should [CID: 1881]'
      description: Agencies SHOULD develop and implement a policy to automatically
        logout and shutdown workstations after an appropriate time of inactivity.
        This includes invalidating any session tokens.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:18
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Screen and session locking
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.41.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:18
      ref_id: 16.1.41.R.01
      description: Screen and session locking will prevent access to an unattended
        workstation.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.41.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:18
      ref_id: 16.1.41.R.02
      description: Ensuring that the screen does not appear to be turned off before
        entering the locked state will prevent system users from forgetting they are
        still logged in and will prevent other system users from mistakenly thinking
        there is a problem with a workstation and resetting it.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.41.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:18
      ref_id: 16.1.41.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 1885]'
      description: 'Agencies MUST:


        configure systems with a screen and session lock;

        configure the lock to activate:


        after a maximum of 10 minutes of system user inactivity; or

        if manually activated by the system user;



        configure the lock to completely conceal all information on the screen;

        ensure that the screen is not turned off or enters a power saving state before
        the screen or session lock is activated;

        have the user reauthenticate to unlock the system; and deny users the ability
        to disable the locking mechanism.

        '
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.41.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:18
      ref_id: 16.1.41.C.02
      name: 'Control -  All Classifications - Should [CID: 1886]'
      description: 'Agencies SHOULD:


        configure systems with a session or screen lock;

        configure the lock to activate:


        after a maximum of 10 minutes of system user inactivity; or

        if manually activated by the system user;



        configure the lock to completely conceal all information on the screen;

        ensure that the screen is not turned off or enters a power saving state before
        the screen or session lock is activated;

        have the system user reauthenticate to unlock the system; and

        deny system users the ability to disable the locking mechanism.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Suspension of access
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.42.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      ref_id: 16.1.42.R.01
      description: Locking a user account after a specified number of failed logon
        attempts will reduce the success of brute force attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.42.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      ref_id: 16.1.42.R.02
      description: Removing a system user account when it is no longer required will
        prevent personnel from accessing their old account and reduce the number of
        accounts that an attacker can target.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.42.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      ref_id: 16.1.42.R.03
      description: Suspending inactive accounts after a specified number of days will
        reduce the number of accounts that an attacker can target.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.42.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      ref_id: 16.1.42.R.04
      description: Investigating repeated account lockouts will reduce the security
        risk of any ongoing brute force logon attempts or inappropriate use of user
        accounts for services and allow security management to act accordingly.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.42.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:19
      ref_id: 16.1.42.C.01
      name: 'Control -  All Classifications - Must [CID: 1892]'
      description: 'Agencies MUST:


        Record all successful and failed logon attempts;

        lock system user accounts after three failed logon attempts;

        use a temporary lock out feature to unlock system (max [] times);

        have a system administrator reset locked accounts if [] times is superseded;

        remove or suspend system user accounts as soon as possible when personnel
        no longer need access due to changing roles or leaving the organisation; and

        remove or suspend inactive accounts after a specified number of days.


        NB: Agencies can determine the risk of using a temporary lock out feature
        on their specific systems.

        [] indicates the chosen ''value of times'' an agency has decided to use for
        the temporary lock out feature.'
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:20
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Investigating repeated account lockouts
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.43.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:20
      ref_id: 16.1.43.R.01
      description: Repeated account lockouts may be an indicator of attempted account
        compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.43.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:20
      ref_id: 16.1.43.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Should [CID: 1896]'
      description: Agencies SHOULD ensure that repeated account lockouts are investigated
        before reauthorising access.
      implementation_groups:
      - Confidential - SHOULD
      - Secret - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1:5:21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5
      description: Logon banner
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.44.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:21
      ref_id: 16.1.44.R.01
      description: "A logon banner for a system serves to remind system users of their\
        \ responsibilities when using the system.\_ It may also be described as a\
        \ \u201CSplash Screen\u201D, \u201CAcceptable Use Policy\u201D or \u201CUser\
        \ Consent Screen\u201D."
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.44.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:21
      ref_id: 16.1.44.C.01
      name: 'Control -  All Classifications - Should [CID: 1899]'
      description: Agencies SHOULD have a logon banner that requires a system user
        to acknowledge and accept their security responsibilities before access to
        the system is granted.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.44.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:21
      ref_id: 16.1.44.C.02
      name: 'Control -  All Classifications - Should [CID: 1900]'
      description: Agencies SHOULD seek legal advice on the exact wording of logon
        banners.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.1.44.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.1:5:21
      ref_id: 16.1.44.C.03
      name: 'Control -  All Classifications - Should [CID: 1901]'
      description: "Agency logon banners SHOULD cover issues such as:\n\nthe system\u2019\
        s classification;\naccess only being permitted to authorised system users;\n\
        the system user\u2019s agreement to abide by relevant security policies;\n\
        the system user\u2019s awareness of the possibility that system usage is being\
        \ monitored;\nthe definition of acceptable use for the system; and\nlegal\
        \ ramifications of violating the relevant policies.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.2'
      name: System Access
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:1
      ref_id: 16.2.1
      description: Access to information on systems is controlled in accordance with
        agency policy and the NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:2:1
      ref_id: 16.2.2
      description: This section covers information on accessing systems for all system
        users.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:2:1
      ref_id: 16.2.3
      description: Additional information on privileged users can be found in Section
        16.3 - Privileged User Access and additional information on security clearance,
        briefing and authorisation requirements can be found in Section 9.2 - Authorisations,
        Security Clearances and Briefings.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3
      description: Access control lists
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:1
      ref_id: 16.2.4.R.01
      description: A clearly defined process will assist an organisation in the consistent
        development of access control lists for their systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:1
      ref_id: 16.2.4.C.01
      name: 'Control -  All Classifications - Must [CID: 1930]'
      description: 'Agencies MUST follow a defined process for developing an access
        control list, such as described in the table below.




        Stage

        Description



        1

        Establish groups of all system resources based on similar security objectives.



        2

        Determine the information owner for each group of resources.



        3


        Obtain agreement from system owners.




        4


        Establish groups encompassing all system users based on similar functions
        or security objectives.




        5


        Determine the group owner or manager for each group of system users.




        6


        Determine the degree of access to the resource for each system user group,
        incorporating the principal of least-privilege access.




        7


        Decide on the level of access for security administration, based on the internal
        security policy.




        8


        Identify any classification, protective markings, and releasability indicators
        (such as NZEO or compartmented information).




        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3
      description: Enforcing authorisations on systems
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:2
      ref_id: 16.2.5.R.01
      description: Use of access controls on a system will assist in enforcing the
        need-to-know principle. How access controls are set up in organisations are
        becoming increasing important to mitigate threats and minimise attack surfaces.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:2
      ref_id: 16.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1924]'
      description: Agencies MUST have authorisation of system users enforced by access
        controls.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3
      description: Protecting compartmented information on systems
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:3
      ref_id: 16.2.6.R.01
      description: Compartmented information is particularly sensitive and as such
        extra measures need to be put in place on systems to restrict access to those
        with sufficient authorisation, briefings and a demonstrated need-to-know or
        need- to access.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:3
      ref_id: 16.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 1927]'
      description: Agencies MUST restrict access to compartmented information. Such
        restriction MUST be enforced by the system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.2:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3
      description: Access from foreign controlled systems and facilities
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:4
      ref_id: 16.2.7.R.01
      description: If a New Zealand system is to be accessed overseas it will need
        to be from at least a facility owned by a country that New Zealand has a multilateral
        or bilateral agreement with. NZEO systems can be accessed only from facilities
        under the sole control of the government of New Zealand and by New Zealand
        citizens.
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:4
      ref_id: 16.2.7.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1920]'
      description: Agencies MUST NOT allow access to NZEO information from systems
        and facilities not under the sole control of the government of New Zealand
        and New Zealand citizens.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.2.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.2:3:4
      ref_id: 16.2.7.C.02
      name: 'Control -  All Classifications - Should Not [CID: 1921]'
      description: Unless a multilateral or bilateral security agreement is in place,
        agencies SHOULD NOT allow access to classified information from systems and
        facilities not under the sole control of the government of New Zealand and
        New Zealand citizens.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.3'
      name: Privileged User Access
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:1
      ref_id: 16.3.1
      description: Only trusted personnel are granted privileged access to systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:2:1
      ref_id: 16.3.2
      description: "This section covers information relating specifically to personnel\
        \ that are granted privileged access to systems.\_Refer also to Section 16.4\
        \ \u2013 Privileged Access Management."
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:2
      description: Privileged access
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:2:2
      ref_id: 16.3.3
      description: 'Within this section, privileged access is, considered to be access
        which can give a system user:


        the ability to change key system configurations;

        the ability to change control parameters;

        access to audit and security monitoring information;

        the ability to circumvent security measures;

        access to all data, files and accounts used by other system users, including
        backups and media; or

        special access for troubleshooting the system.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:3
      ref_id: 16.3.4
      description: "Additional information relating to privileged and system accounts,\
        \ including monitoring, is contained in:\n\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\nRestricting administrative privileges\n\nASD\n\nRestricting\
        \ Administrative Privileges | Cyber.gov.au\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4
      description: Use of privileged accounts
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:1
      ref_id: 16.3.5.R.01
      description: Inappropriate use of any aspect of a system that enables a privileged
        user to override system or application controls can be a major contributory
        factor to failures, information security incidents, or system breaches.
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:1
      ref_id: 16.3.5.R.02
      description: Privileged access rights allow for system wide changes to be made,
        as such logging, monitoring and strong change management practice provide
        greater accountability and auditing capability.
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:1
      ref_id: 16.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 1945]'
      description: 'Agencies MUST:


        ensure strong change management practices are implemented;

        ensure that the use of privileged accounts is controlled and accountable;

        ensure that system administrators are assigned, and consistently use, an individual
        account for the performance of their administration tasks;

        keep privileged accounts to a minimum; and

        allow the use of privileged accounts for administrative work only.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4
      description: Privileged system access by foreign nationals
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:2
      ref_id: 16.3.6.R.01
      description: As privileged users may have the ability to bypass controls on
        a system it is strongly encouraged that foreign nationals are not given privileged
        access to systems processing particularly sensitive information.
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:2
      ref_id: 16.3.6.C.01
      name: 'Control -  All Classifications - Must Not [CID: 1949]'
      description: Agencies MUST NOT allow foreign nationals, including seconded foreign
        nationals, to have privileged access to systems that process, store or communicate
        NZEO information.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:2
      ref_id: 16.3.6.C.02
      name: 'Control -  All Classifications - Should Not [CID: 1950]'
      description: Agencies SHOULD NOT allow foreign nationals, including seconded
        foreign nationals, to have privileged access to systems that process, store
        or communicate classified information.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4
      description: Security clearances for privileged users
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:3
      ref_id: 16.3.7.R.01
      description: When frequent data transfers occur between systems of different
        classifications, having privileged users from the lesser system cleared to
        the classification of the higher system will assist in any actions that need
        to be taken resulting from any data spill.
    - urn: urn:defend:risk:req_node:nzism-v3:16.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.3:4:3
      ref_id: 16.3.7.C.01
      name: 'Control -  All Classifications - Should [CID: 1953]'
      description: Agencies involved in frequent transfers of data from another system
        to their system with a lesser classification SHOULD ensure at least one privileged
        user has a security clearance level commensurate the classification of the
        higher system.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.4'
      name: Privileged Access Management
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:1
      ref_id: 16.4.1
      description: "To ensure Privileged Access Management (PAM) is incorporated into\
        \ IT Governance and that privileged accounts are managed in accordance with\
        \ agency\u2019s PAM policy."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:1
      ref_id: 16.4.2
      description: "This section provides information and guidance on the establishment\
        \ and operation of an agency\u2019s Privileged Access Management policy and\
        \ control mechanisms.\_ This is sometimes also described as Privileged Account\
        \ Management.\_ In the context of this section the terms are synonymous."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:1
      ref_id: 16.4.3
      description: "Reference to other sections in this document is essential.\_ In\
        \ particular:\n\n3.5\_\_\_\_\_ System Users;\n5.1\_\_\_\_\_ Documentation\
        \ Fundamentals;\n6.3\_\_\_\_\_ Change Management;\n9.1\_\_\_\_\_ Information\
        \ Security Awareness and Training;\n16.1\_\_\_ Identification, Authentication,\
        \ and Authorisation;\n16.2\_\_\_ System Access;\n16.3\_\_\_ Privileged User\
        \ Access;\n16.7\_\_\_ Multi-Factor Authentication.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.4
      description: "Privileged Access Management (PAM) \u2013 sometimes also described\
        \ as Privileged Account Management, refers to a set of processes and tools\
        \ for granting, controlling, monitoring, and auditing privileged access.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.5
      description: "A Privileged Account is a user account with high levels of access\
        \ to systems, devices and data.\_ Privileged accounts may, for example, be\
        \ able to install or remove software, delete data, upgrade operating systems,\
        \ or modify system or application configurations.\_ They may also have access\
        \ to data that is not normally accessible to standard users."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.6
      description: "Privileged accounts invariably have direct or indirect access\
        \ to most or all IT assets of an agency or organisation.\_ When used improperly\
        \ or maliciously, privileged accounts represent a significant security threat\
        \ to operations, often exposing sensitive data, impeding operations or damaging\
        \ IT systems.\_ Any compromise of these accounts is, therefore, a significant\
        \ business, operational and reputational risk."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.7
      description: Risks associated with privileged accounts have increased in recent
        years with the expansion of endpoints and use of new technologies including
        Cloud, Internet of Things (IoT) and the rapid and significant increase in
        remote and working from home environments.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.8
      description: Managing, controlling, monitoring and reviewing privileged access
        is fundamental to mitigating the risks posed by insider and external threats,
        privilege escalation threats, preventing unauthorised data access and data
        breaches, and meeting compliance requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.9
      description: "There are many types of privileged access including:\n\nRoot,\
        \ Domain and other Administrator accounts are typically used for installing,\
        \ updating and removing software, changing configurations and administering\
        \ system passwords.\nService Accounts, which may include local or domain accounts,\
        \ are typically used for running processes, such as web servers, database\
        \ servers, and application servers.\_ These may also include the ability to\
        \ change passwords.\nEmergency Accounts, sometimes referred to as \u201CDRP\u201D\
        , \u201Cfirecall\u201D, or \u201Cbreakglass\u201D accounts. These are highly\
        \ privileged accounts that are critical for maintaining administrative access\
        \ in case of emergency. While access to these accounts normally requires managerial\
        \ approval as a security measure, they should only ever be used when normal\
        \ administrative accounts are unavailable and when critically necessary.\n\
        System or Application Accounts are characteristically used by devices and\
        \ systems for running operating system components and owning related files.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.10
      description: "Traditional administrative or management solutions are typically\
        \ based on strong password management.\_ Modern systems, especially in a cloud\
        \ environment, require a more structured and robust means of access control\
        \ and management.\_ This should include the use of Multi-Factor Authentication\
        \ (See Section 16.7 - Multi-factor Authentication) to provide access to privileged\
        \ accounts."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.11
      description: In secure environments, privileged accounts should be reserved
        for network and system administrators to manage the access to and oversight
        of sensitive information and resources in support of normal agency or organisational
        operations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.12
      description: "The characteristics and capability of privileged accounts are\
        \ described at 16.3.3.\_ It is important to note that systems themselves,\
        \ as well as human users, may have privileged account access.\_ As such it\
        \ is important to clearly and individually identify all real persons, systems\
        \ and devices with privileged account access."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:2
      ref_id: 16.4.13
      description: "Access accounts or channels may have the following characteristics:\n\
        \nRegular access channels\u2014protected channels that are subject to standard\
        \ IT controls;\nPrivileged access channels (PACs)\u2014 channels that might\
        \ circumvent regular controls but are deemed necessary and legitimate operational\
        \ channels for reasons of practicality or cost;\nUnintended channels\u2014\
        not demanded by any technical or business requirement and represent a vulnerability.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      description: 'Emergency accounts (Break glass accounts) '
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      ref_id: 16.4.14
      description: "Emergency accounts (also known as break glass accounts) are highly\
        \ privileged accounts and should only be used for maintaining access to an\
        \ organisation\u2019s critical systems in emergencies. These accounts require\
        \ additional layers of protection and\_should never be used for regular administrative\
        \ functions."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      ref_id: 16.4.15
      description: "\n\nAdditional protections include:\_\_\n\n\n\nBreak glass accounts\
        \ are only used when normal authentication processes cannot be used, and when\
        \ there is a critical need to access systems (or testing these for disaster\
        \ recovery).\nUse of non-expiring passwords: passwords for break glass accounts\
        \ should not expire. This helps prevent lockouts during emergencies.\nNo individual\
        \ association: ensure emergency accounts are not associated to an individual\
        \ user.\nCentral logging and auditing of all actions related to use of break\
        \ glass accounts should be performed. Accounts are tested after credentials\
        \ are changed.\_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      ref_id: 16.4.16
      description: Emergency accounts should be excluded from MFA policy. MFA on break
        glass accounts should be managed through other mechanisms outside system policy.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      ref_id: 16.4.17
      description: "\nEmergency accounts should have MFA without being associated\
        \ to any user. Examples of how this can be accomplished are:\_\_\n\n\n\nUtilisation\
        \ of a password\n\nPasswords can be split into two and stored in separate\
        \ safes with strict limitations on authorised personnel accessing each safe.\n\
        \n\nUse of FIDO2 security keys\n\nTwo separate keys can be registered and\
        \ stored in separate safes with strict limitations on authorised personnel\
        \ accessing each safe.\n\n\nVirtualisation, noting this option cannot be associated\
        \ to an individual user.\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:3
      ref_id: 16.4.18
      description: It is important to consider adequate storage and access of break
        glass accounts in disaster recovery plans. Storage, including how (and when)
        to access these accounts should be included in disaster recovery planning
        (DRP) (Chapter 3).
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      description: Attacks on privileged accounts
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:4
      ref_id: 16.4.19
      description: "Privileged accounts frequently allow unrestricted access the IT\
        \ infrastructure, often including data residing on those systems.\_ The very\
        \ high level of access and capability associated with privileged accounts\
        \ makes them a prime target for external attackers and malicious insiders.\_\
        \ A compromise of a privileged account can be extremely damaging and may even\
        \ take down systems, such as in ransomware attacks."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:4
      ref_id: 16.4.20
      description: "Compromised privileged accounts represent one of the largest security\
        \ vulnerabilities an organisation. A compromise may allow attackers to take\
        \ full control of an organisation\u2019s IT infrastructure, disable security\
        \ controls, steal confidential information, commit financial fraud and disrupt\
        \ operations.\_ Stolen, abused or misused privileged credentials are identified\
        \ in a very high proportion of successful breaches."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:4
      ref_id: 16.4.21
      description: 'Common attack methods may include:

        Probes and scans;

        endpoint targeting;

        System and design vulnerability exploitation;

        Social engineering (including phishing, email spoofing, etc); and

        Malware implants.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:4
      ref_id: 16.4.22
      description: These attack methods are essentially the same as attack methods
        on standard accounts. The difference, however, is the level of access an attacker
        gains once successful, and the increase of risk to entities and organisations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2
      description: Governance and Control
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.23
      description: "Privileged accounts are frequently used to deploy and maintain\
        \ IT systems and necessarily exist in nearly every connected device, server,\
        \ database, and application.\_ Privileged accounts may extend beyond an agency-controlled\
        \ IT infrastructure to include, for example, employee-managed corporate social\
        \ media accounts.\_ Most agencies and other organisations can typically have\
        \ many more privileged accounts than employees, sometimes as many as two or\
        \ three times the number of employees.\_ It is not unusual for some privileged\
        \ accounts to be unidentified, overlooked, unmanaged, and therefore unprotected."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.24
      description: "Governance ensures that privileged accounts are properly approved,\
        \ controlled, monitored and decommissioned throughout their entire lifecycle.\_\
        \ A PAM policy defines the roles, policies and mechanisms for access requests,\
        \ as well as the workflow for privileged access approvals and delivery.\_\
        \ Monitoring and auditing ensure that account permissions and usage remain\
        \ appropriate over time.\_ PAM governance is a fundamental part of IT Governance\
        \ as it can influence other IT security systems, such as identity and access\
        \ management systems."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.25
      description: "To support strong IT Governance, it is vital that security efforts\
        \ are coordinated, and technology investment managed.\_ This includes the\
        \ integration of PAM into the Information Security Policy, Systems Architecture,\
        \ IT Security Strategy and Risk Management Plan. The sensitivity of data and\
        \ operations should be assessed by undertaking an impact assessment.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.26
      description: "Underpinning any PAM is the principle of enforcement of least\
        \ privilege.\_ This is defined as the minimisation of access rights and permissions\
        \ for users, accounts, applications, systems, devices and computing processes\
        \ to the absolute minimum necessary in order to perform routine, authorised\
        \ activities and maintain the safe and secure operation of agency or organisational\
        \ systems."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.27
      description: "Enforcing the principle of least privilege assists organisations\
        \ in minimising their systems attack surface and supporting audit and compliance\
        \ within agencies.\_ This also can reduce risk, complexity, and costs for\
        \ organisations."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.28
      description: "Provision of unnecessary system privileges or data access rights\
        \ will magnify the impact of misuse or compromise of that users account and\
        \ can even be devastating. \_Account privileges should be established to provide\
        \ a reasonable but minimal level of system privileges and rights needed in\
        \ order to support the purpose and role. \_The granting of elevated or excessive\
        \ system privileges should be carefully controlled and managed."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.29
      description: 'Risks associated with access to privileged accounts include:


        Misuse of privileges;

        Increased attacker capability;

        Circumventing established security and oversight controls;

        Severe system disruption or failure; and

        Significant data compromise and/or loss.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.30
      description: "\n\nThe principles of PAM controls are to:\_\n\n\n\nEstablish\
        \ and maintain an inventory of privileged accounts;\nAssess the risk(s) of\
        \ each privileged account;\nEnforce the principle of least\_privilege;\nUse\
        \ Multi-Factor Authentication for access to privileged accounts;\nMinimise\
        \ access to only essential\_activities;\nMinimise the number of privileged\_\
        access channels;\nEnsure each channel and user can be uniquely\_identified\
        \ (prevent or minimise sharing of credentials, particularly with accounts\
        \ such as \u201Croot\u201D or \u201Cadmin\u201D);\nEnsure\_all logs are periodically\
        \ reviewed;\nEnsure strong and strict change control procedures are\_implemented;\n\
        Ensure the authorisation, activation and deactivation of privileged access\
        \ channels is strictly enforced;\_\nRegularly audit and review PAM controls;\
        \ and\nReduce scope creep through regular reviewing of privilege user accounts.\_\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.31
      description: "It is also important to define all privileged accounts used by\
        \ an agency or by other organisations, particularly where outsource arrangements\
        \ are in place. \_It is fundamental for robust security to identify and record\
        \ the business functions, related data, systems and access privileges.\_ This\
        \ is particularly important for agencies that create, store and process classified\
        \ data."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.32
      description: "Without a comprehensive privileged accounts inventory, agencies\
        \ and other organisations may overlook \u201Cbackdoor\u201D accounts which\
        \ allow users to bypass proper controls and auditing. \_These may have been\
        \ created during system development, by malicious insiders or by external\
        \ attackers.\_ Such unregistered accounts may be undetected for months or\
        \ even years and can create a means of unauthorised and unmonitored access.\_\
        \ Such accounts may also be used to erase activity logs to avoid detection."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.33
      description: "A privileged access inventory should include a description of\
        \ the IT system, information asset, privilege description, privileged users\
        \ and risk classification.\_ This is essential information for assessing risk,\
        \ the determining of controls and for identifying and managing use and misuse.\_\
        \ Of note are:\n\nLocal or Domain Server Admin accounts;\nDomain Admin accounts\
        \ that typically control Active Directory users;\nSystem Admin accounts that\
        \ manage databases;\nRoot accounts that manage Unix/Linux platforms;\nAccounts\
        \ that run and manage Windows applications, services, and scheduled tasks;\n\
        IIS application pools (.NET applications);\nNetworking equipment accounts\
        \ that give access to firewalls, routers, switches, session border controllers,\
        \ gateways and other similar devices, whether physical or virtual.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:2:5
      ref_id: 16.4.34
      description: Privileged Access Management systems provide many of the capabilities
        and controls briefly described above and can facilitate PAM, as well as supporting
        strong IT Governance.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.35
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:3
      ref_id: 16.4.35
      description: "Additional information relating to Privileged Account and access\
        \ management, including some policy examples, can be found at:\n\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\n\_\n\nISO/IEC 27001\_\n\nISO/IEC/ Standards\
        \ NZ\_\nStandards New Zealand\_\n\n\n\_\nRestrict Administrative Privileges\_\
        \nASD\_\nRestrict Administrative Privileges | ASD's Blueprint for Secure Cloud\_\
        \n\n\n\_\nIdentity and access management\_\nNCSC - UK\nIdentity and access\
        \ management - NCSC.GOV.UK\_\n\n\n\_\nSecuring privileged access\nMicrosoft\n\
        Securing privileged access overview - Privileged access | Microsoft Learn\_\
        \n\n\n\_\nManage emergency accounts in Microsoft Entra ID\_\_\nMicrosoft\_\
        \nManage emergency access admin accounts - Microsoft Entra ID | Microsoft\
        \ Learn\_\n\n\n\_\nPrivileged Account Management\_\nMITRE Corporation\nPrivileged\
        \ Account Management, Mitigation M1026 - Enterprise | MITRE ATT&CK\xAE\_\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Policy Creation and Implementation'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:1
      ref_id: 16.4.36.R.01
      description: "The requirement for an agency security policy is discussed and\
        \ described in Chapter 5 \u2013 Information Security Documentation.\_ A fundamental\
        \ part of any security policy is the inclusion of requirements for the treatment\
        \ of Privileged Accounts.\_ This is most conveniently contained in a Privileged\
        \ Access Management (PAM) section within the agency\u2019s security policy.\_\
        \ A PAM policy is a fundamental component of an agency\u2019s IT Governance."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:1
      ref_id: 16.4.36.C.01
      name: 'Control -  All Classifications - Must [CID: 6835]'
      description: Agencies MUST establish a Privileged Access Management (PAM) policy.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.36.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:1
      ref_id: 16.4.36.C.02
      name: 'Control -  All Classifications - Must [CID: 6836]'
      description: "Within the context of agency operations, the agency\u2019s PAM\
        \ policy MUST define:\n\na privileged account; and\nprivileged access.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.36.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:1
      ref_id: 16.4.36.C.03
      name: 'Control -  All Classifications - Must [CID: 6837]'
      description: "Agencies MUST manage privileged accounts in accordance with the\
        \ agency\u2019s PAM policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' The Principle of Least Privilege'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.R.01
      description: "The Principle of Least Privilege is discussed in the Context part\
        \ of this section.\_ This principle stipulates the minimisation of access\
        \ rights and permissions for users, accounts, applications, systems, devices\
        \ and computing processes to the absolute minimum necessary in order to perform\
        \ routine, authorised activities and maintain the safe and secure operation\
        \ of agency or organisational systems.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.R.02
      description: "The implementation of the Principle of Least Privilege requires\
        \ limitations on the number and use of privileged accounts as well as minimising\
        \ the numbers of users with these privileges.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.R.03
      description: "The use of privileged access should also follow the principle\
        \ of least privilege by ensuring the use of two-factor or Multi-Factor Authentication\
        \ for access to privileged accounts and ensuring that only activity requiring\
        \ such access is undertaken.\_ Refer to Section 16.7 \u2013 Multi-Factor Authentication.\_\
        \ User accounts without privileged access should be used for all other activities.\_\
        \ Refer to Section 16.3 \u2013 Privileged User Access.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.C.01
      name: 'Control -  All Classifications - Must [CID: 6842]'
      description: Agencies MUST apply the Principle of Least Privilege when developing
        and implementing a Privileged Access Management (PAM) policy.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.C.02
      name: 'Control -  All Classifications - Must [CID: 6843]'
      description: Agencies MUST use two-factor or Multi-Factor Authentication to
        allow access to privileged accounts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.37.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:2
      ref_id: 16.4.37.C.03
      name: 'Control -  All Classifications - Should [CID: 7550]'
      description: Agencies SHOULD consider the use of time bound revocation to privileged
        accounts.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Strong Authentication process'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.38.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:3
      ref_id: 16.4.38.R.01
      description: "The approval and authorisation process for the granting of privileged\
        \ access should be based on the requirement to manage and protect organisational\
        \ systems and assets or as an operational necessity only.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.38.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:3
      ref_id: 16.4.38.C.01
      name: 'Control -  All Classifications - Must [CID: 6846]'
      description: As part of a Privileged Access Management (PAM) policy, agencies
        MUST establish and implement a strong approval and authorisation process before
        any privileged access credentials are issued.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.38.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:3
      ref_id: 16.4.38.C.02
      name: 'Control -  All Classifications - Must Not [CID: 6847]'
      description: Privileged Access credentials MUST NOT be issued until approval
        has been formally granted.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Suspension and Revocation of Privileged Access Credentials'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.39.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:4
      ref_id: 16.4.39.R.01
      description: "Because privileged accounts have high levels of trust associated\
        \ with the issue of related credentials, any indication that credentials or\
        \ accounts have been compromised or that credentials have been misused must\
        \ be immediately investigated.\_ Actions may include the immediate suspension\
        \ of credentials.\_ Revocation may follow depending on the outcome of the\
        \ investigation."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.39.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:4
      ref_id: 16.4.39.R.02
      description: "The privileged access credentials for staff and other users (such\
        \ as authorised contractors) should be suspended or revoked as part of exit\
        \ procedures when staff leave the agency and when other users no longer undertake\
        \ duties for the agency.\_ This ensures the numbers of credentials are controlled,\
        \ credentials are revoked when no longer required for operational purposes\
        \ and that the risk of unauthorised activities and access is minimised.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.39.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:4
      ref_id: 16.4.39.C.01
      name: 'Control -  All Classifications - Must [CID: 6852]'
      description: "Agencies MUST establish robust credential suspension and revocation\
        \ procedures as part of the agency\u2019s Privileged Access Management (PAM)\
        \ policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.39.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:4
      ref_id: 16.4.39.C.02
      name: 'Control -  All Classifications - Must [CID: 7553]'
      description: Agencies MUST investigate any indication of compromise or misuse
        of systems credentials or accounts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Privileged Account, Rights and Credential Inventory'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.40.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:5
      ref_id: 16.4.40.R.01
      description: "Account and credential \u201Csprawl\u201D is a continuing challenge\
        \ as the number of users constantly changes and the number and variety of\
        \ devices evolves and grows.\_ The growing use of the Internet of Things (IoT)\
        \ is a good example of this.\_ A primary tool in the management and containment\
        \ of sprawl is the creation and maintenance of an inventory of privileged\
        \ accounts and the access rights and credential associated with those accounts\
        \ together with a process of continuous discovery.\_ This will assist in curbing\
        \ privileged account sprawl, identifying potential insider abuse, and exposing\
        \ external threats and malicious activity.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.40.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:5
      ref_id: 16.4.40.C.01
      name: 'Control -  All Classifications - Must [CID: 6855]'
      description: Agencies MUST create and maintain a comprehensive inventory of
        privileged accounts and the associated access rights and credentials.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Monitoring and Review'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.41.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      ref_id: 16.4.41.R.01
      description: "Privileged Accounts have high levels of system and data access\
        \ and are a \u201Chigh value target\u201D for malicious cyber-attacks and\
        \ insider misuse.\_ Access to privileged accounts can be extremely damaging\
        \ to systems and can cause data and privacy breaches as well as data loss.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.41.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      ref_id: 16.4.41.R.02
      description: "A key control in the ongoing integrity of privileged accounts\
        \ and their associated credentials is a robust system of monitoring and review\
        \ in order to maintain the inventory of privileged accounts and implement\
        \ a process of continuous discovery to curb privileged account sprawl, identify\
        \ potential insider abuse, and reveal external threats.\_ This includes continuous\
        \ data and operations impact assessments."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.41.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      ref_id: 16.4.41.C.01
      name: 'Control -  All Classifications - Must [CID: 6859]'
      description: Agencies MUST create, implement and maintain a robust system of
        continuous discovery, monitoring and review of privileged accounts and the
        access rights and credentials associated with those accounts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.41.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      ref_id: 16.4.41.C.02
      name: 'Control -  All Classifications - Must [CID: 6860]'
      description: 'Privileged account monitoring systems MUST monitor and record:


        individual user activity, including exceptions such as out of hours access;

        activity from unauthorised sources;

        any unusual use patterns; and

        any creation of unauthorised privileges access credentials.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.41.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:6
      ref_id: 16.4.41.C.03
      name: 'Control -  All Classifications - Must [CID: 6861]'
      description: Agencies MUST protect and limit access to activity and audit logs
        and records.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' Response and Remediation'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.42.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:7
      ref_id: 16.4.42.R.01
      description: "Because privileged accounts have high levels of system and data\
        \ access, a rapid response to unusual or anomalous activity is fundamental\
        \ to the maintenance of the integrity of an agency\u2019s systems and data.\_\
        \ Any response must take urgent action to protect compromised accounts and\
        \ systems based on defined policy and breach intelligence.\_ This may include,\
        \ for example, the immediate suspension of credentials, password rotation\
        \ or deactivation of credentials."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.42.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:7
      ref_id: 16.4.42.C.01
      name: 'Control -  All Classifications - Must [CID: 6864]'
      description: "Agencies MUST develop and implement a response and remediation\
        \ policy and procedure as part of an agency\u2019s Privileged Access Management\
        \ (PAM) policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.4:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4
      description: ' User Education and Awareness'
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.43.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:8
      ref_id: 16.4.43.R.01
      description: "Privileged Account access may have procedures additional to or\
        \ that vary from an organisation\u2019s usual account security and maintenance\
        \ processes and procedures.\_ As an agency will have established a Privileged\
        \ Account Management (PAM) policy, this can be conveniently dealt with as\
        \ a separate or additional component of user training and awareness. Refer\
        \ also to Section 3.5 - System Users and Section 9.1 - Information Security\
        \ Awareness and Training."
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.43.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:8
      ref_id: 16.4.43.R.02
      description: User training and awareness is necessary to provide specific training
        to users of privileged accounts. This training should provide detailed information
        specific to users of privileged accounts. This includes awareness of the characteristics
        and value of privileged accounts, the additional responsibilities of users
        of these accounts, and the risk to organisations and systems if these accounts
        get breached.
    - urn: urn:defend:risk:req_node:nzism-v3:16.4.43.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.4:4:8
      ref_id: 16.4.43.C.01
      name: 'Control -  All Classifications - Must [CID: 6868]'
      description: "Agencies MUST implement a Privileged Access Management (PAM) policy\
        \ training module as part of the agency\u2019s overall user training and awareness\
        \ requirement."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.5'
      name: Remote Access
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:1
      ref_id: 16.5.1
      description: Remote access to systems is secure, controlled and authorised.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:1
      ref_id: 16.5.2
      description: This section covers information relating to the methods used by
        personnel to access an agency system from a remote location.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2
      description: Remote access
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:2
      ref_id: 16.5.3
      description: "Remote access is defined as user access to agency systems originating\
        \ outside an agency network. \_It does not include web\u2013based access to\
        \ DMZ resources. \_Further information on working off\u2013site can be found\
        \ in Chapter 21 \u2013 Distributed working. \_The requirements for using multi\u2013\
        factor authentication are described in the Identification and Authentication\
        \ section of this chapter."
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2
      description: Remote privileged access
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:3
      ref_id: 16.5.4
      description: "Remote access by a privileged user to an agency system via a less\
        \ trusted security domain (for example, the Internet) may present additional\
        \ risks. \_Controls in this section are designed to prevent escalation of\
        \ user privileges from a compromised remote access account."
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:3
      ref_id: 16.5.5
      description: "Remote privileged access does not include privileged access across\
        \ disparate physical sites that are within the same security domain or privileged\
        \ access across remote sites that are connected via trusted infrastructure.\_\
        \ Privileged access of this nature faces different threats to those discussed\
        \ above.\_ Ensuring robust processes and procedures are in place within an\
        \ organisation to monitor and detect the threat of a malicious insider are\
        \ the most important measure for this scenario."
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2
      description: Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:4
      ref_id: 16.5.6
      description: Cryptography is used to provide confidentiality and preserve integrity
        of data transmitted over networks where it may be intercepted or examined
        and is outside the control of the sender and recipient.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:4
      ref_id: 16.5.7
      description: "With the increases in speed and computing power and the cost reductions\
        \ of modern computing, older cryptographic algorithms are increasingly vulnerable.\
        \ \_It is vital that recommendations and controls in the NZISM are followed."
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:2:4
      ref_id: 16.5.8
      description: The use of approved cryptographic algorithms to encrypt authentication,
        session establishment and data for all remote access connections is considered
        good practice (See Chapter 17 - Cryptography and Chapter 21 - Distributed
        Working).
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:3
      ref_id: 16.5.9
      description: "Further references can be found at:\n\n\n\nTitle\nPublisher\n\
        Source\n\n\n\nMulti-Site Connectivity\_\n\nNSA\n\nCapability Packages (nsa.gov)\n\
        \n\n\n\nNIST Special Publication 800-114: User\u2019s Guide to Telework and\
        \ Bring Your Own Device (BYOD) Security\_\n\nNIST\n\nSP 800-46 Rev. 2, Guide\
        \ to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD)\
        \ Security | CSRC\_\n\n\n\n\n\_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4
      description: Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:1
      ref_id: 16.5.10.R.01
      description: Authenticating remote system users and devices ensures that only
        authorised system users and devices are allowed to connect to agency systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:1
      ref_id: 16.5.10.C.01
      name: 'Control -  All Classifications - Must [CID: 1973]'
      description: Agencies MUST authenticate each remote connection and user prior
        to permitting access to an agency system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:1
      ref_id: 16.5.10.C.02
      name: 'Control -  All Classifications - Should [CID: 1974]'
      description: Agencies SHOULD authenticate both the remote system user and device
        during the authentication process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4
      description: Remote privileged access
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:2
      ref_id: 16.5.11.R.01
      description: A compromise of remote access to a system can be limited by preventing
        the use of remote privileged access from an untrusted domain.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:2
      ref_id: 16.5.11.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must Not [CID: 1977]'
      description: Agencies MUST NOT allow the use of remote privileged access from
        an untrusted domain, including logging in as an unprivileged system user and
        then escalating privileges.
      implementation_groups:
      - Top Secret - MUST NOT
      - Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:2
      ref_id: 16.5.11.C.02
      name: 'Control -  All Classifications - Should Not [CID: 1978]'
      description: Agencies SHOULD NOT allow the use of remote privileged access from
        an untrusted domain, including logging in as an unprivileged system user and
        then escalating privileges.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4
      description: Virtual Private Networks (VPNs)
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      ref_id: 16.5.12.R.01
      description: "Virtual Private Networks (VPN\u2019s) use a tunnelling protocol\
        \ to create a secure connection over an intermediate (public) network such\
        \ as the internet. \_A VPN uses techniques such as encryption, authentication,\
        \ authorisation and access control to achieve a secure connection. See Chapter\
        \ 17 for details on cryptographic selection and implementation."
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      ref_id: 16.5.12.R.02
      description: A VPN can connect remote or mobile workers or remote locations
        to a private (agency) network.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.12.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      ref_id: 16.5.12.R.03
      description: Using Zero Trust principles alongside the use of VPNs provides
        additional security to agency systems. For example, if a compromised device
        connects through a VPN to an organisation enforcing Zero Trust principles,
        potential damage to the organisation will be minimised through limiting the
        access of the potential compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      ref_id: 16.5.12.C.01
      name: 'Control -  All Classifications - Should [CID: 1982]'
      description: Agencies SHOULD establish VPN connections for all remote access
        connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.5.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.5:4:3
      ref_id: 16.5.12.C.02
      name: 'Control -  All Classifications - Should [CID: 7555]'
      description: Agencies SHOULD use Zero Trust principles alongside the use of
        VPN connections to enhance the security posture of the organisation. This
        should include removing the ability for a standard user to disable the VPN
        connection.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.6'
      name: Event Monitoring, Logging and Auditing
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:1
      ref_id: 16.6.1
      description: Information security related events are logged, monitored and audited
        for accountability, incident management, forensic and system monitoring purposes.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:2:1
      ref_id: 16.6.2
      description: "This section covers information on the automatic logging of information\
        \ relating to network activities. \_Information regarding manual logging of\
        \ system management activities can be found in Section 16.3 - Privileged User\
        \ Access. \_See also Chapter7 - Information Security Incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:2:1
      ref_id: 16.6.3
      description: "A security event is a change to normal or expected behaviour of\
        \ a network, network component, system, device or user. \_Event logging helps\
        \ improve the security posture of a system by increasing the accountability\
        \ of all user actions, thereby improving the chances that malicious behaviour\
        \ will be detected."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:2:1
      ref_id: 16.6.4
      description: "It is important that sufficient details are recorded in order\
        \ for the logs to be useful when reviewed or when an investigation is in progress.\
        \ \_Retention periods are also important to ensure sufficient log history\
        \ is available. \_Conducting audits of event logs is an integral part of the\
        \ security and maintenance of systems, since they will help detect and attribute\
        \ any violations of information security policy, including cyber security\
        \ incidents, breaches and intrusions."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:3
      ref_id: 16.6.5
      description: "Additional information relating to event logging is contained\
        \ in:\n\n\n\nTitle\nPublisher\nSource\n\n\n\nISO/IEC 27001\n\n\nISO/IEC/ Standards\
        \ NZ\_\n\n\nStandards New Zealand\_\n\n\n\n\nStandard Time for a New Zealand\
        \ Network\n\n\nMeasurement Standards Laboratory\n\nMSL NTP Server | Measurement\
        \ Standards Laboratory\_\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Maintaining system management logs
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:1
      ref_id: 16.6.6.R.01
      description: "Having comprehensive information on the operations of a system\
        \ can assist system administration, support information security and assist\
        \ incident investigation and management. \_In some cases forensic investigations\
        \ will rely on the integrity, continuity and coverage of system logs."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:1
      ref_id: 16.6.6.R.02
      description: "It will be impractical and costly to store all system logs indefinitely.\
        \ An agency retention policy may consider:\nLegislative and regulatory requirements;\n\
        Ensure adequate retention for operational support and efficiency;\_\nMinimise\
        \ costs and storage requirements; and\nAn adequate historical archive is maintained.\n\
        Care should be taken to ensure that these considerations are properly balanced.Some\
        \ practices dictate retention periods, for example good DNSSEC practice requires\
        \ log information is stored in log servers for 4 months, then archived and\
        \ retained for at least 2 years."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:1
      ref_id: 16.6.6.C.01
      name: 'Control -  Top Secret - Must [CID: 1997]'
      description: Agencies MUST maintain system management logs for the life of a
        system.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:1
      ref_id: 16.6.6.C.02
      name: 'Control -  All Classifications - Should [CID: 1998]'
      description: Agencies SHOULD determine a policy for the retention of system
        management logs.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Content of system management logs
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:2
      ref_id: 16.6.7.R.01
      description: Comprehensive system management logs will assist in logging key
        management activities conducted on systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:2
      ref_id: 16.6.7.C.01
      name: 'Control -  All Classifications - Should [CID: 2001]'
      description: "A system management log SHOULD record the following minimum information:\n\
        \nall\_system start-up and shutdown;\nall system changes;\nuser\_changes;\n\
        service, application,\_component or system failures;\nmaintenance\_activities;\n\
        backup and archival\_activities;\nsystem recovery activities; and\nspecial\
        \ or out of hours activities.\_\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Logging requirements
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:3
      ref_id: 16.6.8.R.01
      description: Event logging and monitoring can help raise the security posture
        of a system by increasing the accountability for all system user actions.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:3
      ref_id: 16.6.8.R.02
      description: Event logging and monitoring can increase the chances that malicious
        behaviour will be detected by logging the actions of a malicious party.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:3
      ref_id: 16.6.8.R.03
      description: Well configured event logging allows for easier and more effective
        auditing and forensic examination if an information security incident occurs.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:3
      ref_id: 16.6.8.C.01
      name: 'Control -  All Classifications - Must [CID: 2006]'
      description: 'Agencies MUST develop and document logging requirements covering:

        the logging facility, including:


        log server availability requirements; and

        the reliable delivery of log information to the log server;



        the list of events associated with a system or software component to be logged;
        and

        event log protection and archival requirements.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Events to be logged
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:4
      ref_id: 16.6.9.R.01
      description: The events to be logged are key elements in the monitoring of the
        security posture of systems and contributing to reviews, audits, investigations
        and incident management.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:4
      ref_id: 16.6.9.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2009]'
      description: "\n\nAgencies MUST log, at minimum, the following events for all\
        \ software components:\_\n\n\n\nany login activity or attempts;\_\ndate and\_\
        time;\nall privileged\_operations;\nfailed attempts to elevate\_privileges;\n\
        security related system alerts and\_failures;\nsoftware upgrades and/or software\_\
        patching;\nsystem recovery\_activities;\nsystem user and group additions,\_\
        deletions and modification to permissions; and\_\nunauthorised or failed access\
        \ attempts to systems and files identified as critical to the\_organisation.\n\
        \n\n"
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Additional events to be logged
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:5
      ref_id: 16.6.10.R.01
      description: The additional events to be logged can be useful for reviewing,
        auditing or investigating software components of systems.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:5
      ref_id: 16.6.10.C.01
      name: 'Control -  All Classifications - Should [CID: 2012]'
      description: "Agencies SHOULD log the events listed in the table below for specific\
        \ software components.\n\n\nSoftware component\nEvents to log\n\n\nDatabase\n\
        \nSystem user access to the database.\n\n\n\n\_\n\nAttempted access that is\
        \ denied.\n\n\n\n\_\n\nChanges to system user roles or database rights.\n\n\
        \n\n\_\n\nAddition of new system users, especially privileged users.\n\n\n\
        \n\_\n\nModifications to the data.\n\n\n\n\_\n\nModifications to the format\
        \ or structure of the database.\n\n\n\nNetwork/operating system\n\nSuccessful\
        \ and failed attempts to logon and logoff.\n\n\n\n\_\n\nChanges to system\
        \ administrator and system user accounts.\n\n\n\n\_\n\nFailed attempts to\
        \ access data and system resources.\n\n\n\n\_\n\nAttempts to use special privileges.\n\
        \n\n\n\_\n\nUse of special privileges.\n\n\n\n\_\n\nSystem user or group management.\n\
        \n\n\n\_\n\nChanges to the security policy.\n\n\n\n\_\n\nService failures\
        \ and restarts.\n\n\n\n\_\n\nSystem startup and shutdown.\n\n\n\n\_\n\nChanges\
        \ to system configuration data.\n\n\n\n\_\n\nAccess to sensitive data and\
        \ processes.\n\n\n\n\_\nData import/export operations.\n\n\n\nWeb application\n\
        \n\nSystem user access to the Web application.\n\n\n\n\_\n\nAttempted access\
        \ that is denied.\n\n\n\n\_\n\nSystem user access to the Web documents.\n\n\
        \n\n\_\n\nSearch engine queries initiated by system users.\n\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:5
      ref_id: 16.6.10.C.02
      name: 'Control -  All Classifications - Should [CID: 2013]'
      description: "\nAgencies SHOULD log, at minimum, the following events for all\
        \ software components:\_\n\n\n\nAny login activity or attempts;\_all privileged\
        \ operations;\nfailed attempts to elevate\_privileges;\_\nsecurity related\
        \ system alerts and\_failures;\_\nall software updates and/or patching;\n\
        system user and group additions,\_deletions and modification to permissions;\
        \ and\_\nunauthorised\_or failed access attempts to systems and files identified\
        \ as critical to the organisation.\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Event log facility
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      ref_id: 16.6.11.R.01
      description: "The act of logging events is not enough in itself. \_For each\
        \ event logged, sufficient detail needs to be recorded in order for the logs\
        \ to be useful when reviewed. \_An authoritative external time source, a local\
        \ Time Source Master Clock or server or Co-ordinated Universal Time (UTC)\
        \ is essential for the time-stamping of events and later inspection or forensic\
        \ examination. \_The NZ Interoperability Framework (e-GIF) recognises the\
        \ time standard for New Zealand as UTC (MSL), with Network Time Protocol (NTP)\
        \ v.4 as the delivery method over the Internet."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      ref_id: 16.6.11.R.02
      description: "New Zealand standard time is maintained by the Measurement Standards\
        \ Laboratory of New Zealand (MSL), a part of Industrial Research Limited (IRL).\
        \ \_New Zealand standard time is based on UTC, a worldwide open standard used\
        \ by all modern computer operating systems. \_UTC (MSL) is kept within 200\
        \ nanoseconds of the international atomic time scale maintained by the Bureau\
        \ International des Poids et Mesures (BIPM) in Paris."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      ref_id: 16.6.11.C.01
      name: 'Control -  All Classifications - Must [CID: 2017]'
      description: 'For each event identified as needing to be logged, agencies MUST
        ensure that the log facility records at least the following details, where
        applicable:

        date and time of the event;

        relevant system user(s) or processes;

        event description;

        success or failure of the event;

        event source (e.g. application name); and

        IT equipment location/identification.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      ref_id: 16.6.11.C.02
      name: 'Control -  All Classifications - Should [CID: 2018]'
      description: Agencies SHOULD establish an authoritative time source.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:6
      ref_id: 16.6.11.C.03
      name: 'Control -  All Classifications - Should [CID: 2019]'
      description: Agencies SHOULD synchronise all logging and audit trails with the
        time source to allow accurate time stamping of events.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Event log protection
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:7
      ref_id: 16.6.12.R.01
      description: Effective log protection and storage (possibly involving the use
        of a dedicated event logging server) will help ensure the integrity and availability
        of the collected logs when they are audited.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:7
      ref_id: 16.6.12.C.01
      name: 'Control -  All Classifications - Must [CID: 2022]'
      description: "\nEvent logs MUST be protected from:\_\n\n\n\nmodification;\n\
        unauthorised access; and\nwhole or partial loss within the defined retention\
        \ period.\_\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:7
      ref_id: 16.6.12.C.02
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2023]'
      description: Agencies MUST configure systems to save event logs to separate
        secure servers as soon as possible after each event occurs.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:7
      ref_id: 16.6.12.C.03
      name: 'Control -  All Classifications - Should [CID: 2024]'
      description: 'Agencies SHOULD ensure that:

        systems are configured to save event logs to a separate secure log server;
        and

        event log data is archived in a manner that maintains its integrity.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Event log archives
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.R.01
      description: "It is important that agencies determine the appropriate length\
        \ of time to retain DNS, proxy, event systems and other operational logs.\
        \ \_Logs are an important information source in reviews, audits and investigations\
        \ ideally these should be retained for the life of the system or longer.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.R.02
      description: "The Archives, Culture, and Heritage Reform Act 2000, the Public\
        \ Records Act 2005 and the Official Information Act 1982 \_may determine or\
        \ influence the length of time that logs need to be retained and if they should\
        \ be archived."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.C.01
      name: 'Control -  All Classifications - Must [CID: 2028]'
      description: Event logs MUST be archived and retained for an appropriate period
        as determined by the agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.C.02
      name: 'Control -  All Classifications - Must [CID: 2029]'
      description: Disposal or archiving of DNS, proxy, event, systems and other operational
        logs MUST be in accordance with the provisions of the relevant legislation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.C.03
      name: 'Control -  All Classifications - Should [CID: 2030]'
      description: Agencies SHOULD seek advice and determine if their logs are subject
        to legislation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.C.04
      name: 'Control -  All Classifications - Should [CID: 2031]'
      description: Agencies SHOULD retain DNS, proxy and event logs for a minimum
        of 12 months.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.13.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:8
      ref_id: 16.6.13.C.05
      name: 'Control -  All Classifications - Should [CID: 7557]'
      description: Agencies should prioritise their log retention requirements based
        on the risks surrounding their most sensitive systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Event log auditing
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:9
      ref_id: 16.6.14.R.01
      description: Conducting audits of event logs is seen as an integral part of
        the maintenance of systems, as they will assist in the detection and attribution
        of any violations of agency security policy, including information security
        incidents, breaches and intrusions.
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:9
      ref_id: 16.6.14.C.01
      name: 'Control -  All Classifications - Must [CID: 2034]'
      description: 'Agencies MUST develop and document event log audit requirements
        covering:

        the scope of audits;

        the audit schedule;

        action to be taken when violations are detected;

        reporting requirements; and

        roles and specific responsibilities.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.6:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4
      description: Event log monitoring
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:10
      ref_id: 16.6.15.R.01
      description: "\nEvent log monitoring is similar to auditing, however monitoring\
        \ is conducted in near-real time. This provides early detection of any incidents\
        \ and potential authentication violations and incidents.\_\_\n\n\nEarly identification\
        \ of anomalies can protect the security posture of a system.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:10
      ref_id: 16.6.15.R.02
      description: "Monitoring of event logs is essential to understand what system\
        \ \u2018normal\u2019 look like to be able to detect future authentication\
        \ violations and anomalies."
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:10
      ref_id: 16.6.15.C.01
      name: 'Control -  All Classifications - Should [CID: 7560]'
      description: Agencies SHOULD have a monitoring solution implemented that enables
        detection of incidents as they occur so that appropriate responses can be
        taken in adequate timeframes.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.6.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.6:4:10
      ref_id: 16.6.15.C.02
      name: 'Control -  All Classifications - Should [CID: 7561]'
      description: Agencies SHOULD have systems available for processing system event
        logs to identify and correlate events which indicate behavioural anomalies
        or potential security compromise in the systems, in a near real-time manner.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:16
      ref_id: '16.7'
      name: Multi-Factor Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:1
      ref_id: 16.7.1
      description: Multi-Factor Authentication (MFA) mechanisms are adequately implemented
        to enhance and maintain security.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:1
      ref_id: 16.7.2
      description: "This section provides information and guidance on the establishment\
        \ and operation of MFA.\_ It is a critical component of Identity and Access\
        \ Management (IAM)."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:1
      ref_id: 16.7.3
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\n\nChapter 7 \u2013 Information Security Incidents;\nSection\
        \ 9.1 \u2013 Information Security Awareness and Training;\nSection 16.1 \u2013\
        \ Identification, Authentication and Authorisation;\nSection 16.2 \u2013 System\
        \ Access;\nSection 16.3 \u2013 Privileged User Access;\nSection 16.4 \u2013\
        \ Privileged Access Management; and\nChapter 17 - Cryptography.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.4
      description: "Authentication is a key element of security that provides confirmation\
        \ of a returning user to a system when making a transaction.\_ In this context\
        \ a transaction may include browsing, financial operations, and all types\
        \ of data access, creation, copying and deletion."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.5
      description: "MFA is a security system that verifies a returning user by requiring\
        \ multiple credentials, which are typically in the form of another factor\
        \ or type.\_ Initial authentication often requires a username and password\
        \ followed by a requirement for other (additional) credentials.\_ MFA can\
        \ enable, for example, valid users\u2019 access to permit credential reset,\
        \ even if they are using a username and password that may have been compromised."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.6
      description: "Through adequate implementation, MFA can be a strong defence and\
        \ deterrent against many credential attacks, including brute-force, credential\
        \ stuffing, and password spraying attacks.\_ It is also an additional defence\
        \ against many social engineering attacks seeking user credentials."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.7
      description: "MFA requires two or more authentication factors (from a single\
        \ entity) before authorising system access.\_ MFA requires two elements from\
        \ any of the three categories of authentication and with the second factor\
        \ from a different group to the first factor selected.\_\nThese factors or\
        \ groups are:\n\nThe possession/ownership factor - Something you have, preferably\
        \ NOT the device itself but a SEPARATE authentication device such as a token,\
        \ RFID card or smartcard;\nThe knowledge factor - Something you know such\
        \ as a passcode, One-Time password (OTP), reusable password, pattern or other\
        \ component of a standard authentication mechanism;\nThe inherence factor\
        \ - Something you are, biological or behavioural characteristics of various\
        \ types.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.8
      description: Using MFA increases attack resistance by increasing the difficulty
        of obtaining all necessary authenticators. It is important to note, however,
        that the strength of an MFA solution is contingent on how robust any of the
        authentication factors are.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.9
      description: "\_It is important to use a variety of factors to strengthen attack\
        \ resistance in order to increase confidence levels in the chosen authentication\
        \ system.\_ For example, using two factors from the knowledge group is not\
        \ considered 2FA and is less effective than using factors from two different\
        \ groups.\_ The knowledge group is the most exposed to attack and compromise\
        \ through social engineering."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:2
      ref_id: 16.7.10
      description: "Additional authentication also assists in managing Privileged\
        \ Access (refer to Section 16.4 \u2013 Privileged Access Management)."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Phishing resistant MFA
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.11
      description: Although the use of MFA provides improved levels of security than
        the traditional single-factor authentication, it is imperative to recognise
        that not all methods provide adequate protection against all attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.12
      description: The majority of credential stealing is obtained through phishing
        attacks and adversary in the middle attacks (AiTM). Some traditional MFA is
        vulnerable to interception or AiTM attacks, where an access token is stolen
        that contains the MFA claim and can be replayed by the attacker. These types
        of traditional MFA do not provide the adequate security to mitigate against
        many advanced phishing attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.13
      description: Phishing resistant MFA are types of authentication methods that
        are designed to mitigate these phishing attacks found in some traditional
        MFA approaches.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.14
      description: Phishing resistant MFA are methods where attackers cannot replay
        the stolen access token or manipulate the authentication process. This includes
        mitigating against social engineering attacks, phishing attacks, and AiTM
        attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.15
      description: 'Phishing resistant MFA relies on cryptographic keys which eliminate
        the risk of interception and phishing attacks. Methods include:


        FIDO2/WebAuthn.

        Smartcards.

        PKI-Based Authentication.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.16
      description: Due to the reliance on cryptographic keys, this typically can involve
        additional infrastructure and can add additional time and cost to implement
        across organisations.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.17
      description: Agencies need to understand what systems and data needs to be protected.
        Not all entities or transactions may need to implement phishing resistant
        MFA, however it is essential to consider implementing phishing resistant MFA
        to sensitive information, where entities have elevated privileges within organisations,
        and consider adding phishing resistant MFA to PAM policies.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.18
      description: 'Traditional MFA with known vulnerabilities

        Some methods of MFA are known to be susceptible to phishing threats. Methods,
        such as SMS based one-time passwords (OTP), email and application-based OTPs
        have well documented vulnerabilities that can be exploited, particularly through
        phishing and AiTM attacks.'
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.19
      description: 'SMS have several known vulnerabilities which may make it unsuitable
        and unsafe for authentication purposes; these include:


        SIM swapping attacks.

        AiTM attacks.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:3
      ref_id: 16.7.20
      description: Email based OTPs are vulnerable to email account compromises. If
        an attacker gains access to email accounts they can intercept OTPs via email.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Adaptive Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:4
      ref_id: 16.7.21
      description: "Adaptive Authentication is a form of MFA which varies the level\
        \ or degree of authentication required where an unusual authentication request\
        \ occurs.\_ For example, out of normal hours, from an unusual geolocation,\
        \ from an unrecognised device, from an unrecognised IP address and so on.\_\
        \ When an unusual authentication request is received, Adaptive Authentication\
        \ may request additional authenticators such as an MFA token.\_ Some risk\
        \ factors that may trigger Adaptive Authentication include:\n\nThe location\
        \ of the access request such as such as a caf\xE9, airport or home;\nThe time\
        \ of the access request such as like late at night, over weekends or during\
        \ normal working hours;\nThe type of device, such as a smartphone, tablet,\
        \ laptop, or unrecognised device;\_\nThe type of connection, for example,\
        \ a public network such as the internet, or a VPN or some other private network;\
        \ and\nA request for access to privileged accounts.\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:4
      ref_id: 16.7.22
      description: "Adaptive Authentication includes what is sometimes described as\
        \ transaction identification where known characteristics are compared to the\
        \ transaction or access request, for example, a known location or common access\
        \ request.\_ If known characteristics do not match then additional authentication\
        \ steps may be indicated or required."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Client-Side Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:5
      ref_id: 16.7.23
      description: "Client-side authentication originates from the user\u2019s device\
        \ such as laptop, mobile phone, tablet, or home computer.\_ These devices\
        \ may provide a variety of authentication methods including:\n\nInherence\
        \ factor/Biometric:\n\n\nFingerprint scans;\nFacial recognition;\nVoice command/recognition;\n\
        Iris scans;\nKeystroke dynamics;\n\n\nKnowledge factor:\n\nPIN codes;\nPattern\
        \ codes;\n\n\nPossession factor:\n\nGeofencing;\nBluetooth device proximity/Near\
        \ field communication (NFC).\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:5
      ref_id: 16.7.24
      description: "It is important to note that some biometric and other measures,\
        \ for example fingerprints, are susceptible to attacks such as spoofing.\_\
        \ To combat these biometric attacks secondary measures are also required,\
        \ for example pulse-sensing in addition to fingerprint detection in order\
        \ to ensure the fingerprint presentation is a live person.\_ Clearly not all\
        \ secondary measures are fully effective by themselves and multiple secondary\
        \ measures may be required for high risk/high value authorisation requests.\
        \ FIPS-140 provides guidance to organisations to confirm which hardware meets\
        \ secure standards.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Single-User and Multi-User Authorisation
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:6
      ref_id: 16.7.25
      description: "Single-User authorisation involves prompting the account holder\
        \ to authorise an action being taken on his behalf.\_ For example, single-user\
        \ authorisation can even prevent fraud as it occurs in a user-friendly manner.\_\
        \ Instead of calling the customer to verify the legitimacy of a purchase,\
        \ credit card companies could request customer authentication for an on-line\
        \ purchase by sending an authorisation request to the customer through an\
        \ alternate channel such as a mobile phone."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:6
      ref_id: 16.7.26
      description: "Multi-User authorisation usually requires multiple and separate\
        \ authentications (usually by other people) in order to authorise a transaction\
        \ or event, such as establishing an account.\_ This system supports the \u201C\
        separation of duties\u201D concept common in accounting transactions or other\
        \ high-risk activities.\_ Multi-user authorisation may also assess risk indicators\
        \ and context (e.g. time, location) to select the authentication components\
        \ and requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Multi-Step Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:7
      ref_id: 16.7.27
      description: "Multi-step Authentication is a design and architectural approach\
        \ to control access to resources by sequentially using multiple authentication\
        \ verifiers.\_ Each authentication step grants access to increasingly privileged\
        \ areas of the system until access to the desired resources is reached (refer\
        \ also to 16.4 \u2013 Privileged Access Management).\_ Multi-Step Authentication\
        \ can be activated by risk-based \u201Ctriggers\u201D where risk factors are\
        \ identified."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:7
      ref_id: 16.7.28
      description: "Multi-step Authentication may require only one authentication\
        \ factor or mechanism, so it is important not to confuse Multi-Step Authentication\
        \ with Multi-Factor Authentication.\_ Multi-Step Authentication may not be\
        \ as secure as MFA and cannot be an appropriate substitute for MFA.\_ A key\
        \ risk is repeated use of a single authentication factor."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:7
      ref_id: 16.7.29
      description: It is also worth noting, however, that Multi-Step combined with
        Multi-Factor Authentication is a strong architectural security construct,
        particularly when a multi-factor request is triggered for accessing a privileged
        account.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Perfect Forward Secrecy
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:8
      ref_id: 16.7.30
      description: In addition to the encryption protocols and algorithms discussed
        in Chapter 17 - Cryptography, the concept of Perfect Forward Secrecy (PFS),
        often simplified to Forward Secrecy, should also be incorporated into any
        authentication mechanism design.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:8
      ref_id: 16.7.31
      description: "Forward Secrecy is a property of secure communication protocols\
        \ that is intended to prevent a compromised encryption key from being used\
        \ to decrypt previously encrypted traffic.\_ Clearly a compromised key must\
        \ be immediately replaced in order to maintain the integrity of communications.\_\
        \ This mechanism is described as a \u201Crolling secrets\u201D technique and\
        \ is designed to prevent device spoofing and the cloning of mobile clients."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:8
      ref_id: 16.7.32
      description: "A \u201Crolling secret\u201D key is located on the client device.\_\
        \ The client receives two encrypted packages.\_ The first contains another\
        \ private key and is decrypted by the current private key held on the client\
        \ device.\_ The new key is used to decrypt the second package and the new\
        \ private key replaces the existing private key, which is then discarded.\_\
        \ The new key is used to encrypt traffic to the authentication server.\_ With\
        \ each cycle the client replaces the old key with the new key."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Cryptography
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:9
      ref_id: 16.7.33
      description: "The use of encryption is a fundamental component in the security\
        \ of a Multi-Factor Authentication mechanism.\_ It is essential that only\
        \ approved cryptographic protocols and algorithms are used,\_refer to Chapter\
        \ 17 \u2013 Cryptography."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Risk Analysis
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:10
      ref_id: 16.7.34
      description: "The design of Multi-Factor Authentication should start with a\
        \ risk review in order to identify any existing and new risks from changing\
        \ environments, user populations and threat landscapes.\_ Some early steps\
        \ will include:\n\nReview business drivers, existing identity infrastructure,\
        \ enterprise applications, core platform infrastructure and development plans\
        \ for each of these;\nEnsure any plans for cloud and related services are\
        \ reviewed and incorporated;\nIdentify authentication use cases including\
        \ employees and contractors, consumers, customers, partners, and suppliers.\_\
        \ For Digital Government this may also include the General Public for some\
        \ systems;\nDevelop baseline requirements;\nUndertake a threat analysis for\
        \ each use case; and\n\nSelect control mechanisms to manage identified risks."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:10
      ref_id: 16.7.35
      description: "This risk analysis will inform and direct the development of an\
        \ authentication architecture to provide robust but usable security for each\
        \ use case.\_ Some key questions include:\n\nHow will users access the system\
        \ or application?\nAt what stages will users be authenticated?\nWhat authentication\
        \ factors will provide the appropriate level of authentication and security?\n\
        Is the level of authentication appropriate to secure and protect the systems,\
        \ data and other related assets? and\nIs there sufficient capacity to service\
        \ anticipated workloads?\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:10
      ref_id: 16.7.36
      description: "MFA is an additional way of managing access to systems and data.\
        \ MFA will only provide additional layers of managing access to systems provided\
        \ the fundamentals of Identification and Access Management are met. This includes:\n\
        \nImplementation of least privileged principles.\nAccess is removed when not\
        \ required.\_\nAdministration privileges are limited to only users who require\
        \ these privileges.\nEnforcing strong passwords through password policies\
        \ (when passwords are in use).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:2:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2
      description: Governance and Control
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:11
      ref_id: 16.7.37
      description: "Good governance processes assist in identifying potential risks\
        \ to your systems, data, employees, partners and contractors. This reduces\
        \ the risk of a breach or failure to comply with legislation and regulation.\_\
        \ Good governance processes support the fulfilment of duties of senior and\
        \ executive management."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:11
      ref_id: 16.7.38
      description: "Technology governance must demonstrate effective control, security,\
        \ effectiveness and clear accountability.\_ Identity Access Management and\
        \ Authentication are fundamental components in protecting agency systems,\
        \ data and technology assets and underpinning technology governance structures.\_\
        \n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:2:11
      ref_id: 16.7.39
      description: "There are also several national and international legislative\
        \ and regulatory requirements and accepted international standards which may\
        \ influence aspects of governance, particularly in relation to data protection\
        \ and privacy.\_ While not an exhaustive list, these include:\n\nNew Zealand\u2019\
        s Privacy Act;\nNew Zealand\u2019s Public Records Act;\nThe EU\u2019s General\
        \ Data Protection Regulation (GDPR);\nISO/IEC 27701\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.40
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:3
      ref_id: 16.7.40
      description: "Additional information relating to event logging is contained\
        \ in:\n\n\n\nTitle\nPublisher\nSource\n\n\n\nIdentification Standards\n\n\n\
        NZ Govt\n\_\n\n\nIdentification Management Standards | NZ Digital government\n\
        \n\n\n\nISO/IEC 27001\n\nISO/IEC/ Standards NZ\nISO - International Organization\
        \ for Standardization\n\n\nNIST Digital Identity Guidelines\nNIST\nNIST Special\
        \ Publication 800-63 Digital Identity Guidelines | NIST\n\n\nOAuth 2.0\nIETF\
        \ OAuth Working Group\nOAuth 2.0 \u2014 OAuth\n\n\nCloud security guidance\
        \ - Identity and authentication\nNCSC UK\nPrinciple 10: Identity and authentication\
        \ - NCSC.GOV.UK\n\n\nFIDO Specifications Overview\nFIDO Alliance\nUser Authentication\
        \ Specifications Overview - FIDO Alliance\n\n\nMicrosoft Entra ID - Multi-Factor\
        \ Authentication\nMicrosoft\nMicrosoft Entra multifactor authentication overview\
        \ - Microsoft Entra ID | Microsoft Learn\n\n\nMultifactor Authentication Cheat\
        \ Sheet\n\nOWASP\n\nMultifactor Authentication - OWASP Cheat Sheet Series\n\
        \n\nImplementing Phishing Resistant MFA\nCISA\nImplementing Phishing-Resistant\
        \ MFA\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4
      description: ' Risk Analysis'
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.41.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:1
      ref_id: 16.7.41.R.01
      description: "The requirement for an agency information security policy is discussed\
        \ and described in Chapter 5 \u2013 Information Security Documentation.\_\
        \ An essential part of any security policy is the assessment of risk and the\
        \ inclusion of requirements for securing access to systems, applications and\
        \ data."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.41.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:1
      ref_id: 16.7.41.R.02
      description: "A risk analysis is fundamental to the design, implementation and\
        \ maintenance of Multi-Factor Authentication (MFA) processes and will inform\
        \ and direct the development of requirements and an authentication architecture\
        \ to provide robust but usable security.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.41.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:1
      ref_id: 16.7.41.C.01
      name: 'Control -  All Classifications - Must [CID: 6948]'
      description: Agencies MUST undertake a risk analysis before designing and implementing
        MFA.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4
      description: System Architecture and Security Controls
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.R.01
      description: "Security controls should support security while enabling authorised\
        \ user access.\_ The system architecture should be sufficiently comprehensive\
        \ to support this objective."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.R.02
      description: External facing systems and authenticating to third-party services
        exposes additional risk to the organisation. MFA provides an additional layer
        to help an organisation manage risk of systems compromise through authentication
        attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.R.03
      description: While phishing-resistant MFA methods, such as hardware security
        keys or biometric authentication, offer stronger protection (compared to non-phishing-resistant
        MFA), some of these methods may not always be feasible for all users of systems.
        Therefore, while we strongly encourage the adoption of phishing resistant
        MFA wherever possible, any form of MFA is considered an improvement over relying
        solely on passwords.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.R.04
      description: Where devices or systems do not support MFA, organisations are
        encouraged to implement appropriate compensating controls. These measures
        can help mitigate the risks associated with relying solely on passwords.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.01
      name: 'Control -  All Classifications - Should [CID: 7563]'
      description: "The design of an agency MFA SHOULD include consideration of:\n\
        \nRisk identification;\nLevel of security and access control appropriate for\
        \ each aspect of an organisation\u2019s information systems (data, devices,\
        \ equipment, storage, cloud, etc.)\nA formal authorisation process for user\
        \ system access and entitlements;\nLogging,\_monitoring and reporting of activity;\n\
        Review of logs for orphaned accounts and inappropriate user access including\
        \ unsuccessful authentication;\nIdentification of error and anomalies which\
        \ may indicate inappropriate or malicious activity;\nIncident response;\n\
        Remediation of errors;\nSuspension and/or revocation of access rights where\
        \ policy violations occur;\nCapacity planning.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.02
      name: 'Control -  All Classifications - Should [CID: 6953]'
      description: 'Where an agency has implemented MFA they MUST:


        require MFA for administrative or other high privileged users; and

        implement a secure, multi-factor process to allow entities to reset their
        standard user credentials.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.03
      name: 'Control -  All Classifications - Must [CID: 7564]'
      description: Agencies MUST implement MFA on all user accounts with remote access
        to organisational resources.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.04
      name: 'Control -  All Classifications - Should [CID: 7565]'
      description: 'Agencies SHOULD implement MFA on all user accounts with access
        to organisational resources. '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.05
      name: 'Control -  All Classifications - Should [CID: 7566]'
      description: 'Where agencies have implemented MFA, they SHOULD implement phishing-resistant
        MFA on administration accounts. '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.06
      name: 'Control -  All Classifications - Should [CID: 7567]'
      description: Agencies SHOULD use phishing-resistant MFA when authenticating
        users to systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.42.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:2
      ref_id: 16.7.42.C.07
      name: 'Control -  All Classifications - Should [CID: 6952]'
      description: "The design of an agency MFA SHOULD include consideration of:\n\
        \nRisk identification;\nLevel of security and access control appropriate for\
        \ each aspect of an organisation\u2019s information systems (data, devices,\
        \ equipment, storage, cloud, etc.)\nA formal authorisation process for user\
        \ system access and entitlements;\nLogging,\_monitoring and reporting of activity;\n\
        Review of logs for orphaned accounts and inappropriate user access including\
        \ unsuccessful authentication;\nIdentification of error and anomalies which\
        \ may indicate inappropriate or malicious activity;\nIncident response;\n\
        Remediation of errors;\nSuspension and/or revocation of access rights where\
        \ policy violations occur;\nCapacity planning.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4
      description: Integration with Policy
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.43.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:3
      ref_id: 16.7.43.R.01
      description: "The requirement for an agency information security policy is discussed\
        \ and described in Chapter 5 \u2013 Information Security Documentation.\_\
        \ Privileged Access Management policy is discussed in Section 16.4 - Privileged\
        \ Access Management."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.43.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:3
      ref_id: 16.7.43.C.01
      name: 'Control -  All Classifications - Should [CID: 6956]'
      description: "The design of an organisations MFA system SHOULD be integrated\
        \ with the agency\u2019s Information Security Policy, the agency\u2019s Privileged\
        \ Access Management (PAM) Policy, and any additional agency password policies."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:16.7:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4
      description: User Training
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.44.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:4
      ref_id: 16.7.44.R.01
      description: It is important that users understand and have continued awareness
        of risks and threats to authentication credentials, in order to maintain the
        integrity of the credentials and to maintain the security of the systems being
        accessed.
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.44.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:4
      ref_id: 16.7.44.R.02
      description: "MFA introduces some complexity and may require the use of specific\
        \ devices, hardware or applications.\_ Training is essential to increase user\
        \ awareness and maintain adequate security practices."
    - urn: urn:defend:risk:req_node:nzism-v3:16.7.44.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:16.7:4:4
      ref_id: 16.7.44.C.01
      name: 'Control -  All Classifications - Must [CID: 6960]'
      description: "When agencies\u2019 implement MFA they MUST ensure users have\
        \ an understanding of the risks, and include appropriate usage and safeguards\
        \ for MFA in the organisation\u2019s user training and awareness programmes."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17
      assessable: false
      depth: 1
      ref_id: '17'
      name: Cryptography
    - urn: urn:defend:risk:req_node:nzism-v3:17.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.1'
      name: Cryptographic Fundamentals
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:1
      ref_id: 17.1.1
      description: Agencies use cryptographic products, algorithms and protocols that
        are approved by the GCSB and are implemented in accordance with this guidance.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:1
      ref_id: 17.1.2
      description: "This section covers information on the fundamentals of cryptography\
        \ including the use of encryption to protect data at rest and in transit.\
        \ \_Detailed information on algorithms and protocols approved to protect classified\
        \ information can be found in Section 17.2 - Approved Cryptographic Algorithms\
        \ and Section 17.3 - Approved Cryptographic Protocols."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Purpose of cryptography
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      ref_id: 17.1.3
      description: "Cryptography is primarily used to support:\nConfidentiality \u2013\
        \ protecting against the risk of information being disclosed to an unauthorised\
        \ person;\nAuthentication \u2013 ensuring a person or entity is who they claim\
        \ to be;\nIntegrity \u2013 ensuring information has not been compromised,\
        \ either deliberately or accidentally; and\nNon-repudiation \u2013 proving\
        \ who (or what) performed an action.\_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      ref_id: 17.1.4
      description: "Cryptography is an important control for data protection. The\
        \ encryption selected may change depending on the classification of the data.\_\
        \ It is important to note that classification, in itself, provides no protection\
        \ but is merely a labelling mechanism to indicate the degree of protection\
        \ and care required in handling that data."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      ref_id: 17.1.5
      description: Cryptography is frequently used in the establishment of secure
        connectivity (e.g. IPSec VPNs) and in trust frameworks such as those supported
        by Public Key Infrastructure (PKI).
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      ref_id: 17.1.6
      description: "With the increases in speed and computing power and the cost reductions\
        \ of modern computing, older cryptographic algorithms are increasingly vulnerable.\
        \ \_It is vital that recommendations and controls in the NZISM are followed."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:2
      ref_id: 17.1.7
      description: "Mitigation of the risks when using older cryptographic algorithms,\
        \ often takes the form of increased key lengths.\_ Agencies should also note\
        \ the increasing threat posed by the evolution and development of quantum\
        \ computing (see 17.1.19 - Quantum Computing and Encryption)."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.8
      description: "Encryption is the process of converting plain (readable) text\
        \ to an unintelligible form (cipher text).\_ The term encryption is often\
        \ used synonymously with cryptography."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.9
      description: The use of approved encryption will generally reduce the likelihood
        of an unauthorised party gaining access to the information contained within
        the encrypted data.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.10
      description: When data is at rest, encryption can be used to reduce the physical
        protection and handling requirements of media or systems. This does not change
        the classification of the underlying data system or equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.11
      description: Care needs to be taken with encryption systems that do not encrypt
        the entire media content to ensure that either all of the classified data
        is encrypted or that the media is handled in accordance with the highest classification
        of the unencrypted data.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.12
      description: Encryption of data in transit can be used to provide protection
        for information being communicated over insecure media and hence reduce the
        security requirements of the communication process.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.13
      description: It is important to note that when agencies use encryption for data
        at rest or in transit, they are not reducing the classification of the information.
        When encryption is used the potential risk of disclosure of the information
        is reduced.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.14
      description: As the classification of the information does not change when encrypted,
        agencies cannot use lowered storage, physical transfer or security requirements
        as a baseline to further lower requirements with an additional cryptographic
        product.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:3
      ref_id: 17.1.15
      description: "In general terms, the level of assurance of specific encryption\
        \ protocols and algorithms is defined in terms of Common Criteria, Protection\
        \ Profiles or, in some cases, approved cryptographic evaluations.\_ It is\
        \ important to note that evaluations of cryptographic protocols and algorithms\
        \ are NOT universally conducted when security products are evaluated, relying\
        \ rather on previous approved evaluations of cryptographic protocols and algorithms."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Risk Assessments
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:4
      ref_id: 17.1.16
      description: "Encryption algorithms apply data transformations that are designed\
        \ to be difficult to reverse by unauthorised users.\_ Today\u2019s software\
        \ will usually provide several algorithmic options, but may include some older\
        \ algorithms provided for backward compatibility with older (legacy) systems.\_\
        \ In many cases the older algorithms are deprecated, are considered time-expired\
        \ and are not fit for purpose in modern systems. Deprecated algorithms should\
        \ not be used."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:4
      ref_id: 17.1.17
      description: "In all cases a comprehensive risk assessment should be undertaken\
        \ before configurations are selected.\_ Some general principles to be considered\
        \ are:\nCryptographic strength is determined by a combination of the encryption\
        \ algorithm being used, the encryption protocol and the key length.\_ Longer\
        \ keys generally provide increased encryption strength over shorter keys when\
        \ using the same encryption algorithm;\nAsymmetric cryptographic algorithms\
        \ are slower than symmetric cryptographic algorithms at an equivalent cryptographic\
        \ strength;\nAsymmetric cryptographic algorithms are recommended for the exchange\
        \ of symmetric cryptographic keys when they are needed to be shared across\
        \ communication channels;\nEncrypted data cannot usually be compressed, but\
        \ compressed data can be encrypted.\_ Data should be compressed before encryption;\n\
        Encryption keys have the same requirements for handling and storage as the\
        \ unencrypted data they are being used to protect;\nAny risk assessment should\
        \ include consideration of key management \u2013 refer to section 17.9 Key\
        \ Management.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:4
      ref_id: 17.1.18
      description: It is important to note that the NZISM prescribes approved algorithms
        and protocols and users must select combinations from these lists.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Quantum Computing and Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      ref_id: 17.1.19
      description: "Developments in quantum computing have highlighted threats to\
        \ classical cryptography whereby a quantum computing, can undermine all of\
        \ the widely used public key algorithms used for key establishment and digital\
        \ signatures.\_ While this may be not an immediate issue, quantum developments\
        \ are likely to undermine the effectiveness of encryption being used today\
        \ to protect confidentiality of information."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      ref_id: 17.1.20
      description: A further implication is that historical and archived data protected
        by encryption may be at risk.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      ref_id: 17.1.21
      description: It is generally accepted that symmetric encryption, with sufficiently
        long keys, will remain quantum resistant in the short term but that quantum
        resistant replacements for digital signature and key establishment algorithms
        will be required in the near future.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      ref_id: 17.1.22
      description: "In the longer term, quantum resistant algorithms are expected\
        \ to be developed, standardised and approved for use.\_ Until such time, however,\
        \ agencies should be positioning themselves to be ready to migrate to a \u201C\
        post-quantum encryption\u201D environment."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:5
      ref_id: 17.1.23
      description: "As it is now recognised that agencies will need to undertake future\
        \ migration activities related to post-quantum encryption, it is no longer\
        \ specifically advised to invest in migration from RSA to ECC-based algorithms\
        \ if that has not already taken place.\_ Emphasis should instead be placed\
        \ on ensuring minimum key lengths specified in the NZISM are adhered to."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Transitioning Cryptographic Algorithms and Protocols
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:6
      ref_id: 17.1.24
      description: "It is important to use algorithms that adequately protect sensitive\
        \ information.\_ It is also important to recognise that all cryptographic\
        \ algorithms and protocols have a finite life.\_ Challenges are posed by new\
        \ cryptanalysis techniques and methods, the increasing power of classical\
        \ computing technology, and the continuing work on the development of quantum\
        \ computers.\_ In addition, there is an active field of work that continuously\
        \ seeks to compromise algorithms and protocols currently in\_use."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:6
      ref_id: 17.1.25
      description: "Planning for changes in the use of cryptography because of algorithm\
        \ breaks, the availability of more powerful computing techniques or new technologies\
        \ is an important consideration for agencies.\_ Awareness of retirement or\
        \ deprecation of algorithms and associated protocols is essential."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: 'RSA '
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:7
      ref_id: 17.1.26
      description: "RSA was announced in 1976 and is now over 45 years old. Several\
        \ flaws and attacks have been identified since creation, each of which required\
        \ specific mitigations, careful implementation and management.\_ Unfortunately\
        \ there is ample evidence that implementers continue to have difficulties\
        \ in securely implementing, using and managing RSA."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:7
      ref_id: 17.1.27
      description: "To counter identified threats from shorter RSA key lengths, longer\
        \ key lengths have been specified in the NZISM since 2010.\_ Minimum key lengths\
        \ have been subsequently increased over time."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:7
      ref_id: 17.1.28
      description: "For a number of years there had been several indicators that RSA\
        \ was likely to be deprecated by the cryptographic community and standards\
        \ bodies.\_ For example, TLS 1.3 has deprecated the use of RSA for key exchange\
        \ in favour of elliptic curve cryptography, but RSA is still supported for\
        \ digital signatures in the current standard.\_ Previous guidance from NIST\
        \ was also indicative of the impending deprecation of RSA.\_ However, subsequent\
        \ guidance no longer recommends moving from RSA to elliptic curve if that\
        \ has not already been done."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:7
      ref_id: 17.1.29
      description: "Therefore, while RSA is not fully deprecated in the NZISM, it\
        \ is approved ONLY for a limited set of uses as described in Section 17.2\
        \ \u2013 Approved Cryptographic Algorithms."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Product specific cryptographic requirements
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:8
      ref_id: 17.1.30
      description: "This section provides requirements for the use of cryptography\
        \ to protect classified information.\_ Requirements, in addition to those\
        \ in this Manual, can exist in consumer guides for products once they have\
        \ completed an approved evaluation.\_ Vendor specifications supplement this\
        \ manual and where conflict in controls occurs the product specific requirements\
        \ take precedence.\_ Any policy or compliance conflicts are to be incorporated\
        \ into the risk assessment."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Exceptions for using cryptographic products
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:9
      ref_id: 17.1.31
      description: "Where Agencies implement a product that uses an Approved Cryptographic\
        \ Algorithm or Approved Cryptographic Protocol to provide protection of unclassified\
        \ data at rest or in transit, that product does not require a separate, approved\
        \ evaluation. \_Correct implementation of the cryptographic protocol is fundamental\
        \ to the proper operation of the Approved Cryptographic Algorithm or Approved\
        \ Cryptographic Protocol and is part of the checking conducted during system\
        \ certification."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Federal Information Processing Standard 140
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:10
      ref_id: 17.1.32
      description: FIPS 140 is a United States standard for the evaluation and validation
        of both hardware and software cryptographic modules.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:10
      ref_id: 17.1.33
      description: "FIPS 140 is in its third iteration and is formally referred to\
        \ as FIPS 140-3.\_ This section refers to the standard as FIPS 140 but this\
        \ should be considered to encompass FIPS 140-1, FIPS 140-2 and FIPS 140-3."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:10
      ref_id: 17.1.34
      description: "FIPS 140 is not a substitute for an approved evaluation of a product\
        \ with cryptographic functionality. \_FIPS 140 is concerned solely with the\
        \ cryptographic functionality of a module and does not consider any other\
        \ security functionality."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:10
      ref_id: 17.1.35
      description: "Cryptographic evaluations of products will normally be conducted\
        \ by an approved agency. \_Where a product\u2019s cryptographic functionality\
        \ has been validated under FIPS 140, the GCSB can, at its discretion, and\
        \ in consultation with the vendor, reduce the scope of a cryptographic evaluation."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: New Zealand National Policy for High Assurance Cryptographic Equipment
        and Key Management
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:11
      ref_id: 17.1.36
      description: "The New Zealand National Standard for High Assurance Cryptographic\
        \ Equipment (HACE) and related key management is contained in the New Zealand\
        \ Communications Security Policy No. 301 \u2013 Safeguarding of Communications\
        \ Security (COMSEC) Material.\_ This prescribes national doctrine for the\
        \ safeguarding of COMSEC materials.\_ New Zealand Communications Security\
        \ Policy No. 301 \u2013 Safeguarding of Communications Security (COMSEC) Material,\
        \ replaces New Zealand Communications Security Standard No. 300 \u2013 Control\
        \ of COMSEC Material which is now withdrawn. Note NZCSP 301 is a RESTRICTED\
        \ document."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Protection of RESTRICTED/SENSITIVE information in transit over
        public systems
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:12
      ref_id: 17.1.37
      description: The physical requirements for protection of information classified
        RESTRICTED/SENSITIVE are provided by the classification system and PSR guidance.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:12
      ref_id: 17.1.38
      description: Where such information is generated and held on information systems
        (any computer device, including laptops, mobile phones, tablets, desktop and
        networked systems), the requirements of the NZISM apply. Of particular note
        is the requirement to encrypt RESTRICTED/SENSITIVE data when in transit over
        public systems, including any Internet connection, public network or any other
        network NOT directly controlled by the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: Encryption and Key Management
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.39
      description: Direct agency control is described as the immediate and continuous
        physical and logical control, responsibility for, protection and operation
        of agency information systems and data (see 2.2.4).
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.40
      description: "Indirect agency control is described as when information is not\
        \ under the direct control of the agency, this may be through outsourcing,\
        \ ICT management or services, third party facilities such as data centre co-locations,\
        \ or consumption of cloud services (see 2.2.5 \u2013 2.2.7)."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.41
      description: Encryption can be used to protect information not under the direct
        control of the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.42
      description: "The use of encryption (including data encryption, use of a VPN\
        \ or any other form of protection using cryptography) requires cryptographic\
        \ key management and the retention of control of both keys and key management\
        \ processes.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.43
      description: Where agencies make use of VPNs or other forms of network connectivity
        that protect data in transit, the control and management of the cryptographic
        key is fundamental to the integrity and confidentiality of the encrypted data.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.44
      description: If encryption keys are compromised, then any authentication and
        encryption mechanisms that rely on those keys, no matter how robust or comprehensive,
        are futile.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.45
      description: "If encryption keys are lost, damaged, or fail then access to data\
        \ encrypted using those keys will also be lost.\_ If control of encryption\
        \ keys is lost, then those keys should be considered to be compromised and\
        \ must be replaced or superseded urgently."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.46
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:13
      ref_id: 17.1.46
      description: "The selection of the cryptographic protocol and algorithm is described\
        \ in this chapter and specified in 17.1.55.C.02. It is essential that agencies\
        \ select and use only approved cryptographic algorithms and protocols (see\
        \ section 17.2 \u2013 Approved Cryptographic Protocols) and apply the cryptographic\
        \ key management requirements of the NZISM (see section 17.9 - Key Management)."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:2:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2
      description: VPN connection Security
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.47
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:14
      ref_id: 17.1.47
      description: The types of encryption, protocols, and cryptographic algorithms
        applied in the establishment and maintenance of a VPN connection are fundamental
        to the security and integrity of the connection.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.48
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:14
      ref_id: 17.1.48
      description: "Key aspects of VPN security include:\nThe encryption algorithm\
        \ and protocol used;\nCryptographic key length;\nThe authentication protocol\n\
        Key Exchange protocol;\nSelection of VPN protocol;\nVPN monitoring and a \u201C\
        kill switch\u201D to deter IP leakage\_\_ and snooping;\nCryptographic key\
        \ management.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.49
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:2:14
      ref_id: 17.1.49
      description: "It is important to understand that a variety of VPN services can\
        \ use a variety of mechanisms.\_ Agencies should also consider the service\
        \ provider\u2019s use of hash authentication, perfect forward secrecy, and\
        \ the difference in encryption settings on both the data and control channels.\_\
        \ The NZISM specifies the cryptographic protocols and cryptographic algorithms\
        \ that should be used (see sections 17.2 \u2013 Approved Cryptographic Algorithms\
        \ and 17.3 \u2013 Approved Cryptographic Protocols) and agencies must ensure\
        \ the VPN connection conforms with these requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.50
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:3
      ref_id: 17.1.50
      description: "Further references can be found at:\_\n\n\nReference\nTitle\n\
        Publisher\nSource\n\n\nNZCSP 301\nNew Zealand Communications Security Policy\
        \ 301 - Safeguarding of Communications Security (COMSEC) Material, NZCSP 301\
        \ replaces NZCSS 300\nGCSB\n\nContact the GCSB\nRESTRICTED document available\
        \ on application to authorised personnel\n\n\n\n\_PSR\nHandling requirements\
        \ for protectively marked information and equipment\nNZ Government Protective\
        \ Security Requirements\_\nhttps://protectivesecurity.govt.nz/classification-system/how-to-protect\n\
        \n\n\_\nTransport Layer Security (tls)\nIETF\nhttps://datatracker.ietf.org/wg/tls/documents/\n\
        \n\n\_\nTLS 1.3\nIETF\nhttps://www.ietf.org/blog/tls13/\n\n\n\_\nThe Transport\
        \ Layer Security (TLS) Protocol Version 1.3 March 2018\nIETF\nhttps://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html\_\
        \n\n\nRFC 2407\nThe Internet IP Security Domain of Interpretation for ISAKMP\n\
        IETF\nhttps://tools.ietf.org/html/rfc2407\_\n\n\nRFC 2408\_\nInternet Security\
        \ Association and Key Management Protocol (ISAKMP)\nIETF\nhttps://tools.ietf.org/html/rfc2408\_\
        \n\n\nRFC 2409\_\nThe Internet Key Exchange (IKE)\nIETF\nhttps://tools.ietf.org/html/rfc2409\n\
        \n\nRFC 8446\_\nThe Transport Layer Security (TLS) Protocol Version 1.3\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc8446\n\n\nRFC 8996\_\nDeprecating\
        \ TLS 1.0 and TLS 1.1 \u2013 Best Current Practise\nIETF\_\nhttps://datatracker.ietf.org/doc/html/rfc8996\n\
        \n\nFIPS 140-3 (March 2019)\_\nSecurity Requirements for Cryptographic Modules\_\
        \nNIST\_\nhttps://csrc.nist.gov/publications/detail/fips/140/3/final\_\n\n\
        \nFIPS 186-4 (July 2013)\nDigital Signature Standard (DSS)\_\nNIST\_\_\nhttps://csrc.nist.gov/publications/detail/fips/186/4/draft\n\
        \n\nFIPS 186-5 (Draft, January 2020)\_\_\nDigital Signature Standard (DSS)\_\
        \nNIST\_\_\nhttps://csrc.nist.gov/publications/detail/fips/186/5/draft\n\n\
        \nFIPS 197 (November 2001)\nAdvanced Encryption Standard (AES) (This publication\
        \ is under review)\n\_NIST\_\nhttps://csrc.nist.gov/publications/detail/fips/197/final\n\
        \n\nNIST SP 800-56A Rev. 3 (April 2018)\nRecommendation for Pair-Wise Key-Establishment\
        \ Schemes Using Discrete Logarithm Cryptography\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-56a/rev-3/final\n\
        \n\nNIST SP 800-56B Rev. 2 (March 2019)\nRecommendation for Pair-Wise Key-Establishment\
        \ Using Integer Factorization Cryptography\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-56b/rev-2/final\n\
        \n\nNIST SP 800-131A Rev. 2 (March 2019)\nTransitioning the Use of Cryptographic\
        \ Algorithms and Key Lengths\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final\n\
        \n\nNIST SP 800-57 Part 1 Rev. 5 (May 2020)\nRecommendation for Key Management:\
        \ Part 1 \u2013 General\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final\n\
        \n\nNIST SP 800-57 Part 2 Rev. 1 (May 2019)\nRecommendation for Key Management:\
        \ Part 2 \u2013 Best Practices for Key Management Organizations\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final\n\
        \n\nNIST SP 800-57 Part 3 Rev. 1 (January 2015)\nRecommendation for Key Management,\
        \ Part 3: Application-Specific Key Management Guidance\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-57-part-3/rev-1/final\n\
        \n\nNIST 800-175A (August 2016)\nGuideline for Using Cryptographic Standards\
        \ in the Federal Government: Directives, Mandates and Policies\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-175A.pdf\
        \ [PDF, 470 KB]\n\n\nNIST SP 800-175B\_Rev. 1 (March 2020)\nGuideline for\
        \ Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms\n\
        NIST\nhttps://csrc.nist.gov/publications/detail/sp/800-175b/rev-1/final\n\n\
        \nCNSS Policy 15 (October 2016)\nUse of Public Standards for Secure Information\
        \ Sharing\n\nCommittee on National Security Systems\n(CNSS)\n\nhttps://www.cnss.gov/CNSS/issuances/Policies.cfm\n\
        \n\nNSA Quantum Computing FAQ (August 2021)\nQuantum Computing and Post-Quantum\
        \ Cryptography\nNSA\nhttps://media.defense.gov/2021/Aug/04/2002821837/-1/-1/1/Quantum_FAQs_20210804.pdf\
        \ [PDF, 258 KB]\n\n\n\nVPNCP\nVersion 3.1 March 2015\n\nVirtual Private Network\
        \ Capability Package Version 3.1 March 2015\_\nNSA\_\nhttps://www.nsa.gov/ia/_files/VPN_CP_3_1.pdf\n\
        \n\n\n\_\n\nSuite B Implementer\u2019s Guide to NIST SP 800-56A, July 28,\
        \ 2009\nNSA\nhttp://docplayer.net/204368-Suite-b-implementer-s-guide-to-nist-sp-800-56a-july-28-2009.html\n\
        \n\n\nEPC342-08 Version 7.0 4 November 2017\n\nGuidelines on Cryptographic\
        \ Algorithms Usage and Key Management\nEuropean Payments Council\nhttps://www.europeanpaymentscouncil.eu/document-library/guidance-documents/guidelines-cryptographic-algorithms-usage-and-key-management\n\
        \n\n\n\_\n\nChoose an Encryption Algorithm\nMicrosoft\nhttps://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/choose-an-encryption-algorithm?view=sql-server-2017\n\
        \n\n\n\_\n\nTransport Layer Protection Cheat Sheet\nOWASP\nhttps://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet\n\
        \n\n\_\nGuide to Cryptography\nOWASP\nhttps://www.owasp.org/index.php/Guide_to_Cryptography\n\
        \n\n\_\nNew Directions in Cryptography - IEEE Transactions on Information\
        \ Theory Vol IT22 November 1976\nDiffie, Hellman\nhttps://ee.stanford.edu/~hellman/publications/24.pdf\
        \ [PDF, 2.1 MB]\n\n\n\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Using cryptographic products
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.51.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:1
      ref_id: 17.1.51.R.01
      description: "No real-world product can ever be guaranteed to be free of vulnerabilities.\
        \ \_The best that can be done is to increase the level of assurance in a product\
        \ to a point that represents satisfactory risk management."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.51.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:1
      ref_id: 17.1.51.R.02
      description: Refer to Chapter 12 - Product Security for a discussion on product
        evaluation and assurance.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.51.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:1
      ref_id: 17.1.51.C.01
      name: 'Control -  All Classifications - Must [CID: 2070]'
      description: Agencies using cryptographic functionality within a product to
        protect the confidentiality, authentication, non-repudiation or integrity
        of information, MUST ensure that the product has completed a cryptographic
        evaluation recognised by the GCSB.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Data recovery
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.52.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:2
      ref_id: 17.1.52.R.01
      description: "It is important for continuity and operational stability that\
        \ cryptographic products provide a means of data recovery to allow for the\
        \ recovery of data in circumstances such as where the encryption key is unavailable\
        \ due to loss, damage or failure. \_This includes production, storage, backup\
        \ and virtual systems. This is sometimes described as \u201Ckey escrow\u201D\
        ."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.52.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:2
      ref_id: 17.1.52.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2074]'
      description: Cryptographic products MUST provide a means of data recovery to
        allow for recovery of data in circumstances where the encryption key is unavailable
        due to loss, damage or failure.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.52.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:2
      ref_id: 17.1.52.C.02
      name: 'Control -  All Classifications - Should [CID: 2075]'
      description: Cryptographic products SHOULD provide a means of data recovery
        to allow for recovery of data in circumstances where the encryption key is
        unavailable due to loss, damage or failure.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Reducing storage and physical transfer requirements
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.R.01
      description: "When encryption is applied to storage media (whether portable\
        \ or residing within IT equipment or systems) it provides an additional layer\
        \ of defence.\_ Whilst such measures do not reduce or alter the classification\
        \ of the information itself, physical storage, handling and transfer requirements\
        \ may be reduced to those of a lesser classification for the media or equipment\
        \ (but not the data itself).\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.R.02
      description: Approved Cryptographic Algorithms are discussed in section 17.2.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.C.01
      name: 'Control -  All Classifications - Must [CID: 2079]'
      description: Encryption used to reduce storage or physical handling protection
        requirements MUST be an approved cryptographic algorithm in an EAL2 (or higher)
        encryption product.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 2080]'
      description: "If an agency wishes to reduce the storage or physical transfer\
        \ requirements for IT equipment or media that contains classified information,\
        \ they MUST encrypt the classified information using High Assurance Cryptographic\
        \ Equipment (HACE).\_ It is important to note that the classification of the\
        \ information itself remains unchanged."
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.C.03
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2081]'
      description: "If an agency wishes to use encryption to reduce the storage, handling\
        \ or physical transfer requirements for IT equipment or media that contains\
        \ classified information, they MUST use:\nfull disk encryption; or\npartial\_\
        disk encryption where the access control will allow writing ONLY to the encrypted\
        \ partition holding the classified information.\n"
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.53.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:3
      ref_id: 17.1.53.C.04
      name: 'Control -  All Classifications - Should [CID: 2082]'
      description: "If an agency wishes to use encryption to reduce the storage or\
        \ physical transfer requirements for IT equipment or media that contains classified\
        \ information, they SHOULD use:\nfull disk encryption; or\npartial\_disk encryption\
        \ where the access control will allow writing ONLY to the encrypted partition\
        \ holding the classified information.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Encrypting NZEO information at rest
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.54.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:4
      ref_id: 17.1.54.R.01
      description: NZEO information is particularly sensitive and it requires additional
        protection in the form of encryption, when at rest. This includes production,
        storage, backup and virtual systems.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.54.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:4
      ref_id: 17.1.54.C.01
      name: 'Control -  All Classifications - Must [CID: 2085]'
      description: Agencies MUST use an Approved Cryptographic Algorithm to protect
        NZEO information when at rest on a system.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Information and Systems Protection
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.R.01
      description: When encryption is applied to information being communicated over
        networks, less assurance is required for the physical protection of the communications
        infrastructure. In some cases, no physical security can be applied to the
        communications infrastructure such as public infrastructure, the Internet
        or non-agency controlled infrastructure. In other cases no direct assurance
        can be obtained and reliance is placed on third party reviews and reporting.
        In such cases encryption of information is the only practical mechanism to
        provide sufficient assurance that the agency information systems are adequately
        protected.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.R.02
      description: "Data duplication for backups or data replication aggregates agency\
        \ information and will generally increase the impact of an unauthorised party\
        \ gaining access to, or otherwise compromising, the data.\_ This includes\
        \ where outsourced services are undertaken."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 2089]'
      description: Agencies MUST use HACE if they wish to communicate or pass information
        over UNCLASSIFIED, insecure or unprotected networks.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.C.02
      name: 'Control -  Restricted/Sensitive - Must [CID: 2090]'
      description: Information or systems classified RESTRICTED or SENSITIVE MUST
        be encrypted with an Approved Cryptographic Algorithm and Protocol if information
        is transmitted or systems are communicating over insecure or unprotected networks,
        such as the Internet, public networks or non-agency controlled networks.
      implementation_groups:
      - Restricted/Sensitive - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.C.03
      name: 'Control -  All Classifications - Must [CID: 2091]'
      description: "Agencies MUST encrypt aggregated agency data using an approved\
        \ algorithm and protocol over insecure or unprotected networks such as the\
        \ Internet, public infrastructure or non-agency controlled networks when the\
        \ compromise of the aggregated data would present a significant impact to\
        \ the agency. \_"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.55.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:5
      ref_id: 17.1.55.C.04
      name: 'Control -  All Classifications - Should [CID: 2092]'
      description: Agencies SHOULD encrypt agency data using an approved algorithm
        and protocol if they wish to communicate over insecure or unprotected networks
        such as the Internet, public networks or non-agency controlled networks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: IT equipment using Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.56.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:6
      ref_id: 17.1.56.R.01
      description: "In general terms, when IT equipment employing encryption functionality\
        \ is turned on and authenticated all information becomes accessible to the\
        \ system user. \_At such a time the IT equipment will need to be handled in\
        \ accordance with the highest classification of information on the system.\
        \ \_Special technology architectures and implementations exist where accessibility\
        \ continues to be limited when first powered on. \_Agencies should consult\
        \ the GCSB for further advice on special architectures and implementations."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.56.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:6
      ref_id: 17.1.56.R.02
      description: "The classification of the equipment when powered off will depend\
        \ on the equipment type, cryptographic algorithms and protocols used and whether\
        \ cryptographic key has been removed. \_Agencies should consult the GCSB for\
        \ further advice on treatment of specific software, systems and IT equipment.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.56.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:6
      ref_id: 17.1.56.C.01
      name: 'Control -  All Classifications - Must [CID: 2096]'
      description: When IT equipment storing encrypted information is turned on and
        authenticated, it MUST be treated as per the original classification of the
        information.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.56.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:6
      ref_id: 17.1.56.C.02
      name: 'Control -  All Classifications - Must [CID: 2097]'
      description: Agencies MUST consult the GCSB for further advice on the powered
        off status and treatment of specific software, systems and IT equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Encrypting NZEO information in transit
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.57.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:7
      ref_id: 17.1.57.R.01
      description: NZEO information is particularly sensitive and requires additional
        protection. It must be encrypted when in transit.
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.57.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:7
      ref_id: 17.1.57.C.01
      name: 'Control -  All Classifications - Must [CID: 2100]'
      description: In addition to any encryption already in place for communication
        mediums, agencies MUST use an Approved Cryptographic Protocol and Algorithm
        to protect NZEO information when in transit.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.1:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4
      description: Key Refresh and Retirement
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.58.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:8
      ref_id: 17.1.58.R.01
      description: "All cryptographic keys have a limited useful life after which\
        \ the key should be replaced or retired. Typically the useful life of the\
        \ cryptographic key (cryptoperiod) is use, product and situation dependant.\
        \ Product guidance is the best source of information on establishing cryptoperiods\
        \ for individual products. A more practical control is the use of data, disk\
        \ or volume encryption where key changes are more easily managed. Selection\
        \ of cryptoperiods should be based on a risk assessment.\_Refer also to section\
        \ 17.9 \u2013 Key Management."
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.58.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:8
      ref_id: 17.1.58.C.01
      name: 'Control -  All Classifications - Should [CID: 2103]'
      description: 'Agencies SHOULD establish cryptoperiods for all keys and cryptographic
        implementations in their systems and operations. '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.58.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:8
      ref_id: 17.1.58.C.02
      name: 'Control -  All Classifications - Should [CID: 2104]'
      description: Agencies SHOULD use risk assessment techniques and guidance to
        establish cryptoperiods.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.1.58.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.1:4:8
      ref_id: 17.1.58.C.03
      name: 'Control -  All Classifications - Must [CID: 2105]'
      description: Agencies using HACE MUST consult the GCSB for key management requirements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.2'
      name: Approved Cryptographic Algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:1
      ref_id: 17.2.1
      description: "Information\_is protected by a properly implemented, Approved\
        \ Cryptographic Algorithm."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:1
      ref_id: 17.2.2
      description: This section covers cryptographic algorithms that the GCSB recognises
        as being approved for use within government. Implementations of the algorithms
        in this section need to have successfully completed an approved cryptographic
        evaluation before they can be approved to protect information. Correct implementations
        of cryptographic protocols are checked during system certification.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:1
      ref_id: 17.2.3
      description: "High assurance cryptographic are not covered in this section.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2
      description: Approved cryptographic algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.4
      description: "There is no guarantee or proof of security of an algorithm against\
        \ presently unknown attacks. \_However, the algorithms listed in this section\
        \ have been extensively scrutinised by government, industry and academic communities\
        \ in a practical and theoretical setting and have not been found to be susceptible\
        \ to any feasible attacks. \_There have been some cases where theoretically\
        \ impressive vulnerabilities have been found, however these results are not\
        \ considered to be feasible with current technologies and capabilities."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.5
      description: "Where there is a range of possible key sizes for an algorithm,\
        \ some of the smaller key sizes do not provide an adequate safety margin against\
        \ attacks that might be found in the future. \_For example, future advances\
        \ in number factorisation could render the use of smaller RSA moduli a security\
        \ vulnerability."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.6
      description: "The approved cryptographic algorithms fall into three categories:\
        \ asymmetric/public key algorithms, hashing algorithms and symmetric encryption\
        \ algorithms. \_Collectively these\_were known as SUITE B and were first promulgated\
        \ in 2006."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.7
      description: Suite B was superseded by the Commercial National Security Algorithm
        Suite in August 2015 and later supplemented by the Commercial Solutions for
        Classified (CSFC) Programme.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.8
      description: "Some algorithms that were previously approved in earlier versions\
        \ of the NZISM are now deprecated. These are still permitted to be used to\
        \ decrypt or verify previously encrypted or signed files.\_ These algorithms\
        \ are described as \u2018for legacy use only\u2019 in the NZISM."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.9
      description: 'The approved asymmetric/public key algorithms are:

        ECDH for agreeing on encryption session keys.

        ECDSA for digital signatures.

        DH for agreeing on encryption session keys. This should only be used for interoperability
        with third parties where ECDH is not supported.

        RSA for digital signatures and passing encryption session keys or similar
        keys.

        DSA for digital signatures for legacy use only.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.10
      description: 'The approved hashing algorithms are:

        Secure Hashing Algorithm 2; and

        Secure Hashing Algorithm 1 for legacy use only.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.11
      description: 'The approved symmetric encryption algorithms are:

        AES; and

        3DES for legacy use only.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.12
      description: SHA-1, 3DES and DSA MUST NOT be used for new implementations but
        are approved only for processing already protected information. These are
        legacy use only.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:2
      ref_id: 17.2.13
      description: "Summary Table\_\n\n\n\nFunction\n\n\nCryptographic algorithm or\
        \ protocol\n\n\nApplicable standards\n\n\nMinimum\n\n\n\n\nEncryption\n\n\n\
        Advanced Encryption Standard (AES)\n\n\nFIPS 197\n\n\n256-bit key\n\n\n\n\n\
        Hashing\n\n\nSecure Hash Algorithm (SHA)\n\n\nFIPS 180-4\n\n\nSHA-384\n(SHA-256\
        \ IN CONFIDENCE & BELOW only)\n\n\n\n\nDigital signature\n\n\nElliptic Curve\
        \ Digital Signature Algorithm (ECDSA)\n\n\nFIPS 186-3\n\n\nNIST P-384\n\n\n\
        \n\n\_\n\n\nRivest-Shamir-Adleman (RSA)\n\n\nNIST SP 800-56B Rev. 2\n\n\n\
        3072-bit key\n(2048-bit key in PKI)\n\n\n\n\nKey exchange\n\n\nElliptic Curve\
        \ Diffie-Hellman (ECDH)\n\n\nSP 800-56A ANSI X9.63\n\n\nNIST P-384\n\n\n\n\
        \_\n\nRivest-Shamir-Adleman\n\n\_\n\n3072-bit key\n\n\n\n\n\_\n\n\nDiffie-Helman\
        \ (DH)\n\n\nIETF RFC 3526 (Reference m)\n\n\n3072-bit key\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2
      description: Salting
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:3
      ref_id: 17.2.14
      description: "Salting is a technique of further modifying a hash by adding a\
        \ value or character string to the start or end of a password.\_ This improves\
        \ the resistance of the hash to brute-force attacks.\_ To further improve\
        \ resistance the salt should be cryptographically strong and randomly generated\
        \ as unique for each password."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:2:3
      ref_id: 17.2.15
      description: "The effectiveness of salts is reduced if implemented poorly.\_\
        \ Common implementation errors are salts that are too short and the reuse\
        \ of salts.\_ To implement credential-specific salts the following principles\
        \ should be followed:\nGeneration of a unique salt every time a stored credential\
        \ is created;\nGenerate salts as cryptographically strong random data;\nUse\
        \ a 32 or 64 bit salt as storage and system constraints permit;\nImplement\
        \ a security schema that is not dependent on hiding, splitting or otherwise\
        \ obfuscating the salt; and\nDo NOT apply salts per user or on a system wide\
        \ basis.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.16
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:3
      ref_id: 17.2.16
      description: "The following references are provided for the approved asymmetric/public\
        \ key algorithms, hashing algorithms and encryption algorithms. \_Note that\
        \ Federal Information Processing Standards (FIPS) are standards and guidelines\
        \ that are developed by the US National Institute of Standards and Technology\
        \ (NIST) for US Federal computer systems.\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\nW. Diffie and M. E. Hellman, \u201CNew Directions in Cryptography\u201D\
        \ \_IEEE Transactions on Information Theory, vol. 22, no. 6, pp. 644-654,\
        \ November 1976, doi: 10.1109/TIT.1976.1055638.\nIEEE\nhttps://ee.stanford.edu/~hellman/publications/24.pdf\
        \ [PDF, 2.1 MB]\n\n\nRFC 3447\n\nPKCS #1 Public Key Cryptography Standards\
        \ #1\nRSA Laboratories\n\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3447\n\
        \n\nRFC 8624\nAlgorithm Implementation Requirements and Usage Guidance for\
        \ DNSSECJune 2019\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc8624\n\n\
        \nRFC 3602\nThe AES-CBC Cipher Algorithm and Its Use with IPsecSeptember 2003\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc3602\n\n\nRFC 5288\nAES Galois\
        \ Counter Mode (GCM) Cipher Suites for TLSAugust 2008\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc5288\n\
        \n\nRFC 8492\nSecure Password Ciphersuites for Transport Layer Security (TLS)February\
        \ 2019\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc8492\n\n\nRFC 2898\n\
        PKCS #5: Password-Based Cryptography Specification Version 2.0September 2000\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc2898\n\n\nRFC 8018\nPKCS #5:\
        \ Password-Based Cryptography Specification Version 2.1January 2017\nIETF\n\
        https://datatracker.ietf.org/doc/html/rfc8018\n\n\nFIPS 186-4\nDigital Signature\
        \ Standard (DSS)July 2013\nNIST\nhttps://csrc.nist.gov/publications/detail/fips/186/4/final\n\
        \n\nFIPS 197\nAdvanced Encryption Standard (AES)November 2001\_This publication\
        \ is currently under review (10 June 2021)\nNIST\nhttps://csrc.nist.gov/publications/detail/fips/197/final\n\
        \n\n\_\nKey Management\nNIST\nhttps://csrc.nist.gov/projects/key-management/key-management-guidelines\n\
        \n\nSP 800-56A Rev. 3\nRecommendation for Pair-Wise Key-Establishment Schemes\
        \ Using Discrete Logarithm Cryptography\nNIST\n\nhttps://doi.org/10.6028/NIST.SP.800-56Ar3\n\
        Also ANSI x9.63 and ANSI X9.42\n\n\n\n\_\nKey Establishment\nNIST\n\nhttps://csrc.nist.gov/Projects/Key-Management/Key-Establishment\n\
        Also ANSI X9.63 and ANSI X9.42\n\n\n\nFIPS Pub 180-4\nSecure Hash Standard\
        \ (SHS)August 2015\nNIST\nFIPS 180-4, Secure Hash Standard (SHS) | CSRC (nist.gov)\n\
        \n\nSP 800-67 Rev. 2\nRecommendation for the Triple Data Encryption Algorithm\
        \ (TDEA) Block CipherNovember 2017\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-67/rev-2/final\n\
        \n\nFIPS 140-3\nSecurity Requirements for Cryptographic ModulesMarch 2019\n\
        NIST\nhttps://csrc.nist.gov/publications/detail/fips/140/3/final\n\n\nSP 800-56C\
        \ Rev. 2\nRecommendation for Key-Derivation Methods in Key-Establishment SchemesAugust\
        \ 2020\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-56c/rev-2/final\n\
        \n\n\_\nBlock Cipher Techniques\nNIST\nhttps://csrc.nist.gov/projects/block-cipher-techniques/bcm\n\
        \n\nSP 800-38D\nRecommendation for Block Cipher Modes of Operation: Galois/Counter\
        \ Mode (GCM) and GMACNovember 2007This publication is under review, August\
        \ 2021\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-38d/final\n\
        \n\n\_\nMcGrew, David A. and Viega, John (2005) \"The Galois/Counter Mode\
        \ of Operation (GCM)\"\nNIST\nhttps://csrc.nist.rip/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf\
        \ [PDF, 1 MB]\n\n\n\_\nCryptographic Algorithm Validation Program CAVP\nNIST\n\
        https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program\n\
        \n\nSP 800-38A\nRecommendation for Block Cipher Modes of Operation: Methods\
        \ and TechniquesDecember 2001This publication is under review (May 2021)\n\
        NIST\nhttps://csrc.nist.gov/publications/detail/sp/800-38a/final\n\n\nFIPS\
        \ 180-4\nSecure Hash Standard (SHS)August 2015\nNIST\nhttps://csrc.nist.gov/publications/detail/fips/180/4/final\n\
        \n\nSP 800-63\nDigital Identity Guidelines\nNIST\nhttps://pages.nist.gov/800-63-3/\n\
        \n\nSP 800-106\nRandomized Hashing for Digital SignaturesFebruary 2009\nNIST\n\
        https://csrc.nist.gov/publications/detail/sp/800-106/final\n\n\nSP 800-107\
        \ Rev. 1\nRecommendation for Applications Using Approved Hash AlgorithmsAugust\
        \ 2012This publication is under review (6 August 2021)\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-107/rev-1/final\n\
        \n\nSP 800-132\nRecommendation for Password-Based Key Derivation: Part 1:\
        \ Storage ApplicationsDecember 2021\nNIST\nhttps://csrc.nist.gov/publications/detail/sp/800-132/final\n\
        \n\n\_\nCommercial National Security Algorithm (CNSA) Suite\nNSA\nCSA_CNSA_2.0_ALGORITHMS_.PDF\
        \ (defense.gov)\n\n\n\_\nCommercial National Security Algorithm (CNSA) Suite\
        \ Factsheet\nNSA\n\nCSI_CNSA_2.0_FAQ_.PDF (defense.gov)\n\n\n\n\_\nCommercial\
        \ Solutions for Classified (CSfC) FAQ 2018\nNSA\nhttps://www.nsa.gov/Portals/70/documents/resources/everyone/csfc/csfc-faqs.pdf\
        \ [PDF, 1.15 MB]\n\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using Approved Cryptographic Algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:1
      ref_id: 17.2.17.R.01
      description: "Inappropriate configuration of a product using an Approved Cryptographic\
        \ Algorithm can inadvertently select relatively weak implementations of the\
        \ cryptographic algorithms. \_In combination with an assumed level of security\
        \ confidence, this can represent a significant security risk."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.17.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:1
      ref_id: 17.2.17.R.02
      description: "When configuring unevaluated products that implement an Approved\
        \ Cryptographic Algorithm, agencies should disable any non-approved algorithms.\_\
        \ Correct implementation of cryptographic protocols and disabling of non-approved\
        \ algorithms is checked during system certification.A less effective control\
        \ is to advise system users not to use them via a written policy.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:1
      ref_id: 17.2.17.C.01
      name: 'Control -  All Classifications - Must [CID: 2128]'
      description: Agencies MUST ensure that only Approved Cryptographic Algorithms
        can be used when using an unevaluated product that implements a combination
        of approved and non-approved Cryptographic Algorithms.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Approved asymmetric/public key algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:2
      ref_id: 17.2.18.R.01
      description: "Over the last decade DSA and DH cryptosystems have been subject\
        \ to increasingly successful sub-exponential factorisation and index-calculus\
        \ based attacks.\_ ECDH and ECDSA offer more security per bit increase in\
        \ key size than either DH or DSA and are considered more secure alternatives."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:2
      ref_id: 17.2.18.C.01
      name: 'Control -  All Classifications - Should [CID: 2131]'
      description: Agencies SHOULD use ECDH and ECDSA for all new systems, version
        upgrades and major system modifications.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using DH
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:3
      ref_id: 17.2.19.R.01
      description: "While ECDH should be used in preference to DH, there are instances\
        \ where DH is still in use.\_ A modulus of at least 3072 bits for DH is now\
        \ considered good practice by the cryptographic community."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:3
      ref_id: 17.2.19.C.01
      name: 'Control -  All Classifications - Must [CID: 2134]'
      description: Agencies using DH, for the approved use of agreeing on encryption
        session keys, MUST use a modulus of at least 3072 bits.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Equipment using DH
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:4
      ref_id: 17.2.20.R.01
      description: "If a network device is NOT able to support the required cryptographic\
        \ protocol, algorithm and key length, the system will be at risk of a cryptographic\
        \ compromise.\_ In such cases, the longest feasible key length must be implemented\
        \ and the device scheduled for replacement as a matter of urgency."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:4
      ref_id: 17.2.20.C.01
      name: 'Control -  All Classifications - Must [CID: 2137]'
      description: Devices which are NOT capable of implementing required key lengths
        MUST be reconfigured with the longest feasible key length as a matter of urgency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:4
      ref_id: 17.2.20.C.02
      name: 'Control -  All Classifications - Must [CID: 2138]'
      description: Devices which are NOT capable of implementing required key lengths
        MUST be scheduled for replacement as a matter of urgency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using DSA (for legacy use only)
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:5
      ref_id: 17.2.21.R.01
      description: A modulus of at least 1024 bits for DSA is considered good practice
        by the cryptographic community.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:5
      ref_id: 17.2.21.C.01
      name: 'Control -  All Classifications - Must [CID: 7189]'
      description: Agencies using DSA, for the approved use of digital signatures,
        MUST use a modulus of at least 1024 bits.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using ECDH
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:6
      ref_id: 17.2.22.R.01
      description: A field/key size of at least 384 bits for ECDH is now considered
        good practice by the cryptographic community.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:6
      ref_id: 17.2.22.C.01
      name: 'Control -  All Classifications - Must [CID: 2144]'
      description: Agencies using ECDH, for the approved use of agreeing on encryption
        session keys, MUST implement the curve P-384 (prime moduli).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.22.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:6
      ref_id: 17.2.22.C.02
      name: 'Control -  All Classifications - Must [CID: 2145]'
      description: "All VPN\u2019s using an ECDH key length less than 384 MUST replace\
        \ all Pre-Shared Keys with keys of at least 384 bits, as soon as possible."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using ECDSA
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:7
      ref_id: 17.2.23.R.01
      description: An equivalent symmetric key security strength of at least 160 bits
        for ECDSA is considered good practice by the cryptographic community. Not
        all legacy systems support a modulus of this length, in which case significant
        risk is being carried.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:7
      ref_id: 17.2.23.C.01
      name: 'Control -  All Classifications - Must [CID: 2148]'
      description: Agencies using ECDSA, for the approved use of digital signatures,
        MUST implement the curve P-384 (prime moduli).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Using RSA
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:8
      ref_id: 17.2.24.R.01
      description: A modulus of at least 3072 bits for RSA is considered good practice
        by the cryptographic community.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:8
      ref_id: 17.2.24.C.01
      name: 'Control -  All Classifications - Must [CID: 2151]'
      description: Agencies using RSA, for the approved use of digital signatures
        and passing encryption session keys or similar keys, MUST use a modulus of
        at least 3072 bits.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:8
      ref_id: 17.2.24.C.02
      name: 'Control -  All Classifications - Must [CID: 2152]'
      description: Agencies using RSA, for the approved use of digital signatures
        and passing encryption session keys or similar keys, MUST ensure that the
        public keys used for passing encrypted session keys are different to the keys
        used for digital signatures.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.24.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:8
      ref_id: 17.2.24.C.03
      name: 'Control -  All Classifications - Should [CID: 7181]'
      description: Agencies using RSA, for the approved use of digital signatures
        and passing encryption session keys or similar keys, SHOULD use a modulus
        of at least 4096 bits.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Public key infrastructure using RSA
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:9
      ref_id: 17.2.25.R.01
      description: A modulus of at least 2048 bits for RSA is considered good practice
        by the cryptographic community for use within X.509 based Public Key Infrastructure
        (PKI) systems.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:9
      ref_id: 17.2.25.C.01
      name: 'Control -  All Classifications - Must [CID: 7186]'
      description: Agencies using RSA keys within internet X.509 Public Key Infrastructure
        certificates MUST use a modulus of at least 2048 bits.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Approved hashing algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      ref_id: 17.2.26.R.01
      description: "Recent research conducted by cryptographic community suggests\
        \ that SHA-1 may be susceptible to collision attacks. \_While no practical\
        \ collision attacks have been published for SHA-1, they may become feasible\
        \ in the near future."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.26.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      ref_id: 17.2.26.R.02
      description: SHA-1 has been deprecated and the use of SHA-1 is permitted ONLY
        for legacy systems to validate existing hashes previously generated using
        SHA-1.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      ref_id: 17.2.26.C.01
      name: 'Control -  All Classifications - Must [CID: 2155]'
      description: Agencies MUST use the SHA-2 family for new systems. Use of SHA-1
        is permitted ONLY for legacy systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      ref_id: 17.2.26.C.02
      name: 'Control -  All Classifications - Must [CID: 5905]'
      description: Agencies MUST use a minimum of SHA-384 when using hashing algorithms
        to provide integrity protection for information classified as RESTRICTED/SENSITIVE
        or above.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.26.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:10
      ref_id: 17.2.26.C.03
      name: 'Control -  All Classifications - Must [CID: 7187]'
      description: In all other cases when information requires integrity protection
        using hashing algorithms, Agencies MUST use a minimum of SHA-256.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Salts
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      ref_id: 17.2.27.R.01
      description: The use of salts strengthens the resistance of hash values to a
        variety of attacks, including brute-force, rainbow table, dictionary and lookup
        table attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.27.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      ref_id: 17.2.27.R.02
      description: "Key derivation functions use a password, a salt, then generate\
        \ a password hash.\_ Their purpose is to make password guessing by an attacker\
        \ who has obtained a password hash file expensive and therefore the cost of\
        \ a guessing attack high and prohibitive."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      ref_id: 17.2.27.C.01
      name: 'Control -  All Classifications - Must [CID: 6560]'
      description: Memorised secrets such as passwords MUST be stored in a form that
        is resistant to offline attacks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.27.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      ref_id: 17.2.27.C.02
      name: 'Control -  All Classifications - Should [CID: 6561]'
      description: Memorised secrets such as passwords SHOULD be salted and hashed
        using a suitable one-way key derivation function. See 17.2.14.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.27.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:11
      ref_id: 17.2.27.C.03
      name: 'Control -  All Classifications - Should [CID: 6562]'
      description: The salt SHOULD be at least 32 bits in length, be chosen arbitrarily,
        and each instance is unique so as to minimise salt value collisions among
        stored hashes.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.2:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4
      description: Approved symmetric encryption algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:12
      ref_id: 17.2.28.R.01
      description: "The use of Electronic Code Book (ECB) mode in block ciphers allows\
        \ repeated patterns in plaintext to appear as repeated patterns in the ciphertext.\
        \ \_Most cleartext, including written language and formatted files, contains\
        \ significant repeated patterns. \_An attacker can use this to deduce possible\
        \ meanings of ciphertext by comparison with previously intercepted data. \_\
        In other cases they might be able to determine information about the key by\
        \ inferring certain contents of the cleartext. \_The use of other modes such\
        \ as Cipher Block Chaining, Cipher Feedback, Output Feedback or Counter prevents\
        \ such attacks."
    - urn: urn:defend:risk:req_node:nzism-v3:17.2.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.2:4:12
      ref_id: 17.2.28.C.01
      name: 'Control -  All Classifications - Should Not [CID: 2158]'
      description: Agencies using approved symmetric encryption algorithms (e.g. AES)
        SHOULD NOT use Electronic Code Book (ECB) mode.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:17.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.3'
      name: Approved Cryptographic Protocols
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:1
      ref_id: 17.3.1
      description: Classified information in transit is protected by an Approved Cryptographic
        Protocol implementing an Approved Cryptographic Algorithm.
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2:1
      ref_id: 17.3.2
      description: "This section covers information on the cryptographic protocols\
        \ that the GCSB recognises as being approved for use within government. \_\
        Implementations of the protocols in this section need to have successfully\
        \ completed a GCSB recognised cryptographic evaluation before they can be\
        \ approved for implementation."
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2:1
      ref_id: 17.3.3
      description: High assurance cryptographic protocols are not covered in this
        section.
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2
      description: Approved cryptographic protocols
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2:2
      ref_id: 17.3.4
      description: "In general, the GCSB only recognises the use of cryptographic\
        \ products that have passed a formal evaluation. \_However, the GCSB may approve\
        \ the use of some commonly available cryptographic protocols even though their\
        \ implementations within specific products have not been formally evaluated.\
        \ \_This approval is limited to cases where they are used in accordance with\
        \ the requirements in this manual."
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:2:2
      ref_id: 17.3.5
      description: 'The Approved Cryptographic Protocols are:

        TLS;

        SSH;

        S/MIME;

        OpenPGP Message Format; and

        IPSec.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:3
      description: Using Approved Cryptographic Protocols
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:3:1
      ref_id: 17.3.6.R.01
      description: "If a product implementing an Approved Cryptographic Protocol has\
        \ been inappropriately configured, it is possible that relatively weak cryptographic\
        \ algorithms or implementations could be inadvertently selected. \_In combination\
        \ with an assumed level of security confidence, this can represent a significant\
        \ level of security risk."
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:3:1
      ref_id: 17.3.6.R.02
      description: "When configuring unevaluated products that implement an Approved\
        \ Cryptographic Protocol, agencies can ensure that only the Approved Cryptographic\
        \ Algorithm can be used by disabling the unapproved algorithms within the\
        \ products (which is preferred). \_Alternatively a policy can be put in place\
        \ to advise system users not to use the non-approved algorithms."
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.6.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:3:1
      ref_id: 17.3.6.R.03
      description: 'While many Approved Cryptographic Protocols support authentication,
        agencies should be aware that these authentication mechanisms are not foolproof.
        To be effective, these mechanisms MUST be securely implemented and protected.
        This can be achieved by:

        providing an assurance of private key protection;

        ensuring the correct management of certificate authentication processes including
        certificate revocation checking; and

        using a legitimate identity registration scheme.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.3:3:1
      ref_id: 17.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 2520]'
      description: Agencies using a product that implements an Approved Cryptographic
        Protocol MUST ensure that only Approved Cryptographic Protocols can be used.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.4'
      name: Transport Layer Security
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:1
      ref_id: 17.4.1
      description: Transport Layer Security is implemented correctly as an approved
        protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:1
      ref_id: 17.4.2
      description: "This section covers the conditions under which TLS can be used\
        \ as an approved cryptographic protocols. \_Additionally, as File Transfer\
        \ Protocol over SSL is built on SSL/TLS, it is also considered within scope."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:1
      ref_id: 17.4.3
      description: When using a product that implements TLS, requirements for using
        approved cryptographic protocols will also need to be referenced in the Section
        17.3 - Approved Cryptographic Protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:1
      ref_id: 17.4.4
      description: Further information on handling TLS traffic through gateways can
        be found in Section 14.3 - Web Applications.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.5
      description: "Secure Sockets Layer (SSL), and Transport Layer Security (TLS)\
        \ are cryptographic protocols designed to provide communication security when\
        \ using the Internet. \_They use X.509 certificates and asymmetric cryptography\
        \ for authentication purposes. \_This generates a session key. \_This session\
        \ key is then used to encrypt data between the parties."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.6
      description: Encryption with the session key provides data and message confidentiality,
        and message authentication codes for message integrity.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.7
      description: Several versions of the SSL and TLS protocols are in widespread
        use in applications such as web browsing, electronic mail, Internet faxing,
        instant messaging, and voice-over-IP (VoIP).
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.8
      description: Although common usage has been to use the terms TLS and SSL interchangeably,
        they are distinct protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.9
      description: "TLS is an Internet Engineering Task Force (IETF) protocol, first\
        \ defined in 1999, updated in RFC 5246 (August 2008) and RFC 6176 (March 2011).\
        \ \_It is based on the earlier SSL specifications (1994, 1995, 1996) developed\
        \ by Netscape Communications for adding the HTTPS protocol to their Navigator\
        \ web browser. \_A draft of TLS 1.3 was released in October 2014, with a definitive\
        \ version issued in 2018."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:2
      ref_id: 17.4.10
      description: Microsoft announced in October 2014 that that it will disable Secure
        Sockets Layer (SSL) 3.0 support in its Internet Explorer browser and in its
        Online Services, from Dec. 1, 2014.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2
      description: SSL 3.0 Vulnerability
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:3
      ref_id: 17.4.11
      description: "A design vulnerability has been found in the way SSL 3.0 handles\
        \ block cipher mode padding. \_The Padding Oracle On Downgraded Legacy Encryption\
        \ (POODLE) attack demonstrates how an attacker can exploit this vulnerability\
        \ to decrypt and extract information from an encrypted transaction."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:3
      ref_id: 17.4.12
      description: "The POODLE attack demonstrates this vulnerability using web browsers\
        \ and web servers, which is one of the most likely exploitation scenarios.\
        \ \_All systems and applications utilizing the Secure Socket Layer (SSL) 3.0\
        \ with cipher-block chaining (CBC) mode ciphers may be vulnerable."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2
      description: SSL Superseded
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:4
      ref_id: 17.4.13
      description: "SSL is now superseded by TLS, with the latest version being TLS\
        \ 1.3 which was released in August 2018. \_This is largely because of security\
        \ flaws in the older SSL protocols."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:2:4
      ref_id: 17.4.14
      description: Accordingly SSL is no longer an approved cryptographic protocol
        and it SHOULD be replaced by TLS.
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:3
      ref_id: 17.4.15
      description: "Further information on SSL and TLS can be found at:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\n\_\nThe SSL 3.0 specification\nIETF\nhttps://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00\n\
        \n\n\_RFC5246\nThe TLS 1.2 specification\nIETF\n\nhttps://tools.ietf.org/html/rfc5246\n\
        \n\n\n\_RFC6176\nThe SSL 2.0 prohibition\nIETF\n\nhttps://tools.ietf.org/html/rfc6176\n\
        \n\n\n\_RFC8446\n\nThe Transport Layer Security (TLS) Protocol Version 1.3\n\
        \nIETF\n\nhttps://tools.ietf.org/html/rfc8446\_\_\_\n\n\n\n\_\nVulnerability\
        \ Summary for CVE-2014-3566\nNIST\nhttp://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566\n\
        \n\n\_TA14-290A\nAlert (TA14-290A) - SSL 3.0 Protocol Vulnerability and POODLE\
        \ Attack\nUS-CERT\n\nhttps://www.us-cert.gov/ncas/alerts/TA14-290A\n\n\n\n\
        \_\nThis POODLE Bites: Exploiting The SSL 3.0 Fallback\n\nGoogleSeptember\
        \ 2014\n\n\nhttp://www.openssl.org/~bodo/ssl-poodle.pdf [PDF, 213 KB]\n\n\n\
        \n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:4
      description: Using TLS
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:4:1
      ref_id: 17.4.16.R.01
      description: "Whilst version 1.0 of SSL was never released, version 2.0 had\
        \ significant security flaws leading to the development of SSL 3.0. \_SSL\
        \ has since been superseded by TLS with the latest version being TLS 1.3 which\
        \ was released in August 2018. SSL is no longer an approved cryptographic\
        \ protocol."
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:4:1
      ref_id: 17.4.16.C.01
      name: 'Control -  All Classifications - Should [CID: 2598]'
      description: Agencies SHOULD use the current version of TLS (version 1.3).
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.4.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.4:4:1
      ref_id: 17.4.16.C.02
      name: 'Control -  All Classifications - Should Not [CID: 2600]'
      description: Agencies SHOULD NOT use any version of SSL.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:17.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.5'
      name: Secure Shell
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:1
      ref_id: 17.5.1
      description: "Secure Shell (SSH) is implemented correctly as an\_Approved\_\
        Cryptographic Protocol."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:2:1
      ref_id: 17.5.2
      description: SSH is software based on the Secure Shell protocol and enables
        a connection to a remote system.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:2:1
      ref_id: 17.5.3
      description: "This section covers information on the conditions under which\
        \ commercial and open-source implementations of SSH can be used as an approved\
        \ cryptographic protocol. \_Additionally, secure copy and Secure File Transfer\
        \ Protocol use SSH and are therefore also covered by this section."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:2:1
      ref_id: 17.5.4
      description: When using a product that implements SSH, requirements for using
        approved cryptographic protocols will also need to be referenced from the
        Section 17. 3 - Approved Cryptographic Protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:3
      ref_id: 17.5.5
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\nFurther information on SSH can be found in the SSH specification\n\
        \nIETF\n\nhttps://www.rfc-editor.org/rfc/rfc4252\n\n\n\n\_\n\nFurther information\
        \ on Open SSH\n\n\nOpen SSH\n\n\nhttps://www.openssh.com/\n\n\n\n\_\n\nOpenSSH\
        \ 7.3\n\n\nOpen SSH\n\n\nhttp://www.openssh.com/txt/release-7.3\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      description: Using SSH
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.R.01
      description: "The configuration directives provided are based on the OpenSSH\
        \ implementation of SSH. \_Agencies implementing SSH will need to adapt these\
        \ settings to suit other SSH implementations."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.R.02
      description: "SSH version 1 is known to have vulnerabilities. \_In particular,\
        \ it is susceptible to an adversary-in-the-middle attack, where an attacker\
        \ who can intercept the protocol in each direction can make each node believe\
        \ they are talking to the other. \_SSH version 2 does not have this vulnerability."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.R.03
      description: "SSH has the ability to forward connections and access privileges\
        \ in a variety of ways. \_This means that an attacker who can exploit any\
        \ of these features can gain unauthorised access to a potentially large amount\
        \ of classified information."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.R.04
      description: "Host-based authentication requires no credentials (password, public\
        \ key etc.) to authenticate although in some cases a host key can be used.\
        \ \_This renders SSH vulnerable to an IP spoofing attack."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.R.05
      description: "An attacker who gains access to a system with system administrator\
        \ privileges will have the ability to not only access classified information\
        \ but to control that system completely. \_Given the clearly more serious\
        \ consequences of this, system administrator login or administrator privilege\
        \ escalation SHOULD NOT be permitted."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:1
      ref_id: 17.5.6.C.01
      name: 'Control -  All Classifications - Should [CID: 2647]'
      description: "The table below outlines the settings that SHOULD be implemented\
        \ when using SSH.\n\n\n\nConfiguration description\n\n\nConfiguration directive\n\
        \n\n\n\nDisallow the use of SSH version 1\n\n\nProtocol 2\n\n\n\n\nOn machines\
        \ with multiple interfaces, configure the SSH daemon to listen only on the\
        \ required interfaces\n\nListenAddress xxx.xxx.xxx.xxx\n\n\n\nDisable connection\
        \ forwarding\n\n\nAllowTCPForwarding no\n\n\n\n\nDisable gateway ports\n\n\
        \nGatewayports no\n\n\n\n\nDisable the ability to login directly as root\n\
        \n\nPermitRootLogin no\n\n\n\n\nDisable host-based authentication\n\n\nHostbasedAuthentication\
        \ no\n\n\n\n\nDisable rhosts-based authentication\n\n\nRhostsAuthentication\
        \ noIgnoreRhosts yes\n\n\n\n\nDo not allow empty passwords\n\nPermitEmptyPasswords\
        \ no\n\n\nConfigure a suitable login banner\nBanner/directory/filename\n\n\
        \nConfigure a login authentication timeout of no more than 60 seconds\nLoginGraceTime\
        \ xx\n\n\nDisable X forwarding\_\nX11Forwarding no\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      description: Authentication mechanisms
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:2
      ref_id: 17.5.7.R.01
      description: "Public key-based systems have greater potential for strong authentication,\
        \ put simply, people are not able to remember particularly strong passwords.\
        \ \_Password-based authentication schemes are also more susceptible to interception\
        \ than public key-based authentication schemes."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:2
      ref_id: 17.5.7.R.02
      description: Passwords are more susceptible to guessing attacks, so if passwords
        are used in a system then countermeasures should be put into place to reduce
        the chance of a successful brute force attack.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:2
      ref_id: 17.5.7.C.01
      name: 'Control -  All Classifications - Should [CID: 2672]'
      description: Agencies SHOULD use public key-based authentication before using
        password-based authentication.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:2
      ref_id: 17.5.7.C.02
      name: 'Control -  All Classifications - Should [CID: 2673]'
      description: Agencies that allow password authentication SHOULD use techniques
        to block brute force attacks against the password.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      description: Automated remote access
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.R.01
      description: If password-less authentication is enabled, allowing access from
        unknown IP addresses would allow untrusted parties to automatically authenticate
        to systems without needing to know the password.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.R.02
      description: If port forwarding is not disabled or it is not configured securely,
        an attacker may be able to gain access to forwarded ports and thereby create
        a communication channel between the attacker and the host.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.R.03
      description: If agent credential forwarding is enabled, an intruder could connect
        to the stored authentication credentials and then use them to connect to other
        trusted hosts or even intranet hosts, if port forwarding has been allowed
        as well.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.R.04
      description: "X11 is a computer software system and network protocol that provides\
        \ a graphical user interface for networked computers. \_Failing to disable\
        \ X11 display remoting could result in an attacker being able to gain control\
        \ of the computer displays as well as keyboard and mouse control functions."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.R.05
      description: Allowing console access permits every user who logs into the console
        to run programs that are normally restricted to the root user.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.C.01
      name: 'Control -  All Classifications - Should [CID: 2725]'
      description: "Agencies SHOULD use parameter checking when using the \u2018forced\
        \ command\u2019 option."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.C.02
      name: 'Control -  All Classifications - Should [CID: 2726]'
      description: 'Agencies that use logins without a password for automated purposes
        SHOULD disable:

        access from IP addresses that do not need access;

        port forwarding;

        agent credential forwarding;

        X11 display remoting; and

        console access.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:3
      ref_id: 17.5.8.C.03
      name: 'Control -  All Classifications - Should [CID: 2727]'
      description: "Agencies that use remote access without the use of a password\
        \ SHOULD use the \u2018forced command\u2019 option to specify what command\
        \ is executed."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      description: SSH-agent
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:4
      ref_id: 17.5.9.R.01
      description: "SSH-agent or other similar key caching programs hold and manage\
        \ private keys stored on workstations and respond to requests from remote\
        \ systems to verify these keys. \_When an SSH-agent launches, it will request\
        \ the user\u2019s password. \_This password is used to unlock the user\u2019\
        s private key. \_Subsequent access to remote systems is performed by the agent\
        \ and does not require the user to re-enter their password. \_Screenlocks\
        \ and expiring key caches ensure that the user\u2019s private key is not left\
        \ unlocked for long periods of time."
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:4
      ref_id: 17.5.9.R.02
      description: Agent credential forwarding is required when multiple SSH connections
        are chained to allow each system in the chain to authenticate the user.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:4
      ref_id: 17.5.9.C.01
      name: 'Control -  All Classifications - Should [CID: 2737]'
      description: 'Agencies that use SSH-agent or other similar key caching programs
        SHOULD:

        only use the software on workstation and servers with screenlocks;

        ensure that the key cache expires within four hours of inactivity; and

        ensure that agent credential forwarding is used when multiple SSH traversal
        is needed.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.5:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4
      description: SSH-Versions
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:5
      ref_id: 17.5.10.R.01
      description: Older versions contain known vulnerabilities which are regularly
        addressed or corrected by newer versions.
    - urn: urn:defend:risk:req_node:nzism-v3:17.5.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.5:4:5
      ref_id: 17.5.10.C.01
      name: 'Control -  All Classifications - Should [CID: 2740]'
      description: Agencies SHOULD ensure that the latest implementation of SSH software
        is being used. Older versions contain known vulnerabilities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.6'
      name: Secure Multipurpose Internet Mail Extension
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:1
      ref_id: 17.6.1
      description: Secure Multipurpose Internal Mail Extension (S/MIME) is implemented
        correctly as an approved cryptographic protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:2:1
      ref_id: 17.6.2
      description: This section covers information on the conditions under which S/MIME
        can be used as an approved cryptographic protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:2:1
      ref_id: 17.6.3
      description: When using a product that implements S/MIME, requirements for using
        approved cryptographic protocols will also need to be referenced from Section
        17.3 - Approved Cryptographic Protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:2:1
      ref_id: 17.6.4
      description: Information relating to the development of password selection policies
        and password requirements can be found in Section 16.1 - Identification and
        Authentication.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:3
      ref_id: 17.6.5
      description: "Further information on S/MIME can be found at:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\n\_\n\nSecure/Multipurpose Internet Mail Extensions\
        \ (S/MIME) Version 3.2 Message Specification\n\nIETF\n\nhttps://datatracker.ietf.org/doc/html/rfc5751\n\
        \n\n\nSP 800-57\nRecommendations for Key Management\n\_NIST\n\_https://csrc.nist.gov/publications/sp\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4
      description: Decommissioning
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:1
      ref_id: 17.6.6.R.01
      description: Decommissioning MUST ensure any remanent cryptographic data is
        destroyed or unrecoverable.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:1
      ref_id: 17.6.6.C.01
      name: 'Control -  All Classifications - Must [CID: 2769]'
      description: "Decommissioning of faulty or redundant equipment MUST comply with\
        \ media sanitisation requirements described in Chapter 12 \u2013 Product Security."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.6:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4
      description: Using S/MIME
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:2
      ref_id: 17.6.7.R.01
      description: "S/MIME 2.0 used weaker cryptography (40-bit keys) than is approved\
        \ for use by the government. \_Version 3.0 was the first version to become\
        \ an Internet Engineering Taskforce (IETF) standard."
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:2
      ref_id: 17.6.7.R.02
      description: Agencies choosing to implement S/MIME should be aware of the inability
        of many content filters to inspect encrypted messages and any attachments
        for inappropriate content, and for server-based antivirus software to scan
        for viruses and other malicious code.
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.7.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:2
      ref_id: 17.6.7.R.03
      description: "Improper decommissioning and sanitisation presents opportunities\
        \ for harvesting Private Keys. \_Products that hosted multiple Private Keys\
        \ for the management of multiple identities should be considered points of\
        \ aggregation with an increased \u201Ctarget value\u201D. \_Where cloud based\
        \ computing services have been employed, media sanitisation may be problematic\
        \ and require the revocation and re-issue of new keys."
    - urn: urn:defend:risk:req_node:nzism-v3:17.6.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.6:4:2
      ref_id: 17.6.7.C.01
      name: 'Control -  All Classifications - Must Not [CID: 2780]'
      description: Agencies MUST NOT allow versions of S/MIME earlier than 3.0 to
        be used.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:17.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.7'
      name: OpenPGP Message Format
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:1
      ref_id: 17.7.1
      description: OpenPGP Message Format is implemented correctly as an Approved
        Cryptographic Protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:2:1
      ref_id: 17.7.2
      description: "This section covers information on the conditions under which\
        \ the OpenPGP Message Format can be used as an approved cryptographic protocol.\
        \ \_It applies to the protocol as specified in IETF\u2019s RFC 2440 and RFC\
        \ 4880, which supersedes RFC 2440."
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:2:1
      ref_id: 17.7.3
      description: When using a product that implements the OpenPGP Message Format,
        requirements for using approved cryptographic protocols will also need to
        be referenced from the Section 17.3 - Approved Cryptographic Protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:2:1
      ref_id: 17.7.4
      description: Information relating to the development of password selection policies
        and password requirements can be found in the Section 16.1 - Identification
        and Authentication.
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:3
      ref_id: 17.7.5
      description: "Further information on the OpenPGP Message Format can be found\
        \ at:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_RFC 4880\n\nOpenPGP\
        \ Message Format specification\n\nIETF\n\nhttps://datatracker.ietf.org/doc/html/rfc4880\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.7:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:4
      description: Using OpenPGP Message Format
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:4:1
      ref_id: 17.7.6.R.01
      description: "If the private certificate and associated key used for encrypting\
        \ messages is suspected of being compromised i.e. stolen, lost or transmitted\
        \ over the Internet, then no assurance can be placed in the integrity of subsequent\
        \ messages that are signed by that private key. \_Likewise no assurance can\
        \ be placed in the confidentiality of a message encrypted using the public\
        \ key as third parties could intercept the message and decrypt it using the\
        \ private key."
    - urn: urn:defend:risk:req_node:nzism-v3:17.7.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.7:4:1
      ref_id: 17.7.6.C.01
      name: 'Control -  All Classifications - Must [CID: 2806]'
      description: Agencies MUST immediately revoke key pairs when a private certificate
        is suspected of being compromised or leaves the control of the agency.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.8
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.8'
      name: Internet Protocol Security (IPSec)
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:1
      ref_id: 17.8.1
      description: Internet Protocol Security (IPSec) is correctly implemented.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:1
      ref_id: 17.8.2
      description: This section covers information on the conditions under which IPSec
        can be used as an Approved Cryptographic Protocol.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:1
      ref_id: 17.8.3
      description: When using a product that implements IPSec, requirements for using
        approved cryptographic protocols will also need to be referenced from Section
        17.3 Approved Cryptographic Protocols.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: Modes of operation
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:2
      ref_id: 17.8.4
      description: 'IPSec can be operated in two modes: transport mode or tunnel mode.'
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: Cryptographic algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:3
      ref_id: 17.8.5
      description: "Most IPSec implementations can accommodate a number of cryptographic\
        \ algorithms for encrypting data when the Encapsulating Security Payload (ESP)\
        \ protocol is used. \_These include 3DES and AES."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: Key exchange
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:4
      ref_id: 17.8.6
      description: "Most IPSec implementations facilitate a number of methods for\
        \ sharing keying material used in hashing and encryption processes. \_Two\
        \ common methods are manual keying and IKE using the ISAKMP. \_Both methods\
        \ are considered suitable for use."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: ISAKMP authentication
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:5
      ref_id: 17.8.7
      description: "Most IPSec implementations can select from a number of methods\
        \ for authentication as part of ISAKMP. \_These can include digital certificates,\
        \ encrypted nonces or pre-shared keys. \_All these methods are considered\
        \ suitable for use."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2
      description: ISAKMP modes
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:2:6
      ref_id: 17.8.8
      description: "ISAKMP uses two modes to exchange information as part of IKE.\
        \ \_These are main mode and aggressive mode."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:3
      ref_id: 17.8.9
      description: 'Further information on IPSec can be found at:



        Reference

        Title

        Publisher

        Source




        RFC 2401



        Security Architecture for the IP overview


        IETF

        https://datatracker.ietf.org/doc/html/rfc2401




        NIST 800-77 Rev. 1



        Guide to IPSec VPNs, June 2020


        NIST

        https://csrc.nist.gov/publications/detail/sp/800-77/rev-1/final



        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: Mode of operation
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:1
      ref_id: 17.8.10.R.01
      description: The tunnel mode of operation provides full encapsulation of IP
        packets whilst the transport mode of operation only encapsulates the payload
        of the IP packet.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:1
      ref_id: 17.8.10.C.01
      name: 'Control -  All Classifications - Should [CID: 2842]'
      description: Agencies SHOULD use tunnel mode for IPSec connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:1
      ref_id: 17.8.10.C.02
      name: 'Control -  All Classifications - Should [CID: 2843]'
      description: Agencies choosing to use transport mode SHOULD additionally use
        an IP tunnel for IPSec connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: Protocol
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:2
      ref_id: 17.8.11.R.01
      description: "In order to provide a secure VPN style connection both authentication\
        \ and encryption are needed. \_ESP is the only way of providing encryption\
        \ yet Authentication Header (AH) and ESP can provide authentication for the\
        \ entire IP packet and the payload respectively. \_ESP is generally preferred\
        \ for authentication though as AH has inherent network address translation\
        \ limitations."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:2
      ref_id: 17.8.11.R.02
      description: If however, maximum security is desired at the expense of network
        address translation functionality, then ESP can be wrapped inside of AH which
        will then authenticate the entire IP packet and not just the encrypted payload.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:2
      ref_id: 17.8.11.C.01
      name: 'Control -  All Classifications - Should [CID: 2847]'
      description: Agencies SHOULD use the ESP protocol for IPSec connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: ISAKMP modes
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:3
      ref_id: 17.8.12.R.01
      description: Using main mode instead of aggressive mode provides greater security
        since all exchanges are protected.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:3
      ref_id: 17.8.12.C.01
      name: 'Control -  All Classifications - Should [CID: 2850]'
      description: Agencies using ISAKMP SHOULD disable aggressive mode for IKE.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: Security association lifetimes
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:4
      ref_id: 17.8.13.R.01
      description: Using a secure association lifetime of four hours or 14400 seconds
        provides a balance between security and usability.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:4
      ref_id: 17.8.13.C.01
      name: 'Control -  All Classifications - Should [CID: 2853]'
      description: Agencies SHOULD use a security association lifetime of four hours
        or 14400 seconds, or less.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: HMAC algorithms
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:5
      ref_id: 17.8.14.R.01
      description: "MD5 and SHA-1 are no longer approved Cryptographic Protocols.\
        \ \_The approved algorithms that can be used with HMAC are HMAC-SHA256, HMAC-SHA384\
        \ and HMAC-SHA512."
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:5
      ref_id: 17.8.14.C.01
      name: 'Control -  All Classifications - Should [CID: 2856]'
      description: Agencies SHOULD use HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512 as
        the HMAC algorithm.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: DH groups
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:6
      ref_id: 17.8.15.R.01
      description: Using a larger DH group provides more entropy for the key exchange.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:6
      ref_id: 17.8.15.C.01
      name: 'Control -  All Classifications - Should [CID: 2859]'
      description: Agencies SHOULD use the largest modulus size available for the
        DH exchange.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: Perfect Forward Secrecy
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:7
      ref_id: 17.8.16.R.01
      description: Using Perfect Forward Secrecy reduces the impact of the compromise
        of a security association.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:7
      ref_id: 17.8.16.C.01
      name: 'Control -  All Classifications - Should [CID: 2862]'
      description: Agencies SHOULD use Perfect Forward Secrecy for IPSec connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.8:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4
      description: IKE Extended Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:8
      ref_id: 17.8.17.R.01
      description: XAUTH using IKEv1 has documented vulnerabilities associated with
        its use.
    - urn: urn:defend:risk:req_node:nzism-v3:17.8.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.8:4:8
      ref_id: 17.8.17.C.01
      name: 'Control -  All Classifications - Should [CID: 2865]'
      description: Agencies SHOULD disable the use of XAUTH for IPSec connections
        using IKEv1.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.9'
      name: Key Management
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:1
      ref_id: 17.9.1
      description: Cryptographic keying material is protected by key management procedures.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      ref_id: 17.9.2
      description: This section covers information relating to the general management
        of cryptographic system material. Detailed key management guidance is not
        provided in this manual as there is a wide variety of cryptographic systems
        and technologies available, and there are varied security risks for each.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      ref_id: 17.9.3
      description: If High Assurance Cryptographic Equipment is being used agencies
        are required to comply with the NZCSI standards. This is outside of the scope
        of this section.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      ref_id: 17.9.4
      description: In a cloud environment, options for the management of cryptographic
        keys include on premises key generation and outsourcing the control of cryptographic
        keys to a cloud service provider.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      ref_id: 17.9.5
      description: "A number of key management offerings, such as Hold Your Own Keys\
        \ (HYOK), Bring Your Own Keys (BYOK), and Control Your Own Keys (CYOK), are\
        \ available. However, the implementation and role designations often vary\
        \ widely. As such, a single agreed definition of each may not always be practical\
        \ or helpful when considering which key management option is most suited to\
        \ an agency\u2019s requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:1
      ref_id: 17.9.6
      description: When considering key management options agencies need to consider
        the ownership, control, and possession aspects relating to cryptographic keys,
        and how these may impact security and business outcomes.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Applicability for cryptographic systems
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:2
      ref_id: 17.9.7
      description: "In general, the requirements specified in the NZISM apply equally\
        \ to cryptographic systems. \_Where the requirements for cryptographic systems\
        \ are different, the variations are contained in this section, and take precedence\
        \ over requirements specified elsewhere in the NZISM."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.8
      description: Encryption is an unparalleled technology for the protection of
        information, but it relies on the strength of the algorithm, the strength
        of the key and, most importantly, strong key management.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.9
      description: 'All encryption has four important characteristics:


        the value of the data to be protected and the level of protection required
        to protect it,

        the algorithm used to encrypt the data,

        the protocol used to apply the algorithm, and

        the encryption key.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.10
      description: "In almost all cases the algorithm is in the public domain and\
        \ is not a secret. \_When an encryption algorithm is publicly available, security\
        \ rests entirely on the secrecy of the encryption key. \_It is also true that\
        \ the effectiveness of most encryption systems depends on the secrecy of the\
        \ encryption key. \_Approved Cryptographic Algorithms are described in Section\
        \ 17.2. and Approved Cryptographic Protocols (applying the algorithms) are\
        \ described in Section 17.3. \_These sections also specify key strengths to\
        \ resist attempts to compromise the key through cryptanalysis."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.11
      description: "While any algorithm can, theoretically, be broken through cryptanalysis,\
        \ this may require the use of vast computing power and other resources, making\
        \ this approach infeasible. \_If, however, the encryption key is compromised,\
        \ there is no need to attack the algorithm itself. \_Attacks on encryption\
        \ systems will likely target the weakest point, most frequently these are\
        \ the safeguards that are used to protection the key. \_Attempts to compromise\
        \ keys and key management are more likely and more efficient than attacks\
        \ on the algorithm itself. \_This is why strong key management is vital in\
        \ order to protect the encryption key and keep the key secure and secret.\
        \ \_When key management fails, cryptographic security is compromised."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.12
      description: Almost all internet security protocols use cryptography for authentication,
        integrity, confidentiality, and non-repudiation. It is vital that good key
        management is implemented if these security protocols are to be protected,
        considered reliable, and provide required levels of assurance to organisations
        and users.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:3
      ref_id: 17.9.13
      description: In some cases, trusted third-party key management service providers
        furnish assistance to agencies in the generation, storage, operation, management,
        and retirement of keys associated with the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Key management
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:4
      ref_id: 17.9.14
      description: "For encryption to be used effectively, the encryption keys must\
        \ be managed and protected with the same care and security as the data originally\
        \ encrypted, as long as the same key is being used to decrypt or recover data.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:4
      ref_id: 17.9.15
      description: "Key management encompasses the operations and tasks necessary\
        \ to create, protect, and control the use of cryptographic keys. \_The process\
        \ from creation to destruction of the encryption key is described as the key\
        \ management life cycle."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Key management life cycle
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:5
      ref_id: 17.9.16
      description: "The key management lifecycle covers:\n\nkey generation,\nkey registration,\n\
        secure key storage,\nkey distribution and installation,\nkey use,\nkey rotation,\n\
        key backup (operational, backup and archive),\nkey replacement and reissue,\n\
        key recovery,\nkey revocation,\nkey suspension,\_\nkey retirement, and\nkey\
        \ destruction.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Open networks
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:6
      ref_id: 17.9.17
      description: "Open networks, by definition, seek to establish arbitrary connections\
        \ without there necessarily being a pre-existing relationship. \_Protocols\
        \ have been developed to manage this requirement through key exchange protocols\
        \ and through trusted agents, most often a National Authority or Certificate\
        \ Authority. \_Again it is important that approved protocols and algorithms,\
        \ as specified in this document, are used. Refer to sections 17.2 Approved\
        \ Cryptographic Algorithms and 17.3 Approved Cryptographic Protocols."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Public key infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:7
      ref_id: 17.9.18
      description: "Public key infrastructure (PKI) is the system used to create,\
        \ issue, manage, and revoke digital certificates and their associated cryptographic\
        \ keys. PKI has many different applications, and typically is used for encrypting\
        \ and digitally signing data in order to authenticate and protect data in\
        \ transmission, and supporting confidentiality and privacy.\_ It is used extensively\
        \ in ecommerce, internet banking, and secure email as well as being a key\
        \ element in protecting website traffic."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Outsourcing key management
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:8
      ref_id: 17.9.19
      description: "The goal of key management, both for use within an organisation\
        \ or in the cloud, is to enable data encryption by securing access to cryptographic\
        \ keys. This includes using a combination of cryptography and secure hardware\
        \ to generate keys securely, to manage access and destruction of keys.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:8
      ref_id: 17.9.20
      description: "As stated previously, the ownership, control, and possession are\
        \ three key aspects relevant to key management. Understanding the differences\
        \ between them will assist evaluating different key managements that meet\
        \ an agency\u2019s requirements.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:8
      ref_id: 17.9.21
      description: "For the purpose of this section these are defined as follows:\_\
        \n\n\n\nOwnership\n\nSpecifies to whom the cryptographic keys belong. This\
        \ is usually the custodian. Ownership of the key applies to the owner of the\
        \ encrypted data, the owner of the encryption and/or decryption process, and\
        \ the owner of the key infrastructure.\n\n\n\nControl\_\n\nSpecifies who carries\
        \ out key management lifecycle tasks, including having the option of precluding\
        \ others from doing these tasks.\n\n\n\nPossession\_\n\nSpecifies ownership\
        \ of the infrastructure or location where the keys and encrypted data physically\
        \ reside.\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:8
      ref_id: 17.9.22
      description: "The following diagram depicts the relationship between ownership,\
        \ possession, and control aspects within the key management process, including\
        \ the likely points within it, where the aspects would be positioned. Subsequent\
        \ paragraphs expand on these concepts by applying them to specific scenarios.\_\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: 'Commonly used key management scenarios '
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:9
      ref_id: 17.9.23
      description: "Within industry a number of\_approaches are available to manage\
        \ end users\u2019 cryptographic keys. There are variations in how these may\
        \ be defined, therefore an awareness around how role attribution is allocated\
        \ within a provider\u2019s own key management offering is an important consideration\
        \ when deciding on a solution.\_\nExample 1: The provider generates, manages,\
        \ and stores the encryption and decryption keys. This option may reduce the\
        \ amount of overhead an agency outlays compared to if they maintain their\
        \ own key infrastructure. However, if an agency changes providers this may\
        \ present challenges around compatibility, as well as financial implications.\_\
        \n\n\nExample 2: The customer generates and manages encryption keys, and the\
        \ cloud provider can access the keys to encrypt and decrypt the customer\u2019\
        s data. This option may reduce the level of control an agency has over the\
        \ confidentiality of their data. A key consideration for choosing this option\
        \ is likely to be the sensitivity of the data to be stored.\_\n\n\nExample\
        \ 3: An Agency generates and manages encryption keys including its storage.\
        \ Data encryption occurs prior to movement into a cloud environment. The provider\
        \ does not have access to file content. This option may be more suitable for\
        \ agencies that require greater security around sensitive data. The cloud\
        \ environment is used for storing the customer\u2019s encrypted data.\_\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:9
      ref_id: 17.9.24
      description: "The following includes considerations that should form part of\
        \ a technical evaluation when deciding on a key management solution.\_\n\n\
        The value of data to be stored including protection requirements for that\
        \ data.\_\nWhether the key management solution can be integrated with other\
        \ data storage services.\_\nThe number and types of keys required to secure\
        \ data and whether a provider can meet these expectations.\_\nWhether an externally\
        \ generated key provides sufficient assurance than if the key was generated\
        \ using on premises infrastructure.\_\nWhether keys can be automatically rotated.\_\
        \nThe level of investment, resourcing, and technology required to support\
        \ and maintain a key management infrastructure.\_\nWhether a provider\u2019\
        s key revocation process adequately meets agencies\u2019 expectations around\
        \ the removal of access to data.\_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Risks
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:10
      ref_id: 17.9.25
      description: "There are a number of specific risks related to the management\
        \ of cryptographic keys. These include:\n\nKeys exposed to unauthorised persons\
        \ or applications, potentially compromising the keys or data the encryption\
        \ is protecting.\nLost or unrecoverable cryptographic keys.\nSoftware based\
        \ key management, which provides only limited protection.\nFragmented key\
        \ management as new systems are introduced such as when changes occur to the\
        \ physical custody of hardware outside of a trusted environment.\_\nPoorly\
        \ documented and understood key management processes and activities increasing\
        \ the possibility of compromise and potentially increasing compliance costs.\n\
        Inadequate separation of duties within the ownership, control, and possession\
        \ of keys, resulting in non-compatible duties being allocated to the same\
        \ party, potentially resulting in unauthorised access of tenancy data.\_\n\
        Lack of interoperability if an agency\u2019s key management infrastructure\
        \ is not compatible with that offered by a cloud service provider.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:10
      ref_id: 17.9.26
      description: "Several factors should be understood and assessed conjointly to\
        \ enable decisions on which key management option is most suitable for security\
        \ and business requirements. These factors include:\_\n\nscenario,\_\nconsideration,\_\
        \nrisk,\_\nbusiness and/or security priority, and\_\noutsource aspect.\_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:10
      ref_id: 17.9.27
      description: "The following table provides an example of how the factors listed\
        \ above can be considered collectively when undertaking a technical evaluation.\
        \ It may also be useful when developing key or risk management plans. It is\
        \ not intended to be definitive, but rather to assist agencies evaluate different\
        \ key management options.\_\n\n\n\n\nScenario\_\n\n\nConsideration\_\n\n\n\
        Risk\_\n\n\nSecurity and/or business priority\_\n\n\nOutsource aspect\_\n\n\
        \n\n\nAgency generated and management of encryption keys including its storage.\_\
        \n\n\nInadequate separation of duties within the ownership, control, and possession\
        \ of keys, resulting in non-compatible duties being allocated to the same\
        \ party, potentially resulting in unauthorised access of tenancy data.\_\n\
        \n\nKeys exposed to unauthorised persons or applications, potentially compromising\
        \ the keys or data the encryption is protecting.\_\n\n\nSensitivity and value\
        \ of the data. This is summarised by the classification of the data but may\
        \ not always reflect the values of aggregation, cost of compliance breaches,\
        \ or reputation damage from a breach.\_\n\n\nControl\_\n\n\n\n\nAgency generates\
        \ the key, and it is migrated to a cloud where the provider can use the keys\
        \ to perform encryption and decryption operations.\_\n\n\nWhether the key\
        \ management solution can be integrated with other data storage services.\_\
        \n\n\nLack of interoperability if an agency\u2019s key management infrastructure\
        \ is not compatible with that offered by a cloud service provider.\_\n\n\n\
        The variety of key types, data formats, algorithms, protocols, and sources.\_\
        \n\n\nPossession\_\n\n\n\n\nCloud provider generates, manages, and stores\
        \ keys used to encrypt and decrypt data.\_\n\n\nWhether an externally generated\
        \ key provides sufficient assurance than if the key was generated using on\
        \ premises infrastructure.\_\n\n\nPoorly documented and understood key management\
        \ processes and activities increasing the possibility of compromise and potentially\
        \ increasing compliance costs.\_\n\n\nSensitivity and value of the data. This\
        \ is summarised by the classification of the data but may not always reflect\
        \ the value of aggregation, cost of compliance, breaches, or reputation damage\
        \ from a breach.\_\n\n\nOwnership\_\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:2:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2
      description: Prioritisation
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:2:11
      ref_id: 17.9.28
      description: 'Prioritisation helps identify and manage requirements for the
        use and management of cryptography and key management systems. This will determine
        the extent and complexity of the key management programme. Important aspects
        to consider are:


        Sensitivity and value of the data. This is summarised by the classification
        of the data but may not always reflect the values of aggregation, cost of
        compliance breaches or reputation damage from a breach.

        The volume of data and keys.

        The variety of key types, data formats, algorithms, protocols and sources.

        The speed and frequency of transactions, requirements for data access and
        availability.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.29
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:3
      ref_id: 17.9.29
      description: "Further information on key management can be found in the following\
        \ references:\n\n\n\nTitle\nPublisher\nDescription and source\n\n\nCommon\
        \ key management system models for the cloud\n\nCRYPTOMATHIC\n\n\nExplains\
        \ the four primary cloud KMS pattern combinations, and their suitability depending\
        \ on an organisation\u2019s requirements.\nCommon Key Management System Models\
        \ for the Cloud (cryptomathic.com)\n\n\n\n\nOptions for key management in\
        \ the cloud\n\nCSA\n\nProvides guidance and description around different key\
        \ management patterns.\nhttps://cloudsecurityalliance.org/blog/2022/03/24/ownership-control-and-possession-options-for-key-management-in-the-cloud/\n\
        \n\nChoosing and configuring a KMS for secure key management in the cloud\n\
        \nNCSC/UK\n\n\nHow to choose, use, and configure cloud services safely and\
        \ what security risks need to be considered.\nChoosing and configuring a KMS\
        \ for secure key management... - NCSC.GOV.UK\n\n\n\nISO/IEC 11770\nInformation\
        \ Technology \u2013 Security Techniques \u2013 Key Management\nISO / IEC\n\
        ISO/IEC 11770-1:2010 - Information technology \u2014 Security techniques \u2014\
        \ Key management \u2014 Part 1: Framework\n\n\n\nGuidelines for Cryptographic\
        \ Key Management\n\n\nIETF\n\nRFC 4107 - Guidelines for Cryptographic Key\
        \ Management (ietf.org)\n\n\n\nKey management and key establishment\n\n\n\
        NIST\n\n\nKey Management | CSRC (nist.gov)\n\n\n\n\nKey management interoperability\
        \ specification and profile\n\nOASIS\nKey Management Interoperability Protocol\
        \ Specification and Key Management Interoperability Protocol Profiles OASIS\
        \ Standards published - OASIS Open (oasis-open.org)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Developing key management plans
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      ref_id: 17.9.30.R.01
      description: Most modern cryptographic systems are designed to be highly resistant
        to cryptographic analysis, and it should be assumed that a determined attacker
        could obtain details of the cryptographic logic. Cryptographic system material
        is safeguarded by implementing a key management plan (KMP) encompassing personnel,
        physical, and information security.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      ref_id: 17.9.30.R.02
      description: Depending on the security requirements of an agency, different
        key management models or combination of models may be adopted to allocate
        the ownership, control, and possession for keys. It should be noted that the
        greater the sharing model adopted the less control of keys an agency may have.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      ref_id: 17.9.30.C.01
      name: 'Control -  All Classifications - Should [CID: 3016]'
      description: Agencies SHOULD assess the risks associated around key ownership,
        possession, and control against their own security and business requirements.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.30.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      ref_id: 17.9.30.C.02
      name: 'Control -  All Classifications - Should [CID: 3018]'
      description: Agencies SHOULD develop a KMP when they have implemented a cryptographic
        system using commercial grade cryptographic equipment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.30.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:1
      ref_id: 17.9.30.C.03
      name: 'Control -  All Classifications - Must [CID: 3017]'
      description: The level of detail included in a KMP MUST be consistent with the
        criticality and classification of the information to be protected.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Contents of key management plans
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:2
      ref_id: 17.9.31.R.01
      description: When agencies implement the recommended contents for KMPs they
        will have a good starting point for the protection of cryptographic systems
        and their material within their agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:2
      ref_id: 17.9.31.C.01
      name: 'Control -  All Classifications - Should [CID: 3021]'
      description: "The table below describes the minimum contents which SHOULD be\
        \ documented in the KMP.\n\n\n\nTopic\_\n\_Content\n\n\nObjectives\n\n\nObjectives\
        \ of the cryptographic system and KMP, including organisational aims.\nRefer\
        \ to relevant NZCSIs.\n\n\n\n\nSystem description\n\n\nThe environment.\n\
        Maximum classification of information protected.\nTopology diagram(s) and\
        \ description of the cryptographic system topology including data flows.\n\
        The use of keys.\nKey algorithm.\nKey length.\nKey lifetime.\n\n\n\n\n\nRoles\
        \ and administrative responsibilities\n\n\n\nDocuments roles and responsibilities,\
        \ including, if relevant, the COMSEC custodian, cryptographic systems administrator,\
        \ record keeper, cloud service provider, and auditor.\n\n\n\n\nAccounting\n\
        \n\nHow accounting will be undertaken for the cryptographic system.\nWhat\
        \ records will be maintained.\nHow records will be audited.\n\n\n\n\nClassification\n\
        \n\nClassification of the cryptographic system hardware.\nClassification of\
        \ cryptographic system software.\nClassification of the cryptographic system\
        \ documentation.\n\n\n\n\nInformation security incidents\n\n\nA description\
        \ of the conditions under which compromise of key material should be declared.\n\
        References to procedures to be followed when reporting and dealing with information\
        \ security incidents.\n\n\n\n\n\nKey management\n\n\n\nWho generates keys.\n\
        How keys are delivered.\nHow keys are received.\nKey distribution, including\
        \ local, remote and central.\nHow keys are installed.\nHow keys are transferred.\n\
        How keys are stored.\nHow keys are recovered.\nHow keys are revoked.\nHow\
        \ keys are destroyed.\nEach time key information or material is accessed,\
        \ details are captured in logs.\nApproved access lists to cryptographic keys.\_\
        \n\n\n\n\nMaintenance\n\n\nMaintaining the cryptographic system software and\
        \ hardware.\nDestroying equipment and media.\n\n\n\n\nReferences\n\n\nVendor\
        \ documentation.\nRelated policies.\n\n\n\n\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Accounting
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.32.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:3
      ref_id: 17.9.32.R.01
      description: As cryptographic equipment, and the keys they store, provide a
        significant security function for systems it is important that agencies are
        able to account for all cryptographic equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.32.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:3
      ref_id: 17.9.32.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 3024]'
      description: Agencies MUST be able to readily account for all transactions relating
        to cryptographic system material including identifying hardware and all software
        versions issued with the equipment and materials, including date and place
        of issue.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.32.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:3
      ref_id: 17.9.32.C.02
      name: 'Control -  All Classifications - Should [CID: 3025]'
      description: Agencies SHOULD be able to readily account for all transactions
        relating to cryptographic system material including identifying hardware and
        all software versions issued with the equipment and materials, including date
        and place of issue.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Audits, compliance and inventory checks
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.33.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:4
      ref_id: 17.9.33.R.01
      description: Cryptographic system audits are used as a process to account for
        cryptographic equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.33.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:4
      ref_id: 17.9.33.C.01
      name: 'Control -  All Classifications - Must [CID: 3028]'
      description: Agencies MUST conduct audits using two personnel with cryptographic
        system administrator access.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.33.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:4
      ref_id: 17.9.33.C.02
      name: 'Control -  All Classifications - Should [CID: 3029]'
      description: 'Agencies SHOULD conduct audits of cryptographic system material:


        on handover/takeover of administrative responsibility for the cryptographic
        system;

        on change of personnel with access to the cryptographic system; and

        at least annually.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.33.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:4
      ref_id: 17.9.33.C.03
      name: 'Control -  All Classifications - Should [CID: 3030]'
      description: 'Agencies SHOULD perform audits to:


        account for all cryptographic system material; and

        confirm that agreed security measures documented in the KMP are being followed.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Access register
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:5
      ref_id: 17.9.34.R.01
      description: Access registers can assist in documenting personnel that have
        privileged access to cryptographic systems along with previous accounting
        and audit activities for the system.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:5
      ref_id: 17.9.34.C.01
      name: 'Control -  All Classifications - Must [CID: 3033]'
      description: 'Agencies MUST hold and maintain an access register that records
        cryptographic system information such as:


        details of personnel with system administrator access;

        details of those whose system administrator access was withdrawn;

        details of system documents;

        accounting activities; and

        audit activities.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Cryptographic system administrator access
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.35.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:6
      ref_id: 17.9.35.R.01
      description: "The cryptographic system administrator is a highly privileged\
        \ position which involves granting privileged access to a cryptographic system.\
        \ \_Therefore extra precautions need to be put in place surrounding the security\
        \ and vetting of the personnel as well as the access control procedures for\
        \ individuals designated as cryptographic system administrators."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.35.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:6
      ref_id: 17.9.35.C.01
      name: 'Control -  All Classifications - Must [CID: 3036]'
      description: "Before personnel are granted cryptographic system administrator\
        \ access, agencies MUST ensure that they have:\n\na demonstrated need for\
        \ access;\nread and agreed to comply with the relevant Key Management Policy\
        \ and Plan (KMP) for the cryptographic system they are using;\na security\
        \ clearance at least equal to the highest classification of information processed\
        \ by the cryptographic system;\nagreed to protect the authentication information\
        \ for the cryptographic system at the highest classification of information\
        \ it secures;\nagreed not to share authentication information for the cryptographic\
        \ system without approval;\nagreed to be responsible for all actions under\
        \ their accounts;\_\nagreed to report all potentially security related problems\
        \ to the GCSB; and\nensure relevant staff have received appropriate training.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Area security and access control
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.36.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:7
      ref_id: 17.9.36.R.01
      description: As cryptographic equipment contains particularly sensitive information
        additional physical security measures need to be applied to the equipment.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.36.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:7
      ref_id: 17.9.36.C.01
      name: 'Control -  All Classifications - Should [CID: 3039]'
      description: Cryptographic system equipment SHOULD be stored in a room that
        meets the requirements for a server room of an appropriate level based on
        the classification of information the cryptographic system processes.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.36.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:7
      ref_id: 17.9.36.C.02
      name: 'Control -  All Classifications - Should [CID: 3040]'
      description: Areas in which cryptographic system material is used SHOULD be
        separated from other areas and designated as a controlled cryptography area.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: High assurance cryptographic equipment
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.37.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:8
      ref_id: 17.9.37.R.01
      description: The NZCSI series of documents provide product specific policy for
        HACE.
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.37.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:8
      ref_id: 17.9.37.C.01
      name: 'Control -  All Classifications - Must [CID: 3043]'
      description: Agencies MUST comply with NZCSI when using HACE.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4
      description: Transporting commercial grade cryptographic equipment & products
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.38.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:9
      ref_id: 17.9.38.R.01
      description: "Transporting commercial grade cryptographic equipment in a keyed\
        \ state exposes the equipment to the potential for interception and compromise\
        \ of the key stored within the equipment.\_ When commercial grade cryptographic\
        \ equipment is transported in a keyed state it needs to be done so according\
        \ to the requirements for the classification of the key stored in the equipment."
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.38.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:9
      ref_id: 17.9.38.C.01
      name: 'Control -  All Classifications - Must [CID: 3048]'
      description: Unkeyed commercial grade cryptographic equipment MUST be distributed
        and managed by a means approved for the transportation and management of government
        property.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.38.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:9
      ref_id: 17.9.38.C.02
      name: 'Control -  All Classifications - Must [CID: 3050]'
      description: Keyed commercial grade cryptographic equipment MUST be distributed,
        managed and stored by a means approved for the transportation and management
        of government property based on the classification of the key within the equipment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.9.38.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.9:4:9
      ref_id: 17.9.38.C.03
      name: 'Control -  All Classifications - Should Not [CID: 3053]'
      description: Agencies SHOULD NOT transport commercial grade cryptographic equipment
        or products in a keyed state.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:17.10
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:17
      ref_id: '17.10'
      name: Hardware Security Modules
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:1
      ref_id: 17.10.1
      description: Hardware Security Modules are used where additional security of
        cryptographic functions is desirable.
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:1
      ref_id: 17.10.2
      description: "This section covers information relating to Hardware Security\
        \ Modules (HSMs). \_ \_Detailed key management guidance is provided in Section\
        \ 17.9 \u2013 Key Management."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Hardware Security Module
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:2
      ref_id: 17.10.3
      description: "Hardware Security Modules (HSMs) are defined as a hardware module\
        \ or appliance which provides cryptographic functions. \_HSM\u2019s can be\
        \ integrated into a design, installed in a host or be externally connected.\
        \ \_HSM\u2019s can be packaged as discrete appliances, PCI cards, USB devices,\
        \ smartcards or other form factors."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:2
      ref_id: 17.10.4
      description: "Functions include (but are not limited to) encryption, decryption,\
        \ key generation, signing, hashing and cryptographic acceleration. \_The appliance\
        \ usually also offers some level of physical tamper-resistance, has a user\
        \ interface and a programmable interface for key management, configuration\
        \ and firmware or software updates."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Usage
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:3
      ref_id: 17.10.5
      description: "HSMs are used in high assurance security solutions that satisfy\
        \ widely established and emerging standards of due care for cryptographic\
        \ systems and practices\u2014while also maintaining high levels of operational\
        \ efficiency. \_Traditional use of HSMs is within automatic teller machines,\
        \ electronic fund transfer, and point-of-sale networks. \_HSMs are also used\
        \ to secure CA keys in PKI deployments, SSL acceleration and DNSSEC (DNS Security\
        \ Extensions) implementations."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Physical Security
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:4
      ref_id: 17.10.6
      description: "HSM\u2019s usually describe an encapsulated multi-chip module,\
        \ device, card or appliance, rather than a single chip component or device.\
        \ \_The nature of HSM\u2019s requires more robust physical security, including\
        \ tamper resistance, tamper evidence, tamper detection, and tamper response."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Tamper Resistance
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:5
      ref_id: 17.10.7
      description: "Tamper Resistance is designed to limit the ability to physically\
        \ tamper with, break into or extract useful information from an HSM. \_Often\
        \ the boards and components are encased in an epoxy-like resin that will destroy\
        \ any encapsulated components when drilled, scraped or otherwise physically\
        \ tampered with."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Tamper Evidence
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:6
      ref_id: 17.10.8
      description: "The HSM is designed so that any attempts at tampering are evident.\
        \ \_Many devices use seals and labels designed break or reveal a special message\
        \ when physical tampering is attempted. \_Tamper evidence may require a regular\
        \ inspection or audit mechanism."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:6
      ref_id: 17.10.9
      description: "HSMs can include features that detect and report tampering attempts.\
        \ \_For example, embedding a conductive mesh within the epoxy-like package;\
        \ internal circuitry monitored the electrical proper-ties of this mesh \u2014\
        \ properties which physical tamper would disrupt. \_Devices can also monitor\
        \ for temperature extremes, radiation extremes, light, air and other unusual\
        \ conditions."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2
      description: Tamper Response
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:2:7
      ref_id: 17.10.10
      description: "HSMs can include defensive features that activate when tampering\
        \ is detected. \_For example, cryptographic keys and sensitive data are deleted\
        \ or zeroised. \_A trade-off exists between availability and security as an\
        \ effective tamper response essentially renders the HSM unusable."
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:3
      ref_id: 17.10.11
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\nPayment Card Industry (PCI) Hardware Security Module (HSM)\
        \ - Security Requirements\_\nPCI\n\nOfficial PCI Security Standards Council\
        \ Site - Document\nPCI HSM Frequently Asked Questions (pcisecuritystandards.org)\n\
        \n\n\n\nFIPS PUB 140-2\n\n\nFIPS PUB 140-2 Security Requirements for Cryptographic\
        \ Modules\n\nNIST\n\nFIPS 140-2, Security Requirements for Cryptographic Modules\
        \ | CSRC (nist.gov)\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4
      description: Hardware Security Modules
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      ref_id: 17.10.12.R.01
      description: Where high assurance or high security is required or high volumes
        of data are encrypted or decrypted, the use of an HSM should be considered
        when designing the network and security architectures.
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      ref_id: 17.10.12.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3103]'
      description: Agencies MUST consider the use of HSMs when undertaking a security
        risk assessment or designing network and security architectures.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      ref_id: 17.10.12.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 3105]'
      description: "Agencies MUST follow the product selection guidance in this manual.\
        \ See Chapter 12 \u2013 Product Security."
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      ref_id: 17.10.12.C.03
      name: 'Control -  All Classifications - Should [CID: 3108]'
      description: Agencies SHOULD consider the use of HSMs when undertaking a security
        risk assessment or designing network and security architectures.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:17.10.12.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:17.10:4:1
      ref_id: 17.10.12.C.04
      name: 'Control -  All Classifications - Should [CID: 3110]'
      description: "Agencies SHOULD follow the product selection guidance in this\
        \ manual. See Chapter 12 \u2013 Product Security."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18
      assessable: false
      depth: 1
      ref_id: '18'
      name: Network security
    - urn: urn:defend:risk:req_node:nzism-v3:18.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.1'
      name: Network Management
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:1
      ref_id: 18.1.1
      description: "Any change\_to the configuration of networks is authorised and\
        \ controlled through appropriate change management processes to ensure security,\
        \ functionality and capability is maintained."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:1
      ref_id: 18.1.2
      description: This section covers information relating to the selection, management
        and documentation of network infrastructure.
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2
      description: Network diagrams
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:2
      ref_id: 18.1.3
      description: "An agency\u2019s network diagrams should illustrate all network\
        \ devices including firewalls, IDSs, IPSs, routers, switches, hubs, etc. \_\
        It does not need to illustrate all IT equipment on the network, such as workstations\
        \ or printers which can be collectively represented. \_The inclusion of significant\
        \ devices such as MFD\u2019s and servers can aid interpretation."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2
      description: Systems Documentation
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:3
      ref_id: 18.1.4
      description: "Knowledge of systems design, equipment and implementation is a\
        \ primary objective of those seeking to attack or compromise systems or to\
        \ steal information. \_System documentation is a rich source allowing attackers\
        \ to identify design weaknesses and vulnerabilities. \_The security of systems\
        \ documentation is therefore important in preserving the security of systems."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:3
      ref_id: 18.1.5
      description: "Detailed network documentation and configuration details can contain\
        \ information about IP addresses, port numbers, host names, services and protocols,\
        \ software version numbers, patch status, security enforcing devices and information\
        \ about information compartments and enclaves containing highly valuable information.\
        \ \_This information can be used by a malicious actor to compromise an agency\u2019\
        s network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:3
      ref_id: 18.1.6
      description: "This information may be particularly exposed when sent to offshore\
        \ vendors, consultants and other service providers. \_Encrypting this data\
        \ will provide an important protective measure and assist in securing this\
        \ data and information."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:2:3
      ref_id: 18.1.7
      description: "Reference should also be made to Section 12.7 \u2013 Supply Chain."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:3
      ref_id: 18.1.8
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV5, GOV6, INFOSEC1,\
        \ INFOSEC2, INFOSEC3 and INFOSEC4\n\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements/\_ \_\n\n\n\n\nPSR\
        \ content protocols \n\n\nManagement protocol for information security\n\n\
        \nManagement protocol for information security | Protective Security Requirements\n\
        \_\n\n\n\n\nPSR requirements sections\n\n\nHandling requirements for protectively\
        \ marked information and equipment\nSupply chain security\nUnderstand the\
        \ information security lifecycle\n\nClassification system | Protective Security\
        \ Requirements\nSupply chain security | Protective Security Requirements\n\
        Understanding the information security lifecycle | Protective Security Requirements\n\
        \n\n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nTransacting online with the public\nOutsourcing,\
        \ Offshoring and supply chains\nMobile and remote working\nCloud computing\n\
        Communication security\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Classification of Network Documentation
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.R.01
      description: "To provide an appropriate level of protection to systems and network\
        \ documentation, a number of security aspects should be considered. These\
        \ include:\nthe existence of the system;\nthe intended use;\nthe classification\
        \ of the data to be carried or processed by this system;\nthe connectivity\
        \ and agencies connected;\_\nprotection enhancements and modifications; and\n\
        the level of detail included in the documentation.\nHigh level conceptual\
        \ diagrams and accompanying documentation should also be subject to these\
        \ considerations"
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3170]'
      description: Agencies MUST perform a security risk assessment before providing
        network documentation to a third party, such as a commercial provider or contractor.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 3172]'
      description: Systems documentation and detailed network diagrams MUST be classified
        at least to the level of classification of the data to be carried on those
        systems.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.C.03
      name: 'Control -  All Classifications - Must [CID: 3174]'
      description: Network documentation provided to a third party, such as to a commercial
        provider or contractor, MUST contain only the information necessary for them
        to undertake their contractual services and functions, consistent with the
        need-to-know principle.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.C.04
      name: 'Control -  All Classifications - Must Not [CID: 3176]'
      description: Detailed network configuration information MUST NOT be published
        in tender documentation.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.9.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:1
      ref_id: 18.1.9.C.05
      name: 'Control -  All Classifications - Should [CID: 3179]'
      description: Security aspects SHOULD be considered when determining the classification
        level of systems and network documentation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Configuration management
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.R.01
      description: "If the network is not centrally managed, there could be sections\
        \ of the network that do not comply with the agency\u2019s security policies,\
        \ and thus create a vulnerability."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.R.02
      description: "Changes should be authorised by a change management process, including\
        \ representatives from all parties involved in the management of the network.\
        \ \_This process ensures that changes are understood by all parties and reduces\
        \ the likelihood of an unexpected impact on the network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.C.01
      name: 'Control -  All Classifications - Should [CID: 3188]'
      description: Agencies SHOULD keep the network configuration under the control
        of a network management authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.C.02
      name: 'Control -  All Classifications - Should [CID: 3190]'
      description: All changes to the configuration SHOULD be documented and approved
        through a formal change control process.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.C.03
      name: 'Control -  All Classifications - Should [CID: 3191]'
      description: Agencies SHOULD regularly review their network configuration to
        ensure that it conforms to the documented network configuration.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:2
      ref_id: 18.1.10.C.04
      name: 'Control -  All Classifications - Should [CID: 3192]'
      description: Agencies SHOULD deploy an automated tool that compares the running
        configuration of network devices against the documented configuration.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Network diagrams
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:3
      ref_id: 18.1.11.R.01
      description: 'As most decisions are made on the documentation that illustrates
        the network, it is important that:

        a network diagram exists;

        the security architecture is recorded;

        the network diagram is an accurate depiction of the network; and

        the network diagram indicates when it was last updated.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:3
      ref_id: 18.1.11.C.01
      name: 'Control -  All Classifications - Must [CID: 3195]'
      description: 'For each network an agency manages they MUST have:

        a high-level diagram showing all connections and gateways into the network;
        and

        a network diagram showing all communications equipment.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Updating network diagrams
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:4
      ref_id: 18.1.12.R.01
      description: "Because of the importance of the network diagram and decisions\
        \ made based upon its contents, it should be updated as changes are made.\
        \ \_This will assist system administrators to completely understand and adequately\
        \ protect the network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:4
      ref_id: 18.1.12.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3198]'
      description: "An agency\u2019s network diagrams MUST:\nbe updated as network\
        \ changes are made; and\ninclude a \u2018Current as at [date]\u2019 statement\
        \ on each page.\n"
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:4
      ref_id: 18.1.12.C.02
      name: 'Control -  All Classifications - Should [CID: 3199]'
      description: "An agency\u2019s network diagrams SHOULD:\nbe updated as network\
        \ changes are made; and\ninclude a \u2018Current as at [date]\u2019 statement\
        \ on each page.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Limiting network access
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      ref_id: 18.1.13.R.01
      description: "If an attacker has limited opportunities to connect to a given\
        \ network, they have limited opportunities to attack that network. \_Network\
        \ access controls not only prevent against attackers traversing a network\
        \ but also prevent system users carelessly connecting a network to another\
        \ network of a different classification. \_It is also useful in segregating\
        \ sensitive or compartmented information for specific system users with a\
        \ need-to-know."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      ref_id: 18.1.13.R.02
      description: Although circumventing some network access controls can be trivial,
        their use is primarily aimed at the protection they provide against accidental
        connection to another network.
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.13.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      ref_id: 18.1.13.R.03
      description: "The design of a robust security architecture is fundamental to\
        \ the security of a system. \_This may include concepts such as trust zones,\
        \ application of the principles of separation and segregation through, for\
        \ example, segmented networks and VPNs and other design techniques."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      ref_id: 18.1.13.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3204]'
      description: Agencies MUST implement network access controls on all networks.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:5
      ref_id: 18.1.13.C.02
      name: 'Control -  All Classifications - Should [CID: 3205]'
      description: Agencies SHOULD implement network access controls on all networks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Management traffic
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:6
      ref_id: 18.1.14.R.01
      description: Implementing protection measures specifically for management traffic
        provides another layer of defence on the network. This also makes it more
        difficult for an attacker to accurately define their target network.
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:6
      ref_id: 18.1.14.C.01
      name: 'Control -  All Classifications - Should [CID: 3208]'
      description: Agencies SHOULD implement protection measures to minimise the risk
        of unauthorised access to network management traffic on a network.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4
      description: Simple Network Management IT Protocol (SNMP)
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      ref_id: 18.1.15.R.01
      description: "The Simple Network Management Protocol (SNMP) can be used to monitor\
        \ the status of network devices such as switches, routers and wireless access\
        \ points. \_Early versions of SNMP were insecure. SNMPv3 uses stronger authentication\
        \ methods but continues to establish default SNMP community strings and promiscuous\
        \ access. \_Encryption may be used as an additional assurance measure but\
        \ this may create additional workload in investigating faults. \_An assessment\
        \ of risk, threats and the agency\u2019s requirements may be required to determine\
        \ an appropriate configuration."
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      ref_id: 18.1.15.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3211]'
      description: Agencies SHOULD NOT use SNMP unless a specific requirement exists.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      ref_id: 18.1.15.C.02
      name: 'Control -  All Classifications - Should [CID: 3238]'
      description: Agencies SHOULD implement SNMPv3 where a specific SNMP requirement
        exists.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.15.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      ref_id: 18.1.15.C.03
      name: 'Control -  All Classifications - Should [CID: 3239]'
      description: Agencies SHOULD change all default community strings in SNMP implementations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.1.15.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.1:4:7
      ref_id: 18.1.15.C.04
      name: 'Control -  All Classifications - Should [CID: 3240]'
      description: SNMP access SHOULD be configured as read-only.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.2'
      name: Wireless Local Area Networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:1
      ref_id: 18.2.1
      description: "Wireless local\_area networks are deployed in a secure manner\
        \ that does not compromise the security of information and systems."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:2:1
      ref_id: 18.2.2
      description: "This section covers information on 802.11x WLANs. \_It does not\
        \ cover other wireless communications. \_These communication methods are covered\
        \ in Chapter 11 - Communications Systems and Devices. \_The description 802.11x\
        \ refers to all versions and 802.11 standards.\n\n\n\nTitle\nPublisher\nSource\n\
        \n\n802.11 Wi-Fi\nIEEE\nWireless LAN Media Access Control and Physical Layer\
        \ specification. 802.11a,b,g,etc. are amendments to the original 802.11 standard.\
        \ Products that implement 802.11 standards must pass tests and are referred\
        \ to as \"Wi-Fi certified\u201D.\n\n\n802.15 Wireless Personal Area Networks\n\
        IEEE\n\nCommunications specification that was approved in early 2002 by the\
        \ IEEE for wireless personal area networks (WPANs and includes Bluetooth,\
        \ Ultra Wideband, Zigbee and Mesh Networks.\n\n\n\n\n802.16 Wireless Metropolitan\
        \ Area Networks\n\nIEEE\n\nThis family of standards covers Fixed and Mobile\
        \ Broadband Wireless Access methods used to create Wireless Metropolitan Area\
        \ Networks (WMANs.) Connects Base Stations to the Internet using OFDM in unlicensed\
        \ (900 MHz, 2.4, 5.8 GHz) or licensed (700 MHz, 2.5 \u2013 3.6 GHz) frequency\
        \ bands. Products that implement 802.16 standards can undergo WiMAX certification\
        \ testing.\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:2:1
      ref_id: 18.2.3
      description: "Hardware Security Modules (HSMs) are defined as a hardware module\
        \ or appliance that provides cryptographic functions. These functions include\
        \ (but are not limited to) encryption, decryption, key generation, and hashing.\
        \ \_The appliance usually also offers some level of physical tamper-resistance\
        \ and has a user interface and a programmable interface. \_Refer also to Section\
        \ 17.10 \u2013 Hardware Security Modules."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:3
      ref_id: 18.2.4
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\nImplementing Network Segmentation and Segregation\n\n\n\
        ASD\n\n\nImplementing Network Segmentation and Segregation | Cyber.gov.au\n\
        \n\n\n\_\n\nWi-Fi Alliance certification programs\n\n\nWi-Fi Alliance\n\n\n\
        http://www.wi-fi.org/certification_programs.php\n\n\n\n\_802.11\n\nIEEE Standard\
        \ for Information Technology - Telecommunications and Information Exchange\
        \ between systems - Local and Metropolitan Area - Specific Requirements -\
        \ Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)\
        \ Specifications\n\n\nIEEE\n\n\nhttp://standards.ieee.org/findstds/standard/802.11-2012.html\n\
        \n\n\n\nRFC 5247\n\n\nEAP specification\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc5247\n\
        \n\n\n\nRFC 5216\n\n\nEAP-TLS specification\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc5216\n\
        \n\n\n\nRFC 5281\n\n\nEAP-TTLS specification\n\nIETF\n\nhttps://datatracker.ietf.org/doc/html/rfc5281\n\
        \n\n\n\_\n\nPayment Card Industry (PCI) Hardware Security Module (HSM) - Security\
        \ Requirements\n\n\nPCI\n\n\nOfficial PCI Security Standards Council Site\
        \ - Document\nPCI HSM Frequently Asked Questions (pcisecuritystandards.org)\n\
        \n\n\n\nFIPS PUB 140-2\n\n\nFIPS PUB 140-2 - Security Requirements for Cryptographic\
        \ Modules\n\n\nNIST\n\n\nFIPS 140-2, Security Requirements for Cryptographic\
        \ Modules | CSRC (nist.gov)\n\n\n\n\_\n\nExtensible Authentication Protocol\n\
        \n\nMicrosoft\n\n\nhttps://technet.microsoft.com/en-us/network/bb643147.aspx\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Bridging networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:1
      ref_id: 18.2.5.R.01
      description: "When connecting devices via Ethernet to an agency\u2019s fixed\
        \ network, agencies need to be aware of the risks posed by active wireless\
        \ functionality. \_Devices may automatically connect to any open wireless\
        \ networks they have previously connected to, which a malicious actor can\
        \ use to masquerade and establish a connection to the device. \_This compromised\
        \ device could then be used as a bridge to access the agency\u2019s fixed\
        \ network. \_Disabling wireless functionality on devices, preferably by a\
        \ hardware switch, whenever connected to a fixed network can prevent this\
        \ from occurring. \_Additionally, devices do not have to be configured to\
        \ remember and automatically connect to open wireless networks that they have\
        \ previously connected to."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:1
      ref_id: 18.2.5.C.01
      name: 'Control -  All Classifications - Must Not [CID: 3274]'
      description: Devices MUST NOT be configured to remember and automatically connect
        to any wireless networks that they have previously connected to.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:1
      ref_id: 18.2.5.C.02
      name: 'Control -  All Classifications - Should [CID: 3282]'
      description: Wireless auto-connect functionality on devices SHOULD be disabled,
        preferably by a hardware switch, whenever connected to a fixed network.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Providing wireless communications for public access
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:2
      ref_id: 18.2.6.R.01
      description: "To ensure that a wireless network provided for public access cannot\
        \ be used as a launching platform for attacks against an agency\u2019s system\
        \ it MUST be separated from all other systems. \_Security architectures incorporating\
        \ segmented networks, DMZ\u2019s and other segregation mechanisms are useful\
        \ in this regard."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:2
      ref_id: 18.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 3290]'
      description: Agencies deploying a wireless network for public access MUST separate
        it from any other agency networks; including BYOD networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Using wireless communications
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:3
      ref_id: 18.2.7.R.01
      description: As the Accreditation Authority for TOP SECRET systems, GCSB has
        mandated that all agencies considering deploying a wireless TOP SECRET deployment
        seek approval from GCSB prior to initiating any networking projects.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:3
      ref_id: 18.2.7.C.01
      name: 'Control -  Top Secret - Must Not [CID: 3298]'
      description: "Agencies MUST NOT use wireless networks unless the security of\
        \ the agency\u2019s wireless deployment has been approved by GCSB."
      implementation_groups:
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Selecting wireless access point equipment
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:4
      ref_id: 18.2.8.R.01
      description: "Wireless access points that have been certified in a Wi-Fi Alliance\
        \ certification program provide an agency with assurance that they conform\
        \ to wireless standards. \_Deploying wireless access points that are guaranteed\
        \ to be interoperable with other wireless access points on a wireless network\
        \ will limit incompatibility of wireless equipment and incorrect implementation\
        \ of wireless devices by vendors."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:4
      ref_id: 18.2.8.C.01
      name: 'Control -  All Classifications - Must [CID: 3302]'
      description: All wireless access points used for government wireless networks
        MUST be Wi-Fi Alliance certified.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: 802.1X Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      ref_id: 18.2.9.R.01
      description: A number of Extensible Authentication Protocol (EAP) methods, supported
        by the Wi-Fi Protected Access 2 and 3 (WPA2, WPA3) protocols, are available.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      ref_id: 18.2.9.R.02
      description: "Depending on the security requirements agencies deploying a secure\
        \ wireless network can choose EAP-Transport Layer Security (EAP-TLS), EAP-Tunnelled\
        \ Transport Layer Security (EAP-TTLS) or Protected EAP (PEAP) to perform mutual\
        \ authentication.\nEAP-TLS is considered one of the most secure EAP methods.\
        \ With its inclusion in the initial release of the WPA2 standard, it enjoys\
        \ wide support in wireless access points and in numerous operating systems\
        \ such as Microsoft Windows, Linux and Apple OS X. EAP-TLS uses a public key\
        \ infrastructure (PKI) to secure communications between devices and a Remote\
        \ Access Dial In User Service (RADIUS) server through the use of X.509 certificates.\
        \ While EAP-TLS provides strong mutual authentication, it requires an agency\
        \ to have established a PKI. This involves either deploying their own certificate\
        \ authority and issuing certificates, or purchasing certificates from a commercial\
        \ certificate authority, for every device that accesses the wireless network.\
        \ This can introduce additional costs and management overheads but the risk\
        \ and security management advantages are significant.\nThe EAP-TTLS/MSCHAPv2,\
        \ or simply EAP-TTLS, method is generally supported through the use of third\
        \ party software. It has support in multiple operating systems including current\
        \ and supported versions of Microsoft Windows client and server editions.\
        \ EAP-TTLS is different to EAP-TLS in that devices do not authenticate to\
        \ the server when the initial TLS tunnel is created. Only the server authenticates\
        \ to devices. Once the TLS tunnel has been created, mutual authentication\
        \ occurs through the use of another EAP method.\nAn advantage of EAP-TTLS\
        \ over PEAP is that a username is never transmitted in the clear outside of\
        \ the TLS tunnel. Another advantage of EAP-TTLS is that it provides support\
        \ for many legacy EAP methods, while PEAP is generally limited to the use\
        \ of EAP-MSCHAPv2.\nPEAPv0/EAP-MSCHAPv2, or simply PEAP, is the second most\
        \ widely supported EAP method after EAP-TLS. It enjoys wide support in wireless\
        \ access points and in numerous operating systems such as Microsoft Windows,\
        \ Linux and Apple OS X. PEAP operates in a very similar way to EAP-TTLS by\
        \ creating a TLS tunnel which is used to protect another EAP method. PEAP\
        \ differs from EAP-TTLS in that when the EAP-MSCHAPv2 method is used within\
        \ the TLS tunnel, only the password portion is protected and not the username.\
        \ This may allow an intruder to capture the username and replay it with a\
        \ bogus password in order to lockout the user\u2019s account, causing a denial\
        \ of service for that user. While EAP-MSCHAPv2 within PEAP is the most common\
        \ implementation, Microsoft Windows supports the use of EAP-TLS within PEAP,\
        \ known as PEAP-EAP-TLS. This approach is very similar in operation to traditional\
        \ EAP-TLS yet provides increased protection, as parts of the certificate that\
        \ are not encrypted with EAP-TLS are encrypted with PEAP-EAP-TLS. The downside\
        \ to PEAP-EAP-TLS is its support is limited to Microsoft products."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.9.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      ref_id: 18.2.9.R.03
      description: "Ultimately, an agency\u2019s choice in authentication method will\
        \ often be based on the size of their wireless deployment, their security\
        \ requirements and any existing authentication infrastructure. \_If an agency\
        \ is primarily motivated by security they can implement either PEAP-EAP-TLS\
        \ or EAP-TLS. \_If they are primarily motivated by flexibility and legacy\
        \ support they can implement EAP-TTLS. \_If they are primarily motivated by\
        \ simplicity they can implement PEAP with EAP-MSCHAPv2."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      ref_id: 18.2.9.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 7538]'
      description: EAP-TLS or PEAP-EAP-TLS MUST be used on wireless networks to perform
        mutual authentication.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:5
      ref_id: 18.2.9.C.02
      name: 'Control -  All Classifications - Must [CID: 3319]'
      description: EAP-TLS, PEAP-EAP-TLS, EAP-TTLS or PEAP MUST be used on wireless
        networks to perform mutual authentication.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Evaluation of 802.1X authentication implementation
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:6
      ref_id: 18.2.10.R.01
      description: "The security of 802.1X authentication is dependent on three main\
        \ elements and their interaction. \_These three elements include supplicants\
        \ (clients) that support the 802.1X authentication protocol, authenticators\
        \ (wireless access points) that facilitate communication between supplicants\
        \ and the authentication server, and the authentication server (RADIUS server)\
        \ that is used for authentication, authorisation and accounting purposes.\
        \ \_To provide assurance that these elements have been implemented appropriately,\
        \ supplicants, authenticators and the authentication server used in wireless\
        \ networks must have completed an appropriate product evaluation."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:6
      ref_id: 18.2.10.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3326]'
      description: Supplicants, authenticators and the authentication server used
        in wireless networks MUST have completed an appropriate product evaluation.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:6
      ref_id: 18.2.10.C.02
      name: 'Control -  All Classifications - Should [CID: 3329]'
      description: Supplicants, authenticators and the authentication server used
        in wireless networks SHOULD have completed an appropriate product evaluation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Issuing certificates for authentication
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.R.01
      description: "Certificates for authenticating to wireless networks can be issued\
        \ to either or both devices and users. \_For assurance, certificates must\
        \ be generated using a certificate authority product or hardware security\
        \ module (HSM) that has completed an appropriate product evaluation."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.R.02
      description: "When issuing certificates to devices accessing wireless networks,\
        \ agencies need to be aware of the risk that these certificates could be stolen\
        \ by malicious software. \_Once compromised, the certificate could be used\
        \ on another device to gain unauthorised access to the wireless network. \_\
        Agencies also need to be aware that in only issuing a certificate to a device,\
        \ any actions taken by a user will only be attributable to the device and\
        \ not a specific user."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.R.03
      description: When issuing certificates to users accessing wireless networks,
        they can either be in the form of a certificate that is stored on a device
        or a certificate that is stored within a smart card. Issuing certificates
        on smart cards provides increased security, but usually at a higher cost.
        Security is improved because a user is more likely to notice a missing smart
        card and alert their local security team, who is then able to revoke the credentials
        on the RADIUS server. This can minimise the time an intruder has access to
        a wireless network.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.R.04
      description: "In addition, to reduce the likelihood of a stolen smart card from\
        \ being used to gain unauthorised access to a wireless network, two-factor\
        \ authentication can be implemented through the use of Personal Identification\
        \ Numbers (PINs) on smart cards. \_This is essential when a smart card grants\
        \ a user any form of administrative access on a wireless network or attached\
        \ network resource."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.R.05
      description: For the highest level of security, unique certificates should be
        issued for both devices and users. In addition, the certificates for a device
        and user must not be stored on the same device. Finally, certificates for
        users accessing wireless networks should be issued on smart cards with access
        PINs and not stored with a device when not in use.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.C.01
      name: 'Control -  All Classifications - Must [CID: 3343]'
      description: Agencies MUST generate certificates using a certificate authority
        product or hardware security module that has completed an appropriate product
        evaluation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.C.02
      name: 'Control -  All Classifications - Must Not [CID: 3346]'
      description: The certificates for both a device and user accessing a wireless
        network MUST NOT be stored on the same device.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.C.03
      name: 'Control -  All Classifications - Should [CID: 3348]'
      description: Agencies SHOULD use unique certificates for both devices and users
        accessing a wireless network.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.C.04
      name: 'Control -  All Classifications - Should [CID: 3350]'
      description: Certificates for users accessing wireless networks SHOULD be issued
        on smart cards with access PINs and not stored with a device when not in use.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.11.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:7
      ref_id: 18.2.11.C.05
      name: 'Control -  All Classifications - Should [CID: 3351]'
      description: Certificates stored on devices accessing wireless networks SHOULD
        be protected by implementing full disk encryption on the devices.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Using commercial certification authorities for certificate generation
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:8
      ref_id: 18.2.12.R.01
      description: "A security risk exists with EAP-TTLS and PEAP when a commercial\
        \ certificate authority\u2019s certificates are automatically trusted by devices\
        \ using vendor trusted certificate stores. This trust can be exploited by\
        \ obtaining certificates from a commercial certificate authority under false\
        \ pretences, as devices can be tricked into trusting their signed certificate.\
        \ This will allow the capture of authentication credentials presented by devices,\
        \ which in the case of EAP-MSCHAPv2 can be cracked using a brute force attack\
        \ granting not only network access but most likely Active Directory credentials\
        \ as well.To reduce this risk, devices can be configured to:\nvalidate the\
        \ server certificate;\ndisable any trust for certificates generated by commercial\
        \ certificate authorities that are not trusted;\ndisable the ability to prompt\
        \ users to authorise net servers or commercial certificate authorities; and\n\
        set devices to enable identity privacy to prevent usernames being sent prior\
        \ to being authenticated by the RADIUS server.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:8
      ref_id: 18.2.12.C.01
      name: 'Control -  All Classifications - Must [CID: 3354]'
      description: Devices MUST be configured to validate the server certificate,
        disable any trust for certificates generated by commercial certificate authorities
        that are not trusted and disable the ability to prompt users to authorise
        new servers or commercial certification authorities.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:8
      ref_id: 18.2.12.C.02
      name: 'Control -  All Classifications - Should [CID: 3355]'
      description: Devices SHOULD be set to enable identity privacy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Caching 802.1X authentication outcomes
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:9
      ref_id: 18.2.13.R.01
      description: "When 802.1X authentication is used, a shared secret key known\
        \ as the Pairwise Master Key (PMK) is generated. \_Upon successful authentication\
        \ of a device, the PMK can be cached to assist with fast roaming between wireless\
        \ access points. \_When a device roams away from a wireless access point that\
        \ it has authenticated to, it will not need to perform a full re-authentication\
        \ should it roam back while the cached PMK remains valid. \_To further assist\
        \ with roaming, wireless access points can be configured to pre-authenticate\
        \ a device to other neighbouring wireless access points that the device might\
        \ roam to. \_Although requiring full authentication for a device each time\
        \ it roams between wireless access points is ideal, agencies can chose to\
        \ use PMK caching and pre-authentication if they have a business requirement\
        \ for fast roaming. \_If PMK caching is used, the PMK caching period should\
        \ not be set to greater than 1440 minutes (24 hours)."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:9
      ref_id: 18.2.13.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3358]'
      description: The PMK caching period SHOULD NOT be set to greater than 1440 minutes
        (24 hours).
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Remote Authentication Dial-In User Service (RADIUS) authentication
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:10
      ref_id: 18.2.14.R.01
      description: "The RADIUS authentication process that occurs between wireless\
        \ access points and the RADIUS server is distinct and a separate to the 802.1X\
        \ authentication process. \_During the initial configuration of wireless networks\
        \ using 802.1X authentication, a shared secret is entered into either the\
        \ wireless access points or the RADIUS server. \_If configured on the wireless\
        \ access points, the shared secret is sent to the RADIUS server via the RADIUS\
        \ protocol, and vice versa if configured on the RADIUS server. \_This shared\
        \ secret is used for both RADIUS authentication and confidentiality of RADIUS\
        \ traffic."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.14.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:10
      ref_id: 18.2.14.R.02
      description: "An intruder that is able to gain access to the RADIUS traffic\
        \ sent between wireless access points and the RADIUS server may be able to\
        \ perform a brute force or an off-line dictionary attack to recover the shared\
        \ secret. \_This in turn allows the intruder to decrypt all communications\
        \ between wireless access points and the RADIUS server. \_To mitigate this\
        \ security risk, communications between wireless access points and a RADIUS\
        \ server must be encapsulated with an additional layer of encryption using\
        \ an appropriate encryption product (See Chapter 17 \u2013 Cryptography)."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:10
      ref_id: 18.2.14.C.01
      name: 'Control -  All Classifications - Must [CID: 3362]'
      description: "Communications between wireless access points and a RADIUS server\
        \ MUST be encapsulated with an additional layer of encryption using an approved\
        \ encryption product (See Chapter 17 \u2013 Cryptography)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:11
      ref_id: 18.2.15.R.01
      description: As wireless transmissions are capable of radiating outside of secure
        areas into unsecure areas they need to be encrypted to the same level as classified
        information communicated over cabled infrastructure in unsecure areas.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:11
      ref_id: 18.2.15.C.01
      name: 'Control -  All Classifications - Must [CID: 3365]'
      description: Agencies using wireless networks MUST ensure that classified information
        is protected by cryptography that meets the assurance level mandated for the
        communication of information over unclassified network infrastructure (See
        Section 17.2, Suite B).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Cipher Block Chaining Message Authentication Code Protocol (CCMP)
        Encryption
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:12
      ref_id: 18.2.16.R.01
      description: As wireless transmissions are capable of radiating outside of secure
        areas, agencies cannot rely on the traditional approach of physical security
        to protect against unauthorised access to sensitive or classified information
        on wireless networks. Using the AES based Counter Mode with Cipher Block Chaining
        Message Authentication Code Protocol (CCMP) helps protect the confidentiality
        and integrity of all wireless network traffic.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:12
      ref_id: 18.2.16.C.01
      name: 'Control -  All Classifications - Must [CID: 3368]'
      description: CCMP MUST be used to protect the confidentiality and integrity
        of all wireless network traffic.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Temporal Key Integrity Protocol (TKIP) and Wireless Encryption
        Protocol (WEP)
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:13
      ref_id: 18.2.17.R.01
      description: "CCMP was introduced in WPA2 to address feasible attacks against\
        \ the Temporal Integrity Key Protocol (TKIP) used by the Wi-Fi Protected Access\
        \ (WPA) protocol as well as the original Wireless Encryption Protocol (WEP).\
        \ \_A malicious actor seeking to exploit vulnerabilities in TKIP and WEP can\
        \ attempt to connect to wireless access points using one of these protocols.\
        \ \_By default, wireless access points will attempt to accommodate this request\
        \ by falling back to a legacy protocol that the device supports. \_Disabling\
        \ or removing TKIP and WEP support from wireless access points ensures that\
        \ wireless access points do not fall back to an insecure encryption protocol."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:13
      ref_id: 18.2.17.C.01
      name: 'Control -  All Classifications - Must [CID: 3373]'
      description: TKIP and WEP support MUST be disabled or removed from wireless
        access points.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Wired Equivalent Privacy (WEP)
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:14
      ref_id: 18.2.18.R.01
      description: "WEP has serious flaws which allow it to be trivially compromised.\
        \ \_A WEP network should be considered equivalent to an unprotected network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:14
      ref_id: 18.2.18.C.01
      name: 'Control -  All Classifications - Must Not [CID: 3379]'
      description: Agencies MUST NOT use WEP for wireless deployments.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Wi-Fi Protected Access (WPA)
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:15
      ref_id: 18.2.19.R.01
      description: 'As wireless networks are often capable of being accessed from
        outside the perimeter of secured spaces, all wireless network traffic requires
        suitable cryptographic protection. For this purpose, it is recommended that
        Wi-Fi Protected Access 3 (WPA3) be used as it provides equivalent or greater
        security than its predecessor Wi-Fi Protected Access 2 (WPA2).

        WPA3 has also prohibited the use of various outdated and insecure cipher suites.
        WPA3-Enterprise supports three enterprise modes of operation: enterprise only
        mode, transition mode and 192-bit mode. Preference is given to WPA3-Enterprise
        192-bit mode as this mode ensures no algorithms with known weaknesses are
        used.'
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:15
      ref_id: 18.2.19.C.01
      name: 'Control -  All Classifications - Must Not [CID: 7539]'
      description: Agencies MUST NOT use Wi-Fi Protected Access (WPA) for wireless
        deployments.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:15
      ref_id: 18.2.19.C.02
      name: 'Control -  All Classifications - Should Not [CID: 3386]'
      description: Agencies SHOULD NOT use Wi-Fi Protected Access 2 (WPA2) for wireless
        deployments.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.19.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:15
      ref_id: 18.2.19.C.03
      name: 'Control -  All Classifications - Should [CID: 7540]'
      description: Agencies SHOULD use Wi-Fi Protected Access 3 (WPA3) for wireless
        deployments with preference given to WPA3-Enterprise 192-bit mode.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:16
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Pre-shared keys
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:16
      ref_id: 18.2.20.R.01
      description: The use of pre-shared keys is poor practice and not recommended
        for wireless authentication, in common with many authentication and encryption
        mechanisms, the greater the length of pre-shared keys the greater the security
        they provide.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:16
      ref_id: 18.2.20.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 3391]'
      description: Agencies MUST NOT use pre-shared keys for wireless authentication.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:16
      ref_id: 18.2.20.C.02
      name: 'Control -  All Classifications - Should [CID: 3392]'
      description: If pre-shared keys are used, agencies SHOULD use random keys of
        the maximum allowable length.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:16
      ref_id: 18.2.20.C.03
      name: 'Control -  All Classifications - Should Not [CID: 3393]'
      description: Agencies SHOULD NOT use pre-shared keys for wireless authentication.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Administrative interfaces for wireless access points
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:17
      ref_id: 18.2.21.R.01
      description: "Administrative interfaces may allow users to modify the configuration\
        \ and security settings of wireless access points. \_Often wireless access\
        \ points by default allow users to access the administrative interface over\
        \ methods such as fixed network connections, wireless network connections\
        \ and serial connections directly on the device. \_Disabling the administrative\
        \ interface on wireless access points will prevent unauthorised connections."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:17
      ref_id: 18.2.21.C.01
      name: 'Control -  All Classifications - Should [CID: 3397]'
      description: Agencies SHOULD disable the administrative interface on wireless
        access points for wireless connections.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:18
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Protecting management frames on wireless networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:18
      ref_id: 18.2.22.R.01
      description: Effective DoS attacks can be performed on the 802.11 protocol by
        exploiting unprotected management frames using inexpensive commercial hardware.
        WPA2 provides no protection for management frames and therefore does not prevent
        spoofing or DoS attacks. Note, in WPA3 this feature is built into the standard.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.22.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:18
      ref_id: 18.2.22.R.02
      description: The current release of the 802.11 standard provides no protection
        for management frames and therefore does not prevent spoofing or DoS attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.22.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:18
      ref_id: 18.2.22.R.03
      description: "However, 802.11w was ratified in 2009 and specifically addresses\
        \ the protection of management frames on wireless networks. \_Wireless access\
        \ points and devices should be upgraded to support the 802.11w amendment or\
        \ any later amendment or version that includes a capability for the protection\
        \ of management frames."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:18
      ref_id: 18.2.22.C.01
      name: 'Control -  All Classifications - Should [CID: 3408]'
      description: Wireless access points and devices SHOULD be upgraded to support
        a minimum of the 802.11w amendment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:19
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Default service set identifiers (SSIDs)
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:19
      ref_id: 18.2.23.R.01
      description: "All wireless access points are configured with a default Service\
        \ Set Identifier (SSID). \_The SSID is commonly used to identify the name\
        \ of a wireless network to users. \_As the default SSIDs of wireless access\
        \ points are well documented on online forums, along with default accounts\
        \ and passwords, it is important to change the default SSID and default passwords\
        \ of wireless access points."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:19
      ref_id: 18.2.23.C.01
      name: 'Control -  All Classifications - Must [CID: 3416]'
      description: Agencies MUST change the default SSID of wireless access points.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.23.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:19
      ref_id: 18.2.23.C.02
      name: 'Control -  All Classifications - Must [CID: 3418]'
      description: Agencies MUST rename or remove default accounts and passwords.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:20
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Changing the SSID
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:20
      ref_id: 18.2.24.R.01
      description: "When changing the default SSID, it is important that it lowers\
        \ the profile of an agency\u2019s wireless network. \_In doing so, the SSID\
        \ of a wireless network should not be readily associated with an agency, the\
        \ location of or within their premises, or the functionality of the network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.24.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:20
      ref_id: 18.2.24.R.02
      description: This procedure applies to all wireless network assets owned/or
        managed by the agency, including any guest or other publicly accessible networks.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:20
      ref_id: 18.2.24.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3505]'
      description: The SSID of a wireless network SHOULD NOT be readily associated
        with an agency, the premises, location or the functionality of the network.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: SSID Broadcasting
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:21
      ref_id: 18.2.25.R.01
      description: "A common method to lower the profile of wireless networks is disabling\
        \ SSID broadcasting. \_While this ensures that the existence of wireless networks\
        \ are not broadcast overtly using beacon frames, the SSID is still broadcast\
        \ in probe requests, probe responses, association requests and re-association\
        \ requests for the network. \_Malicious actors can determine the SSID of wireless\
        \ networks by capturing these requests and responses. \_By disabling SSID\
        \ broadcasting agencies will make it more difficult for legitimate users to\
        \ connect to wireless networks as legacy operating systems have only limited\
        \ support for hidden SSIDs. \_Disabling SSID broadcasting infringes the design\
        \ of the 802.11x standards."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.25.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:21
      ref_id: 18.2.25.R.02
      description: "A further risk exists where an intruder can configure a wireless\
        \ access point to broadcast the same SSID as the hidden SSID used by a legitimate\
        \ wireless network. In this scenario devices will automatically connect to\
        \ the wireless access point that is broadcasting the SSID they are configured\
        \ to use before probing for a wireless access point that accepts the hidden\
        \ SSID. Once the device is connected to the intruder\u2019s wireless access\
        \ point the intruder can steal authentication credentials from the device\
        \ to perform an adversary-in-the-middle attack to capture legitimate wireless\
        \ network traffic or to later reuse to gain access to the legitimate wireless\
        \ network."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.25.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:21
      ref_id: 18.2.25.R.03
      description: Disabling SSID broadcasting is not considered to be an effective
        control and may introduce additional risks.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:21
      ref_id: 18.2.25.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3514]'
      description: Agencies SHOULD NOT disable SSID broadcasting on wireless networks.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:22
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Static addressing
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:22
      ref_id: 18.2.26.R.01
      description: "Rogue devices or Access Points (APs) are unauthorised Wireless\
        \ Access Points operating outside of the control of an agency. \_Assigning\
        \ static IP addresses for devices accessing wireless networks can prevent\
        \ a rogue device when connecting to a network from being assigned a routable\
        \ IP address. \_However, some malicious actors will be able to determine IP\
        \ addresses of legitimate users and use this information to guess or spoof\
        \ valid IP address ranges for wireless networks. \_Configuring devices to\
        \ use static IP addresses introduces a management overhead without any tangible\
        \ security benefit."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:22
      ref_id: 18.2.26.C.01
      name: 'Control -  All Classifications - Should [CID: 3520]'
      description: Agencies SHOULD use the Dynamic Host Configuration Protocol (DHCP)
        for assigning IP addresses on wireless networks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:23
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Media Access Control address filtering
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:23
      ref_id: 18.2.27.R.01
      description: "Devices that connect to wireless networks have a unique Media\
        \ Access Control (MAC) address. \_It is possible to use MAC address filtering\
        \ on wireless access points to restrict which devices can connect to wireless\
        \ networks. \_While this approach will introduce a management overhead of\
        \ configuring allow lists of approved MAC addresses, it can prevent rogue\
        \ devices from connecting to wireless networks. \_However, some malicious\
        \ actors will be able to determine valid MAC addresses of legitimate users\
        \ already on wireless networks and use this information to spoof valid MAC\
        \ addresses and gain access to a network. \_MAC address filtering introduces\
        \ a management overhead without any real tangible security benefit."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:23
      ref_id: 18.2.27.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3529]'
      description: MAC address filtering SHOULD NOT be used as a security mechanism
        to restrict which devices connect to a wireless network.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:24
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Documentation
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:24
      ref_id: 18.2.28.R.01
      description: Wireless device driver and WAP vulnerabilities are very exposed
        to the threat environment and require specific attention as exploits can gain
        immediate unauthorised access to the network.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:24
      ref_id: 18.2.28.C.01
      name: 'Control -  All Classifications - Should [CID: 3533]'
      description: Key generation, distribution and rekeying procedures SHOULD be
        documented in the SecPlan for the wireless network.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.28.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:24
      ref_id: 18.2.28.C.02
      name: 'Control -  All Classifications - Should [CID: 3534]'
      description: Wireless device drivers and their versions SHOULD be documented
        in the SecPlan for the wireless network.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Non-agency devices connecting to agency controlled wireless networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      ref_id: 18.2.29.R.01
      description: "As agencies have no control over the security of non-agency devices\
        \ or knowledge of the security posture of such devices, allowing them to connect\
        \ to agency controlled wireless networks poses a serious threat. \_Of particular\
        \ concern is that non-agency devices may be infected with viruses, malware\
        \ or other malicious code that could crossover onto the agency network. \_\
        Furthermore, any non-agency devices connecting to agency controlled wireless\
        \ networks will take on the classification of the network and will need to\
        \ be appropriately sanitised and declassified before being released back to\
        \ their owners."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.29.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      ref_id: 18.2.29.R.02
      description: "The practice of Bring Your Own Device (BYOD) is becoming more\
        \ widespread but introduces a significant number of additional risks to agency\
        \ systems. \_Refer to Section 21.4 for guidance on the use of BYOD."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      ref_id: 18.2.29.C.01
      name: 'Control -  All Classifications - Must [CID: 3583]'
      description: Where BYOD has been approved by an agency, any wireless network
        allowing BYOD connections MUST be segregated from all other agency networks,
        including any agency wireless networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.29.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      ref_id: 18.2.29.C.02
      name: 'Control -  All Classifications - Must [CID: 3586]'
      description: "Any BYOD devices MUST comply with the policies and configuration\
        \ described in Section 21.4\u2013 BYOD."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.29.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:25
      ref_id: 18.2.29.C.03
      name: 'Control -  All Classifications - Must Not [CID: 3588]'
      description: Agencies MUST NOT allow non-agency devices to connect to agency
        controlled wireless networks not intended or configured for BYOD devices or
        for public access.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:26
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Agency devices connecting to non-agency controlled wireless networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.30.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:26
      ref_id: 18.2.30.R.01
      description: When agency devices connect to non-agency controlled wireless networks,
        particularly public wireless networks, the devices may be exposed to viruses,
        malware or other malicious code.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.30.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:26
      ref_id: 18.2.30.R.02
      description: If any agency device becomes infected and is later connected to
        an agency controlled wireless network then a crossover of viruses, malware
        or malicious code could occur.
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.30.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:26
      ref_id: 18.2.30.C.01
      name: 'Control -  All Classifications - Should Not [CID: 3600]'
      description: Agencies SHOULD NOT allow agency devices to connect to non-agency
        controlled wireless networks.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:27
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Connecting wireless networks to fixed networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.31.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:27
      ref_id: 18.2.31.R.01
      description: "When an agency has a business requirement to connect a wireless\
        \ network to a fixed network, it is important that they consider the security\
        \ risks. While fixed networks can be designed with a certain degree of physical\
        \ security, wireless networks are often easily accessible outside of the agency\u2019\
        s controlled area. \_Treating connections between wireless networks and fixed\
        \ networks in the same way agencies would treat connections between fixed\
        \ networks and the Internet can help protect against an intrusion originating\
        \ from a wireless network against a fixed network. \_For example, agencies\
        \ can implement a gateway to inspect and control the flow of information between\
        \ the two networks."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.31.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:27
      ref_id: 18.2.31.C.01
      name: 'Control -  All Classifications - Should [CID: 3609]'
      description: Connections between wireless networks and fixed networks SHOULD
        be treated in the same way as connections between fixed networks and the Internet.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:28
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Wireless network footprint and Radio Frequency (RF) Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.32.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:28
      ref_id: 18.2.32.R.01
      description: "Minimising the output power of wireless access points will reduce\
        \ the footprint of wireless networks. \_Instead of deploying a small number\
        \ of wireless access points that broadcast on high power, more wireless access\
        \ points that use minimal broadcast power should be deployed to achieve the\
        \ desired wireless network footprint. \_This has the added benefit of providing\
        \ redundancy for a wireless network should a wireless access point become\
        \ unserviceable. \_In such a case, the output power of other wireless access\
        \ points can be temporarily increased to cover the footprint gap until the\
        \ unserviceable wireless access point can be replaced."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.32.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:28
      ref_id: 18.2.32.C.01
      name: 'Control -  All Classifications - Should [CID: 3614]'
      description: Instead of deploying a small number of wireless access points that
        broadcast on high power, more wireless access points that use minimal broadcast
        power SHOULD be deployed to achieve the desired wireless network footprint.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:29
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Radio Frequency (RF) Propagation & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.33.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:29
      ref_id: 18.2.33.R.01
      description: "An additional method to limit a wireless network\u2019s footprint\
        \ is through the use of radio frequency (RF) shielding on an agency\u2019\
        s premises. \_While expensive, this will limit the wireless communications\
        \ to areas under the control of an agency. RF shielding on an agency\u2019\
        s premises has the added benefit of preventing the jamming of wireless networks\
        \ from outside of the premises in which wireless networks are operating."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.33.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:29
      ref_id: 18.2.33.C.01
      name: 'Control -  All Classifications - Should [CID: 3617]'
      description: "The effective range of wireless communications outside an agency\u2019\
        s area of control SHOULD be limited by:\nMinimising the output power level\
        \ of wireless devices.\nImplementing RF shielding within buildings in which\
        \ wireless networks are used.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.2:4:30
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4
      description: Interference between wireless networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.34.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:30
      ref_id: 18.2.34.R.01
      description: "Where multiple wireless networks are deployed in close proximity,\
        \ there is the potential for RF interference to adversely impact the availability\
        \ of the network, especially when networks are operating on commonly used\
        \ default channels of 1 and 11. \_This interference is also apparent where\
        \ a large number of wireless networks are is use in close proximity to the\
        \ agency\u2019s premises."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.34.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:30
      ref_id: 18.2.34.R.02
      description: "Sufficiently separating wireless networks through the use of channel\
        \ separation can help reduce this risk. \_This can be achieved by using wireless\
        \ networks that are configured to operate with at least one channel separation.\
        \ \_For example, channels 1, 3 and 5 could be used to separate three wireless\
        \ networks."
    - urn: urn:defend:risk:req_node:nzism-v3:18.2.34.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.2:4:30
      ref_id: 18.2.34.C.01
      name: 'Control -  All Classifications - Should [CID: 3621]'
      description: Wireless networks SHOULD use channel separation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.3'
      name: Video & Telephony Conferencing and Internet Protocol Telephony
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:1
      ref_id: 18.3.1
      description: "Video & Telephony Conferencing (VTC), Internet Protocol Telephony\
        \ (IPT) and Voice over Internet Protocol (VoIP) systems are implemented in\
        \ a secure manner that does not compromise security, information or systems\
        \ and that they\_operate securely."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2:1
      ref_id: 18.3.2
      description: "This section covers information on VTC and IPT including Voice\
        \ over Internet Protocol (VoIP). \_Although IPT refers generally to the transport\
        \ of telephone calls over IP networks, the scope of this section includes\
        \ connectivity to the PSTN as well as remote sites."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2:1
      ref_id: 18.3.3
      description: "Additional information relating to topics covered in this section\
        \ can be found in\nChapter 12 \u2013 Product Security;\nChapter 11 \u2013\
        \ Communications Systems and Devices;\nChapter 19 \u2013 Gateways Security;\
        \ and\nany section in this manual relating to the protection of data networks.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2
      description: Exception for VTC and IPT gateways
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2:2
      ref_id: 18.3.4
      description: "Where a gateway connects between an analogue telephone network\
        \ such as the PSTN and a computer network, Chapter 19 \u2013 Gateway Security\_\
        \ does not apply."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2:2
      ref_id: 18.3.5
      description: "Where a gateway connects between a VTC or IPT network and any\
        \ other VTC or IPT network, Chapter 19 \u2013 Gateway Security applies."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2
      description: Hardening VTC and IPT systems
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:2:3
      ref_id: 18.3.6
      description: 'Data in a VTC or IPT network consists of IP packets and should
        not be treated any differently to other data. In accordance with the principles
        of least-privilege and security-in-depth, hardening can be applied to all
        handsets, control units, software, servers and gateways. For example a Session
        Initiation Protocol (SIP) server could:

        have a fully patched software and operating system;

        only required services running;

        use encrypted non-replayable authentication; and

        apply network restrictions that only allow secure Session Initiation Protocol
        (SIP) and secure Real Time Transport (RTP) traffic from IP phones on a VLAN
        to reach the server.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:3
      ref_id: 18.3.7
      description: "\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\nSP 800-58\n\n\
        \nSecurity Considerations for Voice Over IP Systems\n\n\nNIST\n\n\nhttps://csrc.nist.gov/publications/sp\n\
        \n\n\n\_\n\nSecurity Issues and Countermeasure for VoIP\n\nSANS\n\nhttps://www.sans.org/white-papers/1701/\n\
        \n\n\n\nReport Number: I332-016R-2005\n\n\nSecurity Guidance for Deploying\
        \ IP Telephony Systems Released: 14 February 2006\n\n\nSystems and Network\
        \ Attack Center (SNAC) NSA\n\n\nhttps://www.nsa.gov/ia/_files/voip/i332-016r-2005.pdf\n\
        \n\n\n\nReport Number: I332-009R-2006\n\n\nRecommended IP Telephony Architecture,\
        \ Updated: 1 May 2006 Version 1.0\n\n\nSystems and Network Attack Center (SNAC)\
        \ NSA\n\n\nhttps://www.nsa.gov/ia/_files/voip/I332-009R-2006.pdf\n\n\n\n\_\
        \n\nMobility Capability Package March 26 2012 - Secure VoIP Version 1.2\n\n\
        \nNSA\n\n\nhttps://www.nsa.gov/ia/_files/Mobility_Capability_Pkg_Vers_1_2.pdf\n\
        \n\n\n\_\n\nProtecting Telephone-based Payment Card Data PCI Data Security\
        \ Standard (PCI DSS) Version: 2.0, March 2011\n\n\nThe PCI Security Standards\
        \ Council (PCI SSC)\n\n\nhttps://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf\
        \ [PDF, 888 KB]\n\n\n\n\_\n\nPCI Mobile Payment Acceptance Security Guidelines\
        \ Version: 1.0 Date: September 2012\n\n\nPCI SSC\n\n\nhttps://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Developers_v1.pdf\
        \ [PDF, 579 KB]\n\n\n\n\_\n\nPCI Mobile Payment Acceptance Security Guidelines\
        \ Version: 1.0 Date: February 2013\n\n\nPCI SSC\n\n\nhttps://www.pcisecuritystandards.org/documents/Mobile_Payment_Security_Guidelines_Merchants_v1.pdf\
        \ [PDF, 630 KB]\n\n\n\n\_\n\nUnderstanding Voice over Internet Protocol (VoIP):\
        \ 2006\n\n\nUS-CERT\n\n\nhttps://www.us-cert.gov/sites/default/files/publications/understanding_voip.pdf\
        \ [PDF, 83 KB]\n\n\n\n\nCNSS Instruction No. 5000 April 2007\n\n\nGuidelines\
        \ for Voice over Internet Protocol (VoIP) Computer Telephony\n\n\nCommittee\
        \ on National Security Systems\n\n\nhttps://www.cnss.gov/CNSS/issuances/Instructions.cfm\n\
        \n\n\n\n\_DHS 4300A\n\nDHS 4300A Sensitive Systems Handbook Attachment Q5\
        \ To Handbook v. 11.0 Voice over Internet Protocol (VoIP) Version 11.0 December\
        \ 22, 2014\nDHS\nhttps://www.dhs.gov/sites/default/files/publications/4300A%20Handbook%20Attachment%20Q5%20-%20Voice%20over%20IP.pdf\
        \ [PDF, 586 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Video and voice-aware firewalls
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:1
      ref_id: 18.3.8.R.01
      description: The use of video, unified communications and voice-aware firewalls
        ensures that only video or voice traffic (e.g. signalling and data) is allowed
        for a given call and that the session state is maintained throughout the transaction.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:1
      ref_id: 18.3.8.R.02
      description: "The requirement to use a video, unified communication or voice-aware\
        \ firewall does not necessarily require separate firewalls to be deployed\
        \ for video conferencing, IP telephony and data traffic. \_If possible, agencies\
        \ are encouraged to implement one firewall that is either video and data-aware;\
        \ voice and data-aware; or video, voice and data-aware depending on their\
        \ needs."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:1
      ref_id: 18.3.8.R.03
      description: Refer to Section 19.5 - Session Border Controllers.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:1
      ref_id: 18.3.8.C.01
      name: 'Control -  All Classifications - Should [CID: 3721]'
      description: Agencies SHOULD use a video, unified communication or voice-aware
        firewall that meets the same minimum level of assurance as specified for normal
        firewalls.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Protecting IPT signalling and data
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:2
      ref_id: 18.3.9.R.01
      description: "IPT voice and signalling data is vulnerable to eavesdropping but\
        \ can be protected with encryption. \_This control helps protect against DoS,\
        \ adversary-in-the-middle, and call spoofing attacks made possible by inherent\
        \ weaknesses in the VTC and IPT protocols."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:2
      ref_id: 18.3.9.R.02
      description: "When protecting IPT signalling and data, voice control signalling\
        \ can be protected using TLS and the \u2018sips://\u2019 identifier to force\
        \ the encryption of all legs of the connection. \_Similar protections are\
        \ available for RTP and the Real-Time Control Protocol."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:2
      ref_id: 18.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 3728]'
      description: Agencies SHOULD protect VTC and IPT signalling and data by using
        encryption.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:2
      ref_id: 18.3.9.C.02
      name: 'Control -  All Classifications - Should [CID: 3729]'
      description: An encrypted and non-replayable two-way authentication scheme SHOULD
        be used for call authentication and authorisation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Establishment of secure signalling and data protocols
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:3
      ref_id: 18.3.10.R.01
      description: Use of secure signalling and data protects against eavesdropping,
        some types of DoS, adversary-in-the-middle, and call spoofing attacks.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:3
      ref_id: 18.3.10.C.01
      name: 'Control -  All Classifications - Should [CID: 3732]'
      description: Agencies SHOULD ensure that VTC and IPT functions are established
        using only the secure signalling and data protocols.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Local area network traffic separation
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:4
      ref_id: 18.3.11.R.01
      description: Availability and quality of service are the main drivers for applying
        the principles of separation and segregation.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:4
      ref_id: 18.3.11.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3735]'
      description: Agencies MUST either separate or segregate the VTC and IPT traffic
        from other data traffic.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:4
      ref_id: 18.3.11.C.02
      name: 'Control -  All Classifications - Should [CID: 3736]'
      description: Agencies SHOULD either separate or segregate the IPT traffic from
        other data traffic.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: VTC and IPT Device setup
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:5
      ref_id: 18.3.12.R.01
      description: VTC equipment and VoIP phones need to be hardened and separated
        or segregated from the data network to ensure they will not provide an easy
        entry point to the network for an attacker.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:5
      ref_id: 18.3.12.R.02
      description: "USB ports on these devices can be used to circumvent USB workstation\
        \ policy and upload malicious software for unauthorised call recording/spoofing\
        \ and entry into the data network. \_Unauthorised or unauthenticated devices\
        \ should be blocked by default to reduce the risk of a compromise or denial\
        \ of service."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:5
      ref_id: 18.3.12.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3740]'
      description: "Agencies MUST:\nconfigure VTC and VoIP devices to authenticate\
        \ themselves to the call controller upon registration;\ndisable phone auto-registration\
        \ and only allow an allow list of authorised devices to access the network;\n\
        block unauthorised devices by default;\_\ndisable all unused and prohibited\
        \ functionality; and\nuse individual logins for IP phones.\n"
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:5
      ref_id: 18.3.12.C.02
      name: 'Control -  All Classifications - Should [CID: 3741]'
      description: "Agencies SHOULD:\nconfigure VoIP phones to authenticate themselves\
        \ to the call controller upon registration;\ndisable phone auto-registration\
        \ and use an allow list of authorised devices to access the network;\nblock\
        \ unauthorised devices by default;\_\ndisable all unused and prohibited functionality;\
        \ and\nuse individual logins for IP phones.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Call authentication and authorisation
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:6
      ref_id: 18.3.13.R.01
      description: This control ensures server-client mutual authentication.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:6
      ref_id: 18.3.13.C.01
      name: 'Control -  All Classifications - Should [CID: 3745]'
      description: 'Authentication and authorisation SHOULD be used for all actions
        on the IPT network, including:

        call setup;

        changing settings; and

        checking voice mail.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:6
      ref_id: 18.3.13.C.02
      name: 'Control -  All Classifications - Should [CID: 3747]'
      description: An encrypted and non-replayable two-way authentication scheme SHOULD
        be used for call authentication and authorisation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:6
      ref_id: 18.3.13.C.03
      name: 'Control -  All Classifications - Should [CID: 3748]'
      description: 'Authentication SHOULD be enforced for:

        registering a new phone;

        changing phone users;

        changing settings; and

        accessing voice mail.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: VTC and IPT device connection to workstations
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:7
      ref_id: 18.3.14.R.01
      description: Availability and quality of service are the main drivers for applying
        the principles of separation and segregation.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:7
      ref_id: 18.3.14.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must Not [CID: 3751]'
      description: Agencies MUST NOT connect workstations to VTC or IPT devices unless
        the workstation or the device, as appropriate for the configuration, uses
        VLANs or similar mechanisms to maintain separation between VTC, IPT and other
        data traffic.
      implementation_groups:
      - Secret - MUST NOT
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:7
      ref_id: 18.3.14.C.02
      name: 'Control -  All Classifications - Should Not [CID: 3752]'
      description: Agencies SHOULD NOT connect workstations to VTC or IPT devices
        unless the workstation or the device, as appropriate for the configuration,
        uses VLANs or similar mechanisms to maintain separation between VTC, IPT and
        other data traffic.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Lobby and shared area IPT devices
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:8
      ref_id: 18.3.15.R.01
      description: "IPT devices in public areas may give an attacker opportunity to\
        \ access the internal data network by replacing the phone with another device,\
        \ or installing a device in-line. \_There is also a risk to the voice network\
        \ of social engineering (since the call may appear to be internal) and data\
        \ leakage from poorly protected voice mail-boxes."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:8
      ref_id: 18.3.15.C.01
      name: 'Control -  All Classifications - Should [CID: 3756]'
      description: "Where an agency uses a VoIP phone in a lobby or shared area they\
        \ SHOULD limit or disable the phone\u2019s:\nability to access data networks;\_\
        \nfunctionality for voice mail and directory services; and\nuse a separate\
        \ network segment.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:8
      ref_id: 18.3.15.C.02
      name: 'Control -  All Classifications - Should [CID: 3758]'
      description: Agencies SHOULD, where available, use traditional analogue phones
        in a lobby and shared areas.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Usage of softphones, webcams and similar sound and video devices
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      ref_id: 18.3.16.R.01
      description: Software and applications for softphones and webcams can introduce
        additional attack vectors into the network as they are exposed to threats
        from the data network via the workstation and can subsequently be used to
        gain access to the network.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.16.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      ref_id: 18.3.16.R.02
      description: "Softphones and webcams typically require workstation to workstation\
        \ communication, normally using a number of randomly assigned ports to facilitate\
        \ RTP data exchange. \_This presents a security risk as workstations generally\
        \ should be separated using host-based firewalls that deny all connections\
        \ between workstations to make malicious code propagation inside the network\
        \ difficult."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      ref_id: 18.3.16.C.01
      name: 'Control -  All Classifications - Should [CID: 3766]'
      description: Agencies using softphones or webcams SHOULD have separate dedicated
        network interface cards on the host for VTC or IPT network access to facilitate
        VLAN separation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      ref_id: 18.3.16.C.02
      name: 'Control -  All Classifications - Should [CID: 3768]'
      description: Agencies using softphones or webcams SHOULD install a host-based
        firewall on workstations utilising softphones or webcams that allows traffic
        only to and from a minimum number of ports.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:9
      ref_id: 18.3.16.C.03
      name: 'Control -  Top Secret, Confidential, Secret - Should Not [CID: 3770]'
      description: Agencies SHOULD NOT use softphones or webcams.
      implementation_groups:
      - Top Secret - SHOULD NOT
      - Confidential - SHOULD NOT
      - Secret - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Workstations using USB softphones, webcams and similar sound and
        video devices
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:10
      ref_id: 18.3.17.R.01
      description: Adding softphones and webcams to an allow list of allowed USB devices
        on a workstation will assist with restricting access to only authorised devices,
        and allowing the SOE to maintain defences against removable media storage
        and other unauthorised USB devices.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:10
      ref_id: 18.3.17.C.01
      name: 'Control -  All Classifications - Should [CID: 3777]'
      description: Agencies SHOULD use access control software to control USB ports
        on workstations using softphones and webcams by utilising the specific vendor
        and product identifier of the authorised device.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Developing a denial of service response plan
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:11
      ref_id: 18.3.18.R.01
      description: "Communications are considered critical for any business and are\
        \ therefore especially vulnerable to Denial of Service (DoS). \_The guidance\
        \ provided will assist in protecting against VTC or IPT DoS attacks, signalling\
        \ floods, established call teardown and RTP data floods. \_These elements\
        \ should be included in the agency\u2019s wider response plan (See Section\
        \ 6.4 \u2013 Business Continuity and Disaster Recovery)."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.18.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:11
      ref_id: 18.3.18.R.02
      description: "Simple DoS attacks and incidents are often the result of bandwidth\
        \ exhaustion. \_Agencies should also consider other forms of DoS including\
        \ Distributed Denial of Service attacks (DdoS), DNS and latency incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.18.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:11
      ref_id: 18.3.18.R.03
      description: System resilience can be improved by architecting a structured
        approach and providing layered defence such as network and application protection
        as separate layers.
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:11
      ref_id: 18.3.18.C.01
      name: 'Control -  All Classifications - Should [CID: 3782]'
      description: "Agencies SHOULD develop a Denial of Service response plan including:\n\
        how to identify the precursors and other signs of DoS;\nhow to diagnose the\
        \ incident or attack type and attack method;\nhow to diagnose the source of\
        \ the DoS;\nwhat actions can be taken to clear the DoS;\_\nhow communications\
        \ can be maintained during a DoS; and\nreport the incident.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.3:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4
      description: Content of a Denial of Service (DoS) response plan
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:12
      ref_id: 18.3.19.R.01
      description: 'An VTC or IPT DoS response plan will need to address the following:

        how to identify the source of the DoS, either internal or external (location
        and content of logs);

        how to diagnose the incident or attack type and attack method;

        how to minimise the effect on VTC or IPT, of a DoS of the data network (e.g.
        Internet or internal DoS), including separate links to other office locations
        for VTC and IPT and/or quality of service prioritisation;

        strategies that can mitigate the DOS (banning certain devices/Ips at the call
        controller and firewalls, implementing quality of service, changing VoIP authentication,
        changing dial-in authentication; and

        alternative communication options (such as designated devices or personal
        mobile phones) that have been identified for use in case of an emergency.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:18.3.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.3:4:12
      ref_id: 18.3.19.C.01
      name: 'Control -  All Classifications - Should [CID: 3785]'
      description: "A Denial of Service response plan SHOULD include monitoring and\
        \ use of:\nrouter and switch logging and flow data;\npacket captures;\nproxy\
        \ and call manager logs and access control lists;\nVTC and IPT aware firewalls\
        \ and voice gateways;\nnetwork redundancy;\nload balancing;\_\nPSTN failover;\
        \ and\nalternative communication paths.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.4'
      name: Intrusion Detection and Prevention
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:1
      ref_id: 18.4.1
      description: An intrusion detection and prevention strategy is implemented for
        systems in order to respond promptly to incidents and preserve availability,
        confidentiality and integrity of systems.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:2:1
      ref_id: 18.4.2
      description: This section covers information relating to detection and prevention
        of malicious code propagating through networks as well as the detection and
        prevention of unusual or malicious activities.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:2
      description: Methods of infections or delivery
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:2:2
      ref_id: 18.4.3
      description: "Malicious code can spread through a system from a number of sources\
        \ including:\nfiles containing macro viruses or worms;\nemail attachments\
        \ and Web downloads with malicious active content;\nexecutable code in the\
        \ form of applications;\nsecurity weaknesses in a system or network;\nsecurity\
        \ weaknesses in an application;\_\ncontact with an infected system or media;\
        \ or\ndeliberate introduction of malicious code.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:2:2
      ref_id: 18.4.4
      description: The speed at which malicious code can spread through a system presents
        significant challenges and an important part of any defensive strategy is
        to contain the attack and limit damage.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:3
      ref_id: 18.4.5
      description: "\n\n\nReference\nTitle\n\nPublisher\n\n\nSource\n\n\n\n\nISO/IEC\
        \ 27001:2013\n\n\nInformation technology \u2014 Security techniques \u2014\
        \ Information security management systems \u2014 Requirements, A.15.3,\_Information\
        \ Systems Audit Considerations\n\n\nISO\n\n\nhttps://www.iso.org/standard/54534.html\n\
        \n\n\nHB 171:2003\nGuidelines for the Management of Information Technology\
        \ Evidence\nStandards NZ\n\nhttps://www.saiglobal.com/PDFTemp/Previews/OSH/as/misc/handbook/HB171.PDF\
        \ [PDF, 350 KB]\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4
      name: References - Endpoint Security
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:4
      ref_id: 18.4.6
      description: "\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_\nTransport Layer\
        \ Protection\_Cheat Sheet\nOWASP\nhttps://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet\_\
        \n\n\nRFC 5246\nThe Transport Layer Security (TLS) Protocol Version 1.2\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc5246\n\n\nRFC 8446\nThe Transport\
        \ Layer Security (TLS) Protocol Version 1.3\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc8446\n\
        \n\nRFC 7525\nRecommendations for Secure Use of Transport Layer Security (TLS)\
        \ and Datagram Transport Layer Security (DTLS)\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc7525\n\
        \n\nRFC 6749\nThe OAuth 2.0\_Authorization Framework\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc6749\n\
        \n\n\_\nOpenID Connect\nOpenID Foundation\nhttps://openid.net/connect/\n\n\
        \n\_\nNew Zealand Security Assertion Messaging Standard\_\n\nNZ Government\n\
        Department of internal affairs\n\nNew Zealand Security Assertion Messaging\
        \ Standard | NZ Digital government\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Intrusion Detection and Prevention strategy (IDS/IPS)
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:1
      ref_id: 18.4.7.R.01
      description: An IDS/IPS when configured correctly, kept up to date and supported
        by appropriate processes, can be an effective way of identifying, responding
        to and containing known attack types, specific attack profiles or anomalous
        or suspicious network activities.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:1
      ref_id: 18.4.7.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3802]'
      description: 'Agencies MUST develop, implement and maintain an intrusion detection
        strategy that includes:

        appropriate intrusion detection mechanisms, including network-based IDS/IPSs
        and host-based IDS/IPSs as necessary;

        the audit analysis of event logs, including IDS/IPS logs;

        a periodic audit of intrusion detection procedures;

        information security awareness and training programs;

        a documented Incident Response Plans (IRP); and

        provide the capability to detect information security incidents and attempted
        network intrusions on gateways and provide real-time alerts.

        '
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:1
      ref_id: 18.4.7.C.02
      name: 'Control -  All Classifications - Should [CID: 3803]'
      description: 'Agencies SHOULD develop, implement and maintain an intrusion detection
        strategy that includes:

        appropriate intrusion detection mechanisms, including network-based IDS/IPSs
        and host-based IDS/IPSs as necessary;

        the audit analysis of event logs, including IDS/IPS logs;

        a periodic audit of intrusion detection procedures;

        information security awareness and training programs; and

        a documented IRP.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.7.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:1
      ref_id: 18.4.7.C.03
      name: 'Control -  All Classifications - Should [CID: 3804]'
      description: Agencies SHOULD ensure sufficient resources are provided for the
        maintenance and monitoring of IDS/IPS.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: IDS/IPSs on gateways
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:2
      ref_id: 18.4.8.R.01
      description: If the firewall is configured to block all traffic on a particular
        range of port numbers, then the IDS should inspect traffic for these port
        numbers and alert if they are detected.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:2
      ref_id: 18.4.8.C.01
      name: 'Control -  All Classifications - Should [CID: 3807]'
      description: "Agencies SHOULD deploy IDS/IPSs in all gateways between the agency\u2019\
        s networks and unsecure public networks or BYOD wireless networks."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:2
      ref_id: 18.4.8.C.02
      name: 'Control -  All Classifications - Should [CID: 3808]'
      description: "Agencies SHOULD deploy IDS/IPSs at all gateways between the agency\u2019\
        s networks and any network not managed by the agency."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:2
      ref_id: 18.4.8.C.03
      name: 'Control -  All Classifications - Should [CID: 3809]'
      description: Agencies SHOULD locate IDS/IPSs within the gateway environment,
        immediately inside the outermost firewall.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: IDS/IPS Maintenance
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:3
      ref_id: 18.4.9.R.01
      description: "When signature-based intrusion detection is used, the effectiveness\
        \ of the IDS/IPS will degrade over time as new intrusion methods are developed.\
        \ \_It is for this reason that IDS/IPS systems and signatures need to be up\
        \ to date to identify the latest intrusion detection methods."
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:3
      ref_id: 18.4.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3815]'
      description: Agencies MUST select IDS / IPS that monitor uncharacteristic and
        suspicious activities.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:3
      ref_id: 18.4.9.C.02
      name: 'Control -  All Classifications - Must [CID: 3843]'
      description: When signature-based intrusion detection is used, agencies MUST
        keep the signatures and system patching up to date.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Malicious code counter-measures
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:4
      ref_id: 18.4.10.R.01
      description: Implementing policies and procedures for preventing and dealing
        with malicious code outbreaks that enables agencies to provide consistent
        incident response, as well as giving clear directions to system users on how
        to respond to an information security incident.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:4
      ref_id: 18.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 3851]'
      description: "Agencies MUST:\ndevelop and maintain a set of policies and procedures\
        \ covering how to:\n\nminimise the likelihood of malicious code being introduced\
        \ into a system;\nprevent all unauthorised code from executing on an agency\
        \ network;\_\ndetect any malicious code installed on a system;\n\n\nmake their\
        \ system users aware of the agency\u2019s policies and procedures; and\nensure\
        \ that all instances of detected malicious code outbreaks are handled according\
        \ to established procedures.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Configuring the IDS/IPS
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:5
      ref_id: 18.4.11.R.01
      description: Generating alerts for any information flows that contravene any
        rule within the firewall rule set will assist security personnel in identifying
        and reporting to any possible breaches of agency systems.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:5
      ref_id: 18.4.11.C.01
      name: 'Control -  All Classifications - Should [CID: 3857]'
      description: In addition to agency defined configuration requirements, agencies
        SHOULD ensure that IDS/IPSs located inside a firewall are configured to generate
        a log entry, and an alert, for any information flows that contravene any rule
        within the firewall rule set.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:5
      ref_id: 18.4.11.C.02
      name: 'Control -  All Classifications - Should [CID: 3859]'
      description: Agencies SHOULD test IDS/IPSs rule sets prior to implementation
        to ensure that they perform as expected.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:5
      ref_id: 18.4.11.C.03
      name: 'Control -  All Classifications - Should [CID: 3864]'
      description: If a firewall is configured to block all traffic on a particular
        range of port numbers, the IDP/IPSs SHOULD inspect traffic for these port
        numbers and generate an alert if they are detected.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Event management and correlation
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:6
      ref_id: 18.4.12.R.01
      description: Deploying tools to manage correlation of suspicious events or events
        of interest across all agency networks will assist in identifying suspicious
        patterns in information flows throughout the agency.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:6
      ref_id: 18.4.12.R.02
      description: The history of events is important in this analysis and should
        be accommodated in any archiving decisions.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:6
      ref_id: 18.4.12.C.01
      name: 'Control -  All Classifications - Should [CID: 3875]'
      description: 'Agencies SHOULD deploy tools for:

        the management and archive of security event information; and

        the correlation of suspicious events or events of interest across all agency
        networks.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Host-based IDS/IPSs
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:7
      ref_id: 18.4.13.R.01
      description: 'Host-based IDS/IPS use behaviour-based detection schemes and can
        therefore assist in the detection of previously unidentified anomalous and
        suspicious activities such as:

        process injection;

        keystroke logging;

        driver loading;

        library additions or supercessions;

        call hooking.

        They may also identify new malicious code. It should be noted that some anti-virus
        and similar security products are evolving into converged endpoint security
        products that incorporate HIDS/HIPS.'
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:7
      ref_id: 18.4.13.C.01
      name: 'Control -  All Classifications - Should [CID: 3886]'
      description: Agencies SHOULD install host-based IDS/IPSs on authentication,
        DNS, email, Web and other high value servers.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.4:5:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5
      description: Active content blocking
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:8
      ref_id: 18.4.14.R.01
      description: Filtering unnecessary content and disabling unwanted functionality
        reduces the number of possible entry points that an attacker can exploit.
    - urn: urn:defend:risk:req_node:nzism-v3:18.4.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.4:5:8
      ref_id: 18.4.14.C.01
      name: 'Control -  All Classifications - Should [CID: 3892]'
      description: 'Agencies SHOULD use:

        filters to block unwanted content and exploits against applications that cannot
        be patched;

        settings within the applications to disable unwanted functionality; and

        digital signatures to restrict active content to trusted sources only.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.5'
      name: Internet Protocol Version 6
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:1
      ref_id: 18.5.1
      description: IPv6 is disabled until it is ready to be deployed.
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2:1
      ref_id: 18.5.2
      description: "This section covers information on IPv6 and its deployment within\
        \ networks. \_Where this manual specifies requirements for network devices,\
        \ the requirements apply equally whether deploying IPv6 or IPv4."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2:1
      ref_id: 18.5.3
      description: "IPv6 was officially launched by the Internet Society in June 2012.\
        \ \_With the change from IPv4 to IPv6, there is the potential to introduce\
        \ vulnerabilities to agency networks through incorrect or mis-configuration,\
        \ poor design and poor device compatibility. \_Attackers will also be actively\
        \ seeking to exploit vulnerabilities that will inevitably be exposed."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2:1
      ref_id: 18.5.4
      description: Agencies unable to meet the compliance requirements as specified
        for a control when deploying IPv6 network infrastructure will need to follow
        the procedures as specified in this manual for varying from a control and
        the associated compliance requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2
      description: DNS Security Extensions (DNSSEC)
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:2:2
      ref_id: 18.5.5
      description: "DNSSEC has been developed to enhance Internet security and can\
        \ digitally \u2018sign\u2019 data to assure validity. \_It is essential that\
        \ DNSSEC is deployed at each step in the lookup from root zone to final domain\
        \ name (e.g., www.icann.org). \_Signing the root (deploying DNSSEC on the\
        \ root zone) is a necessary step in this overall process. \_Importantly it\
        \ does not encrypt data. \_It just attests to the validity of the address\
        \ of the site you visit. \_DNSSEC and IPv6 have been engineered to integrate\
        \ and thus enhance Internet security."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:3
      ref_id: 18.5.6
      description: "\n\n\n\nReference\n\n\nTitle\n\n\nPublisher\n\n\nSource\n\n\n\n\
        \_\n\nA strategy for the transition to IPv6 for Australian Government agencies.\
        \ (archived document)\n\n\nAustralian Government Information Management Office\n\
        \n\nhttps://www.hpc.mil/images/hpcdocs/ipv6/endorsed_strategy_for_the_transition_to_ipv6_for_australian_government_agencies_v2.pdf\
        \ [PDF, 466 KB]\n\n\n\n\_\n\nIPv6 First-Hop Security Concerns\n\nCisco\nhttps://www.cisco.com/c/en/us/products/ios-nx-os-software/ipv6-first-hop-security-fhs/index.html\n\
        \n\n\_\n\nManageable Network Plan\n\nNSA\n\nNSA Manageable Network Plan.pdf\
        \ (PDFy mirror) : Free Download, Borrow, and Streaming : Internet Archive\n\
        \n\n\n\_\n\nRouter Security Configuration Guide Supplement \u2013 Security\
        \ for IPv6 Routers, 23 May 2006 Version: 1.0\n\nNSA\n\nhttps://hpc.mil/images/hpcdocs/ipv6/nsa-router-security-configuration-supplement-guide-for-ipv6.pdf\
        \ [PDF, 1.37 MB]\n\n\n\n\_\n\nFirewall Design Considerations for IPv6, 10/3/2007\n\
        \nNSA\n\nhttps://www.hpc.mil/images/hpcdocs/ipv6/nsa-firewall-design-ipv6-i733-041r-2007.pdf\
        \ [PDF, 332 KB]\n\n\n\nNIST Special Publication 800-41, Revision 1, September\
        \ 2009\n\nGuidelines on Firewalls and Firewall Policy,\_\n\nNIST\n\nhttps://csrc.nist.gov/publications/detail/sp/800-41/rev-1/final\n\
        \n\n\nNIST\_Special Publication 800-119, December 2010\n\nGuidelines for secure\
        \ deployment of IPv6\n\nNIST\n\nhttps://csrc.nist.gov/publications/detail/sp/800-119/final\n\
        \n\n\n\_\n\nA Complete Guide on IPv6 Attack and Defense\n\n\nSANS Institute\n\
        \n\nhttps://www.sans.org/white-papers/33904/?show=complete-guide-ipv6-attack-defense-33904&cat=detection\n\
        \n\n\nRFC 2460\_\n\nInternet Protocol, Version 6 (IPv6) Specification, December\
        \ 1998\n\nIETF\n\nhttps://datatracker.ietf.org/doc/html/rfc2460\n\n\n\nRFC\
        \ 4291\_\n\nIP Version 6 Addressing Architecture, February 2006\n\n\nIETF\n\
        \n\nhttps://datatracker.ietf.org/doc/html/rfc4291\n\n\n\nRFC 5952\n\nA Recommendation\
        \ for IPv6 Address Text Representation, ISSN: 2070-1721, August 2010\n\nIETF\n\
        \nhttps://datatracker.ietf.org/doc/html/rfc5952\n\n\n\nRFC 6052\_\n\nIpv6\
        \ Addressing of IPv4/IPv6 Translators, ISSN: 2070-1721, October 2010\n\nIETF\n\
        \nhttps://datatracker.ietf.org/doc/html/rfc6052\n\n\n\nRFC 7136\n\nSignificance\
        \ of IPv6 Interface Identifiers, ISSN: 2070-1721, February 2014\n\nIETF\n\n\
        https://datatracker.ietf.org/doc/html/rfc7136\n\n\n\n\nRFC 6781\n\n\nDNSSEC\
        \ Operational Practices, Version 2\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/rfc6781/\n\
        \n\n\nRFC 6840\n\nClarifications and Implementation Notes for DNS Security\
        \ (DNSSEC)\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc6840\n\n\
        \n\nRFC 6841\_\n\nA Framework for DNSSEC Policies and DNSSEC Practice Statements\n\
        \n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc6841\n\n\n\nRFC 7123\n\
        \nSecurity Implications of IPv6 on IPv4 Networks\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc7123\n\
        \n\n\nRFC 4861\_\n\nNeighbor Discovery for IP version 6 (IPv6)\n\n\nIETF\n\
        \n\nhttps://datatracker.ietf.org/doc/html/rfc4861\n\n\n\nRFC 5942\_\_\n\n\
        IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes\n\n\n\
        IETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc5942\n\n\n\nRFC 3315\_\n\
        \nDynamic Host Configuration Protocol for IPv6 (DHCPv6)\n\n\nIETF\n\n\nhttps://datatracker.ietf.org/doc/html/rfc3315\n\
        \n\n\nRFC 6104\_\n\nRogue IPv6 Router Advertisement Problem Statement\n\n\
        IETF\n\nhttps://datatracker.ietf.org/doc/html/rfc6104\n\n\n\n\_\n\nDNSSEC\
        \ \u2013 What Is It and Why Is It Important?\n\n\nInternet Corporation for\
        \ Assigned Names and Numbers (ICAAN)\n\n\nhttps://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en#\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      description: Use of dual-stack equipment
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:1
      ref_id: 18.5.7.R.01
      description: "In order to reduce the attack surface area of agency systems,\
        \ it is good practice that agencies disable unused services and functions\
        \ within network devices and operating systems. \_If agencies are deploying\
        \ dual-stack equipment but not using the IPv6 functionality, then that functionality\
        \ should be disabled. \_It can be re-enabled when required. \_This will reduce\
        \ the opportunity to exploit IPv6 functionality before appropriate security\
        \ measures have been implemented."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:1
      ref_id: 18.5.7.C.01
      name: 'Control -  All Classifications - Must [CID: 3951]'
      description: Agencies not using IPv6, but which have deployed dual-stack network
        devices and ICT equipment that supports IPv6, MUST disable the IPv6 functionality,
        unless that functionality is required.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:1
      ref_id: 18.5.7.C.02
      name: 'Control -  All Classifications - Must [CID: 3952]'
      description: Network security devices on IPv6 or dual-stack networks MUST be
        IPv6 capable.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      description: Using IPv6
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.R.01
      description: "The information security implications around the use of IPv6 are\
        \ still largely unknown and un-tested. \_As many of the deployed network protection\
        \ technologies, such as firewalls and IDSs, do not consistently support IPv6,\
        \ agencies choosing to implement IPv6 face an increased risk of systems compromise."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.R.02
      description: "A number of tunnelling protocols have been developed to facilitate\
        \ interoperability between IPv4 and IPv6. \_Disabling IPv6 tunnelling protocols\
        \ when this functionality is not explicitly required will reduce the risk\
        \ of bypassing network defences by means of encapsulating IPv6 data inside\
        \ IPv4 packets."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.R.03
      description: "Stateless Address Autoconfiguration (SLAAC) is a method of stateless\
        \ IP address configuration in IPv6. \_SLAAC reduces the ability to maintain\
        \ complete logs of IP address assignment on the network. \_To avoid this constraint,\
        \ stateless IP addressing SHOULD NOT be used."
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.C.01
      name: 'Control -  All Classifications - Must [CID: 3960]'
      description: Agencies using IPv6 MUST conduct a security risk assessment on
        risks that could be introduced as a result of running a dual stack environment
        or transitioning completely to IPv6.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.C.02
      name: 'Control -  All Classifications - Must [CID: 3961]'
      description: Agencies implementing a dual stack or wholly IPv6 network or environment
        MUST re-accredit their networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.C.03
      name: 'Control -  All Classifications - Must [CID: 3962]'
      description: IPv6 tunnelling MUST be disabled on all network devices, unless
        explicitly required.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.8.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:2
      ref_id: 18.5.8.C.04
      name: 'Control -  All Classifications - Should [CID: 3965]'
      description: Dynamically assigned IPv6 addresses SHOULD be configured with DHCPv6
        in a stateful manner and with lease information logged and logs stored in
        a centralised logging facility.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      description: New systems and networks
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:3
      ref_id: 18.5.9.R.01
      description: Planning and accommodating changes in technology are an essential
        part of securing architectures and systems development.
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:3
      ref_id: 18.5.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3971]'
      description: Any network defence elements and devices MUST be IPv6 aware.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:3
      ref_id: 18.5.9.C.02
      name: 'Control -  All Classifications - Must [CID: 3972]'
      description: New network devices, including firewalls, IDS and IPS, MUST be
        IPv6 capable.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:3
      ref_id: 18.5.9.C.03
      name: 'Control -  All Classifications - Should [CID: 3974]'
      description: Agencies SHOULD consider the use of DNSSEC.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      description: Introducing IPv6 capable equipment to gateways
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:4
      ref_id: 18.5.10.R.01
      description: Introducing IPv6 capable network devices into agency gateways can
        introduce a significant number of new security risks. Undergoing reaccreditation
        when new IPv6 equipment is introduced will ensure that any IPv6 functionality
        that is not intended to be used cannot be exploited by an attacker before
        appropriate information security mechanisms have been put in place.
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:4
      ref_id: 18.5.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4012]'
      description: IPv6 tunnelling MUST be blocked by network security devices at
        externally connected network boundaries.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:4
      ref_id: 18.5.10.C.02
      name: 'Control -  All Classifications - Should [CID: 4014]'
      description: Agencies deploying IPv6 equipment in their gateway but not enabling
        the functionality SHOULD undergo reaccreditation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:18.5:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4
      description: Enabling IPv6 in gateways
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:5
      ref_id: 18.5.11.R.01
      description: Once agencies have completed the transition to a dual-stack environment
        or completely to an IPv6 environment, reaccreditation will assist in ensuring
        that the associated information security mechanisms for IPv6 are working effectively.
    - urn: urn:defend:risk:req_node:nzism-v3:18.5.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.5:4:5
      ref_id: 18.5.11.C.01
      name: 'Control -  All Classifications - Must [CID: 4018]'
      description: Agencies enabling a dual-stack environment or a wholly IPv6 environment
        in their gateways MUST reaccredit their gateway systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.6
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.6'
      name: Peripheral (KVM) Switches
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:1
      ref_id: 18.6.1
      description: An evaluated peripheral switch is used when sharing keyboards,
        monitors and mice or other user interface devices, between different systems.
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:1
      ref_id: 18.6.2
      description: This section covers information relating specifically to the use
        of keyboard/video/mouse (KVM) switches.
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:1
      ref_id: 18.6.3
      description: "It is important to recognise that any cross-connection of system\
        \ must be carefully controlled in order not to compromise trust zones. \_\
        The principles of separation and segregation must be applied. \_These principles\
        \ are discussed in Section 22.1 \u2013 Cloud Computing and Section 22.2 \u2013\
        \ Virtualisation."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:1
      ref_id: 18.6.4
      description: "Cross-connection of system may also functionally create a gateway,\
        \ whether or not it meets the technical definition of gateways. \_It is important\
        \ to refer to Section 19.1 \u2013 Gateways and Section 19.2 \u2013 Cross Domain\
        \ Solutions."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2
      description: Peripheral switches with more than two connections
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:2
      ref_id: 18.6.5
      description: If the peripheral switch has more than two systems connected then
        the level of assurance needed is determined by the highest and lowest of the
        classifications involved.
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2
      description: Electrical Safety
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:3
      ref_id: 18.6.6
      description: "Electrical safety is paramount. \_Cross-connecting systems may\
        \ create ground loops if different power sources are used for different elements\
        \ of the computer system. \_This may result in catastrophic failure if power\
        \ supplies connected to different phases are cross-connected."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2
      description: Product Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:2:4
      ref_id: 18.6.7
      description: "Product assurance is discussed in Chapter 12- Product Security\
        \ \_It is important to note the role of the Common Criteria, the related CCRA\
        \ and the use of assurance levels in determining product assurance. chapter\
        \ 12 also provides essential reference to assurance levels, evaluation levels\
        \ and defines high assurance as shown in the table 18.6.8 Assurance requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3
      description: Assurance requirements
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:1
      ref_id: 18.6.8.R.01
      description: When accessing multiple systems through a peripheral switch it
        is important that sufficient assurance is available in the operation of the
        switch to ensure that information does not accidently pass between the connected
        systems.
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:1
      ref_id: 18.6.8.R.02
      description: "It is important to maintain the integrity of Trust Zones and adhere\
        \ to the principles of separation and segregation in order to avoid inadvertently\
        \ compromising Trust Zones \u2013 even if they are at the same level of classification."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:1
      ref_id: 18.6.8.C.01
      name: 'Control -  All Classifications - Must [CID: 4051]'
      description: "Agencies accessing a classified system and a less classified system\
        \ via a peripheral switch MUST use an evaluated product with a level of assurance\
        \ as indicated in the table below.\n\n\nHigh System\nLow system / Alternate\
        \ Trust Domain\nRequired Level of Assurance\n\n\nRESTRICTED\nUNCLASSIFIED\n\
        EAL2 or PP\n\n\nCONFIDENTIAL\nUNCLASSIFIED\nhigh assurance\n\n\nRESTRICTED\n\
        high assurance\n\n\nCONFIDENTIAL\nhigh assurance\n\n\nSECRET\nUNCLASSIFIED\n\
        high assurance\n\n\nRESTRICTED\nhigh assurance\n\n\nCONFIDENTIAL\nhigh assurance\n\
        \n\nSECRET\nhigh assurance\n\n\nTOP\_SECRET\nUNCLASSIFIED\nhigh assurance\n\
        \n\nRESTRICTED\nhigh assurance\n\n\nCONFIDENTIAL\nhigh assurance\n\n\nSECRET\n\
        high assurance\n\n\nTOP\_SECRET\nhigh assurance\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3
      description: Assurance requirements for NZEO systems
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:2
      ref_id: 18.6.9.R.01
      description: "NZEO systems are particularly sensitive. \_Additional security\
        \ measures need to be put in place when connecting them to other systems."
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:2
      ref_id: 18.6.9.C.01
      name: 'Control -  All Classifications - Must [CID: 4058]'
      description: Agencies accessing a system containing NZEO information and a system
        of the same classification that is not accredited to process NZEO information,
        MUST use an evaluated product with an EAL2 (or higher) or a PP level of assurance.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.6:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3
      description: Cross-Connecting Systems with a device other than a KVM
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:3
      ref_id: 18.6.10.R.01
      description: Cross-connecting systems with any device other than a KVM approved
        gateway or an approved cross-domain solution may be high risk, may compromise
        the integrity of Trust Zones, and may create an electrical hazard.
    - urn: urn:defend:risk:req_node:nzism-v3:18.6.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.6:3:3
      ref_id: 18.6.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4066]'
      description: 'Cross-connection of security domains and Trust Zones MUST be enabled
        through an approved KVM, Gateway or Cross-Domain solution only.



        High system

        Low system/ Alternate Trust Domain

        Level of assurance




        RESTRICTED & all lower classifications



        UNCLASSIFIED



        EAL2 or PP





        CONFIDENTIAL


        UNCLASSIFIED


        high assurance





        RESTRICTED



        high assurance




        CONFIDENTIAL


        high assurance




        SECRET


        UNCLASSIFIED



        high assurance





        RESTRICTED



        high assurance





        CONFIDENTIAL



        high assurance




        SECRET


        high assurance





        TOP SECRET



        UNCLASSIFIED



        high assurance





        RESTRICTED



        high assurance





        CONFIDENTIAL



        high assurance





        SECRET



        high assurance





        TOP SECRET



        high assurance




        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.7
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:18
      ref_id: '18.7'
      name: Inverse split tunnel VPN
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:1
      ref_id: 18.7.1
      description: Agencies identify and effectively manage the risks and compensating
        controls involved in utilising inverse split tunnelling as part of remote
        access virtual private network (VPN) configurations.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.2
      description: This section covers information relating specifically to configuring
        secure remote access services (also known as VPN services) for agency devices
        that facilitate agency information (e.g., documents or emails) being transferred
        to remote systems.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.3
      description: It is important to recognise that all systems that are able to
        hold or access agency information need protection from compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.4
      description: Traditional network design approaches have focussed on keeping
        agency information within a defined perimeter unless it is explicitly released
        through an approved gateway (such as via an email or file transfer system),
        even when being accessed remotely.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.5
      description: "There are a number of prevalent architecture patterns for delivering\
        \ remote access services that support this traditional network design approach.\_\
        \ Typical patterns include:\nAlways-on VPN services from agency-owned or agency-managed\
        \ devices.\nAs-needed VPN services from agency-owned or agency-managed devices.\n\
        Remote desktop, or thin client, services from any devices, including BYOD.\n\
        Remote, or virtual, applications accessed from any devices, including BYOD.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.6
      description: With an accelerated adoption of cloud delivered services, and agency
        moves to increase the level of work being performed remotely through online
        collaboration systems, the government has published advice on the use of inverse
        split tunnel architectures for remote access VPN services to improve performance.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.7
      description: "The architecture advice advocates for the use of inverse split\
        \ tunnelling, where an explicit list of authorised and trusted internet based\
        \ services are able to be directly accessed, bypassing agency perimeter controls.\_\
        \ Both the architecture advice, and the NZISM, advise against the use of full\
        \ split tunnelling (i.e., allowing all internet traffic not destined to the\
        \ agency internal networks to bypass agency security controls)."
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.8
      description: The use of inverse split tunnel VPN configurations is most likely
        to be appropriate for agencies that are implementing Zero Trust Architecture
        approaches to network security.
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.9
      description: Inverse split tunnel VPN configurations have related, but different,
        considerations from designs that only support direct access to agency-managed
        cloud services from the internet (where devices do not also connect to a remote
        access VPN service).
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.10
      description: "It is also important to recognise that directly accessed services\
        \ represent cross-connectivity between systems and must be carefully controlled\
        \ in order not to compromise trust zones.\_ The principles of separation and\
        \ segregation must be applied.\_ These principles are discussed in section\
        \ 22.1 \u2013 Cloud computing, and section 22.2 \u2013 Virtualisation."
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.11
      description: "Cross-connection of systems may also create a gateway, whether\
        \ or not it meets the technical definition of gateways.\_ It is important\
        \ to refer to section 19.1 \u2013 Gateways, and section 19.2 \u2013 Cross\
        \ domain solutions to understand the implications and relevant controls."
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:2:1
      ref_id: 18.7.12
      description: "In addition to this section, split tunnelling advice is further\
        \ described in section 21 \u2013 Distributed working."
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:3
      ref_id: 18.7.13
      description: "Further references can be found at:\n\n\n\nReference\n\n\nTitle\n\
        \n\nPublisher\n\n\nSource\n\n\n\n\n\_\n\n\nGuide to optimising network traffic\
        \ for cloud services\n\n\nGCDO\n\n\nGuide to Optimising Network Traffic for\
        \ Cloud Services | NZ Digital government\n\n\n\n\_\_"
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:18.7:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:4
      description: Inverse split tunnel in remote access VPN systems
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:4:1
      ref_id: 18.7.14.R.01
      description: "Remote access VPN services that utilise any form of split tunnelling\
        \ provide a mechanism for agency devices to connect directly to third party\
        \ services, bypassing the traditional perimeter.\_ While this provides efficiencies\
        \ in network routing and can improve agency worker\u2019s device performance,\
        \ it introduces a broader range of threats and vulnerabilities to be considered."
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:4:1
      ref_id: 18.7.14.C.01
      name: 'Control -  All Classifications - Must [CID: 7250]'
      description: Agencies MUST undertake a threat and risk assessment on the use
        of inverse split tunnelling prior to enabling the functionality in remote
        access VPN systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:18.7.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:18.7:4:1
      ref_id: 18.7.14.C.02
      name: 'Control -  All Classifications - Should [CID: 7251]'
      description: "When providing inverse split-tunnelled access to internet based\
        \ services (\u201Cdirectly accessed services\u201D), the following aspects\
        \ SHOULD be considered as part of the threat and risk assessment:\nHow do\
        \ directly accessed services authenticate agency device identities prior to\
        \ granting access to the service?\nHow do agency devices securely resolve\
        \ internet addresses for directly accessed services?\nHow are the communications\
        \ between the devices and directly accessed services secured?\nHow does an\
        \ agency monitor and account for access made to directly accessed services?\n\
        How does an agency protect devices from compromise if they are able to directly\
        \ access internet based resources, or be directly accessed from the internet?\n\
        How do directly accessed services authenticate the user of the agency device\
        \ prior to granting access to the service (this is separate to authenticating\
        \ the agency device itself)?\nHow does an agency enforce the use of multi-factor\
        \ authentication with directly accessed services?\nHow does an agency authorise\
        \ access to directly accessed services, and does this include from devices\
        \ that are not authorised to connect to agency remote access services (authorisation\
        \ and authentication are separate activities)?\nHow is access to directly\
        \ accessed cloud services removed when staff no longer require access or leave\
        \ the agency?\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19
      assessable: false
      depth: 1
      ref_id: '19'
      name: Gateway security
    - urn: urn:defend:risk:req_node:nzism-v3:19.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:19
      ref_id: '19.1'
      name: Gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:1
      ref_id: 19.1.1
      description: To ensure that gateways are properly configured to protect agency
        systems and information transferred between systems from different security
        domains.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:1
      ref_id: 19.1.2
      description: "Gateways can be considered to be information flow control mechanisms\
        \ operating at the Network layer and may also control information flow at\
        \ the Transport, Session, Presentation and Application layers of the Open\
        \ Systems Interconnection model (OSI).\_ Specific controls for different technologies\
        \ can be found in:\nSection 19.3 \u2013Firewalls\nSection 19.4 \u2013 Diodes\n\
        Section 18.6 \u2013 Peripheral (KVM) switches;\_and\nSection 19.5 \u2013 Session\
        \ Border Controllers.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:1
      ref_id: 19.1.3
      description: "Additional information relating to topics covered in this section\
        \ can be found in the following sections of this manual:\nSection 4.4 \u2013\
        \ Accreditation Framework;\nSection 8.2 \u2013 Servers and Network Devices;\n\
        Section 8.3 \u2013 Network Infrastructure;\nSection 8.4 \u2013 IT Equipment;\n\
        Chapter 12 \u2013 Product Security;\nSection 16.1 \u2013 Identification, Authentication\
        \ and passwords;\nSection 16.6 \u2013 Event Logging and Auditing;\nSection\
        \ 19.3 \u2013 Firewalls;\nSection 19.4 \u2013 Diodes;\nSection 19.5 \u2013\
        \ Session Border Controllers;\nSection 20.1 \u2013 Data Transfers;\nSection\
        \ 20.2 \u2013 Data Import and Export; and\nSection 20.3 \u2013 Content Filtering.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2
      description: Deploying Gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:2
      ref_id: 19.1.4
      description: "This section provides a baseline for agencies deploying gateways.\_\
        \ Agencies will need to consult additional sections of this manual depending\
        \ on the specific type of gateways deployed."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:2
      ref_id: 19.1.5
      description: "For network devices used to control data flow in bi-directional\
        \ gateways, Section 19.3 \u2013 Firewalls will need to be consulted. Section\
        \ 19.4 \u2013 Diodes will also need to be consulted for one-way gateways.\_\
        \ Additionally, for both types of gateways, Section 20.1 - Data Transfers\
        \ and Section 19.2 - Cross-Domain Solutions, will need to be consulted for\
        \ requirements on appropriately controlling data flows."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:2
      ref_id: 19.1.6
      description: The requirements in this manual for content filtering, data import
        and data export apply to all types of gateways.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2
      description: Gateway classification
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:2:3
      ref_id: 19.1.7
      description: For the purposes of this chapter, the gateway assumes the highest
        classification of the connected domains.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:3
      ref_id: 19.1.8
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\nGateway / Cross Domain Solution Audit Guide, Australian Government\n\
        ASD\nhttps://www.cyber.gov.au/acsc/view-all-content/advice/guidelines-gateways\n\
        \n\n\_\nGood Practices for deploying DNSSEC, ENISA\nENISA\nhttps://www.enisa.europa.eu/publications/gpgdnssec\n\
        \n\nISO/IEC 27033-4:2014\nInformation technology -- Security techniques --\
        \ Network security -- Part 4: Securing communications between networks using\
        \ security gateways\nISO\nhttps://www.iso.org/standard/51583.html\n\n\n\n\
        ISO/IEC 7498-1:1994\n\n\nThe OSI model\nInformation Technology \u2013 Open\
        \ Systems Interconnection: The Basic Model\n\nISO\nhttps://www.iso.org/standard/20269.html\_\
        \n\n\n\nNIST Special Publication\_800-41, September 2009\n\n\nGuidelines on\
        \ Firewalls and Firewall Policy\n\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-41r1.pdf\
        \ [PDF, 331 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:4
      ref_id: 19.1.9
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV5, GOV6, INFOSEC1,\
        \ INFOSEC2, INFOSEC3 and INFOSEC4\n\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements\n\n\n\n\nPSR content\
        \ protocols\n\n\nManagement protocol for information security\n\n\nManagement\
        \ protocol for information security | Protective Security Requirements\n\n\
        \n\n\nPSR requirements sections\n\n\nHandling requirements for protectively\
        \ marked information and equipment\nSupply chain security\nUnderstand the\
        \ information security lifecycle\n\n\nClassification system | Protective Security\
        \ Requirements\nSupply chain security | Protective Security Requirements\n\
        Understanding the information security lifecycle | Protective Security Requirements\n\
        \n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\n\nTransacting online with the public \_\nOutsourcing,\
        \ Offshoring and supply chains\nMobile and remote working\nCloud Computing\n\
        Communication security\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Gateways involving cascaded connections
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:1
      ref_id: 19.1.10.R.01
      description: "Protecting a cascaded connection path with the minimum assurance\
        \ requirement of a direct connection between the highest and lowest networks\
        \ ensures appropriate reduction in security risks of the extended connection.\_\
        \ An illustration of a cascaded connection can be seen below.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:1
      ref_id: 19.1.10.C.01
      name: 'Control -  All Classifications - Must [CID: 3538]'
      description: When agencies have cascaded connections between networks involving
        multiple gateways they MUST ensure that the assurance levels specified for
        network devices between the overall lowest and highest networks are met by
        the gateway between the highest network and the next highest network within
        the cascaded connection.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Using gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:2
      ref_id: 19.1.11.R.01
      description: Physically locating all gateway components inside a secure server
        room will reduce the risk of unauthorised access to the device(s).
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:2
      ref_id: 19.1.11.R.02
      description: "The system owner of the higher security domain of connected security\
        \ domains would be most familiar with the controls required to protect the\
        \ more sensitive information and as such is best placed to manage any shared\
        \ components of gateways.\_ In some cases where multiple security domains\
        \ from different agencies are connected to a gateway, it may be more appropriate\
        \ to have a qualified third party manage the gateway on behalf of all connected\
        \ agencies.Gateway components may also reside in a virtual environment \u2013\
        \ refer to Section 22.2 \u2013 Virtualisation and Section 22.3 \u2013 Virtual\
        \ Local Area Networks"
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:2
      ref_id: 19.1.11.C.01
      name: 'Control -  All Classifications - Must [CID: 3548]'
      description: 'Agencies MUST ensure that:

        all agency networks are protected from networks in other security domains
        by one or more gateways;

        all gateways contain mechanisms to filter or limit data flow at the network
        and content level to only the information necessary for business purposes;
        and

        all gateway components, discrete and virtual, are physically located within
        an appropriately secured server room.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:2
      ref_id: 19.1.11.C.02
      name: 'Control -  All Classifications - Must [CID: 3551]'
      description: For gateways between networks in different security domains, any
        shared components MUST be managed by the system owners of the highest security
        domain or by a mutually agreed party.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Configuration of gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:3
      ref_id: 19.1.12.R.01
      description: "Gateways are essential in controlling the flow of information\
        \ between security domains. \_Any failure, particularly at the higher classifications,\
        \ may have serious consequences.\_ Hence mechanisms for alerting personnel\
        \ to situations that may give rise to information security incidents are especially\
        \ important for gateways."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:3
      ref_id: 19.1.12.C.01
      name: 'Control -  All Classifications - Must [CID: 3562]'
      description: "Agencies MUST ensure that gateways:\nare the only communications\
        \ paths into and out of internal networks;\nby default, deny all connections\
        \ into and out of the network;\nallow only explicitly authorised connections;\n\
        are managed via a secure path isolated from all connected networks (i.e.\_\
        \ physically at the gateway or on a dedicated administration network);\nprovide\
        \ sufficient logging and audit capabilities to detect information security\
        \ incidents, attempted intrusions or anomalous usage patterns; and\nprovide\
        \ real-time alerts.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Operation of gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:4
      ref_id: 19.1.13.R.01
      description: Providing an appropriate logging and audit capability will help
        to detect information security incidents and attempted network intrusions,
        allowing the agency to respond and to take measures to reduce the risk of
        future attempts.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:4
      ref_id: 19.1.13.R.02
      description: Storing event logs on a separate, secure log server will assist
        in preventing attackers from deleting logs in an attempt to destroy evidence
        of any intrusion.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:4
      ref_id: 19.1.13.C.01
      name: 'Control -  All Classifications - Must [CID: 3578]'
      description: 'Agencies MUST ensure that all gateways connecting networks in
        different security domains:

        include a firewall of an appropriate assurance level on all gateways to filter
        and log network traffic attempting to enter the gateway;

        are configured to save event logs to a separate, secure log server;

        are protected by authentication, logging and audit of all physical access
        to gateway components; and

        have all controls tested to verify their effectiveness after any changes to
        their configuration.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Demilitarised zones
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:5
      ref_id: 19.1.14.R.01
      description: "Demilitarised zones are used to prevent direct access to information\
        \ and systems on internal agency networks.\_ Agencies that require certain\
        \ information and systems to be accessed from the Internet or some other form\
        \ of remote access, should place them in the less trusted demilitarised zone\
        \ instead of on internal agency networks."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:5
      ref_id: 19.1.14.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3622]'
      description: Agencies MUST use demilitarised zones to house systems and information
        directly accessed externally.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:5
      ref_id: 19.1.14.C.02
      name: 'Control -  All Classifications - Should [CID: 3623]'
      description: Agencies SHOULD use demilitarised zones to house systems and information
        directly accessed externally.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Risk assessment
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:6
      ref_id: 19.1.15.R.01
      description: Performing a risk assessment on the gateway and its configuration
        prior to its implementation will assist in the early identification and mitigation
        of security risks.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:6
      ref_id: 19.1.15.C.01
      name: 'Control -  All Classifications - Must [CID: 3626]'
      description: Agencies MUST perform a risk assessment on gateways and their configuration
        prior to their implementation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Risk transfer
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:7
      ref_id: 19.1.16.R.01
      description: "Gateways could connect networks with different domain owners,\
        \ including across agency boundaries.\_ As a result, all domain and system\
        \ owners MUST understand and accept the risks from all other networks before\
        \ gateways are implemented."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:7
      ref_id: 19.1.16.C.01
      name: 'Control -  All Classifications - Must [CID: 3630]'
      description: All domain and system owners connected through a gateway MUST understand
        and accept the residual security risk of the gateway and from any connected
        domains including those via a cascaded connection.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:7
      ref_id: 19.1.16.C.02
      name: 'Control -  All Classifications - Should [CID: 3633]'
      description: Agencies SHOULD annually review the security architecture of the
        gateway and risks of all connected domains including those via a cascaded
        connection.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Information stakeholders and Shared Ownership
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:8
      ref_id: 19.1.17.R.01
      description: "Changes to a domain connected to a gateway can affect the security\
        \ posture of other connected domains.\_ All domains owners should be considered\
        \ stakeholders in all connected domains."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:8
      ref_id: 19.1.17.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3637]'
      description: Once connectivity is established, domain owners MUST be considered
        information stakeholders for all connected domains.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.17.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:8
      ref_id: 19.1.17.C.02
      name: 'Control -  All Classifications - Should [CID: 3640]'
      description: Once connectivity is established, domain owners SHOULD be considered
        information stakeholders for all connected domains.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: System user training
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:9
      ref_id: 19.1.18.R.01
      description: "It is important that system users are competent to use gateways\
        \ in a secure manner.\_ This can be achieved through appropriate training\
        \ before being granted access."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:9
      ref_id: 19.1.18.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 3648]'
      description: All system users MUST be trained on the secure use and security
        risks of the gateways before being granted access.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:9
      ref_id: 19.1.18.C.02
      name: 'Control -  All Classifications - Should [CID: 3649]'
      description: All system users SHOULD be trained in the secure use and security
        risks of the gateways before being granted access.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Administration of gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.R.01
      description: Application of role separation and segregation of duties in administration
        activities will protect against security risks posed by a malicious system
        user with extensive access to gateways.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.C.01
      name: 'Control -  All Classifications - Must [CID: 3660]'
      description: Agencies MUST limit access to gateway administration functions.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.C.02
      name: 'Control -  All Classifications - Must [CID: 3663]'
      description: Agencies MUST ensure that system administrators are formally trained
        to manage gateways by qualified trainers.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.C.03
      name: 'Control -  All Classifications - Must [CID: 3668]'
      description: Agencies MUST ensure that all system administrators of gateways
        that process NZEO information meet the nationality requirements for these
        endorsements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.C.04
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3672]'
      description: "Agencies MUST separate roles for the administration of gateways\
        \ (e.g.\_ separate network and security policy configuration roles)."
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.19.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:10
      ref_id: 19.1.19.C.05
      name: 'Control -  All Classifications - Should [CID: 3676]'
      description: Agencies SHOULD separate roles for the administration of gateways
        (e.g. separate network and security policy configuration roles).
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: System user authentication
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:11
      ref_id: 19.1.20.R.01
      description: Authentication to networks as well as gateways can reduce the risk
        of unauthorised access and provide an audit capability to support the investigation
        of information security incidents.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:11
      ref_id: 19.1.20.C.01
      name: 'Control -  All Classifications - Must [CID: 3683]'
      description: Agencies MUST authenticate system users to all classified networks
        accessed through gateways.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:11
      ref_id: 19.1.20.C.02
      name: 'Control -  All Classifications - Must [CID: 3685]'
      description: Agencies MUST ensure that only authenticated and authorised system
        users can use the gateway.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:11
      ref_id: 19.1.20.C.03
      name: 'Control -  All Classifications - Should [CID: 3686]'
      description: Agencies SHOULD use multi-factor authentication for access to networks
        and gateways.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: IT equipment authentication
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:12
      ref_id: 19.1.21.R.01
      description: Authenticating IT equipment to networks accessed through gateways
        will assist in preventing unauthorised IT equipment connecting to a network.
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:12
      ref_id: 19.1.21.C.01
      name: 'Control -  All Classifications - Should [CID: 3695]'
      description: Agencies SHOULD authenticate any IT equipment that connects to
        networks accessed through gateways.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Configuration control
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:13
      ref_id: 19.1.22.R.01
      description: "To avoid changes that may introduce vulnerabilities into a gateway,\
        \ agencies should fully consider any changes and associated risks.\_ Changes\
        \ may also necessitate re-certification and accreditation of the system, see\
        \ Chapter 4 \u2013 System Certification and Accreditation."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:13
      ref_id: 19.1.22.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 3702]'
      description: Agencies MUST undertake a risk assessment and update the SRMP before
        changes are implemented.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.22.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:13
      ref_id: 19.1.22.C.02
      name: 'Control -  All Classifications - Must [CID: 3705]'
      description: "Agencies MUST document any changes to gateways in accordance with\
        \ the agency\u2019s Change Management Policy."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.22.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:13
      ref_id: 19.1.22.C.03
      name: 'Control -  All Classifications - Should [CID: 3707]'
      description: Agencies SHOULD undertake a risk assessment and update the SRMP
        before changes are implemented.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.1:5:14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5
      description: Testing of gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:14
      ref_id: 19.1.23.R.01
      description: "The testing of security measures on gateways will assist in ensuring\
        \ that the integrity of the gateway is being maintained.\_ An attacker who\
        \ is aware of the regular testing schedule may cease malicious activities\
        \ during such periods to avoid detection.\_ Any test should, therefore, be\
        \ unannounced and conducted at irregular intervals."
    - urn: urn:defend:risk:req_node:nzism-v3:19.1.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.1:5:14
      ref_id: 19.1.23.C.01
      name: 'Control -  All Classifications - Should [CID: 3712]'
      description: Agencies SHOULD ensure that testing of security measures is performed
        at random intervals no more than six months apart.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:19
      ref_id: '19.2'
      name: Cross Domain Solutions (CDS)
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:1
      ref_id: 19.2.1
      description: Cross-Domain Solutions secure transfers between systems of differing
        classifications or trust levels with high assurance over the security of systems
        and information.
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:1
      ref_id: 19.2.2
      description: This section describes the use and implementation of Cross Domain
        Solutions (CDS).
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:1
      ref_id: 19.2.3
      description: "CDS provide information flow control mechanisms at each layer\
        \ of the OSI model with a higher level of assurance than typical gateways.\_\
        \ This section extends the preceding Gateways section.\_ CDS systems must\
        \ apply controls from each section."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:1
      ref_id: 19.2.4
      description: "19.2.1.\_\_\_\_ Additional information relating to topics covered\
        \ in this section can be found in the following chapters and sections:\nSection\
        \ 4.4 \u2013 Accreditation Framework;\nSection 8.2 \u2013 Servers and Network\
        \ Devices;\nSection 8.3 \u2013 Network Infrastructure;\nSection 8.4 \u2013\
        \ IT Equipment;\nChapter 12 \u2013 Product Security;\nSection 16.1 \u2013\
        \ Identification, Authentication and passwords;\nSection 16.6 \u2013 Event\
        \ Logging and Auditing;\nSection 19.1 \u2013 Gateways;\nSection 19.3 \u2013\
        \ Firewalls;\nSection 19.4 \u2013 Diodes;\nSection 19.5 \u2013 Session Border\
        \ Controllers;\nSection 20.1 \u2013 Data Transfers;\nSection 20.2 \u2013 Data\
        \ Import and Export; and\nSection 20.3 \u2013 Content Filtering.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2
      description: Deploying Cross Domain Solutions
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:2
      ref_id: 19.2.5
      description: Consult the section on Firewalls in this chapter for devices used
        to control data flow in bi-directional gateways.
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:2
      ref_id: 19.2.6
      description: Consult the section on Diodes in this chapter for devices used
        to control data flow in uni-directional gateways.
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:2
      ref_id: 19.2.7
      description: Consult the Data Transfers and Content Filtering sections for requirements
        on appropriately controlling data flows in both bi-directional and uni-directional
        gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2
      description: Types of gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:3
      ref_id: 19.2.8
      description: 'This manual defines three types of gateways:

        access gateways;

        multilevel gateways; and

        transfer gateways.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2
      description: Access Gateway
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      ref_id: 19.2.9
      description: 'An access gateway provides the system user with access to multiple
        security domains from a single device.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      ref_id: 19.2.10
      description: "A transfer gateway facilitates the transfer of information, in\
        \ one or multiple directions (low to high or high to low) between different\
        \ security domains.\_ A traditional gateway to the Internet is considered\
        \ a form of transfer gateway."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      ref_id: 19.2.11
      description: 'The following illustrates a Uni-Directional Transfer Cross Domain
        Solution.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      ref_id: 19.2.12
      description: 'A Bi-Directional Cross Domain Solution enables access, based on
        authorisations, to data at multiple classifications and releasability levels.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:2:4
      ref_id: 19.2.13
      description: 'A Multi-Level Transfer Cross Domain Solution enables access, based
        on authorisations, to data at multiple classifications and releasability levels.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:3
      ref_id: 19.2.14
      description: "Additional guidance can be found at:\n\n\nReference\_\nTitle\n\
        Publisher\nSource\n\n\n\_\n\nCross Domain Solutions\n\nASD\n\nIntroduction\
        \ to Cross Domain Solutions | Cyber.gov.au\nFundamentals of Cross Domain Solutions\
        \ | Cyber.gov.au\n\n\n\n\_\nSecurity principles for Cross Domain Solution\n\
        NCSC UK\n\nSecurity principles for cross domain solutions - NCSC.GOV.UK\n\n\
        \n\n\_\nCross Domain Security Primer\nCSE Canada\n\nCross domain security\
        \ primer (ITSB-120) - Canadian Centre for Cyber Security\n\n\n\nSse-100-1\n\
        Information Assurance Guidance For Systems Based On A Security Real-Time Operating\
        \ System Systems Security Engineering\_\nNSA\n\nAvailable at:\nNational Security\
        \ Agency Information Assurance Guidance for Systems Based on a Security Real-Time\
        \ Operating System: Systems Security Engineering: National Security Agency:\
        \ 9781508545705: Amazon.com: Books\n\n\n\n\_\n\nSolving the Cross-Domain Conundrum,\n\
        Colonel Bernard F. Koelsch United States Army, 2013\nUS Army War College\n\
        ADA589325.pdf (dtic.mil) \_\n\n\n\_\n\nInside Microsoft 365 Defender: Solving\
        \ cross-domain security incidents through the power of correlation analytics\
        \ - Microsoft Security Blog\n\nMicrosoft\nInside Microsoft 365 Defender: Solving\
        \ cross-domain security incidents through the power of correlation analytics\
        \ - Microsoft Security Blog\n\n\n\_\nShedding Light on Cross Domain Solutions\n\
        SANS\nhttps://www.sans.org/reading-room/whitepapers/dlp/shedding-light-cross-domain-solutions-36492\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Gateway classification
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:1
      ref_id: 19.2.15.R.01
      description: "The trust level or classification of systems directs users and\
        \ systems administrators to the appropriate handling instructions and level\
        \ of protection required for those systems.\_ This aids in the selection of\
        \ systems controls."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:1
      ref_id: 19.2.15.C.01
      name: 'Control -  All Classifications - Must [CID: 3870]'
      description: For the purposes of this Manual, the CDS MUST be classified at
        the highest classification of connected domains.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Allowable gateways
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:2
      ref_id: 19.2.16.R.01
      description: "Connecting systems to the Internet attracts significant risk and\
        \ so highly classified systems are prohibited from being directly connected\
        \ to each other or to the Internet.\_ If an agency wishes to connect a highly\
        \ classified system to the Internet the connection will need to be cascaded\
        \ through a system of a lesser classification that is approved to connect\
        \ directly to the Internet."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:2
      ref_id: 19.2.16.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3880]'
      description: Agencies connecting a TOP SECRET, SECRET OR CONFIDENTIAL network
        to any other network MUST implement a CDS.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:2
      ref_id: 19.2.16.C.02
      name: 'Control -  Secret, Top Secret, Confidential - Must Not [CID: 3887]'
      description: 'Agencies MUST NOT implement a gateway permitting data to flow
        directly from:

        a TOP SECRET network to any network below SECRET;

        a SECRET network to an UNCLASSIFIED network; or

        a CONFIDENTIAL network to an UNCLASSIFIED network.

        '
      implementation_groups:
      - Secret - MUST NOT
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Implementing Cross Domain Solutions
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:3
      ref_id: 19.2.17.R.01
      description: "Connecting multiple sets of gateways and Cross Domain Solutions\
        \ (CDS) increases the threat surface and, consequently, the likelihood and\
        \ impact of a network compromise.\_ When a gateway and a CDS share a common\
        \ network, the higher security domain (such as a classified agency network)\
        \ can be exposed to malicious activity, exploitation or denial of service\
        \ from the lower security domain (such as the Internet)."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.17.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:3
      ref_id: 19.2.17.R.02
      description: "To manage this risk, CDS should implement products that have completed\
        \ a high assurance evaluation, see Chapter 12 \u2013 Product Security.\_ The\
        \ AISEP Evaluated Product List (EPL) includes products that have been evaluated\
        \ in the high assurance scheme but is not an exhaustive list.\nWhere CDS are\
        \ not listed on the AISEP EPL, the GCSB can provide guidance on product selection\
        \ and implementation on request."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:3
      ref_id: 19.2.17.C.01
      name: 'Control -  Secret, Confidential - Must [CID: 3926]'
      description: When designing and deploying a CDS, agencies MUST consult with
        the GCSB and comply with all directions provided.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.17.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:3
      ref_id: 19.2.17.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3927]'
      description: Agencies connecting a typical gateway and a CDS to a common network
        MUST consult the GCSB on the impact to the security of the CDS and comply
        with all directions provided.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Separation of data flows
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:4
      ref_id: 19.2.18.R.01
      description: "Gateways connecting highly classified systems to lower classified,\
        \ or Internet connected systems need to incorporate physically separate paths\
        \ to provide stronger control of information flows.\_ Typically this is achieved\
        \ through separate pathing and the use of diodes. Such gateways are generally\
        \ restricted to process and communicate only highly-structured formal messaging\
        \ traffic."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:4
      ref_id: 19.2.18.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 3929]'
      description: Agencies MUST ensure that all bi-directional gateways between TOP
        SECRET and SECRET networks, SECRET and less classified networks, and CONFIDENTIAL
        and less classified networks, have separate upward and downward paths which
        use a diode and physically separate infrastructure for each path.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Trusted sources
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:5
      ref_id: 19.2.19.R.01
      description: "Trusted sources are designated personnel who have the delegated\
        \ authority to assess and approve the transfer or release of data or documents.\_\
        \ Trusted sources may include security personnel within the agency such the\
        \ CISO and the ITSM."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:5
      ref_id: 19.2.19.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3932]'
      description: 'Trusted sources MUST be:

        a strictly limited list derived from business requirements and the result
        of a security risk assessment;

        where necessary an appropriate security clearance is held; and

        approved by the Accreditation Authority.

        '
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:5
      ref_id: 19.2.19.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 3933]'
      description: Trusted sources MUST authorise all data to be exported from a security
        domain.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.2:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4
      description: Operation of the Cross Domain Solution
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:6
      ref_id: 19.2.20.R.01
      description: "The highly sensitive nature of the data within cross domain solutions\
        \ requires additional audit and logging for control, management, record and\
        \ forensic purposes.\_ This is in addition to the audit and logging requirements\
        \ in Section 16.6 \u2013 Event Logging and Auditing."
    - urn: urn:defend:risk:req_node:nzism-v3:19.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.2:4:6
      ref_id: 19.2.20.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 3936]'
      description: All data exported from a security domain MUST be logged.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:19
      ref_id: '19.3'
      name: Firewalls
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:1
      ref_id: 19.3.1
      description: Agencies operating bi-directional gateways implement firewalls
        and traffic flow filters to provide a protective layer to their networks in
        both discrete and virtual environments.
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2:1
      ref_id: 19.3.2
      description: This section covers information relating to filtering requirements
        for bi-direction gateways between networks of different security domains.
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2:1
      ref_id: 19.3.3
      description: "When a control specifies a requirement for a diode or filter the\
        \ appropriate information can be found within Section 19.4 \u2013Diodes and\
        \ Section 20.3 \u2013 Content Filtering."
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2:1
      ref_id: 19.3.4
      description: "Additional information that also applies to topics covered in\
        \ the section can be found in:\nChapter 12 \u2013 Product Security which provides\
        \ advice on the selection of evaluated products;\nSection 20.1 \u2013 Data\
        \ Transfers;\nSection 20.2 \u2013 Data Import and Export; and\nSection 22.2\
        \ \u2013 Virtualisation.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2
      description: Inter-connecting networks within an agency
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2:2
      ref_id: 19.3.5
      description: "When connecting networks accredited to the same classification\
        \ and set of endorsements within an agency the requirements of this section\
        \ may not apply.\_ When connecting networks accredited with different classifications\
        \ or endorsements within an agency the information in this section applies."
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2
      description: Connecting agency networks to the Internet
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:2:3
      ref_id: 19.3.6
      description: When connecting an agency network to the Internet, the Internet
        is considered an UNCLASSIFIED and insecure network.
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:3
      ref_id: 19.3.7
      description: "Further information on the Network Device Protection Profile (NDPP)\
        \ and firewalls can be found at:\n\n\nReference\_\nTitle\nPublisher\nSource\n\
        \n\nNDPP\nNetwork Device Protection Profile (NDPP)\n(US) National Information\
        \ Assurance Partnership\nhttps://www.niap-ccevs.org/Profile/Info.cfm?PPID=293&id=293\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4
      description: Firewall assurance levels
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.R.01
      description: "The higher the required assurance level for a firewall, the greater\
        \ the assurance that it provides an appropriate level of protection against\
        \ an attacker.\_ For example, an EAL2 firewall is certified to provide protection\
        \ against a basic threat potential, whilst an EAL4 firewall is certified to\
        \ provide protection against a moderate threat potential. A Protection Profile\
        \ (PP) is considered to be equivalent to EAL2 under its Common Criteria Recognition\
        \ Arrangement."
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.R.02
      description: "If a uni-directional connection between two networks is being\
        \ implemented only one gateway is necessary with requirements being determined\
        \ based on the source and destination networks.\_ However, if a bi-directional\
        \ connection between two networks is being implemented both gateways will\
        \ be configured and implemented with requirements being determined based on\
        \ the source and destination networks."
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.C.01
      name: 'Control -  All Classifications - Must [CID: 3970]'
      description: All gateways MUST contain a firewall in both physical and virtual
        environments.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.C.02
      name: 'Control -  All Classifications - Must [CID: 3973]'
      description: Agencies MUST check the evaluation has examined the security enforcing
        functions by reviewing the target of evaluation/security target and other
        testing documentation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.C.03
      name: 'Control -  All Classifications - Must [CID: 3975]'
      description: "Agencies MUST use devices as shown in the following table for\
        \ their gateway when connecting two networks of different classifications\
        \ or two networks of the same classification but of different security domains.\n\
        \n\n\nYour network\nTheir network\nYou require\nThey require\n\n\nRESTRICTED\
        \ and below\n\_\nUNCLASSIFIED\nEAL4 firewall\nN/A\n\n\nRESTRICTED\nEAL2 or\
        \ PP firewall\nEAL2 or PP firewall\n\n\nCONFIDENTIAL\nEAL2 or PP firewall\n\
        EAL4 firewall\n\n\nSECRET\nEAL2 or PP firewall\nEAL4 firewall\n\n\nTOP SECRET\n\
        EAL2 or PP firewall\nConsultation with GCSB\n\n\nCONFIDENTIAL\n\_\nUNCLASSIFIED\n\
        Consultation with GCSB\nN/A\n\n\nRESTRICTED\nEAL4 firewall\nEAL2 or PP firewall\n\
        \n\nCONFIDENTIAL\nEAL2 or PP firewall\nEAL2 or PP firewall\n\n\nSECRET\nEAL2\
        \ or PP firewall\nEAL4 firewall\n\n\nTOP SECRET\nEAL2 or PP firewall\nConsultation\
        \ with GCSB\n\n\nSECRET\n\_\nUNCLASSIFIED\nConsultation with GCSB\nN/A\n\n\
        \nRESTRICTED\nEAL4 firewall\nEAL2 or PP firewall\n\n\nCONFIDENTIAL\nEAL4 firewall\n\
        EAL2 or PP firewall\n\n\nSECRET\nEAL2 or PP firewall\nEAL2 or PP firewall\n\
        \n\nTOP SECRET\nEAL2 or PP firewall\nEAL4 firewall\n\n\nTOP SECRET\n\_\nUNCLASSIFIED\n\
        Consultation with GCSB\nN/A\n\n\nRESTRICTED\nConsultation with GCSB\nEAL2\
        \ or PP firewall\n\n\nCONFIDENTIAL\nConsultation with GCSB\nEAL2 or PP firewall\n\
        \n\nSECRET\nEAL4 firewall\nEAL2 or PP firewall\n\n\nTOP SECRET\nEAL4 firewall\n\
        EAL4 firewall\n\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.8.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:1
      ref_id: 19.3.8.C.04
      name: 'Control -  All Classifications - Must [CID: 3996]'
      description: The requirement to implement a firewall as part of gateway architecture
        MUST be met separately and independently by both parties (gateways) in both
        physical and virtual environments.Shared equipment DOES NOT satisfy the requirements
        of this control.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4
      description: Firewall assurance levels for NZEO networks
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:2
      ref_id: 19.3.9.R.01
      description: As NZEO networks are particularly sensitive, additional security
        measures need to be put in place when connecting them to other networks.
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:2
      ref_id: 19.3.9.C.01
      name: 'Control -  All Classifications - Must [CID: 3999]'
      description: Agencies MUST use a firewall of at least an EAL4 assurance level
        between an NZEO network and a foreign network in addition to the minimum assurance
        levels for firewalls between networks of different classifications or security
        domains.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:2
      ref_id: 19.3.9.C.02
      name: 'Control -  All Classifications - Must [CID: 4000]'
      description: In all other circumstances the table at 19.3.8.C.03 MUST apply.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.3.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.3:4:2
      ref_id: 19.3.9.C.03
      name: 'Control -  All Classifications - Should [CID: 4001]'
      description: Agencies SHOULD use a firewall of at least an EAL2 assurance level
        or a Protection Profile between an NZEO network and another New Zealand controlled
        network within a single security domain.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:19
      ref_id: '19.4'
      name: Diodes
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:1
      ref_id: 19.4.1
      description: Networks connected to one-way (uni-directional) gateways implement
        diodes in order to protect the higher classified system.
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:2:1
      ref_id: 19.4.2
      description: "This section covers information relating to filtering requirements\
        \ for one-way gateways used to facilitate data transfers.\_ Additional information\
        \ that also applies to topics covered in the section can be found in:\nChapter\
        \ 12 \u2013 Product Security which provides advice on selecting evaluated\
        \ products.\nSection 20.1 \u2013 Data Transfers; and\nSection 20.2 \u2013\
        \ Data Import and Export;\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:3
      ref_id: 19.4.3
      description: "Further information on the Evaluated Products List can be found\
        \ at:\n\n\nReference\nTitle\nPublisher\nSource\n\n\n\_\nEvaluated Products\
        \ List (EPL)\nAISEP\nhttps://www.cyber.gov.au/acsc/view-all-content/epl-products\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4
      description: Diode assurance levels
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:1
      ref_id: 19.4.4.R.01
      description: "A diode enforces one-way flow of network traffic thus requiring\
        \ separate paths for incoming and outgoing data.\_ As such, it is much more\
        \ difficult for an attacker to use the same path to both launch an attack\
        \ and release the information.\_ Using diodes of higher assurance levels for\
        \ higher classified networks provides an appropriate level of assurance to\
        \ agencies that the specified security functionality of the product will operate\
        \ as claimed."
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:1
      ref_id: 19.4.4.C.01
      name: 'Control -  All Classifications - Must [CID: 4015]'
      description: "Agencies MUST use devices as shown in the following table for\
        \ controlling the data flow of one-way gateways between networks of different\
        \ classifications.\n\n\n\nHigh network\nLow network\nYou require\n\n\nRESTRICTED\n\
        \_\nUNCLASSIFIED\nEAL2 or PP diode\n\n\nRESTRICTED\nEAL2 or PP diode\n\n\n\
        CONFIDENTIAL\n\_\nUNCLASSIFIED\nhigh assurance diode\n\n\nRESTRICTED\nhigh\
        \ assurance diode\n\n\nCONFIDENTIAL\nhigh assurance diode\n\n\nSECRET\n\_\n\
        UNCLASSIFIED\nhigh assurance diode\n\n\nRESTRICTED\nhigh assurance diode\n\
        \n\nCONFIDENTIAL\nhigh assurance diode\n\n\nSECRET\nhigh assurance diode\n\
        \n\nTOP SECRET\n\_\nUNCLASSIFIED\nhigh assurance diode\n\n\nRESTRICTED\nhigh\
        \ assurance diode\n\n\nCONFIDENTIAL\nhigh assurance diode\n\n\nSECRET\nhigh\
        \ assurance diode\n\n\nTOP SECRET\nhigh assurance diode\n\n\n\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4
      description: Diode assurance levels for NZEO networks
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:2
      ref_id: 19.4.5.R.01
      description: As NZEO networks are particularly sensitive additional security
        measures are necessary when connecting them to other networks.
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:2
      ref_id: 19.4.5.C.01
      name: 'Control -  All Classifications - Must [CID: 4028]'
      description: Agencies MUST use a diode of at least an EAL4 assurance level between
        an NZEO network and a foreign network in addition to the minimum assurance
        levels for diodes between networks of different classifications.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:2
      ref_id: 19.4.5.C.02
      name: 'Control -  All Classifications - Must [CID: 4030]'
      description: In all other circumstances the table at 19.4.4.C.01 MUST apply.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.5.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:2
      ref_id: 19.4.5.C.03
      name: 'Control -  All Classifications - Should [CID: 4032]'
      description: Agencies SHOULD use a diode of at least an EAL2 assurance level
        or a Protection Profile between an NZEO network and another New Zealand controlled
        network within a single security domain.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4
      description: Volume Checking
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:3
      ref_id: 19.4.6.R.01
      description: "Monitoring the volume of data being transferred across a diode\
        \ will ensure that it conforms to expectations.\_ It can also alert the agency\
        \ to potential malicious activity if the volume of data suddenly changes from\
        \ the norm."
    - urn: urn:defend:risk:req_node:nzism-v3:19.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.4:4:3
      ref_id: 19.4.6.C.01
      name: 'Control -  All Classifications - Should [CID: 4039]'
      description: Agencies deploying a diode to control data flow within one-way
        gateways SHOULD monitor the volume of the data being transferred.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:19
      ref_id: '19.5'
      name: Session Border Controllers
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:1
      ref_id: 19.5.1
      description: "To ensure\_the use of Session Border Controllers (SBCs) is integrated\
        \ with the agency\u2019s security architecture and that use is consistent\
        \ with other requirements for gateway security in this chapter."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:1
      ref_id: 19.5.2
      description: "This section encompasses the use of SBCs in Voice over Internet\
        \ Protocol (VoIP) and Unified Communication (UC) networks within an agency.\_\
        \ It describes key risks and threats and provides guidance on the conceptual\
        \ design of security for such systems."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:1
      ref_id: 19.5.3
      description: 'It is important to note that Service Providers generally have
        operational objectives different to those of the agency and typically they
        will:

        Design a highly operationally optimised network requiring minimal maintenance;

        Provide resources, including SBCs, softswitches and media gateways that are
        shared between a number of customers (such as multi-tenanted data centres);

        The standard model may not accommodate all unique agency or NZ Government
        requirements which will then require special consideration.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:1
      ref_id: 19.5.4
      description: "Reference should \_also be made to the following sections:\nChapter\
        \ 6 \u2013 Information Security Monitoring;\nChapter 7 \u2013 Information\
        \ Security Incidents;\nChapter 9 \u2013 Personnel Security;\nChapter 11 \u2013\
        \ Communications Systems and Devices;\nSection 13.1.12 \u2013 Archiving;\n\
        Chapter 16 \u2013 Access control and passwords;\nSection 18.3 - Video & Telephony\
        \ Conferencing and Internet Protocol Telephony.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2
      description: Definitions
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:2
      ref_id: 19.5.5
      description: "A Session Border Controller (SBC) is a device (physical or virtual)\
        \ used in IP networks to control and manage the signalling and media streams\
        \ of real-time UC and VoIP connections.\_ See also Section 18.3 \u2013 Video\
        \ & Telephony Conferencing and Internet Protocol Telephony.\_ It includes\
        \ establishing, controlling, and terminating calls, interactive media communications\
        \ or other VoIP connections.\_ SBCs enable VoIP traffic to navigate gateways\
        \ and firewalls and ensure interoperability between different SIP implementations.\_\
        \ Careful selection of SBCs will provide such functionality as prevention\
        \ of toll fraud, resistance to denial of service attacks and resistance to\
        \ eavesdropping."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:2
      ref_id: 19.5.6
      description: "Unified Communications (UC) is a term describing the integration\
        \ of real-time and near real time communication and interaction services in\
        \ an organisation or agency.\_ UC may integrate several communication systems\
        \ including unified messaging, collaboration, and interaction systems; real-time\
        \ and near real-time communications; and transactional applications."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:2:2
      ref_id: 19.5.7
      description: "UC may, for example, include services such as instant messaging\
        \ (chat), presence information, voice, mobility, audio, web & video conferencing,\
        \ data sharing (such as interactive whiteboards), voicemail, e-mail, SMS and\
        \ fax.\_ UC is not necessarily a single product, but more usually a set of\
        \ products designed to provide a unified user-interface and user-experience\
        \ across multiple devices and media-types."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Purpose
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:3
      ref_id: 19.5.8
      description: "Traditional demarcation points, such as media gateways, are no\
        \ longer natural boundaries.\_ Older firewall technology impacts the performance\
        \ of communications systems, including VoIP and UC.\_ SBCs were introduced\
        \ to improve performance and provide interoperability with real-time and near\
        \ real-time communications.\_ They provide a new natural demarcation point."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:3
      ref_id: 19.5.9
      description: "SBCs can provide a demarcation or normalisation point within the\
        \ agency\u2019s network, allow enforcement of agency specific security policies\
        \ and provide a greater degree of accountability than the usual contract with\
        \ service providers."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Risks and Threats
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      ref_id: 19.5.10
      description: 'Risks and threats associated with the use of VoIP and UC include:

        Confidentiality (eavesdropping);

        Integrity (enabling fraud and theft as well as compromising privacy); and

        Availability (including Denial of Service [DoS or DDoS]).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      description: Confidentiality
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4:1
      ref_id: 19.5.11
      description: "There is a high likelihood of eavesdropping in VoIP systems. Traditional\
        \ telephone systems require physical access to tap a line or compromise a\
        \ PABX or switch.\_ In VoIP networks, virtual LAN environments can be exploited\
        \ remotely to identify weaknesses within and between virtual LANs and gain\
        \ access to valuable information.\_ Sniffing is another form of eavesdropping\
        \ that involves capturing unencrypted voice traffic with malware or a specific\
        \ VoIP sniffer tool.\_ In common with other Internet connected systems, adversary-in-the-middle\
        \ exploits are also used to eavesdrop on both data and VoIP networks."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      description: Integrity
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4:2
      ref_id: 19.5.12
      description: "Exploits such as caller ID spoofing are relatively easy to execute\
        \ and can be extremely costly to businesses.\_ Information from a stolen credit\
        \ card or acquisition of other sensitive data, can compromise an employee\u2019\
        s caller ID, and have funds transferred while posing as the employee.\_ Cyber\
        \ criminals can also change an employee\u2019s registration information in\
        \ order to eavesdrop on or intercept all incoming calls for that individual."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4:2
      ref_id: 19.5.13
      description: "Integrity compromise may include modification or insertion into\
        \ UC.\_ As many UC elements, such as voicemail or email, may encompass electronic\
        \ records as defined in legislation it is vital that these elements are preserved\
        \ unaltered."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      description: Availability
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4:3
      ref_id: 19.5.14
      description: "Because VoIP and UC places high levels of demand on any network,\
        \ managing Quality of Service (QoS), latency, jitter, packet loss and other\
        \ service impediments are important aspects of availability.\_ In the event\
        \ of major faults or outages, diversity and fault tolerance is vital for all\
        \ key sites.\_ To enable failover, for example, where calls leave the customer\
        \ network, call diversity and call failover are essential configuration elements."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4
      description: Denial of Service
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:4:4
      ref_id: 19.5.15
      description: "Denial of Service (DoS) attacks abuse signalling protocols to\
        \ deny availability of VoIP data and degrade performance.\_ If the telecommunications\
        \ network is compromised, it is possible to also traverse systems to attack\
        \ or infect the agency\u2019s data networks and other systems."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Common VoIP and UC Security Risks and Threats
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.16
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:5
      ref_id: 19.5.16
      description: "Common VoIP and UC security risks and threats.\n\n\nRisk\nTypical\
        \ Symptoms\nThreat\nCountermeasures\n\n\nReconnaissance scan\nAddress or port\
        \ scan is used to footprint network topology\nTargeted denial of service,\
        \ fraud, theft\n\n\nIntrusion detection\nProtection against registration floods\n\
        \n\n\n\nAdversary in the middle\nAttacker intercepts session to impersonate(spoof)\
        \ caller\nTargeted denial of service, breach of privacy, fraud, theft\n\n\n\
        TLS encryption for SIP with separate TLS certificates for SIP Service Providers\n\
        \n\n\n\nEavesdropping\nAttacker \u201Csniffs\u201D session for the purpose\
        \ of social engineering\nBreach of privacy, fraud, theft\_\n\n\nIntrusion\
        \ detection\nEncryption\n\n\n\n\nSession hijacking\nAttacker compromises valuable\
        \ information by rerouting call\_\nBreach of privacy, fraud, theft\_\n\n\n\
        Intrusion detection\n\n\n\n\nSession overload\nExcessive signalling or media\
        \ traffic(malicious, non-malicious) is experienced\_\nDenial of service\_\n\
        \n\n\_Protection against registration floods\n\n\n\n\nProtocol fuzzing\nMalformed\
        \ packets, semantically or syntactically incorrect flows are encountered\_\
        \nDenial of service\_\n\n\nMalformed packet protection\nProtocol anomaly protection\n\
        TCP reassembly for fragmented packet protection\nStrict TCP validation to\
        \ ensure TCP session state enforcement, validation of sequence and acknowledgement\
        \ numbers, rejection of bad TCP flag combinations\n\n\n\n\nMedia injection\n\
        Attacker inserts unwanted or corrupted content into messages compromising\
        \ packet/data stream integrity\_\nDenial of service, fraud\n\n\nApplication\
        \ aware firewalls\nIntrusion prevention /detection\nEncryption\n\n\n\n\nToll\
        \ Fraud\nUnexplained/unusual calling activity, increased costs/carrier notification/alert\_\
        \nFraud, financial loss, breach of privacy, information loss\_\n\n\nApplication\
        \ aware firewalls\nIntrusion prevention /detection\nEncryption\n\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:5
      ref_id: 19.5.17
      description: Encryption is discussed in Chapter 17 - Cryptography.
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Product Selection
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:6
      description: Protection Profiles
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:6:1
      ref_id: 19.5.18
      description: "One Protection Profile for SBCs has been published by NIAP (dated\
        \ July 24, 2015 - see reference table).\_ Several other Protection profiles\
        \ (PPs) specifically for SBCs are in development but not yet published (as\
        \ at September 2015).\_ Gateway and other border control device PPs are used\
        \ as surrogates in the interim.\_ Refer to Chapter 12 \u2013 Product Security."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:6
      description: Desirable SBC Functionality
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:6:2
      ref_id: 19.5.19
      description: "To manage risks and threats and to safeguard performance there\
        \ are a number of desirable features in an SBC.\_ These include:\nSecurity\
        \ \u2013 SBC DoS protection, access control, topology hiding, VPN separation,\
        \ service infrastructure DoS prevention;\nEncryption \u2013 Support for Suite\
        \ B encryption;\nService Reach \u2013 surrogate registration IP PBX endpoints,\
        \ SIP IMS-H.323 PBX IWF; VPN bridging;\nSLA assurance \u2013 admission control;\
        \ bandwidth per VPN & site, session agent constraints, policy server; intra-VPN\
        \ media release; QoS marking/mapping; QoS reporting;\nFraud and Revenue protection\
        \ \u2013 bandwidth policing, QoS theft protection, accounting, session timers;\n\
        Regulatory compliance \u2013 provision of emergency service calls (111) &\
        \ lawful intercept.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:7
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Security Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.20
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:7
      ref_id: 19.5.20
      description: 'Typical use of session border controller in an agency gateway
        is illustrated in Figure 1 below:

        '
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:8
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: General References
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.21
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:8
      ref_id: 19.5.21
      description: "Additional information on Session Border Controllers can be found\
        \ in the following references:\n\n\nReference\nTitle\nPublisher\nSource\n\n\
        \nNIST Special Publication 800-58, January 2005\nSecurity Considerations for\
        \ Voice Over IP Systems\nNIST\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-58.pdf\
        \ [PDF, 922 KB]\n\n\n\_\nSecurity Issues and Countermeasure for VoIP\nSANS\n\
        https://www.sans.org/white-papers/1701/\n\n\nReport Number: I332-016R-2005\n\
        Security Guidance for Deploying IP Telephony Systems Released: 14 February\
        \ 2006\nSystems and Network Attack Center (SNAC) NSA\nhttps://www.nsa.gov/ia/_files/voip/i332-016r-2005.pdf\n\
        \n\nReport Number: I332-009R-2006\nRecommended IP Telephony Architecture,\
        \ Updated: 1May2006 Version1.0\nSystems and Network Attack Center (SNAC) NSA\n\
        https://www.nsa.gov/ia/_files/voip/I332-009R-2006.pdf\n\n\n\_\nMobility Capability\
        \ Package March 26 2012 - Secure VoIP Version 1.2\nNSA\nhttps://www.nsa.gov/ia/_files/Mobility_Capability_Pkg_Vers_1_2.pdf\n\
        \n\n\_\nProtecting Telephone-based Payment Card Data PCI Data Security Standard\
        \ (PCI DSS) Version:\_ 2.0, March 2011\nThe\_ PCI Security\_ Standards\_ Council\
        \ (PCI SSC)\nhttps://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf\
        \ [PDF, 888 KB]\n\n\n\_\nUnderstanding Voice over Internet Protocol (VoIP):\
        \ 2006\nUS-CERT\nhttps://www.us-cert.gov/sites/default/files/publications/understanding_voip.pdf\
        \ [PDF, 83 KB]\n\n\nCNSS Instruction No. 5000 April 2007\nGuidelines for Voice\
        \ over Internet Protocol (VoIP) Computer Telephony\nCommittee on National\
        \ Security Systems\nhttps://www.cnss.gov/CNSS/issuances/Instructions.cfm\n\
        \n\n\_\nInfrastructure qualified for Microsoft Lync\nMicrosoft TechNet\nhttps://technet.microsoft.com/en-us/office/dn788945.aspx\n\
        \n\n\_\nA Guide to the Public Records Act\nArchives New Zealand\nhttps://archives.govt.nz/manage-information/how-to-manage-your-information/key-obligations-and-the-standard/key-obligations-public-records-act-2005\n\
        \n\nPublic Act 2002 No.35\nElectronic Transactions Act 2002\n\_\nhttps://www.legislation.govt.nz/act/public/2002/0035/latest/DLM154185.html\n\
        \n\n\_\nNetwork Device Collaborative Protection Profile (NDcPP) Extended Package\
        \ Session Border Controller, September 2016, version 1.1\nNIAP\nep_sbc_v1.1.pdf\
        \ (niap-ccevs.org)\n\n\n\_\n\nPP-Module for Voice and Video over IP (VVoIP),\_\
        October 2020, version 1.0\_\n\nNIAP\_\n\nmod_vvoip_v1.0.pdf (niap-ccevs.org)\n\
        NIAP (niap-ccevs.org)\n\n\n\n\_\nDHS 4300A Sensitive Systems Handbook Attachment\
        \ Q5 To Handbook v. 11.0 Voice over Internet Protocol (VoIP) Version 11.0\
        \ December 22, 2014\nDHS\nhttps://www.dhs.gov/sites/default/files/publications/4300A%20Handbook%20Attachment%20Q5%20-%20Voice%20over%20IP.pdf\
        \ [PDF, 586 KB]\n\n\n\_\n2015 Global Fraud Loss Survey\nCFCA\nhttps://cfca.org/fraudloss-survey/\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:9
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Media Technical References
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.22
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:9
      ref_id: 19.5.22
      description: "Media technical references are listed below:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\nRFC 2833\nRTP Payload for DTMF Digits, Telephony\
        \ Tones and Telephony Signals\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc2833\n\
        \n\nRFC 3313\nPrivate Session Initiation Protocol (SIP) Extensions for Media\
        \ Authorization\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3313\n\n\n\
        RFC 3550\nRTP: A Transport Protocol for Real-Time Applications\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3550\n\
        \n\nRFC 3685\nReal Time Control Protocol (RTCP) attribute in Session Description\
        \ Protocol (SDP)\nIETF\nhttps://datatracker.ietf.org/doc/html/rfc3685\n\n\n\
        RFC 3362\nReal-time Facsimile (T.38) - image/t38 MIME Sub-type Registration\n\
        IETF\nhttps://datatracker.ietf.org/doc/html/rfc3362\n\n\nT.38 (09/2010)\n\
        Procedures for real-time Group 3 facsimile communication over IP networks\n\
        International Telecommunication Union\nhttps://www.itu.int/rec/T-REC-T.38/e\n\
        \n\nV.150.1 (01/2003)\n\nModem-over-IP networks: Procedures for the\nend-to-end\
        \ connection of V-series DCEs\nInternational Telecommunication Union\nhttps://www.itu.int/rec/T-REC-V.150.1-200301-I/en\n\
        \n\nG.711\nPulse code modulation (PCM) of voice frequencies\nInternational\
        \ Telecommunication Union\nhttps://www.itu.int/rec/T-REC-G.711/\n\n\nG.726\n\
        40, 32, 24, 16 kbit/s adaptive differential pulse code modulation (ADPCM)\n\
        International Telecommunication Union\nhttps://www.itu.int/rec/T-REC-G.726/e\n\
        \n\nG. 729 (06/2012)\_\nCoding of speech at 8 kbit/s using conjugate-structure\
        \ algebraic-code-excited linear-prediction (CS-ACELP)\nInternational Telecommunication\
        \ Union\nhttps://www.itu.int/rec/T-REC-G.729/e\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:10
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Signalling Technical References
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.23
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:10
      ref_id: 19.5.23
      description: "Signalling technical references are listed below:\n\n\nReference\n\
        Title\nPublisher\nSource\n\n\nRFC 2705\_\nMedia Gateway Control Protocol (MGCP)\
        \ Version 1.0\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc2705\n\n\nRFC\
        \ 3525\nGateway Control Protocol Version 1.0\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc3525\n\
        \n\nRFC 3261\nSIP: Session Initiation Protocol\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc3261\n\
        \n\nRFC 3263\nLocating SIP Servers\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc3263\n\
        \n\nRFC 4028\nSIP Session Timer\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc4028\n\
        \n\nRFC 3966\nThe tel URI for Telephone Numbers\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc3966\n\
        \n\nRFC 3924\nCisco Architecture for Lawful Intercept in IP Networks\nIEFT\n\
        https://datatracker.ietf.org/doc/html/rfc3924\n\n\nRFC 2327\nSession Description\
        \ Protocol\nIEFT\n\nhttps://datatracker.ietf.org/doc/html/rfc2327\n\n\n\n\
        RFC 3025\nGateway Control Protocol Version 1, June 2003\nIEFT\nhttps://datatracker.ietf.org/doc/html/rfc3025\n\
        \n\nH.248 (03/2013)\nMedia Gateway Control (Megaco): Version 3\nInternational\
        \ Telecommunication Union\nhttps://www.itu.int/rec/T-REC-H.248.1/en\n\n\n\
        H.323 (12/2009)\nPacket-based multimedia communications systems\nInternational\
        \ Telecommunication Union\nhttps://www.itu.int/rec/T-REC-H.323/en/\n\n\nH.450\n\
        Supplementary Services for H.323\nInternational Telecommunication Union\n\
        https://www.itu.int/en/Pages/default.aspx\n\n\nMSF Technical Report MSF-TR-QoS-001-FINAL\n\
        Quality of Service for next generation VoIP networks framework\nMultiservice\
        \ Switching Forum (MSF)\nhttp://www.recursosvoip.com/docs/english/MSF-TR-QoS-001-FINAL.pdf\
        \ [PDF, 778 KB]\n\n\nETSI TS 129 305 V8.0.0 (2009-01)\nUniversal Mobile Telecommunications\
        \ System (UMTS); LTE; InterWorking Function (IWF) between MAP based and Diameter\
        \ based interfaces.\nEuropean Telecommunications Standards Institute\nhttps://www.etsi.org/deliver/etsi_ts/129300_129399/129305/08.00.00_60/ts_129305v080000p.pdf\
        \ [PDF, 425 KB]\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.R.01
      description: "The adoption of Voice over Internet Protocol (VoIP) and Unified\
        \ Communication (UC) networks will introduce a range of technology risks in\
        \ addition to the technology and systems risks that already exist for agency\
        \ systems.\_ It is vital that these risks are identified and assessed in order\
        \ to design a robust security architecture and to select appropriate controls\
        \ and countermeasures."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.R.02
      description: "The availability of agency systems, business functionality and\
        \ any customer or client online services, is subject to further risks in an\
        \ outsourced environment.\_ A risk assessment will include consideration of\
        \ business requirements on availability in a VoIP and UC environment."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.R.03
      description: "Risks to business functionality may include service outages, such\
        \ as communications, data centre power, backup and other failures or interruptions.\
        \ \_Entity failures such as the merger, acquisition or liquidation of the\
        \ service provider may also present a significant business risk to availability."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.R.04
      description: "Testing is a valuable tool when assessing risk. \_A UC environment\
        \ with complex communications streams can provide opportunities for exploitation,\
        \ especially where the configuration is weak or has itself been compromised.\
        \ \_One of the fundamental tools is penetration testing."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.01
      name: 'Control -  All Classifications - Must [CID: 4703]'
      description: Agencies intending to adopt VoIP or UC technologies or services
        MUST conduct a comprehensive risk assessment before implementation or adoption.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.02
      name: 'Control -  All Classifications - Must [CID: 4705]'
      description: Agencies intending to adopt VoIP or UC technologies or services
        MUST consider the risks to the availability of systems and information in
        their design of VoIP and UC systems architecture, fault tolerance, fail over
        and supporting controls and governance processes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.03
      name: 'Control -  All Classifications - Must [CID: 4706]'
      description: "Agencies MUST ensure risks for any VoIP or UC service adopted\
        \ are understood and formally accepted by the agency\u2019s Accreditation\
        \ Authority as part of the Certification and Accreditation process (See Chapter\
        \ 4 - System Certification and Accreditation)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.04
      name: 'Control -  All Classifications - Must [CID: 4707]'
      description: Agencies intending to adopt VoIP or UC technologies or services
        MUST determine where the responsibility (agency or VoIP and UC service provider)
        for implementing, managing and maintaining controls lies in accordance with
        agreed trust boundaries.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.05
      name: 'Control -  All Classifications, Restricted/Sensitive - Must [CID: 4708]'
      description: Any contracts for the provision of VoIP or UC services MUST include
        service level, availability, recoverability and restoration provisions as
        formally determined by business requirements.
      implementation_groups:
      - All Classifications - MUST
      - Restricted/Sensitive - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.06
      name: 'Control -  All Classifications - Must [CID: 4709]'
      description: Agencies MUST ensure contracts with VoIP or UC service providers
        include provisions to manage risks associated with the merger, acquisition,
        liquidation or bankruptcy of the service provider and any subsequent termination
        of VoIP or UC services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.07
      name: 'Control -  All Classifications - Must [CID: 4710]'
      description: "Agencies procuring or using VoIP or UC services to be used by\
        \ multiple agencies MUST ensure all interested parties formally agree to the\
        \ risks, controls and any residual risks of such VoIP and UC services. \_\
        The lead agency normally has this responsibility (see Chapter 2 - Information\
        \ Security services within Government and Chapter 4 - System Certification\
        \ and Accreditation)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.24.c.08
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:1
      ref_id: 19.5.24.C.08
      name: 'Control -  All Classifications - Should [CID: 4711]'
      description: Agencies SHOULD consider the use of assessment tools, such as penetration
        testing, when undertaking the risk assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: Non-Agency Networks
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:2
      ref_id: 19.5.25.R.01
      description: "Networks furnished by a service provider are invariably shared\
        \ networks. \_Much of the security configuration is designed to maximise operational\
        \ efficiency of the Service Providers network. \_Any agency specific security\
        \ requirements may attract additional cost."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.25.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:2
      ref_id: 19.5.25.R.02
      description: "It is preferable to maintain an agency designed and controlled\
        \ gateway to ensure security requirements are properly accommodated. \_The\
        \ use of SBCs should be carefully considered in order to maximise efficiency\
        \ consistent with security requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:2
      ref_id: 19.5.25.C.01
      name: 'Control -  All Classifications - Must [CID: 4715]'
      description: Agencies MUST follow the gateway requirements described in Chapter
        19 - Gateway Security.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: Security Architecture and Configuration
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.R.01
      description: "Trust boundaries must be defined to assist in determining effective\
        \ controls and where these controls can best be applied. \_Trust zones and\
        \ trust boundaries are discussed in 22.1.3. \_The use of SBCs will assist\
        \ with the definition of trust boundaries and allow the segregation of UC\
        \ and normal data."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.R.02
      description: "The threat model for IP is well understood. \_Data packets can\
        \ be intercepted or eavesdropped anywhere along the transmission path including\
        \ the corporate network, by the internet service provider and along the backbone.\
        \ \_The prevalence and ease of packet sniffing and other techniques for capturing\
        \ packets on an IP based network increases this threat level. \_VoIP Encryption\
        \ is an effective means of mitigating this threat."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.R.03
      description: "The nature of traffic through an SBC is an important factor in\
        \ determining the type and configuration of the SBC. \_This also plays an\
        \ important role in determining the resilience of the system. \_Systems may\
        \ require high availability (HA), depending on business requirements for availability\
        \ and continuity of service. \_The use of split trunks for HA normal traffic\
        \ may provide resilience at reduced costs."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.01
      name: 'Control -  All Classifications - Must [CID: 4720]'
      description: Agencies intending to adopt VoIP or UC technologies or services
        MUST determine trust boundaries before implementation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.02
      name: 'Control -  All Classifications - Must [CID: 4721]'
      description: Updates to the SBC and related devices MUST be verified by the
        administrator to ensure they are obtained from a trusted source and are unaltered.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.03
      name: 'Control -  All Classifications - Must [CID: 4722]'
      description: Agencies MUST include defence mechanisms for the Common VoIP and
        UC Security Risks and Threats described in 19.5.10.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.04
      name: 'Control -  All Classifications - Must [CID: 4723]'
      description: Agency networks MUST ensure the SBC includes a topology hiding
        capability.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.05
      name: 'Control -  All Classifications - Must [CID: 4724]'
      description: Agency networks MUST consider the use of call diversity and call
        failover configurations.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.06
      name: 'Control -  All Classifications - Must [CID: 4725]'
      description: In a virtualised environment, agencies MUST ensure any data contained
        in a protected resource is deleted or not available when the virtual resource
        is reallocated.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.07
      name: 'Control -  All Classifications - Should [CID: 4726]'
      description: "Agencies SHOULD conduct a traffic analysis to ensure the agency\u2019\
        s network and architecture is capable of supporting all VoIP, media and UC\
        \ traffic. \_The traffic analysis SHOULD also determine any high availability\
        \ requirements."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.08
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.08
      name: 'Control -  All Classifications - Should [CID: 4727]'
      description: "Agencies SHOULD design a security and gateway architecture that\
        \ segregates UC and normal data traffic. \_Firewall requirements (Section\
        \ 19.3 - Firewalls) continue to apply to data traffic."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.09
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.09
      name: 'Control -  All Classifications - Should [CID: 4728]'
      description: In a virtualised environment, agencies SHOULD create separate virtual
        LANs for data traffic and UC traffic.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.10
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.10
      name: 'Control -  All Classifications - Should [CID: 4729]'
      description: In a non-virtualised environment, agencies SHOULD create separate
        LANs for data traffic and UC traffic.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.11
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.11
      name: 'Control -  All Classifications - Should [CID: 4730]'
      description: Agency networks SHOULD use encryption internally on VoIP and unified
        communications traffic.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.26.c.12
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:3
      ref_id: 19.5.26.C.12
      name: 'Control -  All Classifications - Should [CID: 4731]'
      description: Agency networks SHOULD ensure intrusion prevention systems and
        firewalls are VoIP-aware.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: Access Control
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.R.01
      description: "Network access control and password requirements are described\
        \ in Chapter 16 - Access control and passwords, in particular Section 16.6\
        \ \u2013 Event Logging and Auditing. \_Event logging helps improve the security\
        \ posture of a system by increasing the accountability of all user actions,\
        \ thereby improving the chances that malicious behaviour will be detected\
        \ and assist in the investigation of incidents. \_A fundamental of access\
        \ control is to manage access rights including physical access, file system\
        \ and data access permissions and programme execution permissions. \_In addition,\
        \ access control provides a record of usage in the event of an incident. \_\
        Retention of records and archiving is discussed in\_13.1.12 - Archiving."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.R.02
      description: "Similar requirements apply to VoIP and UC networks as these are\
        \ also IP based. \_This will include any service enabled as part of the UC\
        \ environment, such as Chat, IM, video and teleconferencing."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.R.03
      description: "There may be special cases, such as a 24x7 operations centre,\
        \ where VoIP phones are shared by several duty officers on a shift basis.\
        \ \_Workloads may require a number of duty personnel at any one time. \_In\
        \ such cases it may be impractical to allocate individual VoIP or UC UserID\
        \ and passwords. \_The risks in such cases must be clearly identified and\
        \ compensating controls applied to ensure traceability in the event of fault\
        \ finding or an incident. \_Examples of compensating controls include physical\
        \ access control, CCTV, and duty registers. \_Identification of shared facilities\
        \ is important and may comprise a UserID such as \u201CDuty Officer\u201D\
        , SOC, or agency name in a multi-agency facility."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.01
      name: 'Control -  All Classifications - Must [CID: 4737]'
      description: Any shared facilities MUST be clearly identifiable both physically
        and logically.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.02
      name: 'Control -  All Classifications - Must [CID: 4738]'
      description: "Agencies MUST provide a protected communication channel for administrators,\
        \ and authorised systems personnel. \_Such communication MUST be logged."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.03
      name: 'Control -  All Classifications - Must [CID: 4739]'
      description: Agencies MUST ensure administrative access to the SBC is available
        only through a trusted LAN and secure communication path.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.04
      name: 'Control -  All Classifications - Should [CID: 4740]'
      description: Access control and password requirements SHOULD apply to VoIP and
        UC networks in all cases where individual access is granted.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.05
      name: 'Control -  All Classifications - Should [CID: 4741]'
      description: In special cases where individual UserIDs and Passwords are impractical,
        a risk assessment SHOULD be completed and compensating controls applied.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.27.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:4
      ref_id: 19.5.27.C.06
      name: 'Control -  All Classifications - Should [CID: 4742]'
      description: Event logs covering all VoIP and UC services SHOULD be maintained
        in accordance with the requirements of the NZISM. See sections 16.6 - Event
        Logging and Auditing and 13.1.12 - Archiving.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: Incident Handling and Management
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.R.01
      description: "Service providers may not provide the same level of incident identification\
        \ and management as provided by agencies. \_In some cases, these services\
        \ will attract additional costs. \_Careful management of contracts is required\
        \ to ensure agency requirements for incident detection and management are\
        \ fully met when adopting VoIP and UC services."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.R.02
      description: "Deny listing denies calls to specific numbers, range of numbers,\
        \ or countries.\_ Allow listing allows calls to numbers, range of numbers,\
        \ or countries. \_A combination of deny and allow listing enables a flexible\
        \ method of preventing call fraud (hijacking and \u201Ccall pumping\u201D\
        ), for example, by allowing calls to a specific number within a country on\
        \ a deny list."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.R.03
      description: "Call Rate Limiting allows the restriction of outbound call volumes\
        \ to specific numbers, range of numbers or countries. \_This is a useful mitigation\
        \ for \u201Ctraffic pumping\u201D call fraud schemes. \_Call rate limiting\
        \ also allows temporary limits to be placed on call from or to particular\
        \ destinations while a security incident is investigated."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.R.04
      description: "Call Redirection enables the transfer of blocked calls to another\
        \ destination including via monitoring and recording systems. \_Blocked calls\
        \ may be dropped or a message played indicating, for example, that calls cannot\
        \ be connected."
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.01
      name: 'Control -  All Classifications - Must [CID: 4748]'
      description: Agencies MUST include incident handling and management services
        in contracts with service providers.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.02
      name: 'Control -  All Classifications - Must [CID: 4749]'
      description: "Agencies MUST develop and implement incident identification and\
        \ management processes in accordance with this manual (See Chapter 6 \u2013\
        \ Information Security Monitoring, Chapter 7 \u2013 Information Security Incidents,\
        \ Chapter 9 \u2013 Personnel Security and Chapter 16 \u2013 Access control\
        \ and passwords)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.03
      name: 'Control -  All Classifications - Should [CID: 4750]'
      description: Agencies SHOULD implement fraud detection monitoring to identify
        suspicious activity and provide alerting so that remedial action can be taken.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.04
      name: 'Control -  All Classifications - Should [CID: 4751]'
      description: Agencies SHOULD regularly review call detail records for patterns
        of service theft.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.05
      name: 'Control -  All Classifications - Should [CID: 4752]'
      description: Agencies SHOULD consider the use of allow and deny listing to manage
        fraudulent calls to known fraudulent call destinations.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.06
      name: 'Control -  All Classifications - Should [CID: 4753]'
      description: Agencies SHOULD consider the use of call rate limiting as a fraud
        mitigation measure.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.28.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:5
      ref_id: 19.5.28.C.07
      name: 'Control -  All Classifications - Should [CID: 4755]'
      description: Agencies SHOULD consider the use of call redirection to manage
        blocked calls.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:19.5:11:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11
      description: User Awareness and Training
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.29.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:6
      ref_id: 19.5.29.R.01
      description: The introduction of VoIP and UC services will introduce change
        to the appearance and functionality of systems, how users access agency systems
        and types of user support. It is essential that users are aware of information
        security and privacy concepts and risks associated with the services they
        use.Support provided by the VoIP and UC service provider may attract additional
        charges.
    - urn: urn:defend:risk:req_node:nzism-v3:19.5.29.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:19.5:11:6
      ref_id: 19.5.29.C.01
      name: 'Control -  All Classifications - Must [CID: 4758]'
      description: "Agencies MUST develop and implement user awareness and training\
        \ programmes to support and enable safe use of VoIP and UC services (See Section\
        \ 9.1 \u2013 Information Security Awareness and Training)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20
      assessable: false
      depth: 1
      ref_id: '20'
      name: Data management
    - urn: urn:defend:risk:req_node:nzism-v3:20.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:20
      ref_id: '20.1'
      name: Data Transfers
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:1
      ref_id: 20.1.1
      description: Data transfers between systems are controlled and accountable.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:2:1
      ref_id: 20.1.2
      description: This section covers the fundamental requirements of data transfers
        between systems and applies equally to data transfers using removal media
        and to data transfers via gateways.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:2:1
      ref_id: 20.1.3
      description: "Additional requirements for data transfers using removal media\
        \ can be found in the Section 13.3 \u2013 Media Usage and additional requirements\
        \ for data transfers via gateways can be found in the Section 20.2 \u2013\
        \ Data Import and Export."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:2:1
      ref_id: 20.1.4
      description: "Transfers from a classified system where strong information security\
        \ controls exist to a system of lower classification where controls may not\
        \ be as robust, can lead to data spills, information loss and privacy breaches.\
        \ \_It is important that appropriate levels of oversight and accountability\
        \ are in place to minimise or prevent the undesirable loss or leakage of information."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:3
      ref_id: 20.1.5
      description: "Relevant PSR requirements can be found at:\n\_\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\nGOV2, GOV6, INFOSEC1, INFOSEC2,\
        \ INFOSEC3, INFOSEC4, PERSEC1, PERSEC2, PERSEC3 and PERSEC4\n\nHome | Protective\
        \ Security Requirements\nSecurity governance (GOV) | Protective Security Requirements\n\
        Information security (INFOSEC) | Protective Security Requirements \_\nPersonnel\
        \ security (PERSEC) | Protective Security Requirements\n\n\n\nPSR content\
        \ protocols \n\n\nManagement protocol for information security\nManagement\
        \ protocol for personnel security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for personnel\
        \ security | Protective Security Requirements\n\n\n\n\nPSR requirements sections\n\
        \n\nClassify and assign protective markings\nUnderstand the information security\
        \ lifecycle\n\n\nhttps://www.protectivesecurity.govt.nz/information-security/lifecycle/understand-what-information-and-ict-systems-you-need-to-protect/\n\
        https://www.protectivesecurity.govt.nz/information-security/lifecycle/\n\n\
        \n\n\nManaging specific scenarios\n\n\nManaging specific scenarios | Protective\
        \ Security Requirements\_\n\n\nTransacting online with the public\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: User responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:1
      ref_id: 20.1.6.R.01
      description: "When users transfer data to and from systems they need to be aware\
        \ of the potential consequences of their actions. \_This could include data\
        \ spills of classified information onto systems not accredited to handle the\
        \ classification of the data or the unintended introduction of malicious code.\
        \ \_Accordingly agencies will need to hold personnel accountable for all data\
        \ transfers that they make."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:1
      ref_id: 20.1.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4138]'
      description: Agencies MUST establish a policy and train staff in the processes
        for data transfers between systems and the authorisations required before
        transfers can take place.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:1
      ref_id: 20.1.6.C.02
      name: 'Control -  All Classifications - Must [CID: 4141]'
      description: Agencies MUST ensure that system users transferring data to and
        from a system are held accountable for the data they transfer.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Data transfer processes and procedures
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:2
      ref_id: 20.1.7.R.01
      description: Personnel can assist in preventing information security incidents
        by checking protective markings (classifications, endorsements and releasability)
        checks to ensure that the destination system is appropriate for the protection
        of the data being transferred, performing antivirus checks on data to be transferred
        to and from a system, and following all processes and procedures for the transfer
        of data.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:2
      ref_id: 20.1.7.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4147]'
      description: Agencies MUST ensure that data transfers are performed in accordance
        with processes and procedures approved by the Accreditation Authority.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:2
      ref_id: 20.1.7.C.02
      name: 'Control -  All Classifications - Should [CID: 4148]'
      description: Agencies SHOULD ensure that data transfers are performed in accordance
        with processes and procedures approved by the Accreditation Authority.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Data transfer authorisation
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:3
      ref_id: 20.1.8.R.01
      description: Using a trusted source to approve transfers from a classified system
        to another system of a lesser classification or where a releasability endorsement
        is applied to the data to be transferred, ensures appropriate oversight and
        reporting of the activity.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:3
      ref_id: 20.1.8.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4151]'
      description: Agencies MUST ensure that all data transferred to a system of a
        lesser classification or a less secure system, is approved by a trusted source.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Trusted sources
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:4
      ref_id: 20.1.9.R.01
      description: "Trusted sources are designated personnel who have the delegated\
        \ authority to assess and approve the transfer or release of data or documents.\
        \ \_Trusted sources may include security personnel within the agency such\
        \ as the CISO and the ITSM."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:4
      ref_id: 20.1.9.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 4156]'
      description: 'Trusted sources MUST be:

        a strictly limited list derived from business requirements and the result
        of a security risk assessment;

        where necessary an appropriate security clearance is held; and

        approved by the Accreditation Authority.

        '
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Import of data
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      ref_id: 20.1.10.R.01
      description: Scanning imported data for active or malicious content reduces
        the security risk of a system or network being infected, thus allowing the
        continued confidentiality, integrity and availability of the system or network.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.10.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      ref_id: 20.1.10.R.02
      description: "Format checks provide a method to prevent known malicious formats\
        \ from entering the system or network. \_Keeping and regularly auditing these\
        \ logs allow for the system or network to be checked for any unusual activity\
        \ or usage."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.10.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      ref_id: 20.1.10.R.03
      description: "Personnel reporting unexpected events through the agency\u2019\
        s incident management process provide an early opportunity to contain malware,\
        \ limit damage and correct errors."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      ref_id: 20.1.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4165]'
      description: Agencies importing data to a system MUST ensure that the data is
        scanned for malicious and active content.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:5
      ref_id: 20.1.10.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4168]'
      description: 'Agencies importing data to a system MUST implement the following
        controls:

        scanning for malicious and active content;

        data format checks;

        identify unexpected attachments or embedded objects;

        log each event; and

        monitoring to detect overuse/unusual usage patterns.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Export of highly formatted textual data
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:6
      ref_id: 20.1.11.R.01
      description: When highly formatted textual data with no free text fields is
        to be transferred between systems, the checking requirements are lessened
        because the format of the information is strongly defined.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:6
      ref_id: 20.1.11.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 4239]'
      description: 'When agencies export formatted textual data with no free text
        fields and all fields have a predefined set of permitted formats and data
        values, agencies MUST implement the following controls:

        protective marking checks;

        data validation and format checks;

        size limits;

        keyword checks;

        identify unexpected attachments or embedded objects;

        log each event; and

        monitoring to detect overuse/unusual usage patterns.

        '
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Export of other data
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:7
      ref_id: 20.1.12.R.01
      description: "Textual data that it is not highly formatted can be difficult\
        \ to check in an automated manner. \_Agencies will need to implement measures\
        \ to ensure that classified information is not accidentally being transferred\
        \ to another system not accredited for that classification or transferred\
        \ into the public domain."
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:7
      ref_id: 20.1.12.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4245]'
      description: 'When agencies export data, other than highly formatted textual
        data, agencies MUST implement the following controls:

        protective marking checks;

        data validation and format checks;

        limitations on data types;

        size limits;

        keyword checks;

        identify unexpected attachments or embedded objects;

        log each event; and

        monitoring to detect overuse/unusual usage patterns.

        '
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.1:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4
      description: Preventing export of NZEO data to foreign systems
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:8
      ref_id: 20.1.13.R.01
      description: In order to reduce the security risk of spilling data with an endorsement
        onto foreign systems, it is important that procedures are developed to detect
        NZEO marked data and to prevent it from crossing into foreign systems or being
        exposed to foreign nationals.
    - urn: urn:defend:risk:req_node:nzism-v3:20.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.1:4:8
      ref_id: 20.1.13.C.01
      name: 'Control -  All Classifications - Must [CID: 4249]'
      description: 'Agencies MUST:

        ensure that keyword searches are performed on all textual data;

        ensure that any identified data is quarantined until reviewed and approved
        for release by a trusted source other than the originator; and

        develop procedures to prevent NZEO information in both textual and non-textual
        formats from being exported.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:20
      ref_id: '20.2'
      name: Data Import and Export
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:1
      ref_id: 20.2.1
      description: "Data is\_transferred through gateways in a controlled and accountable\
        \ manner."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:2:1
      ref_id: 20.2.2
      description: "This section covers the specific requirements relating to the\
        \ movement of data between systems via gateways. \_Fundamental requirements\
        \ of data transfers between systems can be found in Section 20.1 \u2013 Data\
        \ Transfers. \_These fundamental requirements apply to gateways."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: User responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:1
      ref_id: 20.2.3.R.01
      description: "When users transfer data to or from a system they need to be aware\
        \ of the potential consequences of their actions. \_This could include data\
        \ spills of sensitive or classified data onto systems not accredited to handle\
        \ the data, or the unintended introduction of malicious code to a system.\
        \ \_ Accordingly, users need to be held accountable for all data transfers\
        \ they make."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:1
      ref_id: 20.2.3.C.01
      name: 'Control -  All Classifications - Must [CID: 4264]'
      description: Users transferring data to and from a system MUST be held accountable
        for the data they transfer.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Data Transfer authorisation
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:2
      ref_id: 20.2.4.R.01
      description: 'Users can help prevent information security incidents by:

        checking protective markings to ensure that the destination system is appropriate
        for the data being transferred;

        performing antivirus checks on data to be transferred to and from a system;

        following the processes and procedures for the transfer of data.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:2
      ref_id: 20.2.4.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4269]'
      description: All data transferred to a system of a lesser sensitivity or classification
        MUST be approved by a trusted source.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Trusted sources
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:3
      ref_id: 20.2.5.R.01
      description: "Trusted sources are designated personnel who have the delegated\
        \ authority to assess and approve the transfer or release of data or documents.\
        \ Trusted sources may include security personnel within the agency such as\
        \ the CISO and the ITSM.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:3
      ref_id: 20.2.5.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 4277]'
      description: 'Trusted sources MUST be:

        a strictly limited list derived from business requirements and the result
        of a security risk assessment;

        where necessary an appropriate security clearance is held; and

        approved by the Accreditation Authority.

        '
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Import of data through gateways
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:4
      ref_id: 20.2.6.R.01
      description: "In order to ensure the continued functioning of systems it is\
        \ important to constantly analyse data being imported. \_Converting data from\
        \ one format into another can effectively destroy most malicious active content."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:4
      ref_id: 20.2.6.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4280]'
      description: When agencies import data to a system through gateways, the data
        MUST be filtered by a product specifically designed for that purpose, including
        filtering malicious and active content.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:4
      ref_id: 20.2.6.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4281]'
      description: When agencies import data to a system through gateways, full or
        partial audits of the event logs MUST be performed at least monthly.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.6.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:4
      ref_id: 20.2.6.C.03
      name: 'Control -  Confidential, Secret, Top Secret - Should [CID: 4282]'
      description: Agencies SHOULD convert data being imported at gateways into an
        alternative format before entering the network.
      implementation_groups:
      - Confidential - SHOULD
      - Secret - SHOULD
      - Top Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Export of data through gateways
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:5
      ref_id: 20.2.7.R.01
      description: In order to ensure the continued integrity and confidentiality
        of data on an agency network, data MUST pass through a series of checks before
        it is exported onto systems of a lesser classification.
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.7.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:5
      ref_id: 20.2.7.R.02
      description: Filtering content based on protective markings is an adequate method
        to protect the confidentiality of lesser classified material.
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:5
      ref_id: 20.2.7.C.01
      name: 'Control -  All Classifications - Should [CID: 4286]'
      description: Agencies SHOULD restrict the export of data to a system of a lesser
        classification by filtering data using at least protective marking checks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Export of highly formatted textual data through gateways
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:6
      ref_id: 20.2.8.R.01
      description: "The security risks of releasing higher classified data are partially\
        \ reduced when the data is restricted to highly formatted textual data. \_\
        In such cases the data is less likely to contain hidden data and have classified\
        \ content. \_Such data can be automatically scanned through a series of checks\
        \ to detect classified content. \_Risk is further reduced when there is a\
        \ gateway filter that blocks (rejects) the export of data classified above\
        \ the classification of the network outside of the gateway, and logs are regularly\
        \ reviewed to detect if there has been unusual usage or overuse."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:6
      ref_id: 20.2.8.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4289]'
      description: 'When the export of highly formatted textual data occurs through
        gateways agencies MUST implement:

        checks for protective markings;

        data filtering performed by a product specifically designed for that purpose;

        data range and data type checks; and

        full or partial audits of the event logs performed at least monthly.

        '
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Export of other data through gateways
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      ref_id: 20.2.9.R.01
      description: "Textual data which is not highly formatted can contain hidden\
        \ data as well as having a higher classification due to the aggregated content.\
        \ \_Risk is somewhat reduced by running additional automated checks on non-formatted\
        \ data being exported, in addition to those checks for highly formatted textual\
        \ data. \_Where a classification cannot be automatically determined, a human\
        \ trusted source should make that determination."
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      ref_id: 20.2.9.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 4292]'
      description: When agencies export data, other than highly formatted textual
        data, through gateways, agencies MUST implement data filtering performed by
        a product specifically designed for that purpose.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      ref_id: 20.2.9.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4293]'
      description: When agencies do not perform audits of the complete data transfer
        logs at least monthly they MUST perform randomly timed audits of random subsets
        of the data transfer logs on a weekly basis.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      ref_id: 20.2.9.C.03
      name: 'Control -  Top Secret, Secret, Confidential - Should [CID: 4294]'
      description: Where the classification cannot be determined automatically, a
        human trusted source SHOULD assess the classification of the data.
      implementation_groups:
      - Top Secret - SHOULD
      - Secret - SHOULD
      - Confidential - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.9.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:7
      ref_id: 20.2.9.C.04
      name: 'Control -  Top Secret, Confidential, Secret - Should [CID: 4295]'
      description: When the export of other data occurs through gateways agencies
        SHOULD perform audits of the complete data transfer logs at least monthly.
      implementation_groups:
      - Top Secret - SHOULD
      - Confidential - SHOULD
      - Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Preventing export of NZEO data to foreign systems
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:8
      ref_id: 20.2.10.R.01
      description: NZEO networks are particularly sensitive and further security measures
        need to be put in place when connecting them to other networks.
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:8
      ref_id: 20.2.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4301]'
      description: To prevent the export of NZEO data to foreign systems, agencies
        MUST implement NZEO data filtering performed by a product specifically designed
        or configured for that purpose.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:8
      ref_id: 20.2.10.C.02
      name: 'Control -  All Classifications - Must [CID: 4303]'
      description: Agencies MUST undertake checks of protective markings and keywords
        before permitting data export.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3
      description: Requirement to sign exported data
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:9
      ref_id: 20.2.11.R.01
      description: Digitally signing data being exported, demonstrates authenticity
        and improves assurance that the data has not been altered in transit.
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:9
      ref_id: 20.2.11.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must [CID: 4308]'
      description: A trusted source MUST sign the data to be exported if the data
        is to be communicated over a network to which untrusted personnel or systems
        have access.
      implementation_groups:
      - Secret - MUST
      - Top Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:9
      ref_id: 20.2.11.C.02
      name: 'Control -  Secret, Confidential - Must [CID: 4309]'
      description: Agencies MUST ensure that the gateway verifies authority to release
        prior to the release of the data to be exported.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.2.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.2:3:9
      ref_id: 20.2.11.C.03
      name: 'Control -  Confidential, Top Secret, Secret - Should [CID: 4310]'
      description: Agencies SHOULD use a product evaluated to at least an EAL4 assurance
        level for the purpose of data signing and signature confirmation.
      implementation_groups:
      - Confidential - SHOULD
      - Top Secret - SHOULD
      - Secret - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:20
      ref_id: '20.3'
      name: Content Filtering
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:1
      ref_id: 20.3.1
      description: "The flow\_of data within gateways is examined and controls applied\
        \ in accordance with the agency\u2019s security policy. \_To prevent unauthorised\
        \ or malicious content crossing security domain boundaries."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:2:1
      ref_id: 20.3.2
      description: This section covers information relating to the use of content
        filters within bi-directional or one-way gateways in order to protect security
        domains.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:2:1
      ref_id: 20.3.3
      description: Content filters reduce the risk of unauthorised or malicious content
        crossing a security domain boundary.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Limiting transfers by file type
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:1
      ref_id: 20.3.4.R.01
      description: 'The level of security risk will be affected by the degree of assurance
        agencies can place in the ability of their data transfer filters to:

        confirm the file type by examination of the contents of the file;

        confirm the absence of malicious content;

        confirm the absence of inappropriate content;

        confirm the classification of the content; and

        handle compressed files appropriately.

        Reducing the number of allowed file types reduces the number of potential
        vulnerabilities available for an attacker to exploit.'
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:1
      ref_id: 20.3.4.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4321]'
      description: Agencies MUST strictly define and limit the types of files that
        can be transferred based on business requirements and the results of a security
        risk assessment.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:1
      ref_id: 20.3.4.C.02
      name: 'Control -  All Classifications - Should [CID: 4322]'
      description: Agencies SHOULD strictly define and limit the types of files that
        can be transferred based on business requirements and the results of a security
        risk assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Blocking active content
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:2
      ref_id: 20.3.5.R.01
      description: "Many files are executable and are potentially harmful if activated\
        \ by a system user. \_Many static file type specifications allow active content\
        \ to be embedded within the file, which increases the attack surface."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:2
      ref_id: 20.3.5.C.01
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4325]'
      description: Agencies MUST block all executables and active content from entering
        a security domain.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:2
      ref_id: 20.3.5.C.02
      name: 'Control -  All Classifications - Should [CID: 4326]'
      description: Agencies SHOULD block all executables and active content from being
        communicated though gateways.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Blocking suspicious data
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:3
      ref_id: 20.3.6.R.01
      description: "The definition of suspicious content will depend on the system\u2019\
        s risk profile and what is considered normal traffic. \_The table below identifies\
        \ some filtering techniques that can be used to identify suspicious data.\n\
        \n\n\nTechnique\n\n\nPurpose\n\n\n\n\nAntivirus scan\n\n\nScans the data for\
        \ viruses and other malicious code.\n\n\n\n\nData format check\n\n\nInspects\
        \ data to ensure that it conforms to expected/permitted format(s).\n\n\n\n\
        \nData range check\n\n\nChecks the data within each field to ensure that it\
        \ falls within the expected/permitted range.\n\n\n\n\nData type check\n\n\n\
        Inspects each file header to determine the file type.\n\n\n\n\nFile extension\
        \ check\n\n\nChecks file extensions to ensure that they are permitted.\n\n\
        \n\n\nKeyword search\n\n\nSearches data for keywords or \u2018dirty words\u2019\
        \ that could indicate the presence of classified or inappropriate material.\n\
        \n\n\n\nMetadata check\n\n\nInspects files for metadata that should be removed\
        \ prior to release.\n\n\n\n\nProtective marking check\n\n\nValidates the protective\
        \ marking of the data to ensure that it complies with the permitted classifications\
        \ and endorsements.\n\n\n\n\nManual inspection\n\n\nThe manual inspection\
        \ of data for suspicious content that an automated system could miss, which\
        \ is particularly important for the transfer of image files, multi-media or\
        \ content-rich files.\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:3
      ref_id: 20.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4329]'
      description: Agencies MUST block, quarantine or drop any data identified by
        a data filter as suspicious until reviewed and approved for transfer by a
        trusted source other than the originator.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Content validation
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:4
      ref_id: 20.3.7.R.01
      description: 'Content validation aims to ensure that the content received conforms
        to a defined, approved standard. Content validation can be an effective means
        of identifying malformed content, allowing agencies to block potentially malicious
        content. Content validation operates on an allow listing principle, blocking
        all content except for that which is explicitly permitted. Examples of content
        validation include:

        ensuring numeric fields only contain numeric numbers;

        other fields operate with defined character sets;

        ensuring content falls within acceptable length boundaries;

        ensuring XML documents are compared to a strictly defined XML schema.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:4
      ref_id: 20.3.7.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 4332]'
      description: Agencies MUST perform validation on all data passing through a
        content filter, blocking content which fails the validation.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:4
      ref_id: 20.3.7.C.02
      name: 'Control -  All Classifications - Should [CID: 4333]'
      description: Agencies SHOULD perform validation on all data passing through
        a content filter, blocking content which fails the validation.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Content conversion and transformation
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:5
      ref_id: 20.3.8.R.01
      description: 'Content conversion, file conversion or file transformation can
        be an effective method to render potentially malicious content harmless by
        separating the presentation format from the data. By converting a file to
        another format, the exploit, active content and/or payload can often be removed
        or disrupted enough to be ineffective.Examples of file conversion and content
        transformation to mitigate the threat of content exploitation include:

        converting a Microsoft Word document to a PDF file;

        converting a Microsoft PowerPoint presentation to a series of JPEG images;

        converting a Microsoft Excel spreadsheet to a Comma Separated Values (CSV)
        file; or

        converting a PDF document to a plain text file.

        Some file types, such as XML, will not benefit from conversion. The conversion
        process should also be applied to any attachments or files contained within
        other files, for example, archive files or encoded files embedded in XML.'
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:5
      ref_id: 20.3.8.C.01
      name: 'Control -  All Classifications - Should [CID: 4336]'
      description: Agencies SHOULD perform content conversion, file conversion or
        both for all ingress or egress data transiting a security domain boundary.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Content sanitisation
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:6
      ref_id: 20.3.9.R.01
      description: 'Sanitisation is the process of attempting to make potentially
        malicious content safe to use by removing or altering active content while
        leaving the original content as intact as possible. Sanitisation is not as
        secure a method of content filtering as conversion, though many techniques
        may be combined. Extraneous application and protocol data, including metadata,
        should also be inspected and filtered where possible. Examples of sanitisation
        to mitigate the threat of content exploitation include:


        removal of document properties information in Microsoft Office documents;

        removal or renaming of JavaScript sections from PDF files;

        removal of metadata such as EXIF information from within JPEG files.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:6
      ref_id: 20.3.9.C.01
      name: 'Control -  All Classifications - Should [CID: 4339]'
      description: Agencies SHOULD perform content and file sanitisation on suitable
        file types if content conversion or file conversion is not appropriate for
        data transiting a security domain boundary.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Antivirus scans
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:7
      ref_id: 20.3.10.R.01
      description: Antivirus scanning is used to prevent, detect and remove malicious
        software that includes computer viruses, worms, Trojans, spyware and adware.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:7
      ref_id: 20.3.10.C.01
      name: 'Control -  All Classifications - Should [CID: 4348]'
      description: Agencies SHOULD perform antivirus scans on all content using up-to-date
        engines and signatures, using multiple different scanning engines.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Archive and container files
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      ref_id: 20.3.11.R.01
      description: "Archive and container files can be used to bypass content filtering\
        \ processes if the content filter does not handle the file type and embedded\
        \ content correctly. \_The content filtering process should recognise archived\
        \ and container files, ensuring the embedded files they contain are subject\
        \ to the same content filtering measures as un-archived files."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      ref_id: 20.3.11.R.02
      description: "Archive files can be constructed in a manner which can pose a\
        \ denial-of-service risk due to processor, memory or disk space exhaustion.\
        \ \_To limit the risk of such an attack, content filters can specify resource\
        \ constraints/quotas while extracting these files. \_If these constraints\
        \ are exceeded the inspection is terminated, the content blocked and a security\
        \ administrator alerted."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      ref_id: 20.3.11.C.01
      name: 'Control -  All Classifications - Should [CID: 4401]'
      description: Agencies SHOULD extract the contents from archive and container
        files and subject the extracted files to content filter tests.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      ref_id: 20.3.11.C.02
      name: 'Control -  All Classifications - Should [CID: 4402]'
      description: Agencies SHOULD perform controlled inspection of archive and container
        files to ensure that content filter performance and availability is not adversely
        affected.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:8
      ref_id: 20.3.11.C.03
      name: 'Control -  All Classifications - Should [CID: 4403]'
      description: Agencies SHOULD block files that cannot be inspected and generate
        an alert or notification.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Allow listing permitted content
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:9
      ref_id: 20.3.12.R.01
      description: "Creating and enforcing an allow list of allowed content/files\
        \ is a strong content filtering method. \_Allowing content that satisfies\
        \ a business requirement only can reduce the attack surface of the system.\
        \ \_As a simple example, an email content filter might allow only Microsoft\
        \ Office documents and PDF files."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:9
      ref_id: 20.3.12.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4406]'
      description: Agencies MUST create and enforce an allow list of permitted content
        types based on business requirements and the results of a security risk assessment.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:9
      ref_id: 20.3.12.C.02
      name: 'Control -  All Classifications - Should [CID: 4407]'
      description: Agencies SHOULD create and enforce an allow list of permitted content
        types based on business requirements and the results of a security risk assessment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Data integrity
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:10
      ref_id: 20.3.13.R.01
      description: Ensuring the authenticity and integrity of content reaching a security
        domain is a key component in ensuring its trustworthiness. It is also essential
        that content that has been authorised for release from a security domain is
        not modified or contains other data not authorised for release, for example
        by the addition or substitution of sensitive information.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:10
      ref_id: 20.3.13.R.02
      description: "If content passing through a filter contains a form of integrity\
        \ protection, such as a digital signature, the content filter should verify\
        \ the content\u2019s integrity before allowing it through. If the content\
        \ fails these integrity checks it may have been spoofed or tampered with and\
        \ should be dropped or quarantined for further inspection.Examples of data\
        \ integrity checks include:\nan email server or content filter verifying an\
        \ email protected by DKIM;\na web service verifying the XML digital signature\
        \ contained within a SOAP request;\nvalidating a file against a separately\
        \ supplied hash;\nchecking that data to be exported from the security domain\
        \ has been digitally signed by the release authority.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:10
      ref_id: 20.3.13.C.01
      name: 'Control -  Confidential, Secret, Top Secret - Must [CID: 4411]'
      description: If data is signed, agencies MUST ensure that the signature is validated
        before the data is exported.
      implementation_groups:
      - Confidential - MUST
      - Secret - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:10
      ref_id: 20.3.13.C.02
      name: 'Control -  All Classifications - Should [CID: 4412]'
      description: Agencies SHOULD verify the integrity of content where applicable,
        and block the content if verification fails.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Encrypted data
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:11
      ref_id: 20.3.14.R.01
      description: 'Encryption can be used to bypass content filtering if encrypted
        content cannot be subject to the same checks performed on unencrypted content.
        Agencies will need to consider the need to decrypt content, depending on:

        the security domain they are communicating with;

        whether the need-to-know principle is to be enforced;

        end-to-end encryption requirements; or

        any privacy and policy requirements.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.14.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:11
      ref_id: 20.3.14.R.02
      description: "Choosing not to decrypt content poses a risk of encrypted malicious\
        \ software communications and data moving between security domains. \_Additionally,\
        \ encryption could mask the movement of information at a higher classification\
        \ being allowed to pass to a security domain of lower classification, which\
        \ could result in a data spill."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.14.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:11
      ref_id: 20.3.14.R.03
      description: Some systems allow encrypted content through external/boundary/perimeter
        controls to be decrypted at a later stage, in which case the content should
        be subject to all applicable content filtering controls after it has been
        decrypted.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:11
      ref_id: 20.3.14.C.01
      name: 'Control -  All Classifications - Should [CID: 4417]'
      description: Agencies SHOULD decrypt and inspect all encrypted content, traffic
        and data to allow content filtering.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Monitoring data import and export
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:12
      ref_id: 20.3.15.R.01
      description: To ensure the continued confidentiality and integrity of systems
        and data, import and export processes should be monitored and audited.
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:12
      ref_id: 20.3.15.C.01
      name: 'Control -  All Classifications - Must [CID: 4420]'
      description: Agencies MUST use protective marking checks to restrict the export
        of data from each security domain, including through a gateway.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:12
      ref_id: 20.3.15.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Must [CID: 4421]'
      description: When importing data to each security domain, including through
        a gateway, agencies MUST audit the complete data transfer logs at least monthly.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.3:3:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3
      description: Exception Handling
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:13
      ref_id: 20.3.16.R.01
      description: "Legitimate reasons may exist for the transfer of data that may\
        \ be identified as suspicious according to the criteria established for content\
        \ filtering. \_It is important to have an accountable and auditable mechanism\
        \ in place to deal with such exceptions."
    - urn: urn:defend:risk:req_node:nzism-v3:20.3.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.3:3:13
      ref_id: 20.3.16.C.01
      name: 'Control -  All Classifications - Should [CID: 4424]'
      description: Agencies SHOULD create an exception handling process to deal with
        blocked or quarantined file types that may have a valid requirement to be
        transferred.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:20
      ref_id: '20.4'
      name: Databases
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:1
      ref_id: 20.4.1
      description: Database content is protected from personnel without a need-to-know.
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:2:1
      ref_id: 20.4.2
      description: This section covers information relating to databases and interfaces
        to databases such as search engines.
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3
      description: Data labelling
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.3.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      ref_id: 20.4.3.R.01
      description: "Protective markings can be applied to records, tables or to the\
        \ database as a whole, depending on structure and use. \_Query results will\
        \ often need a protective marking to reflect the aggregate of the information\
        \ retrieved."
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.3.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      ref_id: 20.4.3.C.01
      name: 'Control -  Top Secret - Must [CID: 4434]'
      description: 'Agencies MUST ensure that all classified information stored within
        a database is associated with an appropriate protective marking if the information:

        could be exported to a different system; or

        contains differing classifications or different handling requirements.

        '
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.3.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      ref_id: 20.4.3.C.02
      name: 'Control -  Top Secret - Must [CID: 4435]'
      description: Agencies MUST ensure that protective markings are applied with
        a level of granularity sufficient to clearly define the handling requirements
        for any classified information retrieved or exported from a database.
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.3.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      ref_id: 20.4.3.C.03
      name: 'Control -  All Classifications - Should [CID: 4436]'
      description: 'Agencies SHOULD ensure that all classified information stored
        within a database is associated with an appropriate protective marking if
        the information:

        could be exported to a different system; or

        contains differing classifications or different handling requirements.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.3.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:1
      ref_id: 20.4.3.C.04
      name: 'Control -  All Classifications - Should [CID: 4437]'
      description: Agencies SHOULD ensure that protective markings are applied with
        a level of granularity sufficient to clearly define the handling requirements
        for any classified information retrieved or exported from a database.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3
      description: Database files
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:2
      ref_id: 20.4.4.R.01
      description: Even though a database may provide access controls to stored data,
        the database files themselves MUST also be protected.
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:2
      ref_id: 20.4.4.C.01
      name: 'Control -  Top Secret - Must [CID: 4440]'
      description: "Agencies MUST protect database files from access that bypasses\
        \ the database\u2019s normal access controls."
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:2
      ref_id: 20.4.4.C.02
      name: 'Control -  All Classifications - Should [CID: 4441]'
      description: Agencies SHOULD protect database files from access that bypass
        normal access controls.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3
      description: Accountability
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:3
      ref_id: 20.4.5.R.01
      description: "If system users\u2019 interactions with databases are not logged\
        \ and audited, agencies will not be able to appropriately investigate any\
        \ misuse or compromise of database content."
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:3
      ref_id: 20.4.5.C.01
      name: 'Control -  Top Secret - Must [CID: 4444]'
      description: "Agencies MUST enable logging and auditing of system users\u2019\
        \ actions."
      implementation_groups:
      - Top Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.5.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:3
      ref_id: 20.4.5.C.02
      name: 'Control -  All Classifications - Should [CID: 4445]'
      description: "Agencies SHOULD ensure that databases provide functionality to\
        \ allow for auditing of system users\u2019 actions."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:20.4:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3
      description: Search engines
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:4
      ref_id: 20.4.6.R.01
      description: "Even if a search engine restricts viewing of classified information\
        \ that a system user does not have sufficient security clearances to access,\
        \ the associated metadata can contain information above the security clearances\
        \ of the system user. \_In such cases, restricting access to, or sanitising,\
        \ this metadata effectively controls the possible release of information the\
        \ system user is not cleared to view."
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:4
      ref_id: 20.4.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4448]'
      description: If results from database queries cannot be appropriately filtered,
        agencies MUST ensure that all query results are appropriately sanitised to
        meet the minimum security clearances of system users.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:20.4.6.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:20.4:3:4
      ref_id: 20.4.6.C.02
      name: 'Control -  All Classifications - Should [CID: 4449]'
      description: Agencies SHOULD ensure that system users who do not have sufficient
        security clearances to view database contents cannot see or interrogate associated
        metadata in a list of results from a search engine query.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21
      assessable: false
      depth: 1
      ref_id: '21'
      name: Distributed Working
    - urn: urn:defend:risk:req_node:nzism-v3:21.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:21
      ref_id: '21.1'
      name: Agency-owned Mobile Devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:1
      ref_id: 21.1.1
      description: "Information\_on agency-owned mobile devices is protected from\
        \ unauthorised disclosure."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:1
      ref_id: 21.1.2
      description: This section covers information relating to the use of agency-owned
        mobile devices including, but not restricted to, mobile phones, smartphones,
        portable electronic devices, personal digital assistants, laptops, netbooks,
        tablet computers, and other portable Internet connected devices.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:1
      ref_id: 21.1.3
      description: It is important to note that product security, selection, maintenance,
        sanitisation and disposal requirements in Chapter 12 - Product Security also
        apply to agency-owned mobile devices.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      description: Trusted Operating Environments
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:2
      ref_id: 21.1.4
      description: "A Trusted Operating Environment (TOE) provides assurance that\
        \ every reasonable effort has been made to secure the operating system of\
        \ a mobile device such that it presents a managed risk to an agency\u2019\
        s information and systems. \_Any residual risks are explicitly accepted by\
        \ the agency."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:2
      ref_id: 21.1.5
      description: 'Special care is necessary when dealing with All-of-Government
        systems or systems that affect several agencies. Security measures that can
        be implemented to assist in the development of a TOE include:

        strong usage policies are in place;

        unnecessary hardware, software and operating system components are removed;

        unused or undesired functionality in software and operating systems is removed
        or disabled;

        anti-malware and other security software is installed and regularly updated;

        downloads of software, data or documents are limited or not permitted;

        installation of unapproved applications is not permitted;

        software-based firewalls limiting inbound and outbound network connections
        are installed;

        patching of installed the operating system and other software is current;

        each connection is authenticated (multi-factor) before permitting access to
        an agency network;

        both the user and mobile device are authenticated during the authentication
        process;

        mobile device configurations may be validated before a connection is permitted;

        privileged access from the mobile device to the agency network is not allowed;

        access to some data may not be permitted; and

        agency control of the mobile device may supersede any convenience aspects.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      description: Treating workstations as mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:3
      ref_id: 21.1.6
      description: When an agency issues a workstation for home-based work instead
        of a mobile device the requirements in this section apply equally to the issued
        workstation.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      description: Devices with multiple operating states
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:4
      ref_id: 21.1.7
      description: "Some mobile devices may have functionality to allow them to operate\
        \ in either an unclassified state or a classified state. \_In such cases the\
        \ mobile devices will need to be handled according to the state that it is\
        \ being operated in at the time. \_For example, some devices can start-up\
        \ in an unclassified mode or start-up in a cryptographically protected mode."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2
      description: Bluetooth and Infra-Red Devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:2:5
      ref_id: 21.1.8
      description: "Bluetooth and Infra-Red devices, such as keyboards, headsets and\
        \ mice are subject to an additional set of risks. \_Refer to Chapter 11 \u2013\
        \ Communication Systems and Devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:3
      ref_id: 21.1.9
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV2, GOV4, GOV6, INFOSEC1,\
        \ INFOSEC2, INFOSEC3, INFOSEC4, PHYSEC1 and PHYSEC2\n\n\nHome | Protective\
        \ Security Requirements\nSecurity governance (GOV) | Protective Security Requirements\n\
        Information security (INFOSEC) | Protective Security Requirements \_\_\nPhysical\
        \ security (PHYSEC) | Protective Security Requirements\n\n\n\nPSR content\
        \ protocols \n\n\nManagement protocol for information security\nManagement\
        \ protocol for physical security\n\n\nManagement protocol for information\
        \ security | Protective Security Requirements\nManagement protocol for physical\
        \ security | Protective Security Requirements\n\n\n\nPSR requirements sections\n\
        \n\nBuild security awareness\nWorking away from the office\n\n\nBuilding security\
        \ awareness | Protective Security Requirements\nWorking away from the office\
        \ | Protective Security Requirements\n\n\n\n\nManaging specific scenarios\n\
        \n\nMobile and remote working\nCommunications security\n\_\n\nMobile and remote\
        \ working\nCommunications security\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Mobile devices usage policy
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:1
      ref_id: 21.1.10.R.01
      description: As mobile devices routinely leave the office environment and the
        physical protection it affords it is important that policies are developed
        to ensure that they are protected in an appropriate manner when used outside
        of controlled agency facilities.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:1
      ref_id: 21.1.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4471]'
      description: Agencies MUST develop a policy governing the use of mobile devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:1
      ref_id: 21.1.10.C.02
      name: 'Control -  Secret, Top Secret, Confidential - Must Not [CID: 4472]'
      description: Agencies MUST NOT allow mobile devices to process or store TOP
        SECRET information unless explicitly approved by GCSB to do so.
      implementation_groups:
      - Secret - MUST NOT
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:1
      ref_id: 21.1.10.C.03
      name: 'Control -  All Classifications - Should [CID: 4473]'
      description: Agencies SHOULD implement a Mobile Device Management (MDM) solution.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Personnel awareness
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:2
      ref_id: 21.1.11.R.01
      description: Mobile devices can have both a data and voice component capable
        of processing or communicating classified information. In such cases, personnel
        will need to be aware of the approved classification level for each function.This
        includes Paging Services, Multi-Media Message Service (MMS) and Short Message
        Service (SMS) which are NOT appropriate for sensitive or classified information.
        Paging and message services do not appropriately encrypt information and cannot
        be relied upon for the communication of classified information.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:2
      ref_id: 21.1.11.C.01
      name: 'Control -  All Classifications - Must [CID: 4476]'
      description: Agencies MUST advise personnel of the maximum permitted classifications
        for data and voice communications when using mobile devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:2
      ref_id: 21.1.11.C.02
      name: 'Control -  All Classifications - Should Not [CID: 4477]'
      description: Agencies SHOULD NOT use Paging Services, SMS or MMS for sensitive
        or classified communications.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Non-agency owned and controlled mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:3
      ref_id: 21.1.12.R.01
      description: "Agencies need to retain control of any non-agency device that\
        \ contains agency or government information. \_Non-agency devices are discussed\
        \ in Section 21.4 \u2013 BYOD."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:3
      ref_id: 21.1.12.C.01
      name: 'Control -  All Classifications - Must [CID: 4480]'
      description: "Agencies MUST apply the full set of BYOD controls for devices\
        \ NOT directly owned and controlled by the agency. \_These controls are detailed\
        \ in Section 21.4 \u2013 BYOD."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Agency owned mobile device storage encryption
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.R.01
      description: Encrypting the internal storage and removable media of agency owned
        mobile devices will reduce the risk of data loss associated with a lost or
        stolen device. While the use of encryption may not be suitable to treat the
        device as an unclassified asset it will still present a significant challenge
        to a malicious actor looking to gain easy access to information stored on
        the device. To ensure that the benefits of encryption on mobile devices are
        maintained, users must not store passphrases, passwords, PINS or other access
        codes for the encryption software on, or with, the device.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.R.02
      description: "Information on the use of encryption to reduce storage and physical\
        \ transfer requirements is detailed in\_Section 17.1 \u2013 Cryptographic\
        \ Fundamentals\_and\_17.2 \u2013 Approved Cryptographic Algorithms."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.R.03
      description: "Refer to the\_PSR - Mobile and Remote workingRefer to the\_PSR\_\
        - Handling Requirements for protectively marked information and equipment"
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.C.01
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4483]'
      description: Agencies unable to lower the storage and physical transfer requirements
        of a mobile device to an unclassified level through the use of encryption
        MUST physically store or transfer the device as a classified asset in accordance
        with the relevant handling instructions.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.C.02
      name: 'Control -  All Classifications - Must Not [CID: 4484]'
      description: Users MUST NOT store passwords, passphrases, PINs or other access
        codes for encryption on or with the mobile device on which data will be encrypted
        when the device is issued for normal operations.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.C.03
      name: 'Control -  All Classifications - Should [CID: 4485]'
      description: Agencies unable to lower the storage and physical transfer requirements
        of a mobile device to an unclassified level through the use of encryption
        SHOULD physically store or transfer the device as a classified asset in accordance
        with the relevant handling instructions.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.C.04
      name: 'Control -  All Classifications - Should [CID: 4486]'
      description: Agencies SHOULD encrypt classified information on all mobile devices
        using an Approved Cryptographic Algorithm.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.13.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:4
      ref_id: 21.1.13.C.05
      name: 'Control -  All Classifications - Should [CID: 4487]'
      description: Pool or shared devices SHOULD be reissued with unique passwords,
        passphrases, PINs or other access codes for each separate issue or deployment.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Mobile device communications encryption
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      ref_id: 21.1.14.R.01
      description: "The above approach cannot be used for communicating classified\
        \ information over public infrastructure, the internet or non-agency controlled\
        \ networks. \_If appropriate encryption is not available the mobile device\
        \ will not be approved for communicating classified information."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.14.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      ref_id: 21.1.14.R.02
      description: 'Note: This applies to information and systems classified as RESTRICTED/SENSITIVE
        and any higher classification.'
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.14.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      ref_id: 21.1.14.R.03
      description: Encryption does not change the classification level of the information
        or system itself but allows reduced handling requirements to be applied.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      ref_id: 21.1.14.C.01
      name: 'Control -  Secret, Confidential, Top Secret, Restricted/Sensitive - Must
        [CID: 4492]'
      description: Agencies MUST use encryption on mobile devices communicating over
        public infrastructure, the Internet or non-agency controlled networks.
      implementation_groups:
      - Secret - MUST
      - Confidential - MUST
      - Top Secret - MUST
      - Restricted/Sensitive - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:5
      ref_id: 21.1.14.C.02
      name: 'Control -  All Classifications - Should [CID: 4493]'
      description: Agencies SHOULD use encryption for Official Information or any
        classified information on mobile devices communicating over public infrastructure,
        the Internet or non-agency controlled networks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Mobile device privacy filters
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:6
      ref_id: 21.1.15.R.01
      description: "Privacy filters can be applied to the screens of mobile devices\
        \ to prevent onlookers from reading the contents off the screen of the device.\
        \ \_This assists in mitigating a shoulder surfing or other oversight attack\
        \ or compromise."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:6
      ref_id: 21.1.15.C.01
      name: 'Control -  All Classifications - Should [CID: 4496]'
      description: Agencies SHOULD apply privacy filters to the screens of mobile
        devices.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Disabling Bluetooth functionality
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:7
      ref_id: 21.1.16.R.01
      description: "As Bluetooth provides little security for the information that\
        \ is passed between devices and a number of exploits have been publicised,\
        \ it SHOULD NOT be used on mobile devices. Refer to Chapter 11 \u2013 Communications\
        \ Systems and Devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:7
      ref_id: 21.1.16.C.01
      name: 'Control -  Secret, Top Secret, Confidential - Must Not [CID: 4499]'
      description: Agencies MUST NOT enable Bluetooth functionality on mobile devices.
      implementation_groups:
      - Secret - MUST NOT
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:7
      ref_id: 21.1.16.C.02
      name: 'Control -  All Classifications - Should Not [CID: 4500]'
      description: Agencies SHOULD NOT enable Bluetooth functionality on mobile devices.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Configuration control
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:8
      ref_id: 21.1.17.R.01
      description: "Poorly controlled devices are more vulnerable to compromise and\
        \ provide an attacker with a potential access point into agency systems. \_\
        Although agencies may initially provide a secure device, the state of security\
        \ may degrade over time. \_The agency will need to revaluate the security\
        \ of devices regularly to ensure their integrity."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:8
      ref_id: 21.1.17.C.01
      name: 'Control -  All Classifications - Must Not [CID: 4503]'
      description: Agency personnel MUST NOT disable security functions or security
        configurations on a mobile device once provisioned.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.17.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:8
      ref_id: 21.1.17.C.02
      name: 'Control -  All Classifications - Should [CID: 4504]'
      description: "Agencies SHOULD control the configuration of mobile devices in\
        \ the same manner as devices in the agency\u2019s office environment."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.17.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:8
      ref_id: 21.1.17.C.03
      name: 'Control -  All Classifications - Should [CID: 4505]'
      description: Agencies SHOULD prevent personnel from installing unauthorised
        applications on a mobile device once provisioned.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Maintaining mobile device security
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:9
      ref_id: 21.1.18.R.01
      description: As mobile devices are not continually connected to ICT systems
        within an agency it is important that they are routinely returned to the agency
        so that patches can be applied and they can be tested to ensure that they
        are still secure.Alternatively a mobile device management solution may implement
        policy checks and updates on connection to agency systems.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:9
      ref_id: 21.1.18.C.01
      name: 'Control -  All Classifications - Should [CID: 4508]'
      description: Agencies SHOULD ensure that mobile devices have security updates
        applied on a regular basis and are tested to ensure that the mobile devices
        are still secure.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.18.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:9
      ref_id: 21.1.18.C.02
      name: 'Control -  All Classifications - Should [CID: 4509]'
      description: Agencies SHOULD conduct policy checks as mobile devices connect
        to agency systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Connecting mobile devices to the Internet
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:10
      ref_id: 21.1.19.R.01
      description: "During the period that a device is connected to the Internet,\
        \ without a VPN connection, it is exposed to attacks. \_This period needs\
        \ to be minimised to reduce the security risks. \_Minimising this period includes\
        \ ensuring that system users do not connect directly to the Internet to access\
        \ the Web between VPN sessions."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.19.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:10
      ref_id: 21.1.19.R.02
      description: "A split tunnel VPN can allow access to an agency\u2019s systems\
        \ from another network, including unsecure networks such as the Internet.\
        \ \_If split tunnelling is enabled there is an increased security risk that\
        \ the VPN connection is susceptible to attack from such networks."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:10
      ref_id: 21.1.19.C.01
      name: 'Control -  All Classifications - Must [CID: 4513]'
      description: Agencies MUST disable split tunnelling when using a VPN connection
        from a mobile device to connect to an agency network.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:10
      ref_id: 21.1.19.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Should Not [CID: 4514]'
      description: Agencies SHOULD NOT allow mobile devices to connect to the Internet
        except when temporarily connecting to facilitate the establishment of a VPN
        connection to an agency network.
      implementation_groups:
      - Secret - SHOULD NOT
      - Confidential - SHOULD NOT
      - Top Secret - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Emergency destruction
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      ref_id: 21.1.20.R.01
      description: "Where a mobile device carries classified information, or there\
        \ is an increased risk of loss or compromise of the device, agencies will\
        \ need to develop emergency destruction procedures. \_Such procedures should\
        \ focus on the destruction of information on the mobile device and not necessarily\
        \ the device itself. \_Many mobile devices used for classified information\
        \ achieve this through the use of a cryptographic key zeroise or sanitisation\
        \ function."
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.20.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      ref_id: 21.1.20.R.02
      description: Staff will need to understand the rationale and be familiar with
        emergency destruction procedures, especially where there is a higher probability
        of loss, theft or compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      ref_id: 21.1.20.C.01
      name: 'Control -  All Classifications - Must [CID: 4519]'
      description: Agencies MUST develop an emergency destruction plan for mobile
        devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      ref_id: 21.1.20.C.02
      name: 'Control -  All Classifications - Must [CID: 4520]'
      description: If a cryptographic zeroise or sanitise function is provided for
        cryptographic keys on a mobile device it MUST be used as part of the emergency
        destruction procedures.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:11
      ref_id: 21.1.20.C.03
      name: 'Control -  All Classifications - Should [CID: 4521]'
      description: Agencies SHOULD ensure personnel are trained in emergency destruction
        procedures and are familiar with the emergency destruction plan.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Labelling
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:12
      ref_id: 21.1.21.R.01
      description: Agencies may wish to affix an additional label to mobile devices
        asking finders of lost devices to hand it in to any New Zealand police station,
        or if overseas, a New Zealand embassy, consulate or high commission.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:12
      ref_id: 21.1.21.C.01
      name: 'Control -  All Classifications - Should [CID: 4524]'
      description: Agencies SHOULD use soft labelling for mobile devices when appropriate
        to reduce their attractiveness value.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1:4:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4
      description: Unauthorised use of mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:13
      ref_id: 21.1.22.R.01
      description: Where mobile devices are issued to personnel for business purposes
        their use for private purposes should be governed by agency policy and agreed
        by the employee or contractor to whom the device is issued.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.22.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:13
      ref_id: 21.1.22.R.02
      description: Agencies must recognise the risks and costs associated with personal
        use of an agency device.
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:13
      ref_id: 21.1.22.C.01
      name: 'Control -  All Classifications - Should [CID: 4530]'
      description: Agencies SHOULD develop a policy to manage the non-business or
        personal use of an agency owned device.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.1.22.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.1:4:13
      ref_id: 21.1.22.C.02
      name: 'Control -  All Classifications - Should Not [CID: 4531]'
      description: Mobile devices SHOULD NOT be used other than by personnel specifically
        authorised by the agency.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:21
      ref_id: '21.2'
      name: Working Outside the Office
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:1
      ref_id: 21.2.1
      description: "Information\_on mobile devices is not accessed from public or\
        \ insecure locations."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:2:1
      ref_id: 21.2.2
      description: "This section covers information on accessing information using\
        \ agency-owned mobile devices from unsecured locations outside the office\
        \ and home environments. \_This section does not apply to working from home;\
        \ requirements relating to home-based work are outlined in Section 21.3 \u2013\
        \ Working From Home. \_Further information on the use of mobile devices can\
        \ be found in Section 21.1 \u2013 Agency Owned Mobile Devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:2:1
      ref_id: 21.2.3
      description: "Also refer to Chapter 12 - Product Security\_for requirements\
        \ on product security, selection, maintenance, sanitisation and disposal."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3
      description: Working outside the office
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.4.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:1
      ref_id: 21.2.4.R.01
      description: "As the security risk relating to specific targeting of mobile\
        \ devices capable of processing highly classified information is high, these\
        \ mobile devices cannot be used outside of facilities certified to an appropriate\
        \ level to allow for their use. \_In addition, as agencies have no control\
        \ over public locations including, but not limited to, such locations as public\
        \ transport, transit lounges, hotel lobbies, and coffee shops, mobile devices\
        \ are not approved to process classified information as the security risk\
        \ of classified information being overheard or observed is considered to be\
        \ too high in such locations."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.4.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:1
      ref_id: 21.2.4.C.01
      name: 'Control -  All Classifications - Must Not [CID: 4541]'
      description: Agencies MUST NOT allow personnel to access or communicate classified
        information on mobile devices outside of secure areas unless there is a reduced
        chance of being overheard and having the screen of the device observed.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.4.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:1
      ref_id: 21.2.4.C.02
      name: 'Control -  All Classifications - Should Not [CID: 4542]'
      description: Agencies allowing personnel to access or communicate classified
        information outside of the office SHOULD NOT allow personnel to do so in public
        locations (e.g. public transport, transit lounges, hotel lobbies and coffee
        shops).
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3
      description: Carrying mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:2
      ref_id: 21.2.5.R.01
      description: "Mobile devices used outside the office are frequently transferred\
        \ through areas not certified to process the classified information on the\
        \ device. \_Mechanisms need to be put in place to protect the information\
        \ stored on those devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:2
      ref_id: 21.2.5.R.02
      description: "When agencies apply encryption to mobile devices to reduce their\
        \ physical transfer requirements it is only effective when the encryption\
        \ function of the device is not authenticated. \_In most cases this will mean\
        \ the mobile device will be in an unpowered state (i.e. \_not turned on),\
        \ however, some devices are capable of deauthenticating the cryptography when\
        \ it enters a locked state after a predefined timeout period. \_Such mobile\
        \ devices can be carried in a locked state in accordance with reduced physical\
        \ transfer requirements based on the assurance given in the cryptographic\
        \ functions."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:2
      ref_id: 21.2.5.C.01
      name: 'Control -  All Classifications - Must [CID: 4546]'
      description: 'Agencies MUST ensure mobile devices are carried in a secured state
        when not being actively used, by:

        power off; or

        power on but pass code enabled.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:3:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3
      description: Using mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:3
      ref_id: 21.2.6.R.01
      description: "Mobile devices are portable in nature and can be easily stolen\
        \ or misplaced. \_It is strongly advised that personnel do not leave mobile\
        \ devices unattended at any time."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:3
      ref_id: 21.2.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4550]'
      description: When in use mobile devices MUST be kept under continual direct
        supervision.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.2:3:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3
      description: Travelling with mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:4
      ref_id: 21.2.7.R.01
      description: "If personnel place mobile devices or media in checked-in luggage\
        \ when travelling they lose control over the devices. \_Such situations provide\
        \ an opportunity for mobile devices to be stolen or tampered with by an attacker."
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:4
      ref_id: 21.2.7.C.01
      name: 'Control -  All Classifications - Must [CID: 4554]'
      description: When travelling with mobile devices and media, personnel MUST retain
        control over them at all times including by not placing them in checked-in
        luggage or leaving them unattended.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.2.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.2:3:4
      ref_id: 21.2.7.C.02
      name: 'Control -  All Classifications - Must [CID: 4555]'
      description: Travelling personnel requested to decrypt mobile devices for inspection
        or from whom mobile devices are taken out of sight by border control MUST
        report the potential compromise of classified information or the device to
        an ITSM as soon as possible.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:21
      ref_id: '21.3'
      name: Working From Home
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:1
      ref_id: 21.3.1
      description: "Personnel\_working from home protect classified information in\
        \ the same manner as in the office environment."
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:2:1
      ref_id: 21.3.2
      description: "This section covers accessing official information and agency\
        \ information using mobile devices from a home environment in order to conduct\
        \ home-based work. \_Further information on the use of mobile devices can\
        \ be found in Section 21.1 \u2013 Agency Owned Mobile Devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:2
      description: The use of workstations instead of mobile devices
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:2:2
      ref_id: 21.3.3
      description: "Where an agency chooses to issue a workstation for home-based\
        \ work instead of a mobile device, the requirements for mobile devices within\
        \ Section 21.1 \u2013 Agency Owned Mobile Devices, equally apply to the workstation\
        \ that is used."
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:2:2
      ref_id: 21.3.4
      description: "It is important to note that product security, selection, maintenance,\
        \ sanitisation and disposal requirements in\_Chapter 12 - Product Security\_\
        apply to all agency-owned mobile devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:3:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3
      description: Storage requirements
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.5.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:1
      ref_id: 21.3.5.R.01
      description: All mobile devices have the potential to store classified information
        and therefore need protection against loss and compromise.
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.5.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:1
      ref_id: 21.3.5.R.02
      description: "Refer to the\_PSR - Mobile and Remote workingRefer to the\_PSR\_\
        - Handling Requirements for protectively marked information and equipment"
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.5.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:1
      ref_id: 21.3.5.C.01
      name: 'Control -  All Classifications - Must [CID: 4571]'
      description: Agencies MUST ensure that when mobile devices are not being actively
        used they are secured in accordance with the minimum physical security requirements
        as stated in the PSR.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.3:3:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3
      description: Processing requirements
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.6.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:2
      ref_id: 21.3.6.R.01
      description: "When agencies consider allowing personnel to work from a home\
        \ environment they need to be aware that implementing physical security measures\
        \ may require modifications to the person\u2019s home, or the provision of\
        \ approved containers or secure storage units at the expense of the agency."
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.6.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:2
      ref_id: 21.3.6.R.02
      description: "Refer to the\_PSR - Mobile and Remote workingRefer to the\_PSR\_\
        - Handling Requirements for protectively marked information and equipment"
    - urn: urn:defend:risk:req_node:nzism-v3:21.3.6.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.3:3:2
      ref_id: 21.3.6.C.01
      name: 'Control -  All Classifications - Must [CID: 4575]'
      description: Agencies MUST ensure that the area within which mobile devices
        are used meets the minimum physical security requirements as stated in the
        PSR.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:21
      ref_id: '21.4'
      name: Non-Agency Owned Devices and Bring Your Own Device (BYOD)
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:1
      ref_id: 21.4.1
      description: "Where an Agency\_permits personnel to supply their own mobile\
        \ devices (such as smartphones, tablets and laptops), Official Information\
        \ and agency information systems are protected to a level equivalent to an\
        \ agency provided and managed office environment."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:2:1
      ref_id: 21.4.2
      description: "This section provides information on the use and security of non-agency\
        \ owned or provided mobile devices when used for official business. This is\
        \ commonly known as Bring Your Own Device (BYOD). The use of agency owned\
        \ devices is described earlier in Section 21.1 \u2013 Agency Owned Mobile\
        \ Devices."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:2:1
      ref_id: 21.4.3
      description: "In the context of this section, a BYOD Network is any agency owned\
        \ or provided network dedicated to BYOD. \_A BYOD Network is usually within\
        \ an agency\u2019s premises but does NOT include networks and related services\
        \ provided by commercial telecommunication or other technology providers."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:2:1
      ref_id: 21.4.4
      description: "BYOD will introduce a wide range of risks, including information\
        \ and privacy risks, to an organisation, in addition to the existing ICT risks\
        \ and threats. \_Agencies will need to carefully examine and consider the\
        \ security, privacy, governance, assurance and compliance risks and implications\
        \ of BYOD."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:2:1
      ref_id: 21.4.5
      description: "Mobile devices are a \u201Csoft\u201D target for malware and cybercrime\
        \ providing a further attack channel or vector for organisational ICT infrastructures\
        \ and networks. Risks fall principally into the following categories:\nData\
        \ exfiltration and theft;\nData tampering;\nData loss;\nMalware;\nSystem outages\
        \ and Denial of Service; and\nIncreased incident management and recovery costs.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:3
      ref_id: 21.4.6
      description: "\n\n\nReference\_\nTitle\nPublisher\nSource\n\n\n\_\n\nRisk Management\
        \ of Enterprise Mobility including Bring Your Own Device\n\n\nASD\n\n\nhttps://www.cyber.gov.au/acsc/view-all-content/publications/risk-management-enterprise-mobility-including-bring-your-own-device\_\
        \n\n\n\n\_\n\nBYOD Guidance: Device Security Considerations\n\n\nGOV.UK\n\n\
        \nhttps://www.gov.uk/government/uploads/system/uploads/attachment_data/file/360960/BYOD_Guidance_-_Device_Security_Considerations.pdf\
        \ [PDF, 235 KB]\n\n\n\n\_\n\nEnd User Devices Security and Configuration Guidance\n\
        \n\nNCSC, UK\n\n\nhttps://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device\n\
        \n\n\n\nNIST Special Publication 800-121, Revision 2, May 2017\n\n\nGuide\
        \ to Bluetooth Security\n\n\nNIST\n\n\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf\
        \ [PDF, 2.1 MB]\n\n\n\n\nNIST Special Publication 800-46,\_Revision 2, July\
        \ 2016\n\n\nGuide to Enterprise Telework, Remote Access, and Bring Your Own\
        \ Device (BYOD) Security\n\n\nNIST\n\n\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-46r2.pdf\
        \ [PDF, 570 KB]\n\n\n\n\nNIST Special Publication 800-114,\_Revision 1, July\
        \ 2016\n\n\nUser\u2019s Guide to Telework and Bring Your Own Device (BYOD)\
        \ Security\n\nNIST\n\nhttps://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-114r1.pdf\
        \ [PDF, 435 KB]\n\n\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.7.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:1
      ref_id: 21.4.7.R.01
      description: "Commonly termed \u201CBring Your Own Device\u201D (BYOD), personal\
        \ use of mobile computing in an organisational environment is widespread and\
        \ personnel have become accustomed to the use of a variety of personal mobile\
        \ devices. \_BYOD can have many advantages for an agency and for personnel.\
        \ \_At the same time, BYOD will introduce a range of new information security\
        \ risks and threats and may exacerbate existing risks."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.7.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:1
      ref_id: 21.4.7.C.01
      name: 'Control -  All Classifications - Must [CID: 4597]'
      description: Agencies MUST undertake a risk assessment and implement appropriate
        controls BEFORE implementing a BYOD Policy and permitting the use of BYOD.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.7.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:1
      ref_id: 21.4.7.C.02
      name: 'Control -  All Classifications - Must [CID: 4598]'
      description: Agencies MUST take an integrated approach to BYOD security, covering
        policy, training, support, systems architecture, security, systems management,
        change management, incident detection & management and business continuity.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: Applicability and Usage
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.8.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:2
      ref_id: 21.4.8.R.01
      description: "BYOD introduces number of additional risks and attack vectors\
        \ to agency systems. \_Not all BYOD risks can be fully mitigated with technologies\
        \ available today. \_It is therefore important that, where feasible, all the\
        \ controls specified in this section are implemented."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.8.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:2
      ref_id: 21.4.8.C.01
      name: 'Control -  All Classifications - Must [CID: 4623]'
      description: BYOD MUST only be permitted for agency information systems up to
        and including RESTRICTED.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.8.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:2
      ref_id: 21.4.8.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 4624]'
      description: BYOD MUST NOT be used for CONFIDENTIAL, SECRET or TOP SECRET systems.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: Technical Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:3
      ref_id: 21.4.9.R.01
      description: "\u201CJail-Breaking\u201D and \u201Crooting\u201D are terms applied\
        \ to devices where operating systems controls have been by-passed to allow\
        \ installation of alternate operating systems or software applications that\
        \ are not otherwise permitted. \_This is a risky practice and can create opportunities\
        \ for device compromise. \_Users may wish to alter settings to allow the download\
        \ of personal apps. \_This can result in security setting violations."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:3
      ref_id: 21.4.9.C.01
      name: 'Control -  All Classifications - Must Not [CID: 4627]'
      description: "Devices that have been \u201Cjail-broken\u201D, \u201Crooted\u201D\
        \ or have settings violations MUST NOT be used for any agency business or\
        \ be allowed to connect to any agency systems UNLESS this been specifically\
        \ authorised."
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: BYOD Policy
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.R.01
      description: "Technical controls fall into two categories: organisational systems\
        \ and device controls. \_Protection for organisational systems will start\
        \ with a risk assessment which guides the development of a secure architecture\
        \ to support BYOD operations. \_Additional controls will need to be applied\
        \ to individual devices. \_The privacy of user data should be considered.\
        \ A user policy is essential."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4630]'
      description: "Agencies may identify additional policy provisions and controls\
        \ that are required, based on their assessment of risk. \_Agencies MUST implement\
        \ the additional controls and protocols before implementing BYOD."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.02
      name: 'Control -  All Classifications - Must [CID: 4631]'
      description: Agencies MUST implement a BYOD acceptable use policy, agreed and
        signed by each person using a BYOD device.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.03
      name: 'Control -  All Classifications - Must [CID: 4632]'
      description: "The agency\u2019s policy MUST clearly establish eligibility of\
        \ personnel for participation in the agency BYOD scheme."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.04
      name: 'Control -  All Classifications - Must [CID: 4633]'
      description: Personnel MUST have written authorisation (usually managerial approval)
        before a connection is enabled (on-boarding).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.05
      name: 'Control -  All Classifications - Must [CID: 4634]'
      description: 'Written authorisation MUST include the nature and extent of agency
        access approved, considering:

        time, day of the week;

        location; and

        local or roaming access.

        '
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.06
      name: 'Control -  All Classifications - Must [CID: 4635]'
      description: Procedures MUST be established for removal of agency installed
        software and any agency data when the user no longer has a need to use BYOD,
        is redeployed or ceases employment (off-boarding).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.07
      name: 'Control -  All Classifications - Must [CID: 4637]'
      description: "Standard Operating Procedures for the agency\u2019s BYOD network\
        \ MUST be established."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.08
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.08
      name: 'Control -  All Classifications - Must [CID: 4638]'
      description: "Provision MUST be made for contractors and other authorised non-employees.\
        \ \_It is at the agency\u2019s discretion whether this activity is permitted.\
        \ \_The risk assessment MUST reflect this factor."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.09
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.09
      name: 'Control -  All Classifications - Must [CID: 4639]'
      description: Ownership of data on BYOD devices MUST be clearly articulated and
        agreed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.10
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.10
      name: 'Control -  All Classifications - Must [CID: 4643]'
      description: Agency policies MUST clearly articulate the separation between
        corporate support and where individuals are responsible for the maintenance
        and support of their own devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.11
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.11
      name: 'Control -  All Classifications - Must [CID: 4644]'
      description: Agency policies MUST clearly articulate the acceptable use of any
        GPS or other tracking capability.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.12
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.12
      name: 'Control -  All Classifications - Must [CID: 4645]'
      description: Individual responsibility for the cost of any BYOD device and its
        accessories MUST be agreed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.13
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.13
      name: 'Control -  All Classifications - Must [CID: 4646]'
      description: Individual responsibility for replacement in the event of loss
        or theft MUST be agreed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.14
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.14
      name: 'Control -  All Classifications - Must [CID: 4647]'
      description: Individuals MUST be responsible for the installation and maintenance
        of any mandated BYOD-based firewalls and anti-malware software and for implementing
        operating system updates and patches on their device.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.15
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.15
      name: 'Control -  All Classifications - Must [CID: 4648]'
      description: The procedures for purchasing and installing business related applications
        on the mobile devices MUST be specified and agreed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.10.c.16
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:4
      ref_id: 21.4.10.C.16
      name: 'Control -  All Classifications - Must [CID: 4650]'
      description: The responsibility for payment of voice and data plans and roaming
        charges MUST be specified and agreed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: BYOD Infrastructure and System Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.R.01
      description: "The use of BYOD presents increased risk and threat to agency systems.\
        \ \_Changes to an agency\u2019s security architecture are necessary in order\
        \ to minimise and manage the increased risk and threat to agency systems,\
        \ information and information privacy."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.R.02
      description: It is important that the principles of separation and segregation
        are applied to any system architecture or design to assist in the management
        of risk in BYOD systems.
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.R.03
      description: "BYOD devices will seek to establish multiple connections through\
        \ Wi-Fi \u201Chot spots\u201D, Bluetooth connection and simultaneous internet\
        \ and cellular connections. \_This behaviour creates multiple simultaneous\
        \ \u201Cback channels\u201D which can provide attack vectors for malicious\
        \ activities and is considered to be high risk."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.01
      name: 'Control -  All Classifications - Must [CID: 4655]'
      description: A security architectural review MUST be undertaken by the agency
        before allowing BYOD devices to connect to agency systems.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.02
      name: 'Control -  All Classifications - Must [CID: 4656]'
      description: "The BYOD network segment MUST be segregated from other elements\
        \ of the agency\u2019s network."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.03
      name: 'Control -  All Classifications - Must [CID: 4657]'
      description: Agencies MUST architecturally separate guest and public facing
        networks from BYOD networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.04
      name: 'Control -  All Classifications - Must [CID: 4658]'
      description: Network configuration policies and authentication mechanisms MUST
        allow access to agency resources ONLY through the BYOD network segment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.05
      name: 'Control -  All Classifications - Must [CID: 4659]'
      description: Access to internal resources and servers MUST be carefully managed
        and confined to only those services for which there is a defined and properly
        authorised business requirement.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.06
      name: 'Control -  All Classifications - Must [CID: 4660]'
      description: "Wireless access points used for access to agency networks MUST\
        \ be implemented and secured in accordance with the directions in this manual\
        \ (See Section 18.2 \u2013 Wireless Local Area Networks)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.07
      name: 'Control -  All Classifications - Must [CID: 4661]'
      description: Bluetooth on BYOD devices MUST be disabled while within designated
        secure areas on agency premises.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.08
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.08
      name: 'Control -  All Classifications - Must [CID: 4662]'
      description: "Access Controls MUST be implemented in accordance with Chapter\
        \ 16 \u2013 Access Control."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.09
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.09
      name: 'Control -  All Classifications - Must [CID: 4663]'
      description: Agencies MUST maintain a list of permitted operating systems, including
        operating system version numbers, for BYOD devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.10
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.10
      name: 'Control -  All Classifications - Must [CID: 4664]'
      description: Agencies MUST check each BYOD device for malware and sanitise the
        device appropriately before installing agency software or operating environments.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.11
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.11
      name: 'Control -  All Classifications - Must [CID: 4665]'
      description: Agencies MUST check each BYOD device for malware and sanitise the
        device appropriately before permitting access to agency data.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.12
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.12
      name: 'Control -  All Classifications - Must [CID: 4666]'
      description: "BYOD MUST have a Mobile Device Management (MDM) solution implemented\
        \ with a minimum of the following enabled:\nThe MDM is enabled to \u201Cwipe\u201D\
        \ devices of any agency data if lost or stolen;\nIf the MDM cannot discriminate\
        \ between agency and personal data, all data, including personal data, is\
        \ deleted if the device is lost or stolen;\nThe MDM is capable of remotely\
        \ applying agency security configurations for BYOD devices;\nMobile device\
        \ security configurations are validated (health check) by the MDM before a\
        \ device is permitted to connect to the agency\u2019s systems;\n\u201CJail-broken\u201D\
        , \u201Crooted\u201D or settings violations MUST be detected and isolated;\_\
        \n\u201CJail-broken\u201D devices are NOT permitted to access agency resources;\_\
        \nAccess to agency resources is limited until both the device and user is\
        \ fully compliant with policy and SOPs;\nAuditing and logging is enabled;\
        \ and\nChanges of Subscriber Identity Module (SIM) card are monitored to allow\
        \ remote blocking and wiping in the event of theft or compromise.\n"
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.13
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.13
      name: 'Control -  All Classifications - Must [CID: 4667]'
      description: Intrusion detection systems MUST be implemented.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.14
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.14
      name: 'Control -  All Classifications - Must [CID: 4668]'
      description: "Continuous monitoring MUST be established to detect actual or\
        \ potential security compromises or incidents from BYOD devices. \_Refer also\
        \ to Chapter 6 - Information Security Monitoring."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.15
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.15
      name: 'Control -  All Classifications - Must [CID: 4669]'
      description: Agencies MUST maintain a list of approved cloud applications that
        may be used on BYOD devices.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.16
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.16
      name: 'Control -  All Classifications - Must [CID: 4670]'
      description: Agencies MUST block the use of unapproved cloud applications for
        processing any agency or organisational data.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.17
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.17
      name: 'Control -  All Classifications - Must Not [CID: 4671]'
      description: BYOD devices MUST NOT be permitted direct connection to internal
        hosts, including all other devices on the local network.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.18
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.18
      name: 'Control -  All Classifications - Must Not [CID: 4672]'
      description: BYOD devices connecting to guest and public facing networks MUST
        NOT be permitted access to the corporate network other than through a VPN
        over the Internet.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.19
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.19
      name: 'Control -  All Classifications - Should [CID: 4674]'
      description: Bluetooth on BYOD devices SHOULD be disabled while within agency
        premises and while accessing agency systems and data.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.11.c.20
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:5
      ref_id: 21.4.11.C.20
      name: 'Control -  All Classifications - Should [CID: 4675]'
      description: BYOD devices and systems SHOULD use Multi-factor (at least two-factor)
        authentication to connect to agency systems and prior to being permitted access
        to agency data.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: Wireless IDS / IPS systems
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      ref_id: 21.4.12.R.01
      description: "Devices will automatically associate with the strongest signal\
        \ and associated Access Point (AP). \_A rogue AP may belong to another organisation\
        \ in an adjacent building, contractor, customer, supplier or other visitor.\
        \ \_Association with a rogue AP can provide a means for the installation of\
        \ malware."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      ref_id: 21.4.12.R.02
      description: "Wireless IDS / IPS systems have the ability to detect rogue wireless\
        \ AP\u2019s by channel, MAC address, frequency band and SSID. \_They can continuously\
        \ monitor wireless networks and detect and block denial-of-service and adversary-in-the-middle\
        \ wireless attacks. \_Establishing baselines of known authorised and unauthorised\
        \ devices and AP\u2019s will assist in detecting and isolating any rogue devices\
        \ and AP\u2019s."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      ref_id: 21.4.12.C.01
      name: 'Control -  All Classifications - Must [CID: 4679]'
      description: Agencies MUST implement a wireless IDS /IPS on BYOD wireless networks.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      ref_id: 21.4.12.C.02
      name: 'Control -  All Classifications - Must [CID: 4680]'
      description: "Agencies MUST implement rogue AP and wireless \u201Chot spot\u201D\
        \ detection and implement response procedures where detection occurs."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:6
      ref_id: 21.4.12.C.03
      name: 'Control -  All Classifications - Should [CID: 4681]'
      description: "Agencies SHOULD conduct a baseline survey to identify:\nAll authorised\
        \ devices and AP\u2019s; and\nAny unauthorised devices and AP\u2019s.\n"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: BYOD Device Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.R.01
      description: "Mobile devices are susceptible to loss, theft and being misplaced.\
        \ \_These devices can be easily compromised when out of the physical control\
        \ of the authorised user or owner. \_To protect agency systems it is important\
        \ that BYOD devices are also secured and managed on an ongoing basis."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.01
      name: 'Control -  All Classifications - Must [CID: 4684]'
      description: "Any agency data exchanged with the mobile device MUST be encrypted\
        \ in transit (See Chapter 17 \u2013 Cryptography)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.02
      name: 'Control -  All Classifications - Must [CID: 4685]'
      description: Any agency data stored on the device MUST be encrypted (including
        keys, certificates and other essential session establishment data).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.03
      name: 'Control -  All Classifications - Must [CID: 4686]'
      description: "The use of virtual containers, sandboxes, wraps or similar mechanisms\
        \ on the mobile device MUST be established for each authorised session for\
        \ any organisational data. \_These mechanisms MUST be non-persistent and be\
        \ removed at the end of each session."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.04
      name: 'Control -  All Classifications - Must [CID: 4687]'
      description: Any sensitive agency data MUST be removed and securely deleted,
        or encrypted at the end of a session.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.05
      name: 'Control -  All Classifications - Must [CID: 4688]'
      description: "Connections to the agency network MUST be time limited to avoid\
        \ leaving a session \u201Clogged on\u201D."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.06
      name: 'Control -  All Classifications - Must [CID: 4689]'
      description: Communications between the mobile device and the agency network
        MUST be established through a Virtual Private Network (VPN).
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.07
      name: 'Control -  All Classifications - Must [CID: 4690]'
      description: "Agencies MUST disable split-tunnelling when using a BYOD device\
        \ to connect to an agency network (See Section 21.1 \u2013 Agency Owned Mobile\
        \ Devices)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.08
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.08
      name: 'Control -  All Classifications - Must [CID: 4691]'
      description: "Agencies MUST disable the ability for a BYOD device to establish\
        \ simultaneous connections (e.g. wireless and cellular) when connected to\
        \ an agency\u2019s network."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.09
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.09
      name: 'Control -  All Classifications - Must [CID: 4692]'
      description: The use of passwords or PINs to unlock the BYOD device MUST be
        enforced in addition to all other agency authentication mechanisms.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.10
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.10
      name: 'Control -  All Classifications - Must [CID: 4693]'
      description: BYOD device passwords MUST be distinct from any agency access and
        authentication passwords.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.13.c.11
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:7
      ref_id: 21.4.13.C.11
      name: 'Control -  All Classifications - Must [CID: 4694]'
      description: "BYOD passwords MUST be distinct from other fixed or mobile agency\
        \ network passwords (See Section 16.1 \u2013 Identification and Authentication\
        \ for details on password requirements)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4
      description: Additional Controls
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      ref_id: 21.4.14.R.01
      description: "There are many new devices and operating system versions being\
        \ frequently released. \_It may not be feasible or cost-effective for an agency\
        \ to support all combinations of device and operating system."
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      ref_id: 21.4.14.C.01
      name: 'Control -  All Classifications - Should [CID: 4697]'
      description: Agencies SHOULD compile a list of approved BYOD devices and operating
        systems for the guidance of staff.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      ref_id: 21.4.14.C.02
      name: 'Control -  All Classifications - Should [CID: 4698]'
      description: Agencies SHOULD consider the implementation of Data Loss Prevention
        (DLP) technologies.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.14.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      ref_id: 21.4.14.C.03
      name: 'Control -  All Classifications - Should [CID: 4699]'
      description: Agencies SHOULD consider the use of bandwidth limits as a means
        of controlling data downloads and uploads.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:21.4.14.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:21.4:4:8
      ref_id: 21.4.14.C.04
      name: 'Control -  All Classifications - Should [CID: 4700]'
      description: Agencies SHOULD take legal advice on the provisions in their BYOD
        policy.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22
      assessable: false
      depth: 1
      ref_id: '22'
      name: Enterprise systems security
    - urn: urn:defend:risk:req_node:nzism-v3:22.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:22
      ref_id: '22.1'
      name: Cloud Computing
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:1
      ref_id: 22.1.1
      description: "Cloud systems risks are identified and managed and that Official\
        \ Information and agency information systems are protected in accordance with\
        \ Cabinet Directives, the PSR, the New Zealand Government Security Classification\
        \ System, the NZISM and with other government security\_requirements and guidance."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      description: Terminology
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:1
      ref_id: 22.1.2
      description: Terminology and definitions of cloud models and services used in
        this section are consistent with NIST Special Publication 800-145, The NIST
        Definition of Cloud Computing, dated September 2011 (see table of References
        below).
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:1
      ref_id: 22.1.3
      description: "A fundamental construct in the management of risk in cloud environment\
        \ 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.2 \u2013 Virtualisation."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      description: Separation and Segregation
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:2
      ref_id: 22.1.4
      description: "Separation and Segregation is 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."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:2
      ref_id: 22.1.5
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      description: Mandates and Requirements
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:3
      ref_id: 22.1.6
      description: "In August 2013, the Government introduced their approach to cloud\
        \ computing, establishing a \u2018cloud first\u2019 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]."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:3
      ref_id: 22.1.7
      description: "Under the \u2018cloud first\u2019 policy state service agencies\
        \ are expected to adopt approved cloud services either when faced with new\
        \ procurements, or an upcoming contract extension decision."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:3
      ref_id: 22.1.8
      description: "In October 2013 the Government approved the GCIO risk and assurance\
        \ framework for cloud computing, which agencies must follow when they are\
        \ considering using cloud services [CAB Min (13) 37/6B]. \_It also directs\
        \ that no data classified above RESTRICTED should be held in a public cloud,\
        \ whether it is hosted onshore or offshore."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:3
      ref_id: 22.1.9
      description: It is important to note that although agencies can outsource responsibility
        to a service provider for implementing, managing and maintaining security
        controls, they cannot outsource their accountability for ensuring their data
        is appropriately protected.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.10
      description: "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,\
        \ technical and security risks."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.11
      description: "Typically agencies and other organisations start with a small,\
        \ private cloud, allowing technical and security architectures, management\
        \ processes and security controls to be developed and tested and gain some\
        \ familiarity with cloud technologies and processes. \_These organisations\
        \ then progress by using non-critical data, for example email, and other similar\
        \ applications, in a hybrid, private or public cloud environment."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.12
      description: "There are a number of technical risks associated with cloud computing,\
        \ in addition to the existing risks inherent in organisational systems. \_\
        Attention must also be paid to the strategic, governance and management risks\
        \ of cloud computing. \_Security architecture and security controls also require\
        \ careful risk assessment and consideration."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.13
      description: Cloud service providers will invariably seek to limit services,
        liability, compensation or penalties through carefully worded service contracts,
        which may present particular risks.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.14
      description: "Much has been made of the operational cost savings related to\
        \ cloud technologies, particularly a lower cost of operating. \_Less obvious\
        \ are the risks and related cost of managing risk to an acceptable level.\
        \ \_It is important to note that short term overall cost increases may, in\
        \ some cases, be attributed to the adoption of cloud technologies and architectures."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:4
      ref_id: 22.1.15
      description: "Some valuable work in mapping the cloud risk landscape has been\
        \ undertaken by such organisations as the Cloud Security Alliance, the US\
        \ National Institute of Standards and Technology (NIST), the UK\u2019s Cloud\
        \ Industry Forum and the European Network and Information Security Agency\
        \ (ENISA). \_It is important to note that the extent of the risk landscape\
        \ continues to evolve and expand."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:2:5
      ref_id: 22.1.16
      description: "This section provides information and some guidance on the risks\
        \ associated with cloud computing, its implementation and ongoing use. \_\
        Some controls are specified but agencies will necessarily undertake their\
        \ own comprehensive risk assessment and select controls to manage those risks."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: References - Guidance
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:3
      ref_id: 22.1.17
      description: "While NOT an exhaustive list, further information on Cloud can\
        \ be found at:\n\n\nReference\_\nTitle\nPublisher\nSource\n\n\nCAB Min (12)\
        \ 29/8A\_\n\nCabinet Minute of Decision \u2013 CAB Min (12) 29/8A \u2013 \u2018\
        Cloud First\u2019 Policy\n\n\nCabinet Office\n\n\_\n\n\nCAB Min (13) 37/6B\_\
        \n\nCabinet Minute of Decision \u2013 CAB Min (13) 37/6B \u2013 Cloud Computing\
        \ Risk and Assurance Framework\n\n\nCabinet Office\n\n\n\_Cabinet minutes\
        \ for public cloud services | NZ Digital government\n\n\n\n\_\n\nAll-of-Government\
        \ Cloud Services\n\n\nGovernment Chief Information Officer\n\n\nhttps://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/cloud-services/\n\
        \n\n\n\_\n\nRisk Assessment Process: Information Security\n\n\nGovernment\
        \ Chief Information Officer\n\n\nhttps://www.digital.govt.nz/dmsdocument/3~Risk-Assessment-Process-Information-Security.pdf\
        \ [PDF, 282 KB]\n\n\n\n\_\n\nGovernment Use of Offshore Information and Communication\
        \ Technologies (ICT) Service Providers \u2013 Advice on Risk Management April\
        \ 2009\n\n\nState Services Commission\n\n\nhttp://ict.govt.nz/assets/ICT-System-Assurance/offshore-ICT-service-providers-april-2009.pdf\n\
        \n\n\n\_\n\nCloud Computing a Guide to Making the Right Choices \u2013 February\
        \ 2013\n\n\nOffice of the Privacy Commissioner (OPC)\n\n\nOffice of the Privacy\
        \ Commissioner | Making the right choices in cloud computing - new Privacy\
        \ Commissioner guidance\n\n\n\n\_\n\nCloud Computing Security Considerations\n\
        \n\nASD\n\n\nhttps://www.cyber.gov.au/acsc/view-all-content/publications/cloud-computing-security-considerations\n\
        \n\n\n\_\n\nCloud Computing Policy and Guidance 2014\n\n\nAustralian Government\
        \ Information Management Office (AGIMO)\n\n\nhttp://www.finance.gov.au/agict//policy-guides-procurement/cloud\n\
        \n\n\n\_\n\nCloud Control Matrix\n\n\nCSA\n\n\nhttps://cloudsecurityalliance.org/research/cloud-controls-matrix/\n\
        \n\n\n\_\n\nSecurity Guidance for Critical Areas of Focus in Cloud Computing\n\
        \n\nCSA\n\n\nhttps://cloudsecurityalliance.org/research/guidance/\n\n\n\n\_\
        \n\nTop Threats to Cloud Computing\n\n\nCSA\n\n\nhttps://cloudsecurityalliance.org/research/working-groups/top-threats/\n\
        \n\n\n\_\n\nGovernance, Risk Management and Compliance Stack\n\n\nCSA\n\n\n\
        http://www.cloudsecurityalliance.org/grcstack.html\n\n\n\n\_\n\nSecurity &\
        \ Resilience in Governmental Clouds - Making an informed decision\n\n\nENISA\n\
        \n\nhttps://www.enisa.europa.eu/publications/security-and-resilience-in-governmental-clouds\n\
        \n\n\n\_\n\nCloud Computing Information Assurance Framework\n\n\nENISA\n\n\
        \nhttps://www.enisa.europa.eu/publications/cloud-computing-information-assurance-framework\n\
        \n\n\n\_\n\nCloud Computing Security Risk Assessment\n\n\nENISA\n\n\nhttps://www.enisa.europa.eu/publications/cloud-computing-risk-assessment\n\
        \n\n\n\_\n\nCritical Cloud Computing \u2013 A CIIP perspective on cloud computing\
        \ services\n\n\nENISA\n\nCritical Cloud Computing-A CIIP perspective on cloud\
        \ computing services \u2014 ENISA (europa.eu)\n\n\nNIST Special Publication\_\
        800-144, December 2011\n\nGuidelines on Security and Privacy in Public Cloud\
        \ Computing\n\n\nNIST\n\n\nhttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-144.pdf\
        \ [PDF, 1.08 MB]\n\n\n\n\_\n\nEnterprise Risk Management for Cloud Computing\n\
        \n\nCOSO\n\n\nCloud-Computing-Thought-Paper.pdf (coso.org)\n\n\n\n\_\n\nCloud\
        \ Security\n\n\nCloud Industry Forum\n\n\nKnowledge Hub - Cloud Industry Forum\n\
        \n\n\n\_\n\nOASIS \u2013 various reference and guidance documents\n\n\n\_\
        OASIS\n\n\nhttps://www.oasis-open.org/committees/tc_cat.php?cat=cloud\n\n\n\
        \n"
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: References - Standards
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.18
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:4
      ref_id: 22.1.18
      description: "Further\_standards can be found at:\n\n\n\nReference\_\n\n\nTitle\n\
        \n\nPublisher\n\n\nSource\n\n\n\nNIST Special Publication 800-145, September\
        \ 2011\n\nThe NIST Definition of Cloud Computing\n\n\nNIST\n\n\nhttp://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf\
        \ [PDF, 84 KB]\n\n\n\nNIST Special Publication 800-146, May 2012\n\nCloud\
        \ Computing Synopsis and Recommendations\_\n\n\nNIST\n\n\nhttp://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-146.pdf\
        \ [PDF, 1.44 MB]\n\n\n\nNIST Special Publication 500-291, version 2, July\
        \ 2013\n\nCloud Computing Standards Roadmap\_\n\n\nNIST\n\n\nhttp://www.nist.gov/itl/cloud/upload/NIST_SP-500-291_Version-2_2013_June18_FINAL.pdf\
        \ [PDF, 2.19 MB]\n\n\n\nNIST Special Publication 500-292, September 2011\n\
        \nCloud Computing Reference Architecture\_\n\n\nNIST\n\n\nhttp://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505\
        \ [PDF, 1.42 MB]\n\n\n\nISO/IEC 17788:2014\_\n\nInformation technology --\
        \ Cloud computing -- Overview and vocabulary\n\n\nISO\n\n\nhttps://www.iso.org/standard/60544.html\n\
        \n\n\nISO/IEC 17789:2014\_\n\nInformation technology -- Cloud computing --\
        \ Reference architecture\n\n\nISO\n\n\nhttps://www.iso.org/standard/60545.html\n\
        \n\n\nISO/IEC 17826:2012\_\_\n\nInformation technology -- Cloud Data Management\
        \ Interface (CDMI)\n\n\nISO\n\n\nhttps://www.iso.org/standard/60617.html\n\
        \n\n\nISO/IEC CD 19086-1:2016\_\n\nInformation technology -- Cloud computing\
        \ -- Service level agreement (SLA) framework and Technology -- Part 1: Overview\
        \ and concepts\n\n\nISO\n\n\nhttps://www.iso.org/standard/67545.html\n\n\n\
        \nISO/IEC NP 19086-2:2018\_\_\n\nInformation technology -- Cloud computing\
        \ -- Service level agreement (SLA) framework and Technology -- Part 2: Metrics\n\
        \n\nISO\n\n\nhttps://www.iso.org/standard/67546.html\n\n\n\nISO/IEC NP 19086-3:2017\_\
        \_\n\nInformation technology -- Cloud computing -- Service level agreement\
        \ (SLA) framework and Technology -- Part 3: Core requirements\n\n\nISO\n\n\
        \nhttps://www.iso.org/standard/67547.html\n\n\n\nISO/IEC AWI 19941:2017\_\_\
        \n\nInformation Technology -- Cloud Computing -- Interoperability and Portability\n\
        \n\nISO\n\n\nhttps://www.iso.org/standard/66639.html\n\n\n\nISO/IEC AWI 19944-1:2020\_\
        \_\n\nInformation Technology - Cloud Computing - Data and their Flow across\
        \ Devices and Cloud Services\n\n\nISO\n\n\nhttps://www.iso.org/standard/79573.html\n\
        \n\n\nISO/IEC DIS 27017:2015\_\_\n\n(In Draft) Information technology -- Security\
        \ techniques -- Code of practice for information security controls based on\
        \ ISO/IEC 27002 for cloud services\n\n\nISO\n\n\nhttps://www.iso.org/standard/43757.html\n\
        \n\n\nISO/IEC 27018:2019\_\_\n\nInformation technology -- Security techniques\
        \ -- Code of practice for protection of personally identifiable information\
        \ (PII) in public clouds acting as PII processors\n\n\nISO\n\n\nhttps://www.iso.org/standard/76559.html\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: PSR references
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.19
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:5
      ref_id: 22.1.19
      description: "Relevant PSR requirements can be found at:\n\n\n\nReference\n\
        Title\nSource\n\n\n\nPSR Mandatory Requirements\n\n\nGOV2, GOV5, GOV6, INFOSEC1,\
        \ INFOSEC2, INFOSEC3 and INFOSEC4\n\n\nHome | Protective Security Requirements\n\
        Security governance (GOV) | Protective Security Requirements\nInformation\
        \ security (INFOSEC) | Protective Security Requirements\n\_\n\n\n\n\nPSR content\
        \ protocols \n\n\nManagement protocol for information security\n\n\nManagement\
        \ protocol for information security | Protective Security Requirements\n\_\
        \n\n\n\n\nPSR\_ requirements sections\n\n\nHandling requirements for protectively\
        \ marked information and equipment\nSupply chain security\_\nAssess the risks\
        \ to your information security\nQuick Classification Guide\n\n\nClassification\
        \ system | Protective Security Requirements\nSupply chain security | Protective\
        \ Security Requirements\nUnderstanding the information security lifecycle\
        \ | Protective Security Requirements\npsr-classification-quick-guides.pdf\n\
        \n\n\n\nManaging specific scenarios\n\nManaging specific scenarios | Protective\
        \ Security Requirements\n\nTransacting online with the public\_\nOutsourcing,\
        \ Offshoring and supply chains\nMobile and Remote working\nCloud Computing\_\
        \nCommunications Security\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Applicability
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.R.01
      description: "Security controls may not be available, cost effective or appropriate\
        \ for all information classification levels. \_Much will depend on the cloud\
        \ computing deployment model adopted. \_It is important that agencies understand\
        \ when it is appropriate to use cloud services and how to select appropriate\
        \ cloud services and service models, based on the classification of the information,\
        \ any special handling endorsements and associated confidentiality, availability\
        \ and integrity risks."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.R.02
      description: Systems and information classified CONFIDENTIAL and above require
        higher levels of protection. This applies in all types of cloud models including
        private, community, hybrid, and public cloud models and deployments.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 4800]'
      description: The use of cloud services and infrastructures for systems and data
        classified CONFIDENTIAL, SECRET or TOP SECRET MUST be approved by the GCSB.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.C.02
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4801]'
      description: Agencies intending to adopt cloud technologies or services MUST
        ensure cloud service providers apply the controls specified in this manual
        to any systems hosting, processing or storing agency data and systems.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.C.03
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 4802]'
      description: Agencies MUST NOT use public, hybrid (incorporating a public element),
        or other external cloud services for systems and data classified CONFIDENTIAL,
        SECRET or TOP SECRET.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.C.04
      name: 'Control -  All Classifications - Must Not [CID: 4803]'
      description: Agencies MUST NOT use public or hybrid (incorporating a public
        element) cloud services to host, process, store or transmit NZEO endorsed
        information.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.20.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:1
      ref_id: 22.1.20.C.05
      name: 'Control -  All Classifications - Should [CID: 4804]'
      description: Agencies intending to adopt cloud technologies or services SHOULD
        obtain formal assurance cloud service providers will apply the controls specified
        in this manual to any cloud service hosting, processing or storing agency
        data and systems.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Risk Assessment
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.R.01
      description: "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."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.R.02
      description: The responsibility for the implementation, management and maintenance
        of controls will depend on the service model and deployment model (refer to
        NIST SP800-145) used in the delivery of cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.01
      name: 'Control -  All Classifications - Must [CID: 4808]'
      description: Agencies intending to adopt cloud technologies or services MUST
        conduct a risk assessment before implementation or adoption.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.02
      name: 'Control -  All Classifications - Must [CID: 4809]'
      description: Agencies intending to adopt cloud technologies or services MUST
        determine trust boundaries before implementation.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.03
      name: 'Control -  All Classifications - Must [CID: 4810]'
      description: Agencies intending to adopt cloud technologies or services MUST
        determine where the responsibility (agency or cloud service provider) for
        implementing, managing and maintaining controls lies in accordance with agreed
        trust boundaries.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.04
      name: 'Control -  All Classifications - Must [CID: 4811]'
      description: "Agencies MUST ensure cloud risks for any cloud service adopted\
        \ are understood and formally accepted by the Agency Head or Chief Executive\
        \ (or their formal delegate) and the agency\u2019s Accreditation Authority."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.05
      name: 'Control -  All Classifications - Must [CID: 4812]'
      description: Agencies MUST consult with the GCDO to ensure the strategic and
        other cloud risks are comprehensively assessed.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.06
      name: 'Control -  All Classifications - Must [CID: 4813]'
      description: Agencies procuring or using cloud services to be used by multiple
        agencies MUST ensure all interested parties formally agree the risks, controls
        and any residual risks of such cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.21.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:2
      ref_id: 22.1.21.C.07
      name: 'Control -  All Classifications - Must [CID: 4814]'
      description: Agencies using cloud services MUST ensure they have conducted a
        documented risk assessment, accepted any residual risks, and followed the
        endorsement procedure required by the GCDO.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Offshore Services
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.R.01
      description: "Cloud services hosted offshore introduce several additional risks,\
        \ in particular, jurisdictional, sovereignty and privacy risks. \_Foreign\
        \ owned cloud service providers operating in New Zealand, are subject to New\
        \ Zealand legislation and regulation. \_They may, however, also be subject\
        \ to a foreign government\u2019s privacy, lawful access and data intercept\
        \ legislation."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.R.02
      description: "The majority of these jurisdictional, sovereignty and privacy\
        \ risks cannot be adequately managed with controls available today. \_They\
        \ must therefore be carefully considered and accepted by the Agency Head or\
        \ Chief Executive before the adoption of such cloud services."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.R.03
      description: "Some cloud services hosted within New Zealand may be supported\
        \ by foreign based technical staff.\_ This characteristic introduces a further\
        \ risk element to the use of foreign-owned cloud service providers."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.R.04
      description: "Further complexity can be introduced when All-of-Government or\
        \ multi-agency systems are deployed or integrated with cloud services. \_\
        Any security breach can affect several agencies and compromise large or aggregated\
        \ data sets."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.01
      name: 'Control -  All Classifications - Must [CID: 4820]'
      description: "Agencies using cloud services hosted offshore MUST ensure jurisdictional,\
        \ sovereignty and privacy risks are fully considered and formally accepted\
        \ by the Agency Head or Chief Executive and the agency\u2019s Accreditation\
        \ Authority."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.02
      name: 'Control -  All Classifications - Must [CID: 4821]'
      description: Agencies using cloud services hosted offshore MUST ensure that
        the agency retains ownership of its information in any contract with the cloud
        service provider.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.03
      name: 'Control -  All Classifications - Must [CID: 4822]'
      description: Agencies using cloud services hosted offshore and connected to
        All-of-Government systems MUST ensure they have conducted a risk assessment,
        accepted any residual risks, and followed the endorsement procedure required
        by the GCDO.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.04
      name: 'Control -  Confidential, Top Secret, Secret - Must Not [CID: 4823]'
      description: Agencies MUST NOT use cloud services hosted offshore for information
        or systems classified CONFIDENTIAL, SECRET or TOP SECRET.
      implementation_groups:
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
      - Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.05
      name: 'Control -  All Classifications - Must Not [CID: 4824]'
      description: Agencies MUST NOT use cloud services hosted offshore for information
        with an NZEO endorsement.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.22.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:3
      ref_id: 22.1.22.C.06
      name: 'Control -  All Classifications - Should Not [CID: 4825]'
      description: 'Agencies SHOULD NOT use cloud services hosted offshore unless:

        privacy, information sensitivity and information value has been fully assessed
        by the agency;

        a comprehensive risk assessment is undertaken by the agency;

        controls to manage identified risks have been specified by the agency; and

        the cloud service provider is able to provide adequate assurance that these
        controls have been properly implemented before the agency uses the cloud service.

        '
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: System Availability
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.23.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      ref_id: 22.1.23.R.01
      description: "The availability of agency systems, business functionality and\
        \ any customer or client online services, is subject to additional risks in\
        \ an outsourced cloud environment. \_A risk assessment will include consideration\
        \ of business requirements on availability in a cloud environment."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.23.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      ref_id: 22.1.23.R.02
      description: "Risks to business functionality may include service outages, such\
        \ as communications, data centre power, backup and other failures or interruptions.\
        \ \_Entity failures such the merger, acquisition or liquidation of the cloud\
        \ service provider may also present a significant business risk to availability."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.23.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      ref_id: 22.1.23.C.01
      name: 'Control -  All Classifications - Must [CID: 4829]'
      description: Agencies intending to adopt cloud technologies or services MUST
        consider the risks to the availability of systems and information in their
        design of cloud systems architectures and supporting controls and governance
        processes.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.23.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      ref_id: 22.1.23.C.02
      name: 'Control -  All Classifications - Must [CID: 4830]'
      description: Any contracts for the provision of cloud services MUST include
        service level, availability, recoverability and restoration provisions.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.23.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:4
      ref_id: 22.1.23.C.03
      name: 'Control -  All Classifications - Must [CID: 4831]'
      description: Agencies MUST ensure contracts with cloud service providers include
        provisions to manage risks associated with the merger, acquisition, liquidation
        or bankruptcy of the service provider and any subsequent termination of cloud
        services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Unauthorised Access
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.R.01
      description: "Cloud service providers may not provide adequate physical security\
        \ and physical and logical access controls to meet agencies requirements.\
        \ \_An assessment of cloud service risks will include physical and systems\
        \ security. \_Refer also to Chapter 19 \u2013 Gateway Security, Section 22.2\
        \ \u2013 Virtualisation and Section 22.3 \u2013 Virtual Local Area Networks."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.R.02
      description: "Some cloud services hosted within New Zealand may be supported\
        \ by technical staff, presenting additional risk. \_In some cases the technical\
        \ staff are based offshore. \_The use of encryption can provide additional\
        \ assurance against unauthorised access \u2013 refer to Chapter 17 \u2013\
        \ Cryptography."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.R.03
      description: "Data Loss Prevention (DLP) technologies and techniques are implemented\
        \ to safeguard sensitive or critical information from leaving the organisation.\
        \ \_They operate by identifying unauthorised access and data exfiltration\
        \ and take remedial action by monitoring, detecting and blocking unauthorised\
        \ attempts to exfiltrate data. \_For DLP to be effective, all data states\
        \ (processing, transmission and storage) are monitored."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.C.01
      name: 'Control -  All Classifications - Should [CID: 4836]'
      description: Agencies intending to adopt cloud technologies or services SHOULD
        ensure cloud service providers apply the physical, virtual and access controls
        specified in this manual for agency systems and data protection.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.C.02
      name: 'Control -  All Classifications - Should [CID: 4837]'
      description: Agencies intending to adopt cloud technologies or services SHOULD
        apply separation and access controls to protect data and systems where support
        is provided by offshore technical staff.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.C.03
      name: 'Control -  All Classifications - Should [CID: 4838]'
      description: Agencies intending to adopt cloud technologies or services SHOULD
        apply controls to detect and prevent unauthorised data transfers and multiple
        or large scale data transfers to offshore locations and entities.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.24.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:5
      ref_id: 22.1.24.C.04
      name: 'Control -  All Classifications - Should [CID: 4839]'
      description: Agencies intending to adopt cloud technologies or services SHOULD
        consider the use of encryption for data in transit and at rest.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Incident Handling and Management
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.25.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:6
      ref_id: 22.1.25.R.01
      description: "Cloud service providers may not provide the same level of incident\
        \ identification and management as provided by agencies. \_In some cases,\
        \ these services will attract additional costs. \_Careful management of contracts\
        \ is required to ensure agency requirements for incident detection and management\
        \ are fully met when adopting cloud services."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.25.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:6
      ref_id: 22.1.25.C.01
      name: 'Control -  All Classifications - Must [CID: 4842]'
      description: Agencies MUST include incident handling and management services
        in contracts with cloud service providers.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.25.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:6
      ref_id: 22.1.25.C.02
      name: 'Control -  All Classifications - Must [CID: 4843]'
      description: "Agencies MUST develop and implement incident identification and\
        \ management processes in accordance with this manual (See Chapter 6 \u2013\
        \ Information Security Monitoring, Chapter 7 \u2013 Information Security Incidents,\
        \ Chapter 9 \u2013 Personnel Security and Chapter 16 \u2013 Access Control)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: Backup, Recovery Archiving and Data Remanence
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.R.01
      description: "Cloud service providers will invariably provide some business\
        \ continuity and disaster recovery plans, including system and data backup,\
        \ for their own operational purposes. \_These plans may not include customer\
        \ data or systems. \_Where cloud service providers do not adequately meet\
        \ agency business requirements, an agency defined backup and recovery plan\
        \ may be necessary."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.R.02
      description: "Residual information remaining on a device or storage media after\
        \ clearing or sanitising the device or media is described as data remanence.\
        \ \_This characteristic is sometimes also described as data persistence, although\
        \ this description may include the wider implication of multiple copies."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.R.03
      description: Full consideration of risks associated with data remanence and
        data persistence is required to ensure agency requirements for backup, recovery,
        archiving and data management is included in any cloud service contract.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.R.04
      description: "In addition to backups, cloud service providers may also archive\
        \ data. \_Multi-national or foreign based cloud service providers may have\
        \ established data centres in several countries. \_Backup and archiving is\
        \ invariably automated and there may be no feasible method of determining\
        \ where and in what jurisdiction the data have been archived. \_This can create\
        \ an issue of data remanence and persistence where cloud service contracts\
        \ are terminated but not all agency data can be effectively purged or deleted\
        \ from the provider\u2019s systems."
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.C.01
      name: 'Control -  All Classifications - Must [CID: 4849]'
      description: "Agencies MUST develop and implement a backup, recovery and archiving\
        \ plan and supporting procedures (See Section 6.4 \u2013 Business Continuity\
        \ and Disaster Recovery)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.C.02
      name: 'Control -  All Classifications - Must [CID: 4850]'
      description: Agencies MUST include a data purge or secure delete process in
        any cloud service contracts.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.26.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:7
      ref_id: 22.1.26.C.03
      name: 'Control -  All Classifications - Must [CID: 4851]'
      description: Any data purge or secure delete process in any cloud service contracts
        MUST be independently verifiable.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.1:6:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6
      description: User Awareness and Training
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.27.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:8
      ref_id: 22.1.27.R.01
      description: The introduction of cloud services will introduce change to the
        appearance and functionality of systems, how users access agency systems and
        types of user support. It is essential that users are aware of information
        security and privacy concepts and risks associated with the services they
        use.Support provided by the cloud service provider may attract additional
        charges.
    - urn: urn:defend:risk:req_node:nzism-v3:22.1.27.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.1:6:8
      ref_id: 22.1.27.C.01
      name: 'Control -  All Classifications - Must [CID: 4854]'
      description: "Agencies MUST develop and implement user awareness and training\
        \ programmes to support and enable safe use of cloud services (See Section\
        \ 9.1 \u2013 Information Security Awareness and Training)."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:22
      ref_id: '22.2'
      name: Virtualisation
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:1
      ref_id: 22.2.1
      description: To identify virtualisation specific risks and apply mitigations
        to minimise risk and secure the virtual environment.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.2
      description: Virtualisation is the software simulation of the components of
        an information system and may include the simulation of hardware, operating
        systems, applications, infrastructure and storage. Underlying the simulation
        is hardware and control or simulation software, often described as a virtual
        machine (VM).
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.3
      description: "A Hypervisor is a fundamental component of a virtual environment\
        \ and provides a supervisory function and framework that enables multiple\
        \ operating systems, often described as \u201CGuest Operating Systems\u201D\
        , to run on a single physical device."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.4
      description: A fundamental construct in the management of risk in virtual environments
        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. As assets are added to a
        Trust Zone, they inherit the security policies set for that Trust Zone.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.5
      description: Trust Zones will also apply the Principal of Least Privilege, which
        requires that each element in the network is permitted to access only those
        other network elements that are required for the node to perform its business
        function.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.6
      description: "Virtualisation is radically changing how agencies and other organisations\
        \ select, deploy implement and manage ICT. \_While offering significant benefits\
        \ in efficiency, resource consolidation and utilisation of CIT assets, virtualisation\
        \ can add risks to the operation of a system and the security of the data\
        \ processed and managed by that system."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.7
      description: "Virtualisation adds layers of technology and can combine many,\
        \ traditionally discrete and physically separate components, into a single\
        \ physical system. \_This consolidation invariably creates greater impact\
        \ if faults occur or the system is compromised. \_Virtual systems are designed\
        \ to be dynamic and to facilitate the movement and sharing of data. This characteristic\
        \ is also a prominent attack vector and can make the enforcement and maintenance\
        \ of security boundaries much more complex."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      ref_id: 22.2.8
      description: Virtualisation is susceptible to the same threats and vulnerabilities
        as traditional ICT assets but traditional security offers limited visibility
        of virtualised environments where the assets configurations and security postures
        are constantly changing. Incidents in virtualised environments can rapidly
        escalate across multiple services, applications and data sets, causing significant
        damage and making recovery complex.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      description: Virtualisation risks
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2:1
      ref_id: 22.2.9
      description: 'Virtualisation risks can be considered in four categories:

        Risks directly related to virtualisation technologies;

        Systems architecture; implementation and management;

        The usage and business models; and

        Generic technology risks.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2
      description: Mitigations
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:2:2
      ref_id: 22.2.10
      description: 'The controls described elsewhere in this manual deal with generic
        technology risks. Important steps in risk mitigation for virtual environments
        include:

        Identify and accurately characterise all deployed virtualisation and security
        measures beyond built-in hypervisor controls on VMs.

        Comparing security controls against known threats and industry standards to
        determine gaps and select appropriate controls.

        Identify and implement anti-malware tools, intrusion prevention and detection,
        active vulnerability scanning and systems security management and reporting
        tools.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:3
      ref_id: 22.2.11
      description: "Further references can be found at:\n\n\nReference\_\nTitle\n\n\
        Publisher\n\n\nSource\n\n\n\n\nNIST\_Special Publication\_800-125, January\
        \ 2011\n\n\nGuide to Security for Full Virtualisation Technologies\n\n\nNIST\n\
        \n\nSP 800-125, Guide to Security for Full Virtualization Technologies | CSRC\
        \ (nist.gov)\n\n\n\n\_\n\nThe Security Technical Implementation Guides,\n\n\
        \nDefense Information Systems Agency,\n\n\nSecurity Technical Implementation\
        \ Guides (STIGs) \u2013 DoD Cyber Exchange\n\n\n\n\_\n\nVirtualization Security\
        \ Checklist\n\n\nISACA\n\nVirtualization Security Checklist - PDF Free Download\
        \ (docplayer.net)\n\n\n\_\n\nGuidelines for System Hardening\_\n\n\nACSC\n\
        \n\nGuidelines for System Hardening | Cyber.gov.au\n\n\n\n\_\n\nVirtual Machine\
        \ Security Guidelines\n\n\nThe Center for Internet Security\n\n\nCIS Benchmarks\
        \ (cisecurity.org)\n\n\n\n\_\n\nSoftware-Defined Networking (SDN) Definition\n\
        \n\nOpen Networking Foundation\n\n\nSoftware-Defined Networking (SDN) Definition\
        \ - Open Networking Foundation\n\n\n\n\_\n\nNetwork segmentation and segregation\n\
        \n\nASD\n\n\nImplementing Network Segmentation and Segregation | Cyber.gov.au\n\
        \n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      description: Functional segregation between servers
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.R.01
      description: "Agencies may implement segregation through the use of techniques\
        \ to restrict a process to a limited portion of the file system, but this\
        \ is often less effective. \_Virtualisation technology MUST be carefully architected\
        \ to avoid cascade failures."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.R.02
      description: The key element in separating security domains of differing classifications
        is physical separation. Current virtualisation technology cannot guarantee
        separation.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.R.03
      description: The use of virtualisation technology within a security domain is
        a recognised means of efficiently architecting a system.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.C.01
      name: 'Control -  All Classifications - Must Not [CID: 4877]'
      description: Virtualisation technology MUST NOT be used for functional segregation
        between servers of different classifications.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.C.02
      name: 'Control -  Secret, Top Secret, Confidential - Must Not [CID: 4878]'
      description: Virtualisation technology MUST NOT be used for functional segregation
        between servers in different security domains at the same classification.
      implementation_groups:
      - Secret - MUST NOT
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.C.03
      name: 'Control -  All Classifications - Should [CID: 4879]'
      description: 'Agencies SHOULD ensure that functional segregation between servers
        is achieved by:

        physically, using single dedicated machines for each function; or

        using virtualisation technology to create separate virtual machines for each
        function within the same security domain.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.12.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:1
      ref_id: 22.2.12.C.04
      name: 'Control -  All Classifications - Should Not [CID: 4880]'
      description: Virtualisation technology SHOULD NOT be used for functional segregation
        between servers in different security domains at the same classification.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      description: Risk Management
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:2
      ref_id: 22.2.13.R.01
      description: Where virtualisation technologies are to be used, risk identification,
        assessment and management are important in order to identify virtualisation
        specific risks, threats and treatments.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:2
      ref_id: 22.2.13.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4883]'
      description: Agencies MUST undertake a virtualisation specific risk assessment
        in order to identify risks, related risk treatments and controls.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:2
      ref_id: 22.2.13.C.02
      name: 'Control -  All Classifications - Should [CID: 4884]'
      description: Agencies SHOULD undertake a virtualisation specific risk assessment
        in order to identify risks and related risk treatments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      description: Systems Architecture
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.R.01
      description: It is important to include virtualisation specific concepts, constraints,
        mitigations and controls in the design of systems architectures that propose
        using virtualisation technologies, in order to gain maximum advantage from
        the use of these technologies and to ensure security of systems and data is
        maintained.
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.R.02
      description: "Virtual environments enable a small number of technical specialists\
        \ to cover a wide range of activities such as network, security, storage and\
        \ application management. \_Such activities are usually undertaken as discrete\
        \ activities by a number of individuals in a physical environment. \_To remain\
        \ secure and correctly and safely share resources, VMs must be designed following\
        \ the principles of separation and segregation through the establishment of\
        \ trust zones."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.R.03
      description: "Software-defined networking (SDN) is an approach to networking\
        \ in which control is decoupled from hardware and managed by a separate application\
        \ described as a controller. \_SDNs are intended to provide flexibility by\
        \ enabling network engineers and administrators to respond to rapidly changing\
        \ business requirements. \_Separation and segregation principles also apply\
        \ to SDNs."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.R.04
      description: "In addition to segregation of key elements, VM security can be\
        \ strengthened through functional segregation. \_For example, the creation\
        \ of separate security zones for desktops and servers with the objective of\
        \ minimising intersection points."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.r.05
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.R.05
      description: "Poor control over VM deployments can lead to breaches where unauthorised\
        \ communication and data exchange can take place between VMs. \_This can create\
        \ opportunity for attackers to gain access to multiple VMs and the host system."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4891]'
      description: Agencies MUST architect virtualised systems and environments to
        enforce the principles of separation and segregation of key elements of the
        system using trust zones or security domains.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.02
      name: 'Control -  Secret, Confidential, Top Secret - Must Not [CID: 4892]'
      description: Agencies MUST NOT permit the sharing of files or other operating
        system components between host and guest operating systems.
      implementation_groups:
      - Secret - MUST NOT
      - Confidential - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.03
      name: 'Control -  All Classifications - Should [CID: 4893]'
      description: Agencies SHOULD architect virtualised systems and environments
        to enforce the principles of separation and segregation of key elements of
        the system using trust zones.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.04
      name: 'Control -  All Classifications - Should [CID: 4894]'
      description: Agencies SHOULD design virtualised systems and environments to
        enable functional segregation within a security domain.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.05
      name: 'Control -  All Classifications - Should [CID: 4895]'
      description: Agencies SHOULD harden the host operating systems following an
        agency or other approved hardening guide.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.06
      name: 'Control -  All Classifications - Should [CID: 4896]'
      description: Agencies SHOULD separate production from test or development virtual
        environments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.14.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:3
      ref_id: 22.2.14.C.07
      name: 'Control -  All Classifications - Should Not [CID: 4897]'
      description: Agencies SHOULD NOT permit the sharing of files or other operating
        system components between host and guest operating systems.
      implementation_groups:
      - All Classifications - SHOULD NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      description: Systems Management
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.R.01
      description: "VMs are easy to deploy, often without formal policies or controls\
        \ to manage the creation, management and decommissioning of VMs. \_This is\
        \ sometimes described as \u201CVM sprawl\u201D, which is the unplanned proliferation\
        \ of VMs. \_Attackers can take advantage of poorly managed and monitored resources.\
        \ \_More deployments also mean more failure points, so VM sprawl can create\
        \ operational difficulties even if no malicious activity is involved."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.R.02
      description: "A related difficulty occurs with unsecured VM migration when a\
        \ VM is migrated to a new host, and security policies and configuration are\
        \ not updated. \_VMs may also be migrated to other physical servers with little\
        \ or no indication to users that a migration has occurred. \_Unsecured migration\
        \ can introduce vulnerabilities through poor configuration and incomplete\
        \ security and operational monitoring."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.R.03
      description: "Denial of service attacks can be designed specifically to exploit\
        \ virtual environments. \_These attacks range from traffic flooding to the\
        \ exploit of the virtual environment host\u2019s own resources."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.R.04
      description: "The ability to monitor VM backbone network traffic is vital to\
        \ maintain security and operations. \_Conventional methods for monitoring\
        \ network traffic are generally not effective because the traffic is largely\
        \ contained and controlled within the virtual environment. Careful selection\
        \ and implementation of hypervisors will ensure effective monitoring tools\
        \ are enabled, tested and monitored."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.01
      name: 'Control -  Top Secret, Secret, Confidential - Must [CID: 4903]'
      description: Agencies MUST ensure a VM migration policy and related SOPs are
        implemented.
      implementation_groups:
      - Top Secret - MUST
      - Secret - MUST
      - Confidential - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.02
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4904]'
      description: Agencies MUST implement controls to prohibit unauthorised VM migrations
        within a virtual environment or between physical environments.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.03
      name: 'Control -  Confidential, Top Secret, Secret - Must [CID: 4905]'
      description: Agencies MUST implement controls to safely decommission VMs when
        no longer required, including elimination of images, snapshots, storage, backup,
        archives and any other residual data.
      implementation_groups:
      - Confidential - MUST
      - Top Secret - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.04
      name: 'Control -  All Classifications - Should [CID: 4906]'
      description: Agencies SHOULD ensure a VM migration policy and related SOPs are
        implemented.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.05
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.05
      name: 'Control -  All Classifications - Should [CID: 4907]'
      description: Agencies SHOULD implement controls to prohibit unauthorised VM
        migrations within a virtual environment or between physical environments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.06
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.06
      name: 'Control -  All Classifications - Should [CID: 4908]'
      description: Agencies SHOULD implement controls to safely decommission VMs when
        no longer required.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.15.c.07
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:4
      ref_id: 22.2.15.C.07
      name: 'Control -  All Classifications - Should [CID: 4909]'
      description: 'Agencies SHOULD implement security and operational management
        and monitoring tools which include the following minimum capabilities:

        Identify VMs when initiated;

        Validate integrity of files prior to installation;

        Scan new VMs for vulnerabilities and misconfigurations;

        Load only minimum operating system components and services;

        Set resource usage limits;

        Establish connections to peripherals only as required;

        Ensure host and guest time synchronisation;

        Detect snapshot rollbacks and scans after restores;

        Track asset migration; and

        Monitor the security posture of migrated assets.

        '
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4
      description: Authentication and Access
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.R.01
      description: "VM sprawl can compromise authentication and access procedures,\
        \ identity management, and system logging. \_This can be complicated with\
        \ the use of customer-facing interfaces, such as websites."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.R.02
      description: "Host and guest interactions and their system vulnerabilities can\
        \ magnify virtual system vulnerabilities. \_The co-hosting and multi-tenancy\
        \ nature of virtual systems and the existence of multiple data sets can make\
        \ a serious attack on a virtual environment particularly damaging."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.R.03
      description: "A guest OS can avoid or ignore its VM encapsulation to interact\
        \ directly with the hypervisor either as a direct attack or through poor design,\
        \ configuration and control. \_This can give the attacker access to all VMs\
        \ in the virtual environment and potentially, the host machine. \_Described\
        \ as a \u201CVM escape\u201D, it is considered to be one of the most serious\
        \ threats to virtual systems."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.r.04
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.R.04
      description: "Hyperjacking is a form of attack that takes direct control of\
        \ the hypervisor in order to gain access to the hosted VMs and data. \_This\
        \ attack typically requires direct access to the hypervisor. \_While technically\
        \ challenging, hyperjacking is considered a real-world threat."
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.C.01
      name: 'Control -  All Classifications - Must [CID: 4915]'
      description: Agencies MUST maintain strong physical security and physical access
        controls.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.C.02
      name: 'Control -  All Classifications - Must [CID: 4916]'
      description: Agencies MUST maintain strong authentication and access controls.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.2.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.2:4:5
      ref_id: 22.2.16.C.03
      name: 'Control -  All Classifications - Should [CID: 4917]'
      description: Agencies SHOULD maintain strong data validation checks.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:22.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:22
      ref_id: '22.3'
      name: Virtual Local Area Networks
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:1
      ref_id: 22.3.1
      description: Virtual local area networks (VLANs) are deployed in a secure manner
        that does not compromise the security of information and systems.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:1
      ref_id: 22.3.2
      description: This section covers information relating to the use of VLANs within
        agency networks.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2
      description: Multiprotocol Label Switching
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:2
      ref_id: 22.3.3
      description: For the purposes of this section Multiprotocol Label Switching
        (MPLS) is considered to be equivalent to VLANs and is subject to the same
        controls.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2
      description: Exceptions for connectivity
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:3
      ref_id: 22.3.4
      description: A single network, managed in accordance with a single SecPlan,
        for which some functional separation is needed for administrative or similar
        reasons, can use VLANs to achieve that functional separation.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:3
      ref_id: 22.3.5
      description: "VLANs can also be used to separate VTC and IPT traffic from data\
        \ traffic at the same classification (See Section 18.3 \u2013 Video and Telephony\
        \ Conferencing and Internet Protocol Telephony)."
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2
      description: Software Defined Networking (SDN)
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:4
      ref_id: 22.3.6
      description: "Software-defined networking (SDN) is an approach to networking\
        \ in which control is decoupled from hardware and managed by a separate application\
        \ described as a controller. \_SDNs are intended to provide flexibility by\
        \ enabling network engineers and administrators to respond to rapidly changing\
        \ business requirements."
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:2:4
      ref_id: 22.3.7
      description: "Separation and Segregation principles also apply to SDNs. \_Refer\
        \ to Section 22.2 \u2013 Virtualisation."
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:3
      ref_id: 22.3.8
      description: "Further references can be found at:\n\n\n\nReference\_\n\n\nTitle\n\
        \n\nPublisher\n\n\nSource\n\n\n\nIEEE 802.1Q-2011\n\nIEEE Standard for Local\
        \ and Metropolitan area networks \u2013 Media Access Control (MAC) Bridges,\
        \ and Virtual Bridged Local Area Networks.\n\n\nInstitute of Electrical and\
        \ Electronics Engineers (IEEE)\n\nIEEE SA - The IEEE Standards Association\
        \ - Home\n\n\n\_\n\nInter-Switch Link and IEEE 802.1Q Frame Format\n\n\nCISCO\n\
        \n\nInter-Switch Link and IEEE 802.1Q Frame Format - Cisco\n\n\n\n\_\n\nDynamic\
        \ Trunking Protocol (DTP)\n\n\nCISCO\n\n\nVirtual LANs VLAN Trunking Protocol\
        \ (VLANs VTP) - Cisco\n\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4
      description: Using VLANs
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      ref_id: 22.3.9.R.01
      description: "Limiting the sharing of a common (physical or virtual) switch\
        \ between VLANs of differing classifications reduces the chance of data leaks\
        \ that could occur due to VLAN vulnerabilities. \_Furthermore, disabling trunking\
        \ on physical switches that carry VLANs of differing security domains will\
        \ reduce the risk of data leakage across the VLANs. \_The principles of separation\
        \ and segregation must be applied to all network designs and architectures."
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      ref_id: 22.3.9.C.01
      name: 'Control -  All Classifications - Must [CID: 4942]'
      description: The principles of separation and segregation MUST be applied to
        the design and architecture of VLANs.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      ref_id: 22.3.9.C.02
      name: 'Control -  Confidential, Secret, Top Secret - Must Not [CID: 4943]'
      description: Agencies MUST NOT use VLANs between classified networks and any
        other network of a lower classification.
      implementation_groups:
      - Confidential - MUST NOT
      - Secret - MUST NOT
      - Top Secret - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      ref_id: 22.3.9.C.03
      name: 'Control -  All Classifications - Must Not [CID: 4944]'
      description: Agencies MUST NOT use VLANs between any classified network and
        any unclassified network.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.9.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:1
      ref_id: 22.3.9.C.04
      name: 'Control -  All Classifications - Must Not [CID: 4945]'
      description: VLAN trunking MUST NOT be used on switches managing VLANs of differing
        security domains.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:4:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4
      description: Configuration and administration
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:2
      ref_id: 22.3.10.R.01
      description: When administrative access is limited to originating from the highest
        classified network on a switch, the security risk of a data spill is reduced.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:2
      ref_id: 22.3.10.C.01
      name: 'Control -  All Classifications - Must [CID: 4948]'
      description: Administrative access MUST be permitted only from the most trusted
        network.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.3:4:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4
      description: Disabling unused ports
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:3
      ref_id: 22.3.11.R.01
      description: Disabling unused ports on a switch will reduce the opportunity
        for direct or indirect attacks on systems.
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:3
      ref_id: 22.3.11.C.01
      name: 'Control -  Top Secret, Confidential, Secret - Must [CID: 4951]'
      description: Unused ports on the switches MUST be disabled.
      implementation_groups:
      - Top Secret - MUST
      - Confidential - MUST
      - Secret - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:22.3.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:22.3:4:3
      ref_id: 22.3.11.C.02
      name: 'Control -  All Classifications - Should [CID: 4952]'
      description: Unused ports on the switches SHOULD be disabled.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23
      assessable: false
      depth: 1
      ref_id: '23'
      name: Public Cloud Security
    - urn: urn:defend:risk:req_node:nzism-v3:23.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:23
      ref_id: '23.1'
      name: Public Cloud Security Concepts
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:1
      ref_id: 23.1.1
      description: Agencies understand key concepts and implement controls related
        to securing their use of public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:1
      ref_id: 23.1.2
      description: This section covers information about the key security concepts
        and architecture patterns related to public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:1
      ref_id: 23.1.3
      description: Cloud technologies require a different approach to the delivery
        of ICT services, and this extends to the way information security controls
        are implemented for cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:1
      ref_id: 23.1.4
      description: "Public cloud security builds on the application of Zero Trust\
        \ concepts and principles.\_ Zero Trust is the recommended approach to ICT\
        \ system security, especially when using public cloud services."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:1
      ref_id: 23.1.5
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\nSection 2.3 \u2013 Using cloud services\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Mandates, directives and requirements
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.6
      description: "In August 2013, the government introduced their approach to cloud\
        \ computing, establishing a \u2018cloud first\u2019 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]."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.7
      description: "Under the \u2018cloud first\u2019 policy public service agencies\
        \ are expected to adopt approved cloud services either when faced with new\
        \ procurements, or an upcoming contract extension decision."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.8
      description: In July 2016, Cabinet subsequently agreed that agencies can also
        use public cloud to deliver office productivity services, provided they comply
        with security guidance issued by the GCDO and the GCSB [CAB-16-MIN-0316].
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.9
      description: "Agencies are required to identify and manage risks associated\
        \ with the use of cloud services through the GCDO Cloud Risk Assessment process\
        \ [CAB Min (13) 37/6B].\_ More information regarding cloud specific risk management\
        \ can be found at digital.govt.nz."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.10
      description: "Agencies are also required to certify and accredit their ICT systems\
        \ and services, including those delivered through cloud technologies. \_Chapter\
        \ 4 of this manual describes the certification and accreditation processes\
        \ and these also apply to cloud services."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:2
      ref_id: 23.1.11
      description: CAB Min (13) 37/6B directs that no data classified above RESTRICTED
        may be held in a public cloud.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Background
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:3
      ref_id: 23.1.12
      description: 'Adopting or using cloud services introduces new approaches to:

        Workload descriptions and management.

        Procurement and contract management.

        Virtualisation and the separation of resources using hyperscale technologies
        and strict control-plane/data-plane, tenant/tenant and tenant/provider segregation.

        Key information security services used to control the information boundary:
        using identity, directories and authorisation, instead of networks, gateways
        and firewalls.

        The approach to and selection of critical security services such as intrusion
        detection, key management, encryption, endpoint controls, privileged and user
        access management and authentication (including MFA).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Public cloud use within other cloud deployment models
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:4
      ref_id: 23.1.13
      description: "All the standard cloud deployment models described by ISO and\
        \ NIST could incorporate elements of public cloud, including:\nPrivate cloud,\
        \ hosted on third party public cloud infrastructure.\nMulti cloud, combining\
        \ elements of different vendors\u2019 public cloud services.\nHybrid cloud,\
        \ combining elements of private and public cloud services.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:4
      ref_id: 23.1.14
      description: "The focus of this chapter is on security concerns related to the\
        \ use of public cloud technologies irrespective of the cloud service\u2019\
        s primary deployment model.\_ This is to avoid these concerns being considered\
        \ out of scope due to inconsistencies in definitions being applied."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Characteristics of public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:5
      ref_id: 23.1.15
      description: "There is not a single accepted definition of exactly what constitutes\
        \ public cloud.\_ Typically public cloud refers to cloud services that are\
        \ generally available for anyone to use and are accessed through the internet."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.16
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:5
      ref_id: 23.1.16
      description: "For the avoidance of doubt, information in this chapter relates\
        \ to public cloud services where:\nThe infrastructure used to deliver the\
        \ public cloud services is not owned by the agency (i.e., server hardware,\
        \ network devices).\nThe cloud infrastructure is shared between many customers\
        \ (\u2018multi-tenanted\u2019) and is accessible from the internet.\nService\
        \ provisioning is automated and customer managed.\nThere is strict isolation\
        \ between customer instances, and between customer instances and the service\
        \ provider\u2019s management plane.\nCustomer data is isolated and controls\
        \ are in place that strictly manage access by the service provider.\nThere\
        \ is a defined shared responsibility matrix for ensuring the services meet\
        \ customer security requirements.\_ It should be noted that regardless of\
        \ the model, agencies will retain ultimate accountability for the security\
        \ of their information.\nThere is limited flexibility in how the services\
        \ are configured, and in at least some aspects there may be no flexibility\
        \ to customise the service.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Responsibility for security in public cloud is necessarily shared
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.17
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      ref_id: 23.1.17
      description: Agencies share responsibility for the security of their public
        cloud environments with their cloud service providers.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.18
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      ref_id: 23.1.18
      description: "Due to differences in how cloud providers operate, there is no\
        \ single model that can fully describe the boundary between agency security\
        \ responsibilities and those of the cloud service provider.\_ Cloud service\
        \ provider responsibilities may even vary between their different service\
        \ offerings."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.19
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      ref_id: 23.1.19
      description: "The following is an example of how responsibilities for security\
        \ in a cloud service could be shared, although every service is different:\_\
        \n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.20
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      ref_id: 23.1.20
      description: "It is essential that agencies understand where the cloud service\
        \ provider\u2019s responsibilities end and their own begin for each cloud\
        \ service they consume, so there is no gap left unaddressed."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.21
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:6
      ref_id: 23.1.21
      description: "Agency security processes, such as certification and accreditation\
        \ or incident response, must be revised to ensure compatibility with their\
        \ cloud service provider\u2019s responsibilities."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Risks and benefits associated with public cloud services
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.22
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:7
      ref_id: 23.1.22
      description: 'Public cloud services can provide agencies with significant security
        benefits when adopted in a controlled and well understood manner, including:

        Pervasive identity and authorisation model.

        Consistent, software-orchestrated environments running immutable workloads.

        Automated response to security incidents or misconfigurations.

        Fine-grained access control.

        Scalable logging, monitoring and audit.

        Improved levels of baseline security.

        Enhanced visibility of security state.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.23
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:7
      ref_id: 23.1.23
      description: The use of public cloud services introduces additional specific
        risks that require careful control selection to manage.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.24
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:7
      ref_id: 23.1.24
      description: "The following examples highlight key areas of public cloud-specific\
        \ risks that need to be understood and managed:\nTraditional barriers limiting\
        \ the movement of agency data across legal jurisdictions can be significantly\
        \ reduced through the use of cloud services.\nCloud service provider self-service\
        \ tools can be subject to manipulation impacting agency infrastructure.\n\
        Agency systems delivered using cloud services are typically accessible from\
        \ the internet, including management interfaces, unless controls are put in\
        \ place.\nAgency data is stored on shared platforms, in multiple locations,\
        \ with agencies ultimately being accountable for ensuring information is secured.\n\
        Cloud environments present large, high value targets, where single exploits\
        \ can impact large numbers of customers.\nCloud services are easier to consume\
        \ without needing to involve common governance processes, such as change control,\
        \ increasing the risk of using shadow services without adequate information\
        \ security controls in place.\nOn-demand services, coupled with rapid-elasticity,\
        \ can lead to inappropriate use of agency cloud environments.\_ Agencies are\
        \ responsible for tracking billing and usage metrics and ensuring appropriate\
        \ controls are in place to manage fiscal constraints.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.25
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:7
      ref_id: 23.1.25
      description: "The GCDO Cloud Risk Assessment process is intended to help agencies\
        \ understand these, and other, risks associated with the use of public cloud.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Public cloud impacts on security control selection
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.26
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:8
      ref_id: 23.1.26
      description: 'Depending on whether responsibility for implementing security
        controls rests on the cloud service provider or the agency, enterprise security
        controls or standards may not be possible to implement uniformly in public
        cloud services, for example:

        Agents used to manage configuration or collect system telemetry may not be
        able to be deployed across public cloud services.

        Log messages may not be able to be centrally collected, or log information
        tailored to agency requirements, from public cloud services.

        Network information, such as packet captures, may not be feasible to collect.

        Traditional security devices, such as firewalls and proxy servers, may not
        be able to be deployed.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Security boundaries in cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.27
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.27
      description: "Security boundaries exist to identify where differing security\
        \ requirements and policies need to be applied to information and infrastructure\
        \ assets operated in support of agency outcomes.\_ Well defined security boundaries\
        \ are a key construct in support of:\nProtecting environments by providing\
        \ control enforcement points to manage information flows between internal\
        \ systems and externally to the environment.\nProviding containment points\
        \ where the impact of incidents can be limited in scope, which also aids in\
        \ recovery.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.28
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.28
      description: "Well defined security boundaries can ensure that information is\
        \ accessible for authorised users and that restrictions do not limit those\
        \ users\u2019 access to information to which they are entitled."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.29
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.29
      description: "There are three key constructs used to describe security policy\
        \ boundaries in the NZISM.\_ These are classification, security domain and\
        \ trust zone. \_Information and systems are subject to the combined requirements\
        \ described in these policies.\_\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.30
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.30
      description: "In public cloud, the classified system refers to the highest level\
        \ of classified information that can be stored, or processed, by systems in\
        \ the agency\u2019s cloud environment.\_ The highest level of classified information\
        \ the classified system can store or process is based on the lower of:\nThe\
        \ highest classification the system is accredited to operate at, AND\nThe\
        \ lowest clearance level authorised users of the system hold.\nThe highest\
        \ classification of information a classified system in public cloud can be\
        \ accredited to operate with is RESTRICTED."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.31
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.31
      description: Minimum security requirements based on classification are described
        in the Protective Security Requirements and the NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.32
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.32
      description: "A security domain in public cloud can be categorised as a group\
        \ of trust zones operating under a common set of security requirements and\
        \ policies.\_ These security requirements and policies are formed through\
        \ a combination of:\nMinimum security control requirements from the PSR and\
        \ NZISM, determined by the classification.\nSecurity control requirements\
        \ to manage the unique threat environment presented by the use of the public\
        \ cloud services.\nAdditional security control requirements to manage specific\
        \ risks identified through risk assessments.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.33
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.33
      description: 'Examples of the unique threat environment related to the use of
        public cloud services include:

        Access to the underlying infrastructure by the public cloud service provider
        systems and staff.

        Differing relative importance of security controls, such as identity, and
        the addition of different types of privileged access such as for managing
        service subscriptions and billing (including terminating services) that can
        have immediate effect.

        Geographic locations where the public cloud services are being delivered from.

        Security controls being defined and implemented by the public cloud service
        provider.

        The ease of extending access to third parties, including third party applications,
        through in-built federation and directory integration services in public cloud.

        The ease of shifting data between services and geographic locations in public
        cloud environments compared to on-premise systems.

        The control and visibility of the security state of the underlying infrastructure
        platforms, including the physical hosting environment.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.34
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.34
      description: "Defining trust zones provides a mechanism to differentiate security\
        \ controls used to manage access to information and services within an agency\u2019\
        s public cloud environment."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.35
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.35
      description: "In the public cloud environment, trust zones represent combinations\
        \ of public cloud services (made up of user, system and data objects) that\
        \ are authorised to interact with each other and are protected by a common\
        \ set of security capabilities. \_The security controls associated with these\
        \ security capabilities are applied at policy enforcement points:\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.36
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.36
      description: "Traditional policy enforcement point implementations based on\
        \ location-based network perimeter security controls can be difficult to successfully\
        \ replicate in public cloud environments.\_"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.37
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:9
      ref_id: 23.1.37
      description: In public cloud, access control policy enforcement points are tied
        to authorised combinations of user, system, and data object identities.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:10
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Security boundaries between cloud providers and customers
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.38
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:10
      ref_id: 23.1.38
      description: A significant difference between public cloud and traditional computing
        is the additional set of administration services used by the cloud service
        provider to manage the overall cloud platform.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.39
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:10
      ref_id: 23.1.39
      description: "Some of these administration services are exposed to tenants to\
        \ facilitate tenancy management, such as maintaining customer contact and\
        \ billing details or creating and deleting top level tenant resources.\_ In\
        \ some circumstances, third parties can be provided access to perform these\
        \ actions on behalf of tenants."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.40
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:10
      ref_id: 23.1.40
      description: "Due to the significant impact from a compromise, access to these\
        \ services and the associated privileged identities requires a high degree\
        \ of trust in those responsible.\_ Ensuring separation of duties (i.e., multi-user\
        \ authorisation, see section 16.7.19) in this area is highly recommended.\
        \ \n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:11
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Virtualisation and multi-tenant security in public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.41
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:11
      ref_id: 23.1.41
      description: Within a public cloud environment adequately architected, designed,
        and implemented virtualisation technologies can be used to provide isolation
        between tenants and separation between security domains.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.42
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:11
      ref_id: 23.1.42
      description: Public cloud service providers that are designed to use technology
        to implement strict isolation between tenant environments, and separate customer
        management from platform management, are more likely to provide adequately
        architected security controls to support security domain separation in a virtualised
        environment.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.43
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:11
      ref_id: 23.1.43
      description: "Examples of adequately architected security controls that support\
        \ tenant isolation in public cloud services can include:\nZero touch configuration\
        \ of infrastructure using well defined infrastructure as code pipelines.\n\
        Separation of the cloud provider platform\u2019s administrative control interfaces\
        \ from customer accessible tenant management services.\nAn inability for cloud\
        \ provider staff to access customer data except through customer authorised\
        \ access channels (i.e., the platform does not provide \u2018back door\u2019\
        \ access to customer data).\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.44
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:11
      ref_id: 23.1.44
      description: "At a minimum, a security domain control boundary exists between\
        \ components where different parties undertake configuration and management\
        \ responsibilities. \n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Collaboration between agencies in public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.45
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.45
      description: Public cloud services, due to their multi-tenant design and support
        for integration to multiple identity providers, can provide a convenient platform
        for collaboration systems between agencies.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.46
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.46
      description: "It is usually not possible, nor desirable, to implement traditional\
        \ DMZ or Landing Zone network architectures to facilitate third party access\
        \ to an agency\u2019s public cloud services where collaboration is the goal."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.47
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.47
      description: "For public cloud collaboration systems, it is often more practical\
        \ to grant access to individual third party identities, or to federate (i.e.,\
        \ trust) the third party\u2019s identity service to perform authentication\
        \ on the collaboration system\u2019s behalf."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.48
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.48
      description: When multiple identity systems are used to control access to shared
        public cloud collaboration systems, the shared system operates to a common
        policy that covers all of the participating agencies security requirements.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.49
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.49
      description: "The common policy reflects a different security domain from each\
        \ of the participating agencies, providing the equivalence of a DMZ environment\
        \ in public cloud. \n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.50
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:12
      ref_id: 23.1.50
      description: When systems are operating in separate security domains, agencies
        must follow the guidance regarding Information transfer and release in public
        cloud described in this chapter of the NZISM.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:2:13
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2
      description: Information transfer and release in public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.51
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:2:13
      ref_id: 23.1.51
      description: "Information being released from trust zones, destined either internally\
        \ or externally to the security domain, must always follow the requirements\
        \ for Data management described in Chapter 20 and Gateway security described\
        \ in Chapter 19 of the NZISM.\_ This includes where data is being backed up\
        \ or replicated to systems operating in a different trust zone."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.52
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:3
      ref_id: 23.1.52
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\nCAB Min (13) 37/6B\n\_Cloud computing risk and assurance framework\
        \ (CAB Min (13) 37/6B)\n\_\nCabinet minutes for public cloud services | NZ\
        \ Digital government\n\n\nCAB-16-MIN-0316\n\_Accelerating the adoption of\
        \ public cloud services CAB-16-MIN-0316\_\n\_\n\_\n\n\n\_NIST SP 800-145 (2011)\n\
        \_The NIST definition of cloud computing\_\n\_NIST\nSP 800-145, The NIST Definition\
        \ of Cloud Computing | CSRC\n\n\nNIST SP 500-293 (2014)\n\_US Government cloud\
        \ computing technology roadmap\n\_NIST\nUS Government Cloud Computing Technology\
        \ Roadmap Volume I: High-Priority Requirements to Further USG Agency Cloud\
        \ Computing Adoption; and Volume II: Useful Information for Cloud Adopters\
        \ | NIST\n\n\nNIST SP 500-291 (2011)\n\_NIST cloud computing standards roadmap\n\
        \_NIST\nNIST-SP 500-291, NIST Cloud Computing Standards Roadmap | NIST\n\n\
        \nNIST SP 800-144 (2011)\n\_Guidelines on security and privacy in public cloud\
        \ computing\_\n\_NIST\nGuidelines on Security and Privacy in Public Cloud\
        \ Computing | NIST\n\n\nNIST SP-800-210 (2020)\n\_General access control guidance\
        \ for cloud systems\_\n\_NIST\nGeneral Access Control Guidance for Cloud Systems\
        \ | NIST\n\n\nISO/IEC 17789:2014\n\_Information technology -- Cloud computing\
        \ -- Reference architecture\_\n\_ISO/IEC\nISO - ISO/IEC 17789:2014 - Information\
        \ technology \u2014 Cloud computing \u2014 Reference architecture\n\n\nISO/IEC\
        \ 27017:2015\n\_Information technology \u2014 Security techniques \u2014 Code\
        \ of practice for information security controls based on ISO/IEC 27002 for\
        \ cloud services\n\_ISO/IEC\nISO - ISO/IEC 27017:2015 - Information technology\
        \ \u2014 Security techniques \u2014 Code of practice for information security\
        \ controls based on ISO/IEC 27002 for cloud services\n\n\n\_\n\_CSF Tools\n\
        \_CSF\nWelcome to CSF Tools - CSF Tools\n\n\n\_\nTrusted internet connections\n\
        CISA\nTIC | CISA\n\n\n\_\nCloud security technical reference architecture\n\
        CISA\nCloud Security Technical Reference Architecture | CISA\n\n\n\_\nCloud\
        \ Security Alliance\nCISA\nHome | CSA (cloudsecurityalliance.org)\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.53
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:4
      ref_id: 23.1.53
      description: 'Relevant PSR requirements can be found at:



        Reference

        Title

        Source



        PSR mandatory requirements


        GOV2 - Take a risk-based approach

        GOV5 - Manage risks when working with others

        GOV6 - Manage security incidents

        INFOSEC1 - Understand what you need to protect

        INFOSEC2 - Design your information security

        INFOSEC3 - Validate your security measures

        INFOSEC4 - Keep your security up to date

        Mandatory requirements | Protective Security Requirements



        PSR protocol for information security

        Management protocol for information security

        Management protocol for information security | Protective Security Requirements



        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5
      description: Cloud security boundaries
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.54.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:1
      ref_id: 23.1.54.R.01
      description: "Security boundaries identify the scope of security policy applicability,\
        \ and determine where data management controls will apply.\_ Refer to Chapter\
        \ 20 \u2013 Data Management."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.54.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:1
      ref_id: 23.1.54.C.01
      name: 'Control -  All Classifications - Must [CID: 7349]'
      description: Agencies MUST clearly identify and understand where classification,
        security domain, and trust zone boundaries exist prior to implementation or
        adoption of public cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.54.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:1
      ref_id: 23.1.54.C.02
      name: 'Control -  All Classifications - Must [CID: 7350]'
      description: "Where multiple identity systems under different security policies\
        \ are used to control access to an agency\u2019s instance of a public cloud\
        \ service, the instance MUST be considered to be in a separate security domain\
        \ from services where access control is managed solely by the agency\u2019\
        s identity system."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5
      description: Shared responsibility model
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.55.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:2
      ref_id: 23.1.55.R.01
      description: "The responsibility for the selection, implementation, management,\
        \ and maintenance of controls in public cloud services is shared between the\
        \ provider and the consumer.\_ Precisely where the responsibilities lie depends\
        \ on the provider and the service and deployment models (refer to NIST SP\
        \ 800-145) used in the delivery of the specific public cloud service."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.55.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:2
      ref_id: 23.1.55.C.01
      name: 'Control -  All Classifications - Must [CID: 7353]'
      description: "Agencies MUST clearly identify and understand their cloud service\
        \ provider\u2019s security responsibilities for each service consumed, and\
        \ the aspects of security that the agency is responsible for, prior to implementation\
        \ or adoption of the service."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.55.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:2
      ref_id: 23.1.55.C.02
      name: 'Control -  All Classifications - Should [CID: 7354]'
      description: Agencies SHOULD clearly document the aspects of security they and
        their provider are responsible for.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.55.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:2
      ref_id: 23.1.55.C.03
      name: 'Control -  All Classifications - Should [CID: 7355]'
      description: "Agencies SHOULD review existing security processes to ensure compatibility\
        \ with their cloud service provider\u2019s responsibilities."
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.1:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5
      description: Automation and infrastructure as code
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.56.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:3
      ref_id: 23.1.56.R.01
      description: Tools and APIs that generate code used to configure cloud services
        enable automated deployment and management of resources in a repeatable manner.
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.56.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:3
      ref_id: 23.1.56.R.02
      description: "Infrastructure as code, where resources and their configurations\
        \ are defined in machine-readable code, can drive automated deployment tools\
        \ that support software engineering techniques such as version control, continuous\
        \ integration and deployment, and automated security testing. \_In particular,\
        \ disciplined version control can support the ability to roll back failed\
        \ changes to the \u201Clast known good\u201D configuration as part of agency\
        \ change control processes."
    - urn: urn:defend:risk:req_node:nzism-v3:23.1.56.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.1:5:3
      ref_id: 23.1.56.C.01
      name: 'Control -  All Classifications - Should [CID: 7359]'
      description: Agencies SHOULD deploy and manage their cloud infrastructure using
        automation, version control, and infrastructure as code techniques where these
        are available.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:23
      ref_id: '23.2'
      name: Governance, Risk Assessment & Assurance
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:1
      ref_id: 23.2.1
      description: Agency cloud initiatives follow the risk management, assurance,
        governance, and control requirements in this manual.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:1
      ref_id: 23.2.2
      description: Good governance is required to ensure appropriate mechanisms and
        lines of accountability are in place to understand, assess, document, and
        manage cloud risks. This section describes the requirements for agencies to
        identify, respond to, and manage risks relevant to public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:1
      ref_id: 23.2.3
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\nSection 2.3 \u2013 Using cloud services\nChapter 3 \u2013\
        \ Information security governance \u2013 roles and responsibilities\nChapter\
        \ 4 \u2013 System certification and accreditation\nChapter 5 \u2013 Information\
        \ security documentation\nSection 5.8 \u2013 Independent assurance reports\n\
        Chapter 6 \u2013 Information security monitoring\nChapter 7 \u2013 Information\
        \ security incidents\nChapter 9 \u2013 Personnel security\nChapter 16 \u2013\
        \ Access control and passwords\nChapter 17 \u2013 Cryptography\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      description: Public cloud services
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      ref_id: 23.2.4
      description: 'Cloud computing affects governance, since it either:

        introduces a third party into the process (as in the case of public cloud
        or hosted private cloud); or

        potentially alters internal governance structures (as in the case of self-hosted
        private cloud).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      ref_id: 23.2.5
      description: "The primary issue to remember when governing cloud computing is\
        \ that an organisation can never outsource responsibility for governance,\
        \ even when using external providers. This is always true, cloud or not, but\
        \ is useful to keep in mind when navigating cloud computing\u2019s concept\
        \ of shared responsibility."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      ref_id: 23.2.6
      description: As with any outsourcing arrangement, agencies bear ultimate responsibility
        for identifying and managing these risks even if they rely on their cloud
        service provider to implement mitigating controls.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      ref_id: 23.2.7
      description: "Cloud services that are hosted or managed from outside New Zealand\
        \ pose jurisdictional, data sovereignty, and privacy risks. Even when the\
        \ service is hosted in New Zealand and subject to New Zealand law, an overseas\
        \ provider may also be subject to its home country\u2019s privacy, data access,\
        \ and lawful intercept legislation, which may conflict with New Zealand law."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:2
      ref_id: 23.2.8
      description: "Cloud services that support multiple agencies or All-of-Government\
        \ capabilities also pose governance and risk management challenges that must\
        \ be addressed by establishing privacy, security, and compliance policies\
        \ in order to protect the corporate assets and intellectual property of participating\
        \ organisations\u2019 data."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      description: Obligations and responsibilities
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:3
      ref_id: 23.2.9
      description: "Agencies must be aware of their statutory and regulatory obligations\
        \ to protect Official, Classified and personal information and data.\_ Any\
        \ move to using cloud services cannot allow compromise of these statutory\
        \ obligations."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      description: Cloud contracts
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:4
      ref_id: 23.2.10
      description: "Cloud contracts should consider data stewardship, data sovereignty,\
        \ jurisdiction, storage and access, including any backups.\_ It remains, however,\
        \ the responsibility of individual agencies to ensure their legislative and\
        \ regulatory responsibilities for data stewardship are met."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:4
      ref_id: 23.2.11
      description: As with any outsourcing arrangement, use of cloud services carries
        the risk of the provider going out of business or otherwise being unable to
        provide contracted services to the consuming agency. This is a commercial
        risk that technical security controls cannot address, but one agencies need
        to consider as part of their due diligence.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:4
      ref_id: 23.2.12
      description: It is essential that appropriate legal advice is taken before any
        cloud contracts are finalised.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:2:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2
      description: Regular assurance checks
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:2:5
      ref_id: 23.2.13
      description: "Changes made to a cloud tenancy may have an adverse impact on\
        \ the security posture of an agency\u2019s cloud service configuration. Usually,\
        \ in such circumstances (e.g., if the change was initiated by the agency on-site)\
        \ this may trigger the commencement of the certification and accreditation\
        \ process. In addition, changes would usually be subject to approval, review,\
        \ and testing, as part of an agency\u2019s IT change control process. However,\
        \ this may not be the case in a cloud environment, as platform changes are\
        \ made by the cloud service provider and may occur with minimal or no notice\
        \ (see section 5.8 \u2013 Independent assurance reports)."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.14
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:3
      ref_id: 23.2.14
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\nCloud computing security for tenants\nAustralian Cyber Security\
        \ Centre (ACSC)\nCloud Computing Security for Tenants | Cyber.gov.au\n\n\n\
        \_\nCCMv4.0 auditing guidelines\nCSA\nCCMv4.0 Auditing Guidelines | CSA (cloudsecurityalliance.org)\n\
        \n\n\_\nCSA Security Guidance for Critical Areas of Focus in Cloud Computing\n\
        \_CSA\nCSA Security Guidance for Cloud Computing | CSA (cloudsecurityalliance.org)\n\
        \n\n\_\nCloud computing \u2014 information security and privacy considerations\n\
        Digital.govt.nz\nCloud computing information security and privacy considerations\
        \ | NZ Digital government\n\n\n\_\nAbout public cloud services\nDigital.govt.nz\n\
        About public cloud services | NZ Digital government\n\n\n\_\nSecure cloud\
        \ strategy\nAustralian Government\nSecure Cloud Strategy | Digital Transformation\
        \ Agency (dta.gov.au)\n\n\nNIST SP 500-291 (2011)\nNIST cloud computing standards\
        \ roadmap\nNIST\nNIST-SP 500-291, NIST Cloud Computing Standards Roadmap |\
        \ NIST\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.15
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:4
      ref_id: 23.2.15
      description: 'Relevant PSR requirements can be found at:



        Reference

        Title

        Source



        PSR mandatory requirements


        GOV2 - Take a risk-based approach

        GOV5 - Manage risks when working with others

        GOV6 - Manage security incidents

        INFOSEC1 - Understand what you need to protect

        INFOSEC2 - Design your information security

        INFOSEC3 - Validate your security measures

        INFOSEC4 - Keep your security up to date

        Mandatory requirements | Protective Security Requirements



        PSR protocol for information security

        Management protocol for information security

        Management protocol for information security | Protective Security Requirements



        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: Understanding levels of assurance for public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.R.01
      description: Although roles and responsibilities for public cloud services may
        be shared between an agency and the cloud service provider, ultimately an
        agency owns security risks and is responsible for all ICT services their agency
        consumes, including public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.R.02
      description: "It is an agency\u2019s responsibility to ensure that cloud service\
        \ providers have adequate safeguards in place to address security risks specific\
        \ to their public cloud instance."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.R.03
      description: Adoption of public cloud services introduce risks to agency systems
        that need to be identified, assessed, and formally accepted in order to understand
        the appropriate use of public cloud services and select effective controls
        and countermeasures.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.C.01
      name: 'Control -  All Classifications - Must [CID: 7386]'
      description: Agencies MUST update their risk assessment process to account for
        public cloud specific risks, prior to implementation or adoption of public
        cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.C.02
      name: 'Control -  All Classifications - Must [CID: 7387]'
      description: Agencies MUST undertake a cloud specific risk assessment in line
        with the process outlined by the GCDO for each public cloud service, prior
        to implementation or adoption of public cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.C.03
      name: 'Control -  Secret, Top Secret, Confidential - Must Not [CID: 7388]'
      description: Agencies MUST NOT accredit public cloud services for use with data
        classified CONFIDENTIAL, SECRET, or TOP SECRET.
      implementation_groups:
      - Secret - MUST NOT
      - Top Secret - MUST NOT
      - Confidential - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.16.c.04
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:1
      ref_id: 23.2.16.C.04
      name: 'Control -  All Classifications - Must Not [CID: 7389]'
      description: Agencies MUST NOT accredit public cloud services to host, process,
        store, or transmit NZEO endorsed information.
      implementation_groups:
      - All Classifications - MUST NOT
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: System availability
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.17.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:2
      ref_id: 23.2.17.R.01
      description: It is important that connectivity between an organisation and their
        cloud service providers meets requirements for latency and reliability. In
        support of this, an organisation and their cloud service providers should
        discuss any specific network requirements, performance characteristics, or
        planned responses to availability failures, especially when high-availability
        requirements exist.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.17.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:2
      ref_id: 23.2.17.R.02
      description: 'An organisation and their cloud service providers should discuss
        whether dedicated communication links or connections over the internet will
        be used and whether any secondary communications links will provide sufficient
        capacity to meet operational requirements should the primary communication
        link become unavailable. '
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.17.r.03
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:2
      ref_id: 23.2.17.R.03
      description: Feedback should be provided to cloud service providers when performance
        does not meet service level agreement targets. To assist with this, anomaly
        detection can be performed through network telemetry that is integrated into
        security monitoring tools.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.17.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:2
      ref_id: 23.2.17.C.01
      name: 'Control -  All Classifications - Must [CID: 7394]'
      description: Agencies MUST consider risks to the availability of systems and
        information in their design of cloud systems architectures, supporting controls,
        and governance processes prior to implementation or adoption of public cloud
        services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: Regular assurance checks
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:3
      ref_id: 23.2.18.R.01
      description: Cloud service providers should conduct independent assurance activities
        as part of their due diligence and to provide customers with evidence of quality
        service provision and compliance. It is important that such assurance activities
        are undertaken by an assessor with the appropriate expertise to validate the
        existence and performance of security controls.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:3
      ref_id: 23.2.18.C.01
      name: 'Control -  All Classifications - Should [CID: 7397]'
      description: Agencies SHOULD obtain regular assurance checks on cloud service
        providers, ensuring they have been undertaken by a suitably qualified assessor.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: "Cloud service providers \u2013 patching and software maintenance"
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:4
      ref_id: 23.2.19.R.01
      description: Data transmitted, stored, and processed off site presents a risk
        to an organisation. This includes reliance on a cloud service provider to
        not only identify software vulnerabilities, but to apply these in a timely
        manner, as well providing evidence to an agency of this.
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:4
      ref_id: 23.2.19.C.01
      name: 'Control -  All Classifications - Must [CID: 7400]'
      description: Agencies MUST obtain assurance that cloud service providers undertake
        appropriate software and operating system patching and maintenance.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: Assurance around workload isolation on shared infrastructure
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:5
      ref_id: 23.2.20.R.01
      description: "Responsibilities for workload isolation in public cloud are shared\
        \ between the cloud provider and consumer.\_ Workload isolation in a public\
        \ cloud security context ensures compute processes or memory in one virtual\
        \ machine/container are not visible to another tenant, even when they are\
        \ running processes on the same physical hardware."
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.20.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:5
      ref_id: 23.2.20.R.02
      description: 'To mitigate the risk of unauthorised access between resources
        in separate tenancies, it is important that adequately architected security
        controls are built into the design. Examples of adequate security controls
        include zero touch configuration and separation of administrative control
        interfaces. '
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:5
      ref_id: 23.2.20.C.01
      name: 'Control -  All Classifications - Must [CID: 7404]'
      description: Agencies MUST obtain assurance that technical protections exist
        to adequately isolate tenants.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.2:5:6
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5
      description: Use of baseline security templates
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:6
      ref_id: 23.2.21.R.01
      description: "GCSB endorsed NZISM baseline security templates are intended to\
        \ assist agencies in understanding the security posture of their cloud environments.\
        \ They provide a baseline level of security within a cloud environment to\
        \ significantly reduce agency\u2019s assurance activities and focus then on\
        \ moving towards continuous security posture assessments. "
    - urn: urn:defend:risk:req_node:nzism-v3:23.2.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.2:5:6
      ref_id: 23.2.21.C.01
      name: 'Control -  All Classifications - Should [CID: 7407]'
      description: "Agencies SHOULD make use of the GCSB endorsed baseline security\
        \ templates where applicable. \_"
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.3
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:23
      ref_id: '23.3'
      name: Identity Management and Access Control
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:1
      ref_id: 23.3.1
      description: Identities used for public cloud services are managed, protected,
        and consistently used to form a secure basis for controlling access to resources.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:1
      ref_id: 23.3.2
      description: This section is primarily concerned with the management of identities
        used to access or administer public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:1
      ref_id: 23.3.3
      description: Identities that interact with cloud platform management portals
        and application programming interfaces (APIs) to create, view, modify, or
        delete resources are considered privileged users in the context of public
        cloud.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:1
      ref_id: 23.3.4
      description: "Concepts used in this section related to identification management\
        \ include:\nIdentity providers\nRelying parties\nCredentials, \_and identity\
        \ information used in authentication\nPolicy decision points and policy enforcement\
        \ points\nThese concepts are described in ISO/IEC IT Security and Privacy\
        \ framework for identity management (ISO/IEC 24760-1:2019) and framework for\
        \ access management (ISO/IEC 29146:2016)."
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:1
      ref_id: 23.3.5
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\nSection 2.3 \u2013 Using cloud services\nChapter 16 \u2013\
        \ Access control and passwords\nSection 16.2 \u2013 System access and passwords\n\
        Section 16.3 \u2013 Privileged user access\nSection 16.4 \u2013 Privileged\
        \ access management\nSection 16.7 \u2013 Multi-factor authentication\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2
      description: Overview
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:2
      ref_id: 23.3.6
      description: 'Public cloud services introduce new areas of risk associated with
        the management of identity and access, including:

        Separation between identity providers and relying parties, with differing
        standards and capabilities for authentication, assignment of privileges, and
        access provisioning/deprovisioning.

        Ubiquitous access to public cloud services, and in particular cloud administration
        services, from the internet.

        The decoupling of the authentication and authorisation steps as part of access
        control (i.e., separation of the identity provider and the policy decision
        point/policy enforcement point).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:2
      ref_id: 23.3.7
      description: This section highlights controls agencies can use to manage these
        cloud identity and access management risks and move towards a Zero Trust approach
        to information security.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2
      description: Public cloud identity providers
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.8
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:3
      ref_id: 23.3.8
      description: 'There are three models of identity management commonly used with
        public cloud services:

        Cloud accounts based on identities and authentication from other services
        or systems using identity federation (such as SAML V2.0 or OpenID Connect).

        Cloud identities synchronised from an existing identity system.

        Cloud identities directly provisioned in local cloud service identity stores,
        either manually or through automation following a standard specification such
        as the System for Cross-domain Identity Management (SCIM).

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.9
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:3
      ref_id: 23.3.9
      description: Due to the differing standards and capabilities offered by both
        identity providers and relying parties a combination of identity management
        models may be required to support the use of public cloud services.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.10
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:3
      ref_id: 23.3.10
      description: Cloud-based identities may be issued and authenticated by different
        identity providers, each offering their own levels of assurance and receiving
        their own levels of trust from the identity consumer.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.11
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:3
      ref_id: 23.3.11
      description: Identity providers are privileged entities that must prove a chain
        of trust, for example by strong cryptographic signing of authentication responses,
        to prevent a malicious actor tampering with authentication traffic as it passes
        between the provider and the relying party.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:2:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2
      description: Public cloud access policy enforcement
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.12
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:4
      ref_id: 23.3.12
      description: Once an entity is authenticated, access control mechanisms determine
        what authorised actions are able to be performed and what resources can be
        interacted with.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.13
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:4
      ref_id: 23.3.13
      description: "Many cloud based system follow Zero Trust principles for access\
        \ control, with access control determined by a combination of the cloud service\u2019\
        s policy decision points and policy enforcement points."
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.14
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:4
      ref_id: 23.3.14
      description: 'The separation between the authentication and authorisation steps
        introduces the opportunity for unauthorised access to occur, through:

        Misconfigured mapping between attributes asserted by the authentication provider
        and their use by the authorisation system.

        Impersonation of authorised users through mimicking the authentication service
        assertions to the authorisation system.

        Delays between a user being removed from the authentication system and re-authentication
        occurring.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.15
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:2:4
      ref_id: 23.3.15
      description: The use of cloud services provides the opportunity to move from
        purely role-based access control (RBAC) to incorporating more attributes (than
        just role definitions) as part of attribute-based access control decisions
        (ABAC).
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.16
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:3
      ref_id: 23.3.16
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\n\_Identification management\n\_GCDO\n\_Identification management\
        \ | NZ Digital government\n\n\nNIST SP-800-210 (2020)\_\n\_General access\
        \ control guidance for cloud systems\_\n\_NIST\n\_General Access Control Guidance\
        \ for Cloud Systems | NIST\n\n\nOpenID Connect\_\n\_Welcome to OpenID Connect\n\
        \_OpenID\n\_OpenID Connect | OpenID\n\n\nSAML V2.0\n\_SAML Wiki\n\_OASIS Open\n\
        \_FrontPage - SAML Wiki (oasis-open.org)\n\n\nRFC 7642\_\n\_System for Cross-domain\
        \ Identity Management: Definitions, Overview, Concepts, and Requirements\n\
        \_IETF\n\_RFC 7642 - System for Cross-domain Identity Management: Definitions,\
        \ Overview, Concepts, and Requirements (ietf.org)\n\n\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.17
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:4
      ref_id: 23.3.17
      description: 'Relevant PSR requirements can be found at:



        Reference

        Title

        Source



        PSR mandatory requirements


        GOV2 - Take a risk-based approach

        GOV5 - Manage risks when working with others

        GOV6 - Manage security incidents

        INFOSEC1 - Understand what you need to protect

        INFOSEC2 - Design your information security

        INFOSEC3 - Validate your security measures

        INFOSEC4 - Keep your security up to date

        Mandatory requirements | Protective Security Requirements



        PSR protocol for information security

        Management protocol for information security

        Management protocol for information security | Protective Security Requirements



        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      description: Privileged account separation
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.18.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:1
      ref_id: 23.3.18.R.01
      description: Separating administrative accounts between environments (for example
        cloud and on-premise) reduces the risk of a compromise in one laterally spreading
        to the other.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.18.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:1
      ref_id: 23.3.18.C.01
      name: 'Control -  All Classifications - Should [CID: 7433]'
      description: Accounts used to perform privileged actions SHOULD NOT be synchronised
        between environments.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      description: Username and passwords
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.19.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:2
      ref_id: 23.3.19.R.01
      description: "Credentials used to access public cloud services can be reused\
        \ across cloud service providers, and are at risk of discovery or being easily\
        \ guessed.\_ Due to these services being directly accessible from the internet,\
        \ authentication should not rely on a single factor for standard users, and\
        \ must not for privileged users. Refer to section 16.4 Privileged Access Management\
        \ (PAM)."
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.19.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:2
      ref_id: 23.3.19.C.01
      name: 'Control -  All Classifications - Must [CID: 7436]'
      description: Where administration interfaces or portals are accessible from
        the internet, privileged accounts MUST be configured to use multiple factors
        of authentication.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.19.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:2
      ref_id: 23.3.19.C.02
      name: 'Control -  All Classifications - Should [CID: 7437]'
      description: Where cloud service interfaces or portals are accessible from the
        internet, user accounts SHOULD be configured to use multiple factors of authentication.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      description: Offboarding
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.20.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:3
      ref_id: 23.3.20.R.01
      description: "Public cloud services often rely on a Zero Trust approach to security\
        \ where policy decision and policy enforcement points are used to control\
        \ access based on authentication and privilege assignments.\_ Timely removal\
        \ of user access is essential to ensure unauthorised access to cloud services\
        \ does not occur from former staff."
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.20.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:3
      ref_id: 23.3.20.C.01
      name: 'Control -  All Classifications - Must [CID: 7440]'
      description: Staff offboarding processes MUST be updated to include removing
        all access to public cloud based services, prior to implementation or adoption
        of public cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      description: Authentication
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.21.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:4
      ref_id: 23.3.21.R.01
      description: Identity providers are privileged entities that must prove a chain
        of trust to prevent a malicious actor tampering with authentication traffic
        as it passes between the provider and the relying party.
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.21.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:4
      ref_id: 23.3.21.C.01
      name: 'Control -  All Classifications - Must [CID: 7443]'
      description: "Agencies MUST ensure that relying parties continually verify the\
        \ authenticity of their identity provider\u2019s responses, through for example,\
        \ cryptographic signing of authentication requests and responses."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.3:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5
      description: Relying parties
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.22.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:5
      ref_id: 23.3.22.R.01
      description: "Cloud provider authentication services often provide additional\
        \ information attributes to relying parties to inform authentication and access\
        \ control decisions.\_ These attributes may include information such as the\
        \ individual\u2019s local time of day, the status of their device (including\
        \ if it has been successfully used before), or their location."
    - urn: urn:defend:risk:req_node:nzism-v3:23.3.22.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.3:5:5
      ref_id: 23.3.22.C.01
      name: 'Control -  All Classifications - Should [CID: 7446]'
      description: Agencies SHOULD ensure that relying parties use all available information
        from the identity provider to inform access control decisions.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:23.4
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:23
      ref_id: '23.4'
      name: Data Protection in Public Cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:1
      ref_id: 23.4.1
      description: Data is protected throughout its lifecycle on public cloud platforms.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2:1
      ref_id: 23.4.2
      description: This section provides information on keeping data in a public cloud
        environment secure from creation to destruction, whether at rest, in-transit,
        during processing, or when it is no longer required.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2:1
      ref_id: 23.4.3
      description: 'Key considerations for keeping agency data secure in public cloud
        are that data is stored and processed on systems that:

        Are not under direct agency control.

        Are designed to be potentially accessible from anywhere.

        Can be accessed by multiple end-point devices.

        May replicate the data to multiple locations.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2:1
      ref_id: 23.4.4
      description: "Where these systems are located outside New Zealand, or a New\
        \ Zealand-based service is provided by an entity subject to another country\u2019\
        s laws, there may be additional jurisdictional risks to privacy and sovereignty\
        \ to consider."
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2:1
      ref_id: 23.4.5
      description: "Reference to other chapters and sections in this document is essential.\_\
        \ In particular:\nSection 6.4 \u2013 Business continuity and disaster recovery\n\
        Section 13.1\u2013 System decommissioning\nChapter 17 \u2013 Cryptography\n\
        Chapter 18 \u2013 Network security\nChapter 20 \u2013 Data management\nChapter\
        \ 21 \u2013 Distributed working\nChapter 23.2 - Public cloud services - Governance,\
        \ risk assessment and assurance\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2
      description: Data accessibility
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:2:2
      ref_id: 23.4.6
      description: "Public cloud services are often promoted for their ability to\
        \ make organisations\u2019 data assets more accessible, both within the organisation\
        \ and to partners or customers. This benefit also brings risks such as default\
        \ accessibility from the internet and requires agencies to carefully manage\
        \ access to data."
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.7
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:3
      ref_id: 23.4.7
      description: "Further references can be found at:\n\n\nReference\_\nTitle\_\n\
        Publisher\_\n\_Source\n\n\n\_\n\_Cloud security technical reference architecture\n\
        \_CISA\n\_Cloud Security Technical Reference Architecture | CISA\n\n\n\_ISO\
        \ 27001:2013\n\_Information technology \u2014 Security techniques \u2014 Information\
        \ security management systems \u2014 Requirements\n\_ISO\n\_ISO - ISO/IEC\
        \ 27001:2013 - Information technology \u2014 Security techniques \u2014 Information\
        \ security management systems \u2014 Requirements\n\n\n\_NIST SP 800-144 (2011)\n\
        \_Guidelines on security and privacy in public cloud computing\_\n\_NIST\n\
        \_Guidelines on Security and Privacy in Public Cloud Computing | NIST\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:4
      ref_id: 23.4.8
      description: "Relevant PSR requirements can be found at:\n\n\nReference\_\n\
        Title\_\nSource\_\n\n\n\_PSR mandatory requirements\n\_GOV2 - Take a risk-based\
        \ approach\nGOV5 - Manage risks when working with others\nGOV6 - Manage security\
        \ incidents\nINFOSEC1 - Understand what you need to protect\nINFOSEC2 - Design\
        \ your information security\nINFOSEC3 - Validate your security measures\n\
        INFOSEC4 - Keep your security up to date\n\_Mandatory requirements | Protective\
        \ Security Requirements\n\n\n\_PSR protocol for information security\n\_Management\
        \ protocol for information security\n\_Management protocol for information\
        \ security | Protective Security Requirements\n\n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      description: Data protection mechanisms
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.9.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      ref_id: 23.4.9.R.01
      description: Agencies remain accountable for the confidentiality, integrity,
        and availability of their data, even though cloud service providers may define
        and implement the mechanisms used to protect their data in the cloud environment.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.9.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      ref_id: 23.4.9.R.02
      description: The mechanisms available for agency control and management of keys
        in a public cloud environment are often tied to a specific cloud environment
        and migrating data to a new environment may require decryption and re-encryption.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.9.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      ref_id: 23.4.9.C.01
      name: 'Control -  All Classifications - Must [CID: 7461]'
      description: For each cloud service, agencies MUST ensure that the mechanisms
        used to protect data meet agency requirements.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.9.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      ref_id: 23.4.9.C.02
      name: 'Control -  All Classifications - Must [CID: 7462]'
      description: Agencies MUST update key management plans to account for differences
        in public cloud before storing organisational data in a public cloud environment.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.9.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:1
      ref_id: 23.4.9.C.03
      name: 'Control -  All Classifications - Must [CID: 7463]'
      description: Agencies MUST ensure their key management plan includes provision
        for migrating data from the cloud environment where it was created.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      description: Data accessibility
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:2
      ref_id: 23.4.10.R.01
      description: Many public cloud services are designed to make customer data directly
        accessible through multiple interfaces. These service endpoints may be internet-accessible
        by default, and will have specific mechanisms that restrict access to authorised
        parties. Failure to consider these endpoints or to control their default accessibility
        risks exposure of agency information to unauthorised parties.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:2
      ref_id: 23.4.10.C.01
      name: 'Control -  All Classifications - Must [CID: 7466]'
      description: Agencies MUST apply the principle of least privilege and configure
        service endpoints to restrict access to authorised parties.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      description: Data location
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:3
      ref_id: 23.4.11.R.01
      description: The geographic locations where public cloud data is stored may
        have security or privacy implications for agencies. These locations may be
        in jurisdictions with differing laws from New Zealand or be subject to particular
        environmental risks that agencies have not previously had to consider. While
        these factors do not of themselves prevent placing agency data in such locations,
        agencies have a responsibility to fully understand where their data is stored
        or processed and to manage any resulting risks appropriately.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:3
      ref_id: 23.4.11.C.01
      name: 'Control -  All Classifications - Must [CID: 7469]'
      description: Agencies MUST identify where data used in conjunction with a public
        cloud service is stored or processed, including any replicas or backups that
        may be created.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.11.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:3
      ref_id: 23.4.11.C.02
      name: 'Control -  All Classifications - Must [CID: 7470]'
      description: Agency risk assessments of public cloud services MUST include any
        risks arising from data location. Any actions required to mitigate these risks
        must be identified and documented prior to implementation or adoption of public
        cloud services.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5:4
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      description: Revise disaster recovery plans to include data in public cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:4
      ref_id: 23.4.12.R.01
      description: "As specified in Section 6.4, Business continuity and disaster\
        \ recovery, agencies must plan for recovery from loss of data to ensure they\
        \ can continue to operate. Public cloud services can provide alternative mechanisms\
        \ to back up and restore data from those used on premises.\_ Recovery processes\
        \ and plans may need to be updated to account for these differences to avoid\
        \ agencies finding their ability to recover from data loss is compromised."
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.12.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:4
      ref_id: 23.4.12.R.02
      description: As well as protecting data stored natively in public cloud services,
        agencies may choose to back up on-premises data to the cloud or vice versa.
        The same considerations and opportunities for new approaches apply in all
        these cases.
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:4
      ref_id: 23.4.12.C.01
      name: 'Control -  All Classifications - Must [CID: 7474]'
      description: Agencies MUST update their disaster recovery plans prior to storing
        or replicating data in public cloud services, to ensure these plans address
        any cloud-specific aspects of backup and recovery.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:4
      ref_id: 23.4.12.C.02
      name: 'Control -  All Classifications - Must [CID: 7475]'
      description: "When planning tests of disaster recovery processes in accordance\
        \ with 6.4.6\_Backup strategy, agencies MUST include tests of any cloud-specific\
        \ data recovery processes."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5
      description: Data retrieval and removal
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.13.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      ref_id: 23.4.13.R.01
      description: "It is important to consider what would be involved in leaving\
        \ or changing the provider of a public cloud service. \_Planning for ending\
        \ the use of a cloud service should be done before commissioning and deployment\
        \ of data into the cloud. \_"
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.13.r.02
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      ref_id: 23.4.13.R.02
      description: 'Terminating cloud service contracts can have undesired consequences
        and risks for an agency if a managed process is not followed, for example:

        All or some agency data being retained on the cloud platform by the provider.

        Agency data being removed prior to being retrieved by the agency.

        Agency data being replicated to other jurisdictions before or after decommissioning.

        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.13.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      ref_id: 23.4.13.C.01
      name: 'Control -  All Classifications - Must [CID: 7511]'
      description: Agencies MUST have a defined exit strategy for each public cloud
        service they consume, including a process by which their data can be retrieved
        and erased from the cloud service as part of contract termination.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.13.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      ref_id: 23.4.13.C.02
      name: 'Control -  All Classifications - Must [CID: 7512]'
      description: Agencies MUST ensure all data they need to retain is retrieved
        from the cloud service provider prior to decommissioning.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.4.13.c.03
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.4:5:5
      ref_id: 23.4.13.C.03
      name: 'Control -  All Classifications - Must [CID: 7513]'
      description: Agencies MUST have assurance that no agency-owned data is retained
        on the cloud service being decommissioned.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.5
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:23
      ref_id: '23.5'
      name: Logging and Alerting in Public Cloud
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5
      name: Objective
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:1
      ref_id: 23.5.1
      description: "Security-related events are recorded from across an agency\u2019\
        s public cloud platforms and are able to be analysed for timely notification\
        \ of potential threats or incidents."
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:2
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5
      name: Context
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:2:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2
      description: Scope
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.2
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:1
      ref_id: 23.5.2
      description: This section describes the requirements for capturing security-related
        information from public cloud services by examining electronic logs for indications
        that unauthorised security-related activities have been attempted or performed.
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.3
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:1
      ref_id: 23.5.3
      description: "\_Reference to other chapters and sections in this document is\
        \ essential.\_ In particular:\nSection 7.1 \u2013 Detecting information security\
        \ incidents\nSection 16.6 \u2013 Event logging and auditing\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:2:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2
      description: Logging
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.4
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:2
      ref_id: 23.5.4
      description: Appropriate ongoing logging is vital for detecting threat actor
        activity occurring within agency public cloud environments.
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.5
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:2
      ref_id: 23.5.5
      description: "Public cloud introduces particular aspects of logging that agencies\
        \ must consider, including:\nResponsibility for logging and detecting anomalies\
        \ is shared between the agency and its cloud service provider.\nCloud services\
        \ may introduce differences in what information is able to be logged, where\
        \ it can be logged, and in what format the log messages are constructed.\_\
        \ It may not be possible for the consuming agency to customise logging parameters.\n\
        Key security components used by cloud services may be sourced from multiple\
        \ providers (e.g., identity federation or SaaS integration). Effective log\
        \ monitoring and incident investigation requires these logs to be accessible\
        \ and be able to be correlated with each other.\nSome components of the environment\
        \ where logs are traditionally collected may not be available in cloud environments\
        \ (e.g., network traffic or boundary devices), or the information may need\
        \ to be collected in different ways.\nOnly a subset of log information may\
        \ be able to be exported from a cloud environment due to technical or cost\
        \ implications.\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.6
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:2
      ref_id: 23.5.6
      description: Agencies running across multiple clouds or running a hybrid of
        public cloud and on premise infrastructure must also balance the advantages
        of platform-specific capabilities against the need for centralised visibility.
        Centralised visibility does not necessarily require centralised log aggregation,
        but agencies must be able to track and correlate activity across all the log
        sources available to them.
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:2:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2
      description: Alerting
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.7
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:2:3
      ref_id: 23.5.7
      description: While logging is vital for detecting threat actor activity occurring
        across agency public cloud systems, in isolation it does not provide a detection
        capability and must be paired with appropriate analysis and alerting tools.
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:3
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5
      name: References
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.8
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:3
      ref_id: 23.5.8
      description: "Further references can be found at:\n\n\nReference\nTitle\nPublisher\n\
        Source\n\n\n\_\nCSA Security Guidance for Critical Areas of Focus in Cloud\
        \ Computing\nCSA\nCSA Security Guidance for Cloud Computing | CSA (cloudsecurityalliance.org)\n\
        \n\n"
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:4
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5
      name: PSR References
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.9
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:4
      ref_id: 23.5.9
      description: 'Relevant PSR requirements can be found at:



        Reference

        Title

        Source



        PSR mandatory requirements


        GOV2 - Take a risk-based approach

        GOV5 - Manage risks when working with others

        GOV6 - Manage security incidents

        INFOSEC1 - Understand what you need to protect

        INFOSEC2 - Design your information security

        INFOSEC3 - Validate your security measures

        INFOSEC4 - Keep your security up to date

        Mandatory requirements | Protective Security Requirements



        PSR protocol for information security

        Management protocol for information security

        Management protocol for information security | Protective Security Requirements



        '
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:5
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5
      name: Rationale & Controls
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:5:1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5
      description: Logging public cloud events
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.10.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:1
      ref_id: 23.5.10.R.01
      description: Logging capabilities and shared responsibility models for log collection,
        storage, and retention differ between public cloud providers. The division
        of responsibility may also vary across different deployment models and the
        individual services within a cloud platform.
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.10.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:1
      ref_id: 23.5.10.C.01
      name: 'Control -  All Classifications - Must [CID: 7494]'
      description: Agencies MUST understand the range of logging capabilities provided
        by their cloud service providers and determine whether they are sufficient
        for agency needs.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:5:2
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5
      description: Logging requirements
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.11.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:2
      ref_id: 23.5.11.R.01
      description: It may not be possible, or desirable, to centralise all public
        cloud log information into a single protected repository. However it is vital
        that log information is still collected and maintained to meet legislative,
        regulatory and incident response requirements (see 16.6.8 - Logging requirements).
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.11.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:2
      ref_id: 23.5.11.C.01
      name: 'Control -  All Classifications - Must [CID: 7496]'
      description: "Agencies MUST ensure that logs associated with public cloud services\
        \ are collected, protected, and that their integrity can be confirmed in accordance\
        \ with the agency\u2019s documented logging requirements."
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.5:5:3
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5
      description: 'Detecting information security incidents in public cloud '
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.12.r.01
      assessable: false
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:3
      ref_id: 23.5.12.R.01
      description: Specialised tools and procedures may be required to detect security
        incidents that occur within public cloud environments (See 7.1.7 - Preventing
        and detecting information security incidents).
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.12.c.01
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:3
      ref_id: 23.5.12.C.01
      name: 'Control -  All Classifications - Must [CID: 7498]'
      description: Agencies MUST ensure that cloud service provider logs are incorporated
        into overall enterprise logging and alerting systems or procedures in a timely
        manner to detect information security incidents.
      implementation_groups:
      - All Classifications - MUST
    - urn: urn:defend:risk:req_node:nzism-v3:23.5.12.c.02
      assessable: true
      depth: 5
      parent_urn: urn:defend:risk:req_node:nzism-v3:23.5:5:3
      ref_id: 23.5.12.C.02
      name: 'Control -  All Classifications - Should [CID: 7499]'
      description: Agencies SHOULD ensure that tools and procedures used to detect
        potential information security incidents account for the public cloud services
        being consumed by the agency.
      implementation_groups:
      - All Classifications - SHOULD
    - urn: urn:defend:risk:req_node:nzism-v3:24
      assessable: false
      depth: 1
      ref_id: '24'
      name: Supporting Information
    - urn: urn:defend:risk:req_node:nzism-v3:24.1
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:24
      ref_id: '24.1'
      name: Glossary of Abbreviations
    - urn: urn:defend:risk:req_node:nzism-v3:24.1:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:24.1
      name: Glossary of Abbreviations
    - urn: urn:defend:risk:req_node:nzism-v3:24.1.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:24.1:1
      ref_id: 24.1.1
      description: "\n\n\n\nAbbreviation\n\n\nMeaning\n\n\n\n\n3DES\n\n\nTriple Data\
        \ Encryption Standard\n\n\n\n\nABAC\n\n\nAttribute Based Access Control\n\n\
        \n\n\nAES\n\n\nAdvanced Encryption Standard\n\n\n\n\nAH\n\n\nAuthentication\
        \ Header\n\n\n\n\nAISEP\n\n\nAustralasian Information Security Evaluation\
        \ Program\n\n\n\n\nAoG\n\n\nAll-of-Government\n\n\n\n\nAS\n\n\nAustralian\
        \ Standard\n\n\n\n\nASD\n\n\nAustralian Signals Directorate\n\n\n\n\nBYOD\n\
        \n\nBring Your Own Device\n\n\n\n\nBYOK\n\n\nBring Your Own Keys\n\n\n\n\n\
        CAVP\n\n\nCryptographic Algorithm Validation Program\n\n\n\n\nCBC\n\n\nCipher\
        \ Block Chaining\n\n\n\n\nCC\n\n\nCommon Criteria\n\n\n\n\nCCI\n\n\nControlled\
        \ Cryptographic Item\n\n\n\n\nCCRA\n\n\nCommon Criteria Recognition Arrangement\n\
        \n\n\n\nCDS\n\n\nCross-Domain Solution\n\n\n\n\nCEO\n\n\nChief Executive Officer\n\
        \n\n\n\nCIO\n\n\nChief Information Officer\n\n\n\n\nCISO\n\n\nChief Information\
        \ Security Officer\n\n\n\n\nCOMSEC\n\n\nCommunications Security\n\n\n\n\n\
        CSfC\n\n\nCommercial Solutions for Classified\n\n\n\n\nCSO\n\n\nChief Security\
        \ Officer\n\n\n\n\nCSP\n\n\nCloud Service Provider\n\n\n\n\nDdoS\n\n\nDistributed\
        \ Denial-Of-Service\n\n\n\n\nDH\n\n\nDiffie-Hellman\n\n\n\n\nDIS\n\n\nDraft\
        \ International Standard\n\n\n\n\nDKIM\n\n\nDomainKeys Identified Mail\n\n\
        \n\n\nDMARC\n\nDomain-based Message Authentication, Reporting and Conformance\n\
        \n\n\nDMZ\n\nDemilitarized zone\n\n\n\nDoS\n\n\nDenial-Of-Service\n\n\n\n\n\
        DSA\n\n\nDigital Signature Algorithm\n\n\n\n\nEAL\n\n\nEvaluation Assurance\
        \ Level\n\n\n\n\nEAP-TLS\n\n\nExtensible Authentication Protocol-Transport\
        \ Layer Security\n\n\n\n\nECB\n\n\nElectronic Code Book mode\n\n\n\n\nECDH\n\
        \n\nElliptic Curve Diffie-Hellman\n\n\n\n\nECDSA\n\n\nElliptic Curve Digital\
        \ Signature Algorithm\n\n\n\n\nEEPROM\n\n\nElectrically Erasable Programmable\
        \ Read-Only Memory\n\n\n\n\nEPL\n\n\nEvaluated Products List\n\n\n\n\nEPLD\n\
        \n\nEvaluated Products List \u2013 Degausser\n\n\n\n\nEPROM\n\n\nErasable\
        \ Programmable Read-Only Memory\n\n\n\n\nESP\n\n\nEncapsulating Security Payload\n\
        \n\n\n\nFIPS\n\n\nFederal Information Processing Standard\n\n\n\n\nFPGA\n\n\
        \nField Programmable Gate Array\n\n\n\n\nFTL\n\n\nFlash Transition Layer\n\
        \n\n\n\nGCDO\n\n\nNZ Government Chief Digital Officer\n\n\n\n\nGCSB\n\n\n\
        Government Communications Security Bureau\n\n\n\n\nGPU\n\n\nGraphics Processing\
        \ Unit\n\n\n\n\nHA\n\n\nHigh Availability\n\n\n\n\nHACE\n\n\nHigh Assurance\
        \ Cryptographic Equipment\n\n\n\n\nHB\n\n\nHandbook\n\n\n\n\nHGCE\n\n\nHigh\
        \ Grade Cryptographic Equipment. Terminology superseded by HACE.\n\n\n\n\n\
        HGCP\n\n\nHigh Grade Cryptographic Products. Terminology superseded by HACE.\n\
        \n\n\n\nHMAC\n\n\nHashed Message Authentication Code\n\n\n\n\nHSM\n\n\nHardware\
        \ Security Module\n\n\n\n\nHTTP\n\n\nHypertext Transfer Protocol\n\n\n\n\n\
        HTTPS\n\n\nHypertext Transfer Protocol Secure\n\n\n\n\nHYOK\n\n\nHold Your\
        \ Own Keys\n\n\n\n\nIaaS\n\n\nInfrastructure-as-a-Service\n\n\n\n\nICT\n\n\
        \nInformation And Communications Technology\n\n\n\n\nIDS\n\n\nIntrusion Detection\
        \ System\n\n\n\n\nIEC\n\n\nInternational Electrotechnical Commission\n\n\n\
        \n\nIEEE\n\n\nInstitute Of Electrical And Electronics Engineers\n\n\n\n\n\
        IETF\n\n\nInternational Engineering Task Force\n\n\n\n\nIKE\n\n\nInternet\
        \ Key Exchange\n\n\n\n\nIM\n\n\nInstant Messaging\n\n\n\n\nIMS\n\n\nIP Multimedia\
        \ Subsystem\n\n\n\n\nIODEF\n\n\nIncident Object Description Exchange Format\n\
        \n\n\n\nIP\n\n\nInternet Protocol\n\n\n\n\nIPSec\n\n\nInternet Protocol Security\n\
        \n\n\n\nIR\n\n\nInfrared\n\n\n\n\nIRC\n\n\nInternet Relay Chat\n\n\n\n\nIPT\n\
        \n\nInternet Protocol Telephony\n\n\n\n\nIRP\n\n\nIncident Response Plan\n\
        \n\n\n\nISAKMP\n\n\nInternet Security Association Key Management Protocol\n\
        \n\n\n\nISO\n\n\nInternational Organization for Standardization\n\n\n\n\n\
        ITSEC\n\n\nInformation Technology Security Evaluation Criteria\n\n\n\n\nITSM\n\
        \n\nInformation Technology Security Manager\n\n\n\n\nIWF\n\n\nInter-Working\
        \ Function\n\n\n\n\nKMP\n\n\nKey Management Plan\n\n\n\n\nKMS\n\n\nKey management\
        \ system\n\n\n\n\nMDM\n\n\nMobile Device Manager\n\n\n\n\nMFA\n\n\nMulti-Factor\
        \ Authentication\n\n\n\n\nMFD\n\n\nMultifunction Device\n\n\n\n\nMMS\n\n\n\
        Multimedia Message Service\n\n\n\n\nMSL\n\n\n(New Zealand) Measurement Standards\
        \ Laboratory\n\n\n\n\nNAND\n\n\nFlash Memory Named After The NAND Logic Gate\n\
        \n\n\n\nNAND\n\n\nNOT AND \u2013 A Binary Logic Operation\n\n\n\n\nNDPP\n\n\
        \nNetwork Device Protection Profile\n\n\n\n\nNIST\n\n\nNational Institute\
        \ Of Standards And Technology\n\n\n\n\nNOR\n\n\nFlash Memory Named After The\
        \ NOR Logic Gate\n\n\n\n\nNOR\n\n\nNOT OR \u2013 A Binary Logic Operation\n\
        \n\n\n\nNTP\n\n\nNetwork Time Protocol\n\n\n\n\nNZCSI\n\n\nNew Zealand Communications\
        \ Security Instruction\n\n\n\n\nNZCSP\n\n\nNew Zealand Communications Security\
        \ Policy\n\n\n\n\nNZ e-GIF\n\n\nNew Zealand E-Government Interoperability\
        \ Framework\n\n\n\n\nNZEO\n\n\nNew Zealand Eyes Only\n\n\n\n\nNZISM\n\n\n\
        New Zealand Information Security Manual\n\n\n\n\nNZS\n\n\nNew Zealand Standard\n\
        \n\n\n\nOTP\n\n\nOne-Time Password\n\n\n\n\nPaaS\n\n\nPlatform-as-a-Service\n\
        \n\n\n\nPAM\n\n\nPrivileged Access Management\n\n\n\n\nPBX\n\n\nPrivate Branch\
        \ Exchange\n\n\n\n\nPED\n\n\nPortable Electronic Device\n\n\n\n\nPIN\n\n\n\
        Personal Identification Number\n\n\n\n\nPKI\n\n\nPublic Key Infrastructure\n\
        \n\n\n\nPP\n\n\nProtection Profile\n\n\n\n\nPSR\n\n\nProtective Security Requirements\n\
        \n\n\n\nPSTN\n\n\nPublic Switched Telephone Network\n\n\n\n\nQoS\n\n\nQuality\
        \ of Service\n\n\n\n\nRAM\n\n\nRandom Access Memory\n\n\n\n\nRBAC\n\n\nRole-Based\
        \ Access Control\n\n\n\n\nRF\n\n\nRadio Frequency\n\n\n\n\nRFC\n\n\nRequest\
        \ For Comments\n\n\n\n\nRSA\n\n\nRivest-Shamir-Adleman\n\n\n\n\nRTP\n\n\n\
        Real-Time Transport Protocol\n\n\n\n\nSaaS\n\n\nSoftware-as-a-Service\n\n\n\
        \n\nSBC\n\n\nSession Border Controller\n\n\n\n\nSCEC\n\n\nSecurity Construction\
        \ And Equipment Committee\n\n\n\n\nSCI\n\n\nSensitive Compartmented Information\n\
        \n\n\n\nSCIF\n\n\nSensitive Compartmented Information Facility\n\n\n\n\nSCIM\n\
        \n\nSystem for Cross-domain Identity Management\n\n\n\n\nSDN\n\n\nSoftware\
        \ Defined Networking\n\n\n\n\nSecPlan\n\n\nSystem Security Plan\n\n\n\n\n\
        SecPol\n\n\nSystem Security Policy\n\n\n\n\nSitePlan\n\n\nSystem Site Plan\n\
        \n\n\n\nSHA\n\n\nSecure Hashing Algorithm\n\n\n\n\nSIM\n\n\nSubscriber Identity\
        \ Module\n\n\n\n\nSIP\n\n\nSession Initiation Protocol\n\n\n\n\nSLA\n\n\n\
        Service Level Agreement\n\n\n\n\nS/MIME\n\n\nSecure Multipurpose Internet\
        \ Mail Extension\n\n\n\n\nSMS\n\n\nShort Message Service\n\n\n\n\nSOE\n\n\n\
        Standard Operating Environment\n\n\n\n\nSOP\n\n\nStandard Operating Procedure\n\
        \n\n\n\nSP\n\n\nSpecial Publication\n\n\n\n\nSPF\n\n\nSender Policy Framework\n\
        \n\n\n\nSRMP\n\n\nSecurity Risk Management Plan\n\n\n\n\nSSD\n\n\nSolid State\
        \ Drive\n\n\n\n\nSSH\n\n\nSecure Shell\n\n\n\n\nSSL\n\n\nSecure Sockets Layer\n\
        \n\n\n\nSSP\n\n\nSystem Security Plan\n\n\n\n\nTLS\n\n\nTransport Layer Security\n\
        \n\n\n\nTOE\n\n\nTarget of Evaluation (in Common Criteria)\n\n\n\n\nTOE\n\n\
        \nTrusted Operating Environment\n\n\n\n\nUC\n\n\nUnified Communication\n\n\
        \n\n\nUTC\n\n\nCo-ordinated Universal Time\n\n\n\n\nVDP\n\n\nVulnerability\
        \ Disclosure Policy\n\n\n\n\nVLAN\n\n\nVirtual Local Area Network\n\n\n\n\n\
        VM\n\n\nVirtual Machine\n\n\n\n\nVoIP\n\n\nVoice Over Internet Protocol\n\n\
        \n\n\nVPN\n\n\nVirtual Private Network\n\n\n\n\nWAP\n\n\nWireless Access Point\n\
        \n\n\n\nWEP\n\n\nWired Equivalent Privacy\n\n\n\n\nWEEE\n\n\nWaste Electrical\
        \ and Electronic Equipment\n\n\n\n\nWLAN\n\n\nWireless Local Area Network\n\
        \n\n\n\nWPA2\n\n\nWi-Fi Protected Access 2\n\n\n\n\nXAUTH\n\n\nIke Extended\
        \ Authentication\n\n\n\n\n\_\n\_"
    - urn: urn:defend:risk:req_node:nzism-v3:24.2
      assessable: false
      depth: 2
      parent_urn: urn:defend:risk:req_node:nzism-v3:24
      ref_id: '24.2'
      name: Glossary of Terms
    - urn: urn:defend:risk:req_node:nzism-v3:24.2:1
      assessable: false
      depth: 3
      parent_urn: urn:defend:risk:req_node:nzism-v3:24.2
      name: Glossary of Terms
    - urn: urn:defend:risk:req_node:nzism-v3:24.2.1
      assessable: false
      depth: 4
      parent_urn: urn:defend:risk:req_node:nzism-v3:24.2:1
      ref_id: 24.2.1
      description: "\n\n\n\nTerm\n\n\nMeaning\n\n\n\n\n802.11\n\n\nThe Institute of\
        \ Electrical and Electronics Engineers standard defining WLAN communications.\
        \ Formally titled IEEE 82.11.\n\n\n\n\nAccess Gateway\n\n\nAn architectural\
        \ construct that provides the system user access to multiple security domains\
        \ from a single device, typically a workstation.\n\n\n\nAccess control\n\n\
        The process of granting or denying requests for access to systems, applications\
        \ and information. It can also refer to the process of granting or denying\
        \ requests for access to facilities.\n\n\n\n\nAccountable\n\n\nRequired or\_\
        expected to justify actions or decisions; being answerable and responsible\
        \ for those actions & decisions.\n\n\n\n\nAccountable Material\n\n\nAccountable\
        \ information, an accountable item or accountable material refers to the accountability\
        \ controls applied to specified information, equipment or materials. Accountable\
        \ information, items or materials are usually uniquely identifiable (usually\
        \ a serial or identification number) and are tracked from acquisition or creation\
        \ to final disposal. Safe custody is a fundamental and is achieved through:\n\
        \nis easily to compute;\nwill usually output a significantly different value,\
        \ even for small changes made to the input; and\ncan detect many types of\
        \ data corruptions.\nallocation to a specific individual (issued or responsibility\
        \ designated);\nallocation or designation of responsibility may also require\
        \ a specific briefing related to the handling, care and protection of particular\
        \ types of classified information and COMSEC equipment;\nthe allocation, issue\
        \ or designation being recorded;\nstrict controls over access and movement\
        \ (special handling requirements);\nmaintenance of a register (manual or electronic);\
        \ and\nregular audits to ensure accountability conditions continue to be adhered\
        \ to and any briefings are current.\n\nAs a general rule, accountable information,\
        \ items or materials are afforded physical security protection by specifying\
        \ special handling and accountability conditions. Examples may include cryptographic\
        \ or COMSEC equipment, other high value equipment, money, computers or information\
        \ subject to privacy legislation and regulation. Cryptographic or COMSEC equipment\
        \ and any information classified as CONFIDENTIAL, SECRET or TOP SECRET is\
        \ accountable by definition.\n\n\n\n\nAccountability\n\n\nMost contemporary\
        \ definitions include two key elements:\n\nthe conferring of responsibility\
        \ and authority; and\nthe answering for the use of that authority.\n\nAccountability\
        \ exists when the performance of tasks or functions by an individual or organisation,\
        \ are subject to another\u2019s oversight, direction or request that they\
        \ provide information or justification for their actions.\nAnswering for the\
        \ use of authority means reporting, explaining actions, assuming obligations,\
        \ and submitting to outside or external judgement. \_Having responsibility\
        \ means having the authority to act, the power to control and the freedom\
        \ to decide.\_ It also means that one must behave rationally, reliably and\
        \ consistently in exercising judgement.\n\n\n\n\nAccreditation\n\n\nA procedure\
        \ by which an authoritative body gives formal recognition, approval and acceptance\
        \ of the associated residual security risk with the operation of a system\
        \ and issues a formal approval to operate the system.\n\n\n\n\nAccreditation\
        \ Authority\n\n\nThe authoritative body or individual responsible for systems\
        \ accreditation.\n\n\n\n\nAdaptive Authentication\n\n\nThis varies the level\
        \ or degree of authentication required where unusual login requests occur.\_\
        \ For example, out of normal hours, from an unusual geolocation, from an unknown\
        \ device and so on.\_ When an unusual authentication request is received,\
        \ Adaptive Authentication may request additional credentials such as a one-time\
        \ code provided to a known mobile phone number.\n\n\n\n\nAgency\n\n\nNew Zealand\
        \ Government departments, authorities, agencies or other bodies established\
        \ in relation to public purposes, including departments and authorities staffed\
        \ under the Public Service Act.\n\n\n\n\nAgency Control\n\n\nThis description\
        \ applies where an Agency has direct control of agency information systems\
        \ and data.\_ It follows that Non-Agency Control occurs where direct control\
        \ is impaired or does not or cannot exist.\n\n\n\n\nAgency\_Head\n\n\nThe\
        \ government employee with ultimate responsibility for the secure operation\
        \ of agency functions, whether performed inhouse or outsourced.\n\n\n\n\n\
        All-of-Government\n\n\nRefers to the entire New Zealand state sector.\n\n\n\
        \n\nAllow list\n\n\nA list that confirms items being analysed are acceptable.\
        \ This is the opposite of a deny or block list.\n\n\n\n\nApproved Cryptographic\
        \ Algorithms\n\n\nApproved cryptographic algorithms have been extensively\
        \ scrutinised for vulnerabilities by government, industry and academic communities\
        \ in a practical and theoretical setting. The approved cryptographic algorithms\
        \ fall into three categories: asymmetric/public key algorithms, hashing algorithms,\
        \ and symmetric encryption algorithms.\_\n\n\n\n\nApproved Destruction Facility\n\
        \n\nThe status of \u201Capproved facility\u201D for the destruction of media\
        \ and equipment, applies to a specific installation/site, and is granted by\
        \ the Director-General GCSB under the NZISM.\nApproval depends upon the Director-General\u2019\
        s satisfaction that the proposed facilities are capable of securely destroying\
        \ IT equipment, devices and media to the standard required under the NZISM\
        \ and related policies and that procedural security meets the required standards.\n\
        \n\n\n\nAsset\n\n\nAnything of value to an agency, such as IT equipment and\
        \ software, information, personnel, documentation, reputation and public confidence.\n\
        \n\n\n\nAttack Surface\n\n\nThe IT equipment and software used in a system.\
        \ The greater the attack surface the greater the chances are of an attacker\
        \ finding an exploitable vulnerability.\n\n\n\n\nAttribute Based Access Control\n\
        \n\nAn access control method where subject requests to perform operations\
        \ on objects are granted or denied based on assigned attributes of the subject,\
        \ assigned attributes of the object, environment conditions, and a set of\
        \ policies that are specified in terms of those attributes and conditions.\n\
        \n\n\n\nAudit\n\n\nA structured process of examination, review, assessment,\
        \ testing and reporting against defined requirements or objectives. Auditors\
        \ should be independent of any IT system, business process, agency, function,\
        \ site, supplier or other subject area being audited.\n\n\n\n\nAustralian\
        \ Information Security Evaluation Program\n\n\nA program under which evaluations\
        \ are performed by impartial companies against the Common Criteria.\_ The\
        \ results of these evaluations are then certified by ASD, which is responsible\
        \ for the overall operation of the program.\n\n\n\n\nAuthentication\n\n\n\
        The process of identifying an individual, device or system before granting\
        \ access to system resources or data.\_ Usually based on a set of credentials\
        \ such as an identifier (such as a user or device name) and an authenticator\
        \ (such as a password or some other authentication factor).\_ Authentication\
        \ is distinct from Authorisation.\n\n\n\n\nAuthentication Header\n\n\nPart\
        \ of the protocol used for authentication within IPSec, it provides authentication,\
        \ integrity and anti-replay for the entire packet (both the header and data\
        \ payload).\n\n\n\n\nAuthorisation\n\n\nAuthorisation is the process of granting\
        \ (or revoking) access privileges to an individual, device or system.\_\_\n\
        \n\n\n\nBaseline\n\n\nInformation and controls that are used as a minimum\
        \ implementation or starting point to provide a consistent minimum standard\
        \ of systems security and information assurance.\n\n\n\n\nBrute Force Attack\n\
        \n\nA brute force attack is when an automated continuous attack is conducted\
        \ against a system or file to decrypt or discover passwords and data.\_ Often\
        \ used as an entry point for privilege escalation.\n\n\n\n\nBug Bounty\n\n\
        \nA monetary reward to researchers for the discovery and reporting of software\
        \ and other information system vulnerabilities.\n\n\n\n\nCascaded Connections\n\
        \n\nLinks to other systems that occur when connected systems are themselves\
        \ connected to other systems. This may result in multiple indirect (cascaded)\
        \ connections to systems with differing security implementations, data, equipment\
        \ and other aspects important for the security and assurance of systems.\n\
        \n\n\n\nCaveat\n\n\nA marking that indicates that the information has special\
        \ requirements in addition to those indicated by the classification and any\
        \ prescribed endorsement. The term covers codewords, source codewords, releasability\
        \ indicators and special-handling caveats. See also Endorsements.\n\n\n\n\n\
        Certification\n\n\nThe process by which the controls and management of an\
        \ information system is formally evaluated against any specific risks identified\
        \ and the requirements of the NZISM. A key output is a formal assurance statement\
        \ that the system conforms to the requirements of the NZISM.\n\n\n\n\nCertification\
        \ Authority\n\n\nAn official with the authority to assert that a system complies\
        \ with prescribed controls within a standard.\n\n\n\n\nCertification Report\n\
        \n\nA report generated by a certification body of a Common Criteria scheme\
        \ that provides a summary of the findings of an evaluation.\n\n\n\n\nCharacterisation\n\
        \n\nIn the NZISM \u201Ccharacterisation\u201D is a synonym for \u201Cunique\
        \ identifier\u201D.\nThis is typically applied to an operating system,\_ programme,\
        \ library or other programmatic element in the form of a checksum which can\
        \ be calculated from a \u201Cknown good\u201D component and stored for comparison\
        \ should there be any concern that components have been damaged or compromised.\_\
        \nForensic methods may also provide characterisation indicators but are likely\
        \ to require additional levels of expertise.\nSee also Checksum and Hash.\n\
        \n\n\n\nChecksum\n\n\nA checksum verifies or checks the integrity of data.\n\
        A good checksum algorithm:\n\nis easily to compute;\nwill usually output a\
        \ significantly different value, even for small changes made to the input;\
        \ and\ncan detect many types of data corruptions.\n\nChecksums are often used\
        \ to verify the integrity of operating system, programme, library or other\
        \ programmatic elements, images and firmware updates.\_ Checksums typically\
        \ range in length from one to 64-bits, depending on the intended usage and\
        \ algorithm used to determine the checksum.\nChecksums are related to hash\
        \ functions, fingerprints, randomisation functions, and cryptographic hash\
        \ functions.\_ Note, however, each of those concepts are distinct, have different\
        \ applications and therefore different design goals.\_ Check digits and parity\
        \ bits are special uses of checksums.\_ It is important to recognise that,\
        \ although related, a hash is not a checksum.\nSee also Hash.\n\n\n\n\nChief\
        \ Information Security Officer\n\n\nA senior executive with overall responsibility\
        \ for the governance and management of information risks within an agency.\
        \ This may include coordination between security, ICT and business functions\
        \ to ensure risks are properly identified and managed.\n\n\n\n\nClassified\
        \ Information\n\n\nGovernment information that requires protection from unauthorised\
        \ disclosure.\n\n\n\n\nClassified Systems\n\n\nSystems that process, store\
        \ or communicate classified information.\n\n\n\n\nCloud deployment model\n\
        \n\nThe term deployment model refers to the type of access and the fundamental\
        \ nature of the support infrastructure but is not specific as to the type\
        \ of service consumed.\_ Typically this includes:\n\u2022\_\_\_\_\_\_\_\_\_\
        \_\_\_ private cloud,\n\u2022\_\_\_\_\_\_\_\_\_\_\_\_ public cloud,\n\u2022\
        \_\_\_\_\_\_\_\_\_\_\_\_ hybrid cloud, and\n\u2022\_\_\_\_\_\_\_\_\_\_\_\_\
        \ multi-cloud.\n\n\n\n\nCloud service model\n\n\nThe term cloud service model\
        \ refers to the type of service used.\_ These cloud service offerings are\
        \ provided and maintained by the cloud service provider. Typical service offerings\
        \ include:\n\u2022\_\_\_\_\_\_\_\_\_\_\_\_ Infrastructure-as-a-Service,\n\u2022\
        \_\_\_\_\_\_\_\_\_\_\_\_ Software-as-a-Service, and\n\u2022\_\_\_\_\_\_\_\_\
        \_\_\_\_ Platform-as-a-Service.\n\n\n\n\nCloud service provider\n\n\nAn external\
        \ company that provides a platform, infrastructure, applications, and/or storage\
        \ services for its clients.\n\n\n\n\nCodewords\n\n\nA short (usually a single\
        \ word) descriptions of a project, operation or activity, typically assigned\
        \ used for reasons of reliability, clarity, brevity, or secrecy. Each code\
        \ word is assembled in accordance with the specific rules of the code and\
        \ assigned a unique meaning. Synonymous with Codename.\n\n\n\n\nCoercivity\n\
        \n\nA measure of the resistance of a magnetic material to changes in magnetisation,\
        \ equivalent to the field intensity necessary to demagnetise any magnetised\
        \ material. The amount of coercive force required to reduce any residual magnetic\
        \ induction to zero. Normally used in describing the characteristics of degaussing\
        \ magnetic media (see Degausser).\n\n\n\n\nCommon Criteria\n\n\nA formal,\
        \ internationally-recognised scheme, defined in the ISO 15408 standard. This\
        \ standard describes process to specify, design, develop, test, evaluate and\
        \ certify as secure IT systems, where \u2018secure\u2019 is explicitly and\
        \ formally defined.\n\n\n\n\nCommon Criteria Recognition Arrangement\n\n\n\
        An international agreement which facilitates the mutual recognition of Common\
        \ Criteria evaluations by certificate producing schemes, including the Australian\
        \ and New Zealand certification scheme.\n\n\n\n\nCommunications Security\n\
        \n\nControls applied taken to deny unauthorised access to information derived\
        \ from information and communication systems and to ensure the authenticity\
        \ of related communications and data.\n\n\n\n\nConduit\n\n\nA tube, duct or\
        \ pipe used to protect cables.\n\n\n\n\nConnection Forwarding\n\n\nThe use\
        \ of network address translation to allow a port on a network node inside\
        \ a local area network to be accessed from outside the network.\_ Alternatively,\
        \ using a Secure Shell server to forward a Transmission Control Protocol connection\
        \ to an arbitrary port on the local host.\n\n\n\n\nConOp\n\n\nConcept of Operations,\
        \ a document describing the characteristics of an information systems and\
        \ its intended use. It is used to communicate the intent and system characteristics\
        \ to all stakeholders\n\n\n\n\nConsumer Guide\n\n\nProduct specific advice\
        \ concerning evaluated products can consist of findings from mutually recognised\
        \ information security evaluations. This may include the Common Criteria,\
        \ findings from GCSB internal evaluations, any recommendations for use and\
        \ references to relevant policy and other standards.\n\n\n\n\nContent Filtering\n\
        \n\nThe process of monitoring communications, including email and web pages,\
        \ analysing them for any suspicious or unwanted content, and preventing the\
        \ delivery of suspicious or unwanted content.\n\n\n\n\nContract\n\n\nContract\
        \ means an agreement between two or more persons or entities, which is intended\
        \ to be enforceable at law and includes a contract made by deed or in writing,\n\
        \n\n\n\nCross-Domain Solution\n\n\nA Cross-Domain Solution (CDS) is a controlled\
        \ interface that enables secure manual and/or automatic access and/or information\
        \ transfer between different security domains while protecting the confidentiality,\
        \ integrity and availability of each domain.\nThere are several types of CDS\
        \ including access, multi-level and transfer gateways.\n\n\n\n\nCryptographic\
        \ Hash\n\n\nAn algorithm (the hash function) which takes as input a string\
        \ of any length (the message), and generates a fixed length string (the message\
        \ digest or fingerprint) as output.\_ The algorithm is designed to make it\
        \ computationally infeasible to find any input which maps to a given digest,\
        \ or to find two different messages that map to the same digest.\n\n\n\n\n\
        Cryptography\n\n\nCryptography is\_the study of secure communications techniques\
        \ that allow only the sender and intended recipient of a message to view\_\
        its contents.\n\n\n\n\nCryptoperiod\n\n\nThe useful life of the cryptographic\
        \ key.\n\n\n\n\nCryptographic Protocol\n\n\nSpecified cryptographic algorithms,\
        \ parameters (such as key length) and processes for managing, establishing\
        \ and using encrypted communications.\n\n\n\n\nCryptographic System\n\n\n\
        A related set of hardware or software used for cryptographic communication,\
        \ processing or storage, and the administrative framework in which it operates.\n\
        \n\n\n\nCryptographic System Material\n\n\nMaterial that includes, cryptographic\
        \ key, equipment, devices, documents, firmware or software that contains or\
        \ describes cryptographic logic.\n\n\n\n\nData At Rest\n\n\nInformation residing\
        \ on media storage facility or a system that is not in use.\n\n\n\n\nData\
        \ Diode\n\n\nA device that allows data to flow in only one direction.\n\n\n\
        \n\nData In Transit\n\n\nInformation that is being conveyed across a communication\
        \ medium.\n\n\n\n\nData In Use\n\n\nInformation that has been decrypted for\
        \ processing by a system.\n\n\n\n\nData Remanence\n\n\nResidual information\
        \ remaining on a device or storage media after clearing or sanitising the\
        \ device or media.\_ Sometimes described as data persistence.\n\n\n\n\nData\
        \ Spill\n\n\nAn information security incident that occurs when information\
        \ is transferred between two security domains by an unauthorised means.\_\
        \ This can include from a classified network to a less classified network\
        \ or between two areas with different need-to-know requirements.\n\n\n\n\n\
        Declassification\n\n\nA process whereby information is reduced to an unclassified\
        \ state. Subsequently an administrative decision can be made to formally authorise\
        \ its release into the public domain.\n\n\n\n\nDegausser\n\n\nAn electrical\
        \ device or permanent magnet assembly which generates a coercive magnetic\
        \ force to destroy magnetic storage patterns in order to sanitise magnetic\
        \ media.\n\n\n\n\nDelegate\n\n\nA person or group of personnel who may authorise\
        \ noncompliance with requirements in this manual on the specific authority\
        \ of the agency head.\n\n\n\n\nDemilitarised Zone\n\n\nA small network with\
        \ one or more servers that is kept separate from an agency\u2019s core network,\
        \ either on the outside of the agency\u2019s firewall, or as a separate network\
        \ protected by the agency\u2019s firewall.\_ Demilitarised zones usually provide\
        \ public domain information to less trusted networks, such as the Internet.\n\
        \n\n\n\nDeny list\n\n\nA set of items to be excluded, blocked or prevented\
        \ from execution. A deny list can also be known as a Block List. It is the\
        \ opposite of an allow list which confirms that items are acceptable.\n\n\n\
        \n\nDepartment\n\n\nTerm used to describe Public Service Departments and Non-Public\
        \ Service Departments within the state sector.\nRefer State Services Commission\
        \ list of Central Government Agencies \u2013 Central government organisations\
        \ - Te Kawa Mataaho Public Service Commission\n\n\n\n\nDevice Access Control\
        \ Software\n\n\nSoftware that can be installed to restrict access to communications\
        \ ports such as USB, Serial HDMI and Ethernet Ports. Device access control\
        \ software can either block all access to a communications port or allow access\
        \ using an allow listing approach based on device types, manufacturer\u2019\
        s identification, or even unique device identifiers.\n\n\n\n\nDevOps\n\n\n\
        DevOps is a set of practices that combines software development (Dev) and\
        \ IT operations (Ops). It aims to shorten the systems development life cycle\
        \ and provide continuous delivery with high software quality.\_\n\n\n\n\n\
        Diffie-Hellman Groups\n\n\nA method used for specifying the modulus size used\
        \ in the hashed message authentication code algorithms.\_ Each DH group represents\
        \ a specific modulus size.\_ For example, group 2 represents a modulus size\
        \ of 1024 bits.\n\n\n\n\nDirect Control\n\n\nIn relation to the NZISM, Direct\
        \ Control is the immediate and continuous physical and logical control, responsibility\
        \ for, and operation of agency information systems and data. See also Indirect\
        \ Control.\n\n\n\nDomain-based Message Authentication, Reporting, and Conformance\n\
        \nDomain-based Message Authentication, Reporting, and Conformance is a scalable\
        \ mechanism by which a mail-originating organization can express domain-level\
        \ policies and preferences for message validation, disposition, and reporting,\
        \ that a mail-receiving organization can use to improve mail handling.\n\n\
        \n\nDomainKeys Identified Mail\n\nDomainKeys Identified Mail defines a mechanism\
        \ by which email messages can be cryptographically signed, permitting a signing\
        \ domain to claim responsibility for the introduction of a message into the\
        \ mail stream.\_ Message recipients can verify the signature by querying the\
        \ signer's domain directly to retrieve the appropriate public key, and thereby\
        \ confirm that the message was attested to by a party in possession of the\
        \ private key for the signing domain.\n\n\n\n\nDual-Stack Device\n\n\nA product\
        \ that implements both IP version 4 and 6 protocol stacks.\n\n\n\n\nEmanation\
        \ Security\n\n\nThe counter-measures, techniques and processes employed to\
        \ reduce classified emanations from a facility and its systems to an acceptable\
        \ level. Emanations can be in the form of RF energy, sound waves or optical\
        \ signals.\n\n\n\n\nEmergency Access\n\n\nThe process of a system user accessing\
        \ a system that they do not hold appropriate security clearances for due to\
        \ an immediate and critical emergency requirement.\n\n\n\n\nEmergency Situation\n\
        \n\nA situation requiring the evacuation of a site.\_ Examples include fires\
        \ and bomb threats.\n\n\n\n\nEncapsulating Security Payload\n\n\nA protocol\
        \ used for encryption and authentication within IPSec.\n\n\n\n\nEncryption\n\
        \n\nThe transformation of data from plaintext (recognisable/readable data)\
        \ to ciphertext (encrypted and not readable) using a cryptographic key.\n\
        Data is encrypted using an encryption key to produce ciphertext and decrypted\
        \ to plaintext using a decryption key.\_ These keys may be the same (symmetric\
        \ encryption) or two different keys (asymmetric encryption).\nEncryption alone\
        \ does not prevent interference or unauthorised access but denies the intelligible\
        \ content to unauthorised individuals, organisations or other would-be interceptors.\n\
        \n\n\n\nEndorsement\n\n\nCertain information may bear an endorsement marking\
        \ in addition to a security classification. Endorsement markings are not security\
        \ classifications in their own right and must not appear without a security\
        \ classification. Endorsement markings are warnings that the information has\
        \ special requirements in addition to those indicated by the security classification\
        \ and should only be used when there is a clear need for special care.\nEndorsement\
        \ markings may indicate:\n\nthe specific nature of information;\ntemporary\
        \ sensitivities;\nlimitations on availability; or\nhow recipients should handle\
        \ or disclose information.\n\n\n\n\n\nEscort\n\n\nAn individual who supervises\
        \ visitors to secure areas to ensure uncleared visitors are not exposed to\
        \ classified information, conversations equipment and other classified materials.\
        \ Such visitors may include maintenance staff, IT contractors and building\
        \ inspectors.\n\n\n\n\nEvaluation Assurance Level\n\n\nA numeric representation\
        \ of the security functionality of a product gained from undertaking a Common\
        \ Criteria evaluation. Each EAL comprises a number of assurance components,\
        \ covering aspects of a product\u2019s design, development and operation.\
        \ The range covers EAL0 (lowest) to EAL7 (highest).\n\n\n\n\nException\n\n\
        \nThe 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.\n\n\n\n\nExceptions and Waivers\n\n\nAn exception is NOT the\
        \ same as a waiver.\_ An exception means that the requirement need not be\
        \ followed.\_ A waiver means that some alternative controls or conditions\
        \ are implemented.\n\n\n\n\nFacility\n\n\nAn area that facilitates government\
        \ business.\_ For example, a facility can be a building, a floor of a building\
        \ or a designated area on the floor of a building.\n\n\n\n\nFilter\n\n\nA\
        \ device that manages or restricts the flow of data in accordance with a security\
        \ policy.\n\n\n\n\nFinder\n\n\nAn individual or organisation that reports\
        \ a vulnerability under an agency's VDP.\n\n\n\n\nFirewall\n\n\nA network\
        \ protection device that filters incoming and outgoing network data, based\
        \ on a series of rules.\n\n\n\n\nFirmware\n\n\nSoftware embedded in a hardware\
        \ device.\n\n\n\n\nFlash Memory Media\n\n\nA specific type of EEPROM.\n\n\n\
        \n\nFly Lead\n\n\nA cable that connects IT equipment to the fixed infrastructure\
        \ of the facility. For example, the cable that connects a workstation to a\
        \ network wall socket.\n\n\n\n\nForeign National\n\n\nA person who is not\
        \ a New Zealand citizen.\n\n\n\n\nForeign System\n\n\nA system that is not\
        \ owned and operated by the New Zealand Government.\n\n\n\n\nFunctional Segregation\n\
        \n\nSegregation based on the device function or intended function.\n\n\n\n\
        \nGateway\n\n\nConnections between two or more systems from different security\
        \ domains to allow access to or transfer of information according to defined\
        \ security policies. Some gateways can be automated through a combination\
        \ of physical or software mechanisms. Gateways are typically grouped into\
        \ three categories: access gateways, multilevel gateways and transfer gateways.\n\
        \n\n\n\nGeneral User\n\n\nA system user who can, with their normal privileges,\
        \ make only limited changes to a system and generally cannot bypass system\
        \ security.\n\n\n\n\nGovernment Chief Information Officer\n\n\nGovernment\
        \ Chief Information Officer (GCIO) is a role undertaken by the Chief Executive\
        \ of the Department of Internal Affairs in order to provide leadership on\
        \ ICT matters within the NZ Government.\n\n\n\n\nHardware\n\n\nA generic term\
        \ for any physical component of information and communication technology,\
        \ including peripheral equipment and media used to process information.\n\n\
        \n\n\nHardware Security Module\n\n\nHardware Security Modules (HSMs) are a\
        \ device, card or appliance usually installed inside of a PC or server to\
        \ provide cryptographic functions. HSM\u2019s are usually physically and electronically\
        \ hardened to reduce the possibility of tampering or other interference.\n\
        \n\n\n\nHash\n\n\nA hash is the result of a one-way, cryptographic function\
        \ that converts a data string of any length into a unique fixed-length bit\
        \ string.\_ Typically applied to passwords and messages to protect against\
        \ loss and/or add resistance to attacks.\nHashing algorithms or functions\
        \ are often are designed as a one-way cryptographic transformation so that\
        \ it's impossible to reverse the hash process and reconstitute the original\
        \ string.\nThe values returned by a hash function are variously described\
        \ as hash values, hash codes, digests, or simply hashes.\nOne common use of\
        \ a hash is a data structure called a hash table, widely used in computer\
        \ software for indexing and rapid retrieval of database elements.\nNote that\
        \ a hash is not the same as data encryption although it does utilise cryptographic\
        \ functions.\nSee also Checksum.\n\n\n\n\nHash Value\n\n\nSee Hash.\_ Also\
        \ known as \"message digest\".\n\n\n\n\nHashed Message Authentication Code\
        \ Algorithms\n\n\nIn cryptography, a keyed-hash message authentication code\
        \ (HMAC) is a specific type of message authentication code (MAC) using a cryptographic\
        \ hash function and a cryptographic key.\n\n\n\n\nHigh Assurance\n\n\nHigh\
        \ Assurance is a generic term encompassing Common Criteria Evaluation Assurance\
        \ Levels (EAL) 5, 6 and 7. Alternatively refers to the independent (unrelated)\
        \ ASD High Assurance Evaluation Scheme.\n\n\n\n\nHigh Assurance Cryptography\n\
        \n\nThe U.S. ranks cryptographic products and algorithms through a certification\
        \ programme and categorising the products and algorithms into product types.\
        \ Product types are defined in the US National Information Assurance Glossary\
        \ (CNSSI No. 4009) which defines Type 1 and 2 products, and Type 3 and 4 algorithms.\
        \ Type 1 products are used to protect systems requiring the most stringent\
        \ protection mechanisms.\n\n\n\n\nHigh Assurance Cryptographic Equipment (HACE)\n\
        \n\nThe equivalent to United States Type 1 cryptographic products & equipment.\
        \ Previously described as High Grade Cryptographic Products & Equipment, the\
        \ term HACE includes classified CCI, and other GCSB-Specific devices.\n\n\n\
        \n\nHybrid Hard Drives\n\n\nNon-volatile magnetic media that use a cache to\
        \ increase read and write speeds and reduce boot time.\_ The cache is normally\
        \ flash memory media or battery backed RAM.\n\n\n\n\nIncident Response Plan\n\
        \n\nA plan for responding to information security incidents as defined by\
        \ the individual agency.\n\n\n\n\nIdentity and Access Management\n\n\nIdentity\
        \ and Access Management (IAM) is a framework of business processes, policies\
        \ and technologies that enable and support the management of electronic or\
        \ digital identities, authorisation, privileges and access to organisational\
        \ resources.\nIdentity management deals with attributes related to a user\
        \ (including people, machines, devices and systems).\_Access Management applies\
        \ organisation processes, policies and security to enable and manage access.\_\
        The two aspects are highly interdependent and are most effectively managed\
        \ conjointly.\_An IAM framework is a key element in Privileged Access Management\
        \ (PAM) and Zero Trust architectures.\n\n\n\n\nImage persistence / Image retention\n\
        \n\nLCD/LED/OLED and plasma technologies can be susceptible to persistence\
        \ or retention of an image or \u201Cghost\u201D image on the screen.\_ This\
        \ can also led to screen burn-in, as can occur in traditional CRT monitors.\n\
        \n\n\n\nIndirect Agency Control\n\n\nIn relation to the NZISM, Indirect agency\
        \ control is when information, services or operations are not under the direct\
        \ control of the agency. This may be through outsourcing of, ICT management\
        \ or services, use of third party facilities such as data centre co-locations,\
        \ or consumption of cloud services. See also Direct Control.\n\n\n\n\nInformation\n\
        \n\nAny 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.\n\n\n\n\nInformation Asset\n\n\nInformation asset\
        \ is any information or related equipment has value to an 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\n\n\n\n\nInformation and Communications Technology (ICT)\n\
        \n\nInformation and Communications Technology (ICT) includes:\n\nInformation\
        \ management;\nTechnology infrastructure; and\nTechnology-enabled business\
        \ processes and services\n\n\n\n\n\nInformation Security\n\n\nMeasures relating\
        \ to the confidentiality, availability and integrity of information that is\
        \ processed, stored and communicated by electronic or any other means.\n\n\
        \n\n\nInformation Security Incident\n\n\nAn occurrence or activity that may\
        \ threaten the confidentiality, integrity or availability of a system or the\
        \ information stored, processed or communicated by it or by any other process\
        \ or system and processes.\n\n\n\n\nInformation Security Policy\n\n\nA high-level\
        \ document that describes how an agency protects its information. The CSP\
        \ is normally developed to cover all systems and can exist as a single document\
        \ or as a set of related documents.\n\n\n\n\nInformation Technology Security\
        \ Manager\n\n\nITSMs 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 responsibility of ITSMs is\
        \ the administrative controls relating to information security within the\
        \ agency.\n\n\n\n\nInfrared Device\n\n\nA device such as a mouse, keyboard,\
        \ pointing device, laptop and smart phone that have an infrared communications\
        \ capability.\n\n\n\nInfrastructure-as-a-Service\n\nInfrastructure-as-a-Service\
        \ is where the cloud service provider offers access to a variety of capabilities\
        \ and technologies on demand. Service is provided either over the public Internet\
        \ or through dedicated connections.\n\n\n\n\nInternet Key Exchange Extended\
        \ Authentication\n\n\nUsed to provide an additional level of authentication\
        \ by allowing IPSec gateways to request additional authentication information\
        \ from remote users. As a result, users are forced to respond with credentials\
        \ before being allowed access to the connection.\n\n\n\n\nIntrusion Detection\
        \ System\n\n\nAn automated system used to identify an infringement of security\
        \ policy from an internal or external source.\n\n\n\n\nIntrusion Prevention\
        \ System\n\n\nA security device, resident on a specific host, which monitors\
        \ system activities for malicious or unwanted behaviour and can react in real-time\
        \ to block or prevent those activities.\n\n\n\nInverse split tunnelling\n\n\
        A particular configuration of split tunnelling where only specifically authorised\
        \ and trusted systems are able to be simultaneously communicated with via\
        \ the external network connection.\n\n\n\n\nIP Security\n\n\nA suite of protocols\
        \ for secure IP communications through authentication or encryption of IP\
        \ packets including protocols for cryptographic key establishment.\n\n\n\n\
        \nIP Telephony\n\n\nThe management and transport of voice communications over\
        \ IP networks. Also described as Voice Over IP (VOIP).\n\n\n\n\nIP Version\
        \ 6\n\n\nA protocol used for communicating over a packet switched network.\_\
        \ Version 6 is the successor to version 4 which is widely used on the Internet.\_\
        \ The main change introduced in version 6 is a greater add"
