Dan Kaminsky is NOT a hero

Before I launch into my rant about all the swirl that's resulted from Dan Kaminsky's recent disclosure of a DNS flaw, I want to make one thing clear: While I do not know him nor have I worked with him, I nevertheless hold Dan's skills in high regard and respect him as a professional. The DNS flaw behind this is indeed serious. Nothing I'm about to say should be seen as a reflection on him or his work, but rather the sometimes-OCD InfoSec community and online media outlets.

Yesterday I read a column by Robert Vamosi, linked off of C|Net, that made me vomit a little bit in my mouth. His comments on Kaminsky would make the reader think that the man just saved the entire world+dog for today and the rest of time from certain doom from some three-headed unstoppable eating machine with minty fresh breath but a bad, bad attitude. Heck, he may just be the second coming. Oh man, that means I'm going to hell for not capitalizing He. Allow me to quote from the article titled - no kidding - The man who changed internet security:

There have been other multiparty patch releases, but never has there been one on such a massive scale.

What he [...] did over the last few months was not only responsible but extraordinary.

all future vulnerability disclosures could benefit from his example.

With the DNS flaw, Kaminsky was in a very weird position. What he found wrong [...] wasn't just within one vendor's product, it cut across various products

He has changed Internet security, and done so for the better of us all.

This is a great amalgamation of all of the idolatry directed at Dan, all in one column. To categorize all of this, many people - professionals in the field (self-proclaimed or otherwise) - seem to be under any combination of the following false impressions:

1. The scope of this issue is without precedent. This is simply not true. Especially in the late 90's and early 2000's as attackers began seriously exploring computer vulnerabilities, there have been a number of widespread service implementation problems - or problems affecting a hugely critical piece of software (think: Bind before many people used MS's DNS server). A recent example is the vulnerability in the implementation of BGP by every major router manufacturer in 2007 which could lead to a spoofed denial-of-service and ZOMG TAKE DOWN THE WHOLE INNERWEBS!
2. Having to coordinate patches between vendors is unusual. While no doubt most vulnerabilities impact only a single vendor, it's also not uncommon to find a second vendor, perhaps borrowing from the same segment of code (I'm looking at you Unix), that is also vulnerable. For an easy example, see (1), or many vulnerabilities found in open source/GPL code over the years.
   
3. This vulnerability is new and completely unexpected. While we won't know for sure until this is discussed at BlackHat, there is evidence suggesting this isn't true. People have pointed out that similar techniques to poison DNS have already been discussed. We can certainly say the severity of the exploit seems new, but beyond that, any responsible discussion on the topic needs to wait until all the facts are in front of the public for peer review. I wouldn't say this is patently false, but I would say to anyone making this assertion, "not so fast there..."
   
4. Responsible disclosure is somehow novel, invented, or revolutionized by Dan Kaminsky. These people either have had their head in the ground since 2000 or so when the debate between full and responsible disclosure first erupted on BugTraq, or they never understood what the term meant. At the time of the writing of this entry, a Google search for "responsible vulnerability disclosure" returned "about" 287,000 pages.
   

To quote his recent blog entry, he's been "the beneficiary of what can only be described as 'redonkulous amounts of press'." To wit, there is plenty of good press discussing the vulnerability and how to fix it - that's obviously not what I'm talking about. Dan's a great professional, I hate to see fanboys like this surface and cheapen - rather than reinforce - his m4d sk1lz.

To Dan: Kudos. To all the fanboys and fangirls: Please to be redirecting your significant energy and time to something a little more productive.

Differentiating CNA and CNE

The sometimes-subtle difference between espionage and attack in the electronic or digital realm is often completely glazed over in the media. This, I feel, is confusing two very different objectives of adversaries. Without such a distinction, it becomes hard to defend computers, networks, and data, as each requires a very different approach to detection and prevention. As Zach in Rage Against The Machine would tell you, "know your enemy." One must fully understand who is attempting to do what in order to properly align defenses.

This issue has annoyed me for a long time, and I've found it somewhat hard to articulate the significance of this delineation. Finally, it seems, someone is getting the word out - and in a way that's easy to understand. In a hearing before congress on May 20th of this year, Col. McAlum, director of JTF-GNO, stated the following:

