The Operating Model

This blog explores how an operating model can help you derive value from premium products. If you don’t have a solid operating model, you won’t get value from your premium product investment. We touch on four different points, including specific mention of Enterprise Security to emphasise the importance of this model in general.

Making sure the roles/responsibilities between the SOC and engineering are clear

An operating model can be crucial for gaining maximum value from any premium product – really, from any platform or tool. This is particularly true in the case of Splunk’s premium products. But before diving into how operating models can help maximise value from Splunk’s premium offerings, we’d like to start with a slightly less technical analogy, just to illustrate how this isn’t a SIEM-specific issue, it can be present in any environment.

So, think of Splunk like a modern airport. Picture this airport with state-of-the-art facilities and expertly trained staff ready to operate them but the issue is, no one’s quite sure what they’re responsible for. Everyone knows their job and is well trained in it, but within their domain, they’re not sure what they’re accountable for.

Imagine you’ve got the best engineers in the world: highly skilled and experienced but they don’t know which aircraft they’re supposed to be repairing or when. They also don’t know who to contact to order spare parts. This airport might have top-notch security scanners, X-ray machines and sniffer dogs but no one knows who’s supposed to be manning which station, how the shift rotation works, or the escalation procedures when something is discovered.

While this may seem far-fetched (and in reality, airports are far more locked down), it serves to demonstrate how a tool or product alone (even when perfectly configured and supported by well-trained staff) can’t provide value or protection unless it’s supported by a robust, well-documented operating model.

For example, engineers not knowing how to obtain spare parts is similar to Splunk admins needing to onboard new data feeds. Or customs officers not knowing how to escalate an incident is like a Tier 1 SOC analyst not knowing the proper response process for security detections.

How could an operating model help prevent this?

An operating model helps define who has ownership over different domains within Splunk. This can highlight responsibilities for maintenance, monitoring, incident response, triage and escalation. It can also document exactly what actions should be taken and within what timeframes.

For example, it might specify how maintenance is carried out or detail how analysts should respond to specific alerts. This clarity removes ambiguity between teams and prevents the common pitfall where everyone assumes someone else is handling it, which leads to neglect and eventually loss of value from the product.

We often see Splunk premium products initially set up well but later neglected because there was no operating model in place. Over time, the features go unused and the product falls into disuse all while the licence continues to be paid for.

Splunk ITSI and Enterprise Security both offer far more tools than any one person could fully utilise. Without a clear operating model, users often default to the first tool they find and never explore the rest. Defining operating models at the beginning of a product’s lifecycle allows you to assign specific teams (or individuals) to different tools, making it easier to plan for training and ensure the team is confident in using the necessary features.

Data quality to take advantage of ES features

Another key area where an operating model adds value is in platform maintenance. As with any Splunk product, the insights provided by Enterprise Security are only as good as the data being ingested. Maintaining high data quality is essential for maximising value, insight and security.

Multiple data sources are often managed by different individuals or teams which can lead to confusion. For instance, “Who do I speak to about updating asset logs?” or “We’ve got a new Azure data feed… how do we get it into Splunk?”

An operating model can help by documenting the full process; who to contact, how to contact them (via a ticket, email or change board) and what to do. This streamlines platform maintenance and eliminates confusion around how to keep data accurate and reliable.

ES-specific features

Now let’s focus more specifically on Enterprise Security (ES), Splunk’s premium security product for analysing events and cybersecurity threats. There are four key tools within ES that benefit greatly from an operating model:

• Asset Register

ES allows you to set up asset registers to enrich incoming data. For example, it could map an IP address to a colleague’s name, office location, time zone and so on. This enriched data can help identify anomalies – e.g., ‘Sarah Bloggs’ logging into a device that’s assigned to ‘John Doe’.

However, this asset data needs to be maintained. If ‘John Doe’ leaves the company and his laptop is reassigned, the register must be updated ideally as part of a leavers/joiners process. Your operating model might include a weekly review involving HR and the Splunk team to ensure accuracy. You could also automate updates using tools like Device42.

• Incident Review

Incident Review lets you create a dashboard of all the activity in your environment: tracking incidents, investigations and analyst comments. It’s often underused. Many treat ES as a second search head, pumping data in, running alerts and sending notifications, without tapping into the full power of this tool.

Incident Review provides a one-stop view of daily events, how they map to frameworks and the status of investigations. It can reveal trends (e.g., recurring incidents at the same time daily) and offer deeper insights; maximising both investigation effectiveness and product value.

• Risk-Based Alerting (RBA)

RBA is a powerful tool for reducing analyst fatigue. For example, if a user enters an incorrect password, RBA can assess the risk based on whether that user is an administrator or has elevated privileges.

RBA helps prioritise threats, but it relies heavily on up-to-date data about users and their roles. If this isn’t maintained alerts may become noisy or inaccurate, leading analysts to switch off the feature altogether, once again losing the product’s added value.

• Alert Actions

While standard Splunk has alert actions (e.g., sending a Slack message or calling a webhook), ES builds on this with more advanced options like raising notable events for further analysis.

If paired with tools like Splunk SOAR, you can automate entire response workflows. For instance, when a specific alert is triggered, SOAR can automatically lock a user’s account. This improves response times and reduces analyst workload.

Yet, without an operating model, these features often go unused. ES might be set up and left to run, with maintenance becoming someone else’s problem. Then, when a one-off incident occurs, no one knows how to respond – leading to delays that adversaries could exploit.

Conclusion

All of these points show how an operating model not only enhances your security posture but also increases the value you get from Enterprise Security. In future blogs, we’ll dive deeper into individual components of ES and how you can use them to improve your results.

If you’re questioning whether ES is the right investment or feel like you’re not getting value from it, take a look through our blogs, it might just help you transform how your team uses the product and help you unlock its full potential.