PurePerformance - Why Compliance is Important and not Boring with Michiel de Lepper

Episode Date: February 17, 2025

The word "Compliance" reminds many about mandatory training or audits. Two things not everyone gets excited about!Tune in and meet Michiel de Lepper who has spent most of his career in Security and Compliance. He gives us a different perspective on the importance of compliance, why it exists, how it intertwines with security and threat detection, what it has to do with security posture management and why he thinks its one of the most exciting things in IT!Links we discussed:Michiel's LinkedIn: https://www.linkedin.com/in/madelepper/Blog posts on security and compliance:https://www.dynatrace.com/news/blog/dynatrace-for-executives-security-compliance/ https://www.dynatrace.com/news/blog/manage-compliance-and-resilience-at-scale-with-dynatrace/ https://www.dynatrace.com/news/blog/dynatrace-kspm-transforming-kubernetes-security-and-compliance/ 

It's time for Pure Performance! Get your stopwatches ready! It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as you might be able to hear from my voice, I'm a little bit sick today but it doesn't keep me away from you because I love you all so much. And I have to say with me today is my fabulous and wonderful co-host as always, Mr. Anthony Grabner. How are you doing Anthony Grabner today? Hey Brian, it's a pleasure to have you on the podcast again. Yes, thank you, thank you.

How did that come about? How did you came up with Anthony? I went to say your name earlier and somehow Anthony came up and I thought that's really funny because you are the furthest away from an Anthony to me than I could possibly imagine and suddenly going from Andy, Andreas to Anthony. See, when you have to explain the humor, it's not great, but I guess I'm getting my connection is unstable. Woohoo! So, yeah. Well, let's make sure, well, maybe there's some posture issues that you have on your end or whatever.

However, I can now make the transition over to the topic of today. Maybe you're not compliant, maybe your internet connection is not compliant with the regulation that we have. We should have high bandwidth, we should have good microphones following instructions like I do. I switched from my crappy headset to my built-in microphone from my laptop, which you said is even better than the stuff that I have on my head. Anyway. Long way about, yes.

Long way, long way of introducing our guest who probably now decides, shall I quit the recording or am I in the right place? I could say Michael, Mike, Michiel. Welcome to the show. Thank you for sticking through the first two minutes of not at all being funny. But how are you? I am good. I have to admit that I was very quickly checking Slack to see, like, oh my God, I always thought your name was Andreas. Is it actually Anthony? But it's not. Okay, there we go.

Michiel, it's actually really interesting because when I read your name, your first name, and I also did some LinkedIn research, obviously your background is, you said you think you're Dutch. Yes, correct. So, but Michiel then is the Dutch version of Michael, I would assume. Yes, that is correct. Or Michal in Irish, where I'm currently living. So I've been living in Ireland now for the last 15 years.

Cool. Hey, Michiel, I keep, I'll try to pronounce your name correctly. And if I mess up, then, you know, you can probably won't notice anymore. You can call your Anthony. Yes, that works. You made me a promise today, or at least now I'm saying it that you made him a promise.

Because one of the topics we want to talk about is compliance. And I want to understand from you, first of all, your background, but really, why compliance is must not be a boring thing. Because I, when I hear the word compliance, then sometimes I say, well, this must be something that I don't want to do. And I'm probably not interested in kind of like a, in a career in that field, but it seems you have a completely different perspective on the topic. So today I want to learn everything there is to know about compliance, why it is actually a cool thing.

And I also want to talk about security posture management, which is a topic and a term that is completely new to me or was until recently. And I'm sure we'll go into other details. But maybe you want to start with a little bit of a background of yourself and then we'll jump into some of the questions that I have. Yeah, no problem. So I think as a kid, I always was tinkering around with like Commodore's and PCs and my first real computer was a Pentium 100 and all of my friends wanted to play with me

because it was awesome because I had a Pentium. I'm also really dating myself here. But for me, it was a natural progression to eventually move into the IT security space. So I moved to one of the more traditional antivirus vendors at the time. So anyone who can check my LinkedIn worked for McAfee at the time, went through the Intel transition and then back again, spent about a good 12 years there, give or take. And really the areas that I specialized in, I had numerous roles there,

