A logo with accompanying text "Listen on Spotify"A logo with accompanying text "Listen on Apple Podcasts"
Striding towards Zero-ish Trust
Season One
· Episode
10

Striding towards Zero-ish Trust

In this episode, host Raghu Nandakumara sits down with Ryan Fried, former Senior Security Engineer at Brooks Running, to discuss the role of cybersecurity in the manufacturing and retail sectors, building a successful Zero Trust program, and the difference between being compliant and being secure. 

Transcript

0:00:04.4 Raghu Nandakumara: Welcome to The Segment, A Zero Trust Leadership podcast. I'm your host, Raghu Nandakumara, Head of Industry Solutions at Illumio, the Zero Trust Segmentation company. Today I'm joined by Ryan Fried, Senior Information Security Engineer at Brooks Running. At Brooks, Ryan is responsible for overseeing organization-wide security projects from design to completion. Prior to Brooks, he worked as a Security Analyst, Network Engineer, Risk Assessment Manager, and Security Architect at organizations like Coverys and BlueSnap. Today, Ryan is joining us to discuss the role of cybersecurity in the manufacturing and retail sectors, building a successful Zero Trust program, and the difference between being compliant and being secure.

0:00:50.3 Raghu Nandakumara: Hey, Ryan, great to have you here today with us, thank you for joining. How are you doing?  

0:00:55.5 Ryan Fried: Good, I really appreciate the opportunity. Always great to chat with you.

0:01:00.1 Raghu Nandakumara: It's our pleasure. I must say firstly, Brooks Running shoes that I've been using now for the last month or so are hands down the most comfortable, lightest, best running shoes I've ever owned. I can't believe that I hadn't tried those out till this time. So it's doubly exciting to have you on board. I like starting off these conversations with our guests and asking them how they ended up in cyber. So what's your journey been?  

0:01:27.5 Ryan Fried: Sure. I would say I'm one of the more traditional routes into cyber. I went to school for management information systems, so a cross between business and technology. Wound up getting a job at a large health insurance company in an IT rotational program, so every six to eight months we would switch into a different part of IT. I went into it thinking I wanted to be a project manager and after six months quickly found out that's not the case. I like more of the hands-on work. So after my second year, the health insurance company got their, at least one of their first, CISOs. He just brought this incredible culture into the company to the point where every day at 4 o'clock, everyone's job pretty much would stop in security and infrastructure and such, and he would talk about the latest threats and vulnerabilities that people are reading about or reported, and then have that discussion. And no other company I've heard where the security person brings it up to the infrastructure person on the call and they develop a plan to remediate it maybe within a few days. Then there were different engineers that talked about their activity in the dark web and keeping an ear to the ground. So I was enthralled and really haven't looked back since.

0:02:42.5 Raghu Nandakumara: That's so exciting to hear just firstly, that comment about you doing project management for a year and then switching. It definitely reminds me of a conversation that I had prior to my first job out of university on the analyst program and I essentially had on... In the left hand it was, "Hey, you could take a job in IT project management, on the right hand it was, you could take a job in cyber." I'm like, "There's only one choice there, it's not the left hand." But that culture of learning is so great to hear because, you are absolutely right. That opportunity just literally down tools and then spend half an hour of your day every day on learning and discussing and sharing ideas is such an incredible opportunity to have. What, just from those first early days experiencing that, what were the things that you came away with?  

0:03:37.3 Ryan Fried: Just having that growth mindset. 10 years ago we just started talking a little bit about public cloud, but more around virtual machines and even within the last year or two I had to basically learn about containers and DevSecOps from scratch, and know just enough to give requirements for people who have been doing it for five years in both a confident fashion but also a mutual agreement. We're not going to give them requirements and say you must do these, but asking them, they know a little bit about security. So just when you think the technology things advance, you have to learn the next one, but being open to learning about it is really important.

0:04:19.8 Raghu Nandakumara: Yeah absolutely. So in that initial discovery of cybersecurity and threats, can you share maybe a particular security capability or maybe it's a threat that caught your eye and said, "God, that's really exciting, this is what I want to pursue."

