Don’t boil the ocean. Start with that.
Before I dipped my toes into security I did a stint as an application administrator. I was responsible for managing system and application monitoring. More performance and capacity monitoring than anything but there is a clear overlap in tools that capture logs and generate alerts based on thresholds, e.g. an IBM Tivoli monitoring, HP EMS, or Microsoft SCOM and a SIEM.
My employer had just one of those tools at the time I started and then management wanted to implement a second, though I cannot explain the why on that decision. I digress.
I recall specific conversations about the data the tool(s) were gathering. The console was overwhelmingly full with just a few devices being monitored. Rules and response, even rules for response were necessary. I might still have the email from a co-worker who asked if he was to “crawl through the phone to choke a user out if they fat fingered their password again.” At least it was an entertaining time.
I happened to search for “best practices” and tips for setting up a SIEM, after all the SIEM is an extension of good monitoring. I found 5 and 7 step lists from a few vendors and then from SANS a pretty comprehensive and helpful list.
1. log all relevant events
2. define the scope of coverage
3. define what events constitute a threat
4. detail what should be done about them in what time frame
5. document when they occurred and what was done
6. document where both the events and follow up records can be found
7. document how long events and tickets are kept
What I’m going to recommend is counter to what the vendors suggested. Both had items either the 3rd for 4th priority, to collect as much data points as possible. I strongly disagree with this at the outset.
The problem with monitoring tools is noise. Too much noise and we stop listening. Too many false positives and the real positives are ignored. Too much noise and critical events are overlooked. Don’t believe me? Look at Target, or Capitol One or any other major breach where the breached entity had some type of monitoring in place:
1. Establish Requirements First /Identify Compliance Requirements
2. Have a Comprehensive Incident Response Plan (IRP)
a.Detail what should be done about them, by whom, and in what time frame
3. Determine Scope
a.Monitor Access to Critical Resources
b.Defend Your Network Boundaries
4. Begin with a Pilot Run
a.Collect only what you need NOT: As Much data, as Possible
5. Review and modify correlation rules
6. Define what events constitute a threat
a.Know your entity’s risks and appetite for risk
7. Walk through events manually before automation
a.Align this process with your IRP
8. Continuously Refine Your SIEM Deployment
a.With success in one event type, move to another event type
b.Leverage synthetic transactions, crawlers and other tools to simulate events and test your workflow
Comments