Elastic Security

Icon

Security for the Cloud

September 19, 2011 • 21:22 0

CloudyScripts for vCloud

Starting from now, CloudyScripts – our popular open-source library (more than 10000 downloads up to now) that aims at relieving administrators from finicky scripting details to secure and manage cloud infrastructures - now supports the vCloud API in addition to Amazon EC2. vCloud is the cloud stack provided by VMWare and already adopted by around 30 hosting providers worldwide.

The first script we provide retrieves all open internet services for a given vCloud organization/account and checks if a service is actually running on that port. Unused open ports represent a means for attackers to deploy rogue publicly available services and may – in the case of providers like Terremark, who charges explicitly for every publicly available internet service – even be linked to additional costs.

As usual, the script can be executed locally by installing a gem from the open-source library, by using the CloudyScripts web-service, or by starting a DevPay AMI within Amazon EC2. We will be happy for any feedback and open to implement or customize scripts on demand!

Filed under: Solutions, ,

September 15, 2011 • 15:42 2

EC2 Usage among Tech-Companies

Until recently, Guy Rosen on Jack of all Clouds published every month his “State of the Cloud” that tracked the adoption of cloud infrastructure services (IaaS) over time. For that purpose, he checked for the 500.000 top ranked web-sites if they were actually run by one of the big cloud infrastructure providers like Amazon EC2, Rackspace, GoGrid, etc. He got the web-sites from Quantcast and matched their IP address with the IP address ranges of the providers, which are publicly available. While the State of the Cloud gives very interesting quantitative information about the adoption, it doesn’t say anything about how cloud infrastructures are used and by whom. It lacks any form of qualitative information.

However, help is there: Techcrunch provides a database (the “Crunchbase“) containing almost 50.000 tech-companies with detailed information about the date of company creation, amount of funding, number of employees, and even a classification by a product domain tag – and their web-site URL, of course. What about combining this data with the adoption of cloud infrastructure (IaaS) usage? In this post, we concentrate only on Amazon EC2 companies.

How many use the cloud?

Here some general numbers:

  • Via the Crunchbase API, we retrieved 49398 companies
  • 3268 companies are using Amazon EC2 for their web-page, which represents around 6.62%.
  • The large majority (83.26%) of EC2 users are in the US East data-center (see also the chart below)

How is the cloud used?

In the crunchbase, companies are associated with tags. In total 6369 different tags are used. Below in the table, you see the most popular ones for EC2 users and for non-EC2 users.

The differences are not very big. Though, it seems that EC2 users have more affinity to consumer related stuff like social network apps, music, and video.

Who uses the cloud?

How many employees have EC2 users compared to other companies?

  • Average employees of EC2 users: 21
  • Average employees of other companies: 765

Are newer companies more open to cloud usage?

The chart below displays the number of companies created in a respective year, both for EC2 users and other companies.

Newer companies seem to be more open to adoption than established companies. The following chart clearly shows that the percentage of EC2 users is strongly growing with the year of creation.

Conclusions

From the charts above, it seem obvious that the adoption of Amazon EC2 is much stronger among smaller companies created in the last few years. This is not surprising given the fact that those companies have no legacy applications and data and can immediately benefit from cloud advantages like scaling and elimination of capital expenses.

Filed under: AWS, ,

September 6, 2011 • 16:49 1

Elastic Detector for free

Elastic Detector, our fully automated security event detection tool for Amazon EC2, is now available for free. It helps administrators and users of Amazon EC2-based infrastructures to continuously identify holes on security groups and applications, thus dramatically reducing the risk of external and internal attacks. In contrary to existing tools, you don’t need to install any additional software, such as agents, and do not need to configure any monitors up-front.

If you want to know more about Elastic Detector, watch the video below or try the service for free under elastic-detector.secludit.com.

Filed under: Internals, ,

September 2, 2011 • 14:38 2

AWS Security Alert: Insecure RDP Server Configuration

What is the Problem?

Some days ago, I received a mail from Amazon AWS telling me that one of our security groups gives public access (that is, an ACL with value “0.0.0.0/0″) to the port TCP/3389, which by default runs the Remote Desktop Protocol on Windows machines. The reason for this their mail is that “a new Internet worm has been discovered in the wild that spreads via the above protocol [...]“. To remedy this danger, they  ”suggest that you audit your Amazon EC2 security group settings and restrict access to only the instances and IP addresses that need access“.

I checked the configuration, found out that fortunately no service instance is running in that security group, but fixed the wrong configuration. While I appreciated the notification, I have two points of critique:

  • My colleague, who wanted to reproduce such an alert by adding port TCP/3389 with public address to one of his security groups, has not been notified yet. This raises the question, how often such a security group audit is run by AWS.
  • When checking my security groups, I realized that I had also other critical ports open, e.g. port SSH/22, that may be subject to future attacks, but for which I didn’t receive a security notification. What about those other sensitive ports?

