In this installment of the Tips and Insights series, Dan Smithson explains the configuration of e-mail alerts across FireEye’s Helix platform.
Hello my name is Dan Smithson and I’m a System Engineer with FireEye. Today we are going to walk through the configuration of e-mail alerts across FireEye’s platform. For today’s purposes we’re going to look at two specific interfaces and how we would configure email alerts in those two different instances. One would be a top level view using our Helix platform interface which we refer to as the brain of an operational SOC. This dashboard provides a top level investigative tool which provides alert management, case management, investigative work bench as well as some investigative tips for junior or senior analysts within your environment. We also have the ability to directly connect in our visibility sensors which we refer to as spokes with Helix being the hub. Those visibility spokes are including things such as email, network, endpoint and other. Those technologies can be obtained separately but in the context of today’s talk we are actually looking at Helix which is having all of those rolling up into it and therefore any alerts that we configure within Helix will apply to each of the constituent technologies feeding it. Within Helix all settings are configured through a little widget on the upper right hand corner that has a little person on it. If you click that picture there. And you click on Helix settings. You go to the notifications dashboard. Within Helix, the way that notifications are sent is actually natively from the Helix environment. So no external email server is required in order to forward on those emails. It can be natively sent from within Helix. Also because Helix is a rules and analytics engine by design it has the capacity to make decisions on when to send alerts on criteria other than simply an alert was generated. It can go entirely based upon the severity of the alert. This is important in terms of reducing the amount of noise within your environment so that you can focus on the priority alerts instead of chasing a bunch of hay when you really need to find a needle. So for today we’re going to click “ON” and that’s going to enable all alerts within Helix to be notified according to the rule policy we have here. Under the alert level you can see there is four subcategories: critical, high, medium and low. These correspond to the badges that you see within Helix on the main dashboard for each individual alert. As you can see it’s as simple as clicking a radio button to decide whether you want to send no e-mail or e-mail every alert. You can also see that beside each of the subcategories we provide an average number of alerts that are being received by the Helix environment per day so that you can make operational decisions as to how the impact of those e-mail notifications will affect your day. On the right hand side we can also see a summary. This summary provides an overall number of emails on average per day that are being received and therefore the total estimate that would be sent to myself the user of this helix interface who’s ultimately going to be sent to those e-mails. Because Helix is managed through an infrastructure access manager everything is user controlled based. So whoever happens to be logged into the Helix dashboard is configuring their notifications for them-self. Those notification policies will not apply to others. Now let’s take a look over at a different interface perspective. From this angle I’m taking a look at our command module our central management server if you would that’s basically controlling the physical updates and the day to day operations of multiple appliances in an environment. These can include virtual or physical appliances and can also include on premise and cloud based appliances in some cases. From the main CM dashboard, if we go over to settings and click on CM Settings we will ultimately see the settings configuration tab for our command module command system here. When I click over on the settings side I can see there’s a notifications tab that if I click on notifications it gives me the opportunity to send out different types of events and I can send them out via various different formats. As I scroll down I can choose do I want to enable email based notifications. If I click over here on the SMTP button at the top it will take me to the sub configuration tab for my SMTP notifications. Including such details as the domain, the SMP server that will be forwarding my emails and what formats I want it to be sent in. I can also here list any users I want to be included as the recipient of these emails. So from this perspective as opposed to Helix when I configure an alert and a notification I’m actually configuring it across the environment and it can a policy base as I choose who I want to send to. Whereas in Helix as I alliterated before it’s an individual decision that you’re making for yourself and it does not have a direct impact on the others in your environment. And that’s how we configure email alerts on the FireEye platform. Thank you for watching and stay tuned for more tips and insights.