How to Operationalize Cloud Security

**Note: Transcript is automatically generated. Expect typos!**

[INTRODUCTION]

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

[00:00:31] MC: You know what’s really hard? Operationalizing cloud security. It's fairly easy to go out and buy a security product or even to hire someone to run that security product. But what's even harder is operationalizing it, extracting value. In today's podcast, we have Brett Tode, who is a security leader at Zoetis, one of the world's largest animal health care companies. What he's going to do is walk us through their journey to the cloud and how he's operationalized his SOC to respond best to cloud security. I hope you enjoy our conversation. 

[INTERVIEW]

[00:01:10] MC: All right. Today on the show, we have Brett Tode from Zoetis. We’re super excited to have him on the show today. Brett, why don't you introduce yourself to the audience? Tell them what you do, where you work. Maybe tell us a little bit about Zoetis.

[00:01:26] BT: Hi there. My name is Brett Tode. I am a Director of Information Security at a company called Zoetis. Zoetis is known for healthcare and is the largest healthcare company for animals in the world.

[00:01:35] MC: Very awesome. What is your role? What do you do at Zoetis? I know you've been there, you were there as part of the spin off, right, when it – I think it spun out of – Was it Pfizer?

[00:01:45] BT: Yeah. It spun out of Pfizer back in 2013. I was previously with Pfizer for a number of years, and I elected to come over to Zoetis at that time. Literally my first day at Zoetis was the day of our IPO. So we did spin off from Pfizer February 1st, 2013. But prior to that, we were part of Pfizer's animal health care unit. So the company is new since 2013, but we've been doing this for about 65 years.

[00:02:09] MC: That's pretty awesome. Now, what's your role from a security perspective? What do you do at Zoetis, and what are maybe some of the areas of focus that you have, you and your team?

[00:02:19] BT: I love to say that I'm a jack of all trades or more like kind of the front line, but officially my title is Director of Information Security, and that ranges from everything for running a 24/7 security operations team to dealing with vulnerability and threat management, threat intelligence, data protection, security awareness. You name it, I say we deal with it. We are the frontline, so dealing with all the events that come in and we do operate that. That operations team that is dealing with anything and everything does come across our plate one way or the other.

[00:02:48] MC: Awesome. Well, that's pretty cool, and it's funny. I was looking at your stock so congratulations on the fact that over the last five years, you guys have handily outpaced the S&P 500. I was looking, the last five years your stock’s up 230% and the S&P is only up 97%, so nice. Thanks for keeping it, thanks for [inaudible 00:03:06].

[00:03:07] BT: It's funny. I think we started. We opened our first day for the IPO, it was like $32, and that we've been upwards around $160. Yeah, the company has been doing well, and we've slowly but surely been getting bigger as well. Acquiring companies, mergers, and acquisitions, and stuff like that, so it's been really good. The company is pretty healthy.

[00:03:23] MC: Yeah. It's pretty good. It's always good to work for a healthy company. One of the questions I always love to ask guests when they come on the podcast is just how did you get into cybersecurity? Because one of the things we constantly hear about our industry is that there's this massive talent shortage. So tell us maybe a little bit around what did your journey look like? Maybe what was it that caught your attention to cybersecurity? I ask that because I was looking at your background. I like to stalk all my guests before they come on the show, and I know you and I know each other, you live really close to where I do. But I noticed that in college, I didn't know this, your major was actually ecommerce. Again, tell us. What was your journey? What was it that made you make the jump from ecommerce to cybersecurity?

[00:04:11] BT: It's a good question. I could say I've always been interested in computers for my entire life. I come from a family of blue collar workers that worked out in heavy excavating, so I'm the only one that has been inside of the white collar type of work here but I've always been interested in computers. Going into college, I was undecided on what I wanted to do. But as soon as I got into school, I knew I wanted to have a business major. When I first attended and first went into college and started taking a bunch of core classes, I started off with computer information systems, thought that was good because it did have a minor in business. I really wanted a full major in business because I just knew that was the route I wanted to take but in some type of technology capacity. 

