Blog

Words matter: You stop attacks, not breaches

By Mike Rothman

Every so often, the way security marketeers manipulate words to mislead customers makes me cringe. I’m not going into specifics because that isn’t the point. I just want to clear up some terminology that many security companies misuse, which really makes them look silly.

Security marketeers behave. That is the impossible dream. For example, security companies (who will remain nameless) have talked about how they could have stopped the RSA breach, if only you used their widget, device, god-box and/or holy grail. But this seems to require violation of the space/time continuum. Either that or Dr. Brown is at it again and the DeLorean hit 88 mph. Breaches happen only when data is actually lost. At least that’s how I define a breach. If the attack is not successful, it’s not a breach. It’s just an attack.

Yes, I’m splitting hairs, and maybe these are my own definitions. Maybe we can come up with a standard definition for the term. A breach involves data loss, not the potential for data loss, right? The words matter. I’m a writer, and a big part of the Securosis value proposition is cutting through the crap and telling you what’s real and important. We pride ourselves on vilifying marketing buffoonery, mostly because we all deserve better.

Come to think of it, I also object to the idea that any technology is going to “render the APT useless.” Yes, I took that right off a vendor’s invitation to a webcast. I have to wonder how they do that. Given that persistent attackers are, well, persistent. Maybe the vendor in question could have stopped the specific attack launched against RSA. But I assure you they cannot stop every attack. Therefore, they are not rendering much of anything useless. Except maybe their own credibility.

Having spent quite a while in a VP Marketing role, I understand the game. The vendors need to rise above the noise and create a reason for a prospect to engage. So they manipulate words and don’t say anything that is provably incorrect, but the words sure are misleading. They count on the great unwashed not understanding the difference, and cash the check long before the customer has a chance to realize they just installed modern-day snake oil in their networks, on their endpoints, and in their data centers. We deserve better. Where is the Straight Talk Security Express when you need it? Oh yeah, that didn’t work out to well for Senator McCain either, did it?

Yes I know. I’m tilting at windmills again. Dreaming the impossible dream. Sancho just gave me that “you’re an idiot” look again because this won’t change anything. The marketers will make their technology seem much bigger than it is. The sales folks will promise users that their products will actually solve whatever problem you have today. The customers will smile, write more checks, and wonder why their customer database keeps showing up on grey market sites in Estonia.

It’s the game. I get it. But some days it’s harder to accept than others. This is one of those days. Guess it’s time to get back on my meds.

Photo credit: [Don Quixote and Sancho Panza] originally uploaded by M Kuhn

No Related Posts
Comments

>>
Regardless of ignorance and arrogance (thanks ds), I actually think this discussion is important. Security professionals are hammered with messages from vendors all day long promising this and promising that. Unfortunately without a common vernacular, many of these claims are at best baseless, at worst disingenuous.
<<

=)

I agree that the discussion is important, but I think focusing on the vendor message misses the target. 

I think a good discussion needs to be had along the lines of:

First, How does/should a security professional determine their need for a product or service?  I.e., how do they properly identify the problems at hand and recognize that they cannot solve them alone.  This is the catalyst to becoming receptive to vendors and puts us in control of our destiny rather than at the whim of marketing. 

Second, what are good practices or habits that they should use in evaluating the promises that those products and service make (more than just interpreting marketing speak)  Sure, you can advocate for a common vocabulary, but the problem is really about “is that vocabulary being used honestly” or are vendors obfuscating. 

-Once a product/service is selected, installed and operational, how does the security professional determine if it actually lives up to its promises.  I.e., is the problem being solved?

-Finally, as a feedback to the process, how does the security professional validate that the problem at hand was worth solving in the first place.  How are we better now that this product is in place or the service was delivered?  How are we worse? 

Just parsing breach versus attack or other vendor hype doesn’t really advance the ball, IMO.

By ds


I like @andrew’s definition the best. I think that sums it up and what I was trying to communicate.

Regardless of ignorance and arrogance (thanks ds), I actually think this discussion is important. Security professionals are hammered with messages from vendors all day long promising this and promising that. Unfortunately without a common vernacular, many of these claims are at best baseless, at worst disingenuous.

As mentioned in the post, I understand the game. I also understand (and advocate) every security professional take a very skeptical view on pretty much every marketing claim. But we only have so many readers and it’s a big world out there. So if I can agitate for some common vernacular, I think that’s worth doing.

I understand these “strawman” arguments can be frustrating to those upper echelon professionals, who understand what is crap and what is reality. But I’m still going to put them forth to spur discussion, call out marketing chicanery, and to vent at times.

By Mike Rothman


Is it necessary to lose data for it to be considered a breach? 
I would contend that “merely” penetrating the security perimeter would constitute a breach.  As an analogy, breaking down a door, entering the premises, and poking around *is* a breach, even if the burglar did not take anything.

By mugabo


You are also making two common mistakes,

First, assuming that everyone is using the same meaning for words and second that your meaning is the only one that is accurate. The first is ignorance and the second is arrogance.  Neither are good. 

As I see it, a breach is a violation of the security requirements.  It doesn’t mean data was lost.  There are other security requirements besides confidentiality, after all.

You guys really need to stop with the strawman arguments.  So many of the posts here are very informative and insightful, but those like this are of little value.

By ds


I think I get your point.  By your definition a breach occurs once data has already been lost. Thus by the time you can use the word breach to describe what happened it’s too late to stop.

However, I don’t believe that’s the most commonly used definition of a breach. I’ve most frequently heard breach used to describe a gap or hole. In the context of an attack it is a hole through which attackers advance. If you look back to the middle ages there was definitely reason for alarm if attackers had breached the walls but that didn’t mean the attackers had already achieved their intended goal.

Speaking of goals what if the attackers isn’t out to take your data? What if they’re there to add falsified data? What if their goal is to insert malicious code to disrupt internal systems that wouldn’t normally be affected by a DOS attack on external systems? In each of these situations security measures must be breached for the attacker to achieve their goal.

It doesn’t make sense to limit the use of “breach” to describe the act of “loss of data to an attacker”. If we take a perfectly cromulent word to describe a hole through which attackers advance and use it to describe something else what word do we put in its place?

Additionally, I think that information security professionals don’t have the ability to stop an attack. Attacks can be thwarted so they don’t succeed but once an attack has been started the attacker is the only one who can directly decide whether they’re going to stop.

Actually, I think that this is the key takeaway from your post. The APT is not going to be stopped by any set of technologies. Nor are they going to be stopped by anything you do. You can merely dissuade, interrupt and track specific attack behaviors and mitigate the effects of a breach. Although that doesn’t make for a very good article title.

Of course all of this applies only if you’re dealing with attacks from hackers. If you’re dealing with an attack from crackers a whole different set of definitions applies ;)

By BenRifkah


Putting my (flameproof?) pedant hat on, I’d suggest the terminology should be: We *block* an attack, which *prevents* a breach. That blocking may persuade the attacker to *cease* the attack.

By Andrew Yeomans


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.