The purpose of this page is to provide guidance to DI2E users so they understand how the DI2E Development Tools can be used properly for information that may be Controlled Unclassified Information (CUI) or subject to International Traffic in Arms Regulations (ITAR) policies.
The DI2E program provides an environment that can be suitable for unclassified ITAR regulated material or CUI (including FOUO) if used properly. DI2E 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, cloud environment, and personnel may work with or support programs that create, store, or transmit ITAR restricted materials. However, the DI2E program itself is not a producer of any original defense materials that could fall under ITAR restrictions. Therefore DI2E 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.
The guidance provided below includes best practices and information on the use of DI2E tools and should not be construed as legal advice for any particular program. It is recommended that each program 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.
For more information on ITAR and CUI, and how DI2E is aligning to policy please refer to DI2E Compliance with International Traffic in Arms Regulations (ITAR) and Controlled Unclassified Information (CUI) Guidance.
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.
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. Many corporate or non-government provided email systems do not meet the policy requirements for receiving ITAR or CUI content. DI2E users should verify what content is permitted based on their specific email provider. The system sends email notifications to the registered email address of our users (all US citizens), these emails are unencrypted. Special precautions need to be taken to ensure protected information remains safe.
To aid users with proper handling of ITAR and CUI data DI2E provides some scenarios and guidance for using various DI2E Development Tools. Below is a table with the specific requirements for each tool along with the responsibilities to ensure safe handling. After the table are more complete descriptions and examples for each tool.
Description of Capabilities
Notifications will be enabled on a project by project basis. Each project will have to agree to the responsibilities noted before notifications will be enabled for that project.
Two notification options exist. The out-of-the box notifications include issue summaries and comments in the emails. If a project would like to suppress those, they may choose to use the DI2E ITAR notification templates. Those templates will include the action that triggered the notification and a link to the issue, nothing more.
ITAR/CUI information must not be entered into any of the standard JIRA fields (issue, description, etc.).
ITAR/CUI information must not be entered into any comments on JIRA issues.
|Notifications from JIRA can include any of the standard JIRA fields along with user comments. Restricting those fields from containing any ITAR/CUI information will prevent it from being sent via email.|
|Confluence||Notifications from confluence can contain any information from the page along with any user comments. Attachments are not included in notifications. Notifications for confluence are enabled system-wide and cannot be disabled for individual projects. The notification template for the DI2E confluence has been updated to only include the page title - all other information will be excluded.|
ITAR/CUI information must not be entered into the page title. Information is provided in the Confluence section below on how to create page banners above the page title to mark pages with ITAR/CUI information.
All pages and content in confluence must be properly marked/portion marked.
|Notifications from confluence will only include the page title. Restricting the page title from containing any ITAR/CUI information will prevent it from being sent via email.|
|Jenkins||Notifications for Jenkins will be enabled on a build by build basis. Email notifications for Jenkins are configured by the build owner when they create a build task.||Jenkins users must ensure that the build tasks are configured so that no ITAR or CUI information would be included in the email notifications.||Each build task will be configured by the user so that no ITAR/CUI information will be sent via email. If there is a possibility of ITAR/CUI in the build notification the user can disable notifications for that build.|
|Bitbucket (Stash)||Notifications include information about pull requests along with user comments and code snippets. Notifications for Bitbucket are enabled system-wide and cannot be disabled for individual projects.||ITAR/CUI information must not be entered into any user comments/messages/descriptions or branch names for bitbucket.||Notifications from Bitbucket include user comments/messages/descriptions, code snippets, and branch names, along with user names and dates. Restricting those fields from containing any ITAR/CUI information will prevent it from being sent via email.|
Notifications from Fisheye include user comments. Users can also optionally include code snippets in notifications as well. Notifications for Fisheye are enabled system-wide and cannot be disabled for individual projects.
|ITAR/CUI information must not be entered into any user comments. Users must not choose to include code snippets in the notification if the code snippet contains any ITAR/CUI information.||Notifications from Fisheye include user comments and optionally code snippets. Restricting comments from containing any ITAR/CUI information will prevent it from being sent via email. Users are required to review the code snippets before including them in the notifications to prevent ITAR/CUI information from being sent via email.|
|Storefront||Notifications from the storefront include user comments, data tags, updates when items are changed, and reports on storefront content.||ITAR/CUI information must not be entered into any storefront field, comment, tag, or rating.||Restricting strorefront content from containing any ITAR/CUI information will prevent it from being sent via email.|
DI2E users should never include ITAR/CUI information in the DI2E IT Support and Accounts JIRA projects.
By default the reporter of a JIRA issue is included in the list of users who is "watching" the issue. There can also be numerous other users watching the issue and email notifications of issue actions will be sent to all watchers of the issue. Built-in fields that are part of the out-of-the-box JIRA and comments may be included in JIRA email notifications and should not contain any ITAR or CUI data: https://confluence.atlassian.com/jira/what-is-an-issue-270829373.html. Any custom fields that are created for your specific project do not come across in email notifications.
Creation or Assignment of a JIRA Issue to a User
When creating a JIRA issue, or assigning a previously created issue to a user the previous Assignee and the new Assignee receive and all "watchers" of the issue receive email notifications with the JIRA issue summary and who performed the action. DI2E users should ensure they do not put any ITAR or CUI content into the JIRA issue summary to prevent that content from transmitting via email.
Editing Issue Title or Field Values
Most user actions are considered edits to JIRA issues: adding or changing field values, changing the state of the issue (e.g. in progress, resolved, etc.), labels, components, priority, etc. Edits to JIRA issues generate email notifications that are sent to all "watchers" of the issue. When editing an issue the contents of the email notification vary depending on what is edited. At a minimum notifications include: the issue summary, the field and field value that was edited, and the user who performed the change. In the example shown below the red text was removed and the green text was added. DI2E users should ensure they do not put any ITAR or CUI content into out-of-the-box JIRA fields to prevent that content from transmitting via email.
Comments on JIRA Issues
When users comment or reply to comments on JIRA issues an email notification is generated and is sent to all "watchers" of the issue. As shown below the email notification generated contains the issue summary and also the comment text. DI2E users should ensure they do not put any ITAR or CUI content into the comments they make on JIRA issues to prevent that content from transmitting via email.
Confluence sends email notifications for many different conditions - by default the creator of a confluence page is included in the list of users who is "watching" the page. There can be numerous other users watching the page and email notifications of page actions will be sent to all watchers of the page. DI2E users should ensure all pages that contain ITAR or CUI information should be properly marked.
DI2E has customized the template for the Confluence email notifications to be limited to only include the link to the page (which may include the page name), without page content, due to the risk that ITAR or CUI information could be included in any email notifications. Users should not create confluence page titles that contain ITAR or CUI information. Information on how to include a banner above the page title for ITAR/CUI pages is provided at Page Banners for Confluence.
DI2E users should also be cognizant of the fact that if you click on a document that is an attachment to a confluence page the document might download to your local machine so you are responsible for ensuring that your local machine meets policy requirements to store ITAR or CUI material.
Editing a Confluence Page
When you edit a confluence page any users who are watchers of the page will be notified via email of the edit.
Tagging (mentioning) a User on a page
When you mention a user (or tag them) on a page with the @username utility an email notification will be sent to the user.
Commenting on a Confluence Page
There are two basic ways in which users can comment on a page: inline comments applicable to a highlighted section of text or a general comment at the bottom of the page. Creating either type of comment will create a notification to all watchers of the page.
Jenkins build tasks can be configured to send email notifications to users for many different conditions. The contents of the email notifications vary depending on the specifics of the build task - build failures notifications in particular can contain lots of information. Failure notifications can contain computer hostnames, URLs, filenames, component names, stacktraces of failed code execution, etc. If the software that you are developing using DI2E Development Tools is software that would be ITAR controlled then be aware that you may need to opt out of email notifications for your Jenkins build tasks for that software to ensure that no ITAR or CUI information would be included in a Jenkins email notification.
Email notifications for Jenkins are configured by the project owner when they create a build task. Jenkins build tasks can be configured to send email notifications and project users are responsible for ensuring no ITAR or CUI information would be included in the email notifications. These notifications can be for any/all of the following conditions:
- Build Start
- Build Aborted
- Build Failure
- Build Not Built
- Build Success
- Build Unstable
- Build Back to Normal
Depending on how the Jenkins task is configured individuals in the recipients list or those who broke a build task may receive email notifications.
When you create a pull request and select a reviewer the reviewer gets notified of the pull request via email. The approval or rejection of the pull request also can generate an email notification but contains similar information to the example below. Email notifications are also possible when code is checked in, changes or fixes are merged with existing code, or a new code release is published. Comments the user enters when performing these actions can be included in the email notification and therefore should not include ITAR/CUI information to prevent mishandling of sensitive data.
The email notification for the pull request only contains the title of the pull request and does not contain the detailed description field therefore the chances of any ITAR or CUI information being transmitted in Bitbucket pull requests is almost zero.
The FishEye code review tool can generate email notifications when users are assigned to review code, provide review comments to code, etc. In the example shown below if a user elects to "Quote source" in their comment then portions of code that could be ITAR or CUI controlled will be sent in the email notification to the Code Author, Moderator, and possibly to other reviewers. If the software that you are developing using DI2E Development Tools is software that is ITAR controlled then be aware that you may need to ensure when using FishEye users do not "Quote source" or enter any comments that contain ITAR or CUI since that information would be included in the email notifications.
The DI2E Storefront also has the capability to send email notifications when a user sets up a watch on a component, has a standing report generated, and when submitting/updating component entries. These emails and reports can contain information from any field in the storefront data, to include titles, descriptions, and comment sections. Therefore users should not include and ITAR or CUI controlled information in the DI2E Storefront; to include component submissions, data tags, comments, and question fields. The DI2E Storefront displays a warning icon on all data entry fields as a reminder.
Cloud Based Software and Services
There are unique challenges presented with the popularity of many commercial and public hosted websites and Software-as-a-Service (SaaS) offerings - many of which utilize commercial clouds or infrastructure that is not FEDRAMP certified and do not meet the regulations to store, process, or transmit ITAR or other sensitive data. DI2E users are cautioned when utilizing any 3rd party resources. Some examples of popular resources that are not ITAR compliant are:
- Many cloud based email providers: Microsoft Office 365, Google Mail, Yahoo mail, etc.
- Docker hub
- Developer community forums: StackOverflow, Amazon developer forums, etc.
DI2E users should also verify what content is permitted for their specific email provider - many are not suitable for transmitting/storing ITAR/CUI information.
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