Application Software Security
Manage the security lifecycle of all in-house developed and acquired software in order to prevent, detect, and correct security weaknesses.
Why Is This Control Critical?
Attacks often take advantage of vulnerabilities found in web-based and other application software. Vulnerabilities can be present for many reasons, including coding mistakes, logic errors, incomplete requirements, and failure to test for unusual or unexpected conditions. Examples of specific errors include: the failure to check the size of user input; failure to filter out unneeded but potentially malicious character sequences from input streams; failure to initialize and clear variables; and poor memory management allowing flaws in one part of the software to affect unrelated (and more security critical) portions. There is a flood of public and private information about such vulnerabilities available to attackers and defenders alike, as well as a robust marketplace for tools and techniques to allow "weaponization" of vulnerabilities into exploits. Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, cross-site scripting, cross-site request forgery, and click-jacking of code to gain control over vulnerable machines. In one attack, 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.
How to Implement This Control
|CSC 6-1 (NEW)||For all acquired application software, check that the version you are using is still supported by the vendor. If not, update to the most current version and install all relevant patches and vendor security recommendations.||Quick Win|
|CSC 6-2||Protect web applications by deploying web application firewalls (WAFs) 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, specific application firewalls should be deployed if such tools are available for the given application type. If the traffic is encrypted, the device should either sit behind the encryption or be capable of decrypting the traffic prior to analysis. If neither option is appropriate, a host-based web application firewall should be deployed.||Quick Win|
|CSC 6-3||For in-house developed software, ensure that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats.||Visibility/Attribution|
|CSC 6-4||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. Include tests for application behavior under denial-of-service or resource exhaustion attacks.||Visibility/Attribution|
|CSC 6-5||Do not display system error messages to end-users (output sanitization).||Visibility/Attribution|
|CSC 6-6||Maintain separate environments for production and nonproduction systems. Developers should not typically have unmonitored access to production environments.||Visibility/Attribution|
|CSC 6-7||Test in-house-developed web and other application software for coding errors and potential vulnerabilities prior to deployment using automated static code analysis software, as well as manual testing and inspection. In particular, input validation and output encoding routines of application software should be reviewed and tested.||Configuration/Hygiene|
|CSC 6-8 (NEW)||For acquired application software, examine the product security process of the vendor (history of vulnerabilities, customer notification, patching/remediation) as part of the overall enterprise risk management process.||Configuration/Hygiene|
|CSC 6-9||For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.||Configuration/Hygiene|
|CSC 6-10||Ensure that all software development personnel receive training in writing secure code for their specific development environment.||Configuration/Hygiene|
|CSC 6-11||For in-house developed applications, ensure that development artifacts (sample data and scripts; unused libraries, components, debug code; or tools) are not included in the deployed software, or accessible in the production environment.||Configuration/Hygiene|
CSC 6 Procedures and Tools
The security of applications (in-house developed or acquired) is a complex activity requiring a complete program encompassing enterprise-wide policy, technology, and the role of people. These are often broadly defined or required by formal Risk Management Frameworks and processes.
A comprehensive treatment of this topic is beyond the scope of the Critical Security Controls. However, the actions in CSC 6 provide specific, high-priority steps that can improve Application Software Security. In addition, we recommend use of the many excellent comprehensive resources dedicated to this topic. Examples include: the DHS "Build Security In" Program, and The Open Web Application Security Project (OWASP).
CSC 6 Effectiveness Metrics
In order to test the effectiveness of the automated implementation of this control, organizations should measure the following:
1. Can the application system detect attacks & block them within 24 hours of being detected (yes or no)?
2. Are all Internet facing applications scanned by web application vulnerability scanners at least weekly (yes or no)?
3. How long does it take for alerts to be generated & sent to system administrators that a vulnerability scan has or has not completed (time in minutes)?
4. Are all vulnerabilities detected by the scanning tools fixed or remediated within 15 days of detection (yes or no)?
CSC 6 Automation Metrics
In order to automate the collection of relevant data from these systems, organizations should gather the following information with automated technical sensors:
1. What percentage of the organization's custom applications have not been recently scanned by an application security code scanner (by business unit)?
2. What percentage of the organization's database systems have not been recently scanned by a database specific vulnerability scanner (by business unit)?
3. What is the aggregate vulnerability rating for all application and database system in the organization (by business unit)?
CSC 6 Effectiveness Test
To evaluate the implementation of Control 6 on a monthly basis, an evaluation team must use a web application vulnerability scanner to test for each relevant type of flaw identified in the regularly updated list of the "25 Most Dangerous Programming Errors" by MITRE and the SANS Institute. 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 that 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 what happened. 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 finish.
CSC 6 System Entity Relationship Diagram
Organizations will find that by diagramming the entities necessary to fully meet the goals defined in this control, it will be easier to identify how to implement them, test the controls, and identify where potential failures in the system might occur.
A control system is a device or set of devices used to manage, command, direct, or regulate the behavior of other devices or systems. In this case, we are examining the process of monitoring applications and using tools that enforce a security style when developing applications.
The following list of the steps in the above diagram shows how the entities work together to meet the business goal defined in this control. The list also delineates each of the process steps in order to help identify potential failure points in the overall control.
Step 1: Web application firewalls protect connections to internal web applications
Step 2: Software applications securely connect to database systems
Step 3: Code analysis and vulnerability scanning tools scan application systems and database systems.
Critical Security Controls - Version 5
- 1: Inventory of Authorized and Unauthorized Devices
- 2: Inventory of Authorized and Unauthorized Software
- 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
- 4: Continuous Vulnerability Assessment and Remediation
- 5: Malware Defenses
- 6: Application Software Security
- 7: Wireless Access Control
- 8: Data Recovery Capability
- 9: Security Skills Assessment and Appropriate Training to Fill Gaps
- 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
- 11: Limitation and Control of Network Ports, Protocols, and Services
- 12: Controlled Use of Administrative Privileges
- 13: Boundary Defense
- 14: Maintenance, Monitoring, and Analysis of Audit Logs
- 15: Controlled Access Based on the Need to Know
- 16: Account Monitoring and Control
- 17: Data Protection
- 18: Incident Response and Management
- 19: Secure Network Engineering
- 20: Penetration Tests and Red Team Exercises
This work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
To further clarify the Creative Commons license related to the 20 Critical Controls content, (i) All persons are authorized to use the content as a framework in their organization or to sell professional services related to the content (e.g. a consulting engagement to implement the 20 Critical Controls), and (ii) sale of the contents as a framework model is not authorized. Users of the 20 Critical Controls framework are also required to refer to http://www.sans.org/critical-security-controls/ when referring to the 20 Critical Controls in order to ensure that users are employing the most up to date guidance.
You may use the following code to embed the 20 Critical Controls on your site:
<iframe src="http://www.sans.org/critical-security-controls/" width="1000" height="1200" />