Ecommerce was a brand new major at the school I went to, and it was a full business major, so a lot of web programming but that full business major. I thought that was the best of both worlds, so that's why I really signed up and I declared my major as ecommerce. I've always been interested in that stuff anyway. During college, I worked in telecommunications, so I worked in very large companies. I handled their data and telephone work, either from running cables to troubleshooting networks and stuff like that, building out network closets. I’m very interested in that. It's actually what brought me into my role here. 

I was working telecom in college back in the summers, and I was working at Pfizer one summer and I was getting close to graduation. I was just talking to a bunch of folks and I struck up a conversation with somebody in the Information Security Department over at Pfizer. They were building out and centralizing all of information security at the time. When I graduated college, I accepted a role over there and started my first job as, kind of, an analyst. I came in as a contract position and took off from there.

[00:05:57] MC: That's pretty awesome. So your first foray into technology, now that wasn't in security though, right? That was just like an IT analyst or what was the role, your first role? 

[00:06:07] BT: It was security. It was security. We were in charge of our global antivirus deployment here at Pfizer.

[00:06:12] MC: Okay. Hearing a global antivirus deployment seems like so long ago, right? Like now we're talking about next gen this, next gen that. 

[00:06:21] BT: Yeah. 

[00:06:21] MC: It’s funny too because I think about my first role out of college was actually at Johnson & Johnson, and that was actually I think one of my first global projects. It was a global rollout of McAfee's ePO, Enterprise Policy Orchestrator, right?

[00:06:32] BT: Same thing. ePolicy Orchestrator, yup. 

[00:06:36] MC: I think it still exists in some shape or form, ePO, right?

[00:06:40] BT: It does and it lives on in a lot of different companies still today. It was a pretty solid product.

[00:06:45] MC: It was. It was. So that's great. Let me ask you this, though. You did start off in cybersecurity, kind of worked your way up. At what point in your career did you maybe have that desire to be in leadership, right? Because right now, your role is a security leadership role, like you have one or more teams that report to you. What was it that – Is it kind of your personality? But was there anything particular about cybersecurity leadership that maybe caught your attention?

[00:07:13] BT: Yeah. At one point in my career and earlier in my career, I was 100%, technical, in the weeds, getting there, building things. So I really understood all the technology that went through there and I loved it. I really did but I always look at and I like to point myself in a direction of where I want to be in my career and where do I want to go, so that really brought me over to leadership. I say I'm still technical enough to be dangerous but I've really stayed out of the weeds in the last several years and just let the folks that are technical on my team do that work. 

But there was a point in time where I really liked working and solving problems from a high level, seeing what we can do and run teams and come up with different solutions to make sure that, one, we weren't really stressing the business. We were providing solutions right off the bat, rather than just putting barriers up in the way. I get a lot of satisfaction out of that, really working with the business, understanding what they need. The company I work for now is not a technology company, so I'm looked at as a barrier and I want to make sure that we are providing solutions, and we're getting out of the way but protecting the company at the same time. So it's been a really nice balance, and I've had a really fortunate career for where I've been able to go to be able to do so much of that work.

[00:08:23] MC: Yeah. You and I, we've actually known each other since – I think it was 2017. I was looking back at my notes. If you remember, at the time, I was actually working at Cognizant, running the cloud security advisory services practice. If I remember right, Zoetis was just getting started on your journey to the cloud. So I'm just curious from your perspective, and maybe just talk a little bit about how security has had to transform along the way with that journey to the cloud.

