Growing up, I think every kid heard a parent or teacher or coach tell them to sit or stand up straight. At the time, it was never quite clear why good posture was so important at the dinner table, in the classroom, or on the field. However, as we grow up, the lesson is apparent: good posture helps us be more attentive, more respectful, and more able to react. Whenever I hear someone mention “security posture”, I always tend to think of sitting up just a little straighter. Unfortunately for information security organizations, assessing your security posture can be quite a bit more difficult than tightening a few muscles.
Confusing matters further is the types of security assessments available are varied and laden with infosec industry jargon.
Red team. Blue team. Purple(!) team. Pen test. Vuln scan. Black box. White box.
Assuming we can decipher the jargon, it can still be challenging to select the assessment(s) most suitable for your organization. With that in mind, let’s break down some of that jargon. For the purposes of this article, we’ll confine ourselves to network and application infrastructure. However, it should be noted that physical access and social engineering can expand this topic considerably, and can often be parts of each assessment discussed here.
Vulnerability Scan or Assessment:
This type of assessment includes a variety of levels of comprehensiveness. A good vulnerability assessment should cover the gamut from network layer to application layer, and shouldn’t be entirely automated if it’s meant to be valuable. Vulnerability analysis is also important in this context, since not all vulnerabilities are necessarily exploitable.
The goal of a quality vulnerability assessment is to determine the vulnerable attack surface of the infrastructure, and then prioritize these discoveries based on exploitability and potential damage due to a successful exploit. Think of the outcome here as a comprehensive inventory of the current security posture. A good vulnerability assessment will provide you a path toward better security, via remediation.
Penetration Test:
The phrase “pen test” is thrown around more than any other type of assessment, yet is often the least appropriate type of assessment. A penetration test is a great tool when there is some level of confidence that a strong security posture has been achieved by remediating the findings of a vulnerability assessment. A penetration test will employ both automated and manual attacks, and may include social engineering and/or physical security tests. The goal of a good penetration test is to determine if there are any exploitable paths into your infrastructure to gain privileged access or execute data theft. For this reason, CISO David Shaw says “pentests are great when you *think* you’re secure, or if you need ammunition to prove you aren’t (to build budget).”
A typical penetration test will have some fairly strict rules of engagement with respect to what is in scope, and what level of risks can be taken when testers attempt to gain access. These rules of engagement need close vetting from the legal team, and should be carefully reviewed by everyone. Or as Red Team Wrangler Ryan O’Horo tells us, “Disruption of business is always a risk, red team should mitigate those risks, and negotiate rules with the business.”
What penetration tests do not provide is a list of vulnerabilities. According to pen-tester Bill Sempf, “pen-testing just has to find one vuln, (vunerability assessment) has to find ALL the vulns.”
Red/Blue/Purple Team:
A Red Team can either be provided via outside consulting or by a dedicated internal team, and they are tasked with attacking your infrastructure. Sounds a little scary, and it should. A good red team should be exploiting any vector available to them: physical, digital, social. They should be working to simulate real adversaries to reveal how your internal teams would defend actual attacks. Red team activities should not only reveal exploitable paths, but also operational inefficiencies in how the internal security and IT teams react to attack scenarios.
The Blue Team is the polar opposite, tasked with defending the infrastructure and is most often staffed by internal employees. A formal blue team does more than simply go about their day job of enhancing organizational and infrastructure security. They are actively engaged with defensive activities and improving defensive security.
Red and Blue team activities are most fruitful when there is a defined Purple team. As you might have guessed, the Purple team is comprised of both Red and Blue team members, and is the way each team shares their findings and methods so that both attack and defense can enhance their capabilities for the next engagement. The level of information sharing during Purple team sessions is often governed by whether black box or white box methodologies are in play.
Black Box vs. White Box:
Black box or White box methodologies can be applied to any type of assessment, and refer simply to the amount of knowledge the vulnerability assessor/penetration tester/red team has about the target organization. In a black box scenario, the adversary has no knowledge of the infrastructure other than what is publicly available. Black box testing is useful for many because it closely simulates the most common type of attacker, and may be best for initial security assessments. In an ongoing relationship, such as Red/Blue team engagements, a white box approach may be most valuable since it enables the red team to model an attacker with inside knowledge such as a current or former employee.
Even vulnerability assessments can employ black box vs. white box methods. For example, in application or network security assessment, a black box scan would likely not include any credentials for logging into applications or network appliances. A white box scan would provide credentials, enabling deeper probing for potential vulnerabilities.
With the jargon deciphered, it now becomes much easier to seek out what is needed to improve security posture, based on the maturity of the organizational security practice. For those organizations just starting on the journey to better security, start with vulnerability assessments to obtain an inventory and list of priorities. Be advised, it will take more than one assessment to develop a level of confidence that a strong posture has been achieved.
Once achieved, the time comes to test that security posture with a penetration test, often provided by an outside consulting team. Be prepared, as multiple outside teams may need to be contracted to find a group who can evolve into a good working relationship as a Red Team. Obviously, a Red Team vs. Blue Team engagement should be treated as the next step beyond periodic penetration testing. According to Shaw, the thing to remember “with red team assessments is that they almost always win, but you get to really see how they (and you) would act.”
As the security practice matures, all of these assessment types will be used, and it’s important to keep in mind that security is a culture and mindset, not a destination. Applications and infrastructures change over time, closing some vulnerabilities and opening others. All the while, attackers and their methods are evolving, as well. By adopting the security-minded culture, and weaving it into process, organizations can become more successful at thwarting attacks and stop seeing security as a burden or obstacle to doing business.
As a Senior Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers and F5 product teams, providing a hands-on, real-world perspective. He is a regular contributor on InformationSecurityBuzz.com, a co-founder of BSidesNYC, and a speaker at AppSecUSA, BC Aware Day, GoSec Montreal, and the Central Ohio Infosec Summit, among others. Prior to joining F5 in 2008, McHenry, a self-described IT generalist, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.