Quisque actraqum nunc no dolor sit ametaugue dolor. Lorem ipsum dolor sit amet, consyect etur adipiscing elit.
Quisque actraqum nunc no dolor sit ametaugue dolor. Lorem ipsum dolor sit amet, consyect etur adipiscing elit.
We are coming to the end of 2021, and it is a good time to look at the state of cloud security. Several events this year have again highlighted the importance for an increased focus on one’s cloud security posture.
An interesting observation of the market is that even though we are well into the teenage years of Public Cloud, and one would expect a more mature security mindset and fewer security incidents, the opposite is true.
Microsoft has shown the industry that even they sometimes struggle to properly secure their infrastructure with two critical security issues disclosed by third party research companies that allowed them to (potentially) access other customers’ data (Azurescape and ChaosDB), and a third (OMIGOD) that would allow actors administrative access to Linux hosts in the cloud, without knowing any credentials.
With the reliance of cloud providers on open-source tooling like Kubernetes also comes that researchers and malicious actors can easily research the code that is run by cloud providers behind closed doors. This is not to say that open-source is bad, to the contrary, we believe open-source is highly valuable. Open-source means that security issues can also be detected and remediated much faster because of the transparency.
Google had several security bulletins published (https://cloud.google.com/support/bulletins/ ) with regards to security issues that were discovered in Kubernetes.
Coincidentally, a Kubernetes security in a (very) old version was also the way how researchers exploited above mentioned “Azurescape”.
Research at ARGOS has shown common areas of concern across all different kinds of organisations, sizes and industry verticals. Interestingly, the choice of cloud provider made no difference.
This is the number one security issue ARGOS finds in cloud environments.
Deploying Virtual Machines (VM) is as simple as never before, often only takes a few clicks or a one-liner on the command line and seconds later you can log on to your new VM. It is mainly so simple because usability is often given a higher priority than security, so instead of having the administrator also deploy a VPN or a Bastion Host / Jump Server (IaaS based or using a cloud service), Cloud Providers make it easy for people to access their VMs from the internet, anywhere in the world.
After all, that is kind of the appeal of cloud. However, this exposes the VM and the whole cloud environment to a myriad of attacks, like the above mentioned OMIGOD vulnerability. In addition to this it is also publicly stated by many Ransomware groups that they commonly use this vector to brute-force into Windows machines.
Remediating actions:
• Limit the source IPs that are allowed to access public endpoints.
• Leverage cloud services that allow remote access to VMs without having to assign a public endpoint.
– i.e., Azure Bastion, AWS Systems Manager, GCP IAP
Storage Accounts or S3 Buckets are some of the most commonly misconfigured cloud services and are often seen mentioned in data breaches.
Organizations leverage cloud storage for a multitude of scenarios, for example sharing of data with partnering organizations. Those cloud storage services on Azure for example are by default publicly accessible and depending on other configuration they can be easily accessed by unintended audiences.
On AWS and GCP they can still be easily misconfigured so that individuals on the internet can access data that they should not be able to access.
Remediating actions:
• Restrict access to cloud storage services to known audiences (network and identities).
• Do not expose cloud storage services directly to the internet but front them with services that can enforce more hardened security practices.
• Leverage cloud services that detect atypical data traffic / data exfiltration patterns
Should Web Applications not be publicly accessible? Well, yes, but in this case, we categorize this as a security issue where web applications should be fronted by Load Balancers, an API Management service, a CDN, a WAF, and not directly on the internet.
Similarly, most cloud providers will offer database services like AWS RDS, Azure SQL or GCP Cloud SQL and these are easily made accessible from the internet, if not already so by default, in the case of Azure SQL Databases.
Databases like RDS are often unintentionally made public and due to other organizational factors find themselves often being loaded with data in “nonproduction” environments that should not be in those environments.
People apply less strict security policies to nonproduction environments and “suddenly” people find their data on a forum on the internet.
Depending on the service being used even empty databases can be a security issue. An overly permissioned database service might have permissions to other services in one’s environment and those permissions can be used to create new users, new resources that can then be used to persist access to an environment.
Remediating actions:
• Restrict access to cloud database services to known audiences (network and identities).
• Apply least privileges to services.
• Review network configuration for database services and ensure that there are no other misconfigured / exposed services in that same network.
Managed Kubernetes Services like Azure AKS, AWS EKS or GCP GKE take a lot of operational loads off the customer, however, they are still not easy to manage and just like with VMs above, they are quickly misconfigured and the Kubernetes API or even the Dashboard is made available on the internet.
Out of all our researched misconfigurations this one is the one that we recommend keeping an extra eye on. It will likely only grow, with more adoption of Kubernetes / containerization we will see more Kubernetes Clusters be made publicly available and potentially granting a malicious actor access to containers running on that service or even other services in the cloud environment.
Remediating actions:
• Restrict access to Kubernetes services to known audiences (network and identities).
• Investigate newer cloud native containerization services like AWS Fargate, GCP GKE Autopilot or Azure ACI.
Comparing this report to reports from previous years, not much has changed.
The industry as a whole is still misconfiguring the basic aspects of cloud environments and cloud providers are not seen to making it easy for all customers of all sizes and budgets to identify these security issues and then solve them.
Organizations are focusing on higher level services (PaaS and SaaS) and we are seeing a real skills gap when it comes to securing those services at the network and identity level. During research for this report ARGOS was told several times that CISOs were hoping that Cloud Service Providers were going to cover more of the security aspects. The reality is that they probably are, but with new services different, new ways of securing them fall into the laps of customers. It is a never ending play of catchup.
Complicated setup of native cloud services or lack of context means organizations are wasting a lot of time investigating alerts that turn out to be not very meaningful. This time that it can take to set native services up, understand and tweak them, and then still spend time to investigate issues, this time is a risk, it’s all potential exposure time of your environment.
With ARGOS you go from zero to secure in just minutes.
ARGOS is your blue team member that finds and then investigates issues for you.
Humans are great at making decisions, but we are not very good at repetitive tasks like repeatedly investigating low-context alerts.
ARGOS provides rich context to detections so that a person can make a quick decision on fix or ignore in minutes, sometimes seconds.
Sign up to our free trial now at https://argos-security.io .