Quantitative Reasoning About Cloud Security UsingService Level Agreements
ABSTRACT
Cloud security the economic and technological advantages of Cloud computing are apparent, its overall uptake has been limited, in part, due to thelack of security assurance and transparency on the Cloud Service Provider (CSP). Although, the recent efforts on specification of security usingService Level Agreements, also known as “Security Level Agreements” or secSLAs is a positive development multiple technical and usability issueslimit the adoption of Cloud secSLA’s in practice. In this paper we develop two evaluation techniques, namely QPT and QHP, for conducting thequantitative assessment and analysis of the secSLA based security level provided by CSPs with respect to a set of Cloud Customer securityrequirements. These proposed techniques help improve the security requirements specifications by introducing a flexible and simple methodology thatallows Customers to identify and represent their specific security needs. Apart from detailing guidance on the standalone and collective use of QPTand QHP, these techniques are validated using two use case scenarios and a prototype, leveraging actual real-world CSP secSLA data derived fromthe Cloud Security Alliance’s Security, Trust and Assurance Registry.
EXISTING SYSTEM:.
Multiple approaches are emerging to assess the functionality and security of CSPs. the authors proposed a framework tocompare different Cloud providers across performance indicators. an Analytic Hierarchy Process based ranking techniquethat utilizes performance data to measure various Qualityof Service attributes and evaluates the relative ranking ofCSP’s was proposed. a framework of critical characteristicsand measures that enable comparison of Cloud servicesis also presented. However, these studies focused on assessingperformance of Cloud services, but not their security properties. In order to develop the full context on the value of secSLAs forsecurity quantification, we present the rationale on SLA usagealong with the basic SLA terminology needed to present the contributions of this paper The discussion presented inthis paper is based on the Cloud secSLA terminology and structurepresented on the latest version of the relevant
standard . At the time of writing that standardwas still on a draft format, although its terminology and generalsecurity components were already stable. Contracts and Service Level Agreements are key componentsdefining Cloud services. According to the ETSI CloudStandards Coordination group, SLAs should facilitate Cloud Customers in understanding what is being claimed for the Cloud service, and relate such claims to their requirements.
PROPOSED SYSTEM:
Customers are allowed to specify theirrequirements and assign their priorities at varied levelsof the hierarchical representation in order to obtain therequired secSLAs. Both requirements and priorities areentered by customers in compliance with the descriptionpresented. Once the CSP has uploaded its information10to CSA STAR it can be retrieved view Manager. Afterwards, this report is used to manuallycreate the corresponding CSP secSLA and store it intoa trusted secLA Repository via the secSLA Management module. This module is also used to update,delete and modify stored Cloud secSLAs.This database stores the secSLAsused by the dashboard in easy to use origanal format.Also as future work, we will integrate a set of protocoladapters to automatically insert/retrieve data from thesecSLA Repository from multiple sources adaptor to download the secSLA from the CSP website. module retrieves, from thesecSLA Repository, the Cloud secSLAs to benchmarkwith respect to the user-defined security requirement.Based on the customer preferences, the evaluation cantake place with either QPT or QHP, depending on therequired functionalityTheobtained results are visualized. CSPs have the possibilityto analyse their secSLAs and update their secSLAs stored in therepository using the CSP management module
MODULE DESCRIPTION:
1. User.
2. Respository.
3. Evaluation.
4. Cloud Security.
5. Security Service Level Agreements.
1. User.
User registration after login to after file upload Users areallowed to specify theirrequirements and assign their priorities at varied levelsof the hierarchical representation in order to obtain therequired secSLAs. Both requirements and priorities are entered by customers in compliance with the descriptionpresented
2.Respository.
Respository registration after login to different documents view and query for different documents reporty for suggestion for update,delete,modifyAfterwards, this report is used to manuallycreate the corresponding CSP secSLA and store it intoa trusted secLA Repository via the secSLA Managementmodule.
3. Evaluation.
Module retrieves, from thesecSLA Repository, the Cloud secSLAs to benchmark with respect to the user-defined security requirement.Based on the customer preferences, the evaluation can
take place with either QPT or QHP, depending on therequired functionality . Theobtained results are visualized bar chart CSPs have the possibility to analyse their secSLAs to better fulfil the Customers
requirements and update their secSLAs stored in therepository using the CSP management module.
4. Cloud Security.
When an organization elects to store data or host applications on the public cloud, it loses its ability to have physical access to the servers hosting its information. As a result, potentially business sensitive and confidential data is at risk from insider attacks. According to a recent Cloud Security Alliance Report, insider attacks are the third biggest threat in cloud computing.Therefore, Cloud Service providers must ensure that thorough background checks are conducted for employees who have physical access to the servers in the data center. Additionally, data centers must be frequently monitored for suspicious activity.
5.Security Service Level Agreements.
Enterprises employ security SLAs in their outsourced contracts, imposing such requirements for scanning service providers' networks for vulnerabilities, patching and change management expectations and checking periodically for quality control. Before you say corporate security policies already cover such matters, consider increasingly, enterprises are using SLAs as a means of codifying the process defined by their security policies. Let's look at how SLAs can be applied in practical terms.
Scope:
1) hierarchy structure
2) weights assignment
3) pairwise comparison
4) attributes aggregation to give theoverall rank calculation.
Problem Statement:
high number ofindividual security SLOs and that Customers might specify theirrequirements with different levels of granularity, the challengeis not only how to quantify different metrics associated to theseSLOs, but also to aggregate them in a meaningful way. To solvethese challenges, QHP’s ranking mechanism is based on AHPfor solving Multiple Criteria Decision Making .
CONCLUSION:
Security evaluationtechniques quantitatively assess thesecurity level provided by Cloud secSLAs. The proposed extensionswere designed based on the specifics of secSLAs as definedby state of the art works and standardisation bodies.Furthermore, both QPT and QHP were empirically validated through a couple of casestudies using real-world CSP data obtained from theCloud Security Alliance. The validation experiments were usefulto highlight the advantages and limitations of these techniques,and provided an objective comparison of both QPT and QHP in order to guide adopters. prototype of a decision-making security dashboard that implementsthe discussed evaluation techniques, to allow customersvisually comparing CSPs based on their offered secSLAs.As future work, we plan extensions to QPT and QHP in order
to implement advanced security metrics/Cloud secSLA notionsuncertainty, end-to-end security evaluation (CSP composition),and dependencies within secSLAs elements The lack of real-world information needed to empirically validate these advancednotions will become an important challenge to overcome through the CSP community of the Cloud Security Alliance.Because secSLAs are concrete mechanisms to improve securityassurance and transparency in Cloud systems, our belief isthat their quantitative assessment will provide a critical elementto drive the development of customersduring the whole Cloud service life-cycle.