Category Archives: Conferences

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

Executive Information Security Risk Dialog

Posted on by

Ah, sigh, Marcus and I almost never agree! And, this often a matter of lexicon and scoping. In this case, Marcus stays away from the thorny issue of risk methodology. But this, I think, is precisely the point to discuss.

Think about the word “risk”. How many definitions have you seen? The word is so overloaded and imprecise (and undefined in Marus’ Rant) that saying “risk” without definition will almost surely undermine the technical/C-level management dialog!

I would argue that the reasons for failure of the security to executive risk dialog have less to do with C-level inability to grasp security issues than it has to do with our imprecision in describing risk for them!

Take Jack Jones. When at Nationwide, he found himself mired within Ranum’s rant. I’ve been there, too. Who hasn’t?

To solve the problem and feel more effective, he spent 5 years designing a usable, repeatable, standardized risk methodology. (FAIR. And yes, you’ve heard me rant about it before)

Jack described to me just how dramatically his C-level conversations changed. Suddenly, crisp interactions were taking place. What changed?

I see the failure of the dialog has having these components:

  • poor risk methodology
  • poor communication about risk
  • not treating executives as executives

Let me explain.

Poor risk methodology is the leading cause of inaccurate and unproductive risk dialog. When we say “risk” what is our agreed upon meaning?

I’ve participated in many discussions that treat risk as equivalent with an open vulnerability. Period.

But, of course, that’s wrong, and actually highly misleading. Is “risk” a vulnerability added to some force that has motivation to exercise the vulnerability (“threat” – I prefer “threat agent” for this, by the way)? That again is incomplete – but that is often what we mean when we say information security risk. And, again, it’s wrong.

In fact, as I understand it, threat can be conceived as the interaction between the components that create a credible threat agent who has sufficient motivation and access in order to exercise an exposed vulnerability. This is quite complex. And, unfortunately, the mathematics involved may be beyond many security practitioners?> Certainly, when in the field these mathematics may be too much?

Most of us security professionals are pretty good on the vulnerability side. We’re good at assessing whether a vulnerability is serious or not, whether its impact can be far-reaching or localized,  how much is exposed. It seems to me, that it’s the threat calculation that’s the difficult piece. I’ve seen so many “methodologies” that don’t go deep enough about threat. Certainly there are reasonable lists of threat agent categories. And, maybe the methodology includes threat motivation. Maybe they include capability? But motivation, capability, risk appetite, access? Very few. And how do you calculate these?

And then there’s the issue of impact. In my practice, I like to get the people close enough to business to assess impact. That doesn’t mean I don’t have a part in the calculation. Often times the security person has a better understanding of the potential scope of vulnerability and the threats that may exercise it than a business person. Still, a business person understands what the loss of their data will mean. However impact is assessed, it has a relationship to the threat and vulnerability side. Together these are the components of risk.

I think in this space, it probably doesn’t make sense to go into the various calculations that might go into actually coming up with a risk calculation? Indeed, this is a nontrivial matter, though I have made the case that any consistent number between zero and one on threat and vulnerability side of the equation can effectively work. (But that’s another post about the hour at an RSA conference presentation that helped me to understand this little bit of risk calculation trickery.)

In any event, hopefully you can see that expressing some reasonable indication of risk is a nontrivial exercise?

Simply telling an executive that there is a serious vulnerability, or that there’s a flaw in an architecture that “might” lead to serious harm waters down the risk conversation. When we do this, we set ourselves up for failure. We are likely to get “I except the risk”, or, an argument about how serious the risk is. Neither of these is what we want.

And this is why I mention “poor communication of risk” as an important factor in the failure of risk conversations. Part of this is our risk methodology, as I’ve written. In addition, there is the clarity of communication. We want to keep the conversation focused on business risk. We do not want to bog down in the rightness or wrongness of a particular project or approach, or an argument about the risk calculation. (And these are what Ranum describes) In my opinion, each of these must be avoided in order to get the dialog that is needed. We need a conversation about the acceptable business risks for the organization.

Which brings me to “treating executives as executives”. When we ask executives to come down into the weeds and help us make technical decisions we are not only inviting trouble, but we are also depriving ourselves and the organization of the vision, strategy, and scope that lays at the executive level. And that’s a loss for everyone involved.

I think we make a big mistake asking the executive to assess our risk calculation. We should have solid methodologies. It must be understood that the risk picture were giving is the best possible given information at hand. There needs to be respect from executive to information security that the risk calculations are valid (as much as we can make them).

No FUD! Don’t ask your executives to decide minor technical details. Don’t ask your executives to dispute risk calculations. Instead, ask them to make major risk decisions, major strategic decisions for your organization. Treat them as your executives. Speak to them in business language, about business risks, which include your assessment about how the technical issues will impact the organization in business terms.

I’ve been surprised at how my own shift with respect to these issues has changed my conversation away from pointless arguments to productive decision-making. And yes, Marcus, amazingly enough, bad projects do get killed when I’ve expressed risk clearly and in business terms.

Sometimes it makes business sense to take calculated risks. One of the biggest changes I’ve had to make as a security professional is to avoid prejudice about risk in my arguments. Like many security folk, I have a bias that all risk should be removed. When I started to shift to that, I started to get more real dialog. Not before.

So, Marcus, we disagree once again. But we disagree more about focus rather than on substance? I like to focus on the things that I can change, rather than repeating the loops of the past endlessly.

Cheers,

Brook

Architect Surprise!

Posted on by

Architect Surprise!

“Architect Surprise” is what I had last Thursday.

No, it’s not a new recipe. Nor is it a building whose structure is shocking. Although most certainly I was surprised enough to sit up and take notice.

I had been attending a series of security meetings where we agonize over the information security issues that are most on our minds.

I’ve been working with this group for 3-4 years. I find baring my security soul to peers and betters deeply helps my practice. And, if I’ve learned something, I’m happy to share any tidbits that I’ve gleaned so that we don’t all make my mistakes. Information security is just plain hard! (my 2 cents)

I can’t tell you who attends these meetings or who runs them.

Still, the facilitators are amazing professionals who work to help us enlighten each other. Let’s just say that it’s the CISOs (Chief Information Security Officers) or their direct reports for a lot of companies you’ve heard of and a few that maybe you haven’t – but they’re all at enterprise level. We have a strict “what is said in the room stays in the room” policy. And I intend to fully honor both the letter and spirit of that agreement.

I’m often the lone techie in the room. I’m not at all sure why these folks tolerate me? But they have been wonderfully open to me, and I deeply appreciate both their confidence, their help and in many cases, the friendship that has been given to me.

Thursday, we had a panel on “generation Y” in the workplace. An erudite and articulate group of folks was assembled to answer our questions. (Most of the usual attendees of the meetings are at least older than Gen-X, smile)

My architect surprise happened almost at the beginning. 2 of these folks, one of whom has been in the workplace for 3-4 years and another person that she recently helped to hire are “Solutions Architects” at a big insurance company.

Wow! At the company for whom I work, “Solutions Architect” is almost as high as one can go. technically.

So, I thought, maybe they’re just using this term in a really different way that I’m used to? I let it go and got on with the panel.

Then, later, it became clear that indeed, they probably did use the term “systems architect” as I know it. I don’t know what they mean by “solutions” and expect that there is some semantic difference?

However, even having someone straight from school (Masters, EE) fulfuill the role of architect I think is generally not a good idea.

I want to be clear that my worry has nothing to do with age, though level of experience is very key.

And here is why: I have long preached that systems architecture practice really requires someone to be deep in at least 2 technical areas. When I write “deep” I don’t mean “studied in school” or “majored” or “masters degree”.

I mean, “practiced successfully”.  I mean, deep, as in, understands an area fully to a core level of practice and broadly across most common cases.

And, I’m sorry, young readers – that kind of experience is very hard to get without a practicum. It takes years. I don’t think it’s easy to short-cut the process.

Not that there can’t exist the odd talent who gets deep early and quickly. The extraordinary does manifest.

But most of us mortals have to live and work to gain our depth.

Why at least two areas?

Because I have seen that something magical and unexpected happens after the second deepening. Even more so on the third, the fourth. Besides, with each area, the next gets easier and faster.

It is the ability to identify and make use of patterns. And patterns are the basis for systems architecture. Not rules. Not following guidelines (architects create these from use patterns) Patterns. Design patterns. Data flow patterns. Communications patterns. Security control patterns.

I have watched great engineers founder as architects. Not everyone is cut out for noting and using abstract patterns, for identifying and working through the relationships between system components.(but that’s a different post)

Systems architecture isn’t about code modules and interfaces. Although that is wonderful place to build (and deepen) design skills. It’s the “school of hard knocks” where I did a great deal of my learning. But systems architecture steps above that to a greater level of abstraction (and sometimes to a much greater level of complexity).

No, I wouldn’t  push my fresh-out-of-school recruits into an architect position. It’s not fair to them. And it’s not fair to the practice.

One of the panelists was delighted to have been given the chance to be an architect straight out of school. But I think she’s missing something important – her practicum that will set her free to design well, perhaps even innovatively.

I believe that systems architecture requires breadth and depth. This can only be won through time, successes, and the all important mistakes and missteps.

cheers

/brook

Another Synchronistic Coincidence

Posted on by

What’s the difference between influence and collaboration?

I might begin to believe that I’ve come to a conference of salespeople, not enterprise architects. Sheesh.