I would also point out on this slide that it's really important to get the lexicon right. In the open source media and other forums, you hear the term "cyber attack" used rather liberally, and you won't hear anyone in the Department of Defense use that term in the context of cyber reconnaissance or network intrusions. What we are seeing today are network intrusions.

Some people might classify that as a form of cyber espionage. I would not have a problem with that characterization, but the terms "attack" and "intrusion" are very different and the differences are significant in many cases. So, for example, someone breaking on to an Air Force base with a camera and a backpack is a serious event, very serious, and is going to get the security forces and a lot of leadership's attention.

However, that's much different than someone breaking into an Air Force base with a satchel charge ready to plant it somewhere and blow something up. Those are sort of the nuanced differences that I think the lexicon discussion has to take into account.

This is one of many very interesting comments on this hearing, titled "CHINA’S PROLIFERATION PRACTICES, AND THE DEVELOPMENT OF ITS CYBER AND
SPACE WARFARE CAPABILITIES." If you take an interest in all the recent press about these topics, you will find this a very good read.

Enabling security through effective interface design

Kudos to the Mozilla Firefox team. I upgraded to Firefox 3 today, and shortly thereafter went to Travelocity to schedule a trip. To my great pleasure, I noticed that the SSL certificate is provided in the URL bar, with a green background to indicate it's trusted.

This information has always been available to users, but how to access it - or even the need to - wasn't something intuitively obvious. The little lock showed up, so everything is encrypted, meaning I'm fine, right? With this interface, you not only clearly see that the certificate is valid, but who it has been issued to. This required a bit of clicking around before - something few were willing to do. Admit it, how often did you check?

Not only that, but the most important details appear at the click of a button, not in a separate window but as a pop-out. Of course, the complete details are also available.

This is precisely how the industry can empower users to act securely and make the right decisions without a second thought. More integration of security features into interface design is exactly what we need, and I'm glad to see the Mozilla team start to walk that path.

A Market-based Approach to Predicting Compromises

This is an idea I've been noodling over and shopping around to some in the industry for a month or two now, and I think I'm ready to at least suggest it intelligently here to see what others may think.

I was reading a Scientific American article on the University of Iowa's long-running experiment in using prediction markets to forecast the outcome of presidential elections, and I thought: why not try a similar model to forecast data breaches and security compromises at publicly-traded companies?

As the article notes, prediction markets have been applied to a variety of different problem sets. Their implementations have ranged from the mundane to the contentious (worth a read), but their real prescience is difficult to prove and the subject of long-running debate. It certainly seems that causality wasn't on the drawing board when they were created - the article even acknowledges, "Economic theoreticians have yet to understand precisely why this novel means of forecasting elections should work better than well-tested social science methods," which extends to other uses of prediction markets as well. But hey, these are economists and business folks we're talking about, so we'll let it slide. One thing that is certainly true is that a prediction market is an effective mechanism for aggregating knowledge. Those with the most knowledge are the most likely to invest more, which means the state of the market represents the experts' best guesses on the reality of a difficult-to-measure situation.

So what does this mean in terms of the market's utility? Like a financial market, a security market could improve confidence in decision-making by consumers and businesses alike, without having to be an expert in the industry. The value of companies on the exchange represents their relative and "absolute" (I use that term loosely) data security posture. While this is unlikely to be a key decision point in any but the most specific cases, it supplements decision-making based on other criteria, and could serve as leverage for large deals and acquisitions. Do we want to invest in this company that deals almost exclusively in personal data? Do I want to open an account with this bank? You see where I'm going here.

Naturally, this model isn't without its problems, the first and most difficult of which is at the heart of many security challenges: how does one know when a security compromise occurs? Underlying this question are problems of definition, disclosure, and internal measurement. The solution to this problem is a robust set of market rules, driven by breach disclosure and data protection laws. Can these be broken? Of course, and while breaking the rules of market participation would undermine its confidence, this is a balance that is successfully struck in financial markets with robust oversight complementing the rules of the market.

Market manipulation is manifested in a little different manner than we see in financial markets. If one knows of the potential for a security breach, one could invest accordingly, cause the breach, and profit handsomely. The fundamental difference is control - in large financial markets, it's more difficult for one person or group of people to bet money on an outcome with the knowledge that they can, with some degree of likelihood, create that outcome. So, parallels to insider trading in financial markets are clear, but incomplete. That notwithstanding, while some mitigations may differ in their nature between the two markets, the presence of this problem shouldn't be a show-stopper towards market success as it can be mitigated via rigorous oversight and enforcement.

I don't see this as a panacea to anything, but rather a knowledge aggregator and magnifier. Whether or not it would be useful, or even accurate, I cannot say - nor do I believe anyone could. IANAE (not an economist), nor have I ever sincerely studied the subject of prediction markets, so it's quite possible this proposal reveals my naivety by overlooking some serious faults. If a "real" economist were to give the idea a preliminary thumbs up, or at least not laugh themselves to tears over the thought, I think further study would be an interesting endeavor. At the very least, I think applying economic models to security problems holds a great deal of promise, and is already being considered by others out there, although I haven't been able to find anyone considering this particular approach.

Update 5/27 08:51
It comes as no surprise to learn that this isn't the first time such a market-based approach to security problems has been proposed (thanks for the link, Richard). You'll find this an interesting and more general read on pretty much the same topic.

Update 6/10 20:30
Adam, and readers from Emergent Chaos, provided some good feedback on this idea. Even though the general response is that this wouldn't be a supportable approach, I appreciate the input! This helps me focus my research intentions on the most promising theories and technologies.

Are we legislating blaming the victim?

Ladies and gentlemen, I present to you HR5983, Homeland Security Network Defense and Accountability Act of 2008. From the bill, describing a proposed requirement of the DHS IG in its report to congress:

"describing the effectiveness of the testing protocols developed under subsection (c) in reducing successful exploitations of the Department’s information infrastructure."

I really fear this is another case of blaming the victim. Can more be done to raise the bar for attackers? Of course. I'll be the first to throw stones at DHS for having very, very shoddy security and doing zilch to help out the rest of us. But it occurs to me that asking DHS officials to prevent compromises is in some ways akin to giving women a bottle of mace and asking them to stop getting assaulted. The anecdote is harsh, but it drives home my point. We'd never do the latter, so why is the former an approach for which we expect results?

The real problem is the high ROI for attackers and insurmountable odds facing computer network defenders. There isn't, nor has there been, any real political consequence attached to getting "caught." Until decision makers in the executive branch show a willingness to address this gap, we will only see limited improvements no matter how strongly worded a bill is. And, to that end, it is our job as experts in the field to communicate this problem to the public, with the hope that it will flow up in the democratic way the US's founding fathers intended.

Email Authentication Frameworks: Truthiness

A few weeks ago, my boss asked for my opinion on an article by Dan Kaplan of SC Magazine titled Keeping A Secret, published 3/9/2008 (yes, awhile ago). The article discusses the larger problem of authenticating email senders, and specifically the TSCP (Transglobal Secure Collaboration Program) framework. It was a great opportunity to step back and contemplate the fundamental concerns and drawbacks of authenticating email. I'm sharing my sanitized thoughts here for the consumption of others, as I think these issues are shared amongst security practitioners everywhere - whether it's called TSCP, TEOS [pdf] (Microsoft's Trusted Email "Open" Standard), or something else.

First, a brief bit about TSCP. From their website, TSCP "engenders a common framework for secure collaboration and sharing of sensitive information in international defence and aerospace programs." It is a partnership, not so much an organization or industry trade group. The group has released secure email specifications [pdf] designed to help address the identity management problems inherent in email, somewhat as an implementation of Homeland Security Presidential Directive 12 (HSPD-12), Policy for a Common Identification Standard for Federal Employees and Contractors.

Enough boring govvie crap, though, let's get on to an analysis of the article and some critical thinking about the claims of the proponents of this and other related systems.

The two sources Kaplan uses to set the tone of this article are Northrop Grumman's Keith Ward, who frames the problem of email authentication, and Amit Yoran (NetWitness CEO & former Bush administration cybersecurity chief), who acts as a professional opinion source on TSCP. Keith does a good job of boiling down the problem we face with targeted, forged emails, and to a certain extent how they've impacted the DoD and its contractors. However, the extent to which TSCP - and indeed any email authentication framework - addresses this problem is greatly exaggerated by Yoran. He even claims the standard "helps remove entire categories of problems that plague us like spear phishing." This is simply not true. The article goes on to cheerlead TSCP as addressing everything from green initiatives to terrorism - weak claims that are clearly hyperbole.

TSCP will provide a higher level of confidence in recipients that the sender of an email from a participating member is authentic. The meat of the article really focuses around Yoran's quote above; however, there are two fundamental problems with the assertion that an email authentication framework (let's assume TSCP is flawlessly implemented) will solve whole categories of problems like spear phishing:

1 It is inconceivable that there will be any situation where all email correspondence for an account holder will be subject to this framework. Wherever there is professional correspondence, there is opportunity for spear phishing. Even where there is casual correspondence, that opportunity exists. To wit, I have seen targeted email campaigns that spoof personal correspondents as senders (scary, huh?). Any broadcast emails that come from a shared or anonymous address will not fit into such a framework. These are common, especially for announcements on contracts from the government (BAA's), mailing lists, etc.

2 The security of the system presupposes that all credentials are secure. If any credentials are compromised, this trust system fails, and phishing is not only possible using the compromised credentials, but it stands to be far more effective as the sender is "trusted." The framework provides a quick and effective response in such situations - revoking the credentials - that isn't available in classic email correspondence, but in the interim all other participants are exposed. To that end, the approach suffers from a painful paradox: the larger the system, the more useful it is and the more participation will grow. But as the system grows larger, the likelihood that some credentials will be compromised at any given time grows with it, putting us right back at square one.

All of this isn't to say that TSCP or similar frameworks are impossibly flawed to the point of being useless. Such systems do raise the bar for adversaries, making some of their approaches less tractable. Expectations should be tempered, however, and investments in them should reflect their true benefits as a real implementation. Users should also realize that strange behavior is strange behavior, even within a trusted framework.

For a long time I have been working on an entry covering identity management more broadly (and philosophically); stay tuned, maybe I'll finish it one day.

Someone's finally listening

When a hospital computer gets compromised, the privacy of a person's health records are at risk of theft. When a bank is compromised, people stand to lose money through fraud.

When defense department computers are compromised, information about the tactics and technologies used to defend our country can be lost. For years, major defense contractors have been jumping up and down, waving our hands, trying to tell the US Government that we have a major problem: compromises of unclassified systems that have the potential to impact national security. And let there be no mistake: regardless of your feelings on the subject, the lines between the networks and staff of the DoD and the defense industrial base are blurred. A compromise of one likely means a compromise of the other, and vice versa. We sit next to each other in operations centers. We build next-generation technology side-by-side.

It seems that, along with the injection of billions of dollars from a presidential directive, someone is finally starting to pay attention. Naturally, this is being presented as their idea, but whatever - the important point is that it gets addressed.

A choice quote:
The government needs the "best and brightest" from Silicon Valley and elsewhere in the private sector to work on creating an advanced warning system to prevent such cyberattacks.

The best & brightest in the DIB have been trying to help the government for years. If this means they will finally start listening (as an institution - to date collaboration has been at more of a professional than organizational level), then I welcome the change. If this means DHS will begin looking for a silver bullet to every security problem, or engaging in more security theater like that which we see at airports, then I loathe to think what this could mean. I can only imagine FTP becoming illegal over IP because an adversary stole sensitive military technology from a compromised system via that protocol. Laughable, yes, but this is a direct parallel to the approach taken in matters of airport security. We need something more than theater and throwing money at snake oil.

The important question is now: can the DHS, which has failed over its 6 years in many of its most important tasks (see also: Katrina), and the NSA, still notorious amongst the intel community for being unwilling to share data, accomplish this task? Let's hope so.

Economics and the Security Cold War

The current state of the computer security threat landscape, it has been said, is a new cold war. I feel, regardless of how deeply this anecdote holds, that lessons can be learned from it. Let's accept the cold war metaphor as an axiom for the moment.

It is widely agreed that the cold war between the United States and Soviet Union was decided by economics - quite simply, the US outspent the USSR. In an effort to keep up with American defense spending, the Soviets sent their economy into collapse. If we follow this lesson through our anecdote, the problem of security boils down to one of economics, not complete security. Slowly, the truth that no computer system or network can be perfectly secured is being accepted by decision makers. Thus, the goal of computer security becomes to make the cost of compromise higher than some other alternative. In a necessary divergence from a comparison to the 20th century cold war, and making the economics of computer security more difficult, we must understand that there is no terminal state. There is no Soviet Union to collapse, relaxing the obligation of net defenders. There will always be some entity with a computer and an ambiguous moral compass.

Economic efficiency therefore becomes the ultimate goal of security - to not just defend, but defend in the cheapest possible way, so the most robust defenses can be erected and the prospect of compromising a network becomes too expensive to warrant investment as the adversary considers options in achieving their various ends. Ideally, this makes the cost of achieving a goal more cost effective via moral and legal means. Most likely, though, it just moves the problem to another entity or altogether different domain.

Understanding the threat landscape of the environment to be defended, in this paradigm, is paramount. Adversaries that are looking to save money by sharing games, videos, or music (classically referred to as warez) can quickly and cheaply be driven out of profitability when you consider the cost of a DVD is around $25. Quite a bit more effort (money) is necessary to outspend the likes of scammers and organized crime syndicates. Once espionage - nation-states attempting to achieve multibillion-dollar generational jumps in their military technology - comes into the picture, it's easy to see that the costs become staggering.

Why, then, are we not condoning threat-appropriate strategies for different industries? The defense industrial base and DoD are starting to diverge as an entity from the rest of the world, but this is an exception. Our collective mindset needs to change, and we need to begin by educating other security professionals. Computer security defense intelligence is needed in every industry, to map the computer security needs of an organization to the economics of its adversaries. This is how security is achieved.

They did it

The information security industry has once again topped itself with stupid names for overly-categorized attacks: we now have "whaling," described as "super-personalized attacks targeted at high-level corporate employees" by CSO Online. The only way I can explain the recurrence of a new, unnecessary, and increasingly silly term every 2-3 months is as a cheap crutch for vendors and media to keep the hype alive. That's not to say the threat landscape is highly fluid and evolving quickly, but come on, does every minor twist need a new buzzword? Maybe I'm behind the curve, but this is the first I've seen this term.

I can't help but to think that some level of attention to detail in the message being conveyed and a bit of effort in understanding the audience would go a lot further in educating the public on the seriousness of the threat than overclassification that, in the end, only serves to confuse.

That's it, I'm creating a few new tags to track this: "overclassification" and "publiceducation."

EPIC files FTC complaint on spyware-for-sale

My roommate, a lawyer for EPIC, recently filed a complaint with the FTC about companies that sell spyware on the premise that it, well, lets you spy on people. This is a novel approach to tackle a serious problem that aggravates the current explosion of malicious software on the internet.

More relevant to his motivations, this was specifically filed in an attempt to raise awareness and combat the use of spyware by men stalking and harassing women. Imagine what a powerful weapon this would be for a jealous ex or predator. The perpetrators already have figured this out. Legally, this is a gray area. Prosecutors are hesitant to pursue cases given the lack of precedent, and that means law enforcement is hesitant to build a case. While the legal system goes through the long and painful process to figure out the ground rules on this type of software (it has its uses - investigators will use this type of software legally to build cases with appropriate legal authority), people are suffering. By claiming unfair trade practices, as EPIC has, attention is drawn to the issue, and hopefully vendors will stop encouraging troubled individuals to break the law through their advertising.

He and I would appreciate it if you spread the word.

HistoryCENTER: Spying

My TiVo knows me well. This morning, it recorded a show on The History Channel titled "HistoryCENTER: Spying." History Channel's Steve Gillon does a good job of presenting material in this show from the few other episodes I've seen, but while educational, I normally find HistoryCENTER as exciting as watching paint dry. This one happens to fall right between one of the bigger political debates of the time and my profession, and as such I was immediately drawn in. The description, from their website:

Security vs. Civil Liberties: How have presidents during wartime walked the sometimes difficult line between protecting Americans and their civil liberties? And will the Bush Administration's decision to spy on American citizens without warrants end up as a chapter or footnote in American history? Guests: Timothy Naftali, professor of history at the University of Virginia's Miller Center and David Kahn, author of The Reader of Gentleman's Mail . Hosted by History Channel resident historian Steve Gillon.

I suspect this aired a year or two ago, but it is relevant today nonetheless. I found it an interesting historical perspective on the issue, and as fair and balanced as anything else I've seen on this topic. It's a javascript nightmare, but a replay of this is available courtesy of AOL Video.

If you're in the industry, you should care about and pay close attention to these discussions. Remember than what you're doing as security analysts is, in many cases, spying (network security monitoring, auditing transactional content, etc). How these public debates are resolved may directly impact our field, and in our positions of trust, we're obligated to strike a fair balance between the powers granted to us and the privacy of those impacted by our actions.

Quis custodiet, ipsos custodes?

Recommended Reading: IEEE Security & Privacy

A few months ago, I was first introduced to IEEE Computer Society's Security and Privacy bi-monthly periodical. Available in both print and web format, I've found most of the articles insightful, useful, or theoretically promising. So far. Hype has claimed many a fine resource in the field, but I'm optimistic IEEE will be able to insulate this one from that common fate. Yes, our industry is still quite nascent. I'm glad to see a reputable, mature organization like IEEE attempt to put some discipline around it. I'll be the first to admit it's not perfect, but it certainly shows promise. To see what I'm talking about, check out their latest highlights. Articles appear by both recognized industry professionals (Bruce Schneier for example, of whom I'm a particularly big fan, in the last issue), as well as researchers with something valuable and intelligent to say who may not be "household" names.

