Critical Control 7: Application Software Security

How do attackers exploit the lack of this control?

Attacks against vulnerabilities in web-based and other application software have been a top priority for criminal organizations in recent years. Application software that does not properly check the size of user input, fails to sanitize user input by filtering out unneeded but potentially malicious character sequences, or does not initialize and clear variables properly could be vulnerable to remote compromise. Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, and cross-site scripting code to gain control over vulnerable machines. In one attack in 2008, more than 1 million web servers were exploited and turned into infection engines for visitors to those sites using SQL injection. During that attack, trusted websites from state governments and other organizations compromised by attackers were used to infect hundreds of thousands of browsers that accessed those websites. Many more web and non-web application vulnerabilities are discovered on a regular basis.

To avoid such attacks, both internally developed and third-party application software must be carefully tested to find security flaws. For third-party application software, enterprises should verify that vendors have conducted detailed security testing of their products. For in-house developed applications, enterprises must conduct such testing themselves or engage an outside firm to conduct such testing.

How can this control be implemented, automated, and its effectiveness measured?

1. QW: Organizations should protect web applications by deploying web application firewalls that inspect all traffic flowing to the web application for common web application attacks, including but not limited to Cross-Site Scripting, SQL injection, command injection, and directory traversal attacks. For applications that are not web based, deploy specific application firewalls if such tools are available for the given application type.
2. Config/Hygiene: Organizations should test in-house developed and third-party procured web and other application software for coding errors and malware insertion, including backdoors prior to deployment using automated static code analysis software. If source code is not available, these organizations should test compiled code using static binary analysis tools. In particular, input validation and output encoding routines of application software should be carefully reviewed and tested.
3. Config/Hygiene: Organizations should test in-house developed and third-party procured web applications for common security weaknesses using automated remote web application scanners prior to deployment, whenever updates are made to the application, and on a regular recurring basis, such as weekly.
4. Config/Hygiene: For applications that rely on a database, organizations should conduct a configuration review of both the operating system housing the database and the database software itself, checking settings to ensure that the database system has been hardened using standard hardening templates.
5. Config/Hygiene: Organizations should verify that security considerations are taken into account throughout the requirements, design, implementation, testing, and other phases of the application development life cycle of all applications.
6. Config/Hygiene: Organizations should ensure that all software development personnel receive training in writing secure code for their specific development environment.
7. Config/Hygiene: Require that all in-house developed software include white-list filtering capabilities for all data input and output associated with the system. These whitelists should be configured to allow in or out only the types of data needed for the system, blocking other forms of data that are not required.

Associated NIST SP 800-53 Rev 3 Priority 1 Controls:

CM-7, RA-5 (a, 1), SA-3, SA-4 (3), SA-8, SI-3, SI-10

Procedures and tools for implementing this control:

Source code testing tools, web application security scanning tools, and object code testing tools have proven useful in securing application software, along with manual application security penetration testing by testers who have extensive programming knowledge as well as application penetration testing expertise. The Common Weakness Enumeration (CWE) initiative is utilized by many such tools to identify the weaknesses that they find. Organizations can also use CWE to determine which types of weaknesses they are most interested in addressing and removing. A broad community effort to identify the "Top 25 Most Dangerous Programming Errors" is also available as a minimum set of important issues to investigate and address during the application development process. When evaluating the effectiveness of testing for these weaknesses, the Common Attack Pattern Enumeration and Classification (CAPEC) can be used to organize and record the breadth of the testing for the CWEs as well as a way for testers to think like attackers in their development of test cases.

Control 7 Metric:

The system must be capable of detecting and blocking an application-level software attack attempt, and must generate an alert or send e-mail to enterprise administrative personnel within 24 hours of detection and blocking.

All Internet-accessible web applications must be scanned on a weekly or daily basis, alerting or sending e-mail to administrative personnel within 24 hours of completing a scan. If a scan cannot be completed successfully, the system must alert or send e-mail to administrative personnel within one hour indicating that the scan has not completed successfully. Every 24 hours after that point, the system must alert or send e-mail about the status of uncompleted scans, until normal scanning resumes.

Additionally, all high-risk vulnerabilities in Internet-accessible web applications identified by web application vulnerability scanners, static analysis tools, and automated database configuration review tools must be mitigated (by either fixing the flaw or through implementing a compensating control) within fifteen days of discovery of the flaw.

While the 24 hour and one hour timeframes represent the current metric to help organizations improve their current state of security, in the future, organizations should strive for even more rapid alerting, with notification about an application attack attempt being sent within two minutes.

Control 7 Test:

To evaluate the implementation of Control 7 on a monthly basis, an evaluation team must use a web application vulnerability scanner to tests for each type of flaw identified in the regularly updated list of the "25 Most Dangerous Programming Errors". The scanner must be configured to assess all of the organization's Internet-accessible web applications to identify such errors. The evaluation team must verify that the scan is detected within 24 hours and an alert is generated.

In addition to the web application vulnerability scanner, the evaluation team must also run static code analysis tools and database configuration review tools against Internet-accessible applications to identify security flaws on a monthly basis.

The evaluation team must verify that all high-risk vulnerabilities identified by the automated vulnerability scanning tools or static code analysis tools have been remediated or addressed through a compensating control (such as a web application firewall) within 15 days of discovery.

The evaluation team must verify that application vulnerability scanning tools have successfully completed their regular scans for the previous 30 cycles of scanning by reviewing archived alerts and reports to ensure that the scan was completed. If a scan was not completed successfully, the system must alert or send e-mail to enterprise administrative personnel indicating that the scan did not complete successfully. If a scan could not be completed in that timeframe, the evaluation team must verify that an alert or e-mail was generated indicating that the scan did not complete.

List Of Controls

• Critical Control 1: Inventory of Authorized and Unauthorized Devices
• Critical Control 2: Inventory of Authorized and Unauthorized Software
• Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
• Critical Control 4: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• Critical Control 5: Boundary Defense
• Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs
• Critical Control 7: Application Software Security
• Critical Control 8: Controlled Use of Administrative Privileges
• Critical Control 9: Controlled Access Based on Need to Know
• Critical Control 10: Continuous Vulnerability Assessment and Remediation
• Critical Control 11: Account Monitoring and Control
• Critical Control 12: Malware Defenses
• Critical Control 13: Limitation and Control of Network Ports, Protocols, and Services
• Critical Control 14: Wireless Device Control
• Critical Control 15: Data Loss Prevention

Additional Security Controls

The following sections identify additional controls that are important but cannot be fully automatically or continuously monitored to the same degree as the controls covered earlier in this document.

• Critical Control 16: Secure Network Engineering
• Critical Control 17: Penetration Tests and Red Team Exercises
• Critical Control 18: Incident Response Capability
• Critical Control 19: Data Recovery Capability
• Critical Control 20: Security Skills Assessment and Appropriate Training to Fill Gaps