**5.5.5 Privacy implementation**

Privacy breaches occur mainly due to the failure to develop the business processes around privacy. Privacy management should not be reactive. Protecting privacy and personal data should be an integral component in the development of information systems that involve PII. Privacy should be one of the most important priorities in the development of trusted information systems, not an afterthought.

Most importantly, privacy depends upon the human component of the system to handle and exchange information with the machine component in a manner that establishes accountabilities for it at the outset and at every opportunity during the use and exchange of tagged and marked information with privacy attributes. Most losses of privacy are the result of human mishandling of information or the failure of machinery to maintain security of the information as it is manipulated and handled according to privacy attributes that originate with humans. Frequently, human handling or the inability of machine components to preserve privacy attributes at exchange points are the primary reasons for privacy failures. Nonetheless, privacy failures are usually misattributed to security failures.

you what information is collected and how it is used. It does not necessarily mean that your privacy is protected and may actually specify that privacy is not provided. The inability for individuals to agree in terms of what they believe is an appropriate privacy policy or practice is a major challenge to achieving consistent protection for groups of individuals.

The ability to balance the privacy concerns of individuals with effective monitoring of potential insiders is a very challenging task. One significant problem is that individuals often are not aware of the information that is collected and how it is used or what has been done with it. In addition to the privacy conditions of notice, choice, use, and security, it is equally important to offer the privacy conditions of correction and enforcement. These six conditions associated with privacy are derived from the European Union's Privacy Directive and are briefly described in Table 5. Transparency protects not only the individual but the

Notice The individual has the right to know that the collection of PII will exist. Choice The individual has the right to choose not to have the data collected.

Security The individual has the right to know the extent to which the data will be

Correction The individual has the right to challenge the accuracy of the data and to

Use The individual has the right to know how data will be used and to restrict its

Enforcement The individual has the right to seek legal relief through appropriate channels

Privacy breaches occur mainly due to the failure to develop the business processes around privacy. Privacy management should not be reactive. Protecting privacy and personal data should be an integral component in the development of information systems that involve PII. Privacy should be one of the most important priorities in the development of trusted

Most importantly, privacy depends upon the human component of the system to handle and exchange information with the machine component in a manner that establishes accountabilities for it at the outset and at every opportunity during the use and exchange of tagged and marked information with privacy attributes. Most losses of privacy are the result of human mishandling of information or the failure of machinery to maintain security of the information as it is manipulated and handled according to privacy attributes that originate with humans. Frequently, human handling or the inability of machine components to preserve privacy attributes at exchange points are the primary reasons for privacy failures.

Nonetheless, privacy failures are usually misattributed to security failures.

Privacy is not absolute. There are many trade-offs in the benefits versus the risks.

organization or company and promotes public trust.

use.

protected.

Table 5. Privacy Control Conditions

information systems, not an afterthought.

**5.5.5 Privacy implementation** 

**Condition Description** 

provide corrected information.

to protect privacy rights.

**5.5.4 Transparency** 

Privacy must be considered an integral part of the development and use of an information system. Privacy policies and procedures must be developed as part of the business process so that appropriate IA measures can be implemented to support them. Recall that security can be developed without privacy but privacy cannot be provided without security. However, security measures cannot address all privacy issues; hence privacy must be considered from the beginning. Privacy management should not be an afterthought, reactive, or piecemeal.

The following recommendations are provided to help move forward in providing both security and privacy for information systems:

	- The information that is being collected,
	- Why the information is being collected,
	- Intended use of the information,
	- With whom the information will be shared,
	- What opportunities individuals will have to provide information or to consent to particular uses of the information,
	- How information will be secured, and
	- Whether a system of records is being created under the privacy policy.

A significant gap in R&D is the interface between human and machine components of a system. Security is about the machine component. Privacy is about the human component and its interaction with the machine component.

In summary, an information system should have a privacy policy that publicly articulates that it will adhere to legal requirements and processes that enable gathering and sharing of information to occur in a manner that protects personal privacy interests. A well-developed and implemented privacy policy should also be transparent in order to protect the enterprise, the individual, and the public; and promotes trust. A well-developed privacy policy also ensures that appropriate IA measures can be taken to meet both security and privacy needs.