How to fix this?

In order to make AWS’s recommendation of auditing security groups easy to perform by anybody, we implemented a ruby-script that retrieves all security groups and identifies permissions that give public access to critical ports, i.e. ports that we consider such sensitive that accessibility may cause critical damage to your machines. For now, we check against the ports 22 (SSH), 23 (telnet), 389 (LDAP), 1433 (MSSQL), 3306 (MySQL), 3389 (RDP), 5432 (Postgres), and 5500 (VNC).

The script is part of the CloudyScripts open source project and thus can be either installed and run locally by yourself or executed from this web-site. We hope to help make your EC2 cloud more secure! Any feedback or collaboration is welcome!

Filed under: AWS, Solutions, , ,

August 26, 2011 • 16:08 0

Detect useless Snapshots and Volumes in the Amazon EC2 Cloud

Do you know that problem? You started and stopped server instances on the Amazon Cloud, performed snapshots of instances or EBS volumes, and after some weeks or months you find the EC2 console totally cluttered. There are lots of unattached volumes with completely meaningless IDs and dozens of nameless snapshots, for which you even don’t know what they actually contain. Having all that data lying around does not only compromise your usage experience in the web-console, but also increments the probability of data leakage and accidental loss. And even worse, you need to pay for that mess and invest some time to regularly clean it up – manually and carefully to avoid the deletion of unique data or backups that might actually be needed for recovery purposes in the future.

We at SecludIT wrote an open-source script to address this problem and published it in on our CloudyScripts site. The script identifies two types of resources that might be considered for cleanup:

  • Snapshots: when the number of snapshots that exist for the same EBS volume exceed a certain configurable number, you can safely delete the oldest ones
  • Volumes: when a volume is not linked to any instance and is not used since more than a day, it is probably useless

We are aware that there are very complete AWS cost control and optimization solutions on the market (e.g. Cloudyn or Cloudrows). However, in case you simply want to clean up your account from time to time without registering for a new service, the script should be quite helpful. I run it every week now!

Let us know if you consider this useful and if you have propositions to improve it!

Filed under: AWS, Solutions, , , ,

July 7, 2011 • 08:16 1

Symposia Journal

The latest edition of the Symposia Journal is out, a magazine with community driven high quality articles around Cloud Computing (partly in German). We contributed to the latest edition with an article about the top threats of cloud computing in the IaaS space and how to tackle them. Have fun reading!

Filed under: Cloud Computing, Discussions,

July 5, 2011 • 10:01 1

The Risk of Unused Public Ports

Services with public access must be kept only to public services. Public services are the most exposed to external attacks and should be minimized. Furthermore, public access requires a running public service in order to prevent an attacker or insider (with no access to the security groups firewall) from deploying a rogue publicly available service within your infrastructure.

We therefore wrote a script as part of the CloudyScripts project that detects open public ports that run no service for all instances in your EC2 infrastructure. Note: the same feature is also part of Elastic Detector and described in more detail here.

Filed under: AWS, ,

July 1, 2011 • 10:24 0

New CloudyScript: Detect Port Ranges

Amazon EC2 uses the notion of Security Groups to let users define inbound firewall rules (called permissions) that are dynamically applied to all server instances that are part of the group. This concept is easy and very powerful at the same time, since permissions must be configured once only and are then applied like a template to all future server instances – contrarily to traditional firewalls, where rules are defined for every server.  At the other hand, wrong configurations have a higher impact since all server instances of a misconfigured group are affected.

Thus, the configuration of security groups and attribution to launched instances should be done very carefully. One very frequent misconfiguration is to open complete port-ranges for public IP addresses. It may also happen that third party EC2 tools use the API to create security groups with open port ranges to facilitate their own access and thereby exposing your infrastructure.

Open port ranges allow attackers to scan all ports that are actually used, retrieve information about the services running on a particular machine, and focus on attacking particularly critical ports like port 22 for SSH. We added a script to our CloudyScripts library that allows you to identify all security groups with open port ranges in a given EC2 region. You can find the script here. An additional contribution to make the cloud more secure. Your feedback is always welcomed!

Filed under: AWS, ,

June 14, 2011 • 17:32 0

Cloud Security and the End-to-End principle

The End-to-End Argument

The end-to-end principle in systems design has become famous for its successful implementation in the Internet architecture. It suggests “that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.” The complexity and cost of implementing those functions in lower layers, the fact that those functions cannot be implemented in a fully reliable way on lower layers and thus need to be implemented on higher layers anyway, and the risk that they may be inefficient or even useless for certain services on top – all those facts are arguments in favor of the end-to-end principle. In the context of the Internet, it means that the network remains rather dumb (simple packet forwarding), while more sophisticated protocol functions like error detection, retransmissions of lost packets, flow- and congestion control, and connection management are implemented at the end-points, i.e. the servers themselves.

