Data Source Mapping Methodology

[matt00davis]

Hi

Really keen to use the DeTTECT tool and looking at previous DeTTECT tool releases and Mitre Data Source mappings, I'd be keen to understand employed methodologies in use. For example, in 2020 according to some tool usage videos one 'data source' could be defined simply as 'Windows Event Logs'. This would then map to potentially detectable TTP's such as control panel items, modify registry, new service etc etc.

As Mitre have updated the Data Sources and taking Windows Event Logs as an example which is no longer a defined data source, how so you go about this mapping.?

So customer X ingests Windows Event logs. How then would you map Windows Event Log sources to the defined Data Sources i.e. whether this log source would fit under Command Execution, Process Creation, File Modification etc.

Hope that makes sense. Is it a matter of essentially breaking down log source capabilities and GPO's into how they transpose across to the Mitre and DeTTECT defined data sources?

[rubinatorz]

hi @matt00davis

MITRE's goal of redefining the data sources is to have more specific data sources that are platform agnostic. The old "Windows Event Logs" is a very broad data source specific for Windows, anything can be in that data source (processes, errors, connections, powershell, wmi, etc). So the idea of MITRE was to make more specific data sources, like Process, Module, Script, Command, etc. And those can be collected on different platforms like Windows, Linux, macOS, etc. The Process data source with data component Process Creation is collected on Windows in the Windows Event Logs (with event ID 4688) and on Linux you can for example use auditd. So you should now focus on the "what" and not the "where". And within DeTT&CT you can administrate for each data source where it's located (Products attribute).

I hope this makes sense to you.

Regards,
Ruben

[matt00davis]

Hi Ruben

Makes perfect sense, thank you and much appreciated

Regards

Matt