System Security Engineering for Information Systems
Logan O. Mailloux1, Michael R. Grimaila1, John M. Colombi1, Douglas D. Hodson1 and Gerald Baumgartner2, 1United States Air Force Institute of Technology, Wright-Patterson AFB, OH, USA, 2Laboratory for Telecommunications Science, College Park, MD, USA
This chapter discusses the problematic intersection of risk management, mission assurance, security, and information systems through the illustrative example of the United States (US) Department of Defense (DoD). A concise history of systems security engineering (SSE) is provided with emphasis on recent revitalization efforts. Next, a review of established and emerging SSE methods, processes, and tools (MPT) frequently used to assess and manage critical shortfalls in the development and fielding of complex information-centric systems is provided. From this review, a common theme emerges—the need for a holistic multidisciplinary approach that addresses people, processes, and technologies to manage system complexity, while providing cost-effective security solutions through the use of established systems engineering techniques. Multiple cases and scenarios that promote the discovery and shared understanding of security solutions for complex systems by those trained in the art and science of systems engineering, information security, and risk management are demonstrated.
Keywords
system security engineering; information systems; information technology; security; risk management; program protection
Information in this chapter
• A concise history of system security engineering is provided;
• Established system security engineering methods, processes, and tools are described with emphasis on United States Department of Defense program protection planning; and
• Modern and emerging system security engineering methods, processes, and tools for complex information-centric systems are described.
Introduction
The benefits of embedding information and communications technologies (ICT), also known as “cyber systems,” into core business processes are well understood as a means to increase operational efficiency, improve decision quality, and reduce costs. Information systems and technologies permeate almost every aspect of life, from hand-held smart phones to massive smart grids; they enable modern 21st-century lifestyles. However, security and assurance of these systems proves elusive. Understanding and controlling risks in an ICT System-of-Systems (SoS) environment is difficult due to the complex nature of modern information-centric systems and a dynamic, often hostile operational environment. This problem is further exacerbated by the nature of cyber system operations, which involve numerous interactions between people, processes, and technologies that is difficult to account for in present security efforts.
Large, widely distributed organizations especially struggle with this ICT security problem. The United Stated (US) Department of Defense (DoD) is an excellent example of a large organization with multi-level security requirements that continues to struggle with risk management, assurance, and security despite massive outlays of financial and personnel resources. Conservative estimates place federal cyber security spending at roughly $10 billion for 2012, with projections up to $14 billion in 2017.
Like many large organizations, parts of the US DoD are primarily focused on providing mission-essential services in any operating environment or condition. Whether relying on a commercial financial service or a tactical intelligence system, users cannot tolerate security compromises or extended outages. Furthermore, military missions often involve dynamically changing, time-sensitive, complex, cooperative, and coordinated ventures among multiple organizations (e.g., units, services, agencies, coalition partners) who may not share in a complete view of their roles within the overall mission, which creates the need for a structured means to collect and evaluate security requirements from a diverse set of stakeholders, each with different goals and objectives. These non-trivial complex security issues would ideally be addressed through a holistic systems engineering (SE)–based approach, known as system security engineering (SSE), to manage or reduce system complexity while providing continuous improvement and cost-effective security solutions.
In this chapter, we provide a concise history of SSE followed by a detailed description of longstanding US DoD SSE methods, processes, and tools (MPT) used to limit vulnerabilities in operational environments. Next, SSE modern and emerging MPTs to manage critical shortfalls in the development and fielding of complex information-centric systems are described. Finally, conclusions and recommendations are provided to promote the discovery and shared understanding of complex system security problems and solutions through multidisciplinary efforts by those trained in the art and science of systems engineering, security engineering, and risk management to assure critical missions and secure modern ICT implementations.
System security engineering history
The field of systems security engineering is extremely young when compared to traditional engineering disciplines. System security engineering was first defined in 1989 by US DoD Military Standard 1785 and superseded in the otherwise unchanged 1995 edition of the Military Handbook 1785 [1]:
Systems Security Engineering. An element of system engineering that applies scientific and engineering principles to identify security vulnerabilities and minimize or contain risks associated with these vulnerabilities. It uses mathematical, physical, and related scientific disciplines, and the principles and methods of engineering design and analysis to specify, predict, and evaluate the vulnerability of the system to security threats.
A number of observations can be made from the historic definition. First, SSE is an element or specialty of systems engineering. Second, the primary purpose of this engineering specialty is to identify, minimize, and contain vulnerabilities and their associated risks. Third, SSE is a multidisciplinary effort that uses scientific disciplines, principles, and methods to identify and assess vulnerabilities. Lastly, the SSE handbook’s stated objective is to reduce system vulnerabilities prior to system fielding which lends itself to early design and development initiatives.
The system security engineering process
The foundation of SSE rests on cost-benefit decision tradeoffs focused on engineering out vulnerabilities and designing in security countermeasures as long-term cost saving measures [1]. The SSE process was originally considered for the design and development of systems with respect to the acquisition life cycle phases shown in Figure 1.1, while program protection addresses operations and support in phase IV:
• Phase 0. Develop system security criteria, describe the baseline security system design, and conduct security threat and vulnerability studies.
• Phase I. Analyze and validate the system security baseline, prepare preliminary performance specifications for security hardware and software, and process identified threats and vulnerabilities through system design modifications and risk management techniques.
• Phase II. Design and integrate the security system, acquire or develop security system hardware and software against the specifications.
• Phase III. Implement the security system design via production and conduct deployment planning.
• Phase IV. Address operational and support security concerns through continual risk management via the program protection process.
Figure 1.1 DoD Acquisition management phases [2].
From this description we note fundamental items of interest that constitute core SSE MPTs. Risk management forms the crux of US DoD system security and protection efforts through threat identification and vulnerability analysis serving as the basis for all SSE decisions. Of great importance, system security requirements are also emphasized from initial concept exploration to implementation and production. Lastly, integrated throughout the acquisition process is the system security baseline, which serves as the foundation for security tradeoffs.
In the 1990s, industry and government supported the development of a System Security Engineering–Capability Maturity Model (SSE-CMM) to help standardize and assess SSE practices. The SSE-CMM was accepted by the International Organization for Standardization/Intentional Electrotechnical Commission in 2002 and revised again in 2008 [3]. The SSE-CMM formalizes SSE into three separate process areas: risk, engineering, and assurance. The SSE-CMM provides SSE goals consistent with MIL-HDBK-1785 [1], while further attempting to address and clarify difficult security concepts such as assurance and trust:
• Gain understanding of the security risks associated with an enterprise;
• Establish a balanced set of security needs in accordance with identified risks;
• Determine that operational impacts due to residual security vulnerabilities in a system or its operation are tolerable (i.e., determine acceptable risks);
• Transform security needs into security guidance to be integrated into the activities of other disciplines employed on a project and into descriptions of a system configuration or operation;
• Establish confidence or assurance in the correctness and effectiveness of security mechanisms; and
• Integrate the efforts of all engineering disciplines and specialties into a combined understanding of the trustworthiness of a system.
Over the next decade, information system functionality was chiefly emphasized over security, leading to a general neglect of the art and science of SSE [4]. However, during this period some works on security engineering were published, including Bruce Schneier’s Secrets & Lies in 2000 [5], and Ross Anderson’s Security Engineering in 2001 [6]. Additionally, during this timeframe the International Information Systems Security Certification Consortium (ISC)2 created the Certified Information Systems Security Professional (CISSP) and later, in conjunction with the National Security Agency, added the Information System Security Engineering Professional (ISSEP) credential to focus specifically on engineering processes.
The revitalization of system security engineering
A number of recent high-profile commercial and DoD-related security compromises have caused a renewal of interest and widespread acceptance of SSE as a specialized domain of expertise in both the US government and industry [7,8]. The International Council On Systems Engineering (INCOSE) officially recognized SSE as a specialty domain in August 2011 and committed to writing a dedicated SSE section in the 2013 INCOSE Handbook rewrite [9]. The Stevens Institute is responsible for hosting the online Systems Engineering Book of Knowledge (SEBoK) [10] and recently produced a US DoD sponsored System Security Engineering Technical Report [11]. These international and academic organizations are helping to reinstitute and advance SSE as a multidisciplinary specialty domain combining systems engineering (SE), information assurance (IA), and critical knowledge of established security domains (i.e., the CISSP common body of knowledge) to overcome the elusive ICT security problem [12,13].
Established system security engineering methods, processes, and tools
In this section, we detail existing SSE MPTs, with particular focus on the US DoD program protection planning process. The established SSE MPTs will be further considered, in view of a holistic SSE approach selectively applied throughout the system life cycle, in order to manage system complexity and provide cost-effective security solutions for ICT systems.
Acquisition program protection planning
Under Secretary of Defense for Acquisition, Technology, and Logistics Frank Kendall recently released a directive that “reflects the integration of the Acquisition Information Assurance (IA) Strategy and recognizes Program Protection as the Department’s holistic approach for delivering trusted systems” [14]. To a great extent, SSE has been conducted in the US DoD through a multifaceted program protection planning framework, as shown in Figure 1.2. The framework depends upon the risk-based identification and mitigation of potential vulnerabilities, which continue to be refined as understanding and expertise grow. For example, detailed accompanying program protection guidance was recently added to the Defense Acquisition Guide (DAG), via a new chapter, in November 2012 [16].
Figure 1.2 Acquisition program protection planning [15].
At the highest level, program protection for large acquisition programs is driven by laws and regulations within the defense acquisition management system [17], which drives a cost-based life cycle decision approach. Depending on the purpose, expense, and sensitivity of a given acquisition system, a scalable level of protection should be conducted to meet sponsor needs and government requirements.
Identification and protection of critical program information and technology (CPI/T) is defined in DoD Instruction 5200.39 [18]. Program protection for hardware and software components is defined in the Trusted Systems and Networks DoD Instruction 5200.44 [19], which dates back to the celebrated “Orange Book” of 1985 [20]. More recently, the role of Information Assurance (IA) has been formalized through the risk-based DoD Information Technology Security Certification and Accreditation Process (DITSCAP), and later updated to the DoD Information Assurance Certification and Accreditation Process (DIACAP) [21].
The protection process begins with identifying leading-edge research and technologies that support US DoD mission areas, as shown in Table 1.1 [16]. Examples of CPI/T may be as specific as engine designs for supersonic flight, software assurance techniques for information systems, or unique manufacturing processes for low observable composite wings.
Table 1.1
The Program Protection Planning Process [16]
Step 1: Identify CPI/T and Component-Level Criticality Analysis
Step 2: Threat Analysis
Step 3: Vulnerability Assessment
Step 4: Risk Assessment
Step 5: Countermeasure(s) Implementation
Step 6: Horizontal Protection (i.e., internal protections to the DoD)
Step 7: Foreign Involvement (i.e., external protections to the DoD)
Criticality analysis is used to provide a mission-oriented analysis of system functions and components, which are prioritized into four criticality levels, listed in Table 1.2 [16]. The defined criticality capture the consequence or potential loss of critical system components. Defined levels also allow for consistent system risk and mission assurance analysis across competing systems and missions.
Table 1.2
Criticality Levels [16]
| Level I: Total Mission Failure | Program protection failure that results in total compromise of mission capability. |
| Level II: Significant/Unacceptable Degradation | Program protection failure that results in unacceptable compromise of mission capability or significant mission degradation. |
| Level III: Partial/Acceptable Degradation | Program protection failure that results in partial compromise of mission capability or partial mission degradation. |
| Level IV: Negligible Degradation | Program protection failure that results in little or no compromise of mission capability. |
Figure 1.3 demonstrates the program protection process and is described with respect to Table 1.1. The results of CPI/T identification and component-level critical analysis (step 1) are combined, forming consequence ratings for individual mission capabilities, while threat analysis (step 2) and vulnerability assessment (step 3) define the likelihood of losing a particular mission capability for the initial risk assessment. Threat and vulnerability identification, analysis, and assessment must be conducted for all potential actors or activities, hostile and non-hostile. Most often DoD risk assessments (step 4) result in an initial risk posture composed of a 5×5 categorization of high, medium, and low risks. Example program risks are shown as R1 and R2. The program protection risk assessment needs to be a detailed holistic mission-oriented capability analysis against all known and postulated threats, vulnerabilities, and weaknesses. Consideration for risk mitigation strategies (risk reduction, avoidance, transfer, or acceptance) and additional countermeasures is made until agreeable levels of risk are achieved within programmatic cost-benefit limitations (step 5). The results of risk mitigation decisions are shown as lower risks R1′ and R2′, with reduced consequence and likelihood postures.
Figure 1.3 Risk assessment methodology [16].
Although it is still developing, the program protection process seems to have a physical component orientation, while perhaps neglecting the holistic nature of modern missions and systems; that is, the interactions of people, processes, and technology produce the desired capability. Ideally, system security engineers can leverage this existing process to select and implement multidisciplinary cost-effective security solutions.
Information assurance
Returning to Figure 1.2, we see that the US DoD utilizes a complete system life cycle risk-based methodology for information assurance, certification, and accreditation through the DIACAP approach, which is largely based on information classification levels. DIACAP describes a step-by-step approach to assure that DoD systems are protected by addressing confidentiality, integrity, availability, authentication, and non-repudiation. The US DoD’s approach to information assurance continues to improve through collaborative initiatives with other federal organizations, such as the ongoing transformation initiative between the US DoD and the National Institute of Standards and Technology (NIST). This effort seeks to provide common terminology, processes, acceptance, and architectures using NIST Special Publication 800-53 as a baseline framework for standardizing risk management approaches [22].
For ICT implementations, DIACAP serves primarily as a formal way to identify and document risk before authorizing connectivity to the broader DoD network. For large information-centric acquisition programs, multiple critical design and development activities should occur throughout the system life cycle. Design and development activities are typically run as specialized teams with multiple representatives from the sponsor, responsible program office, testing organizations, user communities, and various other subject matter experts. Information assurance testing events are most often realized through system security assessments and penetration testing events conducted by highly training cyber security and software professionals.
For conventional weapon systems, the difficulty of information assurance and software testing has come to a head with one of the most complex systems ever developed—the Joint Strike Fighter. The newly appointed program executive officer, Air Force Major General Bogdan, recently stated, “The ‘gorilla in the room’ is testing and securing the 24 million lines of software code for the plane and its support systems, a mountain of instructions that goes far beyond what has been tried in any plane” [23]. Early program testing efforts for the Joint Strike Fighter reflect a significant shift in capability delivery from hardware-based systems to software-oriented functionality.
Information assurance and, more fully, system assurance efforts, such as component verification and system validation provide SSE requirements traceability. This helps the DoD achieve its goal of assured systems through program protection [24].
Systems engineering critical reviews
The DoDI 5000.02 defense acquisition management system describes a formal process for developing and fielding desired capabilities for sponsors and users [17]. A critical aspect of its success is the integration of system engineering efforts in key technical reviews and decision points, as shown in Figure 1.4. These key points represent ideal opportunities for system security engineers to address security, risk, and program protection issues in a formalized and iterative fashion and to work in a multidisciplinary, collaborative environment to simultaneously address multiple interest groups [16].
Figure 1.4 Systems engineering critical reviews [16].
A successful risk-based SSE approach lies in the identification and correct assessment of risks across all involved people, processes, and technologies that contribute to the desired capability(ies) while selecting and implementing appropriate safeguards. Experienced program managers, system engineers, and especially system security engineers need to thoroughly understand the desired capability(ies), requirements, and operational environment in order to make correct decisions and properly informed recommendations [3].
Modern and emerging system security engineering methods, processes, and tools
Many modern and emerging SSE MPTs exist to assess and manage critical shortfalls in the development and fielding of complex information systems. This section describes SSE MPTs, which aid in understanding and controlling system complexity for secure ICT implementations.
Discovery and understanding of complex systems for security
While advanced hardware and software implementations along with extensive interoperability are often the very enablers of desired critical mission functionality, their intrinsic complexity is diametrically opposed to the required security of those missions and systems. However, this is precisely where security engineers can leverage SE MPTs to perform complex system analysis, functional decomposition, and system integration activities to dissect complex systems into manageable parts [25].
Consider, for example, the interoperability requirements and resulting dependencies for a vast classified Command and Control (C2) system as the Combined Air Operations Center (CAOC), which can employ hundreds of personnel across elaborate suites of over 50 software applications and sensors responsible for controlling thousands of aircraft for a large geographical area. More complex still are Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems such as the Distributed Common Ground Station (DCGS), configured to store, analyze, and pass real-time classified intelligence information across globally distributed operational nodes while directly interfacing with live intelligence gathering assets. Lastly, Figure 1.5 demonstrates the collaborative interoperability provided by the Global Information Grid (GIG) for which the National Security Agency provides a robust information assurance program [26].
Figure 1.5 Global information grid architecture [26].
Modern weapon systems are an amazing collaboration of people, processes, hardware, software, and firmware that must function correctly to enable mission-essential capabilities; they are large, complex SoS implementations. To address these SoS problems, the DoD published the SE guide for SoS in 2008 [27]. However, even though SE and SoS SE practices have been established for a number of years, they have not been widely accepted or applied to the security domain. Some SE best practices for consideration are:
• Following a formalized system development process, such as Agile software development, Spiral development (Boehm), Rational Unified Process (RUP), Test-driven development (TDD), or evolutional acquisition process (DoD);
• Following a logical series of developmental activities such as the V-Model;
• Using model-based systems engineering (MBSE) tools and best practices;
• Utilizing concept of operations visualization;
• Early prototyping and testing;
Novel complex system analysis approaches include: game theory, agent-based models, and non-linear dynamics [28]. SSE must leverage these MPTs to first understand and then implement cost-effective security solutions.
Mission assurance
The US DoD faces the daunting challenge of executing military operations against an array of adversaries and environments across the globe—from isolated nationalistic countries to dispersed networks of terrorist cells. This uniquely difficult and dynamic task has spawned an operationally focused, mission-oriented view to address poorly understood risks and interactions, formally defined in [29]:
Mission Assurance. A process to protect or ensure the continued function and resilience of capabilities and assets—including personnel, equipment, facilities, networks, information and information systems, infrastructure, and supply chains—critical to the execution of DoD mission-essential functions in any operating environment or condition.
Inherent in mission assurance is the holistic ability to perform risk management through the identification, assessment, and protection of critical people, processes, and technologies responsible for ensuring mission-essential functions. An excellent example of the linkage between mission assurance and information system risk management is demonstrated by the Mission Assurance Categories (MAC) (Table 1.3) [30].
The information assurance MACs are broken down by identification, analysis, and mitigation technique, consistent with risk management strategies. The MACs clearly define identification and analysis criteria, as well as what risk mitigation steps are necessary. Although the MAC levels are defined with respect to information systems, other mission types can be similarly identified, analyzed, and mitigated to include people and processes.
The US DoD’s movement toward mission assurance demonstrates a greater understanding of the risk modern warfighters face. Although still maturing, mission assurance holds potential as an effective tool for addressing mission risk and overcoming operational complexity through a holistic (people, processes, technologies) risk management approach. Additionally, mission assurance identification and analysis provides an effective way to quickly prioritize operational-based risk and security concerns. Lastly, as an identified best practice, system security engineers should address changing operational environments and attempt to consider unexpected system modifications that may occur during fielding to support evolving mission needs [31].
Formalized security requirements
Initial concept definition and requirements analysis efforts allow system security engineers the opportunity to develop formal security requirements, which can then be effectively incorporated into system design efforts. Formalized security requirements should address conventional security attributes such as confidentiality, integrity, availability, authorization, and non-repudiation. Further, defined security requirements should contain desired levels of security or assurance [24]. The SEBoK offers nine requirement areas for consideration (Table 1.4) [10].
Table 1.4
SSE Requirement Areas [10]
| • Physical | • Transmission |
| • Personnel | • Cryptographic |
| • Procedural | • Communications |
| • Emission | • Operations |
| • Computer Security |
These security requirement areas set the stage for well-understood and formalized system-level requirements that can be easily understood, accepted, and correctly implemented. Furthermore, defining the requirements upfront allows for clear system-level requirements that lend themselves to easier requirements traceability throughout system development and also provides an effective means to embrace the “build-in not bolt-on” security best practice.
Early design considerations
Early involvement by system security engineers examines the widest solution space possible, and therefore, the best opportunity to positively affect the system development for successful fielding. This is especially true for complex ICT SoS implementations, which have many technical issues to manage. Further, system security engineers should take a top-down design strategy when approaching new system development, traditionally considered a strength of the SE discipline [32]. Expert guidelines, lessons learned, and best practices should be taken into consideration early in system design, when they have the best opportunity to be accepted and implemented. Some overarching security engineering-oriented guidelines for system design are offered [33]:
1. Simple is better, but no simpler than necessary is prudent (unwarranted complexity, over-coupling, and unnecessary dependencies);
2. Having contingencies is a good idea (defining failure and response);
3. Using “watchdogs” distributed throughout the system to monitor and report;
4. Configuring for reduced functionality or graceful shutdown;
5. Modularity of functions to enable isolation of offending operations;
6. Shifting functions based on threats; and
7. Configuring the system for failure (whether accidental or malicious).
Traditional fields of security engineering include security protocols, trust relationships, access controls, and cryptology, with each supplying a vast set of best practices and helpful resources, which should be explored for applicability early in the design phase. For example, defense-in-depth has long been considered a key principle of security engineering and should be applied whenever possible. While this principle remains true, system security engineers must design in detection capabilities and not just prevention tools. There is a subtle difference between detection and prevention requirements; however, the cost and difficulty to implement them can be substantial. System thinking approaches can also aid the development of protection schemes when identifying, defining, and addressing mission-essential tasks, operational environment(s), and system boundaries within the system solution trade-space.
Plan for failure
Given the complexity of modern ICT systems and the rapidly changing threat environment, the system security engineer must plan for system failure. Well-known security engineer Ross Anderson states, “Failure recovery is often the most important aspect of security engineering, yet it is one of the most neglected” [6]. But first, organizations must learn to accept system failure. In order to facilitate organizational change, system security engineers should promote shared understanding through educating decision makers on successful fail-safe strategies and mitigating MPTs. Such strategies generally include a number of technical and non-technical design considerations for fault avoidance, fault tolerance, error recovery, failure recovery, and system resiliency. Fail-safe strategies should then be fully integrated as part of the complete design solution trade-space.
Designing fail-safe, resilient ICT systems is a difficult multidisciplinary endeavor, which system security engineers must become increasingly aware of in high-threat environments [34]. Further, fail-safe engineering requires a detailed understanding of the subject system such that extensive domain expertise may be required.
Security and system patterns
Since 1995, object-oriented software design patterns have proven to be a valuable resource for the software engineering community [35]. The information system community has attempted to develop their own security patterns, defined as “a particular reoccurring security problem that arises in specific contexts, and presents a well-proven generic solution” [36]. These security patterns range from conceptual topics such as risk management to detailed implementation issues like programming language-specific Web-based application security. Formalized patterns have also been extended to system design [37]. While security and system pattern research is still in early development, there could be great benefits in a formalized approach that provides a reusable library of solutions to specific ICT security problems.
Leveraging system architectures for security
System security engineers can evaluate preliminary or proposed system or enterprise architectures to identify and assess security considerations between systems, operators, and networks [38]. System architectures identify and define the system’s interactions between people, processes, and various ICT systems including key interfaces and dependencies. DoD Architecture Framework (DoDAF) viewpoints may also help understand and analyze the security trade-space [39].
Specifically, operational views are helpful to identify and understand critical nodes, organizations, and information exchanges while illustrating critical functions along with their dependencies. System and service views help to understand and define system boundaries, inputs, outputs, controls, and supporting mechanisms. The combination of viewpoints supports the identification, understanding, and definition of critical interfaces throughout the system design and development phases. Lastly, the DoDAF offers the possibility of both security views, which facilitate identification and understanding of security points of interest, and verification views, which support system assurance efforts.
Agile and self-organizing system security
An up-and-coming field for SSE is agile system security, which considers designing systems that can detect and proactively respond during unexpected conditions such as cyber attacks. The concept goes well beyond intrusion prevention system responses and enables systems to dynamically respond to uncertain incidents, ensuring continuing operation [40]. Self-organizing systems imply an extremely agile and readily adaptable system configuration capable of reorganizing in response to unexpected system or environmental changes [41,42]. These advanced system designs hold promise for system security engineers.
Security metrics and evaluation
The ability to accurately determine the effectiveness of security solutions is a non-trivial problem that is receiving increased attention as security experts continually attempt to understand the ICT security problem [43]. Security metrics to assess the effectiveness of security solutions is a prevalent area of research both formally and informally [44]. Academic experts and security practitioners have the difficult task of recommending and justifying security expenditures in a cost-constrained, resource-limited environment.
System security engineers need to thoroughly understand the complete risk environment to ensure that recommended and selected security solutions will provide the desired capability. Furthermore, a significant research area exists in measuring and assessing information-centric SoS performance and security metrics [45].
Identified SSE research areas
Ongoing basic research efforts by the INCOSE SSE Working Group are attempting to identify, define, share, and advance modern systems security solutions where no agreed-upon solutions exist. Furthermore, the SSE Working Group is using a commonly understood life cycle approach to promote awareness and adaptability to existing system development efforts [46].
• Conceptual: Explore and advance technology trends and strategies that identify potentially beneficial technologies, advance promising security strategies, or protect desired system capabilities.
• Development: Ensure that security concepts are translated into verifiable requirements with defined levels of effectiveness. Provide functional designs with integrated system solutions facilitating necessary security characteristics.
• Production: Provide insight into security considerations during fabrication, implementation, and integration to ensure security settings and configurations are properly initialized and delivered.
• Operations and Support: Monitor and maintain security effectiveness during the entire system lifetime, including considerations for changes in the operational, user, and threat environments. Ensure security features are updated and effective such that system capabilities are supported or enhanced. Continually assess security features for effectiveness.
Beyond community wide standardization, Steven’s Institute has identified a list of potential SSE research areas for further exploration: scalable trustworthy systems; enterprise-level metrics; system evaluation life cycle; combating insider threats; combating malware and botnets; global-scale identity management; survivability of time-critical systems; situational understanding and attack attribution; provenance of information, systems, and hardware; privacy-aware security; and usable security [11].
Conclusion
The US DoD continues to have significant challenges and successes in terms of addressing risk, system security, and mission assurance. Modern information-centric systems contain millions of lines of source code controlling critical mission functions through a vast suite of interconnected and distributed systems, sensors, and operators. These complex systems present the difficult challenge of understanding a dynamic integrated suite of people, processes, and technologies in a resource-constrained environment. The US DoD has invested billions of dollars in government, industry, and academic organizations to study, address, and refine this difficult task, with many insights and lessons to be gleamed.
• Performing risk analysis for missions and systems leads to a more complete understanding of the subject system and its associated risks while also identifying potential areas for further mitigation;
• The dynamic nature of modern systems and mission demand continuous monitoring;
• Resource limitations necessitate the utilization of proven best practices for risk analysis techniques and mitigation strategies;
• Continuous process improvement lends itself to the rapidly evolving nature of holistic systems; that is, constantly changing people, processes, and technologies; and
• Determining the effectiveness of risk management, and specifically security solutions, is both an art (i.e., qualitative) and a science (i.e., quantitative).
Recommendations
From this review of established, modern, and emerging SSE MPTs, a number of recommendations can be made for the broader community struggling with ICT system security.
• Foster the development of multidisciplinary professionals trained in the art and science of systems engineering, security engineering, and risk management; these professionals are best situated to understand today’s complex systems to holistically manage the dynamic risk environment and provide cost-effective security solutions.
• Promote the discovery and shared understanding of complex systems through awareness, education, training, shared lessons learned, and documented best practices to enable improved security postures of complex ICT systems.
• Further explore identified SSE research areas. In the authors’ opinion, the research and application of security-oriented metrics, interoperability performance, and system architectures for security show promise.
Disclaimer
The views expressed in this paper are those of the authors and do not reflect the official policy or position of the United States Air Force, the Department of Defense, or the US Government.
Acknowledgments
This work was supported by the Laboratory for Telecommunications Sciences (grant number 5713400-301-6448).
References
1. DoD. Military Handbook 1785. System security engineering program management requirements Washington, DC: Department of Defense; 1995.
2. Schmoll JH. Introduction to defense acquisition management 2nd ed. Fort Belvoir: Department of Defense Systems Management College; 1993.
3. ISO/IEC 21827 ISO/IEC 21827:2008(E) Systems security engineering: Capability maturity model (SSE-CMM), security techniques, information technology. 2nd ed. Geneva, Switzerland: ISO/IEC; 2008.
4. Irvine C, Nguyen TD. Educating the systems security engineer’s apprentice. IEEE Security & Privacy. 2010;8(4):58–61.
5. Schneier B. Secrets and lies: Digital security in a networked world New York: John Wiley & Sons; 2000.
6. Anderson R. Security engineering Indiana: Wiley Publishing; 2008.
7. Baldwin K, Miller J, Popick P, Goodnight J. The United States Department of Defense revitalization of system security engineering through program protection. Pap presented at the Systems Conference (SysCon) 2012;1–7 2012 IEEE International.
8. Lewis JA. Raising the bar for cybersecurity. Center for Strategic and International Studies: Technology & public policy; 2013.
9. Dove R. Something wicked this way comes … SE responsibility for system security. Unpublished PowerPoint presentation. INCOSE Enchantment Chapter Meeting; 2012 Sep 12.
10. Pyster A, Olwell D, Hutchison N, et al. Guide to the systems engineering body of knowledge (SEBoK) Version 1.0 Hoboken, NJ: The Trustees of the Stevens Institute of Technology©; 2012.
11. Hamilton D, Horowitz B, Neuman C. Systems security engineering final technical report SERC-2010-TR-005 Hudson, NJ: Stephens Institute; 2010.
12. Baldwin K. Systems security engineering: A critical discipline of systems engineering. Insight 2009;12(2):113.
13. Baldwin K, Dahmann J, Goodnight J. System of systems security: A defense perspective. Insight 2012;14(2):113.
14. Kendall F. Document streamlining—program protection plan (PPP) Washington, DC: Principal Deputy Under Secretary of Defense for Acquisition, Technology, and Logistics; 2011.
15. Baldwin K. DoD trusted systems and networks (TSN) update. [PowerPoint presentation]. NDIA Cyber Division Breakfast Meeting, Office of the Deputy Assistant Secretary of Defense for Systems Engineering, OUSD(AT&L); 2013.
16. Defense Acquisition Guide Defense acquisition guidebook [Internet]. Version 16. Oct 2012 [cited 2012]. Retrieved from https://dag.dau.mil.
17. DoD. DoD Instruction 5000.02. Operation of the Defense Acquisition System. Washington, DC; 2008.
18. DoD. DoD Instruction 5200.39. Critical Program Information (CPI) Protection Within the DoD. Washington, DC; 2010.
19. DoD Instruction 5200.44. Protection of mission critical functions to achieve trusted systems and networks (TSN) Washington, DC: DoD Chief Information Officer/Under Secretary of Defense, Acquisition, Technology, and Logistics; 2012 Jul 16.
20. DoD. DoD 5200.28-STD. Trusted Computer System Evaluation Criteria. 1985 Dec.
21. DoD Instruction 8510.01. DoD information assurance certification and accreditation process (DIACAP) Washington, DC: Assistant Secretary of Defense for Networks and Information Integration/DoD Chief Information Officer; 2007.
22. Cussatt, D. DoD IA policy portfolio update. [PowerPoint presentation]. Information Assurance Symposium; 2011.
23. Drew, C. The next war, costliest jet, years in making, sees the enemy: Budget cuts. [Internet]. New York Times [cited 2012 Nov 29]. Retrieved from: http://www.nytimes.com.
24. National Defense Industrial Association Engineering for systems assurance Assurance Committee. Arlington, VA: National Defense Industrial Association (NDIA); 2008.
25. Bayuk JL. Systems security engineering. Security & Privacy, IEEE. 2011;9(2):72–74.
26. Global Information Grid [Internet] 2008 Nov 14 [updated 2012 Apr 23; cited 2013 July 9]. Available from: http://www.nsa.gov/ia/programs/global_information_grid/index.shtml.
27. Systems engineering guide for systems of systems. Version 1.0. Washington, DC: Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems and Software Engineering; 2008.
28. Calvano CN, John P. Systems engineering in an age of complexity. Sys Eng. 2004;7(1):25–34.
29. DoD. DoD Directive 3020.40. DoD Policy and Responsibilities for Critical Infrastructure. Washington, DC; 2012.
30. DoD Instruction 8500.2. Information assurance (IA) implementation Washington, DC: Assistance Secretary of Defense for Command, Control, Communications and Intelligence; 2003.
31. Dove R. Systems of systems and self-organizing security. Insight. 2011;14(2):7–10.
32. Sutton SJ. Securing a system of system: Start with the threats that put the mission at risk. Insight. 2011;14(2):15–18.
33. DeSpain MJ. Toward a dynamic system architecture for enhanced security. Insight. 2009;12(2):18–19.
34. Rieger C. Resilient control systems: A basis for next-generation secure architectures. Insight. 2009;12(2):20–21.
35. Gamma E, Helm R, Johnson R, Vlissides J. Design patterns: Elements of reusable object-oriented software Boston: Addison-Wesley; 1994.
36. Schumacher M, Fernandez-Buglioni E, Hybertson D, Buschmann F, Sommerlad P. Security patterns: Integrating security and systems engineering West Sussex, England: John Wiley & Sons; 2006.
37. Cloutier RJ, Verma D. Applying the concept of patterns to systems architecture. Sys Eng. 2007;10(2):138–154.
38. Wirsbinski J, Boardman J. Establishing security strategy using systems thinking. Insight. 2009;12(2):41–43.
39. DoD Architectures Framework DoDAF architecture framework Version 2.0. Washington, DC: DoDAF Working Group; 2009.
40. Bayuk JL. Systems-of-systems issues in security engineering. Insight. 2011;14(2):22–24.
41. Dove R. Embedding agile security in system architecture. Insight. 2009;12(2):14–17.
42. Nichols C, Dove R. Architectural patterns for self-organizing systems-of-systems. Insight. 2011;14(2):42–44.
43. Chew E, Swanson M, Stine K, Bartol N, Brown A, Robinson W. NIST Special Publication Performance measurement guide for information security Gaithersburg, MD: National Institute of Standards and Technology; 2008; sp800-55:Rev1.
44. Metricon. Seven metrics challenges. [Internet]. In: Proceedings of The Eighth Annual Meeting of Metricon 2013 Mar 1 [cited 2013 Jun 26]. Retrieved from: http://www.securitymetrics.org.
45. Ford TC, Colombi JM, Jacques DR, Graham SR. A general method of measuring interoperability and describing its impact on operational effectiveness. The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology. 2009;6(1):17–32.
46. Dove R. DRAFT System security engineering handbook section. Paper presented at the 2013 INCOSE International Workshop, System Security Engineering Working Group; 2013 Jan 26–29; Jacksonville, FL.
Further reading
1. INCOSE. INCOSE system engineering handbook. Version 3.2.2. INCOSE-TP-2003-002-03.2.2. San Diego, CA: International Council on Systems Engineering (INCOSE); 2011.
2. Meier JD, Mackman A, Wastell B, Bansdone P, Taylor J, & Araujo R. Microsoft’s Security Engineering Explained. [Internet] 2005. [cited 2013 Aug 23]; Available from: https://www.securityinnovation.com/uploads/SecurityEngineeringExplained.pdf.
3. Stuart J. Engineering Information Security: The Application of Systems Engineering Concepts to Achieve Information Assurance. Vol 14. Wiley.com; 2011.