They have an RSS feed. I suggest subscribing on your favorite reader and checking out the summaries for a few issues, you may find this a worthwhile investment. Or, become an IEEE member and enjoy all the benefits of their world-class online library and access to the top professionals in many technical fields.

2008 DoD Cybercrime Convention

I will be lecturing again at the 2008 DoD Cybercrime Convention in St. Louis, MO. Last year, I spoke about advanced attacks from the front line. This year, I will be discussing tactical tool development supporting incident response from both a theoretical and practical perspective. Abstract, FTA:

Highly-motivated, advanced attackers have been successful in adapting their techniques to avoid traditional defensive and analytical tools. Anti-virus, firewalls, and IDS’s are no longer effective countermeasures to these adversaries, forcing analysts to quickly develop specific tools to combat certain aspects of an attacker's M.O. In this presentation, various new & emerging tools developed by analysts that have been successful in helping combat these threats are discussed.

Proper customer email correspondence

Despite the expenditure of a great deal of effort, users are still ill-prepared for email-borne threats. Much of this is due to the mixed messages users receive. We tell users to not click on links in email to strange websites, then send them surveys from third-party companies they've never heard of and encourage them to participate. We tell users to not open attachments they're not expecting, then send out broadcast messages to many recipients with a PDF containing the information they need to read. When I say "we," I don't mean security analysts, but rather employers, service providers, vendors, etc. It's no wonder users still have no idea when they can and can't click on a link, or open an email or attachment.

