DFARS and the Aerospace & Defence Enterprise

Transcription

1 DFARS and the Aerospace & Defence Enterprise Is Your Organisation Ready? October 2017 Lance Seelbach, CISSP, CISA, Client Security Officer Simon Aplin, Export Compliance Lead Aerospace & Defence ANZ

2 Table of contents Introduction 2 Assumptions 4 Developing a Defendable Approach 5 Myths, Legends, Rumours 6 Trusted Partner 12 Table of Acronyms & Terms 13 Intended Audience Any organisation that either directly contracts with the federal government or is engaged in the downstream supply chain as a second or third tier supplier to primaries. Recommended for the Chief Executive Officer, Export Compliance and Governance Officer, Supply Chain Director and others engaged in government contracts. Who is DXC? The merger between Computer Sciences Corporation and the Enterprise Services business of Hewlett Packard Enterprise gave birth to DXC, the world s leading independent, endto- end IT services company. DXC is the world s third largest solution provider, with a practice providing deep A&D industry expertise that provides services to 7 of the 10 largest A&D companies in the world. Introduction Under the U.S. Defence Federal Acquisition Regulation Supplement (DFARS) defence industry contractors, subcontractors and suppliers must meet the strict requirements for Controlled Unclassified Information (CUI) protection to comply with the National Institute of Standards and Technology Special Publication (NIST SP) Examples where IT security protection is required for defence industry organisations include contracts, agreements, subcontracts, projects, research and development activities and support arrangements that process, store or handle US sourced CUI, International Traffic in Arms Regulations (ITAR), Export Administration Regulations (EAR) or Foreign Military Sales (FMS) controlled information or data A few of the questions the experts at DXC have been asked by our clients; Is your organisation ready for DFARS compliance by 31 December 2017? What does compliance mean? How will your organisation be affected? What are the realistic consequences of non-compliance? Is a Plan of Action & Milestones (POA&M) sufficient for compliance? There are and will continue to be questions and confusion surrounding DFARS compliance. The purpose of this white paper is to share DXC s position on DFARS, based particularly on deep regulatory understanding, membership on the Aerospace Industries Association (AIA), membership in the IT Alliance for Public Sector (ITAPS), contacts within the federal government and experience with our large A&D client base. The purpose of this white paper is to provide as much clarity and perspective as possible to a shifting landscape of regulations and controls. DXC intends to provide updates to this paper as information becomes available from the U.S. federal government DXC has participated and will continue to participate, in events such as the Industry Day hosted by the DoD on 23 June This paper reflects information and experience as of the date of this writing and is subject to change. This paper will begin with a series of reasonable assumptions on which we have based our findings. Then we have discussed about developing a defendable approach to compliance, which will lead to a list of questions and answers that address some of the myths, legends and rumours associated with DFARS. The objective of this paper is to highlight critical information and address misunderstandings and misperceptions of the 14 families and 110 controls referenced in the DFARS regulations. While the paper is specifically addressing DFARS regulations, we must also keep in mind that they reside within a complex framework of agencies, directives, definitions and standards (see Figure 1). Successful compliance with efficiency of effort and cost can only be achieved with a comprehensive view and approach. DFARS, Safeguarding Covered Defence Information and Cyber Incident Reporting, is the supplement to the FAR Basic Safeguarding of Covered Contractor Information Systems. It is the contract instrument to obligate Defence industry suppliers to comply with National Institute of Standards and Technology (NIST) Special Publication (SP) , required by the Department of Defence (DoD). DFARS is issued by the Department of Commerce, administered by the Federal Acquisition Regulations Secretariat. DFARS is based on Federal Information Processing Standard (FIPS) 200 and , both published by NIST. 2

3 It is the responsibility of every supplier in the DoD supply chain to comply with DFARS by 31 December Failure to comply could potentially end existing contracts with the DoD, and prohibit the ability to bid on future contracts. Further, weaknesses with DFARS compliance in a prime contractor s supply-chain will potentially introduce vulnerabilities up the supply chain and back to the prime. If failure to protect Controlled Unclassified Information (CUI) or Covered Defence Information (CDI) occurs then accountability may fall back to the prime contractor. It is worth noting that U.S. Defence exports may include the supply of CUI or CDI. If the U.S. Federal entities do not require obligations to comply with NIST SP in Defence related export regulations, licences and agreements, then proactive U.S. Defence companies may include NIST SP compliance obligations in their supply contracts with foreign partners/entities. We are monitoring to see if U.S. Department of State will apply NIST SP in export regulations, licences and agreements. DXC can assist with compliance requirements in supply chains, from prime down, as well as compliance requirements in foreign entities for suppliers large and small. Figure 1. Complicated relationships among the agencies, entities and artefacts. 3

