In this first part we are going to share with you some common logical and high level steps we tend to follow to design detection logic for a certain attack technique. To make it simple and straightforward we will start with some definitions (to align) and then analyze the following diagram that summarizes big chunks of the process.
- attack technique: group of small blocks (primitives) chained to bypass a certain security control (e.g. steal secrets, elevate privileges, execute code remote or locally).
- datasource: mainly logs (host and network) and OS telemetry such as processes execution, file modifications, network connection.
- detection resilience: high level qualitative metric to measure how easy for an attacker to bypass a certain detection logic (e.g. to detect LSASS memory dump creation we monitor file creation with the name "lsass.dmp". this can be easily bypassed if the attacker has control over the file name).
- unique changes: if a certain attack primitive performs a change that happens a lot and in normal conditions (e.g. create a file with extension .tmp or .js in the user temporary directory) then this change is not unique enough and hence can't be used as an indicator of suspicious activity.
- context: if a certain change is unique enough to use it as an indicator of suspicious activity, we still have to assess if it provides enough context or it can be associated to 100 techniques.