White Paper

DFARS and the Aerospace & Defence EnterpriseIs Your Organisation Ready?October 2017

Lance Seelbach, CISSP, CISA, Client Security OfficerSimon Aplin, Export Compliance Lead – Aerospace & Defence ANZ

2

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 2017. 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, 225.204.7012 Safeguarding Covered Defence Information and Cyber Incident Reporting, is the supplement to the FAR 52.204-21 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) 800-171, 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 800-171, both published by NIST.

Under the U.S. Defence Federal Acquisition Regulation Supplement (DFARS) 225.204.7012 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) 800-171. 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

IntroductionTable of contents

Introduction 2

Assumptions 4

Developing a Defendable Approach 5

Myths, Legends, Rumours 6

Trusted Partner 12

Table of Acronyms & Terms 13

Intended AudienceAny 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, end-to- 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.

White Paper

It is the responsibility of every supplier in the DoD supply chain to comply with DFARS by 31 December 2017. 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 800-171 in Defence related export regulations, licences and agreements, then proactive U.S. Defence companies may include NIST SP 800-171 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 800-171 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.

White Paper

3

AssumptionsWhile 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 800-171 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. 13556. 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 800-171

Acce

ss C

ontr

ol

Awar

enes

s Tr

aini

ng

Audi

t & A

ccou

ntab

ility

Con

figur

atio

n M

anag

emen

t

Iden

tifica

tion

& Au

then

ticat

ion

Inci

dent

Rep

ortin

g

Mai

nten

ance

Med

ia P

rote

ctio

n

Pers

onne

l Sec

urity

Phys

ical

Pro

tect

ion

Risk

Ass

essm

ent

Secu

rity

Asse

ssm

ent

Syst

em &

C

omm

unic

atio

n

Prot

ectio

n

Syst

em &

Info

rmat

ion

Inte

grity

1 National Institute of Standards and Technology Special Publication 800-171 rev 1, Section 2.12 National Institute of Standards and Technology Special Publication 800-171 rev 1, Section 2.13 National Institute of Standards and Technology Special Publication 800-171 rev 1, Section 2.14 National Archives CUI Registry - https://www.archives.gov/cui/registry/category-list

White Paper

4

Figure 2. 14 Security Requirement Families

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 252.204-7102 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 252.204.7012 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 252.204.7012, 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 252.204.7012 establish NIST Special Publication 800-171 (SP 800-171) 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 800-171 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 well-documented 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 (http://dibnet.dod.mil) 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.

White Paper

5

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?

White Paper

6

1. What Is the difference between CUI, CDI and UCTI?

CUI was referenced in NIST SP 800-171, while Unclassified Technical Information (UCTI) was referenced in DFARS 252.204-7102. Based on subsequent rulings and guidance, UCTI falls under CUI as a discrete category. CUI categories are defined by NARA and are available at https://www.archives.gov/cui/registry/category-list.

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:

White Paper

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 2017. Consideration will be given for individual exception requests.

7

Figure 3. Information System Security Requriements.

White Paper

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 252.204–7012 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. 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 252.204-7102 and NIST 800-171 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.

White Paper

9

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 800-171 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 800-171 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.

White Paper

10

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 800-171. 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 www.dxc.technology/aerospace_defense, including updates to this white paper.

White Paper

11

Trusted PartnerDXC 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 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.

• Interpretation of complex controls

• Review of SSPs for completion

• “Table-top” audits

• Project execution

• Managed services

Level 2 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.

• GRC program creation

• Interpretation of complex controls

• Project execution

• Risk mitigation

• Managed services

• GRC program ongoing execution

Level 1 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.

• 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 www.dxc.technology/aerospace_defense

White Paper

12

Acronyms/Terms, Description, Definition. 252.204.7012 “Safeguarding Covered Defence

Information and Cyber Incident Reporting”

DFARS supplement

800-171 NIST Special Publication “Protecting Controlled Unclassified Information in Non-federal Information Systems and Organisations”

Establishes supplement to FAR for DFARS

800-53 NIST Special Publication “Security and Privacy Controls for Federal Information Systems”

Establishes NIST MODERATE baseline

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 800-171 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 Standards

NIST publications

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

White Paper

13

Learn more at www.dxc.technology/services

www.dxc.technology

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 public-sector 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 www.dxc.technology.

© 2017 DXC Technology Company. All rights reserved. MD_6916a-18. October 2017

White Paper

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) 466 358 935

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) 400 900 951