Security in Industry and Academia

Apple gets an F

2008-07-29T21:00:00.002-04:00

Apple needs to start paying half as much attention to security as they're paying to design. Weeks after every other major vendor has released a patch to what we affectionately call the Kaminsky DNS Flaw at work, and months after being informed of the problem, Apple still hasn't patched their implementation.

I never had a soft-and-fuzzy feeling about Apple's commitment to patching, but for them to sit on a serious, ubiquitous flaw as their competitors react responsibly for once shows in no uncertain terms that their priorities seem to lie elsewhere.

Microsoft is a great pioneer in doing things wrong - from a security perspective, anyway. You'd think Apple would do everything it could to differentiate itself and win more market share. You'd think...

FlyClear passes privacy audit

2008-07-23T09:01:00.005-04:00

In a recent press release, Verified Identity Pass, Inc. - commonly known to US air travelers as FlyClear - announced they had passed a four-month long audit of adherence to their own privacy commitments. This is a rare good-news story that acknowledges the significant concerns raised by privacy groups such as EPIC. To what end their own stated privacy commitments addresses those concerns I will leave to the advocates, but an important disclaimer from the audit report was left out of the press release.

...the projection of any conclusions, based on our findings, to future periods is subject to the risk that the validity of such conclusions may be altered because of changes made to the system or controls, the failure to make needed changes to the system or controls, or a deterioration in the degree of effectiveness of the controls.

I wouldn't even point this out if we were talking about anything but a government-sponsored program/company: periodic auditing is absolutely essential to ensure ongoing confidence in the program. The more consecutive audits passed, the greater public confidence grows. I haven't signed up for the program in part because I was concerned about the privacy of my data. This helps offset my reluctance. The effectiveness of the entire program, of course, is another topic altogether.

Dan Kaminsky is NOT a hero

2008-07-16T17:01:00.001-04:00

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:

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!
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.
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..."
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.

In case you missed it...

2008-07-12T09:14:00.003-04:00

In the most recent SANS NewsBites, editor Brian Honan points readers to a great skit on identity theft by British sketch comedians Mitchell & Webb. Hilarious, concise, and satirical-just what you'd expect from British humo(u)r. Worth the 1:55 if you have it to spare.

Malware, defined

2008-07-07T10:08:00.003-04:00

The Merriam-Webster dictionary has released a list of 100 new words defined in their dictionary. Among them is the most commonly red-squiggly-underlined word in any document I type, malware. As reported by Die Welt:

Malware (1990): software designed to interfere with a computer's normal functioning.

Differentiating CNA and CNE

2008-07-03T08:44:00.003-04:00

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.

Readying children for a police state

2008-07-02T09:48:00.002-04:00

A coworker sent me a link to this wiretap kit for children ages 10-14 being sold by Toys-R-Us. This is just terrifying on so many levels...

Enabling security through effective interface design

2008-06-20T21:15:00.007-04:00

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.

Reducing malware analysis with code comparison techniques

2008-06-07T11:52:00.005-04:00

This is another topic that I file under "someone must have certainly done this already"...

We're struggling with the influx of custom malware that has exploded since 2006. The skills necessary to reverse engineer code are hard to find, and expensive when they surface. As a result, bandwidth is always limited for an organization faced with the need to understand the inner-workings of malware to assess damage, scope, and impact of a system compromised by custom code.

There have been a few discussions within my team recently about how these valuable skills can be focused. For years we've worked to reduce the set of malware that necessitates deep analysis by identifying techniques that enable us to make inferences about the unknown code by comparing it to similar known code, or making assumptions based on its context. Discussion has heated up on this topic of late, especially since a colleague began using an intriguing, if unproven, statistical technique to group malware.

The first question that should come to the reader's mind is, "haven't the anti-virus companies already solved this problem?" They should have. But we've seen first-hand that if they know how to solve this problem, it is either ineffectively implemented or not implemented at all in their code. I could tell stories, but that's not the point of this entry.

The technique that keeps coming to my mind as promising is an analysis of code which represents its flow control as a graph, and then searches for isomorphisms in other code flow graphs to identify identical or similar executables. Identifying complete isomorphisms between graphs is a well-studied problem. For one such example, this paper discusses its utility with VLSI hardware, comparing circuit diagrams to chip layout. It stands to reason that a similar technique could be used with what I'll call the identical software flow problem.

