“Red Team Journal still serves as the best open-source repository for helpful hints and emerging practices in the field.”
— MIcah Zenko, Red Team (2015)
‘Redtesting’: More of the Same

‘Redtesting’: More of the Same

Back in 2010, we talked about ISO 42010 ("Systems and software engineering—Architecture description"). It's worth revisiting. In our opinion, it remains one the best windows on the sort of complexity security red teamers and pentesters should address (but often don't).

As we mentioned in the original post, ISO 42010 defines the elements that full systems architectures should include. Arguably most important elements for the security red teamer are

  • Stakeholders: The persons/roles interested in the system

  • Concerns: The system-related issues of interest to the stakeholders

  • Views: A representation of the system relevant to a stakeholder's concern (or stakeholders' concerns)

  • Viewpoints: View templates

In plain language, stakeholders have concerns. We address concerns through views. We build views based on viewpoints. (Again, it's worth revisiting the original post.)

With this as background, we ask "What do most pentesters/redtesters do?" (We're dubbing pentesters rebranded as red teamers "redtesters.") While exceptions exist, pentesters and redtesters largely focus on what they know: the technical skillset associated with infiltrating and breaking IT systems. It's necessary and it's valuable, but it leaves a lot of potential concerns and views untouched.

Let's take the DoDAF viewpoints as one possible source of alternative views:

  • Systems viewpoint

  • Services viewpoint

  • Operational viewpoint

  • Capability viewpoint

  • Project viewpoint

  • Standards viewpoint

  • Data and information viewpoint

  • All viewpoint

You can review the DoDAF literature for full descriptions of these "viewpoints," but the short answer is that enterprise systems and enterprises-as-systems include much, much more than just tech. The DoDAF services, operational, capability, project, and standards viewpoints get at this. So does the TOGAF "business architecture" domain.

As long as we focus almost exclusively on the tech view, we ignore not just stakeholder concerns but also whole classes of potential attack paths.

"But that's what the other red teamers do," some might argue; "The purpose of pentesting/redtesting is to focus on the tech view because that's where so many of the problems are!" True, but we're not finding many of those other red teamers.

Companies believe they've covered their red teaming requirements by hiring pentesters/redtesters, leaving whole-system red teaming unaddressed. Don't believe us? Search "red team" or "red teaming" in LinkedIn. We can tell you what you'll find: hundreds of job postings for pentesters and maybe a job or two for a proposal red teamer.

One of the reasons we believe a more comprehensive approach to red teaming is needed is because it can get at the sorts of issues we've addressed here, here, here, here, and here. Until then, expect more of the same.

Beyond the Never-ending 'Hunt and Peck'

Beyond the Never-ending 'Hunt and Peck'

Red Teaming 'Sparks'

Red Teaming 'Sparks'