What is this thing called “Security Architecture”?

Posted on by

What is this thing called “Security Architecture”?

In February 2009, while I was attending an Open Group Architecture Conference in Bangalore, India, several of us got into a conversation about how security fits into enterprise architecture. A couple of the main folks from the Open Group were involved (sorry, I don’t remember who). They’d been struggling with this same problem: Is high level security participation in the process architectural, as defined for IT architecture?

Participants to that particular conversation had considered several possibilities. Maybe there is such a thing as a security architect? Maybe security participation is as a Subject Matter Expert (SME)? Maybe it’s all design and engineering?

Interesting questions.

I think how an organization views security may depend on how security is engaged and for what purposes. If security is engaged at an engineering level only,

  • “please approve my ACLs”
  • “what is the script for hardening this system? Has it been hardened sufficiently?”
  • “is this encryption algorithm acceptable?”
  • “is this password strength within policy?”
  • etc.

Then that organization will not likely have security architects. In fact (and I’ve seen this), there may be absolutely no concept of security architecture. “Security architecture” might be like saying, “when pigs fly”.

If your security folks are policy & governance wonks, then too, there may not be much of a security architecture practice.

Organizations where security folks are brought in to help projects achieve an appropriate security posture and also brought in to vet that a proposal won’t in some way degrade the current security posture of the organization, my guess is these are among the driving tasks for developing a security architecture practice?

However, in my definition of security architecture, I wouldn’t limit the practice to vetting project security. There can be more to it than that.

  • security strategy
  • threat landscape, (emerging term: “threatscape”)
  • technology patterns, blueprints, standards, guides
  • risk analysis, assessment, communication and decisions
  • emerging technology trends and how these affect security

A strong practitioner will be well versed in a few of these and at least conversant in all at some level. Risk analysis is mandatory.

I’ve held the title “Security Architect” for almost 10 years now. In that time, my practice has changed quite a lot, as well as my understanding, as my team’s understanding have grown. Additionally, we’ve partnered alongside an emerging enterprise architecture team and practice, which has helped me understand not only the practice of system architecture, but my place in that practice as a specialist in security.

Interestingly, I’ve seen security architecture lead or become a practice before enterprise architecture! Why is that? To say so, to observe so, seems entirely counter-intuitive – which is where the Open Group folks were coming from, I fear?. They are focused deeply on IT architecture. Security may be a side-show in their minds, perhaps even, “oh, those guys who maintain the IDS systems”?

Still, it remains in my experience that security may certainly lead architecture practice. Your security architects will have to learn to take a more holistic approach to systems than your development and design community may require. There’s a fundamental reason for this!

You can’t apply the right security controls for a system that you do not understand from bottom to top, front to back, side to side, all flows, all protocols, highest sensitivity of data. Period.

Security controls tend to be very specific; they protect particular points of a system or flow. Since controls tend to be specific, we generally overlap them, building our defense out of multiple controls, the classic, “defense-in-depth”. In order to apply the correct set of controls, in order not to specify more than is necessary to achieve an appropriate security posture, each control needs to be understood in the context of the complete system and its requirements. No control can be taken in isolation from the rest of the system. No control is a panacea. No control in isolation is unbreakable. The architectural application of controls builds the appropriate level of risk.

But project information by itself isn’t really enough to get the job done, it turns out. By now I’ve mentored a few folks just starting out into security architecture. While we’re certainly not all the same, teaching the security part is the easy part, it turns out (in my experience). In addition to a working understanding of

  • Knowledge of the local systems and infrastructures, how these work, what are their security strengths and weak points
  • The local policies and standards, and a feel for industry standard approaches
  • What can IT build easily, what will be difficult?
  • Understanding within all the control domains of security at least at a gross level
  • Design skills, ability to see patterns of application across disparate systems
  • Ability to see relationships across systems
  • Ability to apply specific controls to protect complex flows
  • Depth in at least 2 technological areas
  • A good feel for working with people

Due to the need to view complex systems holistically in order to apply appropriate security, the successful security architects quickly get a handle on the complexity and breadth of a system, all the major components, and how all of these will communicate with each other. Security architects need to get proficient at ignoring implementation details and other “noise”, say the details of user interface design (which only rarely, I find, have security implications).

The necessity of viewing a system at an architectural level and then applying patterns where applicable are the bread and butter of an architectural approach. In other words, security must be applied from an architectural manner; practitioners have no choice if they are to see all the likely attack vectors and mitigate these.

Building a strong defense in depth I think demands architectural thinking. That, at least is what we discovered 9-10 years ago on our way to a security architecture practice.

And, it’s important to note that security architects deal in “mis-use” cases, not “use cases”. We have to think like an attacker. I’ve often heard a system designer complain, “but the system isn’t built to work that way”. That may be, but if the attacker can find a way, s/he will if that vector delivers any advantage.

One my working mantras is, “think like an attacker, but question like a team mate”. In a subsequent post, I’d like to take this subject up more deeply as it is at the heart of what we have to do.

And, as I wrote above, because of this necessity to apply security architecturally, security architects may be among your first system architects! “Necessity is the mother of invention”, as they say.

Security architecture may lead other domains or the enterprise practice. I remember in the early days that we often grumbled to each other about having to step into a broader architecture role simply because it was missing. In order to do our job, we needed architecture. In the absence of such a practice, we would have to do it for projects simply because we, the security architects, couldn’t get our work completed. We’d step into the breach. This may not be true in your organization? But in my experience, this has been a dirty little secret in more than one.

So, if you’re looking to get architecture started in your IT shop, see if the security folks have already put their toes in the water.

In the last year, I believe that a consensus is beginning to emerge within the security industry about security architecture. I’ve seen a couple of papers recently that are attempts to codify our body of practice, the skill set, the process of security architecture. It seems an exciting and auspicious time. Is security architecture finally beginning to come of age?

The time seems ripe for a summit of practitioners in order to talk about these very issues. It’s great that SANS is pulling us together next week in Las Vegas, What Works In Security Architecture. Yours truly will be speaking a couple of times at the summit.

Please join me next week, May 24-26, 2010 in Las Vegas. Engage me in lively and spirited dialog about security architecture.

cheers

/brook