Filed under: Cloud Computing, CSA, Elastic Security, IaaS, Presentations, Cloud Computing, Security, top threats, trust
July 13, 2011 • 17:28 0
Tendances cloud virtual conference
July 13, 2011 • 17:12 0
Trust and cloud security conference
Filed under: Cloud Computing, CSA, Discussions, Elastic Security, IaaS, Presentations, Cloud Computing, Elastic Security, IaaS, Security, top threats, trust
July 8, 2011 • 12:05 0
CloudyScripts: Ruby code for command line Security Audit via SSH
As requested by our users, we have just added a sample code for creating ruby script on top of cloudyscripts gems that can be found on RubyGems or on RubyForge.
The first script allows to run a Security Audit via SSH using a command line. In addition, we extended the scope of usage: the Security Audit can be run against a running instance (in addition to AMIs), thus allowing:
- to test running instances, therefore no need to wait for a new instance to start
- to make a Security Audit of a production server with full control of the Security Audit process
For any information on how to retrieve the source code of this openSource project that is published under Apache v2.0 Licence, please go to cloudyscripts SCM on RubyForge
We would like to thank Jonas Zaddach (Master Computer Science Student at Eurecom) who wrote the “Security Audit via SSH” part of the cloudyscripts library during his internship at SecludIT.
/fred
Filed under: AWS, Secure Cloud, Cloud Computing, Cloudy_Scripts, EC2, Amazon EC2, Amazon, Security, AWS, CloudyScripts, Audit, SSH, ruby
July 8, 2011 • 12:04 0
New CloudyScript: Security Audit via SSH
We are glad to announce a new CloudyScript Security Audit via SSH which makes a Security Audit of an Amazon EC2 AMI. It requires a privileged user that can perform sudo.
Security Auditing is very important in cloud computing infrastructures where virtual machine images (AMI in the case of Amazon) could be shared among users. In order to avoid backdoors or vulnerable machines in your own Amazon EC2 infrastructure, you MUST evaluate the public AMI you are using. Security Audit via SSH CloudyScripts automates that task.
Here is a sample output of an SSH Audit:

Moreover, we designed it as a library of security audits, that for now contains audits for SSH and Apache2 servers, but we will continue to extend it with other security audits
/fred
NB: This Security Audit does not check your IP restrictions for accessing the SSH server. In order to check that your SSH server is not publicly exposed you could use Public Port Checker CloudyScript.
Filed under: AWS, Secure Cloud, Cloud Computing, Cloudy_Scripts, EC2, Amazon EC2, Amazon, AMI, AWS, CloudyScripts, Audit, SSH
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, Symposia Journal
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, Cloud Security, Cloudy_Scripts
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, Cloudy_Scripts, security groups
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, Amazon EC2, Cloud Computing, Elastic Detector, Elastic Security, Monitoring, SaaS, SecludIT, Security, Tutorial
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, Amazon EC2, AWS, Cloud Computing, Elastic Detector, Elastic Security, Monitoring, SaaS, SecludIT, Security, Tutorial
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, Cloud Security, End-To-End, System Architecture


Cloudy_Scripts:
Elastic Detector
Recent Comments