Faisal Jameel is an Enterprise Architect for a leading global pharmaceutical company. His area of focus has been Microsoft.NET technologies, Service Oriented Architecture and Cloud computing. Before joining his current company he has worked at the Institute of Electrical and Electronic Engineers (IEEE) and Astea, a Cloud Service Provider. He holds several industry certifications in SOA and Cloud Computing and a graduate degree in Computer Science.
Still VPN to your SaaS? Published: March 31, 2016 • Service Technology Magazine Issue XCIV PDF
Introduction: Clouds Take Care of Themselves
The popular myth that cloud environments are not secure has an opposing view which is almost as strong. Proponents of this view claim that mature cloud providers due to the economies of scale have the ability to offer the best in class security. If vendors were unable to provide secure solutions their reputation and hence their entire business would be at stake. So there is no need for cloud consumer to worry or invest in cloud security. The answer in fact lies somewhere in the middle. According to a recent Gartner article 1 through 2020, 95 percent of cloud security failures will be the consumer's fault. It is imperative for any organization embarking on the cloud journey to realize that cloud security is a shared responsibility between the cloud provider and cloud consumer, and that majority of the burden is actually on the consumer to secure their cloud applications. This article will try to describe three security techniques that are essential for any organization subscribing to a cloud service.
Part 1 – Auto Defined Perimeter
Strategy Will Lag Use
Most organization will shift workloads to the cloud without a corresponding shift in security policies. Defining a detailed strategic policy upfront is often not possible; however, a happy medium is when some high level directives are available from the C-Lounge. Typical examples could be a pre-approved list of services deemed fit for the cloud or some guidance on which mission critical applications should NOT be moved to the cloud. In the absence of such direction organizations tend to use the tools of yesterday to implement solutions for tomorrow… a recipe for disaster. Take a look at the following example on how peer to peer connections are made over a WAN using TCP /IP. The basic system operation was highly scalable but wide open.
Figure 1 – Basic TCP /IP system operation
A host would find another host it wishes to connect to by looking up its address in a DNS server.
Host B's address is highly advertised and it is constantly listening for requests at the transport (TCP) level not knowing who is actually making the request. Identity and authorization are typically established AFTER the connection handshake is established in this scheme.
When WAN connections were extended over the internet using VPN the basic scheme changed to the following.
Figure 2 – Secure TCP /IP with VPN
The hosts still engaged with each other (TCP connection followed by a TLS connection) BEFORE any authorization took place. So the connection was secured but the network and the hosts themselves remained vulnerable. VPNs were essentially designed for remote access and they typically offer protection between two well-defined network perimeters.
Protecting Ephemeral Boundaries
As we evolve from connectivity to collaboration in the cloud, the notion of a network defensible by firewalls is getting obsolete. Today users connect to an enterprise application from multiple locations using BYOD phones and tablets often using cellular networks external to the organization making network perimeters ephemeral. To our detriment, however, we routinely use site to site VPN connections between enterprises and cloud providers.
As noted above VPNs only protects the connection between two well defined network perimeters. It also offers no protection to the hosts involved, some of which are highly advertised (by DNS servers) ,from denial of service attacks. Phishing attacks aimed at stealing credentials could easily negate the little connection protection that VPNs offer. So the question now becomes, how do we connect securely to any application using any device from anywhere without exposing any hosts that conventionally remained connected.
The Auto Defined Perimeter (ADP) mechanism described below aims at protecting SaaS implementations by not only protecting the connection but also the ephemeral network boundary and the highly advertised hosts involved.
Figure 3 – Auto Defined Perimeter Controller & Gateways
Notice in stark contrast a multi factor token establishes trust BEFORE connecting to the application and it also alleviates the need for a constant connection. Also notice that there is no need for a DNS server. If an organization uses the same browser to connect to SaaS solution that it uses to connect to Google e.g. they are probably not protected using the mechanism described above and are vulnerable to cloud breaches.
Part 2 – Cloud Denial of Service Attacks (DDoS)
Denial of service attacks have existed for some time now. Conventionally they were handled by blocking the offending IP addresses. Over the years the attacks got more sophisticated and seemed to originate from multiple IP addresses. While firewalls got more sophisticated to detect these kinds of distributed attacks, the solutions could not really be applied to a cloud environment. Clouds are expected to scale up when they get requests from multiple locations so conventional rate limiting and IP blocking mechanisms do not apply or work. Cloud systems to this extent enable attackers them to do more damage by scaling up. So for cloud environments a deeper inspection is needed to identify a legitimate request and protect network resources.
Another common aspect that is often over looked in cloud based attacks is bandwidth based resource attacks. If your cloud provider is charging you for bandwidth besides system unavailability bandwidth based attacks could have a significant financial impact. Bandwidth based attacks are either flood attacks where the network bandwidth could be clogged preventing legitimate traffic or amplification attacks which exploit the broadcast reply feature found in most networking devices like routers.
A DDoS mitigation service can be adopted to counter some of the vulnerabilities described above. This service can either be deployed on the consumer or the cloud provider side and typically has the following defense mechanisms
Filtering – This includes inbound filtering of traffic from spoofed IP addresses and an out bound filter to allow packets having valid IP address in the network specified range to leave the network.
Detecting – This includes detecting anomalies based on previously detected normal system performance. A database of well know exploits is sometimes also maintained for pattern comparison.
Responding – Once a DDoS attack is detected this capability aims at blocking the attacker and also tries to trace the attacker's identity. Typical methods could include ICMP trace backs, IP trace backs, Link-testing trace backs or Probabilistic packet marking. A detailed description of these techniques is out of scope of this article.
If the cloud provider you are subscribing to does not offer this service a high capacity front end service deployed at the cloud consumer would generally suffice.
Part 3–Cloud Access Security Brokers (CASB)
For organization relatively new to the cloud journey another important consideration is to use or implement a Cloud Access Security Broker. This is still a relatively newish domain but industry forecasters predicts that 85 percent of all major enterprises would use or employee one in the next three years. Some of the capabilities that typical CASBs offer today are listed below.
Two Types of CASBs
There are essentially two ways in which a CASB works. In both cases it logically sits between the cloud provider and cloud consumer. A brief description of each appears below
Proxy Based – In this type all data passes through the broker. The proxy could be a forward proxy in which case the organization needs to install a certificate for each device accessing the cloud service. This becomes a bottleneck when the employee base is large and the organization allows BYOD. A reverse proxy on the other hand does not require any special device configuration however it cannot work with typical client server applications that uses pre-configured host names.
API Based – The other type of CASBs are API based. Being relatively new there are very few cloud providers that provide API support however this is expected to change in a hurry.
As seen above both types have pros and cons and an organization needs to decide which type serves their purpose. Some CASBs also offer a hybrid approach by providing multi-mode capabilities which support both proxy and API technologies. It should also be noted that all cloud applications do not support CASBs. Whereas general HR and ERP applications do health care specific apps for example do not. Major Pharma companies e.g. are expected to deploy these capabilities in house versus outsourcing security or subscribing to a CASB. Some major players in the CASB arena today are Microsoft (Adallom) , Bit glass, Cloud Lock, Elastica and Cipher Cloud.
To summarize, if your organization is embarking on the cloud journey and does not have adequate resources and skill sets to deploy Auto defined Perimeters or high capacity DDoS mitigation services subscribing to a CASB is a good first step. In sizable organizations this capability may eventually shift to on premise capabilities but what is clear is that techniques used to protect a typical network either do not work in cloud environments or give a false sense of security. Identifying mechanisms that apply to cloud security and applying them correctly would the key to securing your cloud assets.