Is cloud risk management a done job once a business has migrated into the cloud?
Aside from cost and the ability to upscale, one of the most compelling cases for a business to move to the cloud is security. Cloud service providers (CSPs) have the scale and resources necessary for the implementation of robust cyber-security systems, quick threat detection and effective incident response, so the argument goes.
A recent security breach of Microsoft Exchange Servers demonstrates rather convincingly the enormous threats potentially lurking behind on-premises software. The perpetrators, most likely hacker group Hafnium, supposedly financed by the Chinese state, first gained access to the servers either via stolen passwords or – taking advantage of vulnerabilities – disguising themselves as someone who has access.
The hackers then created a so-called web shell, a small piece of malicious code implanted on web servers to provide themselves with remote access and control to the server from a web browser. As this breach is unfolding practically in front of cyber-security experts’ eyes, the full extent of the damage is still hard to assess. What is certain is that the perpetrators have exfiltrated strategic data from infectious disease researchers, defence contractors and institutions of higher education, among others.
For many businesses, the attack by Hafnium serves as a wake-up call to finally move their servers from on-premises into the cloud – a decision that may not have made business sense up until a few years ago, but which – in the light of increasing risks of getting hacked – does now.
But rather than a remedy, the move to the cloud was a cause for trouble in the case of American bank Capital One. News of the company having moved all its operations into the AWS public cloud came in November 2020. The migration process took eight years to complete and suffered a major setback in 2019. In this case, no hacker groups were involved. A former AWS employee, allegedly without any insider knowledge, single-handedly found a vulnerability on Capital One’s firewall protecting access passwords and got hold of a treasure trove of personal data belonging to the bank’s 106 million
Misconfiguration and IAM flaws
The incident is a textbook case of what may go wrong with cloud deployments when a CSP’s customers don’t have continuous visibility and control of their operation in the cloud.
As uptake grows, the cloud is becoming an increasingly complex environment, where configuration ensures that all the assets a business has deployed operate securely and at an optimum level.
Misconfigurations, such as default passwords, out-of-use and forgotten about apps and excessive access permissions, are all conduits to hacks and breaches. It was the open-source misconfigured Capital One application firewall that the hacker exploited to steal critical passwords. The next point of failure was that the web application firewall (WAF) had excess privileges that it was never meant to, thus enabling the hacker to access data and exfiltrate information.
Capital One conceded that it was responsible for the breach, while AWS insisted that its underlying cloud technology played no part in the incident. But as Raef Meeuwisse, cyber-security expert and writer points out, “root cause analysis of widely-known cyber-security losses has repeatedly shown that mega-breaches can only occur when three or more critical or major security controls that should be in place are either missing or inadequate.”
Server-side request forgery (SSRF)
Although it hasn’t made it yet to the Top 10 OWASP Web Application Security Risks, SSRF flashes up ever more frequently on cyber-security experts’ radar, and has played a role in both the Capital One and the Microsoft incident. Relying on SSRF, the hacker could abuse the functionality of Capital One’s application server, getting it to access and clone information (security credentials) in the server’s realm, which they directly wouldn’t have been able to. In other words, the hacker’s external request for sensitive personal data was manipulated so it resembled an authorised internal request coming from the local machine itself.
SSRF had already been a well-known vulnerability before the Capital One incident. Andy Wyatt, security expert and writer, has labelled it an AWS feature, not a bug, in the wake of the breach. Although Microsoft and Google had already integrated protections against SSRF into their products in 2018, Amazon only followed suit in November 2019, when it released IMDSv2, protecting every request with session authentication.
Data breaches and other cyber-security incidents have been putting pressure on CSPs to build extra layers of security and thus increase the depth of defence even in areas which contractually come under the cloud service user’s responsibility. How security responsibilities are shared varies with the different cloud service models, but as a rule of thumb, the CSP is responsible for the security of the cloud (whether a physical data centre, physical and perimeter network or virtualisation platform), while the user is always accountable for what is in the cloud, such as data, accounts, and identities, as well as for its devices. The responsibility for what lies between the two, such as applications and network controls, seem to result in the most finger-pointing in IaaS and PaaS arrangements.
Less splitting and more sharing of responsibility
There is a common perception that the way responsibilities are divided by CSPs and their customers is better described by splitting than sharing. On the other hand, even where providers go the extra mile and send alerts when detecting misconfigurations or gaps in firewalls, notifications often go unnoticed or ignored, while monitoring solutions fail to get enabled.
Automation and the use of AI may have the potential to square the circle. There are several start-ups, some of them already unicorns, whose business models are based on offering misconfiguration services, while others provide deeper visibility into cloud assets and their security posture. Paying for these services will naturally ramp up the costs of cloud deployments. But given the findings of Unit 42’s Cloud Threat Report, published in January 2021, that 65 per cent of all cloud security incidents are the result of customer misconfigurations, it’s money well spent.
As the problem doesn’t look like disappearing any time soon, CSPs, with vested interest in cloud security and uptake, may shortly try and integrate an automated multi-level misconfiguration detection service into their offerings. Until then, cloud service users need to keep reminding themselves that the public cloud is not safe by definition, and that cloud security is a dynamic and ongoing exercise.