Fotolia
How criticality analysis benefits from an entropy engineer
NIST published 'Criticality Analysis Process Model: Prioritizing Systems and Components' to guide organizations when prioritizing systems. Discover the key processes with Judith Myerson.
NIST recently published a new internal report, "Criticality Analysis Process Model: Prioritizing Systems and Components," which describes a model for the criticality analysis process as "a structured method of prioritizing programs, systems, and components based on their importance to the goals of an organization and the impact that their inadequate operation or loss may present to those goals."
Criticality analysis can be used by organizations to better understand the systems that are essential to their operation, as well as to identify those essential systems and their components. NIST divides the model into five processes.
- Process A: Define a criticality analysis procedure;
- Process B: Conduct a program-level criticality analysis;
- Process C: Conduct a system/subsystem-level criticality analysis;
- Process D: Conduct a component/subcomponent-level criticality analysis; and
- Process E: Conduct a detailed review of criticality for processes B, C and D.
Organizations are expected to complete process A first, and then move onto processes B, C and D in any order or at the same time. However, as process E uses input from processes B, C and D to finalize criticality prioritization, it must be done last.
The NIST report describes all the roles in the processes; processes D and E show how an entropy analyst or entropy engineer can contribute to the overall success of the process.
Criticality analysis process roles
A project manager should lead the procedure analysis phase -- process A -- and determines whether the documented procedures for criticality analysis exist or not. If the procedures exist, then process A can end. If the procedures don't exist or don't satisfy the needs of the criticality analysis, the program manager must delegate those responsibilities to a business analyst who is expected to produce documented procedures tailored to the needs of the organization.
The program manager is responsible for performing the program-level analysis phase -- process B. The program manager helps define the program and identify the key activities that are necessary to ensure the main goals and objectives of the program are met. Much of this process may already be conducted as part of strategic planning or project planning processes.
The business analyst and lead security engineer may serve as co-leaders to define the operating states and assign baseline criticality levels to workflow paths. They provide input on criticality analysis procedures from process A, such as:
- laws, regulations, directives and strategic plans;
- risk management strategies;
- contingency plans;
- past audit reports;
- budgets; and
- project plans.
The lead system architect should manage the system-level analysis phase -- process C -- to review and analyze the system or subsystem from the point of view of its criticality to the overall organizational goals. This process may also be conducted as part of project planning, system design and acquisition processes.
The lead security engineer can serve as a co-leader when assigning baseline criticality levels to systems or subsystems, and the business analyst is accountable to the lead systems architect. The input they provide must include documented criticality analysis procedures from process A, final criticality levels of activities, and workflow paths of the program -- from process B -- and others, such as:
- risk management strategies;
- contingency plans; and
- Federal Information Processing Standard 199 impact level of either low, moderate or high.
The lead system engineer should oversee the component-level analysis phase -- process D -- to review and analyze a specific system to identify criticality components or subcomponents. Much of this process is conducted as part of the system architecture and design processes.
The lead system engineer can serve as a co-leader to define operating states and assign baseline criticality levels to components or subcomponents. The system analyst is accountable to the lead system engineer, and they provide input on the criticality levels of systems or subsystems, such as:
- laws, regulations and directives;
- existing documentation;
- system design processes; and
- architecture diagrams.
The lead system architect should drive the criticality analysis review phase -- process E -- to identify interactions, intersections, connections and dependencies across processes B, C and D. The architect should consider mitigation strategies to improve criticality analysis scores. The lead system engineer should work in partnership with the lead security engineer and the program manager to ensure communication and collaboration across processes B, C and D. The team provides input, including:
- existing documentation, system design processes and functional requirements;
- security requirements;
- root cause analysis and hazard analysis;
- risk assessment, threat assessment and vulnerability assessment;
- impact analysis; and
- privacy risk assessment.
Entropy analyst/engineer
The main benefit of adding an entropy analyst/engineer to the criticality analysis team in process D and process E is to include analysis of the sources of entropy used in a specific system and in a criticality analysis review. The analyst/engineer can identify entropy sources, including noise sources that are used to generate cryptographic keys from random data.
Only independent noise sources, such as thermal noise and mouse movements, are considered valid entropy sources. The entropy analyst/engineer should ensure proper testing and validation of entropy sources for a system or component that would contribute to more favorable criticality analysis scores, risk management, security requirements, mitigation strategies, contingency plans and acquisition processes.
NIST's report on the Criticality Analysis Process Model is a good resource to understand how to model criticality, as well as to understand why an entropy analyst/engineer should be included on a criticality analysis team as the criteria for testing and validating entropy sources continue to evolve and the technology for detecting and measuring noise sources improves.
