The art of security transformation

[00:00] Intro: This is the Cloud Security Today podcast, where leaders learn how to get Cloud security done, and now, your host, Matt Chiodi.

[00:13] Matt Chiodi: Niall Browne is the Chief Information Security Officer at Palo Alto Networks, my former employer, and I wanted to have Niall on, not only because he has an awesome Irish accent, but because he's a really cool guy in a really awesome role. Now, as the CISO at Palo Alto Networks for the past four years, he has been there as Palo Alto has gone through a massive transition. As many of you know, five years back, Palo Alto was known mostly as a firewall company. Well, now they've gone through a transition from being not only a firewall company, but a Cloud company, and now an AI company. So, I wanted to have Niall on, because I really wanted to understand how he accomplished such a massive transition from a cybersecurity perspective, because as you go through that, a large brand, very established company, there's work that you have to do, and it's not only about technology, so we really dive into how he got developers bought in, how he got different areas of the organization bought in, and I hope you find this useful, because I certainly found that interesting. So, as I always say, if you like what you hear, please leave us a five-star review wherever you listen to your podcast. Thanks, and enjoy the episode.

Niall, thanks for coming on the show.

[01:35] Niall Browne: No, thank you very much for the invite, Matt, this is going to be fun.

[01:39] Matt: So, as we were talking about before we recorded, a lot of times when folks are earlier on in their career, they look at where someone is today, and they just assume “what I'm doing today, it's not going to get me there,” and the reason I bring this up is, when I was looking at your background, I saw that back in 1997, you graduated from the University of Limerick and then you took your first role as the security webmaster at the Bank of Ireland. So, I'm curious, today, you're obviously the CISO at Palo Alto Networks, the world's largest cybersecurity company. I'm curious, what experiences that you had at the Bank of Ireland, what did that teach you today that you still use?

[02:24] Niall: Yeah, I mean, great question. I mean, I would say, for the most part, when I was working at the bank, I started, I would probably say, you should always be willing to change and pivot. When I started off in Bank of Ireland, I started off as a network analyst, so very much based on LANs and WANs and network infrastructure, and at that time, they were one of the largest banks, the second largest bank, tremendous amount of ATM machines, tremendous amount of phone systems, but no internet. So, from them, they were moving a transformation to the internet, and back then they did a pivot around the room, they would say, “well, we're moving to the internet. We're putting our online portals, our banking services online. Who would like to help as part of this service?” And what I found is a significant portion of people said, “No, I'm happy doing email. I'm happy doing telecoms. I'm happy doing infrastructure from that end.” For me, I was looking at, I said, “Well, that sounds like a really interesting area. By the way, this thing, the internet, could grow pretty big as well.” So, I jumped in there, joined as a security webmaster. I joke to this day that that was the coolest title I've ever had. So, forget about CISO. CISOs are a dime a dozen, but security webmaster, that's got schtick, without a doubt.

So, it was fascinating working there, learning as much as it could, and learning, whereby as soon as you're in one area in one industry, and if you look, you should be ready to pivot at any one time from that, and especially in relation to technology, security, digital transformations, you're going to see very quickly that if you don't, then you're going to be left behind, and that I think, too, as a business, if you look at the bank, from there, it was very much a bricks and mortar infrastructure, and very nascent, starting on going on a digital transformation journey from there. So, it was super exciting to be part of that for, whereby it's taking the banking, moving it all online as part of that platform itself, and then just seeing internally, which processes or teams worked well, but which ones didn't work well, from there. That was really an eye-opener for me.

[04:33] Matt: I love that. So, it's a certain level of curiosity, and I'll tell you from speaking with leaders from all over the globe and in the various different industries, that what you're talking about is just curiosity, so I'm curious, for you, because I'm a curious person. That's partially why I do podcasting is, was there something that you saw at the time, it's easy to look back in time and say, “we'll of course, the internet became a big thing,” but nobody really knew that in 1997. What was it that maybe caught your attention? And the reason I asked this, again, is people who are earlier on in their careers tend to think “hey, what I'm working on today, either it's not important or it's not getting me to what they want to do next.” I'm just curious, for you, specifically about that time, what was it that caught your attention about this developing internet thing? And maybe how do you think that might translate to you some of the business transformation we're seeing today with the move to digital?

[05:41] Niall: Yeah, so I think it was very much a case of looking at what worked locally, internally, and then what could work in scale. So, locally, run a LAN, LAN might connect into WAN, but then it pretty much stopped there. If you wanted to connect to somebody else, then you had to use BC leased lines and ISDN, and all the rest. Now, BC was the internet, would become the next level of evolution. LANs, WANs, intranet. Now, you could globally communicate with anybody across the world, and for me, that was super exciting. Second part was the concept of self-service. Nobody likes interacting with a bank through the telephone. So, if you can do self-service, that's hugely beneficial from there. So, for me, it was really those things of looking at what I was currently doing, what's that next evolution? And then really, what could I be part of? How could I be part of that journey from there? And in some cases, it's been a case whereby I've looked at this, and said, “now’s the time to make a change,” and then there's other times I don't want to make the change, but the industry is moving so fast, I've got to pivot, and one simple example of that is at one point, I was a security architect.

So, I was a firewall instructor, used to go on to customer sites, we architected infrastructure, we built it from the ground up from there, and really enjoyed that job. One of the most fulfilling jobs whatsoever. You go into a greenfield site, or else a broken site, you take it apart, you rebuild it up, you have a great security infrastructure, and then you leave, and then you're in a great position from there, and what I've noticed there at that point is that I was also a security instructor. So, every week I might train 40 or 50 people, and then just looking around the room, I was like, “these 40/50 people, they're getting good.” In other words, and I was like, “they're getting good. There’s 50 in next week's, another 50 in next week, and that's the competition going forward.”

So, if I were going to stay in firewalls, where I was super comfortable, I loved doing it, over time, I would just be eroded and became a commodity. So, in that case, I said, “Well, I love to do firewalls. I would love to continue to do firewalls, but I need to pivot.” So, I pivoted BC from networking in architecture, and I still do it to this day, but I also started pivoting into this new thing called basic information security. So, it was the Policies and Procedures and Standards Guidelines that frameworks. So, that was a really insightful BC, taking as you move into an area, try and master it as much as possible, I find is useful, but be ready to move to the next process, and the next one, and the next one. I've done that throughout. I’ve generally done networks, and then I did information security, then I did risk management, then I did audit, and then so on, and then over time, what you find is you've got a shopping basket of things you can do, and if you've got a shopping basket of things you could do, well, you can probably manage that shopping basket and then you can start building teams, and then you can start basically moving towards directors, Senior Director, VPs, SVP-level. So, that for me was truly insightful. You've got to continuously jump, master that area, jump to the next area, master that, and keep on doing that at scale. For me, I think that's what makes it truly exciting.

[08:56] Matt: So, you've worked at some really amazing places over the course of your career. Dell, Yodlee, Workday, Domo, and now for the last four years, Palo Alto Networks. What are you most proud of? And I know that's probably a hard question, but what's top of mind for you?

[09:12] Niall: Yeah, I mean, it's an interesting one. I can think of three quick short stories. So, one would be when I was at Workday, and we were building security in the best controls in the industry, but also there was a concept of, if you build security controls, how do you get credit for it? How do you get the largest customers in the world to trust you? How do you get them to trust you with some of their most sensitive data, their HR data, financial data? And how do you get them to do that in an unknown platform called Cloud and SAS? So, that was fascinated working with some of the largest organizations in the world. What were their requirements? And we often look at apples to apples and say, “Well, if I want this, somebody else would want the exact same thing,” and it's totally different from what somebody would want in government, is different from what they want from The Financial Services, which is different somebody will want in retail, to nuclear industry. So, that was a really unique opportunity to look at, what are the demands of Cloud? And then, how can we provide that in an efficient, operationalized way, because you don't want to have assessments that last 2/3/4 years. You want it to last 2/3/4/5 days from that end.

So, building a model program at scale, whereby we can get the large organizations of the world to trust the most sensitive data, put it in the SAS, put it in the Cloud. So, that was super interesting, and then after that, then you've done that, you're like, “Well, what's next?” And I done HR data in the Cloud, and then I was like, “Well, what about all the data in the Cloud?” So, then I joined Domo on data analytics, and that case, we had every type of data in the Cloud, and we were looking at how do we protect that data at scale, and especially for a lot of regulatory environments, whereby they've got super specific requirements. What data is in there? It's not HR data. It's not financial data. It's every type of data. So, that was very interesting, and then finally, just at Palo itself, it’s a fascinating opportunity, whereby you have a company that has transformed basically from that network company to a Cloud company, and now to an AI company. So, it's working through those stages of the digital transformation, and then ensuring, how can you build a security program, a trust program, to scale with that level of change, with 110,000 customers around the world?

[11:34] Matt: Let's jump to that because I think you mentioned a good point there about how Palo Alto has gone through a really massive transition, and most of my listeners know, I used to be at Palo Alto for a while. When I was there, we went through that transition from a firewall company to a Cloud company, and now post-my leaving, AI. So, I think for people to get some perspective, that means from the code that’s developed to platforms like Prisma Cloud, Cortex, those now all run in the Cloud. Talk about it maybe from, how did you approach that transition from a risk perspective? Are there frameworks, like NIST/ISO? What are you using? How did you approach that shift? And maybe, what are some of the key metrics that you tracked, or are still tracking?

