Today the trend for commodity cloud adoption is on the increase. The tidal wave of public cloud uptake can perhaps be explained by the perceived ease of customer deployment convenience over on premise systems.
Cloud service providers (CSP) are now so well established that they can deliver capacity which enables their multi-tenant solutions to scale quickly and operate effectively - all charged at a fraction of the cost for customers to build their own information technology.
At the dawn of the internet of things era it is now possible to perform data insights and analytics using cloud back-ends. Corporations who have vast swathes of data can use cloud for data ingestion, pre-processing, queuing, transposition, and post-processing regimes1 - by using a combination of service offerings.
Fuelled by a quantifiable leap in bandwidth, cloud acceptance has occurred against a backdrop of underlying concerns over: (a) the trade-off between performance and a lesser ability to customise infrastructure versus data security, and (b) sovereignty of logically-abstracted infrastructure owned and operated by third-party CSPs’.
Background
Since the inception of Google online productivity apps in 2006, the concept of software-as-a-service (SaaS) has been adopted in various ways by many CSPs. Infrastructure-as-a-service (IaaS) derivations soon followed suit emerging from utility computing pedigrees.
Logical abstraction2 encouraged CSP tool provisioning and services through the platform-as-a-service (PaaS) model. Amazon Web Services (AWS) Elastic Compute Cloud and Simple Storage Service (S3) are an example of IaaS and Google App Engine or AWS Elastic Beanstalk of PaaS.
Cloud 1.0 generation service models can be operated through several cloud formations ranging from public, community, private and hybrid variants. Public cloud provides a service where numerous customers coexist together in a segregated manner on a shared multi-tenant environment3 accessible from the internet.
Today’s technology has recently driven network abstraction through micro-segmentation, the adoption of application containerisation and micro-services to develop server-less web applications. Usefully CSPs can provide multiple availability zones both within in-country regions or between regions for resilience purposes.
Cloud standards
Comprehending cloud security can be difficult because the data centre and infrastructure are outside the customers’ sphere of influence. Recent enhancements to the International Standards Organisation (ISO) 27K series better defines security controls for both cloud computing and personally identifiable information in public clouds - entitled ISO27017:20154 and ISO27018:20145 respectively.
Certifications based on these standards certainly enable cloud customers to gauge a CSP’s credibility and trust profile bounded within the scope of the CSPs’ information security management system and the service level agreements. Out of the big four public - Google, AWS, Microsoft Azure and Rackspace - the first three have been certificated against these new standards and all four continue to be assessed against ISO27001:2013.
Cloud computing works as a ‘shared security responsibility’ between the CSP - once due diligence is undertaken by the customer to assess trust in them - and the customer to allay the risks associated with their cloud instantiations. The security obligations upon each varies depending on the cloud service model utilised. Therefore, each CSP’s security profile should be understood before customers embark on the journey of cloud utilisation.
Cloud security conundrum
Over progressive years the European Union Agency for Network and Information Security (ENISA) has issued warnings based on real-life case-studies summarised as: (a) external threats such as distributed denial-of-service (DDoS), (b) malware incursions or web application injection attacks, and (c) insider threats from either the CSP or from the customer user-base causing information leakage6.
This implies that customers may not necessarily understand the full facts, the associated risks to their data from multi-dimensional threat actor contexts or the potential consequences of using cloud services.
CSPs can only provide infrastructure security up to a certain level in the hardware and software stack; approaches should include countermeasures such as hypervisor logging and tenant isolation. In PaaS, less obvious application container risks should be considered where, depending on the technology, different multi-customer applications may share the same host operating system kernel without application isolation7.
Customers who utilise cloud services must ensure they do not make themselves unnecessarily vulnerable; therefore, they must be technologically savvy to choose the right cloud formation for their risk appetite and be prepared to supplement requisite controls over those of the CSP deemed necessary to protect their data.
Implications of getting it wrong
That said, CSP’s themselves are not infallible:
- If un-patched, 2015’s Virtualised Environment Neglected Operations Manipulation (VENOM) vulnerability might have enabled a remote attacker to breakout from a Xen or Kernel-Virtual-Machine virtual machines (VM) into the hypervisor8.
- Dropbox and Google had been susceptible to account compromises that appeared to be the fault of the CSPs between 2012 and 20159.
- Operation Cloud Hopper advanced and persistent threat attacks of 2016 and 2017 were conducted to compromise global managed internet service providers and CSPs to move laterally and undertake targeted data exfiltration10.
- In addition to the 2008 S3 outage, the AWS storage outage of 2017 was allegedly caused by an administrator’s mistyped command11.
Cloud appears to harbour a false sense of security and foster customer security mitigation omissions even though CSPs publicly provide recommended configuration or guidance - recent ‘big data’ cloud agnostic oversights are as follows:
- In 2013, some AWS customers were found to be negligent in their configurations exposing S3 buckets to the internet - thereby putting their data at risk12.
- In 2014, due to a lack of robust AWS credentials the CodeSpaces supplier was attacked; first through a DDoS attack as a prelude to gaining a foothold and escalating privileges - this resulted in code assets and backups being deleted thus making them go out of business13.
- Inadequate consumer password constitution and lack of two-factor authentication (2FA) adoption enabled iCloud accounts to be compromised in 2015.
- Between 2015 and 2017, 1.1 terabytes of data were found unsecured in S314 including US republican voter records.
- In 2017, up to 5 petabytes of accessible data from online databases was identified - this leakware includes customers of Google and AWS cloud instances15.
- A US contractor exposed US Government data and ludicrously Secure Shell keys through AWS S3 bucket16 misconfiguration in 2017.
New cybersecurity perspective
According to Netwrix17, in 2016 68 per cent of organisations were more likely to use cloud compared to 43 per cent in the previous year; but 70 per cent of organisations were concerned about security and data privacy compared to 63 per cent in 2015.
A worrisome prediction by Gartner is that by 2020 95 per cent of cloud security failures will be the customer’s fault18. Therefore, customers and consumers need to be more threat-aware and detract away from the myth that the CSPs provide the entirety of security measures for them - they must understand their part of the ‘shared responsibility’!
At one end of the cloud model scale with IaaS the main precepts of cloud security can now be categorised as:
(a) cloud console credentials / control groups and credential management;
(b) identity verification and robust authentication and key management;
(c) edge rules and soft-security appliance and VM-borne soft-firewalls;
(d) network zoning and network access-control lists;
(e) instance access control - user groups / privileges;
(f) encryption - data-in-transit and at-rest;
(g) log reviews and monitoring;
(h) guest server patch management;
(i) instance, VM guest and storage configuration control;
(j) backup and recovery regimes; and
(k) post instance utilisation data sanitisation.
At the other extreme in SaaS, the consumer is restricted to implementing basic access control, such as username and passwords, but should also consider setting up out-of-band 2FA verification.
A paradigm shift is required to represent cloud security risk adequately to avoid customer control-set selection ambiguities - especially with hybrid cloud use-cases. An inability to be cloud proficient just increases the attack surface from the asymmetric cyber threat.
Our transformation towards Cloud 2.019 presents an opportunity, to rethink enterprise architecture20 as cloud native from the outset, combined with increasingly progressive machine-learning intelligence. Therefore, logic presupposes that cybersecurity approaches also needs re-evaluating.
