Update the security_control profile to include access control check semantics, and firewall profile semantics.

[pagbabian-splunk]

Related Issue:

Firewall profile can be removed from 1.1-dev in lieu of this updated profile.
Authorization Information should be deprecated from the Actor object in lieu of this updated profile.
The Web Resource Access Activity class can be deprecated and this profile should be registered with Web Resource Activity to include the access control semantics.

Description of changes:

Per weekly call 11/14/2023 Updated the dictionary descriptions of disposition_id, firewall_rule, attacks, malware to include usage with security_control as well as finding.

Updated security_control profile to combine the disposition list with the firewall profile list, and for use with access control checks. Added the firewall_rule attribute. Added the Authorization Information attribute.

[zschmerber]

The change looks like a good start, firewall rules live under an optional firewall_rule object inside the profile. Then we can have an object for each of different tools in that profile: firewall_rule, DLP_rule, IDS/IPS_rule, Proxy_rule, compliance_rule etc. Do we want to add the objects now or wait until we need them ?

[zschmerber]

As we make this change do we want to remove/deprecate the Authorization Result object ?

[pagbabian-splunk]

Yes, we will deprecate Authorization Result from Actor and point to this profile.
As for adding other control specific policies, I had done that in my previous PR that I pulled (sec_ctrl) but I think it is better to add them when we have those objects fleshed out and have use cases behind them. There is a Policy object already, also within Authorization Result and Account Change but not sure if it covers the other areas sufficiently. If we were added at the profile level, it would show up in two places due to Authorization Result.

[zschmerber]

After composing up this schema server I see that the security_control profile only apply across 2 categories. Network Activity and System Activity. Do we want to expand that to include more classes and categories?

[pagbabian-splunk]

After composing up this schema server I see that the security_control profile only apply across 2 categories. Network Activity and System Activity. Do we want to expand that to include more classes and categories?

Yes, we need to do that, for example for the Web Resource Activity in Application Activity, in order to be able to deprecate Web Resource Access Activity. There are a number of other changes after this PR is merged - I just wanted to keep things more focused.

[zschmerber]

We need to solve for a question like this:
boss: "hi, security analyst. Tell me how the attacker got into our network and make it snappy."
analyst: "ok boss."

index=* ip = 1.1.1.1 OR actor.user=zzzz OR hostname = xxxx disposition_action = success

If we have to write: index=* ip = 1.1.1.1 OR actor.user=zzzz OR hostname = xxxx disposition= (Logged OR Allowed OR Tagged OR .....) to answer this question it is not efficient.

A new field in the profile like disposition_action where the result is allowed or blocked would allow us to fit all of those dispostion_id's into a simple binary result.

The other option is to slim down the dispostion_id into 3-6 fields(allowed, blocked, other...) . Place the dispotion_id attributes into the connected object in the profile like "firewall_rule" and get the disposition action detail from that object.

One additional idea was to use status_id but this will not capture the perspective we are looking for as the statues of an operation being run is not the same as a security control blocking or allowing something.

[floydtree]

I like @zschmerber's idea about a disposition_action. A distilled, binary valued field added as an optional attribute in via the security control profile.

I am open to other name suggestions, but Zach and I arrived at disposition_action for it.

We can get it in as a separate PR, unless @pagbabian-splunk you are okay to add that in as a part of this PR.

[zschmerber]

Changes look good to just need @pagbabian-splunk to incorporate @pladam descriptions. we can add the "disposition_action" field later.

[pagbabian-splunk]

Added the action_id and action attributes - should equate to the disposition_action mentioned above. If action is to generic, I would suggest control_action since the disposition isn't the thing that acted, but rather was the result of the action.

Updated the disposition_id descriptions as suggested above, but adjusted the tense to be past tense, and in some cases added activity as well as request in the description.

[zschmerber]

Updated definitions look good and I think Action works well, as it is common in other schemas like CIM and UDM. I think Action will be used so often that people will quickly become accustomed to its meaning and will already be used to its meaning from other schemas.

[mikeradka]

Looks great.

[floydtree]

Looks great, the only thing that appears to be pending is the comment on the Allowed dispostion_id's description.

Made the changes he suggested.

[adplotzk]

addition of firewall_rule in this context is in line with our previous outline, approved.