Free MS Virtual Machine Images

Free MS Virtual Machine Images

  • slmgr /ato – will give you 90 day trial



Available Artefacts – Evidence of Execution

Available Artefacts – Evidence of Execution

This week I have been working a case where I was required to identify users on a Windows Server 2003 system who had knowledge of, or had run, a particular unauthorised executable. As such, I found myself wracking my brain for all the user attributable artifacts which evidence program execution (on an OS I hadn’t analysed for a short while).

Furthermore, David Cowen in his recent Sunday Funday Challenge over at HECFBlog had posed a similar question regarding evidence of execution. With that as my motivation, I set about to document different artifacts which can be used to evidence program execution (both user attributable and otherwise) as available in various different versions of Windows.

I should highlight up front that some really fantastic blog posts from Harlan CarveyAndrea FortunaCorey Harrell and Mary Singh gave me a significant leg up. This isn’t my first time reading any of those posts and I’m sure it wont be my last. A myriad of other posts assisted in confirming details of specific artifacts and I have referenced those below. The main focus of this post, and particularly the associated table of artifacts, is to serve as a reference and reminder of what evidence sources may be available on a particular system during analysis.

On to the main event. The table below details some of the artifacts which evidence program execution and whether they are available for different versions of the Windows Operating System.

Too Small?… It’s a hyperlink!

Cells in Green are where the artifact is available by default, note some artifacts may not be available despite a Green cell (e.g. instances where prefetch is disabled due to an SSD)

Cells in yellow indicate that the artifact is associated with a feature that is disabled by default but that may be enabled by an administrator (e.g. Prefetch on a Windows Server OS) or added through the application of a patch or update (e.g. The introduction of BAM to Windows 10 in 1709+ or back-porting of Amcache to Windows 7 in the optional update KB2952664+)

Cells in Red indicate that the artifact is not available in that version of the OS.

Cells in Grey (containing “TBC”) indicate that I’m not 100% sure at the time of writing whether the artifact is present in a particular OS version, that I have more work to do, and that it would be great if you could let me know if you already know the answer!

It is my hope that this table will be helpful to others. It will be updated and certainly at this stage it may be subject to errors as I am reliant upon research and memory of artifacts without having the opportunity to double check each entry through testing. Feedback, both in the form of suggested additions and any required corrections is very much appreciated and encouraged.

Summary of Artifacts

What follows below is brief details on the availability of these artifacts, some useful resources for additional information and tools for parsing them. It is not my intention to go into detail as to the functioning of the artifacts as this is generally already well covered within the references.


Prefetch has historically been the go to indication of process execution. If enabled, it can provide a wealth of useful data in an investigation or incident response. However, since Windows 7, systems with an SSD installed as the OS volume have had prefetch disabled by default during installation. With that said, I have seen plenty of systems with SSDs which have still had prefetch enabled (particularaly in businesses which push a standard image) so it is always worth checking for. Windows Server installations also have Prefetch disabled by default, but the same applies.

The following registry key can be used to determine if it is enabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnablePrefetcher
0 = Disabled
1 = Only Application launch prefetching enabled
2 = Only Boot prefetching enabled
3 = Both Application launch and Boot prefetching enabled



It should be noted that the presence of an entry for an executable within the ShimCache doesn’t always mean it was executed as merely navigating to it can cause it to be listed. Additionally Windows XP ShimCache is limited to 96 entries all versions since then retain up to 1024 entries.

ShimCache has one further notable drawback. The information is retained in memory and is only written to the registry when the system is shutdown. Data can be retrieved from a memory image if available.



Programs executed via Explorer result in MUICache entries being created within the NTUSER.DAT of the user responsible.


Amcache / RecentFileCache.bcf

Amcache.hve within Windows 8+ and RecentFileCache.bcf within Windows 7 are two distinct artifacts which are used by the same mechanism in Windows to track application compatibility issues with different executables. As such it can be used to determine when executables were first run.


Microsoft-Windows-TaskScheduler (200/201)

The Microsoft-Windows-TaskScheduler log file (specifically events 200 and 201), can evidence the starting and stopping of and executable which is being run as a scheduled task.


LEGACY_* Registry Keys

Applicable to Windows XP/Server 2003 only, this artifact is located in the System Registry Hive, these keys can evidence the running of executables which are installed as a service.


Microsoft-Windows-Application-Experience Program-Inventory / Telemetry

Both of these system logs are related to the Application Experience and Compatibility features implemented in modern versions of Windows.

At the time of testing I find none of my desktop systems have the Inventory log populated, while the Telemetry log seems to contain useful information. I have however seen various discussion online indicating that the Inventory log is populated in Windows 10. It is likely that my disabling of all tracking and reporting functions on my personal systems and VMs may be the cause… more testing required.


Background Activity Monitor (BAM)

The Background Activity Monitor (BAM) and (DAM) registry keys within the SYSTEM registry hive, however as it records them under the SID of the associated user it is user attributable. The key details  the path of executable files that have been executed and last execution date/time

It was introduced to Windows 10 in 1709 (Fall Creators update).


System Resource Usage Monitor (SRUM)

Introduced in Windows 8, this Windows features maintains a record of all sorts of interesting information concerning applications and can be used to determine when applications were running.



In Windows 10 1803 (April 2018) Update, Microsoft introduced the Timeline feature, and all forensicators did rejoice. This artifact is a goldmine for user activity analysis and the associated data is stored within an ActivitiesCache.db located within each users profile.


Security Log (592/4688)

Event IDs 592 (Windows XP/2003) and 4688 (everything since) are recorded within the Security log on process creation, but only if Audit Process Creation is enabled.


System Log (7035)

Event ID 7035 within the System event log is recorded by the Service Control Manager when a Service starts or stops. As such it can be an indication of execution if the associated process is registered as a service.



Within each users NTUSER.DAT the UserAssist key tracks execution of GUI applications.



The RecentApps key is located in the NTUSER.DAT associated with each user and contains a record of their… Recent Applications. The presence of keys associated with a particular executable evidence the fact that this user ran the executable.



Implemented in Windows 7, Jumplists are a mechanism by which Windows records and presents recent documents and applications to users. Located within individual users profiles the presence of references to executable(s) within the ‘Recent\AutomaticDestinations’ can be used to evidence the fact that they were run by the user.



The RunMRU is a list of all commands typed into the Run box on the Start menu and is recorded within the NTUSER.DAT associated with each user. Commands referencing executables can be used to determine if, how and when the executable was run and which user account was associated with running it.


AppCompatFlags Registry Keys



Various Anti-Virus, Intrusion Detection and Endpoint Detection and Response (EDR) solutions may provide evidence of program execution. It is recommended to identify and analyse any associated logs and note that some logging may be centralised.
Repeating the appeal earlier in this post, feedback, suggested additions and corrections are very welcome!

Open Source Threat Intelligence feeds (draft)

Open Source Threat Intelligence feeds


  1. Spamhaus
  4. File Names
  5. Indicators of Compromise
    1. File Names
    2. IPs
    3. URLs
    4. Domains
    5. File Hash
    6. Yara Rules
Group name Reconnaissance Credential harvesting
Tick whoami, procdump, VBS WCE, Mimikatz, gsecdump
Waterbug systeminfo, net, tasklist, gpresult WCE, pwdump
Suckfly tcpscan, smbscan WCE, gsecdump, credentialdumper
Fritillary PowerShell, sdelete Mimikatz, PowerShell
Destroyer Disk usage, event log viewer kerberos manipulator
Chafer network scanner, SMB bruteforcer WCE, Mimikatz, gsecdump
Greenbug Broutlook WCE, gsecdump, browdump
Buckeye os info, user info, smb enumerator pwdump, Lazagne, chromedump
Billbug ver, net, gpresult, systeminfo, ipconfig
Appleworm net, netsh, query, telnet, find dumping SAM

