LAST UPDATED Mar 18, 2022
Welcome to ThreatX Security XChange – our blog series featuring security practitioners and leaders doing the day-to-day hard work of keeping our systems and data safe from cyber criminals. We started this series simply to shine a light on those in the trenches, fighting one of the most important and least understood battles of this generation. We wanted to not only highlight their work, but understand a little more about their pains, priorities, passions, and pet peeves. We hope you enjoy these profiles; let us know if you’d like us to tell your story!
For this Security Spotlight, we sat down with Terence Runge, an experienced CISO and security leader who has held security leadership positions and led security programs at numerous enterprises including Reltio, Illumio, and Salesforce.
ThreatX: What are the top three or four responsibilities of the modern security team?
Terence: I see the top priorities as 1) securing customer data, making sure it’s being handled appropriately and with reasonable controls applied; 2) making sure that the product and the platform that we’re providing to our customers is secure or reasonably secure; and 3) making sure that the business itself is securely using the services that it consumes.
ThreatX: We are hearing from a lot of prospects and customers worried about API security. What do you think is the biggest challenge in that space?
Terence: API security is a major concern. It’s challenging because to get to a point where you can reliably say that your APIs are being exposed securely requires a lot of internal testing as well as a lot of reliance on external third parties. It takes automated testing, manual testing, plus encouraging researchers to report any findings with APIs.
Another challenge is that it requires a close watch on what product and DevOps engineers are doing. Security needs to be alerted to any new APIs or modified APIs. During any design review, my team works very closely with product management and product engineering to try and get that visibility.
ThreatX: What’s on your API security wishlist – whether it exists or not.
Terence: This is not something you can buy, but I would say good, accurate documentation. That helps a lot. Understanding the intended functionality of the API is significant. That really helps us adopt the appropriate security controls relative to the functionality of that API.
Also understanding which APIs might be exposed that are really only intended to be used by an internal team, such as a support team, but could be inadvertently discovered and abused.
Layers of defense is also important. I’m still a little bit stuck on the fact that we tend to see a lot of really simple attacks succeed. In many cases, that’s true because security teams can’t focus on every single attack vector being thrown at them. So having some holistic way to test the security of exposed APIs comprehensively would be very valuable as well as a way to define and apply the appropriate counter measures.
ThreatX: In general, what do you look for in a security solution?
Terence: I would say clarity as far as which direction the product is going. Every vendor is trying to define something that’s truly novel or unique, and it’s confusing. I think a lot of security teams are experiencing analysis paralysis as a result. It requires research. It also requires security teams to understand what they’re defending as well as defending against.
ThreatX: What’s the biggest time sink for security teams?
Terence: For security analysts, I would say lack of comprehensive information surrounding security alerts. The analyst’s responsibility is to investigate alerts and determine whether they are appropriate activity, or something that needs to be escalated and investigated. One of the biggest time sucks they run into is information that is not comprehensive enough. It seems like it would be fairly trivial to get information around some offending IP, but the reality is security teams spend a considerable amount of time tracing down information around the potentially offensive IP address to just get started. Meanwhile, you don’t know if there was a successful attack, if this is an attacker who’s now moving laterally through your network, if there’s data leaking, or if there’s some other malicious activity that’s happening.
ThreatX: As a CISO reporting to the executive level, what are the metrics you care about? What are the KPIs that matter?
Terence: I think metrics are a double-edged sword. I think that when you get mired down in metrics, it’s pretty easy to lose sight of the fact that we still have attackers out there who have one thing to do successfully, which is to penetrate your environment. So I’d rather focus on defending against that, making sure that the product and platform is secure, the customer data is secure, that we’re situationally aware of what’s actually happening in our environment rather than churning numbers that might satisfy some steering committee obligation around number of vulnerabilities or percentage of vulnerabilities reduced over the last 90 days, which is often misunderstood.
That being said, there is one snapshot I produced that I like, called security by the numbers. And security by the numbers includes things like number of connections per month or per quarter, number of malicious events, number of events that were investigated by analysts or researched by analysts, number of events that were further investigated, number of incidents, and number of events that were fully adjudicated, etc. And I do that because I want the consumers of that information to understand that if we have 100 billion connections a month, that’s what normal looks like. If I come to you next month and I said, “Well, we had 500 billion.” That’s going to stand out — what happened there? Maybe it’s not malicious, maybe we just onboarded some massive customer or something else happened.
But I also want them to know 0.015% of our activity is potentially malicious. So if I come to you and I say, “Well, last month we saw 3%.” That’s a huge spike. So I try to ingrain those numbers into other leaders across the business so that they know what normal looks like rather than other metrics. I think it’s more important that they understand the normal landscape, as opposed to other metrics like number of malware events experienced last month or vulnerabilities and that sort of thing.
ThreatX: What do you wish more organizations knew about detecting and responding to breaches?
Terence: I’d really like more organizations to understand when to get hands off and when to engage third-party experts. It’s fairly easy to respond incorrectly to a potential incident or an attack and mishandle it. If you’re a larger organization and you actually have the skillset, if you’re a Microsoft, then you have those capabilities built internally. But for smaller organizations, I would say you probably don’t have an IR team. And even if you did, they’re probably not well exercised. And it’s best to really understand, when do you stop and engage those third-party experts.
ThreatX: What are the primary factors that are signals that it’s time to outsource incident response?
Terence: Tabletop exercises can definitely eek that out. During policy review or policy creation, it’s a good time to really think, do we have this capability? What are we going to put into our IR plan, into the IR policy and how are we going to manage those incidents? There’s a huge default to push to internal. And I still think that’s not always the best answer. It might be better to push up to a crisis management team – a forum of executives led by the CISO or a delegate or somebody who’s appointed as a leader of that group. Make sure the right people are involved, CFO, general counsel, CISO, engineering, your DevOps leaders. And make sure they understand, is this an incident? Do we at this point engage outside council? They’re the right people to make those calls.
Our thanks to Terence for sharing his insights and practitioner perspective with us. Want to be featured in a Security Spotlight? We’d love to hear your story – contact us!