Those with an interest in computational complexity theory would find the following both relevant and intriguing: the graph isomorphism problem has not been proven to be NP-complete, nor is it known to be solvable in polynomial time, meaning it is only NP. Special thanks to Wikipedia for this link (huge PDF), which discusses solving the graph isomorphism problem efficiently despite being NP.

The problem of identifying similar pieces of code, which I'll call the software flow similarity problem, is much more involved and from what I can tell much less studied. In this case, flow control graph subsets would be compared between pieces of code. Some key questions here are:

How big or complex must the subset be, as compared to the complete flow graph, to be meaningful?
How many matches of graph subsets must be identified to confidently call code segments similar?

This is but one technique, and determining software similarity is likely to involve a number of other techniques - computed, observed, statistical, or what have you. I feel this approach would be a very strong indicator on its own, although it would be far more difficult to implement and study than some other heuristic approaches. I'm going to continue searching for papers which discuss these techniques; it seems hard to believe no one has done this before.

Nerd humor

2008-06-07T11:42:00.004-04:00

Thanks to my girlfriend for finding this one...

The image isn't coming out so well in blogger, so if you don't have uber-perfect vision, the original is here.

Introducing Ex-Tip

2008-06-01T22:00:00.001-04:00

In this post, I'd like to introduce a tool I've been working on called Ex-Tip. Begun as a GCFA Gold practical and developed in Perl, the code is very premature at this point. I intend to develop it through a Sourceforge site I've registered for that purpose, although I haven't yet uploaded the code. I will communicate updates through this blog.

Full disclosure: I do not consider myself to be a developer. The version 0.1 implementation was designed as a proof-of-concept to demonstrate the utility of an easily-extensible, multiple input-output timeline generation tool. It was not designed with memory nor computational efficiency in mind, and has many limitations that can be addressed via further development. Of course, I welcome any feedback, or solicitations for offers of help.

Here is the introduction section of the paper that this code was meant to accompany:

Tools exist to construct timelines based on modify, access, and create times of files on various filesystems to aid in forensic investigations. Sleuthkit's mactime in concert with fls or macrobber is a common example. However, in most investigations, the timeline needs of the forensic analyst have become far more encompassing than simple file activity. Investigations often necessitate a step-by-step recreation of events pulling time data associated with Windows registry entries, anti-virus logs, intrusion detection systems, and any other data available to supplement filesystem activity. At times, both in the lab and in the field, investigators find new time-stamped data that warrants inclusion in a timeline, such as custom application logs. As the digital forensics field matures, the list of critical data available grows longer, as does the number of timeline visualization tools available for data presentation. Adding to the complexity, the nature of these data sources is dynamic as software versions change.

All of this considered, one can see that a gap has emerged between the timeline data needed by analysts and flexible, portable tools available to easily consume this data - aggregation, normalization, and visualization, to be specific. This paper describes an extensible framework to achieve these ends, with plug-ins provided for common timeline data sources and output formats as proof-of-concept.

Image courtesy http://www.timemiser.com/

A Market-based Approach to Predicting Compromises

2008-05-26T16:39:00.002-04:00

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.

Strategic warfare in cyberspace

2008-05-18T15:11:00.003-04:00

The USAF is considering building its own botnet. This is a really dumb idea. Richard Bejtlich has a good blog post which discusses many of the obvious problems here, but there are other reasons not to do this; foremost, that the USAF would be ignoring the advice of one of its experts and pioneers in the subject of the strategic use of information warfare.

First, isn't this approach really nothing more than effective central management of computer resources? I think that is a great idea. If the USAF has to use a buzzword and a cool twist to convince base commanders to buy into the central management of all of their computers, then so be it.

However, if the true purpose is to build an offensive strategic capability, then I fear we're in trouble. For the remainder of this entry, I will quote liberally from Col. Gregory Rattray's (8th AF, retired) seminal book, Strategic Warfare in Cyberspace. The argument against such an approach can be made almost entirely from quotes from this text.

In focusing on offense, strategic warfare theorists generally have been influenced by a belief that new technologies will allow attackers to get through and attack key centers of gravity. These theorists assume that adversaries subjected to such attacks have significant vulnerabilities. Strategic warfare theories assume that offensive strikes will prove capable of inflicting sufficient punishment on civilian targets or enough damage on infrastructures supporting military operations to influence adversaries and thereby achieve coercive or deterrent objectives. (p. 98)

