Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Zone to managed entity object #1181

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Add Zone to managed entity object #1181

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
13ac787
Add Zone entity
max-power15 Sep 25, 2024
cd40967
Adding zone object
max-power15 Sep 25, 2024
9fb6b76
validating JSON
max-power15 Sep 25, 2024
36cb15a
adding description to object
max-power15 Sep 25, 2024
61232ab
Updating Changelog MD
max-power15 Sep 25, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -56,6 +56,7 @@ Thankyou! -->
* #### Objects
1. Added `environment_variable` object. #1172
2. Added `advisory` object. #1176
3. Added `zone` object. #1181

### Improved
* #### Event Classes
Expand All @@ -70,6 +71,7 @@ Thankyou! -->
7. Added `src_url` to the `cvss` object. #1176
8. Added `advisory`, `exploit_last_seen_time` to the `vulnerability` object. #1176
9. Added `related_cwes` to the `cve` object. #1176
10. Added `zone` to the managed_entity object. #1181

### Bugfixes
1. Added sibling definition to `confidence_id` in dictionary, accurately associating `confidence` as its sibling. #1180
Expand Down
12 changes: 10 additions & 2 deletions objects/managed_entity.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,10 @@
"6": {
"caption": "Email",
"description": "A managed Email entity. This item corresponds to population of the <code>email</code> attribute."
},
"7": {
"caption": "Zone",
"description": "A managed Network Zone entity. This item corresponds to population of the <code>zone</code> attribute."
}
}
},
Expand Down Expand Up @@ -70,17 +74,21 @@
"version": {
"description": "The version of the managed entity. For example: <code>1.2.3</code>.",
"requirement": "recommended"
},
"zone": {
"requirement": "recommended"
}
},
"constraints": {
"at_least_one": [
"name",
"uid",
"uid",
"device",
"group",
"org",
"policy",
"user"
"user",
"zone"
]
}
}
14 changes: 14 additions & 0 deletions objects/zone.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
{
"caption": "Zone",
"description": "The Zone object describes characteristics of a network zone, a logical boundary to allow or deny access to devices based on IP addresses or geolocation for example.",
"extends": "_entity",
"name": "zone",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description says that this is specifically a network zone. So I'm thinking that the object should be named network_zone. Otherwise we risk running into a name collision when some other part of the OCSF schema has the concept of a zone but with a very different meaning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto!
If we are planning to get these changes in v1.4.0, the PR will need to updated with what @mikeradka recommended above with a slight change - zone_info can be the object name, and we can define an attribute called network_zone of type zone_info, to keep it clear and facilitate potential object reuse down the road.

@max-power15 Note that, these changes will need to be made by Jan 24th, considering that we are releasing 1.4.0 on Jan 31st. If you are unable to, we can always get the changes in the next minor release.

Let us know if you need help with this one. #schema on slack would be a good forum to discuss it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@floydtree I agree with this approach. It aligns with our discussion yesterday about up-leveling the dictionary attribute. If need be, we could discuss in either of the workgroup calls today. Also happy to help if need be so that we can get this into 1.4. Just let me know!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1. I assume the original zone was in reference to Availability Zone or other zonal boundaries within the CSPs (OCI, GCP, Azure, et al)

I like @floydtree suggestion to adapt

Copy link
Contributor

@mikeradka mikeradka Jan 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jonrau-at-queryai @jonrau-at-queryai @davemcatcisco @pagbabian-splunk @max-power15 Rajas and I discussed this offline and agreed to target this for 1.5.0. I'm tagging it accordingly, and implementation can begin after the 1.4.0 release, scheduled for Jan 31. This approach allows us to review the PR thoroughly, avoiding rushed changes or potential corrections in 1.5.

"attributes": {
"name": {
"description": "The name of the Network Zone. For example, <code> VPN Gateway </code> or the <code> On Premise Network Zone </code>."
},
"uid": {
"description": "The unique identifier of the network zone. For example, an <code> Okta Network Zone ID </code>."
}
}
}
Loading