As we continue to build our security teams at JupiterOne, we asked Kenneth Kaye, Security Automation Architect, to describe our Red Team approach, and Chasen Bettinger, Senior Security Automation Engineer, to talk about our Blue Team.
About the Red Team
To begin, there are a few types of commonly-recognized assessments that Red Teams perform such as "black-box", "white-box", and various shades of "grey-box" along with whether the assessment is more general or more targeted to various degrees. One of the most significant differentiators between the various "-box" assessments is the degree of knowledge that is provided to the Red Team ahead of their assessment. In my experience it's almost always more valuable to give your Red Team (whether internal to your organization or not) as much information as you can to get the best results possible. However, there are scenarios where less information can provide different value for your organization.
At this point, it may be useful to view the free webinar, "Pair Cyber Asset Visibility with Pentesting to Fight the Clock Against Hackers" between Cobalt.io and JupiterOne on the time inequality between attackers and defenders to provide some context for this ongoing discussion of the best ways to utilize this type of service/function.
The Red Team Means "Offense"
Red Teams get their name from the offensive versus defensive operations security teams can conduct (blue being defensive and red being offensive), and as such are intended to emulate the actions an actual malicious agent might take when attempting to compromise infrastructure, services, accounts, or information. As mentioned in the webinar, frequently companies are focused primarily on their perimeter security to "keep the bad actors out" as opposed to ensuring they are secure at every level (an approach known as defense-in-depth, which is an industry best-practice).
However, frequently if you can prove that an attacker can't penetrate your perimeter, many leadership teams will decide their investment to risk management ratio is good enough and call it a day.
The Business Case for Your Red Team
But what if you could get more value out of your Red Team? Part of the problem is that people (not just leadership) are hesitant to give the "keys to the kingdom" to people whose job is to attack your infrastructure and compromise it. There's a background of inherent lack of trust for people that regularly and effectively compromise your company's security, and the idea is by denying them such useful information you're more accurately portraying the perspective of the external attacker.
The inequality of time discussed in the webinar linked above disproves this paradigm though. A determined attacker has all the time in the world to dive into any minor aspect of your perimeter to find a way through, and depending on their skill level, nearly infinite time once they're inside your perimeter to continue compromising your organization. Attackers can, and will, spend months researching a technological standard and how it was implemented by whatever vendor you're using to find flaws in either the implementation or the standard. They can then spend as much time as necessary to figure out how to exploit that and take advantage of it in ways that you'd never thought possible, and therefore couldn't possibly create monitoring and/or detection for.
On the other hand, Red Team engagements are normally scoped to a certain time period. Red Teams have a week, or two, or one month to determine the security of their target whether it is a specific application, or an organization's perimeter. This is where the value of complete knowledge of your environment really comes into play - in order to accurately simulate the actions and knowledge of an attacker, you have to assume they know all the obscured security tricks and configurations. By providing your Red Team with as much information as possible, you emulate those months of research the malicious actors put into researching your infrastructure and environment.
In addition to providing a more accurate assessment of an attacker's capabilities with respect to your perimeter security, that knowledge also enables your Red Team to perform further analysis on "what if" scenarios related to perimeter compromise. They can emulate attacker lateral movements, check for misconfigured service interactions, and validate that your internal security controls perform effectively and provide value. These are things that are nearly impossible to perform with "black-box" testing, because the Red Team uses all their time and resources testing the perimeter only.
Empower Your Red Team
You can get much more value from your Red Team by providing them with all the information they could ever need. This can be a daunting task, however, given that (especially for cloud-native companies) the necessary information may be scattered in literally thousands of locations. But a solution like JupiterOne is design-built to gather all that information into one place and make it easy to find answers to questions via the graph nature of the underlying database.
Give your Red Teams access to your infrastructure information using JupiterOne and sit back to watch the fireworks. You will get the best, most effective, and most valuable assessment of your environment - both internal and external - that you've ever had. Then you can prioritize which items need to be addressed (if any) and in what order to mitigate the most risk the most quickly and with the least cost.
That's just smart business.
Chasen will describe our Blue Team approach in an upcoming article. To be notified, sign up for the newsletter.