Government classifies data, in Canada for instance, as Confidential, Secret, Top Secret, or Cosmic Top Secret, and has a variety of requirements, which should be considered relevant to each classification level. Specifically, regardless of the classification level, in order to have access to and store data, an organization would have to have obtained a Facility Security Screening (FSC) clearance with Document Storage from the Canadian and International Industrial Security Directorate (CIISD) of Public Works and Government Services Canada (PWGSC).12 Depending on the level of access and document sensitivity, the requirements increase – as does the time to validate those requirements. An organization could absolutely not consider hosting data of similar classifications on clouds which do not have these levels of screening from their respective domestic security screening providers.

Data considered “Trade Secrets” within an organization will likely have a bare minimum level of security associated with it. Similarly to data about mergers and acquisitions or financial data, an organization will actively want to protect the trade secret data in a meaningful and defined manner. Although there may not be specific government legislation around it (in the case of publicly traded companies, there most likely are laws governing the integrity of this data at a minimum, such as Sarbanes Oxley in the United States13), an organization have no desire to purposely or inadvertently divulge its data, and will likely be willing to take significant steps to protect it.

14.2.2.3  Labeling

Classifying data is only as effective as the exercise of labeling the same data and related systems to reflect their classification. If an organization has undertaken the exercise of classification, it is likely that it has gone through the effort of appropriately labeling it. Of course, by extending an organization to the cloud it becomes incumbent to ensure the appropriate labeling of the relevant systems and data used in the cloud. The challenges of physically labeling virtualized systems persist, and are further compounded by cloud’s virtualization of datacenters.

14.2.3  Access Control and Connectivity

Control mechanisms necessary for appropriate user access are another segment of compliance concern with respect to using the cloud. Specifically, it may be necessary to ensure the availability of authentication mechanisms that need to both provide appropriate levels of authorization and accountability as well as integrate

12 http://ssi-iss.tpsgc-pwgsc.gc.ca/index-eng.html

13 http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_bills&docid=f:h3763enr.tst.pdf

seamlessly with client’s environment. This is where out-of-the-box solutions from the cloud provider may not be sufficient for an organization’s authentication requirements. Depending on the cloud type – SaaS, PaaS, IaaS – the requirements would vary radically. If using cloud Infrastructure-as-a Service, the capability for remote administration of the related equipment would likely be required; how someone physically and logically connects and authenticates to this environment can have a substantial influence on the cloud provider and client organization’s compliance initiatives. For instance, if a computer directly connects to a PCI environment, it runs the potential of being within the scope of the PCI compliance initiative. One way to circumvent this issue would be traversing a demarcation firewall and connecting to a jump point administrative system (such as a terminal server) that uses strong authentication. Mechanisms like this may need to be explored to fully understand the implications of using the cloud and weighing the cost-to-benefit ratio prior to making the decision.

14.2.3.1  Authentication and Authorization

With respect to authentication, how an organization provides access is a subject of great importance. Failing the existence of some sort of universal federated identity or the ubiquity of “Identity 2.0” type technology, offering access to the cloud is not without its substantial obstacles. Many questions immediately arise: Who manages the authentication database? Is the client’s organization responsible for providing it and the related links to the cloud or is the cloud managing it entirely? If the latter, how does the client’s organization obtain the assurances around appropriate access? Alternatively, if the client is providing the authentication mechanism, how does it leverage the distributed environment of the cloud and the benefits of redundancy without having similar capabilities around its LDAP or other authentication directory? These are all very difficult questions to answer and require sufficient planning and understanding of the risks and technologies.

Authorization suffers similar problems, specifically around ensuring only those with appropriate managerial approval are provided the requisite access. In an outsourced environment, it is difficult – if not impossible – to ensure that all of the access is known and approved. Presumably, the cloud provider may have some access of which the client’s organization would not necessarily be aware nor have any significant influence over after the fact.

14.2.3.2  Accounting and Auditing

The issue of authentication is further compounded by the issue of accountability and nonrepudiation. In the case of a cloud provider managing the authentication mechanisms, appropriate logging and monitoring facilities may need to be present depending on the nature of the data in question. In the case of PCI DSS, this is a clear requirement. More so, adequate separation of duties between those who