Skip to main content

The 3 Main Security Risks in IaaS Cloud

09.Mar.2017
SecludIT, now part of Outpost24
Cloud and Container Security
Enterprises are migrating to IaaS due to flexibility and speed. However, IaaS brings new security challenges

Share this article

 

 

Gartner says by 2020, a corporate "No-Cloud” policy will be as rare as a “no-Internet” policy. However, IaaS brings new security challenges as drawn by the CSA. Most 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. 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 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.
 
Discover your infrastructure and your initial security setup.
The Discovery process is high-speed and nonintrusive. Unlike traditional networks, we do not need to rely on Network Scans; we use the IaaS APIs.
The benefits: no impact on network transactions (latency/congestion), no risk of false positives. Stopped and suspended (i.e., without network activity) asset are detected.
 
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. These 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 the advice to fill the gaps to achieve compliance, to get a five 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
 
Description
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.
 
Resolution
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.
 
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 significant security flaws, therefore tests need to be run to check for the security of changes in real time.
 

2. Detect and Mitigate Vulnerabilities in Workloads

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:
  • 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.
  • 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)
  • 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. This storage can contain sensitive or critical data that can leak.
 
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 a new attack surface. It is straightforward to make 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 different 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 Resources
In Cloud IaaS, it is effortless to deploy a new server and just to 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 website for example, restoring due to a server crash, etc..), this server become the riskiest and vulnerable server in your infrastructure.
 
Automation, the DevOps way, may address these risks. Solutions that automatically do all the hard work are available to help DevOps. Elastic Workload Protector is such a solution and we invite you to try it!

Looking for anything in particular?

Type your search word here