Framework for High-Dimensional Anomaly Detection of Network Data in Human-Cyber-Physical Systems

Introduction Human-cyber-physical systems (HCPS) contains people, cyber components, and physical components that interact to perform an operational function. The cyber components include software, computing platforms, and communication services. The physical components include sensors, actuators, equipment, and the processes they observe or control. This usage follows work that places the human component inside the cyber-physical system rather than treating it as an external user . It is also consistent with the NIST view of cyber-physical and Internet of Things systems as interacting logical, physical, transducing, and human components . An HCPS produces network-accessible records of user actions, service operations, communications, sensor measurements, actuator states, and relations among these observations. The records use different schemas and time scales. When combined, they form a high-dimensional data space with both entity attributes and interaction structure. The broader network-big-data literature also identifies heterogeneity, uncertainty, and interaction among human, machine, and physical domains as central challenges . Attributed-network detectors show that structure and attributes can be analyzed together . Other methods use multiple views, contrastive learning, or explicit node and relation types . These methods demonstrate useful detection strategies, but each method reports results in its own form. A management system therefore cannot determine, in a consistent way, which HCPS domains, entities, relations, and feature groups supported a result. This document addresses that exchange problem. It complements the NMOP anomaly architecture, semantic metadata, and lifecycle work . It focuses on the additional context needed when anomaly evidence crosses human, cyber, and physical domains and includes high-dimensional features.

Scope This document defines four parts of an HCPS anomaly-detection framework: an observation inventory, context construction, high-dimensional anomaly analysis, and anomaly-result reporting. The framework allows different statistical, graph-based, or machine-learning methods to use the same basic description of a result. The information model covers the observation interval, HCPS domains, typed entities and relations, feature dimensions, detector profile, scores, and decision. Collection protocols and mitigation actions remain with the systems that already perform those functions.

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement and Terminology

Terminology

HCPS Observation:: A network-accessible record of a human action, cyber operation, physical measurement, physical state, or interaction among those domains.
Source Domain:: The human, cyber, physical, or cross-domain origin represented by an observation or evidence item.
Entity:: A typed object referenced by observations. Examples include an operational role, application service, network function, sensor, actuator, or controlled asset.
Typed Relation:: A declared interaction between two entities, such as accesses, invokes, communicates-with, observes, controls, or reports-to.
Source-Aware Feature Space:: A feature representation that retains the source domain and entity context of its dimensions after feature construction or dimensionality reduction.
Attribute Anomaly:: A result indicating that observed entity attributes differ from the detector's reference context.
Relation Anomaly:: A result indicating that an observed or inferred interaction differs from the detector's reference context.
Cross-Domain Anomaly:: A result supported by evidence from more than one HCPS domain, or by a combination of entity attributes and typed relations.

Heterogeneous HCPS Observations Human-domain observations describe actions, roles, requests, and interaction sequences. Cyber-domain observations describe service calls, resource state, logs, and network flows. Physical-domain observations describe measurements, equipment state, actuation, and reporting behavior. Fields with similar labels do not necessarily have the same meaning across these domains. An anomaly detector therefore needs both the value being analyzed and the domain, entity type, and observation interval that give the value meaning. Removing that context can make a valid result impossible to interpret outside the detector that produced it.

High-Dimensional Feature Space Combining HCPS observations can create hundreds or thousands of features. Many are sparse, redundant, or valid only for one entity type. A detector can reduce or encode those features, but the reported result still needs to identify the source domain, feature namespace, input dimension, and encoded dimension when those values are needed to interpret the score. A source-aware representation preserves this information while allowing each detector to choose its own feature-selection, subspace, reconstruction, or graph-embedding method.

Relation and Cross-Domain Anomalies An entity can show ordinary attribute values while its interaction with another entity is unusual. For example, a familiar operational role, a healthy service, and a normally reporting sensor can still form a new or disallowed access-and-reporting chain. Separate per-domain detectors can miss this condition because no individual entity is unusual by itself. The framework therefore distinguishes attribute evidence from relation evidence and records whether the final result depends on one HCPS domain or on cross-domain evidence.

Framework Architecture The framework has four logical stages. A deployment can place the stages in one implementation or distribute them across edge, network, and management systems.

HCPS Anomaly-Detection Framework

