Review NIST Special Publication (SP) 800-171 and 172 and identify alignment areas with Mojaloop

[godfreykutumela]

Goal:

As a OSS Developer

I want to review NIST Special Publication (SP) 800-171 and 172

so that I can identify alignment areas with Mojaloop.

Acceptance Criteria:

• [ ] TBD

Complexity: <Low Uncertainty: Low

---

Tasks:

• [x] Review 171 [ @godfreykutumela ]
• [ ] Review 172 [ @godfreykutumela ]
• [ ] Summary deferences and identify alignment areas [ @godfreykutumela ]
• [ ] Put a plan of action to align where feasible @godfreykutumela ]

Done

• [ ] Acceptance Criteria pass

Pull Requests:

• [ ] TBD

Follow-up:

• N/A

Dependencies:

• N/A

Accountability:

• Owner: @godfreykutumela
• QA/Review: @godfreykutumela

[godfreykutumela]

I have reviewed NIST 171 and the only section I recommend we baseline against is section 3.3 AUDIT AND ACCOUNTABILITY. To be further explored as part of https://github.com/mojaloop/project/issues/2029 NIST.SP.800-171r2.pdf

[godfreykutumela]

Review Summary

NIST 172 enhanced security requirements focus on the following key elements, which are essential to addressing the APT:

• Applying a threat-centric approach to security requirements specification;
• Employing system and security architectures that support logical and physical isolation using system and network segmentation techniques, virtual machines, and containers;16
• Implementing dual authorization controls for the most critical or sensitive operations;
• Limiting persistent storage to isolated enclaves or domains;
• Implementing a comply-to-connect approach for systems and networks;
• Extending configuration management requirements by establishing authoritative sources for addressing changes to systems and system components;
• Periodically refreshing or upgrading organizational systems and system components to a known state or developing new systems or components;
• Employing a security operations centre with advanced analytics to support continuous monitoring and protection of organizational systems; and
• Using deception to confuse and mislead adversaries regarding the information they use for decision-making, the value and authenticity of the information they attempt to exfiltrate, or the environment in which they are operating.

The above recommendations have to be addressed as part of switch architecture and hub operational processes in order to fully embrace the APT requirements of NIST 172.

Flexibility in Applying NIST 172

Certain enhanced security requirements may be too difficult or cost-prohibitive for organizations to meet internally. In these situations, the use of external service providers21 can be leveraged to satisfy the requirements. The services include but are not limited to:

• Threat intelligence
• Threat and adversary hunting
• System monitoring and security management
• IT infrastructure, platform, and software services
• A threat, vulnerability, and risk assessments
• Response and recovery
• Cyber resiliency25

Finally, specific implementation guidance associated with the enhanced security requirements is beyond the scope of this publication. Organizations have maximum flexibility in the methods, techniques, technologies, and approaches used to satisfy the enhanced security requirements

[godfreykutumela]

IAM requirements in section 3.5 should be referenced as part of our IAM architecture.

• Identify and authenticate [Assignment: organization-defined systems and system components] before establishing a network connection using bidirectional authentication that is cryptographically based and replay resistant. Cryptographically-based and replay-resistant authentication between systems, components, and devices addresses the risk of unauthorized access from spoofing (i.e., claiming a false identity). The requirement applies to client-server authentication, server-server authentication, and device authentication (including mobile devices). The cryptographic key for authentication transactions is stored in suitably secure storage available to the authenticator application (e.g., keychain storage, Trusted Platform Module [TPM], Trusted Execution Environment [TEE], or secure element). Mandating authentication requirements at every connection point may not be practical, and therefore, such requirements may only be applied periodically or at the initial point of network connection.

• Employ automated mechanisms for the generation, protection, rotation, and management of passwords for systems and system components that do not support multifactor authentication or complex account management. In situations where static passwords or personal identification numbers (PIN) are used (e.g., certain system components do not support multifactor authentication or complex account management, such as separate system accounts for each user and logging), automated mechanisms (e.g., password managers) can automatically generate, rotate, manage, and store strong and different passwords for users and device accounts. For example, a router might have one administrator account, but an organization typically has multiple network administrators. Therefore, access management and accountability are problematic. A password manager uses techniques such as automated password rotation (in this example, for the router password) to allow a specific user to temporarily gain access to a device by checking out a temporary password and then checking the password back in to end the access. The password manager simultaneously logs these actions. One of the risks in using password managers is that an adversary may target the collection of passwords that the device generates. Therefore, it is important that these passwords are secured. Methods for protecting passwords include the use of multi-factor authentication to the password manager, encryption, or secured hardware (e.g., a hardware security module).

• Employ automated or manual/procedural mechanisms to prohibit system components from connecting to organizational systems unless the components are known, authenticated, in a properly configured state, or in a trust profile.** Identification and authentication of system components and component configurations can be determined, for example, via a cryptographic hash of the component. This is also known as device attestation and known operating state or trust profile. A trust profile based on factors such as the user, authentication method, device type, and physical location is used to make dynamic decisions on authorizations to data of varying types. If device attestation is the means of identification and authentication, then it is important that patches and updates to the device are handled via a configuration management process such that the patches and updates are done securely and do not disrupt the identification and authentication of other devices.