Making Cloud SLAs readily usable in the EU private sector

Security Policies & SLAs

The usage of policies to manage the increasing complexity on the management of networks and systems comes from several decades ago [1]. Even the definition of languages to structure the information included in policies has also been widely studied from a very early stage [2].

More recently, due to the popularity of internet services and the increasing users’ concern on security and privacy issues (leveraged by the success of electronic commerce and payments, and social networks) security and privacy policies has also centre the attention of the research and industrial community.

Definitions of security policies

There exist different definitions of security policies. NIST defines a security policy [3] as an "Aggregate of directives, regulations, rules, and practices that prescribes how an organisation manages, protects, and distributes information", and according to (Diver, 2007) the purpose of security policy is to protect people and information, set rules for expected behaviour by users, define and authorise the consequences of violation, minimise risks and help to track compliances with current regulations. Høstland et al. [4] and Kadam [5] focus on the definition and creation of templates for security policies.

Depending on their application level, different security policies exist (such as Kannammal et al. [6], and Bronk [7] focussing on the network level). Depending on their purpose, the security policies can be specified at different level of abstraction e.g., at high level of abstraction - through modal logic formulas or a process algebra based language (Benjamin et al. [8]), or an automata based language (Aktug et al [9]). Such policies can be refined through adequate functions [10], in order to preserve security policy through all the degree of abstraction of the system (and language). Karadsheh [11] gives a detailed view of different types of security policies: depending on whether an enterprise information security policy (EISP) for organisational levels is considered, as defined by Whitman et al. [12], or an Issue-specific security policy (ISSP) for corporative services or system specific policies (SysSp) as in [13] by Swanson et al., etc.

Security policies in SLAs

