The word cybersecurity intimidates people enough. Add the word architecture after it, and the intimidation -- and confusion -- is compounded.
One challenge around cybersecurity architecture is that, while many frameworks exist -- from The Open Group Architecture Framework and the Sherwood Applied Business Security Architecture to the Open Enterprise Security Architecture and the Open Security Architecture -- coverage is lacking around how to implement one, especially in smaller organizations.
That's why authors Ed Moyle and Diana Kelley wrote Practical Cybersecurity Architecture -- their guide to "creating and implementing robust designs for cybersecurity architects."
Doing everything in a cybersecurity architecture framework may be more easily achieved by the biggest of big organizations, Moyle said, but what about SMBs, midmarkets and companies with 2,000 to 3,000 people?
"There aren't a lot of good resources -- at least that we found -- on how to bring what's important and valuable about those frameworks to smaller organizations," Moyle said. "That's what we're trying to do in our book -- not replace any of the frameworks, but make them accessible to smaller organizations that might have less time or staff."
Kelley added that large organizations trying to reinvent or rethink how they're doing architecture could also benefit from the book. Geared toward architects of all types, Kelley noted it's not a book that lists instructions like "write this line of code" or "turn the knob on the firewall this way."
"That's not what the book is about," Kelley said. "It's about how you can take the ways to approach doing architectural assessments and architectural planning with security in mind and then bring that anywhere." Anywhere means network architecture, application architecture, enterprise architecture, be it on premises, off premises, hybrid or in the cloud.
Before jumping into implementation and where the approach can be applied, however, there's another challenge to overcome: defining cybersecurity architecture in the first place.
Here, Moyle and Kelley tackle that task and more.
Editor's note: This text has been edited for length and clarity.
Let's start at the top. What is a cybersecurity architecture?
Ed Moyle: The thing that was really surprising to me is there's little consensus definitionally about what a cybersecurity architecture even is. I view it as: How do you ensure a set of guardrails that, if you follow in between those guardrails, you will go from an idea of what you'd like things to be to a systematic process to get to something that is your end goal?
Diana Kelley: Everybody's got their own take. At a top-level view, it's a plan -- a thoughtful, contextualized plan to take you from 'We want to accomplish something' to actually being able to accomplish it. Your architecture is putting those pieces together so you can get there.
In the book, you also offer insights from others in the industry.
Moyle: We wanted the book to not just be our viewpoint. Sure, we wrote about our viewpoint and what has worked for us, but we also got input from other folks. We pulled together a bunch of people from big companies and little companies. We talked to the lead cybersecurity architect for Microsoft. We also spoke to people from smaller organizations, formal organizations, less formal organizations.
Kelley: We used various experts' different definitions in the book because there were different lenses and different ways people view a security architecture. Take Mark Simos [lead cybersecurity architect] at Microsoft. He sees it very much through a vendor lens. An architecture for him is how Microsoft components would overlay to a company, but it's very much Microsoft-centric. His cybersecurity architecture for Microsoft is different from if you're an application architect who needs to bring security into your application.
When you're looking at a security architecture through your own lens, it's slightly different for you and how you practice it. At the top level, it's always a plan. But, as you get more specific -- if you're building a network solution for a company versus if you're vendor trying to help your customers understand where you fit in their architectures versus if you're designing a new mobile application -- you're going to think different things about the architecture because it's going to be different for you.
Moyle: One thing Diana reminded me of as she was saying that, which I thought was really interesting, was one of the people we interviewed said something that stuck with me: 'Look, you're going to have an architecture. Regardless of what you do, there's going to be an architecture. The question is: Is it what happens to grow organically through twists of fate? Or is it going to be something you carefully groom and structure so you can control how it goes?'
I like the idea of the discipline of architecture being the purposeful grooming of an environment that has properties you want -- I thought that was really kind of an insightful thing.
Without a standardized definition, how are you seeing security architectures implemented in companies?
Kelley: As Ed was saying, companies have architectures; they just haven't planned for them. It's very, very common to go into a company that has been focusing on -- rightfully so -- getting the business done, and the architecture has been great. Whether it's the network or the application architecture, it has been expanding to what the company needs. But what they really need to do is step back and take stock of what they have and where they want to go. Often, you see sprawl; you see redundancy. There's inefficiency, shadow and parts of their architecture they're not even aware of. There's a lot of cleanup companies need to do. Everybody has an architecture; it may not have been a thoughtful or planned one. And, in many cases, it's not the most efficient.
Learn more about cybersecurity architectures
Read an excerpt from Chapter 2 of Practical Cybersecurity Architecture, where Kelley and Moyle discuss how to measure the success of cybersecurity goals.
Besides defining a security architecture, what challenges have you observed?
Kelley: One of the biggest challenges is management not understanding that, in order to save money, you need to spend some money. And that you need time and resources to think it through and get a deployment that's going to save money in the long run.
Moyle: Also, impressing upon people that it's something they need to do -- or not even need to do, but that it's beneficial for them to do.
Our whole point is: If you have some discipline around how you approach architecture, it serves your business interests better than taking shortcuts to just get your product, service or whatever it is out the door.
Another challenge is getting people to change their perception. Use words like architecture or governance, and people think, 'Oh, that's some slow, old-school stuff. I don't want to deal with that.' The truth is: You can do architecture in a way that's not slow. That's really the whole premise of the book: You can do governance in a way that's not super boring; it can actually be something that helps you be more agile.
Kelley: When you practice, you get fast at something. Think about the first time you drove a car. Then, think about, when you know where you're driving, you get there fast because it's in your memory, so you can do it much more quickly and efficiently.
A foundational book like ours won't say, 'in Azure, do X.' You don't learn how to do it; you learn specifically what to do in that instance. A foundational book will teach you how to do something, how to do architecture -- and then you're going to be much faster and much more flexible as you do it in any area.
Architecture done right -- and when you've got a good, strong team -- saves time and money.
What do you hope readers will get from your book?
Kelley: The main thing is that it will teach you how to approach architecture, so no matter what kind of architecture you need to do now or in the future, you've got the basics that you can extend and expand to any of those.
Moyle: Hopefully, no matter where you're coming from -- if you're a big org, small org, formal, informal, whatever your company background is -- hopefully, there's some experience -- whether it's ours or folks we interviewed -- that you can pick up and use tomorrow to help do what you're already doing better.