Back
The Value of Detective Controls
For as long as I can remember, security professionals have spent the majority of their time focusing on preventative controls. Things like patching processes, configuration management, and vulnerability testing all fall into this category. The attention is sensible, of course; what better way to mitigate risk than to prevent successful attacks in the first place?
However, this attention has been somewhat to the detriment of detective controls (I’m intentionally overlooking corrective controls). With budget and effort being concentrated on the preventative, there is little left over for the detective. However, in recent years, we have seen a bit of a paradigm shift; as organizations have begun to accept that they cannot prevent every threat agent, they have also begun to realize the value of detective controls.
Some may argue that most organizations have had detective controls implemented for years and, technically speaking, this is probably true. Intrusion detection and prevention systems (IDS/IPS), log aggregation and review, and managed security services responsible for monitoring and correlating events are nothing new. However, in my experience, these processes and technologies are rarely as effective as advertised (IDS/IPS can easily be made ineffective by the noise of today’s networks, logs are only worth reviewing if you’re collecting the right data points, and correlation and alerting only works if it’s properly configured) and far too many companies expect plug-and-play ease of use.
Detective controls should be designed and implemented to identify malicious activity on both the network and endpoints. Just like preventative controls, detective controls should be layered to the extent possible. A good way to design detective controls is to look at the steps in a typical attack and then implement controls in such a way that the key steps are identified and trigger alerts.
Below is a simplified example of such an approach:
| Attack Step | Key Detective Control |
|---|---|
| Gain access to restricted network (bypass network access control) | Network access control alerts for unauthorized devices |
| Discover active systems and services | IDS / IPS / WAF / HIPS; activity on canary systems that should never be accessed or logged into |
| Enumerate vulnerabilities | IDS / IPS / WAF / HIPS; activity on canary systems that should never be accessed or logged into |
| Test for common and weak passwords | Correlation of endpoint logs (e.g., failed login attempts, account lockouts); login activity on canary accounts that should never be used |
| Execute local system exploit | Anti-malware; monitoring of anti-malware service state; FIM monitoring security-related GPO and similar |
| Create accounts in sensitive groups | Audit and alert on changes to membership in local administrator group, domain admin group, and other sensitive local and domain groups |
| Access sensitive data | Logging all access to sensitive data such as SharePoint, databases, and other data repositories |
| Exfiltrate sensitive data | Data leakage prevention solution; monitor network traffic for anomalies including failed outbound TCP and UDP connections |
This example is not intended to be exhaustive but, rather, in meant to illustrate the diversity of detective controls and the various levels and points at which they can be applied.
While every environment is slightly different, the general rules remain the same: implementing controls to detect attacks at common points will greatly increase the efficacy of detective controls while still sticking within a reasonable budget. The one big caveat in all of this is that, in order to be truly effective, detective controls need to be tuned to the environment; no solution will perform optimally right out of the box. At the end of the day, proper application of detective controls will still cost money and require resources. However, the impact of an attack will be reduced substantially through strong detective controls.
