System Security Engineering Guidebook

The Black Book: A Starter Guide to Systems Security Engineering for Acquisition

Bradley Doohan (Australia); Steve Sterling, Mark Jennings, Frederic Painchaud, LCol Yves Turcotte, LCdr Marc Lanouette (Canada); Paul Caseley, Gerard Talbert and Edward Bush (United Kingdom); and, Melinda Reed, Dana Franz, Jean-Paul LeSaint, Glenda Turner (United States).

TTCP Document

DOC-JSA/TP4-1-2016

Defence Research and Development Canada Reference Document DRDC-RDDC-2016-D061 October 2016 © Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2016 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2016 Abstract

This booklet is an introduction to systems security engineering management concepts, terms and activities and supports the TTCP four national strategic drivers: Interoperability; Affordability; Effective Decision Making; and Agility (flexible adaptable systems). It is intended to help systems engineers within TTCP Nations and defense contractor personnel understand how security issues affect their role within the systems acquisition process.

The contents of this booklet is intended for information purposes only and must therefore not be used as the basis for any contract or instruction to contractors.

i Résumé

Le présent livret est une introduction aux concepts, aux modalités et aux activités de gestion en matière d’ingénierie de la sécurité des systèmes et appuie les quatre facteurs stratégiques nationaux du TTCP : interopérabilité, viabilité financière, prise de décisions efficaces et agilité (systèmes adaptables et souples). Ce document vise à aider les ingénieurs de systèmes au sein des pays membres du TTCP et du personnel de l’entrepreneur de la défense à comprendre comment les problèmes de sécurité ont une incidence sur leur rôle dans le cadre du processus d’acquisition de systèmes.

Le contenu de ce livret a été rédigé aux fins d’information seulement; c’est pourquoi il ne doit pas servir de fondement à tout contrat ou directives à l’intention des entrepreneurs.

ii The Technical Cooperation Program

Australia - Canada - New Zealand - United Kingdom - United States of America

TTCP DOCUMENT

The Black Book: A Starter Guide to Systems Security Engineering for Acquisition

11 October 2016

DOC-JSA/TP4-1-2016

This document contains Information authorized under the auspices of The Technical Cooperation Program (TTCP) for unlimited release and distribution.

1 BACKGROUND

Defense acquisitions organisations need to give systems security engineering a high priority due to increased dependence on commercial components in mission critical systems, the fast pace of change in information systems and the emerging cyber threats to military systems, and system of systems. This dependency is being driven by a number of factors such as globalisation in the supply chain and the transition of cost effective manufacturing from traditional first world environments. This report is a product of The Technical Cooperation Program, Joint Systems Analysis group, Technical Panel 4, Systems Engineering for Defense Modernization, Systems Security Engineering work-stream.

PURPOSE This booklet is an introduction to systems security engineering management concepts, terms and activities and supports the TTCP four national strategic drivers: Interoperability; Affordability; Effective Decision Making; and Agility (flexible adaptable systems). It is intended to help systems engineers within TTCP Nations and defense contractor personnel understand how security issues affect their role within the systems acquisition process. The contents of this booklet is intended for information purposes only and must therefore not be used as the basis for any contract or instruction to contractors.

ACKNOWLEDGEMENTS

This booklet concept is based on the “Introduction to System Safety Management in the MOD” known colloquially in the UK MOD as the ‘Safety White Book’. This ‘Black Book’ was developed and written by the Systems Security Engineering (SSE) Work Stream of The Technical Cooperation Program (TTCP) Technical Panel (TP) on Systems Engineering for Defense Modernization, and their National organizations. Panel members include David Oxenham (Chairman, United Kingdom); Mark Unewisse (Australia); Robert Burton (Canada); David Dean (United Kingdom); and Kristen Baldwin (National Leader) and Robert Gold (United States). The SSE work stream members include Bradley Doohan (Australia); Steve Sterling, Mark Jennings, Frederic Painchaud, LCol Yves Turcotte, LCdr Marc Lanouette (Canada); Paul Caseley, Gerard Talbert and Edward Bush (United Kingdom); and, Melinda Reed, Dana Franz, Jean-Paul LeSaint, Glenda Turner (United States). The work stream members also gratefully acknowledge the suggestions and critique from other experts within their national organizations. The combined efforts of these individuals and organizations made possible the development of this guide.

Suggestions for improvement should be sent to: TTCP JSA TP4 SE chair Professor David Oxenham e-mail: [email protected]

2 CONTENTS 1 INTRODUCTION ...... 5 1.1 What is Systems Security Engineering? ...... 5 1.2 The Importance of Early Systems Security Engineering ...... 5

2 INTRODUCTION TO SYSTEMS SECURITY ENGINEERING ...... 7 2.1 Systems Security Engineering Perspective ...... 7 2.2 Threats and Vulnerabilities ...... 8 2.3 Systems Security Engineering Risk ...... 9 2.4 How Much Systems Security Engineering is Enough? ...... 9 2.5 Systems Security Engineering Protection Scheme ...... 10

3 SECURITY/LEGAL RESPONSIBILITIES ...... 11

4 SECURITY COMPETENCE AND CULTURE ...... 12 4.1 Systems Security Engineering Competence ...... 12 4.2 The Culture of Systems Security ...... 12

5 OVERSIGHT OF SYSTEMS SECURITY ENGINEERING ...... 14 5.1 Who Builds Security In? (Systems Engineers) ...... 14 5.2 Pre-requisites to Successful Systems Security Engineering ...... 14 5.3 Stakeholder Requirements Definition and Requirements Analysis Processes ...... 15 5.4 Architectural Design Process ...... 15 5.5 Verification and Validation Processes ...... 15 5.6 Incident Handling and Applying the Lessons...... 15

6 SYSTEM SECURITY ENGINEERING RISK MANAGEMENT ...... 17 6.1 Security Risk Management Introduction ...... 17 6.2 Risk Assessment ...... 17 6.3 Risk Register ...... 17 6.4 Asset Valuation ...... 17 6.5 Threat Assessment ...... 17 6.6 Vulnerability Assessments ...... 17 6.7 Risk Response ...... 18

7 SYTEM SECURITY ENGINEERING LIFECYCLE ...... 19 7.1 TTCP Nations Life Cycle ...... 19 7.2 System Conceptual Stage ...... 20 7.3 Development Stage ...... 20 7.4 Production Stage ...... 21 7.5 Utilisation/In-Service Support ...... 21 7.6 Disposal ...... 22 7.7 Integrated Systems Security Engineering ...... 22 7.8 Continuous Improvement ...... 23

8 SYSTEMS SECURITY ENGINEERING AND SUPPLY CHAIN MANAGEMENT ...... 24 8.1 Introduction...... 24 8.2 Systems Security Engineering Role and Approach ...... 24

3 9 REFERENCES AND USEFUL FURTHER READING ...... 25 Referenced Publications ...... 25

