Executives Anonymous: What’s a SIEM? (and why you should care)

Executives Anonymous (EANON) aims to help inform the decision making process for executives and managers who may be new to the security field or even want (or need) to be better at resource control and optimization of their team’s tools. 

What You’ll Learn

1. What are logs.
2. What is a SIEM and why it matters.
3. SIEM Caveats
4. SIEM Best Practices
5. How to measure your team’s SIEM success.

What’s a Log?

To understand the role a SIEM plays in your network, you first need to understand what a log is. Every device in your network from switches, firewalls, EDR (think antivirus on steroids), door access controllers, to even your corporate style coffee machine generates logs (ask us how we know).

A log is a record of events that happened such as “user John Doe logged into a server”, “John Doe opened a file called “employees.xls”, to items such as “an IP address based on China is trying to connect to your business network.” 

Every device on your network produces some level of logs (records) for each and everything thing it processes. Depending on the device, how often it’s accessed, and the size of your network. Logs per device can range from a few events an hour to hundreds of thousands of logs per hour. It’s worth noting, not all logs are created equally. 

While as a whole they can paint a very detailed picture, logs from a coffee machine won’t actually help as much as logs from your production servers.

What’s a SIEM Anyways?

What’s a SIEM? Chances are you have one, your team is asking for one, or it’s a line item on the budget and you’re not sure why you’re paying for it. SIEM or security information and event management is a tool that aggregates data (logs) across all of your products giving you centralized insight into your network, makes triage and root cause analysis significantly faster, and aids in compliance efforts around logging requirements and retention. 

The easiest way to think about a SIEM and how it functions is to visualize a funnel and large bucket. Data from each and every one of your devices (firewalls, switches, door controllers, servers) all live in separate locations or buckets. Those buckets are all then funneled to your SIEM and aggregated into one tool.

How is it configured (Sending Logs)? 

Being that centralized logging is a critical function to maturing  organizations, a majority of devices now have a built-in function to send logs out of their product and somewhere else, such as a SIEM. In those devices you just enable the function to send logs, provide the IP address or hostname of where you want those logs sent, and you’re done. 

Other devices may not have that functionality built in. In those cases you can typically install a small piece of software that then collects those logs and similarly ships them to the location of your SIEM. 

Log Retention

Your team should have clear direction on logging requirements. This may be informed by a compliance requirement such as HIPPA which is 6 years, or PCI which is 1 year. If you have no mandated requirements, determine what length of time the business is willing to accept visibility into and without. 

At Hurricane Labs we prefer at least 1 year of logging. If you can’t do that, we’d recommend no less than 6 months if possible. However, if that’s not possible at the moment, do no less than 90 days. Anything less and you lose historical insight to inform use cases, look for zero days, and understand what is “normal” and “trending” in your environment. 

Log Storage Types

Storage is typically divided into three tiers: hot, warm, and cold storage, each serving a different purpose based on performance, accessibility, and retention needs. Hot storage is designed for real-time threat detection and active investigations. It stores the most recent logs, providing fast search capabilities with low latency, but has a shorter retention period, usually spanning days to weeks. This high-performance storage enables quick access to logs for immediate security analysis.

Warm storage acts as an intermediary between hot and cold storage, retaining logs that are not needed in real-time but still require occasional access. While slightly slower than hot storage, it offers a balance between speed and cost, making it ideal for incident investigations, compliance reporting, and forensic analysis. Logs in warm storage are generally retained for weeks to months, ensuring analysts can review past events when needed.

Cold storage is the most cost-effective tier, used for storing logs long-term (months to years) for compliance, audits, and deep forensic analysis. It has slower retrieval times but is essential for regulatory requirements and historical threat hunting. While it lacks the speed of hot or warm storage, it plays a critical role in maintaining log availability for extended periods without incurring high storage costs. Cold storage may ultimately live within your SIEM, or can be often rolled off into cheaper cold storage such as storage provided by AWS, Microsoft, or Google. 

Your data should go through all of the above stages at some point. A log comes into the hot dataset, after a few days moves into warm, after a few months moves into cold, and eventually rolls off into long term cheap storage typically called frozen. Note depending on the product cold and frozen storage may no longer be accessible in the SIEM. In order to search these logs they’d then need to be “thawed” and re-sent to the SIEM.

Why Does Centralized Logging Matter?  

