At HackerOne, I led the detection and response team. It was a small, high-impact, and constantly bandwidth-constrained team. We were responsible for building detections while also actively responding to incidents, so speed mattered.
We had to work smarter and leverage as many tools as we could. This meant leaning on various AI capabilities across the space, being very careful with our tool selection as much as possible, and, of course, it also meant that, even as the manager, I would be involved with building detections, responding to alerts, and running incidents.
One of the detections that needed to be built detected a certain type of data on our employee laptops. We had used different soft methods in the past, including policy and training, to ensure this data didn't end up on employee laptops, but inevitably, it still did through either lack of awareness, forgetfulness, velocity, or any other type of excuse.
Using our Endpoint Detection and Response tool, SentinelOne, we leveraged the RemoteOps capability and ran our current script that would detect, log, and delete any discovered data that fit the criteria we were looking for. We had some characteristics of the data, such as common file types, naming structures, and certain contents that would indicate, with high confidence, that it was the particular data type we were looking for that should be removed from laptops
However, given the size of the team and the amount of work the team had, we didn't have the luxury of time to build a script and iterate on it slowly, as a normal software development lifecycle might go.
Rather than spending weeks on traditional development or worse, interrupting my busy team with an ask, I took a different approach. I fired up the Kiro CLI and started building a script using a portion of a test set from a real previous incident to guide the CLI into building a detection script that can be run via Remote Ops in SentinelOne.
Kiro got me about somewhere between 80 and 90% of the way there in an hour or two. Starting off, it was just a simple detection of the different signals. Over time, I pushed Kiro to weigh the dimensions differently; for example, the structure of the data was very specific. I could accurately detect the format of the data, so when the script found this data format, that particular file would be given a significantly higher score than if it matched a file type. Based on a threshold I set, I could either alert on those files or ignore them if they were below the threshold.
In the span of a morning, I had the bones of my detection script working on a dataset that should have triggered it.
I iterated on and tested the detection over the next week between meetings and other obligations. This was the final 10-20% left. I worked with Kiro and found edge cases, such as dealing with screenshots of files that could have sensitive data or tweaking the weights until I minimized the number of false positives so the detection was useful. These are the normal requirements of a detection that take experience to identify and handle.
With Kiro, I also added additional "features" such as notifications, file quarantining or removal, and the ability to weight values in each dimension differently. It didn't take long, five minutes to fire off a new prompt or fifteen minutes to review the adjustments that were made by the last prompt to Kiro.
The Takeaway
I see detection engineering much like treading water. You straddle the line between floating easily and drowning. There's an endless number of exploits, gaps, and "acceptable risks," but using Kiro helped me close a known gap and prevent a recurrence of a critical issue. That's how it can be a multiplier, not simply using it as a means to create your SPA but combining your expertise with Kiro to get 80% of the way there, leaving only minor adjustments and tuning based on your experience.
