Elastic Security

Icon

Security for the Cloud

November 22, 2011 • 18:32 0

Elastic Security: Vulnerability Assessment

Elastic Detector, our FREE Vulnerability Assessment tool for Amazon EC2, has been recently updated with NEW features. Of course, the NEW Amazon US-West (Oregon) has been added at the meantime (see the AWS blogpost for more information).

Sometimes, security is considered boring (as shown in one of our previous posts on Open Ports Check), I take this opportunity to give some explanation on the recent Security Features that have been added and to point out two features of Elastic Detector, that are essential for providing a security solution that can cope with the elasticity of cloud infrastructures.

New Security Features of Elastic Detector

  • Blacklist Checks: Check against well-known RBLs if your Elastic IP Address (EIP according to Amazon naming), or the IP address taken from Amazon pool address is blacklisted.
    This allows cloud users to detect configuration errors in a mail server that is used as an Open-Relay or to detect a malicious insider that is using your infrastructure to install a bot-net (part of CloudSecurityAlliance Top Threats).
  • Critical Ports Audit: Check against a tunnable list of sensitive ports that there are no critical ports open to the public.
    This allows cloud users to be protected from dictionary attacks on administrative services such as SSH, Webmin (for Linux instances), or RDP (for Windows instances).
  • Security Zones Auditor: Define Security Zones according to the port that are accessible (using 3 Levels of Security: public, sensitive and critical) and the source IP addresses that have access to those ports (using 3 Levels of Trust: untrusted, fairly-trusted, trusted). Based on that information, Elastic Detector verifies if there is a perfect separation between servers of different trust levels with regard to their Security Zones. For example, in a three tiered architecture (Web server, Application server, Database server), an instance running a Web server should not be able to directly access an instance running the database server as this will potentially expose your data in case of compromise of the web server.

Two Characteristics of Elastic Detector

  • AgentLess: No additional agent or software to install on your instance (AMI according to Amazon convention naming).
    Using APIs, there is no risk of loosing connectivity with an agent (due to a network problem, a misconfiguration, or a human error) and no need to maintained the agents that are deployed. Moreover, the agent is itself a target for attack, so using APIs give us an additional level of isolation.
  • Auto-Check Technology: Any cloud resources (especially instances) are under control during the complete life-cycle, as continuous Security Checks based on customizable templates are automatically put in place as soon as the resource is detected by a real time polling system til the resource is shutdown.

Feel free to comment or ask more details on the security points.
/fred

Filed under: AWS, Cloud Computing, Elastic Security, Secure Cloud, , , , ,

August 4, 2011 • 17:37 1

Monitoring Tool: Amazon EC2 plugins for Nagios

SecludIT has published two plugins for monitoring Amazon EC2 with the Nagios Open Source monitoring solution. These plugins are available on Nagios Exchange under the Apache2 License . Both Nagios plugins are written in Ruby on top of the Amazon EC2 Ruby Gem library and use HTTP Query API calls to Amazon API endpoints.

Nagios Plugins for Amazon EC2

Nagios Open Source monitoring solution consists of various Nagios projects as follows:

  • Nagios Core: the open source monitoring engine and multiple APIs for extending core functionality
  • Nagios Plugins: efficient, standalone extensions that provide low-level intelligence for monitoring everything with Nagios Core

Contrarily to traditional IT infrastructures, Cloud Computing stacks (such as Amazon EC2) allow server monitoring through their programming interfaces (APIs), meaning that:

  • you do not need to install and maintain agents on the servers (for example, no need for SNMP agents installation and configuration)
  • you do not need to configure and protect a privileged access to the servers (for example, no remote SSH tunnels)

The plugins we provide illustrate these advantages. Without agents, you can:

  • know the status of your servers (running, stopped, starting, stopping)
  • get metrics of your servers (CPU, Network traffic and disk usage)

Check Amazon EC2 Instance status plugin

The Check AWS EC2 Instance Status plugin allows to retrieve the status of Amazon EC2 Instances. This is a Nagios active check that takes the Amazon API endpoint and an Amazon EC2 Instance ID as input parameters, connects to the Amazon API endpoint through HTTP Query API calls and retrieve the status of an Amazon EC2 Instance.