Observation Inventory The inventory records which HCPS domains and entity types can provide observations during an analysis interval. It also records the local identifiers and schemas needed by the next stage. Each observation group included in a result MUST identify its source domain as human, cyber, physical, or cross-domain.

Context Construction This stage associates observations with typed entities and typed relations. It provides the context needed to recognize an unusual interaction even when each entity has ordinary attributes. A reported relation MUST state whether it was observed directly or inferred by the detector.

High-Dimensional Anomaly Analysis This stage constructs source-aware features and applies a local detection method. The method can examine entity attributes, relations, or both. Dimensionality reduction is allowed, but the result SHOULD retain the input and encoded dimensions when they are needed to reproduce or compare the analysis. For streaming data, one possible processing profile uses a change-aware observation window, groups features by source and redundancy, evaluates anomaly scores within the selected groups, and combines the group-level evidence. This outline deliberately leaves the change estimator, feature-selection method, local scoring algorithm, thresholds, and parameters to the detector profile. It describes the processing context that needs to be reported, rather than requiring one algorithm for every implementation. The stage produces an attribute, relation, or cross-domain score. Scores from different detector profiles MUST NOT be treated as directly comparable unless the profiles identify a shared calibration.

Anomaly Result Reporting This stage creates a compact anomaly record for storage, validation, correlation, or lifecycle processing. The record gives the receiving system enough context to understand what was analyzed and how the detector interpreted the result. It does not require the detector to disclose model parameters or raw high-dimensional observations.

Initial Information Model The information model describes the minimum context carried with an HCPS anomaly result. It is organized around four questions: which detector produced the result, what observations were examined, what type of anomaly was found, and what evidence can be disclosed. The model is conceptual in this revision and does not define an encoding.

HCPS Anomaly Record

Observation and Feature Context The observation scope states the time interval and HCPS domains used for the decision. Entity entries state what kinds of actors, services, devices, or assets were involved. Relation entries state how those entities interacted and whether the relation was observed or inferred. The feature summary explains the dimensional context without copying raw values into the event. The namespace identifies the meaning of a feature group. The input and encoded dimensions show whether a high-dimensional representation was reduced before scoring.

Anomaly Result The detector identifier says which component produced the result. The processing profile says how that component formed its analysis window, selected or grouped features, and calculated its local score. The profile identifier and version allow a receiving system to find the corresponding configuration without placing formulas or model parameters in every anomaly record. The result category states whether the finding concerns entity attributes, a typed relation, or cross-domain evidence. Confidence describes the detector's certainty, while severity describes the expected operational importance. Keeping these meanings separate prevents a numerically high detector score from being interpreted as an automatically high operational impact.

Evidence Handling Provenance identifies the component that produced or transformed an evidence item. Sensitivity records whether disclosure is restricted. These fields allow a receiving system to evaluate the result and apply access policy without receiving all underlying human, cyber, or physical observations.

Security and Privacy Considerations HCPS anomaly processing crosses cyber and physical boundaries and can include human activity. A forged observation or relation can create a false alarm, hide a real anomaly, or cause an incorrect cross-domain correlation. Implementations need authentication, integrity protection, authorization, and audit appropriate to the deployment, following the general guidance in . An anomaly result is evidence, not permission to act. A receiving system MUST NOT use the result as the sole authorization for a network change or physical action. Existing policy and safety controls remain responsible for such actions. Human-domain observations can reveal identity, behavior, location, role, and relationships. Implementations SHOULD use role-based or pseudonymous identifiers where possible, limit retained evidence, and avoid exporting raw feature values when a feature summary is enough. Access to entity, relation, and feature evidence needs to follow the stated operational purpose.

Manageability Considerations A deployment needs to manage entity and relation types, feature namespaces, detector profiles, score interpretation, retention, and access policy. Changes that alter score meaning or field semantics SHOULD result in a new detector-profile version so that stored results remain interpretable. Operators also need visibility into which source domains were available during an observation interval. Detailed states for missing, late, or policy-excluded evidence are left for a later revision.

Implementation Status No interoperable implementation of the conceptual information model is reported for this -00 revision. The authors plan to test whether different high-dimensional detectors can produce records that a separate management component interprets consistently.

Open Issues for Future Revisions

alignment with the NMOP anomaly semantics and lifecycle models;
time quality, late evidence, and cross-domain entity resolution;
a stable YANG or message binding for the information model; and
interoperability reports from more than one detection method.

IANA Considerations This document has no IANA actions.