The Evolving Role of CISOs

Intro:

If we put ourselves in the CEO and the CFO’s shoes as an example, and every year we come back to them and say, hey, I need more money for this and I need more money for that. And even if they give you all these investments all the time, at some point, they’re going to come and ask, how much is good enough. And I think this is where we need to figure out that good enough may change from time to time. But same thing as the military, right? How much do we spend on defense and how much is good enough? You know, I think that’s the same thought process, the same mindset of working with the business, partnering, enabling, helping to make risk decisions and decide what is good enough.

Conversation:

Hello, and welcome to Secrets of AppSec Champions. My name is Chris Lindsey, and today we’re talking with Yaron Levy, CISO at Dolby Labs. Today’s conversation is going to be around working with your CISO. Yaron, please introduce yourself.

Hi Chris, glad to be here, thank you. My name is Yaron Levy, and I’m the CISO at Dolby Labs. I’ve been with the company for about three and a half years now, and practicing security for over fifteen. I’ve done a bunch of different things in the industry, from e-commerce to financial services, healthcare, and now entertainment. So, different perspectives. Within security, I’ve also done everything from GLC to incident response, application security, security architecture, and cloud security. I love this industry and have fun. It’s great working with people, collaborating, and always learning. So, glad to be here.

Awesome, I’m glad you’re here. So, today’s conversation is about working with your CISO, and I think we’re talking to the right guy. One thing I wanted to bring up is a little bit more on the role of a CISO. You’re dealing with a lot of things at a security level, with developers, networking, policy making, and others. But one thing I haven’t mentioned is the regulators or even the executives—the CEO, the C-suite, the board of directors. Can you share a little bit about your CISO role, not necessarily where you’re at now, but for a typical CISO, how that would play in that space?

When I think about the role of a CISO, it’s a relatively young profession. We’ve only been doing it for twenty-ish years, and we don’t really have a standard for security. We have a lot of frameworks and opinions, but no single standard. If you’re in finance, for example, they have GAAP rules, the generally accepted accounting practices. For the most part, everyone follows the same GAAP rules. If you ask two CFOs how they run their finance department, you’re probably going to get eighty percent the same answer, with maybe twenty percent differences. You take two CISOs and ask how they run security, and you’re going to get two completely different answers. This is still evolving as a profession. I think also many organizations are still not exactly sure what they want from their CISO and what that role is and where it should be. We’re seeing CISOs reporting to CIOs for the most part, which has been the more traditional reporting structure. Some report to the general counsel, some through finance, some to different places, and some directly to the CEO. I think we’re starting to see some changes, but for the most part, it has been viewed predominantly as a technology role or part of IT.

CISO as a Business Advisor

When I think about the CISO role in general, CISOs for me are advisors. They are advisors to the business, on how to enable the business and manage risk by providing security expertise. When talking about security, this also includes regulatory compliance and things like that. Not being compliant with the law is a form of risk or threat to your organization, because regulators can shut you down or fine you. That’s another risk you have to consider and manage as you build or deliver your service. There are many risks, and there’s never going to be perfection. There’s always going to be some level of exposure. Even more than that, businesses must take risks in order to advance, to work, to deliver their mission. The question is, how do we help businesses take risks responsibly, and reduce risk that is not necessary?

A lot of it is about the foundations. We help the organization build a foundation so they can operate, deliver their mission, and take risks, but with those foundational protections in place. On top of that, there’s governance, risk, and compliance. We have to deal with that because it’s not just the compliance side of things, but also managing the risk and putting the governance in place, whether it’s policies or whatnot. Governance, risk, and compliance will help the organization assume or take more risk as needed for the business. On the flip side, we have the whole defense posture, which is essentially how we proactively reduce risks: vulnerability scanning, incident response, application security. That whole defense side is helping us reduce unnecessary risk.

And then there’s culture, because at the end of the day, everyone is part of the security program. For a developer, I expect them to know what the OWASP Top Ten is. Maybe they don’t need to know the ins and outs of network segmentation and routing protocols. It’s good if they do, but OWASP Top Ten for sure.

And then also community. This is probably the best thing we have in security, that community. We have people we can share with and learn from. We need to build those communities inside the organization as well as outside, where we can share, collaborate, and exchange knowledge.

Building Relationships Across the Organization

When we think about all of that, it’s really about how you build relationships and how you work across the organization at all levels, from executive management down to the frontline engineers and employees. Again, you’re there to help and enable the business, to help them take risks responsibly and reduce unnecessary risk. At the end of the day, you really help the business make decisions about how much security is good enough. Because, there’s never going to be one hundred percent. You don’t want to be in a position where you’re ignoring security completely and being negligent. You want to find the foundation, the things that you have to do, and then build that or manage the risk to a level that the organization can manage and that makes sense. As long as you are thoughtful, intentional, and pragmatic about it, you can make a decision. How much security is good enough for your organization?

I felt I had a duty to come and contribute back to my community. That was a great mission, to come and build and improve the security practice. And I did that for nearly five years. After that, I decided I wanted to do something a little bit different. A friend of a friend, who was this former CISO, had decided to leave, and our mutual friend said, “Hey, does anybody want to throw their name in the hat?” So I did, and after a long process of interviewing, I was selected. So here I am.

It’s a lot of fun. I started in the middle of the pandemic, which was really interesting because all the interviews were like this [gestures to video call]. I didn’t meet anybody face-to-face, with the exception of my former boss, who actually flew to Kansas City to meet with me. He said, “I cannot hire a CISO without seeing them face-to-face.” So he got special approval from the company to travel. We met at the old Kansas City airport for about half an hour, both sitting with masks and a little bit distant from each other. We had a conversation, and then he flew back. I joined the company in January of 2021, and the first time I saw somebody face-to-face was in October. So, ten months was like this [gestures to video call]. That’s it in a nutshell.

I guess I never imagined that this is where I would end up or how things were going to evolve, but I love every minute of it. I’m very blessed to have had this journey and these experiences.

Challenges of Remote Leadership

That’s incredible. When you think about starting in the middle of a pandemic in a position where, normally, we’d all be together in the same building or complex, seeing the people who work for us sitting at their desks… starting this role where you’re not in the same city as your colleagues, they’re scattered… being a CISO in this environment is so different than being a CISO prior to the pandemic. The risks and threats are quite a bit different, I would imagine.

Completely. I think first and foremost, and frankly my biggest concern coming into the role, was how do you build relationships remotely? Because we didn’t have the opportunity to go to lunch or have coffee or do something together. When we are in the office, you can walk around, stop by someone’s cubicle and say, “Hey, how are you doing? What are you working on?” We didn’t have that opportunity. Frankly, that was one of my concerns. How do I do that?

I think it worked very well for two reasons. One is the company culture, which is fantastic. People are very collaborative and open. It’s great to work with them, and they really embraced me. For that, I’m very grateful. The second thing is you have to be very intentional about it. You have to spend the time to reach out. You have to spend time with people, not just because you need something from them or have a meeting about work, but to really reach out and build relationships and trust. “How can I help you? What can I do for you? Tell me more about what you do.” Things like that. It’s possible. It may not be as easy, but if you do it with intention, I think you can be very successful.

You have to be very intentional about reaching out. But people within the company also need to reach in. You have multiple different groups and areas for security that fall under you. The role of a CISO, for those who aren’t familiar, encompasses networking, policies, the software side (app sec), and every aspect, including physical security and entry into the buildings. You might be a regular developer working on a development team, and you might have a finding. It might be the weekend or a time where you just can’t reach your boss, but it’s something serious, such as a potential compromise. One thing I wanted to bring up, and Yaron and I had talked about previously, is it’s okay to reach out to your CISO. If you see something, say something.

Absolutely, one hundred percent. I know some people are hesitant because they don’t want to bother anyone. My preference is to over communicate. Worst case scenario, nothing happened. We met somebody new, we learned something. I appreciate that collaboration. We have a lot of things to deal with. By no means do I consider myself the top expert on everything. My team has the knowledge and experience, and people have specific expertise. No one in security can know everything. Security is so vast. But I think our ability to work together as a team, to collaborate, to support each other, with each one of us bringing something unique to the table… the sum is greater than its parts. So, definitely collaborate, definitely communicate, reach out.

Being in the role of CISO is great because you see the whole picture. You see everything. You see the developers writing API endpoints, writing things that receive and send data. And you’re also asking the question, “What if that gets compromised? What can happen? What’s the worst thing?” You start looking at the east-west, the north-south compromise, the ability to move laterally within a network environment. Being the CISO, you see all that. You can pick out things that don’t smell right. Being in that role, the CISO is critical because they come up through networking or software, but they have a good vision of every aspect of security. They also have the right people below them, working with them in conjunction. That collaboration, all the way down to the developer side, creates a very secure mix.

The Impact of AI on Security

I’d like to talk about the evolution of software development. Right now, AI is huge. Everyone is talking about AI. What do you think about all this new AI stuff that’s coming out?