I get my car insurance from Progressive. Yesterday, I received the following email. This is the type of actions that are needed to maintain user diligence and continue to leverage email as an effective communication mechanism.

======================================================================

Important changes are coming soon to your Progressive e-mails.
======================================================================

Dear MICHAEL CLOPPERT:

We're writing to let you know about some important changes to your
Progressive e-mails to ensure that you continue to receive and
recognize them.

Please note these key changes in your e-mails over the next few
months:

- E-mails will be sent from a new address:
customerservice@email.progressive.com

Please add this e-mail address to your address book or approved
senders to ensure that our e-mails reach you.

- Links in the e-mail will point to re.progressive.com instead of
re.progressivedirect.com.

An Open Letter to SANS

I have been a strong proponent of SANS and GIAC for many years. Their training is, quite simply, the best available in many of the sub-disciplines within Information Security. Their staff represent the best of the best in the industry. I am a member of the SANS advisory board, and while I have no financial incentive in the success of the organization, I feel the continued health of SANS is vital to the Information Security discipline. It is for that reason that I have become concerned about some of the decisions made by SANS over the past few years. Beginning with the decision to separate the practical from certification, and continuing through to the introduction of their Master's degree, I see decisions increasingly being made solely around financial considerations.

In August, Stephen Northcutt asked the advisory board for our thoughts on discontinuing an unprofitable certification. I am posting the bulk of my response below, as it articulates many of my concerns with SANS. It is my hope that by voicing my opinion, positive direction can be maintained in the organization and, by consequence, the industry as a whole.