There can be plenty of reasons why this could benefit your organization, but the few that really matter are faster incident triage (remember every second counts), correlating events across multiple products, and simplifying your security team’s understanding of your own products. 

Incident Triage 

When your network is under attack, every second counts. Chances are you have dozens of products, appliances, and network locations throughout your organization. If you receive an alert for unauthorized logons to your network, where do you start? 

You need to understand where the traffic came from which starts with wasting time on understanding where to even look, which then could lead to logging into and checking dozens of different firewalls, switches, servers, and maybe even user workstations. Add in the complexity of how and where logs are stored. Looking at logs in a firewall are nowhere near similar to logs from Microsoft 365, or even a Windows server.

This means your team will spend additional time looking at logs in different formats, locations, and manually correlating timestamps of when each event happened and in what order. Below is a sample of logs from a firewall, Microsoft 365, and a Windows server.

(Checkpoint Firewall Sample)

(Linux Sample)

(Windows Server Sample)

As you can see, each platform looks different, and while the logs have some similarities they are still laid out differently. And if you’re hunting down an IP, for example, you need to check all 3 products via different searching methods for that IP. If that doesn’t sound like a lot of work, trust me, it is. 

All of this doesn’t even take into account the possibility of the device logs you’re checking being compromised. If a hacker or malware is running on that Windows server, it may make your time in logs incredibly difficult. It could cause slowdowns, or as Ransomware commonly does, it could wipe out all of your logs making root cause analysis significantly harder. 

Now what if you could look through all of the same logs above in one place, presented in the same format, and not be impacted by any changes Ransomware makes after the event has already been logged? Enter SIEM. 

SIEM reformats all of your logs into a unified format in a central location. The logs are still easily identifiable across products so you know what you’re actually reviewing, and due to that means you can search for a single IP (or multiple) across EVERY product in your network at the same time. Ransomware wiped out logs on a server? Not a problem, until Ransomware disables logging, all events leading up to compromise will have been logged and sent to the SIEM. Maybe you have (hopefully you don’t) a Hacker moving laterally through your network (device hopping), track the activity down and create a timeline of events. This lets you know where they’ve been and where they’re going. Below is a sample from Splunk (though each SIEM vendor has a similar function and layout). 

(Splunk Log Sample)

Correlating Events

Using a lot of the same logic discussed prior around triage. You can use a SIEM to correlate multiple events both as part of an investigation, as well as more proactively as part of alerting. Let’s say you have a compromised user “JohnDoe”, you can search for any activity “JohnDoe” has performed by typing “username=johndoe” and clicking “search.” This will return all events where the username JohnDoe was seen. You can even select time periods to narrow the traffic to only what matters. 

Let’s say one of those events shows JohnDoe logging into a server he shouldn’t. You can easily search logs on that server to see what JohnDoe did. The key here is that you don’t know what you don’t think about. If you had to manually look through all of these machines, would you have considered reviewing this specific server? In my career, plenty of malicious activity has been uncovered by doing what we call a “caveman search.” Which means looking very generically across all logs for a single item such as a username or IP. You may be surprised, or scared, to know it’s not uncommon for a client’s SOC to say “we didn’t even know that existed.” 

The last piece of this is being proactive, or reducing the time to respond. You can schedule searches (alerts) to run as frequently as needed checking logs for malicious activity and alerting you when that malicious activity is seen. You can write a search that looks for any account logging into a server that shouldn’t be. Shortly after it happens, you’re alerted, and you can respond immediately. We’ll talk more about building your detection library later. 

Simplified Network Understanding

SIEM at the core, makes it easier to understand your network and what’s going on within it. When you hire a new employee in, they can start investigating incidents in your SIEM immediately. Even if they don’t yet fully understand your network, anyone you’re hiring as of 2025 should understand logging, SIEM, and quickly be able to understand how these events correlate together, even without knowing anything else about your network. That being said, please take the time to document your network and train your employees on how they’re all interconnected. This will save you time during your next incident.

Include the fact that during an incident, panic can create bias and brain fog on what next steps are. In tough times like ransomware traversing your network, a SIEM can help create clarity on next steps. 

SIEMplifying Logs

Each SIEM will have their own name for it. But our SIEM of choice, Splunk, calls it CIM or Common Information Model. While others like Elastic call it ECS, they all mean the same thing. Taking the diverse and varying log types and aligning their data under unifying fields. For example you may have the following IP format across several products.

