AF Life Cycle Management Center

Transcription

1 AF Life Cycle Management Center Aircraft Cybersecurity Risk Management Framework Harrell J. Van Norman Cybersecurity Tech Expert Engineering Directorate AFMC/AFLCMC/EZAS DISTRIBUTION A. Approved for public release: distribution unlimited Case Number: 88ABW May

2 Cybersecurity... so I connected the unclassified black & classified red wires for ONE com & data channel...

3 What is Cybersecurity? Prevention of damage to, protection of, and restoration of computers, electronic communications systems, electronic communications services, wire communication, and electronic communication, including information contained therein, to ensure its availability, integrity, authentication, confidentiality, and nonrepudiation. Source: DoDI Cybersecurity replaced Information Assurance (IA) Requires independent assessment & authorization Cybersecurity required by law, DoD & USAF instruction AFLCMC mandatory process 3

4 Terminology Confidentiality Assurance that information is not disclosed to unauthorized persons Integrity Data, processes, material is what is expected Availability Timely, reliable access to data and information services for authorized users 4

5 Applicability All DoD IT that receive, process, store, display, or transmit DoD information. DoD IT is defined as DoD Information Systems Platform IT (PIT) IT services IT products IT supporting research, development, test and evaluation (T&E), DoD-controlled IT operated by a contractor or other entity on behalf of the DoD. Source: DoDI

6 PIT Examples weapons systems Aircraft Armament Command and Control training simulators diagnostic test and maintenance equipment calibration equipment R&D equipment medical devices buildings and associated control systems utility distribution systems (such as electric and water) telecommunications systems for industrial control systems including control devices and advanced metering data transport mechanisms (e.g., data links, dedicated networks) Source: DoDI

7 Securing Different Types of Systems 7

8 Platform Information Technology (PIT) PIT - Both hardware and software, that is physically part of, dedicated to, or essential in real time to the mission performance of special purpose systems. PIT system - A collection of PIT within an identified boundary under the control of a single authority and security policy. The systems may be structured by physical proximity or by function, independent of location. 8

9 Program Manager Ensure the system has a current authorization Develop Cybersecurity risk management documents for newly acquired PIT systems and legacy systems without current authorizations PIT Determination Package Architecture Analysis Document and/or supporting design artifacts Implementation and Verification Planning SRTM and/or program verification data, traceability, and reports Risk Assessment Report and or Risk Assessment Briefing Ensure Cybersecurity requirements are placed on contract, scheduled and resourced Ensure Cybersecurity is integrated into acquisition, upgrade/modification programs, including initial design, development, testing, fielding and operations Ensure Risk Mitigations are coordinated across appropriate levels of the program Ensure Cybersecurity Plan of Action and Milestones (POA&M) is developed and executed to reduce overall system risk Ensure all changes go through configuration management, are assessed for Cybersecurity impacts and reported to the SCA if applicable Report security incidents to cognizant organizations. Conduct root cause analysis for incidents and develop corrective action plan. Engineering is normally the program office lead for Cybersecurity 9

10 Cybersecurity Policy 10

11 DoD Policy Transformation Highlights Published Versions DoDD , DoDI , DoDI Updated Versions DoDI , DoDI Information Assurance Cybersecurity Mission Assurance Category (MAC) / Confidentiality Level (CL) DoD Specific IA Definitions Joint Taskforce Transformation Initiative Security Objective: Confidentiality, Integrity, Availability Impact Value: Low Moderate High CNSSI 4009 glossary for cybersecurity terms DoD Security Controls C&A Process NIST SP security control catalog. Uses CNSSI 1253 to categorize and select controls Risk Management Framework Lifecycle

12 Summary of Changes Change from Directive to Instruction Information Assurance renamed Cybersecurity DAA=AO; SIAO=SISO; CA=SCA PIT specifically called-out Implements CNSSI 1253 and NIST Cybersecurity fully integrated into system acquisition life cycle Implemented through Risk Management Framework DoDI

13 DoDI Risk Management Framework for DoD Information Technology Rescinds DIACAP NIST s Risk Management Framework, Defines what systems should undergo the full RMF lifecycle Applies to both IT and PIT Requires CNSSI 1253 for Security Control Categorization and Selection, and use of overlays Promotes DT&E and OT&E integration Codifies reciprocity Strengthens risk management governance Emphasizes continuous monitoring and timely correction of deficiencies 13

