The Key to Cloud-Native Security: Understanding the Nature of Vulnerabilities at Cloud Native Now 2024

Hi, my name's Larry Ma and I'm here today to talk to you in the context of Cloud Native about the definition of a vulnerability and the implications of that definition. And it's really important that you define what a vulnerability is because you can't defeat it if you can't define it. And, and that, and, and I think, uh, I've got a, a sort of a interesting way of defining a vulnerability that's very different than what you've probably heard before, but much more actionable than what you've heard before.

But before I get into that too much, I, I wanna give you a little bit of my background, let you know where I'm coming from. I'm currently a DevSecOps transformation lead at Contrast Security. I have a deep cybersecurity and software engineering background, but there's a couple of things on my, uh, sort of resume that I think you would benefit the most from, from knowing about.

First of all, I was the head of application security for Comcast for five years, 10,000 of members of the development teams, 600 different development teams, every possible tech stack and level of process maturity you can imagine. And over the course of those five years, I converted from a traditional gatekeeping oriented AppSec program to a much more developer centric program. And part of the reason I was able to do that was for the second reason thing.

Uh, the thing I'd like you to know about me, and that is that I'm an active developer. I write code almost every day. I'm the primary author of a dozen open source projects, one of which gets a million downloads a month.

I run that project the way I recommend, uh, large enterprises run every project. And so I'm not just preaching, I'm practicing what I preach. So I'm gonna start off with a generic definition of what a, what a vulnerability is.

And, and this is very similar to the one we used when I was at the Software Engineering Institute at Carnegie Mellon and launched the S lab and the build security and initiatives. There. It, it's not exactly the same words, and that changed over time.

So I'm not too worried about that, but I, I, I think it's accurate to say that it's a defect that allows the compromise of the confide confidentiality or integrity of the data or the availability of intended functionality, useful functionality. So, uh, for those of you who sort of steeped in the, in the world of security, the c uh, in confidentiality, the I and integrity in the A and availability, CIA is sort of the acronym, but sort of like what all security is. And, and so it, uh, the only thing additional in this definition is that it's a defect in software essentially, that enables a bad guy, a bad actor, to, to actually accomplish C or I or a here.

Um, so it is accurate and it is broad enough to sort of capture just about everything you can imagine in, uh, in terms of the vulnerability. Um, but it, I, I argue it's actually not the most actionable or useful model for a vulnerability. You know, a defect is really broad.

You know, software doesn't behave as intended. It, it is just a very, it is a very broad sort of thing, not very actionable. Um, so I, I also argue, uh, you know, that all models are wrong in some way, shape, or form, but some models are useful.

What if we could identify a narrower definition, maybe that doesn't cover every possible kind of vulnerability, but that as much more actionable for the most serious ones. And, and that's really what I'm gonna target here today is a, is a more actionable definition. Um, so I'm gonna focus this definition on what I call gnarly vulnerabilities.

And gnarly is, is along two dimensions. The first dimension is, is how difficult they are to detect. And, and the second dimension is how painful they are when they're exploited.

And so how, how, how bad is it when they get exploited? And so, so the, i I call that gnarly just to, to, to that. Now, it's not all def all all vulnerabilities.

The definition I'm gonna give you here in a second is it doesn't apply to embedded secrets, for instance. Um, but it apply, it applies to all of those sort of like the top 10 kind of things. You think of, uh, maybe nine of the top 10 and or 80 to 90% of the sands top 25.

And the definition gives you the ability to sort of act on it much more, uh, more effectively than this sort of generic definition. I'm gonna, I'm gonna get a little technical here and then, and then I'll get a little more abstract, and I'll go back to being a little more technical here. So I'm gonna talk about this concept of data flow, how data flows through your application.

And so let's, let's define sort of where the data comes into the application. Let's call that the source. So, uh, it can be an input field on an on a screen.

It can be an API parameter. There's lots of ways for, it can be a message bus, uh, channel. It can be, there's lots of ways data can get into your application, but we'll just generically call that the source of the data.

And then there is a sync source sync, both begin with s that's sort of intentional. Um, and you'll see why in a second here, source sync. Uh, the sink is where the data ends up going to, it's the dangerous destination.

So, um, that it, that it goes to. Now, if the data comes from an untrusted source, like a user input or API parameter and gets to a dangerous sync like an SQL statement or a command spawn or whatever, um, you have a, a remote code execution or injection kind of attack, and it's vulnerable. And so that is the sort of this simplest definition of, of, of a vulnerability.

Um, I'm gonna introduce another concept here. The idea of taint. So the, the data is said to be tainted between this source and this sink.

And if it gets all the way to the sink and stays tainted, then it is a vulnerability. You could at some point though, uh, after the data comes in, but before it gets to this dangerous sink, you could sanitize the data and then it would go from tainted to untainted. And this would not be a vulnerability that, so in order for a tool like a SaaS tool or an IS tool to know whether the code you write, uh, or a library code is vulnerable, uh, if it's looking at the source code library code, you could look up the known vulnerabilities in the database for, for, for third party libraries also.

But in order to find new vulnerabilities, even in libraries, or to find vulnerabilities in your code, the tool needs to understand exactly how data flows through your application. And data flow analysis is, is, is is the most complicated and difficult part of doing vulnerability detection with tools. And, and so the, and the reason for this, um, I, I'll get to in the next slide, but just before I move on to that, let me give you the, the, the summary of the definition.

A vulnerability is, uh, data that comes from an untrusted source and gets to a dangerous sink without proper sanitization. Now, again, this is not a generic definition that covers all kinds of vulnerabilities. It covers the 80 to 90% of the most gnarly ones.

The ones you see on the OS top 10, or most of the ones you see on the S top 10 are stands top 25. Um, so it's not quite as simple as the diagrams on that last page though. So you have these things called propagators.

And so you have statements in your code that will reassign, uh, a variable, and that came from an untrusted source. Sue another variable name or maybe aggregate to two variables into one, a concatenate, two strings together, for instance, and assign it to something else. Um, uh, you can, you can have all sorts of different kinds of operations.

You do, uh, use a filter, um, function on, on, on something. So, so lots of different things can happen. And at each point after the propagator, the data might look slightly different, and at some point it might look different enough that you sort of claim it's sanitized, so you understand how it's getting comp more complicated to try to figure this out.

But this is even just a linear flow through your application where it's just assignments and single command kind of filtering kind of things I've mentioned so far. There are other kinds of propagators that are linear where there's one place to come in and one place to go out, but programs aren't like that. And, and this is almost never the case that it's even this simple.

You know, this is probably even simple for the average route in a, in a, um, in a typical API, uh, endpoint, it, you know, there's, there's if statements. And so when an if statement happens, you, you know, the data will look differently on one side of the if statement, if it go, comes out, uh, with the if statement being true versus comes out with it being false. And so then now you have to essentially split the state space, and you have to essentially now symbolically execute, follow the data flow through the rest of the program with those two different conditions.

Well, every time there's a loop, it creates another condition, and you essentially have to copy all of the state information over to an alternate reality at, at each time through the loop, or each if statement or each case statement. Um, and this very quickly gets out of hand and, and unmanageable and, and very difficult to deal with. Um, so SAS tools in particular suffer from this thing called state space explosion.

Um, so the way I like to explain state space explosion is with the metaphor of the movie or, you know, superhero concept of the metaverse, not the, not the, the, the, the, the, the meta Facebook definition of the metaverse. But this concept that every decision, every flutter of the butterfly's wing sort of creates a new alternate reality. And, and some realities are probabilistically more likely than others, and some are, are just so similar to the, to the other ones that it's hard to tell them apart except in the details maybe.

Um, but they're completely separate, alternate, parallel universes. And basically that's exactly what's happening. When a SaaS tool goes through and looks at, uh, a single endpoint and an API, they have to create complete copies of reality for every time through a loop or every if statement.

And you get to this state space explosion, it takes a long time to explore all of those possible state spaces. Basically, you have to sort of roll the movie forward from that point on every version of the alternate universe. And so SaaS tools are constantly making this trade-off decision between speed and accuracy.