System Integrity Management Platform (SIMP)

System Integrity Management Platform (SIMP)

The System Integrity Management Platform (SIMP) is an Open Source framework designed around the concept that individuals and organizations should not need to repeat the work of automating the basic components of their operating system infrastructure.

Expanding upon this philosophy, SIMP also aims to take care of routine policy compliance to include NIST 800-53FIPS140-2, the DISA STIG, and the SCAP Security Guide.

SIEM Use Case Examples

SIEM Use Case Examples



Use Case Description Status in 2018
1 – old Authentication tracking and account compromise detection; admin and user tracking Very much alive, also became a popular UEBA use case
2 – old Compromised- and infected-system tracking; malware detection by using outbound firewall logs, proxy, etc Very much alive, more relevant than before, also an UEBA use case
3 – old Validating intrusion detection system/intrusion prevention system(IDS/IPS) alerts by using vulnerability data, etc Less relevant today, not common anymore – perhaps a candidate for removal from popular list?
4 – old Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs, etc Very much alive, also a popular UEBA use case (related to exfiltration detection)
5 – old Tracking system changes and other administrative actions across internal systems, etc Very much alive, AD log analysis became more popular, UEBA expands this to insider threats, etc
6 – old Tracking of Web application attacks and their consequences, etc I’d say alive today, but not that common, not sure why
7 – NEW Cloud activity monitoring, detecting cloud account compromise, cloud access and privilege abuse, other security issues, etc NEW! Also a use case for UEBA and (in case of SaaS, mostly) CASB, this covers many sub-use cases for AWS, Azure, Office 365, etc threat detection
8 – NEW Detecting threats by matching various logs to threat intelligence feeds NEW! A popular use case, pushed up by wide availability of low-priced TI feeds of … ahem… tolerable quality
9 – NEW SIEM as “poor man’s EDR” – review of sysmon and similar endpoint data NEW! As EDR and EPP converge, SIEM can occasionally help with deeper endpoint visibility by utilizing various source of endpoint telemetry; probably not a good STARTER use case though…
Step Details
Use-case Selection Selected use case is tracking authentication information across systems [what] to detect unauthorized access. [why]
Data Collection Needed Prepare a list of systems such as servers, VPN concentrators, network devices, and others.
Log Source Configuration Needed Contact the team that operates the systems and make them modify the logging configurations in order for the logs to be collected by SIEM.
SIEM Content Creation, Preparation and Selection Review vendor’s content — such as their authentication reports and relevant correlation rules or other “canned” analytics — that deals with the problem and check it for suitability; modify the reports and rules until satisfied.
Definition of Operational Processes Required Review operational processes related to the security use case and check whether additional processes are needed. A process for suspending or disabling user accounts might have to be created.
Refinement of the Content and Processes Loop After reports and correlation rules are deployed and the data is flowing in, review reports, dashboards, and perform the testing of correlation rules on the collected data to see whether incidents will be detected. Simulate password guessing and check whether SIEM detected and sent an alert.
  1. Authentication tracking and account compromise detection; admin and user tracking [this is the very use case that I detail in that post]
  2. Compromised- and infected-system tracking; malware detection by using outbound firewall logs, NIPS alerts and Web proxy logs, as well as internal connectivity logs, network flows, etc
  3. Validating intrusion detection system/intrusion prevention system (IDS/IPS) alerts by using vulnerability data and other context data about the assets collected in the SIEM[while some say “this is so 2002”, this use case is still here in its modern form of using SIEM for “context-enabling” various alerts]
  4. Monitoring for suspicious outbound connectivity and data transfers by using firewall logs, Web proxy logs and network flows; detecting exfiltration and other suspicious external connectivity
  5. Tracking system changes and other administrative actions across internal systems and matching them to allowed policy; detecting violations of various internal policies, etc [and, yes, even the classic “root access from an unknown IP in a foreign country at 3AM, leading to system changes” sits here as well]
  6. Tracking of Web application attacks and their consequences by using Web server, WAF and application server logs; detecting attempts to compromise and abuse web applications by combining logs from different components.


  1. Compromised account detection: this is a “classic UBA” usage – study account authentication and usage information to conclude that the account is being used by a malicious party [or, at least, by a different party]; this is often powered by some logic to relate multiple accounts to the same person and/or logic to build sessions of user activity.
  2. Compromised system/host/device detection: by detecting things like attacker lateral movement, C&C activity, access to bad domains [unknown ones, not just via TI!], various telling host and network anomalies, etc reach a conclusion that a system is under malicious control; this use case covers many data sources and a lot of fairly dissimilar methods of “sense-making”
  3. Data exfiltration detection: notably, DLP has not fully solved this one (ha!), but has since become a popular UEBA data source; data theft (“exfil”, if you want to sound cool!) detection by trusted insiders and outsiders (as well as their malware) presents a common UEBA tool use case.
  4. Insider access abuse: this is a fuzziest on the list, this focuses on detecting malicious and risky behavior by legitimate trusted insiders, and includes all forms of privileged access abuse and misuse, among other things; typically powered by user profiling, outlier detection and risk scoring of the results
  5. Gaining additional insight about the environment: a broad use case where UEBA tools are used for gaining better situational awareness; this also includes improved alerts prioritization and support for triage and investigation activities (yes, if you have to ask, hunting too)
  6. Custom use case: a good UEBA tool should be able to address a weird client-specific user behavior analytics scenario, ideally without coding and [much] data science knowledge on behalf of a client.
  7. Define a particular problem to be solved by a SIEM tool in clear, unambiguous terms.
  8. Review the SIEM functionality (rules, algorithms, reports and dashboards) that is needed to solve the problem.
  9. Look at the available and potentially available log data that is useful for solving the problem.
  10. If a correlation rule is the chosen piece of content to be created, analyze what sequence of logged events needs to be tracked and how these events are represented in a SIEM tool; using normalized events and taxonomy categories is highly recommended because they make the rule easier to modify, maintain and apply to additional log sources.
  11. If using a statistical detection method, review its logic to confirm that it will deliver the result needed.
  12. Draft correlation rules on paper, and review the logic flow.
  13. Implement the correlation rule using the SIEM rule interface; some products allow one to click on events and define a rule straight from the observed sequence of events.
  14. If a product has functionality to test the rule or algorithm on historical data, execute this functionality to determine how often this rule would have fired in the past if it had been enabled.
  15. Review any alerting process that this rule will trigger, and set up alerts to go to the people who know how to triage them.
  16. Enable the rule to run on real-time data flow in the production environment.
  17. Review alerts generated by this rule, review the cases where the rule matches partially (if the SIEM product has such functionality) and refine when the rule is needed.



Top SIEM Use Case UEBA Utility for This
1 Authentication tracking and account compromise detection Top UEBA use case; UEBA shines here; this is hard to do well with SIEM
2 Compromised- and infected-system tracking; malware detection by using outbound logs, etc A common UEBA use case; done either via entity profiing or by detecting systems where compromised accounts dwell
3 Validating intrusion detection system/intrusion prevention system (IDS/IPS) alerts UEBA is used for alert validation and triage, but not exactly like SIEM; in fact, UEBA has been used for SIEM alert validation
4 Monitoring for suspicious outbound connectivity and data transfers by using logs, etc Exfiltration detection is a common UEBA use case; done via account activity profiling or via DLP alert analysis
5 Tracking system changes and other administrative actions across internal systems, etc An infrequent UEBA use case, maybe for finding that one worrisome change or access
6 Tracking of Web application attacks and their consequences by using Web logs, etc Not a match to common UEBA use cases

