FireEye Helix Explained: Rules

(Tess Berdiago Cahayag speaking) Hello, everyone! Welcome and thank you for joining today’s webinar FireEye Helix Explained, Multi-stage Rules. My name is Tess Berdiago Cahayag, Senior Marketing Manager here at FireEye and I’ll be your host. Let’s start by introducing our expert presenters. Sarah Cox is an instructor and curriculum developer at FireEye with over 20 years of experience working in technology and security. Joining Sarah is Mike Kizerian. Mike is a principal instructor within FireEye delivering training on FireEye’s products as well as the selection of Mandiant cybersecurity courses. Mike has held various security roles during the course of his 16 years experience from forensics investigator to lead analyst to information security engineer. Today Sarah and Mike will highlight specific functionalities within our FireEye Helix platform to boost the effectiveness of your SOC. I will go ahead and turn it over to our presenters. Mike, the floor is yours. (Mike Kizerian speaking) Excellent. Thank you. We’re going to start with just a quick reminder of data collection and how all of this data comes into Helix and what we’re doing with it. So, the idea here again is your various endpoints and operating systems that you’ve got on premise or even your cloud integrations are feeding all of this data in to Helix which is ingesting these events, parsing these events and then giving you the ability to search as well as create or leverage the rules that are already in place. In addition to that we’re going to be talking about our analytics engine as well and how that plays into alerting and detecting threats within your environment. So, let’s go ahead and take a look at our rules and talk about the overview of what a rule is. So, as the event data comes in to Helix our rules engine will analyze that information. And this provides both the built in rules as well as any rules you’ve created to take over and investigate this information and look for any potential matches that are seen. So, we can actually go in and you can do this if you’ve got your own Helix instance you’re more than welcome to pull that up and go into the rules and check out the rules coverage. So along with the rules that you’ll see there at the bottom of the FireEye rules and any of your custom rules there you’ll see this graphic in the middle for the rule coverage. This allows you to understand. How the data that you’re sending into Helix compliments with the current rule set that you have enabled. Within a 24 hour period we are able to evaluate the event data that you have to determine what we would be able to match on. OK. ..so that’s really what we’re talking about when we’re looking at coverage. It is from a detection standpoint.

Now a rule is really…

a query at the heart of it that is just looking at this event data. So, we can go in and see all of this initial information about the rule. Right? Our title what we want to name it the description that we want to give it.

But it’s this query that is going to make this rule quite effective, right? And one of the great things about this even as you’re developing your rules, we’ll see this a little bit later on when we do a demo, but you can actually create rules from queries. So once you have a query that you can, that you’ve worked through that you really like you can look at the little save as button right below that and pivot into this rule creation as you’d like. This query here though will and I looked at it there are some very important things to keep in mind with this. And one of those is that we always recommend starting these queries off with either the class or the meta class. You’ll notice as you look in here that we don’t worry about any kind of directive transform at the end. That’s because those are to help the human analyst that is looking at the data and the rules engine does not care nor does it need any kind of transform or directive to understand what is going on within these rules. We’ll have also the distinguisher, this is going to be one of the fields available in the event data that is going to help present this as a unique instance. In this instance because we’re looking here at networking data we’re going to go ahead and have our distinguisher to be the source IPV4, in other words the source IP address of the system that we would want to see sending this kind of data out. Now, there are a few other items that we can look at here. We have our threshold and interval count and the number of occurrences within this particular interval will match with this rule. And so if the query here really needed to occur five times or ten times for this to be of any kind of concern then we’d have to adjust the threshold accordingly. OK? Our roll pack is really for our convenience in organizing or rolls allowing us to keep rules that either look at similar systems or similar types of threats in an organized fashion.

