Week 8 Discussion

Three outside reading topics this week, a little longer than usual, but in exchange there is only one discussion assignments.

 Offensive/Defensive Conflict within the NSA

 Early in the textbook reading for this week there was a discussion of the inherent conflict in having the NSA be in charge of both offensive and defensive capabilities. The textbook is perhaps not as explicit as it could have been when discussing this.

 The conflict is pretty simple. The NSA, and other intelligence agencies, rely upon zero-day exploits to access devices used by their targets. Typically those zero-day exploits are attacks on commonly used software, such as Windows or Flash. To make their offensive capabilities as effective as possible, the NSA wants to keep those exploits secret.

 But defense requires closing as many vulnerabilities as possible. So to meet its defensive mission, the NSA should notify the manufacturers (Microsoft or Adobe) of those zero-day vulnerabilities so that patches to remove the vulnerabilities can be created and applied.

 It's a huge conflict. The NSA may well know about vulnerabilities that are currently being exploited against U.S. networks, but it won't disclose those vulnerabilities so that they could be patched.

 This is actually an old problem, but has become much more public in the past couple of years, and possibly even more damaging. The reason is that until the past couple of years, the general assumption has been that the zero-day vulnerabilities exploited by the NSA have all been discovered within the NSA itself, and hopefully, that means that no one else knows about them.

 But that is changing.

 Earlier this quarter you read about hacking tools, such as the Rubber Ducky, that are readily available on the internet. These tools all exploit known vulnerabilities – not zero-day vulnerabilities.

 But there is also a market for zero-day vulnerabilities and exploits. In fact, these are often packaged into software that makes the exploits easy to use for “surveillance”. These tools can be purchased by countries (and others) to start their own cyber espionage projects with little technical expertise.

 One company selling such products it Hacking Team :

 http://www.hackingteam.it/index.php

 They were in the news because they were themselves hacked by someone who publicly released reportedly 400GB of data, including emails:

 http://www.telegraph.co.uk/technology/internet-security/11735575/Hacking-Team-blames-foreign-government-for-attack-on-systems.html

 (by the way, ignore the claims by Hacking Team that the attack was sophisticated – that's what every company claims … some details did eventually come out and it was a typical attack, nothing particularly sophisticated)

 How does this tie back to the NSA?

 Well, the NSA is reportedly one of the biggest purchasers of zero-day exploits. These same exploits may be purchased by the Chinese or Russian governments or anyone else. But yet, U.S. computers remain vulnerable to those exploits. In this case, the NSA knows about vulnerabilities that could very easily be used by other countries to attack systems within the United States.

 That's why this has become a much hotter topic in the past couple of years. Supposedly there's a process that the NSA goes through to decide whether to notify the manufacturers of such vulnerabilities. But the process itself is classified, and in general the tech community is quite skeptical of it.

 Here's a recent article about this by Bruce Schneier. I don't believe that we've read anything from him previously this quarter, he's perhaps the best known popular writer about cybersecurity. He comes from a technical background but can write clearly for a non-technical audience. He's written several books, including one that he plugs in this article (Data and Goliath - it's a great book). His website, www.schneier.com, is one of a handful that I consistently follow.

 Here's his article about the conflict within the NSA, including discussion of Hacking Team in particular:

 http://journal.georgetown.edu/hacking-team-and-the-nsa/

  Cooperation with Law Enforcement after a Breach

 The textbook (and my commentary) talks about reasons why organizations often do not cooperate with law enforcement after a breach. That may be slowly changing, At the very least, government agencies are trying to change this. Here's an article that discusses this, at least in part:

 http://www.swlaw.com/blog/data-security/2015/06/08/doj-unveils-new-cyber-security-unit-and-urges-cyber-attack-victims-to-cooperate-with-post-breach-investigations/

 This article refers to an article about the FTC that is also quite relevant:

 http://www.swlaw.com/blog/data-security/2015/05/28/inside-insight-how-the-ftc-approaches-data-breach-investigations/

  Should Software Companies be held Liable for Vulnerabilities in their Products?

 Whenever you install software, you click a license agreement. You never read it, almost no one does, except perhaps the lawyers that write them. But one thing that is in every one of those agreements is that the manufacturer of the software has no liability for anything bad that happens to use by using that software above what you paid for the software.

 It's a pretty unique situation, we don't agree to that with any other type of product that we buy. Consider cars for instance. If an automobile manufacturer discovers that their car has a flaw that can cause serious damage, they will recall the car and repair it at no cost to the owner. But if a software manufacturer finds a flaw in their software, they have no obligation to fix it or to even tell you about it. And even if they do “fix” it, what that means is that they will make a patch available for you to install, if you happen to find out that it's available (the exceptions being a few software products that automatically do their own updating).

 There have been occasional calls for software manufacturers to have some liability for flaws in their products. The arguments tend to end up like this: software manufacturers argue that liability will stifle innovation, while the other side says that software manufacturers produce products with lousy security because there's no consequences for doing so.

 New Republic ran a series of articles on this topic back in 2013. The basic issues and arguments haven't changed much since that time. This is a five part series, and in total it's fairly long. But this week there are only two discussion assignments so that you will have more time to read these articles.

 The link here is to the last article in the series. Don't start by reading this article! The introduction to this article provides an overview of the entire series and links to the previous five articles. Start by reading this introduction and then go back to the first article in the series.

http://www.newrepublic.com/article/115421/security-burden-shouldnt-rest-solely-software-user