[12:24] Niall: You're sadly missed there, Matt. You can come back anytime you want. So, I think, the model, you nailed it with your question. You’ve got to protect it from the code all the way up supply chain to Cloud. So, we call it Code-to-Cloud. So, how do we project from the developers fingers in the keyboard, developing code, all the way to when it's shipped in Cloud infrastructure? It's running, and it's in runtime from there. So, we looked at, how do we build that holistic security program? And it's an interesting model, because if you look at the tech stack, and you say, “I own that tech stack.” No company does from there, because for the most part, I would say 85/90% of all companies will run is on other people's third party's code or operating systems from there, so you've got the challenge of that need to protect that application than an application sits on a container, container sits on an infrastructure, and then so on, and so forth, and we looked at, for every one of those, how could we codify those?

So as people were building software, using SDLC, that was pretty much a tried and tested model, which is good. So, we ran with that model from there. Now, could we do the same thing with operating systems? Sure, we could. With images and containers, we could also use a code-based model, whereby, as people are building infrastructures and environments from there, they're doing it in a manner whereby it's operationalized as part of the secure CICD end-to-end, so I want to environment, well, then you’ve got to use the latest base image, with the latest configurations, with the latest standards from there, and if you don't, then you can’t ship into that environment, and then if you can do it for containers, then you can do it for supply chain as well.

So, as there's 10s of 1000s of libraries running back and forward, how can you check every single one of them? How can you look at open vulnerabilities? How old they are? Who are the owners? Who contributed last itself? Had they been compromised in any way? And then make a real-time decision on whether that should go into production. Same thing with Cloud. In the old days, people would log into systems and start making changes manually. Cannot happen anymore. Now, with the move to infrastructure as code. Now you can do secure infrastructure as code, and if you can do secure infrastructure as code, you can ensure that people don't jump on to Cloud environments to build to make changes. They've got to do code to Cloud, which means you can put some patterns in place whereby they’ve got to have these org policies and controls, otherwise they can’t ship into that Cloud environment.

So, it's really that holistic model of, how can you treat every single change in production the same as if it was a software change, whereby you can manage it, you can operationalize the, put the security controls? And then one of the things I'm very much a fan of is BC shift left, break build. So, that's the model whereby, shift right is you find a fix, and you go fix it from there. Problem with that is tremendously costly, because one issue is probably duplicated 20,000 times, but if you can do a shift left before it's introduced into production, then you're an exponential better job. So, we've shifted the vast majority of our controllers, start with shift left, as close as possible to developers. So, give an example is, if they tried to add a sequence into code, very quickly they’ll get an emerge request that say, “you shouldn't be doing this. You should be doing that instead. Are you okay with changing that?” And they've got a yes/no answer as part of that, or if not, we block them.

So, we've started doing a shift left, break build, and really helping and empowering the developers to do the best practices, and do the right thing. Now, you can't just do that and just start breaking builds. So, we built a whole suite of tools and technologies to empower and help them there, and then obviously, on the shift right point of view, even if you shift into Cloud, you can still get a compromise in the production environment. So, many of our calls are shift right. We're looking at runtime. We're looking at drift detection from there. So, I would say it's probably those two things. One, Code-to-Cloud, and then, two, BC shift left brake built. So, we can get the same level of security on software as we can get from containers, as we can get from any of our environments.

[16:44] Matt: So, I've talked with probably hundreds of customers who are either well down that path, or they are moving down that path to shift left. The challenge that I often get asked about and I hear about is that there's pushback from developers. “Hey, you shouldn't be breaking my build.” So, I guess my question for you is, what was that transition like? Obviously, Palo makes great tools, but you can't just deploy a tool and expect every developer to take them on. What did that transition look like? And how did you maybe overcome some of those objections?

[17:27] Niall: Yeah, I mean, luckily, we had to build to use our own internal tools like Prisma Cloud, and that made it exponentially easier, but you're right. Just that alone doesn't solve the problem. So, we took it a model of each of our products. We may have 60/80 different products, from that end. Which one of those are the most difficult? Which ones are the easiest? Which ones have the most complex problems? Which ones have the simplest ones? So, we looked at the ones that were smallest, the most friendly. We built a service. We work on services, so we built it once, and that was shared many times. So, the same as Salesforce, or Workday, or ServiceNow. Build it once and everyone's on the same platform. So, we built that service for secure software and building it from there. Second of all, if we found the friendliest space, the smallest product teams, can you take a chance for us? And they generally said, “yeah, let's do this,” then what we would do is we would do a shift left, and would run it for three or four months, would say, “Listen, three or four months, basically, we're not going to make any changes whatsoever. We're just going to get visibility from that end, but we're going to work with you on a weekly basis. Oh, by the way, that's a high vulnerability. That's a medium vulnerability, and then we're going to work through those issues, and eventually, what we're going to do is we're going to get you, as the product owner itself, comfortable enough to say, “I want to break the built,’” because from that end, every time we would ping them to fix issues on production, i.e. shift right, it would take a huge amount of resources. So, if they would stop introducing vulnerabilities, it was much easier. So, we would always empower them as a product owner, to make a decision when they are ready to break build, and break build is very difficult.

