I heard a rather distressing story last night. A major tech company\u2019s security architects routinely demand requirements like this example:<\/p>\n
\u201cSend all logs to security\u201d<\/p>\n
This is so bad on so many levels.<\/p>\n
What does \u201call\u201d mean?
\u2014 Every debugging instrument in the code? That should slow performance down to a crawl. It might even log sensitive information and leave plenty of \u00a0clues about how to exploit the code (\u201cinformation disclosure\u201d).
\u2014 Every possible item in every log that the code makes?
– debugging
– behaviour
– performance
– scale
– etc.
Astute readers will note that some of these are probably at best, only marginally of security interest.<\/p>\n
Consider what the inundation of log detail does to the poor analysts who must sift through a mountain of dross for indicators of compromise (IoC). That\u2019s not a job I want.<\/p>\n
If you\u2019re giving your developers requirements like \u201csend all logs\u201d, you are causing far more harm than good.<\/p>\n
Any savvy developer is going to understand that most of what their code logs isn\u2019t relevant (until perhaps, post-attack analysis. It\u2019s good practice to archive runtime logs \u201csomewhere\u201d).<\/p>\n
Slamming developers with unspecific, perhaps impossible requirements burns precious influence in a useless firestorm. You\u2019re letting your partners know that you don\u2019t understand the problem, don\u2019t care about them, and ultimately, do not offer value to their process.<\/p>\n
As I\u2019ve said many times, \u201cDevelopers are very good at disinviting disruptive and valueless people to their meetings.\u201d<\/p>\n
Besides, such \u201crequirements\u201d are lazy. If you throw this kind of junk at people, you aren\u2019t doing your job.<\/p>\n
Our clients routinely ask us what they should monitor for security. We consider the tech, the architecture, the platform very carefully. To start, we try to cherry pick the most security relevant items.<\/p>\n
We usually offer a plan that goes from essentials towards what should become a mature security operations practice. What to monitor from application and running logs typically requires a journey of discovery: start manageably and build.<\/p>\n
\u201cAll\u201d is a lazy, disinterested answer. Security people need to be better than that.<\/p>\n
Cheers,<\/p>\n
\/brook<\/p>\n","protected":false},"excerpt":{"rendered":"
I heard a rather distressing story last night. A major tech company\u2019s security architects routinely demand requirements like this example: \u201cSend all logs to security\u201d This is so bad on so many levels. What does \u201call\u201d mean? \u2014 Every debugging … Continue reading