It is reasonable to identify the common categories at which security transparency is actualised in cloud lifecycle. The significance of this is to elaborately underline the situations where CSPs tend to be transparent and provide some clarity into how transparency is perceived. For instance, cloud users usually make cloud migration decisions based on public information (freely available to all in public domains) where a provider is unlikely to provide detailed information due to security concerns or privacy restrictions. More accurate and all-encompassing information (in individual contracts) is often provided when agreements are reached. Supposing the private information is the most critical and
41
relevant for decision and it is only made available after agreeing on a contract, the tendency this generates is that users might wrongly perceive the public information as being misleading or deception from the part of the CSP. We, therefore, classify the various forms at which transparency is articulated as shown in Figure 4.1 Transparency Categories Proactive - Notifications - Reports Reactive - Requests - Responses Contractual - SLAs - Contract Clauses
Figure 4.1 Categorisation of Cloud Security Transparency
Proactive Transparency (Voluntary): Otherwise referred to as voluntary disclosure, stems
from CSPs initiatives to make rudimental security information of their offerings available to the whole public without a request being filed, and the aim is to generate assurances using a multiplicity of methods ranging from notifications to reports (through mediums such websites and portals, benchmarks, whitepapers etc.). This disclosure is generally intended to uplift customer trust and confidence, assist customers to evaluate basic CSP control environment, demonstrate CSP conformance to regulatory or industry requirements, and also helps customers address some specific questions around general cloud computing 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 cloud user’s data falls under restrictions emanating from regulatory or compliance requirements, the choice of a CSP hinges on the contentment that the provider is fully compliant to the regulatory body; otherwise, there is the risk of violating regulatory, legal or other privacy requirements. The CSP counteracts customer contemplation through proactive disclosures to illustrate controls and certifications that reveal the reliability of their services at the preclusive cloud strategy stages. The benefits that accrue from CSP’s initiative to proactively disclose information are numerous. It ensures that cloud users are enlightened about the security management procedures applied to their resources while in the custody of the CSP. From another perspective, the ready availability of information ensures timely access to information that helps ensure the equality of access to information for all cloud customers including small, large and medium enterprises without the need to file special request, which is indeed associated with various sort of commitments. However, a supposed downside of this disclosure type is the possibility of a CSP to disclose inherently limited information, attempt to conceal damaging information that could tarnish its reputation, or even proclaim deceptive controls that give an impression different from the genuine environment.
42
Reactive Transparency (Necessary): Reactive transparency emerges from a request-
response routine at the initial procurement phase between an organisation and the CSP for the latter to provide additional information. It may arise from legal or regulatory requirements that mandate CSP to disclose certain information during contract negotiations. Through a request- response routine, a prospective cloud customer files requests for and receive information from an existing CSP. This mainly takes shape through two procurement methods, i.e. Request for Information (RfI) and Request for Proposal (RfP). To demystify the meaning behind each of the terms, RfI is a request to several potential CSPs to specify conditions, information gathering, or for cloud strategy purposes. It is mainly used when a cloud user has not identified their security requirements and need more information from a CSP to help them discover what steps to take next before negotiations commence. While an RfP is mainly employed when a cloud user has determined the scope of their security requirements or identified inherent cloud problems but is unaware of how to solve them, the CSP analyses the customer’s security requirements and responds with the actual existing alternatives in their offerings. Ideally, the RfP reflects the strategy, short and long term requirements of the customer while seeking specific information, security offerings and particular items which the CSP is proposing. Generally, the contents of a CSP response represent the actual settings or state of their offerings, rather than a meagre attempt to beat competition from other vendors, which indeed generates transparency into how individual requirements are distinctly addressed. The advantage of the request-response driven approach is its ability to enable cloud users exclusively specifies their security requirements for assessment and the identification of suitable controls by the CSP. However, it could be argued that it has become a traditional practice for CSP’s to publish frequent solicitations 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 a valid written agreement between a
CSP and a customer where the provider observes complete disclosure of all essential security services strictly relevant to a particular cloud user while refraining from divulging information that could compromise the privacy of other customers. Service Level Agreements (SLAs) are useful tools widely used by both CSPs and their customers as a channel for ensuring transparency and establishing a common pact to manage the security requirements requested by a customer and the security levels being offered by a CSP, which becomes legally binding. Also, the SLA forms the basis for defining responsibilities and the remedies available for customers in case of a contract breach. The information contained in SLAs is usually broader in coverage than those found in proactive and reactive transparency schemes. The Fundamental aspects of the SLA are the representation of the contexts shared by the two actors, and how each actor utilises the contexts in its operations throughout the SLA lifecycle. In other words, the SLA provides a comprehensive description and transparent security processes for both the
43
CSP and customer to avoid uncertainty, apprehension and disputes. Conventional SLAs generally provide clarity on CSP service offers, unambiguous definition of expectations and obligations on both sides, and the boundaries of liability. Nevertheless, a notable limitation to this class of transparency is that essential security property of a customer may remain uncaptured. But despite this limitation, it still provides critical salient characteristics that support customer’s consideration for (i) security governance, legal and regulatory requirements, (ii) and allows customers to determine the impact of CSP offerings on business processes, including those changes required to enable the cloud services to be effectively useful to operate objectives.