but the areas that I really specialized in was very much the endpoint space. Working with endpoints, working with transitioning from segmented endpoints to a platform approach to endpoint, then the rise of EDR and XDR and everything around it. So really moving from point products to a platform approach in security. And obviously with the rise of clouds, all of that became massively more complex.

And then I moved over to a tiny startup in the Czech Republic called Roomcast at the time. And then in their infinite wisdom, thankfully, Dynatrace decided to acquire Roomcast. So I am now the Senior Product Manager, go-to-market for security within Dynatrace. And compliance is absolutely and utterly awesome and cool. It sounds like a really boring topic, but it's not. But that's most likely because a lot of people don't take the time to stand still and think about why compliance is important. So, before I let you talk about compliance, I'm not at all familiar with a lot of the things, some of the acronyms you threw around earlier when you talked about your early days

at MakerFeed Intel. Can you quickly clarify for me what you mean with endpoints? Yeah, so an endpoint is essentially any server or client that you have within your enterprise environment. So that would be in the traditional security world class as an endpoint. And the great thing is that over time, how we view security has changed massively. And I think I jumped in at the right time with security because I went through that change. It's really when I started endpoint security, it was really everyone thought about, oh, you're anti-virus, right? You need to have an anti-virus. Then you had intrusion prevention.

Then you had intrusion prevention, so host intrusion prevention. You had your website filtering, your spam blockers, all of the stuff that you generally had. And they were all point products. And that all moved towards a more integrated and platform approach because all of those solutions give you data and data is fantastic if you can leverage it properly. This leads very much to where we're going to go with this ultimately with security posture management. But that data is incredibly important to get insights and when you look at your endpoint at the time, your endpoint data,

you can correlate that to what your web gateways and your firewalls and your intrusion detection or your intrusion prevention security will give you,. It gives you information. And you start to combine that to get a better picture out of it. And that's really where the rise of SIM came about and log analytics to really take those massive amounts of information and run correlations on them to make sense out of them

and really get meaningful findings out of it. So a lot of that from an endpoint point of view evolved into what I called EDR, so extended detection and response, because you want to detect and response to threat. That's your general goal from a security world, right? The first thing we always need to acknowledge is very much like you can never be 100% protected because it's impossible. Your aim is to be 100%

protected. However, you need to acknowledge that that goal is unobtainable. So at one point, something is going to happen. But by detecting that really fast and responding really fast to that, you can minimize the impact of that and thus minimizing risk. So extended detection and response is really where you took all of that endpoint data and started to combine it with other solutions and with tracing within your environment. And then the security world kind of thought like, oh, this is really great. What about if we put more information in there? And that then evolved into XDR, which is extended. Again, so the more data you have, and if you can

actually make sense out of that data, the better it is for you from a security perspective with the caveat of if you can make sense out of it, right? Because you can also get overwhelmed. I mean, for me, if I can just draw a little analogy or like, try to explain it in different words, if you think about your network, because in the end, we want to protect our network. And if you think about, like, I'm here in the building and thanks for one of our customers that I'm visiting today in London to let me use one of the rooms. But basically the endpoints would be everything that would allow me to enter the building, to enter the network, whether this is physically the doors, whether

this is if I plug in my laptop here to the wifi, whether this is physically the doors, whether this is if I plug in my laptop here to the Wi-Fi, whether it is all the people out there that are sitting with their laptops. And so these are the end points. And now for me, it also makes a lot of sense why logs have just been such an instrumental tool or not tool, a possibility signal to then detect any, I guess, abnormal behavior because logs were available everywhere, right? When somebody entered the door, when somebody logs, I mean, opens up an app or logs into the network.

I mean, that's why it makes, for me, not a lot of sense because I was wondered why logs and why not, yeah, why logs? Yeah, makes a lot of sense. Yeah, I'll give you a very easy example of why very basic information correlated against each other can lead to very smart detections, right? And it's always something that I generally, and a lot of other people, could call the superhuman example. I travel like you guys, I travel a lot for work. So I'm based in Ireland. So if you look at my access data, generally, I tend to log on from Ireland from an IP perspective. And, okay, so I might log into Ireland at let's say, eight o'clock in the morning. And 12 o'clock you can see me in Amsterdam. Well, that makes sense.