(I have nothing against influence by salespeople. No commercial organization can be successful without salespeople. Having once done sales, I have a deep appreciation for the profession; I’m not very good at sales)

When we sell, we “influence”. We have an idea which we are trying to get others to agree with, or product to buy.

And certainly, architects must be influential, persuasive. But I do not believe that “influence” is at the heart of architecture. Influence is a byproduct of successful collaboration. We hone the architecture until it meets the requirements. We incorporate stakeholders’ concerns. Selling is not the operative action, in my opinion.

Rather, I believe that what we architects do is synthetic, perhaps highly synthetic?

If we’ve done our job correctly, when our architecture is successful, we will need no pitch. Or, we must bring the bad news that requirements cannot be met, that tough decisions need to be made.

I just posted to this blog about the importance of forming and maintaining relationships based upon understanding, trust, and mutuality.

Since writing that post, I’ve been sitting in presentation after presentation by enterprise architects. And most of them have pointed to “influence” as a key factor of our practice. But none of them has used the word “collaboration”. None have spoken about relationship building, about understanding as a fundamental prerequisite to “influence”

I would fault the presenters at this conference with missing the point. Influence cannot be thought of by itself. It’s a product. Influence comes naturally from acquired trust and earned authority.

Otherwise, our work as architects is a one-way monologue. And I cannot understand how a monologue produces architecture in an enterprise.

I believe that it’s the interaction, both our influence and the understanding of the needs and influence of our stakeholders that drives the relationships that are fundamental to the acceptance of system architecture in the enterprise.

I can’t believe that I had just written about this subject?!? Synchronicity in action.

cheers

/brook from Bangalore, India

The SANS Application Security Summit

Posted on by

Two days, about 20 speakers, all the major tool makers, pundits, researchers, penetration testers, this summit was almost a who’s who of application security. SANS wanted to kick-off their new GIAC application coding certification. And, along with that, they wanted to take a pulse of the industry. I was privileged to be included on a couple of panels – there were frighteningly smart people speaking – country mouse playing with the city cats, definitely!

A couple of my colleagues sat for the exam. I once held GIAC Intrusion Detection certification (#104?) but I let it lapse. (It’s not really relevant to what I do now) My buddies said it was a reasonable exam. The exam covered implementing security controls from the language APIs (java – JAAS calls) and coding securely.

The larger issue is what can we make out of this certification? How much effect will it have? Will getting coders certified change the landscape significantly?

There was plenty of FUD from the toolmakers. Yes, the entire web is vulnerable, apparently. Ugh! You probably knew that already, huh?

The numbers of applications out there is staggering. Estimates were running in the 100 millions. That’s a lot of vulnerable code. And, considering that my work’s DMZ takes a 6 million attack pounding every 24 hours, it’s not too far a stretch to assume that at least a few of those attacks are getting through. We only know about the incidents that are reported or that cause damage (as pointed out in the Cenzic report released at the Summit)

And, it seems like the financial incentives for exploiting vulnerabilities are maturing? (a google search will reveal dozens of financially motivated hack reports) If so, cash incentives will likely increase the number of incidents for all of us. Another big sigh.

One of the most interesting speakers to me at the conference was Dinis Cruz, CTO of Ounce Labs. A couple of times, he pointed out that while yes, we are being hacked, there’s no blood on the floor. Nobody’s been killed from a web hack (thank goodness!) We (inductries that use the web heavily) are losing money doing damage control, making up losses (especially, the financial industry), and doing remediations. Absolutely true.

But has anyone done an analysis of what the risk picture looks like? Is web exposure worth it? Are we making more than we’re losing? So much more that, like actuaries, the risks are worth it?

I know this question may seem crazy for someone from inside the information security industry to ask? But, anyone who knows me, knows that I like to ask the questions that aren’t being asked, that perhaps might even be taboo? We security folk often focus on reducing risk until we feel comfortable. That “warm and fuzzy”. Risk is “bad”, and must be reduced. Well, yeah. I fall into that trap all too often, myself.

It’s important when assessing a system to bring its risk down to the “usual and acceptable” levels of practice and custom of one’s organization. That’s at least part of my daily job.

But appropriate business risk always includes space for losses. What’s the ratio? Dinis definitely set me to considering the larger picture.

My work organization takes in more than 90% of its revenue through web sites. As long as loss is within tolerable limits, we should be ok, right? The problem with this statement comes with a few special classes of data compromise. These can’t be ignored quite so easily (or, the risk picture needs to be calculated more wholistically)

• Privacy laws are getting tougher. How does one actually inform each of 38 States Attorneys-General first? And, the Japan law makes this problem seem trivial.
• Privacy breaches are really hard on customer goodwill. Ahem
• Internet savvy folks are afraid of identity theft (again, a personally identifying information (PII) issue). The aftermath from identity theft can last for years and go way beyond the $50 credit card loss limit that makes consumer web commerce run.

I’ve got friends working for other companies that are dealing with the fall-out from these sorts of breaches. It ain’t pretty. It’s bad for organizations. The fall-out sometimes dwarfs the asset losses.

And, if I think about it, about all the vulnerabilities out there, are we each just one SQL injection exposure away from the same? Forget the laptop on the car seat. PII is sitting on organization database servers that are being queried by vulnerable web applications.

Considering this possibility brings me back to the importance of application security. Yes, I think we have to keep working on it.

And, our tool set is immature. As I see it, the industry is highly dependent upon people like Dinis Cruz to review our code and to analyze our running applications. I don’t think Dinis is a cheap date!

So, what to do?

I’ll offer what John Chambers, CEO of Cisco Systems, Inc., told me. (no, I don’t know him. I happened be in the same room and happened to have him take my question and answer it. Serendipitous circumstances). “Think architecturally”

That is, I don’t think we’re going to train and hire our way out of the vulnerability debt that we’ve dug for ourselves with 100 million apps on the web being vulnerable. Ahem. That’d take a lot of analysis. And, at the usual cost of $300/hour, who’d have the resources?

I’ll offer that we have to stop talking about and to ourselves about the problem and get it in front of all the stake holders. Who are those?

• The risk holders (i.e., executive management)
• Our developer communities (SANS certification is certainly a start. But I think that security has to be taught as a typical part of proper defensive programming. Just like structuring code or handling exceptions, input must be validated.)
• Security as an aspect of system design and architecture. Not that cute box along the side labeled “security” in the logical architecture diagram. Rather, we need to treat each security control as components of the system, just like the other logical functions.

Which brings me back to the SANS Summit.

My sense of this summit is that we haven’t yet reached the tipping point. I didn’t speak to everyone there. But I spoke to a fair share (I won’t call it a sample. My conversations were hardly statistical in nature!)

Most folks with which I chatted were like me, in the trenches. We had a few formidable notables in the room, and, of course, I think there were a few beginners, as well. My guess is that most branches of the industry were represented: tool makers, consultants, Information security folk, with a sprinkling of governmental folk thrown in. The folks that I spoke to understood the issues.

If I could hazard a guess, the folks who made the time to come are the folks concerned and/or charged with, or making money out of, application security. In other words, the industry. We were talking to ourselves.

That’s not necessarily a bad thing. I’m guessing that most of us have been pretty lonely out there? There’s validation and solidarity (leftists, please forgive me for using that term here – but it does fit!) when we get together. We network. We test our ideas and our programs. That’s important. And, I heard a few really great ideas that were fresh to me.

But I think we need to take this out a good deal further, to a “tipping point” if you will, in order to move the state-of-the-art. And, I don’t think we’re there yet. Consider, if you will, how many programmers are writing web code right now?

What do you think?

cheers

/brook

A Beginning

Posted on by

Sitting on a plane from Washington DC, USA, to my home in Oakland, California, I’m thinking about the SANS Application Security Summit that I just attended. What are the implications of this gathering, at this time? This seems like a propitious time to open a personal blog on information security. Some new winds may be bBrook, in the Netherlandslowing? Perhaps this summit is a the beginning of a sea change?

I’ve repeatedly thought that I’d like to share thoughts on the development of my industry. It’s exciting to me, certainly frustrating, sometimes even frightening.

Perhaps like many of you readers who work in Information Security, I spend my days  helping folks manage their digital risks? And probably, like you, I’m not always successful? Perhaps IT can’t field the technology required? Or, providing security requirements is seen by as an undue burden that cannot be borne at this time?

Still, when I understand that the stake holders feel that due diligence has been served, that an appropriate risk posture has been taken, it’s a good day. Small victories, even though our technologies are often immature or mis-applied, our processes insufficient, and our art, developing. And, of course, very occasionally, I help to identify and eventually close a major gap. Job satisfaction, absolutely.

Does any of this ring any bells or resonate for you?

Occasionally, a flash of incite will come to me. And clear as mud, I suddenly sense a possibility for us to perhaps advance our art just a wee bit. I’ll share those here for your consideration and comment. While I do occasionally publish papers and speak at conferences (as I did these last 2 days), I intend to use this forum for my tentative possibilities, not for my certainties, which are generally few, anyway.

Months will go by in the daily round of meetings, risk assessments, security requirements, system architectures, and design comments. During these periods, I may choose to be quiet, waiting for some inspiration to strike. Please stay tuned.

Perhaps you’ll appreciate knowing that I’m working through the same issues as you? Or, maybe you’ll comment that I’m way off course? I don’t know. I welcome the interchange, in any event. Through dialog, I learn as much, probably more, than I give.

I’ll write more about the SANS Summit in a subsequent entry. But, here’s a beginning…

cheers,

/brook