Elastic Security

Icon

Security for the Cloud

January 28, 2011 • 09:49 0

AWS Elastic Beanstalk

We already wrote about it recently: 2011 could be the year that sees the rising of PaaS. SaaS providers open up their platforms for third party providers and IaaS providers provide added services that simplify usage and hide low-level abstractions. The first group moves move down in the cloud-stack, the second one move up – both will meet in a more and more crowded middle.

The latest move of thought- and market-leader AWS confirms this prediction. Last week they released a service called “Elastic Beanstalk“, a clear PaaS offer that enables users to deploy Java web-applications in a Tomcat environment (apparently, other stacks like Ruby on Rails are in the pipe) by uploading their code via a graphical user-interface. AWS starts the application, provides transparent scaling, load-balancing, and fault-tolerance if needed. In so far, it is a direct competitor of Google Apps Engine, but with the difference that it still gives full control to users on OS level. That is, users can deploy and customize whatever they want on the servers and thus have all the flexibility they need, e.g. start cron-jobs to periodically normalize data in the database, use a file system to store their data instead of a database, or produce chart-images in the background – all things not possible with Google Apps engine today. Beanstalk leverages the power of the EC2 offer to address the biggest limitation of existing PaaS offers.

The service seems to be dedicated to SaaS providers, Web-Startups, E-Commerce sites that are often forced to care for all that awkward low-level stuff themselved and often don’t have the resources to do it correctly. Who else will use Beanstalk? Let me know your ideas in the comments.

Filed under: AWS,

January 12, 2011 • 11:45 0

Monitoring vs Detection

What is the difference between our elastic monitoring/security tool Elastic Detector and the monitoring feature of EC2 called Amazon CloudWatch – aren’t both monitoring tools? The answer will illustrate what we understand by elastic monitoring and elastic security, and explain the difference between monitoring and detection.

Amazon CloudWatch allows to measure performance metrics of individual resources (instances and volumes). The information can be retrieved via a specific API, but also visualized as a graph within the EC2 console. The metrics currently supported are CPU, Disk I/O and Network I/O. While the API allows to retrieve information aggregated by instance-type or image-type, the console currently only displays information per resource. The API also allows to define alerts in case a metric exceeds a certain threshold.

Elastic Detector also collects performance data and even uses the CloudWatch API to retrieve them. It also sends notifications for alerts, but there are fundamental differences:

  • Elastic Detector doesn’t only collect performance data for specific machines, it collects all information that it can get for the whole infrastructure (including security groups and relations between resources). This happens fully automatically without human intervention and immediately, that is, as soon a resource is allocated.
  • Elastic Detector exploits and analyzes the collected information to automatically detect anomalies and notify users about those anomalies, which may be linked to performance data, but also to configuration inconsistencies or security issues. Information filtering is hereby essential to discriminate important from unimportant issues.

Therefore, detection is a layer on top of monitoring that uses the data produced by the monitoring layer to improve visibility, detect problems, and analyze anomalies. The ultimate goal of detection is to give users full visibility over the whole infrastructure to quickly discover problems, distinguish relevant from irrelevant information, and provide them with the tools and the context to track down the origin of those problems to eventually solve them.

Filed under: AWS, Elastic Security, ,

January 7, 2011 • 10:16 1

AWS Policy Generator

We recently posted this article that describes how to generate Amazon EC2 read-only credentials for third-party providers. Amazon released a little helper tool this week, a Policy Generator, that facilitates building quite complex policies. The AWS blog very well describes the necessary steps to produce a policy in this post.

Example

Following our example, the result would look like

{
"Id":"Policy1294332686329",
"Statement":[{
"Sid":"Stmt1294332597167",
"Action":["cloudwatch:GetMetricStatistics",
"cloudwatch:ListMetrics"
],
"Effect":"Allow",
"Resource":"*"
},
{
"Sid":"Stmt1294332680637",
"Action":["ec2:DescribeInstanceAttribute",
"ec2:DescribeInstances",
"ec2:DescribeSecurityGroups"
],
"Effect":"Allow",
"Resource":"*"
}
]
}