#### **5.6 Supplier-Supply Chain Risk Management (S-SCRM)**

Traditional research work in supply chain risk management involves activities and processes for planning, coordination, operation, control, and optimization of the supply chain. These efforts do not examine supply chain risks associated with the compromise or loss of product/service confidentiality or integrity. Supply chain exploits are the opportunities where adversaries can gain access, obtain knowledge, insert malicious code, or corrupt devices bound for information systems.

Challenges in Building Trusted Information Systems 103

Vulnerability

**(Qualitative Judgment Based on Impacts ‐ If Realized)**

Consider:

• Acquisition & Support • Resource Impacts • Influence on other

(*Based on Exposure*)

**Susceptibility**

**(Qualitative Judgment of Susceptibilities)**

**Consequence**

(*Assess*)

**Results Used to Assess Strategy Options for Managing Supply Chain Risks**

of susceptibilities and their potential consequences gives visibility to risk managers and the opportunity to understand the worth of engineering for securing of systems and the residual risks for which security is currently not possible or not affordable. These can then be used to rationalize and justify R&D to discover, invent, and innovate security measures, which if applied achieve dependable and economic implementations able to withstand this emerging insider threat of compromised machinery and its potential to behave as intended most of the

The prospect that variable human-motivated and incentivized behaviors are the only insider behaviors to withstand by applying security measures is no longer wise given both the pervasive dependencies on ICT and the complexities and difficulties of having, maintaining, and sustaining provenance and visibility of supplied items and the production and delivery processes of their suppliers. The most basic need is to advance an agenda of R&D that recognizes today's security measures and countermeasures are not scalable to the new world order. This does not make the current research efforts unnecessary, but they are clearly not sufficient. The authors use the "label" of active risk management to capture the need for scalable means of identifying, implementing, and managing the application of countermeasures and mitigations for this growing set of risks that can never be fully prevented, eliminated, or avoided; but rather must be actively managed. Furthermore, the authors contend that the engineering for active risk management will stress the ability of traditional engineering disciplines, because it is likely to require risk management to be "built-in," not applied and forgotten. In the same manner that much rhetoric surrounds the "building-in" of security versus "strapping it on" like appliqué armor, active risk management will demand advances in design techniques, new and innovative ways and

Fig. 5. Framework for Assessing Supply Chain Risk Management Strategies

time and to change behavior and become malicious at inopportune times.

**Mission Impact**

(*If Realized*)

**Risk** systems, etc. **‐Reduction Return on Investment (RROI)**

**Affordability of COA to Mitigate**

(e.g., *Availibility, Integrity, Confidentiality*) External Results Abort Stop/Start Degraded Change/Disclose Data

(*Based on Access*)

Threat

Consider: • Ops Prevent

• Alternatives

• Recover/Reconstitute

In recent years, supply chain risk management research work emphasizes the key role of managing the operational risks in multi-layered supply chains. The authors have presented an enterprise framework for characterizing supplier-supply chain risk management that captures the underlying complexity and scope of concerns to manage globalization of ICT risks (Chan & Larsen, 2010). The holistic view provides a way to manage risk by bringing intelligence mitigations, technical mitigations, and business mitigations into a tradespace to reach a collective view and to review or adjudicate decisions to obtain a tolerable riskreduction – return on investment in making informed acquisition and procurement decisions of ICT components and services bound for trusted information systems and networks. Additionally, there have been a number of risk management decision models that may apply to managing supply chain quality risk, including supplier qualification screening, multi-sourcing, flexibility, and penalties levied for supplier non-performance (Tse & Tan, 2011).