4 Assumptions While the journey from initial publication to compliance deadline has been filled with twists, turns and speed bumps, there is a core set of assumptions upon which the controls should be evaluated and implemented. NIST SP defines a new set of controls, which has already been subject to one revision late last year, but its primary focus is maintaining the confidentiality of CUI and CDI. We fully expect that interpretation and implementation will evolve in the coming years, but we do not expect to see any change in its focus. CUI is unclassified information that meets the standards for safeguarding and dissemination controls pursuant to law, regulations, and government-wide policies under E.O Previously, similar information may have been referred to as Sensitive But Unclassified (SBU) throughout the executive branch and some of this information may meet the requirements to become CUI. Requirements for the protection of CUI are designed to be consistent, whether the CUI is on a federal or non-federal information systems. 1 Safeguards implemented to protect CUI should be consistent in both federal and nonfederal information systems and Organisations. 2 The confidentiality impact value for CUI is no lower than moderate. 3 Classification of CUI is aligned with and refers to existing Categories established by National Archives and Record Administration (NARA). 4 Also, remember that the requirements listed above do not stand alone, but reside within a broader framework applicable to government contractors. NIST SP Access Control Awareness Training Audit & Accountability Configuration Management Identification & Authentication Incident Reporting Maintenance Media Protection Personnel Security Physical Protection Risk Assessment Security Assessment System & Communication Protection System & Information Integrity Figure Security Requirement Families 1 National Institute of Standards and Technology Special Publication rev 1, Section National Institute of Standards and Technology Special Publication rev 1, Section National Institute of Standards and Technology Special Publication rev 1, Section National Archives CUI Registry - 4

