PurePerformance - Why Security and Compliance must not be a showstopper for SaaS with Milan Steskal

Episode Date: December 9, 2024

Most services are moving to SaaS - whether it’s email, collaboration, customer relations, or finance. But not everyone can go to SaaS - or at least that’s the initial reaction when navigating certain industries’ rules and regulations.Milan Steskal - who worked in healthcare for many years - is now helping organizations ask the right questions and find the best solutions as they evaluate their options to move their observability data to SaaS. Tune in and learn about the questions to ask vendors and your internal security, privacy, and compliance teams. Milan also walks us through the capabilities SaaS vendors such as Dynatrace have put in place to protect data sent to the cloud so that it stays safe and only accessible to those needing access.Links discussed today:Milans LinkedIn Page: https://www.linkedin.com/in/milansteskal/Dynatrace Trust Center: https://www.dynatrace.com/company/trust-center/ Blogs on Trust: https://www.dynatrace.com/news/tag/trust-center/

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 always I have with me my unpredictable co-host Andy Grabner. So today's answer was, won't he? He won't. So for people playing along at home, as you're probably aware by now, Andy usually mocks me as I do my intro. And the question was, will he do it today? And he didn't.

He was a good boy. You're a good boy, Andy. Thank you so much, Brian. Thank you. I know I'm a good boy. No, I know that the last times I maybe overdone, I overdid it a little bit. So today I wanted to be nice and not interrupt you with mocking you while you're doing your introduction. And it's also, no, it's November, the end of the year.

You got to start being nice. Exactly. Otherwise, you're going to be on the naughty list. Exactly. Hey, talking about naughty, the weather here in November, the weather here in November, at least in Linz, is, I don't even know, do I see clouds or is it just fog? It's always like very foggy here.

And I don't even know if there's clouds above the fog. But the clouds... Oh, I see what you're doing. Yeah, the cloud is a good topic because we are looking up to the clouds and we want to send out data to the clouds. At least many people want to go to the clouds using SaaS services. Not everybody can go there. Some think they can't go.

Some think they can't go. Some think they can, but shouldn't. And we invited somebody that could hopefully give us some insights on this whole topic about... Who is it? Who is it? Who is here with us today? Milan. Milan, servus. Welcome to Pure Performance.

Hi, Andy. Hi, Brian. Hi, everybody. And thanks for having me. Yeah, Milan, maybe do us a quick favor. Introduce yourself. Who are you? What's your background? Just a little bit of pieces of information. We obviously have the link to your LinkedIn profile in the podcast description. So everybody could read up more. But from your perspective, just a quick intro. A very quick intro. I lead go-to-market for product compliance and certifications at Dynatrace, which means that I cover things around security, privacy, accreditations, with Dynatrace for around three years. Go-to-market means creating a link between product, between our customers,

and security and privacy, which is really interesting to be a translator between those three completely different worlds. And yeah, coming with a background of almost eight years in healthcare, that gave me a strong, I would say, understanding of the needs of the regulated sectors and regulations and compliance and really how to use them to drive business forward and not to block business, how regulations are often perceived. So thank you so much.

And I think that background actually helps me a lot and makes me more appreciate this discussion, even because you obviously know how challenging it is for, I guess, people and organizations in the healthcare industry to rely on SaaS services. And now, when we talk about SaaS, obviously, we from Dynatrace, we talk about observability, but there's so many different SaaS vendors out there that we use on a day-to-day basis. If I look at my laptop here, my emails are in Outlook 365. I think most of our presentations and documents, they also live up there somewhere in the cloud. I'm using tools like we're using Zoom for recording.

I have Asana. We use Slack. So we have so many different SaaS services. And so my question would be, is there there the people that you've worked with also looking back at your history is there a differentiation between SaaS and SaaS meaning certain SaaS offerings are easier to adopt as an organization that is very conscious about this

where the data ends up and other solutions that might be more tricky that's a very good question. And I would say, yes, there is a big difference because when it comes to SaaS, of course, you as a user or as a customer, and whether it's a professional use like Outlook

or personal use like social media or anything else, you share your data to public cloud. So somewhere where you do not really have control over this data. And now when I get back to the especially regulated sectors and those companies or organizations using SaaS services, really it depends a lot on what types of data they are sending there. If they are sending very sensitive data, for example, I mentioned healthcare, so it could be social security numbers, names, but also medical conditions, prescriptions, medication, and health data such as blood glucose, blood pressure.

Those are extremely sensitive data. So any SaaS solution that would store this data need to really make sure that they protected this data really well. This is, of course, also regulated. However, when it comes to sending data such as CPU metrics, monitoring data performance, when it's really monitoring systems that do not include any of those personal data, then it should be much, much easier.

Ultimately, there is a single, I would say, trigger question. Do I share any of the sensitive data outside of my environment that I can fully control? If no, then adopting this kind of SaaS service is usually much easier. Yeah, I think that's when we kind of prepared for this conversation. I was actually really surprised to hear you say, hey, you know, traditional monitoring, it's not that sensitive because the CPU metric and the memory and maybe the number of processes

and what runs is not that sensitive. But we all know that, especially in our field now of observability, things have changed quite a bit, right? Because we do not just no longer just capture memory and CPU, but we go beyond that, far beyond that, because we now capture traces, we capture logs, we capture real user data through our real user monitoring, right? And that obviously opens up the data that is captured to potentially include confidential information. Is this right? Yeah, exactly. And, I mean, there are two ways. Also, when you capture logs, for example, you don't necessarily need the confidential part of the log. Sometimes you need the information, the confidential part could be linked to, again,

like to performance, for example. And the confidential part can be omitted, can be anonymized, so that actually the log that you capture will be without it. At the same time, there might be use cases where it is required or necessary, or is a part of a use case that could be, for example, for capturing logs for audit purposes or fraud detection. Of course, in those cases, you need to store also the sensitive data, but then you need to make sure that the data is really protected well, that the security controls, privacy

controls, user access, and all of that is set up in a way that unauthorized users will not be able to read or access the data. And I guess this is also the reason, and Brian, I guess you see this as well, by looking at us in the observability space, we still have, I think, organizations that say, I'm willing to send you some of the data into the cloud, but first I have maybe a data pipeline where I want to send data streams that I'm using exactly for these use cases, fraud detection, auditing,

into a different backend system that I have under control that I want to keep on-premise. At least that's what I hear quite a bit out there, kind of like this data separation and then using tools like OpenTelemetry Collectors that can then send it to multiple, like to filter, or there's other tools out there in the open data pipeline space.

But my question then is, what can we do, right now looking at SaaS vendors like us, what can we put in place to give people the confidence that sending data to the cloud, even if it contains confidential information, that this is still an option to consider? What do we do to make it safe for them? Yeah, thanks for this question. It's really a very good one. And let me start with on purpose oversimplifying this. It's not fully accurate, it does not cover everything. But ultimately, when I talk to the customers, it boils down to one thing. Who can access the data that I sent to you,

to your public cloud? Because the customer wants to make sure that we will not be able to see their data. They want to make sure that the data, especially the sensitive data, they should not leave their environment, will not leave their environment or will not be stored. And also from their organizations, only the ones who are allowed to see the data will be able to do so. And to achieve this, the SaaS vendors should implement and should have

a few layers of controlling access to data, both combining security as well as privacy aspects of this, such as anonymizing data, being able to anonymize the sensitive part of the information, for example, email addresses in logs or IP addresses in logs and stuff like that, even before the logs are sent to outside of your environment. Or if this is needed, if the information potentially might be needed, or if for some reason it's not possible to anonymize it at at capture as we call it, then do it as soon as the data arrived to the system of the SaaS vendor.

So before it's stored. As you mentioned, Andy, there are use cases when the data, the sensitive data will be stored. So in that case, making sure that the data is encrypted, of course. And this applies to data in transit as well. Making sure that accessing the data or decrypting the data is potentially, I would say, as complicated as possible. And also that in case, in very unlikely case of exposing the encryption key, like this has minimum impact, meaning not encrypting all the data

with the same encryption key, but having more of them. With this, I'm not suggesting that this keeps happening, of course, but it might happen. For me, it's like when you get on a plane, and on a plane, they say, in an unlikely event of landing in water, life vests are under your seat or in your armrest or somewhere. This is how I would talk about this bridge. And then, of course, it's configuring granular access policies

to make sure that only the ones who are authorized to see the data can see the data. For example, when you think of logs and fraud detection or audit purposes, an auditor or someone from the corporate security, from the legal privacy team should be able to see this data. However, an IT admin or DevOps engineer, they just need to see that, okay, this log is there and it was logged at this time. So it means that they should not see the sensitive part of the capture log. But of course, there are many, many more different controls. But to make it, I would say, easier to understand and also for the purpose of this podcast, this is the angle, or this is how I would think about it. How I protect the data from being accessed by unauthorized users and how I do minimize the data so that I do not share what is not necessary to share.

I think I want to just quickly recap something and also put a connection to a community that I'm working with very closely, which is the OpenTelemetry, the CNCF community, because a lot of people are now implementing OpenTelemetry, which is great, instrumenting your code or leveraging pre-instrumented libraries with OpenTelemetry or using some of these agents that can auto-instrument. And then I think a big point for them, for everybody now that is building everything on these open source tools is, as you just said, make sure that you are, A, not capturing things at the source that you don't want to capture.

As you transport data from, let's say, your process to the open telemetry collector, try to then filter out things as fast as possible. And I know there's initiatives going on to provide some out-of-the-box rules for components like the OpenTelemetry Collector to filter things out and not forward certain things. The collector obviously also has the chance to then send data to different backends. But I just want to raise the awareness again, there's a lot of stuff that needs to be configured and needs to be considered

if you're going all in with, let's say, these open source and open telemetry only. And I know we're not selling now any commercial tools, but from the commercial tool vendor side, we and also our competitors in the market have invested time to do a lot of these things automatically by default because we have our patterns that we recognize for social security numbers, emails, IP addresses.

I'm sure there's many other things that we automatically detect as confidential and then have the option with a check of a box to automatically make sure that these are either not captured or transferred in an encrypted way and things like this. So just making people aware of what you just said early on, decide what you really need to capture, and if you capture, do it in a smart way, in an encrypted way, and then also think about, and this is the next piece, who can really access this data.

I think that's also a very, very big point. And Andy, you gave me one thought that I would like to add to what you just said, that in case of using the, especially the open source tools or solutions, and I am not against them in any case, of course, but already in the beginning when you're planning how to use them, think about this from the very beginning. Like what type of data am I going to collect?

Which data I can collect? Which data need to stay? And how much work and effort is going to be to take care of managing, processing, and ingesting this sensitive data. Because very often this is, or maybe very often, but there are cases where this actually requires much more effort than setting up the traditional use cases for monitoring. Brian, I think you had something on your mind. Totally small thing.

Actually, I have a couple of things in my mind, but the first one I wanted to ask is, we keep referencing social security numbers. I'm just curious, is there an equivalent in the EU? Or do they call them social security numbers? Like, obviously, it's a big thing over here in the United States. That's a great question, Brian. EU is, I think, 27 countries at the moment.

That's 20, 30 years ago where not the EU and each of the countries had their different way of identifying people. I'm not aware of anything that would be that would go across the whole EU. Like passport number. But I think that's

global. But you all have something besides passport numbers. But there is something. I think in Austria we have something like social security number. I come from Slovakia. We have something else like, and in a free translation, it would say like some kind of like birth ID

that I will get when I am born. So like with the birth certificate. And that's what would be used to identify me but no, specifically there no social security number. It's just funny because we toss that around so much and I was do you even know, like, I've been working with the with the US like for the last 15 years already. So like, it's so in my mind that a social security number that's, and it's very easy to understand, because even if you're in the country that you come from, even if you do not use social security number, it's pretty clear what it is.

Yeah, yeah. You know, one other thing that you said early on, which I think is something to keep in mind throughout the whole conversation for our listeners, when you introduced yourself, you said a very, I'd call it profound statement about when it comes to compliance and regulation, it's not about it being a blocker, but it's about finding out how to work with it. Because I think quite often that it's, oh, regulation says this, so we can't go to the cloud, period. It's like, no, it's not saying you can't go to the cloud. It's saying these are the rules you have to follow no matter where you are. So you can go to the cloud if you can figure out a way to make it work or whatever it might be. Because, you know, we see we're obviously a SaaS product ourselves, and we see a lot of people who are very scared to use the SaaS version of Dynatrace still.

But meanwhile, we have government agencies on the cloud. We have other health care and banks, and each customer is going through the same issue. It's not like, yes, people will look at, okay, well, I see healthcare company X is up in your SaaS platform, so that's enough for us. They still have to do the review, which, yeah, that makes sense. You can't just say like, oh, yeah, it's good for them. But I think very often there is this idea of it's a block, right? And you very clearly stated that it's not a block. So I've been trying to keep that in mind.

One other thing, and I don't know if it's a good time to jump in there, but I wanted to bring up the idea. Obviously, there are things like the external tools are doing to help obfuscate and encrypt the data and all that. But when you mentioned about storing data in different areas with different encryptions and all, when people are building their applications and they're building security-minded features into it, as opposed to what external tools do for security,

what sort of, has there been any discussion or discovery about performance impact of built-in security features and functionality? So if we're going to write an encrypted log, which I don't know if people do that, but if you're going to write your logs, that there needs to be some kind of performance implication or performance consideration from a security point of view. Cool. Brian, this is a very good question, but you caught me a little off. If it's not something you prepared for, that's fine.

It just popped in my mind because you're rolling off all these different things. It's a very good question. The last time I wrote, I started my career as a developer. It was 15 to 20 years ago. It's been way over 10 years since

I wrote the last line of code and it was mainly PHP and C sharp.net. It was like version two, which was long ago. And back then we did not have to think that much about performance. And of course, like the data protection and everything was, I think there was like, there really no wide adoption of AWS or cloud. But in any case, on a very high level, of course, like any encrypting data, decrypting data, it requires certain performance. You know, of course, so you need to do some additional computing power to just storing the data in a plain form. However, from my perspective, it's important to build the architecture in a way that this is as

efficient as possible because there is no way around. I think you cannot, you know, you cannot store even like a passport or like those things unencrypted because those, you know, you said that as regulation are, do we need to find a way how to not make them a blocker? And I agree that in some situations and especially for the, for the developers, for the, for the IT, it feels like it's a blocker and I mean, and it's frustrating. And I mean, even for me sometimes, however, the important thing is how i look at it is there anything we can do with it even if you wanted to probably not simply it's coming from legislation

it's coming from governments yes people organizations individuals can lobby against but that takes you know years decades to make any. So it means the best thing is to really embrace what's happening and find a way how to work with it and how to use it to your advantage, meaning build the systems, anticipate what's coming, understand the regulations and requirements, and architect and build your systems with this in mind, kind of secure by design, having privacy by design, including performance.

Milan, again, coming back to the preparation we had, you mentioned that, and this fits perfectly into this discussion right now. Some people just say no. And then I think it's always good to ask questions why, right? I think some people don't ask the right questions on why this is a blocker and what is the real goal and motivation. Yeah. And I know you have these discussions quite a bit. Any additional, let's say, best practices, lessons learned

that you can give to people that listen in and they want to move their company to use SaaS services, but they're blocked right now, which seems to be like a no-go. Any good questions? Who to ask? What to ask? Any good questions to bring up? Oh, yeah. Definitely. And i love the question

thanks for asking what i would say personally i see this as two types of blockers like first is they are hard blockers and there is no way around simply if you need a certain accreditation certain certification it's a checkbox item. For example, HIPAA compliance in the US, no way around, simply you need to achieve it. However, then there are software requirements that where often the security teams or the architects or legal teams bring up to protect the data to increase the security of the data and when they bring those up they usually do it because they have a specific problem or a challenge or a risk on their mind that they want to mitigate with this control. And in that case, it's really very important,

even crucial for the development teams, for example, software developers, to actually work together and talk to legal security and discuss those. Hey, dear security, dear legal, why do you need this? What is the background of this request? And ask five times why. And do not go into this discussion with the mindset of, okay, we need to find them and we hate legal because they cause problems. Legal teams, I do not believe that they want to

cause problems, but they understand the other aspect. Let's get into the discussion with, okay, let's solve this. Let's find a solution. This is not in observability or in IT, but how it works in healthcare. And this helped me a lot is that in healthcare, when you build medical devices, you build a device that can impact your health. And if there is a problem, a bug, an issue with the medical device, it could hurt you. In the worst case, it can kill you. So it means that it's very strong on medical risk management. And there are user studies with the people, with the users, that have purpose to validate that the user experience is okay, that simply the users cannot use it in a way that they would hurt themselves. Very often there are some findings, and then

those are classified, like how often this could happen, what's the severity, and then what happens is that the user experience designers of this product, regulatory people, people with medical background, and the developers and product managers, they get together in the room, they go through finding one by one and discuss it. Like, is it something we need to address? Is it something we do not need to address?

If we need to address, what and something we do not need to address? If we need to address, what and how? So how we mitigate it? And I think that this approach, even though it sounds pretty rigid and in some kind of simplified way, can be used also in our case. Let's get the people in the room and let's discuss it, including the business people, because there is a certain business requirement potentially for blockers because the fines could be extremely high in the case of data breach or non-compliance. But at the same time, the business requirement for implementing certain features can also be very high because there is potential very high return on this investment. So it means that everybody should talk to care and work together to find a solution.

That's why I think, you know, it was eye opening when you gave me a little bit of your background in the beginning about health care, and I think it's great that you go back to this and kind of draw the parallels to the world we're living in right now, which is in the observability space. I want to touch upon one topic because I watched you and I listened into a presentation you gave just recently. And there was a big topic around, again, who has access to what type of data? And I want to like to get an answer from you is again, coming from the observability space, because as many of our listeners I think are performance engineers, platform engineers. Observability is very important.

And I would like to understand from you what type of controls have we put in place in our solution to restrict access. So not talking about the collection of the data because I think we covered this, but once the data is stored, what are some of the things that people need to consider, that need to figure out in their organization about what level of access do people want and need? Can you give us a little bit of an idea here?

And I will try to not sell, of course, if I can fall there, please excuse me and stop me right away. But in general, usually when you monitor larger and more complex IT systems, then you monitor tens, hundreds, maybe even thousands of different services and apps and everything. And very often the performance engineers do not monitor, do not work with all of the whole ecosystem. They work with a certain set of apps or based on region or type of apps or something based on the type of the data collected. Is it confidential? Is it not confidential? So it means that one type, one set of controls is really controlling and defining the groups or the segments of the data and access to those segments.

That's why it's important also when bringing and implementing this solution, to have this on your mind as well, not to give every performance engineer, every IT admin access, access to everything. So really to be able to, on a quite granular level, to configure who has access, and maybe even through some kind of like matrix to be able to combine, for example,

geography or a region with the type of application and even type of data. And then when you go one level deeper, if, for example, we both would be able to access logs, still configure who of us can see which information that is in this log. So I would say this is on a high level to really give the granular configuration and ideally from more angles, more controls, not only, okay, like I can log in, I define, like you can access this one thing and have it kind of partially like hard coded, but making it flexible also to adapt to how your organization is structured so that if you move from one thing to another, ideally this would be, you know, there would not have to be like a super admin of the monitoring solution who would have to manually change this because

in big organizations, that's just a question of time when someone would be able to access data that they are not authorized to see. I'm making it a little bit more kind of, let's say, quickly, Dana, Tracy. I know what we have, because I also need to understand this, because it's a very big topic and I'm not that good into that topic

as I may be in analyzing distributed traces or building workflows. I know in Dana Tracy, we have the concept of what we call buckets. So I guess buckets is really, what you mentioned earlier, the biggest granularity of you want to figure out how in general you segment your data. Can you

give me examples or give us examples on how buckets are typically used from the most granular or from the biggest buckets of how to separate the data. What are some good examples here? Yeah, that's a good question, Andy. And so in 9.0 Trace, now going into this 9.0 Trace way, a bucket is, I would call this one as a high level way how you store or separate data from each other. One of the core options to configure for a bucket is a retention period, meaning how long the data stays in the bucket. So it means that, and of course this really depends on the size of the organization and on the use cases, but in a little simplified way, you configure buckets based on how long the data that you ingest or collect,

for how long you need to store them. Because, for example, for troubleshooting logs, you don't need more than seven or 14 days. For audit logs, 10 years, please, because I need to look back, for example, for fraud detection or something really a few years back. And then for different use cases, anywhere in between. And then it's important, and this is important for two reasons. One, to optimize storage costs. Because you don't want to store troubleshooting logs for five years because it would be

amount of data that i cannot really imagine and it's really unnecessary to store it for for for that lock second compliance purposes because there because it might for because you might be required to store some data if you if you collect them for either for at least certain for certain periods of time or for a maximum period of time. And with this, you can configure it. And then within each bucket, you can configure additional controls so that not, you know, so that it's not only configuring access to the bucket, but then within the bucket to data really on a granular level, even on a record level or data type level. Because I, again, within a bucket, and I think I can draw the parallels a little bit also, I guess this is where the name comes from. When I hear bucket, I also immediately think about S3,

and S3 has the concept of buckets where you put stuff in. So we have buckets, within hear bucket, I also immediately think about S3. And S3 has the concept of buckets where you put stuff in. So we have buckets. Within the bucket, you can have the different things. We call them tables, whether it's logs, metrics, traces. So they're all tables. And also system table, we have a couple of different things. And then these individual records go in there. And then even on a record level, that means on every single log line

and every single trace that comes in, we can even specify, I think what we call the security context where you could then say, these are all the logs that are coming in and we need them for long-term auditing. However, the security context is for team A, B, or C, or maybe a business unit.

And so you can really then specify it down to the individual record level, which is a, again, I never thought about this because this is security and data access is not my field of expertise, but it's just so great that we've built this in and now making it non-Dynatrace. These are requirements for large enterprises

because the reason why we have implemented these things is because we hear and we have these requirements from many organizations around the world, especially in specific fields, because they need to reduce the risk. They need to apply to certain standards. They need to get their certifications. And so this is why these are all things you need to consider

if you build your own observability platform or if you're deciding to go with a particular vendor. And actually, Andy, good that you mentioned or interesting that you mentioned because earlier this week, I spoke with a customer. They are a global organization and they have offices or entities

in the EU, in Asia, and also across the Atlantic Ocean. And they were looking at, on one side, how to make sure that the entities from the countries would keep the data separated from each other because they don't necessarily need to see those. At the same time, the global unit needs to see at least some overview, some visibility into how

the system is working globally. And those are exactly the types of the organizations that need to look at and that require this kind of access also as you described. I also think it's a great example of, once again, going back to here's a blocker, how do we deal with it? If us or any other tool didn't provide a way to separate the data and do these controls, it'd be like, well, it's all or nothing. So we can't do it then, right? Because of the regulation or something.

So I think it always goes back to that. How do you work with the regulations or the restrictions that you have to find a creative way that doesn't violate that, but gives you that access. And a lot of times, you know, I think that that bucket idea we came up with was really pretty clever. I don't know if we came up with it completely on our own or if we were inspired by others, but either way, it probably wasn't an easy task to figure out how do we meet all the requirements for this and make it happen.

So it just takes a lot of effort to do these things, but they can be done. And I'm really happy that I did not need to figure out how to do it. I just talk about it. I really appreciate and admire the people who figured it out. Right. Hey, one topic, just quickly, because I've heard this term before and I know it's a common term used,

but I wanted to understand what this means for us. Bring your own key. I think this is something that is an important topic, is always brought up. Can you quickly highlight what this term means in the industry? Yeah. I don't know how much this is an industry standard because I've heard also like different terms.

But in general, what it means is that a customer manages the encryption key of the data that their vendor encrypts. So it means that if the customer decides to cut the vendor off or simply revoke the access, they just remove the key, delete the key, and the data is not accessible by anyone. Such a simple idea but but huge, right? Yeah, it's a very simple idea, but it's huge. But this requires exactly what I mentioned earlier, that you do not encrypt all your data

with one encryption key, but you encrypt, you use more encryption keys, ideally one encryption key per customer. So it means that then if needed, you can go this direction. And then, how I usually describe it, because is that the main difference, and again, it is a little simplified, the main difference when already the data that the SaaS vendor has from the customer, if they are well separated, and if the data of each customer is encrypted by a unique encryption key,

it's mainly about how is the encryption key stored and managed. Is it in the key management system, in case it's AWS, of the vendor? Or is it in the key management system of the customer? This is the major difference. And of course, if the customer manages it, it's easier to revoke the key however even if the if the vendor manages the key if they if the customer requests them to revoke the key they will have to they they will have to do it anyway it will just require take a little longer and require some process however for the customer that would be easier because they would not have to have all the processes around managing those encryption keys. Because if

something happens to the key, if they lose the key, there is no way to get the data back because the vendor does not have the key. So there are pros and cons. And when our customers ask us about bring your own key when they request it, this is exactly the type of discussion that we have with them. That's interesting because I think the, sorry, but that point exactly, how prepared and experienced are customers in managing their keys? Whereas if you have, like, again, your AWS example, that's all they do, right? That's their job. They're experts at it. They figured everything

out. So there's that huge trade-off. And I'm glad you went there because as you said, if they lose the key, it's exactly what I was thinking. I'm like, oh my gosh. And of course, there are customers who are experienced. Right, right. There are. Yeah. But that's the big question. But it might not be as easy as it looks for someone, for some customers. Because I've even had just my IM keys for AWS in the past, and I'm like, oh, where did I put that again?

It's pretty good. Hey, Milan, thank you so much for clarifying this. I know we're getting to the end here. And I know you mentioned this certifications, whether it's HIPAA compliant. I just wanted to highlight, folks, if you're interested in learning more about these, like so many certifications. I'm just looking at the Trust Center. It's a web page that we have or like a page on our website. I read here CCPA, FedRAMP, GDPR,

obviously, HIPAA, IRAP, StateRAMP, like so many different certifications that are out there that we are following and I'm sure there's many out there that folks that sound familiar to you. I guess any other resource, Milan, that we can point people to? I guess the Trust Center is a great starting point. Trust Center is the best starting point. And I think I can say that we are actually working on an update or revamp of a Trust Center where the information will be even,

I would say, easier to consume, even better. Cool. And then I know we've also put out a lot of blogs over the years to also highlight and explain some of the certifications, how we adhere to them, what they really mean. So folks, if you're interested in learning more, all of the links will be part of the podcast description. So check it out.

Milan, did we miss anything? Especially put yourself into the shoes of somebody that has the task to look into says yes or no for an organization. Is there any other final words, tips and tricks, best practices? I would not say that we missed anything and I probably would not want to add anything more because it's easy to add more and more and more

and then at one point it gets too complicated. So actually I would go in a way to try to summarize and simplify that. I assume that for many people who listen to this podcast, talking about security, privacy, and compliance, it's something less usual. It's not their day-to-day job, what they think about daily. So the last 30 to 40 minutes could be quite overwhelming. So what I would say, if there is one thing for you to remember from what we have

been talking about, is do not worry about, like compliance, security and privacy look like a massive elephant in the room. It is, it could be an elephant, but usually not as big as it looks like. And my advice is try to understand the requirements for why certain regulations, security, privacy requirements from the teams are coming and work very open-minded and work very, be very open-minded and work with the security,

privacy and legal folks within your organizations and find the solutions together as one team. Because ultimately I am pretty sure that everyone in your organization wants to make the organization successful. I think we have a soundbite there. Perfect, yeah. Yeah, that was really good. Milan, thank you so much again for being on it.

Brian, did you have any, cut you off again, any thoughts? Any other questions? No, my final thought was just more around I work on the sales engineering side, solution engineering, and discussions of security in the tool is always a double-edged sword, right? Because on one side, it's going to add some cycles to the sales cycle. But for me, because I'm the type of person who thinks antivirus should be mandatory for everybody, you should have to get a license before you go on the internet so you know not to open up attachments,

I really appreciate when our customers ask us about the security stuff. Because you should be. You should know what the tool has available, how they're going to help you be compliant, and not just go in blindly. So to me, it's always a sign of someone who's thinking about the bigger picture. Like, we can't just buy something and put it in and then, oops, later on. So, yeah, it causes us a little pain in the sales cycle, but to me it's like you're being responsible, and I really, really appreciate that.

And hearing this stuff from you, from the side of it, that is what we usually point to, you know, it's really great to hear about all this stuff, because there's a lot that obviously, myself and I'm sure to some extent Andy was not even aware of or thought about, so just really appreciate you coming on and talking about

this. Actually, Brian, that's a very good comment, and if I can spend one or two more minutes, that if the customer asks about it, it's actually good because it means that they think about it and they ask about it early. And this is important. Because if they do not ask about it early, but only in the beginning, because usually with the enterprise customers, they always have some security checklist that we need to fill out. If the security checklist is part of the contracting phase and there is potentially a topic or area

that needs to be discussed between the security teams or subject matter experts, then it's a big challenge, problem, stress because it usually takes a little longer. So if the customer asks early, it's great because those potential areas of concern to be discussed can be identified early and would not block actually the sales team and the customers from getting the deal done and adopting the solution as soon as

possible. So actually, I am getting it one step further and what I incentivize our sales teams, bring this up proactively on your own with the customer to start looking at it. Of course, not at the very first thing. So that there is enough time to potentially discuss the concerns or the things that the customers need to clarify. Yeah, it's also a good sign of the organization, too, if they do bring it up on their own. Because, you know, we've always talked about being aware of security, not just from that point of view, but, you know, AppSec, being aware of performance, being aware of all these other things, and if they're voluntarily asking about that, that means they are very much aware of all the different factors that go into

things, right? They're probably thinking about the architecture they're making, which is going to make them more successful in their thing. So it's not a definitive signpost, but if you have someone already thinking that way, chances are they're going to be really on top of all aspects of their environment and stuff.

So it's always a positive sign to me. But yeah, good luck in the account execs to bring it up. Sorry, account execs, if you're listening. Anyhow, that's it. Andy, you got any last things to say? No, all good. Thank you so much again. Brian, this is just between the two of us now,

but the Denver in November is coming up, just saying. Next weekend. Well, hopefully the snow will be melted by then. Yeah. Denver in November. Yeah, I can't wait. Anyway, thank you everybody for listening.

Thank you for having me. Yes, thank you Milan for listening. Um, thank you for having me. Yes. Thank you Milan for being on. It was very, very pleasurable. Uh, I, I,

you know, I just really love doing these things. Like every guest, this is a surprise. I don't mean like, Oh, who is it? Like,

but like what we learned and the insights are just, it's just amazing. Um, so, so thank you so much. And, uh, thanks everyone for listening and we will see you next time

we didn't do any U2 jokes today Andy no no no it's all good it's Bono don't call him Bono it's Sonny Bono Sonny Bono is Sonny and Cher who hit a tree and killed himself by accident by skiing into a tree

anyway we'll save that story for another time. Thanks, everyone. Bye-bye. Bye-bye.