As you know what to do journey, we will find it within, I would say within three to six months, that's the timeline, basically, the product owner says “yep, now's the time. We have the data. We're not shipping many vulnerabilities. Let's break build from there,” but the only thing about that, if you think about it, if you break build, you're on the hook now. So, it means that people are going to be calling you 24/7, say “you broke my build, and I need to ship it straight away for a customer,” and so we introduced the concept of break glass. So, as it goes through there, it means that as a developer is going through, they can break the glass and they can ship a vulnerability into a dev environment if they want. So, if they need to do testing overnight, sure, we'll facilitate that. So, it allows them to override the security control. Now, they can ship directly into production, but they can override it from there, and then we'll sit down with them afterwards say, “Well, why did you override that?” and the vast majority times, it's valid, “well, your product didn't or your tool, the way you configure it, the sequence detection, wasn't able to detect a certain problem.” So, and it was “all right, we'll fix that” or it could be their issue from there, but really, I think the two things that were very powerful for us, one, is basically saying to that product owner, “you are in charge. You can tell us when you're ready to break build.” So, it gave them all the power as opposed to me coming in and telling them what to do, and then, two, I think, the ability of having a break glass mechanism whereby if they're ready to ship it from there, they can ship it into another type of environment without slowing down their operational capacity.

So, building that partnership, building that trust with the different teams was critical. If we went in day one, and we said, “the most complex product. We're doing shift left break build tomorrow morning,” 100%, it would never ever work, and it really ties back into, everything in security is a journey. When you think about it, you can't go in there into any organization, say, “Thou shalt have x, y, these controls, you need to have them, and you need to have them next week.” That never works. Instead, “this is where you may be, this is where you want to go, here's the journey the security team can work with the different teams in doing that.” I firmly believe the journey, facilitation, collaboration, that works much better in these environments.

[21:44] Matt: I love that. I think that partnership angle is often missing. The much said, security was often thought of the team, now I think that's changed over the last couple years, but I think the relationship that you built, is just so credible, and I think that's often what gets missed is that security is often seen as not only a bolt-on, but just not as a partner, and I think that that's really big, and the only way that you build that relationship is by having that constant communication, where it's not “you will use. You will do,” but it's like, “we have this tool. Would you be willing to try?” and teaching it that way. Most people, I think developers, particularly, a lot of people became developers because they got tired of doing something manually, they learn how to code it, and now they want to automate it. So, I think a lot of times, it's how you couch certain things with them, like, “Hey, we're going to try this experiment. May not be forever. May be just three months.” I think that's a big part of building that relationship and getting that buy-in.

[22:51] Niall: Exactly.

[22:53] Matt: So, I guess a follow-on to that. Now, Palo, you guys have been in the Cloud now for a couple of years. We talked about how you've codified many things. How do you keep a pulse on that risk? Like you said, you can do shift left, and that will, not eliminate, but it will greatly reduce the number of vulnerabilities that are being introduced. It should quiet things down, in terms of a tooling and alerting perspective, but you still have drift. You still have zero days that come to the environments. How do you keep tabs on all the different CSPs and all the different dev teams that are operating across, probably all three of the major Clouds? That's 1000s of accounts. How do you get some sense of where you are at from a risk perspective, if things are trending in the wrong direction? I know you can't give us specifics, but what does that generally look like for you?

[23:49] Niall: Yeah, I think it's probably two things. It's integration and automation. So, the fact we've on-boarded BC software and containers, and infrastructure on to secure CICD means now that we're in the middle, we can look at all the traffic going back and forth, either on this shift left side, close to the developer, or on shift right in production, and we can get a general sense, basically, of what are the vulnerabilities that are out there? So, that really empowers us at any one time, if we can say, “well, how many containers have high vulnerability? How much software itself? How many secrets are in code itself?” And ideally, the answer is obviously always zero in those scenarios, but you can get that visibility stuff. Once you have that visibility, and you have that metrics, then if you have the metrics, but you're not sharing with anybody, that's no good whatsoever. So, what we do is each of the different teams, the security teams, we have the concept of service reviews, and every month we sit down with every product owner, and we do a service review with them, and it's generally half an hour, an hour-long session, running through all of those metrics.

