Cloud Server Hardening Is So Different Than What You’re Used To

Taking Fortune 500 clients through a Hardening Risk Analysis is very revealing.  It reveals that most Hardening RuleSets, Disciplines, and Policies are steeped in DataCenter thinking.  And although strategies for security in the DataCenter and in the Public Cloud are very similar, the tactical solutions can be quite different.

Risk Assessments are a difficult thing to do, you have to take each Cloud Server and understand its benefits, its vulnerabilities and balance the Operational and Security needs.  

Moving to the Cloud delivers tremendous efficiencies in speed and cost, because whole layers of the datacenter model have simply been removed on the cloud.  As we walk the OSI Layer model, we realize that responsibilities involving all the physical layers of the stack have changed forever.

In the DataCenter, we start with an empty room, we secure the physical room, we add racks and stacks to support server hardware, networking connectivity, access control to the right personnel, protect against fire and theft, and much more.   A datacenter is a living breathing environment, it provides for dramatic change. Systems are added, subtracted, Projects are developed, cancelled, upgraded and maintained. Servers are debugged, tuned for speed, redundant for availability.

As a result, security disciplines evolved around every one of these functions.  Teams and staff to oversee and standardize the manner in which these activities are performed.  Expertise in analyzing risks, attack surfaces, inventory, access, vulnerability assessments all evolve to meet the complexity of a datacenter.

Imagine roughly half of all the complexity is simply eliminated through technology.

Cloud computing represents the convergence of virtualization, cluster computing, and computing as a utility.  As a result, some aspects or complexities were eliminated entirely. Some responsibilities were aggregated and shifted to the public cloud companies.  Amazon, Google and Microsoft run agnostic datacenters where they are relieved of competing interests and use scale to mitigate all physical datacenter concerns.  Risks having to do with physical geography, hardware, or facilities, simply disappear from risk responsibility.

Unfortunately, this reduction or shifting of responsibility finds its way into security policy and hardening strategy.  It isn’t wrong to assess these items, they are risks to servers, but the responsibility has shifted as well.

Our first example of Cloud Server differences is easy to see.

In datacenter servers, there are physical security risks and vulnerabilities we’re all familiar with.  Floppy drives, USB ports and Optical Media drives could all be used to achieve a foothold on a server. Floppy drives, historically accessed first could allow foriegn code to be executed.  USB ports could access this code on startup too. Optical drives usually deliver software to the server, these need to be locked down too.  

All valid concerns, we also need to lockdown the bootloader, possibly grub2 for example, so no bad actor can hijack a server by physically accessing it.  

On the public cloud, Cloud Servers don’t have floppy bootable drives, usb ports, or optical drives, and nobody has access to the Cloud Server anyway.  The agnostic cloud provider takes great effort to not only keep these aspects secure, but to remain agnostic to these servers functions and contents.   

So, taking time to audit floppy drives, usb ports or optical drives is fundamentally different on the Cloud Server.  The hardware components are fundamentally missing, so scans or hardening efforts may yield a strange report.

Our next example of Cloud Server differences involves Hard Drives.

Like every computer we deal with, they all have storage devices for long term, resilient data.  We may call them a Hard Drive with a spinning platter, they may be memory chips that simulate a spinning magnetic platter of a Hard Drive.  In virtualization, often they are abstracted as a large file or file object. These file objects may be spread over a storage service, for resilience, speed or utility.

Hardening rules in datacenters have lots of standards for partitions and filesystems.  These involve the manner and structure of how the data is stored on the spinning platter of a hard drive.  Partitions and filesystems use measures of sectors and blocks leftover from spinning platters, even when you have memory chips or some other simulation or abstraction.

If you have a datacenter server, there are reasons to separate various portions of the operating system into partitions, so a physical attack on a removed harddrive can be thwarted.  Older filesystem storage strategies might let attackers in, so they need to be hardened away from use.

On Cloud Servers, the concept of a Hard Drive is completely abstracted, you don’t have one.  Instead you have something that simulates a Hard Drive, minus the physical vulnerabilities of Hard Drives.  Amazon’s EBS is a fault-tolerant storage-area network service, that fully simulates a Hard Drives, but has totally different and less attack vulnerabilities.  These responsibilities are also shifted to Cloud Providers.

The Cloud offers another sea-change paradigm in Hardening.  The wave of DevOps thinking has moved us from hand-crafted, hand-configured Datacenter Servers, to hard-crafted, hand-configured automation of Cloud Servers.  These servers have fewer users, and commonly zero non-privileged users. The Cloud Servers are often intended to be immutable, and simply replaced when an upgrade is needed.  This disposability of servers, comes from the ease of replacement.

Configuration Management as a discipline involves the recipes, playbooks or golden images constructed as the foundation of every Cloud Server.  Configuration Management often provides the configuration of your applications, your services.  

Another innovation in Cloud Servers that affects Hardening is Universal Firewalls.  AWS called this technology IAM and/or Security Groups, and it provides the long sought-after firewall that works the same protecting Cloud Servers, as the surrounding Cloud Networking, as the native Cloud Services.  You no longer have to learn the unique commands to secure different OS’s, different network switches. Settings onboard the Operating System may not even be hardened in your strategy, iptables, ufw, firewalld tools become redundant against these universal firewalls.  Some Hardening policies double up, using onboard firewalls plus cloud-driven universal firewall envelopes around the server, some turn off the onboard firewall altogether.  

Environmental awareness, follows these universal firewalls.  Your universal firewall becomes fully aware of your network design, cloud estate design, even your application properties, allowing you much more functionality when hardening your whole solution.

HardPrime understands these differences in Hardening, and helps you span the varying needs.  We understand, that although these exceptions no longer need to be hardened, they do need to be documented in your process.  HardPrime allow you to mark issues as N/A CLOUD when Rules are non applicable to Cloud Servers, or to mark issues as MANUALly hardened, meaning that hardening needs to be deliberate because of custom configuration needs.  HardPrime Scans, Hardens, Verifies, and Documents, highlighting both N/A CLOUD and MANUAL selections in the process, reminding and highlighting attention to these special exceptions.

HardPrime makes it easy to satisfy the traditional needs of Security Policies in the DataCenter, through Auditing, while explaining Compliance on Cloud Servers in this new context.

Find out how HardPrime can make building a Hardening Policy easier to iterate through with research, selection and documentation rich details.  Try HardPrime anytime, with our 30 day free trial using your Cloud Marketplace on AWS, and soon Azure and GoogleCP.