6 Top Cloud Security Problems – from a GRC consultant’s perspective

The typical life of a consultant working in the field of governance, risk and compliance is often not deeply technical, but we have to be aware of new technology and the risks it poses; this is very true when it comes to Cloud, and with the massive adoption of Cloud as the vast majority of organizations now use cloud services on some level.

We often take a broad overview informed by studying the details, and to help get the whole picture at a granular level on Cloud we’re increasingly looking at the results from penetration testing. But great as pen test reports are at letting you know where you have a specific problem, on their own these tests don’t address how different security controls are or are not interacting and supporting each other.

In this post, I’m going to look at six of the top Cloud testing findings Trustwave regularly sees and how these might have a deeper impact on your security stance

1. User Access Control

Access control is top of the list for vulnerabilities. We often find poor password policies, default credentials for an admin interface being left in place and even root accounts not using MFA.

These crop up continuously and there’s rarely a good explanation as to why or mitigating controls in place. Sometimes this is linked to Shadow IT (see below) but not always, and when it’s not, the issue can be from an organization’s lack of understanding as to how to secure the account or what privileges the account has, or even if implementation has been designed for a publicly accessible service which has influenced the control.

This makes no sense when you consider threats can come from inside, as well as, outside your organization. Having such a vulnerability in place can generally be tied to poor access control procedures, the mistaken belief in the strength of single factor authentication, possibly a lack of change control and sometimes poor development practices.

2. Shadow IT

One big advantage of Cloud is the ability to create new functioning systems and applications with increased flexibility, cost effectiveness, speed, and almost unlimited size, but potentially at the cost of control and security.

Allowing your developers to spin up whatever they need makes your IT team’s life a lot easier but there’s a strong likelihood these systems will not be properly secured, may store data it shouldn’t and could be left running after they’re no longer required. One way to address this is to have an effective change management process together with a setup management policy (look at Azure Blueprints, for example).

Again, poor infrastructure and change management could be at the root of this problem, exacerbated by the likelihood monitoring is not fully in place and data might be unnecessarily exposed.

Ouch. This issue is one that comes up all the time. From unsecured storage buckets to a lack of logical separation between customer information, data storage is a security issue with a range of causes. Similar to but almost opposite to the “cloud is public” access control issue, very often there’s been a failure to recognize cloud requires additional controls to be secured as not everything should be public. Another cause is failure to understand that backend access is as open as frontend access. And then there’s that Shadow IT problem again as the easiest route to creating extra storage is to use the Cloud.

Behind many of these causes lies the misconception, to some extent, that Cloud is an extension of your on-premises infrastructure. As you know, depending on the Cloud model you’re using – private, public, hybrid - this may not be true. The problem is magnified when using multiple Cloud providers who will have different default configurations. If you’re not seeing and understanding this infrastructure for what it is, what else are you getting wrong?

4. API connectivity

Applications and the data Application Programming Interfaces process are dispersed and separated, often APIs are used to enable apps to interact. But APIs should be authenticated and ignoring this little requirement can lead to big problems. An API cannot type in a password or a code, so how does it authenticate?

The lazy way is hardcoded credentials. Yes, you heard me correctly. There are APIs out there authenticating with an immutable password written in cleartext. To quote OWASP:

”If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.” There are various solutions to this problem, many of which are easy to implement. Furthermore, where applications share code and APIs, a hardcoded password can act like a skeleton key to many, if not all, of your secure assets. This is a red flag to your secure code development process and application testing regime.

5. Code Repository Security

If you’ve not heard of GitHub, you must’ve been asleep for the last 10 years. It is a hosting provider for software development and version control, with a range of source code management functionality available. It is also a platform where over 83 million developers can share their code. The return on time and resources when your organization can reuse code developed by others is staggering, hence the success of GitHub. But is this code secure?

GitHub itself provides tools to check code for vulnerabilities but the question to ask is whether you have any assurance those checks have been completed and problems fixed? Even if the code itself is secure, another common issue we find is failure to secure or use private repositories, making your code accessible and potentially modifiable to all.

Again, this should be part of your secure code development process.

Another worrying aspect of code reuse is should widely used code, such as Log4j, to name one we’re all familiar with, be vulnerable are you aware of where you’re using it? A robust system of secure code development, code manifests and the correct use of solutions like CI/CD can reduce the risks, although be aware increased automation can lead to missed opportunities to spot security holes.

6. Container security

Containers are so neat: they take the idea of virtual machines and extend it; VMs share physical components, containers share virtual components of the underlying operating system. With containers you can create, duplicate, and run applications with control and at speed, moreover, they are completely portable so you can spin them up, split out your workloads and migrate them, making scalability so much easier. Managing many containers becomes an issue but container orchestration systems, such as Kubernetes, are available.

The very things which make containers and container orchestration so useful also lead to security issues: layers of separate software all requiring regular updates and all needing to communicate with each other creates an environment which cries out for strict network access controls, API authentication, traffic encryption, differing access restrictions, and strong protection of the management console. Not all these controls are in place by default and failure to properly implement just one could leave your data and systems exposed.

A Final Takeaway

I call it the ant’s nest problem – how to understand and coordinate multiple entities who are independent but need to act together.

Cloud has introduced us to the shared responsibility model but the thing with sharing is it can introduce gaps and misunderstandings.

This is compounded by the layers of management control, from Cloud infrastructure to users to code repositories to orchestration and containers and more. Applying security as a point solution is no longer sufficient, instead security must overlay the entire process, with each element connected, interoperating, monitored, and managed; as data flows seamlessly from one operation to the next, security must also flow seamlessly from one stage to another.

The technology our businesses now all rely upon is changing and evolving at an ever-increasing pace, this requires a holistic view of security using up to date knowledge, skills and understanding.

Organization’s must invest in training your technical staff and at the same time provide labs where ideas can be tested, and a staff can learn and gain better understanding – without exposing critical data. Embed your security staff into your IT operations to foster knowledge transfer and better cooperation. Monitor and test all your security controls to ensure they’re working together and interface seamlessly. Cloud is taking us into a brave new world, don’t let disjointed and fragmented security lead to failure when you arrive.