Cloud security configuration scanning tools and similar approaches offer great insight at the technical level and are a foundational component of a risk assessment strategy. Prioritizing risk mitigation based on that low level output alone misses something critical (pun intended): organizational context.
“What would happen if an attacker understood Kubernetes better than your operations team?” That was the core question that Ian Coldwater and I posed to each other, and it became clear that the research in this area is underexplored. Last week at RSA Conference 2020 we had the honor of presenting our thoughts on what attackers would do, how they might do it, and how they might try to avoid detection. We look forward to presenting an even more advanced version of this talk at KubeCon EU 2020.
When discussing the risk S3 buckets pose to organizations, the majority of the discussion is around public buckets and inadvertently exposing access. While this is certainly a common threat vector, it can be addressed in a number of policy-driven ways. Blocking the ability to accidentally expose buckets at the organization or account level is much more practical now, and probably a more scalable and sound approach than trying to implement a reactive solution.
The National Security Agency (NSA) today published guidance aimed at “organizational leadership and technical staff”, outlining practical ways organizations can mitigate the most common cloud vulnerabilities. In this post, we’ll highlight the key elements of the NSA’s guidance for convenient reference. The full report is linked below.
Despite advances in Amazon Web Services (AWS) controls around S3 (Amazon Simple Storage Service), we continue to see data leaks and breaches centered around data stored on S3. In November 2018, Amazon released the Block Public Access feature to make it easier to secure access to S3. Newly created S3 buckets have always been private by default, but there is still confusion around the different ways data in an S3 bucket can become public.