Occasionally, I reflect on my earlier years in the broad world of IT and cyber security. I was a teenager fresh out of high school and anxious to get that first corporate job. I landed a break as a contractor and was immediately thrown to the wolves. It was sink or swim, as cyber terrorism concerns were at an all time high. My employer shelled out millions in an effort to feel protected, leveraging everything from Cisco PIX firewalls, to Catalyst routers and even intrusion detection/prevention systems. Heck, they even deployed honeypots, host-based firewalls, virtual private networks and VRF’s just to try and thwart those would be wrong-doers. Sure, these types of devices are still in use today, and companies such as Cisco, Juniper and Barracuda continue to thrive with hardware appliances that you deploy into corporate networks, but software defined infrastructure (SDI) has changed how we as consumers interact with them. Thinking back on how much technology I had to quickly ramp up onseems daunting today. It did, however, lay the groundwork and foundation for future opportunities. I really was fortunate to get exposure to such expensive and cutting edge technology and to have such great mentors, who accelerated my growth. One question sticks in my head though: With the consumerization of cloud and turnkey solutions available, do the majority of the players leveraging cloud technology actually understand how security works in the Cloud? Do they even take time to ensure they are employing best practices when deploying their workloads into production? Okay, so maybe I’m sounding like an old man with just another “back in my day” cliche, but it does seem that IT and security professionals as a whole had a better understanding of security best practices prior to the surge in popularity of running production workloads in the cloud. So how is security managed in the cloud world where access to compute power, storage, databases and more have seen turnkey solutions whichhave consumerized the market? Well, behind the scenes these big cloud providers are still employing the proven technology of old, but with a few twists. Let’s take a look at some of the major players who are using the aforementioned technology under the hood, but are simultaneously simplifying the management for end-users. Azure: Until Q4 of 2014 Microsoft Azure was a bit behind in terms of security options. They only had a single option available to secure their compute instances, instance endpoints. These endpoints are effectively a host based firewall that requires administrators to configure security policy on a host-by-host basis. They are very similar to host-based firewalls, and the management of them does not scale. Having managed over 1,500 servers running IPtables, I can attest that it’s not a fun experience, even if you employ programmatic means to try and automate the management. But, at last in 2014, Microsoft introduced Network Security Groups (NSG’s). These areeffectively glorified access lists which are applied a layer above instances and operate at the network subnet level. The nice thing about these is you can configure your security policy in one location and then associate that with multiple network subnets. Going with NSGs as your primary means of securing Azure resources certainly scales better, but it has its drawbacks as well. First, a network subnet can only have one network security group associated with it. This can result in bulky access lists that will be difficult to audit. More importantly is the lack of Azure portal support for network security groups. Even though they have been around for over a year, Microsoft still forces administration of them via the programmatic API or via . This can be a hindrance and likely is why this feature has not been widely adopted by Azure customers. Google Compute Engine: uses firewalls to protect cloud resources. They operate at the network level. Out of the box- they give you a solid levelof security and assurance that your instances are protected. They support source and target tags which simplify the management of firewall rules when scaling, removing the need to reuse the same source IP ranges over and over again. A drawback of Google’s firewall service is that only inbound traffic can be filtered. This means that organizations with heightened security and compliance standards will need to employ a host-based firewall solution, such as IPtables, to restrict traffic between instances within Google’s cloud. This can be cumbersome for larger footprints and hopefully is something that Google will likely bolster in the coming year. Amazon Web Services: has a few different ways to protect cloud resources: Security Groups, Network Access Lists and VPC flow logs. The former comes in two flavors, EC2 classic and Virtual Private Cloud (VPC). Security groups are similar to Instance Endpoints in that they are applied at the instance level; however, they have one advantage inthat they can be applied to multiple instances. In fact, instances can have up to five security groups associated with each network interface (VPC instances support up to four network interfaces). VPC security groups go a step further in that they can be associated and disassociated on the fly with instances. With EC2 classic instances the security groups you associate at launch are bound to the instance for the entire lifecycle. Network Access Lists (NACL’s), as you would imagine, operate at the network subnet level. Similar to Microsoft Network Security groups only one NACL can be associated with a subnet. End-users can associate custom metadata using the tag system for improved organization. Lastly, VPC Flow Logs enable administrators to audit and inspect traffic as it communicates between VPC resources. This type of promiscuous network sniffing can be vital when trying to identify compromised resources, DDoS attacks and more. A drawback of each of these items is that you cannotassociate descriptions or metadata on the rules themselves. This can make things cumbersome for larger organizations with thousands of rules spread across a number of regions and AWS accounts. Can you imagine having to audit 10,000 rules without descriptions as to what each of the networks are? More information can be found on AWS security options . Rackspace: After years of clamoring from their customers, finally added security group support to their public cloud offering. These security groups operate in a similar fashion to AWS security groups; however, only ingress traffic can be filtered. While this is a step in the right direction, it should be noted that only customers paying for the premium Rackspace’s Managed Service offering are eligible to leverage them. This is unfortunate as the other public clouds offer security solutions free of charge to their customers. If you don’t pay for premium you’re left to managed security using host-based firewalls that your IT team has tomanage. Conclusion: Behind the scenes when you work with any of these resources you are making similar changes to what I had to do back in the late 1990’s and early 2000’s, but without the headache. Cloud providers have delivered turnkey security offerings without the mess and potential for disaster due to human error. No longer do you have to concern yourself with bringing down an entire corporate network due to a typo in your core router’s access list. There is no denying that setting up a fairly comprehensive security policy in today’s Cloud is much easier and approachable for the admins, yet you would be shocked how many servers are left wide open for malicious users to set up a “hacker hotel.” Despite the simplicity and numerous best practice articles that exist, consumers of cloud services continue to simply click the provision button and forget to make sure they are secure. I’ll be following up this article with a more technical write-up which will include examples of how tocreate and interact with these security resources and to employ best practices on securing your resources in today’s cloud.
Share