Webinar Recording

Managing Risk in Ever-Changing As-a-Service Environments

Name: Managing Risk in Ever-Changing As-a-Service Environments
Uploaded: 2021-10-15T12:00:00+02:00
Duration: 58 min 34 s
Description: In the infrastructure and platform-as-a-service worlds, application developers are the new infrastructure superstars. With concepts ranging from containers to infrastructure-as-code, we are experiencing a paradigm shift in how tightly coupled application code and the related infrastructure are. Often security is under-represented in this formula, and for good reason.

Posted on Oct 15, 2021

In the infrastructure and platform-as-a-service worlds, application developers are the new infrastructure superstars. With concepts ranging from containers to infrastructure-as-code, we are experiencing a paradigm shift in how tightly coupled application code and the related infrastructure are. Often security is under-represented in this formula, and for good reason.

Webinar presentation, KuppingerCole

Webinar presentation, Orca

Lead Sponsor

Video Description

Show Transcript

Good afternoon, good morning, or good evening wherever you are. And thank you very much for joining this KuppingerCole webinar that is supported by Orca security.

Today, we're going to talk about managing risk in today's ever changing as a service environment and I'm Mike Small and I'm a senior Analyst with KuppingerCole. And my co-presenter today is Patrick push, who is a technical evangelist at Orca security. So KuppingerCole runs a number of events. And since you've joined this, it's very possible that you would be interested in security. And I suggest that you check out our cybersecurity leadership summit, which will be a, a merged event. It'll be both virtual and online with run from Germany, from Berlin in Germany, and also online.

And these are extremely interesting summits with very good presenters from across the industry, as regards how this session will run you as a participant have been muted centrally, we will be controlling whether or not you can speak, but you can always send in a question via the Q and a box on the control panel.

During this presentation, we will be running some polls and we will discuss the results of those during the webinar and during the Q and a, the webinar is being recorded and you will be able to catch up on this later, if you have missed it live, we also provide the slide decks as, as part of the service. So we're now going to run the first poll and the question that is going to be displayed, and we would appreciate you, your answering is, which is the cloud platform that you mainly use for digital transformation.

Please, will you select one of these? Okay. So I believe the poll has now finished. So let's look at the agenda and we're going to run this webinar in three sections. The first section, I will be talking about how you can make your business fly. Then Patrick will describe in much more detail, how to tackle the security challenges that come from this approach to digital transformation. And then hopefully you will have asked some questions via the poll. And finally, we have a chance to have a Q and a.

So without any further ado, I'm going to talk about how to make your business fly without crushing. And this was the theme of our European identity in cloud conference, because lots of people are going through digital transformation, but how do you do this? How do you make your business fly without actually crushing at the same time? So to give you an idea, there are three things that have driven this. The first is that there are new opportunities through the new ways in which we can deliver it services.

Then we've had to deal with the epidemic and this is forced organizations to change the way they do business. And finally, there is competition that unless you are keeping up with what your competitors are doing, then you are going to fall behind and to give an idea of the kind of agility that you now see.

We spoke with a German hospital within the last couple of months, and they were describing at the beginning of the pandemic, they realized they had a problem because they were being overwhelmed by people trying to get information about coronavirus and whether they were had it and what they should do. And so they, they decided this is a hospital, not if you will a startup it company. They decided to run a hackathon and they created a prototype chat bot.

In one day, they then were able in collaboration with a cloud service provider to create an initial deployment, which covered all of the frequently asked questions on the internet and also by other telephone using the services provided by this cloud service provider. And remember, this is a hospital, not an it professional organization. And subsequently they were able to go into a period of continuous improvement, where they were able to help to use AI to improve the way that this worked so that it could actually refer questions with priority to the appropriate expert.

Now, this is what is happening multiplied across the world. The new kinds of services are making these possibilities a reality for even non it professionals. And so organizations are having to go through a digital journey. Some people have called it digital transformation, but basically what has happened is that just as the, just in time approach to manufacturing completely transformed the way in which manufacturing organizations work and the kinds of goods that we can have just in time.

It, which is characterized by all the things that we now know from cloud services is creating opportunities to do things differently. And in order to compete, in order to exploit these new opportunities, you have to differentiate yourself using digital services, and you can base these on the intellectual property that you have, the data that you have as your organization and your unique selling points. And in order to do that, you need a new way of delivering services.

And this has come about through DevOps, through swarming rather than hierarchical organizations that can respond not only to business requirements, but to feedback from customers and partners in almost real time and deliver just in time services. But when you do that, you create another layer of a risk. If you will, around your organization, because you become more dependent upon these new services. And so you need to secure them.

And not only that, but for organizations, for, for your customers to feel confident in using them, they have to support the customer journey and support it in a secure way. And success is measured by providing a good customer experience, which differentiates you from your competitors and allows you to offer new products, to get closer to your customers, and to make sure that your partners and suppliers are able to work with you more effectively. Now you need to do all of that without crushing. And so if you want to make your business fly, the problem is not actually just keeping flying.

It's actually not falling out of the sky. And at a business level, there are really three concerns, and these are not technical concerns they are, but they do depend increasingly in this just in time security, it's just in time it world upon your, just in time, it organizations are having to comply with an ever increasing number of obligations from laws and regulations. They don't want, you don't want to fail to comply. You don't want your organization to have to pay a fine, you are dependent upon keeping safe, a lot of data about your customers.

This helps you to get closer to them, to deliver just what they need. But if you don't look after that data properly and it gets lost, that's bound for your reputation, it's bound for your customers. And so you need to take care of it. As your organization becomes more and more dependent upon these it services, then you become much more at risk. If the services don't work.

I mean, only yesterday, there was a host of complaints around the UK because the COVID passport system had collapsed for three hours and people were at airports and they couldn't, they were being denied. Boarding denied check-in because this service was not available. So the consequences of non-availability are extremely visible and extremely costly.

And, and the, the cyber adversaries of recogniz this, and they will try to extort money out of you by denying your access to your systems. Now, the new world, the new way of doing things through the cloud, the new development approaches have created new kinds of risks. And to take an example of how these risks occur. I'm just going to quickly look at the capital one data breach, which occurred in 2019. Now there are lots of things that happen, but one of the things that makes me pick this is the fact that it was recorded in a formal indictment in the us district court in Seattle.

And so we know that public information shows what happened, and this is a combination of things that it started off with a misconfigured web access firewall. So the web access firewall is set up to try and protect servers downstream from traffic that isn't related to that application.

Now, if in fact you don't configure it properly. If you allow, for example, SSH through, then somebody can get through that firewall and can actually access the servers that are supposedly protected by it. The second thing was that the hackers managed to get through that and they were able to get to what was effectively a cloud virtual machine.

Now, when you have real machines, when I had real machines, they were things boxes in my room or in my data center, and they couldn't grow legs and walk out. They did not themselves have privileges, but a virtual machine in a cloud service is living within this cloud environment. And so it has to have privileges.

It, it, it has to know, or the infrastructure has to be told that it's yours and it can only access things that belong to you. Now, if you assign excessive privileges to that machine, which you are very likely to do, if you're trying to develop software, because you want it all to work, then those privileges would allow that machine to do things that it shouldn't do. And it turned out that the hackers knew that, and they were able to use those privileges to get more privileges, to access the organization's S3 object data store, and to list and read the files even when they were encrypted.

And the result of that was a fine. So here we had a data breach and a fine, which came from an amazing thing, which is a server that has privileges. So this new world is a dangerous place with new risks and new threats, and that's what we have to deal with. And so this comes from the fact that in today's world, we have just in time services and these just in time services need just in time security. So to look at the journey that we went through, when I, what I alluded to a moment ago is that 10, 10, 15 years ago, you had static it.

When I was developing software, I used to spend half of my life trying to get hold of the servers that I needed. And when the servers came, I knew that I would not be able to change them because they were going to be there for a long time. So I had to plan ahead and development couldn't really start until I'd got these servers. And the systems that we used for development were, if you will prescriptive, there was a specification, we agreed to develop it. We had a plan and we developed it.

And then at the end of the day, if it was wrong, then we said, sorry, it doesn't, you know, we've done what you asked. Here you go. So it was inflexible, but in terms of how we secured it, we could say, when we got the server, we would configure it very carefully. And that configuration was set up because of our understanding of the risk of where the server was, what we were going to do with it. We could manage it through static tools.

The people that could access it were carefully controlled because they had to have access to our intranet, that we spent a lot of time trying to build a perimeter and building a network. And we had lists of vulnerabilities that we could configure out. So these were all static controls that we set up based on a static view of risk. And that isn't really good enough for today's it's world. We have it as a service when I want, when I want to develop something, I use my credit card or the corporate procurement system to get hold of a virtual machine or a set of virtual machines.

And this allows me to get hold of machines, to provision them very, very quickly in seconds, if not in minutes. And I, I then do development in a different way, which is done by a group of people that swarm together to do what is required to fix things dynamically so that we respond to business and customer needs. And that this actually is a, an incredibly dynamic environment. And the problem with that is that it introduces new threats and new vulnerabilities.

As we only just described a moment ago, that the vulnerabilities come from the fact that the servers have privileges the way we develop things quickly makes it more likely that we will leave vulnerabilities that we didn't want. And so what we actually need is a dynamic way of implementing controls just in time security controls that will be created when we create the resource.

