Replace current ZAP w/ NetSparker or Zap-Baseline

[pburkholder]

Running our own ZAP scans incurs significant costs:

• It's hard and unwieldy to run (2-4 hours/month of operator time)
• It produces false positives with assessors, costing more time
• It produces false positives in Conmon, costing another 2-4 hours/month in lost time.
• It produces inconsistent results, costing more lost time
• It produces semi-spurious Low impact findings, which we have to track without really ever fixing them.

Through GSA IT we seem to have access to Netsparker scans at no additional cost. To replace we'd need to:

• ensure we have a path to running scans and getting results on the correct date each month
• ensure we have access to the scan configuration
• ensure the configuration is the same each month
• are able to map the NetSparker findings with the OWASP findings
• explain the OWASP findings that Netsparker doesn't find
• draw up an SCR
• hire in a 3PAO to validate it.

This is more of an epic over several months.

We may also want to ask if ZAP is better than we think and we just haven't been using it correctly.

[pburkholder]

We should also investigate https://www.zaproxy.org/docs/docker/baseline-scan/ 0--0

https://blog.mozilla.org/security/2017/01/25/setting-a-baseline-for-web-security-controls/

[pburkholder]

Some notes:

• It seems that we should always got SQL injection finding for our Kibana services, so worth exploring if we're in fact logging out from the app (and we should exclude logout or save for end of the run)
• When starting ZAP, one can launch browser from ZAP home page and it's autoconfigured with Proxy and certs
• The baseline scan seems to only be passive, and doesn't allow for authentication, but maybe see https://www.youtube.com/watch?v=B-MDsECikqM&list=WL&index=27&t=685s Zap Deep Dive automation from a few weeks ago.
• See also https://github.com/ICTU/zap-baseline which may support JWT and authenticated scans.
• Zap includes NOSQL attack, so see if we can exclude SQL attacks and run the NOSQL ones.

[pburkholder]

Some notes on ZAP:

• We can and should exclude secureproxy.gsa.gov
• We should use less privileged users / mashing all the buttons as a robot in an active scan could be problematic
• The Firefox built-in is pretty nice - upper right on top toolbar
• Definitely need to use the AJAXSpider for Kibana
• Need to start using log.debug so we can investigate findings, as the reports don't provide enough detail on evidence for findings.

[pburkholder]

Some notes on using Netsparker, since it came up the other day that we should leverage GSA's Netsparker/Invicti.

We tried for a period to request that GSA run the "external" scans with Netsparker (now Invicti) and we added those steps to our "Run Conmon" issue from January 2021 to June 2021. We had issues with the operators not being able to run the scans, and Netsparker had it's own issue with false postives, but they were harder to track down without the source code.

If we were to take another swing at this, we'd need our own operator access to GSA's Invicti so we can run scans on demand for conmon, for assessments, and to confirm POA&M / finding closure, and also because we'd still have to auth as an operator for our Tooling apps, we can't outsource that, and we don't really need two tools generating results.

Invicti only runs "on-premise" as a Windows install. There isn't a FedRAMP authorized cloud option, and we can't run Windows ourselves, so we'd have to rely on GSA's install.

It's probably a better use of our team's resources to use ZAP's maturing automation framework and its built-in tools for managing false positives than to pursue a new tool. But I'm open to other ideas.