Peter A Clarke

The National Institute of Standards and Technology (“NIST”) has release Engineering Trustworthy Secure Systems for public comment.It is a very useful document for those interested in privacy and cyber security in that it provides a framework for analysis.

This guide has been produced pursuant to a Presidential Executive Order on 12 May 20212 titled Improving the National’s Cyber Security WO 14028.

The key elements of that executive order are:

• Section 1. Policy. The United States faces persistent and increasingly sophisticated malicious cyber campaigns that threaten the public sector, the private sector, and ultimately the American people’s security and privacy. The Federal Government must improve its efforts to identify, deter, protect against, detect, and respond to these actions and actors. The Federal Government must also carefully examine what occurred during any major cyber incident and apply lessons learned. But cybersecurity requires more than government action. Protecting our Nation from malicious cyber actors requires the Federal Government to partner with the private sector. The private sector must adapt to the continuously changing threat environment, ensure its products are built and operate securely, and partner with the Federal Government to foster a more secure cyberspace. In the end, the trust we place in our digital infrastructure should be proportional to how trustworthy and transparent that infrastructure is, and to the consequences we will incur if that trust is misplaced. 
• Sec. 2. Removing Barriers to Sharing Threat Information. (a) The Federal Government contracts with IT and OT service providers to conduct an array of day-to-day functions on Federal Information Systems. These service providers, including cloud service providers, have unique access to and insight into cyber threat and incident information on Federal Information Systems. At the same time, current contract terms or restrictions may limit the sharing of such threat or incident information with executive departments and agencies (agencies) that are responsible for investigating or remediating cyber incidents, such as the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and other elements of the Intelligence Community (IC). Removing these contractual barriers and increasing the sharing of information about such threats, incidents, and risks are necessary steps to accelerating incident deterrence, prevention, and response efforts and to enabling more effective defense of agencies’ systems and of information collected, processed, and maintained by or for the Federal Government.
• Sec. 3. Modernizing Federal Government Cybersecurity. (a) To keep pace with today’s dynamic and increasingly sophisticated cyber threat environment, the Federal Government must take decisive steps to modernize its approach to cybersecurity, including by increasing the Federal Government’s visibility into threats, while protecting privacy and civil liberties. The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.
• Sec. 4. Enhancing Software Supply Chain Security. (a) The security of software used by the Federal Government is vital to the Federal Government’s ability to perform its critical functions. The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. There is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely, and as intended. The security and integrity of “critical software”—software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources)—is a particular concern. Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.
• Sec. 5. Establishing a Cyber Safety Review Board. (a) The Secretary of Homeland Security, in consultation with the Attorney General, shall establish the Cyber Safety Review Board (Board), pursuant to section 871 of the Homeland Security Act of 2002 (6 U.S.C. 451).
• Sec. 6. Standardizing the Federal Government’s Playbook for Responding to Cybersecurity Vulnerabilities and Incidents. (a) The cybersecurity vulnerability and incident response procedures currently used to identify, remediate, and recover from vulnerabilities and incidents affecting their systems vary across agencies, hindering the ability of lead agencies to analyze vulnerabilities and incidents more comprehensively across agencies. Standardized response processes ensure a more coordinated and centralized cataloging of incidents and tracking of agencies’ progress toward successful responses.
• Sec. 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Networks. (a) The Federal Government shall employ all appropriate resources and authorities to maximize the early detection of cybersecurity vulnerabilities and incidents on its networks. This approach shall include increasing the Federal Government’s visibility into and detection of cybersecurity vulnerabilities and threats to agency networks in order to bolster the Federal Government’s cybersecurity efforts.
• Sec. 8. Improving the Federal Government’s Investigative and Remediation Capabilities. (a) Information from network and system logs on Federal Information Systems (for both on-premises systems and connections hosted by third parties, such as CSPs) is invaluable for both investigation and remediation purposes. It is essential that agencies and their IT service providers collect and maintain such data and, when necessary to address a cyber incident on FCEB Information Systems, provide them upon request to the Secretary of Homeland Security through the Director of CISA and to the FBI, consistent with applicable law.
• Sec. 9. National Security Systems. (a) Within 60 days of the date of this order, the Secretary of Defense acting through the National Manager, in coordination with the Director of National Intelligence and the CNSS, and in consultation with the APNSA, shall adopt National Security Systems requirements that are equivalent to or exceed the cybersecurity requirements set forth in this order that are otherwise not applicable to National Security Systems. Such requirements may provide for exceptions in circumstances necessitated by unique mission needs. Such requirements shall be codified in a National Security Memorandum (NSM). Until such time as that NSM is issued, programs, standards, or requirements established pursuant to this order shall not apply with respect to National Security Systems.

The Guide is a very extensive document, some 209 pages long. This post does not pretend to cover the details of the guide however sets out some key issues.

The Abstract provides:

This publication provides a basis for establishing a discipline for systems security engineering (SSE) as part of systems engineering and does so in terms of its principles, concepts, activities, and tasks. The publication also demonstrates how those SSE principles, concepts, activities, and tasks can be effectively applied to systems engineering efforts to foster a common mindset to deliver security for any system, regardless of its purpose, type, scope, size, complexity, or stage of its system life cycle. Ultimately, the intent of the material is to advance the field of SSE as a discipline that can be applied and studied and to serve as a basis for the development of educational and training programs, including the development of professional certifications and other assessment criteria.

Some of the key terms are:

