Adding Device Config State Change event class

[maxhotta]

Used to report security state changes for managed entities.
This class was ported from the entity change event class that was part of the security category in the ICD schema.

[pagbabian-splunk]

A few questions: We have an Entity Management class in the IAM category, and this will be an Entity Change class but in the Application category. It has activities more akin to the Discovery category (i.e. Logged), rather than any actual update activities (so I guess, just logging the change?).

That's ok, as long as it is explainable - e.g. Discovery classes are proactive (e.g. scans for changes, vulns etc.) while other categories are what would be asynchronously received events for the most part.

This class logs security related changes to a Managed Entity - why is it in the Application category? What is the application, or is it an application layer service (e.g. Web, Email, Systems Management)? Could it live in the IAM category where the Entity Management class resides?

Three possible category choices: IAM, Discovery (only if proactive), and Application.

[maxhotta]

@pagbabian-splunk It's been a little while since we'd discussed this last, but the purpose for this class is to capture security related opstates like changes in the compliance or infected status of applications on devices. It was originally in the Security category of the ICD schema, but in the absence of that category, we'd thought that the application category made the most sense.

[maxhotta]

@pagbabian-splunk Is the consensus that we move this class into the Discovery category?

[pagbabian-splunk]

Yes that was my opinion and with the name change it is close to Device Config State already in Discovery. The question is do we have/need Device? From your Slack, you said Device and OS were the ones you saw in practice, and Device has OS too. I'm wondering whether we can exploit more symmetry from the Device Config State and Device Inventory Info, to now also include state change for Device. I understand that `entity` is more general and wouldn't need to be filled in the same way Device would be but if you do want to identify the actual device and OS that changed, I would think that identification is going to be important. With your `_Info` classes you were very specific class by class for the type of resource which we defended to not be a generic `Resource`. But here, you went with a generic `Managed Entity`. Paul (from my mobile device)

…

On Fri, Jan 12, 2024 at 12:18 PM maxhotta ***@***.***> wrote: [ External sender. Exercise caution. ] @pagbabian-splunk <https://github.com/pagbabian-splunk> Is the consensus that we move this class into the Discovery category? — Reply to this email directly, view it on GitHub <#914 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS5LBZVAVWRGYFOOL7TMO4DYOGLABAVCNFSM6AAAAABBNRZH4SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZHA4TQMBSGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pagbabian-splunk]

We have a risk_level and risk_level_id, and a log_level. Can we not say current_security_level and just say security_level? It would imply current. Then we only need to call out prev_security_level to distinguish it. We have this convention for Registry: reg_key and prev_reg_key, reg_value and prev_reg_value.

[pagbabian-splunk]

Very minor: our convention so far is to use prev_ not previous_ as with the Registry Key and Registry Value attributes. It's also shorter but still quite clear.

[floydtree]

Thanks Max!

[jasonbreimer]

No issues.