This code must be copy/pasted into a file (e.g. policy_file.txt) and then applied by the following command:

iam-groupuploadpolicy -g ExternalProviders -p ReadOnly
-f policy_file.txt

Outlook

I hope that the AWS Policy Generator will be extended to allow also the generation of credentials linked to a policy. That way, the most embarrassing part for many people would disappear: the download and installation part of the command line tools.

Filed under: AWS, ,

January 6, 2011 • 14:20 0

IT Job Security in a Cloud World

A question that is very often posed and discussed in the context of cloud computing is the question of job security. Yesterday I came across this article in PCWorld that argues that tech support tends to split into two main areas of expertise: helping the client and maintaining the infrastructure. A migration to cloud computing solutions would strongly affect the second area (no more server management, no more license related work, no more patching). The article also mentions some new opportunities of cloud computing that include the handling of a multiplicity of devices accessing data (mobiles, tables, desktops, laptops), the existential importance of having a powerful and robust Internet pipe, and new forms of data backups (from the cloud to local servers or across the cloud) – and finally recommends system admins to embrace the cloud instead ignoring it.

The article doesn’t make a difference between small and large organizations, which is missing in my opinion. Many small organizations (with core competence outside IT, but even small software companies) have already started several years ago to outsource IT Management to Managed Service Providers that maintain infrastructure and applications on behalf of their clients. For those small organizations, changing to cloud applications is no big shift anymore.
The big shift will happen within big organizations and the service providers and hosters themselves. But I rather expect the daily work life of an IT administrator more interesting and multi-fold than before. He needs to confront new domains of expertise, work with new tools, and thus acquire some new skills. Just to list a few examples:

  • He will need to work with different cloud models (IaaS, PaaS, SaaS) and with solutions that integrate between different clouds
  • Single-Sign-On and key-management solutions across heterogeneous platforms are particularly important in cloud environments
  • Automation of work-flows and operations via Cloud APIs will leverage the power of cloud computing and drive the development and usage of new tools (like Rightscale, Puppet, or Chef)

Don’t forget that cloud computing doesn’t mean that the operating system will disappear. It is still a part of the cloud stack and maintaining IaaS deployments (like Amazon EC2) require strong Linux or Windows knowledge. IT administrators shouldn’t worry when they read about the rise of cloud computing – there will still be a lot of work to do for them and even more interesting and challenging tasks.

Filed under: Cloud Computing,

January 4, 2011 • 10:00 5

Why The Perimeter Must Become Virtual

The Perimeter is a key concept in the world of information security and even older than that. In its original sense, it means a path that surrounds an area. In the context of information security, this path consists of an ensemble of protection mechanisms that surround your information: they include physical walls and physical protection around servers in a data-center and logical walls (firewall, intrusion prevention systems, anti-virus protection).

In the world of cloud infrastructures (IaaS), it is not so easy to determine the “area” that is supposed to be surrounded. Resources are shared among different clients (multi-tenancy) and they are allocated in data-centers of external providers (outsourcing). Moreover, computing resources get virtual – physical resources are transparently shared – and elastic – they are allocated and destroyed on demand. Since this can be done via APIs in a programmable and automated way, cloud computing infrastructures are highly dynamic and volatile. How can one build a perimeter around a moving target?

Well, the short answer is: the perimeter must also become virtual, highly dynamic, and automated.

Let’s have a look at an example: A new web application is being launched. There should be an automated verification process that checks the firewall rules, the access rights of users, the level of patches and if they are automated, if backups are being done, that performs an external audit of the application (using a SaaS service for instance), even the deployment of a Web application firewall in front of it – just to name a few steps. This does not eliminate the need for including security during the development life-cycle, but unless we can deliver such an automated service, we will hear complaints about the time to get new services online and continue to have insecure application online (maybe in an another cloud :-) ).

Filed under: Cloud Computing, Elastic Security, IaaS, Solutions,

Twitter Updates

Follow

Get every new post delivered to your Inbox.