Skip to content ↓ | Skip to navigation ↓

Digging through my cupboards recently, I came across my old collection of 3½ floppy disks. It’s been quite some time since I’ve had a need to plug in my trusty USB floppy drive, so upon making this great archaeology discovery, I was left simply to ponder about their content and whether I’d really intended to break the write protect notch to prevent writing to the disks.

A younger version of me no doubt would’ve thought this was the height of protecting my data – that and making sure I’d copied the data to at least two disks (the latter habit remains to this day and has often worked out to my benefit!). Arguably, these poor disks now represent an oddly extra hardened state of being – security through obscurity of access methods.

Fortunately, this method of securing media isn’t practical for the internet era. We may typically think about our cloud services high up-time only as a benefit, but availability is also a measurement of the time for which a misconfigured or unhardened system can be exposed. Thus, it’s even more important we take the time to apply hardening measures from the start.

The good news is that, along with increased stability, the standards that help us secure our systems are always improving. From PCI to CIS controls, and through various other standards, security hardening is a well-documented field, and ensuring that you are compliant against a hardening policy is a sensible first step when configuring both your traditional on-premise and cloud hosted solutions.

Take, for example, CIS.

CIS published (version 1.2.0) guidance around Amazon Web Services Foundations back in May of this year; these recommendations offer an excellent starting place for securing your Amazon Web Services. Broken down into two separate profiles (Level 1 and Level 2), they are structured in a sensible fashion that reflects real-world usage rather than abstract recommendations. Level 1’s requirements are intended to be practical and prudent; provide a clear security benefit; and not inhibit the utility of the technology beyond acceptable means.

Level 2 builds on the Level 1 profile and focuses on hardening AWS further, which makes it ideal for situations where security is key. (Although you may have to concede some of the functionality offered up by AWS in exchange for tighter security controls.)

The CIS guidelines are further broken down by recommendation categories, covering areas like Identity and Access Management, Logging, Monitoring and Networking. If all these sections sound familiar to you, that’s because they’re very similar to the sections of traditional server architecture based CIS domains that apply to your more traditional on-site Windows and Linux servers.

When I’m working with clients to assess their infrastructure for hardening, they are often surprised by how lowly a “default, out-of-the-box” server will score when marked against CIS compliance policies, and the same is true of many of the cloud provider’s solutions. Security unfortunately often takes a backseat for default configurations to provide a faster on-ramp for deploying to the cloud. But that’s where the cloud CIS guidelines become your best ally by offering a solid to-do list for taking your infrastructure from “default” to “hardened.”

Taking the categories from the CIS policy set, it’s possible to create a practical set of actionable configuration changes that can be quickly implemented. The guidance is detailed enough to provide the rationales behind making a specific hardening step along with the method of remediation to bring yourself in line with the policy. Perhaps just as important as the remediation process information, though, is the audit process described, which reveals how you can check whether the changes you’ve made have achieved their objectives.

Manually carrying out this process can be arduous, but plenty of tools (like Tripwire Enterprise’s Cloud Management Assessor) can automate the assessment process and identify where the gaps might creep into your configuration. Having an automated method can also bring another important benefit to your compliance strategy – reporting. By tracking your hardening process, you can easily feed back to both your security team to track their individual progress on specific objectives as well as to the rest of the business to show improvements over time.

In the real world, I find that security teams given practical agendas and trackable goals are generally more successful at selling their security vision and can very quickly achieve security improvements. And once you’ve achieved Level 1, pushing for further hardening on particularly sensitive devices no longer seems unachievable.

Compliance often sounds like an onerous task set upon us, but I feel that the better way to look at it is an opportunity to provide a measurable way to improve on your security practices.

My floppy disk may well be securely locked away, but your cloud infrastructure doesn’t benefit from security by obsolescence, so maybe it’s wise to make sure your online servers achieve security through compliance instead.