When we deploy the, the service, when we put into production, the application, and that needs what we are calling dynamic resource entitlement and access management, which is beyond cloud infrastructure and entitlement management, which deals with this volatility through policies and templates rather than fixed views of risk embedded into controls.

But rather that we have systems that can transform those policies into just in time controls when they are needed without manual intervention, that enforce things like least privilege and all of the best practices that we want, that we can intelligently monitor what is happening so that we detect when things are really going wrong. And we can respond quickly in real time with threat to threats as they occur.

So, in summary, what I'm going to say is that in this world of just in time security in this disruption world, in this time of coronavirus organizations are going through a digital journey to differentiate themselves based on agile development. And to do that, they need to develop a secure customer experience. That the ways that we implemented security, which were designed for static last generation, 20th century, it are not adapted to this digital journey. And what we need is dynamic it, which is flexible, is volatile.

And just in time, and that needs just in time security with our dynamic resource entitlement and access management. And so now we're going to go into a couple of polls. So the second poll is how concerned are you that there are vulnerabilities in your use of these services that could be exploited by cyber adversaries.

Okay, thank you for answering that question. And now in the third poll, how satisfied are you that the tools you have can meet these concerns that you've just described? Thank you for giving your answers. Okay. Thank you for giving your answers to those polls. So now we're going to go into the second part of this webinar, where Patrick Bush is going to describe how to tackle these challenges that we describe. So over to you, Patrick, Thanks everyone for tuning in.

Thank you, Mike, for such a, a beautiful stage setting. I'm going to build upon really all the concepts that that Mike spoke about with a little more specificity before I introduce Orca, and really, you know, we've come a long way in both how we develop software and the infrastructure underneath the powers. It right. If you've got the, the, the same kind of road road rash, as I do, you may recall when workloads ran on physical servers in a one to one ratio, right?

And it's, it's no wonder at that time that we built these big monolithic applications, right? We had this built in delay of procuring a new infrastructure that could easily take six months or more, right.

As we, as we built out our data centers, each sort of tranche of infrastructure took, took a lot of time and energy to simply procure. As our infrastructure became a lot more agile via virtualization. We began to take advantage of that and build applications in a much more agile and dynamic fashion. That was kind of the first enabler. And today we make use of public cloud platforms that come with this assumption of near infinite scale and instant on right. Infrastructure really is no longer the barrier.

And so to move as fast as we can, we need this marriage between developers who author software and infrastructure pros who deploy it in modern data center, environments, developers, right software, and are responsible for such and all of the required dependencies, right? Security plays a large role across three vectors workloads, including, you know, base virtual machines. And now sometimes containers the network security of the perimeter firewalls and of a container orchestration engine.

Usually these days, Kubernetes and cloud environments, developers are tasked to author software much faster since again, infrastructure is no longer a barrier at all, but they're still responsible for that software and all the required dependencies. So their sort of domain doesn't change. They're just kind of forced to go a heck of a lot faster, even though security gets to offload one vector of concern, if you will, in the security of Kubernetes, right. That goes to the cloud provider, which is great.

Any advantages they, that sort of seemingly provides are they're offset by the fact that, you know, security has to somehow now become part of that software build process, right, where we're no longer willing to wait until the software debuts in production to find all security risks. That's a very heavy and costly process.

So we're, as we hear about, so often we're shifting security left, so that's a very new for security, but then also, you know, part of the value in the public cloud is the ability to wrap very tighter security controls around workloads. We call that micro segmentation. It's great. From a security perspective, it's challenging from a management perspective, we go from managing, you know, a few or, or low, low double digits of firewalls in our data center to literally hundreds and thousands and tens of thousands in large enterprise environments.

And so any kind of time savings we realize from offsetting the, the security kind of, of our container orchestration engine, we, we definitely find new areas or new domains to, to be busy as security professionals, for sure. And so it's useful in our discussion to review how those software changes get built and published in, in a little bit more detail, right? In sharp contrast to how software development and far less agile infrastructure, modern teams are tasked with building a and releasing software up to many times a day at Orca.

For example, we have the capability to release code really anytime, right? And that's really only possible because of the underlying architecture of the platform. It's really been built from the ground up to make use of many different cloud services that are managed sort of independently without disrupting the rest. It's a modern design principle that allows us as application authors to maintain our applications with little to no downtime, really ever. It's only possible.

However, by using really, really modern cloud services in really modern ways, and that can be especially difficult for cloud security teams who lack cloud experience, mature tools and process. One of the reasons developers can move fast is that they don't wait for security teams any longer, right? That traditional gate wasn't seen as much of a barrier when we had all of that built in delay. But all of these areas of focus have really been automated, which means security has no choice, but to evolve, to sort of meet that need.

