Introduction

As of January 31st 2025, the latest version of the Open Cybersecurity Schema Framework (OCSF)–version 1.4.0–has been released! The 1.4.0 release represents a very large increment to the schema, and was nearly six months in the making. The schema expanded greatly in this release to include a brand new category and profile, several new Observables, seven new classes, over 140 net-new changes, and over a dozen deprecations.

Query has made several contributions as per the synopsis of the changes, as have several others who we work with to make the schema successful and widely adopted. In this blog, we will highlight some of the contributions on behalf of the Query team, notable updates that others have contributed, and take a look on the road ahead to OCSF 1.5.0.

If this is your first time reading about the OCSF, or if you are coming back to it after an absence, consider reading our beginner and executive-friendly blog: Query Absolute Beginner’s Guide to OCSF. For a more detailed explanation of OCSF, see our other blog: Definitive Guide to Open Cybersecurity Schema Framework (OCSF) Mapping.

Lastly, the OCSF Examples repo has undergone significant changes and contributions, and can be viewed here.

Query Contributions to OCSF V1.4.0

The Query Team has contributed significantly to the OCSF since we adopted it as our data model and our lingua franca–the mechanism by which we capture search intent of Federated Search users–and we have been involved since Version 0.31.0. The most exciting change, to me, is that your humble author (Jonathan Rau), is now a codeowner within the OCSF repo. Along with a little over half-a-dozen others, I help to ensure that all changes to the schema are high-quality and properly scrutinized. It has, and continues to be, an honor and privilege to be able to contribute and grow the most ambitious and successful cybersecurity schema.

However, as of 1.4.0, OCSF is no longer only a cybersecurity schema, as you will see. The use cases that OCSF can support–normalization and standardization–have now extended to unmanned systems. Whether you pay close attention to geopolitical events and modern warfare, are a hobbyist yourself, or simply know what a drone is: you are familiar with unmanned systems. Also known as Unmanned Aerial Vehicles (UAVs) or Unmanned Aerial Systems (UAS), unmanned systems are part of everyday life. From building surveyors to linesmen, firefighters to FBI SWAT teams, combatants and professional racers, drones are integrated more and more with our lived experiences.

With that in mind, there also need to be ways to monitor unmanned systems. Whether you are an Electronic Warfare (EW) or Signals Intelligence (SIGINT) specialist–or an “old crow”, if you would–or are part of air traffic control or public safety, being able to monitor unmanned systems and their operators is paramount for safety. There exists an United States Federal Aviation Administration (FAA) standard called Remote ID that mandates drone manufacturers provide transponders on unmanned aircraft that broadcasts their full location metadata, and that of their operator. Remote ID allows professional end users, other drone enthusiasts, and even regular citizens, to decode and monitor drones in real time.

Remote ID can be decoded with several mobile apps, open source projects like WarDragon, and other professional mechanisms such as AeroScope and DeDrone. While there are privacy concerns that are out of the scope of this blog, the standard also lists the schema of this data. All that to say, the Unmanned Systems Category has officially been added to the OCSF schema with the Drone Flights Activity event class used to normalize Remote ID and additional collections metadata into the OCSF. Whether you’re using a War Dragon, consuming Remote ID data from Anduril’s Lattice C2, an ATAK Server, or Palantir Gotham you can now use the OCSF to analyze, store, and/or visualize Remote ID data.

Additionally, another Event Class was added to the Unmanned Systems Category, Airborne Broadcast Activity which allows you to normalize data from another well-known aviation safety standard: Airborne Dependent Broadcast-Surveillance (ADS-B). ADS-B is used nationwide, and internationally, to broadcast flight metadata and Position Location Information (PLI) from aircraft, gliders, balloons, and even larger agricultural and public safety drones. Just like Remote ID, there are several applications and mechanisms to capture ADS-B. You can even stream ADS-B locations anywhere in the world with services like FlightAware and ASDBTracker. Or, you can use an RTL-SDR Dongle, an antenna tuned for 1090MHz, and the dump1090 program to capture ADS-B data yourself.

While I’m not formally trained, I am an enthusiast of fixed-wing, rotary-wing, and unmanned aircraft, and have developed my own mechanisms to capture and monitor this information using DragonOS, BladeRF, HackRF, and other tools. Maybe one day I too can be an “old crow”. When Query updates the Query Data Model (QDM) to OCSF v1.4.0 you can use search federation to look for observables and other data of merit within your normalized ADS-B and Remote ID data.

