Transcript

00:07
Awesome. Thank you, Chris. Yes. Hello, I'm Matt, like he said, and we are gonna talk about Rules Engine. It is a new feature of Pro that will be out shortly. And you're getting an early access preview. So let's get the ball rolling. So first I'm just gonna kind of intro the problem and kind of talk about why we had this idea for this Rules Engine thing, talk about what we've created to date.

00:33
I'm going to do a demo. So like if I'm lucky, things will work out well. If not, you guys might have a nice chance to giggle a bit. And then I'm going to talk about what's next. Like what's going to happen after this call and what our plans are going forward to roll out Rules Engine to all of our pro customers.

00:51
So let's get started with the intro. So the thing here, or at least the thing in my mind is inevitably when you're doing security work you wanna find that diamond in the rough. You wanna get all the actionable issues but not just all the data because tools are great about producing loads and loads of data. Not all of that is actionable. And so the real goal

01:18
And a lot of the work that you're going to be doing as a security person is to get to that actionable nugget hidden. But unfortunately, this is generally what scanners give you is a whole ton of stuff that you have to sort through. You kind of get buried in noise and just data that isn't actionable. So one of the ways that we want to help our customers solve that, and we've been doing that for years with Dojo generally, but a way to even make that better is the rules engine, right? So how do you win the prize?

01:48
of being able to wrangle that data into a shape that makes it much easier for you to use and allows you to have actionable results that you can then take to the proper teams to get stuff sorted and resolved and all those good things that is actually the end goal of all this security work. I always like to have kind of the big picture up so this is kind of what you should be shooting for where you have over here you have on the left you have

02:16
where you're intaking data from something, you're running some tools, they're all flowing into Defect Dojo and then they're going to your downstream stakeholders. And in the case of Rules Engine, we really want to focus on the quality of the data that gets into Defect Dojo. You can run a bunch of tools, you can accumulate all that in Defect Dojo and it's your one source of truth, but how do you make that truth truly actionable and useful and eliminate some of the

02:45
that you have to do before you pass it to your downstream constituency. So this particular MVP of Rules Engine is focused on this section, so to speak, of the workflow. So getting quality data in, right, generally scanners work fine except for when they don't, right. And if anybody's ever used a scanner, you've realized some vendors are great about giving you lots of options to change and tweak and adjust the profile of what gets scanned, and some just have the scan button and give you results. And so

03:16
those noisy scanners, those ones you can't tune, end up putting a lot of extra data that you need to sort of filter and get rid of. Also noisy scanners, oddly enough, tend to be the ones that find more things because they tend to ask more questions or do more investigation. And so you have this Gordian choice of, do I run the noisy scanner and have a lot of noise in with my good data or do I run the not so noisy scanner and worry about missing things?

03:44
And so the real thing is how do you find all the things and don't have the noise and pass on only actionable findings. And so this is why for the rules engine and VP, uh, we started with one particular area of dojo. So what, what have we created?

04:04
Also, the rules engine. The whole idea of the rules engine is it's sort of a three-step process. You're going to narrow down the data you want to change. So this is the thing that I, this is the group of data that I want to change. You're going to describe how you want to change that data. So if it looks like this, make this change. It's kind of the idea. And then we give you a preview. And then you can run the rule and make those changes.

04:31
And then just a quick note to keep me honest, you're gonna see screenshots in the next couple of slides and in the demo. This is super early UI work. This is likely going to change. So this is not the final product, but it'll give you an idea of what it's gonna look like. It won't change substantially, but it will change a bit. It might look a little bit different when you see it in your pro instance later on. So just a heads up.

04:58
So rules engine, right? It's down here on the left menu. You can add and look at all the rules. If I go to the all rules view, you can list the rules that exist in that system. So this one has three rules here, one for doing something with the X header, one for doing something with cross site scripting and another one to handle a SQL injection fingerprinting result.

05:26
So when I'm creating a new rule, I've kind of hinted at this, the initial MVP is gonna be targeting findings in Defect Dojo. That's kind of the heart of Defect Dojo. That's where most of your data is. So that's what we started with, seemed like a pretty obvious choice. And so this is basically a way for you to name that rule. So I named mine rather cheekily the screenshot rule, but this is where once we do

05:54
iterations past the NVP, there'll be more things that you can target this rule against, maybe products or product types or users or who knows what. But the target object here is what you're writing the rule for.

06:09
And then in this next step, you can filter, like I said, or you can filter or give me a list or describe the data that you want to change. So in this particular case, I filter for things that are in my product type and also for Zap scans. So this is a rule to change the findings produced by Zap in a way that makes sense for the way I do things at my business, basically.

