Is this a good way to manage Incident-Response

Question

I m trying to find a good way to deal with incidents. For now these are my thoughts:

x Join Logs and analyse with splunk (and alert with rsyslog, splunk is too expensive),

x Configuration-Management and automatic Re-Deployment (puppet, capistrano),

x Forensic via File-System-Mounting (compare with clean hash-db), Analyse Memory-Dumps for Rootkits (volatilitux)...

I would really appreciate some comments, that help me improves.

Answer 1

Assuming that this is your complete process, not a subset where other decisions have already been made, I would suggest that your first decision point is not whether or not there is an intrusion but whether or not there is a business service impact.

Alert -> Check Logs -> Business Service Impact?

After you've determined the business service impact you can use that to drive the rest of the incident response. If your service is impacted you need to engage the correct people in the business (which should already be documented) to notify them of the impact, providing an early overview of the problem.

Business Service Impact? -> Yes -> Notify Business Incident Manager

Once the business has been notified you can move on to determining the exact nature of the problem and working through the rest of your process flow.

If there is no business service impact you still move on to problem determination.

Business Service Impact -> No -> Intrusion?

My next point would be that, even if the event is not an Intrusion it may still be a security event which you wish (or need) to perform actions as a result of.

For example, you detect some form of automated or manual scan of your web applications. You may decide that you wish to block the attacker's IP address. This is just one simple example.

Such a decision may require authorisation from appropriate business or technology representatives so again, the necessary hooks in to the business must be reflected in your process flow.

In summary then, my feedback points are:

1. Don't forget you're defending a business application, ensure your incident response process reflects the needs of the business, not just detailing the technical steps required.

2. An intrusion is obviously worst case but don't discount actions required for other security related events. It may not just be mis-configuration.

HTH!!

Answer 2

OSSIM has OSSEC. OSSEC can be used on things like mod-security, Wordpress, and MySQL UDF logging interfaces, in addition to file integrity monitoring and syslog management.

I don't understand the need or desire for Splunk when Novell Sentinel Log Manager 25 and Q1Labs QRadar Log Manager have freely downloadable options that are better, in addition to plenty of other open-source projects that are also better (especially for the price). I agree that Splunk is too expensive.

Answer 3

The principles are simple and along the lines you have outlined.

1. Remote logging. Not delayed logging, but real-time. rsyslog works great. As a perfectionist, I try to capture and send logs from source directly, not log to files first and then have them picked up by rsyslog - just to avoid the possibility of interception in between.
2. Include file integrity monitoring. OSSEC is good in this area, but I use my own.
3. Live analysis. I use MozDef (The Mozilla Defense Platform). OSSIM was too proprietary and too restrictive (after a while it felt like the only purpose of OSSIM was to promote the paid product). If you're a first timer, try the docker image. For production use, you'll need to understand how the components tie together and create a custom config for yourself. I'll be happy to help if you like.
4. Configuration Management. Yes.
5. Automated Redeployment. Wait! As a DevOps function this is great, but you want to be super conservative when it comes to IR. Any automation needs to cover many scenarios. We do this with simple webservers, not but anything else. That's because we find that in real life, almost every scenario is different from what we had imagined and prepared for (I know that could also mean we're not imagining/preparing enough).
6. Remote forensics with automated capture. Very nice to have, though automated or not is debatable. Too many risks there, unless you have a very tightly controlled environment (I haven't come across too many). We prefer using GRR / equivalent. The need for live forensics is infrequent (our experience). To try and configure every endpoint (even just servers) under your care for this might be overdoing it a bit, unless you are managing high value assets (Banks / Military / ...). So we do this selectively.