But as an industry, we've really struggled with achieving that security visibility we need while at the same time staying out of developer's way, right. For reasons we've already talked about, and we'll, we'll dive deeper into even now. So that sets the stage for our goals as DevOps or even dev SecOps teams to reduce the friction between software development and operations and security. So let's talk about that from a, a tooling perspective, right? So at Orca, our approach to cloud security really provides four key advantages over any other approach. You'll see.

So we'll talk a lot about coverage again, if we're making use of all of those cloud services, that really were the temptation to the public cloud in the first place, we want to make sure whatever tool set and process we use for security understands them all right. And, and really workloads and cloud services can't sort of fall under the radar. We need to ensure that whatever we choose has lots and lots of coverage. We really wanna make sure that we can have as much capability in one platform as possible.

We know that when we start procuring many separate tools, they all sort of look at their observations distinctly and, and sort of risk them on their own. Whereas if we take the platform approach, and if, especially, if we take a platform approach where observations around, you know, cloud services and workloads are shared between them, then, you know, we, we, we want to use a, a wide enough platform. They can do that, right. They can say, Hey, I found a, a, a risk in a workload. And let me tell you about all the security, the cloud security controls wrapped around it, right.

That that's a really powerful capability and is only possible when you're using a platform that understands both the, the, the third is alerts that matter, right? I think a lot of solutions in this space attempt to win by alert volume, right. And we know from phenomenon like alert, fatigue, and just how understaffed, you know, this is a constant conversation from an perspective how understaffed our security operations folks are with our customers that, you know, they need alerts that matter, right?

The, if I have a limited amount of, of time per Analyst and per security professional, what can I go and do to make the most, the largest difference in my risk posture? Right. That's what I want to know. And then finally built in always on continuous compliance, certainly for those industries that are regulated, but really anyone that's looking to demonstrate that they take security seriously to any stakeholders internal or external.

So, you know, there are really two main problems, you know, with the, the workload agent approach. When we think about two different security domains, one of all the cloud services we use, but then one of, you know, all of the virtual machines and the containers that we deploy as well, right?

The, the virtual machine and container scenario really isn't that on the surface, isn't that different from what we did in the data center, we ran machines, you know, later in, in, as we talked about in the evolution, we ran VMs, we installed security agents. Well, along with lots of others, you know, monitoring performance, backup D P agents in those workloads. And we monitor 'em that way.

Well, a lot of us brought that to the public cloud, as we began, it might have served our purpose at the very start, as we simply modeled the cloud over what we did right. With the data center. But as we began to use more and more cloud services, more and more containerization, even even more and more mature, kind of virtual machines, we found that.

And, and especially as, as, as we grew our cloud usage, we found that, you know, getting an agent to that workload just to have visibility into that workload was a real challenge, not to mention, as we begin to shift security, left it too, was a challenge to, you know, ask developers to say, Hey, please install this security agent in this workload that you're developing so that we can have visibility into what you're doing and tell you what you're doing wrong. Right. It's sort of a relationship fraught with problems, right. From the start.

And I think that's why you saw the DevOps and the dev secs phenomenon blossomed so quickly and evolved is because it solved a real problem in that, you know, security and developers were at odds and, you know, having a, an approach that really has zero friction, meaning no agents and even better an, an approach that really relies on no code installation at all. You know, these were the, the principles that we sort of stood back and, and looked at these agent based solutions and said, you know, Orca Orca can do this in a much better way.

And so one of the core tenants of what Orca does is this process called site scanning and side scanning is the technology by which Orca does not use agents in workloads.

And really what it does is it's, it's focused down at the, the storage that runs your, your workload cloud platforms have evolved enough now where even as consumers, but certainly as ISVs, we can make API calls to each platform and say, you know, tell us about all the virtual machines that any given customer has, but then we can also go one level deeper and say the discs that power, those virtual machines, let us have a look at those. And that's in fact what happens, right?

So that, that storage is analyzed and the storage tells us everything. It tells us the software on your machine, the, the running state of software from a whole security perspective, you know, the, from a best practice, from a workload compliance perspective, all of that data. And in fact, scanning from the side gives us quite a few other advantage. That is that if we have time, we can talk about as well. But side scanning is that, is that first pillar of Orca, if you will. That allows us to be, you know, not only agentless, but it speaks to that pillar of coverage, right?

If I don't have to know that a workload exists before I install an agent and then gain visibility about it, right. If my platform sort of handles that for me automatically, obviously that's, that's a strategic advantage, right? And that's sort of how Orca works. It's deployed at the cloud level. Every time you debut a new workload, Orca automatically knows about it and sends the side scanning process off together, all the intelligence about it, right. And that continues on a regular cycle based on time and cloud activity.

But I guess the point to take away is that no longer do you have to ensure that, you know, every machine is based on the template, because we know that as Mike talked about, that is the best practice. That is what we're striving for. But we also know as we get so many cooks into the kitchen, the proverbial kitchen, if you will, of, of a, of a cloud console, we know that things don't get done, especially with whole company enterprise usage, you know, don't always get done based on best practices and based on the guardrails you set up.

And so it's important to, you know, have a strategy that really is all inclusive and, and speaks to coverage. The other pillar that Orca was really founded on, and it speaks to the, you know, the example I gave earlier where, you know, a, a workload observation might be made. But the next question I might have about that workload observation is, you know, how exposed is it? Maybe that workload observation is, Hey, I found some malware. The very next question I'm gonna have is that as that, so professional is how, how exploitable is it? And has it been exploited? Right.

And that's a question I can't answer with just a workload context. I have to understand at the cloud level, what my security group configuration looks like and what my network design looks like, does it let outbound traffic in or not? Right. All that's important information, as I think about risking that alert and that's exactly how worker was built.

It, it, it looks at that workload, but it also works looks at the, the surrounding or the cloud surrounding around it. Right? So Orca discovers cloud assets. It identifies asset roles, and it's such a big one. Mike did a good job talking about the, you know, the, the breach example, the capital one breach example where now resources hold privilege. Right?

And the, it it's quite ironic. The reason that that decision was made from a cloud level is that as developers, we used to embed credentials in workloads, right? To give our applications access, to do things well, obviously from a security hygiene perspective, that's a terrible idea.

So now workloads inherent permissions that your applications can use for a short period of time when they get started to do, you know, authenticated work that they have to do well, if a VM inherit permissions and your application has access to it, if there's malware sitting on that machine, it too has access to the privilege given to that virtual machine or whatever resource we're talking about. Right? So Orca identifies those roles as well, and then identifies how resources are connected to each other.

And then, and only then will identify the risks, right? And that's a, that's a really, really big difference. If I look at, for example, two examples, one on server, one and one on server, two of, of a vulnerable Apache, right. Web web serving software, and really, really vulnerable with a high CVSs score. If I find that vulner that very same vulnerability in two different places of my network, any other approach to this problem will rank them the same way. Right? We'll look up that external CVSs score. We'll bring it back.

And we'll say red alert, you've got a really, really vulnerable, a web serving software in two places, right? Both being high, no prioritization. What ACA will do is say, look, it's a, it's a big problem. No doubt, but on server two, I'm not connected to the internet at large, right? So it's not publicly exploitable.

In fact, I'm only connected to one other resource, right? And so Orca will look at that and say, these two things, aren't the same. And it's not to say, they're not both serious. They are right. But that second one gets downgraded. One level to that medium level of severity, such that, you know, the security operations staff understand what to do first, what is the truly bigger risk than the other, right?

And that's, that's where Orca, doesn't attempt to win by alert volume, but rather attempts to tell you what's the most critical followed by, you know, the next critical followed by, you know, security observations that can maybe wait a little bit longer. And so speaking to the platform, nature, I think really of any solution, one of the design principles we've really held a steady at Orca is to build as much capability on top of those two pillars of side scanning and contextual risk assignment is really to, you know, build as much capability there as we can.

And so you'll find that Orca finds malware and really in really interesting ways, right? Orca does not have to compete with customers, CPU and disk allotment in the VM. Because again, we don't have an agent that sits at there, right? We do it from the side. And so we can spend, we can and do spend a lot of time chasing down, for example, malware that avoids regular signature based detection by, you know, slight changes, rein encryption, maybe zipped up, you know, these kinds of changes change the signature of a file.

And therefore, you know, change the ability for malware to be detect, be detected for platforms that are only looking at signatures because we're out of Bandu. We could spend a lot more time interrogating the observations we see, we do chase down, you know, in quite a deeper way, malware vulnerabilities. We do very unique things here as well. We'll roll up. We will roll up a bunch of discreet CVEs into, you know, one action.

You know, if you upgrade this version of Tomcat, for example, you'll, you'll handle these 70 CVEs right, again, in an effort to take some burden off the shoulders of that security professional, and just give them, Hey, you know, here's the low hanging fruit. If you get this done, you'll make the biggest difference to your risk posture. You'll find very CSP type of tests in Orca, you know, S3 buckets, open to the world workloads with too much privilege, which is very topical for what we're talking about today. You'll find authentic authentication risks, both kind of at the cloud level. Right?

