ABOUT DEVCENTRAL

DevCentral News Technical Forum Technical Articles Technical CrowdSRC Community Guidelines DevCentral EULA Get a Developer Lab License Become a DevCentral MVP

RESOURCES

Product Documentation White Papers Glossary Customer Stories Webinars Free Online Courses F5 Certification LearnF5 Training

SUPPORT

Manage Subscriptions Professional Services Professional Services Create a Service Request Software Downloads Support Portal

PARTNERS

Find a Reseller Partner Technology Alliances Become an F5 Partner Login to Partner Central

---

©2024 F5, Inc. All rights reserved.

A few years ago, a gentleman created a video showing how quickly an unpatched, unprotected Windows XP machine was infected once connected to the public Internet (the linked video is worth a watch, and is short). That video took the business community pretty much by storm, but was old news to security administrators and most systems administrators. Things have improved on the operating systems side of the house, but so have the systems, attackers, and environment for hackers, meaning things aren’t much better today.

In the confines of your enterprise, that’s all cool. Whether you are deploying a server or a desktop, you configure a machine, it follows the standards of the organization, and is protected by the organization’s security architecture.

When you deploy an application to the cloud, though, far too often the fact of how hostile the Internet is to unprotected servers is not properly appreciated. Sometimes because it isn’t IT deploying the application, sometimes because it is “just a pilot to evaluate cloud”, sometimes because the environment is so different that the Standard Operating Procedure (SOP) and policy documents are close to useless. No matter what the reason, the end result can be a nightmare just the same as if it happened in your datacenter.

The solution is, of course, to use the tools that virtualization offers, install and configure the VM and all applications internally, set up antivirus, lock down the operating system and the applications running in the VM, then either clone it and move the clone out to the cloud, or use VMotion to move it out to the cloud.

Any other alternative approach, due to the nature of the cloud, will leave you exposed for a variable amount of time. The problem here is that the IP has to be publicly routable for you to get to the instance, so there really isn’t a good way to install the OS out there and then lock it down. Once the OS is installed, you’re potentially in for a rough ride.

Some of you are going “Of course, this is common sense”. As usual, in some organizations it is indeed common sense. In others it absolutely is not, and often the nature of pilot programs makes “common sense” relative to “gaining knowledge”. So it is absolutely worth saying outright.

And yes, this is the very tip of the iceberg, your application must provide its own security services or have access to the role-based architecture deployed in the datacenter, but seriously, cloud security at the OS/Application layer is no different than public-facing applications in the datacenter. In the end, both are going to have public IP addresses that must be protected from those lurking in the shadows.

The next major sticking point is data connections back to the datacenter, but products like F5’s BIG-IP LTM can help in that department, offering tools like iSessions to provide secure, encrypted tunnels back to the datacenter. There are other products out there that can answer this same need, but recall that I’m an F5 employee. And recall that F5 is a market leader for a reason.

But you won’t even get there if your server instances are infected before they’re even patched. So remember, protect your server instances before you deploy them. In fact, if you’re going to do more than one or two servers to the cloud, it might just be worth your while to create a specialized image and insist that all cloud images be clones of that image – that way you can build all the protections in once and be done with it, much as you likely do with desktops and servers today. Better to start with the known-to-be-locked-down image and loosen from there than to recreate lock-down code every time you build a new server.

Safety first, it’s scary out there.

A few years ago, a gentleman created a video showing how quickly an unpatched, unprotected Windows XP machine was infected once connected to the public Internet (the linked video is worth a watch, and is short). That video took the business community pretty much by storm, but was old news to security administrators and most systems administrators. Things have improved on the operating systems side of the house, but so have the systems, attackers, and environment for hackers, meaning things aren’t much better today.

In the confines of your enterprise, that’s all cool. Whether you are deploying a server or a desktop, you configure a machine, it follows the standards of the organization, and is protected by the organization’s security architecture.

When you deploy an application to the cloud, though, far too often the fact of how hostile the Internet is to unprotected servers is not properly appreciated. Sometimes because it isn’t IT deploying the application, sometimes because it is “just a pilot to evaluate cloud”, sometimes because the environment is so different that the Standard Operating Procedure (SOP) and policy documents are close to useless. No matter what the reason, the end result can be a nightmare just the same as if it happened in your datacenter.

The solution is, of course, to use the tools that virtualization offers, install and configure the VM and all applications internally, set up antivirus, lock down the operating system and the applications running in the VM, then either clone it and move the clone out to the cloud, or use VMotion to move it out to the cloud.

Any other alternative approach, due to the nature of the cloud, will leave you exposed for a variable amount of time. The problem here is that the IP has to be publicly routable for you to get to the instance, so there really isn’t a good way to install the OS out there and then lock it down. Once the OS is installed, you’re potentially in for a rough ride.

Some of you are going “Of course, this is common sense”. As usual, in some organizations it is indeed common sense. In others it absolutely is not, and often the nature of pilot programs makes “common sense” relative to “gaining knowledge”. So it is absolutely worth saying outright.

And yes, this is the very tip of the iceberg, your application must provide its own security services or have access to the role-based architecture deployed in the datacenter, but seriously, cloud security at the OS/Application layer is no different than public-facing applications in the datacenter. In the end, both are going to have public IP addresses that must be protected from those lurking in the shadows.

The next major sticking point is data connections back to the datacenter, but products like F5’s BIG-IP LTM can help in that department, offering tools like iSessions to provide secure, encrypted tunnels back to the datacenter. There are other products out there that can answer this same need, but recall that I’m an F5 employee. And recall that F5 is a market leader for a reason.

But you won’t even get there if your server instances are infected before they’re even patched. So remember, protect your server instances before you deploy them. In fact, if you’re going to do more than one or two servers to the cloud, it might just be worth your while to create a specialized image and insist that all cloud images be clones of that image – that way you can build all the protections in once and be done with it, much as you likely do with desktops and servers today. Better to start with the known-to-be-locked-down image and loosen from there than to recreate lock-down code every time you build a new server.

Safety first, it’s scary out there.