Interview with Jon Rose, Dun & Bradstreet
In this wide-ranging cybersecurity expert interview, Bishop Fox Partner Vincent Liu chats with the CSO of Dun & Bradstreet, Jon Rose. The two discuss the commercialization of security, the road to becoming a CSO and how agile helped his security team take control of day-to-day activities and better manage priorities.
You can read highlights of the interview in this Dark Reading piece. The long-form version is below.
Security … Before It Was “Cool”
Vincent Liu: Jon, you’ve been involved in security in so many different ways, but I’m curious. How did you originally get into it?
Jon Rose: I’m inquisitive by nature, and became interested in computers and Linux when I was in high school. At the time, I had a connection to a CTO of a security-focused defense contractor. I interned at the company for the summer, read “Hacking Exposed Linux,” and quickly learned the various tools. That job was my introduction to pentesting and was where it all really started.
VL: What was security like when you were in school; did you even know it was a thing?
JR: There was no security major or classes you could take. I think it was cooler back then. It was more underground.
VL: You were there in the beginning, before security was “cool.”
JR: Security has evolved so much since then. Some of these conferences have become so big and are so vendor-focused.
"Occasionally, I’ll attend a smaller conference where folks are just chatting about hacking, new techniques, and custom tools."
VL: Some folks will argue that the commercialization of security is inevitable. Can you share more of your perspective on security’s commercialization, and how that’s changed things?
JR: I remember when some of the “hacker” certifications first came out. We would talk to people who were certified, and it became immediately clear that they often lacked the background or the interest to explore technologies or systems. What I see, though, is that there is such a demand for people with this knowledge, and because of that, more people are learning security-related skills. They don’t, however, always have the passion that was prevalent back in the day. I think about that when I’m interviewing people. You want people with that hunger and passion, and who ask questions. I’m focused on building a strong team and finding the right people with the right mindset. I’m not necessarily referring to technical skills, but knowing how to effectively problem solve. On the other hand, there is the constant growing list of security products. After a breach, many companies throw millions of dollars into solutions. They implement them incorrectly, and no one knows how to manage or run them. It doesn’t accomplish anything except temporarily provide the image of increasing security.
VL: I see that all the time. Do you feel like other CSOs and CISOs are recognizing that this buy-a-tool approach isn’t sustainable? Are they seeing the holes in “fake security?”
JR: I think many security leaders are just buying things. There’s a lack of understanding about how breaches happen. You have to think like an attacker. The first thing I did at Dun & Bradstreet was staff and build up our security operations center, specifically our incident response program. Bad things will happen. It’s just a matter of when, so you have to be prepared to respond.
The Road to CSO
VL: There are folks who learn how to run a few commands, earn a Certified Ethical Hacker certification, and call themselves “pentesters.” But you were deep in tech, code review, complex exploit chains. How did that influence your current role? Did you have other roles that influenced what you’re doing now?
JR: I started consulting for the government. Then, I moved to New York and worked at Ernst & Young. That was when the major banks started application security programs. We wrote a lot of poorly constructed hacking tools that, at the time, got the job done. After that, I did several stints at various boutique consulting firms, which was exciting because I learned so much since we basically had to “do it all.” I next shifted gears and took a job as a product manager.
VL: How did being a product manager shape you?
JR: That was when I learned agile and how to manage multiple teams and prioritize and organize work. Honestly, I also became much better at managing crisis. As a pentester, there’s not many crises (except if I knock over something important). As a product manager, I was on the other side. We were building systems for customers, and if those went down, the customers couldn’t get any value from them. I remember we had an issue and I panicked. I went to the head developer and he was so calm about how he handled everything. For a few years we worked together, and his leadership style helped me stay calm and manage crisis well. It also helped me to think about customers and software development and the sales cycle. From there, I started a consulting company. I later joined Dun & Bradstreet as the Chief Security Officer.
"One of the things that helps me as CSO is that blended experience of deep technical knowledge combined with the business view from being a product manager and leading agile teams."
VL: That’s an unusual jump to make, from a deep-dive technical assessor to a product manager. Why did you do it?
JR: I was tired of pentesting; it was getting repetitive for me. When I was a consultant, I worked for several startups and I was involved in strategy. Being in that business mindset always interested me. I constantly struggle with wanting to go deep technically and wanting to stay strategic and business-focused. My wife would laugh at me when I switched jobs. I would tell her, “Going back to pentesting ... going to start hacking into things!” And she would reply, “Are you kidding me?” In reality, she thinks hacking is way more fun than management.
VL: How do you keep your hands off the technical stuff?
JR: I try to take time to program or learn new technologies whenever I can, although I find I have less and less time these days.
"At work, I focus on finding great people with deep technical skills and putting them in place to run those teams."
The Advantages of Agile
VL: It’s fairly unusual to hear about security teams adopting an agile methodology. What attracted you to agile?
JR: Dun & Bradstreet is at an interesting crossroads. We’re investing in technology and a huge part of that is security. We previously outsourced our security functions and heavily relied on managed security services. This approach doesn’t always work. After being a product manager in a previous life, I understand agile very well. We started it with the application security team as an experiment. Our work was reactive, and I wanted to shift that. We took control of our day-to-day activities and were able to better manage to our priorities. We also established processes for how other teams engage with us.
VL: What are the advantages from a security perspective?
JR: We began controlling the workflow and managing the incoming ad-hoc work. Morale skyrocketed almost immediately. The “lone wolf” pentesting team started talking about their projects and problems they were experiencing, and ultimately began solving them. It was amazing to witness that transformation. At D&B, we want to change the culture and accelerate the company, driving innovation through technology. Those messages often don’t affect employees’ day-to-day lives, but agile changed how everyone worked. Letting employees shape how their teams work, how they interact with each other, and the processes that they use is empowering.
VL: If other organizations wanted to pilot this more agile method of management, where would they start? Do you use JIRA, which seems to be the major player in agile management software?
JR: We started with Trello before switching to JIRA. I gave “Essential Scrum” to everyone. We asked the developers to describe how they ran their sprints and implemented agile. If you’re new to agile, find some developers and pick their brains. You can learn so much from them. Then, we ran agile with our application security group. You learn how to work slowly over time. Agile is an experiment, and everyone conducts it differently.
"The key is taking that first step and having people on your team who are willing to try, take a risk, and do something different."
VL: So if people feel empowered and that they have some control over their tasks, the better their performance will be and, ultimately, the results. That makes sense. Have you seen other benefits?
JR: People know what to do and they self-organize. Some people were concerned regarding how they would be measured. There was worry that story points would reflect on performance appraisals. For me, those are entirely separate metrics. Traditional agile metrics differ from how you evaluate an employee. It’s all the things that aren’t necessarily the work; those other softer skills are important, too.
The Challenges of Agile
VL: I imagine there were probably challenges created by moving to agile. Can you elaborate on what those were?
JR: Communication problems became apparent. To address those, we put in agile practices and managed the ways that teams work internally as well as externally. Those interaction points are where the frustration generally appears. When it’s not clear, we have issues. I believe in light project management. With JIRA stories, which are how we track work, the further away that work is, the less details we need. As that work task moves closer to the point where we will complete it, we add enough details to successfully execute. Before the project’s conclusion, we then add more detail so we can anticipate the outcome. Some people resisted at first, but now everyone loves it. Responsibilities are crystal clear.
VL: Where does agile work? Where doesn’t it?
JR: Our security operations team — which is naturally reactive — has run into some problems with agile. The team was struggling to keep up with requests. It was a perpetual cycle of trying to keep their heads above water. Agile forced the team to track incoming work requests, prioritize those, and schedule those. While SCRUM works for most project-based teams, Kanban, a different agile method for managing work, is much better suited for operations teams. We are experimenting with leveraging those techniques to manage work now.
VL: Not every request demands urgency.
JR: Yes, and the team could visualize the work so we could manage it better. Agile gave us this much-needed framework for controlling our work. Plus, it allowed us to highlight the crazy ad-hoc requests constantly arriving that the team was trying to coordinate. That would take them away from their actual responsibilities. But because we want to support the business, we generally can’t refuse this work. The real benefit we’ve experienced is that we’ve reset expectations regarding how fast we can complete things.
"We want to be fully transparent about what is happening."
Making Agile Work for Security
VL: Does agile fit perfectly or did you modify it for a security setting?
JR: There will always be adjustments for differing environments and requirements. We’ve had to shift it for our needs. For instance, we’re not releasing code like a development team so it’s a little different.
VL: Where does the manager factor into the equation?
JR: The manager’s job is to help the team move faster and work better. In the daily stand-up, they identify potential issues and then eliminate them. This creates an awesome dynamic between the manager and the team. Above all else, the manager is a champion for the team and always fighting for their best interests. At the daily stand-up, everyone discusses what they did yesterday, what they’re doing today, and any problems. This motivates people to take ownership and accountability for their tasks.
VL: As the CSO, can you commit to two-week deadlines?
JR: Sure – although I don’t manage my work in two-week sprints. My role is different because it’s fluid and strategic. I’m responsible for larger-scale changes to the security organization. I supply the framework, and empower my leadership team to use that framework to be more efficient, so we can meet our objectives.
VL: Do the leads ever meet and update each other on projects?
JR: We have a SCRUM of SCRUMs. The daily stand-up is called a SCRUM. The SCRUM of SCRUMS is when someone from each team discusses what they’re doing and any issues they might be having. It was designed to foster collaboration between the teams. So far, we’ve had mixed success with it, but we’re continuing to evolve and enhance it as we move forward.
Parting Advice for CSOs and CISOs
VL: From your perspective, what are a CSO’s core responsibilities?
JR: As CSO, I’m responsible for building the framework for how we work to secure the enterprise, how the leadership meetings function, how the teams execute, how they interact, and helping to define the processes between security and other groups. Since I’ve arrived, I’ve been shaping the way we work — not just in my team, but throughout the entire company. We have proprietary data from our global database of 250 million business records, updated five million times a day. My highest priority and responsibility is ensuring the organization’s security.
VL: How do you achieve that?
JR: I place the right people in the right roles, make sure the organization’s structure is logical and supports those objectives, and that we are properly integrated with various parts of the business so we are efficient.
"Security doesn’t necessarily speed things up, but it doesn’t need to slow things down. We enable the business by protecting our data."
At Dun & Bradstreet, we’re dramatically changing security, and I’m leading that change. Security is intrinsic to everything we do; from business processes to more technical activities.
VL: What advice do you have for other CSOs who might be struggling with operational effectiveness or other facets of their role?
JR: All CSOs and CISOs share the same principle functions; it’s a matter of fulfilling them. Some CSOs are more focused on compliance and policies - I lean toward the technical side. I also put a heavy focus on relationship building, building the framework for working collaboration, as well as higher-level organizational structure. You don’t need a technical background, but you have to be able to map technical risks to business risks and goals so you can talk to anyone from your board to non-technical stakeholders, and have your message be heard and understood.
Read Vincent Liu's previous cybersecurity expert interview with Dropbox's Patrick Heim here.