Even if you are not an engineer, NIST 800-160 Volume 1 could help you in your work to understand security by design. It shows what you need to secure your information system. In the other blogs in this series, we’ve summarized the major points of the document. In the final installment, we’ll take a look at the Technical Processes in Chapter 3.
These processes round out the security-by-design thinking found in NIST 800-160 Volume 1. Given the total number of technical processes, these summaries of security design principles are very brief. Referring back to the source special publication is recommended.
Technical Processes for Security by Design
- Business or Mission Analysis: This process helps find the scope, basis and drivers of the business or mission as they relate to security. By the end of this process you should have defined and characterized security aspects of solutions and problems. It will help you consider different solutions and enable systems or services to achieve the security aspects of business or mission analysis.
- Stakeholder Needs and Requirements Definition: This process helps define security needs that include protection capability, security characters and security-driven constraints needed by users and stakeholders. At the end of this process, you should have identified and addressed the security interests and concerns of all stakeholders throughout the system life cycle. You will have defined stakeholder protection needs, including constraints on the system. Stakeholder agreements will be in place, as will enabling systems or services to support security aspects.
- System Requirements Definition: This process can transform the stakeholder security requirements into system requirements that reflect a technical security view of the system. Intended outcomes include a defined system security description for a solution, requirements, constraints and performance measures. By the end of this process, you’ll have analyzed requirements and the constraints that come with them. Any enabling systems or services for the required security aspects will be present.
- Architecture Definition: This process generates a set of representative security views and options designed to inform decision making. It addresses stakeholder concerns, develops viewpoints and architecture metrics and aligns architecture and requirements.
- Design Definition: This process provides security-related data and information to enable consistent implementation consistent with security architectural entities. It provides frameworks for allocating system security requirements, creating design artifacts and assessing design alternatives. In addition, it aids in identifying security-related design metrics.
- System Analysis: This process provides a security view to system analyses, providing essential data for the technical understanding of the security aspects of decision making. By the end you’ll have identified and validated assumptions and results related to the security aspects of systems analysis. Results will be available for decision, as will any enabling systems or services.
- Implementation: This transforms all system elements into actions. By the end of this process, you’ll have all security aspects of implementation in place, including requirements and constraints. You’ll be able to securely package and store system elements. You’ll also have realized a security-relevant or security-informed system.
- Integration: This process combines the implement system from a complete or partially secure system into a combined secure product or service. It aids in creating an approach and checkpoints for the correct, secure operation of assemble components. You will be able to integrate a trustworthy security system. That includes system elements, checking behaviors and interactions between interfaces and external environments and defining security anomalies.
- Verification: A process that produces evidence sufficient to demonstrate security requirements and characteristics are satisfied. Intended outcomes include verifying security requirements and characteristics and reporting security-driven data providing information for corrective actions. You’ll also be able to provide evidence that satisfies system security requirements. Using this process, you should also be able to identify verification results and anomalies.
- Transition: This process enables you to preserve the system security characteristics in an orderly and planned transition into operational status. Preparing the operation will include its security aspects. The people involved will have training in systems security and its limits. The installed system is active and ready for operation when it comes to security-relevant issues.
- Validation: This process provides sufficient evidence to demonstrate that the system reaches certain criteria while it is in use. It needs to meet its objectives, minimize loss and associated consequences and reach the desired level of trustworthiness. By the end of this process you’ll have defined security aspects and validation criteria, validated security aspects of the system, identified results and anomalies and provided evidence.
- Operation: This process establishes the requirements and constraints to enable secure operation, consistent with intended use. It results in having the enabling systems or services you need to support the security operation of the system. It also outlines results for having trained and qualified personnel on hand and making sure system services meet stakeholder security requirements. Providing security support to the customer also falls under this process.
- Maintenance: This process sets in place the requirements and constraints to sustain delivery of specific services and provides engineering support. As a result, replacement, repaired, or modified systems will be in place and the need for changes will be reposted. Security-related aspects, failure, and lifetime data, including costs, will be determined.
- Disposal: This process provides for the security aspects of ending the existence of a system. It will help developing security aspects of the disposal strategy. This means you can securely remove system security elements from service, return the system to an original or agreed-upon security state and have records of secure disposal actions and analysis.
Of note, for nearly all the processes listed here and in the related articles, traceability will be another intended outcome. Remember, this helps you to apply lessons learned and track what you are doing.
Technical Processes 30,000 Feet
In closing, remember that parts 2 through 4 of this mini-series only introduce the families and their respective processes found within NIST 800-160 Volume 1. When you get into the special publication itself, you find incredibly detailed information, burrowing down into discussion issues and considerations from each control, reference materials (such as those that come from ISO/IEC/IEEE standards) and related publications.
If there is going to be a security-by-design rethinking of cybersecurity and information handling in general, following NIST 800-160 Volume 1 gives a roadmap of how to build and manage that system throughout the entire life cycle.
The post Security by Design and NIST 800-160, Part 4: Technical Processes From ‘Go’ to Disposal appeared first on Security Intelligence.
