The word “system” became quite common in our everyday language to the extent that there is some confusion in its usage between different communities. Indeed, this word is used rather often, as we speak of “the solar system,” “a system of government,” “a health system,” “a system of winning poker,” a “communication system,” or a “weapon system,” and in so doing, we imply certain purposefulness and some sort of organization imposed on various elements that interact between themselves. A system is something that involves and exhibits behavior—a set of activities that can be defined in terms of the manipulation of materials, energy, or information.

A standard definition of a system by IEEE: System is a collection of components organized to accomplish a specific function or set of functions [IEEE 610.12].

Systems are studied by the general systems theory—an interdisciplinary theory about the nature of complex organizations in nature, society, and science, and is a framework by which one can investigate and/or describe any group of elements that are functioning together to fulfill some objective (whether intended, designed, man made, or not).

A standard definition of a system from the systems engineering community: A composite, at any level of complexity, of personnel, procedures, materials, tools, equipment, facilities, and software. The elements of this composite entity are used together in the intended operational or support environment to perform a given task or achieve a specific production, support, or mission requirement. [Air Force 2000]

On the other hand, certain communities prefer to use the word “system” in its narrow and concrete meaning—such as a particular computer application, or a physical system, a facility with a specific geographic location that involves a certain technology to provide service. Concrete systems are procured by organizations and fielded to support organizations and their operations [DoDAF 2007]. The context in which a concrete technical system operates is referred to as an “organization,” which is defined as “an organization structure with a mission.” In a business community, the term “enterprise” is often used to refer to the complex socio-technical organizations designed to provide goods and services to their customers.

National Institute for Standards and Technology (NIST) equates “system” and “information system” [NIST SP 800-18] and defines “information system” as a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

Certain communities prefer to use the term “network,” or “organization network” to mean a specific installation of personnel, operational procedures, technology, and physical facilities, that contain valuable information assets of the organization, in particular, the Network Rating Methodology from the National Security Agency (NSA) [Moore 2000].

The Information Technology Security community distinguishes a system, which is defined as a specific installation “with particular purpose and a known operational environment” and a product, which is defined as “a hardware and/or software package that can be bought off the shelf and incorporated into a variety of systems” [ISO 15408].

System assurance deals with man-made systems, created and utilized for the benefit of man. Cyber systems involve a combination of hardware, software, and humans. System assurance embraces the entire system life cycle from the conception of ideas through to the retirement of a system. System assurance supports the governance of systems and the processes for acquiring and supplying system products and services. Reasoning about systems for the purpose of evaluating security posture requires a common vocabulary that can be used to improve communication and cooperation between diverse disciplines and identify, utilize and manage relevant information units in an integrated, coherent fashion.

The systems approach implies a commitment on our part to focus our attention only at the few selected elements (out of the entire universe), that are relevant to the particular behavior in question. For the systems approach to be applicable, it is important that the selected elements are discrete and identifiable. The set of elements selected as relevant to the system's behavior determine the so-called external boundary of the system. Systems approach involves another boundary that separates selected elements into the system and its environment. For a physical system, this boundary is usually the same as the scope of responsibility of the owner. A system performs its function as the result of interaction between its elements or subsystems. This interaction, which may be very complex indeed, generally insures that a system is not simply equal to the sum of its parts. Units of the system's behavior are the individual functions that are performed by the system's elements or the elements of its environment. The environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The elements outside of the system boundary are only included because their interactions with the target system are relevant to the behavior of the system, therefore, any interactions between the elements of the environment of the system are usually ignored (see Figure 1).

System definition is based on the decision on where to draw the system's boundary. Consider a house alarm system. It includes a number of easily identifiable physical elements: several sensors, such as door/window contacts, motion sensors, glassbreak detectors, CO₂ detectors, smoke detectors, water detectors; a control panel; a siren; a lot of wires if you are using an older model; or a wireless network (some newer wireless models have sensors that wirelessly communicate to the wireless receiver of the control panel). The control panel is powered by electricity and has a 12V backup battery. Should the battery be included as part of the alarm system? A house alarm system usually includes a communicator module, which is connected to the monitoring station. What about the telephone line that is running from the control panel to the telephone jack in the wall? What about the external line that runs from the house to the telephone pole? What about the telephone switching equipment in the grey metal box down the street? Do we include the monitoring station as part of the house alarm system? What about the police department and the fire department that are alerted by the monitoring station? Should they be included as parts of the system? The decision to establish the system boundary is made on the basis of what aspect of the system behavior is of concern. For example, if the immediate concern is how to adjust the motion detector in the family room so that Charlie the dog does not activate it when he jumps on the couch, the system boundary may be closed in. However, if the problem involves the response time when the police arrive at the premises, the boundary needs to be broader.

The choice of the appropriate system boundary determines the soundness and complexity of the analysis. Selection of the system boundaries must be commensurate with the goals of the analysis. To reach certain conclusions about a system, it may be desirable to include more elements within the external boundary. This may require complex, time-consuming analysis. If the money, time, and staff available are inadequate for this task and more efficient analysis approaches are not possible, then the system boundary must be “moved in” and the amount of information expected to result from the analysis must be reduced [Vesely 1981].

The entry points to the system are determined by the external interfaces based on the selected system boundary.

The system approach also involves a commitment to a set of characteristics of the elements that are relevant to the behavior in question. These characteristics establish a limit of resolution of the system definition. The level of the resolution increases when one of the subsystems, for example B, is decomposed, for purposes of the analysis, into smaller sub-subsystems (see Figure 2). The smallest sub-subsystems, X, Y, and Z, are the smallest identifiable elements mentioned in the general definition of a system and constitute an internal boundary for the system. The more detailed level of resolution may involve additional characteristics of the system's elements. In the house alarm example, do you extend analysis to the individual cells of the photo sensor in the motion detector? What about the circuit board? Are you going to consider soldering on the circuit board? What about the molecular structure of the wires?

The limit of resolution (the internal boundary) must be established from considerations of feasibility and from the goal of the analysis. Once the limit of resolution has been established (and thus the “system's elements” defined), we assume no knowledge and are not concerned about interactions taking place at lower levels. Functions of the system elements are adjusted to the selected level of resolution to adequately describe the overall behavior of the system.

The same system can be described at various levels of resolution. In Figure 2, the interaction between subsystem B and system H (in the environment of the target system S), can be described directly at the top level of the resolution, or at a more detailed level of the protocol that involves subsystems X and Y. Functions of the subsystem B are implemented by the functions of the corresponding subsystems X, Y, and Z at a more detailed level of resolution.

We now see that the system boundary serves to delineate system outputs (effects of the system on its environment) and system inputs (effects of the environment on the system); the limits of resolution serve to define the elements of the system and to establish the basic interactions within the system.

Cyber systems involve multiple layers of protocols and involve interactions between a multitude of systems; therefore, the security boundary that the owner of any given system has to be concerned about can be extremely large and complex. Vulnerabilities may occur in different components, often outside of the jurisdiction of the system's owner (and beyond his reach) or at lower levels of the protocol outside of the resolution of the original system definition. As the consequence, a rather detailed resolution of the system needs to be considered in order to understand and reduce the risk of cyber attacks.

It is important to understand that the determination of the system boundaries and limits of resolution are fundamental decisions of the system analysis. While certain elements of a system, such as the physical elements and their relationships, observable events, and the objects being exchanged are often predetermined by the corresponding identifiable objects in the real world, the functions of the elements are often abstractions introduced by the system analysis based on the selected level of resolution. In addition, certain system elements are introduced during the system analysis as aggregations of existing physical elements to lower the resolution and obtain a more compact and comprehensive system definition. For example, the home alarm system can be described as a sensing subsystem (an aggregation of all contacts, sensors, and detectors), a control subsystem (involving the control panel and all keypads), and the signaling subsystem (involving the siren and the communicator module and the monitoring station).

The system's elements, their characteristics, the system boundaries, and limits of resolution are defined before the security analysis begins and are adhered to during the analysis, because these elements constitute the conceptual commitment for the target system and the foundation of the vocabulary for describing any properties of the system of interest, including its security. However, in practical situations, the boundaries or limits of resolution may need to be adjusted because of information gained during the analysis, in particular, the level of resolution of some system elements may need to be increased to allow more accurate analysis. The system boundaries and limits of resolution, and any adjustments, must be clearly defined in order to facilitate information exchanges during the analysis of the system.

Now let us share a few comments, which will help put the material of this chapter into the bigger context of this book. We believe that the idea of a “conceptual commitment” is central for establishing an ecosystem for exchanging knowledge. Conceptual commitment means using a carefully preselected set of concepts (a vocabulary) to describe systems, their behaviors, security policy, safeguards, and the entire assurance case. The elements of such a preselected common vocabulary consist of nouns and noun phrases that describe individual entities/objects in the system and in any associated domains; and verbs and verb phrases that describe relationships between objects. We use a certain methodology to build discernable common vocabularies; this methodology helps identify discernable noun and verb concepts (this methodology is introduced in Chapter 9). Discernable concepts are important because they are unambiguous and allow maintaining traceability links to lower levels of resolution. Incidentally, the OMG Assurance Ecosystem includes standards that define how to exchange well-defined vocabularies and how to systematically transform a well-defined vocabulary into an XML schema for exchanging information about the individual objects. At the same time, the elements of the well-defined vocabulary are identifiable facts that can be stored in a database, or in a suitable fact-based repository. One of the characteristics of the OMG system assurance process is the use of the “integrated system model,” which is stored in a fact-based repository. In the upcoming chapters we are going to introduce the elements of the common vocabulary for cybersecurity for the OMG Assurance Ecosystem. We will do that with varying degrees of formality, because this book is not a formal specification. This chapter will introduce the noun and verb concepts in a very informal way because we assume familiarity with the basic system engineering concepts, and also, because these concepts are, in general, well established and are used in a rather uniform way. However, keep in mind that when we are saying “identify,” for example, “identify a system component,” this means: use the definition of the “system component” from the common vocabulary, apply the definition to locate the corresponding object in the system of interest, and then add the corresponding facts into the integrated system model. When the objects are already known (because they were identified as part of a preexisting process in the life cycle of the system of interest), the task of “identification” is to map the existing definition to the common vocabulary and add the new facts to the integrated system model. The mapping between vocabularies is often required because different methodologies make different conceptual commitments.

When managing descriptions of the system at increasing levels of resolution, it is important to maintain the so-called vertical traceability links between the elements at different levels of resolution. In terms of a physical, fact-based repository, a traceability link is a particular relationship (a fact) in which one object is implemented by one or more other objects. For the purposes of the cost-efficient analysis, it is also important to be able to transfer the characteristics of systems, established at higher levels of the resolution, to the lower resolution descriptions (where there are fewer elements, with more abstract functions and characteristics), so that the majority of the analysis and managing of the information is done using the system description with the lower resolution. Chapter 9 provides further guidance related to managing multiple pieces of information, managing conceptual commitments, and describes the mechanisms for performing analysis at varying levels of resolution. Chapter 11 describes a standard protocol for exchanging system facts that extends the vertical traceability links all the way down to the very low-level implementation facts (such facts are discovered automatically by compiler-like tools).

The integrated system model also has the so-called “horizontal links,” which are relationships between objects, based on the verb concepts defined in the common vocabulary. When facts from different vocabularies are integrated, for example, when we want to map a threat to a system function, we establish a physical relationship (a fact) between the two concepts from the two parts of the common vocabulary.

The rest of this chapter describes the elements of the common vocabulary for managing facts about the system of interest as part of the integrated system model in support of the system assurance process outlined in Chapter 3. Chapters 5, 6 and 7 describe other units of the cybersecurity knowledge used throughout the assurance process and shows how these facts are integrated with the system facts to support the security posture analysis and gathering evidence for the system's assurance case.

Knowledge about systems of concern to system assurance includes both the general knowledge of the systems theory and systems engineering, as well as specific knowledge about a particular system under assessment. System knowledge involves several viewpoints:

These viewpoints are interconnected: a single identifiable element of a system participates in multiple relationships with other elements in other viewpoints. For example, a server participates in several hierarchies: A server is part of the accounting subsystem, and at the same time, it is part of the network of the data center unit. The accounting subsystem is part of the finance department hierarchy, which is in turn part of the organization of interest. However, the server is owned by a different organization, which leases it to the organization of interest. There are diverse hierarchies of elements associated with the server itself: The server consists of two RAID disk arrays, each with four hard disks; a processing unit, consisting of four core processors; a memory unit, consisting of four memory chips; a bus; two network controllers; and several other controllers of the peripheral devices. Another hierarchy associated with the server includes various software products installed on this server, including the operating system, device drivers, the transaction processing monitor, the application server, the web server, and various application programs. The server supports various functions, such as managing the ledger and managing the inventory; however, there are other equipment units that are also involved with these tasks, such as the database server, the network switch, the firewall, the desktop computers, etc. The server of interest is associated with several other hardware units that are part of the same network but that are involved in different business functions. Several personnel roles are associated with the server and various functions that it is involved with. The server is located in a certain facility. The server supports several interfaces (both at the logical level and at the physical level), including low levels of protocol; for example, the server supports web access over HTTP protocol, but at the same time supports TCP and IP protocols and the Ethernet protocol. The protocols supported by the server also constitute a hierarchy. Each of these viewpoints involves certain events and scenarios.

Life cycle processes bring another set of viewpoints to the system organization. The server was manufactured by another organization at yet a different location. The server was installed by yet another organization. A different organization produced the operating system. The web server software is developed using the open source model. A certain application program uses a web service provided by the human resources department of the organization of interest (which is located in a different facility in a different country). Another application uses a web service provided by an external organization. Most of the application software was developed by the personnel of the engineering department of the organization of interest, while the business objects layer was implemented by a contractor.

Different stakeholders of the system have specific concerns, and therefore, need different views of the system, which focus on the elements, hierarchies, and relationships that are relevant to their concerns. Facts about the system of interest are arranged into meaningful units, called views, which focus on a few elements and their relationships, tailored to the specific concerns of system's stakeholders. Each view is defined by the corresponding viewpoint, which describes what element types and relationship types need to be addressed by the compliant view. The viewpoint is an element of generic knowledge that is utilized as a template for building a view about the system.

Figure 3 illustrates an integrated system model that contains certain unique elements and relationships between them, including hierarchies. In particular, the model contains four types of elements (represented as circles with different shading), two types of relationships (thin and thick lines), and several overlapping hierarchies. The middle part of the figure illustrates three views of the system. Note that certain elements occur on multiple views, and that each view contains a limited selection of elements and relationships. The right part of the figure shows the viewpoints describing the views, which illustrates the rules for selection of the elements and relationships on each view. In particular, the top view only shows the white elements and how they are organized in hierarchies. It does not show black and grey elements, despite the fact that there are relationships to them. This view does not show the hierarchy of the grey elements either. The bottom two views share the same viewpoint. They focus on thick relationships between white, black, and grey elements, focusing on a certain initial element.

ISO/IEC 42010 defines system architecture as “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” The concept of views and viewpoints is central to the ISO architectural description of systems. The particular set of viewpoints is determined by a particular architecture framework, while the vocabulary for the system elements and their relationships is, to a large extent, specific to the system of interest.

Each viewpoint also defines a vocabulary and is thus part of the conceptual commitment for exchanging information about the system of interest.

The US Department of Defense Architecture Framework (DoDAF) [DoDAF 2007] describes a particular set of 26 viewpoints to ensure uniformity and standardization in the documentation and communication of architecture. The 26 DoDAF viewpoints are designed to document the entire architecture, from requirements to implementation.

Viewpoints can be grouped into four categories of views (see Figure 4):

Table 1Table 2Table 3 and Table 4 illustrate the architecture views of the DoDAF. As you can see, these products represent the fundamental viewpoints described above.

System description uses the following fundamental elements:

Systems can be described at several increasing levels of resolution. At a minimum, there are two such levels: operational and systems.

Operational viewpoints describe the tasks and activities, operational elements, and information exchanges required to conduct operations. Operational viewpoints involve the following key noun concepts:

Operational node is an element of the operational architecture that produces, consumes, or processes information. Usually an operational node represents an operational role, fulfilled by an organization or a human, and organization, or an organization type, a logical grouping of organizations, etc.

Information exchange needline represents a need for some kind of information exchange between two connected operational nodes. A needline represents a flow of information, and not a physical communications link.

Information exchange is an act of exchanging information between two distinct operational nodes and the characteristics of the act, including the information element that needs to be exchanged and the characteristics of the exchange; for example, transaction type, access control requirement, confidentiality, integrity, availability, dissemination control, protection needs, classification, and classification caveat.

Information element is the information content that is required to be exchanged between nodes. Information elements can be organized in hierarchies.

Operational activity is an action performed in conducting the operation of the enterprise.

Operational activity is performed at operational node. Activities can be organized in hierarchies. Operational capability is one or more sequences of activities.

Event is a specification of a significant occurrence that has a location in time and space. In the context of state diagram, an event is an occurrence that can trigger a transition.

State is defined as a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

Figure 5 illustrates the operational views and their relationships.

Systems viewpoints describe systems, services, and interconnections supporting operations. System viewpoints involve the following noun concepts.

Systems node – a node with the identification and allocation of resources (e.g., platforms, units, facilities, and locations) required to implement specific roles and missions.

System item – an element of a system, such as a hardware item or a software item.

Service – a distinct part of the functionality that is provided by a system on one side of the interface to some other system on the other side of the interface to include those capabilities to execute a business or mission process or exchange information among both machine and human users via standard interfaces and specifications.

Interface is an abstract representation of one or more communication paths between system nodes or between systems (including communication systems).

System function – a data transform that supports the automation of operational activities or information exchange.

Figure 6 illustrates the relationships between the operational and system views.

A system can be described from multiple viewpoints. We need to examine various viewpoints in more detail to decide which of them is more suitable to contain the “location” of vulnerability.

The following are the major categories of viewpoints:

The Event Trace viewpoint is literally the most visible one, because event flow views describe sequences of events. Events are individual, observable occurrences. What occurrence is claimed to be observable is determined by the selection of the boundaries of the system, both external and internal. Usually, events are observable at the external boundary of the system. The Event Trace view shows the system in operation, as it can be perceived by an outside observer. Event Trace view shows information exchanges between the elements of the system. Event Trace is often described as a dynamic viewpoint that represents behaviors of the system as sequences of events in the order in which they occurred in time. Certain events may occur simultaneously. Certain events that occur together (either in sequence or simultaneously) can be combined into “phases,” which are often confused with “states.” Certain events and event sequences (at some resolution, of course) are common to large families of systems. A debug trace of an application is an event view, and the contents of a log file is an event view.

The next viewpoint is the Structure viewpoint, which is related to the “locations” of the systems as it describes the elements of the system as the “places” in which activities that produce events take place. The elements of the system are involved in interactions, which mean that there is flow of something between various elements. The Structure viewpoint defines the participants of the interactions, which is, of course, determined by the external boundaries (the scope of the system) and the selected resolution. Some of the “places” are directly at the boundary of the system, which means they are the discrete points of interaction between the system and its environment. These elements are often referred to as the system “entry points.”

Additional Structure views can be used to represent various relationships between nodes; for example, an organizational relationship chart represents organizations and their parts, roles, and other relationships among organizations.

The events are correlated with the flow of objects, although a software intensive system is mainly about the flow of information. This viewpoint can describe the flow of money, the flow of color, the flow of goods, and the flow of personnel, even the flow of service offerings, or the flow of knowledge. The Data Flow viewpoint describes how data flows between the activities of the system or between the activities and the system's environment as the system performs its function. This viewpoint emphasizes the capabilities and operational activities of the system, the relationships between activities, their inputs and outputs, etc.

Flows of data and events are determined by some rules that distinguish one system from another. The Rules viewpoint is the static viewpoint that describes the elements of the system, the events they cause, and the rules they impose on the event flow, the associated data flow, how these rules determine the possible events of the system in operation, and how the rules constrain possible behaviors, which are sequences of events. The code of a software application is an example of a Rules view.

Now we have defined all the ingredients, and we can define the concept of a state, which is somewhat more elusive. In general, state is defined as a condition or mode with regards to circumstances or with regards to form, such as structure, growth, or development. State is a very fundamental concept, but it is the least visible one, since it is an abstraction of behavior.

State corresponds to a "stable" condition of the system of interest, at a certain period of time, that is determined by the behavior of the system at the previous periods. Usually, a state can be described by a simpler subset of the behavior rules. Behavior of a stateless system does not depend on the previous periods. As opposed to the behavior phases (or event-based states), systems may easily have an infinite number of states. Defining vulnerabilities in terms of states should be avoided, because of the difficulties in systematic examination of all states. Viewpoints as locations of vulnerabilities are illustrated at Figure 7.

Additional viewpoints may be needed to address the concerns of other stakeholders of the system. For example, the Motivation viewpoint describes the objectives of the system (the ends) and the mechanisms (the means) that are used to achieve the objectives.

The CONOP (sometimes called ConOps) stands for the Concept of Operations. CONOP is a brief overview of a system at a low resolution. Usually, a CONOP document addresses the following questions:

CONOP also defines the key security requirements of the system, such as the access rights of the users and their need-to-know. Chapter 12 illustrates a CONOP for the system used in the case study.

In general, a computation is a sequence of steps/events performed by the system or one of the activities within the system. The computation is performed by the code, which is supported by other components of the system. Code provides the constraints to computations and therefore, determines which computations can occur. For example, the computation is determined by the control flow relationships between individual activities, and further by the data flow relationships describing how individual activities act as producers and consumers of data. These relationships are the constraints for the computation (see Figure 7).

In order to analyze a computation, all system components have to be considered, including the so-called application code, but also the runtime platform and all runtime services, as some of the key control and data flow relationships are provided by the runtime platform, as the computation flows through the application code into the runtime platform and services and back to the application code. Application code alone in most cases does not provide an adequate picture of the computation, as some segments of the flow are determined by the runtime platform and are not visible in the application code. For example, while a large number of control flow relationships between different activities in the application code are explicit (such as statements in a sequence, or calls from a statement to another procedure), some control flow relations are not visible in the code, including the so-called callbacks, where the application code registers a certain activity with the runtime platform (for example, an event handler or an interrupt handler) and it is the runtime platform that initiates the activity. Without the knowledge of such implicit relationships, the system knowledge is not complete at a very fundamental level, leading to incomplete coverage of code analysis by vulnerability detection tools, and subsequently, to false negative and false positive report findings.

A system is a collection of activities that exchange information to achieve some common purpose. Computations occur at system nodes that are connected by channels. Following the NIST Common Vulnerability Scoring System (CVSS) [NIST IR-7435 2007], [Schiffman 2004] approach we distinguish local channels between system nodes deployed at the same machine, adjacent network channels between system nodes deployed at the same local area network, and remote channels. This distinction is important because it determines the class of access required in order to exploit vulnerability. Each system node performs computation to provide services to other system nodes or the environment of the entire system. Data interchanges use channels. We distinguish between data at rest (for example, databases), data in motion (data in the channel), and data in use (data flowing inside the computation) (see Figure 8).

The runtime platform manages resources on behalf of the application. This is a very important consideration, as, in fact, many vulnerabilities are related to the usage of the resources (see Figure 9).

So far we have addressed the system facts that are related to the operations of a system. These facts describe the system as a mechanism that performs some activities to achieve required objectives. The system facts addressed the common vocabulary for describing the system in terms of its components, functions, and rules, and the implications of selecting boundaries and resolutions of such descriptions. The evolution of the system (covering the time from conception to operations, and from operations to disposal) bring another dimension to the knowledge of system. Consideration of the system life cycle is an important concern for system assurance because the evolution of the system also includes the evolution of its security posture. Ultimately, a strong security posture is determined by organization of the system (the various rules that are enforced during the operation of the system, whether by technical mechanisms, physical mechanisms, or administrative measures). However, the confidence in the security posture involves knowledge of the evolution of the system, and claims regarding various aspects of how the system was put together. Cyberdefense measures extend to the early phases of the system life cycle: Defenders need to be confident that the desired security mechanisms are built correctly so that they are available during the operations as efficient elements of the operational defense. In order to achieve this, additional defense mechanisms are designed and added to upstream activities of the system life cycle. The evolutionary countermeasures are accounted for in the system assurance case together with the operational countermeasures. Claims about evolutionary countermeasures involve knowledge of system life cycle activities prior to operations, and sometimes also of the activities involved in the disposal of the system.

The system life cycle involves multiple activities. ISO/IEC 15288:2008, “Systems and software engineering—system life cycle processes,” defines a standard framework for describing the system life cycle in terms of various activities involved in creating and utilizing systems. Collectively these activities are bringing together the elements of the future system and are imposing the required organization upon them so that the system emerges, and when launched into operation, its elements are engaged in coordinated interactions that satisfy the objective of the system. The system assurance process as described in Chapter 3 is a logical cross section of the diverse activities throughout the system life cycle organized together to systematically build confidence in the security posture of the system.