4 ,1752'8&7,21 .H\0HVVDJHV x 6\VWHPVVHFXULW\HQJLQHHULQJ 66( LVFRQVLGHUHGDGLVFLSOLQHRIV\VWHPVHQJLQHHULQJ x 6\VWHPVHQJLQHHULQJDQGWKXV66(DSSOLHGHDUO\LQWKHDFTXLVLWLRQOLIHF\FOHSURFHVVKDVEHHQUHFRJQL]HGDV DNH\HQDEOHURIDFTXLVLWLRQVXFFHVV x 7KH1DWLRQV¶PLOLWDU\V\VWHPVDUHFRQWLQXDOO\IDFLQJQHZFKDOOHQJHV GXH WR WKH UHYROXWLRQ LQ 'LJLWDO 7HFKQRORJLHVFRPSOH[6\VWHPRI6\VWHPVDQGWKHJURZLQJF\EHUWKUHDW7KH\DUHDOVRGHSHQGHQWRQ2II 7KH6KHOIFRPSRQHQWVIURPWKH*OREDOVXSSO\FKDLQ

:KDWLV6\VWHPV6HFXULW\(QJLQHHULQJ"

6\VWHPV VHFXULW\ HQJLQHHULQJ 66( LV D VSHFLDOW\ HQJLQHHULQJ ILHOG VWURQJO\ UHODWHG WR V\VWHPV HQJLQHHULQJ DV LOOXVWUDWHG LQ )LJXUH ,W DSSOLHV VFLHQWLILF HQJLQHHULQJ DQG DVVXUDQFH SULQFLSOHV WR GHOLYHU WUXVWHG V\VWHPV WKDW VDWLVI\VWDNHKROGHUUHTXLUHPHQWVZLWKLQWKHLUHVWDEOLVKHGULVNWROHUDQFH>@

)LJXUH6\VWHPVVHFXULW\HQJLQHHULQJDVSDUWRIV\VWHPVHQJLQHHULQJ

7KH,PSRUWDQFHRI(DUO\6\VWHPV6HFXULW\(QJLQHHULQJ 1DWLRQV QHHG WKHLU V\VWHPV DQG SODWIRUPV WR EH VHFXUH WUXVWZRUWK\ DQG LQWHURSHUDEOH ZKDWHYHU WKH RSHUDWLRQDO HQYLURQPHQW )RU SURMHFWV GHSHQGHQW RQ 2II7KH6KHOI 276 FRPSRQHQWV WKH QRQIXQFWLRQDO UHTXLUHPHQWV PDLQWDLQDELOLW\UHOLDELOLW\VDIHW\VHFXULW\ PXVWEHFRQVLGHUHGHDUO\LQWKHV\VWHPVHQJLQHHULQJSURFHVVIRUFRVW HIIHFWLYHPLWLJDWLRQRIWKHULVNV

6\VWHPRI6\VWHPV 6R6 LVGHILQHGDV³$VHWRUDUUDQJHPHQWRIV\VWHPVWKDWUHVXOWVZKHQLQGHSHQGHQWDQGXVHIXOV\VWHPVDUH LQWHJUDWHGLQWRDODUJHUV\VWHPWKDWGHOLYHUVXQLTXHFDSDELOLWLHV´86'HIHQVH$FTXLVLWLRQ*XLGHERRN7KH77&3*XLGH RQ 6R6 VHH UHI >@ VKRXOG DOVR EH FRQVXOWHG IRU DGYLFH RQ KRZ VHFXULW\ DQG RWKHU V\VWHPV HQJLQHHULQJ LVVXHV VKRXOG EH FRQVLGHUHGGXULQJWKHDFTXLVLWLRQOLIHF\FOHIRUDV\VWHPZLWKLQDV\VWHPRIV\VWHPV

The lack of applied SSE has often led to major security incidents. Early SSE implies identifying “protection requirements” and “protection countermeasures” up front during the exploratory stage of the acquisition life cycle and conducting engineering trade-offs, which considers these requirements. Despite significant strides in developing secure and trustworthy systems, adversaries continue to compromise military systems. Due to poor systems security engineering, adversaries have a broad range of attack methods. The following two incidents highlight the vulnerability of systems and supply chains. The fact that systems and supply chains are vulnerable, and potentially could enable attacks, confirms the need to implement SSE early and throughout the life cycle.

1) Volkswagen Emissions Test Software

In September 2015, it was announced by the U.S. Environmental Protection Agency that Volkswagen had intentionally incorporated modified emissions software in diesel engines of vehicles sold in the U.S. that could detect when they were being tested and change the performance to improve results [2]. The US Environmental Protection Agency (EPA) report reveals some key points regarding the importance of implementing strong system security practices: ∗ Modifications made within the supply chain are difficult to detect once the product is transferred to the acquirer. ∗ Modifications can be made such that a device appears to be operating normally while actually operating in an unintended manner.

2) Remote exploitation Jeep Cherokee – Uconnect’s cellular vulnerability

Security researchers from two US Universities demonstrated that they could wirelessly disable the locks and brakes on a vehicle [3]. Extracting from the internet many automobile technical specifications, technical manuals, architecture diagrams, and wiring diagrams from automobile manufacturers, this technical information was used to determine automobile potential vulnerability to hackers via ingress and egress points to the internet. Researchers then studied remote exploits, vulnerabilities, and reverse-engineering the firmware of a Jeep Cherokee vehicle which has Uconnect [4] integrated within it.. Then some of the firmware was re- written with the researchers code in order to allow them to send, via the internet, remote commands to the vehicle network CAN bus which enabled these commands to be sent to the vehicle network-enabled components like windshield wipers, brakes, engine, steering, user displays, etc…, thus allowing the researchers to remotely control the vehicle. In hacking terms this is called a zero day exploit. This incident led to a significant safety recall [5].

Implementation of early SSE is a key enabler to understanding the security risks and therefore managing and delivering an acceptable operational system. SSE is an integral engineering discipline within systems engineering with an emphasis on systems engineering vice security engineering. SSE requirements need to be integrated into the overall system requirements and to be applied throughout the life cycle but is most effective in the early phases of system engineering. The Nations’ military systems are continually facing new challenges due to the revolution in Digital Technologies, complex Systems of Systems [24] and the growing cyber threat. Security incidents are difficult to contain in a boundless, networked environment and can cause grave national, and international, interoperability consequences. SSE needs to be aware of traditional assurance techniques and apply them from new perspectives to respond to the challenges posed by Cyber and complex global supply chains. SSE employs critical thinking to systems security to integrate the contributions across security engineering disciplines such as cyber security, hardware / software assurance, supply chain risk management, technology sharing and security specialties to produce a coherent security capability across the system. The Systems Security Engineering supports the systems engineering evaluation and balancing of security with respect to system performance, cost and schedule. 6 2 INTRODUCTION TO SYSTEMS SECURITY ENGINEERING

Key Messages • SSE needs to consider development environment, acquisition, and operational contexts.

• Adversaries are the threats and they will attempt to exploit a system’s weaknesses (vulnerabilities). • Systems security decisions should be driven by security risk, to include considerations of mission-impact of security, the likelihood of vulnerabilities being exploited, and the security risk tolerance applicable for the system. • Not all vulnerabilities can be prevented which requires the system owner to determine the risk tolerance. A cost-effective protection scheme should include prevention, detection and response measures. These trade- offs are determined by SSE and inform the system owners security risk decisions.

