Add UAS (drone) tracking event: `Drone Flights Activity`

[jonrau-at-queryai]

Related Issue:

N/A

Description of changes:

As discussed in an OCSF meeting on 3 SEPT 2024 - there was a desire to bring IoT and drone/UAS related normalization into the schema.

This PR creates the Remote ID Activity Event which captures details from the Remote ID specific described in ASTM F3411-22a: Standard Specification for Remote ID and Tracking such as the specific UAS/drone platform, operating areas, the operator themselves, and other relevant information that could be captured or logged by dedicated Counter-UAS or UAS monitoring devices and software.

While a majority of the attributes were repurposed, several new attributes and objects were added into the dictionary to support modeling this.

[irakledibm]

I would suggest to rename it to drone_flights_activity, remote_id_activity as a name is not clear for anyone who is not working directly with drones.

[jonrau-at-queryai]

@irakledibm made the change and updated the changelog with new merges in.

Some folks still want this in an extension.

[irakledibm]

It has an error: Error processing objects/unmanned_aerial_system.json: missing value for field "attributes.type"

[jonrau-at-queryai]

It has an error: Error processing objects/unmanned_aerial_system.json: missing value for field "attributes.type"

Yeah that took a bit to find, just fixed it

[taddhar]

small editorial issue in CHANGELOG: "Actiivty"

[taddhar]

A more fundamental remark and a question. When I look at the dictionary, the list of attributes defined here is very traditional to the "domain knowledges" of security, IT, ICT.

Now when I see the block of attributes this brings here I fear it is unbalancing the current dictionary and wonder how we are going to do for each and every IOT domain knowledge.

Meaning accepting this PR in the way it is and modifying the dictionary this way is opening the door for a colossal future expansion of the dictionary.

Is this really what we want?

[irakledibm]

I think that IOT will become very large part of the cybersecurity and we can't ignore it.

[jonrau-at-queryai]

I agree with @irakledibm that there will be more IOT startups coming up and IOT becoming much more relevant into the overall domain.

Additionally, this type of IOT/UAS activity is already considered as "cyber", more specifically: Cyber Electro Magnetic Activity (CEMA), which is how the Joint Chiefs in USDOD (and how NATO also views it) covers down on this type of overlapping domain.

It would be great to get adoption form more government/military types for OCSF. It will make the schema pretty large, and there is a good reason to put this in Extensions, but I also don't like Extensions and I think there is support to do away with them for 2.0.0 but that's neither here nor there.

Not that your observations and concerns are lost on me @taddhar I felt the same while I was authoring this PR, it's a laser-specific set of attributes and objects, but I think that is fine since we have dozens of other events that are precisely for one thing.

[taddhar]

No :-) I didn't mean that IoT is not important, it is actually one of my biggest worries :-) My question is 'normative' here because I need to see it from a document stability in the long run and there are various ways we can manage that situation. IF the team agrees to make it this way, my recomendation is that we have a CLEAN delineation between each domain knowledge that the WHOLE of IoT space is going to give us ... and that is going to push us on interesting taxonomy and even ontologicial issues. It is all about setting expectations

[irakledibm]

I agree that some of the additions to a dictionary should have more distinct naming, since it may have different meaning in other domains. The "operator" for example in case of the UAS refers to a human identity, while in a cloud domain refers to deployment lifecycle management and may have different meanings in other domains. I will add few naming recommendations and we can discuss it. However I agree with Jonathan that IoT should not be part of the extension. I would avoid usage of extensions as much as possible. We probably should add new category for IoT and it is a natural evolution of OCSF.

[jonrau-at-queryai]

....I will add few naming recommendations and we can discuss it. ... We probably should add new category for IoT and it is a natural evolution of OCSF.

Sounds good! I think a new Category does make sense, and I can do better to disambiguate. I'll await your suggestions and implement.

[taddhar]

@irakledibm yes you hit the issue with your example with operator. And again I agree I didn't mean to make it an extension either. Perhaps we should look for a categorisation or a name space but you are the experts here. What I am not comfortable with is to have a flat, foreever expanding dictionary. @jonrau-at-queryai yes I see your comments too and agree on the remark on extensions.

Ok am pretty dead tired at the time of writing this so let's sleep on it and let's see if night is helping @irakledibm to propose some recommendations.

