consensus around what security/compliance documentation is sensitive

[afeld]

Background Information

We have questions come up regularly about whether or not it's ok for various security/compliance documentation to be public. Most recent conversation.

Implementation Steps

• [ ] Create a list of example pieces of information
  • IP addresses
  • Configuration Management Plans
  • Incident Response Plans
• [ ] Determine if there's any existing GSA policy related to this (or upcoming through CUI, cc https://github.com/18F/tts-tech-portfolio/issues/1018)
• [ ] Get consensus from Security and Compliance Guild
• [ ] Get consensus from Security team
• [ ] Determine if any pieces cannot be shared publicly, but can have broad access within TTS/GSA
• [ ] Document, e.g. in the open source practice guide

Acceptance Criteria

• [ ] Documented restrictions around what security/compliance information needs to be restricted, and to whom

[its-a-lisa-at-work]

"TTS should be more judicious related to the information that it puts out publicly. The information related to systems can be used against TTS from an adversary to have an impact on the security of the systems. Before publishing security data, I recommend that TTS does the following:

• Adversary Assessment
• Includes reward with Bug Bounty and added bounus if they can produce how the information helped with proof of concept
• Properly mark data and its releasability
• Establish Data Stewards within TTS
• Give regular trainings on the Pentesting lifecycle, specifically recon and how the data is later used in breaches"

[JJediny]

https://docs.google.com/document/d/1P-_ow-6CFu_uEJ62wLHTUhix-d5zWVls-hdTPD16bho/edit#heading=h.mety7wpfbz9l