Recently, I asked my Lares mates to comment on a red team (RT) architecture post I stumbled upon. A volley of responses ensued with the conclusion: “That’s a penetration testing platform – not full-scope”- and a non-committal “or maybe.” Our RT banter characterizes for the larger efforts to define RT. The red team (RT) market has become wildly competitive. At the same time, RT market-speak is equally confusing. As a result of this confusion and emerging RT guidelines (e.g., CIS 20, Control 20) for security programs, I find myself seeing red.
Today, we see many organizations bunt on testing of any kind. “It’s a good thing to have.” “We plan to get around to it.” Adoption rates of penetration testing are already low. As a result, pundits and regulating bodies continue to push adoption. Clients have expressed to me a sense of unreadiness when considering RT, opting to focus on other program components. Assessment of any kind cost too much or not relevant.
Coming to Terms
What should we say about the terms used to describe RT v. PT? The Center for Internet Security (CIS) offers the following definitions for RT and PT the CIS 20, Control 20:
Penetration testing starts with the identification and assessment of vulnerabilities that can be identified in the enterprise. Next, tests are designed and executed to demonstrate specifically how an adversary can either subvert the organization’s security goals (e.g., the protection of specific Intellectual Property) or achieve specific adversarial objectives (e.g., the establishment of a covert Command and Control infrastructure). The results provide deeper insight, through demonstration, into the business risks of various vulnerabilities.
Red Team exercises take a comprehensive approach at the full spectrum of organization policies, processes, and defenses in order to improve organizational readiness, improve training for defensive practitioners, and inspect current performance levels. Independent Red Teams can provide valuable and objective insights about the existence of vulnerabilities and the efficacy of defenses and mitigating controls already in place and even of those planned for future implementation.
The standards writers apparently use the terms ‘comprehensive’ and ‘spectrum’ to distinguish pentesting from red teaming. I and others do not believe that these definitions go far enough to explain the differences in testing. For instance, the CIS 20 RT definition omits the time aspect. Daniel Miessler has written that RT engagements should be campaigns that last weeks, months, or years. In an amazing presentation called “You’re probably not Red Teaming…And usually, I’m Not, Either,” Deviant Ollam concluded after parsing several RT definitions that the industry has overused the term “red team.”
Full Scope Please
Lee Kagan, Director of Adversarial Collaboration at Lares, recalls delivering an impassioned talk to executives and CISOs on RT and PT regulatory mandates. Lee views emerging RT mandates as misleading. That is, the new recommendations are not RT in the traditional sense but a series of penetration tests. Lee feels the term “red team” in no way anymore resembles what it once meant. In truth, the original point of the simulated adversary likely disappeared years ago. “I’m not sure what pentests are called these days but in the last few years, I haven’t personally seen many full-scope, dissimilar adversarial ( and continuous) testing being done. For me personally, I struggle with the ‘red team in a week’ assessment which is unfortunately very common is really all that tends to happen.”
Going back to the well-constructed and beautifully architected infrastructure RT setup I shared, it likely accomplishes 3 things – phishing and Long Term (LT)/Short Term(ST) listening posts. An LT listening port, in general, refers to a C2 endpoint that attackers would only use to receive callbacks from persistent implants versus day-to-day attacks – a lifeline of sorts. In contrast, STs help attackers gain initial access thru phishing or other means. The call back occurs on the on an ST host, which drops persistence that directs a callback to an LT one to avoid detection. Our team ultimately believed the platform fell short of meeting RT infrastructure needs. At the same time, we did not rule out its potential use in a given RT scenario. It all depends on the goal of the exercise.
Red Team Guidance
One aspect of RT infrastructure our adversarial engineering team mentioned, stands out and resonates with me. There’s pentest infrastructure and then there is RT infrastructure. The latter is based on attacker needs for the targeted goal. That is, RT reference architectures are fluid. A static architecture may or may not reflect true adversarial methods in a particular context. Offensive-minded adversaries do what is needed for the job. They use objective-driven infrastructure to accomplish specific tasks. To that end, attackers build attack infrastructure with two design considerations in mind:
- Attribution (pop someone else’s stuff or daisy-chain compromised systems in places that have no reciprocity/legal cooperation so they WON’T share info)
- Just enough infrastructure/arch (JEA) moving pieces to get the job done. Situational objectives dictate what infrastructure(s) attackers will use. Anything more is overkill and may not be germane to the specific needs of a particular RT exercise
Do not allow niche sellers or vendors, including us, to pressure you into procuring RT services. Educate yourself. Work with proven partners to guide you. To avoid seeing red, keep the following items in mind when thinking about RT:
- Be an informed buyer. The RT provider should help demonstrate risk and measure control effectiveness through structured, iterative processes that emulate real-world adversarial cadence, scope, and tempo. Given the niche nature of RT, know what teams can truly deliver on an RT engagement
- Know the Difference. Based on your industry, are you mandated to have simulated adversaries constantly at your gates, or is it quite literally a mandate for penetration testing where the industry has simply replaced that phrase with RT?
- Own your threat model and communicate it to your selected red team provider. If your vendor understands your threat model, chances increase for better engagement outcomes. When the RT vendor dictates your threat model, items tend to be missed.
- Ensure to integrate your defenders/SOC/blue team in your RT exercises. Your defenders are integral for achieving the most desired RT outcome – improved defense.
I leave you with a few resources to help familiarize you with RT and related information. Please do not hesitate to reach out directly to us here at Lares. We are eager to help and hear what you are experiencing in the RT marketplace. You can reach me here: email@example.com
Defensive Strategies: the Power of Visibility Lee Kagan and Anton Ovrutsky
Red Team Telemetry: Empire Edition Zach Grace
See also the “I Want a Pentest” series of blogs for more perspective.
Mark Arnold has a 15+ cybersecurity career, serving 8 of those years in leadership roles. As a transformational leader, Mark has built security teams and programs, authored maturity model blueprints to optimize risk management processes, and implemented security domain practices at large enterprises and service providers. Mark’s areas of interest include cloud security, threat intelligence, and vulnerability research, nation-state attack methods and related activities (e.g. information operations and disinformation campaigns) and their collective impact on nations and society. Mark recently completed an executive education cohort on the intersection of cybersecurity and technology at Harvard’s Kennedy School.