Overcoming Common Causes for SIEM Solution Deployment Failures

Overcoming Common Causes for SIEM Solution Deployment Failures

Implementing SIEM solutions continues to be fraught with difficulties, with failed and stalled deployments common as well as solutions not meeting goals a year or more afterward. Security and risk management leaders can avoid the six most common SIEM failures by following these best practices.

Key Challenges

  • Avoiding stalled or failed SIEM solution projects requires careful planning where there is a clear understanding of the scope, objectives and associated use cases. Many security organizations underestimate the amount of planning required before purchasing, implementing and operating a SIEM solution, and hit a hard stop once this becomes clear.
  • Many security organizations do not realize that enabling security logs can materially increase resource utilization (CPU and I/O) on the monitored server.
  • The necessary resources for effective implementation and operations are routinely underestimated, and SIEM solutions are often purchased without assessing the feasibility of running them in-house.


To avoid the common causes for SIEM deployment failures, security and risk management leaders focused on security monitoring and operations should:

  • Define clear goals, use cases and requirements – including plans for how to run, administer and use the SIEM solution – before selecting a SIEM solution.
  • Develop an initial six- to 12-month roadmap encompassing the deployment of the SIEM solution and the phased implementation of five to seven use cases.
  • Follow an output-driven model when planning SIEM tool acquisition, implementation and expansion, and use this to drive the selection of specific data sources needed for use cases.
  • Start with a CLM solution, if resources are limited, to gain experience with the intricacies of implementing a SIEM tool, then gradually
  • Use a co-managed SIEM service provider to rescue failed SIEM tools deployments, and to address resource or expertise constraints for new implementations.


Due to their complexity and demanding requirements, security information and event management (SIEM) solution projects often do not live up to leaders’ (and user’s) expectations, and failed or abandoned deployments are not uncommon. Moreover, Gartner frequently speaks to clients who are purchasing their second or third SIEM solution after finding that their incumbent solution does not meet their expectations. Lack of planning and an underappreciation of the ongoing budget, operational and infrastructure requirements, as well as underestimating the required resources and skills, are the most common causes for failed SIEM projects.

Even a successful SIEM solution deployment can be an expensive and resource-intensive proposition. Approaching a SIEM project without sufficient planning and without following a formalized process will make it even costlier, with the risk of achieving few, if any, benefits.

Gartner points out how to overcome the six most common pitfalls that Gartner encounters as root causes for failed and stalled SIEM solution deployments. Avoiding these – and following the best practices that accompany them – will help ensure an effective and successful deployment.


Undertake Careful Planning to Avoid Stalled or Failed SIEM Deployments

Pitfall No. 1: Failure to Perform Detailed Planning Before Buying

Despite the common perception that SIEM solutions are complex and expensive, many organizations buy one without following best practices, such as first defining goals and requirements, and then evaluating and scoping the project to determine that a given solution will meet all their requirements. The chance of successfully implementing a SIEM project without prior planning is slight; the necessary investment in time, resources and potential additional costs will far outweigh the perceived benefit of moving forward without planning. Gartner commonly encounters organizations where a SIEM solution was acquired and has been quietly gathering dust ever since the initial deployment – not due to the technology being inadequate.

The majority of SIEM solutions provide solid security information management (SIM) and security event management (SEM) capabilities. However, there is wide variation in out-of-the-box, third-party integrations; integrated workflows and ancillary capabilities, such as network flow (NetFlow), network monitoring and endpoint detection and response (EDR). More importantly, without sufficient planning, correct scoping becomes guesswork.

Planning is also important to prove feasibility. In the course of planning, you may come to the conclusion that the inherent requirements of a SIEM solution mean that this is not a realistic option for your organization. SIEM tools are not suitable for every organization. They require expertise and dedicated resources; rely on a sane, well-formed operational environment; and will not compensate for shortcomings in investment, operational execution or skills. If that is the case in your organization, then there are better options available – from using managed security services or managed detection and response (MDR) services to co-managed SIEM to investing in something else first for lower effort and reduced cost-risk.

Best Practice: Use a Formalized Planning Approach

Gartner recommends the following approach to planning and implementing a SIEM tool:

  • Form a core project team whose primary responsibilities include defining the goals, scope and deployment phases of the project, and identifying initial stakeholders.
  • Define security event monitoring objectives and the initial scope of deployment.
  • Determine the initial use cases that will be covered.
  • Define the data collection, retention, reporting and security event monitoring requirements.
  • Assess how many and which data sources will be included to determine the required scale of the solution – whether in terms of events per second, back-end storage or processing power – and then check whether you can get access to those data sources.

Security and risk management leaders should then use this foundation to:

  • Conduct an environmental assessment.
  • Assess the architectural requirements and collection methods to determine what effort will be required to integrate data sources, if those data sources support enablement of security logs without affecting performance on workload, how many collector instances will be needed to accommodate segmented networks or geographically dispersed locations, or whether other organizational groups (such as networking or application support) should be included in the planning.
  • Determine the ability of the log sources to generate the expected events. There may be limitations on some of the log sources due to performance, software versions, etc.
  • Define security event monitoring and incident response (IR) processes/playbooks. Place special importance on the development of your IR processes and playbooks, as your SIEM solution will reveal the incidents.
  • Create the relevant processes and policies in order to assess how many resources will be required to actually run the solution.
  • Select the technology (see “Magic Quadrant for Security Information and Event Management” and “Critical Capabilities for Security Information and Event Management,” as well as “Toolkit: Security Information and Event Management RFP”).
  • Deploy the technology (see “How to Deploy SIEM Technology”).

Pitfall No. 2: Failure to Define Scope

Attempting to deploy SIEM without a predefined scope can be realistically expressed as: “no scope, no hope.” The scope provides the basis for all that will follow – planning, deploying, implementing and maturing the SIEM solution and related capabilities. It will determine the choice of solution, the architectural requirements, the necessary staffing, and the processes and procedures. Deployment without a defined scope and set of use cases is like building a house without a foundation. Not only is the process of building fraught with danger, but also the house will eventually crumble. For example, a SIEM deployed to monitor 10 log sources for Payment Card Industry Data Security Standards (PCI DSS) violations via reports is a very different project scope versus a global bank deploying a SIEM solution in a security operations center (SOC) over three locations, a team of 30 people and 10 terabytes of log data a day.

Attempting to define the drivers after implementation will be costly, and could lead to a failed implementation, wasting time and resources better spent on other projects. Technological debt could also be incurred due to the wrong SIEM technology selection. Gartner frequently encounters clients that have had to recover from these failed SIEM deployments.

Deploying SIEM is a marathon, not a sprint. Expect it to take up to a year to have a library of well-executed use cases and internal skills built up that allow you to effectively implement and evolve your own SIEM solution. Gartner advises security and risk management leaders to have a multistage approach that covers more than just the initial deployment, but also follow-up stages that continue to evolve additional use cases and ingest other data sources to support these use cases.

Best Practice: Define Scope and Objectives Based on Digital Business Outcomes

SIEM scope and associated objectives will be determined by the drivers for deploying SIEM and will facilitate the creation and design of use cases. Driverless SIEM will never provide a return on investment.

