Listen to learn about what is driving the continued shift to the Cloud and Cloud security fundamentals.
Chase Pettet (Chief Security Architect at Archer Integrated Risk Management) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to dive into cloud security 101.
Listen to learn:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics podcast. My name is Jen Stone. I'm one of the principal security analysts here at SecurityMetrics. And today, we're gonna talk a little bit about cloud security. Let me talk to you about, our guest. Chase Pettit is the chief security architect at Archer Integrated Risk Management. It's an RSA security company.
And, Chase is a distinguished security professional, partner, advocate, architect, engineer, people manager, and data security enthusiast.
He has an emphasis on risk informed decision making, automation, tactical optimism, I love that, and fostering healthy cultures of collaboration to help build and grow successful initiatives across industries. Chase has worked for companies behind globally ranked top ten and one hundred and fifty websites for a decade in these capacities as well as highly regulated environments for an additional decade. This includes HIPAA, PCI DSS, FSMA, and ISO twenty seven thousand and one. Chase is a lifelong builder and continuous learner who can often be found in the workshop. He lives in the Midwestern portion of the United States with his wife and two daughters. Chase, welcome to the podcast.
Thank you very much. Yes. Appreciate it.
So so tell me let's I mean, before we jump into the, the topic, tell me a little bit of your background. How did you how did you get to be here in your career? What where did you start? A lot of people like to know, you know, what's the avenue that takes them to to being a security professional like you?
I wanted to be a network engineer. I thought that was, like, the the top of the mountain at one point, and, I was really fascinated by it. So I did that. And then I was at places where it was always pretty valuable if you had a primary skill and then a secondary or even a couple secondaries.
Mhmm. So and I did network infrastructure and then network and Linux infrastructure, and then security kinda crept in on all those fronts. And I was at a series of places where no one really held, like, a official distinct security title. And so I just I inherited more and more and more of it until I was at a place where I just finally made the leap and started doing nothing but that.
And, yeah, it's been going well.
Excellent. I I often have people ask me, how do I get into security? Where what's a good starting place? And I tell them, an excellent entry level position for security is IT.
Mhmm. Learning about the basics of how how architecture works in a in a network. How how to build that, how to manage it, how to make sure you've got your your, patches, you know, on on the various things. And that doesn't always it seems, like, obvious to me that IT would be a great starting point.
Networking is is a great starting point. Systems management is as well. System administration, good starting point. But that doesn't always seem, like, obvious to people who are interested in in security.
But if you if you understand that as a background, it gives you kind of a basis for learning how to protect the things.
Yeah. Depending on kinda what arena in the broad umbrella of security you find interesting, you're gonna find yourself relating those concepts just every day.
Right.
And so having a a pretty broad background in them really helps. Yeah. It really kind of accelerates your you know, you get dropped into a situation. You have to orient yourself, and that's a big that's a big boom from that front.
Yeah. And risk management, it seems like regardless of how you apply risk management, understanding just where to start with on it, it is a good jumping off point.
Yeah. I I mean, risk management is such a long and storied topic that goes back so much further than than IT.
And, some of the kind of youngness of the industry, the youth is running into some of the more established industries. And so financial, risk management is kind of starting to overlap with with IT. And so I find that to be a really meaningful subset of just language and skills in terms of running information security programs. I wanna say the words at scale, but, you know, in a way that's integrated with the business at a place where it's more than a few hundred people, that's the language of it to my experience.
Yep. For sure. And and, sometimes we use language in odd ways in security or even specifically in compliance, that's intended to create security. We use words that mean so many things and you kind of have to know which one you're talking about. Let's take the word segregation.
Like, let's let's say you're trying to keep credit card data secure. And so, you're doing the PCI standard and you're supposed to segment a network, a subnetwork from other things in order to, you know, declare your scope. Well, segment can mean so many things depending on who's using the word and in what in and in what way.
Yeah. I'm I, I've worked with a couple of different places that were very international. Right? And some of the best engineers I've ever worked with, English is not their second language.
And I am blown away by people who can have high level conceptual conversations in a second language Yeah. Especially when you're reusing words and descriptors that have multiple meanings and have a lot of nuance to it.
It really kinda speaks to the necessity of shared language. Yeah. And then, you know, like, the need for common ground. So Right. I find that really fascinating.
And I think that, you know, to your point, the common ground, the more experience you have in as a security professional. If you wanna talk to the people who are are hands on making the things happen, you kinda have to have a background technical at least a little bit to understand what they're saying. And then you wanna take and apply that to the decision making from the c the c suite. Well, you have to also understand where they're coming from with the same words, but maybe little slightly different connotations. Right?
Yeah. Yeah. Definitely having kinda having been in the mix. I was actually thinking about this earlier yesterday.
Some of our some of the operations folks I talk to right now are, you know, kind of a rock and a hard place thing. And I've been in that hard place at other gigs, and so I have almost, like, a visceral a visceral understanding in my chest of, like, what it feels like to feel kinda caught in the middle between competing constraints. And I do feel like that pushes me to go a little farther to empathize and try to find the solution that works for everyone because I don't take it personally, and I don't think, you know, like, people who are responsible for keeping a system up and stable sometimes, you know, the ultimate, polarity there is, like, making progress change versus stability.
Right.
And the people on both sides of that equation have a good intent, and you just really have to work it out and and keep it not personal and relate it back to you know, a a thing that I tell myself is I am not trying to find the best solution. I'm trying to find the best solution given the constraints of the situation, which maybe sounds, I don't know, like I'm wriggling out from underneath something, but it just, to me, means there might be a a technical mountaintop, but that's not necessarily what can happen in any given situation. And if you're really fixated on something that's unrealistic, you can cause way more harm than good.
Yeah. No. I don't think that that's an unrealistic way to put it at all.
Taking things into account and finding the best way, isn't always the, the most technical way or the most, you know, if you're trying to to solve all security, that means you don't have any communication. Right? So it's always a balance between, as you said, competing constraints. What do you want to have happen and how do you wanna have that happen? And and what is best for one organization might not be the same for another.
And it kind of depends on your environment. So that brings us to the actual topic for today, which is cloud security.
So what's changed? What's the same?
I know originally when when organizations started moving from on prem to cloud solutions, that was a that was a big conceptual leap, and not everybody made that leap. A lot of organizations took, what they had in their on prem solution and just rebuilt it in the cloud. Some some organizations, the the IT folks were were a little concerned that, you know, what's going to happen to my job if what I do now transfers to the cloud? First of all, what do you think is driving this shift to the cloud? And do you think it is all one way at this point? Are we all moving to the cloud, or is there is there a shift coming backwards? What what's that that look like from your perspective?
Yeah. There's a there's a couple of big cycles. You know? It's like, I've noticed that large scrunchies are back.
My daughters are wearing them, and those are big in the early nineties. And so it makes me think about, like, the the push and pull between local compute and, like, mainframe compute. So, you know, like, time renting versus, buying something and and depreciating it over time, like, which one's more efficient. And it just seems like things push and pull back and forth.
So I don't think it's ever gonna be one way. I've act I've heard, folks say, like, there's no reason to ever run your own on prem, cloud or whatever.
Mhmm.
That seems way too broad Yeah. To me. I can think of a number of situations where it probably makes the most sense. But in terms of, like, moving to the cloud, it's interesting because we don't always think of SaaS as, like, part of the cloud migration story, at least when we're talking in technical terms.
Like, most people I talk to immediately jump to infrastructure as a service Mhmm.
As, like, their kind of anchor. But, really, the the push towards SaaS solutions and, I don't wanna say, the loosening of of data data sovereignty, but sort of defining what it means for other people to hold your data and and what the safeguards are.
Right.
That has been part of the the you know, it's like, I read a meme that said something like in the nineties, it was don't talk to strangers on the Internet, don't ride with strangers, and now it's like, you know, order a stranger in an app so that you can ride in their car. Yeah. And there's been a a similar kind of loosening of norms in terms of, what happens if I disseminate my data out? How do I protect it?
How do I account for that? And I think some of that is SaaS and the appetite for that, and then it kind of works backwards into the more technical realms of we wanna do infrastructure as a service. We wanna do platform as a service. Mhmm.
I'm I'm talking a lot, so please interject if No.
This is great. Well, I think one one thing is that most of our listeners understand that SaaS is software as a service. But, I I think one of one of the things we should do is talk about what what do we mean by that, and in what way would we be sharing our data with a with a SaaS solution. There's a couple that I can think of, like, really quickly, which is, well, are you taking care of your own logs, monitoring Mhmm.
And alerting? Are are you your or do you have your own, security operations center that's taking care of all that? Or are you shipping your logs to a third party organization that's that's keeping an eye on things for you? Right?
That could be software as a service. That could be another would be, EHR, which is a elect electronic, health health records. Right?
That's that's a really big one because, originally, people said, no. You can't take PHI, protected health information. You cannot put that in the cloud. Right? That was a huge one that people thought Yeah.
Yeah.
You could never do that. And now everybody's saying, no. You absolutely can and kinda need to do that.
And so, like you said, that it it goes back and forth, but, sometimes people don't even realize that's what they're doing with some of these big application solutions. Right?
Mhmm. Yeah. The the FUD has dissipated over time. Yeah. You know? It's it's become sort of, less and less resilient to real introspection. And I think some of that's totally valid.
The one thing that I I really like, with Amazon, I love their sort of pictograph of the shared responsibility model Mhmm. Because I I think that people understand that. My experience is that is a great jumping off point for we are transferring liability for some things by paying other people to do things we could otherwise accomplish, but we are not abdicating responsibility for our data. We are not abdicating responsibility for our users or our operations. Right. And I do feel like some of the the cloud marketing copy in the early days was was trying to say that without saying it because they knew they couldn't, and it's come back down to reality in some respects Mhmm.
Which is good. But, okay. So in terms of, why are people moving to the cloud I'll try to circle back here. Great.
I have this theory a little bit that as the systems become kind of more powerful, more robust, and cheaper, that we are able to optimize for things that are more human.
Right.
So, like, if you wanted to write a program in the early nineties, in many ways, you were probably dealing with memory constraints.
And, like, a lot of the really cool old PDP stories are the clever use of memory or storage because they were dealing with so many resource constraints. But that has shifted so much that now you're to the place where if you wanna hold, you know, n number of copies of of a library in a container across your fleet, that's that's not a burden, really.
Yeah.
And so the the storage and the compute, all of that is so ubiquitous that, really, you can start to optimize for the human element, which if you backtrack honored enough is really, like, the innovation element. And so my thinking on that is is cloud in general has been kind of moving towards a, improving time to market, story and improving time to value rather than, like, the early days, I heard a lot more about cost optimization. I remember AWS, taglines, I don't know, maybe ten or twelve years ago. And it was a lot about, you know, saving money, finding ways to save money by by farming out these problems.
And I don't hear that as much anymore. No. Now it seems to be much more about, you know, not reinventing the wheel, focusing on business differentiators, and things that make total sense to me in terms of that shared responsibility model. Like, businesses don't necessarily wanna have to build their own roads.
They just want cars to transfer things from a to b. And so that's nice, generally, especially if you're looking to focus on kind of the business logic of of the whole thing. So my take is is that it's it's gonna continually move in that direction just because there's so many economies of scale in terms of a loud a large cloud operation.
And, really, you could drive down costs, but I don't I don't think that's the driver anymore. That's not what I hear when I'm talking to, you know, people who control the budget. It's more about, you know, how can we empower faster, better innovation? How can we improve quality?
You know? And you can do that through a bunch of patterns that are that are enabled by certain technical things on the back end, like, you know, composable, recreatable environments that you can stand up and blow away. That's a that's a big thing for developers to be able to do. And it really just wasn't possible in the same way even in the early zeros.
Right.
So I think that's why, and I don't think that everybody is is moving towards the cloud. I mean, I know a number of large places that they're so big. They have their own economies of scale, and they have their own, you know, special considerations that aren't tied back to, the technical elements of things. Like, I used to work at, Wikimedia Foundation. You know? They famously run Wikipedia and and a bunch of other projects.
And one of the concerns there was, privacy and data sovereignty and who do we trust to be in the middle of users and content Because it's it's not a mercantile operation. It's it's a nonprofit.
And so maybe there are things in the cloud universe that could have been leveraged stronger or more often, but it was almost always looked at through this, kind of privacy advocacy lens. And, you know, those are gonna be very different technical outcomes once you hit the ground versus what is the most efficient way to to process these bits.
Right. And and efficiency, isn't isn't the only concern. It's it's a primary concern for some groups. It's not what for for some other groups. There there are, like you said, that sometimes we've got maybe, regulatory, aspects that have to be considered that, that make it so that you either can't be in the cloud or, more likely, you can't be in the cloud maybe in certain parts of the world.
Mhmm. Alright. So Yeah. So when when we look at, kind of those decisions, I think you're right. Sometimes it's it's, what do these cloud, you know, platforms offer that make it easier for the organization to do what they do really well and and offload the stuff that they're they're not the experts at?
Yeah.
And they're really hard, really time consuming, and risky in terms of cost to try to do it yourself versus taking the commodified experience of it and then building value on top of that. And, plus, the biggest thing that I've heard that I thought was a bit of light bulb moment for me was, talking to a a really smart product manager about all of this, and we were talking about data sovereignty and locality and just kind of a decision point. And one of the things she said to me was, I just don't want to incur the opportunity cost of building up all of this, table stakes infrastructure on our own when we could be using that time to work on the product, the things about what we do that make it different and special. And I was like, bam. Let's put that on a shirt.
You know? Absolutely.
One of the ways that I'm seeing this is we kinda talked briefly about it a a little while ago was, you know, the the architecture, how architecture might be different for on prem solution versus in cloud. I think early on, the in cloud, solutions really looked like on prem architecture. And when we talk about architecture, this is like, someone described it to me once, says, stuff that's harder and takes longer to change. So, like, the the underlying structures on which your your solution, your your product, your data, your, you know, applications are built. Right?
Mhmm. Yeah. Totally.
And and so early on, we we really did see you know, you had your your server farm, on prem. People said, hey. We're going to the cloud. And then they they rebuilt their server cloud up in the cloud.
So they they took all of the things that existed and maybe weren't efficient and and just recreated it. But more and more, I'm seeing, especially for for greenfield applications, people are are taking it to the the service layer, in in the cloud. Are you seeing that as well?
Oh, yeah. Definitely. Like, when I review projects internally where I'm at now, I often describe that as using cloud primitives, like, versus building on top of an e c two. And so, like, we have a push and pull between kind of historic on prem customers and and new SaaS customers.
And so when you're looking at features or products or components that need to live in both worlds, you're always kind of finding that happy medium in using what I call cloud primitives. Right? Like, are you gonna use Lambda? Are you gonna use RDS?
Are you gonna use things that are kind of value adds of that ecosystem?
When you program in in Python or some other language, they're you know, generally, you have the same data structures, the same control structures, and all that. But you also have a bunch of, like, idioms that are very specific to a language that probably is something that isn't expressed the same way or accomplished the same way in other programming languages even if the end result is the same. And, like, it's very similar in in the cloud computing context. AWS has certain idioms that make sense there. Google Cloud has certain idioms that make sense there. And so when you are designing something to be, you know, really native to that cloud experience, it can be efficient and cheaper and everything else, and and then you get into portability concerns. And, yeah, it's just part of the process.
This episode is brought to you by SecurityMetrics Shopping Cart Monitor Inspect. It's a revolutionary new product that can help you detect any problems with your shopping cart security, allowing you to effectively improve your ecommerce security. Here's what I know about it. A lot of times people say, well, hey.
I am PCI compliant because I passed my SAQA. Great. You're missing most of the things that people are actually stealing information from right now. Shopping Cart Monitor was created to actually close those gaps and help you against things like made cart and other known ecommerce issues.
To learn more about this shopping cart monitor, head to our website www.securitymetrics.com/shopping-cart-monitor. So, taking that idea from a security spec perspective, how do you think the the different types of of architecture, these different, you know, basic foundational choices, how do you think it affects security?
I kinda think that the move towards programmatic architecture programmatic infrastructure is maybe the lead that's buried when we talk about cloud because you don't necessarily have to be using public cloud to have, you know, declarative, programmatically driven infrastructure, but that's sort of the end result if you wanna do it well. But you could totally build that all in house prior to kind of the the big guys. And in some cases, I did. I'm sure a lot of people built mechanisms for that kind of automation and and, infrastructure as code way before AWS.
But and that, programmatic declarative and and then kind of by extension, the compute the composable, repeatable, deterministic nature of of infrastructure and, being able to describe a a stack, you know, in one place and then repeat it.
That has to me been kind of the biggest transformation, and it's really hit security in a few different ways.
One of them is it's difficult to be a security engineer and not be somewhat educated on at least reading code.
Everything is code anymore, at least in most of the environments I operate in. You have to be able to read, you know, Terraform.
You probably have read Puppet or Chef. You've thought through, you know, how those things are are implemented and how they impact, existing projects and and other projects that are coming down the pipeline.
The other thing that I think is is interesting is that in many ways, the anatomy of of the field of of an information system information security management system is the same. Right? But, like, people have legs and and crabs have legs, but if you confuse them, you might be in serious trouble if any of the.
And so, you know, for me, like, I've been in environments that are that are primarily hybrid, and policy was always the same. We have the same policy regardless of context, but then the standards were probably a little different. Right? What were we doing?
And then the procedure for how to do it was way different. But the policy, the conceptual element, the principles, really, they didn't change. It really came down to the context, which was always true before, but now you have this arena where there are there's a proliferation of, like, best standards and practices because it's all shared. Mhmm.
Right? Like, back when, I remember learning someone's infrastructure, and you would always kinda have to tally what what skills would translate to your next job necessarily. Like, maybe you were used to VMware, maybe, you weren't. What was the, you know, virtualization engine?
What were the networking devices in use? Like, it was very much a compartmentalized world in terms of on prem deployments.
For sure.
And now I see a lot of advertisements that are just like, do you have experience in AWS? Great. You know? You can walk in the door with with so much context. It's it's kinda crazy, just all of the shared concerns.
But from an anatomy standpoint of, like, how I think about running a security program, you know, it's it's certain layers that are now now have contextually specific applications in the cloud arena. If you still have on prem or if you have IoT or whatever, you know, they're gonna have different standards and procedures.
I would say the technical controls are much, much different in terms of of what we used to do, both because, you know, it's great that the the ground floor has been raised from a development perspective so that, you know, it's possible to just write code and and run it, and that's the extent of your concern. Right. But the same is true in many cases for security.
Like, AWS, guardrails, in terms of, like, multi account management and all that.
All the things that you can kinda do magic sauce out of the box in that scenario if if you know about it, that would have been so much work to even get that capability Right.
In a job fifteen years ago Mhmm. That it's kinda wonderful. And then the flip side of that is, you know, now you are really beholden to the entire life cycle process because things are moving so fast, because declarative infrastructure can be reshaped, redeployed.
You have to be so close to kind of the inception of those those concepts and models in order to have them secured in place when they manifest that whereas a a pound of, no, an ounce of prevention used to be worth a pound of cure. Sorry if you hear my daughter.
Now it's like an ounce of prevention is worth twenty pounds of cure just because of how quickly issues can spiral when, you know, you have one service that gets deployed and then another is deployed on top of it, and you get all kinds of interconnected complexity.
And, like, soon, the technical debt can become really difficult, to reconcile much quicker than it used to, in in my experience at least, just based on how much faster people are innovating and expanding.
Right.
That that brings up a a a concept that maybe we can come up with some practical advice for people.
A lot of times, organizations are in the cloud at moving at speed with almost different paradigms in how, interconnectedness works, how security works.
But a lot of these and it's almost impossible to unmarry compliance from security. You know, the intent being, that compliance creates security. But but but we know that that's not always necessarily true. And sometimes the compliance is written, in ways that that is presupposes some of the older paradigms and and not the new ones.
And so and then you can't compound that with in order to be an assessor, you you have to have a lot of experience with various things that that you then get plucked out of your experience and become full time in security. So a lot of the assessors that are coming along might have a gap in knowledge because they went from on prem knowledge and abilities and and now are are being required to look at, cloud based models, which, of course, you can get training. But hands on is a very different thing. And so if you have a a cloud environment where you know how that that some of the the questions that you're being asked are are almost nonsensical sometimes in in terms of the new environment.
So this can make people frustrated on both sides because here you've got an assessor, you know, third party coming in trying to evaluate what you have, might need to might have a gap in knowledge, but but also might just have a gap in how you do things, not necessarily just how the cloud does things, but but how you specifically are doing that where, you know, the group that that, is creating it might be so cloud native. They don't know how to translate it backwards to to that type of of language. So do you ever run into this?
Yeah. Definitely.
I I think that this is a a new boss, same as the old boss situation in many cases, and I'll I'll attempt to explain what I mean by that.
And I'm gonna use a a a real sticky phrase, which is just to start with why.
That's been my approach to this, and I've had this sort of ships in the night Yeah.
Thing between sort of eras, right, of of infrastructure a few times. And it it kinda hearkens back to doing customer support or developer support in many cases. Because, like, security is a support function, you know, to the creation of of the product. And so I end up doing, you know, for high level developer support in many cases, how to implement certain scanning or or whatever for their code.
And it's kinda commonly stated that, I say this with love, that developers are the worst end users to support. And I would probably acknowledge that security folks are maybe even more difficult to please. But, you know, why is that? A lot of times, it's because by the time we seek help, we're ten miles down the road on what we're trying to do.
And when we finally kinda get someone else in, we don't always start with what we are trying to accomplish.
Right.
And so, you know, real cheesy example. If you get in the car, you're turning the key, car won't start.
You submit a a thing to me, and you're like, hey. Key doesn't start the car. What do? Well, we have milk in the fridge or the store is not open or take the bus or you're using the wrong key.
They're all valid Those are all valid answers.
Yeah.
Just depending on what you're trying to achieve. Mhmm. Right? And it's just rarely ever make the key start this car. That's that's so rarely the thing that someone actually needs out of a situation. It's almost always I need to go there and do this thing.
Mhmm.
And so my approach here has been in both of these cases, because there's parallels to me, I kinda go back to the original, hey. What are we trying to get out of this situation? You know? In this case, define the controls purpose.
Yeah. And then I would challenge the assumptions of the systems that you're unfamiliar with as an auditor because those are kind of the the unspoken things that are maybe missing in the details between the the system and people who are running it and then the auditor. Right? What are the assumptions that both sides are working on Right.
About how this is probably working and and what it should be actually doing? And then I would verify that the processes match the assumptions that are agreed upon, and then you spot check the the process application.
And, like, from an auditor perspective, it's easy to say and very hard to do, but I just don't think that there's another way. You kinda have to take it back to zero Yep. And have the conversation and find the shared ground and then really figure out, like, are we describing the same thing? Is is what I'm trying to get across achieving the same thing as what you're trying to do?
Yeah. And so, like, PCI example that I think about pretty far too often because it's just funny to me. But I remember in the early one dot x coming to two dot o, and I actually don't know if this is still in place. But they came out with a requirement that you had to either have, static analysis for your code or a WAF.
Yep. And I always thought that is such an interesting approach to this Yeah. Because I don't consider those to be overlapping controls at all. And yet in this land, like, the way that it's been framed, one of these two things needs to solve for x.
Mhmm.
And I always had a really difficult problem, like, defining what that thing is that both of those overlap with that they're solving for. Because to me, you need both.
Yeah.
And most of the time, if the WAF is the answer, it should be very short term.
Yeah. So because a WAF is like I mean, it it can cover it can cover for, a lot of issues, but should not cover for a lot of it. Like, it it's it's great to have a WAF. But you know what was really great? Secure code.
Right. Yeah. Yeah. And, also, just because you have secure code doesn't mean that there's not some zero day that you can mitigate WAF until you push out a fix.
Yeah. Absolutely.
I mean, both have value, and they don't do the same thing. So that to me was always I remember head scratching on it ten years ago. I still think about it occasionally. Yep.
That's it's one of my favorites as well. As much. I I also love the one about, how many how many and how complex your password should be, when we have, you know, some some pretty you know, NIST is coming out with some information that that is wildly different from that recommendation. And, so password management is is a a difficult one. I got asked the other day, hey. What do you think about this passwordless idea, and how are they gonna handle it in PCI? And I was like, meh.
Right.
So, generally and I loved what you said because, generally, when I'm working with any organization, I assume that they know more than I do about their technology.
And I also assume that, somebody's missed something somewhere. And Yeah.
And and so, like you said, trying to generally, especially if a group is already kinda frustrated with that they have to be in a meeting with me Mhmm.
I'll lay down. This is the problem I'm trying to solve. You tell me how to solve it quickly. You know, information I need specifically to that, and we're done. Right? It's it's a, it's a conversation, but it it requires dropping that ego and listening carefully to things that other people are saying. And I think it requires a little bit of that on both sides.
Definitely. Yeah. There's a lot of adult conversations to be had, which are the most fun ones when you can actually when you can have them. Yeah. The the other one that I I ran into, two jobs ago, which I found really interesting is we had a requirement.
I can't remember if it was I can't remember the context, but, it was essentially a fixed list of of assets. Right?
We needed a spreadsheet that had all of our assets on it. And in a in a cloud environment in a dynamic environment mean anything.
I don't think that makes any sense whatsoever. You Generate it on demand, and then you audit to make sure that that process doesn't leave things behind. And that is a Yep. Provably better outcome than trying to manually keep some list up to date.
Absolutely.
Yet a better outcome doesn't necessarily solve for the control as it's written. And so that for me was always the, It's pretty clear that times are changing. Yeah. The technology is changing. And in many cases, the assurance frameworks, like, are struggling with adapting the language and expectations to the kind of wildly different implementation environments.
Yeah. I think it's a I I definitely think that compliance is valuable. I've gone back and forth between, you know, the whole statement compliance is not security. And that is true.
However, there are quite a few organizations that I work with that wouldn't have a solid security program if they didn't know somebody was gonna come in and check their work, right, in in some way. And so so having that compliance there is is of tremendous value in order to just kinda kick off that process of having a having a security program in place that somebody's going to look at, somebody's going to challenge you on. And and, I do like a lot of the the the defense in-depth aspects of PCI specifically, but of a lot of these, the different, standards and and, there is in the conversation, there is value as long as as long as we stay with what is the underlying purpose.
What if if we threat model, basically, the the the current environment and and really say what is the underlying potential threat that we're we're really solving for here rather than checkboxing. You know, you just go through a checkbox and both everybody is just bored and frustrated. Right?
Yeah. Definitely. And speaking of things that are the same, the process of threat modeling is the same. Right?
Like, the specifics are different. Yeah. But the the mechanism itself and what you expect from it in terms of visibility into what needs to be protected and from who, that's the same regardless of kind of what model you're looking at in terms of deployment. And those are skills that you build up over a long bit of time.
It's really difficult to almost put into words the value of, like, experience because sometimes you walk into an organization where your title is supposed to be, you know, a senior type person, but so much of the value of that is the context that you hold on on the organization, and you don't have that when you walk in brand new. And so you're really you're you're right for imposter syndrome.
But in terms of, like, kind of being able to talk through a threat model in the exercise, being able to describe how a security program can be run, what what the shared language is, what the, you know, why you should have an awareness program rather than just, a checkbox that says you have an awareness program. That's kind of where experience and having gone through it before seems to come into play.
Mhmm.
So, luckily, a lot of those kind of skills and perspective translate.
And then whatever is beyond cloud computing, you know, implantable, peer to peer net, who knows what in your brain stem, Whenever that comes to fruition, I'm sure we'll threaten out a lot of this.
We'll we'll apply what we know to that as well. Well, I feel like I could talk to you for hours. This has been really fun. Chase, thank you very much for for, talking to me today.
Same. I had a really good time. I love, conversations like this. Thanks for having me on.
Alright. Take care. Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