[00:08:51] BT: Just with the cloud, and I think what everyone can always attest to, is just saying it's fast. Back when we were starting and we were really kind of developing as a company, cloud came, wouldn't say out of anywhere, but just everyone was jumping on it. In our particular company, we had business units that were moving to the cloud faster than the technology departments, so we had to adapt. What did we do and how do we catch up? It was just moving so fast that we had to just really get our hands around it and really understand and get our arms around it to really understand what we needed to do to make sure that we weren't setting ourselves up for failure, as far as a security standpoint and just letting things go out the door or having some type of vulnerabilities or things like that that would really put us in a bad spot that could tarnish our reputation and our company's name.

It was tough. We did bring in companies like Cognizant to help us out and really just say, “Hey, help us with that plan. Help us really establish that foundation, so we don't, one, lose the business but, two, don't lose our time to really just set things up the right way.” So we're not playing catch up and years to come and trying to redo a lot of the work that was being done at that very time.

[00:09:54] MC: What would you say, being now multiple years kind of I guess into this cloud migration, what would you say were some of the most important things that you had to tackle up front and maybe some of the most challenging things? What were the areas that you felt like you personally, as well as your team really just had to transform?

[00:10:14] BT: The speed thing, as I said, is one of the things, and understanding. There were just so many new features coming out on almost a daily basis in the cloud, and it was, “Hey, can we stop and review all those features to make sure they're secure?” A lot of those answers were, “No, we can't.” But we had to adapt to really understand what those things were to really allow us to move forward. Standardization, I just live and die by our process. We're very process-oriented. You can do that in the cloud but you have to take time to do that, and that's how it should be done. So we really went back to the basics. Everything that you would expect to be done we wanted to verify was going to be done. Were our systems being spun up securely? Were we patching systems? We're going back to all those things. 

Once we got those things right, it was easy. It was really easy, but those fundamentals could have been, and were in some cases, easily missed in the beginning that we were just missing. We had to go back and make sure they were there, really secure the code by design and make sure that we were good from the get go and really just kind of get ourselves under control there and make sure that the businesses and how we – Our infrastructure teams knew that that had to be done from the very beginning.

[00:11:27] MC: Makes sense. It's funny. Well, it's not funny that you say standardization, but that's like one of those, I feel like that's almost a dirty word in the industry. It sounds really boring, right? It's a standard. So therefore, it should be boring, right? It's like, this should be your SOP. 

[00:11:40] BT: Yeah. 

[00:11:44] MC: I've blogged about this and talked about it many times, but it's like I always say standards are the precursor to automation, right? So I think a lot of times people assume when they move to the cloud, they're going to automatically get automation. But I'm sure you guys would attest to the fact that you don't get it by default, right? You've got to build it.

[00:12:01] BT: Yeah, absolutely. It’s funny because automation is the big thing, and automation has been a very big goal of mine for the past several years and remains one. Why? Because I run an operations team. One of the big parts is time and how we spend our time. We went back and we looked at all of our processes to really understand, “What are we doing? Does it make sense? Are we being very realistic with what we do?” I don't like to rip and replace but I will refine over time all day long. Before we even look at that automation, just getting back to that standardization, which could be very boring, but we literally have standardized our process for everything we do.

Now, why do I do that? We do use a managed service provider, and that allows us to have people come in and out, really quickly be brought back up to speed because we've standardized our processes. It's an insurance plan for myself. For me as the team lead, I need to make sure that we're going to be effective every single day. If you have a high turnover with your MSP, your standardized processes or the things that really are going to keep you in control and keep you effective over time. Automation is really cool and great because it's going to save us time. But without that standardized process and just those things, you can never get to automation without it.

[00:13:19] MC: It’s funny, you and I over lunch, I think we've talked about this many times. Like you said, you've just got this passion for automation but really specifically around the SOC, right? I guess you touched on this a little bit, but what can you share maybe around what you've done with SOAR tools to automate? I guess the other piece I'd say there too is, obviously there's a lot that’s out there from security vendors in terms of SOAR tools, but what I've heard from many people, and I'd love to get your feedback on this, is that they've said to me that they feel like they really can't use a SOAR tool yet because perhaps they haven't standardized enough of their SOC processes. So what can you share around maybe what you've done with SOAR tools? Were things you had to do before you could really leverage those tools? What did that look like?

