The purpose of this page is to describe how DI2E systems currently meets the technical safeguards outlined in the DoD Instructions and NRO Directives to handle Controlled Unclassified Information (CUI) or subject to International Traffic in Arms Regulations (ITAR) information.
The DI2E Framework program provides an environment that can be suitable for unclassified ITAR regulated material or CUI (including FOUO) if used properly. DI2E Framework serves a diverse community of Intelligence Community (IC) and Department of Defense (DoD) users and makes every attempt to support the policy safeguards of both communities. The CUI policies for both IC and DoD align with very little deviation. However, it is important to note that each government sponsor may have their own variations in their specific policies for CUI, and users are advised to consult their sponsor's policies to ensure they are handling CUI information accordingly. The US Department of State Directorate of Defense Trade Controls is the governing body for ITAR regulations and should be consulted as the authoritative source. The DI2E Development Tools (DevTools), cloud environment, and personnel may work with or support programs that create, store, or transmit ITAR restricted materials. However, the DI2E Framework program itself is not a producer of any original defense materials that could fall under ITAR restrictions. Therefore DI2E Framework program does not possess or need to obtain an ITAR export license and the program does not need to be registered with the DDTC as a manufacturer or exporter of ITAR materials.
As an Intelligence Community (IC) project executed out of the NRO, DI2E Framework falls under the authority of the IC Community Directive 503, Intelligence Community Information Technology Systems Security Risk Management, Certification, and Accreditation, and is following the Risk Management Framework (RMF) process under NRO oversight. To support our DoD customers, DI2E Framework analyzed and compared both the IC (NRO-100-37) and DoD (DoD 8582.01) guidance for controlling Controlled Unclassified Information (CUI) to help our customers understand how DI2E DevTools comply to both sets of requirements. This policy analysis and requirements trace can be found at below.
Recently, DISA released v3.0 of the DoD Cloud Computing Security Requirements Guide (CC SRG) dated March 6, 2017, which has updated guidance on CUI for DoD Cloud Service Providers (available here http://iase.disa.mil/cloud_security/Pages/index.aspx). DI2E Framework has completed an analysis on the CC SRG and added it to the analysis and requirements trace.
The guidance provided below includes information on how DI2E systems currently meets the technical safeguards outlined in the DoD Instruction and NRO Directives to handle CUI or ITAR information. This should not be construed as legal advice for any particular program.. It is recommended that each program should consult their legal organization and/or Government leadership regarding creating, marking, storing, and distributing any CUI or ITAR software, documents, and other materials.
This page conveys the interpretation/opinions of the DI2E program and may not reflect the interpretation/opinions of your company, project, or the Government. The DI2E program and personnel are not liable for the actions of the DI2E users or their use of the DI2E environment for ITAR or CUI related material.
CUI Policies Applicable to DI2E
For DI2E there are three main documents that outline the technical and policy requirements for Controlled Unclassified Information (CUI) which includes For Official Use Only (FOUO) information.
- NRO Directive 100-37 NRO Directive FOUO.pdf
- DoD 8582.01 and DoD 5200.01 vol 4 (specifies marking FOUO)
- DoD Cloud Computing Security Requirements Guide, V1R3 6 March 2017
Summary of Difference in NRO and DoD CUI Policies
The CUI policies for both NRO (IC) and DoD align with very little deviation. A review of the the technical requirements and safeguards for hosting FOUO for each of these reveals that the language between the NRO Directive and DoD Instruction is almost identical. The only deviations are noted below. The NRO is more stringent in their directive on the following two matters:
- NRO (Section IV (a), Page 7) ---- explicitly disallows the use of cloud based software providers and storage locations where as DoD ((m) Page 8) states that it is allowed as long as they "provide at least the same level of protection" as outlined by the other technical safeguards in the instruction.
NRO (Section V , Page 9-10) ---- requires that we provide a CONOPS and get PSO approval whereas DoD instruction has no corresponding section requiring approval.
Use of DoD PKI
The DoD CC SRG paragraph 188.8.131.52 notes:
"It is recognized that some Impact Level 4/5 systems must support some non-privileged user populations (e.g., retirees) that cannot receive a DoD CAC/PKI or other DoD-approved PKI authentication to gain access to CUI (e.g., PII/PHI) for which they have a legal right to access. In cases such as these the Mission Owner will seek AO approval to categorize such data as Unclassified Sensitivity Level 1 IAW DoDI 8520.03, which would permit the use of Credential Strength A. (E.g. A password as an authentication) While such populations must typically use a UID and strong password managed IAW DoD password policy, the Mission Owner is encouraged to implement stronger measures such as two-step verification where an access code is sent to the user via a different communications path than the one accessing the web site or application after entering the UID/password combination. In effect, this becomes a two-factor authentication system"
DI2E DevTools are deployed on Amazon Web Services (AWS) GovCloud, a FedRamp certified cloud provider. The DI2E DevTools currently support CAC authentication, but do not require it - many of our customers cannot receive a DoD PKI/CAC. To meet this requirement, DI2E Framework is working to implement solutions that cover the "other DoD-approved PKI" as provisioned in the guidance and are adding multi-factor authentication to meet the minimum credential strengths as outlined in DoDI 8520.03, Identity Authentication for Information Systems.
Use of .net verse .mil
DoD Instruction 8410.01 Internet Domain Name and Internet Protocol Address Space Use and Approval guidance is that in most circumstances any DoD web content should be hosted on a child of the *.mil Domain. This instruction states in section 2.b that is is not applicable "to programs used for non-operational purposes (e.g., research, developmental, and testing networks)."
DI2E DevTools support other programs' research, development, and testing efforts that would normally be conducted in individual contractor facilities and other non-accredited environments. DI2E DevTools consolidates those development factories into a single government owned environment, significantly reducing cost across the enterprise and reducing risk to the software development life cycle. DI2E DevTools does not support any DoD or IC military or intelligence mission/operations and is a non-operational system that supports research, development, and testing.
DoD CC SRG paragraph 3.2.4 defines when DoD customers may use commercial cloud offerings and other domains. DI2E DevTools operates on a commercial FedRamp cloud offering, and as such the two cases sited below apply. When customers are allowed to operate on other domains, the DoD SCG states customers will "establish their own boundaries and private or internet based connectivity."
- DoD contractors operating a system or application for the DoD. This is primarily for the fulfilment of the contract, not for the contractor’s general storage/processing of CUI/CDI or the contractor’s internal corporate cloud use cases. In this case, the contractor is operating on the behalf of a Mission Owner and must fulfil all Mission Owner requirements as specified in the CC SRG.
- DoD contractors required to store/process DoD CUI or Covered Defense Information (CDI) as part of their DoD contract. This is primarily for the fulfillment of the contract, not for the contractor’s internal corporate cloud use cases.
Based on the allowances in the DoD 8410.01 and the DoD CC SRG, DI2E DevTools operates on a FedRamp certified AWS Cloud on a .net domain to support DoD and IC programs' research, development, and testing efforts.
How DI2E meets Policies for Controlled Unclassified Information (CUI)
DI2E DevTools currently meets the technical safeguards outlined in the DoD 8582.01. NRO Directive 100-37, and DoD CC SRG as outlined in the table below. DI2E is currently seeking the formal written approvals required from NRO. Specific safeguards from the NRO and DoD policies are shown below with an answer for how DI2E meets the requirement.
NRO Directive 100-37
DoD Cloud Computing Security Requirements Guide
How DI2E DevTools meets the requirement
|(a, p7) Controlled unclassified NRO information shall not be processed, sent from, or stored on publically available computers (e.g., those available for use by the general public, such as kiosks in lobby areas, Internet cafes, hotel business centers, airports, etc.), or any personal portable electronic devices, nor shall cloud storage solutions (e.g., SkyDriv, Amazon S3, RISC Cloud, etc.) be used for controlled unclassified NRO information.||(a, p7) Do not process unclassified DoD information on publically available computers (e.g., those available for use by the general public in kiosks or hotel business centers).||5.2.1 All data stored and processed by/for the DoD must reside in a facility under the exclusive legal jurisdiction of the US|
The DI2E DevTools does not contain or process controlled unclassified information on publicly available information systems.
DI2E DevTools require a user account that can be accessed with CAC PKI or username/password credentials. All individuals with DI2E accounts are required to provide US citizenship verification: CAC, JPAS, or PSO vetting, prior to getting a system account.
DI2E DevTools utilizes AWS GovCloud to host the Development Tools which has been FedRamp approved for use with ITAR and CUI information.
While the DI2E System and supporting Personnel make the DI2E Development Environment a safe place for ITAR and CUI, the system does send automated email notifications to users in response to specific user actions.
|(b, p8) Protect controlled unclassified NRO information by at least one physical or electronic barrier (e.g., locked container or room, logical authentication or logon procedure, etc.) when not under direct control of an authorized user.||(b, p7) Protect unclassified DoD information by at least one physical or electronic barrier (e.g., locked container or room, logical authentication or logon procedure) when not under direct individual control of an authorized user.||5.6.1 CSP data processing facilities supporting Level 4 and 5 CSOs/information will meet the physical security requirements defined in the FedRAMP Moderate baseline|
DI2E DevTools is hosted in Amazon Web Services Gov Cloud which is FEDRAMP certified and meets the protections required to store CUI https://aws.amazon.com/govcloud-us/faqs/
|(c, p8) Controlled unclassified NRO information shall be removed when no longer needed in accordance with NI 56-1-3, Records Disposition and Preservation. For electronic devices and storage media, at a minimum, delete or overwrite the information on media/devices that have been used to store and/or process controlled unclassified NRO information before external release or disposal.||(c, p7) At a minimum, overwrite media that have been used to process unclassified DoD information before external release or disposal.||5.9 CSPs will ensure that no residual DoD data exists on all storage devices decommissioned and disposed of, reused in an environment not governed by an agreement between the CSP and DoD, or transferred to a third party|
DI2E Framework does not release physical media. Physical media is physically destroyed after use IAW NRO and DoD procedures.
DI2E DevTools is hosted in Amazon Web Services Gov Cloud which is FEDRAMP certified and ensures no residual data exists on devices prior to decommissioning, disposal, reuse, or transfer, in accordance with NIST SP 800-88, Revision 1, Guidelines for Media Sanitization
|(d, p8) NRO information designated as FOUO shall be sufficiently marked (i.e., prominently at the top and bottom of each individual page) so that persons having access are aware of its sensitivity and the need to protect it (see NRO Security Manual).||Marking requirements are in DoD 5200.01 Volume 4||not covered in the CC SRG|
All CUI material is clearly marked as being FOUO or ITAR in accordance with policy.
Note: Applying appropriate markings to material is the responsibility of the individual/program/organization that created the material.
|(e, p8) Encrypt all controlled unclassified NRO information when it is stored on mobile computing devices such as laptops, tablets, and removable storage media (e.g., compact disks, thumb drives), using the best encryption technology available (preferably consistent with FIPS 140-2 encryption).||(d, p7) Encrypt all information that has been identified as CUI when it is stored on mobile computing devices such as laptops and personal digital assistants, compact disks, or authorized removable storage media such as thumb drives and compact disks, using the best encryption technology available to the contractor or teaming partner.||not covered in the CC SRG||DI2E Framework personnel who have physical access to DI2E facilities and systems are trained to ensure information stored on mobile devices is encrypted. DI2E DevTool account holders have been provided FOUO and ITAR guidance to ensure if they download information they only do so to a device that meets policy guidance.|
|(f, p8) Limit the transfer of controlled unclassified NRO information to subcontractor or teaming partners with a need-to-know and obtain a commitment from them to protect the information they receive to at least the same level of protection that specified in the contract or other written agreement.||(e, p7) Limit transfer of unclassified DoD information to subcontractors or teaming partners with a need to know and obtain a commitment from them to protect the information they receive to at least the same level of protection as that specified in the contract or other written agreement.||not covered in the CC SRG||All individuals with DI2E accounts are required to provide US citizenship verification: CAC, JPAS, or PSO vetting prior to getting a system account. Users are required to read the DI2E ITAR and CUI Guidance.|
|(g, p8) Transmit e-mail, text messages, and similar communications containing controlled unclassified NRO information using technology and processes that provide the best level of privacy available (e.g., closed networks, virtual private networks, public key-enabled encryption, or transport layer security (TLS)).||(f, p7) Transmit e-mail, text messages, and similar communications containing unclassified DoD information using technology and processes that provide the best level of privacy available, given facilities, conditions, and environment. Examples of recommended technologies or processes include closed networks, virtual private networks, public key-enabled encryption, and transport layer security (TLS).||not covered in the CC SRG||DI2E DevTools conduct communications over SSL enabled protocols (HTTPS, SSH) and some tools require VPN to access them.|
|(h, p8) Encrypt organization wireless connections and use encrypted wireless connections, where available, when processing or storing controlled unclassified NRO information. If encrypted wireless is not available, protect files (e.g., documents, spreadsheets, presentations, etc.) using application provided password protection.||(g, p8) Encrypt organizational wireless connections and use encrypted wireless connections where available when traveling. If encrypted wireless is not available, encrypt document files (e.g., spreadsheet and word processing files), using at least application-provided password protected level encryption.||not covered in the CC SRG||DI2E DevTool servers are deployed within AWS GovCloud. No wireless networking is implemented..|
|(i, p8) Transmit voice and fax transmissions only when there is assurance that access is limited to authorized recipients.||(h, p8) Transmit voice and fax transmissions only when there is a reasonable assurance that access is limited to authorized recipients.||not covered in the CC SRG||The DI2E DevTools doesn't have voice or fax capabilities. Users have been told to follow the DI2E FOUO and ITAR guidance to ensure access is properly limited.|
|(j, p9) Controlled unclassified NRO information shall not be posted to publicly available websites. Such information may be posted to websites that control access to authorized individuals by user identification and password, user certificates, or other technical means and provide protection via use of TLS or other equivalent technologies during transmission.||(i, p8) Do not post unclassified DoD information to website pages that are publicly available or have access limited only by domain or Internet protocol restriction. Such information may be posted to website pages that control access by user identification and password, user certificates, or other technical means and provide protection via use of TLS or other equivalent technologies during transmission. Access control may be provided by the intranet (vice the website itself or the application it hosts).||not covered in the CC SRG||The DI2E DevTools only has limited set of welcome pages that are publicly accessible and those pages do not contain any FOUO or ITAR material. These pages to not allow users to edit or upload content. After being authenticated to the DI2E system via CAC PKI, or DI2E username/password credentials the user will potentially have access to FOUO or ITAR data depending on their assigned user roles. All DI2E tools and sites conduct communications over SSL enabled protocols (HTTPS, SSH) and some tools require VPN to access them.|
|(a, p9) Current and regularly (at least monthly) updated malware protection services (e.g., anti-virus, anti-spyware, etc.).||(j(1), p8) Current and regularly updated malware protection services, e.g., anti-virus, antispyware.||not covered in the CC SRG|
DI2E DevTools updates antivirus definitions daily and conduct weekly scheduled scans.
|(b, p9) Monitoring and control of both inbound and outbound network traffic (e.g., at the external boundary), including blocking unauthorized/unauthenticated ingress, egress, and exfiltration through technologies such as firewalls and router policies, intrusion prevention or detection services, and host-based security services.||(j(2), p8) Monitoring and control of both inbound and outbound network traffic (e.g., at the external boundary, sub-networks, individual hosts), including blocking unauthorized ingress, egress, and exfiltration through technologies such as firewalls and router policies, intrusion prevention or detection services, and host-based security services.|
3.2.4 All other CSO customers establish their own boundaries and private or internet based connectivity.
|DI2E DevTools and our network provider control inbound and outbound traffic through technologies such as firewalls, intrusion prevention and detection services, and host-based security services.|
|(c, p9) Prompt application of security-relevant software patches, service packs, and hot fixes.||(j(3), p8) Prompt application of security-relevant software patches, service packs, and hot fixes.||not covered in the CC SRG||DI2E DevTools are configured to vendor trusted yum and patch repositories and will automatically download and install the latest security fixes and patches to system software.|
|(k, p8) Comply with other current Federal and DoD information protection and reporting requirements for specified categories of information (e.g., medical, proprietary, critical program information (CPI), personally identifiable information, export controlled) as specified in contracts, grants, and other legal agreements.||not covered in the CC SRG||Not applicable to DI2E|
|(p9) Intrusions or incidents involving the potential compromise, exfiltration or other loss of controlled unclassified NRO information on any non-government, non-NRO information system shall be reported to the Program Security Officer (PSO) in accordance with contractual requirements.||(l, p8) Report loss or unauthorized disclosure of unclassified DoD information in accordance with contract, grant, or other legal agreement requirements and mechanisms.||5.7 A data spill is a cyber-incident that requires immediate reporting and response from both the Mission Owner and CSP in order to minimize the scope of the spill and the risk to DoD data. . Mission owners will report the incident via their normal channels.||DI2E Framework reports loss or unauthorized disclosure of unclassified DoD information in accordance with contract, grant, or other legal agreement requirements and mechanisms.|
|(m, p8) Do not use external IT services (e.g., e-mail, content hosting, database, document processing) unless they provide at least the same level of protection as that specified in the contract or other written agreement.||not covered in the CC SRG|
DI2E Framework personnel utilize commercial Google mail accounts for their di2e.net e-mail. All users granted di2e.net e-mail accounts are verified US Citizens and must login with username/password credentials for account access. Access to e-mail utilizes HTTPS. All DI2E Framework personnel have been instructed that di2e.net email is not suitable for transmission of CUI or ITAR material.
|CSG Table 4 lists Mission Owner credential types for each Impact Level. For Impact 4/5, it states Non-privileged and privileged user access to CUI requires using DoD CAC/PKI or other DoD-approved PKI.||"Other DoD-approved PKI" is defined in DoDI 8520.03. Using Sensitivity Level and Entity Environment to determine Credential Strength. DI2E DevTools is determined to be Credential Strength B and states: Credential Strength B credentials can use either a multi-token solution or a multi-factor one-time password solution. These credential solutions do not involve the use of public key cryptography or PKI certificates. DI2E DevTools is implementing MFA to cover this requirement.|
DI2E System Assurances for ITAR Compliance
The International Traffic in Arms Regulations (ITAR) is a set of United States Government regulations that regulates the export and import of defense related articles and services that could have serious impact on defense and national security. The ITAR rules are primarily intended to keep technology with military applications out of the hands of countries or individuals posing a threat to U.S. national security. Defence-related technology, which includes both goods and the related technical data, is included in a part of the regulations called the United States Munitions List (USML). ITAR regulations impose additional constraints on the handling and dissemination of materials in addition to the classification marking of the materials. ITAR requires, in relevant part, that covered material (items listed on the USML) only be shared with U.S. persons unless a special license, authorization, or exemption is obtained. DI2E enables customers to design, develop, document, and share project materials containing ITAR data under the assumption of a shared responsibility model where each program is responsible for the use of DI2E tools and the actions of their program personnel.
If you are unsure if the software, design, document, code, email, or other work product is considered an ITAR restricted material then please consult your project, Government leadership, or counsel because DI2E can not make that determination for you.
When discussing ITAR it is important to note there is a distinction between the restrictions placed on personnel using ITAR and a system containing ITAR material.
US Citizens can create, handle, store, and disseminate ITAR material with other co-workers who are US Citizens and have a need for the materials during the course of their job duties without requiring any specific export license. Personnel who have a need to distribute ITAR material with any foreign personnel, foreign based companies, foreign governments, or place any material in a software system where foreign personnel can access the information must have an explicit license to "export" the ITAR material. Special care should be taken with cloud based email or cloud based file storage because use of a cloud that is not FEDRAMP certified is considered an export. Always be cognizant of who the recipients are when sending emails, sharing links, or posting potential ITAR data to any web location because these could be considered exports. If you are unsure if you are covered by an ITAR export license please consult your Contracting Officer Technical Representative (COTR).
Unlike ISO 27001, there is no formal ITAR certification. However, the DI2E program has conducted a review of the DI2E system and provides specific assurances that the system, DI2E users, and privileged DI2E personnel meet the regulations to allow DI2E to process, store, and transmit ITAR data when used in accordance with the guidelines established in this document.
To ensure that DI2E systems are appropriate for ITAR data the DI2E program has implemented the following measures:
- All users who have any DI2E system access provide either verification of US Citizenship for the DI2E team to validate US Citizenship prior to being granted an account;
- See https://www.di2e.net/display/DI2E/Accounts for further information on proof of citizenship.
- The DI2E tools are hosted in data centers within the United States, administered by only US Citizens;
- DI2E tools are hosted on US Government servers physically located in Northern Virginia, run by our administrators, and/or
- DI2E hosts some tools from Amazon Web Services GovCloud which is FEDRAMP certified and meets ITAR compliance https://aws.amazon.com/govcloud-us/faqs/
- The DI2E program communicates/passes data only with US Citizens;
- Special precautions are taken when working with 3rd party vendor support. If support is required of 3rd party vendors, only sanitized, administrative log files are provided.
- The DI2E program does not export (outside the US);
It is important to note that in the ITAR regulations, allowing access to the DI2E system that contains ITAR data, or sharing ITAR with an employee who may be temporarily or permanently located abroad does not require a special export license - If that employee is not in an excluded country, is a US Citizen, and has a legitimate business need for the access. However this exemption should be used with extreme caution.
- Section 125.4 Exemptions of General Applicability (exempt from needing an export license): "(9) Technical data, including classified information, and regardless of media or format, sent or taken by a U.S. person who is an employee of a U.S. corporation or a U.S. Government agency to a U.S. person employed by that U.S. corporation or to a U.S. Government agency outside the United States. This exemption is subject to the limitations of §125.1(b) of this subchapter and may be used only if: (i) The technical data is to be used outside the United States solely by a U.S. person; (ii) The U.S. person outside the United States is an employee of the U.S. Government or is directly employed by the U.S. corporation and not by a foreign subsidiary;" https://www.pmddtc.state.gov/regulations_laws/documents/official_itar/ITAR_Part_125.pdf
- All users who have any DI2E system access provide either verification of US Citizenship for the DI2E team to validate US Citizenship prior to being granted an account;
Marking ITAR and CUI Data
DI2E requires users to properly mark any ITAR or CUI data stored within any DI2E tool whether it is an attached document, Confluence page, source code, field within JIRA, etc. ITAR and CUI data must be clearly and explicitly marked. Please consult and follow your project specific guidelines for exact marking requirements and language. For reference a sample of ITAR export warning marking is:
WARNING - This document contains technical data whose export is restricted by the Arms Export Control Act (Title 22, U.S.C., Sec 2751, et seq.) or the Export Administration Act of 1979, as amended, Title 50, U.S.C., App. 2401 et seq. Violations of these export laws are subject to severe criminal penalties. Disseminate in accordance with provisions of DoD Directive 5230.25.
US Department of State, Directorate of Trade Controls https://www.pmddtc.state.gov/index.html
- ITAR Regulations and Laws
- Compliance Program Guidelines
- White paper discussing possible updates to ITAR to allow encryption with use of cloud, however looking that the current regulations the suggested wording was never accepted as a change
- Advisory opinion about tokenization of ITAR data prior to using commercial cloud
- Discusses that there was a State Department Advisory Opinion that said storage/transmission in public cloud was ok if the data was tokenized (not encrypted but tokenized). Encryption was never accepted.
- 2015 Proposed rule change/clarification to allow encryption to be sufficient protection of ITAR in the cloud - no confirmation this was ever enacted though
- Oct 2015 blog explaining current state of proposed rule changes
NRO Directive 100-37 NRO Directive FOUO.pdf
DoD Cloud Computing Security Requirements Guide, V1R3 6 March 2017