So, for product, how many will be a critical/high/medium/low vulnerability? Same thing as well for your Cloud infrastructure. Same thing as well for your partners’ external vulnerabilities that are there. I will run through the vulnerabilities, and the key thing is, we’ll trend them, because if I said 32, you're just “I don’t know what 32 is. Is that good or bad?” So, we’ll trend, “by the way, before you were 1000. Now you're 32, but 32 is great number then for a vulnerability survey.” So, we'll look at the trend and see, you’re trending up or trending down, and then the way we communicate them is simply the model of, again, if they stop introducing vulnerabilities on the shift left model, now they stop the bleed.

So, the great thing, if you stop the bleed, you're in a great position going forward. You're virtually done to a certain extent. Now, the thing is, you still need to fix all the technical debt that's out there, which is a huge thing, but it can be managed bite chunks from there. So, we'll say to them, “listen, you've got this technical debt from there, and then we'll triage it,” and we'll say, “let's just take it out. Can you go fix maybe 8/9/10/12% of those every month?” And they're like, “Oh, cool. That's great. I thought you would ask me to go fix everything.” No, it will take 6/8/9/10/12%, and then if they take that model every single month, they can take bite chunks of the technical debt, and then very quickly, there'll be a point whereby all of that technical debt is washed away, and in the meantime, they see anyone who's shipping, can't ship new vulnerabilities going forward. So, it's that model of, how do we get visibility? How do we build the metrics? How can we sit down with them in service reviews? And then it's that conversation. Again, it's not us telling them what to do. It's not them telling us what to do. It's more of a conversation. “This vulnerability there? Well, don't worry about that, because that datacenter is going to shut down, or that VPC is going to shut down. Well, that's fine. That makes a lot of sense, whether you have something that's exposed externally from the internet, well, maybe you want to go fix that pretty quickly from there.” So, again, it's that partnership of trust. I think it has worked really well above.

[28:07] Matt: So, one of the topics that I had a guest on probably maybe two or three months ago, who talked about the new SEC cybersecurity disclosure rules, and that has caused a lot of speculation, that's caused a lot of indigestion on the part of security professionals, and it brought up board-level conversations, because now it basically forced the issue where before maybe boards, obviously, they were talking about it before but this made it something they really needed to talk about. I'm curious, from your perspective, when you meet with the board, you've met with boards before, not just in Palo, what have you found effective, in terms of communicating risk? I put this in the context of, most CISOs that I know, they may get a half-hour a quarter, sometimes a little more, sometimes less, to talk to the board, so they've got this really small piece of time as part of an overall board meeting. What have you found that actually works? If you're to council, maybe somebody who's just stepping into this role, maybe they've never talked to different board members before, what have you found to be effective, in terms of communicating risk, and then maybe what are some mistakes that you've made in the past and be like “yeah, this didn't work. Don't do this”?

[29:26] Niall: Great questions. I think for the most part, and I would chunk it into if you look at board members from there, firstly, not all boards but significant amount of boards out there, they're really smart and the reason they’re on the board is the reason they're on the board. They're many skilled, they maybe have financial skills, accounting skills, they may be the leaders in business, but the mind have that cybersecurity background, likely they probably don't. So, if you go in there talking about cybersecurity, MTTR, Mean Time To Respond, “What’s 32?” It doesn't make any sense to them there, so instead we try to organize, how do I speak with them in business terms? How do I make this a business problem? “Here's what the business issue is, and here's where our security solution to this business problem is.” That generally resonates very well, and I will obsess about the deck.

So, on the presentation, you never want to go in there pretty cool, you're just talking about basically, “here's what we're doing. We'll spend a lot of time on the deck,” and the deck should still tell a story. They should be able to read the deck and not even speak to me. That's the ideal scenario itself, whereby they look at the deck, and it's clear enough, concise enough, and answers the questions in a manner whereby they don't have a lot of questions when you go into the room. When you enter a room and they have a lot of questions, that's great as well, because there's a lot of insightfulness and a lot of conversations back and forth, but it's really the model of making it whereby, as you're communicating from there, they read the deck, they have a pretty strong sense of what the security model is from a business term perspective, and after that, then when you go in there, you're not reading from the deck. For the most part, it’s just like “next, next, next, next.” For the most part, it's just that conversation back and forth. “There’s a new area we heard of, maybe AI itself, what are you doing in that area?” “Well, we're doing this, this, that.”

