LAST UPDATED Apr 11, 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 cybercriminals. 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 Xchange, we sat down with John Brunn, CISO at Domino Data Lab who has also held security leadership positions at numerous enterprises including Lookout, Hotwire/Expedia, and Cmd.
ThreatX: You have had a variety of security roles over the course of your career, which one have you enjoyed the most?
John Brunn: I really like my current CISO role. I have more responsibilities now than I’ve had in other roles, which means I’m less hands-on, which I do miss. But it’s also really satisfying to build a great team and be able to solve hard problems together. There’s a lot of pride in the work.
ThreatX: What is your process for evaluating a new security technology that you’re thinking of buying and implementing?
John Brunn: The important thing is always to say, “what are we trying to solve?” You have to be careful about having a hammer and looking for nails. We don’t want to do “management by magazine” — “I just read about X, let’s throw this in here.” Rather, what are we trying to solve? In addition, a lot of times we need buy-in from the teams that are actually implementing the solution. If I buy something today and eight months later it’s not installed yet, that is a big deal. So we have to be aware of the true cost of ownership, including the general management and the maintenance. For instance, are we going to install it and then walk away from it? What are the integration points to our existing tooling?
The important thing is always to say, “what are we trying to solve?” You have to be careful about having a hammer and looking for nails. We don’t want to do “management by magazine” — “I just read about X, let’s throw this in here.”
ThreatX: How do you know when a technology is just working for you?
John Brunn: There’s always the question of whether something was purchased to add value, or reduce risk, or to check a box. Monthly, or more likely quarterly, we should re-assess our solutions. What’s our threat landscape? What’s changed for us? Do our tools actually address new threats coming in, do we need to request new features, or do we need to start re-evaluating the vendor altogether? But this process is often challenging because vendors will say, “Oh yeah, we have that in audit log somewhere.” But if I can’t easily get to the data, if I can’t integrate it with other data sources, I either can’t get a true picture of my threat landscape or now I’ve got two processes.
There’s always the question of whether something was purchased to add value, or to check a box.
ThreatX: What about the threat landscape that you experience and see day-to-day do you find most challenging?
John Brunn: If I’m going to be honest, it’s time spent trying to communicate our security posture. We spend a lot of effort trying to communicate with all of our customers the posture of our security program. And we try and speak risk. And a lot of times speaking risk is not a common vernacular with a lot of organizations. They might speak CVSS, which by definition informs risk, but is not risk. And so we spend a lot of effort working on the attestation of our security controls and our overall product security across our customer base. And that leads to a lot of effort that isn’t looking at our risk threats, which makes actual threat management more challenging. We do incorporate industry best practice as well as customer feedback into our reporting, but it’s a challenge.
ThreatX: What do you wish that more organizations knew about detecting and responding to attacks and breaches?
John Brunn: Oh, where do you start? I think the difficult part is that there is often a lot of time and effort to get to the point where you can hear about a threat and then be able to say, “Hey, I can tweak this alert and look exactly for that threat” with immediate results — or have the visibility to guarantee that a SolarWinds type breach didn’t happen. Someone might say, “Hey, here are the IP addresses that were published that potentially were used in this attack.” But they don’t realize that it takes effort and infrastructure and cost and manpower to be able to just take those 12, 24, however many IPs, put them in a system, and gain confidence in our protection. You have to invest in that ahead of time. And a lot of companies are only able to do that after they had a breach or they’ve had a scare, or similar.
So really, the difficult challenge is, how do you shift the mindset to the need to invest, instead of just react. To convince people that we need to put processes and systems in place, but you can’t show immediate gain and you can’t show immediate ROI. And it is difficult to do without scare tactics either. One approach is to say, this happened to a similar company as ours. This could have happened to us, this would’ve been the impact. I’ll leave it at that.
ThreatX: Do you think about API security, and if so, is there anything uniquely challenging about API security?
John Brunn: There’s not a lot of good tooling to test API security. That would be the immediate challenge. A lot of the historic web application scanners didn’t work with single page apps, which is a complex web app written to talk to an API. I think part of the issue is that this type of testing requires a lot more effort to really make sure you’re thoroughly testing, to make sure you know what’s going on there. For instance, you can pen test a web app pretty easily. You can spider the site, start throwing info at the forms. For API testing, if you don’t have good Swagger documents, you don’t know what the API can do, it’s a lot more difficult. It involves more teams to be able to properly test it. You have to understand it better. So it’s definitely more challenging.
Our thanks to John for sharing his insights and practitioner perspective with us. Want to be featured in a ThreatX Security Xchange? We’d love to hear your story – contact us!