Like anything else, it’s a new technology. We’re relatively early in our journey. It reminds me of the 2008, 2009, 2010 era, where cloud started to become a thing. AWS started around 2006, but around 2008 or 2009, people started to adopt it and play with it. It’s similar to how AI is emerging now, but AI is obviously happening faster. It’s hitting us fast and hard.

I remember conversations from that time where people said, “There’s no way I will ever move my data to the cloud. It’s somebody else’s data center. I will never use it.” I see similarities in AI today. “We are using it, or we’re not using it.” You have this spectrum of opinions, from “Absolutely not, we’re never going to use this, it’s going to be the end of humanity,” to “It’s the next big thing, better than sliced bread.”

The truth is somewhere in the middle. It’s still relatively early. We probably can’t imagine yet the practical applications and opportunities that AI is going to create. Cloud wasn’t just a different data center. It’s a whole business model that was created. If you think about SaaS companies, different apps, DevOps… a lot of things that were created were a result of this whole “as a service” model. That allowed us to scale and innovate. We created a lot of value from a business perspective, but we also created some problems and some new risks.

Like everything else, we have to look at the technology, the opportunity, and consider the risks. We have to decide what trade-offs we’re willing to live with. There are going to be some things that AI is going to be great for, and you can use a lot of its capabilities to accelerate and do a bunch of different things. On the flip side, if you are concerned about data loss, if you are Coca-Cola, you probably are not going to put your secret formula in there. Again, these are trade-offs. You have to make a decision about what’s right for your business and how to leverage AI.

With AI, it’s adding complexity to software development.

It’s adding complexity across the whole spectrum. If you think about the new AI ethical hacking tools… these tools are developed for penetration testers to test against systems, to find weaknesses in the network. One of the jokes I talk about in regards to these AI ethical hacking tools is, it’s basically a quote from the movie Top Gun: “It’s the pilot in the box.” When you look at ethical hacking tools, it’s really the person at the keyboard. What makes it ethical versus not ethical is a matter of permission and perspective. Like you said, every tool can be used for good or bad. There are definitely ways that we can leverage these things for better productivity, acceleration, innovation, and to create a bunch of different things. At the same time, the bad guys are going to use it for bad things.

Evolution of Cloud Security Practices

Like everything else, I think we’re going to evolve. Cloud security wasn’t as much of a thing back in 2008, 2009. Now it’s a practice. We have tools and processes for how to leverage and use it. Again, we’re going to evolve and learn. There are going to be bumps along the way. Hopefully, they’re not going to be too disastrous. But it’s part of the journey.

With security, it’s always a question of when, not if. We’re trying to do our best and kick that can down the road. That’s the best we can do. There are trade-offs. Everything evolves. Two years ago, I would sit in front of a whole bunch of CISOs and ask this question, and it was funny because the room would always get dead silent. My question was, “Technology is moving at such a quick pace. You have kids who can do things today with scripts they find online. They have time, lots of time, and they’re just hitting and doing things because they can. These kids are attacking things left and right. What are you doing within your companies to stay ahead of this curve?” This question was before AI was really known as it is today. That question is so relevant. Now with AI, automation, and the lightning speed at which you can attack with full automation… you just set it off and walk away, come back a couple of hours later, and you’ll have stuff you can start digging into.

That’s true. Again, there are risks and threats. But at the same time, we need to be practical. If we think about the last five, ten, fifteen years, for the most part, if you think about a lot of the breaches, even the mega breaches, they all came down to the same things: exposed credentials, misconfigurations, some vulnerabilities. We have to sometimes… we tend to run after the new shiny object, the new shiny thing. But there are so many fundamental things that we have to do, and those fundamentals are not easy. Sometimes we don’t do them for whatever reason. But for the most part, if we focus on those fundamentals and make sure they are done right, we’re going to be eighty percent there. Even if you look at, again, many breaches, none of them are really sophisticated. Stuxnet was sophisticated, but how many Stuxnets have we had? SolarWinds, you can say was sophisticated. But even if you take something like the MITRE ATT&CK framework… it’s not the end-all, be-all, but for the most part, these are the most common methods that have been observed and used. So start there. Focus on those first.

Empowering Security Teams