Alongside a variety of less common niche drivers, there are two primary drivers for SIEM: compliance and threat management. Although compliance is still a possible driver and key requirement for SIEM tool implementations, the focus has shifted for some organizations toward threat management (see Figure 1).

Figure 1. SIEM Implementation Drivers

Figure 2. SIEM Duties

Source: Gartner (May 2017)

Threat Management – Threat management scope can span many different objectives and use cases (for example, detecting brute force and malware attacks, or monitoring third-party or privileged users for any kind of administrative policy changes). Depending on the specific objective, the scope will typically include network security devices, such as firewalls, intrusion detection and prevention systems (IDPS), secure web gateways (SWGs), web application firewalls (WAFs), and security applications like vulnerability assessment and data loss prevention (DLP), as well as various security, audit and application logs from systems or database servers.

Examples for threat management use cases include real-time monitoring for external network threats, authentication failures, threat intelligence feed fusion, and user activity and behavior profiling and monitoring. These will be accompanied by incident response processes and automated cross-data correlation and alerting, among others.

The addition of threat intelligence has added significantly to a SIEM solution’s ability to ingest external threat context and overlay it over existing data. It is highly recommended that all SIEM deployments at a minimum look to enable the vendor-provided threat intelligence add-on of feed. In addition, you should look to use other sources, often via the open standards, like STIX/TAXII. For more advanced use cases, a threat intelligence platform (TIP) can be used to do the collection, curation and deduplication of large amounts of threat intelligence, which can then be deposited into the SIEM tool via native integrations.

Compliance – When compliance is a driver, the scope will be determined by the compliance requirements and regulatory mandates, such as the PCI DSS Requirement 10 and the Sarbanes-Oxley Act (SOX) of 2002. Also, the General Data Protection Regulation (GDPR) is expected to quickly become another compliance mandate that drives investment in monitoring technologies like SIEM. Typical mandates include log management or user activity monitoring by regular inspection of reports and monitoring for policy violations. The main objective is to comply with regulations, which drives security monitoring; however, this does not dictate that the organization should monitor specific infrastructure and applications.

Basic use cases include the collection and retention of log data, as specified by a regulatory mandate, and the occasional generation and review of user activity reports, with advanced use cases ranging from the automated auditing of policy violations to daily log reviews. SIEM solutions that have good coverage of compliance use cases can bundle compliance reports that are already created with the express purpose of meeting this compliance regime. Security and risk management leaders are strongly advised to investigate these options when the topic of using SIEM for compliance use cases is needed.

Niche – There are also a number of niche use cases with their own scope – for example, retail point of sale (POS) monitoring, operational technology (OT) monitoring or honeypot monitoring. “Honeypot” is a term commonly referred to as a deception technique, and has been utilized with a SIEM solution to expand security event monitoring capabilities.

Pitfall No. 3: Overly Optimistic Scoping

To obtain the maximum value out of a SIEM tool, it may seem tempting to do everything with it at once. SIEM solutions can ingest and process large amounts of event data and provide capabilities to manage these accordingly. Critically, however, the only effective way to scale the SIEM tool to be an effective platform for organizationwide security event monitoring and incident management is to do so in stages. Every use case has distinct required data sources and subsequent correlation rules, alerts, reports and dashboards. SIEM use cases should be used in a way to set up stages of cycles so that the organization is “chipping away” at constant improvements, rather than a “boil the ocean” approach where it is at a high risk of not getting adequate value from the SIEM tool.

Attempting to throw everything at the SIEM solution at once and hoping to be able to clean up later is one of the most common causes for stalled SIEM deployments. Sending a SIEM tool too many logs is just as bad as not sending enough. Also, some organizations fall into a “collection first, usage never” trap. Collecting everything takes years, and by that time, they are displeased with their SIEM solution. In many cases, an environmental assessment of that scale is a daunting and costly task that inevitably involves many different organizational units and stakeholders. Architectural and operational changes that may result from the use-case requirements will be complex and difficult to implement across the organization.

Best Practice: Construct an Initial Roadmap of Five to Seven Use Cases

Gartner recommends that security and risk management leaders who are planning a SIEM implementation should identify between five and seven use cases that will be used to construct an initial roadmap. A realistic time frame for this sort of implementation is six to 12 months, depending on use-case complexity, the IT security team’s experience, and whether additional technologies or stakeholders are required. Then, further use cases can be added going forward. Once the process has become sufficiently formalized and practiced, many organizations find their ability to implement new use cases becomes more efficient and effective.

It is, however, not uncommon to have a combination of compliance, threat management or niche drivers. In this situation, the use cases should be prioritized according to business needs. Advanced users can also attempt to logically group use cases according to shared requirements, such as needing the same data sources.

Common use cases include authentication tracking and compromised account detection, tracking compromised and infected systems, malware detection by using network connectivity logs to identify outbound connections, and tracking system changes and other administrative actions.

It is also important to note that, depending on the scope, organizations need to verify the availability of the required data sources to validate feasibility of the use cases. With everything else going on within an organization, it is easy to forget to check if it is possible to physically generate logs from the servers, security appliances, etc. For example, an organization may want to monitor logs from its database server from a security perspective. In order to do this, it would need to enable certain types of auditing logs from the database management system (DBMS), which, in turn, would increase the CPU usage. Some organizations have their database server working close to its capacity, and enabling auditing logs would create performance issues. If that is the case, adding a database firewall to generate the auditing logs will not compromise the performance, nor would it require the need to upgrade the server.

If it is the first time implementing a SIEM solution in your organization, do not buy excessive quantities of capacity (e.g., storage and computing power). It is much better to start with a realistic (more conservative) approach, and allow the architecture to grow into the SIEM tool. Growing the architecture includes various components of the entire SIEM system (for example, the back-end storage and correlation/analysis systems). An organization can grow the system by replacing hardware with bigger hardware; however, most deployments grow by becoming more distributed, adding more components or separating functions (such as correlation and storage) into distinct systems. For a profound description of SIEM expansion, see “Security Information and Event Management Architecture and Operational Process.”

Pitfall No. 4: Monitoring Noise

SIEM is not log collection, where the goal is to capture and store all logs from all devices and applications without discrimination. Yet a common mistake is to approach it this way, thinking it will be easy to make sense of all of this data once it is in the SIEM system. The predictable result is that what should be an exercise in reducing noise actually amplifies it and generates more of it. Finding a needle in the haystack does not benefit from increasing the amount of hay.

In addition, beyond out-of-the-box correlation rules, reports and dashboards that cover common basic use cases, SIEM tools have to be configured to look for and recognize the activity or events you may be seeking. It is not a magic bullet – throwing data at it and hoping it will automatically illuminate every security problem in your environment will yield nothing but disappointment and disillusionment. Certain anomaly detection approaches such as statistical analysis, deviation from baseline and outlier identification can potentially benefit from larger datasets, but even then the specific type of data is relevant. Despite some basic overlap in functionality and approach, SIEM tools are not big data analytics platforms.

Best Practice: Employ Output-Driven SIEM

To facilitate the targeted and focused collection and analysis of only relevant events and data, SIEM should be output-driven, which means that event data is captured only if it is required for a predetermined output or result. Log and event sources must be admitted based only on specific use cases, correlation rules, reports and dashboards. For example, for the typical use case of monitoring for suspicious outbound connectivity and data transfers, firewall and web proxy logs and network flow data are required. The use case would not, however, benefit from the inclusion of web application access or DHCP logs.

