Within the security industry, generally you can detect threats in one of two different ways. You can detect it using behaviours/anomalies or using known activity detections. When using behavioural indicators and anomalies this is seeking to identify ‘strange’ or ‘unexpected’ behaviour. The thing to remember though, is that generally a human exists in that chain somewhere and there are few things which can behave more unexpectedly than a human. This means that in practice, what is theoretically able to present highly targeted anomalies security detections also often also triggers when humans do benign, but unexpected, things.
If we contrast that with known detections (often called signature detection), the nuts and bolts behind those are what are referred to as IoCs (Indicators of Compromise). Simply reading the name, you could be concerned that they represent known and definitive evidence of a clear breach; if you see this happening then start pulling out cables and waking C-suite up. Still, humans are involved somewhere in the chain and that means in practice that these IoCs are less definitive than the name sounds. Very few things in life are certain, and IoCs are no different – the important word to focus on is “indicators”.
These indicators can exist within almost anything – IP addresses, log message contents, file paths etc. The terms are intentionally broad that it can take almost any form and the form does matter. If we take an example of an IoC which is an IP address for example, IP addresses are easy to change (particularly if they come from cloud services like AWS). Generally, one may find that IoCs of this type have a shelf life given they are held within a resource which is liable to change. If we contrast that with something like an exploit string (which might be observed within network traffic) then generally an exploit string is absolutely needed to carry out a given exploit; its unlikely that this can change much, or the actual malicious activity wouldn’t have the chance of being successful. So, some IoCs have a shelf life, and some don’t.
Another important context for an IoCs is where in the environment you find it. If we have an IoC as an IP or an exploit string being found in inbound, blocked requests on a firewall that doesn’t warrant a concern. That represents existing security controls reporting on them doing their function and should be monitored and acknowledged but couldn’t be considered evidence of a compromise. However, if such were found going outbound over the same firewall, then that becomes very immediately concerning. So, it isn’t enough to have an IoC – it very much matters where the IoCs is observed.
These IoCs might be presented to you via any number of different avenues. You might have a partner (say, your firewall vendor) who sends out a bulletin which contains IoCs or you may be contacted by law enforcement for your domain (say, if you work in finance or banking). You may also come across an article online which seems relevant for your operations or technology. In all those locations you need to understand what the likely shelf life of the IoCs is, how you might find them in your environment and how you would interpret them once found.
The first thing would be to take those IoCs and apply them within the security controls in place. You should identify which of them are more time sensitive and seek to have those added first. Then ensure that there is a concrete process in place for how you take those IoCs and apply them quickly and correctly to each of the security technologies in question. Finally, ensure that you have staff who have a responsibility to ensure that alerts or activity from within those security controls are reviewed on a regular basis. IoCs are important, but only as important as the technology and humans who can interpret them and put them in context of your business.