Risk
2/10/2012
12:57 PM
Connect Directly
RSS
E-Mail
50%
50%

Tech Insight: Penetration-Testing Your Cloud Provider

Vulnerability assessments and penetration tests can be a great way to validate the security posture of these organizations

Understanding what's behind a cloud-based application or service can sometimes be painful -- but it doesn't have to be. Cloud service provider audits typically start out of habit: the need to review, understand, and assess, but organizations don't often tailor their approach to the risk at hand.

Before embarking on a long audit of a cloud service provider, define your goal by clearly identifying what it is we care about and want to protect. If the service stores data that, if compromised, would be detrimental to our organization, then the assessment should be much more aggressive than if the data stored would be a minor annoyance if it were compromised. Spend your time, money, and resources wisely so you don’t spend more time than required on assessing a third party and taking time away from other activities that provide better risk mitigation to your organization. Be sure to cover all the risk points -- data transit, storage, access control, vendor employee access, logging, application security, physical security, and third-party integrations, to name a few.

Here's what not to do: Don’t start audits with huge checklists and questionnaires. We all have these, we’ve all had to answer them, and we all hate them. No one wants to answer them and, more importantly, no one wants to review the answers. The questions never accurately address the risk or service being assessed, which leads to more work on both sides to clarify answers. Start the assessment by understanding the controls of the third party, what audits the organization undergoes, and what compliance standards the organization has already met. Being clear about your goals and concerns will help guide the assessment, especially in cloud situations where infrastructure and applications are very different than traditional enterprises and thus rapidly evolving.

[ Two-thirds of IT pros don't believe cloud environments are as secure as on-premises environments. See Most Execs Don't Feel They Can Secure Cloud Infrastructures. ]

Vulnerability assessments and penetration tests can be a great way to validate the security posture of these organizations. In my experience, most cloud-based providers are open to allowing potential customers to perform vulnerability assessments against the infrastructure as long as it’s during an agreed-on time frame so their teams can respond to any issues and be available to answer questions. In the rare case where this hasn't been possible, it has usually been a red flag that I might need to walk away from this vendor.

These assessments are good for most providers since they have little other information to provide to prove their service stands up to the rigorous enterprise security standards given that many build their services on public cloud services, and enterprise security offerings don’t fit well with cloud infrastructures. Ever tried doing IPS and full-packet capturing in the cloud? If so, then you know that the IDS/IPS line of the security checklist is hard to fulfill. One side tip: Be sure to do your due diligence in identifying all of the in-scope systems and to validate any findings the organization presents. Some providers host their applications within the infrastructure of larger cloud providers and, as such, go through some sort of validation process. These validation processes aren’t the most complete and don’t necessarily address the concerns you have. Validate scope for yourself since it’s your risk to assume.

When working with cloud providers, be clear about your concerns, approach the assessment in a risk-based manner, and, most importantly, realize that we’re at a pivotal point where our traditional methodologies and processes no longer apply across the board. Those responsible for security in the cloud have just as tough of a job as we do on the enterprise side. We’re trying to prove their security, their trying to build the security, and neither of us has the resources we truly need to meet the same requirements we set for our own internal operations. Even so, cloud services can be secure, or some are insecure, but we must view them for what they are and review the risk on a case-by-case basis.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MSHIVHARE000
50%
50%
MSHIVHARE000,
User Rank: Apprentice
2/22/2012 | 8:18:46 AM
re: Tech Insight: Penetration-Testing Your Cloud Provider
Dear Adam,

As you rightly said, defining goals is the most important step while assessing the cloud. Whenever organization wants to test any cloud infrastructure, it is recommended to evaluate the performance of the platform that the cloud vendor is offering. However, many organization try adding variables that are specific to the business problems they are trying to solve, but this is completely a wrong approach. In case of hybrid solution which involves PaaS and IaaS, seek testing the private and public clouds individually. Simultaneously, the scope of cloud testing needs to be widened in order to outrun the challenges and risk involved in it.

Regards,
Manish
MS8699
50%
50%
MS8699,
User Rank: Apprentice
2/13/2012 | 7:04:16 AM
re: Tech Insight: Penetration-Testing Your Cloud Provider
Cloud-based approaches to this layer of IT are becoming more of a norm and less of an exception
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6117
Published: 2014-07-11
Dahua DVR 2.608.0000.0 and 2.608.GV00.0 allows remote attackers to bypass authentication and obtain sensitive information including user credentials, change user passwords, clear log files, and perform other actions via a request to TCP port 37777.

CVE-2014-0174
Published: 2014-07-11
Cumin (aka MRG Management Console), as used in Red Hat Enterprise MRG 2.5, does not include the HTTPOnly flag in a Set-Cookie header for the session cookie, which makes it easier for remote attackers to obtain potentially sensitive information via script access to this cookie.

CVE-2014-3485
Published: 2014-07-11
The REST API in the ovirt-engine in oVirt, as used in Red Hat Enterprise Virtualization (rhevm) 3.4, allows remote authenticated users to read arbitrary files and have other unspecified impact via unknown vectors, related to an XML External Entity (XXE) issue.

CVE-2014-3499
Published: 2014-07-11
Docker 1.0.0 uses world-readable and world-writable permissions on the management socket, which allows local users to gain privileges via unspecified vectors.

CVE-2014-3503
Published: 2014-07-11
Apache Syncope 1.1.x before 1.1.8 uses weak random values to generate passwords, which makes it easier for remote attackers to guess the password via a brute force attack.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.