The Microsoft approach to cloud transparency – Part III

Welcome! Please comment and leave me a note telling me what you like and what you'd like to see more of. Sign up to my RSS Feed!
This entry is part of a wonderful series, Microsoft Cloud Transparency»

Thank you for joining us again for the continuation of the paper I authored for Microsoft about  its approach to security of Cloud offering, including using the Cloud Security Alliance (CSA) Security, Trust & Assurance Registry (STAR).

Let me know what you think!


The Microsoft approach to cloud transparency

Using the Cloud Security Alliance’s Security, Trust & Assurance Registry (STAR)


Part III – Privacy

As part of the security risk assessment, a privacy review needs to be considered to ascertain potential risks to the data and operations in the cloud. Today, the notion of privacy goes beyond the traditional description of customer data and extends into organizational privacy, which includes most intellectual property constraints; that is, the

know-how, know-why, and know-when of organizations. As more and more organizations become knowledge-based, the intellectual property values that they generate increase. In fact, intellectual property value is often a significant part of an organization‘s value.

Confidentiality and integrity

Similarly, concerns about confidentiality (who can see the data) and integrity (who can modify the data) are important to include in any evaluation. Generally, the more access points to the data, the more complicated the risk profile creation process. Although many regulatory frameworks focus on confidentiality, others such as Sarbanes-Oxley focus almost exclusively on the integrity of data that is used to produce report financial statements.


In many cloud computing environments, the data flow that moves information into and out of the cloud must be considered. Sometimes multiple carriers are involved, and oftentimes access beyond the carrier must be evaluated. For example, a failure at a communications service provider can cause delay and affect the reliability of cloud-based data and services. Any additional service provider must be evaluated and assessed for risk.

Auditing, assurance, and attestation

Many organizations are experienced in traditional application and data deployment activities, such as auditing and assessments. In a cloud deployment, the need for some of these activities becomes even more acute at the same time that the activities themselves become more complex.

Embedded in the cloud concept, and especially in public cloud deployment, is a lack of physical control by the organization that owns the data. Physical controls must be considered to protect the disk drives, the systems, and even the data centers in which data resides. Such considerations also apply to software environments in which cloud services components are deployed.

In addition, obtaining permissions for the purpose of satisfying requirements for resiliency testing, penetration testing, and regular vulnerability scanning can be a challenge in cloud deployments.

It can also be a challenge to address and satisfy requirements for independent validation of controls. Cloud providers are typically reluctant to approve many types of testing in a shared infrastructure because of the impact that testing could have on other customers.

 Frequently, an organization intending to engage in cloud deployment does not

know how to evaluate risks or how to choose a cloud provider that mitigates risks.


For certain regulatory frameworks, auditing is a requirement.  Frequently, cloud customers are faced with challenges that threaten or appear to deny the many benefits of cloud adoption and deployment.


Join us again next week for Part IV of the Microsoft approach to cloud  transparency.


PCI DSS Wireless Analysis and Recommendations, Part 3

This entry is part of a wonderful series, PCI DSS»


The PCI DSS Wireless Guidance document is filling out a very important need.  As I said in Part I, and Part II.   Today I will continue analyzing this Wireless Guidance document.  I will number them and ask that you refer to that number in your comments on my suggestions.  Remember – the goal is to help improve the document.


How to Improve on the PCI DSS Wireless Guidelines Document – Part III

Point of Clarification

>Before I delve into the flow-chart detailed in section 2.2, that I have a lot of input on, let me suggest that the comment at part 2.1.3 (9) is a tad confusing:

Allow me to suggest that if there was a way to guarantee that no traffic would ever enter or leave from the AP to the CDE, then those are, in fact, not on the same network.  Since there is no way to positivly assure of it, and keeping in mind the inteded audience of this document, why don’t we (10) call this scenario out as such?

Finally on this point, why don’t we agree the firewall’s configuration is always a part of the PCI DSS?  At the very least, this device is the demarc point and we need it.


Requirements and Processes

This flow chart, titled "figure 5" and appearing on page 8, could be improved:


In this ‘blog entry I will start the discussion about it.

Firstly, let’s look at the first two rows of the flow chart:


There seems to be a logical problem here.   Let me suggest replacing the flow with mine, below:



 The two changes I notate are (11 in Red) that documented access control policies should exist BEFORE we can check if there are any unauthorized wireless devices and (12 in blue) that the rule about Documentation and about Proving should be broken into two separate rules.  The proving rule might belong to an audit, and required by PCI DSS. 

I also have another suggestion (13), that the box marked "have monthly reports…" should be considered for clarification due to the discussion on the previous section of firewalls within or without the CDE definition – there by leading to the possibility that all scans be rendered useless due to a functioning firewall…




Beginning next week I intend to make:

– all, of course, time allowing.