Application Security

XChange Security: John Brunn, CISO

XChange Security: John Brunn, CISO
Written by ga_dahmani
XChange Security: John Brunn, CISO

Welcome to ThreatX Security Xchange – our blog series featuring security professionals and leaders who do the daily 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 his work, but understand a little more about his pains, priorities, passions, and pet peeves. We hope you enjoy these profiles; Tell us if you want 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 roles at numerous companies, including Lookout, Hotwire/Expedia, and Cmd.

threatX: You’ve had a variety of security roles throughout your career, which one have you enjoyed the most?

John Brunn: I really like my current CISO role. I have more responsibilities now than in other roles, which means I’m less practical, which I miss. But it’s also very satisfying to build a great team and be able to solve difficult problems together. There is a lot of pride in work.

threatX: What is your process for evaluating a new security technology you are thinking of purchasing and implementing?

John Brunn: The important thing is always to say, “what are we trying to solve?” You have to be careful with having a hammer and looking for nails. We don’t want to do “management by journal”: “I just read about X, let’s add this here.” Rather, what are we trying to solve? Also, many 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 still not installed, that’s a big deal. Therefore, we must be aware of the true cost of ownership, including general administration and maintenance. For example, are we going to install it and then leave it? What are the integration points with our existing tools?

The important thing is always to say, “what are we trying to solve?” You have to be careful with having a hammer and looking for nails. We don’t want to do “management by journal”: “I just read about X, let’s add this here.”

threatX: How do you know when a technology is working for you?

John Brunn: There is always the question of whether something was bought to add value, reduce risk, or check a box. Monthly, or more likely quarterly, we should reevaluate our solutions. What is our threat landscape? What has changed for us? Do our tools really address the new threats coming in, do we need to request new features, or do we need to start re-evaluating the vendor entirely? But this process is often challenging because vendors will say, “Oh yeah, we have that in the audit trail somewhere.” But if I can’t easily access the data, if I can’t integrate it with other data sources, I can’t get a true picture of my threat landscape, or now I have two processes.

There is always the question of whether something was bought to add value or to check a box.

threatX: What is it about the threat landscape you experience and see day to day that 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 our security program posture to all of our customers. And we try to talk about risk. And many times talking about risk is not a common vernacular in many organizations. They can talk about CVSS, which by definition reports risk, but it’s not risk. That’s why we put a lot of effort into certifying our security controls and the overall security of our products across our entire customer base. And that leads to a lot of effort that doesn’t analyze our risk threats, which makes actual threat management more challenging. We incorporate industry best practices as well as customer feedback into our reports, but it’s challenging.

threatX: What would you like more organizations to know about detecting and responding to attacks and breaches?

John Brunn: Oh, where do you start? I think the hard part is that there’s 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 modify this alert and look for exactly that threat.” with immediate results, or have the visibility to ensure that a SolarWinds type violation did not occur. Someone might say, “Hey, here are the IP addresses that were published and potentially used in this attack.” But they don’t realize that it takes effort, infrastructure, cost, and manpower to be able to take those 12, 24, no matter how many IPs, put them in a system, and gain confidence in our protection. You have to invest in it ahead of time. And a lot of companies can only do that after they’ve had a breach or had a scare or something similar.

So really, the difficult challenge is how to change the mindset to the need to invest, instead of just reacting. To convince people that we need to put processes and systems in place, but you can’t show an immediate win and you can’t show an immediate ROI. And it’s not hard to do without scare tactics, either. One approach is to say, this happened to a company similar to ours. This could have happened to us, this would have been the impact. I’ll leave it like this.

threatX: Do you think about API security, and if so, is there anything especially challenging about API security?

John Brunn: There aren’t many good tools for testing API security. That would be the immediate challenge. Many of the historical web application scanners did not work with a single page application, which is a complex web application written to communicate with an API. I think part of the problem is that this type of testing requires a lot more effort to make sure you’re doing a thorough test, to make sure you know what’s going on in there. For example, you can perform a penetration test of a web application quite easily. You can crawl the site, start throwing information in the forms. For API testing, if you don’t have good Swagger docs, you don’t know what the API can do, it’s much more difficult. Involve more teams to be able to test it properly. You have to understand it better. So it’s definitely more challenging.

Our thanks to John for sharing his knowledge and perspective as a professional with us. Does he want to appear on the ThreatX Security Xchange? We’d love to hear your story, contact us!

The charge XChange Security: John Brunn, CISO first appeared in ThreatX.

*** This is a syndicated Security Bloggers Network blog from Web Application and API Protection Blog written by Suzanne Ciccone. Read the original post at:

About the author


Leave a Comment