Review requirements for vulnerability scanning

[theathorn]

Review the NIH Infosec Policy Handbook to answer the following questions:

What does a vulnerability scan report contain?
Does the scan only look for vulnerable binaries or should Python packages be considered as well?
Do we need to scan packages deployed to AWS Lambda?
Do we need to scan GitLab EC2 instances?
Does the report need to reference vulnerable versions of Python packages?
How is Python source code scanned in general by these tools?
Are there recommended vulnerability scanners?
Do these scanners support scanning Python programs?
What is the procedure for ignoring a vulnerability scan?
How frequently do these scans need to be run?

Review "FedRAMP vulnerability scanning requirements" and "FedRAMP vulnerability scanning requirements for containers" and highlight what the team is currently doing and gaps. Review NIH handbook for additional information on specific ask from agency on the final scanning report.

[melainalegaspi]

@theathorn to identify a more specific epic for this ticket.

[theathorn]

Nneka to fill-in list of all related FedRAMP controls, and then re-assign to Hannes.

[nolunwa-ucsc]

@theathorn the list of related FedRAMP Control https://docs.google.com/document/d/1LcihWQcmAbgbW7hEVOXJPvuDh5b5Jyo98dJVlv7xsf0/edit

[nolunwa-ucsc]

update from Jevan about the authentication scan issue, it is still being worked on by the Invicti help desk... they have internally escalated the issue to their developer team, so hopefully we will have a solution soon.

[melainalegaspi]

@hannes-ucsc: "The team is not implementing the security scan, ITS is. Not quite sure why I would be the proper assignee."

[melainalegaspi]

Triage during Thursday 10 a.m. compliance meeting.

[theathorn]

@hannes-ucsc to review @nolunwa's document.

[hannes-ucsc]

I've started to review the document but have come to the conclusion that its current structure is inadequate for its purpose, since there seems to be significant overlap between the controls. For example, the scanning of instances by Amazon Inspector (with support by the SSM agent) is mentioned in CA-7, RA-5, SI-11, SI-2 and SI-3. This leads to a highly duplicative and hard to manage document. The overlap also interferes with our ticket management since many concrete implementation tickets would have to be mentioned in multiple epics, something that is currently not possible.

The best way to handle the overlap is to create a table that has the individual controls as rows and concrete implementations as columns. The individual columns should each represent a concrete implementation ticket. If we want to continue to manage controls as epics we need to pick one epic (row in the table) as the main epic for every concrete implementation ticket (column in the table).

[theathorn]

Tickets may belong to multiple Epics, and many of the compliance tickets do so.

[melainalegaspi]

@hannes-ucsc :"you are correct. My point about the table format still applies."

[melainalegaspi]

@nolunwa to restructure document according to @hannes-ucsc's proposal.

[nolunwa-ucsc]

thia has been done, closing it out