Bamford’s latest update on the NSA

James Bamford is well known for his revealing of the National Security Agency in The Puzzle Palace, published in 1983.  He has written two updates since then, Body of Secrets and The Shadow Factory, the latest one covering the Bush Administration in some detail.  Bamford’s technical details in The Shadow Factory are nowhere near as good as they were in The Puzzle Palace, which is something that really attracted me to his writing.  Also, in this book, Bamford seems to play both sides of the fence, at one point arguing that the attacks on 9/11 were an intelligence failure, while at the same time arguing that we must safeguard our civil liberties.  This works, mostly because he successfully argues (in my opinion) that the government had all the power it needed to stop the attacks, but that incompetence ruled the day.

To be sure there are a few points I would take issue with.  For one, although I despise the name, it was probably a good idea to roll together many agencies into the Department of Homeland Security.  But quite frankly even that was done ineptly, as we have seen from auditor reports, again and again.

Returning to the Shadow Factory, in this update Bamford highlights the role of the Internet and the change in the nature of communications, where many communications have moved from sattelite to fiber, and from simple voice circuits to voice over IP.  He talks about certain organizations wanting to hire Cisco employees simply to reverse engineer IOS and find ways to install back doors.  I have no way of knowing if that has happened.

Bamford retreads much of the story about the illegal spying the NSA did within the United States, and how James Comey would not recertify the program.  While it makes my blood boil to think that anyone in government would think that such a program was legal (certified by the attorney general or not), that part of the story isn’t so much about the NSA as it is about Dick Cheney and David Attington.  Quite frankly I think Bob Woordward has covered that ground as well as could be covered.

Were I to give advice to Mr. Bamford it would be simply this: it is difficult to read just one of the three books he’s written, as either the earliest is woefully out of date, or the latest doesn’t stand on its own without having read the earliest.  A consolidated update that combines all three seems in order.

How Much Do You Value Privacy?

People in my company travel a lot, and they like to have their itineraries easily accessible.  My wife wants to know when and where I will be, and that’s not at all unreasonable.  So, how best to process and share that information?  There are now several services that attempt to help you manage it.  One of those services, TripIt.Com, will take an email message as input, organize your itinerary, generate appropriate calendar events, and share that information with those you authorize.

The service is based in the U.S., and might actually share information with those you do not authorize, to market something to you- or worse.  If the information is stolen, as was the case with travel information from a hotel we discussed recently, it can be resold to burglars who know when you’re way.  That can be particularly nasty if in fact only you are away, and the rest of your family is not.

But before we panic and refuse to let any of this information out, one should ask just how secure that information is.  As it happens, travel itineraries are some of the least secure pieces of information you can possibly have.  All a thief really needs is an old ticket stub that has one’s frequent flyer number, and we’re off to the races.  In one case, it was shown that with this information a thief could even book a ticket for someone else.

So how, then, do we evaluate the risk of using a service like TripIt? First of all, TripIt does not use any form of encryption or certificate trust chain to verify their identity.  That means that all of your itinerary details go over the network in the clear.  But as it turns out, you’ve probably already transmitted all of your details in the clear to them by sending the itinerary in email.  Having had a quick look at their mail servers, they do not in fact verify their server identities through the use of STARTTLS, not that you as a user can easily determine this in advance.

Some people might have stopped now, but others have more tolerance for risk.

Perhaps a bigger problem with TripIt is that neither its password change page nor its login page make use of SSL.  That means that when enter your your password, the text of that password goes over the network in the clear, for all to see.  It also means that you cannot be sure that the server on the other end is actually that of TripIt.  To me this is a remarkable oversight.

For all of these concerns, you still get the ability to generate an iCal calendar subscription as well as the ability to share all of this information with friends and family.  Is it worth it?  One answer is that it depends on whether you actually want to enter the information yourself, whether you care about security concerns, and whether you like using calendaring clients.  It also depends on what other services are available.

Another service that is available is Dopplr.  It also attempts to be a social networking site, not unlike Linked In.  Dopplr allows you to share you itineraries with other people, tells you about their upcoming trips (if they’re sharing with you), and it lets you create an iCal subscription.

Dopplr also has some security problems, in that they do not use SSL to protect your password.  They also do not use SSL for their main pages.  They do, however, support OpenId, an attempt to do away with site passwords entirely.  I’ll say more about OpenId in the future, but for now I’ll state simply that just because something is new does not make it better.  It may be better or worse.

And so there you have it.  Two services, both with very similar offerings, and both with almost the same privacy risks.  One of them, by the way, could distinguish themselves by improving their privacy offering.  That would certainly win more of my business.

The Do Nothing Presidency

Smoke Stack

Yesterday, the Bush Administration released a long awaited report by the Environmental Protection Agency, that says that Carbon Dioxide can and should be regulated.  One would think this a remarkable departure for an administration that has done everything within its power to destroy the environment, through drilling in fragile environmental areas, unmitigated logging, and the failure to protect endangered species.  There’s a catch: the Supreme Court ordered the EPA to develop the report, and in releasing it, in the same breath, the administration argued that regulation by the EPA to protect our children will hurt business and industrial growth.

