Today, I will be going over Control 18 from version 7 of the CIS top 20 Critical Security Controls – Application Software Security. I will go through the eleven requirements and offer my thoughts on what I’ve found.
Key Takeaways for Control 18
- Understand your risk. The first great addition to control 18 is the requirement to run both static and dynamic code analysis utilities on in-house developed code. The second is creating the ability for vulnerabilities to be reported to the company, especially from outside parties. Both of these are going to uncover vulnerabilities to the business which previously may have remained hidden for long periods of time.
- Layered security is important. This is iterated over and over again in control 18. Starting with training developers on how to write secure code, testing the code they write, harden the environment around the code, then install security tools in front of the code. The goal is to have multiple security layers to stop an attack before it can start.
Requirement Listing for Control 18
1. Establish Secure Coding Practices
Description: Establish secure coding practices appropriate to the programming language and development environment being used.
Notes: The first step in writing secure code is following best practices. OWASP has a great cheat sheet for the secure software development life cycle. Additionally, developers can study for the ISC2 Certified Secure Software Lifecycle Professional (CSSLP) certification.
2. Ensure Explicit Error Checking is Performed for All In-house Developed Software
Description: 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.
Notes: Many common attacks against software come in the form of no sanitizing user input or not handling errors correctly. Both of these can have devastating effects on the security of the software and underlying operating system. Following section 7 lower down can help catch many of these if they are inadvertently left in the source code.
3. Verify That Acquired Software is Still Supported
Description: Verify that the version of all software acquired from outside your organization is still supported by the developer or appropriately hardened based on developer security recommendations.
Notes: This is the same as Control 2.2. Complex software used in enterprises is bound to have a vulnerability discovered sooner or later. Having software which is receiving security updates will ensure that your network isn’t unnecessarily left exposed. In some instances the business will require the use of unsupported software, such as Windows XP. If that’s the case, make sure you leverage compensating controls to limit the risk exposure to the business.
4. Only Use Up-to-date And Trusted Third-Party Components
Description: Only use up-to-date and trusted third-party components for the software developed by the organization.
Notes: It’s one thing to make sure the software is still supported; it’s entirely different to make sure that you actually install updates to that software. Similar to Control 3.5, you should install updates to supported software as soon as possible.
5. Use Only Standardized and Extensively Reviewed Encryption Algorithms
Description: Use only standardized and extensively reviewed encryption algorithms.
Notes: There are plenty of encryption algorithms which have been studied by mathematicians many times over. Creating a proprietary encryption algorithm is introducing unnecessary risk that sensitive data can be arbitrarily decrypted by any number of flaws in the algorithm or usage of the encryption.
6. Ensure Software Development Personnel are Trained in Secure Coding
Description: Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities.
Notes: It’s easier and cheaper to write secure code from the beginning rather than being notified of a vulnerability by QA or a customer. Training is essential in reducing the cost of finding and remediating vulnerabilities in source code.
7. Apply Static and Dynamic Code Analysis Tools
Description: Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software.
Notes: Because humans are fallible creatures, it’s important to test for mistakes that have been made. Both dynamic and static code analysis tools have their pros and cons. Research both to determine which may be right for your code.
8. Establish a Process to Accept and Address Reports of Software Vulnerabilities
Description: Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group.
Notes: You shouldn’t rely on your QA team finding all of your security vulnerabilities. Even if your organization does not write any application software, websites can be littered with security bugs that can open the door for attackers all over the world. Create, document, and publish how anyone can submit a security issue to your company.
9. Separate Production and Non-Production Systems
Description: Maintain separate environments for production and nonproduction systems. Developers should not have unmonitored access to production environments.
Notes: Ideally, the developers should write the code, QA should test the code, and operations should move the code into the production environment. In smaller organizations, anyone who has the ability to push code into production should have all of their actions monitored when doing so.
10. Deploy Web Application Firewalls (WAFs)
Description: Protect web application by deploying web application firewalls (WAFs) that inspect all traffic flowing to the web application for common web application 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 traffic prior to analysis. If neither option is appropriate, a host-based web application firewall should be deployed.
Notes: Deploying a web application firewall was consolidated from a handful of sections into a single section with version 7. The higher-level view eliminates the controls for specific vulnerabilities, opting instead for a broad stroke of protecting against attacks with a tool. WAFs can be incredible powerful to protect against the missed input sanitization bug a developer left in on a Friday afternoon.
11. Use Standard Hardening Configuration Templates for Databases
Description: 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.
Notes: As with Control 5, deploying hardening guides from either CIS or DISA against everything possible will help reduce the attack surface down as much as possible.
See how simple and effective security controls can create a framework that helps you protect your organization and data from known cyber attack vectors by downloading this guide here.
Read more about the 20 Critical Security Controls here:
Control 20 – Penetration Tests and Red Team Exercises
Control 19 – Incident Response and Management
Control 18 – Application Software Security
You can also learn more about the CIS security controls here.