Notes from the Field: CIS Control 16 – Application Software Security 

by Greg Halpin / April 3rd, 2024

Recently, I’ve been working with a small Software as a Services (SaaS) company, and it quickly became clear they didn’t have much in place by way of security. They didn’t have a documented policy. They didn’t do code reviews. New code releases were deployed on the fly. They didn’t do secure scans of code or the web application. They didn’t have a web application firewall (WAF). The application database was hosted on the same server as the application server. There were a handful of developers who had many years of experience. They were supposedly knowledgeable in software development best practices and didn’t need what they considered rigid and unnecessary security controls. 
 
That’s when I discussed some basics around application security from CIS Control 16. As a reminder, the Center for Internet Security Controls are 18 critical information security controls that all organizations and information security professionals should be familiar with and implement to protect their networks and data. The document contains high level information that executives can understand and also has specific details about tools and procedures that technical staff to run with. I recommend it to all my clients for information security guidance.  

The Overview for Control 16 – Application Software Security is: Manage the security life cycle of in-house developed, hosted, or acquired software to prevent, detect, and remediate security weaknesses before they can impact the enterprise. 

Why is Application Software Security critical?  

Attackers can use a company’s own public-facing applications to bypass network security tools to compromise company and customer data. Attackers can also use applications to steal user credentials and install malware on user systems. Today’s applications are complex and are designed to be accessible from many different platforms, like web browsers, mobiles apps, and API calls. Development cycles are much more frequent than they used to be, as many as multiple times per day or week compared to a release once or twice a year. Additionally, developers use many open-source libraries that need to be updated. These elements make application security very challenging. That makes it imperative to implement and maintain proper security controls in support of in-house developed and off-the-shelf applications. 

Control 16 includes 14 sub-controls or safeguards: 

16.1 Establish and Maintain a Secure Application Development Process 

16.2 Establish and Maintain a Process to Accept and Address Software Vulnerabilities 
16.3 Perform Root Cause Analysis on Security Vulnerabilities Applications 
16.4 Establish and Manage an Inventory of Third-Party Software Components 
16.5 Use Up-to-Date and Trusted Third-Party Software Components 
16.6 Establish and Maintain a Severity Rating System and Process for Application Vulnerabilities 
16.7 Use Standard Hardening Configuration Templates for Application Infrastructure 
16.8 Separate Production and Non-Production Systems 
16.9 Train Developers in Application Security Concepts and Secure Coding 
16.10 Train Developers in Application Security Concepts and Secure Coding 
16.11 Leverage Vetted Modules or Services for Application Security Components 
16.12 Implement Code-Level Security Checks 
16.13 Conduct Application Penetration Testing 
16.14 Conduct Threat Modeling 

Let’s discuss some of the above controls.  

16.1 – Establish and Maintain a Secure Application Development Process  

Safeguard 16.1 lays the groundwork for the entire control and the safeguards that follow it. Document a policy and implement procedures at your organization that establishes development requirements, such as restricting access to code repositories; code reviews by a peer or a team lead before code advances in the code pipeline; DAST scans of code and libraries to identify vulnerabilities; and SAST scans of applications. QA testing and user acceptance testing should be defined. The document should also state how new versions of code are released. It is an automated process after code has passed a series of manual and automated testing or there is a team that must sign off on release of the new version. 

The security standard the company follows should also be listed, such as OWASP Top 10 with at least annual refresher training for developers on common application security concerns.  

16.10 – Apply Secure Design Principles in Application Architectures 

Safeguard 16.10 is so important to get right, as it’s difficult to correct if you get it wrong. It’s important to design your application and supporting infrastructure to minimize the attack surface. Some companies put their servers and databases directly on the internet facing the public. The companies I’ve worked with that do have good controls in place generally use Cloudflare’s DDOS and WAF protection to filter all traffic before it reaches AWS load balancers. This protects their systems, putting web, application, and other servers on private IPs that are not directly accessible to the internet. The company also benefits by freeing up resources instead of implementing complex and expensive security controls that they can obtain from Cloudflare or other vendors.  

16.12 – Implement Code Level Security Checks  

Companies with good development practices use code analysis tools such as BurpSuite, Brakeman, Qualysis, and SonarQube to name a few. There are many different tools for specific programming languages. Some of these can be used for DAST scanning of the actual application. In any event, it’s necessary to use such tools to find vulnerabilities in your own code, the libraries your code is built upon, and at the application level.  

Control 16.13 – Conduct Application Penetration Testing  

Safeguard 16.13 helps identify vulnerabilities in your applications that could not be identified using automated tools. If your organization does not have internal resources that can perform a pen test, engage a security firm to do so. First, make sure you know in advance what your chosen firm’s pen test entails. Clients unfamiliar with pen tests have shown me reports that were basically vulnerability scans with some narrative details about the scope added. No actual manual testing by a skilled offensive security professional was performed. Not to mention, they paid a lot of money for a vulnerability scan.  

Ask to see a sample report before deciding on a company. If they decline to provide one, that’s a red flag and you should move on until you find a pen test firm you are confident will conduct a detailed scan. A thorough pen test will include a discussion with your team and the pen testers about your environment. The report should include actionable recommendations to better secure your application and environment.  

Partner with KirkpatrickPrice to Improve You Application Software Security 

Implementing the guidance from CIS Control 16 will go a long way to protecting your company’s in-house and third-party applications as well as your company and customer data. We hope this overview of CIS Control 16 provided guidance on how you can follow application security best practices, but if you have questions about your organization’s specific environment or would like to discuss our penetration testing services, connect with one of our experts today.  

About the Author

Greg Halpin

Greg Halpin has 25 years of experience in information technology and security. He has a Master’s in Information Sciences – Cybersecurity and Information Assurance from Penn State University, and he has earned the CISSP, CISA, and CCSP certifications. He has experience and additional

certifications in Amazon Web Services, Azure Cloud Services, Linux and Windows systems administration, vulnerability scanning, intrusion detection/prevention, and project management. He enjoys working with people and organizations to help them secure their networks and systems.