Workload and Application Security Blog

The Virsec Story: Game-Changing Application Visibility & Security

Written by William Leichter | Dec 1, 2019 3:45:38 PM

 

Virsec's Application Protection Story

The presentation below is from a recorded presentation by Willy Leichter, VP of Marketing and Product Management. Willy gives a brief but thorough overview of the state of cybersecurity - from the threats and vulnerabilities organizations face today to Virsec's deep and complete insight and protection. Virsec's unique approach to safeguarding and protecting applications and memory processes provides complete visibility and protection during runtime, blocking zero-day attacks and other threats, including ransomware attacks.

Today’s Security Environment – 20K Vulnerabilities & Rising

Briefly I’d like to touch on some of the issues that are affecting most enterprises in the industry. First of all, we’ve seen a massive increase in vulnerabilities. The National Vulnerability Database tracks vulnerabilities that are reported. Typically that’s been about 5,000-7,000 a year. In 2018, they topped 20,000 vulnerabilities recorded. The sheer numbers are staggering. That means about 80 new vulnerabilities for every work day. So if you imagine, trying to keep up with that is nearly impossible.

Typically that’s been about 5,000-7,000 a year. In 2018, they topped 20,000 vulnerabilities recorded. The sheer numbers are staggering. That means about 80 new vulnerabilities for every work day. So if you imagine, trying to keep up with that is nearly impossible.

We’ve heard from one of our major customers that the cost of tracking down, patching, fixing any major vulnerability is about $50K each. And finally, some interesting stats from Microsoft say that about 70% of current vulnerabilities are memory related. I’ll talk more about that in a moment.

Why is this significant? Well these vulnerabilities are being exploited every day. These are just some of the memory-based, fileless-based attacks we’ve seen in the last few years.

There’s been incredible acceleration, with attacks like WannaCry, NotPetya, Industroyer, GreyEnergy, LockerGoga. It goes on and on. There is unfortunately a common theme here where these threats are leveraging memory-based attack techniques that have largely leaked out through the Shadow Brokers – tools like Eternal Blue, Double Pulsar. These tools used to be in the realms of nation states but now are easily available to any kind of hacker.

What’s the significance? Well, the cost of just WannaCry and NotPetya were estimated at over $14 billion. Maersk, the shipping line, lost over $300 million from a single event - just from NotPetya. One of our aerospace clients has told us that they have viewed in the past these in-memory attacks as being basically indefensible.

Now finally of course, what’s the end result here that everyone wants to avoid? Most organizations, certainly the CIOs from these organizations, want to avoid having their logo show up anywhere here.

It’s pretty relentless - the breaches, the attacks you hear, across the board. No one is immune. Really, we need to take these issues seriously.

Key Application Security Challenges

Now I’m going to simplify this and briefly touch on 3 issues that we think are key security challenges that Virsec addresses.

First of all, we’re seeing increasingly that attackers are exploiting security blind spots in our application stack. We’ll talk more about that term in a moment. But they’re going where your defense aren’t. Maybe that’s not new but there are certainly areas of the application stack now that have never been looked at and are being exploited every day.

We probably already know that our response time to attacks is far too slow to be effective. We’re seeing attacks that happen within seconds or minutes and response time can be weeks, months, years or never. And that means we’ll never win this game. And finally, we really don’t know if our applications are doing the right thing.

We don’t know if they’re acting as intended as opposed to being corrupted, hijacked, or influenced by someone else to do something they’re not supposed to do.

Securing Applications During Runtime

I want to talk for a minute about this whole concept of runtime. Most conventional security that has been developed over the years has looked at perimeter defense, like firewalls, IPS, WAFs, endpoint protection.

Progressive layers that maybe come closer and closer to the application. But they’re all trying to estimate what’s good or bad before it hits something, which sounds logical. Now if something’s been discovered, there’s a signature, it’s known, they’ll do a pretty good job of stopping something the next time around. That’s all well and good. But if it’s unknown, and there’s an infinite variety of attacks possible out there, they really are blind to it and they’re guessing.

All the AI in the world doesn’t mean it’s not guesswork and it’s probable-istic. After the fact, there’s also increasingly tools – like EDR - endpoint detection and response - various other forensics, machine learning, that’s looking for clues after the fact. What happened? Did it do something wrong, can we detect this, can we now make a new signature now to stop this in the future. All so well intentioned but in many cases, it’s too little, too late.

Now what’s in between ‘before’ and ‘after’ is during - during runtime. Runtime has been viewed in the past as kind of a black box. You know, you’re running code, we don’t really know how it works or where it came from, maybe it’s developed by a third party.

We assume that it does what it’s supposed to do. Now, hackers are exploiting the fact that no one is watching this here.

There’s no visibility during runtime. They are coming up with various techniques to corrupt code during execution, to inject their own code to run instead of yours, to turn malicious input into code. All of these fileless, memory attacks, zero-day attacks, they can bypass the conventional security, execute during runtime, or as we like to say weaponize during runtime.

And they leave few clues behind because they actually only exist when an application is running. So this is the challenge and this is what Virsec sets out to address. We are all about protecting applications in real time as they are running and making sure they do the right thing and only the right thing. I’ll talk more about that in a moment.

Protecting the Full Stack

Now the other thing that’s important if we think about the application stack is you have to protect the whole stack.

Attackers will naturally go where your defense aren’t. Many people are familiar with various types of web layer attacks, the OWASP Top 10 – cross site scripting, CSRF, command injections. There are tools that try to stop some of these things that are more familiar. But attackers are not just relying on that. They’re using memory-based attacks – buffer errors, stack smashing, various types of overflows, ROP chains, to attack and inject their code directly into binary code, third party apps or maybe mission-critical industrial control systems.