And we can then establish our confidence in our severity about this rule and this query. And so this would be just how severe of a threat this is when it comes in, how confident we are that the query is is going to find and discover the data that we’re looking for. Tags is another great way to organize our data and make sure that we are able to go in and apply that sense of understanding about what this rule is looking for. We do have the ability to go in and sign rules in to queues based off of alerts so as long as a rule generates alerts like we see here they can apply and go directly into queues. Again another form of organization that can be done to assist the security teams in performing analysis. And of course as long as this generate alerts is ticked you will have an alert associated with each one of these rules. And so we do have several FireEye rules that you will see…several is underplaying the amount. There are lots and lots of FireEye rules. They’re all going to be prefixed with a number one. Our rules under customer rules will all be prefixed with a 9999 for the rule I.D. And within these we can see that these FireEye rules all belong to various rule packs. Again this allows us to go in and organize and we can take bulk action as we’d like on these these rule packs as well. Now, an example here is a very simple RDP example and as we step through and build this out, you’ll see each additional portion of this query appeared here in orange. So, we start with remote desktop as a destination port of 3389. That could be a bit, a bit noisy. Right? So, maybe we tune this a bit more so that we want to see only those RDP connections that are occurring from our internal lan to someplace external. And that’s where we can use this private IP address lan which will automatically resolve all the internal RFC standard private IP addresses here. And so we can look for the source ISP where it is equal to that and then a destination ISP where it is not equal to that. Further, delving into this we could then omit a country code that would make sense that might be the US right? Maybe we do allow certain RDP to occur within the U.S. but we don’t want to see it you know outside that or your given country. So this is an example. The one thing I would say that this is likely missing from what we did discuss earlier is you do want to and we do encourage you to prefix all of these here with a class or meta class. So in this case because this is looking at network data you would want to make sure that you have that kind of class appropriately preappended on to this particular query here. Now we can leverage regular expressions as well within rules and when we do this we do recommend inkers that is necessary. So, you can see here we have the dollar sign at the end or carrot at the beginning. You would want to make sure that you do have those in place as you’re building out these regular expressions as well as make sure that you are again adding the class, adding the meta class and narrowing in your query prior to the actual regular expression.

There are two major types of rules that you’ll see and that you can develop intel based ones as well as behavior and intel based ones are going to be very specific and they’re going to look like this. Right? For example we know if we’re looking for APT1 in there cookie bag backdoor that there is a specific proxy data that we can use. So taking that information we can now develop a very specific indicator looking for this. Again leveraging that meta class or that class at first narrowing down by user agent stream and then using this URI. Here we have our regular expression again with our anchors at the beginning and the ending of the string. So this is an example of an intel based. These are usually a bit tighter. A bit easier to nail down when we move into our behavior base. This would be something that may provide a few false positives. This could be a bit squishy depending on your environment and what you’re looking at. For example Windows firewall stop unexpectedly looking here at the Windows event ID of 5025 with the message stopped. Well early on in my career I spent time as both a desktop and a server admin and desktop admin server admins as we need to we will play with services and and do whatever we need to as we’re troubleshooting a particular system even to include taking down the Windows firewall if necessary. And so while we can go out and create a rule that would look for this any time this would appear it may need a bit of further investigation. To be sure what we’re looking at in this particular case is actually a threat versus just an admin that’s troubleshooting. Now I’m going to turn over the presentation to Sarah. She’s going to talk through a bit more with the analytics engine, lists and one of the other big features that we want to look at which is actually the multi-stage rules. Sarah the time is all yours.