• Firewall: sourceip = 192.168.1.1
• Windows: source = 192.168.1.1
• EDR: src.ip = 192.168.1.1
• Exchange: sender = 192.168.1.1

While you can clearly see they all have the same IP address in common, that’s where it stops. Each of these products have different ways of displaying “source ip.” If you left these as is and wanted to find the IP of 192.168.1.1 across your network, you’d need to write a search such as “sourceip=192.168.1.1 OR source=192.168.1.1 OR src.ip=192.168.1.1”. One this requires you to remember how each field varies, and two missing just one of these means you’ll completely ignore possibly critical logs. 

Splunk, like other SIEMs, has you re-write all fields to be matching. In the above example, once the logs are ingested into Splunk (or your SIEM) they’d be all moved to having “src_ip” as the field you need to care about. Instead of the long search above you could just type “src_ip=192.168.1.1” and it will immediately search ALL logs in your SIEM where the src_ip (source ip) matches. This is true for most other fields as well. Destination IPs, actions, user names, source port, destination ports, and so on. 

Consider if you have an active incident and all you have is a single ip address to start with. How easy is it now to find any and all related activity to what that IP has done! You just need to know the IP and know src_ip= to start search. Or even just a username! John Doe has been compromised, let’s find everywhere John Doe has logged in with “username=johndoe” and search!

This is where the true power of a SIEM is showcased. Your logs have been aggregated across the network, put under a common format, and can easily tie events together to paint a detailed picture of an attack against your network. 

Detect Malicious Activity….Automatically

Now that you know how a SIEM works and the core reason it’s a powerful tool to have in your arsenal, how do we get a bit more proactive? Instead of waiting for user complaints that they have weird pop-ups, or finding out a server is offline, how do you detect the threat sooner? 

This is where alerting comes in. Alerts are just scheduled searches that run on pre-determined intervals. Those searches run, look over your logs, and if there’s any matches generate a detection to your SOC for review and possibly remediation. 

Again remember these searches can run across all of your logs! Running a scheduled search to look for any malicious activity across all matching logs is a big deal! Remember a lot of products like your exchange servers or even Windows servers can’t alert on the same type of activity within their own product wheelhouse. Meaning, without a SIEM you won’t know some of these things are even happening until it’s too late. 

While we’re not here to talk about how to build a use case library, the best method for building an effective use case development program, or what is the measurement of success. It’s worth calling out that use case development (alert creation) is not automatic. 

Every SIEM will come by default with a repository of use cases that you can use. You should NEVER just turn these on. They are blueprints for your team that sometimes won’t even work for your environment or worse generate hundreds of unnecessary alerts per hour. 

Best practice is always to assess the use case, re-write it for your environment, and refine it to the point it should only fire if a legitimate issue occurs. We’ll cover this in a future write up, but the key takeaway for this section is that flipping on all of the out of the box use cases is always a bad idea. If your team or MSSP is doing that without proper assessment, this should cause you concern. If your MSSP tells you they can turn on 100+ use cases today for you, again, be concerned. These are typically unrefined for your environment and will cause you headaches.

Zero Days / Emerging Threats

Every day there’s a new emerging threat or a disclosed zero day. How do you know if you’ve been compromised due to these? Easy! Find out what the indicators are such as an IP address, file hash, or powershell command. Then look back 30, 60, 90 days, or if you have it 12 months! Zero days being disclosed today, do not guarantee they were not exploited prior. It just means we’re all now aware. Using your SIEM you can look back and know if this zero day, was already in your environment. 

SIEM Caveats

Hopefully by now, if you take nothing else away. You’re aware that a SIEM centralizes all of your logging, reduces time to triage incidents, and can create a proactive alerting environment across all of your logs. But the grass isn’t all green is it? 

Some of the misunderstandings with what a SIEM can do are typically as follows.

1. Just send your logs to SIEM and you’re ready.
2. Alerting is automatic.
   1. Turn on all of the use cases (alerts)
3. SIEM will remediate the issues. 
4. SIEMS only work with data.
5. Is my SIEM a SIEM?

Send Your Logs

The easy part is typically pointing your logs to your SIEM. But from there you need to make sure those logs can pass through any firewalls in-between, the proper apps/receivers are installed in your SIEM, and the logs are properly formatted and searchable. Some apps such as Splunk TAs or Elastic Apps will try to format known logs in the correct manner. However, sometimes your firewall receives an update changing how logs are presented, and the SIEM app hasn’t yet been updated. Or sometimes, vendors just don’t have apps. This means your team needs to create custom parsing of those logs and manually map the fields. The good news is, unless something changes on the sending side, this is usually a set and forget. 

