Now we're into a world where asking companies to pay you millions for a massive PPT slide deck that says, "This is your company now and this is what your company should look like tomorrow," is simply a non-starter. So while the tech-heavy firms like Accenture and Cap Gemini do well at the bottom and the high-end starts like the Monitor Group do well at the top of the pyramid, a lot of mid-range, standard cookie-cutter management consulting firms are seeing their market decline. Everyone wants the super-integrated solution now that combines compliance, security, systems-integration, performance metrics—and they want it delivered in a service-oriented architecture that frees companies up to evolve in ways commensurate with globalization's many demands and opportunities.

I see efforts in all the compliance, security, systems-integration, performance metrics, and SOA rabbit holes. I don't see very much unification. In my swamp - SOA security. I do see a lot of starter efforts where companies build out services, but forget the security -  and then either an auditor comes asks "so how are you doing authN and authZ for your web services" or a security event happens, or a diligent director comes along and asks variant of the auditor question. Then some things start to happen, usually a purchase of a XML gateway, but Data Power, Vordel and Cisco can't help you if its just shelfware.

Integration is inherently difficult and messy. Information security groups need to get good at engaging with development and architecture in a proactive way to deiver these security services to the system. I call it "playing offense", infosec spends most of its time defending against bad guys, and that is ok, it is a huge part of infosec's job, but sometimes you need to go on offense and raise the bar. Make the bad guys' job harder, build security in.

In plain English, clickjacking lets hackers and scammers hide malicious stuff under the cover of the content on a legitimate site. You know what happens when a carjacker takes a car? Well, clickjacking is like that, except that the click is the car.

"Clickjacking" is a stunningly sexy name, but the vulnerability is really just a variant of cross-site scripting. We don't know how bad it really is, because the details are still being withheld. But the name alone is causing dread.

The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

This essay previously appeared on Wired.com.

The details of the vulnerability aren't important, but basically it's a form of DNS cache poisoning. The DNS system is what translates domain names people understand, like www.schneier.com, to IP addresses computers understand: 204.11.246.1. There is a whole family of vulnerabilities where the DNS system on your computer is fooled into thinking that the IP address for www.badsite.com is really the IP address for www.goodsite.com -- there's no way for you to tell the difference -- and that allows the criminals at www.badsite.com to trick you into doing all sorts of things, like giving up your bank account details. Kaminsky discovered a particularly nasty variant of this cache-poisoning attack.

Here's the way the timeline was supposed to work: Kaminsky discovered the vulnerability about six months ago, and quietly worked with vendors to patch it. (There's a fairly straightforward fix, although the implementation nuances are complicated.) Of course, this meant describing the vulnerability to them; why would companies like Microsoft and Cisco believe him otherwise? On July 8, he held a press conference to announce the vulnerability -- but not the details -- and reveal that a patch was available from a long list of vendors. We would all have a month to patch, and Kaminsky would release details of the vulnerability at the BlackHat conference early next month.

Of course, the details leaked. How isn't important; it could have leaked a zillion different ways. Too many people knew about it for it to remain secret. Others who knew the general idea were too smart not to speculate on the details. I'm kind of amazed the details remained secret for this long; undoubtedly it had leaked into the underground community before the public leak two days ago. So now everyone who back-burnered the problem is rushing to patch, while the hacker community is racing to produce working exploits.

What's the moral here? It's easy to condemn Kaminsky: If he had shut up about the problem, we wouldn't be in this mess. But that's just wrong. Kaminsky found the vulnerability by accident. There's no reason to believe he was the first one to find it, and it's ridiculous to believe he would be the last. Don't shoot the messenger. The problem is with the DNS protocol; it's insecure.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

That's what a good design looks like. It's not just secure against known attacks; it's also secure against unknown attacks. We need more of this, not just on the internet but in voting machines, ID cards, transportation payment cards ... everywhere. Stop assuming that systems are secure unless demonstrated insecure; start assuming that systems are insecure unless designed securely.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Now, those of you who know me are probably picking your jaws up off the floor and asking whether I’ve suffered a stroke, have started drinking heavily, or have a gun pressed to my temple by a regulator or someone from the PCI lobby.  Nope.  I still have my full mental facilities (such as they are), and I make the statement without duress — however…

There’s compliance, and then there’s compliance

As usual, our profession tends to not be specific in our use of terms, which sets us up for confusion, inconsistency, and a host of other problems.  When I say “compliance is critical”, I don’t mean compliance with some external standard like PCI, ISO, or some hypothetical “best practice”.  I mean compliance with an organization’s own policies and standards.  Compliance with external standards has its place too (unfortunately), but we’ll pick that up in another post.

Think about it…

In most cases, if an organization was completely, 100% compliant with its own policies and standards, it would almost certainly have a much lower level of risk exposure than most other organizations.  In fact, in many cases a 100% compliant organization would be too secure to operate effectively.  In other words, the more significant problem isn’t typically a matter of how strong a policy is, it’s the variance from intended/desired state that’s described by policy.

In a perfect world…

The illustration below is intended to represent a “perfect world” condition, where all of the assets/systems/whatever are compliant with an organization’s policies/standards.  It also reflects the fact that there is no perfect security, and that the organization has wisely established its policies/standards with an acceptance of some degree of vulnerability (and thus, risk).

The real world tends to be much different

The illustration below represents a more likely condition, where controls applied to a population of assets/etc. tend to vary from what policy calls for.  It also reflects the effect that has on vulnerability, which in turn affects risk.

But we knew this already, right?

Yes, it’s true that 99.9% of us already know that variability exists and that it’s bad from a risk perspective — so what’s my point?  My point is that variance is one of the most important risk-related metrics we have available to us.  Here’s why…

As we see from the illustration above, variance from policy can be a strong indicator of an organization’s risk exposure.  At the same time, it’s also a marvelous indicator of an organization’s ability to manage risk (i.e., decision making capabilities and/or the ability to execute against decisions).  A little root cause analysis of a highly variant asset population can provide critical insights into what’s not working, which can lead to far more cost-effective risk management measures.

One example of where this could be applied is in the evaluation of a third party’s risk posture.  Rather than send a 60 page questionnaire, why not evaluate the organization’s compliance with its own policies across a cross-section of its information risk landscape.  I submit that it would provide a more accurate and useful picture of risk exposure and risk management capabilities than the typical questionnaire, at less cost/effort to both parties.