Log sources for process creation (4688) events from endpoints

Copper Contributor



I noticed that lots of the use cases in Sentinel are driven by process creation events - 4688 in the Security event log; suspicious Powershell command lines, for example.


Is Microsoft's idea that the Sentinel agent would be deployed to all endpoints in order to capture these? Or can it leverage Defender ATP for these events (not just ATP's alerts). Or is the expectation that a customer might use Defender ATP for endpoint coverage, but ingest Security event logs from Windows Servers into the SIEM only?

2 Replies



Not a solution, but just sharing my thoughts...

Capturing all the process creation events from ALL endpoints would be prohibitive from a cost perspective. For this reason, I'm only considering deploying the agent on endpoints with suspicious behavior though this is not an optimal approach. Relying on Defender ATP is not an option as many of our customers have significant investments in endpoint protection and replacing them with Defender ATP would be a long sales and engineering effort. As it is, we need to balance costs of ingesting this data vs. the increase in security posture.



Adrian Grigorof

Managed Sentinel Inc.


@ford8k   It seems like Microsoft doesn't care where the data comes from as long as it is stored in the Log Analytics with Sentinel can process it.  This can be shown by having all the various connectors that attach to various systems, both Microsoft and not.  I am sure Microsoft would love for you to deploy Defender ATP on all the machines and have all that data coming into Sentinel but is it realistic?  Granted Defender handles a lot of the security for you but at the very least, the Agent can have log files sent to Sentinel.


There are 2 schools of thought here: 1) Monitor only what you think will cause problems and 2) Monitor everything.  While option 1 will reduce your cost, how do you know you are not missing something?  Option 2 gives you a better view of your environment but at a higher cost.


Personally, I lean towards option 2 as much as possible since it is better to have the data and not need it rather than need the data and not have it.