And, and it's important to note that cloud and workload observations there. There's not a lot of difference in OrCAD, they're all in the same stack.

You don't, they're not in different parts of the tool. Right. And that's very purposeful if you've got an IAM misconfiguration, not the cloud, or you've got a really weak password, that's been part of a, a, a, a breach leak before, right? Tho those two things both have to be discovered and, and both have to be presented for you in almost the same way, sensitive data at risk, right? Maybe you've got potential PII in an openness three bucket, you know, as an object in an open S three bucket, Oracle we'll find that and alert you and then a lateral movement risk as well, right.

As we think about the ability to, to land and then for a bad actor to figure out how to move closer to their, their goal, we wanna minimize those, those possibilities in orcas. Great at that as well. And so just before I, I, I let you go and we get back to Mike for some Q and a, the last thing I'll say is that Orca, you know, the data in Orca is yours.

And so from a, from very early on, I've been with Orca for just about two years now, even when I joined, we had a, a really, really healthy library of integrations because we do believe that, you know, we, we come to the cloud to not necessarily reinvent the wheel, right.

And so we may have great security tools, but part of that security ecosystem is usually, you know, a SIM is usually a single sign on strategy is more and more becoming kind of, sort of chat op strategies, you know, piping alerts into a channel in slack, for example, or routing exactly who does what with them in kind of a workflow tool like PagerDuty. This slide in fact needs a little bit of a, of an update we've got, we've got about three or four new integrations.

So that's always, top of mind for us is, you know, how does Orca fit into your workflow rather than having to define a new workflow to use Orca? And that's all, Thank you very much. Indeed.

Patrick, that's really good. So I'm now I hope showing my screen again, but I believe that we're going to see the results of the polls. So we can now see that 40% of the respondents were using AWS and 60% were using Azure. That's interesting in itself. And how concerned are you?

Well, everybody was concerned to some extent 40% were very concerned and 60% were concerned. Nobody was unconcerned. So clearly there is a problem. And now how satisfied are you?

Well, nobody was very satisfied and nobody was not at all satisfied. And it was a split between people being satisfied and somewhat satisfied. So it looks like nearly everybody feels they have some way to go, Right? So that's pretty much, I think the way that we certainly, I see the situation in terms of, in terms of the contact we have with, with people. So now we have questions and answers and at the moment I don't actually see any questions from the, the audience.

Just to remind you, if you want to ask a question, if you've got something you'd like to ask, please, will you use the Q and a panel that you should see in the control panel on your thing? So well, since there are no questions, let me ask Patrick a couple of questions. Now you mentioned the importance of contextual alerts. So that's a, a very interesting problem because you, you know, this is the real problem.

You, you get all of these alerts, how do you know, which is important to which person and to which stakeholder you have to do to, to decide what to do things about. So how do you deal with that? How do you define that?

Yeah, you're right. There's sort of two, two sides to your statement.

One is, you know, how do we make sense of this endless flow of information from these tools, right? And then how do we get it to the right people to do the right thing? And I think, yeah, we, we absolutely took the approach that, you know, winning by number of alerts isn't winning at all.

You know, I think when you read the statistics on how SOC Analyst feel about, you know, the alert flow and, and how much trust remains in that alert flow, you know, we, we know the, as we talk about breaches, the target breach of 2013, I guess, was, was discovered the malware that was leveraged to do that was known. It was alerted on, but, you know, no one had confidence in that alert stack because it was, it was, so it was so full of false positives, right? And so we, we took that to really mean that the, the, the risking needed an overhaul.

And the way we do it is by context, that often means what's around the observation, but it can also mean, you know, is there a fix available for it? What is the, you know, what are the external sort of known vectors of attack for a vulnerability, for example, is it being talked about in the media? Is it top of mind right now, for example, is it hot? These are all, this is all weight that goes into an observation in Orca.

And then to your point, once we've got that down to maybe a, a, a, a far more manageable number of, of alerts that are gonna make the biggest difference, then you need the ability to get them to your point to the right people, right? If, if you're, if you're an SMB and you've got one team, that's one thing. But if you're an enterprise, you know, sort of segregated by project team or business unit, these alerts might go to one team who's really mature using a mature tool, set. Some other alerts might have to go to a different team.

Who's still using, you know, spreadsheet governance, they're just getting started. And so there's, there is absolutely that ability to say, you know, I, I, I need this alert stream to be consumed and this way through this integration, and I need this alert stream to be kind of handled in a very different way.

That's, you know, it's, it's, it's part of our, our journey too. We're, we're still young, you know, we're, we're about three years old, but, you know, we've built a lot more of that enterprise kind of, you know, message bus capability into the product lately as well. Okay. Thank you. Thank you.

