| Internet-Draft | HCPS Anomaly Framework | October 2026 |
| Zhong, et al. | Expires 19 April 2027 | [Page] |
Human-cyber-physical systems combine human activity, computing and communication services, and networked physical processes. Their network data is heterogeneous and high-dimensional. An abnormal condition can appear in the attributes of one entity, in an interaction between entities, or only when evidence from several domains is considered together.¶
This document specifies an initial framework for anomaly detection in human-cyber-physical environments. It describes the functions used to inventory observations, construct entity and relation context, analyze high-dimensional data, and report an anomaly result. It also defines a small conceptual information model so that anomaly results retain their observation scope, feature context, and score meaning.¶
This note is to be removed before publishing as an RFC.¶
Discussion of this document is expected to take place on the Network Management Operations (NMOP) Working Group mailing list (nmop@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/nmop/.¶
This document is currently an individual contribution. Its use of the NMOP name in the document header does not indicate Working Group adoption.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [HCPS-AD]. It is also consistent with the NIST view of cyber-physical and Internet of Things systems as interacting logical, physical, transducing, and human components [NIST-CPS-IOT].¶
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 [NETWORK-BIG-DATA].¶
Attributed-network detectors show that structure and attributes can be analyzed together [DOMINANT] [AnomalyDAE]. Other methods use multiple views, contrastive learning, or explicit node and relation types [CoLA] [AHEAD] [MOD-KF]. 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 [I-D.ietf-nmop-network-anomaly-architecture] [I-D.ietf-nmop-network-anomaly-semantics] [I-D.ietf-nmop-network-anomaly-lifecycle]. It focuses on the additional context needed when anomaly evidence crosses human, cyber, and physical domains and includes high-dimensional features.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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.¶
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.¶
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.¶
The framework has four logical stages. A deployment can place the stages in one implementation or distribute them across edge, network, and management systems.¶
+----------------+ +----------------+ +----------------+
| Human-domain | | Cyber-domain | | Physical-domain|
| observations | | observations | | observations |
+-------+--------+ +-------+--------+ +-------+--------+
| | |
+-------------------+-------------------+
|
+---------v----------+
| Observation |
| Inventory |
+---------+----------+
|
+---------v----------+
| Context |
| Construction |
| entities, relations|
+---------+----------+
|
+---------v----------+
| High-Dimensional |
| Anomaly Analysis |
+---------+----------+
|
attribute, relation, or cross-domain result
|
+---------v----------+
| Result Reporting |
| and Storage |
+---------+----------+
|
validation and lifecycle processing
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.¶
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.¶
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.¶
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.¶
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
identification
event-id, detection-time, detector-id
processing-profile
profile-id, profile-version
window-policy, feature-policy, scoring-policy
observation-scope
start-time, end-time, source-domains[]
entities[], relations[]
feature-summary[]
source-domain, feature-namespace
input-dimension, encoded-dimension
contributing-feature-groups[]
anomaly-result
category, score, threshold, confidence, severity
evidence-handling
provenance[], sensitivity
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.¶
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.¶
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.¶
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 [RFC3552].¶
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.¶
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.¶
This section is to be removed before publishing as an RFC.¶
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.¶
This document has no IANA actions.¶