A Closer Look: Open Enterprise Security Architecture (O-ESA) from the Open Group

Continuing our deeper dive into security architectures, this week we’ll cover the Open Enterprise Security Architecture (O-ESA) from the Open Group.

One of the areas where many more formal security architecture models struggle is in the capacity to handle change within the organization. Recognizing that change in the technology ecosystem is a complicating factor and needs to be specifically accounted for in enterprise architecture efforts, the now-defunct Network Application Consortium (NAC) created a model for security architecture that specifically accounts for (in fact, presupposes and in some senses relies upon) the fact that change is both inevitable and a natural part of enterprise security efforts (see Comparing Security Architectures: defining and testing a model for evaluating and categorizing security architecture frameworks, Rob Van Os, master’s thesis, Luleå University of Technology, Department of Computer Science, Electrical and Space Engineering, Luleå, Sweden, available here).

This model, the Enterprise Security Architecture (ESA) model, was absorbed by The Open Group — an industry consortium consisting of over 700 enterprise stakeholders including IBM, Oracle, Philips, Microsoft, Boeing, and numerous others — who took over as steward when the NAC concluded its charter in 2007. Today, subsequently renamed as the Open Enterprise Security Architecture (O-ESA): A framework and template for Policy-Driven Security, it continues to provide value to security architects by embracing automation as the primary method to account for continued security in the face of near-constant technology change.

The model stems from a similar premise as SABSA; namely, that business drivers are the fundamental nexus from which all security efforts stem. O-ESA uses “governance” as the starting point and strategy for defining the principles, policies, guidelines, and standards of the organization as input into the architectural decision-making process.

Formally, governance in this context refers to the process of ensuring that IT efforts are in alignment with stakeholder and organizational goals. COBIT 5: A Business Framework for the Governance and Management of Enterprise IT, ISACA, an IT governance framework, defines Governance of Enterprise IT (GEIT) as “A governance view that ensures that information and related technology support and enable the enterprise strategy and the achievement of enterprise objectives. It also includes the functional governance of IT, that is, ensuring that IT capabilities are provided efficiently and effectively.”

It should be noted that, throughout our book, we try to attempt to avoid using the word governance where possible. This is for the simple reason that the term is used often informally in a way that is contrary to the formal definition and the way that O-ESA intends. This creates confusion and can detract from, rather than adding to, the understanding of those confronting the material for the first time. Therefore, while governance (at least in its formal sense) is important conceptually to the architecture process (as its use within O-ESA highlights), we’ve tried to use specific language in describing what we mean.
O-ESA then describes an approach to creating policy, drawing heavily on ISO/IEC 27001 and ISO/IEC 27002 to do so. The model goes on to describe elements of “automated policy enforcement” — specifically, automated measures to ensure that policy is enforced throughout the organization; these elements include the following:

• Policy Management Authority (PMA) — the central authority responsible for setting policy.
• Policy repository/registry — a location where policy artifacts are stored.
• Policy Decision Points (PDPs) — locations (for example, software or hardware) where decisions are made about whether requests or actions are allowed or disallowed based on the governing policy.
• Policy Enforcement Points (PEPs) — locations (for example, software or hardware) where decisions about policy are enforced.

Have you used O-ESA in your work? We’d love to hear about your experiences. And to wrap up our series on security architecture frameworks, next time we’ll cover Open Security Architecture (OSA).

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.