Information Security Matters: Information Security Architecture—From Access Paths to Zero Trust

Bob Dylan told us that “you don’t need a weatherman to know which way the wind blows.” I would amend Bob only to say, “But it helps.” Similarly, you do not need an architect to build a house, but if you want the windows and doors to be in the right place, the power and plumbing to work, and the roof to stay on, then it helps. And you do not need an information security architect to build security into information systems. You can just keep buying security tools and placing hope and trust in the salespeople who tell you how great it is going to be.

Information Security Architecture, From Mainframes to Distributed Systems

My first attempts at information security architecture began with a list of attributes (e.g., integrity, confidentiality, recoverability, accuracy) that I gave to developers to ensure inclusion in the applications they were working on.¹ From that approach, I moved on to charting the access paths to data and ensuring that adequate security measures were applied on every path. That was workable in the days of mainframe systems, inasmuch as there were only a limited number of access paths. This method broke down as we moved to distributed, client server-based systems. As I commented several years ago in this space, “when we moved from massive centralization—mainframes to distributed processing—candidly, we security professionals did not manage that one well.”²

The problem then was that we, as an information security community, were trying to design and implement centralized controls for an environment that had no center. The failure of this approach has been evident in the growth of cyberattacks, which seem to have come to a crescendo in the past decade. Clearly, a more effective method for architecting information security was needed. Indeed, there have been a number of attempts, including:

• The Open Group Architecture Framework (TOGAF) was developed in 1995. It defines four domains for security: business, application, data and technology. It is accompanied by an architectural development model that seems overly complex to me, perhaps because it was designed for large enterprises implementing very big systems.³
• The Sherwood Applied Business Security Architecture (SABSA), defined in 1996, is another such approach. Its developer, John Sherwood, explained it as “a holistic, enterprise-wide view, and creating principles, policies and standards by which the system will be designed and built […] [ensuring] consistency of the design approach across a large complex system.” It provides a layered vision of security, from the perspectives of mangers, technicians, constructors, designers, architects, and the business as a whole.⁴

Frankly, although I am aware of both SABSA and TOGAF and other such methodologies, I have never used them. Perhaps this is because they were just ahead of their time, or maybe they were just too complicated with all their perspectives, layers, and domains.⁵

Buyers should be able to acquire and implement security features that integrate seamlessly with all the other products that they have bought previously and will buy in the future. However, since older products were not designed to be interoperable, ZTA is only truly applicable to current and future acquisitions.

Zero Trust Architecture

Then, Zero Trust Architecture (ZTA) arrived. The term Zero Trust had been coined before the publication of “Developing a Framework to Improve Critical Infrastructure Cybersecurity” in 2013, but this document brought the term to a wider audience. It was written by John Kindervag, then of Forrester Research, and published by the US National Institute of Standards and Technology (NIST).⁶ The prominence of a government standards body and the market savvy of a major analyst firm gave Zero Trust a degree of acceptance that other architectural methods had not achieved, although it took several years to catch on.

The architecture to achieve Zero Trust is known, naturally enough, as Zero Trust Architecture or ZTA. Structurally, it is based on just a few core concepts. Exactly how many such concepts, or pillars, is a subject of some dispute. Some say three,⁷ some five,⁸ others six,⁹ and others even seven.¹⁰ Personally, I see five basic concepts in ZTA:

1. Ensure all resources are accessed securely regardless of location.
2. Adopt a least privilege strategy and strictly enforce access control.
3. Inspect and log all traffic.
4. Permit no lateral movement without validation.
5. Segment networks in alignment with access requirements.

A respected colleague of mine says that these five just add up to “least privilege on steroids.” Yeah, and Superman is just Clark Kent on steroids. But just as Superman can be brought low by kryptonite,¹¹ so ZTA does not create systems that are impervious to cyberattacks. Zero Trust Architecture will not stop them all, but it can ensure that organizations do not fall victim to the easiest of attacks or fail to discover a breach for months or even years.¹² Despite the initial objective of improving critical infrastructure security, the real value of ZTA is to provide a consistent, coherent basis for acquiring security hardware and software over the course of time.

