2019: The Dev Ops Crusades

### Overview In '2019: The Dev Ops Crusades', the speaker addresses the recurring problem of massive data leaks stemming from AWS misconfigurations. Highlighting high-profile incidents like the 2019 Capital One breach, the talk examines how standard cloud adoption and rapid DevOps culture often incentivize speed and convenience over secure architecture. The speaker argues against treating security as an afterthought or merely tacking it into 'DevSecOps', advocating instead for breaking down silos, educating developers on AWS permission models, and integrating security practices directly into daily development workflows.

### Key Topics - **DevOps Culture vs. Security**: The pressure to push features rapidly leads teams to rely on quick, insecure configurations rather than rigorous permission designs. - **The Capital One Breach Architecture**: Unlike typical publicly open S3 buckets, the Capital One breach involved an attacker bypassing a misconfigured Web Application Firewall (WAF) to compromise an EC2 instance, which had overly broad permissions to access multiple S3 buckets containing customer data. - **AWS Permission Architecture**: S3 access relies on two primary mechanisms that should both be used: IAM roles/policies (centered around users and service entities) and S3 bucket policies (which determine what entities the bucket opens itself to, including MFA and IP restrictions). - **Convenience vs. Security**: AWS makes insecure configurations easy via built-in 'S3 Full Access' policies and wildcards (`*`), while configuring least-privilege custom JSON policies is tedious and requires iterative testing.

### Technical Details - **IAM and Service Roles**: IAM statements define access for users and automated services (such as AWS CodePipeline grabbing source code from S3/GitHub and deploying it). EC2 instances similarly inherit permissions via assigned IAM roles. - **Overprivileged Policies**: Built-in full access policies grant wildcards across all actions and resources, allowing dangerous capabilities such as listing all buckets, downloading files, deleting buckets, or wiping out access/audit logs stored in S3. - **Restricting Policies**: A secure custom policy (illustrated as 17 lines of JSON) explicitly restricts access to specific actions—specifically `ListBucket` (requiring the bucket ARN to refer to it by name), `GetObject` (to download files), and `PutObject` (to upload files)—scoped strictly to designated bucket and object ARNs rather than account-wide wildcards. - **Tooling**: The speaker highlights the AWS Policy Simulator as a free, accessible tool to evaluate and debug permission structures before deployment.

### Takeaways - **Review Infrastructure in Code**: Treat cloud infrastructure as code (using tools like AWS CloudFormation) and mandate security reviews of AWS changes within pull requests. - **Isolate Environments**: Maintain separate AWS accounts for production and development/work-in-progress environments to limit the blast radius of errors. - **Enforce Least Privilege**: Avoid wildcards and full access policies; limit roles to specific ARNs and necessary API calls. - **Empower Developers**: Treat security improvements as features and patches as bug fixes. Train developers to understand cloud permissions and test them early rather than handing production applications to security teams to fix after deployment.