[irakledibm]

Proposed changes:

1. Add new category: "Unmanned Systems Activity"

"unmanned_systems_activity": { "caption": "Unmanned Systems Activity", "description": "Unmanned Systems Activity events report detailed information about the behavior of unmanned systems.", "uid": 8 },

2. "ceiling" change to "altitude_ceiling", caption to "Altitude Ceiling"

3. "floor" change to "altitude_floor", caption to "Altitude Floor"

4. "height" change to "aerial_height", caption to "Aerial Height"

5. "operator" change to "unmanned_system_operator", caption to "Unmanned Systems Operator"

6. Object "operating_area" change to "unmanned_system_operating_area"

7. "unmanned_system_operator" probably should be of type=user not managed_entity

8. drone_flights_activity class file name is incorrect "events/network/remote_id_activity.json", has to be changed

9. altitude_ceiling, altitude_floor, aerial_height, geodetic_altitude, geodetic_vertical_accuracy, horizontal_accuracy, pressure_altitude probably should be changed from string_t to integer_t

[taddhar]

thank you @irakledibm I think it is already much better.

Just a question for my curiosity. Why do I see a postal attribute?

[taddhar]

I mean 'postal_code' in locations.json ... for a drone?

[jonrau-at-queryai]

Proposed changes:

1. Add new category: "Unmanned Systems Activity"

"unmanned_systems_activity": { "caption": "Unmanned Systems Activity", "description": "Unmanned Systems Activity events report detailed information about the behavior of unmanned systems.", "uid": 8 },

2. "ceiling" change to "altitude_ceiling", caption to "Altitude Ceiling"
3. "floor" change to "altitude_floor", caption to "Altitude Floor"
4. "height" change to "aerial_height", caption to "Aerial Height"
5. "operator" change to "unmanned_system_operator", caption to "Unmanned Systems Operator"
6. Object "operating_area" change to "unmanned_system_operating_area"
7. "unmanned_system_operator" probably should be of type=user not managed_entity
8. drone_flights_activity class file name is incorrect "events/network/remote_id_activity.json", has to be changed
9. altitude_ceiling, altitude_floor, aerial_height, geodetic_altitude, geodetic_vertical_accuracy, horizontal_accuracy, pressure_altitude probably should be changed from string_t to integer_t

Thanks @irakledibm I am not sure if a dedicated UAS Category makes sense, I can only thing of one other activity that would possibly fit for this, but it's a distinct military capability for Counter UAS.

I was going to do an Internet of Things iot.json category as I think we'd get more mileage out of that.

Everything else makes sense - I had the types for 9 as strings because that is what the RID spec had them as but I will change them to float_t.

@taddhar I didn't add postal_code that was there already

[taddhar]

Ok @jonrau-at-queryai do you know where this is coming from? Is it from a norm somewhere? Actually as @pagbabian-splunk is adding a metadata to track the sources we are going to need it.

In fact the reason why I am overlooking this one is because when it comes to the ITU this will have a HUGE bar of pressure because UAS is heavily connotated and I am going to have tons of questions by member states and given the geopolitics of the day, I will need to be ABSOLUTELY prepared down to each attribute, etc. Not sure you realize the door this is opening.

[irakledibm]

@jonrau-at-queryai I proposed "Unmanned Systems Activity", not "Unmanned Aerial Systems Activity", which would include any remotely operated devices (air, space, ground, underground, water, under water). Didn't propose IoT since in my opinion IoT is too large and very general (anything from healthcare to appliances).

[taddhar]

@irakledibm I like your intention but I am not sure it works. If you change (here generalise) the scope of this 'category', you may need to revisit all the attributes behind it. Therefore my earlier point of postal_code. It seems that the current attributes are 'imported' from some reference that is in an Aerial context. If now you generalise to any Unmanned system, we may need more attributes or to generalise some of them ... or not. Hope my point translates.

[jonrau-at-queryai]

@irakledibm we will need to get more opinions on this, not sure how the larger group feels about adding more categories. I am indifferent, I can see IOT or Unmanned Systems Activity being used and I am sure we'll get pros/cons of either.

[irakledibm]

Agreed, lets discuss it during our next weekly meeting.

[pagbabian-splunk]

Great discussion - I will add this to this week's group call for Tuesday.