Other contributions from the Query team include the addition of a new Discovery category Event Class, Cloud Resource Inventory Info. Previously, to normalize cloud asset management data–such as data from Axonius, Armis, ElectricEye, or otherwise–mappers and producers would have to make use of Device Inventory Info and other Discovery classes to crudely map the data. Now, a dedicated Event Class that was purpose built to normalize and standardize cloud asset data has been created. You’ll have access to data normally spread around the Cloud Profile and the Resources Detail Object along with several other Objects to make normalizing anything from the cloud accounts to small sub-resources a breeze.

Alongside that change, several improvements have been made to the Identity Provider (IdP) Object which has been lacking an update for several releases of OCSF. Now, the Object has been greatly expanded to normalize Single-Sign On (SSO) and System for Cross-domain Identity Management (SCIM) data and other metadata. This way, you can capture specific configurations from upstream systems for SaaS Security Posture Management (SSPM) use cases, or simple asset management collection jobs.

Additionally, we added more updates to the Open Source Intelligence (OSINT) Profile that we contributed to OCSF for the 1.3.0 release. Firstly, we expanded the OSINT Profile by adding several new Objects (File, Related Analytics, Reputation, Script), new Attributes (Subnet), and expanding the enum to include Command Line, Registry Key, and Registry Value. Finally, we created a standalone Event Class in the Discovery category: OSINT Inventory Info. If you want to normalize data that comes from the threat intelligence table in Microsoft Sentinel, or from Events in your Malware Information Sharing Project (MISP) server, this affords you the ability to do so.

Finally, we added several new Observables into the schema to help account for quick searching and pivoting within the schema. These include User UID, Group Name, Group UID, Account Name, Account UID, Serial Number, and Resource Name. This was done to give a sibling Observable to both Username and Resource UID, as well as add pertinent Observables for identity and cloud platforms. Lastly, Serial Number is referenced by Unmanned Systems Category event classes as well as device hardware information captured by several security and IT tools.

Other small changes that we helped contribute as well include

  • Adding vendor_name and model Attributes to the Device Object.
  • Created the has_mfa boolean Attribute and added it to the User Object, along with phone_number to the User and LDAP Person Objects.
  • Added a new enumeration–11 (Basic Authentication)–to the Authentication Protocol ID Attribute which appears in the Authentication Event Class.
  • Added the HTTP Headers array Object to the Email Object.
  • Hostname, IP, and Name were added to the Resource Details Object, especially useful for cloud-based asset management.

Again, it was an honor being named as a Codeowner and expanding the stewardship that I can bring to the OCSF on my own and on behalf of Query. It was equally just as fun to be able to contribute so many new additions to the schema, I did find myself chuckling several times seeing Unmanned Systems as a new Category! I hope to see more folks adopting it for their own use cases. There were also a lot of other great contributions we wanted to call out too.

Other Notable Contributions to OCSF 1.4.0

Query contributions are always great to celebrate, but equally important are changes to the schema from other individuals and companies to expand the schema. These are in no particular order of importance.

Firstly, a minor one, but other folks besides us had added to Observables: Script Content is now an Observable type. This is part of a larger change that added the Script Activity event class to the System category for capturing information about executable scripts. This can be used for both IT and security use cases, especially helpful when normalizing EDR or XDR data that retains information about the actual script content.

One of the other popular event classes that Query has contributed, Data Security Finding, saw a major improvement and overhaul. Data Classification and Data Security Objects have gotten updated and expanded as has the Databucket Object to better support Amazon Macie and other AWS-specific Data Security Posture Management (DPSM) findings. Now, you can account for encryption types, encryption modes, storage class, as well as metadata such as key, path, column, row, and page information within implicated findings.

If you are a DSPM or other data security company looking to contribute a mapping, the Data Security Finding is a great place to start. While this most notably supports AWS use cases, other cloud vendors and DSPMs such as Azure Defender for Cloud, Cyera, and others capture this same type of detail in their owning alerting and event schemas.

A very exciting change was added to the Software Inventory Info event class in the Discovery Category, and that is the addition of a Software Bill of Material (SBOM) object and supporting sub-objects. SBOMs have been around for a few years in the security industry and are still applicable to AppSec and vulnerability management teams. Now you can take advantage of the OCSF for inventorying your SBOMs or creating findings with them with the addition of the new objects.

The Device object is very popular in the OCSF and well-used across the Host Profile as well as several dozen Event Classes. It has seen improvements and expansions to include the ability to capture kernel and release information in the Operating System Object within Device, as well as the CPU Architecture within the Device Hardware Information Object. Lastly, for those of you normalizing Mobile Device Management (MDM) information, a string array of IMEIs have been added in place of the single IMEI object.

Lastly, the Tags Object was changed and added as part of the Key Value Object which allows for greater flexibility of accounting for tags, labels, annotations, and various other key-value pair type details that are often appended to assets. This can be as straightforward as adapting cloud provider tagging, adding tags from Alerts and Incidents of upstream systems, or accounting for labels from Kubernetes objects.

