Skip to content

Transcript: How To Build Resilient Business Applications

 

(Daphna) So before we begin, I just wanted to give our panelists an opportunity to introduce themselves. So we'll start with Lee.

(Lee) Sure. So I'm Lee Krause. I'm the CEO and President of Rampart AI. I have 30 years experience, in software development. In the last 10 years, we really focused on the cybersecurity problem. And when we approached it, we went to tackle the really hard problem tackling the problem of… can we prevent cyber events and increase the resiliency of software without rewriting the code and without any signature or known information about what we're protecting against. We consider that to be the real hard problem.

Zero-day types attack that will take your system down. And so that's really is the fundamental premise of Rampart AI is to ultimately allow us to protect against things that we don't know about. And I think that's pretty exciting.

(Sam) My name is Sam Curry. I'm the Chief Security officer of Cybereason by day and President of the Cybereason government entity. I'm also visiting fellow at the National Security Institute. I've been knocking around in cyber for longer than we've called it that 30 years as well. Doing a variety of roles and I just love everything about application security and I happened to be friends with the folks here, so I thought it'd be good to have a conversation together.

(Daphna) Perfect. And then we have Jacob here who's gonna be doing the demo at the end. I don't know if, Jacob, do you want to introduce yourself as well?

(Jacob) Uh, sure. So I'm the CPO of Rampart AI. I don't quite have the, uh, lengthy careers of the other folks on the panel, but I do have a lot of experience in the Cybersec domain and we've been working on a technology underpinning all this for about 10 years now. So what you're seeing today is kind of the fruition of 10 years worth of work and we hope you find it interesting and valuable.

(Daphna) Perfect. So if you haven't caught this yet, today we're talking about application resiliency. We believe the big question today is how can you better protect your application from bad actors? How past attacks are impacting the future of security and what we can do to secure applications. So let's dive in. Lee, let's start with you. What are the problems you are seeing today with our current security solutions that are not giving businesses the security needed to defend against bad actors?

(Lee) I think that's a really good question. So when I ripped that apart, I think that it's obvious that the solutions that exist today aren't solving the problem. I think if you look at Solar Winds or Log for J particular attacks, we can see that we had plenty of tools in place, but yet they provide, they created massive problems for the industry and so to me, It kind of shows that the current tool sets really aren't keeping pace with attackers and attacks of the future. I think that's just a really good indicator to think about. I also think when we look at it, is that, I view cyber security as a layered approach. That not just one tool is gonna solve the problem. It's a layered approach. And the area that we're most interested in right now is the application layer. And I think one of the things to think about is, that's really where a lot of your emergent threats are going to come from is from the applications themselves. And I'd like to just kind of turn around a quote that Hector had, which his quote was, What's the easiest way to break through a firewall? And the solution was have the firewall call you. Well, I think that's still very true for applications. What's the easiest way too, solve application issues is for the application to ultimately phone home and call you. So the problem, that malware exists within the application itself, and I think that's a real problem in the future. When we look at Solar Winds, you can immediately say it was a supply chain attack. I think really what we've seen is that it was an attack where they took trusted code and allowed it to proliferate through the entire development process. And it actually even showed that the current, you know, DevSecOp tools are only good at understanding what's being tested or what they're working on, because it easily flew through the whole DevSecOps process, even made it through all the way through tests and into operational production. Right. So something needs to change to ensure that problems like that can not occur in the future. And I think that the solution there is to be able to monitor applications at runtime and ensure they're operating as expected. And I think that's an incredibly key component of it. I also think when you look for log, Log for J, was an example where, it was an attack of an obscure library.

That ultimately created havoc within the industry. So here's a case where because it wasn't a known signature, it ultimately caused an immense amount of problems. And so again, how do we protect against the attacks without knowing anything about them is key. So I think that's really kind of the future of what we're going to see is more sophisticated attacks that are happening at the application level that are taking advantage of systems and ultimately, holding owners of the application at Ransom to say, If you're not paying up, they're not going to allow your application to work. That's what I see in the future.

(Daphna) Perfect. So if you guys have any questions based on Lee's response, please, you can put it in the chat now and we're gonna move on to Sam. So our question for you is, ransomware is a great example of bad actors at work, what are some of the top methods ransomware gangs are using today to breach the network?

(Sam) Uh, yeah. So, I mean, there's, there's a lot here to unpack, but I generally, I just wanna add to something Lee said. I think we as an industry are, we're kind of flatfooted. We’re not, innovating enough and adapting enough.

