At the start of my career as a security engineer, I built an allow list management system for our web gateway within the security operations center (SOC) I worked in. Beyond just a script, this was a live system that a core security component relied on. Someone once blocked a /3 vs a /32 IP range, and access to a third of the internet broke for all 40,000 employees. I knew the system I created had to prevent something like that from occurring again. The manager of the SOC analysts would have regular discussions with myself and my manager on any issues that arose, which helped me realize the impact my code had on someone else’s work. That was the first time I felt responsible for software, not just automation.
This series explores my lessons as I crossed into platform engineering from security engineering. What I might tell my past self, given the chance, and how I now approach problem solving with a software and platform engineer's perspective. If you're a security practitioner wondering what's on the other side, this is for you. If you're a developer who works with security teams, this might help explain why we think the way we do.
While in the security org, I started to notice that the numbers of vulnerabilities kept growing faster than we could fix them, given how often we patched. As cloud platforms came onto the scene, we also started to produce misconfiguration findings. Hoping to avoid the same outcome there, I took a different approach.
Rather than creating more findings to track, I identified platform controls that were acceptable to all parties. With stories of public S3 buckets causing data leakage left and right, I implemented a preventative control that disallowed public buckets. This eliminated those types of issues outright for both the development team and the vulnerability management team.
While the security team does not own and operate all systems in an enterprise, working with one platform or infrastructure team vs 50-100 can greatly reduce remediation time. However, there were a few times where we had to roll back a control as it negatively impacted teams’ ability to operate their own systems. This taught me the value of progressive rollouts, a practice the rest of software engineering already relied on. Similarly, using policy-as-code we could move back to an older version of the policy in minutes.
Many skillsets in security are more portable than I realized. Conducting security reviews prepared me well for system design discussions and operational troubleshooting when a system might be down. From tracking an attacker's footsteps during incident response, I could debug a running system, stitching together the timeline with logs and traces.
The most effective controls I've built have been from understanding how development teams work and finding ways to remove risk without increasing friction. While not everyone needs to become a software engineer, understanding the core concepts and ways of working helps find solutions that don't slow teams down. In the next post, we'll explore CI/CD and how to balance effective controls, defaults and exceptions.
Top comments (0)