Blog post

Security Architecture Frameworks – Yay or Nay?

By Anton Chuvakin | October 24, 2018 | 9 Comments


This post is about a topic that few of us ponder often: security architecture frameworks. We have some exciting research plans in this area, hence this blog series.

Perhaps one can say that dumb people think of boxes, smart people think of processes, wise people think of architectures? OK, I just made it up, so perhaps dumb people think of pithy oversimplifications of reality, no? 🙁

In any case, this post is a continuation of this one, where I asked about how people define “security architecture” in 2018. Today I want to remind people that “standard” security architecture frameworks do exist.

Widely-known [not the same as widely-used, mind you] examples include:

  • SABSA (Sherwood Applied Business Security Architecture … and no, I don’t know what Sherwood stands for either, but presumably not the forest …)
  • O-ESA (The OpenGroup Enterprise Security Architecture, definitely alive, but closed behind the paywall? [oh, look, the pot calling the kettle back :-)])
  • OSA (Open Security Architecture, presumed dead by some)

On top of this, some “architecture-like” things can be found in NIST CSF (a lot, actually), ISO 2700x series and even in COBIT, if you look hard enough and use your architect’s eye.

But here is the punchline: does anybody care? More specifically, does anybody use them as foundations for their security architecture? Can security architecture frameworks even keep up with the evolution of IT? After all, there wasn’t much agile cloud mobile DevOps in the 1990s … Furthermore, we all know of people who use ISO series or NIST CSF (or NIST 800s) as control lists or policy advice, but perhaps not so many use them as architectural foundations…. If you do, please comment.

Posts related to this research:

Comments are closed


  • Anthony F. says:

    We used OSA in developing the concept and eventually the job role of enterprise security architect. In practice, it doesn’t always play out like we wrote it up but it gives us something to strive for.

  • Thanks a lot – appreciate the comment re: the OSA

  • Mikah says:

    We are confortable with Togaf but for security we melt Cobit Nist ISO SANS

  • Alex Parkinson says:

    The focus on the use of particular architecture frameworks excludes organisations that use system engineering practices to deliver complex solutions. This is a bit counter-intuitive since architecture frameworks where originally intended to deal with complexities in delivery of systems and outcomes.
    For engineering organisations architecture is practiced at multiple levels – definition of overall objectives, system-level architecture and technical solution architecture.
    I have found that SABSA architect experience and practices (yes, I am SABSA architect) fit very well with this approach since this framework was based on system engineering methodologies. Therefore, it is possible to apply security architecture practices even though an organisation has not ‘mandated’ a particular framework.
    The key issue with security architecture is does it help you define and answer the questions.
    [The Sherwood in Sherwood Applied Business Security Architecture refers to John Sherwood, not the forest. 🙂 ]

    • Thanks A LOT for the comment!

      >The focus on the use of particular architecture frameworks excludes organisations that use system engineering practices to deliver complex solutions.

      The above comment IMHO is pure gold. I did see the same theme in some twitter comments re: the fact that “frameworks are for losers” or at least for beginners.

      In this light, and in our upcoming research, we plan to treat SABSA as a sort of “meta framework”, framework for making frameworks for your own use.

      Finally, thanks for catching my Sherwood joke 🙂 This made my day.

  • In this day and age, with a myriad of security products overlapping in many areas, with projects fighting to get on top of the “roadmap”, a security architecture seems to be the only way to make sense of what should be done first and why. Maybe you don’t need a framework to come up with the architecture but why reinvent the wheel when experienced security practitioners have already spent countless hours to come up with something that works?

    I have the Enterprise Security Architecture book by John Sherwood and team on my desk all the time – some visiting friends commented that they didn’t realize that I’m such a Star Trek fan :(. It is more or less SABSA in practice, in a very readable format.

    Anyway, regardless of methodology, framework, etc, without full support from senior management, all the security architecture work is bound to fail.

  • Nichols says:

    If you look back to the Greek definition of architecture, you will find the broad meaning of “the art and science of make complex or carefully designing structures of something.” Thinking in security and considering all arguments (great Parkinson and Grigorof!), I believe that the principles and basilar of our area evolving since Saltzer and Schroeder (and before, of course) and currently have a great challenge to embrace business driven needs. Being more clear (I know that I only philosophize until now!), anyone who want to deliver the security architecture of any black box need to follow the body of knowledge and good practices that shows good results nowadays, adapting frameworks to their needs, maybe blending where it need it. It´s not an one size fits all and never will be, companies are incredibly distincts and complex, so the architecture frameworks must be an track and not a rail, without space for tailoring.

  • More comments:

    “Never been able to get SABSA to work for me, OSA is a good idea but dead, oesa has good ideas but isn’t consistent enough or maybe not complete”

    “There is no art in security architecture. NIST and others have ensured that fact. 😉 In fact, NIST has effectively dictated the minimum security architecture, so just look at their documentation and move on.”