Welcome

Dan GriffinWelcome to the fourth edition of the JW Secure Informer, our bi-monthly newsletter. This is an opportunity to share what’s on our radar, specifically with respect to enterprise network security, but also regarding IT and business more generally.

The Informer is intended to be useful content and good for a quick read. So if it’s just clutter in your inbox, we’ve failed, and I hope you’ll let us know.
 

Cloud Application Platforms

I’m going to start this issue by highlighting two different types of virtualization, specifically as they pertain to cloud computing.

The first, infrastructure virtualization, is what Amazon offers with its Elastic Compute Cloud (known as EC2; for a more detailed introduction, click here). The key point is that, at first blush, infrastructure virtualization feels like an easy transition from onsite servers to cloud computing, because it gives you the ability to remotely manage your own servers in cloud in much the same way that you manage them in an onsite datacenter (for example, via RDP or SSH).

However, like any technology transition, infrastructure virtualization places a burden on IT staff to develop new tooling and management scripts. That’s because the underlying virtual fabric is different from what was being used before (for example, ESX or bare metal).

The second type of virtualization I want to highlight is application runtime virtualization. This is the model used by Windows Azure and Google App Engine. This approach places a different kind of burden on the IT staff because it’s difficult to control, regulate, and monitor. There are two challenges, both of which I’ll return to in the next two sections:

  • Line of business (LOB) developers can deploy apps directly to the cloud without going through IT approval processes.
  • Virtualized storage provided in the cloud may not comply with IT controls such as data loss prevention, access and auditing policies, encryption, and sovereignty (I wrote about the latter in the previous issue of the Informer).

Despite the challenges, it’s important to note that application virtualization in the cloud is a boon for developers and software start-ups for many of the same reasons that it’s painful to IT. From a cost perspective, cloud computing is proving to be irresistible to larger businesses because it facilitates the current trend of transforming capital expenses, such as in-house servers, into operational expenses, such as a monthly cloud services bill.

Plus, once developers have been trained on the new cloud computing environment, the result may be an overall reduction in the cost of LOB app deployment and lifecycle management. And let’s not forget the inherent scalability benefits of cloud computing.

The major tech vendors recognize this, of course, and are doing everything they can to entice LOB developers to use their cloud platforms. Tight integration with the developer tool chain is the key.

Cloud Strategy: Developer Tool Chain Integration

VMware announced on August 31 its competitive answer to Windows Azure: vFabric. The most notable quality of vFabric is its tight integration with the Java-based SpringSource Tool Suite, which includes a reputable runtime library and also offers tight integration with the Eclipse integrated development environment (IDE).

This is the same approach that Microsoft is using: deploying applications directly from the developer’s desktop to the cloud is becoming easier with each new version of its Visual Studio IDE and the Azure integration tools.

Why does IDE integration matter? Because building a cloud computing platform is enormously expensive, and the only way companies like Microsoft and VMware/EMC stand a chance of making back their investment is to make it brain-dead simple for every developer in the world to run his or her app in the cloud. That means lowest common denominator: write a Visual Basic app, click a button, it’s running in the cloud and you’re done – next project. No setup, no confusing configuration, no keys, etc.

Problem: the focus on this one-click-deployment strategy is convenient, but it leaves some unanswered questions in the security department.

More on Cloud Security

Cloud security faces two challenges. The first is data sovereignty, which basically boils down to this: if I’m an American company, then data stored on my servers is subject to American data sovereignty laws (same concepts apply worldwide, of course). Those laws determine, for example, who is able to demand access to that data, when, and why. If you’re a foreign government, or a company that does business with one, you’re unlikely to want to store your data on my cloud service, because my government can basically seize it whenever it wants. That puts a dent in my prospective customer base.

The second security challenge is data encryption. An informative reference on the subject is this TechNet article, which mentions the threat of data compromise from within the cloud. To mitigate that threat, the article suggests creating and storing keys in the cloud. However, that’s not going to work if someone from within the cloud compromises your keys, or compromises whatever secret protects those keys. The only solution is to store the secret outside of the cloud and never transmit it to the cloud. That greatly limits the scalability benefit of the cloud – which is supposed to be one of its main selling points – unless all you’re looking for is pure storage space.

Let’s be realistic, though – applications are being migrated to the cloud. To that end, a good blog post on Azure Security is here – it links to a lengthy paper on Azure security. The paper offers some useful threat modeling checklists in the References section at the end. For example, see the section entitled Cheat Sheet – Web Application Security Threats and Countermeasures at a Glance starting on page 86. I couldn’t find a similar reference for vFabric, but all of the points raised by the Azure paper are applicable.

Want to read more about the cloud? See also this post on cloud dev resourcing, plus my upcoming TechNet article on local and cloud resource coexistence.