While the attackers, they have a much greater rate of innovation and advancement collect. It doesn't have to be that way, but it is. And so they pick their points of attack and they go after things that we just haven't thought about how to update or how to build a nimble scheme for improving.

Now, ransomware in particular there are two major components in the setup and the execution of events, and then there's what comes afterwards. The first is the distribution of it. It's the how do you and that's really a malicious operation. It's a MalOps if you will. Not malware. Its people with their tools distributing and getting through networks to systems.

Think of it like placing bombs or simultaneous detonation, and then there's the detonation. That's the malware. Really, if it's only done partially, or if it's not done simultaneously, then there's a chance, an increasing chance that the victim will have a partial survival or will be able to respond in time.

And so what they try to do is they try to get their operations to deliver it rapidly, put it in place, and then detonate. We also see. Sometimes it's called double or triple extortion. It is the attempt to extract a ransom and to embarrass the target if they don't to publish their information, like Conti does on their website.

That's the stuff that happens afterwards. And they target, we just saw the LA Unified School District got targeted by reprehensible group who go after explicitly K through 12 education. Think about that. They go after schools because they know that schools have non homogenous environments. Often strange things happening because of labs and students.

Sometimes, you know, people are cutting their teeth as hackers in those environments in courses. In red team courses, things like that, and they know that they can absolutely take advantage of those institutions. They used to go up to municipalities and so it's pretty horrible, but there's a lot of innovation going on in the tools.

Sometimes they're less sophisticated ransomware actors, like the ones that went after the LA Unified School District, they were pretty much script kiddies running existing things. You know, like, just using tools that have existed for ages, like Hello Kitty, for instance. So they're evolving and now they've aligned geopolitically.

So what we see is the sort of neutral cyber criminals have anonymous, has aligned more with Ukraine. Places like Conti have aligned more with Russia or the conflict over there, and they're looking to sow and wreak havoc. So there's a lot going on, A lot to unpack there. I hope I didn't drag it on too long, but I would emphasize there are human beings on the other side who are innovating and picking and choosing the time and means of their attack, and that's second-order chaos. It's far worse than something like a hurricane or an earthquake because you can prepare for those. You can build insurance, you can build better codes for buildings.

You can build risk management for those. But human beings are the most devious opponents we've ever faced. And as such, if they're innovating faster than defenders collectively, then the problem's only gonna get worse.

(Daphna) Perfect. Very well said. So this is for any one of our panelists. Are the bad actors using methods of old with more creativity to breach organizations today? For example, phishing misinformation, socially engineered attacks? Could you both speak on that?

(Lee) So I guess I'll take it first so I think if you look, again, if you look at solar winds, I don't think it was necessarily new malware they were using. It was just being used and delivered in a new form. I think that right now, as long as it's working, people are gonna continue to do it. And I think it gets to Sam ,what Sam said there. You're basically, as long as you're successful, you're gonna keep doing it and you're, as soon as you're forced to change your game, they ultimately modify again. I think the biggest thing that occurred that was earth-shattering is that solar winds allowed what was considered to be trusted code to be entered into a baseline and people just assumed it was trusted. And I think that same notion of how many other gifts exist in third-party code or operating systems that are already in there that we're unaware of, and we think just because somebody signed off on it or whatever, we think it's safe. And that's not even taken to account any type of real-time attack that can occur in the future.

So I think that, from a defensive position. It's really a hard thing you're getting hit with anyone, looking at what's the easiest way to get in? Just use an ex metasploit kind of tool set and just search and say who's vulnerable with the existing vulnerabilities. And then you also have true actors and criminal gangs that are looking to truly exploit. And in that case, they're innovating and they'll continue to innovate because that's what's driving them.

(Sam) Daphna, I'm gonna build on what Lee said again. I'm gonna say, look, like he said, if it works, why would you stop using it? But there's often incremental innovation. So it's iterations, it's tuning, but identity continues to be apart of every attack.

Like the vast majority of attacks, maybe not every, but the vast majority of attacks include some component where there’s an identity compromised. It might be the initial vector, it might be something along the attack chain and I think one of the premises that Lee mentioned earlier is that now we're starting to see applications in every attack chain, right?

So it might begin with an identity, but ultimately get to something like an application, right, and so there are some things, call them the usual suspects, and they're turning up in, in every, kill chain. The other thing that I will say is, even supply chain attacks are not new. NotPetya, if you remember that folks, it was a supply chain attack.

