Heartbleeding Red: What’s a Red Teamer to Do?


The recently exposed Heartbleed bug in OpenSSL raises an interesting question for you, the crackerjack red teamer: how far should you take your red teaming? (Since most of you don’t red team for free, the natural companion question is “How far should your customer take their red teaming?”) To wit, do you limit your red teaming to the specific enterprise or system of interest, or do you open the door to all of the enterprise or system’s external dependencies?1
      Put differently, every system that sits on the other side of an external interface can introduce upstream or downstream vulnerabilities, and everything that sits on the other side of the these systems can do the same. You can extend this logic again and again and, via the small-world phenomenon, soon touch nearly every system and potential vulnerability in the world.
      But you, dear red teamer, have a budget and a schedule. While the nature of connected systems might persuade an infinitely wealthy customer to conduct exploratory red teaming outward from interface to interface and dependency to dependency, very few infinitely wealthy and boundlessly patient customers exist. (If you find one, let us know; we’d love to help you red team for them.)
      Red teaming remains more art than science, so, as you might expect, no algorithmic solution exists. Instead of answering the question with finality, we simply offer some initial thoughts:

  • Stay informed. While a customer wouldn’t have expected you to uncover the Heartbleed bug before it was disclosed, he or she will most certainly expect you to know about it today. Whether you’re red teaming information systems or business strategies, you must stay current on the targeted domain. This doesn’t mean that you have to know everything, but you should compose your team so, taken as a whole, the team at least knows the most important things. (And to know what those are, you need to stay informed so you know the most important things—yes, it’s circular, which is precisely why it’s so challenging.)
  • Don’t ignore external dependencies and interfaces. Even your customer lacks the time, money, or interest to explore everything on the other side of those external interfaces, you at least need to identify them. You can then assess which ones justify further exploration. You should document your decisions and work closely with your customer. If you believe it’s worth your customer’s time to explore an external dependency and it’s going to cost more money, make your case to them. If you believe you can trust something on the other side of the interface, log your reasons and revisit your choice periodically.2
  • Adopt a risk-informed approach. When deciding whether to explore a dependency, think about it from a risk-informed perspective, and remember that confronting the risk directly isn’t the only strategy available to you. Alternative strategies include but are not limited to studying the risk, waiting for it to hit a predetermined threshold before acting, sharing the risk (through insurance, for example), or even accepting the risk. Regardless of which strategy you choose, scale your effort in relation to the perceived gravity of the risk.3 This, of course, can be hard to nail down, even among experts. As Richard Bejtlich (@taosecurity) noted in a series of recent Tweets, we might be overhyping the Heartbleed bug. Bruce Schneier, on the other hand, calls it “catastrophic.”
  • Truly red team. As appropriate, consider the adversary’s concerns and metrics. Weigh their resources and preferences. Adopt their mindset. This is one approach to filtering a possibly prohibitive number of dependencies and interfaces. This approach isn’t without risk, however: the real-world adversaries you’re attempting to mimic might be deceiving you and your customer regarding their concerns, metrics, resources, preferences, and mindset. Or you might simply get it wrong. Still, it can be worth the effort if you believe you can do it well.4

       Modern security and strategy are hard. Red teaming can help, but it’s hard, too. Dependencies and interfaces ripple outward from systems and enterprises in complex, interwoven, reciprocal, uncertain, and sometimes counterintuitive ways. But hey, if you wanted an easy job, you wouldn’t be a red teamer.

  1. In the case of Heartbleed, for example, we consider it an “external” dependency in this context because your customers don’t likely “own” it. They might use it, and they might depend on services that use it, but until recently, they generally trusted its provenance. []
  2. As above, this can be somewhat circular, which is precisely why it’s so challenging. []
  3. As above, this can be somewhat circular, which is precisely why it’s so challenging. []
  4. As above, this can be somewhat circular, which is precisely why it’s so challenging. []


Terms of Use

Please read.