The IAO will ensure active vulnerability testing is performed.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-16831	APP5100	SV-55789r2_rule	DCSQ-1	Medium

Description
Use of automated scanning tools accompanied with manual testing/validation which confirms or expands on the automated test results is an accepted best practice when performing application security testing. Automated scanning tools expedite and help to standardize security testing, they can incorporate known attack methods and procedures, test for libraries and other software modules known to be vulnerable to attack and utilize a test method known as "fuzz testing". Fuzz testing is a testing process where the application is provided invalid, unexpected, or random data. Poorly designed and coded applications will become unstable or crash. Properly designed and coded applications will reject improper and unexpected data input from application clients and remain stable. Many vulnerability scanning tools provide automated fuzz testing capabilities for the testing of web applications. All of these tools help to identify a wide range of application vulnerabilities including, but not limited to; buffer overflows, cross-site scripting flaws, denial of service format bugs and SQL injection, all of which can lead to a successful compromise of the system or result in a denial of service. Due to changes in the production environment, it is a good practice to schedule periodic active testing of production web applications. Ideally, this will occur prior to deployment and after updates or changes to the application production environment. It is imperative that automated scanning tools are configured properly to ensure that all of the application components that can be tested are tested. In the case of web applications, some of the application code base may be accessible on the web site and could potentially be corrected by a knowledgeable system administrator. Active testing is different from code review testing in that active testing does not require access to the application source code base. A code review requires complete code base access and is normally performed by the development team. If vulnerability testing is not conducted, there is the distinct potential that security vulnerabilities could be unknowingly introduced into the application environment. The following website provides an overview of fuzz testing and examples: http://www.owasp.org/index.php/Fuzzing The following website provides information on web application vulnerability scanner tools. Reference the “Related Links” section at the bottom of the page for a list of available commercial and open source tools. http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html Please note that reference to these tools does not imply that they have been tested and approved for use by DISA.

Description

Use of automated scanning tools accompanied with manual testing/validation which confirms or expands on the automated test results is an accepted best practice when performing application security testing. Automated scanning tools expedite and help to standardize security testing, they can incorporate known attack methods and procedures, test for libraries and other software modules known to be vulnerable to attack and utilize a test method known as "fuzz testing". Fuzz testing is a testing process where the application is provided invalid, unexpected, or random data. Poorly designed and coded applications will become unstable or crash. Properly designed and coded applications will reject improper and unexpected data input from application clients and remain stable. Many vulnerability scanning tools provide automated fuzz testing capabilities for the testing of web applications. All of these tools help to identify a wide range of application vulnerabilities including, but not limited to; buffer overflows, cross-site scripting flaws, denial of service format bugs and SQL injection, all of which can lead to a successful compromise of the system or result in a denial of service. Due to changes in the production environment, it is a good practice to schedule periodic active testing of production web applications. Ideally, this will occur prior to deployment and after updates or changes to the application production environment. It is imperative that automated scanning tools are configured properly to ensure that all of the application components that can be tested are tested. In the case of web applications, some of the application code base may be accessible on the web site and could potentially be corrected by a knowledgeable system administrator. Active testing is different from code review testing in that active testing does not require access to the application source code base. A code review requires complete code base access and is normally performed by the development team. If vulnerability testing is not conducted, there is the distinct potential that security vulnerabilities could be unknowingly introduced into the application environment. The following website provides an overview of fuzz testing and examples: http://www.owasp.org/index.php/Fuzzing The following website provides information on web application vulnerability scanner tools. Reference the “Related Links” section at the bottom of the page for a list of available commercial and open source tools. http://samate.nist.gov/index.php/Web_Application_Vulnerability_Scanners.html Please note that reference to these tools does not imply that they have been tested and approved for use by DISA.

STIG	Date
Application Security and Development Checklist	2014-12-22

Details

Check Text ( C-17830r2_chk )
Ask the application representative to provide vulnerability test procedures and vulnerability test results. Ask the application representative to provide the settings that were used to conduct the vulnerability testing. Verify the automated vulnerability scanning tool was appropriately configured to assure as complete a test as possible of the application architecture components. E.g. if the application includes a web server, web server tests must be included. 1) If the application test procedures and test results do not include active vulnerability and fuzz testing this is a finding. 2) If the vulnerability scan results include critical vulnerabilities, this is a finding. 3) If the vulnerability scanning tests are not relevant to the architecture of the application, it is a finding. 4) If the vulnerability scan report includes informational and/or non-critical results this is not a finding. 5) If previously identified vulnerabilities have subsequently been resolved, this is not a finding.

Check Text ( C-17830r2_chk )

Ask the application representative to provide vulnerability test procedures and vulnerability test results.

Ask the application representative to provide the settings that were used to conduct the vulnerability testing.

Verify the automated vulnerability scanning tool was appropriately configured to assure as complete a test as possible of the application architecture components. E.g. if the application includes a web server, web server tests must be included.

1) If the application test procedures and test results do not include active vulnerability and fuzz testing this is a finding.

2) If the vulnerability scan results include critical vulnerabilities, this is a finding.

3) If the vulnerability scanning tests are not relevant to the architecture of the application, it is a finding.

4) If the vulnerability scan report includes informational and/or non-critical results this is not a finding.

5) If previously identified vulnerabilities have subsequently been resolved, this is not a finding.

Fix Text (F-17148r3_fix)
Perform active vulnerability and fuzz testing of the application. Ensure the vulnerability scanning tool is configured to test all application components and functionality. Address discovered vulnerabilities.