Recent efforts have been devoted for including security policies in Service Level Agreements (security SLA or SecSLA). SLAs were typically considered in SoA architectures, such as WSLA [14] and WS-Agreement [15], as well as in cloud computing and grid computing such as by Henning [16]. In SPECS, security SLA is taken into account for the negotiation of security levels. Also Luna et al. [17] uses SecSLA as a basis to quantify security in cloud environments. SecSLA are also considered by the industry (Mohahan et al. [18] and Undheim et al. [19] and are adopted in the Web Service domain (Frankova et al. [20]). A set of good practices on modelling SLAs is provided by Feglar in [21]. SLAs provide a convenient way to handle the contents of security policies represented as security provisions (parameters).

Customers unawareness

ENISA’s survey [22] shows that currently many customers are unaware of the security aspects contracted with the provider and related to their services and do not control or monitor them. Often the SLAs consider only QoS (Quality of Service) related aspects and security aspects are less covered in spite of the existence of some approaches such as Bernsmed et al. [23]. The specification of security parameters in a security policy forces a provider to explicitly address security that can help cope with this problem.

Machine readable security policies

Another challenge is that security policies or SLAs are often represented in natural language (non-machine readable) which impedes their management by the provider. Furthermore, the format varies from one provider to other. To this end, organisations such as the CSA are trying to provide a common format for the security provisions to be included in security policies and Sec SLA, such as the STAR repository. This issue is also addressed in the researching academia by Zhengwei et al. [24] and Schilling [25]. Bernsmed [23] considers that SLAs can be modelled by a provider at the service level, normally based on either a set of expert-driven security requirements (e.g., for compliance reasons), or some kind of preliminary threat analysis. A machine-friendly approach that expresses the security provisions in the form {security attribute, value} (e.g., {Backup Frequency, Daily} is considered by industrial and academic works such as the ones described by Casola et al. [26], Luna et al. [27] and Taha et al. [28].

Krautsevich [29] also proposed adding security metrics to the agreement and provided a way to reason how well the service satisfies the security needs of the customer. Savola [30] and the CSA with the Cloud Control Matrix goes one step beyond by organising these security provisions into "categories" derived from a taxonomy. This set of security provisions – now organised into taxonomic categories – are easier to be automatically processed, combined in security SLA and managed by users and providers.

More recent research (Luna et al. [31]) improves these models by also including dependencies between provisions that may also affect the subsequent reasoning. Other activities such as the SLA@SOI project has created a language independent SLA language to add QoS guarantee and party obligations. The SLA@SOI model was adopted by Contrail by extending it to use a standard OVF descriptor to specify IaaS resources. In OPTIMIS the activities were focused on the management of SLAs between infrastructure and service providers. To this end OPTIMIS created a machine readable language based on WS-Agreement and WS-Agreement Negotiation. Finally, 4CaaSt created a description language to capture service dependencies across cloud layers.

 

[1] European Commission, Cloud Service Level Agreement Standardisation Guidelines (C-SIG SLA 2014). Brussels, 2014.

[2] T. Koch, C. Krell, and B. Krämer, "Policy definition language for automated management of distributed systems," In Proceedings of Second IEEE International Workshop on Systems Management, 1996, pp. 55-64.

[3] National Institute of Standards and Technology, Guide for developing security plans for federal information systems, vol. 800-18. Gaithersburg, MD: US Dept. of Commerce, 2006.

[4] K. Høstland, P. A. Enstad, Ø. Eilertsen and, Gunnar Bøe. "Information Security Policy. Best Practice Document," UNINETT led working group on security (No UFS126). 2010.

[5] AW. Kadam, "Information security policy development and implementation," Journal Information Systems Security, vol. 16, no. 5, pp. 246-256, 2007.

[6] A. Kannammal and N.Ch.S.N. Iyengar, "A model for mobile agent security in ebusiness applications," International Journal of Business and Information, vol. 2, no. 2, pp. 185-198, 2007.

[7] C. Bronk, "Hacking the nation-state: security, information technology and policies of assurance," Information Security Journal: A Global Perspective, vol. 17, no. 3, pp. 132-142, 2008.

[8] A. Benjamin, et al., "Controlling usage in business process workflows through finegrained security policies," Springer Trust, Privacy and Security in Digital Business, vol. 5185, pp. 100-117, 2008.

[9] I. Aktug and K. Naliuka, "ConSpec: A Formal Language for Policy Specification," In Run Time Enforcement for Mobile and Distributed Systems (REM’07), 2007.

[10] F. Martinelli and I. Matteucci, "Idea: Action Refinement for Security Properties Enforcement," In Proc. of Engineering Secure Software and Systems, (ESSoS), 2009, pp. 37-42.

[11] L. Karadsheh and S. Alhawari, "Applying security policies in small business utilising cloud computing technologies," International Journal of Cloud Applications and Computing, vol. 1, no 2, pp. 29-40, 2012.

[12] M. Whitman and H. Mattord, "Principles of information security," 3rd ed. Course Technology, Boston, 2009.

[13] National Institute of Standards and Technology, U.S. Department of Commerce, M. Swanson and B. Guttman, "Generally accepted principles and practices for securing information technology systems," 1996

[14] H. Ludwig, A. Keller, A. Dan, R.P. King, and R. Franck, "Web Service Level Agreement (WSLA) Language Specification," Tech. Report wsla-2003/01/28, IBM, 2003.

[15] K. Andrieux, A. Czajkowski, K. Dan, H. Keahey, T. Ludwig, J. Nakata, J. Pruyne, S. Rofrano, M. Tuecke, and M. Xu, "Web Services Agreement Specification (WS-Agreement)," Open Grid Forum, 2007.

[16] R. Henning, "Security Service Level Agreement: Quantifiable Security for the Enterprise?," In Proc. of the New Security Paradigms Workshop (NSPW 1999), 1999.

[17] J. Luna, R. Langenberg, N. Suri, "Benchmarking cloud security level agreements using quantitative policy trees," ACM Workshop on Cloud computing security workshop, pp. 103-112, 2012

[18] B. Monahan and M. Yearworth, "Meaningful Security SLAs," Technical Report. HP Laboratories, 2008.

[19] A. Undheim, K. Bernsmed, and M.G. Jaatun, "Security in Service Level Agreements for Cloud Computing". 1st International Conference on Cloud Computing and Services Science, pp. 636-642, 2011.

[20] G. Frankova and A. Yautsiukhin, "Service and protection level agreements for business processes," In The 2nd European Young Researchers Workshop on Service Oriented Computing, 2007.

[21] T. Feglar, "ITIL Based Service Level Management if SLAs Cover Security," Journal of Systemics, Cybernetics and Informatics, vol. 3, no. 4, pp. 61-71, 2003.

[22] M. Dekker and G. Hogben. "Survey and analysis of security parameters in cloud SLAs across the European public sector". Tech. Report TR-2011-12-19, European Network and Information Security Agency, 2011.

[23] K. Bernsmed, M.G. Jaatun, P.H. Meland, A. Undheim, "Security SLAs for Federated Cloud Services," In Proc. of the 6th International Conference on Availability, Reliability, and Security (ARES 2011), 2011.

[24] J. Zhengwei et al. "A Meta-Synthesis Approach for Cloud Service Provider D2.2 Requirements emerging from a state-of-the-art analysis – Final Report Page 91 Selection Based on SecSLA," Fifth International Conference on Computational and Information Sciences (ICCIS), 2013, pp. 1356 – 1360.

[25] A. Schilling, "A Quantitative Threat Modelling Approach to Maximize the Return on Security Investment in Cloud Computing," in Proceedings of the 1st International Conference on Cloud Security Management (ICCSM’13), 2013, pp. 68-78

[26] V. Casola, et.al. "A SLA evaluation methodology in Service Oriented Architectures,"Quality of Protection of Springer Advances in Information Security, vol. 23, pp. 119 – 130, 2006.

[27] J. Luna, H. Ghani, D. Germanus, and N. Suri, "A security Metrics Framework for the Cloud," in Proc. of the 6th International Conference on Security and Cryptography (SECRYPT 2011), 2011, pp. 245-250.

[28] A. Taha, R. Trapero, J. Luna, and N. Suri, "AHP-based quantitative approach for assessing and comparing cloud security," in Proc. IEEE Conf. Trust, Security Privacy Comput. Commun., 2014, pp. 284–291.

[29] L. Krautsevich, F. Martinelli, and A. Yautsiukhin. "Formal analysis of security metrics and risk," in Information Security Theory and Practice. Security and Privacy of Mobile Devices in Wireless Communication, pp. 304-319, 2011.

[30] R.M. Savola, "On the Feasibility of Utilizing Security Metrics in SoftwareIntensive Systems," in International Journal of Computer Science and Network Security (IJCSNS), vol. 10, no. 1, pp. 230-239, 2010.

[31] J. Luna, et.al. "Quantitative Assessment of Cloud Security Level Agreements: A Case Study,". In Proc. of Security and Cryptography, pp. 64-73, 2012.