(Sarah Cox speaking) Thanks, Mike. So obviously the presentation today is going to be focusing on rules and multi-stage rules but we did want to talk about the analytics infrastructure as it plays into generating those MSRs and also to talk about list because it’s an important and easy piece of detection that you can leverage. So, just as kind of a note here in terms of your detection you can leverage the Intel match list type very straightforward feature to leverage. When you’re on the list page you can click on create list and essentially you’ll get a pop up that lets you define the list type as intel matching. And then any value that you add on that list are going to be treated as an intel match and generate hits. And so this is a very straightforward piece to leverage. And you can add look at indicators like IP addresses shown here are fully qualified domain names and MD5. And of course you can also manage these using the API. So again very straightforward but we wanted to make sure that we covered that this was a very easy detection option to leverage. I also want to talk a little bit about the analytics infrastructure. So, at the start Mike talked a little bit about the process of ingesting events into Helix. And so as events are indexed and parsed in our environment in the cloud we have various engines that run against them. And the analytics engine is one that is applied to events in conjunction with the rules engine. And what the analytics engine allows us to do is to do some more behavioral based detections along the lines of what Mike had talked through with the Window firewall stopping. So, with analytic events we don’t necessarily want to alert on those, but you do want to have the ability to review and make some judgments… professional judgments on that activity. And so FireEye provides those analytics through the analytics rule pack which we can see here and we have our rule IDs and just like rules we could click through and see the intelligence behind those. And so just to highlight a few of the analytics that we’re able to detect based on the data that you’re feeding in, we can look for beaconing activity finding regular intervals between IP connections. So, not just a single event but looking at activity over a span of time differential beaconing, as well geo feasibility. So something like a user logging in one geographic region and then a very short time span logging in from another area that might be possible maybe through some configurations of systems or VPN in some way or it might be anomalous and suspicious. And so we want to be able to point that out and have the analysts have the ability to review those. So, these analytic detections are not alerting in the same way as rules but they are identified and then we have the ability to build dashboards and run searches on them. You can see some more examples here. But of course if you’re in the UI and you’re trying to understand what coverage you have, another piece that you can leverage is to go to the analytics tracker. This is a FireEye provided dashboard. If you go to the dashboards menu on custom dashboards you’ll see the tracker listed there. And what’s really helpful about the analytics tracker is not only does it give you access to the types of analytics that FireEye provides it also gives you concrete information about the types of analytics that would apply in your own environment. Every environment has different data that set in based on what you’ve configured. And so we can see here on the left hand side based on the data from this environment this is our training environment. We have just a handful of analytics that we can detect. And so that’s useful. But if we wanted to extend it we could review the unsupported analytics to get a sense for the queries and the type of data that would be needed to be able to detect those. And simply by adding those data sources we would get better coverage. So, while this training seminar is more focused on rules and MSR we do want to make sure that you guys are aware of the analytics engine and the different ways that you can get insight into how analytics are working in your environment. So, moving back to rules. Mike showed you some kind of examples of rules. We want to cover the nitty gritty. “How to” working with rules. I’m going to take you through a few of those. This is all pretty straightforward. The UI team has done a fantastic job. It’s very intuitive to create a rule in the UI. But, of course we don’t want to leave anything to chance. So we’ll just talk you through creating those rules. From the rules page when you click the little button you’re going to get the pop up. Of course you can do all of this through the API as well. We’ll use the UI. So, in this example we’ve got a rule that we’ve created. We’re giving it a name. Yes. We’re 100 percent going to take time to write a meaningful description. We can add tags so that this rule is manageable for any one else using our environment. And then the meat of this is going to be the query. And we’ve seen several examples of that. So, we’ll define the query which we tuned and developed through our search and then we’ll use distinguishers in the threshold and the time window. We did have a question about, if there is any difference in the syntax between rules used here and rules in search. So, through our presentation Mike and I are trying to call out some of the specific details. So as one example Mike mentioned when you’re creating a rule you do always want to include either a class or a meta class. So we want to make sure that we’re writing our rules in a way that is efficient for our engine. And so that’s one way that we can do that. So, this is the rule creation screen. We do have the ability to have the rule enabled or disabled. So if we did have a rule in our environment that was alerting maybe more than was helpful we could disable it. And that gives us time to address it. And then we also have the ability to have alerts generate or not generate from a rule. Now, you might ask yourself if I have a rule why would I not want to have it generate what. We’re going to see an example when we get into the MS rule creation where we want to use the alert to identify specific activity and create a match…sorry…we want to use the rule to find those matches. But, we don’t necessarily want to generate an alert because we’re going to use that match in a different way. And so we do have the ability to have alerts generated or not generated any time a rule matches we’ll get the underlying event that we can search. So, that was for an individual as you’re creating you can obviously define the settings if after you’ve created a rule you need to make changes from that rule table or you can view the status and then we can click either on the rule name or take action from the gear icon in the action menu. Again pretty straightforward but we want to make sure we’re covering all of the options that you can take advantage of in the UI. Here we can see a rule where the generation has been disabled and this particular slight example comes from our MS rule creation. We’re going to talk you through an example. This was a MSR for the suspicious command run by a new user. I see it’s actually cut off a little bit here but this query is kind of the first stage rule. And so we’re not going to generate an alert on that. And we’ll talk you through an example so you can see it in practice. But, the rules that you create and for FireEye rules you can tune the query and let me talk you through the benefit of that. In this example we can see this is a FireEye provided rule while looking for Dridex activity. We get based on the description a sense of what the rule is looking for. The original query is actually obfuscated. And what that allows FireEye to do is to have the leading intelligence available in use for detection in your environment. But we’re not providing the details of that. And we know with these intel based indicators they’re highly effective at finding attacker activity but they also have lifespans. Right? So, as soon as the attacker is aware that we’re aware of what they’re doing they can change their tactics somewhat easily in terms of using a different domain or different IP for callback. And so by not providing the specific details in the query we’re hoping to give our rule a little bit of a longer life. But we still want you to know that you have this coverage. And so we’re giving you the description. And this should give you enough information to understand the data sources that are used for detection. Regardless of whether you can see the query or not you can tune the query. So we’re not going to change the underlying query when we tune it but we can click on the tune query button here and that’s going to give us a pop up and we can add MQL that would be added to the end of the rule and the benefit of that is if FireEye decides to tune their intelligence because we have some updated information. We can provide those updates and that rule that you have not affected the underlying intelligence of the rule. You were just adding MQL to the end of it. So this query gets tuned with whatever additional statements you’ve provided. We also talked in our last seminar on lists and MQL that we have a global exclusion list so you can set up a list exclusions.global.IPV4 and any addresses any systems that you add to that list you can, that would be automatically configured to not alert. So let’s say you have a vulnerability scanner that’s expected to be identifying threats. We don’t necessarily want that to alert every time it encounters one because we’re expecting that. And so we could add that to the global exclusions list. So, that’s a second way that you could tune a rule both through tune query and through setting up that global exclusion list you can also adjust the threshold in time on the rule. That’s going to override the default settings provided by FireEye.

