Why do defenders usually start from a community Sysmon configuration such as SwiftOnSecurity's or sysmon-modular instead of writing one from scratch?

Because a good configuration is mostly about noise: thousands of well-tested include and exclude rules that keep attack-relevant events and drop routine ones, which takes years of experience to build.

With no filtering, Sysmon produces a flood of events on every machine: every DLL load, every process opening another. Analysts drown, storage fills, and the SIEM licence (often priced per GB per day) runs out. Too aggressive filtering has the opposite failure: the event that mattered was excluded.

• SwiftOnSecurity/sysmon-config is a single, heavily commented baseline, a good default for most organisations.
• olafhartong/sysmon-modular splits the rules into modules per event type and ATT&CK technique, so you assemble and tune the configuration you need.

Both are maintained against new Sysmon versions and new attack techniques. The usual approach is: adopt one, deploy, then tune exclusions for software specific to your estate. Perfecting a configuration requires a broad knowledge of how the organisation works; the less noise, the more time analysts spend hunting threats.

Go deeper:

• SwiftOnSecurity/sysmon-config — the widely used baseline configuration, commented rule by rule.
• olafhartong/sysmon-modular — modular rules mapped to MITRE ATT&CK.