Non-Slacker Friday: More Thoughts on Continuous Audit

Back in January I posted
SSH keys: An Argument for Continuous Audit SSH keys: An Argument for Continuous Audit. I hope you take a moment to read that (only 467 words) post.

However, that was a very specific example of the usefulness of continuous audit, and I would like to generalize that a bit.

For a number of years I've written software (fp: fingerprint) that attempts to evaluate the security posture of Linux systems. That has mainly been focused on the Red Hat family, with a digression into SLES. It has recently come to my attention that some truly ancient versions of fp are still being run, long after it should have been updated, or simply retired.

Admins should have been shouting about this, and likely were, as some were extremely professional. Be that as it may, there is fp code, still in use, that does things like call 'ifconfig', which ships with the net-tools package. If I query a recent version of this package, I get:

The net-tools package contains basic networking tools,

including ifconfig, netstat, route, and others.

Most of them are obsolete. For replacement check iproute package.

That is just one example; there are many more in some of these ancient versions of fp, pertaining to storage, sudo configuration, SELinux policies, modern pre-linking, etc. It is illustrative in that this stale software cannot accurately record bridges, network devices which are configured but may be up or down, IP6, etc., when run against recent versions of the OS. Given the numbers of enterprises which have been breached via network connections that had fallen through the monitoring cracks, that is important.

Some of this old code is running in PCI-DSS environments, which represents an enormous risk that may be not have been correctly evaluated. For a possibly worst-case scenario, you might read
Target Provides Preliminary Update on Second-Quarter Expenses Related to the Data Breach and Debt Retirement. I say 'possibly' because greater losses are only a matter of time, if history provides any guidance. It is also useful to realise that this 2013 disaster is on-going, nine months or so later.

Am I Just Peddling My Services?

I have no idea, and am acutely aware that this is not an ideal business plan. It is certainly a component, as we all have to make a living, and consulting does that. On the other hand, I ocassionaly become so frustrated at the whole sorry state of affairs that I am tempted to open source all of the fp and hardening code. I am not reaching enough people to make a difference, and making a difference matters. Another benefit would be associating with even more great people. That matters too.

Log Analysis (Still) Matters

fp and harden have always written log files, and all but the earliest versions have been able to store data in a manner that was amenable to centralized analysis. This has never been perfect, but it seemed to me that it met a certain standard of usefulness. I won't quote statistics here, because I have already done that, in July, 2013. See We still fail at log analysis.

But I will agree with common knowledge in the security community: logs are written, but seldom read or analyzed.

I would go one step further: they are even more seldom verified, and analysis almost never includes tests for sensitive information that might be written by programs executing in a 'debug' mode. That last bit is often exacerbated by log files often being poorly protected.