Executive Information Security Risk Dialog

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.



System Architecture: Fascinating People Forming Relationships

Fascinating People, Forming Relationships

I’m in Bangalore for a week or so. I’m here for a couple of purposes: I’m spreading the word about our new Application Vulnerability Assessment programs. And, I’m here to talk about Security Architecture as a practice, as a career. Our security department’s team here in Bangalore are wonderful engineers, young, full of energy, enthusiastic. But there aren’t any Security Architects here. So, our global security architecture practice is hampered by the lack of presence in this theater.

Hence, I’ve been here explaining, demonstrating, yes, stumping a bit.

I’ve been staying with a friend from work who’s here managing this team. He’s been hosting me in his home – I much prefer getting to know his family rather than staying in a hotel, no matter how plush the accommodations. A bed and a shower are about all I require. There’s no accounting for personal tastes, eh?

And, here’s where my story takes an interesting turn.

Traffic is tough in Bangalore. You’ll be crossing a congested bridge, and cars and especially motorcycles supposedly on the other side of the road will take one or more lanes out of your side, oncoming, willy, nilly. Driving lanes are not respected; as many vehicles as will fit side by side, with inches to spare, will be filled. Beware of any empty space, as it will be filled by vehicles trying to get a leg up, crowding to the “front” of the line. Though in this traffic, where exactly would be the “front”?

So, I’m happy to be driven by an expert in this traffic. And, our company does not allow staff posted to work here to drive. The company pays for a driver. The risk of accident is just too high. It’s cheaper to let a professional do the driving.

I’ve had a lot of interesting conversations with my host’s driver. And his story is what I want to share. Let’s call the driver Raju (to protect him and his privacy).

Ragu is a wonderfully sweet man, mid-thirties, dedicated to his family, hard working and conscientious. His driving, at least to my eyes in the rather chaotic and dangerous Bangalore traffic is highly professional, careful and as considerate as one can be here where traffic courtesy is taken as a sign of weakness of which to take advantage. The traffic here is scary to my West Coast USA driving habits. I would not get behind the wheel of a vehicle here, glad to let someone else handle it for me.

So, one might assume that Ragu is satisfied with his life, basically, as a chauffeur? Yes, and, here’s where some of the most important principles of Security Architecture comes into play.

  • Never assume what you don’t know: dig deeper, get the whole story
  • People matter; we are not replaceable objects
  • Effectiveness = Relationships
  • Trust is built
  • Authority is earned

I’ve been reminded about the importance of being an advocate for the success of people we meet. Let me tell you about Ragu.

Being a chauffeur is a rather new occupation for Ragu, a couple of months only. He has done many things:

  • A guitarist
  • A real estate finder
  • A builder

He’s faced down a local gangster group who threatened his family. Whew! But that’s not all.

Ragu was supervising the building of a home for someone else. In that area, he payed the women working for him a living wage, comparable to the men on the job. Then, some of the local villagers threatened his life for paying those women enough to survive. The villagers preferred the usual state of affairs where women are beneath men, kept in servitude, unable to make a living.

These villagers literally surrounded Ragu with big sticks, beating on his vehicle, threatening his life. Yikes!

So Ragu has seen some life, been through serious challenges. Perhaps a bit more than facing down a couple of enterprise Directors who don’t like one’s risk assessment, don’t you think?

OK. So why am I sharing this?

Because this is not the whole story.

Ragu is a product of the child labor market in India. His very poor family pulled him out of school at 9 years old. He was sent to a clothing factory to labor for 5 rupees each week, 1 rupee for a whole day’s work, at the tender age of 9 years old.

Still, the human spirit is indomitable.

Ragu is working on his bachelor’s degree. He continues to study the guitar. All this while driving a family around and raising his own children.

And, Ragu and I had a great conversation about getting started on a technical career. Ragu has aspirations. Because, it is impossible on a chauffeur’s salary to purchase a home in India.

I won’t go into my ideas about shifting into a technical career track.

What is important to me is that I’ve helped someone perhaps see his way to achieve his goals. And, what may not be obvious is that I’ve established a firm relationship which time and distance can’t destroy. Who knows? I may never see Ragu again. And that’s fine.

Still, through seeing the whole person, taking the time to understand, not the surface, but the whole story, I’ve established relationship. Rather than taking things at face view, I was curious, concerned, and one Ragu’s side for his aspirations.

I hope that I can say that Ragu and I are friends? And friends help each other.

Now please understand, I don’t think at this point that I need much from Ragu. His job demands that he drive me where I need to go, anyway. That’s not the point of this writing.

I’ve got a friend, a compatriot. I went out of my way to understand, to give what I have, little or great, to look through Ragu’s eyes. And I know in my heart that we can help each other, and that we will, if called upon.

And that value cannot be purchased. It has to be earned.

So it is in the practice of security architecture. My relationships are more than 50% of my practice. Trust is always earned. Relationships are built. I’m here at a conference on Enterprise Architecture put on by The Open Group. I’ve run in to one of my work compatriots, Srikanth Narasimin. We’ve walked together through some very difficult moments on projects. We have rather deep earned trust (I hope he would agree?).

So, we can at a very fast pace, figure out a problem (we just did on this on a troubled huge initiative on the job) There’s a lot of shared reference and resonance.

One achieves this kind effectiveness, I believe, by stressing the human side as much as technical depth and leadership. Srikanth and I can move fast because of our relationship, a relationship built up through projects, efforts, trust, listening to each other, seeing each’s point of view, understanding background information and how that influences that which is under discussion. Srikanth knows that I’m on his side, even if we disagree in this moment about a particular thing. Our larger resonance gives space for conflict resolution.

Again, you can’t purchase a relationship like this. A fancy title conferred by management won’t build this authority. These are built and earned.

I like to say that Security Architecture is at least one half people-centered. If you don’t like people, you won’t be happy as an architect. One has to be able to effectively interact with and influence:

  • Management
  • Other system architects
  • Implementors
  • Project Managers (“PM”) and others driving projects directly
  • Those charged with executing procedural operations and those charged with creating procedures and processes

I interact with these categories every day. If I specify something that cannot be done, it won’t get implemented. If I don’t understand the viewpoint and needs of each stakeholder, there’s no way that I can specify security requirements that will meet business need and which will be acceptable.

Interacting with Ragu reminded me that my effectiveness is directly related to my ability to form and sustain relationships. And relationships are built not by what I know, but what I hear and understand, my interest and concern.

As a practice, if I can, I make a practice of finding out about the personal life and concerns of the people with whom I work, as they choose to share. It’s a beginning place from which to start.

And, circling back to Ragu’s story, he told me, “I will never allow my children to be forced labor. They will get an education.” And so the world changes, yes?


/brook from Bangalore, India

The SANS Application Security Summit

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?