The other one I would put in there as was very important as you can't go into any board and say, “Hey, we're going to 100% security,” because that never works. 100% of business modeling. What is that from there? So, being realistic, what's working really well? What's not working? And then what are some of the really big risks that are doing? for me, I think that model works really well, and then last but not least, I think as you read a book, you don't go to chapter 12 in the book. You start at maybe chapter one, and then you work to the next one, next one, next one. Same thing with a board. You don't want to say, “hey, this week, I'm going to talk about, or this month, or this quarter, I'm going to talk about SDLC, and next month I'm going to talk about IoT, and the next month I’m going to talk fiscal security.” They're just like, “he's all over the place.” So, what we generally do at the start of the year, we come up with a taxonomy itself, and a narrative of what areas we talk about, and generally, maybe 4 or 5 board meetings per year, and we'll start with high level, and then we'll do a deep dive, and the next one might be on AI, and somebody else might be on zero trust, and that way, you can stay high level, and then every quarter you do deep bring into a particular section that they're interested in.

So, for me, I think it's that conversation, and then last but not least, know your board. So, I think it's very useful to look at the board members and pick two or three personas across the board, that generally fit the board, and then pitch to those two or three personas from that end. That way, you could have somebody on the board who is a politician, you could have somebody on the board who’s finance, you could have somebody in the board who's a VC, and if you know what the personas are, then you can make sure that you're articulating, you're communicating effectively from there, and they get it, as opposed to me talking about cybersecurity mumbo-jumbo and 1000 metrics, and at the end of it, they're “NIST, ISO, FedRAMP, IRAP.” They're lost from there, and I think they will probably be the main points.

[33:44] Matt: I think that's really helpful. So, I want to go back in time a little bit here. So, back in August of ‘22, in doing my research here, I found an article that you wrote. It's on CSO online. We'll put a link to it in the show notes. It's called Doing More With Less: The Case For SOC Consolidation, and what I thought was interesting about this piece is that actually seems even more applicable today than roughly two years ago, when you wrote it. I've not spoken to a single person in security in the last six to nine months, who hasn't said that they're being asked to do more with less. So, you've been at Palo for over four years now. How have you shifted the SOC to do more with less? Give us some examples. Tell us what’s changed, what it looked like maybe four years ago when you joined, and how does it look today?

[34:36] Niall: The more with less is a key because, as you pointed out, every business unit is asked to do that. So, when we look at the SOC, when I joined the SOC four years ago, there were eight analysts. In the interim, Palo has grown exponentially. Now, if you went into the SOC this morning, you'd find 10 analysts. So, in the last four years, we've added two analysts alone. That's it, and the key component of that is, we don't want to be solving security problems with people, because you never scale with that, then you hire 10/20/100/200 from there. So, we've really focused in on having 10 core analysts there that can manage and support that business from there. How have we done that? We've looked at how do we build that security operation center, the next generation security operations center, using tools, products, like EXIN, and XOR, and how do we automate? Looking at, for us, basically pull data from as much or as many sources as possible, you always want to get 100%. Then we'll apply machine learning against that, and we'll try to find those needles in a haystack, and once we find the needles in the haystack, then you don't want to send those directly to those 10 analysts, because if there's 140 issues a day, you said it, that those 10 analysts, now, they’re looking at 14 orders per day, they get blown away

So, instead, you’ve got to do automation and orchestration. So, we use XOR as part of that series of playbooks. Those 140 issues go into automation orchestration, and then at the end of the day, you really want to have maybe around 10/12 core instance that you're working on, they're going back to those SOC analysts. Now, what happens is you're using the power of the platform. So, you're using the model whereby you're using machine learning, using automation, orchestration, to get the right alerts to the right analysts at the right time, so that they can take that right action. For us, that's been critical, and the good thing about that is now the analysts are spending less and less time at boring alerts, because the vast majority of alerts don't provide a lot of value in most organizations. So, now, if they're only spending 20/30% on alerts, well, they've got a lot of free time. So, now they can spend their time improving that service, or else threat-hunting from there. So, now what you have is a team of a SOC analysts and engineers that I believe are world-class, and instead of focusing on the same issues, boring, repetitive ones over and over, they're continuously looking at, “let's do a threat hunt in this, or let’s build a new service for that, or let's improve this. Their automation doesn't work, we're going to go fix that, or we missed 10% of issues. Well, for those 10% of issues, we should start building machine learning in our analytics. What did we miss there, and how do we improve that service?” So, it's really about, I think we've flipped the SOC analyst/engineers to a model whereby now they're continuously improving that service, and we're very cautious about adding new SOC analysts from there, because, again, throwing people at a problem never solved any problem. There’s chaos, and there's 10 people doing chaos, and you add 20 people or 30 people, then it's just going to get more chaotic across the board.

