Every week, Sprocket CEO Casey Cammilleri interviews an expert leading the charge on empowering security experts and practitioners with the knowledge and insights needed to excel in the future of cybersecurity.
He recently spoke with Roger Allen, Sr. Director, Global Head of Detection & Response at Sprinklr. Here are the top takeaways from the interview.
#1: Practice Breach Response Before You Need It
“Breach repetitions. I think that's the big thing. My team does scenarios where we simulate different activities or types. We do that in addition to our tabletops that we do where we engage executives and we engage all the engineering teams. But what are we doing as a security operations team to be able to identify and respond? What are the actions that we're going to take? If it's a malware exploitation, are we going to contain a host?
“Even thinking cloud native, when your company has a product, are you going to just go and contain a product host and shut down part of production? Probably not. So what are the implications? Do you have a plan for the tier rankings of the severity of if an attacker makes it to this point versus this point, what are your actions? Are you going to monitor, are you going to contain? What are you going to do? So I think going through our scenarios in building those workflows and understanding that plan is the most critical.”
Actionable Takeaway: Regular breach scenario drills prepare your team for real incidents better than tabletop exercises alone. Cloud-native environments require tier-based response plans that consider production impact. Will you contain a host and shut down customer services, or monitor and gather intelligence? Build workflows now that account for business implications, not just technical responses.
#2: Turn Engineer Behavior into Detection Intelligence
“We have a dedicated product security team. We work very closely with them as we see different activity within our environment. A lot of activity you'll see, prior to an adversary gaining access to your environment through your engineers, they're going to find very creative ways to try and do intended things just in very obscure ways.
“And as you find those activities, it's important to take that as a learning opportunity and incorporate that into your defensive strategy. So you may be something where someone uses a binary, such as if you have Netcat in your environment, are they using Netcat just to test a port on a machine to make sure that it's responding the way it's supposed to?
“Okay, well now we need to go make sure we're taking out Netcat or Telnet or any of those. Are they trying to use SCP to move data between different machines instead of bringing it in the way they should? Okay, well, let's monitor SCP. What are the conditions that SCP would be useful? What are the conditions that would be malicious, and how can we build property detections that would differentiate between those two? So if we have SCPs going to an internal subnet, maybe it's not such a big deal. We've got SCPS going to an external source, we've got big problems.”
Actionable Takeaway: Engineers often use legitimate tools in unusual ways before attackers exploit the same techniques. Monitor how your team uses binaries like Netcat for port testing or SCP for file transfers. Build context-aware detections that differentiate between internal subnet transfers (likely legitimate) versus external transfers (potential data exfiltration). Their creative workarounds become your early warning system.
#3: Build Detection Strategies Around Business Context
“There's no detection that should apply to everybody. You're going to have buckets of detections that will really apply to engineers. Like you said, SAP usage is going to be very prevalent in an engineering group, but it's going to be very unlikely in a finance group. So if I see SCP on a finance group, very much should be a detection. But if I see an engineering group, very much more context is going to be required.
“So I would say, where, how are they accessing what data? So finance is going to have different data sets than engineering. So I would focus on what is our most important data set at that point in time. And I think that's really going to be a partnership with the business.
“And I think that's where security leaders really need to bridge that gap between technical aptitude, but also business acumen and say, ‘Hey, I need to work with our senior leaders to understand what is our most important at this point in time. What's our most important data? Is it our source code? Is it our customer data? Is it our internal data?’ And I think building backwards from there.”
Actionable Takeaway: Generic detections create noise instead of actionable alerts. SCP usage triggers different responses in finance teams versus engineering groups because they access different data types. Security leaders must partner with business stakeholders to identify crown jewel assets—source code, customer data, or internal systems—then build detection buckets that protect what actually matters to revenue.