This is not that far away. So it's all very normal, right? Okay. And then I might need to travel to the US. Okay. That's also possible if you see me there the next day at, let's say, four o'clock in the afternoon, right? the next day at let's say four o'clock in the afternoon. However, when you start to track that over time

and then suddenly see like, okay, so hey, Michiel's here in Ireland, he's now two hours later, he's in Amsterdam, well, it's about an hour and a half flight, one hour 20 from where I live, that's fairly reasonable. And then 40 minutes later, I log in via New York. reasonable and then 40 minutes later I log in via New York. Great. I've logged in in New York beforehand. I've been there.

You can look at my historical data and it's like, yes, he's been to the US, he's logged into New York and other cities there. So that's pretty normal behavior. But unless I'm Superman and I can fly really, really fast, I'm not able to get from Amsterdam to New York in 40 minutes. So that's a superhuman example where you take really basic information that on its own is very normal and within the reference of what I normally do. But when you compare them together and start to tie them into each other, then suddenly

you get something, hey, there's something seriously wrong there because he can't be from Amsterdam to New York in 40 minutes. Now, because you brought up that example, I'm going to have to bring up a really stupid bit of trivia that also dates you, that dates me as well as I'm sure you will, not quite 40 minutes, but do you remember the Live Aid concert from like the early 80s? Yes.

So I just have to bring this up. Phil Collins, who was one of the biggest stars at the time, performed in London, hopped on a Concorde, got to the US about what, three hours later to perform in the US. So maybe if it was three hours, we could say you were Phil Collins, but 40 minutes, not even Superman Phil Collins could do that. Anyway, I have to bring that up because it's such a... Yeah. But then we need to correlate the information again that we no longer have Concorde, right?

Right. Exactly. I wish we had, because it would be really cool to fly in a Concorde, because I am that nerdy and I would love that. But yeah, but that's another data point, right? Is it possible? Yes or no? Yeah, and it's funny too because we were saying earlier, a quick point here that compliance is really interesting, you were saying, right?

And I think, at first, I think Andy, as well as myself, we were a little skeptical, but hearing you just because what happens is, is most people like us, our experience with compliance is compliance training, making sure we swipe our badges and are we going to get yelled at if someone follows us in even if it's we know that, you know, all this kind of stuff. So that's our experience of compliance. When you talk about the side of compliance that you're looking at it from, the investigative side of compliance, yes, it is absolutely fan necessity. So I definitely want to hear more. So I will

shut up now. And yeah, you're not the first person who tells that to me where they go, like, really, you're going to talk about compliance. That's really boring. It's like, no, it's not, you just need to talk about it in the right way. Can I, so the, from a compliance perspective then, does this mean compliance kind of evolved out of the early days of security to then detect patterns and say, hey, in order to avoid some of these things, here are some patterns or things you need to do, or how does then, how does compliance and, I'm like you, I think this is not my first language, so maybe I also have a different idea of what compliance really means, but I think for me compliance means you're doing certain things by a rule book

and then you are kind of good, you're compliant to something. compliant to something. Yeah, and that's the basic, very basic view of it, right? So let me take you back to the security topic again, because for me, compliance and security are very much intertwined as they should be for everyone else. And I'll explain why. Because when you look at your enterprise environment, and you look at the whole, and you think about it going, I want to secure this. I want to make sure that I can minimize my risk as much as possible.

Because we need to acknowledge that we can never have 0% risk, but the ultimate goal is absolutely risk minimizing. You're then going to look at your environment and you're like, okay, so I need to do all of these hundreds or thousands of things in order to minimize my risk in my particular environment. And then I need to make sure that I stay at that level. So let's build a very customized rulebook for this.

And then I need to follow this rulebook. And if I drift away from that rulebook, I'm going to be in trouble. So I need to fix it then. Now then look at any particular sector. And I'm going to pick banking as an example. Why? Because it's a really good sector to use as an example, because everyone knows banks, everyone knows finance, and everyone knows that if something happens with a bank, you're

not going to be happy because your money is going to be gone. When you look at the banking sector, a lot of organizations that are in that sector will have very similar environments. Of course, there's differences in each environment, but from an overall perspective, their environments will be relatively the same because they're relatively the same. Because they're doing the same things. So then they came together and then they said like, okay, let's make a standard. If we're all going to be working together, let's pool all of our resources together and get all of our smart people together. And how can we minimize risk the most specifically for our specific sector? And then they came all together,

everyone shared best practices and voila, right? These are the best practices to follow if you're in the banking sector. Over time that evolved into something like PCI DSS, which is a compliance framework and it's a regulatory compliance framework because there's a difference there as well, but it's a regulatory compliance framework that you need to adhere to if you're processing payment card information. And I take PCI DSS as an example, but there's loads of other ones in there, but

And I take PCI DSS as an example, but there's loads of other ones in there. But it's, you don't need to be compliant to PCI DSS because someone tells you, you need to be because you're processing payment card information. Technically that's correct, right? Because the general authorities will tell you that you need to be compliant. And if you're not, and you fail an audit, that's not pretty and it could cost you a lot of money from fines and reputational damages or even worse, a breach. Because the compliance frameworks that we're talking about are all specifically designed to minimize risk. So the most horrible outcome of being not compliant

is not failing an audit and getting a potentially really big fine, it's actually getting breached because that can cost you your business. So security and compliance are utterly intertwined with each other. So once you start to realize that, it suddenly becomes really interesting because you're looking at this from a security point of view

and going like, okay, so this is why I actually need to be compliant. Not because someone in some organization tells me, but no, it's a standardized approach to minimizing risk for the industry that I am in, or the sector that I'm in. Wow, I guess I've never thought about it that way because we have been, at least Brian, I think I can speak for yourself as well,

we've been so deep into our performance engineering and performance testing observability space that I guess I never thought about how does this whole PCI comply and how did this even came up? Obviously, banks set together and define standards that protect their whole business or their whole industry, right? Because in the end, you want to make sure that the public has trust in the banking system and not just in a bank. And then you have your, so the, can I ask you then as a question if some, let's continue with the banking example. If a bank would be breached and somebody can steal credit card information, who is, is then, did then the, whoever did the audit, a data blame because they didn't do the job well or is it, I don't know how

this works. It's the bank itself. And in certain countries, it can even be the board of directors or the CEO and the leadership team who can be personally deemed responsible in a court of law, for instance. So it's not just your organization, it can be individual people as well at the helm of those organizations. It was that intern. The auditors, yeah, the auditors are there to audit and they will give you a very good audit of, hey, this is

the stuff that is wrong that you need to fix. Ultimately, it is up to the organization to do that. And if you don't do it, yes, you can get fined and everything. But in the meantime, you can also get breached. And I guess that's the big challenge, right? Because the audit, I'm not sure how often they happen, but it's basically a snapshot of time. And the snapshot of time is the challenge, because now I guess coming back to the world we live in, where we have constant change, and this is where you cannot have constant auditors sitting around. But I guess this is where then, and again, now I get to see with excitement about this whole thing, the more data we have, the more automation, the more rules and data we can

process, the more we can get close to something that is continuously auditing you, I guess, all the time. Yeah. Just in the full, yeah. Yeah. At the same time. Oh, go on. Yeah, yeah. guess, all the time. Just in the full, yeah. Yeah, and at the same time. Oh, go on. Yeah, yeah. No, no, no, go on, go on.

No, I was going to ask at the same time, right? So just because it's not listed in the audit doesn't mean it doesn't have to be complied with, right? I mean, the audit is going to look at point of time, what's everything that's exposed right now. Now, if we create something new and we let a known breach, let's say we just, oh, PCI is open and available. Well, it's on us to know that, right?

It's not like you would be able to say, well, it wasn't in the last audit. You created something new. There are certain practices you follow. I could see it would only be if there was some brand new type of hack that was unknown at the time. It could be like, well, no one ever knew that could happen. But it's really interesting to see how the, and maybe this goes into later on when you talk about it.

It's interesting to see how the industry, especially banking and credit cards have evolved and tried to stay ahead of all this. Two things I know about, one thing I know about credit cards is ever since, at least in the United States, they were put on the responsibility for credit fraud was put on the credit card companies.

It was shifted from the users to the credit card companies so that they lose the money. That suddenly changed the way they do security. But also I remember years ago, if I was traveling abroad, I'd have to call my bank and say, I'm going to be going to Barcelona or I'm going to go to Mexico. This way you don't shut down my credit card. And now they say, you don't have to bother because of that trail, let's say of the logs Andy you were talking about before, they've gotten to the point where they're looking at and calculating, all right, I see now he's near the airport or made a purchase at the

airport. It's not suspicious that he's making a purchase in Mexico, right? Unless it was some gigantic thing. And that's it, right? No, so I want to loop back to that continuous thing that you talked about, Andy, right? Because to me, that's the crux here. An audit is always going to be a snapshot, a picture of a moment in time. It's more like a timeframe because an audit is six, eight weeks minimum, and it's not pretty.

If anyone has ever gone through an audit, it's really not a nice experience. Because you're very stressed out, you need to deliver a lot of information. The auditors lock themselves in meeting rooms essentially and just ask for things. And you need to deliver them. But the most, the biggest problem with an audit is that snapshot. I passed my audit. Now I am PCI DSS complains. Well, no, not really.

You were PCI DSS complained five minutes ago. That doesn't necessarily mean your PCI DSS has complained right now, because something might have changed. So I think that's a really important concept to always reference about. And one of the questions that I always ask people when I'm talking around this stuff and I've done public speaking and stuff, I always ask audiences, like how mature are your compliance efforts across your organization? And everyone always nods a little bit and goes like, yeah, yeah, we have this and we have that.

And oh, yeah, yeah, yeah, yeah, yeah. We passed this audit. We passed that audit. And my follow-up question then always is, how do you know? It's like, yeah, because we got audited. Okay. So when were you audited? Ah, last November.

So, okay, you knew last November, but where are you now? And then suddenly they start to bluster. Because unless you have things like continuous compliance implemented, you won't know. And that's the biggest problem. And then when we loop this back to the very beginning of our conversation where we linked compliance with security and that the ultimate goal of compliance is to minimize risk, then you suddenly start to realize, okay, so I should always be compliant, actually, because I always want to minimize risk as an organization. And that is the big challenge.

I always say that it's relatively easy to help any customer to the point of where they are now, to help them to achieve the point of where they need to be. Because that's essentially what you do with an audit as well. You give them a list of stuff they need to fix and go fix it. And hey, we can even help fix this for you. Great, right? But managing compliance drift over time, that is the real challenge. And then you need to take into account that for now in the course of this conversation we've only just talked about PCI DSS. When you look at compliance, there's always the very first question you need to ask yourself. What is regulatory and what is nice to have.

Because regulatory you need to adhere to. So a bank will process PCI DSS. They probably want to be ISO certified as well. If they're in the EU or they do business with the EU, GDPR. And hey, we now have DORA as well in the EU, or if you want to do business with those banks in the EU. Because I went through the whole implementation of GDPR in my career. And a lot of discussions we were like, oh, yeah, GDPR, that only counts for Europe. Yes, that's technically correct. But do you want to do business with Europe?

Oh, yeah, absolutely. Then you need to be GDPR compliant, right? So it's not just one compliance framework that you need to adhere to. There's multiple and all of them will need to be tracked. All of them will need to be monitored and audited. And then you have your nice to haves. Because let's take CAS or NIST, for instance, two other compliance frameworks. Doesn't necessarily apply to every organization, but they're really

good frameworks for minimizing risk. So you might want to take certain aspects of that and apply them to your organization. So they're the nice-to-haves. So it's an exponential build-up of things that you need to start tracking and not only achieve firstly, but also over time keep adhering to. So without automation and without processes in place for all of this stuff it's near impossible to achieve. I think hardly ever does it happen that both Brian and I are just like extremely speechless and just listening in and... I told you compliance was cool. Yeah it's really cool. But I have a question now obviously where we are getting to is that we have now more automated data besides logs. We have, you mentioned earlier, traces.

We have metrics. We have events. If we are with automation efforts, we can continuously validate certain things. Does this mean that the automation, the software supported auditing will replace the human auditing? No. It will make it easier. Okay. So I've already mentioned that I'm Dutch, right? For years and years now we had a commercial in the Netherlands about doing your taxes and the national tax department.

And they always said, we can't make it more fun, but we can make it easier. And that is what solutions like security posture management are trying to do. solutions like security posture management are trying to do. You can never take the human out of the loop. Due to various reasons, right? There's a whole discussion and it's an ethical discussion about AI versus humans. It's capabilities. So humans have the ability to make intuitive loops in their thinking and put the hypotheses forwards out of essentially thin air or very little information.

But what we're really bad at is processing really, really, really large amounts of data and trying to detect a pattern in there. So to me, there's always going to be something like what you almost would call a human machine team in there. And really combining the strengths of both worlds to minimize risk across your organization, whether this is just normal security or regulatory complaints or just complaints to your internal policies. I think a human is always going to be needed. And I think now, if I come back to your example from earlier with the 40 minutes from Amsterdam to New York, that's obviously impossible. This is

knowledge that you can feed obviously into a system that certain data is just simply impossible. And I guess the same is now true with modern systems where we have, let's say, logs, metrics and traces. We know how things connect to each other, but we also then know that certain things cannot be in a certain way because we just have either information about a system because we observe it and we can extract that information. Or I guess over years we've built rules into a system that does continuous

validation and continuous posture management to say, hey, you know, we have a thousand rules, we don't need a thousand people to manually check it, we can automate that. And we can then also use, I assume, different algorithms to detect other patterns, but that makes a lot of sense now. Yeah, I think coming back to the humans as well, one of the things that I always try to achieve working with an organization, not just the security departments,

obviously that's my bread and butter because I work with them a lot, but you need to talk to a multitude of organizations in any organization, in departments, right? You need to talk to a multitude of departments within an organization. So getting a mutual understanding and a synergy, for instance, between SecOps and DevOps is incredibly important because realistically, when you look at a traditional organizational model, SecOps are the guys who put all of this crappy code out that has vulnerabilities all over the place. That's the security view.

And then SecOps thinks of security. Yeah, these are the guys that tell me to fix all of these things and everything is a priority. I have a list of a hundred things already that is a massive priority. Like, lads, come on. like, lads, come on. And that's because there's always traditionally a separation between, as an example, DevOps and SecOps, right? Where the industry is going more and more now is DevSecOps, where they're becoming much more intertwined. And that creates mutual understanding. And then if you have solutions that will actually bring benefit to both teams,

then you start to really accelerate. So for instance, a solution and security posture management is one of those solutions as a general industry area. It's leveraged by or it should be leveraged by both SecOps and DevOps. Because SecOps can really look at all of the compliance stats and where are we, how secure are we, and what kind of vulnerabilities do we have. Whereas when you look at this from a DevOps point of view, a DevOps person, whatever your role is, if you're an SRE or a platform owner or whatever, you don't care about all of the stuff that works. It's great to know that all of the things are working and it's actually safe, but what you really care about is the stuff that doesn't work or the stuff that needs fixing. And what is my priority there?

Because everything is a priority. So if you have a solution like security posture management that can give you contextual information and allow that to prioritize your dev environments and what you need to fix in there, that will save you a lot of time and manual work and very much frustration as well. Because you'll be presented with a really nice list of stuff that you need to fix in order of importance, instead of having to manually... And if you have a good solution, it will also tell you exactly where you need to go fix it. Because it might be a single vulnerability, or it might be a single compliance rule that

is not being adhered to, but it might be spread out over 500 systems. How are you going to find that out? In a traditional Sturm, you would do that manually. You start to query things and look through things and then manually, hopefully, find those 500 systems. Whereas if you have automation in place, you have all of that information. So, okay, this is my main priority right now. I need to fix this particular item, and I have this particular vulnerability over these 500 systems. This is where my effort needs to go now. And then you work down the line. And if you then start to add in automation and remediation in there,

and all of that hooked in, your life is going to become much easier. You're always going to need a human, but you can automate a lot of that workflow already instead of having to do all of that stuff manually. I think you brought just a couple of examples with vulnerabilities. I know Brian, if you remember when log4j, log4shell came out, I think we had sessions and never heard.

But this was a vulnerability and similar, right? If you have automation that tells you not only where are these libraries, but where to load it, are they actually executing the vulnerable code? Is it, are these systems that are exposed to the internet or not? This obviously made a difference. Now going away from vulnerabilities, do you have maybe other examples from on the Kubernetes side because I worked in the CNCF. Do you have any examples on what some of these kind of posture management rules or whatever it's called, what they look like in Kubernetes will be like the top three things you would see in

most environments. It's very different in environments. Think about all of the, any configuration that will leave you vulnerable. And there can be very simple things like default passwords and usernames. It's not just vulnerabilities and a lot of people always think like, oh, vulnerabilities and compliance is different. Actually, no, they're very intertwined. But compliance is more than that. It looks at vulnerabilities and how you actually manage them, but it also looks at configuration. Because when you look at the history of modern IT, let's call it that, a lot of the so-called hacks were breaches that were just simply done by having default passwords and usernames

exposed to the internet. So it doesn't always need to be a fancy zero day. It doesn't always need to be some nation-state attack that uses radio waves and radar to remotely hack into your system via an air gap network and all of the fancy stuff we see in movies. It can be as simple as admin passwords and exposed to the internet. And there's multiple examples out there where very large companies have been breached because they had internet facing database with literally admin and password

as their username and password. So there's no such thing as the top three most because the difference per Kubernetes environment, but very simple things, right? Are there things exposed to the internet when they shouldn't be? Are my credentials, are they changed away from default? Right? Do applications have root access if they don't need it? Things like that. So when you talk about automation and all this in that process, is that stuff that can all be automated? Because you know, especially, I like the one that you mentioned about, should this data be exposed to the internet? Right? I just myself have trouble understanding how would something automated understand what should and shouldn't be exposed to the internet. I'll know if it is, but whether or not it is or isn't, or if the password's been changed. Is that stuff that's automated,

or is that human factor there? So a lot can be automated, but there's always gonna be, to a certain degree, humans in the loop, right? There's best practices, and you can adhere to that. But should a particular application that's running on Kubernetes be exposed to the internet, yes or no? That's not any judgment that a machine can make because the machine doesn't know what the application is, right? Once you tell it that, absolutely.

And to a degree, the remediation of things can be automated as well. Right. But then the question comes in, do you want that as an organization? What's your level of appetite in that? Because in essence, it sounds really, really great. And don't get me wrong, right? I'm a massive fan of automation, but it always reminds me of things like bricklaying robots. If you have a bricklaying robot that does its job perfectly, it can build a house in

weeks or days. However, robots are stupid and robots are essentially automation. If they make a mistake, they will make that mistake hundreds, thousands or millions of times up until the point where you stop them. Yeah. So automation is great if you go through the proper procedures

to test out your automations before you roll them out in production, right? Don't write an automation and you roll them out in production. Don't write an automation and immediately roll it out in production. Same with code. You're not going to put your code in production immediately. You're going to run a true test first. And the same counts for automation. So it's very dependent on the level of automation that the company has an appetite for.

Almost anything can be automated. Yeah, and do we automate automation testing? Yes, exactly. And this leads to other problems, as we've fairly recently seen, for instance, with certain events in our industry. So it's always in balance, right? And to me, that's what makes security in essence so interesting because everything is finding a balance. Because I can create

a perfect system for you, right? I can make an absolutely secure system. I will take your laptop with whatever data is on there, and I will pour it into concrete and then I weld a buttload of titanium around it, and I dump it in the Mariana trench, never to be found again. It's very, very safe. You just won't be able to use it, which is a problem. So security always is a balancing act between minimizing risk and trying to make things as secure as possible while still allowing people to do their jobs without them having to jump through hoops to change something

in the document. It's always going to be a balancing act and the same goes for automations. And I think that's exactly, you know, when you mentioned the idea of making it easy, you can't make it fun, make it easy. Everything you've been talking about before has been making it easy. You know, exactly. Here's here's that top list, right? And and and it's funny because you know We've you know DevOps has been around for a while Andy. I know we've talked DevSecOps and all But this is really the heart of what those things mean, right? Is that collaboration with everybody?

Bringing it to the surface making it easy for everybody getting everybody getting everybody on the same side Because even if you go back to what was at the Phoenix project, right? Keep referencing that brilliant book right once once security what was the security guy's name is gonna come to me later on but once security was understood it was like oh this makes sense yeah we should work with you right and then he was able to start making it easy for them yeah But that's the hard way. Both ways, right? Security to an extent needs to understand deaf as well. Correct. Because it will make both lives easier.

Right, because security needs to realize that deaf already has a list of a hundred things that are critical that they're working on. So working together to really prioritize is once again coming back to contextual information, is very important. And if you can then somehow manage to also in that same workflow, get the information to the dev on how to actually fix it, it's even better

because not only do you tell the devs, hey, listen, this is broken, this is the highest priority, this is where it is broken, and hey, by the way, this is how you fix it. If you want to automate it, click here. It's the ultimate golden thing to achieve, right? Not as easy as it sounds, but we're working towards it. Hey, Michiel, we went from learning about your Pentium 100 that you were really

excited to share with your friends or people came over until you talked about putting your laptops in concrete and putting it down the deep waters. Very safe. It's very safe now. But It's very safe. It's very safe, yeah. But for me, and I know I repeat myself, especially for the listeners that we have, for me, this is yet another great example on how much there is to learn in our industry and how happy I am that we can host this podcast because we learn a lot from our guests that are really deep into a particular topic, right?

Brian and I might be deeper in performance engineering because that's what we've been doing for the last 20 something years. But hearing this from you, I fully understand your excitement about security, about compliance. Now it makes more sense security posture management, the whole drifting, like continuous validation is a key point because just having an audit today doesn't mean you're really safe from anything and you're no longer compliant a minute later. So that was fantastic.

Meet me here to allow you to also say a little bit about the work that you do. I know we said we don't wanna talk too much about what we're currently doing. We know we said we don't want to talk too much about what we're currently doing. We all work for Dynatrace, but obviously you have a lot of history and you came in through the Roamcast acquisition.

I would assume that a lot of the stuff we talked about today is exactly what is now possible with having all this data in Dynatrace to automatically detect and to continuously validate in case anybody's interested in learning more about this. Correct. And I think from my own personal point of view, right, so some of the things that I mentioned earlier on in here is the amount of data. And traditionally, security has always looked at security data. But how much richer can it be if you can actually combine that with observability data? So for me when I was in Roomcast and we got

the news that Dynatrace was requiring us, to me that was really exciting news because if we can leverage both sets of data properly, and that is what we're obviously working towards, it becomes so much better. It becomes so much richer. And to me, that's a very exciting future. So a lot of that is, yes, we're working a lot with the Runecast capabilities and transferring those over into Dynatrace from a capabilities point of view. But to me, the wider security conversation that we can have with all of the existing and upcoming Dynatrace functionalities,

together with the observability data is phenomenal. And I think that's really exciting to see what we can actually do with that in the future. Ultimately, it's more safe. Yeah. Yeah. Thank you so much for coming on the show. And security is a never ending topic. neither is compliance. And I'm pretty sure we'll have you back because we want to educate the folks that we have as listeners that are most likely more on the performance engineering side. We want to educate them on these extremely relevant topics. Give me an ear and I will talk it off. It has it. It has been an absolute pleasure guys.

Thank you so much for having me. It's been great and more than happy to come back when needed. Very much appreciated. Cool. Well, thank you everybody for listening. It's been another amazing and enlightening show. And we hope

you all had fun listening to it as we did. Thank you so much. We'll see you later, Michal. See you guys. Bye.