to also give credit where credit is due.
If you were to switch to the blue team, what would be your first step to better defend against attacks?
Prevention is preferred, but detection is a must. My first step would be to understand what data sources were available and make sure they were accessible to defenders. Many defenders have complained of data overload, but almost every engagement I’ve ever been part of had shown some kind of blind spot. The more data available to automation and manual queries, the more likely an attack will be detected.
What is some practical advice on writing a good report?
Stick to the facts, and paint the picture of the attack path. Don’t use jargon, and provide references to CVEs or technical guides wherever possible. The report is the product you are providing; it is what the customer is paying for. Nothing else matters, so get this right every time. If there are follow-up questions, answer them promptly and accurately and make note of them for your next report.
How do you ensure your program results are valuable to people who need a full narrative and context?
This will vary with each organization, but a good way to start is to identify who the red team’s true customers are. Customers are different than stakeholders, and this differentiation becomes important when trying to prioritize engagements and reports.
Once the true customers and stakeholders are identified, red team leadership should begin to tailor their communications to those individuals. Reports should be at the correct level of detail and clearly answer the inevitable “so what?” question before it is even asked. This requires learning the business and understanding how the technology your team has just assessed fits into those processes (and therefore the impact of your team’s actions on the business as a whole). The business is the ultimate customer, and the business does not exist solely to run a CIRT (or a red team).
How do you recommend security improvements other than pointing out where it’s insufficient?
Red teams are often asked for recommendations for security improvements, but frustratingly, the answer is almost always “it depends.” Red teams provide a snapshot-in-time look at an environment. Red teams likely have no idea why the environment looks the way it does, but almost certainly there were decisions made at some point, for some business reason, to design and build the environment in that particular way. One way to take this into account is for the red team to sit down with the teams responsible for implementing fixes and walk through the attack path from start to finish.
This helps the network owners get a peek into the mind of the attacker, and it helps the red team understand what challenges the network owners face. Then, potential mitigations can be brainstormed and table-topped at that moment, resulting in quality recommendations that can actually be implemented. The red team can even come back at a later date and retest the environment to see whether the recommended fixes are performing as intended.
What nontechnical skills or attitudes do you look for when recruiting and interviewing red team members?
When I am talking to candidates, I am looking for positive attitudes and strong internal drive/motivation. Red teamers will often find themselves neck-deep in mind-numbing analysis, the results of which could determine the success of the engagement.
Therefore, it is important that candidates are able to motivate themselves to keep going, not lose sight of the objective, and not complain that they’re “not doing cool stuff.” Red team work is usually pretty boring, minus the moments of sheer adrenaline when that shell finally comes back, so candidates need to give the impression that they have the patience and determination to accomplish the mission.
What differentiates good red teamers from the pack as far as approaching a problem differently?
Good red teamers are able to think, plan, and act like an attacker. This ability is often referred to as the attacker mind-set, but it’s more of a lifestyle than something that can just be turned on or off as needed. For example, once a good red teamer has been trained and has conducted physical engagements, that red teamer will habitually and unconsciously “case” every building they enter. They will automatically make note of the position and angle of cameras, security personnel, type and condition of locks on doors and windows, and so on, all without thinking about it. The same is true for red teamers on the keyboard: they will develop an innate ability to “feel” vulnerabilities and intuitively understand not only how to exploit them but whether they should exploit them in furtherance of their ultimate objectives.
This quality is difficult to identify in candidates and even harder to express in words. However, I have seen good results from having candidates demonstrate their talents in skills challenges during the last stages of the interview process. How a candidate approaches problems in a high-pressure virtual environment tells us quite a bit about whether the attacker mind-set is fully present, needs developing, or simply doesn’t exist within a candidate. Not everyone can think this way, and not everyone is cut out to be on a red team, and that’s okay. I’ve seen very smart people struggle with this aspect but then go on to build successful careers in other aspects of cybersecurity. ■
3 Paul Brager
“As you can imagine, the best way to get a red team job is to first understand what it is that you want to do and then build a technical skill set and foundation to align with what that type of role would entail.”
Twitter: @ProfBrager
Regarded as a thought leader and expert in the cybersecurity community for more than 25 years, Paul has deep expertise evaluating, securing, and defending critical infrastructure and manufacturing assets (ICS, IoT, and IIoT). An avid speaker and researcher, Paul seeks to move the conversation forward surrounding ICS cyber and managing the threat surface.
He has provided commentary on several security-related podcasts, publications, and webinars that provided guidance and insight into strategies for critical infrastructure and manufacturing cyber defense. Paul has a passion for mentoring and guiding people of color who are aspiring to contribute to the advancement of the industry and promoting diversity within the cyber community.
How did you get your start on a red team?
My red team beginnings (much like most experiences in this space) came about from necessity. Company leadership fired a “legacy” employee who was using a Windows 95 desktop with local accounts (yes, Windows 95). At the time, it wasn’t uncommon for workstations to not be part of a domain (Windows domains weren’t terribly common in the mid-’90s), but there also weren’t many methods of getting into a workstation if the password was lost. Novell was still king of the network operating systems, so you get the picture. Recovering a machine typically means re-installing over the top of it and hoping that you didn’t step on any of the critical documents/areas or getting into it with one of many “magic boot disks” that had started to appear at the time.
These were generally Slackware-based, but you needed some “skills” to be able to get them to work without destroying the master boot record (MBR) on the target. “Hacking” those disks with predictable results became more of an art than a science, as you needed not only some Linux/BSD knowledge but also knowledge of how partitions worked within Windows. After spending countless hours building (and rebuilding)
