Access to information and systems is securely controlled and only provided to authorised entities, at all times.

]]> Identification and authentication requirements are implemented in order to provide a secure means of access to information and systems.

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

]]> Controls in these Identification Standards related to identification and authentication are provided to facilitate credential provider’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.

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

]]> 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 – Enterprise Systems Security and Chapter 23 – Public Cloud Security.

]]> The New Zealand Government publishes four Identification Standards:

]]> The first three standards are relevant to Relying Parties; all standards are relevant to Credential Providers.

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

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

]]> Authentication mechanisms are invariably described in terms of factors of authentication as follows:

  • Something the entity has – the possession factor.
  • Something the entity knows – the knowledge factor.
  • Something the entity is or does – the biometric factor.
]]> 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.

]]> There are two distinct roles performed for identification management – a credential provider, and a relying party.

  • Credential 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.
  • Relying parties provide the services that are being accessed by the authorised users (entities) and systems. Relying parties use an entities’ credentials to ensure the right authorisations are in place prior to access of data or systems.

NB: 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.

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

]]> 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.
]]> Zero Trust (ZT) is a security concept based around a central principle of ‘never trust, always verify’, being maintained through enforcing accurate, least privilege per-request access decisions on systems, services and networks.

]]> ZT means continuous verification and enforcement of access controls, regardless of location. This includes continuous authentication of entities on internal network and zones.

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

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

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

]]> Successful implementation of Access Controls for ZT at an organisation level can be supported by the following methods:

  • Implementation of Multi-Factor Authentication (MFA).
  • Use of adaptive authentication based on contextual factors (e.g. location, device, behaviour).
  • Least Privilege Access – enforced at a micro level within systems and networks. This may also include just-in-time (JIT) delivery of privileges.
  • Centralisation of user accounts and accesses.
  • Passwordless authentication models adopted within organisations.
]]> 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
]]> Relevant PSR requirements can be found at:

Reference Title Source
PSR Mandatory Requirements

GOV5, GOV6, GOV7, 

INFOSEC1, INFOSEC2, INFOSEC3, INFOSEC4,

PERSEC1, PERSEC2, PERSEC3, PERSEC4,

PHYSEC1, PHYSEC2

Home | Protective Security Requirements

Security governance (GOV) | Protective Security Requirements

Information security (INFOSEC) | Protective Security Requirements

Personnel security (PERSEC) | Protective Security Requirements

Physical security (PHYSEC) | Protective Security Requirements
]]> Developing policies and procedures will ensure consistency in managing identification, authentication and authorisation across agency systems. Refer also to Section 16.4 – Privileged Access Management.

]]> Agencies MUST:

  • develop, implement and maintain a set of policies and procedures covering all system users’:
    • identification;
    • authentication; 
    • authorisation;
    • privileged access identification and management; and
  • make their system users aware of the agency’s policies and procedures.
]]> 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.

]]> Agencies SHOULD design and implement Zero Trust principles and architecture to strengthen identification management.

]]> Having uniquely identifiable system users ensures accountability.

]]> Agencies MUST ensure that all system users are:

  • uniquely identifiable; and
  • authorised and authenticated on each occasion that access is granted to a system.
]]> 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.

]]> Agencies MUST NOT use shared credentials to access accounts.

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

]]> Agencies SHOULD NOT use shared credentials to access accounts.

]]> Agencies may have a compelling business reason for the use of shared accounts.  These may include anonymous, guest and temporary employee credentials.

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

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

]]> A personal identification number (PIN) is typically short in length and employs a small character set, making it susceptible to brute force attacks.

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

]]> Agencies MUST NOT use a numerical password (or personal identification number) as the sole method of authenticating a system user to access a system.

]]> Agencies SHOULD use multi-factor authentication (MFA) when identifying and authenticating system users.

]]> Centralising authentication and the reliance on single credentials to access multiple systems and wider organisations (eg, SSO, FIM) enhances an organisation’s security posture through:

  • centralisation to control access (joiners, movers, leavers);
  • reducing risk of password fatigue;
  • enforcing strong access controls;
  • enforcing password policies; and
  • reducing the risk of misconfiguration.
]]> 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.

]]> Agencies SHOULD assess and determine the risk of centralised access management systems, including SSO, to safely manage integration into systems and when using FIM.

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

]]> Passwords have traditionally been the terminology used for the memorised secrets allowing access and authorisation onto systems. The term ‘passphrases’ is often referred to in place of ‘passwords’, as it denotes longer (more secure), easier to remember memorised secrets.

Where the NZISM references passwords, it equally applies to passphrases.

]]> Passwords are subject to three primary groups of risks:

1.       Intentional sharing.

2.       Theft, loss or compromise.