Also want to point out as we are making matches to data coming into the environment we have the raw events that is maintained and indexed. And so those index, those fields are getting parsed out. And when we have a rule match we’re going to append metadata to that original event on that match. And this can be leveraged for searches and building contacts around any matches that you have in your environment here. So some of those fields are rule appended to detect rule ID to the original event. We’ll also add the detect rule name. And so this would allow you to have a specific alert. We could search for other events that have that same alert name and build context about any related activity in our environment. And we can also search undetectable matches this is a JSON object containing metadata for the rule match. So, as an example here we can search on the tag field within that JSON for specific tags. So again data that we see in the UI for a rule and in the alerts we can also leverage the search. I talked through rule tuning which is a great option for FireEye rules. If the FireEye rule or your rule is really not working the way you want it to, you can also clone it. Any time you have an alert you’ll see the query syntax and you can copy that and then create a separate rule for it. So that’s an alternate way to handle a rule if you need to make changes. If you’re planning FireEye rules just keep in mind if we push updated intelligence you’ll lose those updates because you’ve actually created a copy that you’re modifying. So, I do recommend exploring the tuning options first. So needed to give you that background so that we can set the stage for creating multi-stage rules so I’m going to hand it back over to Mike whose going to talk you through that. And I think he’s got a demo.

(Mike Kizerian speaking) Excellent. Thanks Sarah. Thanks. So yeah we’re going to talk through these these multi-stage rules. We’ll look through this and then we’ll jump into a a demo as well. So, multistage rules… there are a number of examples that can be used here. And so with some of these multi stage rule examples here really the idea behind this is that it gives you the ability to tie together events that have a common thread. So one example that we’re actually going to step through here would be a newly created user with some suspicious commands that might be executed. This is a fairly straightforward one here. And there are two main components to these. These each exists as separate rules and the first one would assert a fact to which the second one would depend on that fact in order to bring in the information, look for that particular user, which would then kind of complete that cycle of a multi stage rule. So, as I mentioned you have these two concepts of an assertion and a dependency and these both actually exist in rules. We’re going to take a look at that and and walk through this with some rules that we’ve actually created. And then we’ll look at…