Gartner recommends that a central log management (CLM) solution should be implemented first in front of the SIEM solution. CLM is a critical IT capability that has value for all parts of IT operations, including security. If an organization has CLM, this will allow the controlled selective filtering and forwarding of relevant and in-scope event data to the SIEM tool, permitting an output-driven approach. In addition, CLM allows for later forensic usage or to fulfill nonsecurity requirements, which can be done on the log collection and management tier without polluting the SIEM tool. Another advantage to having a log collection and management tier is that it significantly reduces the time to search a collection of logs from days or weeks to minutes or hours should an organization need to perform this task during an incident response activity. Without it, the task could become a multiweek effort, as logs are manually reviewed by administrators and analysts, and manual correlation of events is attempted. During this time, attackers might still be operating inside the IT environment of the organization and/or could be long gone with the stolen critical information.

Output-driven SIEM requires careful forward planning, know-how around real-world threats (or regulatory requirements and controls), and expertise around the processes and technologies to be monitored. Often this requires the involvement of stakeholders outside of the security organizations. However, a case can be made that these are general requirements for an effective SIEM deployment.

This investment in planning will yield a far more effective SIEM deployment compared to doing this haphazardly. Output-driven SIEM has several benefits and advantages beyond preventing the SIEM tool from being inundated with useless data.

More-focused use cases with selective data ingestion reduce the amount of personnel required to watch and manage the SIEM tool and also minimize the required data collection. This allows for more cost-effective scaling of the SIEM solution.

If you do not know what you are looking for, SIEM will not provide a lot of additional value – especially for the potential costs involved.

On the other hand, there are user and entity behavior analytics (UEBA) tools that can also be integrated with the SIEM solution or from the provider natively to pinpoint threats and improve threat detection capabilities across multiple monitoring systems or other information sources that feed into their platforms. Since UEBA products typically need a data source, and SIEM products are commonly the central aggregation point for security logs for an organization, the tools complement each other. It can almost be a two-way street in the sense that the SIEM forwards applicable log events to the UEBA for user profiling, while the UEBA tool generates alerts that can be sent into the SIEM tool for enrichment with events from other sources, in turn presenting the alert to a security analyst for triage. Also, a SIEM solution in place with the necessary data makes the UEBA deployment far easier, as data collection becomes straightforward. However, Gartner has recently seen some of the UEBA vendors building their own SIEM solutions and competing in that market as well.

Pitfall No. 5: Lack of Sufficient Context

Monitoring an intrusion detection and prevention system (IDPS) via SIEM will add some powerful capabilities: It will correlate the operating system, user logins and network telemetry from the IDPS to significantly enhance behavior monitoring and incident response activities. However, without further context and data sources for correlation, such as access to the application server logs to verify if the attack seen on the IDPS has been successful, the SIEM will not be utilized to its full potential. SIEM does not see anything that you do not provide.

Best Practice: Follow a Formal Use-Case Implementation Process

Generally, these pitfalls can be avoided by following a formal process for use-case implementation that includes the following (see “How to Develop and Maintain Security Monitoring Use Cases” for more detailed information on security monitoring use-case implementation):

  • Use-case selection – Determine and select the initial use case(s), which identify what you are trying to monitor or achieve.
  • Data collection needed – Identify the scope of required data.
  • Log source configuration needed – Configure necessary log and data sources to send the data to, or fetch it from, the SIEM system.
  • SIEM content creation, preparation and selection – Construct the SIEM content (correlation rules, reports, dashboards, etc.).
  • Definition of operational processes required – Define the operational processes to manage this specific use case if required.
  • Test the use case – Generate the anticipated behavior or activity, and verify that everything is configured correctly (see Note 1).
  • Refine the content and processes loop – Remediate and refine any issues and SIEM content.

Pitfall No. 6: Insufficient Resources

A successful SIEM deployment requires skilled people. Once you begin looking, you will inevitably find things; and these findings will require a response. Additionally, a SIEM solution does not run itself. At a bare minimum, it requires ongoing tuning and maintenance to reflect changes in the environment, “threatscapes,” compliance mandates or the gathered data itself. There are three main duties associated with the operation of SIEM:

  • Run – This entails managing and maintaining the underlying infrastructure for the SIEM, ensuring that patches have been applied, that there is sufficient storage, or that users are added or deleted. Typically, this is an engineering task, especially when following segregation of duties per ITIL, for example.
  • Watch – This encompasses real-time event monitoring of alerts and events, and responding, investigating and escalating incidents. A typical role title would be security analyst.
  • Tune – This aspect focuses on the ongoing optimization and tuning of correlation rules, reports and signatures, and even processes involved with the watch duties described above. Often this is done by a senior security analyst or third line.

For most SIEM deployments, the above duties are needed, and require time and a different skill set, to be performed on a continual basis (see Figure 2).

Figure 2. SIEM Duties

Figure 2. SIEM Duties

From “Security Information and Event Management Architecture and Operational Processes”
Source: Gartner (May 2017)

While some airplane mechanics may be able to fly a plane, you would probably prefer a fighter pilot to fly it into combat if the need ever arose. The same is the case with SIEM. The maintenance and administration of the architecture remains under the engineering umbrella and will feel familiar to anyone managing other types of systems or network infrastructure. However, using SIEM – making sense of the data that is coming in, analyzing and responding to incidents, and constructing use cases and correlations rules – requires a security analyst skill set. Many organizations state that there are too many unfulfilled security-related positions, and not enough security analysts, within their organizations; however, concurrently, the salaries for these security professionals have increased substantially.

Not only must there be sufficient knowledgeable staff to manage and maintain the SIEM, but they must also be prepared for the additional work that results from the SIEM. Incidents must be investigated and issues remediated, and these tasks are seldom the responsibility of the security organization; they require other departments and teams.

For a typical midsize bank, a minimum staff of eight to 10 is required to run a dedicated 24/7 security event monitoring operation, with two analysts per shift (not necessarily dedicated full-time equivalents) working three days and having four days off, reversing the week after. In total, there are four 12-hour shifts per week, without taking into consideration vacation, sickness or staff turnover. In addition, this does not include any managers, and it also does not account for how much work is actually there. Rather, it is the minimum to allow real-time, 24/7 monitoring.

Best Practice: Limit the Scope and Engage an External Service Provider

SIEM is not a deploy-and-forget technology, and it does not run itself. Instead, SIEM is a force multiplier. It will allow certain tasks and use cases to be done more efficiently and effectively, but it will not run by itself. There are, however, a few strategies that can be employed to operate SIEM with a low staff contingent:

  • Limit the scope – Adapting the scale of what is being monitored to align with the available resources is a viable option. This applies to the number of monitored data sources, as well as the scope of the use cases. Use cases should be concise and focused so they can be automated via correlation rules as much as possible, and there should be a realistic estimate of how many use cases in total can be managed by the available staff.

    Successfully implementing at least limited use cases can provide risk reduction where it is most needed and can also be used to build a business case for expanding the monitoring scope.

    Engage an external security service provider – Consider an external service provider if you face one or more of the following concerns within your organization due to a lack of internal resources and expertise: managing a SIEM deployment, performing real-time alert monitoring and expanding the deployment to include new use cases. Gartner sees an interest in services to support existing or planned SIEM deployments.

    Co-managed SIEM service providers remotely manage, operate and use the customer’s own SIEM solution. Basic services include management, configuration, rule- or report-writing, and tuning of the SIEM tool. They also offer more-comprehensive capabilities, such as 24/7 security event monitoring and alerting, as well as investigation of security incidents detected via the SIEM tool.

    Managed security service providers (MSSPs) offer real-time monitoring and analysis of security events, and provide log collection via their own SIEM solution for reporting and investigation purposes.

    MDR service providers are an alternative to deploying a SIEM solution, and do not fit the traditional managed security service model. These services typically monitor specific elements of the customer environment and use advanced analytics techniques to identify threats. MDR providers focus primarily on threat detection use cases, and rarely on compliance use cases. MDR vendors may provide their own technology to the customer’s environment, and delivered as-a-service. There is no need for the customer to purchase a commercial SIEM, as the security functions are delivered via shared services from the MDR service provider’s remote SOC.

    Another viable option is on-site staff augmentation (see Note 2), which is also offered by many providers; however, it can be prohibitively expensive, with prices ranging from $150,000 to $350,000 per year per analyst. There are also security consulting services available, but their prices depend on the services provided. For instance, general consulting can range from $170 to $200 per hour, and increasing for incident response or digital forensics, which can range between $300 and $450 per hour.1