14 Contractor Laptop Removable Media Boundary Example IFF UHF/VHF comm HF comm Data Links UHF/VHF comm SATCOM Simple Key Loader Mission Planning Depot SW Development Flightline Laptop LRUs Various LRUs 1553 Bus Caps Bus Data Recorder NIPR/ SIPR Equipment Memory Loader Data Recorder Backshop Test Station Legend Classified Unclassified

15 Weapon System Security Requirements Design Requirements Tng Sys Cybersecurity Integrity Confidentiality Availability Mx Sys Cybersecurity Operational Requirements Platform IT Sys Cybersecurity Msn Pln Sys Cybersecurity Depot Sys Cybersecurity Systems 15

16 Process and Artifacts PIT Determination Package PIT Determination Memo EITDR Registration Architecture Analysis CRTM System Security Plan Risk Assessment Authorization Memo Plan of Action & Milestones Impact Assessment Incident Reports 16

17 Architecture Understand System CONOPS Operating environments Classification level Users and system access Criticality Accreditation boundary Interfaces Components --HW, SW, firmware, networking, ports protocols & services Data flows Logistics process Upgrade process Supply Chain HW & SW process Determine potential System Vulnerabilities 17

18 Cybersecurity Systems Engineering Approach PIT Cybersecurity Risk Management Framework Systems Engineering Process SRR SFR PDR Cybersecurity Requirements Cybersecurity Functional Requirements Cybersecurity Design Verification SCA AO SCA SCA Concur? Assessment Assessment CDR TRR Cybersecurity Design Verification IATT Test Plan SCA SCA Verify Concur? SVR Review SCA Certify / Approval? AO Decision - ATO 18

19 RMF within the Acquisition System MS A MS B MS C FRP / FDD Strategic Guidance (OSD/JCS) Joint Concepts (COCOMs) CBA ICD MDD Materiel Solution Analysis Technology Development CDD Engineering & Manufacturing Development CPD Production and Deployment O&S Systems Engineering ASR SRR SFR PDR CDR TRR IAS IATT ATO ATO OTRR Cybersecurity Categorize Select Implement Assess Authorize Monitor 19

20 SE Steps Criticality Analysis Identify mission essential function and dependencies; Tailor system requirements, Capture in SRD, SOW & PPP PIT Determination Initial Categorization & Control Selection MDD Addressing Cyber Vulnerabilities in Future Systems Materiel Solution Analysis Integrate CS/IA requirement specs into lower level subsystem specifications SRR: Evaluate reqt coverage& flow down MS A Conduct PDR, ensuring CS/IA Requirements integration PDR Conduct risk assessment Pre-EMD Review MS B Decompose CS/IA Req s. Component Specs. for Product Baseline and System Design IATT Conduct CDR, ensuring System Mission Assurance Integration CDR Conduct risk assessment ATO Engineering & Technology Manufacturing AOA ICD Development CDD Development CPD MS C Fabricate, Assemble related HW and SW to Build To Documentation (control Implementation) Full Rate Production Decision Review Production and Deployment Conduct SVR, PRR, and FCA Integrating CS/IA Sustainment security engineering Continuing vulnerability assessment and remediation O&S ASR Full-up SRR SFR PDR CDR TRR DT&E SVR DT&E OTRR IOT&E Assessment T&E Steps Understand CS/IA requirements; they maybe specified, implied or mission essential Develop approach for T&E CS/IA Characterize the attack surface in an integrated environment determine possible threat vectors. Analyze potential vulnerabilities to determine measures to improve resilience Cybersecurity DT&E Realistic mission environment. Cyber threat representation DT&E Assessment Requirements assessment Operational Cybersecurity and Vulnerability Evaluation Remediation of findings Operational Evaluation of Protect, Detect, React, Restore (including penetration testing) Selected programs evaluated for COOP Treat cyber requirements like other design requirements 20

21 Risk Based Approach RMF replacing DIACAP 21

22 Threats Insider Threat (Often under-estimated) Disgruntled personnel Unintentional actions of user Trusted insider Hacker/Cracker Malicious Code/Viruses/Worms Via link or HW/SW upgrades State Sponsored Cyber Attack DOS (Denial of Service) Attacks Self imposed Deliberate actions of others 22

23 Real World Environment (SCRM) Counterfeit Components Malicious Logic Embedded in Chip Software Industry process to validate integrity of vendor products 23