06:38
The next step is where I describe how I want to change that data. And these are called actions. And so that red box is a set of actions that I can do. I can set a field, I can set a user, I can set a group. I can append or prepend to a field. I can add tags. I'm kind of like the stuff you would do if you were clicking around the UI, but this does it programmatically and automatically for you, which is kind of nice. Like no code kind of a thing. So.

07:05
Let's say for example, I want to tag any cross site scripting or cross site requests forgery findings with a special tag. So our WAF team can go into defect Dojo and look those up and see if they have rules for them and write rules if they need to or whatever. That's the theoretic.

07:23
So here's I've defined a rule, I've added two actions and they're conditional actions. Where in the first one says basically when a title contains the words cross site scripting, add a tag called waft-team. And the second one says same thing, when a title contains cross site request forgery, add a tag for waft-team. All right, so I click next.

07:50
and I'll get a preview of how that rule will run. So here I have all of those finding titles that actually had those strings in them and also the fact that it's gonna add those tags. I confirm that I wanna create the rule, which I did and do, and bam, I've got that rule. So now I've got my screenshot rule. From there, I can run it, right? Run that rule.

08:18
Confirm that I want to run, which I do.

08:22
And then this will tell me after that rule ran, there were 12 findings in this case that were changed and 55 findings that were skipped because they didn't match the criteria for that rule. They didn't have Cross site scripting, cross site request forgery in there. So in this case, 12 findings should have been tagged. So if we look at those findings before I ran the rule, you'll notice there is a well an utter lack of tags.

08:51
And then after I run the rule, they're all tagged. So this did just what it was supposed to do, right? You wanna tag certain things so the WAF team can filter those out and find those and take action. And now it's done. And by the way, for those people worried, we do support the dark side. There is a dark mode. I find for presentations, the dark slides are a little bit harder to see. So yes, we have a dark mode. So don't feel concerned if you're a dark mode person.

09:20
And then one final note, rules engine is only available to what Dojo calls super users historically, which is also the same thing as a global owner. This is because of the RBAC and permission system that exists in defect Dojo. You get in some really interesting cases where how can you write rules that are RBAC restricted and the case where like user one writes a rule.

09:50
that changes their data user tool, two would have to then write a rule that changes their data. Rather, if those changes are the same, you might as well just have one rule that changes both of those datas. It just makes life significantly easier, and this is somewhat of a power tool. So we wanted to restrict it to just the super users who have access to all of the data objects in DefectDojo.

10:11
All right. So it's demo time. And hopefully I'll be doing something like this in a minute when the demo's over. We'll see. Let me switch tabs. And so this is Defect Dojo, obviously running the Pro UI. And here is our rules engine down here. If I expand this guy, you will see, I can look at all rules and new rule, all rules.

10:38
I'm gonna sort these in inverse order so my oldest ones show up first. Here's some rules I created prepping for this demo. They're the same ones you saw in some of the screenshots earlier. But I'm gonna go ahead and create a new rule.

10:54
So in this case, I want to write a rule for path traversal findings. Let's say, demo office hours.

11:08
In this case, I want to write a rule that for our company, we're having to push this quarter to try to get rid of any path traversal findings. So any path traversal findings become even more important because we're trying to crush them as a, you know, as a company and get those out of our lives.

11:29
So this is that first screen where I'm going to filter. In this case, I want to filter where, let me change this to five, and actually I'm gonna stretch this window a bit just to make our lives a little easier. I've shrunk it for the slides, but this is better. Let me go over here and go to product type. And in this case, I wanna set a filter for, excuse me, for maps product type.

12:03
And in this case, I'm only going to concern myself with ZAP scans. So I'm also going to set a filter here. Or excuse me for active findings. I don't need to flag ones that are inactive mitigator to duplicate because why they're already handled. So any finding that is active.

12:24
Okay, so now I've said this is the group of data that I want to filter any findings in my product type and anything that are active because those are the things that are important for us to fix. So click next. And here's where I set up those actions. So in this case, I want to set a field. I'm going to add that action. And I want this to be conditional. So let's say we're CW E

12:53
where that is, and I just happen to have notes over to the side if you see me peeking that way, 35 is the CWE for path traversal. In that case, I wanna set severity to critical. Now this may not really be a truly critical vulnerability, but that will bump it up in its priority, and suddenly the SLAs for criticals will apply, and I can get these resolved quickly. But let's say not every tool is gonna give you a CWE, so I wanna...

13:22
kind of do a belt and suspenders thing, I'm going to select another set field action. This case I want to do it where the title contains path traversal. So if I don't catch it with the CWE, I can catch it with this one. I'm also going to set severity to critical. Okay.

13:47
And so here is what I'm going to do. And this is my preview. So you can see this path traversal finding is going to be moved from high to critical, which is what I want. Let me save this rule. Yes, I want to create it. And if I sort these, oops, if I sort these in inverse mode, this will be the last rule I created, right? Here it is. I can do things like edit the rule, which we just, I just showed you. I can delete it. I can run it. One interesting thing. Oops, clicked on the wrong thing.

14:18
One interesting thing is, and I'll find a past rule like this one, I can look at the history and see this is when I change the rule. When you run a rule, you change it from true to false and it runs and then changes itself back off. So you can actually see the history of rules. And then if you look at the, if you're familiar with defect dojo, the objects that you change, their history will show up as changed in the object history. I'll show you this in a minute.

14:48
Go back to alt rules. Go back to our rule.

14:54
So I'm going to run this guy. And actually, I'm not going to run this guy. Let me do this. I'm going to cheat. Let me go over here.

15:02
Oh, the silly UI for Zoom is overlaying. Quit overlaying my thing. You move over here. There we go. Thank you for overlaying. I'm gonna cheat and grab this URL and go to a specific finding.

15:20
Okay, here's our finding that's path traversal. It's one that's gonna match this. And right now you'll notice it is a high, okay. And its title is path traversal. So that's gonna catch by the both the, or either I should say the title contains, or I actually have that CWB 35. So I'm gonna catch this in two different ways. So I go back here and I run this rule.

15:52
Yes, I want to run the rule. It will go off and it rules run in the background. So it may take a minute or two for them to run. Let me go back here and filter for that last rule. Okay, it has run. It affected one object. It skipped seven. If I go back over to this finding and I refresh.

16:14
Oh man, that zoom UI is just evil. Quit overlaying my window. Okay, you'll see this is critical. All right, and so boom, our rule ran. We made the change we wanted. Everything's good. So rules will allow you to do, I can go back here by the way and see the history. Right, I ran it once at this date and time. And if I go to this finding and I view this findings history.

16:46
you will see that the finding was changed and this is a bug that got fixed in a version that isn't deployed. It will actually say from what rule specifically, but in the before and after values. But anyway, finding has changed by demo rule here. Boom. This is me manually changing it to high so that we have something to run. And this is me testing it. If you can't tell, I tested it before my demo, which is why this one went pretty smoothly.

17:17
Let me go back to here. So that's a quick demo of how Rules Engine works. Hopefully you have a decent idea of how things should work generally. Let me go back to the... Man, this overlay is evil. There's an invisible overlay that keeps me from seeing, clicking on things like this tab. Okay.

17:46
So that was a demo. Hopefully you're jumping up and down while as you cross a bridge. So what's next? So where we started, like I said earlier, was if you look at this representation of all of the sort of the data model for Defect Dojo, these are at least the primary ones. You'll see that we started with findings and that seemed like a natural choice.

18:11
And then what's next is we kind of want to do all the things. Because the goal of the rules engine is to allow you to do things that you could do normally clicking through the UI, but without having to do that, nor having to write an equivalent with, an equivalent with like calling the.

18:37
the rest API endpoint. So I've done a lot of things similar to this in past uses of Defect Dojo by making API calls. This way I don't have to deal with maintaining and running my own sort of API client that does things. So when we were kicking around this idea of rules engine, some of the things we considered.

18:58
Is this idea of sending an alert if a peer review is older than so many days, right, because I've asked someone to review a finding that they haven't reviewed it yet. I want to kind of give them a poke on the shoulder and say, hey, it's time assigning a finding to a user or a group. This is the that somebody owns the remediation of that finding getting it fixed moving the findings from one product engine engagement or test to another adding snippets to findings.

19:26
So if you wanna have a standard mitigation and reference for a particular CVE, you could do that. Automatically create a pen test for any product that has the PCI regulation, cause that's a requirement. Send a pager duty if a critical appears in a product. Those are all those kinds of things that we're thinking of and we're thinking of when we created rules engine and we would like to end up with rules engine. The general idea is that we wanna be able to run rules

19:56
when we get out of MVP, ad hoc on a schedule or based on some kind of internal event. So like the last one, send a pager duty alert if a critical appears in a product, that would be based on an event, right? I've had done an import, my CICD job ran whatever, I got new findings into Defect Dojo, there's a particular product that has a critical, I wanna send a pager duty, those kinds of things.

20:23
What's next for rules engine? Well, like I said, the MVP is focusing just on changing findings. Once we get that in the hands of our customers, we want to gather feedback because I have some rules I think are cool, but everybody does AppSec programs slightly differently. So we want to hear what our customers want for rules. We want to be able to add scheduled rules and event-based rules, as I mentioned, notifications from rules, and there's a feature.

20:50
In Pro, we're looking at doing sometime this year where we're actually going to enhance the targets of the notifications as well, expand them a bit. And then hopefully, like from our customers, we'll get their cool ideas and we can add them to the list of things that Rules Engine can do.

21:08
And that's it. I saw a ton of questions come in. Somehow I stayed on track, which is pretty cool. So let's go ahead and start knocking out questions.