Cyb3rPandaH
commented
2 years ago Hey @b1t-hunter , I hope you are doing well 😃
We are happy to hear you are using the project in your environment. Also, thank you for taking the time to submit this issue.
Regarding renaming of fields (provider --> log_source): we decided to use a more general term when identifying the source of telemetry collected. This is helping us to continue documenting the project with telemetry from different platforms in a more standard way. So the equivalent to provider would be log_source now.
Regarding the log_channel field: we decided to remove the field to align the schemas of OSSEM Data Dictionaries (DD) and Detection Modeling (DM). The log_channel field was Windows focused and we did not consider it as part of the key (log_source / id / version / platform) to identify a data dictionary uniquely within DD. However, the use case that you describe here is very interesting. We are already using optional / conditional fields within DM such as audit_category and audit_sub_category that are related to the Windows platform, but let me get some feedback from the team first.
Then we can make a final decision about adding the "channel" field to the yaml schema.
Thank you again 🍻
b1t-hunter
Dear OSSEM-DM Team,
thanks for your great work! I have worked with your detection model relationships to extract Windows events that would be required for comprehensive monitoring in a Windows domain. In a past version of your generated relationships (__all_ossemrelationships.yml), you always specified the channel (
log_channel), provider (log_source) andevent_idfor each referenced Windows-based security event. This allowed to generate corresponding log policies and Windows event subscriptions to retrieve those events.In a newer version of your specification, those fields have a changed semantics (
log_source) or have been removed (log_channel). This makes the automated derivation of required events much more difficult or even impossible. Is it planned that this information is reintroduced, maybe under a different key name? If not, do you see any other way to retrieve the channel and provider from the relationship data, maybe with some mapping table?While the simple cases of
Microsoft-Windows-Security-Auditingandsysmoncould be mapped to the channel/provider-pairsSecurity:Microsoft-Windows-Security-AuditingandMicrosoft-Windows-Sysmon/Operational:Microsoft-Windows-Sysmon, this becomes much more difficult for event providers that log into multiple channels, such asMicrosoft-Windows-Eventlog. So in order to derive the corresponding WEF subscription or generally event filter, I would have to know which event_id belongs to which channel/provider pair. On the other hand, there are some log sources that go into two different providers (and channels), like Powershell. Powershell seems to be covered now by the twolog_sourcespowershellandMicrosoft-Windows-PowerShell.powershellseems to be used for the two providersPowerShell(channel:Windows PowerShell) andMicrosoft-Windows-PowerShell(channel:Microsoft-Windows-PowerShell/Operational). Hence, it cannot be determined automatically (or manually without additional knowledge of existing events) whether events should be collected from eitherWindows PowerShellorMicrosoft-Windows-PowerShell/Operationalchannel.