The Risk Profile of IaaS Cloud Proliferation
How layers of security can save the hybrid cloud.
Infrastructure as a Service (IaaS) cloud computing is transitioning from early adopters to widespread use for the first rounds of production applications at global-enterprise stalwarts.
The strategy being used is a mix of “hybrid” (connecting private and public cloud providers) and “multi-cloud” (interconnecting with more than one public cloud).
Basically what we are seeing is companies connecting their brick-and-mortar data centers (and the private cages at a shared facilities) to not just one, but to several public cloud providers.
Both hybrid cloud offerings and multi-cloud solutions require greater feats of organization to manage the risks. Enterprise IT pros must become experts in integration, interoperability, and security features of each platform and provider. With a single public cloud provider, security professionals could run through the provider’s pro-offered checklist, and SLA documents, to reach a reasonably good baseline-line assessment of risk & assurance. Multi-cloud solutions increase the complexity, and introduce the risk of ‘weakest-link’ exposures that are often less than obviously disclosed by the vendor.
Hybrid and Multi-Cloud Models Will Prevail
Hybrid and multi-cloud obviously involve more complex security and governance responsibilities. Why not simply mandate exclusive use of an in-house private cloud?
That’s been tried, and has proven to be a recipe for increased exposure, because the compelling economics simply drive business unit cloud projects farther underground. Hybrid / multi-cloud is not a bad thing; the more aware of the risks users are, and the more collaborative IT security is, the more proactive your IT security team can be in proactively managing those risk.
Before the advent of cloud IaaS, enterprise IT and distributed business unit tech teams were not offered flexibility or control, and the reaction, like the PC revolution, has been to go ‘off reservation.’ Even with a single IaaS provider; outage risk, vendor cost lock-in, geo-political diversity, and especially feature set shortcomings have driven the movement to hybrid / multi-cloud.
Hybrid / multi-cloud deployment strategies allow for an application running as a topology of virtual servers to migrate, or scale-out, not just within a single location, but between locations, vendors, and geo-political boundaries. I call this deployment strategy Cross Cloud computing. Right now in many large organizations, like yours, there are two Cross Cloud adoption forces at play. Many IT organization are working to leverage the the Cross Cloud model, and are offering more than simple virtualization re-branded as private cloud. While that effort moves along, business unit teams are expanding their independent initiatives, and growing last year’s skunk works projects into full scale production applications.
Integration across cloud offerings and cloud providers brings about greater flexibility for diverse business use cases, and will prevail as the infrastructure model going forward. As security professionals our goal should be to be proactive, educated, and prepared as this sea change progresses.
Roles and Responsibilities for Security
Your enterprise needs an elegant solution to prepare, migrate, and manage applications and networks as the use of Cross Cloud IaaS expands and grows. The key is application-layer control. Everyone from the executive suite on down is aware that security is the first concern with the cloud. But the deeper issue is really control. Who owns and provides the cloud edge, router, firewall or port filtering?
The needs and concerns of cloud service providers are distinctly different than the needs and concerns of the cloud service user. In Figure 2, the Cloud deployment model, you can see a dotted red line of demarcation illustrating a new dividing line of roles and responsibilities for security and control. Cloud and critically Cross Cloud IaaS inverts traditional thinking about the focus of risk management from the infra layers up the stack to the individual application server.
If you have not already done so, take a look at the contracts your organization (and business units) have already signed with cloud providers. A good starting point would be to search for “AWS Shared Responsibility Model,” and review the 60 page overview, which opens with the statement:
Moving IT infrastructure to AWS creates a shared responsibility model between the customer and AWS. This shared model can reduce your operational burden as AWS operates, manages, and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the services operate. In turn, you assume responsibility and management of the guest operating system (including updates and security patches), other associated application software, as well as the configuration of the AWS-provided security group firewall. You should carefully consider the services you choose as your responsibilities vary depending on the services you use, the integration of those services into your IT environment, and applicable laws and regulations. It is possible for you to enhance security and/or meet more stringent compliance requirements by leveraging technology such as host-based firewalls, host-based intrusion detection/prevention, and encryption.[Amazon Web Services: Overview of Security Processes November 2013]
Do your users understand that many aspects of security operations remain the customer’s responsibility, not the cloud provider’s? Notice the work possible in the last sentence? When business units in your organization subscribe to IaaS, they (and if anything goes wrong, you) are responsible for security above the hypervisor. Best practices call for you and your team to seek out cloud providers who explain and discuss this concept of shared responsibility openly. And, to invest in the host-based firewalls, host-based intrusion detection/prevention, and encryption technologies as recommended.
Just Who Can You Trust?
We’ve learned the hard way that the “oh. gee wizz — you can trust me” story of the telco’s and their plain text MPLS message tagging allow ‘just the good guys’ to see inside every single packet. Today, many
IaaS providers are marketing with a variation of the ‘trust me’ game. Yet, It’s contractually clear, inside the provider’s perimeter firewalls, your traffic is moving in plain text. To be clear, at least a third of your provider’s admins work in ______. (US citizens fill in the blank with China, and everyone else with USA.) If that is acceptable, flip the page, and have a nice day. Otherwise, your strategy has to focus adding host- based firewalls, host-based intrusion detection/prevention, and encryption at the application layer.
To be clear, there are currently over 260 companies across the globe offering various forms of IaaS on their websites. They all have SLA’s, and they all offer various forms and degrees of hardware, and visualization layer security features. The good news some of these services are far more effective, and better maintained that is the case in the budget strapped enterprise data center. But, in every single case, you will find, they can deliver nothing more than a shared responsibility model; one that can hide hardware and virtualization layer attack surfaces and vectors from your ability to control and monitor.
The Solution is a Security Lattice
IaaS cloud providers deliver several layers of shared ownership and control in the form of firewalls and isolation at the cloud edge. Vendor marketing and sales (plus enterprise application owners wishful thinking) distracts attention from the control gaps in security below the application layer.
“The NIST Definition of Cloud Computing” acknowledges:
The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).
[NIST Definition of Cloud Computing. Mell, Grance. Sept 2011]
Cross Cloud IaaS brings with it the need for a combined team effort, where providers and users work together to offer a security and control profile that meets the organization’s risk control requirements. Gartner analyst Thomas Bittman adds:
…a key to cloud computing is an opaque boundary between the customer and the provider. This is a result of the needs and concerns of the cloud service provider being distinctly different from the needs and concerns of the enterprise cloud user/application owner.
Figure 2 highlights the separation of control and ownership between application owners (the users) and IaaS providers in the IaaS business model. This boundary between what the cloud user can control and view, vs. what the cloud provider can view and control is reflected in more detail in Figure 3, the Security Lattice. The eight core elements of control and security of the lattice are divided into four different types of ownership and responsibility:
Security Lattice – Provider-Owned / Provider-Controlled
Most public IaaS cloud providers arguably have significantly better protections in place than the average enterprise. It is important to familiarize yourself with your public cloud provider’s capabilities. As a result the provider-owned, provider-controlled features (such as cloud edge DoS detection and remediation) provide a strong foundation for a powerful security lattice strategy.
Security Lattice — Provider-Owned / User-Controlled
One of the first techniques to emerge in virtualized infrastructure was port filtering on the host operating system of the hypervisor itself. This allows connections/packets that have made it to the host machine, where your instance runs, to be blocked at the hardware/host OS level, without ever reaching your virtual adapter. This occurs “inside the provider’s LAN” but before your instance.
Public IaaS providers allow users to control this hypervisor firewall through network mechanisms like security groups or parameters.xml. Recommended best practices are to lock down all but the ports that are needed for the application use-case.
Security Lattice – Independently Provided / User-Controlled
Purchasing and installing a virtual network device you control as part of your application layer can give you control of addressing, protocols, topology and security, and is an increasingly common use case. Using the virtual device to take control of your own VPN overlay solves the problem of data in motion being visible on the wire, even if it is a VLAN managed by the public cloud provider.
Look for 3rd party virtual firewall/router solutions that provide unique cryptographic keys for each host on your overlay network. Recommended best practices are to once again lock down all but the ports that are needed for the application use-case.
Security Lattice — User-Owned / User-Controlled
Assuming a “rogue” packet has made it through the network edge, through the hypervisor filtering, into your isolated VPN overlay virtual network, through the application layer firewall, and to one of your virtual machine instance’s primary interface, then host port filtering on that image is the last defense, or in fact ideally, the second to last defense when a virtual network is used.
When using a virtual network — this packet will only be responded to if it arrives at the tunnel port of the virtual network; AND if it has the unique signature for its stated address; AND has your virtual application layer network switch’s certificate. The final line of defense in the event the cryptographic credentials were stolen or forged, is your host’s virtual interface. Recommended best practices are to configure the virtual interface to only accept specific ports from specific hosts or network masks that are needed for the application use-case.
Security Lattice Best Practices
Leveraging the Security Lattice requires an orchestration of cloud provider services, cloud provider features, and security features on the part of the application owner. Tim Phillips describes it as:
“virtual application networking” or a feature of the network that allows the application owner to define the requirements of each server and applications. In other words, software-defined networking (SDN). SDN can span the cloud stack and offers application-layer control into the underlying infrastructure which translates into increased security for applications deployed to the cloud.
In order to run business application topology stacks in the cloud with secure access to your corporate data center and Cross Cloud to other IaaS vendors you should create secure and encrypted VPN connections using standard IPsec tunnels.
One of our customers uses this approach of overlay networking to connect their end customers’ virtualized networks regardless of hardware type or physical location. The end customers’ connect edge firewalls to business intelligence (BI) servers running in the Amazon AWS public cloud each with its own IPsec tunnel. The end customer’s devices vary well beyond those supported by AWS as to H/W vendor, age, and firmware version. Regardless, overlay networking provides the required interoperability and control.
Application-centric overlay networking allows the application owner to create a federated cloud-based encrypted overlay network spanning public clouds and regions & data centers inside those cloud providers. The result is a common encrypted address space spread between cloud providers.
Sourcing Virtual Firewall Routers
Just as we have learned with H/W firewall/routers, when sourcing virtual firewall/router devices, it is essential to confirm with your own testing that back doors do not exist. To build you own network overlay (BYON), you are looking for a supplier offering an virtual devices that support strong end-to-end encryption of site-to-site IPsec connectivity.
BYON virtual devices used for building virtual overlays should allow your organization to regain control of addressing, to use protocols the provider reserves (e.g. UDP Multicast), and to encrypted communications inside the IaaS providers edge firewalls.
To achieve secure Cross Cloud virtual networking, BYON best practice calls for deploying a mesh of virtual firewall/routers to extend connectivity across disparate clouds. The resulting application overlay VPN network will make it easy for you to capitalize on public cloud benefits, support IT innovation, and retain control of every aspect of enterprise-to-cloud connectivity.
Installing BYON devices that are under your organizations exclusive control, will allow you to extend edge and DMZ equipment like IPsec extranet, intrusion prevention, IDS and stateful inspection devices running in your data center into the cloud without the risk of exposing you security technology to rogue or undisclosed operatives at work inside the Public Cloud infrastructure.
Summary
I encourage you and your team to anticipate the future will bring cross cloud IaaS computing into your organization. Avoid the mistakes learned during the very similar sea-change during the PC revolution by avoiding prohibitions that drive IaaS use underground, and prepare now by embracing the logic of the Security Lattice. Focus your attention on Application Layer security & control by leveraging user-controlled overlay networks.
This article originally appeared in the January 2014 issue of Pen Test Magazine.
Subscribe to the Cybersecurity War Stories publication on Medium to get more from me and other IT security professionals in the trenches.
