# A Framework for Security Transparency in Cloud Computing
## 5 Cloud Security Transparency Framework
### Organisational Level and Modelling Concepts for the Framework  
The organisational level concepts are based on the conceptual level foundation concepts to ease the implementation of transparency at the technical level. For example, a CSC at the conceptual view sends a Request for Transparency to a CSP demanding additional security information while the CSP responds to such a request by disclosing information through mechanisms for transparency. Before the request for information is sent, the CSC ought to apply some essential analytical steps for identifying their goals, assets and security transparency. This level allows for such processes to be applied. Therefore, the following are the necessary concepts at an organisational level while focusing on the conceptual view. * **Cloud Strategy**. This supports the CSC to make sense of adopting or the reasons cloud services have been adopted. In other words, it allows CSCs to conduct an internal analysis of their goals and the readiness to adopt cloud services, and how security transparency can be realised. The cloud strategy is characterised by two attributes:
* Goals. Represent the aims and objectives of a CSC's intention of migrating to the cloud. The goals could be cost reduction, flexibility and scalability, improved accessibility, and security _etc._
* Cloud Readiness. This analyses the integration of locally hosted applications, data, or processes with cloud services in terms of standardisation, format, portability, interoperability, _etc._ Also, cloud readiness identifies the potential benefits associated with fulfilling goals. * **Assets**. This involves the identification of CSC assets, those assets that are outsourced to the cloud environment and those that are hosted locally. Selected assets are classified according to category and criticality to the operations of the CSC. The relevance of this is to allow for the identification of the essential security requirements that are put around the assets to help the CSC maintain a track record of the assets. Asset has two attributes:  
Figure 5: Conceptual Model of Cloud Security Transparency. Category. Assets are classified according to different tiers of sensitivity and security requirements such as public, open or confidential. Public means asset is accessible to the general public, open means available to every company user, confidential limits access to only authorised company users. * Criticality. Criticality is the major indicator used by the CSC to determine the importance of the asset to the business. Criticality is not dependent upon category, however, the criticality of any asset category can be high, medium or low. Assets with a high rating are the most valuable to CSC, a medium rating represents a moderate value; while low means little value to the CSC. * **Risk**. Risks are the potential consequences inherent to a CSP control environment that could potentially compromise the security of assets in the cloud. A risk could fall under one or more of areas of cloud such as: security, operational, technical, nontechnical, regulatory, governance _etc._
* **Controls**. Controls are sets of security safeguards or countermeasures to avoid, counteract or minimise security risks in a CSP operating environment. Controls may also represent the mechanisms used by CSPs for providing transparency. They are supported by a CSP and characterised by a combination of technical and non-technical controls that describe the essential components assembled and actions taken to protect assets. * **Evidences**. Are affirmations from the CSP specifying the existence of acclaimed security controls and providing a transparent overview of their implementation/management. In other words, evidences are exclusively generated by a CSP in connection with supported controls to CSCs assets.