Detection engineering

A sidebar about the popular process for gaining observability

Detection engineering is the process of writing rules inside your SIEM - or events dashboard (EDR, logging, other) - that highlights suspicious behavior when seen on an endpoint.

Rules come in different varieties, depending on what backend system being used, but can be thought of as SQL statements for finding malicious behavior. This process has become an essential process for security teams, especially purple teams, to identify breaches or security events in quick order.

The biggest issue with this process is it is (almost) entirely reactive. Adding the rules is the proactive step but once an issue is spotted, the threat actor is already off and running and the game is now to catch, eradicate and patch the impacted endpoints.

What if there was a better way to approach this problem?

Using Prelude Detect, you can run Verified Security Tests around the clock. Each test continuously attempts to break a "rule" that should never be broken. Your EDR should quarantine malicious files - that's a rule. If breakable, you have a weakness that an adversary can take advantage of by dropping a piece of malware on the computer and setting up command and control infrastructure.

Detect can validate this, and many other rules, daily and warn you (proactively) when rules are being broken.

This process can drastically reduce your reliance on detection engineering practices and convert what used to be your primary way of "doing cybersecurity" into a backup plan.