Last updated at Tue, 27 Aug 2024 15:32:13 GMT

Toss some confetti in the air and bust out the bubbly—this is the final installment of our 20-part series on the CIS Critical Security Controls. This post will focus on Critical Control 20, penetration tests and Red Team exercises.

Think about your bank. The building was specifically designed with security in mind, with guards, vaults, safety deposit boxes, and locks keeping the bank’s goods safe from harm. Though all of these elements must be in place, they should be consistently evaluated and tested to ensure they still successfully keep malicious actors out.

The same principle applies to any security program. While you can define a defense in depth model and use people, processes, and technology to manage the tools, it’s important to not overlook safety checks. Protecting yourself from threats requires consistently asking yourself whether your security program is working as designed.

Enter CIS Critical Control 20

This is what Control 20 of the CIS Critical Security Controls aims to address. The overall strength of an organization’s defenses needs to be regularly and proactively tested by simulating the tactics and techniques used by modern adversaries. To accomplish this, organizations perform penetration tests (“pen tests”) and Red Team exercises as part of their security program.

What are pen tests, and how are they different from Red Team exercises?

A pen test is an authorized attack on an organization’s, technology, people, or facilities designed to evaluate the specific target’s security controls. These are typically focused on one specific environment or system, such as an internal network or web application.

In addition, Control 20 also touches on Red Team exercises. Let’s briefly discuss the differences between pen testing and Red Team exercises.

Penetration tests involve assessing the target using the tools and technique of an attacker. Once identified, those vulnerabilities are then exploited to determine what type of access an attacker can gain. The goal is often to find and chain as many vulnerabilities as possible within the scope of the test to determine the risk of each weakness.

Red Team exercises* are often confused with pen tests, but they are not the same thing. Red teaming is designed to improve the readiness of an organization by preparing the staff of the targeted organization for the eventuality of an attack and ensure the detection and response capabilities of an organization are adequate. The Red Team engages in a full-scope attack simulation, meaning that all techniques available are able to be used, with the goal of testing organizational security rather than that of an individual system or application. These engagements are goal-oriented and are conducted in a way that simulates the target organization’s most likely threat actor. The goal of these simulations is to discover shortcomings on policies, procedures, and technologies in order to improve the security of the entire organization.

*It is important to note that Red Team exercises are not ideal for every company, especially for organizations with a lower security maturity. Rapid7’s Advisory Services team can help assess and determine your company’s maturity level and help develop a plan to increase the overall effectiveness of your company’s security plan.

Planning for a pen test

Not all pen tests are created equal, so before you perform your own or engage with a third party such as Rapid7 to perform penetration testing services for you, it is important to develop clear goals. Ask yourself these questions before you engage in these activities:

  • Are you looking for just a network-based pen test that searches for OS and application-based vulnerabilities?
  • Do you want to evaluate your perimeter defenses (external pen test) or look at your internal defenses based on a presumed compromise (internal network pen test)?
  • Do you want to test employee security awareness through social engineering?
  • Do you want the pen test team to target a particular section of your network?
  • Do you need the team to exclude any systems from their tests?
  • Does your organization have many web-based services or applications that could benefit from a web app pen test?

Other considerations

So, let’s assume you’ve already decided to start performing pen tests as part of your organization’s security program and have defined clear goals. Here are some other areas to consider and how the additional sub-controls of Control 20 address these:

  • A pen test may require the use of a domain account or accounts that are used to perform some authenticated parts of the testing, such as in the case of a web application. This is normal practice. You’ll want to make sure accounts are removed or disabled once testing is over—or, at the very least, ensure any activity on those accounts is isolated to the testing windows.
  • Define the objective of the engagement. For example, consider having the tester look for sensitive internal information or personally identifiable information (PII), attempt to gain access to a specific system, or gain physical access to a sensitive office.
  • Leverage the results of the pen test in conjunction with vulnerability assessment results to determine how your vulnerability management program is working. Was a pen tester able to exploit a vulnerability you thought was already patched? There are many ways a pen test can help identify other programmatic deficiencies in your security program.

The final word

Many organizations fail to perform pen tests for many reasons, mainly out of fear of what the pen test will find and what shortcomings of the security program it will identify. However, it’s important to recognize that no security program is perfect and you are not alone in your concerns. It’s better for you to know and verify your weaknesses than to discover you were breached through an unpatched vulnerability that went unnoticed.

Rapid7 recommends that most organizations perform a pen test annually. Reach out and ask how we can help.