Security engineers who possess red team skillsets are the most powerful offensive weapon toward uncovering risk across an organization — but they must also know the technology basics in order to be most effective.
A dedicated group that assess security methodologies through adversarial simulation is commonly referred to as a “red team.” These exercises are a hallmark of the information security lifecycle due to their ability to identify systemic risk that had not been taken into account. This model provides incredibly valuable insights to security teams. From testing security controls to assessing the human element, the ethos of a red team embodies reflection, awareness, and a constant determination to disprove assertion through real world action.
In security, we use the Johari Window to analyze the delta between our systems defenses and from what we’re defending our systems. By bucketing threats in this way, we gain better understanding of our weaknesses, which ultimately make us safer and more secure.
The most difficult quadrant to defend against is the “blind spot.” In the last few years, we’ve witnessed some of the world’s largest organizations become compromised in overwhelming fashion. In 2010, a high-security French bank was breached by unknown attackers in ways the bank had previously considered impossible. This is just one of several examples where the cunning criminal drastically outsmarted well-funded, and frankly overly confident, defenses.
So, how can companies develop defenses for complex risk that, by definition, they have no awareness?
Enter the world of the red team.
A red team’s mission is to simulate threats to identify previously unknown and unmitigated risk. Through a unique blend of adversarial engineering and standard penetration testing methodologies, red team exercises are meant to challenge your organization’s belief in the strength of their security. By emulating a wide array of threat actors, red teams bring perspective uniquely suited to the iterative development models commonly practiced in information security programs.
As my career has progressed, I’ve developed a firm belief that security engineering candidates should possess red team skillsets. It’s often, and truly, said that the best defender is also the best attacker. We live in a world where nerds are attempting to outsmart criminals — being able to embody an attacker’s mindset is a top priority. Even if your organization doesn’t have an official red team, your security engineering team will be much more effective and strategic if required to hone red team skillsets. Following the practice of screening candidates for these skillsets will help you develop a stronger team that will uncover issues at a reliable pace.
One caveat: your work will include much more than red teaming. Eventually, you’ll have engineers scattered across your security organization with a fantastic ability to uncover risk. Some of them might be building logging pipelines, while others are doing forensics. Fortunately, there are amazing opportunities that enable your team to continue to sharpen their skills.
One of the pinnacle events for me is the annual Collegiate Cyber Defense Competition (CCDC). CCDC is a purely defensive security competition designed to measure college students’ abilities to protect and secure information systems. During the event, competing teams of eight students, known as a blue team, are placed in identical enterprise-grade networks that are configured to emulate a real company. The student teams must then race against the clock to secure the systems and maintain the integrity of the services they provide.
In order to make this work, the competition recruits a singular red team to emulate real world threats. The red team will measure the effectiveness of both the competitors’ security methodologies, as well as conduct gap analysis to identify vulnerabilities the students have missed. These are documented and factored heavily into the overall score and outcome of the competition.
CCDC is nationwide, with everything from state-level competitions to the national championship hosted by the Center for Information Assurance and Security. They employ several full-time staff to design and architect the complex infrastructure required for the event. Last weekend was my sixth time red teaming the National Championship. I’ve used this opportunity over the years to improve my capabilities, regardless of my day job. While the blue teams spend the months leading up to the competition practicing security hardening and vulnerability management, I take the opportunity to improve my skills by studying cutting edge offensive security techniques. These skills are invaluable, for both the competition and my day job.
One of the questions I am asked the most is, “How do I get into red teaming?” or “How do I become red team?” Red teaming has such broad appeal in our industry, and it’s a hotter topic than ever right now. It’s also a bit taboo because, after all, you are breaking rules to expose flaws, so people are even more drawn to it. Attacks are often mystifying because, as stated previously, the unknown unknown will leave the mind wandering, attempting to uncover the methods.
Thusly, I’ve started tweaking my response to that question. One of the most common mores I witness is how worshipped offensive security is by a large segment of our community. With hacker culture moving from underground to mainstream populism in society, the security community has evolved into a global industry. This has shifted the power of balance in a number of ways. The Pareto Principle is stretched incredibly thin, with the vast majority consuming tools and software produced by a small but growing group. This phenomena leads to misconceptions about what is really involved in participating in a red team.
As valuable as it is to able to channel the attacker’s mindset, it is incredibly beneficial to be able to develop your tools. No effective outcome has ever occurred from leveraging only offensive tactics before developing more basic, albeit seemingly mundane in comparison, skillsets. Writing effective software takes both strong muscle memory and lots of practice. Learn to embrace the less glamorous, often overlooked skills. Developing software engineering skillsets, including a deep knowledge of computer systems, libraries, and protocols will act as a force multiplier in your security career.
I’d also strongly encourage people with those questions to really understand the effort that goes into red teaming. Dave Cowen, our NCCDC red team captain, and I were chatting after the competition and talked about the traits that really make a strong red teamer. These are the four:
Knowledge – Possess a broad understanding of the systems and technology you’re attempting to circumvent. This is where I strongly encourage folks to study and read about emerging technology. The more you’re familiar with databases and web servers and routers, the better you’ll be able to understand their weaknesses.
Methodology – Adhere to a methodology that best sets you up for success. Red teaming can be frustrating and if you abandon your principles, you’re going to end up down the wrong rabbit hole with nothing to show for it.
Agility – Adapt to chaos. In the real world, things change for thousands of reasons. It’s not your job to figure out why, it’s your job to adapt and continue moving forward.
Grit – Persevere. I can say first-hand the difference between success and failure can be measured in grit. Though last on the list, this is most important.
For example, when I was at Lares, I learned so much from Chris and Eric. The most valuable lesson of all was learning to stand up to adversity and see the job through. I’ve never met a more determined group of individuals and the results speak for themselves. Again, at Western Regionals, while everyone was hunting vulnerabilities, I sat and made wordlists by hand. I scraped IMDB for potential usernames. I used awk and sed to generate the wordlists. I narrowed a password list down. Miraculously, one of them worked. It was the much-needed entry point to our first shell of the competition. It wasn’t pretty, it wasn’t glamorous — but it got the job done by the force of sheer will.
I want to see more companies embrace the practice of red teaming as one of learning and self assessment. I want to see our community stop glorifying red teaming as the end all, be all. We only cover one quadrant of that Johari Window. There are three times the amount of work needed to cover the other three. Don’t follow the crowd, be yourself. The required grit I wrote about above will show success in any career path you take. I promise.
I’m working on a more detailed, technical post about the infrastructure tech we built for red team this year. You probably saw in Dave’s NCCDC debrief about our infrastructure and were wondering “WTF?” I’ll try and answer your burning questions in that post set to come out in the next week or so.
Cheers!
Alex
Alex Levinson 