Get Amazon CloudWatch metrics plugin

The Get Amazon CloudWatch metrics plugins allows to retrieve metrics from Amazon CloudWatch. This is a Nagios active check that takes the Amazon API endpoint, an Amazon EC2 Instance ID and the CloudWatch metric as input parameters, connects to the Amazon API endpoint through HTTP Query API calls and retrieve the value of the metric for the Amazon EC2 Instance.

Security

As these two Nagios Plugins requires Amazon Credentials (Access Key ID and Secret Access Key) to connect to Amazon APIs endpoints we must ensure that the Amazon Credentials are encrypted (that is, not stored in clear on the disk) and permissions for the encryption key and the encrypted credentials must be restricted to the user or daemon running the plugins. Moreover, our plugins only require a read-only access to the Amazon APIs endpoints, therefore we highly recommend the use of AWS Identity and Access Management (IAM) to generate read-only Amazon Credentials. We have written a blogpost on how to generate read-only Amazon EC2 Credentials.

Amazon EC2 security monitoring using SecludIT’s Elastic Detector

SecludIT uses Nagios on Elastic Detector, a Security and Monitoring Tool for Amazon EC2. The two Nagios Plugins (that we gave to the community) are used in Elastic Detector to get the status and metrics of Amazon EC2 instances. This information is one of the inputs to our detection engine, and is complemented by other security related information such as Amazon EC2 Security Groups analysis and open ports. Therefore, Elastic Detector is agentless and detects Amazon EC2 security related events.

Feel free to try out our Nagios plugins and Elastic Detector and let us know what do you think.

/fred

Filed under: AWS, Cloud Computing, Elastic Security, Secure Cloud, , , , , , ,

July 13, 2011 • 17:28 0

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

July 13, 2011 • 17:12 0

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

June 23, 2011 • 11:37 0

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

June 16, 2011 • 09:02 0

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

March 8, 2011 • 17:05 0

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

February 18, 2011 • 19:04 1

Amazon EC2 ‘broad character’ support and Security impact on third party tools such as Elastic Detector

The goal of this document is to enlighten security issues on third party tools that come from some features of the Amazon EC2 console. We are going to explain two security threats, a XSS (cross site scripting), and a command injection, using a second party tool as injection’s vector.

Taking our own product Elastic Detector as an example

First of all, let’s describe the context of our application. Then we will have a closer look at the security issues introduced using the Amazon EC2 console.

Elastic Detector is complementary to the Amazon EC2 console (or other management console). It retrieves security group information by the EC2 API and it helps users to have a global security overview of their infrastructure on Amazon EC2. In addition it performs analysis of potential security threats.

XSS

Amazon EC2 API supports broad characters in the Security Group name. If for example, we define the following Name: <script>alert(“Hello World!!”)</script>

A third party product that displays this Security Group Name without sanitizing the data, it will result on a nice Hello World !! alert popup when browsing this Security Group.

Command Injection

Due to the broad character support in Amazon EC2 in Security Group name, we could define the following Name: `cp /etc/passwd /tmp`

So, once this security group is stored in a database without sanitizing, a third party product using shell commands such as eval, exec, mail or printf, could potentially execute the injected command. So a new file name passwd would be added to the /tmp directory in the product as a simple example.

NB: This could also be done using Amazon EC2 Security Instance Tags, in fact every field supports broad characters in Amazon EC2.

Conclusion

These two security issues are examples that illustrate the fact that a third-party tool MUST check and sanitize user’s input (like all software), but also check and sanitize any data coming from other tools or service SaaS.

Thanks To

We would like to thank the Amazon Security Team that fully collaborated and confirmed that broad character support is a feature of Amazon Web Services (especially Don Bailey) and the Certilience Team that helped us as an external auditor of our code.

/fred

Filed under: AWS, Cloud Computing, Elastic Security, Secure Cloud, , , , , , , , , ,

February 17, 2011 • 21:15 3

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

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

Twitter Updates

Follow

Get every new post delivered to your Inbox.