1 Based on pricing reviewed by Gartner during client inquiries.

How to Deploy a Security Information and Event Management Solution Successfully

How to Deploy a Security Information and Event Management Solution Successfully


SIEM deployments may stall or fail if not implemented with the right scope, use cases, data sources, architecture, expertise or staff size. Security and risk management leaders deploying a SIEM solution should follow this structured approach to ensure a successful implementation.


Key Challenges

  • Deploying a SIEM solution effectively is predicated on a clear understanding of the scope, objectives, associated use cases, and the availability of trained personnel, a managed security service provider (MSSP) or a co-managed SIEM service provider.
  • Throwing all possible event and data sources at the SIEM solution at once, without considering what the sources are used for, will be setting the SIEM initiative up for failure, and will lead to an unsuccessful deployment.
  • A poor architecture choice can have wide-ranging consequences, from insufficient capacity and a lack of redundancy and disaster recovery capabilities to an inability to meet future objectives, while spending too much.


Security and risk management leaders responsible for security monitoring and operations should:
  • Use a phased, output-driven approach to deploy a SIEM solution. Determine the scope and use cases, and build requirements from those inputs.
  • Prioritize use cases and iteratively onboard those use cases in a methodical manner to gain experience and build competence with the SIEM solution.
  • Work with line of business (LOB) owners and IT systems operators to refine logging and audit capabilities to ensure the data sources are generating logs/events specific to security use cases.
  • Implement a suitable deployment architecture, whether on-premises or cloud, to address the specified use cases with acceptable performance, and to enable future expansion.


Before embarking on a security information and event management (SIEM) implementation project, an organization needs to understand the overall project life cycle. There are multiple stages within this life cycle, and they are all an integral part to ensure a successful SIEM solution deployment (see Figure 1).

Figure 1. SIEM Implementation Stages

Source: Gartner (March 2018)


SIEM Implementation Stages
In “Establish Scope and Requirements for a Successful Security Information and Event Management Deployment,” Gartner defines the tasks that are needed to plan for a successful SIEM deployment. This particular research explicitly focuses on the deploy stage. It provides specific guidance for organizations that have understood the requirements and responsibilities of maintaining and running a SIEM solution, and that have decided to deploy it either on-premises, self-hosted in a public cloud service (PCS), or hosted by the vendor or a third party. However, if your organization does not have the expertise, nor the resources to implement, manage, maintain and monitor a SIEM solution, there are operating models available that might be more appropriate, such as using:
  • Managed security services (MSSs) (see “Magic Quadrant for Managed Security Services, Worldwide”)
  • Managed detection and response (MDR) services (see “Market Guide for Managed Detection and Response Services”)
  • Co-managed SIEM services (see “How and When to Use Co-managed Security Information and Event Management”)
You could also invest in something else first, for lower effort and reduced cost-risk (see “Use Central Log Management for Security Event Monitoring Use Cases”).


Use a Phased Approach

The inherent complexity of an enterprisewide SIEM deployment can be lessened by taking a tactical and phased deployment approach. Focusing on quick wins by the sequential implementation of specific use cases enables ultimately reaching the desired scale and strategic objectives. Except in very small and restricted environments, the “collect all at once and sort it later” approach never results in a successful and effective deployment.
There are two approaches to a phased SIEM deployment.

Deploy Log Management First

Security and risk management leaders need to carefully assess whether the log management and collection architecture should be deployed first, either by a separate central log management (CLM) solution or by using the SIEM’s log management capability. Indeed, SIEMs have two main components, a base layer of CLM functionality and an additional layer for some security analytics. Most SIEM vendors are capable of selling this CLM solution separately (also known as SKUs [stock keeping units]) for clients who just want a CLM functionality. CLM is a critical IT capability that has value for all parts of IT operations, including security, and it provides some benefits to the organization if deployed first. Some of the benefits are:
  • It is relatively easy to deploy and can deliver visibility into user and resource access activities, including security-related ones, and it aligns well with compliance use cases (see “Security Event Monitoring Options for Midsize Enterprises”).
  • Event management is easier to deploy from a scalability and performance perspective when log management functions enable selective forwarding of events to the event management function. This will also impact the ultimate specifications and subsequent price for a SIEM solution.
  • Already-collected log data can then be used to develop security-specific correlation rules and use cases, and event data can then be selectively forwarded to the SIEM system.
Operationally, deploying log management first:
  • Allows for later forensic usage or fulfillment of nonsecurity requirements, which can be done on the log collection and management tier without polluting the SIEM tool.
  • Significantly reduces the time to search a collection of logs from hours, and sometimes days to minutes, should this need to be performed during an incident response activity. Without it, the task could become a slow and onerous effort, as even an ad hoc, manual collection and centralization of logs can be very time consuming when these are distributed across the enterprise and across organizations’ technology stacks.
You may come to find that your organization may already have existing log management infrastructure. If that is the case, a gap analysis ensuring the scope is consistent with the objectives for the SIEM deployment will be required.
It may seem counterintuitive to differentiate between SIEM and log management. However, SIEM is not suited to be an enterprisewide log management solution per se, where every log source regardless of security use-case value is collected and stored for the purpose of forensics, operational monitoring or regulatory compliance. SIEM is about monitoring and identifying security-related violations and incidents. It does not benefit from additional data for which there are no corresponding correlation rules, dashboards or reports, but it can suffer for it. There are also more cost-effective ways of providing pure log collection and storage than a full-fledged SIEM solution (see “Use Central Log Management for Security Event Monitoring Use Cases”).

Use-Case-by-Use-Case (Output-Driven) Approach

In this scenario, use cases are planned and implemented one by one. Supporting log management and SIEM components are deployed in support of each use case, and the process is repeated. This is an output-driven approach (see “Overcoming Common Causes for SIEM Solution Deployment Failures” and Figure 2).
The sequence of use-case implementation should be determined by the combination of critical need balanced with quick wins, based on the lowest effort to the highest risk reduction. These quick wins can then provide early metrics for business justification of the investment in SIEM, and also give security and risk management leaders responsible for security monitoring and operations confidence to expand the use cases further. As the process matures in a “crawl, walk, run” fashion, the organization can move to implement batches of use cases as part of sprints — especially when the use cases share similarities on chosen technology, data sources and objectives (see “How to Develop and Maintain Security Monitoring Use Cases”). Furthermore, a phased, use-case-by-use-case approach will build momentum within the organization for more complex use cases with greater scope.

Figure 2. Output-Driven SIEM

From“Security Information and Event Management Architecture and Operational Processes”

Source: Gartner (March 2018)


Output-Driven SIEM

