NIST SP 800-160

Define the problem space, mission needs, stakeholders, and constraints that drive the engineering of a trustworthy secure system, including security and resilience needs traceable to mission outcomes.

• Business and mission analysis report
• Stakeholder register with security interests
• Security and resilience needs statement
• Traceability to mission outcomes

• Security needs not traced to mission
• Stakeholder register missing security stakeholders
• Constraints undocumented

Develop and maintain an assurance case that argues, with evidence, that the system possesses claimed security properties.

• Assurance case document
• Claim and argument structure
• Evidence references
• Update log as system evolves

• No assurance case
• Claims without evidence
• Not updated after changes

Document trade-offs among security objectives, system performance, cost, and schedule, ensuring decisions are informed and approved by an appropriate authority.

• Trade-off study reports
• Decision logs with authority
• Approval signatures
• Rationale for each decision

• Trade-offs decided informally
• No approval
• Decisions not communicated to operators

Address human factors during engineering, including usability of security controls, error tolerance, and operator workload, to reduce the likelihood of human-induced compromise.

• Usability test reports for security functions
• Workload assessments
• Error analysis
• Design changes resulting from human factors review

• No usability testing of security functions
• Operators bypass controls due to friction
• Errors not analysed

Manage and control system elements and configurations over the life cycle, preserving security-relevant configuration integrity.

• Configuration management preserving security integrity

• Security-relevant configurations uncontrolled

Provide a structured framework for selecting a course of action among alternatives, accounting for security implications.

• Decision records accounting for security implications

• Decisions ignore security trade-offs

Generate, obtain, manage, and protect designated information, including security-relevant information, throughout the life cycle.

• Protection of security-relevant information

• Sensitive engineering info unprotected

Collect, analyze, and report data, including security measures, to support effective management and demonstrate product and process quality.

• Security measures and reporting

• No security measurement

Identify, analyze, treat, and monitor risks continually, including security risks to the system and its assets.

• Security risk register and treatment

• Security risks not managed continually

Provide the organization with necessary skilled and security-competent human resources and maintain their competencies.

• Security competency management records

• Security skills not maintained

Create the capability and assets to reuse knowledge, including security knowledge, across the organization.

• Security knowledge reuse assets

• Security knowledge not captured/reused

Assure that products, services, and processes, including their security characteristics, meet organizational quality objectives.

• Quality objectives including security characteristics

• Security excluded from quality management

Assess whether plans are aligned and feasible, and direct execution to meet objectives including security objectives.

• Assessment/control records covering security objectives

• Security objectives not tracked in project control

Produce and coordinate effective and workable project plans that incorporate security activities and resources.

• Project plans incorporating security activities/resources

• Security activities not planned/resourced

End the existence of a system element or system, securely handling data sanitization and residual security risks.

• Secure disposal and data sanitization records

• Residual data/risk on disposal

Sustain the capability of the system to provide a secure service, including security patching and configuration control.

• Security patching and configuration control in maintenance

• Maintenance erodes security posture

Use the system to deliver its services, including sustaining secure operation and managing operational security risks.

• Secure operation and operational risk management

• Operational security risks unmanaged

Generate system architecture alternatives and select an architecture that frames security concerns and protection capabilities.

• Architecture addressing security/protection capabilities

• Security not framed in architecture

Provide sufficient detailed data and information about the system and its elements to enable secure implementation.

• Design detail enabling secure implementation

• Security design detail insufficient

Define stakeholder protection needs and security requirements that the system must satisfy in its operational environment.

• Stakeholder protection needs and security requirements

• Protection needs undefined

Transform stakeholder protection needs into a technical view of security requirements for the system.

• System security requirements traceable to needs

• Security requirements not derived/traceable

Assure the effective application of the organization's quality and security processes to the project.

• Quality assurance of security processes

• Security processes not assured

Obtain a product or service in accordance with the acquirer's security requirements, including expressing security needs in the agreement.

• Acquisition agreements expressing security requirements

• Security needs absent from acquisition agreements

Provide an acquirer with a product or service that meets agreed security requirements.

• Supplier deliverables meeting agreed security requirements

• Supplied products not evidenced against security requirements

Provide and maintain the secure infrastructure and services needed to support the organization and projects.

• Secure infrastructure provisioning records

• Project infrastructure not secured

Define, maintain, and assure the availability of policies, processes, models, and procedures, including their security aspects, across the organization.

• Life cycle models/policies including security aspects

• Security not embedded in life cycle models

Initiate, sustain, and direct projects and ensure the necessary investment, including security investment, to meet organizational objectives.

• Security investment in portfolio decisions

• Security not funded in portfolio

Provide a rigorous basis of data and information, including security analyses, for technical understanding and decision making.

• Security analyses supporting decisions

• No security analysis basis for decisions

Realize a specified system element, incorporating secure development and supply chain considerations.

• Secure implementation and supply chain evidence

• Implementation not following secure practices

Synthesize a set of system elements into a realized system that satisfies security requirements and architecture.

