Skip to main content

NSA Tapping and Cloud Computing


th (4)Recent revelations from the U.S. have informed the public that conspiracy theorist fantasy's are all too real, the U.S. National Security Agency (NSA) has been installing taps at key Internet points to absorb vast quantities of email and Internet traffic.

As IT professionals, publically available information (no inside information or secret information is utilized in the preparation of this article) and an understanding of the Internet as a series of routers and servers, we understand that “taping key Internet points” means copying streams of Internet traffic via router configurations and having monitoring software installed on email servers and the like (directing copies to the government monitoring servers).

The NSA isn’t secretly tapping into some sort of vast Internet cable bundles.  Rather they’re walking into AT&T, Google, Yahoo, Microsoft, Internet backbone and primary service providers, and installing software on their routers and servers as well as installing NSA receiving servers on their networks and premises. 

A few months ago ZapThink published an article questioning why the move into Cloud Computing via Public Cloud Vendors has been relatively slow…

Cloud Computing: Rethinking Control of IT : Jason Bloomberg, April 24, 2013

In my role as a globetrotting Cloud consultant, I continue to be amazed at how many executives, both in IT and in the lines of business, still favor Private Clouds over Public. These managers are perfectly happy to pour money into newfangled data centers (sorry, “Private Clouds”), even though Amazon Web Services (AWS) and its brethren are reinventing the entire world of IT.

Their reason? Sometimes they believe Private Clouds will save them money over the Public Cloud option. No such luck: Private Clouds are dreadfully expensive to build, staff, and manage, while Public Cloud services continue to fall in price. Others point to security as the problem. No again. OK, maybe Private Clouds will give us sufficient elasticity? Probably not. Go through all the arguments, however, and they’re still dead set on building that Private Cloud. What gives?

The true reason for this stubbornness, of course, is the battle over control…

Why do (IT) executives crave control so badly? Two reasons: risk mitigation and differentiation. If that piece of technology is outside your control, then perhaps bad things will happen: security breaches, regulatory compliance violations, or performance issues, to name the scariest.

(The article continues why this isn’t really true and mitigated through SLA agreements and gives you the advantage of separating the responsibility and control.)

ZapThink misses the major point in my mind. 

There’s been a variety of Cloud Computing articles superficially discussing potential legal complications of a corporation having some of their business data in a different legal or national jurisdictions from their business.  And we’ve seen some practical challenges of major US service providers being hit with EU privacy standards violations (for example).  What, for example, would happen if a customer sued the Cloud Vendor for “deletion rights” (an EU data right) for a EU customer who had signed up with a US Internet service provider that happened to use an EU based Cloud Resource Vendor for their storage?  IT executives naturally shudder at the business / legal complexity of data crossing state / national / international borders.

With the NSA monitoring revelations, we see much worse concerns.

In the case above, I could end up in a lawsuit outside my jurisdiction.  If I’m a small company, this could be catastrophic (if I’m a large corporation, only ridiculously expensive).  But at least all I have is a legal risk.  As long as the Cloud Resource or Platform Vendor is living up to their contractual responsibilities and technical features, my data and computing results remain private and controlled – though now I have the additional party of the Cloud Vendor in the mix.

With NSA monitoring, the Cloud Vendor may be forced (or coerced or tempted with financial payments) to provide monitoring access without being permitted to notify me (fully legal).  My company would thereby have no legal recourse to attempt to protect our data because we wouldn’t even know such monitoring is occurring.  (In instances of the monitoring revelations, it’s also become clear that the NSA is doing so with “secret court” orders which prevent the service providers / vendors from letting anyone know such monitoring is being requested or occurring.)

Suddenly the controlling or paranoid IT executive is looking smart. 

We now have established the fact that if your data leaves your premises, it may be secretly tapped / copied / monitored, and you’ll likely never know (thereby offering no legal recourse to challenge it).  And while we certainly want our national security resources to be able to do their jobs and provide national safety, we also know that such authority is subject to misuse – and misuse of key company data could cost millions or even billions, or put a company out of business.

When police or investigative authorities arrive with a court order, we may legally challenge it as well as trying to keep the access as narrow as possible.  Even further, it may be our IT people providing the data (so we know exactly what’s leaving and what the potential business impact is).  If the NSA is monitoring or accessing Cloud Vendors, our data is leaving without any control or even knowledge on our part.  Our business risk is potentially unlimited.

The advantages of the Cloud now carry a real risk.

For personal use, cloud services now carry the same risk.  If you’re tying your Android phone to Google account sync or your iPhone to the iCloud, your contacts are now (probably) being monitored.  How about if you’re using a Cloud backup service or online file storage (Googe Drive, Microsoft SkyDrive, etc)?  We don’t know, but with recent revelations, we’d be foolish to assume the data is being kept private from national security authorities – which included revelations that NSA employees used the service to spy on personal love interests.

If it leaves your premises and it’s not encrypted and kept encrypted at the destination, it’s only appropriate nowadays to assume it’s being monitored.  And if it is encrypted, you may warrant special attention.

Welcome to the digital age.  Your government is now online.

Popular posts from this blog

Integration Spaghetti™

  I’ve been using the term Integration Spaghetti™ for the past 9 years or so to describe what happens as systems connectivity increases and increases to the point of … unmanageability, indeterminate impact, or just generally a big mess.  A standard line of mine is “moving from spaghetti code to spaghetti connections is not an improvement”. (A standard “point to point connection mess” slide, by enterprise architect Jerry Foster from 2001.) In the past few days I’ve been meeting with a series of IT managers at a large customer and have come up with a revised definition for Integration Spaghetti™ : Integration Spaghetti™ is when the connectivity to/from an application is so complex that everyone is afraid of touching it.  An application with such spaghetti becomes nearly impossible to replace.  Estimates of change impact to the application are frequently wrong by orders of magnitude.  Interruption in the integration functioning are always a major disaster – both in terms of th

Solving Integration Chaos - Past Approaches

A U.S. Fortune 50's systems interconnect map for 1 division, "core systems only". Integration patterns began changing 15 years ago. Several early attempts were made to solve the increasing problem of the widening need for integration… Enterprise Java Beans (J2EE / EJB's) attempted to make independent callable codelets. Coupling was too tight, the technology too platform specific. Remote Method Invocation (Java / RMI) attempted to make anything independently callable, but again was too platform specific and a very tightly coupled protocol. Similarly on the Microsoft side, DCOM & COM+ attempted to make anything independently and remotely callable. However, as with RMI the approach was extremely platform and vendor specific, and very tightly coupled. MQ created a reliable independent messaging paradigm, but the cost and complexity of operation made it prohibitive for most projects and all but the largest of Enterprise IT shops which could devote a focused technology

From Spaghetti Code to Spaghetti Connections

Twenty five years ago my boss handed me the primary billing program and described a series of new features needed. The program was about 4 years old and had been worked on by 5 different programmers. It had an original design model, but between all the modifications, bug fixes, patches and quick new features thrown in, the original design pattern was impossible to discern. Any pattern was impossible to discern. It had become, to quote what’s titled the most common architecture pattern of today, ‘a big ball of mud’. After studying the program for several days, I informed my boss the program was untouchable. The effort to make anything more than a minor adjustment carried such a risk, as the impact could only be guessed at, that it was easier and less risky to rewrite it from scratch. If they had considered the future impact, they never would have let a key program degenerate that way. They would have invested the extra effort to maintain it’s design, document it property, and consider