As the security industry continues to progress, companies are focusing on their own security programs, trying to figure out what works and what doesn't. One of the areas of focus that goes to the early days of the security industry is penetration testing. Penetration testing has always been a validation method to identify exposures and help prioritize what needs to be addressed from an exposure standpoint. There are other pieces of supplemental data that come out of these types of assessments, including strategic planning on areas of weakness from the security program perspective and around enhancing monitoring and detection practices. Over the years, penetration testing hasn't necessarily kept up with evolutions in corporate maturity models.

Some companies are in a position to focus red team simulations on the betterment of the organization, validation of existing controls, and finding ways to continuously test and improve. Penetration testing, however, has become standardized across the industry in a number of ways. At TrustedSec, we still see vulnerability scanning used as a substitute for a penetration test. This is not an ideal method, especially when companies have the option of selecting good vendors and people with solid resources at their disposal for a better test. The major problem we see is that not every penetration test is after the same sets of vulnerabilities and the objectives tend to change as the organization's maturity develops.

Penetration testing is an evolving concept and companies are continuously improving from a security perspective. With that said, there are several questions that will need to be answered before determining what kind of testing is needed for an organization. Is the penetration test for compliance? Is it to test Endpoint Detection and Response (EDR) products? Is it to test monitoring and detection capabilities? Figuring out the organization's maturity level and objectives of the engagement, as well as determining the best middle ground before going full adversarial simulation, is important. Often, the client may not know the answers to the above questions, and there will need to be an understanding of where the organization's maturity level is first, before a penetration test is performed.

Scoping an organization's maturity level can be difficult, especially for developing security programs, but it's something that will make outcomes and deliverables that much more valuable. Most organizations that focus on compliance should start off with a "traditional" penetration test. After the initial penetration test, the organization can shift and focus more from an assumed breach position to enhance not only the initial exploitation vectors from a criticality perspective, but to determine next steps after an attacker has compromised the organization.

An assumed breach scenario begins with a machine equipped with a full security stack and plays out attempts to circumvent and gain access to other resources and objectives within the organization. Compared to a standard Internal Penetration Test that revolves around inserting a machine into the network side stepping the endpoint controls and focuses on identifying exposures internally.  An assumed breach on the other hand focuses on understanding the full endpoint security stack and the controls in place to limit post exploitation scenarios once initial access has been granted by the attacker.

What steps should be taken after a successful attack? Can we prevent or detect attacks to eliminate the amount of time an attacker has on the network? Simple tweaks to an engagement's goals can help prioritize an organization's security program, assist in formulating a response to an attack, and even elevate an organization's preparations for attack scenarios.

I was just discussing this topic with Justin Elze, the Practice Lead for our red team, research, and defense and counter measures groups. We are fortunate to have a ton of repeat clients that trust us to do high-end assessments for them each and every year. For those clients, it becomes increasingly more difficult for us to gain access into their systems, which is a good sign that the partnership is working as anticipated. In terms of traditional penetration testing, timing can become a challenge, for example when a customer needs to test monitoring and detection capabilities, or circumvention of specific pieces of technology.

 An assessment that would normally only take a week, as in the case of an immature security program, might take considerably longer or require more effort for an organization with a fully realized security program. As organizations grow and develop their security programs, penetration testers have to find new methods of access. At this point, moving to a red team engagement may make more sense, but there is a lot of middle ground with regard to objectives, and some elements of program development may still need to be worked out.

For organizations looking to have a penetration test performed, and for the organization that is performing the penetration test, it is important to recognize where the organization is in the journey of their information security program as well as their ultimate objectives. An organization may not know the value of a penetration test, so the process of challenging, validation, and growing the security program may need to be part of the conversation. The goal is to work together, share in our learning, and make sure that, as an industry, we can shift methodologies for defense and remain relevant in reducing the risks associated with attackers. To accomplish these goals, we must understand that security programs are constantly evolving, and we must be willing to evolve with them.