So rather than explore the, the, the breadth of all possible ways that this could move forward in the future, what if you were to say, well, these three are so similar, I'm gonna statistically merge them and, and using, using proba probability that they're likely not to be different. If it's vulnerable, then, uh, it's vulnerable. If it's not vulnerable, it's not vulnerable.

And everything in that bucket of these three or these 300 or these 300,000 alternate realities is roughly the same outcome. Now that's approximation, essentially. And so you're simplifying reality, and, and every time you make one of these approximations, you are injecting the possibility of error.

So, you know, SAS tools create a data flow model. All models are wrong. Some models are useful, their data flow model is wrong.

SAS tools, data flow models are wrong in that they actually can be incorrect. They can say that this is not vulnerable when it actually is vulnerable or vice versa. They can say it's, it's vulnerable when it's actually not vulnerable.

Um, and so, so the, so that's where all the inaccuracy comes from. The very best SaaS tools on the market get this right about 70% of the time. And the, the sort of the typical ones are the 50% accurate sort of sort of range.

That means that 50% to 30, 30% to 50% of your results are wrong. You know, they're not saying correctly whether it's a vulnerability or not. And so that's sort of the big downside to, to SaaS tools.

This concept of state space explosion makes, um, the use of SaaS tools to identify vulnerabilities a little bit painful because you end up wasting time on that. Um, 30 to 50% that are not actually vulnerabilities. Um, false positives, we call those.

Or you end up in this situation where you have false negatives, where it is vulnerable, but we said it was not. And that means you have more risk and, and you give the, the check of approval when you really shouldn't have given the check of approval to that. So what if there was a better way than how SAS works in doing data flow modeling, data flow analysis?

So we're getting a little meta, meta meta now because I, I was talking about models and, uh, and the model is the definition of the vulnerability. And now I'm actually talking about the model, the data flow model. So we got models all over the place here.

So, but what if we had a better way of doing data flow modeling? So, um, there's another category of tools, um, usually referred to as I asked tools or runtime security tools that don't try to look at your source code to reverse engineer how data might flow through that application. Rather, they cheat, they observe the actual data as it flows through the application.

So they, they've, they've tagged every untrusted source in every sort of standard library and every system call. And they know that if it came in via the one of these things, it's an untrusted source, it's tainted. And they've, I, I, you know, tagged every destination library like that, uh, SQL libraries or IM libraries or system libraries that sort of allow you to spawn a command, et cetera, any possible dangerous destination, dangerous sync.

Um, and so they know when data comes in and they add a sentinel to it, and the sentinel doesn't just sort of track that data all the way through the system, it'll actually sort of observe what the state changes. When you have a propagator that changes, it concatenates two things together, it observes that. And so, so, so this approach to data flow modeling is never wrong because it's observing actual data flow.

It can however be incomplete. So if you don't exercise the application enough, it won't have explored enough possible data flows through your system and it could possibly miss something. So is tools, um, with low, if you are using an IS tool and you have low coverage metrics, meaning you haven't exercised the app with a, a functional automated test suite enough, you know, a hundred percent test coverage test suite is not necessary to get to, to much better than SaaS tools can.

But, but a maybe a 60% test coverage suite is necessary to sort of exceed the very best SaaS tools on true positives. Uh, but it's gonna blow it away on false positives because it's essentially impossible to have a false positive for these types of vulnerabilities in, in an IAS tool because the data flow is never wrong. And that's where all the accuracy comes from.

SaaS tools sort of analyzing, uh, the, an application application code, API code, et cetera. So now we're gonna get technical again here. So let's, we do a concrete example looking at code for SQL injection and, and, uh, I'm making this superlative claim at the top here.

Let's solve SQL injection forever. So this code up here, lines 2 0 9 through 212 is the code that, uh, uh, uh, user would've a developer would've written. Um, and it's calling this my SQL connection, um, locally scoped connection.

It's calling, it's calling this, um, uh, uh, execute query. Uh, the, their code is calling this execute query code. And that then, then, you know, calls down into the, the MySQL code.

So at the beginning of this execute query command, what if we modified the code? What if we essentially wrapped the execute query function with some checks? So this is just the sync, this is not the source, but we've done the data flow analysis prior to this point.

