Question

Assess the relationships between continuous monitoring for 1) NIST Systems Security Engineering, SP 800-160, Systems Security Engineering and 2) IETF SACM.

Consider for your Analysis and Conclusions utilizing the NIST enterprise levels:
• Level 1: Organization
• Level 2: Mission/Business Processes
• Level 3: System

Answer 1

System Security Engineering:

Systems security engineering is a specialty engineering discipline of systems engineering that applies scientific, mathematical, engineering, and measurement principles, concepts, and methods to coordinate, orchestrate, and direct the activities of various security engineering specialties and other contributing engineering specialties to provide a fully integrated, system-level perspective of system security. Systems security engineering, as an integral part of systems engineering, helps to ensure that the appropriate security principles, concepts, methods, and practices are applied during the system life cycle to achieve stakeholder objectives for the protection of assets—across all forms of adversity characterized as disruptions, hazards, and threats. It also helps to reduce system defects that can lead to security vulnerability and as a result, reduces the susceptibility of the system to adversity. And finally, systems security engineering provides a sufficient base of evidence that supports claims that the desired level of trustworthiness has been achieved—that is, a level of trustworthiness that the agreed-upon asset protection needs of stakeholders can be adequately satisfied on a continuous basis despite such adversity.

Systems security engineering, as part of a multidisciplinary systems engineering effort: • Defines stakeholder security objectives, protection needs and concerns, security requirements, and associated validation methods; • Defines system security requirements and associated verification methods; • Develops security views and viewpoints of the system architecture and design; • Identifies and assesses vulnerabilities and susceptibility to life cycle disruptions, hazards, and threats; • Designs proactive and reactive security functions encompassed within a balanced strategy to control asset loss and associated loss consequences; • Provides security considerations to inform systems engineering efforts with the objective to reduce errors, flaws, and weakness that may constitute security vulnerability leading to unacceptable asset loss and consequences; • Identifies, quantifies, and evaluates the costs/benefits of security functions and considerations to inform analysis of alternatives, engineering trade-offs, and risk treatment 13 decisions; • Performs system security analyses in support of decision making, risk management, and engineering trades; • Demonstrates through evidence-based reasoning, that security claims for the system have been satisfied. Provides evidence to substantiate claims for the trustworthiness of the system; and • Leverages multiple security and other specialties to address all feasible solutions so as to deliver a trustworthy secure system. Systems security engineering leverages many security specialties and focus areas that contribute to systems security engineering activities and tasks. These security specialties and focus areas include, for example: computer security; communications security; transmission security; antitamper protection; electronic emissions security; physical security; information, software, and hardware assurance; and technology specialties such as biometrics and cryptography. In addition, systems security engineering leverages contributions from other enabling engineering disciplines, specialties, and focus areas.14 Figure 1 illustrates the relationship among systems engineering, systems security engineering, and the contributing security and other specialty engineering and focus areas.

The systems security engineering discipline provides the security perspective to systems engineering processes, activities, tasks, products, and artifacts. These processes, activities, and tasks are conducted in consideration of all system elements; the processes employed to acquire system elements and to develop, deliver, and sustain the system; the behavior of the system in all modes of operation; and the various forms of disruption, hazard, and threat events and conditions that constitute risk with respect to the intentional or unintentional loss of assets and associated consequences.

IETF SACM:

Today's environment of rapidly evolving security threats highlights the need to automate the sharing of security information (such as posture information) while protecting user information and the systems that store, process, and transmit this information. Security threats can be detected in a number of ways. The Security Automation and Continuous Monitoring (SACM) charter focuses on how to collect and share this information based on use cases that involve posture assessment of endpoints. Scalable and sustainable collection, expression, and evaluation of endpoint information is foundational to SACM's objectives. To secure and defend a network, one must reliably determine what devices are on the network, how those devices are configured from a hardware perspective, what software products are installed on those devices, and how those products are configured. We need to be able to determine, share, and use this information in a secure, timely, consistent, and automated manner to perform endpoint posture assessments.

Securing information and the systems that store, process, and transmit that information is a challenging task for enterprises of all sizes, and many security practitioners spend much of their time on manual processes. Standardized protocols and models aiding collection and evaluation of endpoint elements enable automation, thus freeing practitioners to focus on high priority tasks. Due to the breadth of this work, the working group will address enterprise use cases pertaining to the assessment of endpoint posture (using the definitions of Endpoint and Posture from RFC 5209). In alignment with RFC 5209, a network device is an endpoint.

Posture assessment entails the following five steps which the working will create solutions to automate:

1. Identify and characterize target endpoints
2. Determine specific endpoint elements to assess
3. Collect and make available specified elements' actual values
4. Compare actual element values to policy compliant element values
5. Make results available