When someone says it will take some time to get logs in, that’s a valid statement. They can go very quick, or they can take days of configuration and parsing. But again, once it’s done, if nothing changes, it’s done!

Alerting is Automatic & Turn On All The Use Cases

As we had just covered a few sections back. Alerting is not automatic, and you should never just turn on all the use cases. Each use case both from the out of the box content (OOTB) or even a theory around a new detection will take time to fine tune. You need to consider what to look for, where to look for it, and what is considered normal? An employee failing to logon at 8AM a few times before successfully logging on, likely isn’t a threat, if anything it’s a coffee problem. However, a user who has 50 failed logon attempts in 5 minutes is likely something malicious. 

As you refine the search you need to consider what is normal for your network. No two networks are the same. Yes there are common core principles but we’ve seen some wild “normal” activity that for any other network would easily be an all hands on deck because we’re in a compromised situation. Know that a solid use case that won’t burn your team out should be refined to reduce false positives and only trigger when it requires genuine attention. 

SIEM Will Remediate Issues

SIEMs are like central dispatch. If you call your local police department in a panic they’ll ask information about what happened, understand the current state of the situation, and work to get help to your location ASAP. That’s a SIEM. A SIEM tells you more about what happened, lets you know the current situation, and then directs your other teams and tools to the right place to start resolution. 

Security tools have come a long way! While a SIEM typically will not remediate natively, a lot of SIEMs such as Splunk do have some level of built in “actions” that can be taken. Usually these require some python knowledge and custom development, but you can build out triggers to run some level of actions in your environment. 

To be honest though, this is where a SOAR tool comes in. Not a topic we’ll cover here today. But know a SOAR is a Security Orchestration, Automation, and Response tool. This tool interacts with all of your other tools to automate actions or even create a centralized incident response center. 

SIEMs only work with data

SIEMs aren’t perfect. If your SIEM goes down, or the product sending logs breaks, your SIEM will be blind. Write alerts to notify you if data stops coming in. The bare minimum would be to write an alert looking at each index (data type) and if results 0 generate an alert. 

Is my SIEM a SIEM? 

We often get told by customers that they already have a SIEM, or they plan to cut certain features because they don’t need that for their SIEM. SIEM has a specific and small level of requirements to be a SIEM. The important thing to know is that if your “SIEM” doesn’t contain security functionality, it’s not a SIEM, it’s just log management. 

Splunk for example has an additional add-on called ES (Enterprise Security). ES adds a slew of features such as correlation searches (robust alerting) and centralized incident management among other things. Those pieces make Splunk a SIEM. If you remove ES, Splunk Core still allows you to search, it also allows you to generate reports and small alerts. However, it’s no longer considered a SIEM. Elastic prior to adding their “Security” module around 2 years ago, was also just log management, not a SIEM. 

What you need to be aware of is that some compliance may require you to have certain functions within your security logging tools that only a SIEM offers. The last thing anyone wants to do is fall victim to a failed compliance audit. While a full SIEM does cost a bit more due to additional functionality, just know it builds a significantly more robust security functionality that will over the long term help you detect more and reduce false positives. 

XDR: Do I Need my SIEM?

Yes. If that’s all you came here for, the answer is YES! We won’t fully dive into XDR here today, but due to some incredible marketing, XDR has positioned itself as the SIEM killer. I won’t lie, XDR does some cool stuff. I also believe there’s a solid future where XDR and SIEM are one in the same, it would make perfect sense! However, they’re not currently the same. SIEM will accept any and all logs, as long as you can get them there. XDR will only accept supported log types (typically vendor restricted, ie not all firewalls but only certain firewalls). They also, as of now, have a more limited supported type of logs. While this is a growing list, usually they take EDR logs (XDR is usually an expansion of EDR for some vendors), Firewall Logs, and other network related logs. Some are expanding into supporting e-mail and Microsoft 365, but again are restricted to only certain log types.

That being said, where XDR shines is the fact that most have some AI component assisting with threats, as well as can take action to remediate those threats. Again, something a SIEM cannot typically do natively. We like to look at a SIEM as our central dispatch and XDR as one of our patrolmen. XDR is out there also actively looking for threats and stopping them in real-time. But if dispatch (SIEM) calls, they can be directed towards an active incident to help resolve the threat as well. 

