Q&A Follow-Up: How Datev uses MITRE ATT&CK & Splunk in its SOC

Hey Everyone,

We recently did a webinar with Christian Heger, technical head of the DATEV SOC, as well as Sebastian Schmerl, head of cyber defense of Computacenter. They shared their 6-month path of modernizing their security operations with help of Splunk technology and the MITRE ATT&CK framework.

As we weren’t able to address all of the questions during the webinar, we discussed these afterwards and share them in this blog post as a Q&A follow-up.

Q: How does DATEV ensure that all Logs are complete and contain the full audit trail?

A: Three dimensions are crucial for this:

1) Is the SOC aware of all log sources within the organization?

If available, it is recommended to utilize a CMDB to get a rough overview of all available log sources. Based on the gathered data of the CMDB report, it is necessary to know if all IT departments possess lists and information of assets with active participants within the network. In order to identify active assets, the SOC Team used an interrogative approach. Since all active assets generate log data, we need to figure out if the logs are already stored within Splunk or if they’ve been sent to another logging broker/collector.

2 ) Can log messages disappear or be changed in your environment?

To ensure the integrity of log sources, end to end encrypted transport - from the log source to the destination - is necessary. Another important element is checking if any log source stops sending log events. Within Splunk all of this can be performed easily - for example through anomaly detection of a baseline profile per log source.

3 ) Have logging levels been configured correctly?

The SOC Team checks whether log levels are correct while creating SIEM Rules and Analytics. It executes test scripts on a regular basis to ensure continuous high quality of each piece of SIEM content. If the corresponding alert fails to be triggered, something has to be wrong within the chain.

Q: How did you convince the IT team to roll out Sysmon without official Microsoft support?

A: We tested Sysmon on a few individual systems first. After we got the thumbs up, we expanded to further systems. However, in case of any problems with Sysmon, it’s easy to remove it via a GPO.

Q: How many playbooks exist in your SOC and for which topics?

A: We have playbooks for the First Level SOC. They give clear instructions, making sure that in-depth analyst knowledge isn't needed. Additionally, Level 1 analysts create their own playbooks for incidents that happen frequently.

Q: Are your SOC Analysts responsible to work on alerts “exclusively” or do they also manage items like connecting new log sources, developing new use cases and maintaining the Splunk environment?

A: Our analysts should ideally know about the full lifecycle. Only if they are at least aware of the operational challenges and understand why SIEM Rules trigger, are they going to be able to analyse the associated alerts efficiently.

Q: Is the SOC Team considered as the “employee monitoring unit” and how do you handle this?

A: The SOC Team showcases all of the activities that are happening in the SOC to ensure transparency. We call this “open door policy of the SOC”. We welcome employees in our SOC Traveller Program so they can become a Guest-Analyst. All personal matters are dealt with responsibly and in close collaboration with the workers’ council and HR which creates high acceptance. The SOC team is a trustworthy point of contact for all employees and departments. It explains security risks, gives advice on improvements and tracks their implementation - without ever blaming anyone.

You can find the English video of the Datev session at .conf here.

Hopefully these answers help you to modernize your own security operations program, to reduce security risks in your organization and operate a continuous improvement cycle.

Best,

Matthias