Now repeat poster, Ben, was chomping at the bit to be share his thoughts on (brace yourself) Cyber War. Further, he wanted it introduced with some AC/DC lyrics from "Thunderstruck". We at least thought we could go with "Let's have a war" by Fear (or A Perfect Circle) instead. Someone should update it for "Let's have a (cyber)war" sometime. With some level of protest... have at it.

...I was caught

In the middle of a railroad track (Thunder)

And I knew there was no turning back (Thunder)

My mind raced

And I thought what could I do (Thunder)

And I knew

There was no help, no help from you (Thunder)

Sound of the drums

Beatin' in my heart

The thunder of guns

Tore me apart

You've been - thunderstruck..

by Ben Tomhave (@falconsview)

I've been reading Richard Clarke's latest book, Cyber War, recently in an effort to delve deeper into the topic. Maybe it's been all the recent inflammatory rhetoric, or maybe it's an earnest interest, or maybe - just maybe - it comes from an innate interest in fighting obtuse uses and abuses of FUD.

The tone of the book initially is far less FUD-y than one might expect. Some of the tech details are clearly off a bit, but overall it's been surprisingly level-headed. Except for the scenarios. These are some of the most over-the-top scenarios I've seen since "digital Pearl Harbor" in 2000. However, in this case it gives me pause, and not just because of the glaring FUD factor.

What I wonder is this: just how much data and control must we lose before we stand up and start taking action? How much proprietary designs, plans, formulas, etc., must be compromised? How many SCADAsystems have to be pwnd? Is it really going to take a massive blackout before energy company execs wake up and smell the ozone?

Clarke asserts that foreign assets already have embedded attack tools ("logic bombs") into many, if not all, critical infrastructures. We've not done an adequate job of supply chain management, so consider that his assertion may, in fact, be fact-based and plausible. Now add factual assertions that massive research databases (academic, government, and corporate) have been copied wholesale by these same foreign assets. Accept this as fact, if you will, and not as FUD. How does this change your perspective on the topic?

The Case For FUD

Taking the previous examples as fact (as an example here - we can debate the depth of pwnage, but I think we can all agree that there are serious concerns here), there may be a valid case for FUDtastic scenarios like the ones Clarke uses in his book. The "digital Pearl Harbor" example of yore is nothing. He puts an interesting spin on it: what if there is reasonable upside to a foreign power to take down our critical infrastructure in a single, well-coordinated attack? What if our assumption of a "cold war" styled standoff (based largely on a belief in economic interdependency) isn't actually valid?

If anybody has attended Black Hat and DEFCON, then they should know definitively just how good the breakers are these days, and just how behind the curve most organizations really are. Pulling out a book like Clarke's can help drive home this point in a wonderfully FUDerific manner. "If you don't fix things NOW, then you will lose everything!!!" Or so it might go in your head. After all, there's nothing like a healthy dose of fear to motivate people. Or does it really work that way?

The Case Against FUD

There are a couple deficiencies with using FUD to make an argument. Excessive and continuous use of FUD can elevate the message to a state of background noise. It can also hurt your credibility. If every time you open your mouth FUD spews forth, then people will tune you out or avoid you. We in infosec - especially vendors - seem to be guilty of this historically, as evidenced by how hard it is to get the attention of execs.

Another problem is context. If everything is expressed as the highest of high risks, then how do you decide how to respond? If everything rates a 10 (on a 10-pt scale), then does that mean everything must be addressed immediately? How do you justify that?

Along these same lines, there's also typically a lack of adequate supporting data to justify the consistently hyped state. Where are the metrics and measurements? Have the risk factors been measured and ranked using a reliable method? FUD tends to not have these supporting structures, which further damages credibility.

"We're So Screwed"

This statement probable summarizes our situation today, at least from the U.S. perspective. How do we get this message across? If we have a high degree of credibility, and if we haven't abused the use of escalated rhetoric, and if we have some facts to back us up, then and only then can we whip out some FUD to make our point (of course, we could debate if this is really FUD, but I digress...). You have all thattoday, right? No? Uh oh. Now what?