[37:59] Matt: So, maybe this is a good time to talk about what everybody loves to talk about now, which is AI. So, a lot of what you talked about, you've been able to do for a couple years now with SOAR tools, recreate playbooks, and you define essentially a workflow, “X or this condition happens, take these actions, go out, get enriched data.” That way, by the time it gets to an analyst, if it gets to them at all, all the work that might have taken them a day or two to do manually, is already done. I remember working with unit 42 team on this, and we were there using our own SOAR tool to do this, and it was amazing, just the time savings for that, and quite frank, that was pre-Gen AI or any of that type of stuff. So, Gen AI. How does it make what is already could be perhaps an automated process, how does it make it better in this specific case? How are you guys leveraging it?

[38:50] Niall: I think, it has tremendous potential without a doubt. So, even if you look at it currently, itself, you've got the model whereby you can pull data from systems around the world. So, it gives examples, one system gets infected, the system learns about it. Now, it's got a signature, it's got a machine learning component, and it learns from there, and if it sees anywhere else in the world going forward, then it blocks immediately from there. So, there's always been machine learning in some shape or form from that end, and machine learning journey has been pretty effective at finding what the real issues are. The problem with machine learning is that, how do you find if somebody did something three times versus the did something 30 times? And then you add the context behind it itself, and then you're like, “well, that person was on holidays with machine learning as well when they were there.” So, it's for us basically, AI is the next iteration of that. How can you take all of that data, feed them through LLMs, the Language Learning Model? We try to get those true business insights from there.

Now, you're finding you get to know that person. You get to know the device better. You get to know the action better, and it really gives you better insights into, A, finding the issue and, B, to your point, looks to automations and playbooks, is there ones whereby AI can help generate those or generate insights that your team can leverage? So, I think going for what's going to happen is, AI, certainly ML has been used for years and years and is truly trusted across the industry. Now, it's the next iteration, AI building that model, but it's going to be iterative. So, it's whereby you try something, the first thing works, and the second thing fails. The third thing fails, and the fourth thing works. I think it's going to be that, there's not going to be, “let's just turn it on, and it works. Great.” This is a long, long journey, highly repetitive from there, and it's highly complex. If you feed no unstructured data into AI, generally learn pretty quickly. Security is the most complicated data in the world because you're pulling data from everything, systems, containers, infrastructure, and then you may pull it from Okta, which is a different structure to Workday, which is a different structure to, let's just say, Palo Alto Networks. So, it's always that learning model of how do you create and how do you get the best value and the deepest insights from the data? And I'm a huge fan of logging as much as you can, and then consuming it per ML or AI as much as you can, and that way you can get the insights that you need.

[41:26] Matt: So, I don't know if you know Ross Haleliuk, but I had Ross on recently. He's a bestselling author now, apparently, with his new book, that I love, by the way. It's basically how to build a cybersecurity product, cybersecurity company, but he also writes venture insecurity, and what I love about Ross is he was actually on my podcast, I think, just recently, he goes very deep. So, a lot of blogs are 500 words. It's really shallow. Ross’s stuff is 5000/8000 words. It's very long form. He goes super deep. When I had him on recently, we went into the much-discussed cyber skills shortage, and he took a little bit of a contrarian view, and that he believed that the shortage isn't as severe as discussed, because he said those numbers that are reported out, they largely assumed that previous generation of security, some of what you and I talked about, a large SOC with dozens or hundreds of analysts, in some cases, staring at a piece of glass, and with little node automation, and definitely no AI. So, I'm curious, this is building on what we talked about, but what's your take on this? And how are you approaching this at Palo? We talked about this a little bit, but maybe think about it from an industry-at-large perspective. What's your take on it? Is it really as big of a challenge as we've talked about, and what do you think are some ways around that?

[42:51] Niall: Yeah, I think hiring the right skillset itself is very difficult. I mean, if somebody’s good, they have multiple offers out there. They have multiple opportunities from that end, and with security, you can generally get into mindset, “they’ve got to have this operating system, they’ve got to have the following experience, then network, this, this, this.” You're looking for this unicorn. You'll never hire that unicorn from there. So, the skillset is not out there from there. So, oftentimes, either you have to bring it in or trade it organically, and then build up a great team, and that takes time from there. I think one of the big things, and I believe certainly Ross is that, the old days of having huge, tremendous, large security teams that have no concept of automation or orchestration, no concept of machine learning from that end, they do today, because that's how they did it yesterday, and that's how they did it last year. That, over time, is going to die. I mean, it has to die from there, because for the most part, it's horrendously inefficient to me.

Some large organizations could have 1/2/3000 security people in a team. Just absolutely massive itself, and you can’t self-fulfill, and support that, so I firmly believe going forward, it's going to be smaller, more specialized, Special Forces skillsets, whereby, in a team, in a secure software team, you may have a team that specializes in automation, and they'll go in and they automate end-to-end, and as you pointed out is, if you can create a playbook and you can automate an action, and I lost a laptop. Where did you lose the laptop? You click on that file. That file downloads. If the downloads, it executed, it was a command-and-control. Command-and-control move laterally. If you can automate that, well, then you don't need 10 people to analyze one incident. You may need one SOC analysts to look at it and say “yep, he did.” We close it pretty quickly. So, what we're seeing going forward even now itself is the knowledge-driven companies are moving to smaller and more specialized teams, and they're very much focused in on that automation, orchestration, integration component from there, because if you can do that, then you can gather a tremendous amount of data.