24 Cybersecurity Case Scenarios Radar System Backdoor (reference IEEE Spectrum, May 2008, The Hunt for the Kill Switch) Stuxnet worm (reference Wikipedia) Flame (skywiper); screen shot, remote deletion capability, etc. Back-door discovered by U.K. researchers in U.S. Microsemi chip; allows remote access to memory 24

25 Components of Risk Risk Analysis Cause Effect Threat Likelihood Vulnerability Impact Means & Opportunity of the threat Severity of vulnerability & Criticality of the system/subsystem 25

26 Risk Assessment Likelihood Oportunity Risk Likelihood O-5 L-2 L-3 L-4 L-5 L-5 O-4 L-2 L-3 L-4 L-5 L-5 O-3 L-1 L-2 L-3 L-4 L-5 O-2 L-1 L-2 L-3 L-4 L-4 O-1 L-1 L-1 L-2 L-3 L-3 M-1 M-2 M-3 M-4 M-5 Likelihood Means Risk Likelihood L Near Certainty L Probable L Occasional L Remote L Improbale Likelihood Impact Risk LIKELIHOOD Overall Risk Factor Matrix L-5 L-4 L-3 X L-2 L-1 I-1 I-2 I-3 I-4 I-5 Impact IMPACT Vulnerability Severity S-5 I-2 I-3 I-4 I-5 I-5 S-4 I-2 I-3 I-3 I-4 I-5 S-3 I-1 I-2 I-3 I-4 I-5 S-2 I-1 I-1 I-2 I-3 I-4 S-1 I-1 I-1 I-1 I-2 I-3 C-1 C-2 C-3 C-4 C-5 System Criticality Risk Impact I Catastrophic I Major I Moderate I Minor I Negligible

27 Example Risk Reporting Template Component Control / Requirement Risk # Control name Initial risk level High Threat: Any circumstance or event with potential to intentionally or unintentionally exploit one or more vulnerabilities in a system, resulting in a loss of confidentiality, integrity, or availability. Examples of threat agents are malicious hackers, organized crime, insiders, terrorists, and nation states. Vulnerability: Flaw or weakness in design or implementation of hardware, software, networks, or computer-based systems, including security procedures and controls associated with the systems. Be specific Risk: Combination of the likelihood that a particular vulnerability in an organization s systems will be either intentionally or unintentionally exploited by a particular threat agent and the magnitude of the potential harm (consequence) to the organization s operations, assets, or personnel that could result from the loss of confidentiality, integrity, or availability. Likelihood: (Highly Likely) Explain the probability of occurrence due to mission parameters. Make sure this category designation matches the Matrix category designations. Impact: (High) Explain the consequence to data, mission, operation, or life in quantifiable terms. Make sure designation matches consequence column headers on Risk Matrix. In terms of confidentiality, integrity & availability, Mitigation/Countermeasures: List actions that are that are implemented and documented relevant to the risk. Residual Risk: After mitigation/countermeasure have been applied what is the risk level? Why should the AO accept the risk Current Residual Risk: Moderate Additional countermeasures needed for Low residual risk: What is needed to meet the requirement or mitigate to a low risk 27

28 Risk Analysis Summary Template IMPACT LOW MINOR MEDIUM SIGNIFICANT HIGH Level 5 Impact % Most Likely Level 4 Initial R5 Ʃ= Likelihood Risk LIKELIHOOD 61-90% Probable Level % Somewhat likely Level 2 By design R % Remote Level % Unlikely By Test R5 28

29 Terminology Authorizing Official (AO) Formerly referred to as Designated Accrediting Authority (DAA) Authorized to accept cybersecurity measured risk Ensure cybersecurity integrated into programs Review/Approve accreditation package with cybersecurity risk assessment and mitigation approach Accredit/Deny system for test or operation Independent Authorization Official Security Control Assessor (SCA) Formerly referred to as Certifying Authority (CA) Approve requirements Review cybersecurity technical assessments Certify cybersecurity implementation and risk assessment Make risk recommendations to AO (DAA) Independent assessment authority *Delegated IAW AFPD

30 Terminology Decisions Platform IT Determination - A determination made by an AO that a system meets the criteria of Platform IT Interim Authority to Test (IATT) - An IATT is a special type of authorization decision allowing a Platform IT system to operate for the purpose of testing in order to complete specific test objectives Authority to Operate (ATO) - An ATO is a decision issued once all risks have been reduced to acceptable levels or proper mitigation is in place and the Platform IT AO is willing to accept the residual risk as assessed Denial of Authority to Operate (DATO) - A DATO is a decision issued when risks are not acceptable to the Platform IT AO. This may result due to unauthorized changes to the system, new threats or system vulnerabilities, insufficient progress on the POA&M Authority to Connect (ATC) A decision by another AO to allow a connection to an accredited system See PIT Guidebook for complete definition 30