[00:14:08] BT: Yeah. I mean, so it all comes back to just central management of our logs. We particularly use Splunk at Zoetis, and we've used Splunk for a long time. It was just the tool we selected. It was very versatile at the time that we could start really slow and it didn't cost that much money. We used their cloud product, which was nice too. But it was really understanding those logs and getting those logs onto the right spot. Now, I have really rethought a lot of the traditional ways that we thought about logs, and everyone just said, “Hey, bring everything in. Let's bring every single log we can possibly bring into something.” When we're paying by the gigabyte for that for Splunk cloud, we got really creative about what we're going to do. So we had to put that use case together about what logs we're going to send because if you're going to send logs, what are we going to do with them? If we're not going to do anything with them, do we need them? Because you can stockpile logs all day long and do nothing with them. You're just wasting a lot of money. 

The first thing we did was really centralize all of our logs, identify the logs we wanted. Again, we started slow and we just said, “Right, we want this. We know we want this. We're not sure about that.” But as we started to get all of our logs ingested appropriately, now we can say, “All right. We'll start pulling them apart.” What are we actually doing with these things? You get a ton of firewall logs. I mean, that makes up most of my log ingestion today. I mean, what we're spending. But what are we doing with that? We need it for investigations and stuff like that. We need to go back in time. So that's something we need. But other stuff – Now, what can we do with those logs? 

Let's just use firewall logs again. If I have a particular event, I'm going to want to pull from every single source around that event. If I have an event that happens on, say, one system today, let's pull everything around that event around that time, and that's where we started getting really good with that correlation because I think a lot of folks use a tool like Splunk today, not to its full capacity. They're using it for just logs, just to ingest logs, and they do a little bit of searching there. But the true beauty of it is that correlation. You can take one event and say, “Alright, search around that with every single other log and tell me everything we have about that.” Now, we're getting really good. Now, we're getting a lot more information, and that information can lead to just further decisions and solutions like, what we're going to come up with, with all that extra information, I now can just rule that out as a false positive. Or, “You know what? We found that this just became something huge based on the correlation we just made right there.” So it's been really good but it's been a journey for us.

[00:16:33] MC: Obviously, you talked about that in the context of firewalls. But obviously, that applies to probably almost any other security tool. When you think about that automation piece with SOAR and you apply it towards a public cloud like an AWS, Azure, or Google, how does that change? Where do you really see like you're getting a lift, either in terms of efficiency, effectiveness? How does that change when you're looking at cloud as opposed to traditional firewalls?

[00:17:00] BT: Yeah. That’s been a little bit of a shift for us too. Back to, and I meant to mention this earlier too, when we're just talking about cloud and the company and the business really pushing us further, and that was kind of the opposite of what we've always seen. How do we get our arms around it and what do we do? Now, we'll use the native tools that you get from AWS or Azure, the Azure Security Center, stuff like that. They have some really great tools in there. But when you're talking about different cloud instances, like what do you do? 

One of the first tools we purchased was RedLock, now Prisma Cloud. I will be completely honest. We purchased that almost on a whim. We just needed help, and it's been one of the best solutions that we've had that’s still in place today because that's helped us centralize the security no matter what cloud instance we're using. It's been really good for us because we were able to get that kind of single pane of glass, regardless of where we were, and it just helped us to really, not only perform a really easy assessment, so we were able to onboard that technology and I want to say ours. It was just simple configuration, and we got actionable results right away. That’s something that we still use to keep everyone in line today with things getting out of compliance. 

That's been something that's been instrumental for us, and that's just one piece too. It was really nice. But then, again, as I said, we'll always use the management security consoles that come native to the cloud instance as well. So we have that kind of multiple different solutions in place. But, again, feeding all those things to a central management console like a Splunk where we can get all those logs and really take actions from there.

