The last framework that we will look at is the Open Security Architecture (OSA). OSA is a community-driven effort to develop a model for security architecture. By community-driven, we mean that it is a set of individual elements contributed by whoever has the willingness and acumen to do so, with subsequent peer review by others in the broader community. One way to think about this is along the lines of an open source software project. In an open source project, interested parties contribute to the development of the final work, such as a server (for example, Apache), tool (for example, Wireshark), operating system (for example, Linux), or any other software that might be of interest to the broader world at large. The model for OSA is similar; in this case, interested parties contribute to a repository of information about security architecture “design patterns” for enterprise security measures.
At the highest level of abstraction, OSA provides the contextual backdrop (“landscape” in their parlance) that allows meaningful contributions to take place. This includes a common set of terminology (to ensure that everyone contributing refers to the same concept the same way), actors (personas or roles of stakeholders in the security life cycle), a controls catalog (based on those outlined by NIST in their special publication 800-53), and a taxonomy – a map of relationships between elements of a security system.
The most directly useful element of the OSA effort though, at least from the point of view of the practically minded security architect, is the library of community-authored design patterns. Those with a background in software development (or those that have worked closely with developers) will likely be familiar with the term “design pattern.” It essentially refers to a strategy for accomplishing a certain goal that can be used and reused when faced with a given situation.
Design patterns are essentially strategies for accomplishing a certain goal. In a software development context, they are strategies that can be described in a way that is agnostic of implementation and language. By describing these strategies this way, it allows developers to easily discuss and share those strategies when they are faced with a given problem that they may have never seen before. For example, a developer of an object-oriented program might wish to create an instance of a software object and interact with it via a defined interface; in so doing though, they might wish to leave the actual mechanics of implementing the functionality to someone else: either another piece of code they didn’t write or in a way where the implementation can be dynamically changed at runtime.
To put more specificity on this example, a developer working in Java might wish to create and use a TLS-enabled socket (that is, a “secure socket”) to send data but do so in such a way that the actual implementation of the socket (that is, the version of the TLS protocol supported, the cipher suite, and so on) is decided upon at runtime based on the defined policy of the system. There is a design pattern that accomplishes exactly this: in this example, the factory design pattern. In Java, this pattern is implemented (among other places) via the SSLSocketFactory class that follows and implements this pattern: it allows a developer to create and use a TLS-enabled socket without knowing the underlying implementation.
These design patterns are very powerful because they provide a concise, standardized way to describe the solution to a problem that others might encounter and describe those solutions in a concise, highly precise way. The landscape and high-level artifacts of OSA allow the creation of security design patterns that do this in a way comparable to the way that software design patterns perform. For example, an OSA contributor can create a design pattern to address any given situation that includes information about the solution (for example, a diagram or schematic), a list of the relevant controls or security measures that implement the pattern, as well as other information such as challenges and threats that the pattern is designed to defend against.
For example, OSA provides design patterns for securing everything from public web servers (pattern SP-008) to public Wi-Fi hotspots (pattern SP-007), to cloud computing (SP-011), to even a pattern that describes the entirety of a Payment Card Industry Data Security Standard (PCI-DSS) cardholder data environment (SP-026). These are only a small sample of the many design patterns that are made available through OSA.
Hope you found our review of three security architecture frameworks useful. Our next post will address security architecture roles and processes.
This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978-1838989927 available at Amazon and published by Packt.