A lot of folks don't realize that it was the Emmy doc financial application that was exploited, and everybody who did business with the government in Ukraine, anyone who did business in Ukraine had to pay taxes through this package, and the Russians knew it, and NotPetya was delivered through this application so that it hit everything, all the private sector and public sector in Ukraine, but also people who did business with Ukraine. That's how it went international. And so we're talking 2017, five years ago. We were looking at, an instance of a supply chain attack. We didn't call it that. And I'm gonna go a step further here and imagine in your head the triage list of most attractive vectors for supply chain attacks and the ones that are most attractive: you’re gonna be ubiquitous, you’re gonna be powerful, you're gonna be largely ignored, and they're gonna be easy to reach. So, what were the first ones? PowerShell. Of course, it was PowerShell. That, by the way, if you think about it, is a supply chain attack. If you think about it the right way, it's there.

It's everywhere. MS office scripting languages, but eventually you get to things like Log for J. 

And if you did a triage list of what those things are by doing an inventory of components and software around the world, you'd probably have a hit list of what they're gonna go after or have gone after. I would use an iceberg analogy, except that I think 10% is, is probably too big. It's probably more like we know about one or 2% of ways through enterprises.

Hector joined us, so I'll shut up now and feel free to ask him a question, but give him the opportunity of hearing the question.

(Daphna) Well, yes, as everyone can see, one of our esteemed panelists has joined in. I'll let Hector Monsegur introduce himself and then we do in fact have some questions for you.

(Hector) So my name is Hector Monsegur, Director of Research at Alacrinet. And you know, at one point I was the bad guy. I'm a former adversary. And I'm here to share that perspective with you guys. And for the record, I've been here the whole time. I just had a different name on the screen, so you probably, you know.

(Sam) Identity compromise right there. Who were you, Hector?

(Hector) Oh, listen. Uh, it starts with a C I leave it at that.

(Daphna) I think I know who, I think I know who it was, but I wasn't sure. And I wanted you to reveal yourself just like you did now. So it's all part of the plan.

(Hector) See that, that is, that is great security hygiene by Daphna and I hope you guys in the audience learn that.

(Daphna) So, Hector, we have a special question for you. So, since you had such a background in application security, as you have mentioned yourself before, how do you think we can better protect applications from bad actors? What are some of the attack methods that you are seeing, making it, making through all the defense?

(Hector) Well, I like to look at things historically, right? So for quite some time, especially during my time as a bad guy, SQL injections were all the rage. You know, that was kind of a daily thing there. But now when you start looking at, Hacker One or any other, you know, book Bounty Feats, you're seeing a ton of information disclosures.

You're seeing a ton of insecure direct object references or eye doors, which is, you know, essentially an access control issue or authorization control issue. There are a whole bunch of different ways to look at it. But that's, that’s kind of what I'm seeing in terms of trends. Yeah, the other thing is, gonna be access controls in general.

Can a user, if they get, compromised, or if an adversary creates an account on our system, are they able to move laterally or escalate privileges? Or move upstream. And so you really have to look at dealing with these problems, these questions, before even going into production. You know, the whole DevOps experience is extremely important for identifying some of these or including tools that'll help you mitigate some of these.

For a long time, a lot of, organizations relied on static systems, right? Signature-based systems like mob security and that's fine. Well, it's fine for back then. Now what you see is companies opting to use something like Cloudflare Secure Eye because they're offering, an extensive, solid, signature database, as extensive as you can go, but as you, as everyone should be aware by now, they blacklist are usually take you as far as possible.

And there's never really a full coverage. So, yeah. So those are my, those are my perspectives on what I'm seeing today and, um, how to deal with some of those issues.

(Sam) By the way, that happened with Uber. That happened with Uber, at least allegedly, right? None of us were on the inside of Uber, but everyone's talking about the MFA exhaustion. Really, that was just the front door. What actually happened was they had hard-coded passwords that let them get to the vault, and then it was all over.

(Hector) Oh yeah. See, the thing is a lot of, and, I'm not here to point blame at anybody, but the reality is that a lot of organizations kind of skirted through time.

Putting that initial security fence, right? It's a security fence, whatever that is. Okay. And they're like, Well, you know, I think that's good enough. But the reality is it really is not, it really is not. You have to really look at your security program, you know, holistically or from, as many angles as possible because if all you have is a MFA before an attacker could get keys to the kingdom is a major problem.

(Lee)I have a thing to say to add on to Hector. So one of the things that you talked about is, you know, moving laterally, becoming persistent. And I think that's a huge problem because what you're really seeing is someone that's sophisticated is leaving gifts within your applications to ultimately use at a later date. And I think that's an incredibly hard problem for industry to figure out if they've been exploited. I mean, if you look, use Solar Winds again, they did an awesome job covering their tracks. They were in and out. The majority of the people didn't even know they were exploited, right? And they could have left many, many gifts behind. How do we ensure that none of those gifts get, get continued to, leap back doors, or lead to other exploits? How, as an industry, how do we protect against that?

(Daphna) That's what we're all trying to talk about and solve with various different solutions. And kind of going into that. People often say they've applied X solution here or Y solution there, so they should be protected overall. So have organizations been lured into a sense of security that they are quote” secured for good" because they're implementing these different solutions? So that's a question for all panelists.

(Sam)I suspect every CISO, Well, first of all, CISOs don't, I'm speaking as one I don't like when people ask me what keeps me up at night, there are lots of things that keep me up at night, but I have a risk register, right? And there's no, there's nothing in my risk for student zero, like nothing.

Now I might hit, some that are wrong. But most of them are changing. Here's the key thing. Every one of them is getting worse over time. The question is how fast everything comes out. I like to think of security measures as having a cost to break from company, right? Hector, back in the day, had had an opportunity cost and a literal cost to break into something.

That cost came down and my job is to figure out what's the optimal spend of money to reduce the risk. So nothing’s ever zero, but I think the better answer would be Daphna, that a lot of CISOs are confused as to what is really at risk, controls are degrading and most don't know where the real risk lies, the models get out of date real quick. That's my take.

(Hector) Yeah, I would jump on that as well. I agree. From all the conversations I've had. And remember, you know, for the audience here, I'm on the offensive side, so I would interface with like Sam Curry for example, and we would have a conversation about this topic, right? But from my perspective, I also agree that I don't think a lot of CSOs really understand the risk... It doesn't mean that they're terrible at their job, it just means that there are probably some processes in place that need to be improved or there's some other information that they're probably missing. Now it's up to them, you know, kind of working as a team, figuring out what kind of gaps are we dealing with.

Are there even any gaps? What kind of tools are we using? What's the worst-case scenario? The tools were compromised. Why are the tools ineffective? How many steps before? An attacker gets keys to the kingdom if they’re able to compromise a custom web application that we've created in-house that didn't go through any audits.

Right. So that's really my take. I mean, I agree with Sam here. I think that's the bulk of it. The other thing is, you know, and this is something that is less on the technology of more than the people. When you start to bring in folks who are developers that do not have any, I would say the security experience, with experience with cyber security in general, in terms of concepts, in terms of good hygiene and so on, and you're always gonna have problems moving forward.

You know, this is why I think that I've always been a big, big proponent and fan of DevOps, security, and organizations trying to bring someone in that could interface between developers and the security program. I think that goes a very long way rather than you have a bunch of. Developers, you know, deploying a bunch of AWS scripts, or instances, and then posting their code from QA straight to production without any sort of testing in between. It's extremely problematic.

(Lee) I'll just add on that just one thing is that if, if you look at the current vulnerabilities, I mean every application your running is just continuing to get more vulnerabilities. You know, I mean, if you rerun your vulnerability checker three months, six months down the road, the numbers just keep growing and that's the tip of the iceberg. That's what we know about. So I think people should really worry about what we don’t know about. That's what should really keep you up at night.

(Sam) There are inevitably going to be vulnerabilities in applications. The rate at which humans find them is both finite and never complete.

(Daphna) Good points. Good points all around. We are kind of rounding up to the half-hour mark. So we have time for just a couple more questions for anyone in the audience. Feel free to send those in now. At the half-hour mark, we're going to transition to a demo by Jacob. But before then, this is for all panelists. What is the most important step of application resiliency?

(Sam) Are you speaking? Is that, is, is that question asked of CISOs, as applying it to existing applications in production? Or are you asking it from an SDLC perspective, like getting it right in the software development lifestyle? Or maybe I could phrase it as an answer to both.

The first one is for you, Sam, The second one is for Lee. And then Hector, feel to interpret however you'd like. Let's do it that way. To cover all of the bases.

So I'm gonna answer this by saying that I particularly buzz phrase you hear a lot, which is zero trust. I hate it. I believe in the least trust least function, least privilege. One of the best things you can do is try to minimize what the entitlements are in your environment and how things can be accessed by whom under what conditions. So minimize the ways, the complexity, and the ways that things can interact within production. You shouldn't have seven ways to get into production.

You should, one, not everybody should be able to, only a few the ways you can do it. You should be very limited. Now, this is painful, right? Because what's the IT department trying to do most of the time? Find ways to connect everything, Make sure people can do lots of stuff. Cause that's when cool things happen.

So it is a political fight as well. But I'll take the product question to say, even though I have opinions in all the rest, the production question should be to make sure that, you limit connectivity as much as possible. In fact, in one instance, in one of my environments, I just shut the stack down.

I don't need FTP. Get it out. Don't let the hacker get that, like just toss it. That's least function and we all know least privilege. So rather than say zero trust, because it's never zero trust. Least trust is a great principle for coming back and moving more and more production.

(Lee) I guess for my side of it. I think, we need to look what is the weakest link. So if, you don't really look at it from what's your weakest link in your, production cycle. You're not really gonna solve the problem. So from my perspective, I think we need to harden the toolchain and ensure that every aspect of that toolchain, in addition to ensuring that you have the right to be there, that you're using it appropriately, and that we can verify through ultimate testing of the software, that it does what it's supposed to do and enforce it at run time, I think is the key to product.

(Hector)Yeah. And I definitely appreciate both perspectives from Sam and Lee here. I already have much to add on the offensive side, my biggest concern is even if I'm testing an application is it gonna crash. If it crashes, what's the consequence? I'm always dealing with. Well, one of the, one are the requests that I always make is can we, can we take this web application off of production?

Right. I would hope that we're testing. A staging server, staging version of the application. It’s absolutely important for these applications to be able to, not only maintain stability but to ensure that the organization has some sort of plan to deal with, well, what's the worst-case scenario?

If the application crashes or something happens, what can we do from there? How can we be resilient in that capacity? So, yeah, the big shout out to Lee and Sam on this topic, I think they have way more experience than I, but I just wanna say one thing Daphna I am looking forward to the Jacob demos because those are always the best part.

(Daphna) Well, we're gonna get to that in a second. We actually have a very topical question from the chat that maybe you guys can take a crack at. Just quickly, so the question is, how do you think the recent conviction of Joe Sullivan former Uber CSO will change the posture of CSOs in the near, immediate and long term, specifically with regards to tooling?

(Sam) Before I answer that, Daphna, is this recording going out for broadcast?

(Daphna) We can take your answer out if you'd like, so you can speak candidly.

(Sam) I did say something if you go look at the cyber reason blog back in 2017, but I will say this, I think there's a lot of, fear in the security community about what this means.

However, Joe is a lawyer by training. It is my personal opinion. And I think the jury has spoken, and we'll see what happens in the appeal process. There you go. That's mine. I'd love to hear the others though.

(Hector) Well, I'll just jump in and say, from someone that has to deal with, you know, either CISOs or CSOs or CIOs pretty much on a daily basis.

I think that there are either two directions that we could go. You know, folks are going to be more approachable when it comes to breaches and have a plan in place in case a breach happens and follow very strict policy. Again, I don't know their full, thinking behind what happened.

But the second one, the second way I would look at it is I hope that it doesn't scare some of these executives who are probably non-technical people who probably wouldn't like going to jail or being sued…Um, scare them into hiding more. Right. Hope that that’s not the case because we're trying to move forward. Not backwards folks.

(Sam) Hector, you raise something really interesting there because. We as CSOs are really, we have an almost at this point, fiduciary responsibility. I can't actually say that we do, because that's a legal term. That means that you have to look out for your customer's benefit rights and, and, and interests over those of shareholders.

But we, but it's my belief that, that, that we're on a path to that as CISOs, in other words, data and the protection of data. Is a privilege. It's not a right for companies. Now that will come out in jurisprudence and law, but it’s already turning out in some jurisdictions to be true, which means that chief privacy officers, chief data officers, and chief security officers are men and women who have to think about the rights of the owners of that data.

And, so it's interesting because we aren't lawyers except for Joe. We generally aren't the minority of us who have a legal background. I do not for instance and so how this plays out is really going to be very significant because we, most of our general councils think about the company first and about the shareholders first.

We don't have a voice yet representing us as a group saying, Should we be really representing something else with equal or greater footing?

(Lee) I think you, you hit it right on and, and it’s extending that whole concept of fiduciary duties, that is, value to that corporation. For companies that have clients using their data, it's money, right?

If your data's held for ransom, it's money. So I think the whole conflict is making people more responsible for breaches and things of that nature, I think will create greater awareness and create change. If you realize that you're responsible. And I think one of the things responsibility is, is important and it may be painful steps to get through, but it needs to happen. That's just my opinion.

(Daphna) Perfect. Well, I'm glad we were able to make some time to chat about that. I just wanna give a big thank you to all of our panelists. Lee, Hector and Sam, thank you so much for sharing your expertise and your time, with all of us.