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.