I am working on a series of posts related to the Center for Internet Security (CIS) Critical Security Controls (CSCs). See the full listing here.
Manage the security life cycle of all in-house developed and acquired software in order to prevent, detect, and correct security weaknesses.
This control includes eleven (11) sub controls. For those of you reviewing the CIS Controls with the Implementation Groups in mind, there are zero (0) IG1 controls and nine (11) IG2 controls. This means that, at a minimum, we want to…. skip this one? For the sake of discussion, I’ve listed out the IG2 controls.
- Establish secure coding practices appropriate to the programming language and development environment being used.
- 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.
- 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.
- Only use up-to-date and trusted third-party components for the software developed by the organization.
- Use only standardized, currently accepted, and extensively reviewed encryption algorithms.
- Ensure that all software development personnel receive training in writing secure code for their specific development environment and responsibilities.
- Apply static and dynamic analysis tools to verify that secure coding practices are being adhered to for internally developed software.
- Establish a process to accept and address reports of software vulnerabilities, including providing a means for external entities to contact your security group.
- Maintain separate environments for production and non-production systems. Developers should not have unmonitored access to production environments.
- Protect web applications 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 the traffic prior to analysis. If neither option is appropriate, a host-based web application firewall should be deployed.
- 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.
It is important to revisit the definitions of each IG to note why none of these controls apply to IG1 – most notably “off-the-shelf” software. These IG1 organizations are not writing their own code, so obviously none of these would apply.
Some of these controls are items I would consider foundational to any organization looking to develop their own software. Some of these examples being things like a formal SDLC document (18.1), making sure your developers receive secure code training (18.6), and having a process to triage and address vulnerabilities in your code (18.8). I would still consider many of these controls to be “high-level” in the sense that these will move you in a good direction, but these should not be considered the end-all be-all software development security controls. Any organization developing software should be looking at more granular control frameworks and security guidance, such as OWASP Top Ten or the OWASP Secure Coding Practices.
It is also worth noting that the Verizon Data Breach Investigation Report shows continued focus on web-application based attacks as a primary means of entry.
Relevant News Stories
|Commercial||Open-Source & “Freemium”|
|Application Security Manager (F5)||WebScarab|
The CIS Controls are in version 7.1 at the time of this writing. For more information on this control check out the CIS Control #18 page here.