Proposal: Extend Security Control Profile for Authentication Class in OCSF

[pladamgregory]

Proposal: Extend Security Control Profile for Authentication Class in OCSF

Summary

This proposal aims to extend the OCSF (Open Cybersecurity Schema Framework) security control profile to support the authentication class. Specifically, it introduces an access_control object within the auth_factors structure, which includes various attributes related to access restrictions, policy rule matching, identity stores, and authentication results.

Motivation

Currently, the OCSF schema lacks detailed coverage of authentication-related attributes within the security control profile, limiting its use in monitoring, auditing, and managing authentication flows and policy application in a granular way. This extension will enable better tracking of authentication attempts, associated policies, and the effectiveness of access restrictions, enhancing overall security visibility.

Proposal Details

New Structure

Within the authentication class, we will add an access_control object under auth_factors, which will contain the following attributes:

• access_restricted (boolean): Indicates if access is restricted based on policy.
• matched_group_policy_rule_name (string): The name of the matched group policy rule.
• matched_auth_policy_rule_name (string): The name of the matched authentication policy rule.
• matched_identity_policy_rule_name (string): The name of the matched identity policy rule.
• matched_service_policy_rule_name (string): The name of the matched service policy rule.
• auth_identity_store (string): The identity store used for authentication.
• query_identity_store (string): The identity store queried for authentication.
• auth_status (string): Status of the authentication (e.g., authenticated, failed).
• auth_method (string): Method used for authentication (e.g., password, biometric).
• auth_method_type (string): Type of authentication method (e.g., single-factor, multi-factor).
• auth_result (string): Result of the authentication attempt (e.g., success, failure).
• auth_type (string): Type of authentication (e.g., user_authentication, service_authentication).

Example JSON

An example JSON structure illustrating the new auth_factors object with access_control:

{
  "class": "authentication",
  "auth_factors": [
    {
      "factor_type": "RADIUS",
      "factor_result": "success",
      "access_control": {
        "access_restricted": true,
        "matched_group_policy_rule_name": "VPNAccessPolicy",
        "matched_auth_policy_rule_name": "RADIUSAuthPolicy",
        "matched_identity_policy_rule_name": "NetworkUserPolicy",
        "matched_service_policy_rule_name": "VPNServicePolicy",
        "auth_identity_store": "Cisco ISE",
        "query_identity_store": "LDAP",
        "auth_status": "authenticated",
        "auth_method": "radius",
        "auth_method_type": "single_factor",
        "auth_result": "success",
        "auth_type": "network_authentication"
      }
    },
    {
      "factor_type": "otp",
      "factor_result": "success",
      "access_control": {
        "access_restricted": true,
        "matched_group_policy_rule_name": "VPNAccessPolicy",
        "matched_auth_policy_rule_name": "RADIUSAuthPolicy",
        "matched_identity_policy_rule_name": "NetworkUserPolicy",
        "matched_service_policy_rule_name": "VPNServicePolicy",
        "auth_identity_store": "RSA SecurID",
        "query_identity_store": "LDAP",
        "auth_status": "authenticated",
        "auth_method": "otp",
        "auth_method_type": "multi_factor",
        "auth_result": "success",
        "auth_type": "network_authentication"
      }
    }
  ]
}

[floydtree]

It appears there's a lot of scope to create duplication and conflict with the existing attributes in the Authentication event class. I would recommend, taking a deeper at the existing class and all it's attributes and only add missing pieces. The core reasoning it to be more prescriptive for the users of OCSF.

Quick observations:

1. Is radius appropriate as an auth_factor type? It's better suited for auth type, check out auth_protocol
2. Why is access_control being nested inside auth_factors? Don't see a clear value of this nesting.
3. Within the proposed access_control it appears you are duplicating attributes that are already a part of the class elsewhere in the structure. auth_result -> status, auth_method -> auth_protocol, auth_type -> logon_type
4. Look at utilizing and augmenting existing entities before creating a new ones, can the policy object be used with augementations to represent all the policy attributes that you have?

[pagbabian-splunk]

I also noticed some redundancies / duplications. However if I understand the intent here as being part of the security_control profile: that an external (or an implicit) control can limit access in a more specific way than the current ALLOWED or DENIED options. The authorization_result array can hold a decision string and a policy object. You would like details per factor_type_id type.

[mlmitch]

I realize this doesn't solve your entire issue, but the security_control profile is now applicable to all OCSF event classes as of OCSF 1.4.

https://github.com/ocsf/ocsf-schema/pull/1281