Elastic Security

Icon

Security for the Cloud

February 8, 2011 • 10:17 0

Reply to “Don’t Conflate Virtual with Dynamic”

This post is a reply to the blog post “Don’t Conflate Virtual with Dynamic” posted here and here, that was already a reply to our original post “Why the perimeter must become virtual“.

First of all, thanks to Lori for the very interesting blog post. Here goes my comments :

  1. Overall we agree. In the original block post we stated “Well, the short answer is: the perimeter must also become virtual, highly dynamic, and automated.”. Lori on the other hand says “In order to implement the kind of dynamic network perimeter … we do, in fact, need a more flexible, automated perimeter.” We agree on the dynamic and automation part.
  2. It seems that is the word “virtual” that triggered the discussion, for example Lori states “Dynamic is not a synonym for virtualization and virtualization does not inherently provide the fluidity of the network architecture required to address the challenges associated with highly dynamic environments.” And the fact that virtualization itself rises security, compliance and performance issues. We agree on the issues and for example the top threats to cloud computing from the Cloud Security Alliance refer to this in the item “Shared Technology Issues” (for example xen and vmware vulnerabilities).

So, everything boils down to the questions : Should the (security) perimeter be virtual or non-virtual ? Should we use a “toss another virtual appliance” approach to security (like we do for scaling) or more about “designing an architecture comprised of highly dynamic and interactive components that can be provisioned and managed on-demand” as Lori said ?

These are challenging questions in my opinion and I’d really appreciate to continue to discuss this topic. What are your thoughts?

Just to give some clues, I can think about trusted computing platforms and are they possible with virtualization? Can we establish trust on top of virtualization layers? Actually, these are some of the questions that the Virtualized Platform working group is trying to address.

Sergio

Filed under: CSA, Elastic Security, IaaS, Uncategorized

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 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.