This cuts right to a core issue about SANS that I have been meaning to bring to the attention of the advisory board & leadership for some time, which is this: SANS needs to decide if its primary mission is to make money, or to educate. Many decisions I've seen from the leadership at SANS in the past few years seem to indicate that it is the former. I hope, for the sake of the integrity of the organization, that this tendency can be changed. It would be rather naive of me to think that this note would begin to turn the ship, but I hope it can raise awareness of the issue. I can say with absolute certainty that it has been noticed by professionals and decision-makers outside of SANS (some of whom I respect greatly); this is a real risk.

Bringing this more to the point, I believe that the value of certifications should not be solely measured by their profitability. SANS needs to remain in good financial standing, no doubt, but costs can be reclaimed elsewhere. Other untapped profit opportunities (corporate sponsorship, linking employers with job hunters, etc.) are out there. Universities face the very same trade-offs. In recent years, a debate has grown about the cost and value of technical degrees versus liberal arts degrees. Merely charging more for some degrees than others was highly controversial for the Universities; dropping less profitable, more technical degrees would be considered unconscionable. If SANS wants to operate at a similar level, I feel it must adopt this sort of mindset.

If [this certification] is judged to be valuable as an educational tool to the Information Security community at large, and it can reasonably be afforded by SANS, it should be kept. Otherwise, you needlessly sacrifice education for a larger bottom line, which advances a financial rather than educational mission. If we feel [this certification] in its current instantiation is a bad way to vet the top of the InfoSec talent pool, then it's a different problem we're talking about and financial concerns shouldn't really play a part in our discussions - the shortcomings should be addressed and a new approach tried before the life of this certification is prematurely cut short.

Overhaul Anti-Virus Products NOW

It's been a few weeks since the below story appeared in SANS NewsBites, but I wanted to point it out to the community. The story, and subsequent NewsBites editor comments, speaks volumes to not only challenges with Anti-Virus that we're currently experiencing, but also to the attitude of the established Anti-Virus industry towards anyone not already part of their collective. I've lamented about the state of the anti-virus industry in the past, but this particular problem is the most dire for their industry - and the rest of us. The nature of the industry's rebuff of Ed Skoudis and Tom Liston (both highly-respected and recognized security professionals) that is discussed in the comments section below echoes of attitudes I've found amongst individual "antivirus researchers" with whom I've worked - some even as peers and coworkers. I think the root of the problem is Antivirus companies and contributors have developed their own self-serving, self-congratulating circle that espouses "group think" and rejects constructive criticism from anyone not a part of this clique. Further, they do not see themselves as security analysts and companies. Malware has become woven into the fabric of the security challenges facing entities in the 21st century and at this point the two can scarcely be separated in many cases. It's time these companies and contributors begin seeing themselves as part of the larger security industry, not simply a clique that sits at the "cool kids" table at lunch.