0:04:37.9 Ryan Fried: Yeah, I think looking back about 10 years ago, the most exciting technology was CrowdStrike in the EDR space. I grew up knowing the basics of Sophos or Vera and having those do basic scans. But then when I saw the visibility that something like a CrowdStrike can do or really any other EDR vendor to look at that process tree and use that behavioral-based approach, I thought that was really cool.

0:05:05.8 Raghu Nandakumara: So that shift from heuristic-based detection to behavioral detection was obviously a seismic change in the way particularly that we did endpoint-based protection. And that's developed significantly over the last 10 years with the evolution of ML- and AI-based technology. So, and I know you were at RSA recently, what was particularly exciting about what you saw from the vendors there?  

0:05:34.4 Ryan Fried: Yeah. From RSA, I thought some of the coolest technology was you have your cloud security protection, looking for cloud configuration which is really helpful. But for me, I want to know what threat actors are doing and mapping that to the controls, usually misconfigurations for cloud platforms. There is a lot of cloud configuration platforms that they'll give you 300 high alerts which is not helpful for me. So I'm starting to see vendors do some more risk-based approach where maybe it can detect that it has a public IP address associated with it and open internet access or this is a misconfiguration that's being exploited in the wild. I'm starting to see a little bit more of a threat-based approach to public cloud misconfigurations, which is really helpful as an engineer.

0:06:31.7 Raghu Nandakumara: And you use the words or the terms “risk-based” and “threat-based” and we hear these a lot and particularly in vendor marketecture. As a practitioner and as a very experienced practitioner, when you say risk-based and when you say threat-based, what do you mean very precisely?  

0:06:54.2 Ryan Fried: So when I use those two terms, I typically think about vulnerability management. So you can't patch everything. You have to freely have a high level of fidelity for how critical it should be when you go to your infrastructure team. So some things I look at, which some vulnerability management tools do better than others, are is the asset public facing? Is their vulnerability, does it have proof of concept like exploit code out there? Is it actively being exploited? Which CISA does a really good job with the known exploited vulnerability list now. What's the level of complexity it would take a hacker? Can they just type in a one-line command line using Metasploit, or does it require a high level of complexity? And then what's the level of user interaction? Are they sending an email where they don't even have to open it? Or does it require a user to click a couple of times? So those are usually the things that on top of the CVSS score that help us really prioritize what we should be looking to remediate first.

0:08:01.8 Raghu Nandakumara: And I think you used the term exposure. What is the real exposure, exposure risk of vulnerabilities? How as a practitioner, how do you build a picture of exposure of your assets for your organization?  

0:08:20.0 Ryan Fried: Yeah, that's really hard. Asset management at most of the companies I've been at has definitely been a challenge. You have assets all over the place. You have people coming and going as far as workstations. You have new servers that are being spun up. You have DevSecOps where you have ephemeral servers being spun up on top of your public cloud. And I've been burned in the past with pentest where we have a Windows 2008 box that was jacked up, it didn't have an EDR agent, the pen tester found it, exploited it and then moved laterally and got domain and admin access. So the best methods I've found recently are API access into your VMware stack, public cloud presence whatever you use, your MDM solution. So that way you're not relying on an agent being installed or a step being taken.

0:09:14.0 Ryan Fried: So there's a couple of vendors out there that are doing a really good job as far as using the API connection to different platforms. But then also a challenge as a practitioner is making sure all of your agents are everywhere which... I've never had 100% compliance across all agents, across all servers, and workstations. So being able to instead of manually going through and looking at your EDR vendor and your vault management vendor, there are tools that will run API calls. They'll get that one hostname and it'll say we see EDR, we see vault management but we don't see the tool that pulls your logs and sends them to the SIM. So it makes it way easier, otherwise, you're doing that yourself which you're not always going to get 100%.

0:10:01.2 Raghu Nandakumara: That thing about, you're never going to get 100% and you're always playing catch up. And I don't mean this in the context of, we often say, “oh, attackers are always one step ahead.” I'm not talking about it from that perspective but as you said, just on basics we're always playing catch up whether it's with patching or whether it's with asset discovery etc. How do you determine what is good enough? What is an acceptable level and then beyond that it's a bonus, but also the cost of doing better is also potentially prohibitive. How do you set that? Because, and not to cut you off because, again going back to that example of that Windows 2008 server that you just didn't know about. That's the vulnerability that ends up getting exploited. How do you strike that balance?  