Interoperability

The key premise of ZTA, as I see it, is the interoperability of security mechanisms. Buyers should be able to acquire and implement security features that integrate seamlessly with all the other products that they have bought previously and will buy in the future. However, since older products were not designed to be interoperable, ZTA is only truly applicable to current and future acquisitions. Implicit in this statement is that the full implementation of ZTA will take an extended period of time, probably measured in years.

This raises several dilemmas for information security architects. Will the introduction of security mechanisms that are interoperable alongside others that are not actually leave more openings for penetration? If it is not financially or technically feasible to acquire an entire suite of Zero Trust-enabled products all at once, which ones should be the first? Is complete interoperability off the shelf really possible, or does it require the development of interfaces that create exposure by themselves?

I have to admit that I do not have answers to these and numerous other questions. I do not think anyone does yet, including the vendors of security systems. But I am confident that solutions will arrive. Not always satisfactory solutions; compromises and accommodations will need to be made as they have in the past. However, I do believe that information security architecture provides a path to resolving the dilemmas. And although ZTA is not the end of the progress of information security, and other architectures may still be developed, I do think that ZTA is the best we have today and that it points the way for any future progress.

Endnotes

¹ Interestingly, the only attribute they pushed back on was legality. Since I was working at a US Wall Street bank at that time, I thought that handling data about other people’s money in a legal manner was just common sense. I wonder how much has changed today.
² Ross, S.; “Security in the Migration to a MultiModal Environment,” ISACA^® Journal, vol. 3, 2018, http://74pq.liashapiro.com/archives
³ Reselman, B.; “TOGAF and the History of Enterprise Architecture,” Red Hat, 14 September 2020, http://www.redhat.com/architect/togaf
⁴ Platt, M.; “What Is SABSA Enterprise Security Architecture and Why Should You Care?,” Medium, 26 August 2019, http://medium.com/@marioplatt/what-is-sabsa-enterprise-security-architecture-and-why-should-you-care-a649418b2742
⁵ An interesting comparison of SABSA, TOGAF, and COBIT can be found in Rassoul, G.-Z.; “Enterprise Security Architecture—A Top-Down Approach,” ISACA Journal, vol. 4, 2017, http://74pq.liashapiro.com/archives. Notably, Zero Trust Architecture is not mentioned.
⁶ CGI, Developing a Framework to Improve Critical Infrastructure Cybersecurity, Canada, 2013, http://www.nist.gov/system/files/documents/2017/06/01/040513_cgi.pdf
⁷ Atwell, E.; “The History, Evolution, and Controversies of Zero Trust,” Kolide, 23 February 2023, http://www.kolide.com/blog/the-history-evolution-and-controversies-of-zero-trust
⁸ Hernández, J.; “The Key Pillars of Zero Trust: Mastering the Basics,” Prey, 23 June 2023, http://preyproject.com/blog/the-key-pillars-of-zero-trust-mastering-the-basics. However, not everyone agrees with Hernandez as to what the five pillars are.
⁹ Secude, “The Foundational Pillars of Zero Trust,” http://secude.com/the-foundational-pillars-of-zero-trust-strategy/
¹⁰ Balaban, D.; “The 7 Pillars for Zero Trust: An In-Depth Guide,” Cybeready, 20 September 2023, http://cybeready.com/the-7-pillars-for-zero-trust-an-in-depth-guide
¹¹ I knew all those hours reading comics when I was a kid would come in handy someday.
¹² Cunningham, C.; “The Zero Trust eXtended (ZTX) Ecosystem,” Forrester, 19 January, 2018

Steven J. Ross, CISA, CDPSE, AFBCI, MBCP

Is executive principal of Risk Masters International LLC. He has been writing one of the Journal’s most popular columns since 1998. Ross was inducted into the ISACA^® Hall of Fame in 2022. He can be reached at stross@riskmastersintl.com.