Last year, I did this great SIEM webinar on “SIEM Architecture and Operational Processes” [free access to recording! No Gartner subscription required] and received a lot of excellent questions. This is the forgotten post with said questions.
The webinar was about “Security information and event management (SIEM) is a key technology that provides security visibility, but it suffers from challenges with operational deployments. This presentation will reveal a guidance framework that offers a structured approach for architecting and running an SIEM deployment at a large enterprise or evolving a stalled deployment.”
Before the attendee Q&A, I asked one question myself:
Q: Are you satisfied with your SIEM deployment?
You make your own conclusions from that one.
And here is the attendee Q&A:
Q: Do you have tips for starting log management (for SIEM) in a heavily outsourced environment, so where most servers, routers, firewalls etc are managed by 3rd parties?
A: Frankly, the central problem in such environment is about making changes to systems. Can you change that /etc/syslog.conf or that registry setting when needed, quickly and efficiently? Beyond that, I’ve seen outsourced IT will good log monitoring and I’ve seen traditional IT with bad one, so its success is not chained to the delivery model. If anything, I’d watch the outsourced environment more closely since “if you cannot control what they do, at least monitor them.”
Q: To what degree do you think it is realistic, and to what degree useful, to collect and analyze logs from Windows workstations (endpoints), rather than just servers?
A: It used to be rare, and it is still not that common, but more organizations are doing it. In fact, ETDR tools has emerged to collect even more security telemetry from the endpoints , including plenty of activities that are cannot be logged. In general, desktop/laptop [and soon mobile?] logging is much more useful now than it used to be. Also, the SIEM tool scalability (in both raw EPS and logging devices/sources) is better now and thus enables more user endpoint logging.
Q: For a mid-size company what percent of time would a typical SIEM analyst spend in monitoring / management of the tool – outstanding incident management.
A: Look at my SIEM skill model of Run/Watch/Tune and the paper where it is described in depth. Ideally, you don’t want to have one person running the SIEM system, doing security monitoring and tuning SIEM content (such as writing correlation rules, etc) since it would be either one busy person or one really talented one. Overall, you want to spend a small minority of time on the management of the tool and most of the time using it. SIEM works if you work it! SIEM fails if you fail to use it.
Q: How do you reconcile (at a high level) an overall SIEM effort with a Syslog or “IT search” type tool selection? We have enterprise architects who say our Operational Intelligence should include SIEM, but Ops and Security aren’t on that same page.
A: Nowadays, we see both “SIEM for security, general log management for ops” and “single system for both ops and security.” Organizations may choose to run a separate system for operational logging (as well as a SIEM) or choose to run one system and feed the logs from one place into different components. Many, many organization are still very silo’d and would actually prefer to do separate log collection in separate tools. Theoretically, this is unhealthy and inefficient, but for many organizations this is also the only way they can go…
Q: What kind of role do you see “Security Analytics” or the new generation SIEM solutions playing versus the traditional SIEM solutions? What kind of market adoption are you seeing of these new solutions versus the traditional SIEM ones?
A: In our recent paper on the topic, we tried to predict the same evolution as well as reconcile such SIEM evolution with new tools leveraging big data technologies and new analytic algorithms. At this point, new analytic approaches remain for the “Type A of Type A” organization with the most mature, well-funded and dedicated security operations teams (example). Many organizations can barely operate a SIEM and are nowhere near ready for the big data-style tools and methods. In essence, “if you think SQL is hard, stay outside of a 5 mile radius from Hadoop.” See this post for additional predictions and this one for a funnier take on this topic.
Q: Is SIEM dead or going to die? if yes, what other tools can you use for these SIEM-type use cases?
A:Not at all! SIEM is alive and happy, growing and evolving.
There you have it, with a slight delay : – )
Posts related to SIEM: