Software "Securibility" with Shannon Lietz

In coversation with Shannon Lietz, Director of Adversary management at Intuit Inc. We talk about Securibility and its increasing centrality to developer led application security programs.

We chat about two main pillars of securibility - exploitability and threat analysis with respect to an application. Shannon describes how a securibility metrics can help development teams achieve success for the goal of creating security software.

Alok Shukla, VP of Products at Shiftleft, anchors this conversation from the eyes of a real life security practioner and as a host of this podcast.

Transcript

Alok:   0:11
This is Alok your host and our guest is Shannon Lietz,  Director of Security at Intuit. We're going to discuss the topic of securibility  with Shannon. Welcome, Shannon.

Shannon:   0:23
Hi there. Thanks Alok, Nice to be here today. Um, as you know, I'm the director of adversary management at Intuit and that basically brings together the red team plus threat Intel and some of our newest capabilities, like adversary insights and securibility. So I'm really excited to be here with you today.

Alok:   0:45
Awesome. So, Shannon, what would be the two minute definition off securibility anchored in the context of application security?

Shannon:   0:55
Ah, that's a really good question. So, um, maybe I'll give a little bit of background context for a moment. Uh, you know, one of the things that I think the security industry has been working through for a long time. It's finding a security measure that works, and along the way, with devsecops, you have to solve for a maturity model and trying to bring things along and pulling together processes and really asking yourself, Is this solving for the next generation of security? One of the things we focused our efforts on with securibility and in the context of application security. Securibility is essentially a measure that helps us to identify what the most important things are that creates security resilience in our applications and software. Yeah, it's important to realize that, um, you know, we need this for a lot of different reasons.

Alok:   1:52
So do we have a formula that we can aspire for?

Shannon:   1:56
Yeah, actually, when I was one of the coolest things about working on securibility is trying to figure out a formula that resonates and actually brings to the forefront the problems. So our general just starting off with the actual equation, it's actually really simple. If you equate resilience, which is the thing you really want to get out of software to, um, the number one. It's basically binary. Is it yes or no? And then you subtract the exploit ability, which will be escapes over exploitable  opportunities. From that resilience you essentially get have you degraded your resilience, your security essentially, and then you multiply that by 100% to get to some number, that basically helps you to understand the percentage of all risk. Ah, and that essentially, that calculation helps you to get to what we call five nines measure because most of the time exploit ability is actually a micro problem. Like what most people see is that, uh, you know, security is degraded by Attackers in a variety of ways, right? But most of the time it's actually really small edge case, nuanced problems or mistakes that keep coming up that degrade that resilience. And when that happens, essentially its again a micro problem with a lot, lot of intensity from an adversary and scrutiny and enough time they'll find that defect, pick it apart and leverage it to do bad things with your environment in your software.

Alok:   3:34
So you said three intresting things, and I'm becoming in the context of application security. Uh, you have threats,  adversary, and you're going to measure that you have your application code by which you will measure, and you will apply some kind of analysis to measure the exploit ability of that, and you're basically trying to match the two that how much you are exploitable and based on. what kind of attacks you are seeing. Is that the broad context here? 

Shannon:   4:06
You know that's absolutely true. It's the broadest context we have. Um, one of the things to think about is in the formula, right? You're really trying to solve for ultimately understanding whether you've built secure enough software. Built security into your software, resolved all the problems of your edge cases and the mistakes that could possibly arise that would essentially give attacker an advantage.  

Shannon:   4:36
In game theory the way you think about this is, you know, it's always a zero sum game. They don't have anything to get if you didn't give it to them. So as you make risk tradeoffs in your software, whether be for speed or simplifying something because of complexity, challenges or even something super costly to do and see, you just don't see the benefit of doing it, you're essentially in giving away against those risks. You're actually creating opportunities for adversaries. And so you know, this calculation really brings to the forefront that ultimate goal of, um, building security. And I haven't equated also to making something that developers can use as a measure that simplifies it enough akin to sort of availability.  

Shannon:   5:31
So if you look at the availability challenges that the industry had when the Internet was first born, you know, it was quite common for things to fall over and stay down and cost lots of money. And over the many years we've gotten pretty good as an industry on availability. My belief is, you know, I've actually looked at data sets and there's basically around $4.5 billion availability Challenge is still in the industry. That's all next to the $600 billion that exists in the security challenges that plague the industry.

Alok:   6:02
Absolutely, so I want to kind of double click on some of the items you  said. So, and this was a very interesting point you made,  that if you have just by design a lot of exploit ability as exploitable opportunities, then some, someday your threat actor will figure that out and will go to that. So the good thing is to kind of reduce the exploitable opportunities. But how do you in as a practitioner, how will you figure out total exploitable opportunities? What tools a security practitioner  use to figure that out?

Shannon:   6:34
Ah, good question. So, you know, I think that one of the things that the security industry is just starting to figure out is This notion of bill of materials and a bill of materials is something that I think a lot of industries are trying to figure out because they're start starting to be regulation around having a bill of materials. It's similar to when you look at Toyota when they were trying to represent what it meant to build good, high quality products. Um, having that bill materials is where you start. So you know, some of the tools that might be out there - things like exonious are sharing the salt for one of the things that have to have security controls around them, looking at manifests and Github, maybe even using things like Snyk or some of those major players in this space. It is a super emerging part of the industry right now. So I would say figuring out your explicable opportunities is still something that I think a lot of people are trying to reconcile because when you basically get to the point where an equation does resonate and it really can help, um, the work that you do to really bring that to life, it's probably some of the most meaningful and most valuable work. Um I think it's absolutely an area that needs a lot more capability.

Alok:   7:57
Okay, so we start with bill of materials and then off course, the next step would be that you understand that how those bills of material of the code interact with each other. I mean, is it not important to understand your protocols and your business logic? Uh, does it improve the code visibility? I mean, if you understand business logic, code protocols more,  does it help you to understand the exploitable threats?

Shannon:   8:23
Yeah. You know, again, good question. Once you have the bill of materials, you know, it's really important to go through examining those materials. So if you look at the resource is that underlie that built their bill of materials, Essentially, your code, the protocols that you're riding into that code and some of the things that you might borrow say, libraries or borrowed code. They all need to be inspected, evaluated for mistakes, misconfigurations. Um uh, coding practice. So we know, for example, that there are a lot of different ways that input validation needs to be appropriate. And as part of that, um, you know, inspection there has to be both the right tools for that inspection against more precision so that we can put out better software. Uh, you know, it's not easy to write perfect software as you can imagine. And then if you're not trying to write perfect software, you're trying to provide resilient enough software. Really trying to figure out what your edge cases are and how you're gonna deal with those things is super important.

Alok:   9:37
So just like the last time, what the tools would you recommend? You have some tools that you will recommend for people to understand protocols, business logic if the practitioners are listening to it.

Shannon:   9:48
Yeah, it's a Iittle bit of trick question right, um, one of the one of the products that we do use is obviously shift left. And, uh, it helps us to go through our code using code graphing capabilities and protocols through, you know, the business logic running through those things. Additionally, when we look at things like misconfigurations and some of those areas, you know, we're leveraging things like the ability to do configuration checks in AWS for the stuff that is in infrastructure. Um, we're looking at all of the configurations from an outside in perspective. So we're actually scanning using things like nmap.  

Shannon:   10:30
We kind of built something called Raven that's got nmap on steroids, if you will. And, um, you know, inspecting outside and inside these tools help us to get more precision about what are the actual exploitable opportunities? What things will an adversary actually go after? And then once you have that data, you can actually go through the curation process of determining you know, what are the biggest threats that you have to resolve? And I think that also gives you a sense of, you know, are the things that you made decisions about in your software process. Um, something like you'll be okay with letting go to production or if you need to actually pull something back and make sure that it's actually resilient enough because, you know, most companies know that they get a lot of attacks on a daily basis for software, especially the things that are in the mobile world or the Web application world. That that can be a real challenge, right?

Alok:   11:24
Yes, absolutely. So we covered part of where you talked about exploitable opportunities, both from bill of material as well as from protocol perspective. Now, I will take your second part that you say is to match this with understanding your threat data. So how do you measure your threat data on how can practitioner do that? Again the same question. How can they? What kind of tools that they should use to generate insights about the threat data?

Shannon:   11:54
Yeah, that's a great question to0.  So threat Data comes in a variety of forms. From the front end of your company. You know, you're gonna have obvious opportunities that adversaries are going after. So you're gonna see things near logs as an example. A good place to pick that up is going to be in Splunk. And, you know, when we first got started, that was obvious place to start to look for signs of adversary interest, if you will. And over time, as we started working more and more in closer the code getting cloudy, getting more cloud proximity, you know some of the additional tools like real time application self protection is really important. And there's a variety of vendors that participate with RASP. Um and I think it's actually real time application self protection is what its termed, so people usually mix it in a variety of ways.  

Shannon:   12:48
Uh, those tools can help to identify where adversaries are trying things. It's almost like when you lock your door. Do you actually know if an adversary or or, uh, burglar is actually checking the lock every day? Not unless you're actually watching right. So when you move to the cloud, if you don't have the right telemetry, you'll never see what's actually trying to attack you. And there are different types of adversaries. The lucky versus the good, if you will. The luckier basically trying anything and they're doing the spray and pray. They've got tools and capabilities that if they light up, they caught one right. It's almost like fishing and good are actually doing some of that reconnaissance there, you know, stalking things and watching. And they're actually more advanced and how they go about finding an opportunity so that they could take advantage of it.

Alok:   13:41
That's pretty interesting. So as we wrap, we kind of connected the two sides. the from exploit ability and threat data. So just to repackage this. I think you talked about the formulae? Would you like to talk about the formula again once so that now people have understood the basic concept. Now they can bring all the data together.

Shannon:   14:05
Yeah, absolutely. So if we go back like I said, you're really equating your software resilience to essentially 100%. And you're trying to find out through the work of bringing your bill of materials together with the exploits and P. O. C's and actual attacks that could hit you and then essentially creates sort of the explicable opportunities. And then I think, you know, the equation is essentially your subtracting that exploit ability with the escapes that you find over the exploitable opportunities. Um, and you're essentially getting to a five nines measure that, um, is something that you can then test against your adversary information. So is five nines, you know what you need or, you know, do you need your product to be 100% because it's constantly attacked? Uh, that can help a developer to understand, in their environment, with the specificity of their environment, how to make better decisions.  

Shannon:   15:09
So, as an example, when they first start to write their software bringing it all together from the very early parts of the development and design pipeline, essentially shifting left this notion of what adversaries is my software going to encounter? And how do I essentially solve those problems before they become something that I'm gonna have to worry about? You really do have to understand how much adversary interest in my gonna have by posting a Web application out there. There's so much more telemetry than there's been, um, specifically because we are seeing those real time application self protection capabilities that provide some of this data. That suggests that when you post an application to the Internet's going to scan within only a felt few moments,  

Alok:   15:55
Yeah,

Alok:   15:55
no, absolutely. And I, and in your industry you would be, Your apps, for example, would be awful lot off interest. So without going in to a specific app, if I would. If you have a story for us to tell that where you basically have a real life example to demonstrate the power of secure ability

Shannon:   16:17
um, you know, it's a really good question. Uh, you know, we've implemented secure ability, and we've been measuring it for about a year and 1/2. Um, and it's really powerful because it helps you to decide on investment decisions. And, uh, one of the cool things I think is it's probably not just, you know, which products and stuff are we doing. Why are we doing with it? But imagine just putting something out there. That is, um, you know, a sandbox or some sort of application to study it, to see how often adversaries are actually going after it. What are the lucky things? So imagine. You know, some of the banks. What is it? The, uh vulnerable apps that are out there, Um, that you could pose. So some of the OWASP crowd has really cool little learning site, so you can put them out in the sandbox and see how they do. If you put the right telemetry on them, you can take back a whole bunch of information about the bill of materials. For that application, you can see adversary is hitting it. You can determine that the secure ability was pretty low for that application.  

Shannon:   17:25
And what really happens in real life is as a honey pot, you capture a whole bunch of telemetry about some of the things that really are concerning. Like as an example, cross site scripting. You know, how often will an adversary actually go after a cross site scripting issue? If it's super easy to scan for, the answer is it only takes moments for them to start trying. And then all of a sudden you see attempts being made against that application that are not good, right? So I would just say, You know, it's, uh, I always like to keep a little bit more of the information about where, specifically, we use some of this detail, the honeypot information. I think it's wildly impressive when it comes to secure ability because it's almost like putting a hypothesis out there with unknown outcome and seeing what happens that that's Ah, that was a real eye opener and one of the reasons why we think the measure is so valuable.

Alok:   18:25
So I think what you are kind of giving us a new metric where rather than folks doing vulnerability prioritisation on some internal looking measure, this kind of becomes more important that what kind of things you should fix more to get a higher, secure ability. Isn't it?.

Shannon:   18:42
That's right. That's right. Um, you know, I like CVSS. I like some of the measures that are out there that help you to figure out what things you should be worried about from a known perspective. But what secure ability gives you because CVSS is really for the security industry? Developers want something a little bit more simple, and they want something that they're acquainted to already. So having a five nines measure, it means that you can make security accessible for people who have already existing pipelines for measuring like this. And all we have to do is give them the appropriate data, tools and capabilities and essentially turn the list with the measure and then govern, you know, using that same measure with some of the tools in telemetry and controls. And now you have a really great you know, relationship between developer and security professional, um, such that both have a good way to participate together and bring the most value to software resiliency.

Alok:   19:44
That's awesome. Actually, Shannon, this was an awesome conversation. In that I mean, before I thank you for joining us. I mean, would you like to give the audience of this podcast an indication that when you're speaking next?

Shannon:   20:01
some of the things that I was planning on doing here on out have been moved to virtual conferences, and I'm participating in ONUG. Yet I think it's O N U G is a conference that's coming up and then I have a few other things that are on the horizon. And hopefully with the current situation it was hard to predict a pandemic in my travels. So I think you'll probably hear from me through more of the virtual conferences for the remaining part of the year. Um, hopefully by the fa;; will see more of this pandemic play out that I am hoping to see in the next couple of weeks that we'll have the ability to have more potential for in person conferences.

Alok:   20:46
Awesome! Thanks Shannon for joining me. And thanks for joining us for this episode of podcast.

Shannon:   20:52
Thank you.  

Alok:   20:53
Thank you.