Enjoy:
TOP OF THE NEWS
-- Overhaul AntiVirus Product Testing Now
(October 10, 2007)
Momentum is growing for an overhaul of the way anti-virus products are tested. Presently, tests focus on signature-based malware detection and have changed little over the last 10 years. However, anti-virus technology is changing to meet the demands created by new malware, and the organizations believe that tests need to be reformulated to reflect that change. The tests don't examine the effectiveness of behavioral anomaly malware detection, a technique that is proving valuable in catching malware that spreads quickly. Proposals for new testing methods and procedures will be presented in November at the Association of AntiVirus Asia Researchers 2007 Conference in Seoul, Korea.
http://www.theregister.co.uk/2007/10/10/av_tests_revamp/print.html
[Editor's Note (Skoudis);: Given the change in threat, with new malware introduced every hour, this is a good development. My colleagues and I have been pushing for something like this for about 2 years now. I made a call very much like this at a talk during the Anti-Spyware Coalition meeting in February 2006. My colleague Tom Liston and I released a tool called Spycar a year and a half ago to test the behavior-based claims of anti-malware vendors, and discovered that most were either not doing any behavior-based detection at all or had severely broken behavior-based functionality. Many of the anti-malware vendors publicly scoffed at our testing, while a few said that our results were interesting. Just last month, my colleague Matt Carpenter and I tested a bunch of products again, and found that the behavior-based detection capabilities of all the major vendors were severely lacking. I'm hopeful that this new initiative will help improve the state of
behavior-based detection.
(Liston): Saying we were "skoffed at" is Ed's way of being polite. Essentially, they told us that we were amateurs who didn't know what we talking about, even _after_ we had discovered and disclosed serious flaws in the behavior-based detection offered by several major vendors. With increasing numbers of malware being released and the rise of targeted malcode attacks, behavior-based detection is going to become
anti-malware's front line defense. It's nice to finally see this reality being addressed by AV vendors' testing methods, and, of course, it's also nice to be vindicated.
(Northcutt): The anti-virus industry has served us well. Without them, computing might well have failed, but they are a tad stuck in their ways and malware grows ever more complex. I hope that projects like Spycar, which hold vendors responsible for something beyond signature detection, continue to prosper.]

User Education is NOT (necessarily) the Answer

In the past few years, user education has been all the rage in the security industry. Today, we are quick to point out that one of the biggest computer vulnerabilities is actually not in the computer at all, but rather the mound of carbon and water exerting force normal to the surface of the keyboard. Unfortunately, this externalization of the security problem has become an excuse for the shortcomings of IT and information security just as frequently as it is the actual cause of compromise.

While the computer industries have largely failed at this important task until very recently, it is not the panacea that we are making it out to be. Anytime you hear about computer security failures, the response from "security experts" is always "patch and educate your users." This is important, but such a response trivializes the underlying complexities of computer systems and the persistence of the advanced and skilled adversary. Take the following example from Forbes discussing alleged security breaches at military contractors which quotes Allan Paller, director of SANS:

'More important than the elusive identity of hackers is the question of how to keep them at bay. Paller recommends that corporate security offices teach employees to be on the lookout for fraudulent e-mails. Companies could "inoculate" staff by occasionally spoofing phishing e-mails themselves and then alerting their victims, Paller suggests.'

It's a shame that someone as highly visible and regarded as Allan Paller would take the opportunity to presumably get a sound bite before using his contacts to understand the facts, if any, behind the article. Regardless, this is a perfect example of what I'm talking about. User education can only go so far, and is unlikely to thwart dedicated attackers. To follow this example through, what if the attacker in question includes a signature in the email with legitimate contact information? What if the name in the From: bar is someone the target knows? This information can be trivially forged, but it can also be just as trivially collected. Have you ever scrutinized emails that are "from" someone with whom you work, with their valid signature at the bottom, containing a Word document that seems to be topically relevant? Then why would your users? This goes further: adversaries can - and have - compromised real accounts which they then use to spread infected documents. So in some cases even legitimate email can't be trusted.

The bottom line is that user education is important. We all know it's important. But let's make sure this is the answer when it needs to be, and not given as a response action to any and every notion of computer compromise. Doing so will inevitably lead to an undermining of the industry's credibility if it isn't tempered.