Figure 5 illustrates a framework to assess strategy options for managing supply chain risks. Risks must meet a threshold of feasible realization to be considered for the application of countermeasures or mitigations. This figure proposes an approach to determine the feasibility of risk mitigation strategies by making a determination of susceptibility (previously defined as an intersection at a point or interval of time of a threat able to gain access with the exposure of a vulnerability). Note that this requires access and exposure to occur at the same point or during some interval of time in order to become susceptible to an adverse consequence. Thus, simply being accessible or being vulnerable is insufficient to gauge the degree of consequence. The coincidence of a threat and vulnerability may have quite different consequences depending on the time of coincidence and the particular mission operation underway. Consequences must be judged with respect to impact on mission and relative to the state of mission execution (a point or duration in time). An assessment can then be made on whether the system retains the risk and the associated impacts on mission performance or if the risk needs to be specifically countered or mitigated. Subsequently, an appropriate risk reduction strategy must be developed by both considering the existing counters and mitigations and the availability or potential for applying additional countermeasures and mitigations to diminish the impact. In some cases, the strategic outcome may require a change of operational concept, a redesign of the system or component in order to eliminate a susceptibility, alter the consequence impact, or develop more effective and affordable counters and mitigations, or in extreme cases abandon the system altogether.

In all cases, this collection of knowledge is applicable in an iterative manner to arrive at an approach that applies supplier and supply item countermeasures and mitigations at various points of risk realization – either in a general manner or very specific manner. This could be at the level of threat actor generally (avoid suppliers) or more specifically at the point of access to a vulnerability (know the supplier but assume the item of supply can become an insider threat). Similarly, one can deal with vulnerabilities. In the ideal case, exquisite knowledge and opportunity exist to deal with susceptibilities that give rise to intolerable risks. If not, then counters and mitigations can be developed and applied for an assumed or poorly understood susceptibility and the consequences implied to system performance if realized. In the end, no judgment can be satisfactory without some sense of the economic and mission impact of uncountered and unmitigated risks. At a minimum, the identification

In recent years, supply chain risk management research work emphasizes the key role of managing the operational risks in multi-layered supply chains. The authors have presented an enterprise framework for characterizing supplier-supply chain risk management that captures the underlying complexity and scope of concerns to manage globalization of ICT risks (Chan & Larsen, 2010). The holistic view provides a way to manage risk by bringing intelligence mitigations, technical mitigations, and business mitigations into a tradespace to reach a collective view and to review or adjudicate decisions to obtain a tolerable riskreduction – return on investment in making informed acquisition and procurement decisions of ICT components and services bound for trusted information systems and networks. Additionally, there have been a number of risk management decision models that may apply to managing supply chain quality risk, including supplier qualification screening, multi-sourcing, flexibility, and penalties levied for supplier non-performance (Tse

Figure 5 illustrates a framework to assess strategy options for managing supply chain risks. Risks must meet a threshold of feasible realization to be considered for the application of countermeasures or mitigations. This figure proposes an approach to determine the feasibility of risk mitigation strategies by making a determination of susceptibility (previously defined as an intersection at a point or interval of time of a threat able to gain access with the exposure of a vulnerability). Note that this requires access and exposure to occur at the same point or during some interval of time in order to become susceptible to an adverse consequence. Thus, simply being accessible or being vulnerable is insufficient to gauge the degree of consequence. The coincidence of a threat and vulnerability may have quite different consequences depending on the time of coincidence and the particular mission operation underway. Consequences must be judged with respect to impact on mission and relative to the state of mission execution (a point or duration in time). An assessment can then be made on whether the system retains the risk and the associated impacts on mission performance or if the risk needs to be specifically countered or mitigated. Subsequently, an appropriate risk reduction strategy must be developed by both considering the existing counters and mitigations and the availability or potential for applying additional countermeasures and mitigations to diminish the impact. In some cases, the strategic outcome may require a change of operational concept, a redesign of the system or component in order to eliminate a susceptibility, alter the consequence impact, or develop more effective and affordable counters and mitigations, or in extreme cases abandon the

In all cases, this collection of knowledge is applicable in an iterative manner to arrive at an approach that applies supplier and supply item countermeasures and mitigations at various points of risk realization – either in a general manner or very specific manner. This could be at the level of threat actor generally (avoid suppliers) or more specifically at the point of access to a vulnerability (know the supplier but assume the item of supply can become an insider threat). Similarly, one can deal with vulnerabilities. In the ideal case, exquisite knowledge and opportunity exist to deal with susceptibilities that give rise to intolerable risks. If not, then counters and mitigations can be developed and applied for an assumed or poorly understood susceptibility and the consequences implied to system performance if realized. In the end, no judgment can be satisfactory without some sense of the economic and mission impact of uncountered and unmitigated risks. At a minimum, the identification

& Tan, 2011).