So we know any, if the data that's coming in here, this, this SQL string that's coming in here is tainted or not, and exactly how it's tainted because we actually have observed the, the nature of the value from, from, uh, uh, as it's flowed through the, the system. And, and so we know that, and if we get to this point and it is tainted, we call into, into, into a code that we've injected as well. The, what call it the trust engine.

So we're wrapping this dangerous function, this execute SQL query in, in a trust boundary. And the trust boundary's gonna do three things, maybe even four. I don't, I'm gonna show you three here, and I may describe the fourth year.

First of all, it knows which s MySQL library you're using, so it can look that up and to see if there's a publicly reported vulnerability on it. It can do essentially what an, uh, SCA tool can do, but it, it, it does one better than the average SCA tool because, uh, it knows whether or not the, uh, data actually got to this call. So the vast majority of the code in the libraries you import never gets used.

Uh, it's basically the libraries are big enough that they have lots of functionality and you only use 10% of it. And so if you never get to one of these dangerous things, you know, you, you, you, you're, you're, you're recording it as an s uh, an SCA vulnerability if all the SCA tool does is look to see if the library at all is important. This actually sees whether or not you using that part of the library to see whether or not it's, it it's vulnerable or not.

So that's, that's, that's sort of straightforward and doesn't even require the data flow analysis prior to this point. Um, but we also know that if the data that came in was tainted, this, this query that came in that it, it, it's called with the, the sql, the parameter named SQL here, and it's the parameters named query here. But if query, if it looks it up and it traces it and it, and the trace says that it was, it was tainted, then we know this is a vulnerability.

It got all the way to an execute query statement. A dangerous syn, um, uh, tainted data got all the way here, uh, without being properly sanitized. 'cause it wouldn't have been tainted if it got, if it got to this point, um, uh, a after it had been through a sanitizer.

So we report that as a vulnerability. That's what SaaS tools do, uh, for the code you write. Um, and, um, so, uh, I work for Contrast.

I said, when I started, contrast is an IS tool, one example of, of a tool that works this way as opposed to the way SaaS tools work. And, uh, contrast does, does this, uh, exactly like this and gives this feedback to developers so that they can fix and remove the vulnerability. We take it one step further though.

And, and this is sort of, uh, bleeding out of the space of, uh, where SaaS tools and typically think of as is tools working more into the space where a web application file a WAF or a runtime application, self-protection tool, RAs tool is working. We can actually block requests. So if you're in a pre-product environment, you're gonna get these first two.

But if you install our product in a or any rasp tool in a pro production environment, we have to install it in order for it to block. Then it will not only detect that an attack is coming, it'll throw an error at this point. And so the attack won't succeed.

It won't actually finish the call to the, to theq execute SQL statement. And it'll never, it will never actually, it will never actually, uh, uh, result in an, in, in, in an exploit. So, um, the tagline for our product, one of them is that we can replace your SaaS tools, USEA tools and your das tools, and we can strengthen your waf and I, we say strengthen, not replace waf because WAFs are also doing things potentially like distributed denial service tax that that RASC won't, won't do, or, or, um, using, uh, the affinity of the providence of an IP address to sort of make some smart statistical decisions as to whether or not you're being attacked or not.

Um, and rasp tools just don't, just don't do that. Um, so, um, this is a, you know, a summary slide of, uh, uh, a essentially our product, we're taking a dangerous function, we're wrapping in, in this trust boundary, and we're doing, um, four things. I mentioned three of them in the code.

Um, we essentially, uh, replaced the need for, um, an SA SaaS tool or a das tool. With is capability. We replace the need for an SEA tool, um, with runtime based SEA, and we, um, will, uh, this is the one that isn't mentioned in the code.

We can actually sort of map where, which applications talk to what databases, and create what's called a security blueprint of your distributed system so that you can do things like pen testing more effectively and threat modeling more effectively. And then the last thing I mentioned is we can actually block attacks if you install us, uh, or, or any RAs tool in, in production. Um, so that's all I have for you today.

Uh, please, uh, reach out with questions, uh, or asking for more information. Connect with me on LinkedIn. You can send me a direct message on, on LinkedIn and I'll re reply there.

Or I'll set up a time and we can, uh, we can, we can talk more, more in depth. Thank you.