Splunk Enterprise (on-premises) can be setup in a vast number of ways. An important part of hardening a Splunk Enterprise installation is to carefully plan the underlying network infrastructure and to do proper segregation. This post contains an idea on how this can be achieved, and then further explores the possibilities.
What I propose here by no means the only way to build a Splunk Enterprise infrastructure – the proper way is always context dependent. This will however give you an idea on how to approach the issue. Once the network is planned, we can create trust boundaries and using those, we can refine a threat model. Let’s get to work.
Ideas for threat modelling Splunk Enterprise
A threat model is a way to identify who threatens a system, and how. Using a threat model we can quickly assess where our weak spots are, and where to put our resources of defense. A final threat model is of course always very context-specific. Some systems may only have a few users, all of them trusted – and all of the components in one large subnet. Others may be very strictly segregated. Some may have forwarders and server outsourced and no visibility therein. This is the context that matters, as always.
As part of a threat model, it is important to identify trust boundaries. These are the logical lines between the different parts of the system, each part having its own rules related to access, access management, security controls – and for the purpose of this exercise – patching. The trust boundaries and ideas presented here can be used as a starting point. We have added prime threat actors as a starting point as well.
If you require a specific threat model of your Splunk Enterprise setup, please contact us and we will assist you. Until that, feel free to use this model as a baseline. In this model we are assuming a certain level of hardening taking place - we are assuming that user interfaces ("splunkweb") is disabled where not needed, servers are being protected by host firewalls to some extent, hardware firewalls actually implementing physical segregation and user management being in place. Of course, not all of this may be true for any specific deployment.
Using the threat model - a threat based patching strategy
From a threat modelling point of view, understanding the trust boundaries will give us insight into which vulnerabilities and Splunk security advisories (https://advisory.splunk.com) have an effect on separate parts of the Splunk Enterprise ecosystem. With a clear understanding of the aforementioned we can more easily understand, which advisories and patches to prioritize.
Final words – what you see here is not complete nor perfect. Caveat emptor.
Trust boundaries
“Trust boundaries represent conceptual divisions within information systems where security levels change, signifying a transition from one trust level to another. They delineate environments with differing trust assumptions, requiring authentication and authorization for crossing. These boundaries are crucial in defining how data and requests are validated, ensuring secure interactions between distinct security zones. Implementing trust boundaries effectively mitigates risks by isolating and protecting sensitive data and functions within a system.”
This is an incomplete but sufficient definition of the trust boundaries which could be identified within a Splunk Enterprise installation and ecosystem. Based on this, a threat based patching strategy can be drafted.
N1. Indexer zone
Herein lies all the most important data. Interactive access to this zone is limited to administrators only. All forwarders are talking to the indexers.
- Prime threat actors: disgruntled administrators, skilled hackers
N2. Trusted Forwarder zone
This is where the servers and therefore also forwarders and heavy forwarders are located. The assumption is that this zone is under your control directly or indirectly, meaning you at least trust the administrators who are in charge of this zone.
- Prime threat actors: server administrators, skilled hackers, application administrators, forwarder developers
N3. Untrusted Forwarder zone
This is where the servers and therefore also forwarders and heavy forwarders are located. The assumption is that this zone is utsourced or beynd your control, meaning you have no knowledge of the administrators trust level. You should assume a level of rogueness or at least indifference on their behalf.
- Prime threat actors: all administrators, skilled hackers, forwarder developers
N4. Trusted SH zone
This is where your internal search heads are. The search heads are accessed by users you know. This necessarily does not mean the users are trusted, but at least they are part of your user scope and policies and the identities are internally managed.
- Prime threat actors: hackers, disgruntled employees, nosy employees, administrators, app developers
N5. Untrusted SH zone
This is where your external search heads are. The search heads are accessed by users you may or may not know. You should assume these users are more indifferent to the data the system than internal users.
- Prime threat actors: hackers, indifferent third party users, administrators, app developers
N6. Splunk utility zone
This is a common placeholder zone for “miscellaneous Splunk components”. These components usually have the characteristic of having to communicate with the rest of the Splunk ecosystem at large. Meaning, there are a lot of firewall openings. Deployment servers as well as license master and cluster manager have a user interface usually accessed by Splunk admins.
- Prime threat actors: disgruntled administrators, skilled hackers
N7. Common Workstations
This is where the trusted or internal end-users are located. Access from here is limited, but we should assume users may have vast privileges on the search heads. The level of trust should always be defined and thought thru.
- Prime threat actors: disgruntled employees, phishers and malware
N8. External network
This is where the untrusted end-users are located. Access from here is limited, but we should assume users may have vast privileges on the search heads. Also we should assume indifference, highly divergent endpoint protection and workstations being used in all sorts of locations.
- Prime threat actors: indifferent employees, phishers and malware, all hackers