[ADVERTISEMENT]

[00:18:30] MC: Securing IAS in past platforms has always been a pain. Prisma Cloud by Palo Alto Networks is the industry's most comprehensive cloud native security platform, with the industry's broadest security and compliance coverage throughout the development lifecycle and across hybrid and multi-cloud environments. The Prisma Cloud platform offers an integrated approach that enables security operations and DevOps teams to collaborate effectively and accelerate secure cloud native application development. To find out more, go to paloaltonetworks.com/prisma. 

[INTERVIEW]

[00:19:12] MC: You mentioned you use Prisma Cloud for your multi cloud security, so that's one thing that's providing you signal from your different public clouds that you guys use. You're using a SIM tool like Splunk to kind of gather the logs. Then you have a SOAR tool that you guys use as well. Does the SOAR tool, does that really kind of help you with – You mentioned correlations before. But when you think about how your SOAR tool is interacting with a cloud security platform like Prisma Cloud, and then how does it interact with Splunk? Where is that value add there? I have not actually been hands on with the SOAR tool before, so I'm just curious. What does that look like for you guys?

[00:19:51] BT: Well, look at our processes. Let's just say there's a five-step process for how we'd handle something. Taking SOAR out of the picture right now, let's just say we get an event, we verify it this way, we pull some information this way. So we go through five different steps. Where SOAR has come in, and that's what we'll look at as our processes today. If I have those five steps, I would say, “Hey, in the perfect scenario, we can get SOAR to really automate all five of those pieces.” Realistically, it's not always the case. So if I can automate three of those different steps out of the five, I'm saving time. If I could automate four, I'm saving time. If there's actions that we can now take, now we're getting really, really good. It's more than just correlation. 

I mean, when we first brought SOAR in, it was validation. We use that for a lot of our cloud pieces today, the events that come in, validation. Is the event what it says it is? Is that really what it is? So we'd have a step that would really validate if it's legitimate or not, if it's a false positive or a true positive. We're able to automate that now, which is awesome. So now, next step, what do we do? We can do things like opening tickets. That's great. We can open tickets to the appropriate team that will then take the action. Within that ticket, we can provide all the information about everything we said, including those verification checks or the actions that we've already taken, just to let them know. 

SOAR has just become such a thing of speed for us because now, one, if SOAR’s doing, it's standardized completely through and through. There's no human error whatsoever. But then we're also saving that time. So if we automate three of the five steps, we're saving time there. Now, the analyst can just spend the time on those last two steps. If we automate everything, the analyst doesn't have to look at it, and then they can focus their time on other pieces. But that's essentially everything we're doing with SOAR, but we're being very slow with it to make sure that we're getting it right. I don't want to just jump out of the gate and all of a sudden we shut the company down because we're taking major actions that are just causing issues. 

We have been on this journey that is relatively slow. But now that we've had all these bases and we have numbers of playbooks, SOAR playbooks out there that are just automating all these different pieces that were once manual, we're in a really good spot and we're just saving that time. Again, at the end of the day, I mean, I look at this. I've even said this to my team, “We’re going to automate everything as everything we can. It’s not to eliminate you or make the team smaller. I want the team to grow. But in order for us to play offense, we have to save as much time as possible, so you can spend as much time as possible doing the stuff that you need to be doing that we just can't automate today.” So it's been really good.

[00:22:12] MC: Now, I know that you guys use an MSSP for a lot of that type of work. Have you found – This is one of the things I hear from the vendors,  at least I see in their marketing, is that they can automate L1, L2 type of stuff completely. Is there any truth to the fact that, do you see – Again, just an MSSP, they're not your direct employees, but do you see this actually potentially helping with that? Because one of the things you often hear about SOC analysts is they get burned out because you're looking at literally millions of events coming in. Do you actually see this as something that, as a company uses it and they actually build toward more maturity, that it could actually help with helping to eliminate talent drain or helping to at least reduce it?

