RASP Demo

00:00

one lesson 7.33 I'm gonna demo the contrast run time application.

00:08

So and with the demo, the contrast, rasp and then kind of explain some of that rasp benefits.

00:18

So for the before the demo starts, here is the link they probably seen before. Just a link to the contrast community edition page. You can take a look at it.

00:27

So we are back in the contrast at for this demo. You can see it might look a little bit different, but it's what we looked at previously was the vulnerabilities and the libraries. This time I'm just gonna focus on the attacks. So Iran, Iraq, me

00:46

and, um, Nick toe against this the application just to kind of simulate an attack here. So now we see over on right there. It says attack as you can either get to it from here or at the top attack either way,

01:00

So you would be in the operations mode we're having set up. So these type of attacks can be viewed

01:06

so you can see that there was one I p address which would have just the self attacking itself here. It was blocked. We see this with our application or server

01:17

and get some rules that were used during this attack or rules that were that they assigned to the type of attack. So

01:23

command injection, cross site scripting path reversal, sequel injection.

01:29

Um, you can Actually, if this was in ah Riel

01:34

operation, you could blacklist I p here or do a little bit more on the attack. So we're more interested in just seeing what, what? What the two offers. So it could drill down into here.

01:48

At this point, you can see again. There's further information. How long is it happened? The number of events. You could see the timeline drill down anywhere here. Additional notes on it. So there was 2700 attacks. It's all that there was a medium attack, but it it ruled that the high because it's all one of the

02:07

attacks coming through

02:10

again. You'll see it. It sorts. The events by

02:15

oh are effective, which means that there was some action needed to take be taken.

02:20

I just sort here. And also there was 550 events.

02:23

I've added some tags here just so we can take a look at them to kind of see the difference. So you see, the 1st 1

02:30

which was a cross site scripting it's marked as it was part of the effective one to it. Uh, it was actually blocked. We could open up. This won t take a look at it. So this was a cross site scripting event.

02:44

Uh, and you noticed right here. It says we blocked this attack, so you know,

02:47

it's all something coming in or going out, and it decided it need to be blocked. It was attacked that was gonna be successful.

02:54

And again, we, in the same way as the I asked version of it is highlights the attack here. The important part

03:01

s we see here

03:04

that there's a cookie with the jail. With the Java session I d. And it looks like there's some HTML tags into. It definitely looks like something

03:12

wrong is going on here. The details has a little further information. Just pulled out that, but it's just like like the I asked tool again. You can add this couple tags here is you can put him and take him out. Everyone

03:25

and a couple of events to its soul

03:29

that that it

03:30

marked him as probed so it means it's all the attack. It was able to map it to say, for example, this one's a sequel. Injection

03:38

on. It's definitely

03:40

yeah, they're sending a number equals one equals two and trying to inject something into the sequel. So it's all this, but it didn't see any ever adverse that coming back from the database. What decided didn't need to block this. So this was a failed scan or failed attack, and he's here at the bottom here where it says,

04:00

unlike the other one says, we blocked this says this attempt

04:03

attacked attempted attack did not require specific blocking because it did not cause any adverse actions within the application.

04:11

So that's the interesting part of these, uh, the rest

04:14

that it can see the attack, identify it, but actually monitor

04:17

what would what would happen and then not waste time blocking the attack. And hopefully this would be having any false positives. Are site false negatives where it saw something that maybe wasn't even attacking actually blocked it. So it has some intelligence that way

04:32

that marked a couple of easy antique couple command injection path reversal. Looks like none of these were effective This is another cookie injection trying to hit the linen Prock self environment to get some environment variables may be something else of bad,

04:48

but that's about it for the blocking portion of it, so you can see it looks just like that, I asked. But it's making some decisions instead of just notifying what's going on. So this would begin, would be running on the production side. When you're in the operations phase, you probably don't wanna block on the development side because

05:08

you want that tax to go through and be able to find the vulnerabilities and not rely just on the rasp.

05:15

I just want to jump in here kind of, as they usually do, and ask you a question just so you can kind of think of that versus just listening to what I'm talking about.

05:24

So what do you what I've said? Or what you can think of? What are their rasp? Pros and cons?

05:31

The 1st 1 obviously pro, is real time protection, so you can maybe the middle of the night or the middle patching cycle, and you're still you're trying to build it so somebody gets a jump on you and tries this new attack, so the grass possibility

05:47

Germany can detect it is to actually block this attack before it can be exploited.

05:55

So they mentioned, it bridged the gap between the patching. So even if you may find out a vulnerability, maybe working on it, you may. There may be some lag time between fixing it and deploying it to the production, so it gives you that little bit of gap of time, assuming it can block the attack.

06:11

But it really needs the help of a Web application, firewall or something's other tools. Firewall blocking for known bad domains. Things like that you don't This shouldn't be your primary tool for blocking, but it should be part of a suite.

06:27

The other con is it may block legitimate traffic. So the way your application is set up, it may the data it sends maybe large. It may come in some formatting that that the rest sees as a new attack or some illegitimate traffic and Amanda blocking it.

06:44

It's not specific to the raft. The Web application firewalls have the same issues, but just something you need to think about

06:49

that you should be running tests that should be part of your your testing with the tool in a blocking mode

06:56

and the momentum before there's gonna be a performance hit because it's running in the application,

07:01

performing some evaluation and, you know, possibly blocking determine whether it's a block so it needs some resource is to perform these activities