InfoSec Blog - IT Security and the Cloud

Cloud Computing

December 20, 2019

2020 is just a few days away. Time to think about the next year projects? Possibly moving another workload to the cloud? Cloud companies have a lot of experience in IT security, dedicated staff, petabytes of data on internet traffic patterns and threats. Cloud is more secure than the on-prem deployment.


Or is it?


In November, a Wisconsin-based IT provider of cloud data storage and security services to over 100 nursing homes suffered a ransomware attack [1]. Earlier in December, an IT service provider in Colorado suffered another ransomware attack which impacted over 100 dental offices served remotely by the company [2]. Some dental practices then had to negotiate recovery of their data individually with the attackers. 


What are the security advantages in the cloud?

Let's take the cloud pioneer - Amazon Web Services (AWS). Amazon among others follows the Shared Security Model (SCM):  "Security and Compliance is a shared responsibility between AWS and the customer" [3].


The AWS is responsible for the hardware infrastructure and its security (servers, networking, facilities,...) and possibly higher tiers depending on the type of services the customer chooses. If the customer chooses the Infrastructure as a Service model (IaaS) and deploys their IT service directly on the AWS virtual machine within the Amazon Elastic Cloud [4] (EC2) then the customer is still responsible for OS patching and configuration of the virtual machines and all upper tiers. 

But if the customer chooses to deploy their service in a server-less environment, e.g., on Amazon Lambda [5] then there is no server to patch and the customer can focus on the secure application design while AWS is responsible also for the security of the application servers – this is the Platform as a Service model (PaaS).

Finally, when the customer chooses a specific Software as a Service (SaaS), for example the Amazon Identity and Access Management (AWS IAM) then the AWS takes responsibility even for the application (IAM) patching and security. In most cases the customer remains responsible for defining and managing the appropriate access permissions, managing their application (and database or OS) options, training of their employees, and the high-level architecture, e.g., identifying the availability requirements.


While the SaaS model frees customer resources which can be then spent on conducting the business it may not provide enough flexibility for some customers. What if you need to operate the EC2 infrastructure, e.g., a virtualized server with your custom-designed middleware, and, therefore, you are responsible for the OS security - what are the security benefits of the cloud compared to on-prem virtualization?


Cloud companies often provide suites of security and automation tools to assist you and these tools typically require less deployment and configuration effort relative to on-prem. As an example, let’s have a look at the Amazon Inspector [6]


The Amazon Inspector (launched in October 2015) is a Security Vulnerability Assessment tool available for the AWS cloud and hybrid deployments. While the full functionality requires agent installation on the monitored hosts, the Inspector can identify potential vulnerabilities in network security configuration even without any software installation. Let’s run a vulnerability scan to see what it requires...


We will:

  • install the data-collection agent (the only software we will need to install)
  • define the assessment target
  • define the assessment template (what we will scan for) and execute it
  • review and act on the findings



Step 1: Install the agent on the monitored server

Let’s pick the Amazon Linux virtual machine (the agent is supported also on other operating systems [7]). We will download the agent package and run the installation script as root on the target virtual machine:


bash install


Step 2: Define the assessment target

Sign into the AWS console, proceed to the Amazon Inspector service and hit the Get Started button (we do not need to deploy any other software).

On the Welcome page select the Advanced Setup and define the assessment target – the list of servers you would like to scan.  Define the name of the target, lookup the monitored host by its tag (in this case our server is tagged with the Project=isblog key-value pair), uncheck the Install Agents option (we have done that already in the step 1) and hit next.

Defining the assessment target - the servers we will scan


Step 3: Define and run the assessment template

The assessment template links together the target and the assessment rules (what vulnerabilities we will be looking for). On the template page we will enter the name of the template, confirm the target we just defined, leave all four assessment packages enabled, and leave the duration set to 1 hour. Then “Create and Run”.

Defining the assessment rules - the vulnerabilities or configuration weaknesses we will scan for


Step 4: Review and act on the findings

This is the most important step. The findings are categorized by severity and by the rules package, for example, Common Vulnerabilities and Exposures (CVEs) [8], Network Reachability [9], CIS Benchmark [10], or Security best practices [11]. We could export the data, receive the report as pdf, or have it emailed to us upon completion. And once the vulnerabilities are mitigated we will repeat the assessment to confirm the resolution.


Reviewing the assessment findings


Cost? Presently [12] the cost for the assessment we just ran would be US$0.45. As with many AWS services there are volume discounts and the initial free tier.

Amazon Inspector also comes with a command line interface and APIs similarly to other AWS tools. Alternatives to Amazon Inspector are available from the AWS Marketplace, e.g., Tenable Nessus Scanner.  While the Nessus Scanner provides a variety of options, it requires its own virtual machine, and has a different pricing model. 


Despite the various data breaches, cloud has potential advantages in security over on-premise but it depends on the implementation by both the solution provider and the customer.

Three take-aways from this blog post:

  1. Cloud-native security tools require little or no installation effort.
  2. Native cloud tools support automation and integration.
  3. Cloud security is a shared responsibility between the provider and the customer.


Written by: Zdenek Nejedly (Identity and Access Management Senior Analyst, Information Security)

Randall Munroe


[13] Randall Munroe: The Cloud