Replies: 3 comments 9 replies
-
|
The Firewall, along with other security products, performs various actions based on the activity it detects. Therefore, the event should include attributes that report both the original activity that triggered specific firewall rules and the subsequent actions executed by the firewall. For instance, the proposed class does not provide a clear description of the actual activity. What exactly triggered the firewall rule? In other words, what does the 'activity_id=Allow' indicate as being allowed? Was it a new connection, data traffic, or a file download? Additionally, was the rate within acceptable limits? While we have made considerable progress in defining activity classes, we haven't focused as much on detailing the security actions triggered by these activities. The OCSF has introduced a single profile, 'https://schema.ocsf.io/1.0.0-rc.3/profiles/security_control,' which serves as a starting point for covering the security actions resulting from normal activity events. However, due to time constraints, we were unable to fully explore and expand upon this idea. Now might be an opportune moment to delve deeper into this aspect. |
Beta Was this translation helpful? Give feedback.
-
|
I see your point, however I think, our activity_ids should be focused directly on the most obvious activity of the event. A specialized source such as a L7 firewall, should have an event class with activity_ids that directly reflect that source's activities. e.g in the case of web application firewall activity, the event class's activity_ids should be about whether the connection was allowed/blocked/etc instead of new connection, data traffic, or a file download The triggering-activity that caused the WAF to log an event, which will be a supporting contextual piece of information, can be determined based on information in the supporting attributes (in this class's case, I infer it will be rules.match_details). |
Beta Was this translation helpful? Give feedback.
-
|
This will be available within the PR when I raise it, however http_request will be a required object which addresses your aforementioned criteria. The proposal above is just to highlight the specific elements which makes this unique, and does not encompass the entire event class. For example the event you posted will map to the following under 6005 which is quite straightforward: |
Beta Was this translation helpful? Give feedback.
-
|
ok, what I am trying to say is that we don't need a new event, let's reuse the existing event and use a profile to add the fw specific attributes. |
Beta Was this translation helpful? Give feedback.
-
|
But that goes back to the original point, if we reuse a class, we'll not have L7 firewall specific activity_ids and that would be a crucial miss. I think having a dedicated L3 firewall class would also be worthwhile. |
Beta Was this translation helpful? Give feedback.
-
|
The L7 firewall specific activities will be in put in the |
Beta Was this translation helpful? Give feedback.
-
|
These perspectives will be discussed in the next meeting |
Beta Was this translation helpful? Give feedback.
-
|
@pagbabian-splunk @rroupski @floydtree |
Beta Was this translation helpful? Give feedback.
-
|
My PR is ready to go as soon as this is reviewed |
Beta Was this translation helpful? Give feedback.
-
.
.
.
Full EC Context -
}
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions