# A Framework for Security Transparency in Cloud Computing
## 4 Cloud Security Transparency
### Categories of Cloud Security Transparency  
Security transparency shows three different types as shown in Figure 1.  
* **Proactive Transparency (Voluntary)**. Proactive transparency involves voluntary disclosure of information, meaning that the CSP voluntarily provide information to the users by means of autonomous agents or manual process. It stems from CSPs initiatives to make security information of their offerings available to all without a request being filed. It can be generated through various methods such as notifications or reports (such as websites and portals, benchmarks, whitepapers, _etc._). This disclosure is generally intended to improve customer trust and confidence, assist customers evaluate basic CSP control environments, demonstrate CSP certification to regulatory or industry requirements, and also help customers address some specific questions around general practices. It does not reveal information that could jeopardise the security posture of a CSP or expose them to harm's way. For instance, when a CSC's data falls under restrictions emanating from regulatory or compliance requirements, the choice of a CSP hinges on the contentment that they are fully compliant to a regulatory body, otherwise there is the risk of violating regulatory, legal or other privacy requirements [25]. The benefits that accrue from CSPs initiative to proactively disclose information include the availability of information that ensures timely access to information to help all CSCs including small, large and medium enterprises without the need to file special request, which is indeed associated with various sorts of commitments. * **Reactive Transparency (Necessary)**. Reactive transparency involves a request-driven approach where a CSP is expected to respond to a user's specific request. It emerges from a request-response routine between a CSC and a CSP for the latter to provide additional information. Through the  
Figure 1: Categorisation of cloud security transparency. request-response regime, a prospective user files a request and receives information from an existing CSP or for an incident notification to be sent to the CSC. Generally, the contents of a CSP response represent the actual settings, offerings or security status of CSC assets rather than a meagre attempt to beat competition from other vendors, which indeed increases transparency on how individual requirements are distinctly addressed. The advantage of the request-response driven approach is its ability to enable users to exclusively specify their security requirements and the identification of suitable controls by the CSP. However, it could be argued that it has become a traditional practice for CSPs to frequently publish information in public domains so that future cloud users do not have to file a request, saving time for both the CSP and the customers. * **Contractual Transparency (Statutory)**. This implies that a CSP is legally mandated by the law to provide transparency while rendering services to CSCs. It involves a valid written agreement where the CSP observes utmost disclosure of all essential security services on an individual basis, while refraining from divulging information that could compromise the privacy of other users. SLAs are useful tools widely used by both CSPs and CSCs for ensuring transparency and establishing a common pact in order to manage the security requirements requested by a CSC and the security levels being offered by a CSP. Also, the SLA forms the basis for defining responsibilities and the remedies available for customers in case of a contract breach. Fundamental aspects of the SLA are the representation of the contexts shared by the two parties, and how each actor utilises the contexts in its own operations throughout the SLA. In order words, the SLA provides a comprehensive description and transparent security processes for both the CSP and customer to avoid uncertainty, apprehension and disputes.