system altogether.

Fig. 5. Framework for Assessing Supply Chain Risk Management Strategies

of susceptibilities and their potential consequences gives visibility to risk managers and the opportunity to understand the worth of engineering for securing of systems and the residual risks for which security is currently not possible or not affordable. These can then be used to rationalize and justify R&D to discover, invent, and innovate security measures, which if applied achieve dependable and economic implementations able to withstand this emerging insider threat of compromised machinery and its potential to behave as intended most of the time and to change behavior and become malicious at inopportune times.

The prospect that variable human-motivated and incentivized behaviors are the only insider behaviors to withstand by applying security measures is no longer wise given both the pervasive dependencies on ICT and the complexities and difficulties of having, maintaining, and sustaining provenance and visibility of supplied items and the production and delivery processes of their suppliers. The most basic need is to advance an agenda of R&D that recognizes today's security measures and countermeasures are not scalable to the new world order. This does not make the current research efforts unnecessary, but they are clearly not sufficient. The authors use the "label" of active risk management to capture the need for scalable means of identifying, implementing, and managing the application of countermeasures and mitigations for this growing set of risks that can never be fully prevented, eliminated, or avoided; but rather must be actively managed. Furthermore, the authors contend that the engineering for active risk management will stress the ability of traditional engineering disciplines, because it is likely to require risk management to be "built-in," not applied and forgotten. In the same manner that much rhetoric surrounds the "building-in" of security versus "strapping it on" like appliqué armor, active risk management will demand advances in design techniques, new and innovative ways and

Challenges in Building Trusted Information Systems 105

Trustworthy and reliable is the definition of dependable. Thus, securely engineering

The authors posit that dependability is one of the missing specifications that enable the systems security engineering community to be more effective through the lifecycle of a system's development and to maintain effectiveness during operations and maintenance of a system. Without a specification of necessary and sufficient trustworthiness in the context of a system's use, it is extremely difficult to provide the arguments and demonstrations of the worth of security measures. They are often then subordinated in the engineering trade-space

Dependability may serve as the property that combines security engineering with other engineering disciplines that lead to security being "built-in" versus "strapped-on." Security cannot be an afterthought. It must be built into cost, schedule, and performance. Not all risks are equal and not all users/consumers have equal tolerance for risks. Dependability establishes the value of security measures in a way that they legitimately become part of the engineering trade-space. It places a value on security measures that enable a value of worth during operations and use and serves as a metric for how well risks have been managed. Dependability may be the basis for integrating traditional "engineering of" systems (the partitioning with a defined system boundary and application of engineering disciplines) with the larger context of "engineering for" systems (the inclusion of the system

"Engineering of" systems requires a holistic perspective that treats the operating environment of the engineering of a system concept, design, development, implementation, and support as more than an assumed and invariant actor that must merely be characterized and exploited by the system to be engineered. The operating environment "as a system" can be conceived, designed, developed, implemented, and supported to attain an advantage or benefit or present a risk. This is what distinguishes the "engineering of" versus the

Systems engineering is defined as an interdisciplinary approach to enable the realization of successful systems. It focuses on defining user needs and required functionality early in the development cycle, documenting requirements, and then continuing with the design synthesis and system validation while bearing in mind the whole problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. Systems engineering includes both the business and technical needs of all users with the objective of creating a quality product that meets user needs. Systems engineering can fit within the overall engineering systems field. For example, systems engineering views the enterprise as a consideration or major influence on the system whereas engineering systems

Engineering systems is an emerging interdisciplinary academic and research field focused on addressing large-scale, complex engineering challenges with their social-political context. It takes an integrative holistic view of large-scale, complex, technologically-enabled systems with significant enterprise level interactions and socio-technical interfaces (Rhoades & Hastings, 2004). It may include components from several engineering disciplines, as well as

environment that leads to the specification and definition of a system boundary).

systems need to move in the direction of being dependable.

to other systems engineering factors (the other "ilities").

includes the enterprise as an essential part of the system.

**5.8 Engineering systems** 

"engineering for" a system.

means of implementing countermeasures and mitigations, and vastly improved instrumentation to know the state of risk, the state of counters for such risks, and the invocation of countermeasures and mitigations on-demand.