0:10:46.1 Ryan Fried: Yeah. I'm really glad you brought up the phrase “good enough” because that's something I live by in the security field. I’ve worked in heavily regulated companies like health insurance and Fintech and cardholder data, where it's pretty prescriptive on what you have to do, but no company I've worked for is in the business to be secure. Brooks is in business to sell shoes and we're trying to minimize our attack surface. And if and when we do get hit with ransomware that it doesn't take us out as a company. For working in the retail sector for better or for worse there's no compliance framework that we really have to abide by from a holistic perspective. So we'll use things like NIST cybersecurity framework or CIS Top what was 20 I think is 18 now.

0:11:34.5 Ryan Fried: And then we usually, once a year, we'll take a look at, and we rate ourselves, at the different controls because let's say asset management. It's important for us. And if we put ourselves on a scale of one to five, maybe we're at a two or a three, but maybe we don't get to a five. What's the level of effort to get from a two to a three vs. three to four and four to five? At what point do we call it good enough based on our size, our staff, and then move on to the next thing? So really we take a look at it what's most important to us, asset management is obviously very important. And then we determine what's an acceptable score for it and improving it.

0:12:16.5 Raghu Nandakumara: That's really interesting. And you said some really interesting things there about the contrasting heavy regulated industries like finance, like healthcare, vs. a far less regulated industry particularly when it comes to cybersecurity requirements like manufacturing and retail. And when I think about those highly regulated industries typically they have the three levers. The one is the regulation, one is a very clear idea of this is something that I absolutely have to protect otherwise loss of reputation, loss of business revenue etc. And then there's often been a seismic event that affects that industry, that sector which means that no one else wants to be the headline act. But now in the, not unregulated, but the less regulated industries, how do you essentially build those levers to move your program forward?  

0:13:12.7 Ryan Fried: Yeah, I think the most important thing that we've done at Brooks, and I've seen in other companies, is having that steering committee. So my boss meets with the COO, the CFO, head of privacy and head of legal, and for them to understand the importance of security, that buys us a ton of leverage. So I think that's really the most important thing, you need buy-in from the C-suite and to be able to articulate where we are, where we need to get to be and what it takes, whether it's money or people, is really how I found the most successful way to do it.

0:13:48.0 Raghu Nandakumara: And how do you contrast the role that you do today at Brooks with some of the roles at your previous employers in those regulated industries? What are the challenge in one vs. challenges in the other? And so, because it's really interesting that you've moved around in these different industries doing this role.

0:14:09.1 Ryan Fried: Yeah, I think our North Star is a little bit different. So working in a highly regulated industry for HIPAA for insurance, we were much more data-driven. We used tools to find confidential restricted data. We did more around data loss prevention. Not to say we don't do that at Brooks, but we don't have that data that is highly regulated. While at Brooks, we're much more focused on availability. So looking at ransomware drives a lot of what we do. So yeah, I would say while we do think about maybe some proprietary type of data in intellectual property, we're much more focused on availability from different threats.

0:14:52.2 Raghu Nandakumara: And I find that sort of really fascinating because that we think about that traditional, the CIA triangle of security. The C typically gets a lot of focus. And the I gets decent amount of focus and the A often gets not ignored, but is the bit that everyone is willing to sacrifice in order to protect the C and the I. But again, I think, I feel particularly with the term cyber resilience really coming into vogue over the last couple of years that the focus on the A is increasing and organizations are putting far more importance on the availability pillar of the CIA triangle in addition to the C and the I. Is that how you see it?  

0:15:37.3 Ryan Fried: I really do. Yeah. We think about the availability of our ERP system. One thing I've noticed is more and more companies are, from my experience, testing that ransomware recovery. It's one thing to put it in place, but to be able to find out how long it actually takes and then actually recover it and have that business user be able to get the data that they need to is really important because you don't want to do that for the first time with ransomware. And then it's super interesting to find... I've been involved with business continuity efforts and let's say someone needs application XYZ, you ask them how quickly and they say an hour. Because why not? Why not say an hour? When in reality it might take our infrastructure team eight hours and then figuring out that discrepancy where they can say, “We can do it in an hour, but you're going to have to pay for another data center that is active and writing and it'll costs say a million dollars and then they're like, ‘Eight hours sounds pretty good.’” So managing those expectations of how long it actually takes for those critical applications is important to level set because it takes longer than you think.

0:16:52.5 Raghu Nandakumara: Yeah, absolutely. And you said so... Just a couple of things. Sorry, I get really excited when our guests, just this stream of thought and everything, I kind of want to double click on all of those things. So let's start at the beginning of that stream of thought and you talked about effectiveness and how effective are my controls. So a bit of a loaded question, in your perspective and again this goes back to your time in more regulated industries is, what do you see as the difference between being compliant and being secure?  

0:17:27.9 Ryan Fried: Yeah, that's a huge difference. So compliant can be used in a positive way. In working in with credit card data, PCI is really prescriptive and it does have a lot of great things, but it also recommends eight-character passwords, which I have a hard time with. So it's a good baseline and you can use it to get stuff done. I think having that threat-based approach of what industry are you in, how are attackers going about it. For instance, with cloud, Gartner comes out with I think 90-95% of cloud breaches are misconfiguration. I don't know that audits are talking about that, but that's important because we have a cloud presence. So compliance is good, it can be your friend, but that can't be all that you do.

0:18:18.4 Raghu Nandakumara: The way I look at this from previous roles is that often compliance and audits are checking against a checklist or a set of standards that you have defined vs. as you say, compared to what is the real threat and how could it exploit this current configuration. So that then brings me onto the follow-on question to that sort of stream of thoughts you shared is that how do you test that your controls are effective?  

0:18:52.0 Ryan Fried: So now you're coming about my passion project in my last couple of jobs.

0:18:57.6 Raghu Nandakumara: Alright, let's go.

0:18:57.8 Ryan Fried: Yeah, when I first started, talk about the 10-year evolution. You'd pay a pen tester however much money and they would basically just run a Nessus scan and tell you these are all your vulnerabilities and that was it. The next part I've seen is now you pay a pen tester, maybe you give them access in your environment, maybe you don't. Probably not. They try to get in, they might get in, they'll get access, and then you fix those things. In the last couple of years, you start to see the evolution of purple teaming and tools like Atomic Red Team, where now someone who is not trained as a formal pen tester can actually run simulations of what hackers are using.

0:19:38.7 Ryan Fried: So I'll look at different reports from Mandiant or Red Canary and it will say, these are the top 10 hacker techniques that we've seen over the last year. And then I'll actually use a tool to run those techniques on my laptop in our network. We'll see what our EDR or firewalls catch. If they catch most of it, great. And if they don't catch something, I'll write a detection from our SEM or EDR, so we'll catch it next time. So a quick example is, most hackers when they get in, they'll run something like, who am I? To figure out exactly where they are, what account they have. And we saw that our EDR tool didn't detect on it, so we wrote a quick detection anytime we see that and we've caught pen testers like that with something so simple and so early. Yeah, I just think using stuff like adversary emulation or even running stuff in command prompts, like who am I or sysinfo or net group admin is really impactful and free.

0:20:46.3 Raghu Nandakumara: So I want to ask that. And absolutely, and I think that really is the evolution of security testing. Where now I believe we're at a stage where we're far more realistic in testing our security defenses. And of course, team exercises allow a quick feedback loop to improve that. But when let's say you are there, you are shopping for the next security capability that you want to bring on board to protect in this case Brooks, how do you validate whatever that vendor is trying to sell you is actually going to provide you with the security uplift that you are expecting? How do you go about that?  

0:21:30.1 Ryan Fried: Yeah, I think it's really important to define really prescriptive success criteria. So like what use case are you trying to find? Because you're not going to have a good time if you just go in to look for a vendor and say, I want the capability to do this. Why? What are you trying to defend against? And can you emulate that? If you're looking for a cloud security posture management solution, maybe you do a quick POC and then you make an S3 bucket open to the world with no data in it and see how quickly it catches it. Or for microsegmentation, maybe you have a laptop and you do an Nmap scan to the whole environment and see what it can communicate back. And then you put the tool in enforcement mode and see what you can still reach. So I think you need to understand the use case and the problem you're trying to solve before you even think about looking at vendors.

0:22:30.2 Raghu Nandakumara: Yeah, absolutely. I agree. because it's the, and I think both from the customer side is having a clear idea of the use case that you're trying to solve vs. a general, "Hey, I need this capability." It's gotta be tied for benefit. And then I think from a vendor perspective is being able to clearly connect with that use case as opposed to saying again, "Hey, we're selling you this capability," and it just works like this. And being able to say that, I think that's so important. And I want to go to the next thing because this is a Zero Trust Leadership podcast. So we're going to talk a bit about Zero Trust. And I know that you are very much a Zero Trust practitioner. You've built at least two Zero Trust programs at different employers. Firstly, how do you think about Zero Trust and why does it resonate with you?  

0:23:23.4 Ryan Fried: Yeah. So I always think about the Target breach from about a decade ago when an HVAC contractor had access into the network and then was able to access cardholder data. That's one of the reasons we're trying to do it. Or I basically think about if and when a user is infected, how do we minimize that blast radius giving them least privilege access so they can't do much damage?  

0:23:52.4 Raghu Nandakumara: So when you apply that, and of course... So that absolutely maps to the Zero Trust approach to security, then how do you then build a program to go and help your organization adopt that approach? Because we hear consistently that Zero Trust is a great idea, but difficult to achieve in practice, and yet you've done it twice successfully. So what's the secret sauce that you've got that others need to know?  

0:24:23.0 Ryan Fried: Sure. Zero Trust is more of a principle I've been able to apply it in a couple of different ways. In almost everything we do, we think about how can we go towards Zero and also Zero-ish Trust. Actual Zero Trust is really hard to do, and I think it's really intimidating. When I first thought about Zero Trust, I thought about being able to allow less server-to-server communication, which really scares me, and it's really production-impacting. But for instance, what we're talking about is microsegmentation from a Zero Trust perspective. What is the best bang for our buck that we're going to get with being the least disruptive? Because as you, and I'm sure your listeners know, I've lost credibility because of a tool or a technology, some kind of security tool that blocked something, maybe it was a legitimate block, maybe not, but it's really hard to gain that trust back.

0:25:22.3 Ryan Fried: I've had tools where anytime something broke, they were like, "Is it that tool?" I'm like, "No." So, going off of that, we looked at workstation-to-workstation communication, which should be none. And then user-to-server interaction, because over 90% of our employee base are not in IT. So they really don't access servers unless it's through HTTPS they are not remotely accessing them. And when you think about from a threat perspective, most of the intrusions start with a phishing email on a workstation, people don't normally access email on a server and they shouldn't. How do I make it, so I hear someone got hit with ransomware that were not having a bad day, they can't affect any other workstations and they can't affect most other servers. That for me is the Zero-ish Trust from a microsegmentation perspective.

0:26:19.2 Raghu Nandakumara: I like the way, how you said it's Zero-ish. because I think it goes back to something we were talking about earlier is good enough. And it's drawing that line between this... I know that this is where the... And I think to paraphrase what you just said is, I know that these are the biggest risks with overly permissive access within my network. So that's the access that I'm going to focus on reducing that implicit trust. So moving towards more Zero-implicit-Trust but I draw the line here because, beyond this, the return I get for the effort I'm putting in is negligible or potentially I think going back... And that was a really important point about... It's potentially a career-defining often. Security controls are career-defining because if they go well and you are able to show that you've reduced risk and your exposure, then everyone sings your praises. But there's a far greater chance that some critical application will break and they will be like, "Hey Ryan, hey Raghu, let's have a chat about this thing that you just applied." And as you said, you have to spend hours, days, explaining why it wasn't your product that caused the issue. Again, I think maybe just to reiterate, what is that measure that says up till this point, the effort is worthwhile? That's the good enough. And then beyond this, the cost is high to get more benefits. How do you draw that line in the sand?  

0:27:56.8 Ryan Fried: Sure, it can definitely be subjective, but for me, I think about the administrative overhead and then the production impact to applications. People in their job description other than us, it doesn't say to be secure. They need their applications to run. So I can give a good example of something we didn't do because I didn't think it was worth the bang for the buck. So another potential risk is let's say a server gets infected and they visit a command and controlled domain and download malware and they are infected. Straight from the server, didn't require a user to connect to it. Now one thing we could do is do Zero Trust where we only allow applications or servers to go to specific domains, certain websites. Realistically, servers don't go to a lot of websites but the work behind that is incredible. And I only know that because we tried it. There are so many domains on a website that things reach out to. So it would be an administrative nightmare and production impacting if let's say they download a new application, it doesn't work. And let's say it's someone in Asia or Europe and I'm the person doing it. So really what I think about is, what's the risk? The risk is our DNS not catching that domain, our EDR not catching that domain, our firewall not catching that domain, and it's a C2 server. Can a state actor do that? Sure. But for me that's not worth it because of how production impacting it can be. So we've done it other ways.

0:29:45.1 Raghu Nandakumara: Yep. And I have a similar experience, so I absolutely understand that. So what is the future for your Zero Trust program and how you think about that continued evolution? What does that look like?  

0:30:01.1 Ryan Fried: Yeah, I think from microsegmentation, making sure it's applied everywhere. Looking at different use cases, maybe more from a visibility perspective to figure out what's talking to what we look at public cloud and making sure we're using as least privilege as possible when it comes to roles and access and such. And in least privilege access in general across our active directory accounts, both in Azure and on-prem. Those are some of the big things we're working on.

0:30:29.6 Raghu Nandakumara: And you talked about cloud a few times. And, often organizations and practitioners differentiate between cloud security and traditional campus and data center security. And, actually, I was at an event earlier this week and on stage was essentially a person who ran DevOps or DevSecOps at a large financial organization. And what he said was, the problem we've created is by saying, “Okay, I do separate security differently or how I think about security differently for cloud vs. legacy, traditional, whatever you want to call it.” What are your thoughts? Because his perspective was you need to think about those in the same way so that you have consistent security.

0:31:18.0 Ryan Fried: I absolutely agree. The saying I always go by is the cloud is just an extension of your data center. Whether it's a VM, a Windows VM in the cloud or in your data center or under your desk. It still needs to get patched, it still needs the certain agents and it's a really dangerous view to view them separately. And I think it is taking some time to get used to, both from a security and infrastructure perspective. But like you said, the controls need to be similar. Now when you get to certain things like services and storage containers, those can be different. A VM is a VM, whether it's ephemeral or not. So you still do need that visibility and patching and such just like you would in your data center.

0:32:04.6 Raghu Nandakumara: So what sort of, now when you look at, what you are looking at into the future. What are the trends, technologies that really excite you? I know you've spoken a bit about your passion project, but what are you really looking forward to happening in the cybersecurity world?  

0:32:24.8 Ryan Fried: Yeah, I think just improvements in asset management, like we talked about, more of that API-based approach to figure out what's your total asset count. That's a hard thing to find out, but I also think in the coming years we'll see some more technology around API security. I think that's something that companies probably have more exposure than they realize, especially if they have applications, calling applications in your network or more likely in other staff-based applications or networks. And you might have no idea what kind of security you have for that. So I'm really excited to see that technology to find out where are your APIs and what kind of security do you have around them. And then having that developer-based approach where, that's not my expertise, but I would love a tool that it’ll put it in the developer language and with the proper criticality so they can fix it.

0:33:19.3 Raghu Nandakumara: And actually, you hinted on developer and we hear a lot of terms like DevSecOps and a shift-left and secure by design or secure by default. I'm by no means an expert in any of these terms, but I'm... I'm dangerous enough that I've read them and that I can blurt them out. What do these mean to you and what do they mean to what you do as a practitioner?  

0:33:46.1 Ryan Fried: Yeah, I think shift-left is really important. I've been on both sides where developers will say, “Hey, we have this application that's going to be going in production in two weeks. Can you just give a sign-off?” I'm like, "What?" And then we use different tools to be able to try to look at application vulnerabilities and such. And we figure it out. Most likely it's going to go live anyway. So ideally we get involved from the beginning and I don't have a huge application development background, but sometimes I find just having security in the room makes them talk or behave differently in that initial discussion. But then I also think it's really important because there are static code analysis tools, dynamic code analysis tools. Let the developer pick what they like. Because most likely I'm not going to be in it day to day, I want something that's developer friendly. And so we've had good success with that. Obviously, we want to look at it to see if it has the baseline minimum of security-type checks, but we want it to be in a language where they understand and we're more of in a consultative role.

0:34:56.1 Raghu Nandakumara: I'm sort of been playing with the idea that adopting a Zero Trust approach to security really aligns with a shift-left. And taking that rather than trying to block bad things, being explicit about saying, these are the good things I want to allow very much aligns with let's say the development of an application where it's almost you're saying, okay, I know these are the things I need the application to do and I want to write the security rules that allow me to do that. So do you think it is the case that as we see security shift-left, that will... In order to make that practical, it'll be an increased adoption of Zero Trust or to put it a different way, essentially more focus on defining an allow list-based security?  

0:35:48.4 Ryan Fried: Yeah, I think the shift-left definitely plays along with it. I think about now as we onboard new servers or applications, we're involved earlier because it's going to be put into our microsegmentation environment and we want to understand what communication that tool actually needs. And I can give a quick example. We've had an application where the vendor said we need ports one through 65,000 opened, which is wild and extremely lazy of that vendor.

0:36:16.7 Raghu Nandakumara: What about the other few hundred at the end. They didn't want those?  

0:36:20.6 Ryan Fried: Yeah. They were trying, the least privilege or Zero-ish Trust. If we we're involved early, we can let it run for a month and see that maybe it's a range of only 100 or 1,000 ports. But if we're not involved early and they install the application without us knowing and it's already in production, we're probably going to have to keep the one to 65,000 unless we have extensive work and a quick feedback loop. Being involved early in that requirement phase and looking at the data that helps you be successful in a Zero-ish Trust strategy.

0:36:58.1 Raghu Nandakumara: Absolutely. And I think that I think then comes back to sort of the maturity you were talking about that as that program matures, naturally the engagement of security shifts further and further to the left. And again, how far left really depends on how far you want to take that program. I mean like we've said there's so much more that we can discuss, but I'm conscious of your time. What are you excited about in terms of the future? What are the things that you'd want the listeners to hear and take away and maybe put into practice?  

0:37:37.3 Ryan Fried: Yeah, I've been talking about like the control validation. I've been really excited to see the shift in security of really the collaboration and the actionable threat intelligence. I think MITRE ATT&CK has been a really positive thing for the industry to basically codify what attackers are doing from a high level. So to be able to be part of an information sharing group or go to a conference or just read articles and see what are hackers using, and then giving you the value or the command to run. That way you can run it in your environment to see if you are affected. Because previously you'd have a pen test once a year, and then after that, you have to wait until next year and it's, it becomes stale very quickly because of the adapting environments. So I'm really excited to continue to see that happen and maybe even shift the cloud to see what are logs that I should be looking at. What are attackers doing? How can I emulate it? How can I see if it would work or not?  

0:38:40.2 Raghu Nandakumara: Awesome. The other thing, Ryan, is it true that at Brooks Running, you do all of your important security meetings while out for a run in Brooks trainers? Is that true? Just let us know.

0:38:49.0 Ryan Fried: Yeah, I think I was telling you prior, as I interviewed, you have to send in your 5K time and be under 20 minutes.

0:38:55.1 Raghu Nandakumara: Having run with you, I'm pretty confident that you could do a sub-20 if you tried. I know you were going easy on me that day. Ryan, it's been such a pleasure to have you. It's always a pleasure to converse with such a wonderful security professional like yourself. So thank you so much for your time.

0:39:14.0 Ryan Fried: Yeah, thank you for the opportunity. It's been great.

0:39:16.6 Raghu Nandakumara: And, yeah, and if you want to learn more about how Illumio is helping organizations like Brooks Running reduce risk and run down cyber-attacks, you can visit our website illumio.com and check out that customer case study and a whole bunch of others. Thank you so much.

0:39:37.5 Raghu Nandakumara: Thanks for tuning into this week's episode of The Segment. For even more information and Zero Trust resources, check out our website at illumio.com. You can also connect with us on LinkedIn and Twitter at @illumio. And if you liked today's conversation, you can find our other episodes wherever you get your podcasts. I'm your host, Raghu Nandakumara, and we'll be back soon.