ocsf-schema
ocsf-schema copied to clipboard
Identity Analysis Finding - A new event class.
Adding a new event class in the Findings category, to help represent outcomes of analysis performed on IAM Identities. Key use-cases include, representation of unused privileges, credentials, external entity access. We can expand this class as we come across more use-cases. Refer to AWS IAM Access Analyzer, if you are interested in learning more.
Note: The class is designed to be generic enough in structure to allow for more objects, attributes to be added in the future to help represent different ITDR products.
Description of changes:
- Adding a new event class - 2007 - Identity Analysis finding
- Adding
external_access_analysis,identity_activity_metrics,permission_analysis,additional_restrictionobjects - Adding
traitstofinding_infoobject. - Adding
typetopolicyobject.
Sample finding
Represents a finding that outputs analysis of an IAM Policy associated with an IAM Role, highlighting presence of unused privileges
{
"activity_id": 2,
"activity_name": "Update",
"category_name": "Findings",
"category_uid": 2,
"class_name": "Identity Analysis Finding",
"class_uid": 2007,
"cloud": {
"account": {
"uid": "111111111111"
},
"provider": "AWS",
"region": "us-east-2"
},
"finding_info": {
"created_time_dt": "2024-10-08T17:27:39.665Z",
"desc": "The IAM role 'Admin' (arn:aws:iam::111111111111:role/Admin) has unused action permissions across AWS services that should be reviewed and removed to follow least privilege principles",
"src_url": "https://console.aws.amazon.com/access-analyzer/home?region=us-east-2#/unused-access-findings?resource=arn%3Aaws%3Aiam%3A%3A111111111111%3Arole%2FAdmin",
"title": "AwsIamRole/arn:aws:iam::111111111111:role/Admin/ has unused permissions",
"types": [
"Software and Configuration Checks/AWS Security Best Practices/Unused Permission"
],
"uid": "arn:aws:access-analyzer:us-east-2:111111111111:analyzer/UnusedAccess-ConsoleAnalyzer-example/arn:aws:iam::111111111111:role/Admin/UnusedPermission"
},
"metadata": {
"processed_time_dt": "2025-01-05T20:24:23.201Z",
"product": {
"name": "IAM Access Analyzer",
"uid": "arn:aws:securityhub:us-east-2::product/aws/access-analyzer",
"vendor_name": "AWS"
},
"profiles": [
"cloud",
"datetime"
],
"version": "1.5.0-dev"
},
"permission_analyses": [
{
"granted_privileges": [
"s3:GetObject",
"s3:PutObject",
"ec2:RunInstances",
"Example Actions"
],
"policy": {
"name": "Example IAM Policy"
},
"unused_privileges_count": 2,
"unused_services_count": 1
}
],
"remediation": {
"desc": "If the unused permissions aren't required, delete the permissions to refine access to your account. Use the IAM console to modify or remove the policy that grants the unused permissions. If all the unused permissions are removed, the status of the finding changes to Resolved."
},
"user": {
"account": {
"uid": "111111111111"
}
"uid": "arn:aws:iam::111111111111:role/Admin",
"name": "Admin",
"type": "AWS IAM Role"
},
"severity": "Low",
"severity_id": 2,
"status": "New",
"status_id": 1,
"time": 1733525097887,
"time_dt": "2025-01-05T20:23:57.887Z",
"type_name": "Identity Analysis Finding: Update",
"type_uid": 200702
}
The class ID (7) will conflict with the ASPM Finding which is also 7. One of them needs to be changed to 8.
I am concerned that some of the details in this event class currently are very specific to AWS, while the overall event is positioned generically ("Identity Analysis Finding"). For example, terminology like unused_actions_count and unused_services_count assume that identity policies are based around actions and services, which may be true for AWS IAM, but may not be true for other contexts. How would Okta policies that deal with access to apps be represented, for example?
There are several products (or capabilities of products) in the identity space that also report findings that include over-privileged identities, as in your example. Here are a few, I tried to pull up documentation where I could find it publicly available:
- Sailpoint
- Oort/Cisco Identity Intelligence (Cisco)
- Zilla (CyberArk)
- Spera (Okta) (there's a screenshot on the home page of "Unused privileged access")
- Silverfort
Are these types of findings intended to also map to this class? I would love to see how a finding for at least one other provider would map to this event class before we committed to the structure of this event.
@alanisaac Fair commentary. It is very much designed to support a use-case, while attempting to be generic to support varied use-cases down the road. We can augment the objects and class as we need, to better represent more use-cases. I fully expect folks more familiar with other products to propose augmentations to this class. I like to start lean, and add as necessary. The primary question I have is, do you see the current structure preventing us from augmenting this class for other use-cases?
Thanks @alanisaac for helping with a sample from Cisco Identity Intel.
This is how it can be normalized using this class (I have since added the new applications object to this class, and renamed policy_analyses to permission_analyses to allow representation of non policy based permission structures.)
original -
{
"version": "0",
"id": "3a9f6ca8-08af-43f0-827a-example",
"detail-type": "FAILED_CHECK",
"source": "908040f3-da74-4a58-8029-example",
"account": "227542035969",
"time": "2025-04-10T06:26:40Z",
"region": "us-east-2",
"resources": [],
"detail": {
"id": "8ca60986-39ae-4b43-b512-example",
"checkId": "unused-user-apps",
"title": "Unused Application for a User",
"severity": "low",
"login": "[email protected]",
"checkTags": [],
"checkTopics": [
"compliance",
"identity_posture_insight"
],
"frameworks": [
"nist_csf_pr_ac_4"
],
"explainabilityDetails": [
{
"value": "devops engineer",
"key": "userTitle"
},
{
"value": "FAVORABLE",
"key": "userTrustLevel"
},
{
"value": "{\"applications\":[{\"name\":\"workday\"},{\"name\":\"five9 plus adapter for salesforce\"},{\"name\":\"workday sandbox\"}]}",
"key": "context"
}
],
"userTrustLevel": "FAVORABLE",
"published": "2025-04-10T06:26:40.577Z"
}
}
Normalized to OCSF
{
"activity_id": 1,
"category_uid": 2,
"class_uid": 2008,
"severity_id": 2,
"time": 1744787200,
"type_uid": 200801,
"activity_name": "Create",
"category_name": "Findings",
"class_name": "IAM Analysis Finding",
"severity": "Low",
"type_name": "IAM Analysis Finding: Create",
"applications": [
{
"name": "workday"
},
{
"name": "five9 plus adapter for salesforce"
},
{
"name": "workday sandbox"
}
],
"cloud": {
"provider": "AWS",
"region": "us-east-2",
"account": {
"uid": "227542035969"
}
},
"finding_info": {
"created_time_dt": "2025-04-10T06:26:40Z",
"title": "Unused Application for a User",
"uid": "8ca60986-39ae-4b43-b512-example",
"tags": [
{
"name": "framework",
"values": [
"nist_csf_pr_ac_4"
]
},
{
"name": "checkTopics",
"values": [
"compliance",
"identity_posture_insight"
]
},
{
"name": "userTrustLevel",
"value": "FAVORABLE"
}
],
"types": [
"unused-user-apps"
]
},
"metadata": {
"correlation_uid": "908040f3-da74-4a58-8029-example",
"uid": "3a9f6ca8-08af-43f0-827a-example",
"version": "1.6.0-dev",
"product": {
"name": "Identity Access Management Analysis - SAMPLE",
"vendor_name": "XYZ"
},
"profiles": [
"cloud",
"datetime"
]
},
"user": {
"email_addr": "[email protected]",
"name": "[email protected]",
"ldap_person": {
"job_title": "devops engineer"
}
}
}
looks like this is still in draft. Is it ready for review ?
looks like this is still in draft. Is it ready for review ?
Nope, I am pulling this one out of 1.5.0, we'll bring it in the next release.
How does programmatic_credentials differ from the authentication_token object?
@mikeradka Although it might appear overlapping, I see them as complementary. The authentication_token object is geared more towards representing standard protocol-based authentication info, where as programmatic_credentials is more about direct access (vendor/service issued) credentials
I have updated object descriptions to reflect that, take a look.
How does
programmatic_credentialsdiffer from the authentication_token object?
This is great. Much tighter descriptions now.
Seems like there is not a required AIM specific filed was this intentional ?