<div dir="ltr">I wanted to cover some of the issues with the NSA Task Force document. I'll begin abruptly here:<div><br></div><div>The document recommends splitting the NSA up quite a bit - specifically moving defense (INFOSEC otherwise known as IAD) to one organization, and offense (SIGINT, TAO, etc.) to another.</div>
<div><br></div><div>It also recommends drastic changes to the way classified information is stored and used, and a massive about-shift in how the SIGINT community handles 0day.</div><div><br></div><div>As is highly publicized the document also recommends changing the way the government stores massive databases and having the big telecoms do this instead (which, of course, they probably already do at some level).</div>
<div><br></div><div>The most glaring issue in the document is that the recommendations assume a massive injection of money and resources probably equal to doubling the black budget, at a time when sequestration and budget cuts are forcing the exact opposite.</div>
<div><br></div><div>I will start with resources, which is a problem that the IC struggles with daily. In particular, the clearance system is completely and obviously broken, but not in a way that would be fixed by this document's recommendations. Like most American companies, the IC struggles to fill positions with qualified technical individuals. IAD and SIGINT, being both complementary missions and in many ways technically similar, provide the ability for people to be trained and moved to more challenging positions within the organization - or simply rotated to avoid burn-out. The military side (Cyber Command) may eventually stand up on its own in terms of manpower, but just got its first real money in January of this year - it's not ready to be completely independent, and may not be for years.</div>
<div><br></div><div>Vulnerabilities (in this case described as 0days and widely disowned in recommendation 30) are a more complex subject that currently go through an equities process to attempt to provide protection while enabling offensive operations. It is demonstrably true that the IC fixes vulnerabilities in both government and commercial systems that it deems a great threat - but the document describes a process that would unilaterally disarm our offensive teams for no clear defensive benefit. Likewise, the US Govt does not always have the intellectual property rights to 0days that would allow it to disclose them to a vendor - and should it start ignoring the agreements with its supply chain, the supply chain (which may be individuals, companies, other governments, other parts of the USG, academic institutions, etc.) will quickly find other customers. </div>
<div><br></div><div>The equities process also has to consider collateral damage. Imagine if a vendor received reports about a set of vulnerabilities which taken together disclosed a new attack surface, mathematical static analysis technique, or cryptanalysis technique. The cryptographic hash collision attack that was used in the FLAME trojan is a good example of how much can be revealed with a single vulnerability. </div>
<div><br></div><div>The paper states without any supporting evidence "In almost all instances, for widely used code, it is in the national interest to eliminate software vulnerabilities rather than to use them for US intelligence collection." This is demonstrably not true since without these vulnerabilities a large segment of extremely valuable targeted collection would go blind and fixing all USG known vulnerabilities does not necessarily decrease the risk from running buggy commercial software.</div>
<div><br></div><div>One assumption in the paper is that moving your searching and minimization to the endpoints of your collection (your trojans themselves, the phone companies, etc.) is a wise thing to do. However, your searches themselves are often classified at a very high level, especially taken as a whole. Likewise, the equipment and software required to perform the searches is expensive to build and maintain, and telecom companies would very much not like to bear that cost.</div>
<div><br></div><div>As another example, collecting all of the email on a server, with the exception of US Citizens, would instantly indicate that your trojan was tied to the USG ("attribution"). It is far better OPSEC to collect all of the email and then minimize it to remove the US Citizen data after it has been taken. In the case of "data in transit" there may not be computational power at the endpoints to do filtering.</div>
<div><br></div><div>The paper also recommends a large reliance on intellectual rights management ("DRM") software to track information in the classified world. Keep in mind that DRM is, at best, a mirage when approached by a system administrator of any kind. This software would not have prevented Edward Snowden from doing what he did, or even have slowed him down very much. It is also a huge burden operationally, which is why it has essentially failed in the wider marketplace, despite massive financial incentives (c.f. "The music industry").</div>
<div><br></div><div>The document also recommends EINSTEIN 3 and other network security ("The Best Available") be placed throughout the IC. Upgrading the world's biggest network is of course, easy to do when you have infinite money and time. Ask any Fortune 500 CTO what it would take to handle a mandate to move off their legacy hardware and software platforms while maintaining operations - the cost is unimaginable. And EINSTEIN 3 is of course, already out of date. "The Best Available network security" is a fast moving target.</div>
<div><br></div><div>One of the recommendations, that the agencies move from a "need to know" model to a "work related access" model, is confusing, since these are essentially the same thing. Likewise, information is not split into clear quantums - at some point it is better to clear additional people rather than live under the illusion that they cannot put 2 and 2 together ("Hmm, we appear to have hacked into all those machines running IIS 7.5 - I wonder if there is a bug in IIS 7.5?") </div>
<div><br></div><div>In conclusion, while there are major changes espoused in the document on purely philosophical and legal level, there are also changes that run into technical and operational security areas which cannot be addressed without hamstringing our IC (f.e. recommendation 30 on 0days) or requiring immense amounts of additional capital. </div>
<div><br></div></div>