1.) Staff to manage the Infrastructure (uptime, performance, storage, upgrades)
2.) Staff to administer the SIEM (rule/alert tuning and creation, log sources collection and monitoring)
3.) Staff to monitor and analyze the alerts (ensure you have enough to manage the queue quickly and hit all SLAs)
4.) System Resources (Enough hardware, licenses, etc. so you don't drop logs, and can correlate events quickly, etc.) 5.) Custom Alerts for your Environment (disable most of the defaults, write the rules specific to what should or shouldn't happen in your company)
6.) Constant Tuning of existing Alerts (to ensure analysts are only working on useful alerts and not noisy junk)
7.) Constant Adding/Enhancing of Alerts (as new security trends pop up, quickly add new alerts to capture them)
8.) Add accurate and relevant Intel (don't blindly take free feeds, make sure the intel you gather is accurate and relevant to your environment)
9.) Log Sources Processes (ensure processes exist so whenever a new device, server, or app is brought up it doesn't go-live until you're getting logs)
10.) Document all alerts (generate a history for devices, servers, users, ips, urls, etc. so that analysts have context and don't have to re-invent the wheel)
11.) Data Classification (analysts must know what your sensitive data is and where is resides so they know what they're protecting and know when to raise red flags)
12.) Management support (you need managers that show interest and concern for things like alert queues, SLAs, false positive rates, etc. to drive improvement)
It's a lot, but if you have those things it would seem that a SIEM can be a valuable tool in your layered Security!
More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- DOM XSS 101 Walk-Through
- An Invoice email and a Hot mess of Java
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment