How entropy sources interact with security and privacy plans

In a new draft document, "Risk Management Framework for Information Systems and Organizations," NIST provides important guidance for information security professionals responsible for managing risks related to information systems. This framework can be especially helpful when considering how to use entropy sources to secure systems and networks.

NIST divides a system lifecycle with its Risk Management Framework, which includes seven steps: prepare, categorize, select, implement, assess, authorize and monitor.

Because each step begins with a summary of tasks and outcomes, organizations executing the Risk Management Framework (RMF) for the first time should perform these steps in sequential order. However, if the last step -- monitoring -- reveals changes in security and privacy controls, then organizations need to circle back to adjust the framework. The security and privacy controls should be system-specific, which is common for multiple systems or a hybrid setup.

Entropy source controls should be included in a security and privacy plan, as the controls are dependent on entropy sources to generate cryptographic keys from random bits. Entropy can be obtained from physical sources, such as keyboard strokes, mouse movements and hard-disk access times, as well as from a cloud-based Entropy as a Service (EaaS) server.

EaaS can be useful for virtual machines, clouds and containers in which there is no direct user activity. The server can then send entropy to a client who has requested a public key, and a random value that the server generates can then be signed with the EaaS private key.

In this tip, we'll review each step of the NIST RMF lifecycle, with special attention on how entropy source controls fit in.

The first step is prepare. Preparation, in this case, includes identifying, documenting and publishing common controls that organizational systems can inherit. A security and privacy plan should contain a description of a common control implementation, including the requirements, inputs and expected output behavior of entropy source controls. Stakeholder assets that need to be protected, such as physical keyboards and mice, should be identified and prioritized by system level.

At the organizational level, a senior official for risk management and a senior agency official for privacy should be primarily responsible for the risk management effort. However, at the system level, the system owner will most likely be more familiar with the system-specific security and privacy controls, including entropy source controls.

The next step is categorize, where adverse impacts to organizational operations and assets, such as hackers accessing random bits from keyboards and mice, are determined. The system owner has the primary responsibility of documenting system descriptions and categorizations and should be familiar with the different types of entropy sources. An authorizing official and senior agency official for privacy should be responsible for reviewing and approving security categorization -- the system owner should share the supporting documents on entropy sources with these officials.

Next is the select step, where security and privacy controls -- including entropy source controls -- are documented in the security and privacy plan. The plan must be reviewed and approved by an authorizing official while the system owner and common control provider select and tailor the controls, including those of validated entropy sources.

The implement step then follows, and it is where controls specified in the system security privacy plans are deployed and updated. Deployment includes installing system components that have been tested, evaluated or validated by approved third-party assessment facilities, such as the NIST Cryptographic Module Validation Program Testing Laboratories and the National Voluntary Laboratory Accreditation Program -- accredited laboratories on testing and validation of entropy sources. With this, an initial configuration baseline for the system can be established and the system owner and common control provider can assume responsibility for the implementation.

The next step is assess, which is when an assessor or assessment team is selected to conduct control assessments and to develop, review, and approve security and privacy assessment plans. Controls should be assessed in accordance with security privacy assessment plans, and remediation actions must be taken to address deficiencies in the controls.

A plan of action and milestones detailing remediation plans for unacceptable risks identified in security and privacy assessment reports must be developed. The control assessor is primarily responsible for the assessment, and the system owner, common control provider and authorizing official should take a lesser role.

The authorize step is next. This is where a senior management official determines if the security and privacy risk to organizational assets -- based on the operation of a system or the use of common controls -- is acceptable.

This step starts by sending an authorization package to an authorizing official who determines its risk tolerance. Based on the risk responses -- either high or low -- the common controls are approved or denied; such controls include Authorization to Operate, Interim Authorization to Operate, Denial of Authorization to Operate and Interim Authorization to Test. Authorization decisions, significant vulnerabilities and risks must be reported to an authorizing official.

The last step in the process is monitor, where the information system and environment or operations are monitored to ensure that ongoing assessments of control effectiveness are based on the monitoring strategy. Risk responses and authorization updates must be documented and updated, and reports on the security and privacy posture of the organization must be sent to the authorizing official, senior leaders and executives.

Authorizing officials further conduct ongoing authorizations, such as approve, deny or interim, while communicating the changes in risk determination -- from either high to low or low to high -- and the acceptance of authorization decisions on entropy sources and other security and privacy controls. As expected, a system disposal strategy should be developed and implemented.

Overall, entropy source controls should be added to a security and privacy plan, as high entropy controls are needed for resource-constrained assets that require very little user activities, particularly in virtual environments.