• Integration preserving security requirements

• Integration introduces unmitigated risk

Establish a capability for the system to provide services, including security services, in the operational environment.

• Secure transition to operations evidence

• Security services not established at transition

Provide objective evidence that the system, when in use, fulfills its stakeholder protection needs in the intended environment.

• Validation that protection needs are met in use

• Protection needs not validated operationally

Provide objective evidence that the system fulfills its specified security requirements and characteristics.

• Verification evidence against security requirements

• Security requirements not verified

Establish configuration management to identify, control, and account for the configuration of system elements that influence security properties.

• Configuration management plan
• Baseline documentation
• Change control board records
• Configuration item register

• Plan exists but not used
• Baselines stale
• CCB does not review security changes

Provide independent quality assurance over engineering activities including security engineering tasks, with corrective action when deviations are found.

• QA plan
• Independent review reports
• Corrective action register
• QA closure evidence

• QA not independent
• Findings not closed
• Security tasks excluded from QA scope

Manage risks across the system life cycle including identification, analysis, treatment, monitoring, and communication of security and resilience risks.

• Risk management plan
• Risk register entries with security context
• Treatment decisions with rationale
• Monitoring and reporting records

• Risks not updated as system evolves
• Treatment decisions undocumented
• Communications to authorities missing

Define a system architecture that realises required security properties through identified principles, structures, and patterns, including trust boundaries and dependencies.

• Architecture description document
• Trust boundary diagrams
• Security pattern catalogue applied
• Dependency analysis

• No documented trust boundaries
• Security properties not realised in architecture
• Dependencies hidden

Develop a design that implements the architecture and specifies the components, interfaces, and security mechanisms required to satisfy system requirements.

• Design specification
• Component design documents
• Interface control documents with security parameters
• Mechanism selection rationale

• Security mechanisms unspecified
• Interfaces lack contract
• Design diverges from architecture

Dispose of the system and its data securely, ensuring that residual information cannot be recovered and that dependencies are addressed.

• Disposal plan
• Certificates of sanitisation or destruction
• Dependency closure records
• Final audit of decommission

• Sanitisation certificates not retained
• Dependencies left active
• No final audit

Implement the system in accordance with design and architecture using secure development practices that protect against introduction of weaknesses.

• Secure development standards
• Static and dynamic analysis results
• Build pipeline configuration with integrity controls
• Code review records

• No code review for security
• Build pipeline lacks integrity controls
• Standards not followed

Integrate system elements and verify that security properties hold across interfaces and that integration does not introduce new weaknesses.

• Integration plan
• Interface test results
• Regression test suite results
• Issue log from integration

• Interfaces tested only for function not security
• No regression suite
• Integration issues unresolved at release

Maintain the system to sustain security properties through patching, configuration management, and corrective and adaptive changes.

• Patch management procedure and records
• Configuration baselines
• Change records linked to risk assessments
• Maintenance log

• Patches delayed without risk review
• Baselines drift
• Change records lack security review

Operate the system under defined security policies, monitor security state, and respond to events that may affect trustworthy operation.

• Operations manual with security policy
• Monitoring configuration and dashboards
• Event response records
• Operational readiness reviews

• No security monitoring in operations
• Policies not followed
• Events ignored

Perform analyses including security, dependability, and assurance analyses to evaluate design alternatives, trade-offs, and residual risk.

• Security analysis reports
• Trade-off study documents
• Residual risk acceptance records
• Assurance case fragments

• No trade-off rationale captured
• Residual risk not accepted by an authority
• Assurance evidence missing

Elicit, analyse, and document stakeholder needs and translate them into validated stakeholder requirements that capture protection needs and acceptable risk.

• Stakeholder needs document
• Requirements matrix with security entries
• Validation records
• Risk-informed acceptance criteria

• Security needs not elicited from operational stakeholders
• No validation step
• Acceptance criteria absent

Transform stakeholder requirements into system requirements that specify the protections, properties, and behaviours necessary for trustworthy secure operation.

• System requirements specification
• Security properties catalogue
• Verification criteria for each requirement
• Traceability to stakeholder needs

• Security requirements vague
• No verification criteria
• Broken traceability

Transition the system from development to operation with secure deployment, training, and handover, ensuring security properties are preserved.

• Deployment plan with security checks
• Operator training records
• Handover documents
• Go-live security review

• Operators untrained
• Security review skipped at go-live
• No handover record

Provide objective evidence that the system, when deployed in its operational environment, satisfies stakeholder needs including protection of mission and assets.

• Validation plan
• Operational test results
• Stakeholder acceptance records
• Evidence summary linked to needs

• No operational test
• Acceptance signed without evidence
• Evidence not retained

Confirm that the system meets specified security requirements through inspection, analysis, demonstration, and testing.

• Verification plan
• Test cases mapped to requirements
• Verification results
• Tool qualification records

• Coverage gaps between requirements and tests
• Tools not qualified
• Results not reviewed