This working group will focus on collection, evaluation, and orchestration and communication, as described herein.

A. Collection. The WG will define a standardized way to provide two types of guidance to collectors over varying collection mechanisms:

1) Which target endpoints to collect from, and
2) What elements to collect from these target endpoints.

A set of instructions (such as vulnerability description data, YANG filter expressions, Windows Management Instrumentation classes, etc.) can be brokered to the appropriate collectors using the control plane functions defined by "C. Orchestration and Communication" (below). Element collection from different sources may require orchestrating functions that go beyond the set of capabilities a collector can provide. This will inform the requirements and characteristics for "C. Orchestration and Communication". The working group recognizes that manual configuration of targets and corresponding collection profiles will not scale and does not seem to be a viable option.

B. Evaluation. The working group will standardize a criteria language enabling evaluation of actual endpoint posture information against desired endpoint posture information to produce a standardized result. This extensible language will support complex Boolean statements, comparison operators, logical flow statements, and functions for string manipulation. Additionally, the working group will seek to discover an approach that allows data from any posture collection mechanism to be generically evaluated.

C. Orchestration and Communication. The working group will define a set of control plane functions to enable the orchestration between element collectors. These element collectors can then provide the requisite elements sought by posture collectors, posture evaluators, and data repositories.

Specific work items may include the following:

- Define a way to provide three types of guidance to the correct SACM collectors: 1) Which target endpoints to collect from and 2) what to collect from these target endpoints, and 3) how quickly after an attribute change information must be collected. When applied, a set of instructions, such as vulnerability description data or YANG expressions, can be brokered to the appropriate collectors.

- Define an extension of IETF NEA [https://ietf.org/wg/concluded/nea.html] to collect and deliver information about firmware, operating systems, and software installed on an endpoint.

- Describe a criteria language capable of being evaluated against endpoint posture information to produce a standardized result. The language will support complex Boolean statements, comparison operators, and functions for string manipulation; and will be extensible enough to be applicable to the full range of collected posture attributes. Additionally, this document will describe an approach that allows data from any posture collection mechanism to be evaluated.

- Define a control plane function to enable the discovery and orchestration between devices that can provide the requisite information sought by posture collectors, posture evaluators or both. For example, XMPP capable host/endpoint interactions may be defined through XMPP control plane and data transfer protocol extensions. Likewise, the asynchronous push of selected attributes on switches and routers may be framed using YANG Push for periodic and on-change triggers.

- Define a method of expressing software metadata that is suitable for use by constrained devices including a CBOR-based format derived from the ISO/IEC 19770-2 Software Identification (SWID) tag standard.

- Define best practices for the collection of posture information from endpoints and its delivery to a collector, from which it can be distributed using the SACM messaging standards.

- Extend existing standards for information exchange to support the sharing of software, configuration information, and other forms of guidance including extensions to the Resource-Oriented Lightweight Information Exchange (ROLIE).

- Describe a SACM Information Model and a SACM Architecture including protocol requirements and their associated use cases as well as a description of how SACM protocols fit together into a system.

LEVELS:

Risk management can be viewed as a process and practice that requires participation from, and engagement of, all levels of a given organization. The risk management functions at each level are interconnected and inform the risk decisions made at the other levels. The National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) proposes a three-level approach to risk management: (1) organization level; (2) mission/business process level; and (3) information system or system component level. At the top of the pyramid, the organization establishes the risk management strategy, communicates risk management guidance, identifies missions and business processes, and provides oversight of the organization’s risk posture. The risk guidance developed at the strategic levels determines the risk management activities performed at the lower, tactical levels – e.g., the information system and system component level. The security and privacy risk management practices ultimately implemented at the information system level directly reflect the risk management principles defined by the organization. Reporting of system risk posture up to the organization level is intended to provide an aggregate view of risk across the organization, allowing the organization to adjust and achieve the desired risk posture. In the Smart City context, the organization level may include entities such as the mayor’s office and key risk-related offices such as those of the chief risk officer, chief information officer, chief information security officer, or chief privacy officer. Underneath this level may be a transportation mission area or an acquisition management business process area. These areas would naturally involve a wider array of stakeholders; for example, the transportation mission area may include a wide variety of transportation-related agencies, including the departments of transportation and public works as well as emergency management and law enforcement entities. At the most tactical level – the information system level – the risk management process may focus on a single system, solution, or capability. Example systems of interest could be defined as a smart parking meter system or a system comprised of traffic sensors and the back-end traffic analytics capability. It should be noted that the depiction in the pyramid does not explicitly address the relationships with external organizations (e.g., county, state, private sector).