> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # OCSF Schema Audit Messages In the OCSF (Open Cybersecurity Schema Framework) schema, recorded log messages have this syntax: ```none { "activity_id" : , "category_uid" : , "class_uid" : , "time" : , "severity_id" : , "type_uid" : , "metadata" : "actor" : { "user" : { "type_id" : , "name" : , "groups" : } }, "src_endpoint" : { "ip": , // IP address for origin client computer "port": , // Port for origin client computer "intermediate_ips": [ { // IP address and port for mongos or load balancer "ip": , "port": }, { // IP address and port for mongos or load balancer "ip": , "port": } ] }, "dst_endpoint" : { // IP address and port for local MongoDB server "ip": , "port": }, "direct_endpoint" : { // IP address and port for the host that connects directly to // the MongoDB instance "ip": , "port": } } ``` The following table describes the fields in the log message. | Field | Type | Description | | --- | --- | --- | | `activity_id` | Integer | Activity type. See [OCSF Type Mapping.](https://www.mongodb.com/docs/manual/reference/audit-message/ocsf.md#std-label-ocsf-type-mapping) | | `category_uid` | Integer | Audit event category. See [OCSF Category Mapping.](https://www.mongodb.com/docs/manual/reference/audit-message/ocsf.md#std-label-ocsf-category-mapping) | | `class_uid` | Integer | Audit event class. See [OCSF Class Mapping.](https://www.mongodb.com/docs/manual/reference/audit-message/ocsf.md#std-label-ocsf-class-mapping) | | `time` | Integer | Number of milliseconds after the Unix epoch that the event occurred. | | `severity_id` | Integer | Severity of the audited event. | | `type_uid` | Integer | Combination of the audited event's class, activity, and category. See [OCSF Type Mapping.](https://www.mongodb.com/docs/manual/reference/audit-message/ocsf.md#std-label-ocsf-type-mapping) | | `metadata` | Document | Metadata about the event such as product and schema version. | | `actor` | Document | Information about the user who performed the action. | | `src_endpoint` | Document | Starting in MongoDB 8.1, if a client application connects to `mongos` through a load balancer, the origin client computer and load balancer IP addresses and ports are included in the audit log. You can use the log to match an audit event with the origin client computer. `src_endpoint` stores information about IP addresses and ports. Each element in the `intermediate_ips` array is a document with an IP address and port for a load balancer or `mongos` that the origin client computer request passed through. If the request passes through a load balancer: `src_endpoint` stores the origin client computer IP address and port read from the proxy protocol header.; `src_endpoint.intermediate_ips` stores the load balancer IP address and port. If the audit event occurs on a shard: `src_endpoint` stores the origin client computer IP address and port. The address and port are read from the proxy protocol header or, if the origin client computer connects to `mongos`, the address and port are read from the client computer connection.; `src_endpoint.intermediate_ips` stores the `mongos` IP address and port. And, if a load balancer is used, there is an additional `src_endpoint.intermediate_ips` that stores the IP address and port of the load balancer. The `direct_endpoint` field records the host that opens the connection when a load balancer or reverse proxy asserts the client address. **Changed in version 8.1** | | `dst_endpoint` | Document | IP address and port of the local MongoDB server. **Changed in version 8.1** | | `direct_endpoint` | Document | IP address and port of the host that connects directly to the MongoDB instance. If the client connects through a Unix domain socket, `direct_endpoint` stores an `interface` field set to `unix` and omits the `port` field. This address identifies the host that opens the connection, even when a load balancer or reverse proxy asserts a different client address. MongoDB accepts proxy protocol connections on a specific port. Any host that can reach that port can assert an arbitrary client address. To keep the recorded address trustworthy, restrict access to that port to the load balancer or reverse proxy. For audit events recorded by a shard, the reported address depends on how the shard receives the request: If a `mongos` instance routes the request, the address repeats the client address that `mongos` forwards.; If the request comes directly from `mongos`, the address records the `mongos` instance. **New in version 9.0** (*Also available starting in 8.3.9*) | **Note:** Log messages may contain additional fields depending on the event that was logged. ## OCSF Category Mapping This table describes the `category_uid` values: | `category_uid` | Category | | --- | --- | | `1` | System Activity | | `2` | Findings | | `3` | IAM (Identity and Access Management) | | `4` | Network Activity | | `5` | Discovery | | `6` | Application Activity | ## OCSF Class Mapping For a complete list of OCSF (Open Cybersecurity Schema Framework) `class_uids` and how they map to different classes, see the [OCSF Documentation.](https://schema.ocsf.io/1.2.0/classes) ## OCSF Type Mapping The `type_uid` field represents a combination of the audited event's class, activity, and category. The resulting UUID indicates the type of activity that occurred. Specifically, `type_uid` is `( class_uid * 100 ) + (activity_id)`, with `category_id` being the thousands place in a `class_id`. This table describes how audited actions map to `type_uid`: | Action Type | `type_uid` | Category | Class | Activity | | --- | --- | --- | --- | --- | | `addShard` | `500101` | Configuration | Device Config State | Log | | `applicationMessage` | `100799` | System | Process Activity | Other | | `auditConfigure` | `500201` or `500203` | Discovery | Device Config State | `1` is Create; `3` is Update | | `authzCheck` | `600301` - `600304` | Application | API Activity | `1` is Create; `2` is Read; `3` is Update; `4` is Delete | | `authenticate` | `300201` | IAM | Authentication | Logon | | `clientMetadata` | `400101` | Network | Network Activity | Open | | `createCollection` | `300401` | IAM | Entity Management | Create | | `createDatabase` | `300401` | IAM | Entity Management | Create | | `createIndex` | `300401` | IAM | Entity Management | Create | | `createRole` | `300101` | IAM | Account Change | Create | | `createUser` | `300101` | IAM | Account Change | Create | | `directAuthMutation` | `300100` | IAM | Account Change | Unknown | | `dropAllRolesFromDatabase` | `300106` | IAM | Account Change | Delete | | `dropAllUsersFromDatabase` | `300106` | IAM | Account Change | Delete | | `dropCollection` | `300404` | IAM | Entity Management | Delete | | `dropDatabase` | `300404` | IAM | Entity Management | Delete | | `dropIndex` | `300404` | IAM | Entity Management | Delete | | `dropPrivilegesToRole` | `300107` | IAM | Account Change | Attach Policy | | `dropRole` | `300106` | IAM | Account Change | Delete | | `dropUser` | `300106` | IAM | Account Change | Delete | | `enableSharding` | `500201` | Configuration | Device Config State | Log | | `getClusterParameter` | `600302` | Application | API Activity | Read | | `grantRolesToRole` | `300107` | IAM | Account Change | Attach Policy | | `grantRolesToUser` | `300107` | IAM | Account Change | Attach Policy | | `importCollection` | `300401` | IAM | Entity Management | Create | | `logout` | `300202` | IAM | Authentication | Logoff | | `refineCollectionShardKey` | `500201` | Configuration | Device Config State | Log | | `removeShard` | `500201` | Configuration | Device Config State | Log | | `renameCollection` | `300403` | IAM | Entity Management | Update | | `replSetReconfig` | `500201` | Configuration | Device Config State | Log | | `revokePrivilegesFromRole` | `300108` | IAM | Account Change | Detach Policy | | `revokeRolesFromRole` | `300108` | IAM | Account Change | Detach Policy | | `revokeRolesFromUser` | `300108` | IAM | Account Change | Detach Policy | | `rotateLog` | `100799` | System | Process | Other | | `setClusterParameter` | `500201` | Configuration | Device Config State | Log | | `shardCollection` | `500201` | Configuration | Device Config State | Log | | `shutdown` | `100702` | System | Process | Terminate | | `startup` | `100701` | System | Process | Launch | | `updateCachedClusterServerParameter` | `500201` | Configuration | Device Config State | Log | | `updateRole` | `300199` | IAM | Account Change | Other | | `updateUser` | `300199` | IAM | Account Change | Other | ## Examples The following examples show OCSF (Open Cybersecurity Schema Framework) schema log messages for different action types. ### Authenticate Action ```javascript { "activity_id" : 1, "category_uid" : 3, "class_uid" : 3002, "time" : 1710715316123, "severity_id" : 1, "type_uid" : 300201, "metadata" : { "correlation_uid" : "20ec4769-984d-445c-aea7-da0429da9122", "product" : "MongoDB Server", "version" : "1.0.0" }, "actor" : { "user" : { "type_id" : 1, "name" : "admin.admin", "groups" : [ { "name" : "admin.root" } ] } }, "src_endpoint" : { "ip" : "127.0.0.1", "port" : 56692 }, "dst_endpoint" : { "ip" : "127.0.0.1", "port" : 20040 }, "user" : { "type_id" : 1, "name" : "admin.admin" }, "auth_protocol" : "SCRAM-SHA-256", "unmapped" : { "atype" : "authenticate" } } ``` ### AuthCheck Action ```javascript { "activity_id" : 0, "category_uid" : 6, "class_uid" : 6003, "time" : 1710715315002, "severity_id" : 1, "type_uid" : 600300, "metadata" : { "correlation_uid" : "af4510fb-0a9f-49aa-b988-06259a7a861d", "product" : "MongoDB Server", "version" : "1.0.0" }, "actor" : {}, "src_endpoint" : { "ip" : "127.0.0.1", "port" : 45836 }, "dst_endpoint" : { "ip" : "127.0.0.1", "port" : 20040 }, "api" : { "operation" : "getParameter", "request" : { "uid" : "admin" }, "response" : { "code" : 13, "error" : "Unauthorized" } } } ```