Oxeye: Cloud-Native Application Security Testing

Mike Matchett: [00:00:00] Hi, Mike Matchett with Small World Big Data. We are here today talking about Kubernetes and securing our new cloud apps, it's a brave new world. We can't simply do the same kinds of security testing we did to our monolithic apps or even our virtualized apps that we do in a containerized world. In fact, there could be a whole new world of hacks out there that we don't even know how to look at right now. There is a lot of vulnerability and we need some new technologies. So we've got Dean Agron, who's the CEO and co-founder of Oxeye here today. Welcome, Dean.

Dean Agron: [00:00:32] Thank you, Mike. Glad to be here.

Mike Matchett: [00:00:34] So you and your other co-founder looked at, you know, Kubernetes and containerization and said, there's a better thing we need to be doing. There's something new we need to be doing in cloud and cloud native applications for security just in a broad brush. What did you guys? How did you guys get to your vision?

Dean Agron: [00:00:52] So I would say that when me and Ryan, we both arrived from that web application landscape and from the cloud security landscape. So when we looked on these two vectors, we see that first, the world is shifting from monolithic applications to cloud native applications from a big chunk of code on a server to multiple code components on top of containers. Everything orchestrated on a hybrid cloud environments public or private cloud. In addition, we see that because of the development phase and the edge and the era of the era of the desert with the world is shifting that developers are getting more and more ownership over security. So this drove us to look into the application security testing landscape and find out how these tools are overcoming the challenges imposed by the architecture of cloud native.

Mike Matchett: [00:01:44] And so when you when you looked at the cloud native and things have to change. I mean, we're talking about the fact that in a in a containerized service, there's multiple levels of things when when a when an API call comes into an application, it can root to any number of sub microservices and causes cascading chain of application flow. That's that's very complex. It might be quite dynamic. How can you possibly look through that?

Dean Agron: [00:02:09] So that's exactly why Oxeye is built for cloud. Native is a component inside the environment. We inject visibility into the application security testing landscape. We scan the microservices. We then follow and find what we call the vulnerable flows to actually track these multi-service vulnerabilities. Because remember, in the past, a vulnerability was started and ended when the same piece of code today, like you said, it stretches on multiple microservices. It starts on the API service to message you other services to the vulnerable one. Now you need to see the whole flow to understand the severity, and that's in addition to understanding the different infrastructure layers. Because if the container is configured in one way, then the severity is higher, and if it's configured in a different way, the severity is lower. So at Oxeye what we are doing. We are providing contextual risk assessment to identify and resolve the critical vulnerabilities which are exploitable.

Mike Matchett: [00:03:19] All right, so walk me through this. Let's just take something that most people probably have heard about, and that's like a SQL injection. Try and do some remote code execution here. And if I go to a monolithic app or, you know, my old rails apps and I do remote code execution, I can look at, you know, pretty easily what happens from where the API endpoint is in the code to the database. And if I say pretty easily, lots of people miss SQL injection even in that environment. But if I'm looking for it and doing the testing in the code scanning, I could probably find it and feel something. If I go to a containerized set of code where lots of people may have contributed lots of different microservices. I'm not really going to be able to do that as a developer without a lot of help. So what are you guys? What do you guys particularly do in that case?

Dean Agron: [00:04:02] So first, we understand whether there are potential vulnerabilities if there are SQL injection or cross-site scripting or remote code execution, potential vulnerabilities in the specific microservices. Then we leverage open telemetry to actually understand the application flows that leads to the applications that lead to these vulnerabilities to allow us at the last phase to actually create malicious payload to validate these vulnerabilities.

Mike Matchett: [00:04:33] Because you're you're creating a malicious injection to to to actually intentionally try to break it after you found the vulnerability.

Dean Agron: [00:04:41] That's correct. And not only that, but I don't expect I don't do the analysis based on the response, but I'm leveraging cloud native capabilities to actually set the hook on the sequel function. So I inject the malicious text on the one end and I see how it arrived to the Malicis function. And if it is, if it arrived the same as I injected it. There is no sanitation and we know for sure that that's a vulnerability. On the other hand, if the input was sanitized was dropped, then I know that this may be a potential vulnerability, but somewhere along the road, it's being sanitized and a mitigated. So there is no real vulnerability.

Mike Matchett: [00:05:26] All right. And so if there is a vulnerability you integrate into, I assume all the DevOps tools along the line and and give the developers some information. What does a developer get to try to address this?