What adversary of the US exists which could be coerced by such a force? What national "center of gravity" exists in cyberspace outside of the US? To date, we're the only ones vulnerable to such an attack. And not only that, as we saw during the cold war with the Soviet Union, developing this capability will only encourage our adversaries to develop the same capability - which could be used far more effectively on us than vice versa. To wit:

Enabling Conditions for Waging Strategic Warfare
[...]
3. Prospects for effective retaliation and escalation are minimized. Actors initiating strategic warfare need to assess an opponent's likely reactions to a strategic attack and possible courses of action after an attack has been sustained. Such attackers must also assess, prior to initiating attacks, their own vulnerabilities to strategic attack and their adversary's capability to retaliate. The efficacy of an actor's threat or use of attacks will depend on its vulnerability to retaliation both in kind and through other military and nonmilitary means. (p. 99-100, emphasis mine)

And even assuming that all of these preconditions are met - that the military invests significant resources in its defensive posture to an attack in kind - even then, the efficacy of this strategy is dubious at best:

The use of force is not simply a linear exercise in orchestrating one's own forces and unleashing them with certain effect against the enemy. Adversaries will attempt to anticipate each other's actions and minimize their detrimental effects. The likely course of an opponent's actions can only be guessed at, however, not determined with any certainty. As eloquently developed by Edward Luttwak, strategy is governed by an interactive logic rather than a linear logic. (p. 78)

Prior to 6 August 1945, the strategic bombing campaigns of World War II had opened up a new battlefield for conflict based on attrition. These campaigns were neither quick nor decisive. Those assessing the potential for waging strategic information warfare have so far paid little attention to the possibility that its actual use may well confront similar hurdles in terms of requirements for lengthy campaigns and lack of decisiveness. (p. 84, emphasis mine)

Does anyone still think this is a good idea or wise investment of resources?

Are we legislating blaming the victim?

2008-05-12T23:42:00.007-04:00

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.

Measuring the Effectiveness of Bulk Data Collection

2008-05-11T23:58:00.003-04:00

While decompressing from a brutal day of studying for a crypto final, I came across an article on BBC which argues that "huge investment in closed-circuit TV technology has failed to cut UK crime." My first thought was, did they really expect it to?

A lot has been made by the media and bloggers of the efforts in London to deploy thousands of CCTV cameras, much of it surrounding civil liberties of British citizens. I'm going to set aside civil liberties concerns for now and focus on more objective measurements (not that these issues are not important, but rather they aren't important to my point here).

To sell or design a widespread CCTV system on some notion that the thought of Big Brother will somehow keep the citizenry well-behaved is so tragically Orwellian that I don't think it warrants another mention. However it was sold to the public or government, and regardless of these silly claims, measuring its success in terms of crime reduction belies the real investigative benefit of such a system: as a forensic tool.

To bring this into an area which I have more expertise, I think of CCTV in the same way that I think of full packet capture on an important network segment. How much sense would it make to have an analyst sit and watch every packet, every flow, every session that blows by this sensor? How much would I expect detection of malicious activity to increase? Not at all. Even if it were possible for an analyst to keep up with the data rate of the sensor (which is the case with CCTV), so few things happen in the timespan of the human attention span that have investigative prima facie meaning that I would expect the results to be negligible. However, when placed in the context of a known attack, suddenly benign or minute details become significant. That white van parked in a parking spot that leaves 1 minute after a robbery a block away now has some meaning. That weird base64-encoded comment in HTML is now of concern.

Active monitoring of these dragnet systems is ludicrous. If some correlative system can be built to reduce data - and that's a big if - then some limited monitoring might make sense, but we are nowhere close to having a technique that will allow us to do so and this argument is moot.

The bigger story is that only 3% of London's street robberies [are] being solved by security cameras. This is certainly concerning, but this is one slice of crime. How do these tools assist in other crimes? The information provided in that article is limited. I would like to see a comprehensive study on the forensic use of this tool by London police - perhaps one is available that I haven't seen. Both the police and the media should start focusing their attention on this aspect of the system - for critique, improvement, and measuring success. That's what we'll be doing as we build a full packet capture system at work, and how we'll be measuring its success.

Nothing that hasn't already been said...

2008-05-03T16:35:00.007-04:00

...but it bears repeating.

Security has its limits. Thanks to Igor for the help on this entry.

Image on the right is directly from the Ohio state patrol website. Image on the left source unknown; Soviet Russia 1950's ("Be sharp sighted and vigilant").

Windows XP DEP in action

2008-05-03T16:13:00.002-04:00

For a bit of comic relief, I'll share with you this error I got at work not too long ago:

Email Authentication Frameworks: Truthiness

2008-04-22T23:31:00.005-04:00

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

2008-04-09T01:11:00.005-04:00

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

2008-04-06T20:09:00.003-04:00

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.

On Blaming The User

2008-04-06T17:30:00.003-04:00

I've written previously on how blaming users is a flawed approach to security. Recently, in an interview with Educause, Bruce Schneier opined:

Users are going to pick up their knowledge from their experiences. You can try to teach them stuff explicitly, but it's not going to stick in the same way that experiences do, and unfortunately, the experiences often don't match our reality, whether it's an experience of fear, an experience of an attack, or an experience of no attacks. Rather than focus on what can we do to educate users, we need to focus on building security that doesn't require educated users. That will be much more resilient, because while there are some educated users, there are a lot of noneducated users.... For example, my mother is never going to be a security maven—not because she's stupid but because it's not her area of expertise. And we can't expect it to be. If I say, "Look, Mom, you didn't know enough to do this and that, and you deserve to get hacked," I think that's blaming the victim....
(Emphasis mine)

Users aren't going to act securely. It's worth reiterating this message until the security industry finally decides to "get it" and start accepting responsibility for security problems, rather than passing the buck.

Philosophy of Blogging

2008-03-23T14:38:00.004-04:00

In what's become a weekly ritual, I sit here on Sunday in my comfy athletic wear, putting off all things necessary to begin my day by reading my RSS feeds because I know what comes next is work - this week, six formal mathematical proofs for a cryptography class I'm fighting my way through. This week, as with many, I found yet another fantastic blog: Emergent Chaos. Brilliant in both concept and content, I highly recommend it to anyone whose interest draws them to my blog.

While thoroughly enjoying the recent posts, I came to a realization that should be self-evident to me a long time ago: the difference between blogs I find useful and useless, and the resultant impact to my own blogging. For me, a useful blog contributes something new - something I can't find anywhere else. A blog that simply reinforces a belief I already have by making the same argument I've heard over and over again, or one that simply rehashes analysis I'm already familiar with, does not expand or enlighten my mind. The more different, the better. And as I discover more and more fantastic blogs that expand my mind, I find it harder and harder to contribute my own content to the universe of knowledge on the web. How can I possibly contribute to such a vast body of information?

While this is the first explicit self-realization I've had of this nature, it helps me explain to both myself and the few who read this blog my history of unpredictable posting - sometimes frequent, sometimes rare; sometimes technical, sometimes philosophical. While I cannot be sure that everything I write will be unique, that is my goal, and hopefully it makes this blog predictably useful in the blogroll of the global internet.

QOTD

2008-03-20T00:57:00.003-04:00

Thanks for inspiration from my girlfriend on this one:

If stupidity is doing the same thing over and over and expecting a different result, then
stupidity is ignorance to idempotence.

They did it

2008-03-17T01:24:00.005-04:00

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."

Juvenal meets Rijndael

2008-03-12T00:25:00.004-04:00

A first century philosopher meets the Advanced Encryption Standard in 21st-century American body art realized as hex... with a very slick typeface. Ciphertext starts at the front of the shoulder and progresses downward. Enjoy.

8c 0d 04 09 03 02 e2 f7 5d a3 17 73 db b0 60 d2
4e 01 a1 e1 31 b4 d8 61 f4 63 fa 79 9d f8 7b b0
3f a1 21 05 f4 9f 75 dc 50 bb 49 36 f6 76 6c 27
1f a8 84 a5 50 44 fa d4 b6 2f ad c6 f6 ad 22 cb
c4 63 b7 83 2c e7 3f 6f 48 1a 91 89 2b 54 d0 60
ca cf cf 16 f7 bc 5e c6 fd 1b 8f f2 49 07 f3