Protecting the Environment – Files, Processes, Libraries, Registries

And finally, the environment that these applications are running in – the files, the processes, the libraries, registries – all of these things are vulnerable as well and need to be protected to ensure complete application protection.

Now if we look at conventional solutions that are out there, there are point solutions that are doing pieces of this, and that’s a positive. Look at a WAF or a RASP, they’re doing various things at the Web layer, end point protection or EDR’s, they’re doing various things at the host layer. But these are point solutions and they leave gaps. They leave blind spots.

Virsec is the first solution on the market that puts all of this together, gives you full context across the application stack – and frankly that’s required if we’re going to be able to shut down these threats completely.

Now, I’m not going to get technical here but want to give you a little bit more detail here about what we talk about when we say we want apps to do the right thing, and how we make that happen. So if you imagine your developers develop applications or maybe you get them from a third party. Hopefully there’s some chain of trust so you’re running the right software and SecOps runs it and makes sure it’s secure. That all sounds good.

But attackers increasingly are going to the operations point here, the runtime point (see diagram), and using the various techniques I mentioned. They’re using malicious input into web servers, converting interpreted code into malicious code on the fly. They’re also injecting code directly into binaries, things like libraries can do that, and various other techniques. And finally, they are also often inserting their code, their tools into the chain of trust so you aren’t running the right things in the first place. Maybe they’re changing a critical file or changing a library out or doing a DLL injection. At the end of the day, the attacker’s intent is to run their code instead of yours and this is how bad things happen.

Are Your Applications Doing the Right Thing?

Now at Virsec, what we do in a nutshell is we create an AppMap. It’s a properly termed concept. The AppMap is multi-dimensional.

We look at all the allowed files, the executables, everything surrounding it - the whole package - and make sure it’s not corrupted and that it doesn’t change as it’s being delivered to runtime.

And then as applications are launched, as they’re running, we look at the input, we map the binary control flow. We map a whole host of things here so that we know what the application is supposed to do, what the developers intended and what is proper execution of this application. And this is the “black box” that people have talked about.

Now armed with this map, this gives us the ability to enforce this in near real time, to detect these attacks. We get complete visibility to this runtime environment and very precise, actionable forensics and protection actions. Now this is happening within milliseconds as I mentioned, so we can spot something and at clock speed, we can determine exactly what happened, where and when. And that’s what you need to defeat these attacks.

With Virsec’s AppMap, Be Deterministic, Not Probablistic

Now if we bring our hacker back, we mention all these various ways the hacker can insert their code. We can detect this on the fly because all of these things cause deviations outside of our AppMap. And that means if it’s wrong, it’s bad. We call this ‘deterministic,’ not ‘probablistic.’ So it is definitively bad and that means we can take action with confidence. Unlike say a WAF where you might have false positives or uncertainty and you don’t want to stop things.

Now the actions we can take vary. We can correct any files that may have been corrupted, we can quarantine bad information, we can un-inject malicious code. And we can take broader actions through APIs to say, have a firewall cut off access for a particular malicious user. All of this, again, happens extremely quickly, almost instantly. And before attacks can really be effective and execute, we are stopping them and nipping them in the bud.

Now finally I’ll give you a quick view of our dashboard. We have a very intuitive dashboard. And as I mentioned, extremely detailed and actionable forensics.

So here’s an example of a Command injection where we have captured not just that it happened, but the entire payload. This is critical. This is the information you need to understand it, to make sure it doesn’t happen in the future and to take action precisely to correct this. So this is also an unprecedented thing that we deliver that really has not been available before.

Now we’re not the only ones saying memory protection is important. In fact Gartner has gone as far as to say it’s mandatory. We think that’s significant. We’re in a very small group of vendors that do any kind of memory protection. We are the only ones who do it across the full stack and in runtime, in real time.

What Makes Virsec Better?

So why is Virsec significant, why is it important for protecting application and memory processes?

It gives better results. It dramatically improves security coverage, it eliminates blind spots and exposure to advanced attacks.

It’s faster. As I mentioned many times, we’re detecting in real time without any prior knowledge, no signatures, no tuning, no learning. And that speed lets us take action also, in extremely rapid timeframes to essentially stop these attacks before anything bad can happen.

We’re also less expensive. I say this because our precision means you’re not endlessly chasing false positives and hiring whole teams of people to manage your WAFs. That’s the real cost of most security systems if they’re not efficient, if they’re not accurate and actionable. So pinpointing attacks eliminates that whole chain of expense.

And finally, this is all quite easy. All of the processes and steps I’ve talked about happen automatically. There’s no learning, there’s no tuning, there are no signatures, no policy updates. This is all out of the box. This works with any type of application without access to source code. So we’re not changing the application and this allows security teams to effectively know applications are running properly even if they didn’t create the application, even if they’re not the developers or it’s built by a third party. They can still have confidence that it’s not going to go off the rails.

Because of our unique technology, Virsec has been recognized with multiple awards globally. We’ve also partnered with some of the largest, most security conscious organizations in the world in the effort of protecting application and memory processes

Raytheon has deployed our solution and we’re partnering with them globally, deploying this in all kinds of environments.

Schneider Electric and Aveva are in the industrial control space where there’s huge amount of concern obviously about the threats and attacks on critical infrastructure. But this applies to any type of application that your organization feels is important and worth protecting accurately.

Thank you for your time.

Next steps:

Web Application Security

Memory Protection

Critical Infrastructure Protection