I’ve provided a simple comparison below, but you should walk away from this knowing that while XDR should be a tool in your team’s belt, it is not yet a replacement for a SIEM with solid established alerting. 

SIEM Cost Considerations

Every SIEM is different, but at the core most have pricing related around usage or ingestion. To control your costs no matter the license, have a perfect understanding of the logs you need from your network to do a thorough investigation and plan to onboard those. Additional logs could be helpful, but depending on your budget could drive costs up. 

Ingestion refers to the volume of logs, typically in gigabytes, that you plan to ingest, as well as for how long you plan to retain. 

Usage is more generalized to the resources needed, think compute power. Most cloud SIEMs run in AWS, so the costs of CPU, Memory, Storage, and redundancy are passed onto you. 

Measuring Success!

At this point you should be well versed enough in the world of SIEM that you should be able to talk about logging, analysis, triage, alerting, and tell your smug senior security person why XDR is not a SIEM and the potential loss of visibility into your network if you make that change. Or to be fair, also tell your smug senior security person why SIEM is great, but you should supplement with XDR.

However, how do you really measure success? I’ll dive into those topics below and provide a checklist at the end that you can hand off to your team. 

Are you collecting all of your relevant logs? 

Depending on your budget you may be able to send everything generating logs directly into your SIEM, heck throw in the coffee machine! But as we noted in “SIEM Cost Considerations” above. Budgets are not infinite. If you’ve got room to spare, we’d highly recommend bringing in those logs you don’t think you need. Again, a large retail store several years back was hacked  . . . . through their HVAC system. Maybe having logged that event could have triggered an alert that your HVAC system was trying to gain access to your network!

So what should you collect? Well, have a serious conversation with your teams about areas of concern, what area of your business being hacked would put you in the news? Which areas is your team concerned they lack visibility into? Focus on these areas. 

Alternatively and more robustly, have your team diagram out how your network is connected all the way from the outside in, and then all the way back outside. Everything within that diagram should then be logged to your SIEM. If a hacker gains access remotely, they will move through your network, all the way in, and then all the way back out with your data. This is a great starting point! On top of that make sure to include any dedicated security products such as your EDR, XDR, and IDS tools. 

Example of how that may look:

Internet -> VPN -> Firewall -> File Server -> Domain Controller -> Firewall -> Internet

Are your logs in a standard format? (Splunk = CIM, Elastic = ECS)

Pointing data to your SIEM isn’t enough. Have your team check that the logs they brought in are all formatted correctly. 

Are you constantly building use cases (alerts)?

Use cases are not infinite. At some point you won’t have enough data or you’ll have covered all the attacks that are relevant to your network. You should have a process in place to regularly assess your network, its gaps, and how you can alert on any related malicious activity. 

There is no magic number, either you have good coverage or you don’t. A PenTest can help validate this. 

Are you refining the use cases regularly? 

On at least an annual basis. Check your use cases are still functional, looking at the right logs, especially if you’ve added new logs, and exclude any false positives that many have cropped up. 

Are your use cases following a framework? 

Use case development at first can succeed just knowing your gaps. But at some point you’ll exceed your team’s knowledge and foresight. At this point it’s best to adhere to a framework and build use cases based on best practices and gaps related to your environment. Personally, we love MITRE ATT&CK. 

Are PenTests Informing Your Use Case Development? 

The thing people hate to hear. You SHOULD fail your PenTest. If your PenTest company finds zero issues, you hired the wrong company. PenTests are meant to let you know your flaws before a hacker does it for you. PenTests are also incredibly valuable tools for protecting your network. 

First and foremost a detection is a detection not a fix. If you can remediate the issue they exploited, DO THAT NOW! Second, whether or not it can be remediated, take the exploits and create detections. You now know thanks to the PenTest how your network can be exploited. Look for the logs in your SIEM, if they’re missing, get those onboarded into your SIEM ASAP. Once the logs are ready, write some use cases to alert on similar future activity. 

If you can have your PenTest company retest, do that. You should receive an alert, and even if you were able to remediate the issue, you know a hacker may attempt to exploit it anyways. This is a good breadcrumb for triggering responses in your network. 

Also consider an automated PenTest platform. While this won’t replace your typical PenTest, it’s a great tool for validating your gaps and your use case functionality!

Do you have dashboards to speed up investigations? 