Dean Agron: [00:05:38] So Oxeye would provide the developer a very clear remediation guidance because for cloud native apps, we provide them what they used to receive from static dynamic and interactive tools. We will provide the developers, first of all, these tactics, the specific line in the code where the vulnerability resides. In addition, we will provide the steps to reproduce what is the malicious payload and where is the entry point that we injected it in to to be able to reproduce like in every other issue. The last thing is the visibility, what the application flow actually looked like because the fix may be in a different microservices than where the vulnerabilities. Now on top of that, we also provide we enrich the vulnerabilities and the data that we provide the developers with their configuration layers, the infrastructure configuration layers because the the solution may be in the container itself. Maybe if changing the configuration of the container may a lower the severity of the vulnerability. So they will see that also both as parameter for the. Isn't that the vulnerability and it also may be a way to pave way for resolution,

Mike Matchett: [00:06:51] So as developers become dev ops and take on operational responsibilities, we know lately they're also taking on security responsibilities to becoming sick dev ops and write these. The words just keeps getting longer as to what one person needs to do. So this sounds like a great way to really give them all the information they're going to need to narrow in on the problem because you're doing the static analysis, he said. The dynamic analysis of where the flow is going and even the the interactive look at what's what's actually happened with the particular injection. So that's pretty cool. Does this does this scale well? How does someone automate this or is this kind of a set up an environment and take a long time to do the lab test?

Dean Agron: [00:07:29] It's one line of installation. It's a help chart with SQL apply. It is installed once the container, the Oxeye, we call it the Arcserve observer. Once it is deployed within the environment, it can be any testing, environment or production. Once it is there, which we automatically adjust. According to the changes, there's no need to do any changes in the environment because once it is there and a new process, a rise or an impressive start, Arcserve will automatically detect that we will scale that process and we run all the tests on that process and the environment it is a part of. So it's one line of installation, no code changes. And and from that point forward, it's all to adjust to the environment changes.

Mike Matchett: [00:08:17] All right. So I'm not instrumenting 10000 microservice YAML files or anything like that. I'm just putting one line of code in there and getting getting all that. That sounds pretty cool. And when when you're doing this, you're able to find, I assume, more vulnerabilities than any one particular way of attacking because you're doing all three at once. Have you found that to be the case?

Dean Agron: [00:08:44] So I think we are we are changing the way or we're seeing vulnerabilities differently than what it was. What legacy to see that because we see them as either multi service or multi layer like think of a remote code execution, for example, if a remote code execution ends at the container, it's one thing. But if the container is sharing a namespace with the host, then it's a remote code execution on the host, which is which is much more severe. Now, our research team is setting these combined types of vulnerabilities because this is these are the new types of vulnerabilities. You still have the single injection, the remote code, the remote site, a remote code execution. But think about it, in the past it was it was defined as a low severity vulnerability. But today, on cloud native environment, you can leverage such a vulnerability to actually fetch database credentials and elevate your permissions. So the severity of such a vulnerability is much higher, and I think that's what we introduced the contextual risk analysis.

Mike Matchett: [00:10:03] And I think, as you know, as containerized environments get bigger and bigger and take on more and more functions for business, you know, if they fail security wise, you know, the risk is that someone can access a wider swath of what the company does and a wider swath of their data. And it's not just limited to the one application that was penetrated anymore. All right. That's that's part of being cloud native. Services gets shared, right? Very cool. So this sounds like something that's pretty much going to become, you know, part of best practice, right? People have to do security testing and Kubernetes. They should be doing the best thing they possible for their business apps. And I think there's just fascinating stuff. If if people are interested in looking at Oxeye and what you're doing and maybe maybe trying it out, what would you have them do? What would you recommend?

Dean Agron: [00:10:49] So first, I would recommend them to either go. Follow us on LinkedIn to look at our Twitter page or to or to browse to other side audio and stay tuned for the upcoming news from Oxeye Oxeye.

Mike Matchett: [00:11:04] I io folks, not Oxeye. Anything else? Keep that in mind. Well, thank you, Dean. So much for being here. I appreciate it.

Dean Agron: [00:11:12] Thank you very much, Mike.

Mike Matchett: [00:11:14] And you know, folks, if you've got a Kubernetes environment, you're starting to kick the tires on cloud native or even got a big environment and you don't feel that's been secured properly. This is a technology you need to keep. Keep an eye on on axion. Get it all right. Take care, guys.