Nested Phasing
Beyond implementing a use-case-based approach to evolve and expand the SIEM deployment, real-world users will often find that additional organization units, network environments or even geographies have to be included in the future security monitoring scope. There are two ways to approach this. You can apply the phased, output-driven approach to each new environment, implementing each use case until all have been applied before moving on to the next environment, essentially nesting the phases. You can also begin managing correlation rule sets as policies to facilitate a more rapid rate of scope expansion. The effectiveness of this will depend on how standardized your environments are. If a correlation rule set is applied to an environment and a large percentage of the rules need extensive modification, then the phased use-case-by-use-case approach may be better-suited, even if just individually enabling the associated rules.

Refine Your Monitoring Policy

Logging policies implemented to monitor event sources in support of general IT systems will often be very different from those required for effective security monitoring. After the use cases have been developed, a better understanding will emerge for the data sources that need to be collected and managed, and the level of detail required for logs and events from these sources (also known as “verbose level”). Security and risk management leaders need to work closely with LOB owners and IT systems operators (as well as the team responsible for threat intelligence, regarding newer threats) to assess the current logging level and apply audit-level changes to in-scope event sources. This enables the generation of events relevant to security use cases. It is important to note that attempting to send all of your logs to the SIEM solution at once, and hoping to be able to clean up later is one of the main causes for a SIEM solution deployment failure. Doing so drastically increases the cost to maintain the solution, while reducing its effectiveness to detect threats and deliver mandated compliance outcomes. Unfortunately, a “habitable zone” is nonexistent since sending too many logs to the SIEM solution is just as bad as not sending enough. Instead, align your SIEM solution to the specific use cases, which should already be prioritized according to the organization’s needs, then instantiate a logging regime that meets those needs. Part of this activity requires an assessment of the logging policies of the required log sources to verify whether necessary security events are being generated and, if not, to identify the required changes to allow that to happen (see “How to Develop and Maintain Security Monitoring Use Cases”).
Enabling extensive logging and auditing on any system can potentially have an effect on the performance of that system and your SIEM solution. This needs to be carefully assessed. In some cases, the infrastructure may simply be unable to cope with the additional load without detrimental effect on any hosted services or applications. For example, the network can be overloaded with traffic from too many sources with too high a verbose flowing to the CLM and/or SIEM. Databases are especially susceptible due to the large amount of resulting disk activity. They can benefit from prioritizing the categories of events and/or alternate approaches to getting the required information, such as third-party database audit and protection (DAP) tools, workstations, and endpoint protection and response (EDR) solutions. Also, increasing logging horizontally (for example, by adding more context, such as usernames, through X-Forwarded-For [XFF]) can have more advantages than adding extra events.

Follow Log Source Sequence

Use cases should determine security data collection decisions. For example, if you are trying to implement account compromise by monitoring authentication events, then active directory (AD) logs should be collected. The sequence of log source integration should be determined on the basis of importance and feasibility. Establishing some quick wins can build credibility and momentum for the monitoring program, and provide valuable experience to enable you to tune the SIEM deployment. Furthermore, doing so can give you the experience and trust in the solution itself to create more use cases. It is important to note that not every log source type will be relevant to every organization, but they should support the desired use cases. Based on these criteria, we can list the log source integration sequence we see implemented in general by most organizations (the list below does not imply any specific order or priority):
  • Network firewalls
  • Intrusion detection system (IDS)/intrusion prevention system (IPS) devices
  • Network sandboxing
  • Network and host data loss prevention (DLP) solutions
  • Web proxy logs
  • Authentication server logs, such as Windows Active Directory and virtual private network (VPN) access logs
  • Internal DNS server logs
  • Server activity, such as UNIX and/or Windows
  • Cloud service application programming interfaces (APIs)
  • Endpoint security logs (such as antivirus and host IPS)
  • Web server and web application logs
  • NetFlow data
  • Database logs
  • Application logs
Although this exact log source integration sequence should not be construed as a best practice or as a recommendation, it is something Gartner still observes with its more successful clients, and can be used as a rough guide. It should also be noted that this sequence could be used for a subset of some event source types (for example, critical web servers and critical database instances first, followed by moderate-criticality resources). For more information on logging policies, see “Security Information and Event Management Architecture and Operational Processes.”

Use a Deployment Architecture

There are several broad architecture choices that can be used for an enterprise SIEM solution deployment, such as:
  • A single SIEM solution with all components, including log collection and retention, contained within the same system (“appliance SIEM” architecture, suitable for small organizations)
  • A single SIEM solution with collection components distributed across the organization and centralized log storage and analysis (“single SIEM” architecture)
  • Multiple SIEM solutions, one for each region or each data center (“multiple SIEM” architecture, where individual systems may or may not be connected)
  • A federated SIEM solution, in which a higher-tier SIEM system gathers select information from individual SIEM deployments at lower tiers (“federated SIEM” architecture)
  • A SIEM solution delivered as a service (simplifies and reduces the time to implement, administer, maintain and scale, while reducing licensing complexity — see “Innovation Insight for SIEM as a Service”)
  • A SIEM solution hosted in a service provider’s data center or public cloud service (PCS), such as Amazon Web Services or Microsoft Azure
  • A SIEM solution delivered from the cloud as a software as a service (SaaS) application
How the deployment will need to be managed and maintained, and how to expand the scope going forward, will be the indirect result of the choice of architecture, whether deployed on-premises or in the cloud. Also, each architecture type poses slightly different challenges in regard to redundancy and backup requirements, and considerations such as data governance or cross-border privacy issues.
Since SIEM solution architectures vary, some vendors provide collectors that only forward or buffer data, while others provide horizontally and vertically scalable distributed collection, processing and analysis capabilities.
In a SIEM implementation, log management systems (or components) may be deployed in different locations for on-premises deployments. The purposes of log collectors are to:
  • Feed SIEM solutions and log management solutions.
  • Feed into log management solutions, which then send filtered sets into SIEM solutions.
  • Feed SIEM solutions with unfiltered sets of data that are then streamed into log management solutions.
On the other hand, if deployed in the cloud, the organization accepts storing its data either in the SaaS SIEM vendor’s cloud or on a collector controlled by the vendor. In this case, the customer needs to keep in mind that if access to logs requires API keys, or requires credentials on particular systems, then these keys and credentials need to be shared and stored outside of their premises.
Ideally, log collectors are placed closest to the data they need to collect. Organizations should plan at least one collector per site, with distributed storage locations for raw data in the largest environments. In some instances, a security data lake can be implemented, in which a log collection and management tier leverages commercial and open-source log tools, as well as big data platforms. This typically occurs in organizations that already have those technologies deployed and have internal expertise available to the security team. A distributed architecture also requires a secure communication channel — for organizations leveraging the internet — to ensure that the data confidentiality, integrity and availability attributes are respected (usually requires encryption, and store and forward mechanisms). Lastly, the performance (or connectivity for cloud deployments) has to be considered, as well. A vertical architecture with too many tiers can introduce delays that will make real-time monitoring difficult.
Single SIEM systems will often suffer from performance issues when high ingestion rates, analysis and reporting are done concurrently. SIEM systems are mainly designed for ingestion reliability at the cost of processing. This type of architecture also lacks redundancy and requires an external backup facility, which is a valid concern, especially if used for regulatory compliance purposes. An alternative, or more importantly a best practice, would be running a production/development system as a failover. In other words, have a smaller production/development system in place that doesn’t take large log feeds, and can test the log feeds that have been ingested without affecting the actual SIEM solution. However, if deploying in the cloud, compensate for cloud-related issues by designing the architecture and associated processes to include additional resilience factors, such as connectivity (see “Selecting and Deploying SaaS SIEM for Security Monitoring”).

