Enterprise Security Architecture

The following question, paraphrased, came up during my RSA 2013 presentation on why an Enterprise Information Security Architecture (EISA) matters:

Do you factor in threats when developing your EISA?

My initial response was essentially "no." The person who asked the question came up after the presentation and wanted me to think about that response.

Fair enough. I have been. Quite a bit.

I am going change my answer to "yes", but I want to qualify that a bit.

The primary qualification I want to make is scope. We need to be aware of the threat environment when designing our architectures, not necessarily the detail. While we need to understand the environment our enterprises are operating in from a broad perspective, we do not need to keep track of specific actors or threat actions at this level.

For example, when an architect is designing a building for an environment where tornadoes are common, he has to account for that in his design. However, he doesn't focus on architecting for a specific tornado. He can't.

Here's another example. If I am designing an EISA for a financial institution, being aware of the criminal element is important. Tracking exactly which group is using which malware is not, at this level.

I do want to make a huge plug for threat intelligence at the operational level though. Understanding who is operating against you, what they are doing, and the tools they are using is hugely valuable in tailoring our monitoring and response tooling.

So. Where does the threat environment information get captured?

In our context map. I didn't talk about context maps, and a whole bunch of other stuff, in my talk. I will be in future blog posts, but the short version is that the context map is a way to capture and represent the influences that make up the context our EISA will be developed in. "Understand the Business" is a big part of this context. Threat environment is another. There are many more influences.

So there it is. I flip-flopped.

What say you?


PS - To the person that asked the question, thank you!



On Friday, March 1st, 2013, I delivered my first RSA USA talk. It was a 20 minute talk on the need for and the value of an Enterprise Security Architecture. In addition to extolling the benefits of an EISA, I also provided a high level description of what one should look like and a quick blue print of how we go about starting down the path of developing one. Below is the text of the talk. I tend to wing it a bit during my talks so it is not a verbatim transcript, but all the thoughts and ideas are there. You can download the here, if you wish.

Winchester House Security:
Why Enterprise Security Architecture Matters


Oliver Winchester made his first fortune in the clothing business, but is best known for establishing the Winchester Repeating Arms Company which produced the Winchester Repeating rifle, referred to as the “Gun that won the West.”  He married Jane Ellen Hope in 1834 and they had three children, Ann, William, and Hannah. When he died in 1880, he left the company and his fortune to his son William.

Sarah_WinchesterUnfortunately, William died of Tuberculosis shortly after his father’s death and 50% of the company and an income of $1,000/day, roughly $22,000/day in today’s dollars, passed to Sarah, his wife. Legend has it that Sarah visited a medium who told her that the spirits of the dead killed by Winchester rifles were angry with her family and that’s why bad things were happening to them. The medium further told her that she must move west and build a house for herself and the spirits. Sarah took this advice, moved to San Jose and began construction of what is now known as Winchester house.

WinchesterHouseConstruction began in 1882. Fueled by her belief that the spirits were angry with her family, the words of her medium regarding what would happen if she eer stop construction on the house, and effectively an endless income, construction continued 38 years, day and night without any apparent overarching plan or architecture.

In summary, someone with a lot of money decided to follow an unusual belief that led to 38 years of perpetual building… without a plan. Does that sound eerily familiar?

So what does a house built over the course of 38 years, with lots of money and no plan  turn out like? StairsWell, rather chaotic. There are stairways that lead to nowhere, doors that lead to a…. Doorrather large first step, a long fall and a rapid deceleration.  There are  purpose specific rooms that never get used, a floor plan that, well, isn’t, and a lack of any real idea of exactly what’s what.


So, let me ask you the these questions:

  • Do you know exactly how everything used to secure your enterprises fits together?
  • Do you know everything you have?
  • How about this? How many of you have a complete set of solutions that all talk together?
  • Do you have some solutions that don’t talk to anything?
  • How many have multiple solutions for the same purpose, but not on purpose?

Kind of starting sound like we may have some of the same problems as the Winchester Mystery House.

So what’s the moral of the story?

Whether building houses or security, building without a plan – in other words, an architecture – leads to a real mess. Lets use the lessons of the Winchester house to focus on the needs of security.

Think about the value architecture provides:

First it establishes   a comprehensive view of where we are, or our current state. It’s really hard to figure out how to get somewhere if you don’t know where you are in the first place.

Next it provides a future view of what we want our security practice to look like, a target state. In the rare event the current state and target state are the same, it’s time to celebrate. How many here are in that position? Stand up so we can all celebrate.

The rest of us -- most of us -- have things that we want to change;  the target state is different than the current reality.

Once we have those two states defined, the rest of the architecture helps us define the path we are going to take to get from here to there. In some cases, there will be intermediate states that are worth documenting, but not in all cases.

In the case of information security, we will refer to this plan as the Enterprise Information Security Architecture. It is the guiding plan on how we are going to secure our enterprises. It does several good things for us.

  • It describes the risk posture of the organization based on the over-arching business strategy and drivers. Without this context, we are incapable of making informed decisions on how to implement security controls.
  • It builds on the current state and the target state.
  • It includes/requires a gap analysis between the two states and finally, and most importantly, produces the roadmap to get from here to there, from current to desired/target.

There are five major goals to keep in mind:

First, the architecture needs to be business driven. We are not trying to do security just to be doing it. The goal is to support and enable the business to get done what they need to get done. That means we need to understand what that means. More on that in a moment.

Second, our architecture needs to be a top-down plan. Moving from higher levels of abstraction down to more detailed directions. Think of how a building is architected. We don’t start by architecting the bathrooms. We start with the gross building features and move to greater levels of details as we progress .  Just in case the fact that we BUILD buildings from the ground up, starting with the detail, getting more ‘abstract’ as we go, is crossing your mind, remember that we are talking the enterprise architecture. The work that guides detailed level implementation is solutions architecture which is used to realize the enterprise architecture we define.

Third, it needs to be structured. It needs to flow appropriately.

Fourth, it needs to employ appropriate levels of abstraction. At the enterprise level, describing the details of how of the security settings for our browser of choice is going to be counter productive. At the enterprise level we would describe the need for a secure browser. Again, later solutions architecture work will get into the specifics.

Finally, it provides a common language for discussing the information security work of the organization.

As just mentioned, the first thing we have to do when we start down the path of building our EISA is to make sure we understand exactly what the business is trying to achieve.

This goes beyond just know that we are a bank, or manufacturing plant, or a pick your business type. We need to understand, specifically, what drives the business.

That means we also need to understand the business's goals AND the strategies the business plans to use to reach those goals.

Of all the things we can do as information security professionals to help the business, understanding their goals, drivers, and strategies will arguably gives us the biggest bang for the buck. If nothing else, it shows the business that we are engaged in what they want to achieve.

Now that we are on the same page as the business, we need to understand the business's key processes. This will drive out where the data is, who needs to get to it, and, most importantly, how they need to get to it.

The final bit we need to work on with the business to understand is what their risk tolerance is. That bit right there is hugely important. Without understanding what the business is willing to risk, we cannot provide appropriate levels of control.

With a good understanding of the business, it’s time to get to the nuts and bolts of building the architecture.

The first step is defining  the principles that are going to drive the development of the architecture. Principles are the underpinnings of our architecture. They are informed by the business understanding we have. One warning, principles are not policy. Principles are fundamental stakes in the sand which should be non-negotiable. Well, maybe not non-negotiable. What is ever non-negotiable in what we do? If you are looking for a good start list of principles, check out The Open Group's Enterprise Security Architecture. It has a really good list.

The next step is to build out our current state. In many cases, if this is the first time an enterprise architecture has been attempted, this will be at the physical level. This is entirely acceptable. This can be both the easiest part and the hardest. Finding all the bits and pieces that need to be included can certainly be challenging. However, this is a vital step and will provide immense value to the organization if you just stop here. Wouldn’t recommend that though.

The next bit is a where we get to cheat a little. There are myriad sources for reference architectures that we can leverage as guides as we develop our target architecture. Reference architectures are idealized architectures that have already been worked out. They obviously have to be fairly abstract, but they can be very helpful in making sure we don’t miss any of the big pieces.

Finally, we take everything we have done to date and describe our target start architecture. At the enterprise level, we will likely stop at the conceptual level, maybe dipping into the logical level a little, when describing our target architecture. The work of further logical detail and physical architecture deliverables will be driven by the roadmap we will discuss next. I do want to urge everybody to not get caught up in letting the current architecture drive the target architecture. There will certainly be influences from the current state, but don’t let current state back you into a corner.

Whew! We know where we are. We know where we want to go. Now the hard part. Getting from here to there. The first thing we need to do is figure out where the gaps are between our current state and our target state. This gap analysis will drive out the work we will need to undertake to move us towards the end goal.

Once we have our gap list and have identified or described the work that we need to undertake to move us along, we need to build roadmaps that give us the dependencies and help drive out timelines and milestones on our journey.

We also need to derive the metrics we need to have in order to track our progress. Have metrics that describe how effective we are at implementing our new architecture is vital to the success of the effort. The only way to know if we are changing things is if we can measure them.

In summary, chaos is bad. Systems, solutions, and controls implemented willy nilly will surely provide some level of security…maybe, but certainly not in the most efficient and effective manner.

We need a plan. We need all our security systems, solutions, and controls to work together holistically.

We need to understand how we are going to support the business in achieving their goals while making sure that vital business processes and data are protected appropriately.

Finally, we need to be able to effectively describe how we are going to get from where we are to where we need to be through gap analysis and roadmaps. All the while, being able to provide measures that demonstrate progress.


The Open Group Enterprise Security Architecture

Sherwood Applied Business Security Architecture

Image Attribution:

[1] Oliver Winchester - Wikimedia Commons - Copyright expired link
[2] Sara Winchester - Wikimedia Commons - Copyright expired link
[3] Winchester House Roofs - Photo by nhanusek - Creative Commons - link
[4] Winchester House Staircase - Photo by InSapphoWeTrust - Creative Commons - link
[5] Winchester House Door - Photo by HarshLight - Creative Commons - link
[6] Blueprint - Wikimedia Commons - Photo by Adrian Michael - Creative Commons - link