Top 5 Reasons a SIEM Implementation Fails to Deliver Value

Harold Tabellion

Harold Tabellion

Share on facebook
Share on twitter
Share on linkedin

SIEM implementation can be a large project with multiple stakeholders. Without careful planning, the project can drag on indefinitely, or worse–be considered completed without ever providing value to the organization. Below are some of the common reasons for a SIEM to be discarded to the fail bucket so these obstacles can be addressed during your implementation.

1. Failing to do an initial scoping of the security environment

Scoping the environment to be monitored so the SIEM can be properly sized is a very important initial step and should be done immediately after deciding to purchase a SIEM. Once all the critical business applications have been identified, then start evaluating which SIEM(s) will best support your environment. After identifying which SIEM to utilize, determine how much data the platform will need to ingest. You simply cannot expect satisfactory results if you attempt to send three times the EPS (events per second) a system was engineered to handle. Events will be dropped and delayed, alarms may not be generated in a timely manner, and the user interfaces can become too slow to be useful.

2. Lack of feedback loop

The second way a SIEM project can fail is lack of a feedback loop between the different groups responsible for administering the SIEM, including the Security Operations Center (SOC) analysts monitoring the SIEM and the security analysts evaluating the tickets generated by the SOC analysts. The security analysts should not only provide confirmation when a true positive is identified, but also give feedback on the false positives. Some false positives are a necessary evil. Highly-sensitive tasks, such as updating the Domain Admins group, should always be verified as soon as possible. Other sensitive tasks may only require a daily review and would make a good candidate for a report; however, without providing feedback to the SOC analysts so they can separate the highly-sensitive tasks, their only choice is to continue handling them the same way. The SOC analysts must also provide feedback to the SIEM administrators on the quality and volume of alarms being generated. An alarm is going to continue to generate repeated false positives if it is not tuned. That said, tuning cannot happen if the feedback is only “false positive” without also communicating the criteria used to identify the alarm as a false positive. 

3. No plan for continued SIEM maintenance

The phrase “fire and forget” does not apply to a successful SIEM program. Blitzing through the initial stages of deployment to get all devices sending logs, then calling the project complete is a sure way to have the project fail. Planning for the continued maintenance of the platform should be considered a criterial item during the planning phase. Project managers should probably skip the rest of this sentence, but a technologist (lumping systems administrator and information security engineers together here) should never consider the implementation complete. This doesn’t mean that regular stakeholder meetings for the implementation project need to occur indefinitely. The implementation phase can end once the milestones identified in the planning phase have been met; however, if a new server is brought online, it must be integrated into the SIEM as well. Accounting for environmental changes in the SIEM must be part of the new system’s operational lifecycle. If a new server is being brought online, integration into the SIEM is another required task on the checklist. Operational changes are not restricted to bringing new systems online. During a SIEM implementation, an alarm may have been created with a list of sensitive Active Directory groups to monitor. If a new application with Active Directory integration is being deployed into the environment, a new set of privileged groups could be created that need to be monitored by the SIEM in addition to the original list.

4. Not getting buy-in from stakeholders

Having buy-in from the groups that will be doing the leg work for the implementation is necessary for a successful project. Network and systems administrators will need to roll configuration changes and possibility push agents to the systems under their care. Some teams will have a passion for security and will be eager to lend a hand, while others will be reserved with how these changes will affect the systems. Perhaps they’ve taken the 3 a.m. calls for a bad antivirus update or another agent that consumed all system resources as another critical job was running. Addressing these concerns to get their buy-in will help tremendously with not only getting these changes made, but these administrators can also provide valuable insight into the normal operation of these systems during the tuning phase of the SIEM implementation.

5. Not proving the business need to the C-Suite

Information security does not operate within a bubble for the sake of information security, but to protect the operations and assets of a larger organization. Yes, it’s critical to detect a new member of the Enterprise Admins group; however, would the Enterprise Admin group be on a business analyst’s list of critical assets? The business analyst’s list may include: financial statements, intellectual property, client list and physical assets. The critical assets of the business must be evaluated for use case development. The board is not going to care that the infosec team was immediately notified when a pentester successfully executed a privilege escalation when the SEC is asking why the upcoming the quarterly financial reports have been pasted to /r/WallStreetBets. Always ensure that in addition to protecting privileged groups from unauthorized modifications and Active Directory from kerberos attacks, time is spent discussing how to protect the organization’s competitive advantage and critical processes. This will be unique to every organization and will require internal resources to identify.

Hopefully this post has provided insight to the common pitfalls when implementing a SIEM. Identifying potential obstacles allows for planning prior to confronting these challenges increasing the opportunity for success.

More Articles