[00:22:55] BT: I think so because those mundane tasks, those things you do over and over, and you're just saying, “Nope, nope, nope. This isn't it. This isn't it.” You go through those things, and we can now have that completely automated. What does that allow the analyst to do? Spend time on the interesting things, the more stuff that they're actually getting some potentially satisfaction out of, some of those more interesting things that they can go, “Hey. Now, I have time to just go play offense. We're going to threat hunt almost all time, rather than just waiting for these things to come in and just checking boxes and stuff like that.” So those mundane tasks, those things that we just do 1,000 times a day, we're going to automate. 

But how we can keep those analysts excited about what they're doing is allow them to do exciting things and really to find things. Find those needles in the haystack and really come up with those great solutions and push all that kind of boring stuff aside that we could just automate.

[00:23:45] MC: I love that. I mean, I love when there's actually a technology that solves a true challenge but addresses also the human component of it. I think that's awesome to hear. I think, I'm sure that there's going to be someone listening to this who's like, “Okay, I think I need to do this.” I think SOAR is a technology at least, and I speak with hundreds of different customers around the globe, I think that although you said that you guys have slowly adopted this, I still think that you guys are probably really far ahead of the market just in terms of adopting cloud and adopting SOAR type capability. If you were to give somebody some recommended steps, maybe from a people and a process perspective. They're looking to automate their SOC, they're trying to automate and trying to blend, how do they take this whole new amount of signal that's coming from cloud that they didn't have to deal with before? From a people in process perspective, where would you recommend they start?

[00:24:42] BT: It's a really good question. I mean, at the source of the whole matter is, you have to understand really what's going on, so sticking again with those fundamentals. In almost everything I do too, I try to keep things simple. Don't try to make something so complex from the get go because it’s just never going to work. Start out in pieces. What do you really need to do? The answer to your question, Matt, would be, understand what really we're looking for. Understand what those needles are that we want to find and really determine what steps you need to do to find them. Understand what the problems are, “What are we really trying to do?” Once you get that foundation, then you can start getting a little bit deeper into it and say, “All right. Well, now what can we do to make things better? We see the same thing every day. How can we prevent that?” Just start really with the easy things. Because once you get your feet wet with that, then you're going to understand about where can we go next. 

I mean, there are so many items that we just have on our plate now that we're just saying, “Yup, that's in the pipeline. It's in the pipeline, and we're working through this stuff.” We’re busy. We're really busy because we could always be better. We'll never just say, “You know what? We've reached the point where we're just great.” We’re always going to strive to be better. I think everyone should do that because making yourself better is just providing more value for the company. At the end of the day, that's what we're all supposed to be doing is providing value to the company, so we’re going to constantly just be putting things back in the hopper to say, “What can we do to tune that? What can we do to polish that?” 

But starting really slow and just understanding what those foundational items and what really is your goal is the most important piece because I've seen a lot of folks, they'll just try to jump right into step nine, and they didn't even think about those foundational analysis, and things just topple over, and it's just not working right. So I always try to start things pretty slow, and then we can move really fast. Because once you establish those items, then you can just rip and reuse. I mean, there's a lot of playbooks we have today with SOAR that work here, and we can just change it a little bit, and that could work over here too.

So we have these things we call – I mean, it's termed Lego blocks, right? I'll build a Lego block and I can use it for a million different things. But I'm not going to recreate that Lego block for every single playbook that I want to put together. The Lego block in itself can be all put together, and we can have four of those blocks together. Now, all of a sudden, we have a brand new playbook. I mean, it's really good. That's what we've been trying to establish and make sure that we're, one, doing things appropriately but not getting too overly complex.