This, I think, reflects our current situation. We are sorely in need of a breakthrough, too (SCADA owners - I'm looking at you!). One such step being taken is that DHS is now sending teams off to energy companies to help with security, but this seems unlikely to be sufficient. We have decent methods for modeling risk (e.g. FAIR). How do we take the next step? How do we get the message across in a meaningful way that spurs meaningful action?

What do you think?

Here at the Fudsec Summer Resort, we were chilling with our wine coolers in between rides on the tire-swing, enjoying the hottest part of summer with some time off, and then Jack Daniel (@jack_daniel) goes and writes a perfect FUD-related rant on his Uncommonsense Security Blog. Several people DM'd us and asked us to re-post. With Jack's kind permission, we've done so below. All hail Jack for a great analysis of some serious FUD

Someone has done some wildly successful social engineering. Amazing, actually. I am not talking about the "Robin Sage" social media/social engineering case where a lot of people who should know better gave up a lot of information in a lot of different ways. That may be interesting (we'll see when it is presented), but even though some of the results were sensitive, that is building on a lot of prior work.

I am talking about the coverage of that story, where the reporting has largely been horrible, gullible, naive crap. Sorry folks, but yes, that includes coverage from people I like. If you believe a lot of what you read, you would think that a lot of people were "duped" into following/friending/linking/whatevering Ms. Sage. This shows a gross lack of understanding of both social networking and the security community- both on the part of the journalists, and to a lesser extent, the researcher.

The people who "over-shared" really are a problem, and it may be interesting to see what Thomas Ryan (the person behind Robin Sage) presents at DefCon. It looks like s/he got a lot of sensitive information from people who should know better- three letter agencies, military, and more. Interesting, but "people are stupid and gullible" is not really ground-breaking, nor is mining/abusing social networking to prove this point a new idea either. It does sound like the scope and scale may be noteworthy. But not new, and being a skeptic, I'm not sure it is newsworthy.

Where things fall apart is the nonsense over stories which pretty much proclaim that MILLIONS OF SECURITY PROS DUPED, and point to the number of friends/links/etc. the virtually perky Ms. Sage gathered. I would like to point out four things:

1. Different people use social networks in different ways. Just because someone accepts your connection request does not mean they are fooled by you. They may not even care if you are real or fake.
   • Maybe they (sadly common) think that more connections means they are more important.
   • Maybe they are public figures of some kind, and accept most requests as a matter of policy. If people are careful with what information they share, there is nothing wrong with this. Nothing. It is voluntary, get over it. It is how Social Media and Social Networking work for many people. If you don't like this approach- don't use it.
   • The decision to accept may be based on connections offered (via friend-of-a-friend linking) instead of being based on the person making the request. Again, if you are cautious about what you share, there isn't a risk here- even if it is a pretty shallow move. Robin certainly had some interesting friends/links to entice people. Put another way: Some days, the wingman scores.
2. Once Robin Sage became fairly visible, the drama got interesting and a lot of people began following/linking to the myriad of Robin Sages (yes, there were clones and evil twins, too) just to watch the train wreck. I was one of these, and like many others I had my suspicions- but didn't care if she was real, fake, or just another troll, there was entertainment. People were not duped, they grabbed a beer and some popcorn and watched the show.
3. Robin Sage was called out. Spotted. Thoroughly outed. Many thought "something was fishy". Some people did actual research and provided real details. People had to connect/accept to do the research and confirm their suspicions. The press almost completely missed this critical point. They also missed the fact that once this was widely known, even more people connected to and followed Robin to watch the evolving train wreck mentioned in point 2.
4. Mr.. Ryan apparently convinced (socially engineered) much of the media into thinking this was something it wasn't, then and the result was not journalism, it was an embarrassment.

And this is just the worst of it this week. Half baked ideas, giant (and flawed) leaps of logic, obvious vendor spin, and more were on parade this week. Maybe it was the heat and no one could think clearly. Maybe it was Vacation from Healthy Skepticism Week and no one told me. I don't know, but I'm not happy about it.

For a year, Fudsec.com has brought you the finest FUD-bashing that money can buy, and many have asked us how they can post here (email us at the address below if you'd like to).

All too often, though, we've outed fear, uncertainty and doubt without thought to giving credit to those who toil thanklessly to create it.

We're out to change that.

Announcing the FUDdies® - the industry standard recognition of innovation and creativity in the prodution of FUD. After all, coming up with new ways to wrest legitimate budget dollars from security initiatives towards illegitimate boxes is no easy task. Join Fudsec.com as we honor those in the business of making this magic happen.

Face it, folks: there's tons of FUD out there, and even here on Fudsec there are few people being specifically called out for FUD. So let's bring it. Tell us who's doing it. Tell the community about it. 

We need your help to get these going. Email us your thoughts, your nominations, or anything else you think we should think about. Right now, there are two categories of FUDdie: FUDiest Campaign, and Most Unctuous Information Security Marketing Executive.

Voting is held by secret ballot at fudsec ( at ) gmail com  , and all results are reviewed by a top secret, anonymous committee whose decisions shall be final.

Prizes are coveted, genuine Reynolds-built aluminum foil caps, which look great and shield your brain from electromagnetic mind control carrier waves and beacons. The prizes will be announced at RSA 2011, which means we need help now.

Vote early! Vote with your heart! 

The Fudsec Team

Today's post comes from Ben Tomhave. Ben and others felt the Zalewski ZDNet piece was a bit of a "Blame or Frame Job" on our industry and was compelled to respond. Do you agree? You'll want to follow the links if you haven't already read them. Any post that starts with a Sin City reference is likely to be gritty.

by Ben Tomhave (@falconsview)

"I've been framed for murder and the cops are in on it. But the real enemy, the son of a bitch who killed the angel lying next to me, he's out there somewhere, out of sight, the big missing piece that'll give me the how and the why and a face and a name and a soul to send screaming into hell." ("Marv" in the movie Sin City)

I've read and reread (a couple times) the May 20th article "Security engineering: broken promises" by Michal Zalewski of Google (a guest post on ZDNet's "Zero Day" feature). I have to say, I find it highly disappointing and FUD-tastically frustrating. The bio at the end describes him as a "security researcher," which in my mind makes him a "breaker" more than a "fixer" (supported by the kinds of tools he's released). As such, we have to expect a degree of whining cynicism about how bad things are, but I would have at least hoped he'd have a little more clue before spreading FUD doom and gloom.

Framing Frameworks
"...for several decades, we have in essence completely failed to come up
with even the most rudimentary, usable frameworks for understanding and
assessing the security of modern software... The frustrating, jealously
guarded secret is that when it comes to actually enabling others to
develop secure systems, we deliver far less value than could be expected."

As a card-carrying member of OWASP, I find this statement to be ill-informed and suspicious. While it is true that we don't have mathematical models describing software security (to which he later alludes), it is completely false to say that we lack frameworks for understanding and assessing software security (which he never defines). There are lots of options to choose from, whether it be OpenSAMM, BSIMM/BSIMM2, or even the various efforts of groups like OWASP, ISECOM, or WASC. Let's also not forget efforts like Microsoft's SDL.

In terms of enabling others, this is not a security failure, it's a management and business failure. Many like to throw blame onto security teams for this situation, but everything ultimately comes down to the decision-makers and their needing to place proper emphasis on the need/requirement for writing secure code+apps.

Framing Risk Management
Now we get into some very FUD-erific territory...

"...[risk management] introduces a dangerous fallacy: that structured
inadequacy is almost as good as adequacy, and that underfunded security
efforts plus risk management are about as good as properly funded
security work."

and

"...security incidents are nearly certain, but out of thousands exposed
non-trivial resources, any resource could be used as an attack vector,
and none of them is likely to see a volume of events that would make
statistical analysis meaningful within the scope of the enterprise."

and

"...in information security, there is nothing contributed by healthy
assets to directly offset the impact of a compromise, and there is an
insufficient number of events to model their distribution with any
degree of certainty; plus, there is no way to reliably limit the maximum
per-incident loss incurred."

Wow, talk about cynical. First off, apparently risk management has no value. Second, risk management apparently detracts from security initiatives. Third, because there are potentially infinite threat vectors, the statistical analysis performed in risk assessment is pointless. All of this prattle belies a keen ignorance about risk management, and once again seems to suggest that software security failures are a result of something other than poor coding practices under the rule of security-disinterested business leaders.

More importantly, his risk management comments don't seem to have much of anything to do with risk management, but instead seem to be focused on risk assessment methods. He probably also thinks that qualitative risk assessment techniques are de rigueur. It never ceases to amaze me when criticism is launched from a place of ignorance.

Framing Unified Theories
As the piece progresses (or maybe it digresses), it seems that we finally start to see his true intentions as he talks about CWE and CVSS, saying: "Having said that, none of them yielded a grand theory of secure software yet - and I doubt such a framework is within sight." This comment finally reveals Zalewski's true intent or hope, and that is some sort of mystical silver bullet "grand theory of secure software." I thought this guy was a security researcher for the venerable GOOG? Anybody else's spidey sense tingling over the inanity of his comment here?

Of course, perhaps the biggest problem is Zalewski chafing at what is actually "good enough" from a software security perspective. Frameworks seem to be the preferred ideal du jour, but to what end, and with what backing? More importantly, to quote Amrit Williams:

"What we must learn to accept is that security – as it pertains to both
the development of software and its operational use – is ultimately more
survivable than we like to believe." (from "The Simple Elegance of Faith; When Good Enough Is")

Call me crazy, but it seems like Zalewski is framing infosec for the failing of business leaders, compounded by his own ignorance.

What do you think?

Also check out Jack Daniel's response ("A bit of deep thought.") as he links to several other replies as well.

This week's post comes from Eric Hanselman. Eric has an uncommon, common sense. Eric tried to leave Security two years ago after the RSA conference - bound for Virtualization-land. Alas, security pulls you back in and he was right back at RSA 2009. We always say "we'll do better at security the next time." "We'll bake security in." There were a lot of promises and claims made about how much better virtualization security would be. Here is sort of a "state of the union" from Eric.

by Eric Hanselman (@e_hanselman)

We’re heading in to a brave new world of desktop security and we need to do it with our eyes open.  There’s a lot of potential benefit that desktop virtualization can bring to an organization.  Like any new technology, though, there’s a lot of misunderstanding of the change in risk dynamics and how to deal with them.  In recent weeks there have been announcements and discussions that bear some analysis.

Hosted and Virtual desktops (HVD is the Gartner term) deliver awesome mitigation for data loss.  The desktop is back in the data center and the only the screen image makes it back to the user.  There are also all of these really great operational expense savings.  It’s easy to think that it resolves some of our biggest endpoint protection headaches.  There’s an air of irrational exuberance out there, that’s a little disturbing.

There are two big concerns:

·       Users think that desktops in datacenters are wicked safe.

·       Vendors aren’t disabusing them of this delusion.

At RSA this year, in two different virtualization security sessions, I heard attendees ask if anti-virus software was still needed with virtual desktops.  Lest you think that these were aberrations, industry analysts are posing the question, as well.

Forget about all of the Blue/Red Pill hysteria.  There’s a much more fundamental issue that we need to address.  Yes, the desktops are now in the datacenter, but there are still a whole set of security issues that have to be handled.  We’ve made a big jump forward with physical security.  It’s now a lot harder for random people to plug USB devices in to desktops or walk off with the thing that holds all that local data.  We’ve paid for this by turning every user in to a remote user.  Remote access security is something that we should have a good handle on, but now every user needs it.  IAM capabilities take a big step forward.

Securing the desktop is where real work still needs to be done and that falls to the traditional tools of endpoint defense.  The hitch is that our existing tools don’t play well with the virtual world.  For the security conscious, the virtual desktop gets built like the physical desktop.  Tried and true desktop suites can be managed in the virtual world alongside the physical desktops.  This works.

There’s a danger lurking here, if we don’t understand the impact in the virtual world.  There are a number of horror stories of a newly minted virtual installation being brought to its knees when every one of the virtual desktops was scheduled to do system scans at the same time.  Even if our suite supports flexible scheduling, those compute and I/O intensive tasks that worked so well when distributed across bunches of under-utilized systems are a huge load when brought back to a shared set of servers.

This is a problem that has many people considering turning off traditional protections.  A big difference between server and desktop virtualization is the concern about scale.  Running endpoint protection on virtual desktops reduces the number of desktops that can be hosted on a given set of hardware.  There are virtualization vendor claims that, by destroying each desktop after use, we eliminate infection.  This is the first vendor complicity issue.

What about all of that user data?  Aren’t there a lot of PDF’s full of APT’s out there?  Fortunately, virtualization can address a part of this.  But only part.

One big benefit of desktop virtualization is that I’ve got all of my users’ disks in the datacenter.  They’re available all of the time.  If I’ve got enough disk I/O capacity, I can scan all of those disks any time with minimal user impact.  I’ve also got the potential to remediate issues centrally.  A big win.  Some traditional AV vendors pitch this as their “virtual” solution today.

The piece that isn’t covered is execution monitoring.  The virtual environment still doesn’t have a way to keep tabs on live processes.  There are good signs, but they’re not complete.  VMware’s VMSafe opens memory pages for inspection, but, again, we’re back to static signature scans and advanced threats have proven that they’re pretty good at obfuscation.  And only VMware offers this today.  And only a few security vendors are doing anything with VMsafe.  This is a missed opportunity.

We now come to the recent announcement by Citrix and McAfee of their partnership for virtual desktop security, the MOVE platform.  This sounds like it’s going on the right direction.  It makes the agent functions more granular and allows processing to be split between the desktop and the virtual environment.

How will this fare when put under the scrutiny of the recently developed SCSOVLF metric?  Not well, unfortunately.  To begin with, it’s still a “concept” with delivery some months off. Details are still emerging, but the first stage seems to move some analysis parts to a separate VM and leans heavily on virtualization being a great way to improve configuration management.  Points off for relabeling something that we should have been doing already.

There is a second phase to MOVE, native hypervisor inspection.  My heart leapt!  Until I realized that it’s application  and process whitelisting.  This is desktop security, not server, right?  There are a lot people who’ve been burned out there by the twin issues of manageability and effectiveness for whitelisting.  It puts us right back to manually locking down users’ desktops.  While this is a step in the right direction, it comes with a high cost.  And more sophisticated threats already know how to beat it (DLL injection anyone?).

What we really need is endpoint protection that can rely on sophisticated techniques in the hypervisor.  Have per instance execution monitoring for the desktop, and leave the signature scans to a storage analysis piece.  And correlate the two, please.

And wouldn’t it be even better if, while providing virtual execution cycles, the virtualization layer was doing some effective protection, as well.  A guy can dream, right?

Interesting technical post by the super-smart Andy Ellis.

It may not obvious what this post may have to do with FUD. Some context may help. A position we've heard: DNSSEC and its benefits have been postponed for years by folks afraid that zone files would not be secret enough. NSEC was an attempt to add secrecy, but it cost the world three tries and associated delays to settle on NSEC3. Oh, and by the way, it doesn't solve the "issue" either. Was FUD a factor here delaying the move to DNSSEC?

By Andy Ellis (@CSOAndy)

NSEC3, or the "Hashed Authenticated Denial of Existence", is a DNSSEC specification to authenticate the NXDOMAIN response in DNS. To understand how we came to create it, and the secrecy issues around it, we have to understand why it was designed. As the industry moves to a rollout of DNSSEC, understanding the security goals of our various Designed Users helps us understand how we might improve on the security in the protocol through our own implementations.

About the Domain Name Service (DNS)

DNS is the protocol which converts mostly readable hostnames, like www.csoandy.com, into IP addresses (like 209.170.117.130). At its heart, a client (your desktop) is asking a server to provide that conversion. There are a lot of possible positive answers, which hopefully result in your computer finding its destination. But there are also some negative answers. The interesting answer here is the NXDOMAIN response, which tells your client that the hostname does not exist.

Secrecy in DNS

DNS requests and replies, by design, have no confidentiality: anyone can see any request and response. Further, there is no client authentication: if an answer is available to one client, it is available to all clients. The contents of a zone file (the list of host names in a domain) are rarely publicized, but a DNS server acts as a public oracle for the zone file; anyone can make continuous requests for hostnames until they reverse engineer the contents of the zone file. With one caveat: the attacker will never know that they are done, as there might exist hostname that they have not yet tried.

But that hasn't kept people from putting information that has some form of borderline secrecy into a zone file. Naming conventions in zone files might permit someone to easily map an intranet just looking at the hostnames. Host names might contain names of individuals. So there is a desire to at least keep the zone files from being trivially readable.

DNSSEC and authenticated denials

DNSSEC adds in one bit of security: the response from the server to the client is signed. Since a zone file is (usually) finite, this signing can take place offline: you sign the contents of the zone file whenever you modify them, and then hand out static results. Negative answers are harder: you can't presign them all, and signing is expensive enough that letting an adversary make you do arbitrary signings can lead to DoS attacks. And you have to authenticate denials, or an adversary could poison lookups with long-lived denials. Along came NSEC. NSEC permitted a denial response to cover an entire range (e.g., there are no hosts between wardialer.csoandy.com and www.csoandy.com). Unfortunately, this made it trivial to gather the contents of a zone: after you get one range, simply ask for the next alphabetical host (wwwa.csoandy.com) and learn what the next actual host is (andys-sekrit-ipad.csoandy.com). From a pre-computation standpoint, NSEC was great - there are the same number of NSEC signed responses in a zone as all other signatures - but from a secrecy standpoint, NSEC destroyed what little obscurity existed in DNS.

NSEC3

NSEC3 is the update to NSEC. Instead of providing a range in which there are no hostnames, a DNS server publishes a hashing function, and a signed range in which there are no valid hashes. This prevents an adversary from easily collecting the contents of the zone (as with NSEC), but does allow them to gather the size of the zone file (by making queries to find all of the unused hash ranges), and then conduct offline guessing at the contents of the zone files (as Dan Bernstein has been doing for a while). Enabling offline guessing makes a significant difference: with traditional DNS, an adversary must send an arbitrarily large number of queries (guesses) to a name server (making them possibly detectable); with NSEC, they must send as many queries as there are records; and with NSEC3, they must also send the same number of requests as there are records (with some computation to make the right guesses), and then can conduct all of their guessing offline. While NSEC3 is an improvement from NSEC, it still represents a small step down in zone file secrecy. This step is necessary from a defensive perspective, but it makes one wonder if this is the best solution: why do we still have the concept of semi-secret public DNS names? If we have a zone file we want to keep secret, we should authenticate requests before answering. But until then, at least we can make it harder for an adversary to determine the contents of a public zone.

"Best" practices in zone secrecy

• If you have a zone whose contents you want to keep obscure anyway, you should consider: Limiting access to the zone, likely by IP address.
• Use randomly generated record names, to make offline attacks such as Dan Bernstein's more difficult.
• Fill your zone with spurious answers, to send adversaries on wild goose chases.
• Instrument your IDS system to detect people trying to walk your zone file, and give them a different answer set than you give to legitimate users.

Jason Bau and John Mitchell, both of Stanford, have an even deeper dive into DNSSEC and NSEC3

If we look at the preferences and trends in the consumer electronics market, can we gain insights into IT security development and purchasing patterns? 

I subscribe to Wired magazine, but my teenage sons pilfer it before I have a chance to read it all. As such, it was only when I came across a news snippet about a Wired article in another magazine that I stopped to think about the security implications.

From worldmag.com: 

Robert Capps, writing in Wired, identifies a revolution that began with technology but is changing the way other industries, including law and medicine, are doing business. Capps calls it the 'Good Enough Revolution' and uses the Flip video camera to illustrate his point. Traditional video cameras emphasized image quality and features. A new company, Pure Digital, came along and saw a market for a low-cost video camera that was easy to use and produced video that was easy to share online. It sacrificed image quality for ease of use. The Flip Ultra is now the best-selling video camera and controls 17 percent of the market. Capps writes: 'We now favor flexibility over high fidelity, convenience over features, quick and dirty over slow and polished. Having it here and now is more important than having it perfect.

I recall the days when "hi-fi" was the objective. Sure, the market still recognizes differences in quality, but other factors seem much more important. As Capps points out, despite the availability of excellent medical technology, "good enough" is an emerging theme in healthcare. 

Since the founding of Fudsec we've looked to expose FUD, but until today it's been a little like Justice Stewart's definition of obscenity - I can't define it, but "I know it when I see it." In this week's invited post, information security and risk management consultant Gal Shpantzer blows the lid of that problem with the Shpantzer Coma Scale. We at the Fudsec Institute For FUD Studies are delighted that he could bring clarity and metrics to such an important topic - because if you can't measure it, you can't ... well, you know.

By Gal Shpantzer (@shpantzer)
When considering the veritable cornucopia of vendor offerings in the information security niche, you'll find a spectrum of quality in the products and services themselves, from the ridiculous to the incredibly useful and well-designed. You'll also find a wide variety of approaches to sales and marketing these very same products and services.

Some vendors are consistent and have good products as well as sales/marketing teams. This is a rare vendor indeed. Treasure them if you find them. The majority within the vendor space have either good products or good marketing. Then there are those with neither. Inconsistency breeds hilarity.

Please consider this friendly scoring system, inspired by a combination of the Glasgow Coma Scale, APGAR and some other medical scoring schema for survivability of trauma and disease. Note: We're carefully calibrating the rating system with an old Cray supercomputer in @rybolov's basement. YMMV)

Let's add up some points!

Vendor inappropriately uses absolute terms like "always" and "never" in order to delude the sucker, er, I mean prospect into thinking there's any certainty to be had in the security niche. Take one point off for every absolute term, starting at 5.

• Bottom score of -5 for FUD lameness.

Number of minutes from start of presentation until vendor uses the term "APT".

• +1 point for every minute past start. Max -5 points 
• Bonus 3 points for not mentioning it at all, unless prompted to.

If, when prompted to address APT, vendor says "oh yeah, we've been doing APT since before 9/11".

• -5 points

If, when asked, "How do you approach the APT issue, exactly?" they respond "That's on our roadmap".

• -5 points

Vendor claims to fully detect malware on your endpoint. The more certain the claim sounds, the more points you can take off, starting from 5.

• Bottom score of -5

Vendor has something that goes beyond a default OS build for its products: Starting at 0, add points for each aspect of security hardening credibly claimed.

• +1 point per feature, Max 5 points.

Vendor has credible claims to integrate with relevant third party applications and services.

• +1 point per feature, Max 5 points.

Vendor offers some level of choice in pricing model.

• +1 point per choice, Max 5 points

Vendor has recent history of catastrophic encryption implementation failures.

• -5 points

Vendor offers a 99% discount off retail pricing for year one software licensing. When pressed for total cost of ownership over 3 years, they reveal their plan to stick you with maintenance based on MSRP for years two and three.

• -5 points

Vendor offers some level of ability to update and upgrade the software they're selling.

• Max 5 points

Vendor actually responds to vulnerability reports in a way that remotely resembles something a reasonably responsible business would.

• +5 points

Vendors offers some level of centralized management of distributed product.

• Max 5 points

Vendor's central management of said distributed product causes DoS on your network.

• -5 points

Vendor has some sort of third party certifications for their crypto library and/or device as a system (FIPS 140-2, Common Criteria, UK gov't, German gov't, etc).

• Max 5 points

Vendor doesn't use proprietary encryption algorithms (yes, this is still being done, see Onix International and EncryptStick polymorphic…).

• +5 free points for using AES or other accepted algorithm.

Vendor has technical capability to deploy in a flexible manner, to suit your virtualization strategy, if relevant.

• +5 points

Vendor has real scalability in technical and pricing terms. Ask for references, don't just buy the canned demo.

• +5 points

Vendor has reasonable licensing terms that allow for configurations that serve different use cases.

• + 5 points

Vendor can integrate with two-factor authentication tokens/cards, at least for administrative interface.

• +5 points

Vendor is very negative and constantly disparages other competitors in their space.

• 0 points

Vendor is negative when disparaging obvious lamers like those who use polymorphic encryption.

• Max +3 points.

When asked about reference customers, vendor claims that the entire DoD and civilian government uses their products. When pressed for a confidential phone call, under NDA? "That's classified, but just between you and me, we're all over Langley and Ft. Meade."

• -25 points and a call to the FBI Counterintelligence office.

Vendor is an otherwise credible up-and-coming security player that has been around for more than a year and can legitimately support an enterprise customer, in theory.

• Max 5 points.

Vendor product does in the testing lab something close to what it says in the slideware.

• Max 5 points Bonus 3 points for having a reasonably responsive pre-sales engineer available via webex to help with a qualified bake-off.

Vendor is an otherwise credible security player that's been around for a while and has actual, reference-able enterprise customers.

• Max 5 points.

SCORE:

Negative Score: Bring back the pillory and the scarlet letter.

Under 30: Run, don't walk. Then keep running. Write a blog post to lower your blood pressure.

31-50: Ask for a webinar and have them explain polymorphic encryption to you.

51-70: Possible long-list candidate with value play

71-90: Probably gonna make it to shorlist for tech eval

91+: Might be able to deliver on the promise and not the peril

In mid-2009, after a flurry of Twitter activity on the subject, Craig Balding established Fudsec. He felt that, since Fear, Uncertainty and Doubt was permeating the world of information security, there should be a place where information security professionals could rebut it, could stake claims to intellectual honesty and begin conversations about issues of community interest.

"Fudsec," Craig wrote, "was created to showcase bad examples of Information Security marketing. Anytime the marketing message from an Information Security vendor or provider makes you feel Fear, Uncertainty, Doubt (FUD!)...or just plain dirty, let us know and we'll feature it here."

The Twitter effect was certainly responsible for the site's rapid growth, and by many measures the site has been a great success. Readership for each of the more than 30 posts to date has averaged several thousand, and the feedback generated has been highly positive. Each entry has a call to action. Not all posts draw comments on the site. All posts have sparked conversations - some highly charged, some in violent agreement, some in lively debate.

The list of contributors to date reads like a Who's Who of the information security world - in alphabetical order, posts have been contributed by Iftach Ian Amit, Paul Asadoorian, Balazs Attila-Mihaly, Richard Bejtlich, Carl Brooks, Anton Chuvakin, Justin Clarke, Joshua Corman, Rocky DeStefano, Drazen Drazic, David Etue, Will Gragido, Jeremiah Grossman, Brian Honan, Peter Kuper, Lori MacVittie, Haroon Meer, Ewout Meij, Chris Nickerson, Dale Pearson, Larry Pesce, George Reese, Wim Remes, Kevin Riggins, Chris John Riley, Mike Rothman, Nick Selby, Shrdlu, Jayson Street, Chris Swan, Vince Tuesday and Amrit Williams

Now Craig is passing the baton, curtailing his online activities to turn his attention to his growing family, and a new team will be running Fudsec - in Craig's words, "two of Fudsec's biggest fans and notable contributors." You can expect the same level of integrity as before, and the potential for some new debate, or even some new services. A podcast is not out of the question.

The Fudsec site will remain true to Craig's original and important vision: intellectual honesty, an open forum where the known and the not-so-well known can contribute to the conversation. Where voices from all continents and cultures will find an audience.

As he passed the torch, Craig passed on some thoughts about how the site should be continued. A small sample of what currently comprises our mission statement:

"We need to go beyond acknowledging the FUD elephant in the room. We need to exorcise the demon from within...or ultimately we will be "without". Fudsec is the place to initiate that. We don't claim sole rights on the FUD meme, but we built a launchpad and every week aim rockets at the collective infosec consciousness...A Fudsec piece without a call to action is an operating system without an application."

If you'd like to write for Fudsec, please let us know at fudsec[at] gmail [dot ] com.

Today our invited post is from David Etue, a vendor speaking about FUD in information security marketing. Yes, he has skin in the game and yes, he knows it. But his larger point is that when marketers point FUD at vendors in other markets, intellectual honesty and customer information is the victim.

By David Etue (Twitter: @djetue)

Disclosure: I am a marketing guy - a VP of Products and Markets at Fidelis Security Systems, a network security company addressing problems from cyber defense to DLP. That's my conflict, and now it's disclosed.

Sadly, FUD continues to evolve, and not in a positive way. As Anton Chuvakin has pointed out, FUD's role in security today probably overshadows the role of any other factor we know. However vendor's use of FUD is continually evolving, and has now reached what I determine to be its Third Wave: Fear, Uncertainty and Doubt against other solution categories. In order to understand the third wave, we'll first look back at what I consider the first and second wave.

The First Wave
The "first wave" of FUD is when vendors use fear, uncertainty and doubt to convince (well, scare) an organization to buying their security product. Rather than learning a customer's organization and explaining how the technology, along with people and process, benefits the customer's risk management program, this FUD involved targeted messages to the end user on how they will be hacked, fail an audit, lose their job, etc. if they don't purchase this product.

This first wave of FUD is still omnipresent today, but many consider it misdemeanor-level FUD as it's also the easiest to detect by the end user - it often overlaps with "silver bullet FUD" stating how the product solves both all information security problems, and maybe even world hunger too.

The Second Wave
The "second wave" of FUD targets competitors in the same sub-sector of a given industry; this is FUD-marketing attacking the competition to win the customer bake-off. Again, rather than competing the noble way and articulating how product differentiators affect customers cost of ownership and benefits their risk management program to gain selection, many resort to competitive FUD. There are few different types of second wave FUD:

• Bogus Requirements: This FUD consists of establishing criteria that have NO or LOW material mapping to how the organization would use the product and there for no benefit, yet will eliminate competitive solutions. My personal favorite examples are when organizations require esoteric templates, often compliance related, in the product with NO relevancy to their organization because one vendor has them and convinced them to include it in the specification.
• Bogus Features: I have a product management background so I often refer to these as "test cases", versus "use cases." These are typically extraneous, but can sometimes be intentionally malicious. The extraneous cases consist of creating an event that would never happen in the real world, modifying your product to cover it, and then convincing the end user it matters. A few years ago, I came across a great example of a more malicious example from a data leakage prevention (DLP) vendor, where they had modified their product (whether intentionally or unintentionally) to alert on a Social Security Number ending in "0000", which is not a valid SSN. The vendor then proceeded to provide the end user with a test file of SSN's ending in four zeros, and then claimed to be the only vendor to detect the file "correctly!"

The Third Wave
Unfortunately, we've gone past these to the "third wave" of FUD, where FUD is used to compete for a customer's mind-share versus other solution categories. Rather than using FUD as a compelling event (FUD wave one), or competitive FUD to gain selection (FUD wave two), vendors are now FUDing for mind share before projects even start! A great example of this is Gunter Ollmann of Damballa's blog post, Botnet Prevention with DLP Technologies.

I am pretty familiar with the DLP space, and I'm not aware of many cases of vendors using botnets, or even botnet FUD, as a primary selling point of a DLP solution. However, Gunter goes out of his way to try to make a point that he can't "see a reason for [DLP] existing as a separate security technology anyway."

As an aside, I'd recommend that Gunter choose his FUD more carefully in the future. Much of his "DLP doesn't do botnet" FUD could also be used to argue why a separate botnet appliance (like Damballa) shouldn't exist as a "separate security technology", as he makes a compelling argument that IPS, anti-spam and perimeter Web gateway help stop nodes from being infected over the network; anti-virus best deals with determining "malicious intent of the binary files"; and IP/Domain/URL blocking technologies are effective at blocking command and control.

Why is Gunter focusing Botnet FUD at DLP?
While botnets certainly may play a role in data exfiltration, Damballa's mission of protecting "businesses from bot-driven targeted attacks used for organized, online crime" and DLP's focus on content-aware data security are fairly different. I think the reason is that DLP is currently a funded market category with name-funded projects in the large enterprises that Damballa is interested in selling too.

These same enterprises don't have a named, "botnet detection" project or budget, so the battle for dollars and mind share has begun. He is not alone in this FUD, as many other vendors have joined this third wave of FUD with DLP alone. For example, Lancope announced their DLP solution that is soooooo good that it "not dependent upon packet-level data" (thanks to Rich Mogull of Securosis for calling out this FUD in his blog post Hit the Snooze on Lancope's Data Loss Alarms). There are many more examples across the security landscape.

So, how did we get to this third wave? I have a few ideas.

First, the security buyer is suffering from information overload. If we look across the security product landscape, Gartner has a taxonomy that defines 159 discrete security topics ranging from infrastructure protection to identity & access management to compliance, risk & governance. This overwhelming list of "solutions" is way too many categories for an end user to possibly navigate, let alone have in depth knowledge of how they would benefit their organization's risk management program.

Second, there is very little spending on new security projects, or new IT projects in general. According to the quarterly Citi CIO Survey for the fourth quarter of 2009 (by Richard Gardner and Aswin Shirviakar), the 80:20 rule applies to existing projects and maintenance versus new IT spending: "about 80% of IT spending over the next year is expected to be maintenance." This report also states that "security spending intentions remain high yet just stable." What does this mean? Any of the products within the Gartner 159 security categories which is not yet deployed is fighting for 20% of IT security spending, and the overall pie from which the 20% is derived isn't growing.

Finally, compliance spending continues to drive the majority of the spending in security dollars. The same Citi CIO survey cited before noted that government regulations were a significant driver of spending. As compliance regulations have become more prescriptive, this compliance-spending has become very focused on a small number of traditional (some may call legacy) security controls.

This report also states that "security spending intentions remain high yet just stable," so more and more solutions are fighting for budgets that are flat. Finally, compliance spending continues to drive the majority of the spending in security dollars. The Citi CIO survey also noted that government regulations were a significant driver of spending.

The Payment Card Industry Data Security Standard (PCI DSS) is a great example of this, as, as Josh Corman points out, it only explicitly requires nine security technologies (firewall; IDS; anti-virus; log management; encryption; vulnerability scanning; web application firewalls or application reviews; integrity monitoring; and patch management.) This leaves 150 of 159 Gartner sub-sectors of security - many with technologies solving significant challenges important to enterprises today - not required by compliance.

So, we have a confused buyer not able to keep up with the number of security product categories available, let alone the products within them. They may have little motivation to learn as budget pressures allow for few new projects, especially when 80% of the budget is spent on existing projects and maintenance. Top that off with compliance driving spending to a small number of legacy controls.

This leaves the remaining vendors thinking "If they have one discretionary project left, it MUST come to my project," and makes them incredibly focused on driving the small fraction of remaining budget to their solution. This is no excuse for the use of FUD, but is a sobering view of the state of the information security industry today.

Conclusion
Information security has reached a desperate time and some say desperate times call for desperate measures. However, these desperate measures should be to the benefit of the end user, not any single vendor. I would suggest that the presence of third order FUD is an indicator of the desperation of a solution to find its way in a crowded marketplace. This is a commentary on both the marketplace and the vendors who seek to use it. In a time when we all want to drive FUD down, adding a third wave should not be acceptable.

In the interest of continued disclosure, I remind you, I am a vendor. But am I wrong?

Which examples of third-wave FUD do you have?