Add a config system for Panther detections

[jof]

This adds a fork-friendly way to define some configuration values for detections inside of this repository to consume.

Additionally, this implements this configuration scheme for all existing uses of example.com as a way to demonstrate how to consume the API and use it with some tests and Mocks.

In the current state:

• Organizational users of Panther are directed to make private forks of this repo
• Plugin code makes use of hard-coded configuration values directly inside the python source

This is leading to:

• Organizational users modifying the detection python sources to set configuration values that make sense for them
• Upstream changes landing into python sources
• Merging of upstream branches into the forks are causing merge conflicts

The hope of the configuration system proposed in here is that the public fork (panther-labs/panther-analysis) of this repo contains a bunch of reasonable default values inside of global_helpers/panther_config_defaults.py and a mostly empty global_helpers/panther_config_overrides.py.

Then, at lookup-time, users can import and reference panther_config.config; accesses to attributes of this object will first look for values in panther_config_overrides.py and fall back to the defaults in panther_config_defaults.py.
Importantly, for testing, these configuration values should probably get imported into the top-most scope of each rule, such that they can be easily overridden with Mocks: content for the test cases.

[grantjoy]

Awesome PR, thanks for opening it. Should add this file .gitattributes with ours ownership so it always overrides the upstream?

[jof]

Yeah, I think that probably makes sense. From my user-perspective, we only ever merge upstream into our fork (or rebase). So long as we're never merging in the other direction (fork->upstream), this seems like the right choice.

Will add.

[arielkr256]

@jof I like the idea of centralizing config values, but want to make sure the changes don't break things in other environments. The 3 new global helper functions need to be added to the pack files for the log types where rules have been updated so that environments using packs get the new helper functions.

[jof]

@arielkr256 Good call on the Packs -- I updated the affected ones with the new modules

[arielkr256]

We were able to confirm these changes will not overwrite configs for customers using packs, good to go!