• Security is freedom from the conditions that can cause a loss of assets with unacceptable consequences.  Stakeholders must define the scope of security in terms of the assets to which security applies and the consequences against which security is assessed
• Systems engineering provides a necessary foundation for a disciplined and structured approach to building assured, trustworthy secure systems.
• Systems security engineering, as a systems engineering subdiscipline, addresses security-relevant considerations intended to produce security The engineering efforts are conducted at the appropriate level of fidelity and rigor needed to achieve trustworthiness and assurance objectives.

The purpose of the publication is:

• • To provide a basis to establish a discipline for systems security engineering, as part of systems
  • engineering, in terms of its principles, concepts, activities, and tasks
  • To foster a common mindset to deliver security for any system, regardless of its purpose, type,
  • scope, size, complexity, or stage of the system life cycle
  • To demonstrate how selected systems security engineering principles, concepts, activities,
  • and tasks can be effectively applied to systems engineering activities
  • To advance the field of systems security engineering as a discipline that can be applied and
  • studied
  • To serve as a basis for the development of educational and training programs, including the
  • development of individual certifications and other professional assessment criteria

A system with freedom from those conditions that can cause a loss of assets with unacceptable  consequences must provide the intended behaviors and outcomes (e.g., the intended system 651 functionality) and avoid any unintended behaviors and outcomes that constitute a loss. The term 652 has two cases, both of which must be satisfie:

 Design intent: As intended by the design

 User intent: As intended by the user

The primary security objective is to ensure only the intended behaviors and outcomes occur, both with the system and within 660   the system. Every security need and concern derive from this objective, which is based on the concept of authorization for what is and is not allowed. The primary security control objective is enforcing constraints in the form of rules for allowed and disallowed behaviors and outcomes. This control objective is Mediated Access.

Privileges define the set of allowed and disallowed behavior and outcomes granted to a subject. Privileges are the basis for making mediated access decisions. A restrictive default practice for security policy enforcement is to design the enforcement mechanism to allow only what the policy explicitly allows and to deny everything else. For a system to be deemed trustworthy secure, there must be sufficient confidence that the system is capable of enforcing security policy on a continuous basis for the duration of the time that the security policy is in effect

Adequate security is a concept that enables meaningful judgments about the idealistic nature of security objectives. A secure system:

• Enables the delivery of the required system capability despite intentional and unintentional forms of adversity
• Enforces constraints to ensure that only the desired behaviors and outcomes associated with the required system capability are realized while satisfying the first aspect
• Enforces constraints based on a set of rules to ensure that only authorized human-to-machine and machine-to-machine interactions and operations are allowed to occur while satisfying the second aspect

To be adequately secure, the system:

• Is assessed to meet minimum tolerable levels²⁶ of security, as determined by experience, analysis, or a combination of both
• Is as secure as reasonably practicable (ASARP), (i.e., an incremental improvement in security would require a disproportionate deterioration of meeting other system cost, schedule, or  performance objectives, would violate system constraints, or would require unacceptable.

The nature and characteristics of systems, their interrelationships with other systems, and their role as part of a system of systems all impact security (including determining adequate security) and efforts to achieve a trustworthy secure system of interest include:

• System type, function, and primary purpose
• System technological, mechanical, physical, and human element characteristics
• System states and modes of operation
• Criticality or importance of the system
• Ramifications of the system’s failure to meet its performance expectations, to function 757 correctly, to produce only the intended behaviors and outcomes, and to provide for its own 758      protection (i.e., self-protection)
• System concept for the delivery of capability
• Approach to acquisition of the system
• Approach to managerial and operational governance
• Value, sensitivity, and criticality of assets entrusted to and used by the system
• The system’s interfaces and those interfacing systems that interact through those interfaces
• Role as a constituent system in one or more system of systems

System security analyses address important topic areas related to systems security engineering including:

• architecture,
• assurance,
• behavior,
• cost,
• criticality,
• design,
• effectiveness,
• emergence,
• exposure,
• fit-for-purpose,
• life cycle concepts,
• penetration resistance,
• performance (including security performance),
• protection needs,
• security objectives,
• privacy,
• requirements,
• resilience,
• risk,
• strength of function,
• threats,
• trades,
• uncertainty,
• vulnerability,
• verification, and
• validation.

The systems security engineering framework includes a closed loop feedback for interactions among and between the three framework contexts and the requisite system security analyses to continuously identify and address variances as the variances are introduced into the engineering effort.

The problem context defines the basis for an acceptably and adequately secure system. It focuses on stakeholders’ concerns about unacceptable losses given their mission, operational capability, and performance needs and concerns, as well as all associated cost, schedule, performance, and risk-driven constraints. The problem context enables the engineering team to focus on acquiring as complete an understanding of the stakeholder problem as practical, to explore all feasible solution class options, and to select the solution class option or options to be pursued.

The solution context establishes the security aspects and constraints for the architecture and design of the system that:

(1) satisfies the requirements and objectives of the problem context,

(2) realizes the design for the system, and

(3) produces sufficient evidence to demonstrate that the requirements and objectives of the problem context have been satisfied.

The solution context is based on a balanced proactive and reactive system security protection strategy that exercises control over events, conditions, asset loss, and the consequence of loss to the degree possible, practicable, and acceptable to stakeholders. The solution context includes:

·       Defining the security aspects of the solution

·       Realizing the security aspects of the solution

·       Producing evidence for the security aspects of the solution

The trustworthiness context is a decision-making context that provides an evidence-based demonstration – through reasoning – that the system of interest is deemed trustworthy (or not)  based on a set of claims derived from security objectives. This context consists of:

·       Developing and maintaining the assurance case

·       Demonstrating that the assurance case is satisfied.