Defining a logging strategy can be hard. It’s unclear what logs you will need during a Cyber Security incidents, or outage. The notion of not having logs during hard times brings fear, so often a strategy of “log the lot” starts to develop.
Why Is That A Bad Thing?
The idea of logging all brings ilusions. It also shows that no clear strategy or thought process has happened. Not only this but a common problem starts to occur. One that is known by all… cost.
The statement “storage is cheap” is correct, however storage is cheap; cold. Hot storage in large quantities has in fact the opposite result. You also then have to apply additional layers of security on top of this, to ensure integrity and recovery.
The other consideration should be hydration of data. Storing logs is easy, however if they are ever needed, how “easy” is it to hydrate? This becomes less relevant if the destination is a SIEM, however it’s still something to consider.
So I Don’t Log?
No. Instead, it would be more beneficial to first understand your attack surface, and posture. From this, you will be able to map out what areas you need to have full visbility on. Often these areas will be email, perimeter firewalls, load balancers, portals, cloud audit, identities etc…
If you are totally lost, a good way to start is by critical data and infrastructure. Once you have this, work backwards on how a person wishing to do you harm may reach them. The map should show you multiple attack chains in which you need all the breadcrumbs.
Once you have these, you can move on to working out how to generate these breadcrumbs. Within the attack chain, you will see what tools and solutions the bad guy would have to interact with before they reach the data/infrastructure.
It’s these tools and solutions that will need to have logging enabled.
So I Enable All ?
Yes and no. Whilst you mature, enabling all logging may reduce missing something you need. This however isn’t a long term strategy. Instead, the next part will be auditing and understanding.
You’ve already mapped attack chains, key infrastructure and data, however we’ve not identified the what. You can enable all the logs for say your Microsoft Azure tenant, however what are you looking for?
In most cases, logging is for governance and compliance reasons. They are there to assist with Cyber Security events and investigations. Your security teams however are not sieving through each log at a time. Instead you are most likely feeding into a SIEM. In most cases, SIEM solution have pre-defined “alerts”, however some do not.
Without the answer to “what are you wanting to alert on”, the solution will fall flat. It will keep you safe, but it will be endless fire fighting. If you have clear goals on what you want to alert on, you become empowered and controlled. You can also start to build automated remediations, response and runbooks as you know what alerts you expect to see.
So Ignore The Rest?
No. You will get there, but we are talking of a greenfield situation. Although these don’t exist in the SOC world, it can be imagined. Prioritising this effort over the flood of alerts for now will pay off in the long run, however you can’t just ignore.
The best solution, would be to run SOC alongside governance who will define the big picture. From here, the SOC can help turn expectations into results.
The Take Away
The take away from this is that there isn’t going to be a good day to start, nor a template to copy. Each enviroment is different, and so is the risk tolerance and accetance.
What we do share in common, is the need to understand the level of risk, and where it comes from. Having this, helps us to understand what we NEED to log, and alert on with priority.
This bad news is that this isn’t a one stop shop. This process needs to be repeated, as posture and environments often shift. So does the attack methods used by malicious actors. The plus is that you will be able to sleep at night knowing you have at least the minimum visibility you need should the worst occur.
Amoranio 🚀 
Leave a comment