Creating a Sustainable Red Team Program

Creating a Red Team program from the ground up is no easy task. It's even hard to keep it going.


Andrew Long

2 years ago | 5 min read

As I start this article, I’m not sure if I’m addressing the swamped security engineer trying their best to piece together a decent testing program, or the SOC chief working to refine their red teaming process. The more I think about it, the less it matters. I think that, no matter where you sit in the organization, this guide can help you.

This article shares the combined experience of many engineers. My own sweat, tears, and time have gone into learning a lot of these lessons, but just as valuable are the bits of advice I’ve gotten from other, more mature sources in this field. Let’s get into it!

Locking down your process

I don’t feel like I can ever stress this enough. I’ve written, at length, about creating your pentesting process, so I won’t go into the specifics of that here. What I want to explore are the overarching concepts you need to bake into whatever plan you go with.

What it all really boils down to is managing expectations, creating healthy relationships, and being reliable. You can probably take those three concepts and apply them to most parts of your career (or life) to great success. Let’s break these down into more concrete, actionable steps.

First up is documentation, the bane of every security engineer’s existence, or at least the lazy ones (aren’t we all a little lazy?). Documentation is a foolproof way to consistently manage the expectations of your team in the eyes of your organization. Most orgs are going to be much happier if the facets of your operation are properly documented.

There are a few documents every professional red team should have on the ready at all times:

Rules of Engagement - A boilerplate set of scope definitions that will dictate what can and cannot be tested, how it can be tested, and anything that is strictly off limits. This document will basically be a template you bring with you to the pre-engagement meeting, but it’s something that will mature with time as you begin to understand what should and should not be done.

It’s worth noting that this document can also serve as your license to operate, should someone try to accuse you of illegal activity. Some teams like to have an abridged version of this they can carry around (a “get out of jail free card”). It should be signed by a high ranking officer in your organization, as well as an officer from the department you are testing, if application.

Standard Operating Procedure - This is another living document. The SOP outlines how your team functions, the methodology you use to test, and what can be expected as a deliverable. When we talk about managing expectations through documentation, the SOP is at the heart of everything.

Your document should include a mission statement, any compliance requirements, tools your team uses, an explanation of your testing methodology (flowcharts work well for this), and an organizational structure for your team / department. Other sections like common terminology and a privacy policy are great additions.

Statement of Work - Much like the ROE, the SOW is a template you’ll use to define a particular engagement. Where the ROE mostly covers the scope and permissions of the engagement, the SOW gets into the specifics of the activities you are about to engage in for a particular office/team/department. You need to have a firm understanding of your team’s time and labor requirements. Being able to accurately predict that will come with time, and will allow your organization to rely on your abilities more and more.

Communication is the Real King

I look at communication as two things: a way to manage expectations (the necessary companion of proper documentation) and a way to build relationships. You could certainly make the argument that it plays a major role in the reliability of your team as well.

I could go on a two page rant about all of the benefits of proper communication, but you’re not here for relationship counseling. The big takeaway is that communication will help you avoid unwanted surprises while building a good rapport with your ‘test subjects’.

Often, the people you are affecting by performing pentests have no say in the matter, which usually puts you on uneasy footing from the start. I’ve seen this first hand dealing with development teams; you test their environment, applications, etc., and reveal vulnerabilities. The situation is immediately on the brink of a blame game, just because of the nature of it. You’re pointing out flaws in their work. It’s not fun for anyone.

So how do you avoid a situation devolving into fisticuffs? Well, first remember that you’re not the god of war coming down to destroy their defenses. You’re finding out how others might get in so you can teach your organization how to defend against it. Properly handing the emotional effect of an engagement can be a delicate process, but easier than you’d think. Here are some tips:

  • Identify stakeholders and make a point to keep them in the loop before, during, and after the engagement. This allows a feeling of security and control for them, as well as a sense of investment.
  • Do not treat vulnerabilities as the result of stupidity or negligence, they are mistakes that you are there to point out. Everyone makes mistakes.
  • Use each vulnerability as a learning experience for affected teams. Make it obvious that you are there to help them grow.
  • DON’T RUB IT IN THEIR FACE. I know, you’ll want to show them how cool it was when you totally owned their system, but they don’t need to know that. Stick to the facts, tell them the core issue and how to fix it.

The last thing I want to touch on here is probably one of the most influential methods to communicate your findings to stakeholders: thoughtfully prepared training. This is especially true with development teams. Using a major vulnerability as a teachable moment is much more effective than throwing it in their lap and walking away.

I’m not saying you have to do the job of fixing everything, that’s not typically the job of a pentester. What you need to do is tailor training based on what you find during your engagement. Teach people how not to make these mistakes. While you’re at it, illustrate how easy it is to make a mistake (literally everyone does as some point).

Old, Reliable You

Finally, let’s talk about how to ensure your organization can count on you. If you’re following the steps up until now, that’s a great start. But, it’s not enough to do well a couple of times. You have to develop a system that ensures you have repeatable results, or at least assists you in doing so. Sounds great, but what’s the secret?

Spoiler alert, there’s no secret recipe for reliability. Nothing beats work ethic and elbow grease. However, there are things you can do to put your team on the right path. I’m sure some, if not all, of these seem like common sense. Regardless, it never hurts to double check your process. Here are some key points I like to focus on:

  • Establish a testing cadence that works for teams affected by your work
  • Setup opportunities for continuous education for your team; sharp skills are the lifeblood of this industry
  • Ask for feedback from leadership, and follow through on it

Trust is an iterative process. Being great once or twice will get you some praise, but being consistent will earn the trust and respect of your organization. If you do drop the ball, understand that you still need to finish the game. Trust the process, get back on your feet, and try not to make the same mistake twice.


Created by

Andrew Long

Ethical hacker and IoT security specialist.







Related Articles