search

GSA-TTS / tts-tech-operations

Home of the TTS Technology Portfolio team
https://handbook.tts.gsa.gov/tech-operations/
Other
5 stars 0 forks source link

Translate proposed capabilities for Common Control Platform into technical requirements #661

Closed its-a-lisa-at-work closed 3 years ago

its-a-lisa-at-work commented 4 years ago

Background information

A TTS Common Control Platform has been brought up frequently.

User stories

As a cybersecurity expert with a performance measure related to Cybersecurity measure, I would like to do something that benefits the TTS Tech Portfolio and has been identified as important so that I can get a good performance rating.

Acceptance criteria

The assignee should add some checkboxes as a "sketch" of the steps to complete, which may evolve.

afeld commented 3 years ago

GSA IT calls theirs the Enterprise Application Services (EAS). The ATO memo, which lists the components that are part of it.

afeld commented 3 years ago

Relevant doc from cloud.gov

JJediny commented 3 years ago

@afeld confused is it EAS or GSA's IT Security Procedural Guide: Information Security Program Plan (ISPP) CIO-IT Security-18-90 or is that document within the EAS program's management?

its-a-lisa-at-work commented 3 years ago
afeld commented 3 years ago

I point people to this issue a lot, so to ground it a bit:

Across TTS, we have systems with ATOs that leverage external policies and tools in similar (if not identical) ways. This causes a lot of duplication of effort, copying and pasting responses (at best), wasting time rewriting them, or having sub-par practices around them (at worst). I'm looking for us to:

  1. [ ] Identify what components might be good candidates. Examples:
  2. [ ] Decide on where the canonical statements should live, and in what form
    • Maybe Google Doc(s) to start, then OSCAL in a repository once they settle?
  3. [ ] Pull relevant control statements from whatever System Security Plans (SSPs) we can
  4. [ ] Merge those responses into best-of-breed control narratives
    • May also include conditions for use ("you can use this if you have X enabled," etc.)
  5. [ ] Get sign-off (even unofficially) from Security
  6. [ ] Update the relevant SSPs
  7. [ ] Publish them somewhere canonical
  8. [ ] Update documentation (Before You Ship, Engineering Practices Guide, etc.) to point to them

That probably needs to be split into multiple issues, but that's the arc I'm thinking.

_Some history: This is following through on the Component ATO proposal that was done several years ago._

its-a-lisa-at-work commented 3 years ago

@afeld Thanks! That above is extra helpful. I think a step that we also need to do while we do this is keep CUI requirements in mind .. for example ... typically an office org chart is considered FOUO, so it is reasonable to think that other information about our internal office might need protecting as well

afeld commented 3 years ago

These components are basically the building blocks that would build up to / be extracted from https://github.com/18F/Security-Compliance/issues/1.

afeld commented 3 years ago

cloud.gov's documentation of the TTS Common Control Policy

its-a-lisa-at-work commented 3 years ago

We should also consider

how performance measurements enable your organization to improve information security accountability and bolster your information security activities’ effectiveness

ryanwoldatwork commented 3 years ago

The work @afeld outlined in https://github.com/18F/tts-tech-portfolio/issues/661#issuecomment-729973705 is 80% of it.

I'd add Cloud.gov, Snyk, Google Analytics, and GSA IT as controls that are commonly shared in TTS projects.

Dependency management for documents

I'd also like a resource (diagram) that depicts the value stream, starting with the existing Controls (maybe OSCAL or OpenControls). I'm guessing this would require sitting down with TTS product owners to determine the status of each compliance process and the state of the compliance docs.

Is there a bigger problem that isn't being solved?

Is there an opportunity to engage the Security office? I know they have systems to manage the documents, but a big opportunity imo, is to embrace the notion that these free-form text documents are very de-normalized representations of discreet data (control responses), and should be managed as such. Wrapping this in an opinionated app, or at least strict-ish user conventions, could yield valuable capabilities, like Control search and lookup. Example: When writing a new control, author can run a report to see the same control response for several other systems. And maybe the results can be filtered by Shared systems and any other attribute where the data is managed. The compliance-masonry project is an example here, and might be sufficient. A challenge to realize the value of this networked effort is adoption and support by the Security office.

Update: for reference, there are derivative documents that are manually maintained that summarize information already contained with SSP's. This indicates there is a reporting need, and it is currently being fulfilled with manual work.

its-a-lisa-at-work commented 3 years ago

The intention for this card is to lay out the roadmap

afeld commented 3 years ago

Relevant opinion piece: ATO ASAP: Let’s finally fix the security compliance problem, specifically the Compliance Library part.

afeld commented 3 years ago

Splitting out to more discrete issues: