Michael Isbitski – Managing Cloud Risk Without Slowing App Delivery
Learn how the largest financial services, media and software companies address cloud security. You will gain insight into the top security challenges and pragmatic techniques to manage cloud risk without slowing down application delivery. Michael Isbitski, director of cybersecurity strategy at Sysdig, will share our customers’ best practices for securing containers, Kubernetes and cloud services.
Transcript
Hello, everyone. Welcome to Cloud native day 2022. I'm Mike asbitski director of cyber security strategy with systic.
I've been here for for a few months, but prior to this I've had a lot of experience as a practitioner and security leader and also industry analyst covering all a lot of areas particularly application security defect cops and Cloud security and container Security today. We're going to be talking about managing Cloud risk. Without slowing application delivery, right?
That's really kind of an important aspect of this most businesses are trying to accelerate how they build and release applications and infrastructure. There's inherent risk that occurs with that with Automation and most of this is being done in Cloud environments or with Cloud native Technologies. So we're gonna kind of do a whirlwind tour of these topics.
If you have questions, I'm always available. It's kind of my gig right it's also my passion, but you know, please do stick around and ask questions. That's the way we all learn.
Agenda for today. We're going to kind of do the Journey of how most organizations get into cloud and adopt Cloud Technologies. I want to talk about the risk that emerge in Cloud native environments and then we're going to talk about systic itself.
And what is it that we do and some of our customers, you know, how are they actually approaching Cloud security problems and container security. How are they using systems technologies to address those problems? now most organizations when they get into cloud and Cloud native typically starts with stage one, which is kind of you know, Lift and shift or rehost right?
There's often a tide of data center consolidations or data center migrations. It is a desire to get things out of traditional data center environments often that's bare metal, but it could also be virtualized environments but there's cost associated with that right? There's a lot of it burden there's a lot of benefits cost benefits that can be reaped in Cloud environments, right?
You only pay for the compute that you use that's always been the promise of cloud typically also as part of this Cloud Journey though you you also see other kind of Intersecting factors particularly devops practices, right how we build and release applications and infrastructure has changed. It's no longer kind of that traditional waterfall world. It's very cicd build pipeline Centric and also often there is an undertide of newer design patterns particularly microservices architectures.
We're you're building a smaller units of functionality that make it easier to change those things and redeploy and oftentimes containers of the ideal form of compute to host a microservice could be a lightweight virtual machine as well. But most organizations are are rapidly embracing containers because of kind of that repeatability easier to roll out new updates and things quickly so stage one, right that's kind of that rehosting or lift and shift into cloud or Cloud native Technologies. Refactoring is where you're kind of rethinking.
How is this application built? You'd likely have some monolith. You want to break that down?
It's just too much efforts to kind of update it right you're talking about a lot of interdependencies within the application code and the infrastructure. You can easily break things right and changing all of that environment. It just takes too much time.
And now you start thinking about those cicd processes and squeezing everything in it just can't work. So stage two is we're organizations kind of go deeper into what cloud native technology can provide them and start refactoring their applications to to you know, really take advantage of cloud environments and stage three is really where you get through truly to that cloud native platform some might view this as utopia, right? It really depends on your organization and development pedigree.
How old is the organization right? Not every not everybody's born in the cloud right? Some organizations have been around for decades.
You have a mixture of Brownfield and Greenfield Technologies. So you're gonna have monoliths and microservices but stage 3 is usually things like kubernetes for instance or serverless Technologies like AWS fargate and Lambda. And security really needs to keep Pace with all of this Innovation, right?
This is a problem. I've often heard when talking to security practitioners. Usually it starts with digital Transformations could be this Cloud native Journey, but organizations desire to move faster security is traditionally slower, right and that's by Design often because we want to be safer you make sure best practices are implemented.
So there's often a lot of push on security to move faster have tooling that to integrated and seamless that kind of works to support development and release process. So it's it does cause friction in some cases right? It's very tricky and you know, you can see this statistic here 60% of companies deploy many times a day to once every few days, right?
It might not be for all your applications or infrastructure, but it's certainly going to be those newer things. Like maybe you're a calm our sites or a customer facing sites. If you have them You're Gonna Want quicker changes right because customers the demand a new functionality that's just kind of Way things are in the world and security teams.
It's it's you know, kind of security 101. It's always about how do we find prioritizing fix all these vulnerabilities and misconfigurations? Right?
That's always been the kind of challenge to security teams. But now it's also we need to balance that with release velocity right and considering devops practices. Like how do we do all that security work without impacting negatively our it teams.
and Cloud native architectures are different right kind of something that's depending where you are in this journey of Bare metal virtualization and containerization containers might be a very foreign concept, right? You know many practitioners are used to you build the application deployed on to infrastructure that may run for weeks or months maybe years right? Maybe yeah, you don't want to reboot the thing, right?
You don't want to cause that production outage containers are much different right? When you do kind of operate with containers at kind of production scale or Enterprise scale containers are typically very short lived or ephemeral. Right.
So the statistic which actually comes from systics research on the topic on cloud usage and Cloud native usage. It's almost half of containers live less than five minutes, right? That's a very short lifetime if you think about this from kind of certainly observability, right?
How do you kind of do troubleshooting if that things you know spin up and tear down within five minutes, but also on the security end of the spectrum, how do you maintain visibility into what that container is doing to know as data been leaked. Is there some type of compromise? How do I Implement my controls?
Right all of those kind of security best practices becomes very challenging, right? How do you how do you kind of maintain your security visibility troll in these highly ephemeral environments and kubernetes is notorious for this and maybe not everybody is on that journey of adopting orchestration platform. Usually if they are they're looking at kubernetes, but kermudanese essentially spins up and and terminates those Containers as a matter, of course, right?
That's what it's doing as you need more capacity. It's going to scale those things up to support your application workloads. So this is it's kind of one of those things that's part of the complexity of kubernetes or the learning curve right kind of getting used to this world of where containers are just spinning up and tearing down very quickly.
All right risks that emerge in Cloud native environments. There's no shortage of breaches right? I'd say one of the most common we hear is things like S3 bucket exposures, which are are interesting.
Right? Because you know a S3 is that AWS simple storage service kind of general purpose data storage not inherently secure insecure by itself, right? It's just kind of how do you spin up that data storage location?
And then how do you lock it down? An AWS is given clinical tools on. How can you monitor those things?
How can you lock them down at scale but they still happen right and it's kind of complexity in Cloud environments, right? If you think back to what we've been saying about FM morality, but also scale of containers, right? We're gonna see this on some of the customer examples.
It's often thousands or tens of thousands of containers. And often there's an undercurrent of automation, right or machine automation. So Services need to be able to communicate freely.
You can't be challenging for authentication and authorization. So that's actually where a lot of things like those S3 exposures happen because credentials are being hard coded or API keys, right? So an engineering team might be inclined to just create that repository and neglect the lock it down because it's too hard to kind of think about that machine identity scenario and account for your containers that are spinning up and need access, right?
You can't be doing that. I know it's just not gonna work. So these these happen and they will continue to happen get repo exposures are also kind of in this kind of saying domain and then we also have other very large-scale breaches like Capital One for instance was very interesting because it was a very complex attack chain kind of pivoted from application domain into infrastructure or the attacker was able to Target the cloud and metadata services and then pivot and attack other infrastructure within Capital One Cloud environments, but you know, the end result is the same you're talking about very large scale data exposures.
There's regulatory impacts from that right Capital One certainly has to appease their customers. So when data is exposed like that, it's it's a pretty massive hit right certainly reputational but also financially and Gardner has the statistic that Through 2025 more than 25% of cloud breaches will have root causes they're actually preventable misconfigurations or mistakes made by end users. Right and that just kind of reinforces what I was explaining about, you know your architecture or design.
It is going to be inherently complex, right? You can configure something like an S3 bucket securely but doing that at scale and maintaining that visibility can be very challenging. Right?
So it's preventable and not necessarily easy to do in practice, right? So that's kind of where these mistakes are happening. Crowd Cloud sprawl increases risk, right?
This is a this is kind of a an evolution of that thought that we're creating a lot of resources, right compute data repositories identities, right and identities aren't necessarily just end users in many cases. They're actually machine identities right or service identity. And that machine identity it's not necessarily going to use a GUI, right?
It may not even use a command line interface more than likely it's going to be saying API calls and it needs to do those systematically and automatically right? This is where that at risk. I described emerges right?
How do you how do you secure that service interaction and then store credentials so you can do the authentication and authorization security it gets incredibly complex very quickly. And again, this is where organizations often makes. all right, if we had to think about How do we secure a modern Cloud application?
There's quite a bit, right? But you can kind of break it down into specific personas that exist within organizations often. There's a devops.
Function that's usually a combination of software engineering or application development and then infrastructure and operations, but it's some organizations that does become a combined function, right? You see specifically devops roles or personas that own both application code or infrastructure code and the infrastructure it runs on right because as we're going to see as part of this Cloud native Journey many things become forms of code. So it you do have to kind of have some code awareness or be able to kind of work with software engineering teams to to get things addressed quickly.
We talked about those security personas right like that. We're always trying to find and fix vulnerabilities but also identify alerts is this actionable is that an actual risk? Should it be prioritized most security teams are wrestling with quite a bit in their Enterprise, right?
There's all types of attacks and certainly Cloud attacks are one aspect that there's many other things like Email born a tax for instance. and then there's a you know, kind of the cloud operations function or Cloud Architects just might be platform operations, but they're more concerned with the cloud environments or Cloud native environments, right so different personas this can Branch out right you have many different types of roles in organizations that it can be shared responsibility to right we see all types of organizations and government entities that Our staff differently right or structured differently. So in many cases there's shared responsibility, but generally those are kind of the the generalized personas in organizations.
And as I've been looting to you the scope of what the responsible for is. It's kind of all types of workloads. Right some of those might exist within data center environments increasingly things are hosted within Cloud environments, but certainly Cloud native platforms, right?
So essentially every organization is adopting. So some type of container platform. They might be hosting that on premises but more often not there are also hosting that in Cloud right things like manage kubernetes makes that easier to work with or even a managed container service.
So all this kind of needs to be rationalized right if you think about the larger it organization structure, how do you kind of support these mixed technology stacks and ensure that all of your non-security requirements or accounted for but also the security requirements right across kind of these heterogeneous environments becomes very challenging very quickly. And core capabilities that organizations really need to look for. You can kind of generalize them into four categories.
You see them here a vulnerability management is typically been something that security teams kind of addressed after the fact where they're scanning and production usually identifying things like cve IDs most commonly and then they'll kind of go back and treat us those things and it might take months or years to correct or remediate everything. That's a problem. Right that doesn't really work in the world of agile and devops, right?
We need to be doing vulnerability testing and vulnerability management early and continuously, right? So you often hear terms like feedback loops. So doing those things contagiously and build pipelines when you find something make sure you're working with you correct or most appropriate Persona in the organization to you know address that maybe that's something just configured.
Maybe you need to update some dependency. Maybe it's a commercial software package package patch it but changes right the remediation workflows Threats and anomalies that's very much in the world of threat detection and response, right? How do you monitor your environments and run time to know?
What is you know the normal baseline or known good to identify is somebody attacking, you know, is there potential reach occurring and then I need to respond to that quickly and effectively. Configuration risk posture. We see a lot of this right talked about things like S3 buckets, but there's also the concepts of cloud control planes.
Like if I have an AWS subscription, how do I make sure that all the compute settings are defined correctly at the control plane our S3 default Define correctly. There's a lot of things that can be done at the control plane to make sure you're following security best practices, which also often mapped a few things like compliance and regulatory requirements, which is that fourth bucket, right? So there's often a discussion of compliance versus security that can be distinct things.
Most organizations have to consider both right. There's the things you do in order to be compliant or satisfying regulatory requirements. And then there's the things you're going to do to additionally secure above and beyond right your data your customers and your employees.
Systic is the standard for cloud detection and response. We have two very well adopted open source projects. Probably the one of the most well-known is the cystic open source project itself.
Just kind of a Telemetry Gathering mechanism. We sometimes refer to it as a flight recorder, but it's able to gather all the signals from all types of workloads, whether they are virtual machines or containers, right and then that data or those signals can be used for a lot of other use cases certainly monitoring right or observability. Use cases but also security right and that's our other open source project, which is Falco which we sometimes refer to as the security camera, but based on those signals, right we can take appropriate action.
So there's a lot of out-of-the-box rules that are very useful within Falco, but it becomes this very robust threat detection engine, right? I've gathered signals now, I actually need to analyze that data and then figure out How do I respond effectively does this actually look like a security meant and Trigger workflow terminate that container right? There's a lot of potential responses.
You might want to take. you'll see some customers here on the right or actually how some clouds and isvs have actually repurposed some of the assisting and Falco open source, and then you see some some other cystic customers on the bottom there. But I do want to actually get into specific.
Customer examples and how they're leveraging system. A little bit more about this dig, right? I talked about the open source projects.
And actually what's not listed on this slide is our our one of our Founders is actually The creator of the Wireshark project which if you're in kind of the network engineering space or network security space maybe even just security pen testing, right? You've likely heard of Wireshark or ethereal or etherreal depending on I I like to freeze it but a lot of the design philosophy around Wireshark actually Catalyst for Cystic right as opposed to just Network traffic though. We wanted something that was more holistic together all types of signals, right what's going on at the syscall level for that particular workload which includes things like Network traffic, right?
And then the ability to filter on that is it's kind of part of sign. Uh, we are headquartered in San Francisco. We have quite a few customers over 700 Enterprises.
I've used you've seen this statistic about the open source downloads as well over 45 million at this point and the company is quite sizeable and growing. We have this concept that cystic of source to run right as I was talking about earlier with kind of devops processes and how vulnerability management kind of needed to be revamped. Right?
It could not exist as this traditional security thing where you're you're running scans and production and finding issues like the game, right you you often hear things of the cost of a fixed late in production is 30X right? I think those studies were from this or old IBM Consulting research but you know the reality is that a fix if you're not implementing it early as something is being built, it just becomes exponentially more expensive to fix it. Right so cystics kind of engineered around this concept, right?
We need to be constantly testing all types of code and workloads and then provide that information to the right personas and organizations so they can address that quickly right? You don't want to be finding things late. And then figuring out how to block it with something like a firewall just not going to scale the world of native.
All right, one of the largest deployments and actually a great customer examples Yahoo, Japan. All right, they have over a 50,000 node kubernetes platform, which is a exceptionally large if you think about it, right a kubernetes cluster at a minimum could be one right you could have the control plane and the worker nodes all running on one host but You know, that's not really Enterprise grade. So if you want to look at kind of a reference architecture or considerable size kubernetes deployment Yahoo, Japan.
It's certainly one of them. So that's a lot right a nodes and host that they run on trying to make sure that those are all available and not being attacked that is kind of a significant Challenge and Yahoo. Japan's case to have over a million containers running on those notes, right and that's going to change because of the effemorality right or scalability.
So you might have more or less on a given day depending how much Yahoo! Japan's customers are using the services. They also like the cystic ability to provide context to prioritize vulnerabilities and then assign ownership within their engineering teams, right that's important that kind of goes back to what I was saying the personas.
It's not enough to just find security issue. Right a security team runs a scanner spits out results, right? We need that kind of warrant in your context or work streams of how engineering and development teams are working.
Right so issue things like get pull requests and make sure that we're addressing that at the source. And you know, Japan also likes the out-of-the-box Falco rules as a describing right Falco again, is that threat detection engine, but there's a very robust rule set that comes with it that a lot of organizations find is very satisfactory refer achieving compliance didn't have customized beyond that but they can right and you'll see in some cases. Our customers are customizing Falco rules for their specific use cases.
another customer example, we can actually name the Company here, but it is a leading US based digital payments firm. Very sizable. I'd say it's probably one of the bigger names you you could think of if you think of this kind of space they have over 10,000 hosts and over 1,000 accounts, but across clouds, right?
You see that it is actually AWS and Google right? So now we're kind of in that world of multicloud. So it's not enough to just kind of manage user identity and machine identity and one of our environment I actually have to rationalize us multiple environments.
So this particular customer? Really like the ability to detect risky configuration changes that's cystic provided. And again, you kind of see this as a recurring theme that Falco becomes kind of that mechanism that enables it but in their case, they also like the ability to ingest cloud trail just kind of that ubiquitous logging service within AWS, right everything that occurs with any of the AWS environment gets logged.
Cloud Trails or within a lake if you're subscribing to that. So ingesting that data becomes very important to threat detection and response strategies. They also like the ability to identify events real time as opposed to.
Processing all the data after the fact right? So you sometimes see this in Cloud security strategies. It depends on the tooling that Particular organization has selected but they might be doing snapshots of the environment.
There's polling intervals that occur there, right and there can be latency. Maybe it's 24 hours 36 48 and that's a that's kind of a problem. Right because it's not necessarily just your employees that might be changing things that can also be attackers.
So if a change occurs in your environment, maybe it's something like an S3 bucket exposure. You kind of want to know about that real time, right? So that's that's kind of this premise of streaming detection.
It's kind of another way to say I want to kind of want to know about that real time. Like tell me when somebody changes that so I can take an appropriate action. Otherwise, I have this kind of very large window of exposure depending on what point that change occurred between snapshots and you also see issues with Sam deployments commonly.
That's things like Splunk or Q radar right? There's there's no shortage of sim Solutions but a lot of organiz Oceans taken a lot of log and event data. They just don't know how to operationalize that or make it actionable.
Right? So same kind of becomes a Dumping Ground for all types of data and it's it's very hard to respond to threats quickly. So this particular organization really loves statistics capabilities and on that front, And again, it's kind of when we think about this concept of multi environment.
We have the user identities and machine identities, but also mixed workload types still likely have a hosts in Cloud that's kind of virtual machines as opposed to bare metal and then you have all types of containerized work another common security use cases to meet Sauk to compliance that's kind of a standard for achieving certain sets of requirements that are appropriate for a cloud-based service provider right things. They should be doing such as securing their environments. However, they authenticating and authorizing administrative users securing the server rooms themselves right in most cases.
That's the cloud provider itself. Right? So your stock to compliance kind of shifts a little so I should say some of the burden rest on the cloud provider, but nonetheless many SAS based Solutions are Concerned about stock to clients and in this particular case.
They were are a heavy Google shop, right? They use Google kubernetes engine to host their containers, but they also consume a lot of Google cloud services as well. And they they really like the systic offering because of the unified solution for image scanning right talked about kind of how vulnerability management shifted we're not doing at the Town the life cycle with containers containers get instantiated from container images.
So the concept of image scanning becomes incredibly important you want to be doing that very early in the development life cycle oftentimes. That's as things are being built. But certainly as code is committed to standardized repositories or Registries and then things are being built in cicd.
They also like the ability to Um support or enable their intrusion detection and then that configuration security right tell me if something has changed quickly so I can respond to it and that's our two pieces huge right because it's it's not easy to attain some cases. It can be expensive in terms of time or dollar amounts to achieve it. Right so obtaining that stock to certification, but then also maintaining is important, right?
So it's particular organization preferred assisting All right, and our final customer example is actually Goldman Sachs. Goldman Sachs is actually been a cystic user and consumer for quite some time very heavy on monitoring. But they also expanded to the secure capabilities as over time mixed workloads actually have over a hundred thousand Linux hosts.
They're certainly some containers in that environment as well. And then over 10,000 developers, right? This is a kind of interesting.
I in my experience. I've actually worked in an organization that had Yeah, actually more developers then then this count it becomes very challenging. Right.
There's a lot of code that's changing all the time. Right? I talked about digital transformation and Cadence of changes, right and then that release velocity.
It just keeps going right you can't there. There is no time to sit down and review everything right has to be kind of more automated and systematic as for part of build processes. So Goldman actually liked the lightweight instrumentation that's cystic provides, right?
You'll sometimes hear in security language that agents are you know taboo, you know cystic is an instrumentation piece of technology you need ways to kind of gather that Telemetry there's different deployments for it. I'm not going to get into it in today's discussion. But if you prefer to kind of get deeper in the weeds, please do reach out but there's different mechanisms to kind of plug into environments to extract that instrumentation, right that's important.
We need ways to gather that data or those signals so we can actually monitor workloads and then actually determine appropriate security responses and some cases agent list just can't work. They also standardized on miter attack framework and miter based detection. So when they identify issues in their environments, they they prefer to map those things to miter attack.
This is a very common amongst secops practitioners, right? We want kind of a universal taxonomy taxonomy for classifying threats so we can you know, determine what what's the appropriate response and then coordinate cross teams internally, but also externally so minor attack kind of becomes that common language in the world of detection and response Goldman also like the anomaly detection-based features particularly for file and network activity, right? That's kind of what I'm saying earlier about Wireshark, which was kind of very Network traffic Centric system actually provide that plus more right we're looking at this call activities that we can see file and on network activity.
Um, and then the forensic piece was very important to them as well. If you think about digital forensics, it's challenging in its own. Right, right.
How do I make sure I'm gathering all the right data to support incident response or audits? And then if you also combine that with this reality of ephemerality and Cloud native environments, you might not have that that workload five minutes from now, right we talked about this Statistics. So there's really complicates forensics, right?
How do you make sure you're Gathering keeping all that data that can support forensics and auditing after the fact I've come to talk about this throughout right kind of cystics approach with source to run. There's a lot of components to this again. It's a lot more than what we can get to today.
I talked about how everything is kind of become forms of code. And in the world of cloud native that's typically referred to as a infrastructure as code right container images, but also things like kubernetes yaml. Maybe you're working with AWS cloud formation or High School terraform, right?
There's a lot of infrastructures code formats and all those things are used to define. What should your infrastructure look like? And then those are the things you're spinning up so that that's actually where you need to make configuration changes or security fixes.
We talked a lot about these capabilities with configuration checking which is often referred to as cspm or Cloud security posture management the runtime security aspects which is kind of a powered by Falco heavily and then incident response, right? What do I do once I've detected an anomalous event that that could be to a security incident or reach? And all these things kind of supports Regulatory Compliance, right?
And these are going to vary per industry and region, right there's different different regulations for all aspects of business. So if you take nothing away from kind of mine discussion, it's really statistic can combine all of these signals throughout the lifecycle of workloads kind of rationalize things and across environments. Right?
Most organizations are going to be mixed. You're not doing everything in Cloud. You're likely hybrid cloud or multi-cloud.
Another topic worth touching on you know, as you think about the shift left approaches, right? Typically, this is out organizations. Try to get into some type of devsecops strategy, or maybe it's an offshoot of their application security strategy often those things intersect, but you often hear this concept of shift left.
Right in the world of cloud native as I was saying, you know many things start as container images. We are sourcing those things from hopefully trusted Registries, but the reality is much like mobile app stores. It's very hard to kind of scan those things and keep on top of all of the code and all the dependencies, you know, all the providers have challenges on this front as things are changing quickly, right we talked about this extensively kind of those release cadences just keep accelerating.
So scanning things everywhere and understanding the fully nested dependencies. It can be challenging. It's kind of an Ever shifting landscape.
So there's a lot of discussion and shifts left about doing container image scanning doing those things early in development and in builds and then releases, but the challenge that often emerges is as you scan. It could giving container image you are going to uncover quite a few vulnerabilities or cve IDs and it's very hard to know what's actionable right? So you can actually almost end up in the same boat you were with the traditional vulnerability management approaches where you're staring at hundreds or thousands of findings.
You just don't know what to fix and if it is Source like an open source project, you might not want to fix that right? That's not your responsibility. So what's this thing provides which we call our runtime intelligence?
Is we'll actually tell you which which packages are executed in runtime so you can actually know well these are the container images. I need to address which really helps kind of prioritize your risk, right? So reduce the vulnerability alerts by up to 95% and then say Cycles triaging scan results which include your security teams, but also your non-security teams, right?
You don't want software Engineers chasing down cvids. It's kind of a losing proposition. So this capability actually saves organizations quite a bit of time and day expense.
The other reality with something like the cystic secure platform. Is that as you think about the ecosystem of devops tooling and Cloud tooling? There's just a lot right?
There's CI Services CD Services. You have images registries. You have code repositories.
You have traditional ITC systems for collaboration and defect tracking in the world of security you have Sims and it's response, right? So there's just a lot right in the cloud providers all have their own native mechanisms for working with workloads. Typically.
Those are API based. So kind of an API first API driven architecture is essential. So this again, this is kind of assistance engineered it's built for this world of cloud and containers.
So you have all those connections to disparate tooling that most organizations will have one or by multiple of each of these Technologies. But if they are multicloud, they're gonna kind of fill out this this logo chart, pretty quickly a couple more takeaways around this should be pretty apparent but cystic is kind of that mechanism that can give you a single view of risk prioritize what matters right talked about kind of that reduction and vulnerability counts. You can actually focus on what matters right safe cycles for your development teams and then release velocity, right?
That's kind of the name of the game with devops and Cloud native you want to be able to deploy quickly to meet the needs of the business and there's a lot of customer benefits to this some of this map to business value. But it's shorter time to Value. Right?
So we want to release quickly so we can recognize value for our customers or employees innovate quickly, right? That's kind of a that was always a big Catalyst for digital transformation to begin with and again Cloud native kind of underpins those things. An increased automation, right?
We're never going to have enough staff. You're never going to be able to do look at everything. It's just the reality Technologies moving too fast.
It's too complex. So now most practitioners and organizations are always trying to find ways to automate and increase their levels of automation. Cystic actually just achieved.
A or received an award from Frost and Sullivan as a global container security company of the Year award. I'd also encourage you to come check us out at our virtual booth at the event. I'll be there at the networking session so you can meet me or any of the other speakers.
We also have a lot of relevant resources on this front. We actually just published some pretty extensive research with Sans the kind of dives into topics like agent versus Agent list keeping on top of API keys and different kind of complexities that emerge in Cloud environments and responding to threats. And finally, we have kind of a competition going at the the event this scan this QR code, but how it's a crossword puzzle to crack the code.
You could be a winner can earn some some nice swag and Amazon gift cards. So please do check out the you know the game and good luck to everybody. And with that, thank you.