31 Software Pedigree Understand the Source of software GOTS, MOTS, COTS Concern with uncleared personnel writing critical software for weapons systems Concern with freeware/shareware Need approval to use COTS software not previously analyzed Independent V&V of software code Utilize software tools to check for malicious code Software scanned for vulnerability 2013 NDAA SEC. 933 includes requirement to develop DoD software assurance policy applicable to weapons systems 31

32 Software Assurance (SwA) Assessment Benefits: Security & Quality Significantly reduces cost of reliable, secure software Compliments existing testing approaches Boosts overall development productivity Promotes adherence to key industry standards Security Buffer overflow Un-validated user input SQL injection Path injection File injection Cross-site scripting Information leakage Vulnerable coding practices Reliability Memory and resource leaks Concurrency violations Infinite loops Dereferencing NULL pointers Usage of uninitialized data Resource management Memory allocation errors Coding Standards & Maintainability MISRA, DISA, CWE, CERT, etc. Dead code Unreachable code Calculated values that are never used Unused function parameters

33 Supply Chain Counterfeit Hardware Supply Chain Risk Management Impacts Reliability Concern over potential malware or backdoors Extra concern for ICT components Software Assurance (SwA) Design of the code Embedded malicious code Software development and assessment See DoDI ICT = Information Communications Technology 33

34 Supply Chain Risk Management (SCRM) Concerns Counterfeit Hardware Impacts Reliability Concern over potential malware or backdoors Extra concern for ICT components Software Concerns Design of the code Embedded malicious code ICT= Information Communications Technology 34

35 Source of software GOTS, MOTS, COTS Software Pedigree Concern with uncleared personnel writing critical software Concern with freeware/shareware Need approval to use COTS software not previously analyzed Independent V&V of software code Software tools utilized to check for malicious code 35

36 SwA tool Comparison Study Important Issue Types Score (%) Scan Results Score (%) Environment Integration Score (%) Performance Score (%) Presentation Score (%) Support Score (%) Cost Clarity Score (%) Final Score Coverity SAVE C/C++ Test Insight Palamida Enterprise Edition Fortify CodeSonar CxInvestigate PC-lint AppScan FxCop Fakebust

37 Technology Challenges No automated aircraft system architecture vulnerability identification tools No aircraft cyber threat modeling tool No quick way to V&V software supply chain integrity No automated criticality assessment tool No technology to test cyber resiliency of aircraft system No technology to measure cyber resiliency 37

38 Summary Cybersecurity Requirements adapted for Weapon System Requirements Cybersecurity part of the system engineering review process Risk assessment accomplished on all requirements Independent Certification and Accreditation (risk taking authority)

39 Backup 39

40 Cybersecurity Requirement 44 USC Chapter 35 Subchapter III INFORMATION SECURITY DoDI Cybersecurity DoDI Risk Management Framework for DoD IT Interim DoDI Cybersecurity RMF integrated into Systems Engineering and Acquisition AFI USAF C&A Process AFI Guidance Memo: guidance for C&A of PIT Directs assessment of legacy PIT systems Requires Risk Management and Authorization of PIT Systems USAF Platform IT Guidebook AFLCMC Platform IT C&A Process Mandatory AFLCMC Standard Process Metrics briefed quarterly to AFLCMC/CC, PEOs and Functionals 40

41 System Security Plan (SSP) The organization: a. Develops a security plan for the information system that: - Explicitly defines the authorization boundary for the system; - Describes the operational context of the information system in terms of missions and business processes; - Provides the security categorization of the information system including supporting rationale; - Describes the operational environment for the information system; - Describes relationships with or connections to other information systems; - Provides an overview of the security requirements for the system; - Describes the security controls in place or planned for meeting those requirements including a rationale for the tailoring and supplementation decisions; and - Is reviewed and approved by the authorizing official or designated representative prior to plan implementation; b. Reviews the security plan for the information system [Assignment: organizationdefined frequency]; and c. Updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments. The intent is covered by CRTM and architecture analysis report. However, processes and procedures used to meet requirements or mitigate risk must be documented in an SSP or technical order. 41

