Notes from the Field - CIS Control 16 - Application Software Security

Working recently with a small Software as a Services (SaaS) company, 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 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. 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. 

Warning Sign at Colyer Lake in Central PA

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 this control 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 - web browsers, mobiles apps, API calls. Development cycles are much more frequent than they used to be, as much 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. They are:

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. The very first one, Control 16.1 - Establish and Maintain a Secure Application Development Process 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; 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 is there 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. 

Control 16.10 - Apply Secure Design Principles in Application Architectures 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, 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. 

For Control 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 - 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 you will receive from the firm as to what their 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. And 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. 

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. 

In the next post, I discuss CIS Control 17 - Incident Response Management.