EDR (Endpoint Detection and Response) is a valuable security layer. While Antivirus protects the system against known threats (in theory), and an IDS (Intrusion Detection System) protects a network against threats, the EDR monitors known endpoints (computer, server, etc.) in a network. The EDR installs an agent on each device in the network and relays data on system issues. The data is collected at a central server, where alerts and events can be graphed in a dashboard or sent out as notifications.

What an EDR is Good For

Since the EDR agent is installed on most endpoints in a network, data relating to individual computer stability and security is readily available. Immediately upon logging into an EDR, one can get a sense of what’s happening across the endpoints in a network. Alerts can be sorted by severity, to quickly assess the worst offending elements.

If an application is crashing on a specific computer, you’ll know about it. If someone has logged in with one access level and then transitioned to another, you’ll know. If there are numerous login failures… it’s logged.

Some EDR platforms have built in rules to validate endpoints for PCI and GDPR compliance, as well as security based measures described in the MITRE framework – providing incredible analysis across the fleet of endpoints.

What an EDR isn’t Good At

While EDR is useful, it isn’t by itself the totality of security. EDR’s weakness is that it depends on access to each machine on a network. If a threat arrives from an unknown device (such as someone gaining access to the wifi network, from their own laptop outside the knowledge or scope of the network administrator), EDR won’t detect the threat until it makes a move against an endpoint.

As an EDR requires the installation of an agent on the operating system, network devices (such as printers or security cameras) may be out of scope for EDR monitoring.

With an EDR, one also should use other security layers, such as SIEMs, IDS/IPS, and local Antivirus.

OpenSource Wazuh

There are several Open Source EDR projects, but my favorite so far is Wazuh. Wazuh comes pre-installed in Security Onion (a well known SOC in a box project).

Above is the main Wazuh load screen. It shows how many endpoints are installed, if any are disconnected (or never connected). Below that we have modules laid out by category. Security information has modules for Security Events, and Integrity Monitoring. The auditing module has elements for Policy, system auditing and security config assessment. Under Threat detection and response, we have Vulnerabilities and MITRE ATT&CK rules. Finally, under regulatory compliance, we have PCI DSS and NIST based rules.

Before discussing some of these modules, it should be mentioned that the top menu can pull up information on agents.

If you think, “this kinda looks like Elastic/Kibana,” you’d be right. Under the hood Wazuh is using the ELK stack, including the Elastic Query Language (called WQL in Wazuh). On the agent dashboard the fleet of endpoints is visible. Data pertaining to the OS version, IP, and agent status is present.

One of the most important parts of this screen is the “Deploy new agent.” This is where you can quickly come to create the curl and install parameters for a particular endpoint. Example: You log in to a laptop on the network, head to the Wazuh admin pages, click Agents, and then Deploy New Agent. Filling in the OS details, will generate the download and install string necessary for the agent. Pasting the string in powershell or a terminal (depending on OS) will install it right away.

Security Dashboard

The security dashboard loads in with a typical ELK interface. We have a timeline dropdown on the upper right, a query bar on the top left, and various visualizations below. We get a quick count of events (2006 in this screenshot), with a notice of any alarming events (level 12 or above). The top left graph shows the breakdown of alerts by severity. The top right graph shows MITRE ATT&CK rules being triggered. There are some false positives here, so keep that in mind.

Further down, a graph showing the top agents is viewable, and to its right, a timeline of aggregated events by agent.

At the bottom is a table of events, much like you’d find with Suricata and ELK.

Expanding a row in the timeline will provide details into what occurred. For example… a level 9 alert may show information on application crashes. Opening it up, we’d see the application that failed and when.

Integrity Module

The integrity module deals with issues pertaining to registry data that has been modified, added or deleted.

Threat Intel

On the MITRE dashboard a showcase of rules that are loaded is quickly made visible. In the top left, we see an endpoint and any alerts triggered on these rules.

…and Much More

As the compliance modules are out of scope for my internal network, I won’t cover those. I also passed over some granular details on endpoints. There’s just so much a person can do with Wazuh, that it’s a bit much to detail every single screen.

Reporting and Notifications

Screens can be output to reports (PDF), which are saved under the Management section (link is “reporting”).

Notifications are also possible. It supports email, Slack and other delivery methods.