42 Data Flow Example Prime Contractor Aircraft Data Portable device Download CD USAF Analysis CD Conversion Legend Entity Process Storage Data Flow 42

43 Roots of DoD Policy 43

44 Architecture Subsystems Example Guidance Computer Functional description Include criticality, classification, storage media, external/internal interfaces and protocols, and hardware & software Device Name Manufacturer Model Guidance Computer Acme Guider 200A Part# 423 Sub- System (A/N/G) Class Level (U/S/TS) Non- Volatile Storage Media Removable Media A S Hard Drive Yes Front-Panel Interface USB, E-net Maintenance Interface 1533, ARINC 429 Purpose Guidance Processing Description Guidance Computer Guidance Computer Guidance Computer LRU/Model Number O/S License required Application Software 1623 Some RTOS Y CPC LCOS control software 1623 Y Interface control software 1623 Y Other control software Developer ABC Comments Evaluated by NSA 123 Contains foreign dev software XYZ Scanned with Fortify For each component the architecture analysis document should have this level of detail. This becomes the HW/SW baseline. 44

45 Cybersecurity Requirements Traceability Matrix (CRTM) Reqt CONTROL NAME Control Text Armament Guidance Supplemental Guidance Applicable Compliant Method of Verification Verification Result Supporting Artifact Comments Yes/No Yes/No Requirement PE-19 Requirement text Emissions and TEMPEST Control Text The organization employs cryptographic mechanisms to prevent unauthorized disclosure and modification of information at rest unless otherwise protected by alternative physical measures. Armament Guidance Rationale for tailoring or why the requirement is nonapplicable Applicable Yes Compliant No Method of Verification Verification Result Supporting Artifact Comments TEMPEST Tests IAW AFI 700. Discuss test specifics Summarize Name and section of the test report. Use this to discuss if this drives a risk. Also use this area for rationale for Technical controls verified with demonstration, analysis or test. Process & operational controls validated with inspection. 45

46 CNSS 1253 Cybersecurity Requirements IDENTIFIER FAMILY CLASS AC Access Control Technical AT Awareness and Training Operational AU Audit and Accountability Technical CA Security Assessment and Authorization Management CM Configuration Management Operational CP Contingency Planning Operational IA Identification and Authentication Technical IR Incident Response Operational MA Maintenance Operational MP Media Protection Operational PE Physical and Environmental Protection Operational PL Planning Management PS Personnel Security Operational RA Risk Assessment Management SA System and Services Acquisition Management SC System and Communications Protection Technical SI System and Information Integrity Operational PM Program Management Management 46

47 Requirements IDENTIFIER AC Access Control AT Awareness and Training AU Audit and Accountability CA Security Assessment and Authorization CM Configuration Management CP Contingency Planning IA Identification and Authentication IR Incident Response MA Maintenance MP Media Protection PE Physical and Environmental Protection PL Planning PS Personnel Security RA Risk Assessment Management SA System and Services Acquisition SC System and Communications Protection SI System and Information Integrity PM Program Management Tailored Requirements that apply to the system 47

48 Biographical Sketch Harrell J. Van Norman is the Cybersecurity Technical Expert for AFLCMC Engineering Directorate, US Air Force, WPAFB, supporting Platform IT systems as the Certifying Authority Representative and as an Adjunct Professor with the Institute of Defense Studies and Education at Wright State University and with the Management Information Systems Department/MBA Department at the University of Dayton. Previously, Harrell served as the Information System Security Manager (ISSM) for unmanned aerial system SIGINT sensors, supporting the US Air Force at WPAFB. Harrell also served as the Cybersecurity and Workforce Development Program Coordinator at ATIC. With over 30 years experience in cybersecurity, system design, implementation, optimization, management, and training, Harrell is a skilled and certified engineering research staff member (CISSP, Security+, e-biz+, Network+, CCNA, CCDA, CCDP, CCNP). Harrell has a balanced background of engineering design and optimization, information assurance, anti-tamper, program protection, remote sensing intelligence systems, communications protocol standards, training and education, simulation modeling and analysis, program management, and network infrastructure support. He is the author of LAN/WAN Optimization Techniques, and his work has been published in Data Communications Magazine, Communications News, Faulkner Information Services, and The Communications Handbook. He currently serves on the Board of Directors for the Dayton, Ohio, Information Systems Security Association chapter. 48