Let’s review our tally for this administration:

  • Housing —  Failure to properly regulate the housing market has led to a massive series of bank failures.
  • The Energy Market — we are suffering from inflation due to a massive increase in oil prices, which itself is in part due to an inability of Americans to conserve.   The administration has done absolutely nothing to reduce consumption, or for that matter offer fuel alternatives.  Instead, they’ve argued that drilling in wilderness refuges will offer some form of relief, a claim that is disputed by every expert in the field, because it will offer no short term relief, while medium and long term relief are by no means at all assured.
  • Security— having gone to war twice and wasted billions of dollars on meaningless programs, the administration has managed to alienate America from the rest of the world, reducing people’s desires to visit, impacting tourism, and reducing our national credibility.  At the same time the Taliban has rebuilt itself, and we’ve lost our allies in Pakistan and now, seemingly Iraq (not that Prime Minister Maliki was every clearly an ally).
  • Education— No Child Left Behind has meant that our children haven’t gone forward as a group.  Our public education system remains in a shambles due to lack of incentives for good teachers, buildings that are falling apart, and a general willingness by this administration to divert funds to religious programs.
  • Public Transportation— our skies are more dangerous than they have been since the creation of the FAA.  More runway incursions, more close calls in the air, disgruntled workforces, and disgruntled passengers have left our air transportation system in a mess, while we’ve invested nearly nothing in ground public transport.
  • Public Welfare— with a remarkably lame response to Hurricane Katrina, the administration demonstrated that they could not be trusted with emergency crisis management.

In short, they did nothing except collect pay checks.  Perhaps Americans will pay more attention to our civic responsibilities the next time we hand someone the keys.

For the Umpteenth Time, IPv6 doesn’t do much for Security

If you read the wrong books or the wrong articles, some will claim that IPv6 has improved security over IPv4.  While this may be true in an extremely limited sense, for practical purposes there is no difference.  The only way in which IPv6 is really more secure that IPv4 is that one cannot easily port scan a subnet.  In some other ways, IPv4 might be more secure than certain implementations of IPv6, where the EUI-64 address is used as the lower 64 bits of the IP address, and thus enabling violation of privacy (e.g., tracking).  The most absurd statement I just recently read was that NAT causes Spam.  Where do these people get this stuff???

Let’s Get Simple

A picture of a mess of wiresIn the summer of 2004 I gave an invited talk at the USENIX Technical Symposium entitled “How Do I Manage All Of This?”  It was a plea to the academics that they ease off of new features and figure out how to manage old ones.  Just about anything can be managed if you spend enough time.  But if you have enough of those things you won’t have enough time.  It’s a simple care and feeding argument.  When you have enough pets you need to be efficient about both.  Computers, applications, and people all require care and feeding.  The more care and feeding, the more chance for a mistake.  And that mistake can be costly.  According to one Yankee Group study in 2003, between thirty and fifty percent of all outages are due to configuration errors.  When asked by a reporter what I believed the answer was to dealing with complexity in the network, I replyed simply, “Don’t introduce complexity in the first place.”

It’s always fun to play with new toys.  New toys sometimes require new network features.  And sometimes those features are worth it.  For instance, the ability to consolidate voice over data has brought a reduction in the amount of required physical infrastructure.  The introduction of wireless has meant an even more drastic reduction.  In those two cases, additional configuration complexity was likely warranted.  In particular you’d want to have some limited amount of quality-of-service capability in your network.

Franciscan friar William of Ockham first articulated a principle in the 14th century that all other things being equal, the simplest solution is the best.  We balance that principle with a quote from Einstein who said, “Everything should be made as simple as possible, but not simpler.”  Over the next year I will attempt to highlight examples of where we have violated both of these statements, because they become visible in the public press.

Until then, ask yourself this: what functionality is running on your computer right now that you neither need nor want?  That very same functionality is a potential vulnerability.   And what tools reduce complexity?  For instance, here is some netstat output:

% netstat -an|more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:2544          0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.1:817           0.0.0.0:*               LISTEN
udp        0      0 0.0.0.0:32768           0.0.0.0:*
udp        0      0 127.0.0.1:53            0.0.0.0:*
udp        0      0 0.0.0.0:69              0.0.0.0:*
udp        0      0 0.0.0.0:111             0.0.0.0:*
udp        0      0 0.0.0.0:631             0.0.0.0:*
udp        0      0 127.0.0.1:123           0.0.0.0:*
udp        0      0 0.0.0.0:123             0.0.0.0:*
udp        0      0 :::32769                :::*
udp        0      0 fe80::219:dbff:fe31:123 :::*
udp        0      0 ::1:123                 :::*
udp        0      0 :::123                  :::*

It’s difficult for an expert all of this stuff.  Heaven help all of us who aren’t experts.  So what do we do?  We end up running more programs to identify what we were running.  In other words?  That’s right.  Additional complexity.  What would have happened if we simply had the name of the program output with that line?  This is what lsof does, and why it is an example of reducing complexity through innovation.  Here’s a sample:

COMMAND     PID    USER   FD   TYPE DEVICE SIZE NODE NAME
xinetd     3837    root    5u  IPv4  10622       TCP *:pop3 (LISTEN)
xinetd     3837    root    8u  IPv4  10623       TCP *:pop3s (LISTEN)
xinetd     3837    root    9u  IPv4  10624       UDP *:tftp
named      3943   named   20u  IPv4  10695       UDP localhost:domain
named      3943   named   21u  IPv4  10696       TCP localhost:domain (LISTEN)
named      3943   named   24u  IPv4  10699       UDP *:filenet-tms
named      3943   named   25u  IPv6  10700       UDP *:filenet-rpc
named      3943   named   26u  IPv4  10701       TCP localhost:953 (LISTEN)
named      3943   named   27u  IPv6  10702       TCP localhost:953 (LISTEN)
ntpd       4026     ntp   16u  IPv4  10928       UDP *:ntp
ntpd       4026     ntp   17u  IPv6  10929       UDP *:ntp
ntpd       4026     ntp   18u  IPv6  10930       UDP localhost:ntp