As the company's security department, our system administrators ask us what they need to log for SIEM (Security Incident and Event Management). We don't have any prepared documents and are seeking something that combines the combined wisdom of COBIT, PCI, etc. in a way we can present to other departments.

  • 4
    You're a security department, but you have to ask for guidelines on what should be logged?
    – EEAA
    Aug 8 '11 at 15:24
  • Are you talking about documentation on SELinux maybe?
    – djangofan
    Aug 8 '11 at 18:14
  • 3
    @ErikA That's a very important question to ask that will always be open to discussion. Not only what material needs to be logged, but how an audit trail should be constructed, etc. All professional sectors work on establishing guidelines. Further, this question is asking about conveying that information to a non-security department. Knowing the material and effectively communicating the concepts to others are two equally respectable tasks.
    – Jeff Ferland
    Aug 8 '11 at 19:22
  • 1
    @Jeff - agreed that it's an important question. However, the OP showed zero evidence that they have any idea what sort of things he's looking for, so as far as we're concerned it was a "please do my job for me" type question, which are not appropriate.
    – EEAA
    Aug 8 '11 at 19:28
  • 1
    @daveCourago, welcome to the site! ErikA is correct that this question is missing some key bits of information, please see the FAQ. Specifically, you should add some context, types of systems, risk profile, etc.
    – AviD
    Aug 9 '11 at 13:52

This is a mind-blowingly huge question. What you need to log is business specific need. Typically, you want to log administrative logins and changes. But still that is pretty basic. What you need is a better understanding from the people who drive you organization on what systems are important. A good business continuity plan with some risk assessments will drive you far.

I am realistic, and I know that getting that is probably a non-starter. So can I offer this, if you are trying to tune your SIEM product, don't just slam everything in there at once. Pick something, like Network Switches and get those sending logs and tuned up before you move onto the next thing, say Domain Controllers.

You want your SIEM to only be notifying you of a problem, if you are inundated with 400 alerts per day, your SIEM tool is almost worthless and you should've just deployed a syslog server and saved a bunch of cash.


Here's a simple answer: Log everything.

Everything that can be captured, send it along to your SIEM server. Your focus should be on selecting and implementing an SIEM server that can handle that volume of data and can be used for alerts and reports that provide meaningful security-related information without too many false positives.

You should not focus on determining what is or isn't important and squelching messages at the source. If you're wrong, then when you need the data, it'll be gone or scattered out at the endpoints, with the only copies on possibly compromised machines.

If you gather everything to your central SIEM, then you've got a forensic copy in case an endpoint machine is compromised. Where you would have had to tune which logs to forward, now you only have to tune which logs to process for your alerts and reports. And if it turns out that you needed something you thought unimportant, then you have it, right there and ready for the centralized searching that SIEM provides.

The downsides are:

  • Disk space requirements to hold all those logs
  • SIEM software fast enough to handle a huge log database
  • SIEM software smart enough to support concise queries

The upsides are:

  • You'll have all the logs you need, even the ones you didn't think you'd need
  • Your guidance for the system administrators becomes dead-simple
  • 1
    Not sure how realistic it is to ask system administrators to log everything. They may refuse this request as logging everything may degrade the performance of their application or on the other hand if your not prescriptive with what you require to be logged they may not log the important info that must be logged. Good answer though for a hard question. Aug 9 '11 at 10:55
  • 1
    Good point,@Mark McDonagh, to clarify I mean "Everything that's being logged currently should be sent to the SIEM," as opposed to "turn all current logs to the highest sensitivity and send to the SIEM." Which of course presumes that existing local logging configurations are decent, which can't be assumed, so that's another can of worms... My bottom line, though, is that it's better to filter your SIEM database than it is to squelch your data sources.
    – gowenfawr
    Aug 9 '11 at 11:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy