CIS Critical Security Control 18: Breaking Down the Control Chaos of Application Software Security

Last updated at Tue, 09 May 2023 21:15:43 GMT

We’re nearing the end of our discussion on the CIS Critical Security Controls, with only three left in the series. This particular post will focus on Critical Control 18, application software security.

It can be easy to feel overwhelmed by Critical Control 18 due to the sheer size of the concept. Hear “application software security,” and your mind starts to conjure up images of waterfalls, SCRUM masters leading the party into the next dungeon meeting, and a security guy with an expression that’s usually followed by the word, “No.”

Though it can be tough to disentangle yourself from the negative imagery that accompanies application software security, give it a try. When upheld, this control can be the genie that makes your SDLC wishes and SecOps dreams come true.

Related: Want to learn more about SecOps? Get started here.

Which Controls Does Application Software Security Cover?

The list could cause anyone to let out a nervous laugh or even a sigh, but the truth is that most of my clients (even the ones that are lower on the maturity scale) have at least some components of the control already in place.

These sub-controls include the following:

1. Ensure all versions of third-party software are still being supported by the vendor, and either update or retire versions that are not.
2. Deploy a web application firewall (WAF) to inspect traffic for known web application vulnerabilities, such as SQL injections (SQLi), cross-site scripting (XSS) or request forgery, etc. For applications that are not web-based, ensure there is an application firewall in place that can decrypt traffic prior to analysis. If the traffic is encrypted, the device should either sit behind the encryption or be able to decrypt traffic. If neither seems to be appropriate in your environment, consider a host-based web application firewall.
3. Perform explicit error checking for internally developed applications, and document all input, including size, data type, and acceptable ranges or formats.
4. Use a web application scanner to test software developed internally or by a third party prior to deploying to production, after any major changes, and on a regular basis (at least once a month is preferred).
5. Perform output sanitization by ensuring users cannot see system error messages.
6. Maintain separate environments for production and development, ensuring proper segregation duties are in place.
7. Use standard hardening configuration templates (CIS, USGCB, DISA, STIGS, etc.) when using a database on the backend of applications.
8. Provide software development personnel with security awareness training on a regular basis.
9. Ensure internally developed applications have all artifacts (such as test data and scripts, tools, and debugged code) removed prior to deploying to production or are accessible in the production environment.

Now that you have an idea of which components you should have in place, let’s take a look at the process of implementing these controls, keeping in mind that it will look very similar across companies of various sizes and industries.

Step 1: Foster a Relationship with Your Application Development and Procurement Groups

A lot of problems I see when going out to a client site stem from security trying to operate in a vacuum and/or trying to control what other groups within IT do. Neither of those things are beneficial for a robust security organization, nor are they sustainable in the long run if you want buy-in from management or other teams.

At the very least, security should aim to foster communication with teams such as development, change management, and project management—though the best-case scenario would be establishing an ongoing relationship with them. Rather than dictating the rules to other teams, security practitioners should help enable them to do their jobs in as secure a fashion as possible without negatively affecting the business.

Cool story, bro, but how do we do this?

Before taking the list of controls and hitting other teams upside the head with it, have a series of meetings with stakeholders. The objective of these meetings should be to obtain a clear understanding of how the SDLC currently works, any pain points that could be addressed by the security team, and regulatory and compliance requirements that are already being addressed (spoiler alert, there’s overlap between the controls outlined by the CIS and software development standards outlined by compliance requirements such as in the Payment Card Industry Data Security Standard (PCI DSS).

Once you have the meetings and a solid understanding of the current state of things, you can move on to the next phase.

Step 2: Implement Security Gates to Address the Controls Instead of Having a Pass/Fail at the End of the Software Development Lifecycle

Something I have come across quite often when working with companies that have a seemingly solid SDLC is that they wait to do all of their security checks at the end. However, by incorporating several control gates—places between SDLC phases that are held for security—organizations can save a lot of time, money, and rework.

Related: [VIDEO] How to Drive Application Security Earlier in the Software Development Lifecycle

For example, security practitioners can work with the business in the design and requirements-gathering phase to determine whether there is a security requirement in the first place, then follow it up with which control gates should be incorporated and at what stage of the project.

Let’s say that an organization is making a minor change to an existing piece of software that was developed in-house. Does it make sense to perform a full-blown penetration test or have security sign off on it prior to release? Maybe not. But what if you’re migrating from an outdated version of your database in order to be in line with the first control? All of a sudden, you need to:

• Talk about what industry-standard best practices are for hardening the new version of the database (sub-control 7)
• Ensure developers are trained (sub-control 8) to perform the explicit error checking and sanitation (sub-controls 3 and 5) during the development and QA phases
• Perform a scan of the application using tools you have in place for web- or non-web-facing applications (sub-control 4)
• Ensure pre-production data isn’t being migrated into production (sub-control 9), since you’re using environments that are at least logically separated (sub-control 6)

Step 3: Ensure You Have the Proper People and Tools in Place

I put this step at the end, although in all honesty, it should be an ongoing part of having an internal development function. It is easy (and normal, even) to be hypersensitive to all of the security requirements and controls your organization has to stay on top of—and easy to forget that they usually aren't a top concern for the rest of the business (or even the general IT org).

There are several things you can do to make sure development personnel have appropriate training on security best practices without starting a shouting match over whose budget it will come out of.

When you’re meeting with other stakeholders as part of the first step, try to identify at least one person in each meeting who either shows enough interest to be a security advocate themselves or knows someone on their team who can step up to the plate. From there, training can be as simple as sending them online training videos and materials, hosting lunch and learns with the advocates and the security team, attending meetings held by local Open Web Application Security Project (OWASP) chapters, or even sending them to security-specific training for their role if there is time, interest, and budget.

Finally, there are tools that can (and should) be considered to help ease the burden of trying to implement security controls around your SDLC. Sub-control 1 specifies needing a WAF (essentially an application firewall that is designed for web-facing applications), application firewalls for non-web-facing applications, and even host-based web application firewalls, as mentioned earlier.

Implementing security control gates within your current SDLC process or building it into a new process does not have to be a daunting task. Just remember to break it up into smaller chunks throughout the process, rather than waiting until the end.

Like what you see? Check out our next post in this series, “CIS Critical Security Control 19: Steps for Crafting an Efficient Incident Response and Management Strategy.”