So, in, in what you were saying, there, there's a whole number of points that are really interesting. So you, you, at the end, you were talking about spreadsheet governance and in a sense, this is, well, I've got this list of controls, so everything's fine, as long as my control's there and it's operational, but in fact, then you have the poor guys that are actually trying to develop this stuff. And at the same time, you've got this tidal wave of new threats and new vulnerabilities that you described as being hot.

And so, but on the other hand, many of the hot things may actually be based on well known and tried and trusted vulnerabilities that people keep forgetting about. So it it's a really complex area. So how do you advise people about the way to deal with triangulating all of those three, three things together? Yeah. Yeah.

And, and it's compounded by the fact that when you first adopt public cloud, it there's an illusion that, that spreadsheet governance is almost working because you're just doing the same things you did in the data center, right. You're preventing virtual machines, you're provisioning base networks. And not a lot of them, you're doing it by hand.

And so, you know, for, for a project team, who's maybe pretty immature with a, with a cloud skillset that sort of seems like it's working, but as you begin to understand the cloud better and make use of these far more dynamic features, right. We know that, for example, we used to think that IP address was the sort of bastion of identity.

Well, we know now that that's certainly never the case, right? IP addresses get recycled and reused from not just resource to resource, but even type of resource. Right? No IP address in, in, in, in AWS is actually mine as a customer. It can kind of be released back. So just that very basic assumption, you know, kind of breaks down. How often do we see in the spreadsheet governance, right. Identity by IP address and, and just that basic assumption kind of no longer works.

It can work on day one, but I think as you begin to start to frankly, use the features we, that temped us there in the first place, right. It quickly gets out of hand. And so that's, that's kind of the other part of, of what we do at Orca is this compliance engine that's always on, you may not be interested in compliance, but the day you are you'll realize that orcas kind of been charting your compliance journey through about 40 different standards since the day you started, which is a great, you know, a great advantage. Yeah.

So what, what you just described there is, is the challenge that organizations face with this list, this long list of vulnerabilities, and this long list of compliance requirements, just keeping up to date is, is, is a challenge. So in a sense, how, how, how, how up to date do you manage to keep Orca and how do you manage this and, and so forth, because all these standards are constantly being updated and the vulnerabilities are being updated. That's right. Yeah. That's right.

So, yeah, I mean this year, especially Orca had a giant push on compliance, right? So we had, you know, we had a handful of compliance standards, definitely the, the big ones. And that's really been built out across the, you know, the, the workload level, the application level.

You think, not all of us are aware that there are compliance standards, even at the application level, you know, how do I configure my, my Apache web server from a best practices perspective, for example, we support that. And then your cloud level compliance as well.

So a big, a big push there for us though, you know, we think that great compliance leads to what most of us are at least thinking about. And that is kind of auto remediation.

How do we, at least for a class of problems that are fairly, let's say binary kind of, yes, no, this should be this way or this way, you know, a lot of us are thinking about how do we, how do we do automatic remediation for these kinds of problems? We are thinking about that too. But for us, it started with, you know, great compliance. And then how do I write a compliance test? For example, that's really specific to my environment.

Here's a good example in any compliance standard, you'll see, you know, make sure there are no publicly accessible storage buckets, which is a great rule until I have one intentionally, right. I may have, my website may run out of a AWSs three bucket on purpose. It's set to be publicly readable on purpose.

Well, if I'm thinking about auto remediation, any compliance standard would see that would flag it and would close it for me effectively, right. Disabling my app.

So for us, it started at this let's think about how we can allow an Orca customer to write a compliance rule or edit one that already exists, you know, that maybe takes into account a tagging standard where these resources exist, such that I can be really confident that I'm not going to have false positives in the end. Right.

That's, that's where we've been thinking. And we've been spending a lot of time this year, especially. Yeah. And I think, I think that's a very important point. You've been raising there that as you say, it, it's the exceptions that sort of prove the rule.

If, if, if you will, because you can, you can set up the standards, but it's understanding where it is that is valid and understanding and being sure that that risk is accepted and being properly, properly managed. And, you know, in a, in a sense, this is ultimately down to the risk appetite of the people that are running the, the systems, because they may choose not to, to do this now.

So do you feel that organizations have fully recognized what they need to do when they are, if you will shifting left as you put it, or do you, do you need to ask some extra questions and if so, what would those questions be? Oh, that's a great question. Yeah.

I, you know, I think it depends, we're, we're all software publishers now to some degree, right? Any, especially any enterprise organization as a software publisher, so where you are on that journey, probably predicates a little bit, you know, how serious you'll think about security and how far you'll think about shifting at left. But when we think about shifting security left, it can mean sort of on the extreme side, it can be measuring infrastructure as code. Right.

