Welcome! This is the fifth edition of CloudProfs, sent to subscribers on August 27. See the email in-browser here.
If you enjoyed this newsletter, why not sign up to receive it in your inbox every week? Or if you have any feedback, email the editor.
What’s Been Said and Done in Cloud (Security!) This Week
A Microsoft Azure vulnerability made public this week has been described by the company who discovered it as ‘the worst you can imagine.’ A ‘series of flaws’ in a Cosmos DB feature created a loophole allowing any user to download, delete or manipulate a massive collection of commercial databases, alongside read/write access to the underlying architecture of Cosmos DB.
Wiz, the security company who found the issue, praised Microsoft’s security team for acting so quickly. Microsoft has notified more than 30% of Cosmos DB customers that they need to manually rotate their access keys to mitigate this exposure. However, the issue has been dormant for ‘possibly years’, meaning other customers may be at risk. “This is the worst cloud vulnerability you can imagine,” Ami Luttwak, CTO of Wiz told The Verge. “This is the central database of Azure, and we were able to get access to any customer database that we wanted.”
You can read an explainer and remediation tutorial from Wiz here.
Meet Monad, a company which aims to provide security and DevOps teams a ‘single source of truth’ for their asset and vulnerability data. The company emerged out of stealth this week (August 26) with $17 million USD in funding.
As enterprise organisations typically have dozens of security tools, investing in more disparate tools, or hiring people at a rate of knots, rarely solves the issue and leads to more complexity.
This may be a story we have heard before, but Monad states its approach is different. The company’s platform utilises what it calls the Monad Object Model, which works with any data warehouse. “By opening the data to queries, all teams – security, DevOps and cloud engineering – can interact directly with the data through SQL and third-party business intelligence tools,” the company claims. “With this new knowledge in hand, security teams can now build effective security applications and compliance workflows on the fly.”
David O’Brien, founder of Argos Security, tells the Software Engineering Daily podcast about why Azure is more manager-friendly and AWS more developer-friendly from a security perspective. “I actually think if you need to use one of the three cloud providers, and most of the time [are] going to use the console, you’re probably going to be happiest on Azure. The information you get out of the dashboard is a lot more informative almost than it is on AWS. There’s no way on AWS to see all your EC2 instances across all regions, across all the accounts you have access to. On Azure, I can go into the console and say ‘show me all the virtual machines across everywhere.’ And I can see all that information in one view.”
When it came to security, O’Brien argues you can get equal levels across all the hyperscalers – but with a caveat.
“The default configuration – I think it’s probably the most secure on Google as I’ve seen. Microsoft and Amazon are often insecure by default. What I mean by that is if you go and look at Amazon or Microsoft blogs, or tutorials, they want to get you started quickly. They want to make sure that if you deploy an EC2 instance and install a web server, for example, on that EC2 instance, that you can get that started and done in minutes, not days.
“A lot of people don’t necessarily go back to the thing they just deployed and secure it after the fact, because cloud providers give you a bit less secure defaults so you can get started quickly. That means there’s a lot of insecure stuff out there that is not going to get looked at again.”
You can listen to the full podcast here.
Why HashiCorp is Researching Multi-Cloud Spend
More than a quarter of telcos surveyed by HashiCorp spend more than $10 million per year (USD) on cloud deployments. That is the key finding from the latest report by HashiCorp exploring organisations’ cloud habits. Previously, multi-cloud workloads were explored – as CloudProfs issue #3 reported – but this time, cloud spend is the focus.
Two in five of the more than 3,200 respondents admitted their organisations overspent their cloud budgets in 2020. Yet Covid-19 was not the primary driver. Companies are shifting priorities, as the multi-cloud research previously detailed. A third (33%) of respondents adopting multi-cloud plan to spend more than $2m per year, while 6% expect to spend more than $50m per year.
There are various examples of mega-spend. Spotify revealed through its IPO filing in 2018 that it was paying Google Cloud €365m over three years – approx. €10m a month. Pinterest has committed similarly to spending at least $750m on AWS over six years. Apple reportedly spends more than $30m per month on AWS.
But where does the sprawl come in? “Many organisations seem to be adopting the cloud on an ad hoc basis, without a complete multi-cloud strategy or toolset,” HashiCorp argues. “That approach makes it difficult to project cloud spend.” This can be seen in other factors blamed by respondents; 14% said they had no guardrails to manage resources, while 13% said they had a lack of tooling standardisation.
Part of the reason HashiCorp is publishing these reports is to grow awareness of its HashiCorp Sentinel offering. Sentinel is an embeddable policy-as-code framework to treat security policy as an application, with version controls, pull reviews, and automated tests.
An example can be seen in Terraform (documentation for Terraform Cloud here) through this code sample ensuring AWS security groups do not have egress set to 0.0.0.0 (unrestricted outbound access):
import “tfplan/v2” as tfplan
security_groups = filter tfplan.resource_changes as _, rc {
rc.mode is “managed” and
rc.type is “aws_security_group” and
rc.actions is not [“delete”]
}
main = rule {
all security_groups as _, sg {
all sg.change.after.egress as egress {
egress.cidr_blocks not contains “0.0.0.0/0”
}
}
}
Kubernetes Security: Zero Trust Models and Top Tools
A couple of interesting blogs which went live this week with regard to Kubernetes security.
Dr. Alan F. Castillo writes on a way to achieve Zero Trust security in Kubernetes by enforcing the network policies. Start with a default deny-all network policy which stops pods from talking to anything else; then, gradually add more permissive policies which override the default after carefully evaluating the required connections. This achieves the goal of following the principle of least privilege, a key facet of Zero Trust.
Example here:
//Application of Default Deny-All policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
spec:
podSelector: {}
policyTypes:
-Ingress
-Egress
// Allow access from App 1 to App 2
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-my-app
spec:
podSelector:
matchLabels:
app: app-1
Ingress:
– from:
– podSelector:
matchLabels:
app: app-2
Egress:
– to:
– podSelector:
matchLabels:
app: app-2
The other two methods explain the role of SPIFFE (Secure Production Identity Framework For Everyone), as well as the role a service mesh such as Istio can play. You can read the full blog here.
Elsewhere, take a look at these top eight open source Kubernetes security tools, as ranked by a Red Hat user survey:
- Open Policy Agent (OPA). OPA is a general-purpose policy engine but also a ‘very powerful tool for enforcing context-aware security policies.’ As Pod Security Policy is set to be removed altogether by K8s v.1.25, OPA is expected to become very important. 32% of survey respondents use OPA.
- KubeLinter. KubeLinter is a static analysis tool that scans YAML files and Helm charts. The tool can assist in checking for security misconfigurations such as enforcing least privilege and running containers as a non-root user. 32% of survey respondents use KubeLinter.
- Kube-bench. Kube-bench is a tool which audits K8s settings against security checks recommended in the CIS Benchmark for Kubernetes. The tool is ‘particularly useful when self-managing the control plane components.’ 24% of survey respondents use Kube-bench.
- Kube-hunter. Kube-hunter, as the name suggests, hunts for security issues in your Kubernetes clusters, and can be very helpful in looking for further exploits based on the vulnerabilities is has already discovered. 23% of survey respondents use Kube-hunter.
- Terrascan. Terrascan is an open source static code analyser for infrastructure as code (IaC), with more than 500 policies for security best practices across K8s, Terraform, and the major clouds. 22% of survey respondents use Terrascan.
- Falco. Falco protects running containerised applications in Kubernetes, and is built for runtime security. 21% of survey respondents use Falco.
- Clair (11% of respondents) is an open source security tool used for scanning container images for known vulnerabilities, while Checkov (9%) is similar to Terrascan, with features such as context-based analysis.
How CloudQuery Can Help Multi-Cloud Account Compliance
A SANS Institute webinar this week saw AJ Yawn, co-founder and CEO of ByteChek, explore CloudQuery as an easier method for multi-cloud, multi-account cloud compliance.
CloudQuery exposes cloud configuration and metadata as SQL tables and is related to OSQuery, an endpoint package developed by Facebook that allows users to expose system information as a relational database.
A large part of this commonality – and a large part of where Yawn sees benefit for security professionals – is through the flexible ‘universal language’ of SQL. “Trust me, you can do it,” Yawn said to sceptical security professionals who may worry that they don’t have the knowledge. “SQL is not that hard to learn. You don’t necessarily have to become a database administrator to learn OSQuery.
“With this language, we can use the power of SQL to join certain tables together, grab specific information out of tables,” Yawn added. “That’s a really powerful aspect of OSQuery that we’re going to be able to leverage when it comes to CloudQuery as well.”
A key feature of CloudQuery is its exploring and monitoring capabilities. When ETL (extract, transform and load) capabilities are generally scattered across different cloud, SaaS providers and APIs, CloudQuery “puts it into a local PostgreSQL relational database that gives [the user] an ability to focus on the business logic without writing code or working directly with APIs,” Yawn put it.
Crucially, admins do not need to log in to AWS, Azure, or Google Cloud Platform every time. Ease of use for multi-cloud deployments is a key factor, though Yawn railed against this. “I personally have not heard a good justification for running multi-cloud,” he told attendees. “You can generally get the same benefits from within one cloud provider, which puts less stress and pressure on your team.” Yawn cited saving redundancy as an example where one cloud in multiple regions could suffice.
For Yawn, CloudQuery is a tool which will ultimately help compliance professionals in communication with other business departments, to stop being lost in translation. “In the same way operators and engineers are using infrastructure as code to build, change and version infrastructure, we can use CloudQuery and CloudQuery policies to monitor, alert and version our compliance and security rules,” he said.
“If you think about the shift in moving the space from DevOps to DevSecOps, you’re constantly hearing about security shifting left, but we never really hear about compliance shifting left.”
One attendee asked whether CloudQuery results would be accepted by auditors as legitimate. Yawn noted that this was the second part of the challenge, after collecting the data.
“I think we’re getting there, in terms of auditors becoming more technical , but I think we won’t really see a huge shift in that until companies really start to force and ask the tough questions during the audit procurement process,” said Yawn. Auditors ‘should’ accept this evidence, but organisations have to convince them. “I’d much rather get that information as an auditor than a screenshot. The screenshot doesn’t tell me much, but I can see that this is something that’s running on a regular basis, here’s where the results are stored, and I can take a lot of those Excel, CSV files, and interact with them in a programmatic manner.”
The webinar took place as part of a wider SANS course, where Yawn instructs, on Continuous Automation for Enterprise & Cloud Compliance (SEC557). You can find out more about the course here.
Secret Knowledge
A recent repository of cool cloud tools and reports. Thanks to John for suggesting this!
Cloud-Katana (Azure): Unlocking serverless computing to assess security controls. Open sourced this week. Primary language: PowerShell
easegress: A cloud-native traffic orchestration system. V 1.2.0 released this week. Primary language: Go
engine: Deploy your apps on any cloud provider in just a few seconds. Primary language: Rust
GCP-Uploader-proxy: Simple uploader proxy for uploading files to Google Cloud Platform Storage. Primary language: Python
k8gb: A cloud-native Kubernetes global balancer. Primary language: Go
SECRET SECURITY CHEAT SHEET: TrustOnCloud ThreatModel for Amazon S3! (136 page PDF, immediate download)
Bonus Cloud Security Reads
Take some time out and get stuck in to these rich cloud articles from across the web:
1) Chaos Engineering With AWS Fault Injection Simulator
2) Certifications: CCSP vs. Cloud+: How Do They Stack Up?
3) Security of AWS CloudHSM Backups (whitepaper)