While this isn’t a topic I dove into above. With all of these logs in your network in one place, you can create visualizations to help show something is wrong in your environment. More importantly you can again decrease investigation times. You can have a single dashboard where you enter an IP address and it shows all relevant logs, trends, and other charts to point your team in the right direction. 

Is Management Receiving Automated Reports? 

Your SIEM can be used to generate scheduled reports or dashboards for management review or audit purposes. Look to reports for trends and other indicators that things are going well or possibly poorly. 

What is your logging retention? 

Determine how long you must keep logs based on any compliance requirements. Some such as HIPAA can require up to 6 years. If you don’t adhere to any compliance retention requirements. Determine what you feel comfortable with being able to look back on. At Hurricane Labs, we prefer at least 1 year. However, we’d recommend no less than 6 months if it’s within budget. 

SIEM Success Checklist

Do I Need an MSSP for my SIEM? 

Maybe? Not all MSSPs are built the same and may not be needed if you have an internal robust SOC. If you have a team of people to help manage the SIEM platform such as data onboarding, maintenance, and fixing should the platform go down. As well as staff constantly writing use cases and responding to alerts, then no. You don’t need an MSSP. 

But if you have a smaller team, or don’t have the expertise to manage the platform and write use cases, then yes, get an MSSP. 

A good MSSP will know your SIEM in and out. They’ll also make sure the use cases (alerts) end up in your SIEM. Some MSSPs blackbox their support of you, and while they may use your SIEM, they primarily use their own platform to do the alerting. That means if you leave that MSSP after three years, you have no alerts of your own. As a feather in our cap, Hurricane Labs writes and deploys the use cases in YOUR SIEM. If you leave us after 3 years, any and all work we’ve done you take with you. 

The other benefit of an MSSP is the use case development. The truth is, writing good use cases and keeping up to date on what use cases to even write, is a full time job. Between research, writing, and fine-tuning for your environment, this can take several hours per use case. An MSSP brings that expertise and usually a robust repo of use cases they know work, and just need to be tuned to fit you. 

I always recommend an MSSP that will build use cases specific to you, and let you keep them, especially when starting or improving your SIEM journey! An MSSP will help you adhere to best practices, build our robust use cases, and ensure your SIEM keeps on functioning. 

Lastly, some MSSPs provide their own SIEM for client use. This may be an in-house developed product, a resold product, or a combination of both! The benefit is the MSSP owns the product, is responsible for its upkeep as well as use case development, and doesn’t typically add any burden to your team. The obvious trade-off is if you leave the MSSP, you likely lose access to the product. 

What SIEM is the Best SIEM? 

Well that’s a loaded question. Budgets, toolsets, and budgets usually drive this decision. We’re biased here, as we love Splunk! Splunk wasn’t the first SIEM, but it sure did set high expectations and create a lot of standardizations that the rest of the industry eventually followed suit on. Some of the key factors too look for are:

1.  Cloud vs On-Premise
   1. Do you require the redundancy of a cloud environment?
   2. Do you require the security & control of a on-premise environment?
2. Do you plan to use this only for security? Would you like to monitor infrastructure up-times and other operational items?
   1. IF you want to monitor more than security, look for platforms supporting “Observability.” 
3. Do you want to own it or use an MSSP provided solution? 
4. Do you have any retention requirements? 90 Days, 6 months, 1 year?
5. How will you perform long term storage of logs? (Cold / Frozen Storage)
   1. Retain in the SIEM? 
   2. Offload to a cheap storage provider? (AWS, Microsoft, Google, etc). 
6. Consider the level of support you’d like.
   1. Tools like Splunk / Elastic provide not only vendor support, but vast community support (which is often better than any vendor support). 
   2. Consider an MSSP which typically respond faster than the vendor, as well as a good MSSP will be part of the product community as well. 
7. Run a proof of concept (proof of value)
   1. Ask the vendors to spin up a test instance.
      1. Send a few key log sources, especially loud ones, to understand more accurate sizing requirements. 
      2. Have the vendor or MSSP write 3-5 use cases so your team can understand capabilities and alerting processes. 
      3. Have your SOC, or the MSSP handle a few alerts so you can understand how the process comes full circle. 

You’re a Better Executive Already

Believe it or not, very few executives I talk to understand what a SIEM is. Being an executive myself, I understand every day is a busy day. But taking a moment to understand these tools will help you be more informed, which will reflect well with your team, as well as make sure you’re able to set your team up for success as well as hold them accountable.