[00:27:16] MC: I love that. I mean, I think that's really wise. As I've gotten to know you over the years, I think one of the things that makes you so good at what you do is the fact that you are willing to do things differently, but you, I think are also really wise and that you don't try to go 100 miles an hour day one because you realize that – I forget, how many people are at Zoetis? I mean, it's not a small company.

[00:27:38] BT: No. We have anywhere around 12,000 employees and then about 3,000 to 4,000 contract staff at any given time. We're a big company. We're a Fortune 500 company and we're in 100 different countries, so we're global. It’s what I call the sweet spot, around that 15,000 users globally. We're not too big where we can't move fast but we're not too small that we don't have the funding.

[00:28:00] MC: Yeah. I think you're wise, like doing things, you start on them but you take a measured approach. I think that's paid off for you guys a lot. One of the things that I've blogged about in the past and I always love to ask guests about on the show is, when it comes to security tools, controls, there's a difference between effectiveness and efficiency, so effectiveness versus efficiency. I know many of our listeners are using two or more cloud platforms, and they are absolutely struggling with measuring cloud security. So I'm curious, you own the SOC, you have responsibility over so many different areas in security. But are there any cloud-specific metrics that you track? And I'm just curious, why are those important? How do you kind of keep a pulse of your cloud-specific stats? Just tell me or talk a little bit about metrics specific to cloud. 

[00:29:00] BT: Sure. The one thing that we found, again, just the speed with cloud and how fast things get spun up is, we tend to be able to spot problems early on because we can see things. I'll just say a resource that gets spun up that is missing all of our different security controls. Those metrics are huge for us because we've seen with different developers anyway or the other, they could have been putting something together and they're not using the correct code, let's just say. They're not using that production code. Well, we can spot that really easily. They're going to spin something up, and it's going to be riddled with just security holes. Those types of metrics are things that we follow up all the time. Those are the things that we have automations in place. 

If there's stuff being built that's not meeting our security controls and policies, they're going to know about it right away. We already have some automation in place that's going to basically scream those alarm bells and really just say, “Hey, we see a problem right here. What's going on?” They’re going to say, “Oh, we didn't mean to do that.” Then we’re going to stop that before it becomes a major problem and now, you have production applications running on infrastructure that does have issues or something like that. I mean, it's just an example. But spotting those problems pretty early is key for us, and that's why we have things in place to really understand and check for that and validate to make sure that that secure code that we all agreed on is being used.

[00:30:23] MC: I love that. I love that. From metrics, let me just ask you this, because I think one of the – I know that you have a really great relationship with your leadership team. I think, again, that goes to a lot of just your approach to securing things. You take a very programmatic approach to it, and very measured. Do you get interest from your security leadership around like seeing, do they ask you, how interested are they in like cloud security metrics? Is this something that you guys talk to the board about? Or is it kind of bubbled up in other things? I'm just curious because I get this question a lot from other companies like, “Are there specific metrics I should be bubbling up to my leadership, to the board?” What does that look like for you guys? Whatever you can share too? I mean, I understand some of this stuff is sensitive, so whatever you feel like you can share would be just awesome.

[00:31:07] BT: Yeah, I hear you and I'll give you some perspective in what I've just seen with, I'll say my company, but I just think it's in general. I mean, everyone is just – All of our executive and board level members are really asking us now about security. They're seeing all issues with other companies and they don't want to be that company that has a problem, right? So they're asking those questions now. Metrics are the best way to get their attention, and I think about this a ton. What metrics are the right metrics? I don't have the greatest answer. I will say, “Are they asking specifically about cloud metrics?” “No.” “Are they asking about cloud usage?”” Yeah, because they want to know. Are we maximizing our dollar? Are we being versatile now? Are we able to move really quickly?” Yeah. So they’ll ask things like that. But around security and cloud-specific metrics, I don't know the best metrics that would be good for that type of audience today. I think about this a ton and not just about cloud metrics but just about metrics in general. 

