Red Teaming in cybersecurity has traditionally been very narrowly defined as those activities performed while replicating the templated actions of a likely adversary. These actions include a mixture of attempts to penetrate the network, application, and the human and physical defenses of the targeted organization. The problem with this narrow definition is that it focuses on methods, and not the true objective of the Red Team—which is to identify and stratify information security risks. If we take an objective-based approach rather than a method-based approach to our definition, it becomes logical to expand our definition of Red Teaming to include all proactive activities performed to identify information security risks. This expanded definition thus includes activities such as framework-based vulnerability assessments, audits, vulnerability scans and even policy reviews.
Successful Red Teamers think, act, and become like the adversary. But being LIKE the adversary is not the same thing as being the adversary—and that’s where communication comes in. Red Teams, whether external or internal, have to collaborate with the “enemy” to define goals and report and communicate their findings, successes, and the vulnerabilities they have identified. The goal isn’t just to win but rather to help the Blue Team defend against real attacks.
Providing intel that is truly helpful in improving an organization’s security posture requires a methodical, iterative approach—at the heart of which is collaboration. Whether internal or external, Red Teams aren’t typically acting from the heart, but rather the head. And that’s where three common communication headaches can happen.
It’s not uncommon for Red Teams and Blue Teams to go into an engagement without shared objectives. If a Red Team is set loose on an objective without clear guidance, they will naturally use all the tools in their arsenal to reach the crown jewels. Blue Teams are often left with no guidance at all beyond “Stop the bad things from happening.” At the end of this all-to-common scenario, Blue Teams are handed results that may not be congruent with the organization’s strategic priorities—or worse, may simply regurgitate vulnerabilities that are already documented.
Collaborative planning goes beyond the traditional scoping questionnaire or Statement of Work discussions. It must begin with establishment of objectives by information security leadership, and these objectives should be established as part of a systematic plan for improving the overall security posture of the organization.
It is unrealistic to expect any engagement to test the gamut of defenses across the attack lifecycle. Adversaries have too many options—it is the equivalent of attempting to defend every inch of a football field on each play. Instead, Blue Teams should focus on specific adversary objectives in the attack lifecycle (tactics). Furthermore, they should leverage locally-generated and external threat intelligence to help narrow the scope of specific techniques to test their defenses against.
This initial set of test objectives becomes the baseline for collaborative planning. Red Teams can help refine these objectives by assisting the now Purple Team with selection of appropriate techniques and even the specific procedures within those techniques. With a full understanding of the overall engagement objectives, the Red Team can build a playbook that will provide the actionable intelligence needed for rapid remediation.
Collaborative planning isn’t just for enterprises with in-house Red Teams. Consultancies should offer and customers should insist on the inclusion of hours for this type of collaborative planning in the Statement of Work. This small additional upfront investment that enables collaboration will result in more meaningful results and an overall better ROI.
The primary method by which Red Teams communicate to Blue Teams today is traditional document-based delivery. At the end of the engagement, Red Teams drop off a 300-page PDF and perhaps perform an hour-long outbrief with leadership that is largely one-way communication.
This approach suffers from three fundamental limiting factors:
Remediators need to rapidly find the information that they need to develop and deploy solutions, and they need access to as much information as possible to enrich their understanding. This won’t ever happen if we continue to rely upon traditional document-based delivery.
Both Red and Blue Teams need a custom reporting tool that makes it easy for testers to provide data and for remediators to find the data they need. Thankfully, in the 1990s some visionaries at the National Center for Supercomputing Applications invented this amazing thing called the “web.” Somehow though, our community of technology experts has managed to largely ignore this method of delivery for decades.
PlexTrac was built from the ground up to take advantage of all the benefits a web-based reporting method can provide. Testers can provide and organize as many screenshots, code samples and even videos as they produce without fear of creating the “signal to noise” problem because remediators can easily browse, search, and select the information that they need.
Both Blue and Red Teams have access to findings as they are being documented in PlexTrac. This view provides remediators with the opportunity to ask for clarifications, or even for opinions, on potential remediation efforts while the engagement is still in progress. Better yet, this communication can occur within the platform and within the context of the specific finding through the Status Tracker associated with each result.
Finally, because PlexTrac was built as a reporting engine, testers don’t waste time fighting the complexities of Word templates. Data is entered into forms that automatically format it for viewing in the platform, to include those artifacts such as videos and screenshots. We do acknowledge that there are customers who still expect a document as an artifact of the engagement. To meet this requirement, PlexTrac’s custom export templates make creation of a traditional report document as easy as selecting “Export.”
While two-way communication during an engagement is vital, inevitably additional questions will arise after the completion of an engagement. Some remediation efforts are quick, but others require planning and resources to implement.
Additionally, the severity of identified risks can change over time. Today, the speculative execution vulnerabilities in processors may be considered low risk because of the lack of exploits in the wild. That’s a situation that could change very rapidly—there may already be exploits in use that have not yet been disclosed.
Just as we must look at pre-engagement collaboration as a necessary investment, we should also ensure that post-assessment collaboration is a standing aspect of any engagement plan. Remediators need access to the testers who identified the risks, especially for more complex vulnerabilities.
This communication needs to be asynchronous and it needs to be secure. It’s unrealistic to expect to be able to pick up a phone a month after an engagement and ask questions about a particular finding, and it is unwise to attempt to do so via unsecured email.
PlexTrac allows testers and remediators to communicate directly in a secure environment and within the context of the topic at hand. Both Red and Blue Team members receive notifications when issues are assigned to them, and can even share new information within the context of a finding. And should personnel turnover happen on either side, the complete record of collaboration is retained with the data needed to continue remediation efforts.
Communication is hard enough given the dispersion of the modern workforce and the velocity at which we all operate. It’s time we stop trying to communicate about modern problems using 20th Century reporting techniques. Interested in how PlexTrac can help your teams enhance collaboration and get better results? Drop us a line at email@example.com and let us give you a tour.