Add anomaly type to Potential Threats category

[larihuttunen]

Description

This pull request adds a new functional type, anomaly, to the Potential Threats category in the Data Harmonization Ontology.

Justification

Currently, the Potential Threats category includes the attribution type, which is defined for "Observations that can be attributed to malicious activity, which are not detailed enough to action on". This works well for observations where malicious intent is suspected, but we lack a type for observations that are simply unusual or represent an unspecified exposure without any initial evidence of malice.

The anomaly type is introduced to fill this specific gap. It is defined as:

"This type denotes an observation that deviates from expected patterns or baselines but is not immediately identifiable as a specific vulnerability or malicious event."

By adding anomaly, we allow for more precise classification of raw or unverified findings that require human analysis, improving the fidelity of the ontology without prematurely labeling an event as malicious. This aligns with the core goal of categorizing information to serve the correct domain of expertise—in this case, threat analysis and risk assessment.

Changes Made

• Added the anomaly type definition to the table under the "Potential Threats" section in Harmonization.md.

[larihuttunen]

Hi team,

To provide some broader context for this pull request and address the long-term governance and sustainability of this data model, I would like to share a strategic perspective on how we can collectively mitigate intellectual property (IPR) risks while maximizing the value of the ontology.

Strategic Context: Multi-Government Collaboration

As this data harmonization ontology has been historically shaped and validated in close collaboration with multiple international national cyber security authorities and CSIRTs, maintaining it under a strictly rigid, closed proprietary framework introduces implicit legal and alignment risks. Transitioning the schema/ontology definition layer to a recognized open standard (e.g., Apache 2.0 or MIT) ensures long-term compliance and trust with the public sector entities that rely on it and have contributed to its conceptual foundation.

Mitigating IPR Risks via a Contributor License Agreement (CLA)

I understand that accepting external contributions can raise internal concerns regarding IPR contamination or ownership clarity. To fully eliminate this risk for Arctic Security, I propose the introduction of a standard Contributor License Agreement (CLA) for this public repository.

A CLA (similar to frameworks used by Google, Microsoft, or the Linux Foundation) ensures that any external contributor formally signs off, granting and vesting the intellectual property and usage rights of their PR to Arctic Security.

This provides the company with total legal safety and uncompromised ownership of the repository.

Commercial Alignment: The Road vs. The Car

Adopting an open governance model for the ontology definition layer serves as a commercial multiplier rather than a loss:

The Ontology is the Road: Making the schema an open, accessible standard drives global adoption. It is already utilized globally across dozens of countries as a de facto baseline.

The Processing Engine is the Car: Arctic Security’s core commercial value does not lie in the markdown definition files, but in the proprietary automation engines, data ingestion pipelines, and products that execute this ontology at scale.

By formalizing the ontology layer as an open standard managed securely through a CLA, Arctic Security shifts from a vulnerable position of hoarding shared international concepts to becoming the respected Global Custodian of a widely adopted threat intelligence standard.

I am highly open to discussing how we can formalize a CLA framework to make accepting this and future pull requests legally seamless and risk-free for the company.

Best regards,
Lari