Lessons Learned as a SOAR Engineer: Series Intro

Back in 2011, I was staring down the barrel of the rest of my life, trying to figure out how to get where I wanted to be. I knew I wanted a career in information security, but I had no real understanding of what roles actually existed. My interests leaned heavily toward the red team, inspired by getting suspended in ninth grade for being "my brother’s brother", but that’s a story for another time. In my very limited view of the industry, security seemed to boil down to two options: offensive security, or what I thought of as the "general security admin". You know the type, a small team responsible for everything security-related, with little budget, less time, and even less hair.

With no professional network to speak of, I ended up asking someone I barely knew for advice on becoming a penetration tester. Their advice was blunt: "Get a computer science degree. You’ll always have a job. If you get a degree in information security and can’t land a role, you’re up the creek, but everyone needs programmers. It’ll be easy to transition from software engineering."

It wasn’t.

Five years of college and another five years working as a software engineer later, I finally got my break. Someone on the security team at my alma mater reached out to tell me they were creating an Information Security Administrator role specifically for people trying to break into the field without direct security experience. The catch was a substantial pay cut compared to what I was making as a software engineer. After spending nearly a decade working toward this goal, I wasn’t about to pass it up. I threw my name in the hat and started adjusting my life around the expected salary.

I soon found myself as Bowling Green State University’s first Information Security Administrator, and shortly thereafter a full-fledged Information Security Analyst. Over the next two years, I got hands-on experience across a wide range of security functions: reviewing and remediating phishing reports, conducting digital forensic investigations for the university and for local and state law enforcement, managing VPN infrastructure and security-related firewall rules, building detection logic in Splunk, and triaging alerts when they inevitably fired at 3 a.m. Nearly all of this work was manual, driven by budget constraints and a cultural skepticism toward automation.

Because this was my first and only experience in the field at the time, I assumed this was just how security work was done.

That belief was challenged when I came across an opening for a role called a "SOAR engineer", a term I had never heard before. I had no experience with SOAR platforms and little understanding of what the job entailed, but it quickly became clear that it represented the perfect intersection of my background. My time as a broadly scoped security analyst taught me what should be automated, and my years as a software engineer taught me how to automate it effectively.

That intersection, and the lessons I’ve learned working within it, is what this series is about. Over the last 4 years I've experienced challenges and setbacks both of my own making as well as technical debt created by others' decisions. Sometimes this presented as significant time lost as work gets redone, sometimes that time isn't available and the price is paid daily in the way of burdensome support and less than ideal UX for the end users of the platform.

Let me know in the comments what challenges you've faced or are facing with automating your detections and response!