Which is kind of one of the ways we now think about design and provision of infrastructure is, you know, writing you put it well, you know, we think more about templates now than we do kind of sing at a console, banging out individual operations because of the repeatability of that. And so, you know, on the, on the far shift left side, we have let's judge infrastructure as code. And then on the, on the less far shift left side, we have, I've got some containers that are in development, sitting at a registry. I've got some VMs that are now I've got sort of built as images.

Let's, let's look at those just before I push them to production. Let's judge those, make sure I didn't incorporate any old software with risks. Right. Let's do that just before I push it sort of to production and everything in between. So I think, you know, how far you shift left kind of depends a little bit on your software development life cycle maturity, as it stands.

And of course your security maturity, if you're not taking security really seriously in production, you're probably not that interested in pushing it that far left, but I think it's mostly for that enterprise that does this all the time. That realizes, Hey, if we fail a build because of security at the very end, we've invested so much time in this process that, you know, it's a massive waste. So it's them, I think that are pushing to get it as far left as we can. And there it's, it's a lot more complicated.

The platforms that judge infrastructure is code are far, far less mature, but, but, but what's coming along for sure. We're getting there. Yes.

And again, all of this comes back to understanding risk and who, who in the organization understands risk and, and the extent to which you believe that the DevOps teams, I mean, they are often, shall we say condemned as not being interested in security? Do you feel that is a fair assessment or, or, or is it, is it some other factor that leads to the problems that arise from this new way of doing things?

No, I, I mean, I think, I think they're not interested in the litany of observations and alerts. They get thrown at them. Right.

I think, I think there's two things. There's, if we're flooding security professionals with information, how could we not be flooding developers with information, right.

And, and they're not poised at all to be able to deal with it. So there's two things. One is right when we, when we step on their process and we introduce lag by, Hey, you have to install this thing, or you have to use this sanctioned image with my, my agent already installed. These are your two options.

If, if what you wanna do is outside those, you can't do it anymore. Right? So I think in that way, security professionals are very, or, or developers are very sick with security because we, you know, we create this very narrow path that you have to March, and they're tasked with doing things, you know, different from, from time to time.

And, and, and they need that flexibility. The other thing then again, is once we judge them from a security perspective, you know, we have to find a way to get them the information that matters, but not get them the information that doesn't, you know, how, I don't know what they're expected to do.

You know, if we send them a hundred alerts about every piece of software on that machine, right. What we have to know is what's it gonna be used for, is it going to be, oh, somewhat external? Is it going to be nice and private tucked in the network? Those are all important. That's all important information. We need to risk those alerts.

You know, if it's being tucked nice, away, deep in the environment we're gonna have, we're gonna place a lot less severity on, on, you know, software. We find that is somewhat exploitable, but maybe not remotely, for example.

So again, I think context help us with the second problem of just not overwhelming those developers who are already not well poised to deal with security observations. Thank you.

Well, we're coming to the end now. So I don't know if you've got some kind of final things you'd like to say, Patrick, perhaps about an event or an experience with a customer, which you feel you'd like to share with us about Orca.

No, I think, you know, I, I really appreciated our, our time together. Mike, I love the stage setting you did. And then my ability to sort of just talk about how Orca maybe hits those, hit those points. I think we'd love to have that sort of opportunity to, to, to really work with anyone. Typically what we do is, you know, get, get you to point Orca at your environment, sort of see what it sees and talk through those observations. They're always a lot different than any other tool you use, right? All the same information's there.

But to, to the point of what we've been talking about all day today, it's it, it's, it's a very kind of different experience that, that takes a, maybe a, a, a, a different perspective. But I think once people see it, they're, they're, they're really, really enthused by two things.

One is, you know, the, the coverage aspect, just how, how Orca does know about everything you debut in your account, really, without any code to install at all. It's a different way of thinking about it. If you come from a, you know, every mature, I think organization that leverages cloud has a cloud security posture manager, right. And those tools, you know, I think about those as kind of generation one tools.

I was involved with the creation of one of those two, which was really exciting, but what we're doing at Orca, I think about is kind of the, the next generation, the fidelity is a lot different and kind of what you can do with that. Information's a lot different. So I'd love to love the opportunity to really work with, with anyone that's listening today. Okay.

Well, thank you very much, Patrick, for your splendid presentation, and thank you very much to the audience for your participation. And with that, I'm going to say, thank you very much to everyone and finish the webinar.

Goodbye, Patrick. Thank you.

Like this?

Don't like this?

Why don't you like this?

Managing Risk in Ever-Changing As-a-Service Environments