how we can set this up in our environment a query to to look for this information and then look for the final multi-stage rule executing. So, in this it’s probably easier to to just jump into the demo at this point but I will point out here that the multi-stage rule logic does run in the analytics infrastructure and it does produce an analytics event as well. And then this process is every four hours. So, let’s jump in and take a look at the demo. So, everybody should be seeing my Helix instance here at this point. I’m going to start with some rules that I have tied together. So, the first one that we’re doing is actually a very straightforward user creation within Windows here. And it’s this Windows methodology for a user created. Whenever a user is created we will see an event ID of 4720. Now this is a FireEye built in rule. And you can see here for the assertions that there are four of them and these assertion names are simply variable names that you assign and then reference again when you’re creating the second stage of this multi-stage rule. They do have a validity in this case. This is all built in. If you wanted to though you could create your own in which that validity may be a bit smaller in time frame if you needed to. And then the assertion field in this case is username or target username. So, if I wanted to use this that means that my second rule would need to depend. And I have a dependency built around the assertion here and I’ve done that under my customer rules. What I did was created a rule here for some suspicious commands. Now these here weren’t terribly unique. There wasn’t anything too crazy about these. And I did use the audit process logging here in order to key in on those with the event ID of 4688. But the critical component here is down under the dependency. You can see here that this is referencing the FireEye Windows new user which has a time validity of 24 hours and the applied field is user name. And the distinguisher here is tied as well to the username. So, those actually look if we were just to pull this information up in a brand new rule it’s right here under the advance section we need to make sure that we have to a distinguisher. And then this is where we can add our assertion. The assertion name again is just a free form text. The assertion field is actually going to be tied to these distinguishers. Something that we want to focus in on and then we can set it for hours or minutes. The second stage would forego the assertion and just add the dependancy picking on one of these assertion names that had been stored. So, once they execute I’ve generated some of this traffic here in our environment we can see off one system that we went and had a user account was created and within a short amount of time later we have this process created as well. And in an effort to go ahead and find this traffic or to verify that this had hit once the analytics engine successfully captured this data. I’d actually be able to see it. We don’t see it here quite yet as it’s not run and captured this but we would have that application of a multi-stage rule. The final application of this would be a actual third rule to look for that particular event. Remember when we’re looking at these analytics here the class analytics these are all synthetic events, right? And so we can actually go in and create a rule that would generate an alert on that specific instance. And so as we actually go in and look at that. ..you can see here at the very end of the detection options what that query may look like right where we’re looking for the class analytics, the application of multi stage rules and then the very specific detect rule ID in order to discover that that query would be placed in a third rule that would actually alert. And as we’re creating each of these rules we can forego the alert piece on that and just have these as detections.

So that brings us to an end here of our initial presentation as well as the demo and we’ve got some good time I’m going to turn this back over to Tess. (Tess Berdiago Cahayag speaking) Awesome. Thank you, Sarah and Mike you both provided some great insights. So, let’s go ahead and get the Q&A portion of our session started. But before we do that once again I’d like to welcome Todd Bane, Manager of Deployment and Integration with Mandiant and Dustin Siebel, Senior Manager in Detection Research at FireEye. Both will be joining Sarah and Mike for the Q&A. So, let’s start with our first question. The question is, Is there a limit to the number of stages you can use in MSRs? In other words are they always just two rules or could you have a chain of three or more rules? Should each rule depend on the one rule before it or does the final rule in the chain depend on all the other rules? (Dustin Siebel speaking) Hi everybody. This is Dustin there technically is not a limit to the number of stages there is a limit to the amount of time that we will persist the entire scenario, which I believe is up to three days. And so to the point of chaining different rules together, yes each stage is going to be dependent on the previous stage. Right? So, if you start with a new user being created that must be satisfied first before we look into you know if there’s a suspicious command. That must be satisfied if there’s any other checks after that. The same logic will follow. But, but no there’s really technically not a limit on the number of stages just just the amount of time that we continue to check.

(Tess Berdiago Cahayag speaking) Perfect. OK another question here, How often does FireEye push out rules and how do customers get notified? (Dustin Siebel speaking) This is Dustin again so we so we actually have an automated release process that happens every weekday around the middle of the day, Eastern Time zone. So, we don’t always push out new content. So this job runs regardless of new content is available. You know we generally will release it when it’s ready. So we we do a fair amount of testing, peer review, et cetera before content is released. And once it is in essentially the staging area then it will automatically go out to every customer. In terms of notifications every time that we release new or updated rule content or dashboard content we will update the there’s a little in app notification system. So, you might see a little you have a message waiting for you when you log in that will contain just a brief summary of of any of the relevant content changes. And then another tip is if you just go into the rules page in Helix and click on the FireEye rules those are all sorted by default by the creation date. So, all of the newest rules should be at the top. So that’s just another easy way to… to drill into those.

(Tess Berdiago Cahayag speaking) Excellent. Thank you. Another question we’ve got in here is, Is there a way to close alerts in bulk or move them into a different queue?” (Todd Bane speaking) Hi, this is Todd Bane with deployment and Integrations, so there’s a few ways that you can do both closing through web UI and also API. So if you’re in your Helix screen and you look at your alerts you can select multiple values there and then close them out that way by using the menu dropdown when you selected those objects. But you can also use API as a means of closing them out or suppressing them. So you have a few options there. We also have an orchestration platform that can handle bulk requests like that through the API as well.

(Tess Berdiago Cahayag speaking) The next question, Is it possible to have a list automatically update once a day or once an hour for example to make use of the Tor IP list or the, I’m not going to read out the url or the url has recently reported malicious url list? (Sarah Cox speaking) So, I can grab that one Tess. To do those types of automations you would need to work with the API or leverage the automation of the FireEye security orchestrator that Todd mentioned previously but through the UI is manual.

(Dustin Siebel speaking)I will ask that one thing we do include in our daily release we do update some open source lists. I know like News Tracker has been one which I think some of those trackers now shut down. But so those happen every every weekday during our normal content release process.

(Tess Berdiago Cahayag speaking) Excellent, we’ve got another question, You mentioned using API to close alerts. Is there a guide or webinar on how to use the Helix API? (Todd Bane speaking) Yeah, this is Todd so to respond to that yeah we’ve actually got a few materials out there. Helix itself has the swagger documentation you can use for the Helix API itself. We also have some “Tips & Insights” videos on introduction and access to the Helix API. And you can find that publicly on YouTube.

(Tess Berdiago Cahayag speaking) Thank you. Next question, Can alerts trigger a pre-defined or custom action such as create a ServiceNow security incident?” (Todd Bane speaking) This is Todd Bane so yeah for taking custom actions like that typically we’re doing that through API calls or kind of the more popular instances of that is with the security orchestration type tools or other automation platforms and that kind of fashion. It’s not a native integration that we have today.

(Tess Berdiago Cahayag speaking) Got it. Thank you, Todd. Next question, Will Helix help to monitor a hardware alert? (Dustin Siebel speaking) So, if it’s in a FireEye appliance there are some native integrations there where there is some built-In monitoring of those like for example you can, you can look at a dashboard to see which of your… NX or HX appliances are connected or disconnected et cetera. Beyond that if it’s custom hardware right? So, if there are some logs that can alert you if there are some type of hardware problems then certainly you could create rules for that. We probably don’t have much in the form of stock rules for that type of thing. But I imagine it should be a fairly straightforward custom rule given the right data.

(Mike Kizerian speaking) I was just going to add as long as the hardware, whatever hardware events are coming in and make it into Helix like Dustin said you can create your rules for monitoring that. So you just need to kind of keep that in mind. However your hardware is is exporting that kind of event data.

(Tess Berdiago Cahayag speaking) Awesome, thank you. All right, Is there a way to view all FireEye rules i.e. all FireEye made rules and analytics or can we only see/view rules that are applicable to our environment? (Dustin Siebel speaking) Yeah you can view all the rules if you go to the rules page and go to the FireEye tab that’s the same list of stock rules that every customer gets. There is an option where some rules might have some, what we call protected query logic where we don’t expose the query just for maybe some intel reasons or whatever the case may be. But if you do happen to get an alert for that rule then at that time the query is exposed. Analytics are a little bit different in than you know it’s a separate engine and we don’t really have a native UI in Helix right now for the analytics themselves but there was the dashboard it was mentioned earlier in this webinar that does list all of those currently deployed analytics. And that data set is dynamically set once a day to the customer. So if we do add something in the backend you should see an update there. (Sarah Cox speaking) I really like the distinction of like what roles are available and for review which is all of them. And then thinking about the coverage. Right? Because we can have the rule that if a customer doesn’t have the data feeding into it it’s not ever going to lead to detection. And so you do need to think about those two pieces hand in hand. And so when you go to the rules page you are going to see the full list of rules. And then there’s the widget at the top which you can expand or collapse and that’s going to show you your coverage. And so beyond just looking at what is available when you identify rules of interest you do want. You can cross-check to see that you actually have the data that will lead to detection.

(Tess Berdiago Cahayag speaking) Perfect. Thank you, Sarah.

I think that’s probably going to be the last question that we take. So, we will be closing out our webinar. For more information on today’s topic as well as many others please visit www. fireeye.com/Helix. Again thank you for joining us. And thank you to our team of experts. Thanks so much. Bye bye.

This webinar was recorded on August 25, 2020.

Experts from FireEye Education Services explain and demonstrate rules in Helix.

Topics include:

  • Improving FireEye Rule coverage in your environment
  • Tuning FireEye Rules to maintain a manageable flow of alerts
  • Creating custom Rules for detection
  • Creating multi-stage Rules to detect threats across multiple event logs
  • Demonstrations including identifying rule coverage, creating rules, and building multi-stage rules

The webinar is followed by an in-depth Q&A session.

Scroll to Top