Group vulnerabilities and weaknesses by NIST 800-53 Rx in Security Dashboards
Problem to solve
Need a way to sort/group by NIST 800-53 Rx controls.
Intended users
https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst
Further details
As GitLab becomes more widely used by development teams within the US Public Sector and US Federal Government community, more and more discussions about solving the DevSECOps problems in those environments are becoming prevalent. In general, the prospects/customers we talk to like our approach. Single application that can do i2p. However, they are also seeing some specific areas where we do not yet have the necessary vision to meet their needs. The specific asks are:
- Do we have a way to sort Security vulnerabilities in a way that makes their overall Risk Management Framework (NIST RMF) work? (see https://csrc.nist.gov/projects/risk-management/risk-management-framework-(rmf)-overview)
- Can we classify what is of higher priority based on such a classification? Given that in the RMF there should be a set of controls that should be selected upfront to guide what gets implemented by the development team, is there a way to provide a yes/no answer to what was selected and what needs to be implemented?
Proposal
- Understand what NIST 800-53's role is in the US Federal sector. (Aware)
- Understand what NIST 800-53 controls mean and how they are organized (https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/draft)
- Understand, design and implement how GitLab will ingest the selected controls as Issues.
- Understand, design and implement how each finding of the SAST, DAST and Container Scanning components map to the NIST 800-53 controls.
- Design and implement how this will be presented to the users in the Security Dashboard. Provide a way to capture why something is dismissed/ignored. Also provide a way to identify what is fixed.
- Design and implement how API will be presented for customers to extract this information and feed to GRC (Governance, Risk and Compliance) softwares like RSA Archer (https://www.rsa.com/en-us/products/integrated-risk-management), Xacta (https://www.telos.com/cyber-risk-management/xacta/), etc.
- Provide metrics of how this is changing through each build cycle. (Perhaps in the Cycle Analytics Dashboard)
Permissions and Security
Consistent with the current usage of Security Dashboard. API will require system integration token.
Documentation
Testing
What does success look like, and how can we measure that?
All of US Federal Government and many US States use the NIST framework as a way to manage their Security posture. This is currently identified as a hole in our offering in virtually every conversations. Currently, Security teams (belonging to the CISOs and the Information Assurance offices) feel that GitLab does not address appropriately and hence do not feel our offering is mature enough to work with their Security mechanisms. That leaves our product in the same category as the Jira/Jenkins solution which they already have and use - No impetus to move to our product.
Success Criteria:
- More interest from US Federal and US States to implement GitLab in their environment.
- Give the competition a run for their money. Currently Azure has nothing in their offering, but they are working closely with Fortify to provide this. All other vendors working with US Federal government use a Best-of-breed integration philosophy. All currently used products allow this kind of mapping and reporting.
What is the type of buyer?
Ultimate because all Security offering is available there.