That’s where I think we need to evolve and do better. We know there is no longer a perimeter, or just one perimeter. I don’t necessarily think that one security team can solve everything for everybody. That doesn’t scale. So how do we empower, train, and work with the rest of the community to make sure that everybody’s doing their part? How do we get the economies of scale? For example, if you are a software developer, I expect you to know the OWASP Top Ten if you’re developing a web application. I expect you to know the CVE Top 25. For the most part, if we look at software deployment and vulnerabilities, eighty, ninety percent of the vulnerabilities are in the OWASP Top Ten on the website and the CVE Top 25. That’s it.

It’s not that complicated. We just need to be willing to do it. When software developers go to school, they’re not taught security. We’re starting to see classes popping up, or they’re doing a semester, or at least throwing a little bit in. But how many people can you ask to name the OWASP Top Ten right now? When you have someone coming in as an intern or an entry-level developer, you don’t expect them to have that background. You would hope they would, but you don’t expect it. Part of the problem we face today is what I call “notepad inheritance,” where they take some code that could have problems—it may have SQL injection, command injection, any number of potential issues—and they just copy and clone that code from one method to another to do something new.

That’s where software architects should be more engaged with security. As leaders of the development team, they should be more security-focused. They need to understand the security vulnerabilities and the threat modeling. If they’re not doing threat modeling, working with the security team, and understanding the threat model for their applications, you’ve got bigger problems. Then they can mentor the junior developers. “Welcome to development. I know you’re brand new, you just graduated. Let’s sit down and talk about secure programming practices, coding practices, and help you get to that next level.”

ou’re right. At the end of the day, a software security vulnerability is no different than any other software defect. It’s just a different type, but it’s the same thing.

Understanding Threat Modeling

You manage technical debt within your software application, and you can do the same with security. I don’t see that as anything magical or special. The key is understanding the risks and threats. Start with threat modeling. This is an art that is not taught and practiced enough as part of software design. Do your threat modeling. We’re always going to have vulnerabilities for many different reasons: coding practices, technologies, misconfigurations, etcetera. We have to continuously monitor for those vulnerabilities. When you come across something, you check the risk and make decisions. Sometimes we have to prioritize business functionality, and sometimes we have to prioritize defect resolution. As long as we find the right balance, for the most part, we should be okay.

One thing that can help the industry is bug bounties. Think about the benefits they bring. Have you worked with a bug bounty program previously?

We have a public disclosure policy and things like that. Every time you get an opportunity and things are found, there’s an opportunity to become better, as long as you plan for it, manage it properly, and have the staff to deal with it. You can find a lot of interesting things. There’s also a lot of noise. But for the most part, it’s like a free penetration test.

Exactly. You can take those twelve and fourteen-year-olds who have all this free time, who are experiencing and learning… I call it the Minecraft generation, where they have so much time that they’re just digging and digging and digging. That’s what Minecraft is all about, digging and finding things and building things. To be able to take that energy and have them penetration test and hack and try to find something… when they do, the new disclosure laws and the things that companies are doing make it effective. It gives you the ability to say, “You went against our production environment. You didn’t get anything serious, but disclose it to us. We appreciate it.” In the old days, companies would get very upset when somebody did that, and instead of taking the information and saying, “Please share with us,” they would send litigation paperwork. That’s never good.

We have new and better platforms these days to do that responsibly. If you walk down the street and try to open every neighbor’s door to see if you can get in, they’re going to be pretty upset. Probably don’t do that. But if there’s a platform that invites you to check them out and tell them how they’re doing, and you do that responsibly… because a lot of those systems have sensitive information, and you can impact people and functionality. On the one hand, you want to know when you have vulnerabilities and problems. On the other hand, you don’t want to be down because everyone can just bring you down all the time. There are responsible ways to do that, not just for showboating and making a point. It’s helpful. It’s contributing and compensating the researchers. I agree, it’s better these days that we have platforms to do that responsibly. As long as it’s responsible and people work together, it’s usually okay.

Any companies or team leads listening, think about setting up an environment for bug bounties. There are groups like Bugcrowd and others that are out there trying to help you be better. By setting up this environment, you can have people test against it, as Yaron and I were talking about, without any downstream bad effects, no denial-of-service attacks or anything accidental.

Enhancing Collaboration through Tabletop Exercises

I want to change topics slightly. One way to build good collaboration and communication is through tabletop exercises. The value they bring is huge. When you have an event and you’ve done your tabletop exercises, instead of the initial shock and awe of, “Wait a second, something bad is going on. What do we do?” it’s a matter of, “Okay, we’ve identified this event, a ransomware attack or some other adverse event. Let’s hit the ground running and deal with it.” The difference is between your house burning down completely or maybe just one room.