Some other notable changes that we found cool were:

  • HTTP Request, HTTP Response, JA4 Fingerprints, and TLS Objects added to the Evidence array Object.
  • Related CVEs and Related CWEs were added as arrays of the CVE and CWE Objects, respectively.
  • New Environment Variable, Advisory, and Vendor Attributes Objects were created to account for more metadata related to several dozen Event Classes.
  • A new Profile was added for Incident information, now you can capture incident response and incident commander data as a Profile into Event Classes that didn’t have it such as Detection Finding.
  • Several deprecations include project_uid in favor of account.uid, kb_article_list in favor of advisory, policy in favor of policies in the Account Change event class, and several deprecations from the Email object.

For a complete look at all of the changes and contributions, see the linked Release Changelog in the Introduction section. And for a bit of a lookahead, at least an opinionated one, proceed to the next section.

Looking ahead to OCSF 1.5.0

While OCSF 1.4.0 has just come out and the Query team is hard at work updating our QDM schema to use it, we are already looking ahead at OCSF 1.5.0. As part of delivering a federated search solution that also offers schema normalization based on OCSF, we develop several dozen of our own mappings per month. These can be in support of customers onboarding their own dynamic sources from Snowflake, Splunk, Amazon Security, and others using our Configure Schema no-code mapping workflow or static sources such as our direct integrations.

As such, we constantly encounter occasions where we can not map to the schema in the best possible ways. This usually happens when a Profile is not supported by a specific Event Class, when an Object is missing key Attributes, or in some cases an Object doesn’t support enough of the same Attribute. For example, in the Device Object you have instance_uid for public cloud compute IDs (e.g., Amazon EC2 instance IDs), uid for the main ID, and uid_alt for alternative identifiers such as an Active Directory Common Name.

Not all OCSF Objects are as “well stocked” as the Device Object, nor are all OCSF Objects made with the same amount of attributes. This is usually because a specific vendor submitted an Object based on something similar, or an individual mapper opens a Pull Request against the OCSF repo. Query is extremely blessed (and cursed, in a way) to have so much access to so many tools and schemas that we can find discrepancies faster than the average practitioner.

So, to that end, look for Query to add more Attributes to more Objects across the entire schema and overhaul or add other Objects. This will be a never-ending battle to account for numberless amounts of vendor schemas while also keeping OCSF generic and abstracted in different ways. We will also likely add other Event Classes, though, we don’t know for what–yet!

A bigger project that is top of mind is to expand the OSINT Profile or add another Profile that accounts for more actor- and campaign-centric data. When we first developed the OSINT Profile, we attempted to model several Objects against the Structured Threat Intelligence Exchange (STIX) format, which has generic ways to capture details on threat actors, campaigns, capability sets, motivations, and individual attacks.

We look forward to working with others in the OCSF community to add a STIX-like Object and Profile that captures this information. It is not without cause, beyond the Threat Intelligence Platforms (TIPs), it is not uncommon for Endpoint Detection & Response vendors–Microsoft, Crowdstrike, SentinelOne, and others–to include attacker, campaign, threat name, and other categorization data in their alerting.

Finally, there are still areas in which OCSF is not able to serve. This includes several types of data that are also present in EDR tools, such as recommendations, scoring data, and Application Security centric findings such as SCA, IAST, DAST, ADR, and others. As we encounter those vendors to add search federation support for, we will likely be better informed about the future contributions in that vein.

Conclusion

The Open Cybersecurity Schema Format (OCSF) continues to grow, both from an adoption and contribution perspective, and here at Query we are very proud of that. We took a calculated risk for sure when we picked in version 0.31.0 to serve as our data model and search translation basis, and it has been a great decision.

We covered some of our more exciting contributions as well as the equally exciting and impactful contributions from others in the community and look forward to working with more and more of you (and the same old friends) as well as continue to plow ahead. 2025 definitely feels like the year that more and more security teams get serious about their SecDataOps journey and commit resources and training into data governance, and hopefully adopt the OCSF as well.

Be sure to check out our referenced guides and look forward to more OCSF-related content from the Query team in the future! 

If you want to use the OCSF but are not sure where to start, or do not want to take on the ownership of data governance and Extraction, Transformation, and Loading (ETL), reach out to the team and we are happy to give you a demo of Query Federated Search capabilities. With our search federation platform, you never have to worry about ETL, about how to translate queries to several different languages, or data sovereignty concerns. Query never duplicates nor stores your data in a persistent backend and we take care of query building, planning, execution, and data normalization all on your behalf.

Stay Dangerous.