2.1 Systems Security Engineering Perspective This section introduces the context of SSE, including the primary desired outcomes and its application for a system with a particular emphasis on acquisition. It will also introduce the concept of risk as a driver for SSE activities, and outlines the tenets of an effective protection scheme. ISO/IEC 15288 [6] defines a system as a “combination of interacting elements organized to achieve one or more stated purposes.” Ultimately, SSE efforts focus on the “stated purposes” of the system, which can be described as the capabilities or the mission of the system. This effort includes not only ensuring that security concerns are sufficiently addressed so that the system is able to perform its mission in the security threat environment, but also ensuring that the system will not perform additional functions that the system is not intended to perform. In order to deliver a sufficiently secure system and achieve the stated general goals of systems security, the context within which security is considered must be broadened beyond the system itself to include the systems development environment, acquisition, and operational context (which includes maintenance and sustainment efforts). This is because how the system is developed, acquired, and operated/maintained can introduce security vulnerabilities into the system. In essence, SSE must integrate into all existing system life cycle processes defined by ISO/IEC/IEE 15288:2015 (Figure 2) [6]. Additionally, it is key to integrate SSE considerations into technical reviews and audits, such as those defined in IEEE 15288.2-2014 [7].

System Life Cycle Processes – ISO/IEC/IEEE 15288 Agreement Processes Technical Management Processes Technical Processes − Acquisition Process − Project Planning Process − Business or Mission Analysis − Supply Process − Project Assessment and Control Process Process − Stakeholder Needs and − Decision Management Process Requirements Definition − Risk Management Process Process − Configuration Management − System Requirements Process Definition Process − Information Management − Architecture Definition Process Process − Measurement Process − Design Definition Process − Quality Assurance Process − System Analysis Process − Implementation Process − Integration Process − Verification Process − Transition Process − Validation Process − Operation Process − Maintenance Process − Disposal Process Organizational Project-Enabling Processes − Life Cycle Model Management Process − Infrastructure Management Process − Portfolio Management Process − Human Resource Management Process − Quality Management Process − Knowledge Management Process Figure 2. System Life Cycle Processes [6]

2.2 Threats and Vulnerabilities A threat is defined by NIST SP 800-160 [1] as “any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, [ …] via unauthorized access, destruction, disclosure, modification […], and/or denial of service.” A vulnerability is defined as a “weakness in [a ….] system, systems security procedures, internal controls, or implementation that could be exploited or triggered by a threat source” [1]. Each of these concepts are factors for determining how likely it is for a system to be exploited. The more an adversary is motivated to attempt to realize an adverse circumstance (a threat), and the greater the opportunity is to exploit the system in order to realize that event (a vulnerability), the more likely it is that the system will be exploited. Despite significant strides in developing secure and trustworthy systems, adversaries continue to compromise systems through their vulnerabilities. There is a broad range of threats that may impact the operation of systems, including, threats from:

8 ,QVLGHUDWWDFNV 6RFLDOHQJLQHHULQJDWWDFNV 3K\VLFDODWWDFNV $WWDFNVRQWKHJOREDOVXSSO\FKDLQ &\EHUDWWDFNV $WWDFNVRQGHYHORSPHQWSURFHVVHVDQGWRROV $WWDFNVZLWKLQ&276SURGXFWV

