Cloud computing security is an evolving sub-domain of information security and refers to a broad set of policies, technologies, and controls deployed to protect data, applications, and the associated infrastructure [[i]]. There are a number of security concerns associated with cloud computing, which can be broadly classified in two categories: (a) issues faced by Cloud Service Providers (CSPs) and (b) issues faced by their customers. Providers must ensure that their infrastructure is secure and clients’ data and applications are protected; customers, on the other hand, must ensure that their provider has taken appropriate security measures to protect their information. The security expectations and obligations of both supplier and user are described in Service Level Agreements (SLAs) [[ii]].
Organisations need to understand the specific security requirements, regarding data protection, audits, etc., and any regulations that are applicable to a particular application that they are looking to move to the cloud. To achieve this, they should map every application that is a candidate for migration to cloud computing to a set of security, governance, and compliance issues that are specific to that application. Thus, they have the ability to understand the application requirements, and how the migration and re-development effort to the cloud should impact application operations.
The UK’s National Technical Authority for Information Assurance, which provides advice on Information Assurance Architecture and cyber-security to UK government and the wider public sector and suppliers to UK government, published 14 security principles to consider when evaluating cloud services, and why these may be important to an organisation [[iii]].
|Cloud Security Principle||Description|
|1. Data in transit protection||Consumer data transiting networks should be adequately protected against tampering and eavesdropping via a combination of network protection and encryption.|
|2. Asset protection and resilience||Consumer data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.|
|3. Separation between consumers||Separation should exist between different consumers of the service to prevent one malicious or compromised consumer from affecting the service or data of another.|
|4. Governance framework||The service provider should have a security governance framework that coordinates and directs their overall approach to the management of the service and information within it.|
|5. Operational security||The service provider should have processes and procedures in place to ensure the operational security of the service.|
|6. Personnel security||Service provider staff should be subject to personnel security screening and security education for their role.|
|7. Secure development||Services should be designed and developed to identify and mitigate threats to their security.|
|8. Supply chain security||The service provider should ensure that its supply chain satisfactorily supports all of the security principles that the service claims to implement.|
|9. Secure consumer management||Consumers should be provided with the tools required to help them securely manage their service.|
|10. Identity and authentication||Access to all service interfaces (for consumers and providers) should be constrained to authenticated and authorised individuals.|
|11. External interface protection||All external or less trusted interfaces of the service should be identified and have appropriate protections to defend against attacks through them.|
|12. Secure service administration||The methods used by the service provider’s administrators to manage the operational service should be designed to mitigate any risk of exploitation that could undermine the security of the service.|
|13. Audit information provision to consumers||Consumers should be provided with the audit records they need to monitor access to their service and the data held within it.|
|14. Secure use of the service by the consumer||Consumers have certain responsibilities when using a cloud service in order for this use to remain secure, and for their data to be adequately protected.|
Consumers of cloud services should decide which of the principles are important, and how much assurance they require in the implementation of these principles, while providers of cloud services should consider these principles when presenting their offerings to public sector consumers. This will allow consumers to make informed choices about which services are appropriate for their needs.
The STORM CLOUDS approach
In order to achieve a clear understanding of the security requirements of both the SCP and the Smart City applications, the following vulnerability scanning tools were used to scan web applications to look for known security vulnerabilities:
- Zed Attack Proxy (ZAP), an easy to use integrated web applications vulnerability scanning tool;
- OpenVAS, a framework of several services and tools offering a comprehensive and powerful vulnerability scanning and vulnerability management solution;
- SQL Inject Me, a Firefox Extension used to test for SQL Injection vulnerabilities;
- Qualys SSL Server Test, an online service performing deep analysis of the configuration of any SSL web server on the public Internet;
- Vega, an open source scanner and testing platform to test the security of web applications.
The security testing identified a number of critical security issues resulting in applications’ modifications in order to address them. In particular, the following issues were fixed:
- “Directory listing” security risk, whereby an attacker can simply list directories to find files. To address it we have updated the Apache configuration file by removing the Indexes from the file.
- “Insufficient Transport Layer Protection” security risk, caused by not requiring SSL (at least for all sensitive pages) allowing an attacker that monitors our network traffic to obtain an authenticated victim’s session cookie, itself then replayed to take over the user’s session. To address it we have included an HTTPS certificate and requested that all traffic is forwarded to the secure connection (HTTPS). However, new vulnerabilities introduced by the HTTPS certificate, such as the RC4 cipher and the POODLE attack vulnerability, resulted in the disabling of:
- TLS 1.0 compression and weak ciphers
- SSL 3 in our browser and our servers
- “Clickjacking” security risk, caused by an attacker that is “hijacking” our clicks meant for the application page and routing them to another malicious page. To address it we send proper X-Frame-Options HTTP response headers that instruct the browser to not allow framing from other domains. This is done at the Apache configuration file.
Regarding the use of the above-mentioned tools, one should always check the terms of service of the selected CSP to determine whether running security tests on the CSP infrastructure is allowed, even if own machines are the target. If this is not so, either a CSP that allows penetration tests on own VMs must be chosen, or have tests run on a development or testing environment before deployment to the production environment.
In order to enhance the authentication process, applications have been updated to support session expiration, thus minimizing the time available to an attacker who uses a valid session identifier. In order to balance between security and usability, applications have properly selected the timeout values, allowing users to complete their operations without frequent session expirations.
The acquisition of an HTTPS certificate was necessary for the protection of data in motion for Smart City Applications. The Apache server was configured to forward all traffic to the secure connection. However, as applications don’t deal with sensitive data no encryption is applied for data at rest, apart from the OpenStack object storage that is protected using LUKS (Linux Unified Key Setup or LUKS is the standard for Linux hard disk encryption).
Virtualization technologies have their own vulnerabilities such as those coming from the virtual switch, those coming from reallocation of resources from one VM to another and vulnerabilities coming from the remote administration port that is turned on by default on all VMs. To respectively address these attack vectors:
- We’ve used layered security mechanisms to increase the security of the system as a whole. This was achieved using OpenStack security groups in order to define a number of IP firewalling rules that describe what kind of network traffic is allowed to go to or come from the VMs. With this solution even if a VM is compromised the security group rules continue providing the required level of security because they are implemented in the host operating system.
- We’ve used OpenStack functionality for zeroing all data used by a virtual resource once the resource is released.
- We associated each VM with a valid SSH Keypair. This was then forwarded to the application owners in order to allow them to access the VM instances given the public IP address the VM is configured to use.
Finally, securing our cloud infrastructure means not only implementing controls for the layers we are able to do so, but also auditing our CSP regarding the actions were taken to lock-down the tenant instances. We must conduct our own analysis of our needs, and assess, select, engage and oversee the cloud services that can best fulfill those needs.
[ii] Giannakoulias A, Cloud Computing Security: Protecting Cloud-Based Smart City Applications, Applications in Smart Cities and Cloud Computing Special Issue, Journal of Smart Cities (submitted)
[iii] Cloud Security Guidance: Summary of Cloud Security Principles, viewed June 24, 2016 <http://goo.gl/mUf5c2>