Getting A Handle On Enterprise Information Security Architecture
‘New’ enterprise level companies are somewhat of a rarity. Generally speaking, a company will slowly grow into an SME, and bring along their own preferences for security developed over the years. Sure, there are some small companies that get tens of millions in investment, and suddenly need to expand their infrastructure to match their new status. But in most cases, infrastructure is a gradual acquisition process.
With this in mind, Enterprise Information Security Architectures (EISAs) can be seen as checklists more than shopping lists. These checklists each correspond with a prescribed layering of security resources, generally representing what are considered best practices for certain countries or industries. All of them share basic security tenets (defense in depth, the confidentiality / integrity / availability triangle, etc.), but they differ at the implementation level.
So let’s take a look at some of the mainstream EISAs, and see where they fit in the context of the global cybersecurity gestalt.
The Most Popular Enterprise Information Security Architectures
We’ll cover the four big Enterprise Information Security Architectures seen in the field over the last few years. Note that there are plenty of smaller alternatives to examine if you aren’t satisfied with one of the options below.
One of the most important things to note about EISAs is how frequently they’re updated. Threats shift as time goes by, and good architectures shift to compensate. If an EISA hasn’t been updated for over a decade, it probably isn’t completely relevant or up to date. Which brings us to…
The Department of Defense Architecture Framework (DoDAF) is the U.S. Department of Defense’s suggested security framework, which is now over a dozen years old. Version 2.02 came out in August 2010. Even though it is still used as a blueprint from some enterprises, it is considered a legacy architecture in some circles.
In a way, that status matches the general outlook of the framework. It mainly applies to large systems with a mix of legacy and modern resources, which can result in complex integration challenges. Think 80’s COBOL codebases and mainframes coexisting with Cloud based resources in a secure and stable way.
It’s impressive that DoDAF has this kind of flexibility, to be sure. A lot of parallels can be found in the banking industry and older retail chains. They can take advantage of newer systems while maintaining systems with a long history that are difficult to replace.
The main problem with DoDAF is that everything is shoehorned into either ANSI/IEEE 1471-2000 or ISO/IEC 42010. If one just blindly adopts these systems without identifying specific stakeholder needs, it can result in wasteful expenditures for the purpose of ‘completeness’ that don’t actually accomplish anything.
The Zachman Framework is in a similar update hiatus as DoDAF, with their last version being released in August 2011. Originally, Zachman developed this EISA at IBM in the 80s. To his credit, over 30 years of faithful updates is quite impressive. But the security aspects of the framework really need to be updated every few years, or they risk not incorporating strategies against the latest OWASP and industry trends.
Understand that this framework is not methodology oriented. It states the issues that need to be addressed categorically and as long as the chosen solution addresses all aspects of the issue to the stakeholder’s satisfaction, it’s considered covered.
The grid based system architecture philosophy covers Who, What, When, Where, Why, and How as they apply to a variety of business perspectives: Executive, Business Management, Architect, Engineer, Technician, and Enterprise.
For a more general rule set that can cover security as well as other enterprise structures, Zachman is pretty good. But it doesn’t address the specific realities of today’s security landscape, like the indirect threat of browser and device fingerprinting or the gross prevalence of phishing in recent years. You can ‘read between the lines’ to create prescriptive solutions to these things (virtualization policy, soft training, etc.) under the broad framework. But that can be said about every emerging issue, and isn’t particularly helpful.
At least the Federal Enterprise Architecture Framework (FEAF) was updated in the last decade; 2013 to be exact. The bad news is that, internally at least, FEAF is considered an utter failure.
Why, you may ask? Stanley Gaver said it best in his 2016 criticism of the project: “Enterprise Architecture within the federal government hasn’t been working, and far more often than not hasn’t delivered useful results. Moreover, significant parts of the federal EA program have been complete and utter failures.“
Perhaps, ironic as it might seem, the U.S. government is simply a poor choice for FEAF. On its surface it seems fairly robust, taking the NIST Enterprise Architecture Model and building upon it in an entirely reasonable way. It runs business and design drivers through a four part enterprise architectural model that includes a decent data structure and security framework.
Its also unafraid to borrow from other models that have had success in the past, including Zachman and EAP. It’s still embraced in many manufacturing sectors, who say that it helps prevent waste and gives them ample data security at a reasonable price point. It’s possible that the American government simply wasn’t flexible enough to take advantage of the system that they helped to design.
This brings us to The Open Group Architecture Framework (TOGAF), the most widely used EISA in the world. It’s projected that over 60% of Fortune 500 companies use some version of TOGAF. And for good reason.
TOGAF 10 was launched in April of 2022. It is the most frequently updated major enterprise architecture in the world. It was created by a global consortium called The Open Group, which has helped with transparency as well as industry specific adaptation. Platinum members include Fujitsu, Huawei, IBM, Intel, and Philips. There’s even a list of TOGAF certified tools that comply with their framework entirely.
On the security side, it isn’t bad. It’s focused on gap analysis and system monitoring. While not entirely prescriptive as far as systems, it is flexible enough to analyze modern threats and guide businesses towards adopting appropriate countermeasures. Then those countermeasures are tested and monitored to see if any tweaks need to be made, or a new system considered.
But therein lies the main criticism of TOGAF: That it doesn’t provide enough specific examples to bring real weight to the words in the document. In fact, some companies discard entire systems because they can’t find a way to adapt them to their particular vertical.
But that having been said, it seems like TOGAF is the best of an aging set of enterprise architecture frontrunners. Nothing else has reached a significant number of enterprises, and so theories remain largely untested. For most enterprises wanting to adopt a modern security model, it seems to be TOGAF’s way or the highway.

