Dynamic Application Security Testing (DAST)¶
Dynamic Application Security Testing (DAST) is the process of analyzing a web application through the front-end to find vulnerabilities through simulated attacks. Game Warden conducts Dynamic Application Security Testing (DAST) as part of the routine security screening of your application.
Artifacts from these testing regimes are crucial components of the Deployment Passport, the body of evidence provided to our government accrediting officials that facilitate a rapid risk determination for your application. These artifacts are included in the Deployment Passport as part of an assessment memorandum indicating “Meets/ Does Not Meet” OWASP Top 10 framework for both Static and Dynamic Application Testing.
DAST technologies are designed to detect conditions indicative of a security vulnerability in an application in its running state. Most DAST solutions test only the exposed HTTP and HTML interfaces of Web-enabled applications; however, some solutions are designed specifically for non-Web protocol and data malformation.
Conducting DAST scans is the responsibility of Second Front Systems; we conduct both un-authenticated and authenticated DAST scans using Tenable. Game Warden customers are responsible for remediating findings in accordance with the DAST Acceptable Baseline Criteria listed below. Second Front Systems will provide Game Warden customers results of DAST scans and will identify findings that need remediation if the finding represents a vulnerability under the OWASP Top 10 Exploits.
DAST artifacts are stored in the Game Warden application in the documents section.
DAST Scan Periodicity¶
DAST scans are required:
- Prior to initial Certificate to Field
- Prior to deploying any code changes
- Prior to Certificate to Field Renewal
DAST Acceptable Baseline Criteria¶
DAST scanning provides a robust analysis of each application based on known exploits and vulnerabilities. 2F prioritizes findings in the the the OWASP Top 10 Exploits, which are categorized by severity and finding family. Findings must be addressed in accordance with below Acceptable Baseline Criteria timelines:
| Severity | Justification Timeline | Mitigation/Remediation Timeline |
|---|---|---|
| Critical | Pre-deployment | Pre-deployment |
| High | Pre-deployment | Pre-deployment |
| Medium | 10 days | 60 days |
| Low | 30 days | 180 days |
| Info | N/A | N/A |
Informational findings are for information purposes only, they will be provided to the customer but require no action.
Scan Prioritizations and Timeline¶
Prerequisites
The application must be functional in development and accurately depict the architecture and code that will be submitted for CtF.
You must provision a user account for Second Front's test user.
-
Use this format: (company)-test@secondfront.com
-
Ensure this user has basic permissions, not admin
There is an unauthenticated scan that will run and then the customer will need to add Second Front's test user, so that we can do an authenticated scan.
- Scans take a full day to run, with more time factored for an additional web-based login process after P1.
- Scans will be prioritized FIFO (First In, First Out)
Can we unfreeze dev to address any DAST results?
Any vulnerabilities that come up during DAST will require justifications or remediations. Our Security team will help guide you to a resolution either way. If a remediation is necessary, you will need to make the fix, even if that involves making changes in dev. If you have to make any changes to fix issues, DAST will need to be rerun. SAST scan is good for 30 days, SAST scan didn't populate any vulnerabilities or if those vulnerabilities were addressed, there's no need for new scans. Note: if the most recent scan of images in Scan Lab is older than 14 days when 2F is ready to run the DAST scan, the Security Team will require a fresh scan, which can result in new CVEs being populated.