Enterprises are migrating to IaaS due to flexibility and speed. Gartner says ““by 2020, a Corporate No-Cloud” Policy Will Be as Rare as a “No-Internet” Policy Is Today.”
However, IaaS brings new security challenges as drawn by the CSA. Mostly important is the new shared responsibility model as follows:
– Your provider is responsible for the security of the cloud (e.g., global infrastructure, storage, databases, networking, compute, etc.)
– You are responsible for security in the cloud (e.g., data, platforms, applications, operating systems, firewalls, etc.) and we can manage it with and for you !!
Once we understand the consequences of this new model and we trust our IaaS provider for its share of responsibility, we still need to tackle our share. In order to make your journey secure, we contribute with our view of priorities built upon our expertise helping enterprise securely migration to IaaS such as AWS and Azure.
The 3 main security risks in IaaS Cloud: Misconfiguration, Vulnerabilities, and Shadow-IT
1- Avoid Misconfigurations, Apply Security Best Practises in the Cloud
As a Cloud customer, you have a lot of options for configuring security. Often these options are far too cumbersome and complicated, especially to a company just starting off with IaaS. Like a DevOps continuous build chain, our benefits are pipelined into an automation process that use Cloud APIs, letting our running production server and network untouched and safe.
a. Discover your infrastructure and your initial security setup.
The Discovery process is very fast and non intrusive. Unlike traditional networks, we do not need to rely upon Network Scans, we just use the IaaS APIs.
The benefits: no impact on network transactions (latency / congestion), no risk of false positives. Stopped and suspended (ie without network activity) asset are detects.
b. Fix security misconfiguration and reduce time to achieve compliance to cloud security labels and standards.
IaaS is not managed like Traditional IT, IaaS is driven by code and APIs, and rather than testing misconfiguration with some entropy and side effect, so we may query our setup configuration through APIs, and compare it with templates. Theses templates are built from Security Labels Benchmarks such as CIS Security (we are CIS supporting partners).
For example in AWS, we will query your account, and compare it with a set of 52 security rules. Then, we give you advice to fill the gaps to achieve compliance, to get a 5 stars security level, and minimize threats.
Here is an example of a Configuration Entry test :
CIS-AWS – 1.1 Avoid the use of the “root” account
Service IAM – Risk Level High
Using the “root” account entity is dangerous and should be avoided, if possible. Users should practice “least-privilege”, a technique where specific user accounts are created and assigned the minimum privileges necessary to complete their work. Additional privileges can be added to their account as their scope grows, but no user should have the limitless power of the “root” entity. We examine your account to determine if a non-root entity exists, ensuring that you have at least one IAM user configured to perform daily work functions.
Create an IAM user and assign the basic role or privilege that you deem necessary to perform daily functions.
By checking Configuration with more than hundred tests run, we are able the get the best security misconfiguration cover and find the wrong or insufficient setup.
c. Monitor your infrastructure in a continuous way and raise alerts when changes or new security vulnerabilities are detected.
For testing purposes, new infrastructure setup, new application deployments, changes happen all the time (and are accelerating). These changes can lead to major security flaws, therefore tests need to be run to check for the security of changes in real time.
Deploying applications and data in IaaS, does not protect you from vulnerabilities and weaknesses in applications and data. The cloud provider is not responsible for the Workloads security.
While vulnerability management is a must have in traditional or cloud environments, workloads change more rapidly in the cloud. We need to adapt our approach for more recurring scans, more automation and deeper analysis.
The benefits of using our Elastic Workload Protector technology:
a. SCAN more often with no impact on workloads: with our patented technology, we can run deep intrusive server analysis with no impact on running servers.
b. PRIORITIZE with quick evaluation of real and residual risk of your information system. Track your compliance evolution to the market security standards. (CVE, CIS, PCI, OWASP, ANSSI)
c. REMEDIATE taking into account the cyber attack consequences on your company and setup an efficient action plan.
3- Uncover Shadow-IT in IaaS
– Ghost virtual servers or workloads
The ability to detect servers or services with no activity. Probably, they have been started for tests and forgotten by their owner. They cost money, and presumably as they are unused, they are not updated and therefore are a point of vulnerability in the infrastructure. (Gartner says that 28% of servers are ghost servers)
– Orphan Storage
Storage disks that are not attached to any computing resources and that anyone can attach to any servers. These storage can contains sensitive or critical data that can leaked.
– Nefarious workloads e.g. usage control
Example: using cloud to crack passwords or launch attacks
Example: Side channel attack detection from you own account can be detected with Elastic Detector, just by detecting a suspicious activity on your own account (several launch and termination on virtual machine).
– Many new services and APIs
This introduces new attack surface. It is very easy to do mistakes with lines of code that have a great impact (for example disabling all firewalls takes 1 line of code)
AWS has more than 50 differents services and it is releasing new ones every month. It is hard to keep the pace and easy to make mistakes at the beginning. You cannot be an expert on everything (from map-reduce to load balancing)
– Dormant ressources
In Cloud IaaS, it is very easy to deploy a new server and to just stop the old one. This server is then not seen and not updated during the patching for example. In this case, when you start this server for any reason (checking old version of the web site for example, restoring due to a server crash, etc..), this server become the most risky and vulnerable server in your infrastructure.
Automation, the DevOps way, may address these risks. Solutions that automatically do all the hard work ara available to help DevOps. Elastic Workload Protector is such a solution and we invite you to try it!
More information about Cloud Workloads and security risks: