As Mike Rothman (the Pragmatic CSO) wrote yesterday on “Incrementally Getting to Secure Code“, there are a lot of Security Managers (and/or CSO’s) who have inherited a big mess of legacy systems and infrastructure. You can’t hope to put a program in place instantaneously, especially not when you don’t have a budget for new systems. Some systems may have big holes that won’t be patched for a while. Where do you start?
One person I know was parachuted into a security management position, and the first time he read the policies and documentation from his predecessor, he says it meant absolutely nothing to him. So, its been a struggle, but he’s doing very well.

So, here are some things to consider: your environment, your skills, and your methodology. Mike covers them all well in his book “The Pragmatic CSO”. While I confess that I only recently bought his book, and haven’t finished reading it yet, I am hoping there is a section on “Triage for the new CSO”.

One thing I think you can do to start getting to know your environment is to spend a few minutes each day reading your system logs. If you have a lot of systems, pick the ones you think are most critical to the business operations.

You should be looking for login events by privileged accounts such as ROOT, SYSADMIN, SU, ADMINISTRATOR, and any personnel or usernames names whom you think might have high privileges and/or knowledge of your systems. Most consoles will log this stuff by default. Login failures are a good thing to check for; especially if there are a lot of them. Someone might have found out the ROOT password, and it might be used maliciously. Or it might just be used for some routine task in a benign way because “that’s the way it was always done”.

Either way, these accounts must be controlled and all activities logged.
Then check for status messages related to accesses. If there are databases, they should be logging major operations such as updates. The amount of data could get large, but it is important to know who is updating the data, and that they are the ones authorized to do so. In a bit of serendipity, Mike has a link today for “what to log“. Very timely.
If you don’t see any of these types of log messages, find a way to set logging levels for these types of system events, and check them daily until you have a view to what’s happening behind the scenes. If anything looks suspicious, save the logs and find someone who knows what the data means. If you don’t know if you should trust them, contact someone in the security community who can do forensics and is well-respected.

This feels a bit like sitting in a control tower, talking a student pilot in control of a 747 down to the ground. But the idea is to find out information about anything that might be a big threat today.
In the meantime, I do recommend using a systematic approach to address your whole business’s security management. I like Mike’s P-CSO approach, and I will probably add more comments on it over time. But for now, if you aren’t sure what to do while waiting for his book to arrive, read your systems’ logs.