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.