When you put those numbers up in front of executives or board members, it's gotta make sense, and those things have to stand on their own. So taking what we all do as could be not very understood by those type of people because it's just not, technology is just not maybe their thing or what they're thinking about. It's more about the business. It's what would make most sense to them and what should they be doing. We’re still trying to look for that.

[00:32:29] MC: That makes total sense. So I'm not going to ask you. Switching gears a little bit, I want to ask you if you guys were impacted by SolarWinds. But I'm curious, how has this event maybe changed how you guys are thinking about third-party risk management? Obviously, organizations are still trying to understand the impact of SolarWinds. But at least from your perspective, how has this changed, maybe even how you guys are approaching third-party risk management? Are you looking at changing things and just in light of what we've all learned as an industry about this? How do you guys think about that?

[00:33:04] BT: It was kind of an awakening event for everyone, and everyone just said, “How could this ever happen?” But if you think, it was like the perfect model for something to happen. Most folks would just anticipate, yeah, third-party risk management, before this happened, is it good? Everyone's like, “Yeah, it's great.” We ask those questions. We do all those things, and you do. But sometimes things change. But what I think about the whole incident is you do have this trust. You have this implicit trust on vendors and partners that you're working with, and there's some reasons and things that you have to take those risks. You have to take those risks in some cases, but they're calculated risks. Are they partners? Are you checking what they're doing with their software development lifecycle and stuff like that? What's happening? Are we getting that deep? Are we asking those things? Maybe not before, but maybe yes now. 

One of the biggest things that I think came out of SolarWinds that we've been dealing with and that I see other companies looking at is things like partner connections. Do you have connections set up between you and a partner company? Everyone's like, “Yeah, we have those set up.” But how easily can you find those? So the next company that reports a breach or a problem or a ransomware, you what the executives are always asking, “Do we have a partner connection? We do work with them. Do we have any network connection setup with them?” We can find that, but is that readily available for everyone? Again, I think most people would say, “Yeah, I could probably find that.” But can you find that in minutes? Can you sever that connection in minutes?

[00:34:31] MC: Probably no.   

[00:34:32] BT: Those are the things that we're making changes on right now, being prepared to make sure that we're not a byproduct for another company that gets owned. Can we sever the connection? Who makes the call about some of these actions? We've been empowered by the board and our executives at my company to basically make that decision right away. We'd rather take a chance, sever a connection or take an action to stop something and it be nothing than to just say, “I'm not sure,” and watch it happen.

[00:35:01] MC: I love the fact that they've empowered you because I've worked at Fortune 500, Fortune 100 companies my whole life, and many of those I can tell you, maybe it would be different pre-SolarWinds. But I can say many of them would probably have just taken the approach of, “Well, let's just wait and see, right? I don't want to impact any potential revenue generating systems.” So I love that. I think that that proactive approach is actually really wise. Let me ask this, I know we're almost at the end of our time here today and I've really enjoyed chatting with you and just kind of learning about your path and what you do at Zoetis. If our listeners want to connect with you or they want to learn more about Zoetis, how can they go about doing that?

[00:35:43] BT: Yeah, so the standard. I don't really have a presence on Twitter. But if you wanted to get in touch with me, you can find me on LinkedIn. Want to learn more about Zoetis, our company website has a multitude of information out there, and plus we're hiring. We have a number of job positions open right now in information security and all around technology, so the company continues to grow, and we continue to identify needs that we need to fill.

[00:36:05] MC: Well, that's awesome. So if they want to find out, zoetis.com. I assume, there's a career section of the site, they can go in there and see what security roles are open. I love it. I love it. Well, Brett, it was great talking with you today. I appreciate your time. Thanks so much for joining us.

[00:36:19] BT: Yeah. I appreciate it.

[END OF INTERVIEW]

[00:36:21] ANNOUNCER: Thank you for joining us for today's episode. To find out more, please visit us at cloudsecuritytoday.com

[END]