Context Data Source Integration

Beyond event and log data, SIEM systems also ingest contextual data, such as:
  • User context from identity and access management (IAM) solutions
  • Asset context from configuration management databases (CMDBs) or asset inventory solutions
  • Threat context from threat intelligence platforms (TIPs) or services
  • Vulnerability context from vulnerability management/assessments
There are specific use cases that may require these, but these sources also provide general context for event data (for example, by adding user context to a specific event).
These may have different functional requirements depending on the integration mechanism (for example, deep integration via bidirectional APIs or even just a flat-file import). Connectivity between the SIEM system and the contextual data source must be considered, as well as organizational aspects, such as including context that identifies the LOB owners and/or system operators (see “How to Develop and Maintain Security Monitoring Use Cases”).
Gartner defines several types of context that are useful for security monitoring (see Table 1).

Table 1: Sources of Context Data

Enlarge Table
Context Type
Typical Source
User context
IAM systems and directory services, and other user repository information, such as human resources information (for example, employees who have joined and left the organization)
Asset context
Asset management systems, directory services and internal SIEM asset subsystem
Vulnerability context
Vulnerability Assessment (VA) tools, dynamic application security testing (DAST) and static application security testing (SAST) tools
Threat context
Tactical threat intelligence (TI) feeds that present lists of “bad” entities, such as internet Protocol (IP) addresses, domain name system (DNS) names, URLs and file hash sums
Configuration context
CMDB and VA tools with security configuration assessment capability
Data context
DAP and DLP tools and data management systems
External context
Public and private TI feeds and social media monitoring
Application context
Infrastructure and business applications, and DAST and SAST tools
Business context
Business unit managers, personnel and business applications, and integrated risk management (IRM) tools
Location and physical context
GPS sensors built into systems, network location data and physical access control systems
Source: Gartner (March 2018)

SIEM Integration Considerations

When planning for a SIEM deployment, organizations should also consider how users will interact with the SIEM, and where and how the SIEM integrates with the overall organization security workflows and processes. Specifically:
  • What is the organization’s overall workflow for end-to-end security monitoring and remediation?
  • How are the SIEM alerts managed? Is the triage, investigation and remediation done manually by people, or are the alerts fed into other tools?
  • If the level of analytics of the SIEM is not sufficient, are the SIEM alerts and event context dynamically fed into User and Entity Behavior Analytics (UEBA) systems (see “Market Guide for User and Entity Behavior Analytics”)?
  • If the alerts need to be triaged, and extensive real-time context needs to be applied for this investigation, does the SIEM integrate with Security Orchestration, Automation and Response (SOAR) tools (see “Innovation Insight for Security Orchestration, Automation and Response”)?
  • Does the SIEM need to integrate with the organization’s case management or IT Service Management (ITSM) corporate solutions?

SIEM Architecture Dimensions

The following attributes may affect SIEM architecture choices and need to be assessed and considered:
  • Number of log sources
  • Volume of logged data to be collected and analyzed
  • Types of collection mechanisms utilized
  • Specific set of use cases (across all phases of the project)
  • Network topology
  • Available bandwidth
  • Regulatory compliance issues, including log retention period mandates
  • Log retention locations, both physically and logically (for example, physically stored in a country, but by an outsourcer), as well as log retention duration
  • Data governance, cross-border privacy issues and legal limitations
Choosing which data to selectively forward in a distributed environment (for example, to facilitate centralized organization-wide threat monitoring) will be a key decision. The output-driven SIEM approach, based on use cases, will provide a framework for this, as well. Generally, log data not immediately required for a specific use case should not be forwarded. It will not provide any immediate security benefit, but it will add noise and impact performance. The organization can still access the raw log data itself in its original form, if required for investigative purposes. The “let’s collect it just in case, you never know” approach needs to be balanced with pragmatic cost, efficiency and scalability considerations.
Table 2 provides an outline to create a high-level plan for a SIEM architecture.

Table 2: SIEM Architecture Dimensions

Enlarge Table
Architecture Dimension
SIEM Architecture Impact
What problems will a SIEM solution solve?
A high-level list of problems that a SIEM solution is purchased and deployed to solve has a primary architecture impact.
Use cases
Why is the system here, and how is it used (depends on goals)?
Specific use cases for initial and later phases affect where and how different components are deployed.
Who would be using the system?
The number of users of the system affects information presentation architecture.
Collection scope
What will data do (depends on use cases)?
The scope of data collection, itself defined by the use cases, affects the number, size and distribution of collection components, and determines which data should be collected for alerting versus reporting.
Event source topology
What data sources are located at various remote sites?
The location of different types of log sources at different data centers and remote offices affects the number and placement of collectors and distributed storage.
Retention scope
What data is stored, and for how long (depends on use cases)?
Log retention scope defines what types of data are stored and where and how that data is stored.
Organization’s size
What is the overall size and complexity of organizational networks?
The size of an organization, and specifically the size of its IT environment, affects scalability requirements.
Organization’s distributed nature
Is the organization globally distributed?
The distributed nature of an organization affects not just collection architecture, but also retention and data analysis of a SIEM product.
Organization’s IT approach
Will there be somebody using a tool in each region or just in a central location?
A centralized or distributed approach to IT maps to SIEM architecture and affects a choice of single or federated SIEM deployment.
Integration with upstream systems
What systems will consume SIEM output?
SIEM data may flow to a UEBA system, SOAR tool or an IRM tool, and the methods for data selection and transfer need to be decided on and implemented or configured.
False Positive Reduction
Does the organization have processes to adequately understand how its content is performing?
Continuous feedback can help with reducing false positives. Data that is aligned to the SIEM solution’s performance should be analyzed annually. The processes in place to reduce false positives and remove inefficient rule sets should be carried out on a regular basis.
Context data integration
What additional data will need to be collected to enable the required analysis?
SIEM may collect all the right logs, but it may need links to identify management, asset management and other enterprise systems. Such links need to be defined and implemented.
Source: Gartner (March 2018)

Additional Architecture Questions to Be Answered Before the Deployment Stage

Organizations should be asking themselves additional questions before deploying their SIEM solution, such as:
  • Where should we use agents versus agentless collection of log and context data (if there is a choice)?
  • What collector form factor (appliance, software or virtual image) should we use? How many collectors? Which collector types?
  • Can we use independent collection and routing technologies, such as Apache Kafka and NiFi?
  • How do we decide which log sources go into which collector if there are many collectors per site?
  • How do we deal with super-high-volume and super-low-volume log sources?
  • How do we architect log collection around network architecture boundaries, such as zones and access control lists (ACLs)? Specifically, how do we run demilitarized zone (DMZ) log collection?
  • Is there a separate audit zone in network security architecture?
  • Can correlation be distributed? Tiered? How will the log data be routed to different correlation engines, and where should each rule run?
  • How can storage be distributed across sites?
  • What is being stored: structured data, unstructured data or both? Can many data stores of structured or unstructured data be queried from one place?
  • What do we do when any particular component becomes oversubscribed?
  • How will redundancy, availability and recovery be architected? How will the data be backed up? How fast can a reserve instance be brought online?
  • Is there data caching in lower-reliability areas of the network to ensure data will not be lost?
  • What network architecture constraints (such as connectivity and link bandwidth) are in place, and how do we work around them for log data transport? How is log transport redundancy architected given the above constraints?
  • How, and from where, can you get NetFlow data?
  • How do we deal with other external constraints on architecture: firewall rules, security policy, available servers and user population?