Why Red Teamers Should Care About ISO 42010 (IEEE 1471)
Red teaming remains stuck in the Wild West phase of its maturity. One of the main culprits is the lack of shared terms—a lack that makes it difficult for red teamers to compare methods, communicate insights, and, ultimately, build a consistent and structured discipline. IEEE 1471 can help. ((To learn more about the standard, see, for example, Rich Hilliard's presentation or this FAQ written by Mark Maier, Dave Emery, and Rich Hilliard.))
The full name of IEEE 1471 is “IEEE Standard 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems.” The standard is currently managed jointly by IEEE and the International Organization for Standardization (ISO) as ISO/IEC 42010:2007. As noted here, IEEE and ISO intend to broaden the standard’s scope to include both software and systems engineering.
The first important concept to understand about IEEE 1471 is that it's not an architecture framework but a standard for creating architectural descriptions. Any given architecture framework, for example, may conform to IEEE 1471 to a greater or lesser degree. As a system or enterprise architect, for example, you wouldn't use IEEE 1471 to architect your system of interest, but you might use an architecture framework that conforms to IEEE 1471.
The second important concept follows from the first: IEEE 1471 is notation independent. When generating an architectural description that conforms to the standard, you are free to use any appropriate modeling or diagramming approach to populate your architecture. The analyst, then, retains considerable methodological freedom, whether he or she is a software developer, a systems architect, or a red teamer.
At this point, the skeptical red teamer will naturally ask, "If the standard isn't a framework, and it doesn't specify any modeling techniques, how can it benefit me?" It's a fair question, but before I answer it, I need to define six key terms used in the standard.
Every system has an architecture; it is the inherent structure of the system. The architecture exists regardless of whether an analyst ever describes it.
An analyst or engineer creates an architectural description when he or she models the structure of the system. The architectural description characterizes or describes the whole system.
Systems have stakeholders. Stakeholders aren't limited to the system's users but include, for example, persons who sponsor, develop, implement, maintain, and depend on the system.
Stakeholders have concerns. A sponsor might be concerned that the system must be delivered on time, a developer might be concerned that a needed technology is delayed, and so on.
A view characterizes the whole system through the lens of a single concern or a set of related concerns. ((As defined in one IEEE 1471 FAQ, "A view is a collection of models representing the architecture of the whole system relative to a set of architectural concerns.")) To describe a system, the analyst or engineer will typically need to build many views. Each view may in turn contain many models.
A viewpoint helps the architect structure the views. It should specify the stakeholders, their concerns, and the conventions used to construct the view models. ((In the same FAQ cited above, a viewpoint is defined in these terms: "A viewpoint captures the conventions for constructing, interpreting and analyzing a particular kind of view. Viewpoint conventions include languages, notations, model types, modelling methods, analysis techniques, design rules or other operations on views.")) In the domain of software engineering, for example, Rozanski and Woods apply six viewpoints: functional, information, concurrency, development, deployment, and operational. (Rozanski and Woods, Software Systems Architecture, 2005.)
The following list summarizes the relationships among these six terms:
a system has an architecture,
an architecture is described by an architectural description,
a system has one or more stakeholders,
stakeholders have concerns,
a viewpoint addresses one or more concerns, and
a view conforms to a viewpoint. (For those who are interested, ISO defines the terms and illustrates their relationships diagrammatically here.)
So again, why is this useful to red teams?
Most red teams "architect" target systems, even when they don't use the term. Sometimes the process is informal and the resulting description is unsophisticated (and perhaps even undocumented). Sometimes the process is structured and the resulting description is much more complex. Rarely, however, do teams apply the same concepts or terms to their architectural descriptions.
The real advantage of IEEE 1471 in this context is that teams can employ different tools and approaches and still use the same high-level concepts and terms. Remember that the IEEE standard recommends a common method of describing architectures, not of building them. The concepts and terms are abstract enough--yet also robust enough--to facilitate communication without constraining methods or imposing burdensome requirements.
It is worth noting that I am not arguing that all red teams should adopt the same viewpoints and views. Most teams have different goals, customers, issues, and constraints, and these factors naturally yield different architectures, stakeholders, concerns, viewpoints, and views. I am, however, arguing that we should at least use the same terms and adhere to the same high-level structure in order to share ideas, concepts, and, yes, sometimes even viewpoints more efficiently. (That said, we should always be careful to avoid tainting our analysis with an engineering bias. The answer, of course, isn't to throw out any engineering-based approaches, but to be aware of the perspectives we adopt when we use them.)
Sandia's IDART, for example, employs views, a concept another team might call viewpoints, a set of perspectives, a set of models, or something else entirely. If IDART and other teams were to use the term views consistently (along with the rest of the IEEE 1471 terms and concepts), they would be able to compare their methods and products more easily without surrendering their teams' basic methodological independence. (I continue to emphasize the latter point because some red teamers will assert that any standard, no matter how loose, will encroach upon their methodological independence.)
Architecting--whether formal or informal--is just one of many functions red teams perform. While the lack of shared terms extends to most of these functions, we need to start somewhere. IEEE 1471 offers us a foundational set of concepts and terms on which we can begin to build a true discipline. And as we all know, Wild West gunslingers, card sharps, and cattle rustlers never were much inclined to discipline, but a clever sheriff could keep the assorted rowdies in line with a good set of shared terms. (And yes, I purposely used rowdies. Some of the red teamers I know would probably consider themselves modern guns for hire, and a few, I suspect, are decent card sharps. For all I know, a couple might even be cattle rustlers.)