5 Developing a Defendable Approach What is in-scope and where is it in my enterprise? In an ideal world, defining scope and identifying where CUI and CDI are hosted would be simple. As described both in DFARS as well as subsequent publications, we are pointed at Categories established by NARA and, ideally, called out explicitly by the Contracting Officer (CO). Identifying scope is complex for example, category headings like Procurement and Acquisition and Proprietary Business Information are vague enough to imply everything or nothing. Furthermore, if the CO does not clearly identify CUI, then who is on the hook? The starting point for developing a defendable approach is effective data classification. With data classification, CUI and CDI can be localised and a DFARS program can narrow its focus, rather than trying to encompass the whole of the enterprise - saving money, being smart. How does DFARS interact with the National Archives and Record Administration (NARA) CUI Rule? In September 2016, the NARA issued a final rule regarding the protection of controlled unclassified information (CUI). The FAQ notes that the NARA Rule is consistent with DFARS , as CDI falls under the NARA Rule s definition of CUI, in that it is unclassified information that requires safeguarding or dissemination controls pursuant to laws and regulations. Furthermore, both the NARA Rule and DFARS establish NIST Special Publication (SP ) as the minimum-security standard for protecting both CUI and CDI. Thus, the two rules are not in conflict. Still to come, however, is a final universal FAR rule that imposes to civilian agencies, with some indication that it will not be released until after the 31 December 2017 deadline imposed by DFARS. Against this backdrop, we believe failure to properly classify data and information systems will lead to unnecessary expenditures and ultimately increased business risk due to sweeping changes made to the enterprise estate. Mandatory Cyber Breach Reporting Expansion While requirements have previously been in place for reporting system breaches, the latest DFARS clause has increased the number of scenarios in which contractors must report incidents, and has clearly established a 72-hour threshold for reporting those incidents to the Department of Defence (DoD). For most companies, this will be a bolt-on attachment to existing incident response processes. If an incident response process has not been implemented, or if it is not matured, then upgrades will be required that include a clearly documented plan with thresholds, defined roles, communication, execution, and test plans. A welldocumented and managed plan will support effective responses and avoid less desirable responses in which teams trip over themselves trying to remember what they are supposed to do. Additionally, contractors must submit notices to the DoD through the DIBNet portal ( using the Incident Collection Format (ICF). Since this requires a DoD-approved medium assurance public key infrastructure (PKI) certificate, some subcontractors may choose to route their reporting through the Prime contractor. In some cases, this may be required as part of the Prime-to-Subcontractor agreement. 5

6 Cloud Computer Standards and Procedures Cloud platforms (internal, external, public, private or hybrid) used to store, or process CUI must be governed by the same controls applicable to non-cloud information systems. This includes the policy outline in the DoD Cloud Requirements Guide and breach reporting through DIBNet. FedRAMP compliant platforms can provide the foundation for a compliant solution, but do not necessarily guarantee compliance. Each information system must be evaluated for its compliance with all in-scope controls. Myths, Legends and Rumours In this section, common questions received from our large A&D client base will be reviewed. 1. What Is the difference between CUI, CDI and UCTI? 2. Will there be an extension granted beyond 31 December 2017? 3. Will a POA&M be sufficient for compliance where controls will not be in place by the deadline? 4. I am a third tier supplier In a complex supply chain. Do I have to comply? 5. Is compliance a one-time effort? 6. How do I establish a governance program? 7. Do I need a dedicated team to run a governance program? 8. How do I prove compliance? 9. Do I need a SOC and SIEM tool for compliance? 10. We have legacy applications that do not support the multi-factor authentication controls. What do I do? 11. Do I need a third party to audit and/or attest compliance? 12. Is the deadline for compliance really 31 December 2017? 13. What does compliance mean and how is it measured? 14. What will DCMA look for? 15. Will compliance be an evaluation factor in pursuing government contracts? 16. How will prime contractors ensure compliance from their suppliers down the supply chain? 17. How is CDI defined in the contract? 18. What about COTS? 19. What about implementing alternative controls? 20. Where do I turn for more information? 6

7 1. What Is the difference between CUI, CDI and UCTI? CUI was referenced in NIST SP , while Unclassified Technical Information (UCTI) was referenced in DFARS Based on subsequent rulings and guidance, UCTI falls under CUI as a discrete category. CUI categories are defined by NARA and are available at CDI is defined as: Unclassified information provided to the contractor by, or on behalf of the DoD in connection with the performance of the contract; or Unclassified information which is collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract. Common types of CDI are controlled technical information (Military), export controlled information (commodities, tech, software etc.) and critical information (DoD Directive, OPEC, etc.) A useful diagram to visualize this was made available by the DoD earlier this year: Figure 3. Information System Security Requriements. It is incumbent on contractors and suppliers to evaluate and determine what data and information systems are in-scope for CUI, based on the defined categories. We see a number of our customers wrestling with the Procurement and Acquisition, and Proprietary Business Information categories. As such, we consider it critical to establish and document clear boundaries around data and information systems associated with government contracts. Failure to do so leads to all data and systems falling in-scope, which is impractical and prohibitively expensive to bring into compliance. 2. Will there be an extension granted beyond 31 December 2017? No. It has been made very clear that there will be no blanket extension to the 31 December Consideration will be given for individual exception requests. 7

8 3. Will a POA&M be sufficient for compliance where controls will not be in place by the deadline? No and yes. It is clear that no one can draft POA&Ms for every control, pushing completion out as far as they want and expect to be deemed compliant. Compliance can only be demonstrated by showing either a fully implemented control or a sufficient compensating control. Honestly, without POA&M you will not be compliant. For controls that require significant and complex change to the business (e.g., extending multi -factor authentication across the enterprise), there is a growing consensus that an in-flight project, accompanied by a POA&M and notification to the DoD Chief Information Officer (CIO) will be sufficient. We understand that these will be evaluated on a case by case basis and may be accepted or rejected by a Contracting Officer. 4. I am a third tier supplier In a complex supply chain. Do I have to comply? DFARS clause was amended to limit the requirements from flowing down only to subcontractors whose efforts will involve covered Defence information, or will involve operationally critical support. You and your upstream supplier will need to determine on a contract-by-contract basis if you fall in-scope. 5. Is compliance a one-time effort? No. As data and information systems are subject to frequent change, compliance must be maintained through an effective compliance program operating within a sufficiently robust governance model. 6. How do I establish a governance program? A governance program is a working set of processes and management structures that allow key decisions to be made during the lifecycle of a program to ensure that the benefits and outcomes of the program are achievable and meet the objectives of the program & Organisation. If you already have some form of governance model or program related to other regulatory requirements, you may be able to simply extend that model and mechanism to include the DFARS requirements. In the absence of any governance program, there are a multitude of resources and seasoned experts available to assist you with developing and implementing such a program 7. Do I need a dedicated team to run a governance program? Not necessarily. This will largely be driven by both the scope of your Organisation s information systems and the relative maturity of your compliance program. We have seem some customers be successful with a small leveraged team using automation tool sets to reduce the required effort. 8. How do I prove compliance? At this point in time, self-attestation is considered sufficient. We have seen some customers who fall under a Prime contractor held to a higher standard by the Prime. This has not been consistent in execution or granularity. DXC s view is that well-documented System Security Plans which map the controls to their implementation (or compensating control) will be sufficient should questions arise around compliance. 8

9 9. Do I need a SOC and SIEM tool for compliance? In our experience, and based on dialog with customers, achieving compliance will require some form of monitoring Security Operations Centre (SOC) and a Security Event and Incident Management (SIEM) tool to stream line event and alert handling. The scope of scale and investment will depend on factors such as the number of in-scope information systems, where they are logically located and the types of detective and protective technologies in place to meet the controls. 10. We have legacy applications that do not support the multi-factor authentication controls. What do I do? Keeping in mind that the requirements of DFARS and NIST are not required at the application level, but at some point prior to reaching the application, successful implementation of multi-factor authentication controls require the following: Clear mapping of data access flow from user to CUI/CDI where along the path can Multi-factor Authentication (MFA) be effectively and economically applied? Flexibility of your chosen MFA solution does it require an agent? What operating systems does it support? What options are available for out-of-band access? Do we have to support Personal Identity Verification (PIV) on day one or can it wait? What physical form factors are available (smartcard, USB, mobile app, etc) and will practically work in your environment? One promising approach, however, is to restrict (logically or physically) access from the network and establish a singular front door to the application or data using a jump box or presentation/publication gateway (e.g., Citrix). This approach should only be necessary where there is no other opportunity to enforce MFA prior to the application or data (e.g., a contractor portal hosted in a DMZ). 11. Do I need a third party to audit and/or attest compliance? There is no requirementfor a third-party audit. If there is real or perceived risk to the business because of your current state and progress towards compliance, then there may be value in obtaining an external assessment or audit of compliance. Armed with that data, you should be able to focus your investments of capital and time, reducing risk and possibly cost. 12. Is the deadline for compliance really 31 December 2017? There was no extension of the deadline. One of the most urgent and important questions on many contractors minds was whether the current compliance deadline of 31 December 2017 would remain in place or be extended to allow contractors extra time to complete their implementation efforts. The government has not extended the deadline and therefore contractors should be taking immediate action to meet the DFARS requirements before the end of this year. 9

10 13. What does compliance mean and how is it measured? When a contract is signed, you are attesting to the fact that you are compliant unless, within 30 days of contract award, you turn in a list of the compliance requirements that have not been completed. The DoD will not certify compliance. It is up to each contractor to self-verify prior to signing a contract. The System Security Plan (SSP), along with a POA&M indicating how you plan to address any current gaps in compliance can be used as the proof of compliance. The government contracting officer may request to submit the SSP(s) and/or POA&M. If you have prepared an SSP and POA&M, but do not implement all the NIST SP requirements by the end of the year, then the government may accept the risk as defined by your SSP and POA&M. 14. What will DCMA look for? When the DCMA performs audits, if there is a CDI in your contract, they will verfiy that you: Have a SSP Turned in your 30-day notification disclosing which security controls have not yet been implemented Have a valid medium assurance PKI certificate for reporting cyber incidents 15. Will compliance be an evaluation factor in pursuing government contracts? The government can use a NIST SP SSP (and POA&M if necessary) as part of the tech evaluation criteria in a selection process. 16. How will prime contractors ensure compliance from their suppliers down the supply chain? Primes need to tailor and control what flows down to subcontractors based on the CDI data the subcontractors need access to in order to do their jobs If a subcontractor cannot implement the required CDI protections, then CDI should not be shared with the subcontractor 17. How is CDI defined in the contract? Contract Section J should include a list of CDI data that will be provided by the government Contract Data Item Description (DID) has marking requirements check item 9 in each Contract Data Requirements List (CDRL) 18. What about COTS? Commercial Off-The-Shelf (COTS) equipment sold under a contract is not considered CDI unless the COTS have been modified for CDI purposes. This exclusion does not extend to COTS packages used by a supplier to provide operational support or in any other way fulfil their contractual obligations. 10

11 19. What about implementing alternative controls? In some cases, contractors may have implemented security measures that provide protection equivalent to the controls defined in NIST In those cases: The DoD CIO will assess alternate measures Assessment responses will be provided within five days 20. Where do I turn for more information? Learn more at including updates to this white paper. 11

12 Trusted Partner DXC provides services to 7 of the 10 world s largest A&D companies. Our experience in the industry, and specifically DFARS compliance, provide us with a great deal of intelligence we can share. The ongoing work we are doing with our A&D client base provides us with a unique perspective and experience. Our relationship with the AIA provides us access to federal policymakers. Based on our experience with clients, we see three general DFARS compliance maturity levels with matching levels of available DXC support, as shown in the following table. Level Current State DXC Assistance Level 3 Level 2 Level 1 Approaching compliance with a well-defined plan for completion. The client Organisation has a clear picture of their CUI/CDI footprint and have projects completed & in-flight to meet compliance. SSPs exist and are being updated. Ongoing GRC is in place. Compliance is a low risk. Approaching compliance with a plan for completion, but not for sustaining. Gap analysis is complete. Program is up and operating. Projects have been prioritised and plan is complete to meet deadline. The client, however, has no ongoing program in place to manage compliance. Compliance is a moderate risk. Late start, not yet approaching compliance. The client may have begun a gap analysis, but has not yet created a program to prioritize projects to approach compliance. Compliance is a high risk. Interpretation of complex controls Review of SSPs for completion Table-top audits Project execution Managed services GRC program creation Interpretation of complex controls Project execution Risk mitigation Managed services GRC program ongoing execution GRC program creation Completion of gap analysis Interpretation of controls Project prioritisation Project execution Compliance compensation and/or mitigation Risk mitigation Managed services SOC, SEIM services GRC program ongoing execution Whenever your organisation falls within this spectrum, DXC can help. Contact us at 12

13 Acronyms/Terms, Description, Definition Safeguarding Covered Defence DFARS supplement Information and Cyber Incident Reporting NIST Special Publication Protecting Controlled Unclassified Information in Establishes supplement to FAR for DFARS Non-federal Information Systems and Organisations NIST Special Publication Security and Privacy Controls for Federal Information Establishes NIST MODERATE baseline Systems AIA Aerospace Industries Association Lobbies the FAR CDI Covered Defence Information CDRL Contract Data Requirements List CIO Chief Information Officer COTS Commercial Off-The-Shelf CUI Controlled Unclassified Information D[FAR}S Defence (Federal Acquisition Regulations) Supplement Published by GSA, DoD, and NASA Supplement NIST establishes control due 12/2017 DID Data Item Description DOC Department of Commerce DOS Department of State EAR Export Administration Regulation FAR Secretariat Establishes and operates the FAR FIPS Federal Information Processing NIST publications Standards FISMA Federal Information Security Act Executive order established in 2002 FMS Foreign Military Sales GRC Government Regulatory Compliance GSA General Services Administration ITAPS IT Alliance for Public Sector Alliance of leading technology companies ITAR International Traffic in Arms Regulations U.S. persons on U.S. soil MFA Multifactor Authentication NARA National Archives and Records Defines CUI NARA National Archives and Record Administration NIST National Institute of Standards and Technology Publishes FIPS and Special Publications (800-xxx) for FAR, FedRAMP and FISMA OMB Office of Management and Budget PIV Personal Identity Verification SASC Senate Armed Services Committee SEIM Security Event and Incident Management SOC Security Operations Centre SSP System Security Plan 13

14 Regional Contacts (Australia and New Zealand) Dean Coughran is an Industry Leader in Aerospace & Defence (A&D) at DXC. He is focused on solving the most critical business issues that affect the industry. Dean sees this global initiative as a critical step forward for the A&D industry. dcoughran@dxc.com +61 (0) Simon Aplin is a Senior Consultant at DXC specialising in Export Compliance in the Aerospace & Defence (A&D) industry. Simon has extensive experience across the defence, ICT and nuclear industries, managing export compliance requirements across global trade markets. He has worked with large defence companies and government organisations to facilitate business solutions that are fully compliant with complex export controls. simon.aplin@uxcconsulting.com.au +61 (0) Learn more at services About DXC Technology DXC Technology (DXC: NYSE) is the world s leading independent, end-to-end IT services company, helping clients harness the power of innovation to thrive on change. Created by the merger of CSC and the Enterprise Services business of Hewlett Packard Enterprise, DXC Technology serves nearly 6,000 private and publicsector clients across 70 countries. The company s technology independence, global talent, and extensive partner network combine to deliver powerful next-generation IT services and solutions. DXC Technology is recognised among the best corporate citizens globally. For more information, visit DXC Technology Company. All rights reserved. MD_6916a-18. October 2017