6\VWHPV6HFXULW\(QJLQHHULQJ5LVN

6\VWHPVVHFXULW\ULVNLVDQDORJRXVWRRWKHUW\SHVRIULVNVLQWKDWLWLVFRPSRVHGRIWZRIDFWRUV WKHVHYHULW\RI LPSDFWIRUDQHYHQWDQG WKHSUREDELOLW\WKDWWKHHYHQWZLOORFFXU,QVHFXULW\WKHOHYHORILPSDFWLVFRQVLGHUHGWR EH WKH LPSDFW RQ WKH V\VWHP¶V DELOLW\ WR FRPSOHWH LWV PLVVLRQ 7KH SUREDELOLW\ RI RFFXUUHQFH LV EDVHG XSRQ WKH WKUHDWVWRDQGYXOQHUDELOLWLHVRIWKHV\VWHP

)LJXUH66(5LVN0DWUL[

6HFWLRQRIWKLV*XLGHSURYLGHVDGHWDLOHGGHVFULSWLRQRIWKHJHQHUDOPHWKRGVIRUDQDO\VLQJDQGPDQDJLQJV\VWHPV VHFXULW\ ULVNV IRU D V\VWHP *HQHUDOO\ V\VWHPV VHFXULW\ ULVN LV D PDLQ GULYHU IRU V\VWHPV VHFXULW\ DFWLYLWLHV DQG GHFLVLRQV

+RZ0XFK6\VWHPV6HFXULW\(QJLQHHULQJLV(QRXJK" 6\VWHPVVHFXULW\ULVNVGRQRWH[LVWLQDYDFXXPDQGPXVWEHFRQVLGHUHGZLWKLQWKHFRQWH[WRIWKHV\VWHPDQGRWKHU V\VWHP FKDUDFWHULVWLFV 7KH OHYHO RIDFFHSWDEOHV\VWHPVVHFXULW\ULVNLVGHSHQGHQWXSRQWKHULVNDSSHWLWH IRUWKDW SDUWLFXODUV\VWHP2QO\ULVNRZQHUV RUJDQLVDWLRQDQGRUVWDNHKROGHUV FDQGHWHUPLQHULVNDSSHWLWH7KLVLVLPSDFWHG E\PDQ\FRQVLGHUDWLRQVLQFOXGLQJ 7KHLPSRUWDQFHRIWKHPLVVLRQWKDWWKHV\VWHPSHUIRUPV$OHVVLPSRUWDQWPLVVLRQPD\PHDQWKHUHLV JUHDWHUDSSHWLWHIRUVHFXULW\ULVNV 7KHHQYLURQPHQWRIWKHV\VWHP$QRZQHUZKRGHSOR\VDV\VWHPLQDORZHUWKUHDWHQYLURQPHQWPD\EH PRUHZLOOLQJWRDFFHSWVHFXULW\ULVNV$OVRLIWKHV\VWHPPXVWRSHUDWHLQDV\VWHPRIV\VWHPVWKHQWKHUH PD\EHPDQ\LQWHUGHSHQGHQFLHVDQGLQWHUIDFHVWKDWJHQHUDWHVHFXULW\FRQFHUQV6HHUHIHUHQFH>@ 7KHLPSRUWDQFHRIRWKHUQRQIXQFWLRQDOULVNV$JUHDWHUHPSKDVLVPD\EHQHFHVVDU\IRUPDLQWDLQDELOLW\ RUVDIHW\UDWKHUWKDQVHFXULW\ 7KH LPSRUWDQFH RI FHUWDLQ SHUIRUPDQFH FKDUDFWHULVWLFV ,I UHGXFLQJ VHFXULW\ ULVN ZRXOG LPSDFW SHUIRUPDQFHLWPD\EHGHWHUPLQHGWKDWKLJKHUVHFXULW\ULVNVDUHDFFHSWDEOH

As the system progresses through its life cycle and a changing security environment, SSE influences the design decisions to ensure that the systems security protections are sufficient to satisfy the risk owner. Generally, systems security risks become a part of the overall technical risks for a system. Given a limited set of resources, SSE may drive design trade-offs based on the appetite for security risks. How much SSE is enough? Enough to satisfy the risk owner(s).

2.5 Systems Security Engineering Protection Scheme As a whole, protection measures can be classified into two categories. One category of protection measures describe what the system capabilities and attributes must be. These are incorporated into the system requirements and design. The other category of protection measures describe how the system will be built, maintained, or procured. These measures impact all of the elements that contribute to developing and maintaining a system, including processes for the system development, acquisition, and maintenance. Ideally, every vulnerability of a system that presents a systems security risk to the mission would be prevented from being exploited. Prevention measures may need to be revised and adapted to keep pace with the constantly changing threat environment. Despite this challenge, continuously adding prevention measures may not be practical due to increases costs and diminishing benefits – the owner’s acceptance of risk for system trade-off decisions is informed by SSE. Systems security requires a balanced protection approach consisting of the following choices: * Remove the risk, eg. design out the vulnerability; * Reduce the risk, eg. design in prevention measures that monitors the system; * Respond to the realised risk, eg. design in system characteristics or processes to analyze, mitigate and recover from the incident. This balanced approach is also influenced by the underpinning security objectives of Confidentiality, Integrity and Availability. For military systems, the emphasis on these objectives can change the approach in System Security Engineering. For platforms, the priority objective is normally availability, followed by integrity and then confidentiality whereas for traditional enterprise or intelligence systems, confidentiality may be the overriding objective.

Figure 4. Traditional Enterprise vs Military Platform Systems Focused Security

10 3 SECURITY/LEGAL RESPONSIBILITIES

Key Messages • The policies on security differ between the TTCP Nations • Systems security engineers must consider relevant security policies for the risk owners • Despite differing policies, the underpinning SSE principles remain the same across TTCP nations

Each TTCP Nation2 has a defined legal and policy framework. Under these frameworks the Nations’ work to share and collaborate common best practises. This includes influencing international standards for example, ISO/IEC 27001:2013 [8], ISO/IEC 27002:2013 [9], and ISO/IEC/IEE 15288:2015 [6]. Even though the responsibilities of SSE practitioners are different in each Nation, the use of common principles and approaches for security aids understanding, enables interoperability, and is a contributor to effective systems engineering. It is a responsibility of those engaged in SSE to give due weight to all relevant facts, published guidance, and Nations’ legal frameworks. For example, the US has security related legal responsibilities regarding the exporting of specific technologies and information. In such a case, the security restrictions relate to the following export regulations. * International Traffic in Arms Regulations (ITAR) [10]: ITAR controls the export and import of defense- related articles and services on the US Munitions List (USML). It implements the Arms Export Control Act. In order to export USML items to a "foreign person," a US entity must obtain authorization from the U.S. Department of State before the export can take place. * Export Regulations Administration (EAR) [11]: The EAR regulate exports of commercial and “dual- use” goods, software and technology (i.e., items intended for non-military applications that nonetheless may be useful for military purposes). The specific items subject to the export control restrictions under the EAR are identified on the Commerce Control List (CCL).

Each of the other Nations have equivalent legal frameworks that cover the export of strategic controlled goods (ie military or dual-use items).

2 Further references to the word “Nation(s)” will be understood to mean TTCP Nations(s).

11 6(&85,7<&203(7(1&($1'&8/785( .H\0HVVDJHV x 66(FRPSHWHQF\LVUHTXLUHGDQGFDQEHPHDVXUHG x 2UJDQLVDWLRQVQHHGWRGHYHORSDUREXVW6\VWHPV6HFXULW\(QJLQHHULQJ$VVHVVPHQW)UDPHZRUNLQRUGHUWR GHFLGHZKHWKHURUQRWDSHUVRQKDVDFKLHYHGDJLYHQVWDQGDUGRIOHDUQLQJRUFRPSHWHQF\ x $VWURQJRUJDQLVDWLRQDOV\VWHPVVHFXULW\FXOWXUHHQFRXUDJHVVHFXULW\YDOXHVDWWLWXGHVDQGEHKDYLRXUV

6\VWHPV6HFXULW\(QJLQHHULQJ&RPSHWHQFH

7KH QDWXUH RI 'HIHQVH UHTXLUHV WKDW WKH PDQXIDFWXUH DQG GHYHORSPHQW RI VHFXUH V\VWHPV EH GHOLYHUHG DQG HQJLQHHUHG E\ FRPSHWHQW JRYHUQPHQW DQG VXSSOLHU RUJDQLVDWLRQV 7KLV UHTXLUHV WKDW V\VWHPV DUH GHYHORSHG E\ FRPSHWHQWV\VWHPVVHFXULW\HQJLQHHUVZKRPDNHHQJLQHHULQJMXGJHPHQWV WUDGHRIIV EDVHGRQHYLGHQFHVNLOOVDQG H[SHULHQFHDQGWKHRZQHUVULVNDSSHWLWH7KLVVKRXOGHQVXUHWKDWVHFXUHV\VWHPVDUHGHOLYHUHGZLWKFRQVLGHUDWLRQRI SHUIRUPDQFHVFKHGXOHDQGEXGJHW ,QUHVSRQVHHQJLQHHULQJJURXSVDQGJRYHUQPHQWDJHQFLHVKDYHGHYHORSHGDVVHVVPHQWIUDPHZRUNVDQGJXLGDQFHIRU FRPSHWHQF\ PHDVXUHPHQW 2UJDQLVDWLRQVKDYHDEURDGFKRLFHRIFRPSHWHQFHVFKHPHVIRUDVVHVVPHQWWRFKRRVH IURP 6RPH H[DPSOHV DUH VDIHW\ ,(7 >@ VRIWZDUH DVVXUDQFH 6(, >@ JHQHULF PRGHOOLQJ RI FRPSHWHQF\ +ROW>@ DQGV\VWHPHQJLQHHULQJWRLQFOXGHVHFXULW\ 1$6$>@ DQG ,1&26(>@ 7KHUHLVDUHVSRQVLELOLW\RQDFTXLVLWLRQRUJDQLVDWLRQVWRHQVXUHWKDWWKHLUV\VWHPVVHFXULW\HQJLQHHUVDUHVXLWDEO\ TXDOLILHG DQG H[SHULHQFHG 66( LQFRUSRUDWHV D QXPEHU RI FURVVGLVFLSOLQDU\ VNLOOV LQFOXGLQJ 66(VXEVSHFLDOWLHV ZLWK YDU\LQJ FRPSHWHQF\ UHTXLUHPHQWV (DFK GLVFLSOLQH DQG 66( VXEVSHFLDOW\ PD\ KDYH LWV RZQ PRGHO IRU GHPRQVWUDWLQJFRPSHWHQFHZLWKLQWKDWDUHD6HFXULW\UHTXLUHPHQWVGLIIHUJUHDWO\IURPRQHV\VWHPWRWKHQH[WDQG ZKLOVWDV\VWHPVHFXULW\HQJLQHHUPD\EHFRPSHWHQWLQRQHRUPRUHGLVFLSOLQHVLWLVXQOLNHO\WKDWKHVKHZLOOEH FRPSHWHQWLQDOODUHDV+HQFHDPL[RIV\VWHPVVHFXULW\HQJLQHHUVZLWKFRPSOHPHQWDU\H[SHUWLVHPD\EHUHTXLUHG

)LJXUH5HODWLRQVKLSVLQLQWHJUDWHGFRPSHWHQFH

7KH&XOWXUHRI6\VWHPV6HFXULW\

7KHVHFXULW\FXOWXUHRIRUJDQLVDWLRQVLVDVLJQLILFDQWLQIOXHQFHIDFWRURQWKHLUSHRSOH$QRUJDQLVDWLRQZLWKDVWURQJ 66( FXOWXUH EHQHILWV IURP LQFUHDVHG SURWHFWLRQ IRU WKHLU HPSOR\HHV FXVWRPHUV DQG UHSXWDWLRQ DV ZHOO DV FRQWULEXWLQJWRQDWLRQDOVHFXULW\ $V\VWHPVVHFXULW\FXOWXUHLVWKHDWWLWXGHWKDWH[LVWVZKHQHYHU\RQHUHFRJQLVHVDQGDFFHSWVKLVKHUUHVSRQVLELOLWLHV IRUVHFXULW\WDNHVVHFXULW\VHULRXVO\DQGWKHRUJDQLVDWLRQ³WKLQNVVHFXULW\´DVDPDWWHURIFRXUVH7KLVLVDQLGHDO ZKLFKLVGLIILFXOWWRDFKLHYHLQSUDFWLFHEXWRUJDQLVDWLRQVVKRXOGVWULYHWRDFKLHYHDFXOWXUHWKDWLVVWLOOVXEMHFWWR UXOHVDQGDQ\UHOHYDQWQDWLRQDOVHFXULW\UHJXODWLRQV

Errors and mistakes are inevitable, and security can only be improved if the organisation can learn from its mistakes. People should be encouraged to report failures in its organisation’s security products or services, as well as security failures in the internal processes. Organisations should use these lessons to improve training, awareness and the competence of their staff. Finally, staff who report security issues and problems should be commended.

13 5 OVERSIGHT OF SYSTEMS SECURITY ENGINEERING

Key Messages • SSE is a responsibility that permeates all positions related to the development of a system • Responsibility for SSE ultimately resides with the chief systems engineer • SSE must be addressed initially from stakeholder requirements, and continue to be addressed throughout requirements development • Effective SSE introduces protective security measures through architectural design • SSE Verification and Validation follows standard system engineering procedures • SSE also includes the operations processes that cover secure operations, engineering support and incident handling. Applying the lessons learned from incidents is a systems security engineering task.

5.1 Who Builds Security In? (Systems Engineers) Ultimately, the lead systems engineer (or chief engineer) is responsible for all the technical aspects of the system, which includes the performance and other characteristics. Systems security is one of these other, non-functional characteristics for which the lead systems engineer is responsible. Supporting the lead system engineer should be a number of competent systems security engineers, however, every member of the team responsible for the development of the system must be aware and contribute to the security design. From the lowest levels of design to the purchasing of critical system components, security is a consideration that must permeate all responsibilities. Those who have some amount of responsibility for systems security include the following (from NIST SP 800-160 [1]): * Individuals with governance, risk management, security, and oversight responsibilities; * Individuals with acquisition, budgeting, and project management responsibilities; * Individuals with system design, development, and integration responsibilities; * Individuals with systems security, operations, sustainment, and support responsibilities; and * Individuals with independent verification and validation, testing/evaluation, auditing, security assessment, inspections, and monitoring responsibilities. This section will focus on how SSE is incorporated into systems engineering. It will address the dependencies that systems security has with other practices, and then describe how systems security relates to a key set of systems engineering technical processes (aligned with the technical processes in ISO/IEC/IEEE 15288:2015 [6] and NIST SP 800-160 [1]). 5.2 Prerequisites to Successful Systems Security Engineering Many system non-functional characteristics have some dependency on each other and require the others to be sufficiently addressed in order for the system to fulfil its intended purpose. If performance is high, but reliability is very low, then the system doesn’t ever truly perform as needed to fulfil its purpose. Similarly, systems security practices are dependent upon items which are not directly related to security in order to sufficiently address security concerns. Successful SSE has some dependency on the following practices being implemented with a system development effort: * Effective risk management practices * Design reviews * Hiring qualified personnel, and upgrading their skills *Quality Control and Quality Assurance * Configuration management * A healthy security culture, i.e., “Think Security”

14 5.3 Stakeholder Requirements Definition and Requirements Analysis Processes The Stakeholder Requirements Definition process [6] is intended to elicit needs of various stakeholders and transforming these needs into stakeholder requirements, such that the stakeholder requirements define a system that can provide the services needed by users and stakeholders within the defined environment. Security Engineers must understand the security-related aspects of the environments and elicit the expected security needs of the system within that environment. Also, direct protection needs should be elicited as well. This elicitation process provides the base information to define stakeholder requirements which accurately reflect the security needs of the stakeholders, particularly owners of the risk [1]. As part of requirements analysis process, security requirements must be defined and refined – security requirements are influenced by constraints on the project, the risk assessment process (section 6) and Nations’ policies (section 3).

5.4 Architectural Design Process The ideal method of introducing protective security measures is through architectural design. As part of the architectural design process [6], security related requirements should be considered through the following strategy[1]: * Identify and examine architectural design and implementation strategies from a security perspective, eg remove the vulnerabilities * Refine the architecture and design to identify, minimize, and contain the impact of vulnerabilities * Iteratively refine the protections specified by the security design requirements into security specifications and security procedures from which the system is implemented, configured, operated, and maintained, taking into account susceptibility to threats and owner risk tolerance * Ensure configuration management and control processes consider security requirements, to maintain configuration control in an evolving threat environment through application of agile software updates

5.5 Verification and Validation Processes SSE Verification and Validation follows the same procedures and processes as practiced in systems engineering. As a general concept, the verification process ensures that the system was built correctly, essentially ensuring that the system meets performance and design requirements. The validation process ensures that the correct system was built, essentially ensuring that the stakeholder needs and requirements are being met by the system. For verification and validation, both planning and execution of these tasks are vital (ISO/IEC 15288 [6]). As Blanchard and Fabrycky remind us: “Final system validation occurs when the system is performing effectively and efficiently when operating within its associated higher level system of systems configuration” [25].

5.6 Incident Handling and Applying the Lessons SSE also includes the operations processes that cover secure operations, engineering support and incident handling. Acquisition organisations should consider incident handling in their requirements for systems. It is the Acquisition organisation that must prepare and implement the sustainment processes that translates lessons identified from incidents into system improvements. “Once a system is delivered, the operational/sustainment community may provide feedback to the engineering team through security problem and incident reports, observations, and findings to inform subsequent developmental efforts. ” (NIST SP 800-160 [1]) “For example, the engineering team may need to initiate a system modification in a relatively short period of time in order to respond to a serious security incident. In this situation, the engineering team may only informally consider each process rather than formally executing each process. It is essential that any system modifications continue to support the stakeholder’s security needs. Without this system-level perspective, modifications could fix one problem while introducing others.” (NIST SP 800-160 [1])

15 Nations have policies and guidance on incident reporting. Systems security engineers should be part of the incident handling process to ensure the lessons are applied. Guidance on incident response and its lifecycle can be found at (NIST SP 800-61 [17]) and is illustrated in Figure 6. Guidance on analysing lessons learned can be found in (NIST SP 800-55 [18]) and (NIST SP 800-66 [19]). Suppliers of systems should assume that they will have to support and respond to security incidents as part of their SSE activities. For some Nations it is part of law to report incidents. Acquisition organisations will need to ensure that their system suppliers competently support incident handling processes.

Figure 6: Incident response lifecycle (NIST SP 800-61 [5])

16 6 SYSTEM SECURITY ENGINEERING RISK MANAGEMENT

Key Messages • Organisations must assess risk(s) to their systems • System Security Engineers must work with Organisations • A Security Risk Register must be maintained and reviewed on a regular basis

6.1 Security Risk Management Introduction Risk is a measure of the extent to which an entity is threatened by a potential circumstance or event, the adverse impacts that would arise if the circumstance or event occurs, and the likelihood of occurrence. Risk management is conducted as a holistic, enterprise-wide, activity that addresses risk from the strategic level to the tactical level— ensuring that effective risk-based decision making is integrated through life into every aspect of the system life cycle. Risk is managed within the scope and priority of stakeholder risk concerns. System security risk is the product of likelihood and impact, where the likelihood of a security incident is a measure of the threat to the system, the asset value and vulnerabilities. Risks may be articulated either qualitatively or quantitatively.

6.2 Risk Assessment A fundamental principle of risk management is risk assessment, and all organisations must assess risk(s) to their systems. Any assessment must include an asset identification and valuation, vulnerability and threat assessments so that Organisations can understand the risks faced by a system.

6.3 Risk Register

A Security Risk Register must be maintained and reviewed on a regular basis to confirm the applicability of the Risks, or when the operation or usage of the system has altered such that the recorded Risks may no longer be relevant. The Security Risk Register should contain records to display how security issues are being addressed and it should identify any residual risk to the system so that these risks can be presented to the Risk Owner(s) for acceptance. The Security Risk Register is maintained as part of the program Risk Register.

6.4 Asset Valuation

System security engineers must work with Organisations to determine the value or criticality of the system and its component parts based upon the functions that the system is expected to support.

6.5 Threat Assessment

System Owners are responsible for ensuring that a threat assessment is carried out for the system and that systems security engineers are appropriately informed of the threat(s) to the system within its development and operations environments.

6.6 Vulnerability Assessments There are potentially three classes of vulnerabilities in delivered systems: * vulnerabilities whose existence is known and either eliminated or rendered inconsequential; * vulnerabilities whose existence is known but that are not sufficiently mitigated; and

17 * unknown vulnerabilities that constitute an element of uncertainty—that is, the fact that the vulnerability has not been identified should not increase confidence that the vulnerability does not exist.

Vulnerability assessments are systematic investigations of a system throughout its lifecycle to determine and identify vulnerabilities within the system, their severity and exploitability. A systematic investigation may include: supply chain audit, architectural reviews, detailed design reviews, code reviews, port scanning, static code analysis, etc. System Security Engineers are pivotal to the identification and assessment of vulnerabilities at an early stage within the system lifecycle thereby enabling cost-effective treatment.

6.7 Risk Response

An organisation’s response to identified risks to their system may take the form of accepting, avoiding, sharing, transferring, or mitigating that risk. The factors that affect the choice of Risk Response options are discussed at Section 2.4.

18 7 SYTEM SECURITY ENGINEERING LIFECYCLE

Key Messages • Engage security experts and establish systems security requirements early in the acquisition lifecycle • SSE is an ongoing activity throughout the acquisition life cycle. The focus is on integrating security engineering into acquisition development, system production and in-service lifecycles through the adoption of key security-focused activities • Systems security requirements must be traceable right through the SE decomposition, sub-system allocation, build, and verification activities . • SSE should demonstrate elimination of threats and vulnerabilities, and effectiveness of engineered controls prior to the production stage since this can be achieved cost-effectively. • Once the system is In-Service, SSE management focus is on implementing necessary controls (and monitoring any new security gaps) and arrangements to maintain security performance as necessary.

This chapter describes SSE as employed in the major systems acquisition and support lifecycle. Systems, however, that may have additional security policies and processes like National security and intelligence systems, and major IT Systems acquisitions, are not considered herein. Different security engineering activities happen throughout the stages of the system acquisition lifecycle.

7.1 TTCP Nations Life Cycle

Systems Security Engineering needs to be considered at each stage of the acquisition lifecycle and government security requirements as required documented in acquisition contractual documents. Government acquisition organisations employ different procurement stages with distinct characteristics depending on factors such as business context, system complexity, requirements stability, operational urgency and the availability of resources. The typical system acquisition and support lifecycle stages and broad outcomes are shown in Figure 7.

Utilization Stage

Exploratory Conceptual Development Production Support Stage Stage Stage Stage Stage Mission or Enterprise Identify Stakeholder Refine System Produce Investment Needs Requirements Systems Operate Systems Analysis Demonstrate, Explore Concepts of Create Solution Sustain System Inspect and Concepts Operations Descriptions Capability Test Systems Initial Security Propose Viable Commission Prepare System for Risk Build Systems Solutions Systems Disposal Assessments Verify and Validate Systems Figure 7. TTCP Nations Acquisition Lifecycle and Stage Outputs (adapted from ISO/IEC/IEEE 15288)

19 7.2 System Conceptual Stage

At the earliest stage of the project, the emphasis is on deciding if the capability requirements to be delivered have a security concern. Initial activity will include identifying key security related stakeholders and consulting on security issues as part of the early pre-acquisition and planning period, when economic, technical and operational scenarios are assessed through market survey, feasibility and trade-off studies. The SSE program aims to determine whether the capability requirements can be met without unacceptable threat to operations. Where unacceptable threats are identified, the project must consider how these threats may evolve over time and whether they can be eliminated or reduced during the development stage, given the level of technology, cost and schedule risks assessed. Main outputs at this stage, if contractually required, could include: ∗ Identify organisations that will influence ongoing security requirements ∗ Identify broad user needs, scenarios and operational concepts with security implications ∗ Identify functions /system components and operations that may be vulnerable to exploitation ∗ Investment analysis and work processes (cost and schedule estimates) to include security analysis, risk mitigations and countermeasures ∗ Preparing for source selection and define the supplier monitoring/access requirements for security-related products and review activity ∗ Apply security evaluation criteria to proposals ∗ Review compliance with legal and regulatory requirements

7.3 Development Stage

The Development stage comprises the initial design, development, integration, and verification of system capability. The expected threat and security performance of different design options should inform the choice of which option is preferred to meet user needs at an acceptable level of security risk. During this phase the project must decide whether the risks for the system warrant considerable security oversight especially during production stages of the final system capability. Supply chain decisions and engineering level activities are continually being monitored. Initial project assessment of industrial capabilities should include risk assessments and mitigation strategies that can be included in contract requirements, such as: ∗ identification of critical functions and components subject to greater controls ∗ identification of specific testable and measurable parameters for security/protection solution requirements ∗ conduct enhanced design reviews and checklists that are commensurate with risk ∗ conduct specific security verification activities ∗ definition of controls for access to critical components in development / production environment ∗ consideration of supply chain issues for the developing (or final) solution including review of historical data ∗ provision of supplier threat assessments as necessary ∗ assessment of protection measures commonality used across related projects Main output in this stage, if contractually required, could include: ∗ definition of assurance processes and audit requirements to control access to the development and production environment (including software development) ∗ definition of requirements for control over software development tools and other development environments like firmware and system modelling ∗ identification and analysis of vulnerabilities and impacts as part of the system engineering processes, eg Fault Tree Analysis (FTA), Failure Mode, Effects and Criticality Analysis (FMECA) and Criticality Analysis

20 ∗ translation of security risk assessments and vulnerability mitigations into systems security architecture and design requirements ∗ identification of solution options and trade-offs that include security considerations (architecture, design, code, system interfaces, personnel, work procedures) ∗ documentation of critical mission threads and functions to prioritize system protection, in Concept of Operations and Functional Performance Specifications ∗ trace of critical operational functions to solution components (initial) ∗ refinement of Test Concept Documents including verification techniques of mitigations ∗ verification that test plans and system integration environments adequately address security requirements ∗ assurance that security considerations are consistently treated across all capability elements (systems, training, doctrine, logistics)

7.4 Production Stage

The bulk of SSE design verification and validation occurs in the production stage. The aim should be to eliminate threats through design and production changes since this can be achieved cost-effectively at these lifecycle stages. During manufacture, the emphasis is on ensuring that neither production nor any baseline re-design changes have compromised security, and the system is acceptable for use in the operational environment. Once the complete system exists, trials are conducted to test verifiable aspects of the system design and configurations. The necessary in-service security controls (with respect to design controls, work processes and infrastructure) should also be verified. Engineering artefacts such as assurance cases should contain all the necessary security evidence and show how the security targets are being met, or will be met. In SE terms assurance cases are similar to assessment reports that demonstrate security requirements have been adequately traced through design, to verification and validation, certification and accreditation activity. Main output in this stage, if contractually required, could include: ∗ plans for addressing systems security in overall SE approach are conducted in accordance with Contract arrangements ∗ analysis and documentation of vulnerabilities, including monitoring of initial operations, defect reports and systems changes by users ∗ mapping of critical operational functions to project solution components (final) ∗ provision of component and supply chain contractor data in standardised format to allow ready aggregation of data to look for ‘horizontal’ (eg. use in multiple programs) issues ∗ through monitoring, report on the integrity of sub-system/component supply chains ∗ report of suspect / fraudulent/ counterfeit parts and incidents in accordance with legal, regulatory and contractual requirements ∗ documentation of access control measures to critical parts in the contractor storage and distribution systems ∗ use of software tools such as Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE) and Common Attack Pattern Enumeration and Classification (CAPEC) to identify vulnerabilities on critical development software ∗ audit and monitoring reports for deployed system installation procedures and resolution of security issues.

7.5 Utilisation/In-Service Support

The emphasis in Systems Security Engineering changes once the system enters into operational service. Up to this point, SSE is mainly concerned with aspects such as influencing acquisition strategies, adequate elicitation of security requirements, rigorous design reviews and supply chain monitoring activities.

21 Once the system is in-service, the management focus is on implementing necessary arrangements to maintain security performance as required. Emphasis should be on implementing security control measures designed into the system (e.g. effective configuration control, training users, monitoring systems used within design limits, resolving security issues, contingency arrangements), and the identification of new threats. Reporting threats should be strongly encouraged by senior management and those threats should be reported to the appropriate organization and investigated. Security analysis should be revisited to examine: a) the effects on security of changes to the design (e.g. modifications, off the shelf upgrades etc); b) how the system is maintained; and c) how the system is used in the operating environment. The assurance case (or similar evidence artefacts) should be reviewed on a planned basis at intervals commensurate with the security risk. Main outputs in this stage, if contractually required, could include: ∗ documentation of access control to system, installed software and executable code repositories used during operations limit opportunity for exploitation ∗ updated security risk assessment and mitigations based upon system as built and latest threat assessments; system resilience is understood ∗ control and conduct of maintenance (including software) in accordance with approved plans ∗ continued systems security integrity through design modifications, off the shelf upgrade and supply chain changes ∗ conduct of regression testing and maintenance of system certifications as applicable ∗ audit of maintainer training related to systems security issues ∗ audit of maintenance access control

7.6 Disposal

Planning for disposal should begin at the earliest stage of the project so that the security design can be influenced for secure disposal in accordance with the respective Nations’ regulations. The plan for end of life disposal should be refined and updated as the system is modified. Main outputs in this stage include: ∗ Disposal of System and components to control critical information and countermeasures ∗ Disposal of suspect / counterfeit components to avoid re-entry into supply chains

7.7 Integrated Systems Security Engineering SSE includes enabling prevention protection measures or leveraging other systems engineering activities that support or enable secure systems, for example: * Extending safety related activities to consider and identify security issues – a requirement of some safety engineering standards (DS-56 [20]) * Extending the quality assurance processes in the supply chain * Actively improving the security culture * Using trusted suppliers in the supply chain * Enhanced planning and designing for the recovery of systems; for military mission systems, confidentiality and integrity are important but availability in the operational environment may be a critical design enabler for rapid recovery

Figure 8: Enhance protection measures to protect the supply chain

7.8 Continuous Improvement The security of a system is not static and it will usually tend to degrade over time as people can become complacent and less vigilant. Effective configuration control, monitoring and feedback are therefore required to maintain or improve the security performance. Acquisition should consider SSE activities throughout the lifecycle. There are several ways of achieving the SSE goal of continuous improvement. These include both active and reactive methods such as the following: * Incident reporting, investigation and feedback (see above) - reactive * Security reviews and audits - active * Acquisition security committees - active and reactive * Suggestion schemes which cover security - active Acquisition organisations must not view SSE as a one-off exercise: engineers should be continuously trying to make systems, and a system of systems more secure. A strong security culture, with the necessary stimulation from reviews, audits, incidents and suggestions, will ensure that system security continually improves.

23 8 SYSTEMS SECURITY ENGINEERING AND SUPPLY CHAIN MANAGEMENT

Key Messages • Every system has an identifiable supply chain • Security risks can be introduced through compromised system elements or compromised enabling systems • System security engineers consider all system life cycle processes and identify threats, vulnerabilities, risks, and appropriate protection measures across the system life cycle

8.1 Introduction

Supply chain risk management can be approached as an organizational problem. See for example NIST Special Publication 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations [21]. It can also be approached as an industrial sector problem. See for example Supply Chain Best Practices (NEMA CPSP 1-2015) [22], published by the [United States] National Electrical Manufacturers Association. This chapter approaches supply chain risk management as an SSE problem to be addressed within the context of specific projects or acquisitions.

While supply chain risk management is often discussed abstractly in terms of global supply chains, the reality is that every system has an identifiable supply chain or network. See Supply Chain Attack Framework and Attack Patterns [23] for a practical discussion of how to conceptualize a system supply chain and the way supply chain attacks may vary across system life cycle stages. Within a system supply chain, security risks can be introduced through:

∗ Compromised system elements. System elements are discrete parts of a system (e.g., hardware, software, data, or materials) that are implemented to fulfill specified requirements. ∗ Compromised enabling systems. An enabling system, as defined in ISO/IEC/IEEE 15288 [6], is a system that supports a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation. Examples include design, manufacturing or production systems (including software production systems such as compilers, open source libraries or development toolkits), training systems, or maintenance systems.

8.2 Systems Security Engineering Role and Approach

Across the system lifecycle (Chapter 7 of this document) and all system life cycle processes, system security engineers should iteratively identify supply chain threats, vulnerabilities, and system impacts through analytic and definition processes (Chapter 5 of this document) and determine appropriate protection measures through the risk management process (Chapter 6 of this document). System security engineers should be involved in the implementation, integration, and monitoring of the continued effectiveness of protection measures through the Systems Engineering Agreement, Technical Management, and Organizational Project-Enabling Processes as well as through the Technical Processes.

24 9 REFERENCES AND USEFUL FURTHER READING

Referenced Publications

[1] NIST SP 800-160 initial public draft, Systems Security Engineering, An Integrated Approach to Building Trustworthy Resilient Systems, May 2014

[2] Hotten, R. (2015, December 10). Volkswagen: The scandal explained. BBC News. Retrieved from http://www.bbc.com/news/business-34324772

[3] Greenberg, A. (2015, July 21). Hackers Remotely Kill a Jeep on the Highway – With Me in it. Wired. Retrieved from http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/

[4] Uconnect. Retrieved from https://www.driveuconnect.com/

[5] Lingeman, J. (2015, July 24). 1.4 million Fiat Chrysler vehicles recalled for hacking concerns: Here's the list. Autoweek. Retrieved from http://autoweek.com/article/recalls/fca-issues-recall-fix-jeep-cherokee-software-hack

[6] Systems and Software Engineering—System Life Cycle Processes. ISO/IEC/IEEE 15288:2015.

[7] Standard for Technical Reviews and Audits on Defense Programs. IEEE 15288.2-2014.

[8] Information security management systems — Requirements. ISO/IEC 27001:2013.

[9] Code of practice for information security controls. ISO/IEC 27002:2013.

[10] International Traffic In Arms Regulation, Parts 120 through 130 of Title 22, US Code of Federal Regulations

[11] Export Administration Regulations (EAR), Parts 730 through 774 of Title 15, USCode of Federal Regulations

[12] IET, HSE and BCS, “Competence Criteria for Safety – related system practitioners”, The Institution of Engineering and Technology, 2006.

[13] SEI, CMU/SEI-2013-TN-004, Software Assurance Competency Model, March 2013.

[14] Holt J and Perry S.A, “A Pragmatic Guide to Competency, Tools, Frameworks and Assessment”, British Computer Society, 2011, ISBN:978-1-906124-70-0.

[15] NASA,“NASA’s Systems Engineering Competencies”, http://www.nasa.gov/pdf/303747main_Systems_Engineering_Competencies.pdf, downloaded 17 April 2013.

[16] Don S. Gelosh, Mimi Heisey, John R. Snoderly, James F. Anthony Jr., and Ken Nidiffer, Developing the Next Generation of the INCOSE Systems Engineering Competency Framework, INCOSE 2014.

[17] NIST SP 800-61, Revision 2, Computer Security Incident Handling Guide, August 2012

[18] NIST SP 800-55, Revision 1, Performance Measurement Guide for Information Security, July 2008

[19] NIST SP 800-66, Revision 1, Guide to Integrating Forensic Techniques into Incident Response, August 2005

[20] Def Stan 00-56 interim issue 5, Safety management requirements for Defence Systems, January 2014. 25 [21] NIST SP 800-161, Supply chain risk management practices for federal information systems and organizations, April 2015.

[22] National Electrical Manufacturer’s Association. Supply Chain Best Practices. NEMA CPSP 1-2015, January 2015.

[23] MITRE Technical report “Supply Chain Attack Framework and Attack Patterns”, December 2013

[24] Dahmann, J. et al, Recommended Practices: System of Systems Considerations in the Engineering of Systems, TTCP Technical Report, TR-JSA/TP4-1-2014, August 2014. http://www.acq.osd.mil/se/docs/TTCP-Final-Report-SoS- Recommended-Practices.pdf

[25] Blanchard, Benjamin S., and Fabrycky, Wolter J., Systems Engineering and Analysis, Prentice Hall, 2001 International Edition.

26 DOCUMENT CONTROL DATA (Security markings for the title, abstract and indexing annotation must be entered when the document is Classified or Designated) 1. ORIGINATOR (The name and address of the organization preparing the document. 2a. SECURITY MARKING Organizations for whom the document was prepared, e.g., Centre sponsoring a (Overall security marking of the document including contractor's report, or tasking agency, are entered in Section 8.) special supplemental markings if applicable.)

DRDC – Centre for Operational Research and UNCLASSIFIED Analysis Defence Research and Development Canada 101 Colonel By Drive 2b. CONTROLLED GOODS Ottawa, Ontario K1A 0K2 (NON-CONTROLLED GOODS) Canada DMC A REVIEW: GCEC DECEMBER 2012

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S, C or U) in parentheses after the title.) The Black Book: A Starter Guide to Systems Security Engineering for Acquisition (U)

4. AUTHORS (last name, followed by initials – ranks, titles, etc., not to be used Bradley Doohan (Australia); Steve Sterling, Mark Jennings, Frederic Painchaud, LCol Yves Turcotte, LCdr Marc Lanouette (Canada); etc. 5. DATE OF PUBLICATION 6a. NO. OF PAGES 6b. NO. OF REFS (Month and year of publication of document.) (Total containing information, (Total cited in document.) including Annexes, Appendices, etc.) October 2016 26 25

7. DESCRIPTIVE NOTES (The category of the document, e.g., technical report, technical note or memorandum. If appropriate, enter the type of report, e.g., interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered.)

Reference Document

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development – include address.)

DRDC – Centre for Operational Research and Analysis Defence Research and Development Canada 101 Colonel By Drive Ottawa, Ontario K1A 0K2 Canada

9a. PROJECT OR GRANT NO. (If appropriate, the applicable research 9b. CONTRACT NO. (If appropriate, the applicable number under and development project or grant number under which the document which the document was written.) was written. Please specify whether project or grant.)

10a. ORIGINATOR’S DOCUMENT NUMBER (The official document 10b. OTHER DOCUMENT NO(s). (Any other numbers which may be number by which the document is identified by the originating assigned this document either by the originator or by the sponsor.) activity. This number must be unique to this document.) TTCP Document DOC-JSA/TP4-1-2016 DRDC-RDDC-2016-D061

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by security classification.) Unlimited 12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspond to the Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement audience may be selected.)) 13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual.)

Le contenu de ce livret a été rédigé aux fins d’information seulement; c’est pourquoi il ne doit pas servir de fondement à tout contrat ou directives à l’intention des entrepreneurs.

14.

KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus,

Systems security engineering; Systems engineering; Acquisition.