We do these exercises all the time in different places. If you live in the Midwest, we have tornadoes. So we have tornado drills at school, with the kids, or at work. We have building evacuations for fire drills. This is how the military trains. They run drills over and over again because when the real thing happens, people rarely rise to the occasion. They sink back to their training and instincts. The reason we train so much is to build that instinct, that muscle memory, so you don’t even have to think when you need to react.

Security is no different. You don’t want to deal with a breach for the first time when it happens. I think a lot of people make bad decisions under panic. Panic is when you’re faced with a situation and you don’t have the programming to tell you what to do. Are you going to run or stay and fight? But if you practice, train, and simulate those scenarios, you build that muscle memory and knowledge, and you can react much better.

You don’t take a pilot and just send them to read a book and then have them take off with a plane full of passengers. That’s probably not going to end well. You train them a lot on different things. Even when they are trained, they use simulators to gain hours and practice. They can crash the simulator a hundred times and learn from each one. So when the real thing happens, they know how to deal with it. I’m a big believer in simulations, tabletops, and the like. Over the years, I’ve seen a lot of value come from that for security teams.

In one tabletop exercise I ran, we only let two or three people know what we were doing: the director of support, the networking director, and the CISO. We called the support desk. We set up a new environment and mimicked a ransomware attack. We didn’t actually launch one, but we mimicked it. It wasn’t one of the normal ransomware variants. We had someone act like a customer and call support, saying, “I’m seeing this weird thing. Can you help me?” We learned about the amount of time it took to get to the right group and identify what was going on. We had a stopwatch and started counting. By the time we got to the right group and identified what was going on, the whole place was basically gone. Had it been a real ransomware event, it would have been terrible. But we learned a lot from it. We learned where the mistakes and hiccups were. We learned about the time it took from when the support person received the call to when it reached the right people. We identified deficiencies in our documentation and were able to improve it.

The next time we did this exercise, we had multiple shifts, daytime and nighttime. We kicked it off again after a couple of months and did the same event, but slightly different. We called the night shift people and said, “I’m a customer. I’m seeing this weird thing. My files are encrypted.” By the time it got to the right people and the right people did the right thing, it was like my analogy earlier: only a small footprint was affected, versus the whole environment being taken down.

Mike Tyson, the boxer, once said, “Everyone has a plan until they get punched in the face.” By doing these exercises and simulations, you can test your assumptions. Through real-life simulation, you can see if your response is sufficient and if your response time is fast enough. We make a lot of assumptions when we plan and build things. It’s the nature of the beast. You don’t have much choice because you don’t have all the information. But when you test it and see how it operates in real life, you can say, “Okay, we need to make some adjustments.” These simulations give you great empirical data to help you make those decisions.

Continuous Learning in Security

I’m going to ask you two questions. I’m curious about your thoughts. What is the best advice that somebody has ever given you regarding security?

The best advice? I guess it’s that you’re always a noob and should never stop learning. The field changes so much, and there’s so much to learn. I don’t think there’s anybody who is an expert, per se. As long as you keep learning and keep yourself up-to-date by talking to people, teaching others, collaborating, and going to conferences like OWASP… those are great places to collaborate and learn. Never stop learning, because otherwise you’re going to get stale. That’s what I’m finding really helpful.

That’s rock solid. If you’re not moving forward, you’re falling behind. I hate to ask this, but what’s the worst advice you’ve been given?

The worst advice? I don’t know if it’s advice, but it was a perception I encountered throughout my career that security is the police, the enforcer, and everybody has to go through security for approval. That’s not right. First of all, we can’t scale that way. Second, our job is not to go around and punish people who misbehave. That’s not our role. We’re more like the military, not the police. Our goal is to help secure the organization so we enable the organization to deliver and work on what they need to do, as opposed to punishing everyone who misbehaves. Sometimes, as an industry, we shoot ourselves in the foot with this “gotcha” mentality. That’s something we need to get beyond.

Yaron, this has been an amazing conversation. I know you and I could probably speak for hours about the role of the CISO, programming, and security. Thank you so much for taking the time to speak to our podcast community. I really appreciate you coming and doing this.

You’re very welcome, Chris. Thank you for having me. It was a lot of fun. I’m happy to be back anytime.

Thank you so much. Thank you for joining us today on Secrets of AppSec Champions. If you found today’s information valuable, hit that subscribe button on Apple Podcasts, Spotify, or wherever you’re listening. Ratings and reviews are like gold for us. So if you’re feeling generous, please leave us a kind word, as it helps others find our show. Until next time, take care.