Josh Stella

Co-founder & Chief Technology Officer

A Brief History

Josh Stella is Co-founder and CTO of Fugue, the cloud infrastructure automation and security company. Fugue identifies security and compliance violations in cloud infrastructure and ensures they are never repeated.

Previously, Josh was a Principal Solutions Architect at Amazon Web Services, where he supported customers in the area of national security. He has served as CTO for a technology startup and in numerous other IT leadership and technical roles over the past 25 years.

From Our Blog

Articles By Josh Stella

  • Developers Now Own Security, and That's a Good Thing

    Software is eating the world. In the age of cloud computing, developers now own the security posture of your enterprise because the cloud is fully software-defined and programmable. If that scares you, it's because you haven't given your developers the tools to create secure systems. The good news is that you can, but you need to change how you think about security.

    Read More
  • A Technical Analysis of the Capital One Cloud Misconfiguration Breach

    UPDATE: August 26, 2019 Since posting this, AWS has made some public statements regarding the breach that shed some light on what likely happened. From their response to Senator Ron Wyden, AWS stated: "As Capital One outlined in their public announcement, the attack occurred due to a misconfiguration error at the application layer of a firewall installed by Capital One, exacerbated by permissions set by Capital One that were likely broader than intended. After gaining access through the misconfigured firewall and having broader permission to access resources, we believe a SSRF attack was used (which is one of several ways an attacker could have potentially gotten access to data once they got in through the misconfigured firewall." "As discussed above, SSRF was not the primary factor in the attack. We are not aware of any other noteworthy SSRF compromises of AWS customers." Much has been made of the likely SSRF aspect of the breach, but as AWS makes clear, it was not the primary factor in the attack. Overly permissive configuration of cloud resources was. This post describes in detail some ways those resources may have been misconfigured and those misconfigurations exploited.   ORIGINAL POST: August 1, 2019 This is a technical exploration of how the Capital One breach might have occurred, based on the evidence we have from the criminal complaint. I want to start by saying that I deeply respect the Capital One cloud team, and have friends on it. They've been leaders in cloud computing, and what happened to them could have happened to nearly anyone. I'm also not criticizing Amazon Web Services (AWS)⁠—my previous employer. They offer secure services and I have nothing but respect for them. The purpose of this post is to explore a combination firewall/IAM/S3 attack to illustrate some of the dangers of cloud misconfigurations that every organization on cloud should heed.

    Read More
  • Shift Left on Cloud Security, Part III: Extending into Production

    In the last part of this series, we're going to look at the final stages of the software development life cycle (SDLC)—deployment and operations. As a reminder, in parts one and two, we discussed the overall concept of shifting left for security and compliance, and laid out some best practices for how to do so during the development and testing phases of the SDLC. In this post, we'll cover how using policy as code and baselines allows you to leverage all the work done in the earlier phases to prevent deployment of misconfigurations and ensure that your deployed infrastructure remains functional and compliant over time.  

    Read More