So, if somebody said to you, if you went to your typical InfoSec team and said, “show me all the instances of AI running in the company,” it could take them six months to talk to people, email people, one system, another system, another system, and then 90% of the data is wrong, because sometimes to generate it, it's been washed two or three times, to now model, whereby because you're part of that secure SDLC process, because you've gone to automate, you've got the integrations, now you can generate a key list in pretty much seconds in a lot of cases, and then you can add metadata, and you can add some true value there.

So, I think teams are going to get smaller, I think they're going to get more specialized, and that's what we're seeing, certainly within Palo Alto Networks. It's teams that are just highly specialized. They can jump in, take an area apart, operationalize it, move out, then the next team moves on, operationalize that, and then the next one, and the next one. So, I think having broad generalists that have skillset in just a broad amount of areas, they're going to struggle the most, because they're generous, which is really good, but the specialist component of, how can they jump in, do an integration, operationalize it, and then basically hand it off? That's going to be huge.

[46:40] Matt: It's interesting you say that, because when I think about it, I was in consulting for many years, when I was at Deloitte, we had the same thing. At the time, it wasn't necessarily for cybersecurity, but we had specialist teams who would go in, solve a problem, they had a playbook because they had done it at a number of other customers that were in that industry, and it was like running that playbook again, and again, and again. So, I think that's similar to what you were talking about. So, let's switch gears. When it comes to personal growth, what's the formula that works for you?

[47:10] Niall: I would say it's jumping into a new area, learning it, trying to build a strong body of knowledge, and then jump on to next. As soon as you start getting bored, it’s just jumping on to the next area. I think that's the most critical component up there. Every single journey I've made, either laterally or learning new skillset has been based on, I know enough about this area. Now, let me move on to a new area. Let me build up the skillset there, and then on to the next area, and the next area. I think that's the one that truly adds value. The problem is, like an actor, you can get typecast, it is just “you do comedy, or you do a horror,” but problem is, even if you want to grow out of there, then you can't, and at that point, it's much more important to be able to understand, how does the whole business work? How did security controls work? And then continuously put yourself in challenging environments from there. So, if you ever do a job, whereby you're like, “I can do that,” you’re leaving yourself short. Every time you do a job, it should be “wow, this is going to be interesting. How am I going to do X, Y, Z. I have no idea. How is this going to work? No idea.” You should be continuously challenging, question yourself, looking at that and say, “Can I do that job? Can I fit that role? Can I execute exceptionally from there?” That's always been a key mantra from that end, as opposed to a taking a position whereby you're like, “Yeah, I can do that. That should be pretty easy.”

Again, I've seen the CISOs that have done the most and achieved the most are the ones that are just continuously challenging themselves, learning new areas, pivoting, and then always, you don't want to play with football where it is now. You want to play with the football where it's going to be. So, where's the next train going to be? And generally, you can say, “well, maybe AI is, in the past,” maybe you could have said Bitcoin was that, crypto, and then, well, maybe AI is it from there, and then it's a new AI and an example is the team, they've had tremendous amount of conversations on, going back to the earlier point about Palo Alto Networks pivoting from on-prem to the Cloud, and the Cloud to AI, and I will say similarly to having teams that go to transformations from on-prem to the Cloud, and if you do that, then obviously most organizations have done that in the last, I'd say, 5/10 years, they need to build up a whole new repertoire, a whole new skillset, because the worst thing in the world is somebody pings you in the corridor and says “by the way, Matt, by the way, Niall, how do we build this Cloud infrastructure?” And you're like, “Well, I don't know. I know on-prem, not the Cloud.” They're never going to come back to you. That is the exact same thing with a move to AI. Everybody in InfoSec, no matter who they are, they've got to start building up that subject matter expert, whereby now they're that SME for AI, and what we've done is we've sent all of our InfoSec team through trainings, through certifications, whereby now it's whether they're highly technical or they're more on program side, they can answer very quickly, very succinctly in relation to AI from there.

[50:28] Matt: I love that proactive stance that you guys are taking, and I think that plays into why Palo Alto is now the number one cybersecurity company. So, Niall, thank you so much for coming on the show. I think this has been a great conversation.

[50:43] Niall: Thank you, Matt. Anytime. Really enjoyed it. Thank you.

Thank you for joining us for today's episode. To find out more, please visit us at Cloudsecuritytoday.com.