12:57 PM
Connect Directly
Repost This

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
Newest First  |  Oldest First  |  Threaded View
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.

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
Current Issue
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Published: 2014-04-24
The E-Mail autoconfiguration feature in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 places a password in a GET request, which allows remote attackers to obtain sensitive information by reading (1) web-server access logs, (2) web-server Referer log...

Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in Open-Xchange AppSuite 7.4.1 before 7.4.1-rev11 and 7.4.2 before 7.4.2-rev13 allows remote attackers to inject arbitrary web script or HTML via a Drive filename that is not properly handled during use of the composer to add an e-mail attachment.

Published: 2014-04-23
CRLF injection vulnerability in the CGI implementation in Microsoft Internet Information Services (IIS) 4.x and 5.x on Windows NT and Windows 2000 allows remote attackers to modify arbitrary uppercase environment variables via a \n (newline) character in an HTTP header.

Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

Best of the Web