The End-To-End Argument in Information Security

The end-to-end principle however does not play the same role in the information security domain. Encryption of file-transfers (encrypt files instead network packets) follow the end-to-end argument. However, many security functions like firewalls, network intrusion detection systems, authentication and authorization servers or reverse proxies violate the end-to-end principle – and for good reason because they are more effectively done by separate components in the enterprise network instead on the end-points. Even vulnerability, anti-virus software and patch management systems are no longer managed by the end-points, but by centralized servers with big databases behind.

The End-To-End Argument in Cloud Security

OK – the end-to-end argument does rarely hold for Information security systems. But is this still true in a cloud computing setup, where servers may be distributed across different heterogeneous networks and infrastructures provided by different providers? Most cloud providers provide a simple provisioning API that allows to start and stop instances from virtual images and possibly create snapshots of the running servers. They don’t provide a firewall component in their infrastructure (Amazon EC2 is one of the exceptions with their concept of security groups), they provide no or only rudimentary Identity and Access Management, no IDS/IPS systems, no vulnerability and patch management, no encryption, no data leakage systems, no VPN layer. Most providers put the burden of assuring security explicitly on the shoulders of their clients and say: that is your responsibility, not ours – do it yourself or find someone who does it for you. This way, they implicitly promote the end-to-end principle: why encrypting all data in memory and on storage, when only few customers need this level of protection? Why providing a firewall, when every end-point can install and configure their own? Why providing sophisticated identity and access management, when the users know much better what exactly they need with regard to IAM?

The danger of this attitude is that when the cloud providers don’t build security services into their infrastructure, no one may do it. Many users simply won’t do the effort of searching and deploying an appropriate third party security solution. They will use the cloud service as it is, enjoy their immediate benefits (no capex, immediate access, scaling), and postpone the security problem for later. This is somehow understandable, since it corresponds to the division of work and responsibilities in most enterprises today: users/developers are not the administrators are not the security experts. My belief is that cloud providers will be obliged to integrate more and more security services in their infrastructure (similar to Amazon EC2 security groups) and provide APIs for them – and thus adapt a system design that move security functions away from end-points into the cloud providers own network and infrastructure.

Filed under: Discussions, IaaS, , ,

May 9, 2011 • 14:18 0

Cloud Security – Who is Responsible?

A recent survey among cloud providers (via) raises the question about the responsibility for security between cloud-providers and cloud-users. A large majority of 69% out of the 127 cloud providers asked in this survey rather consider the cloud user responsible for ensuring the security of the cloud services (while 35% of the cloud users see this the same way). 32% of the cloud providers and 32% of the cloud users see security as the cloud providers responsibility, 16% of the cloud providers and 33% of the cloud users see it as a shared responsibility (note: apparently, several choices were possible, the numbers not adding up to 100%).

Those number are alarming, especially together with other findings of the survey:

  • most cloud providers do not believe their products or services substantially protect and secure the confidential or sensitive information of their customers
  • they also say their systems and applications are not always evaluated for security threats prior to deployment to customers
  • on average providers of cloud computing technologies allocate10 percent or less of their operational resources to security and most do not have confidence that customers’ security requirements are being met
  • the majority of cloud providers in our study admit they do not have dedicated security personnel to oversee the security of cloud applications, infrastructure or platforms.

While those results indicate a general lack of maturity in this early phase of cloud computing adoption (seems to be a recurring pattern that security is added later in the life-cycle of technologies), there’s another aspect that is completely hidden in this survey and even misleading: it doesn’t discriminate results by delivery model (55% of the participants are SaaS providers, 34% IaaS providers, 11% PaaS providers) although the level of control given to cloud users is a very different for the 3 delivery models – and the level of control is essential with regard to sharing responsibilies between providers and users.

IaaS providers (like Amazon EC2) provide a high-level of control to their users back down to the operating system, while SaaS providers (like Google Apps) don’t even give control of how and where data is stored (PaaS models are somewhere in-between). That is, SaaS users are simply not enabled to carry their supposed responsibility, while IaaS users are and actually do to a large part (e.g. Netflix). The following graphic provided by the Cloud Security Alliance (CSA) well illustrates the relationship between security and control.

For example, Amazon EC2 encourages a “Design for Failure” model, where cloud users are supposed to replicate components to deal with potential outages. IaaS users have also full control over their databases and can encrypt sensitive data.

Bottom-line: a discussion about the responsibilities of cloud security does not make sense without taking into account the delivery model of the cloud provider – since responsibility is linked to control.

Filed under: Discussions,

Twitter Updates

Follow

Get every new post delivered to your Inbox.