3.       Guessing and cracking.

]]> Associated with these risk groups are four principal methods of attacking passwords:

  1. Interactive attempts including brute force attacks or some knowledge of the user or organisation.
  2. Obtaining through social engineering or phishing.
  3. Compromising through oversight, observation, use of keyloggers, cameras etc.
  4. Decryption of network traffic interception, misconfiguration, data capture etc.
]]> 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.

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

]]> Mandatory training for all employees, including senior management, on these policies is essential to manage and mitigate risks associated with password attacks.

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

]]> Ensure a balance of security and usability considerations when deciding on implementing a password expiry policy for the organisation.

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

]]> Agencies MUST ensure adequate password policies are implemented and enforced across all systems.

]]> Agencies MUST implement a password policy enforcing at least annual password changes on systems that have not implemented MFA or passwordless authentication.

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

]]> To ensure security of systems are not weakened through authentication mechanisms, at a minimum, agencies MUST:

  • apply MFA appropriately (refer to controls in Section 16.7);
  • ensure authentication secrets (including passwords) are securely stored;
  • remove knowledge-based questions from authentication process (eg, dog’s name, first school etc.);
  • new passwords are screened to reduce the likelihood of previously compromised passwords;
  • remove hints from authentication process; and
  • change passwords when a suspected or known compromise of an account has occurred.
]]> Agencies MUST NOT:

  • allow predictable reset passwords;
  • store passwords in the clear on the system; and
  • reuse passwords when resetting multiple accounts.
]]> 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).

]]> When creating password policies, agencies SHOULD consider implementing annual password changes.

]]> 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’s security and authentication requirements.

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

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

]]> Agencies MUST ensure that system authentication data is protected when in transit on organisation networks or All-of-Government systems.

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

]]> Password and other authentication secrets MUST be hashed before storage using an approved cryptographic protocol and algorithm. See Chapter 17 – Cryptography.

]]> Passwords and other authentication secrets MUST be stored securely including being:

  • salted (32 bits or more),
    • salts should be unique to each password and should be randomly generated.
  • hashed (HMAC using SHA-2/3), and
  • “stretched” (such as PBKDF2 with at least:
    • 600k iterations with internal hash function of HMAC-SHA-256; or
    • 210k iterations with internal hash function of HMAC-SHA-512).
]]> 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.

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

]]> Agencies using NZEO systems SHOULD ensure that identification includes specific nationality for all foreign nationals, including seconded foreign nationals.

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

This evidence could be in the form of:

  •          the system user physically presenting themselves and their security pass to service desk personnel who then reset their password;
  • physically presenting themselves to a known authorised colleague who uses an approved online tool to reset their password; or
  • providing a MFA code.
]]> 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.

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

]]> Where passwords are not set by the account holder, agencies MUST use temporary passwords when resetting system user accounts.

]]> Agencies SHOULD NOT use single factor authentication when changing users’ Multi-Factor Authentication details.

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

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

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

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

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

]]> Agencies using password managers SHOULD consider the use of MFA to access the password manager.

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

]]> Passwordless authentication provides additional security mechanisms by moving away from ‘something you know’ and placing emphasis on other verification factors such as ‘something you have’ or ‘something you are’. These alternative authentication models can rely on other factors such as something you are or something you have (eg, biometrics, tokens, and authentication applications).

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

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

]]> Passwordless authentication does not mean ‘no authentication’.

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

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

]]> 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’s security and authentication requirements.

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

]]> Agencies MUST ensure authentication methods that are susceptible to replay attacks are disabled.

]]> Agencies MUST disable LAN Manager for password authentication on workstations and servers.

]]> Developing a policy to automatically logout workstations after an appropriate time of inactivity will assist in preventing the compromise of unattended workstations.

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

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

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

]]> Screen and session locking will prevent access to an unattended workstation.

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

]]> 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.
]]> 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.
]]> Locking a user account after a specified number of failed logon attempts will reduce the success of brute force attacks.

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

]]> Suspending inactive accounts after a specified number of days will reduce the number of accounts that an attacker can target.

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

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

]]> Repeated account lockouts may be an indicator of attempted account compromise.

]]> Agencies SHOULD ensure that repeated account lockouts are investigated before reauthorising access.

]]> 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 “Splash Screen”, “Acceptable Use Policy” or “User Consent Screen”.

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

]]> Agencies SHOULD seek legal advice on the exact wording of logon banners.

]]> Agency logon banners SHOULD cover issues such as:

  • the system’s classification;
  • access only being permitted to authorised system users;
  • the system user’s agreement to abide by relevant security policies;
  • the system user’s awareness of the possibility that system usage is being monitored;
  • the definition of acceptable use for the system; and
  • legal ramifications of violating the relevant policies.
]]>