[Dailydave] The NSA Task Force Document.

[Dave Aitel]

I wanted to cover some of the issues with the NSA Task Force document. I'll
begin abruptly here:

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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?")

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20131219/326a0aa2/attachment.html>