Elastic Security

Icon

Security for the Cloud

Launch of HP Cloud with OpenStack

We’ve been busy lately with the second version of Elastic Detector, that supports Amazon EC2, Terremark’s vCloud Express and Eucalyptus. Today we’re thrilled to announce support of another leading cloud infrastructure: HP Cloud. Please find the complete announcement here.

We are strong believers in OpenStack and we have participated to the private beta of HP Cloud, in order to be ready from day one. We are happy to start our partnership with HP Cloud, with the goal of bringing added security services to the HP Cloud customers.

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

Tendances cloud virtual conference

Yet another french presentation to promote the whitepaper of “Tendances cloud”. And great questions from the more than 90 participants. Thanks to the other contributors and the organizers Salesforce.com and PowerOn.
Please stay tuned for the recording of the conference (in french).
 

Filed under: Cloud Computing, CSA, Elastic Security, IaaS, Presentations, , , ,

Trust and cloud security conference

Last week I was happy to be part of the conference on Trust and Security for cloud computing, organized by the Pole SCS.  I enjoyed the very good presentations and interesting ideas for collaborative projects. Keep up with the good work Pole SCS. Here are my slides.

Filed under: Cloud Computing, CSA, Discussions, Elastic Security, IaaS, Presentations, , , , , ,

Tendances cloud

Sorry to the non-french readers, but I’m often asked for french papers about cloud computing and security. We are proud to be contributors to a french white paper on cloud computing, so here is the link:

http://www.tendances-cloud.com/

Bonne lecture

Filed under: Cloud Computing, Elastic Security, IaaS, News, SaaS, Secure Cloud, , , , , , , , ,

How to increase security and visibility of Amazon EC2 instances?

Amazon EC2 administrators have to deal with daily problems such as:

  • Ensuring security of new instances,
  • Detecting performance and capacity problems,
  • Keeping track of the modifications on the infrastructure.

We would like to provide you some insights in our solution to address those problems and to facilitate the life of cloud-administrators by detecting security related issues and events: Elastic Detector. What makes this product unique is that it is fully automated and agentless. You can see how Elastic Detector works on this short video:


Filed under: AWS, Cloud Computing, Elastic Security, IaaS, Internals, Secure Cloud, Solutions, , , , , , , , , ,

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

Elastic Detector Launch

We have launched a private beta program in December 2010 and first of all we would like to thank all our beta testers for their feedback and comments.

For the last 2 months we have been busy improving Elastic Detector by integrating new features that suit your needs such as more powerful graphs and daily reports. Such features are built on top of our auto-check technology, that allows to ensure the security of your infrastructure with near zero configuration.

We are really excited to announce that the first version of Elastic Detector is ready.

Elastic Detector helps you to achieve full visibility of your Amazon EC2 deployment and monitors your security groups. You may give it a free try for 1 month. Configuration takes only 2 minutes,and then you may check Elastic Detector improving the security of your infrastructure in real time.

We will be very happy to count you among the Elastic Detector Community and we are committed at continuously securing your infrastructure on Amazon EC2.

Filed under: AWS, Cloud Computing, Elastic Security, IaaS, SaaS

Most annoying and at the same time most loved feature of Elastic Detector

During the beta test of Elastic Detector, we had a lot of queries concerning an important feature of Elastic Detector, that is :

  • Elastic Detector considers that an open port in the security groups should correspond to an available service in the instances that use the security group.

For example, if you have defined a security group web with the HTTP port open, Elastic Detector deploys an auto-check HTTP and if Elastic Detector does not get an answer, he raises a critical alert on it.

First of all, why Elastic Detector does this?

From the security point of view, it is a potential threat that can be exploited by an internal or external attacker. It means that the attacker can install a rogue application that has immediate access from everywhere. Imagine that the attacker (internal or external) deploys an e-commerce application to sell viagra on your infrastructure.

So, why sometimes this can be annoying to Elastic Detector Users?

I try to enumerate the reasons they gave us:

  • It is work in progress, so the service is going to be deployed later
  • It is a pain to manage a lot of security groups that should fit their services AND that must be changed whenever a service changes
  • I have IP restrictions to access this service

What are the solutions?

In order to cope with the first and second use case, we plan to allow for an acknowledgment of a temporary exception and for the third we have disabled auto-checks whenever Elastic Detector has no permission to access the service. Of course, once our users add Elastic Detector to the authorized IPs then an auto-check is deployed.

Finally, why is it loved by some Elastic Detector Users?

The administrators that are trying to control cloud usage love this feature. It gives an alert whenever one user changes the security groups, so administrators can at least follow the changes and drill-down if needed.

Conclusion

We strongly believe that the ports should be closed until the service is up and running for the sake of security.

Please let me know your thoughts about this feature, annoying or loved?

Filed under: AWS, Discussions, Elastic Security, IaaS, , , , , ,

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

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.