A YANG Data Model for Network Element Threat Surface Management
Internet-Draft draft-hu-network-element-tsm-yang-01
Feifei Hu
China Southern Power Grid
huff@csg.cn
Danke Hong
China Southern Power Grid
hongdk@csg.cn
Liang Xia
Huawei Technologies
frank.xialiang@huawei.com
18 September 2024
This document defines a base YANG data model for network element threat surface management that is application- and technology-agnostic.
Introduction
nowadays, there are more and more advanced network attacks on network infrastructures, such as routers, switches, etc. To ensure the security management of network devices, the first thing is to continuously improve the security status visibility of network devices. To achieve this, on the one hand, the device security operation baseline should be defined based on device's normal services, so that the abnormal status of the device is identified in real time based on the trustlist similar mechanism, to ensure that all devices, connections, and traffic meet the expectation. On the other hand, by switching to the attacker perspective, comprehensively define the threat surface of devices, and manage potential risks in a timely manner through identification and monitoring to ensure the convergence of the threat surface.
Network element threat surface management is not a new concept, a similar concept is External Attack Surface Management (EASM) which is defines as "refers to the processes, technology and managed services deployed to discover internet-facing enterprise assets and systems and associated exposures which include misconfigured public cloud services and servers, exposed enterprise data such as credentials and third-party partner software code vulnerabilities that could be exploited by adversaries.". In contrast, EASM is a larger system and methodology, of which this document presents a specific implementation for network devices. In addition, the difference between the threat surface and attack surface needs to be clarified. The threat surface may not have vulnerabilities or be an attack surface. However, it is exposed to the sight of attackers and faces threats from external attackers. Therefore, the security risk is high. The attack surface can be accessed by hackers and has vulnerabilities, that is, it is both exposed and vulnerable, and the security risk is very high. In summary, not all threat surfaces will become attack surfaces, only exploitable threat surfaces that overlay attack vectors will become an attack surface. So, managing the exposure means converging the attack surface.
In the past, the IETF has done some work in the area of security posture definition, collection, and assessment, including the concluded Network Endpoint Assessment (NEA) and Security Automation and Continuous Monitoring (SACM) working groups [RFC5209][RFC8248]. However, they mainly complete the standard definition of general use cases and requirements, architecture and communication protocols, and software inventory attribute definition, and do not continue to extend and define more specific security posture models, such as the network device threat surface model proposed in this document. As described above, in the current situation of increasingly frequent network attacks and complex means, it is valuable to define the specific security posture model to automatically mitigate major security risks in user networks. Recently, the extended MUD YANG model for SBOM and vulnerability information of devices defined in [RFC9472], and the extended MUD YANG model for (D)TLS profiles for IoT devices proposed in [I-D.ietf-opsawg-mud-tls], seems as the continuation of the definition of the specific security posture model.
Section 2 of this document defines the basic framework of the threat surface management. The details are as follows:
- What parts are included? How to design each part? Specifically, what attributes, configurations, and running status information are included?
- What their relationship is like.
- Some key points in operation: timely discovery, continuous visibility, verifiability, traceability, priority management, etc.
Based on the above definitions, Section 5 of this document defines the YANG model for the device threat surface management.
Terminology and Notations
The following terms are defined in [RFC7950] and are not redefined here:
- client
- server
- augment
- data model
- data node
The following terms are defined in [RFC6241] and are not redefined here:
- configuration data
- state data
The terminology for describing YANG data models is found in [RFC7950].
Following terms are used for the representation of the hierarchies in the network inventory.
Network Element:
- a manageable network entity that contains hardware and software units, e.g. a network device installed on one or several chassis
Chassis:
- a holder of the device installation.
Slot:
- a holder of the board.
Component:
- a unit of the network element, e.g. hardware components like chassis, card, port, software components like software-patch, bios, and boot-loader
Board/Card:
- a pluggable equipment can be inserted into one or several slots/sub-slots and can afford a specific transmission function independently.
Port:
- an interface on board
Requirements Notation
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.
Tree Diagram
The meaning of the symbols in this diagram is defined in [RFC8340].
Prefix in Data Node Names
In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table.
Prefixes and corresponding YANG modules
Prefix | Yang Module | Reference
inet | ietf-inet-types | [RFC6991]
yang | ietf-yang-types | [RFC6991]
ianahw | iana-hardware | [IANA_YANG]
ni | ietf-network-inventory | RFC XXXX
RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please remove this note.
Definition of Threat Surface
Overview
Figure 1 depicts the overall framework of the network element threat surface management:
Network Element Threat Surface Management Framework

                +------------------+
                |  Threat Surface  |
                +--------+---------+
                         |
      +-------------+----+-------+------------+
      |             |            |            |
      |             |            |            |
      |             |            |            |
      |             |            |            |
 +----v----+  +-----v---+  +-----v---+ +------v------+
 |Interface|  | Service |  | Account | | Version &   |
 |Exposure |  |Exposure |  |Exposure | |Vulnerability|
 +---------+  +---------+  +---------+ +-------------+

Interface Exposure
Device interfaces include physical interfaces (such as Gigabit Ethernet interfaces) and logical interfaces (such as POS, tunnel, and loopback), and IP management layer interfaces for local access.
Interface exposure is classified as follows:
- Unused Interfaces:
  - Definition: The physical status of the interface is Down, but the administrative status is not shutdown.
  - Recommended security hardening operation: Set the interface management status to shutdown.
- IP management interface exposure:
  - Definition: The interface has an IP management layer interface configured for local access.
  - Recommended security hardening operation: If the address does not have service requirements, delete the management interface. If the address meets service requirements, check and set the corresponding access control policy, such as ACL, is configured.
The YANG model here is defined based on [RFC8343], which the preceding interface information related to the threat surface is parsed and obtained from.
Service Exposure
Services refer to all management plane protocol functions running on devices, including SNMP, FTP, Telnet, SSH, TFTP, NTP, RADIUS, TACACS, SYSLOG, PORTAL, NETCONF, RESTCONF, SFTP, HTTP, HTTPS, and RPC.
Service exposure is classified as follows:
- Insecure protocols:
  - Definition: The protocol used by the service is insecure, such as Telnet and SNMPv2.
  - Recommended security hardening operation: Disable the service or replace the protocol with a secure one, for example, replace Telnet with SSH.
- Abnormal service IP address:
  - Definition: The service binding IP address is invalid or is not within the predefined management address range.
  - Recommended security hardening operation: Change the IP address bound to the service to a valid address and set the corresponding security policy.
- Weak service security configuration:
  - Definition: The security configuration of the corresponding service is insufficient. For example, weak algorithms or passwords are used, or ACLs are not configured.
  - Recommended security hardening operation: Modify all weak security configurations.
- Abnormal Service port:
  - Definition: It is found that the service uses an invalid, incorrect, or redundant port, or there is a port that cannot correspond to the service.
  - Recommended security hardening operations: Reconfigure all incorrect ports and disable invalid and redundant ports.
Part of the YANG model here is defined based on [RFC7317], which the preceding interface information related to the threat surface is parsed and obtained from. The other part may add new definition.
Account Exposure
To add.
Version and Vulnerability
The software version and vulnerability information directly affect the device threat surface. The any above threat surface may have specific problems in a specific version. The problems may be caused by the device itself or the third-party open-source implementation. Therefore, this information is very important for the overall analysis of the threat surface and needs to be collected and comprehensively used in real time.
"Bug Fixes and Errata", "Security Advisory"和"Optimal Software Version" use cases in [I-D.palmero-ivy-ps-almo] mention the value about collecting and untilizing these information as well.
Operation Key Points
Supports full and incremental information reporting.
Calculates the priorities of different types of exposure plane information and handles anomalies on the threat surface based on the priorities.
Supports baseline setting and comparison with the baseline to accurately detect exceptions.
Quickly collects and processes information about a large number of devices.
Security hardening policies can be automatically delivered and executed.
...
YANG Data Model for Network Element Threat Surface Management Overview
To add.
Network Element Threat Surface Management Tree Diagram
To add.
YANG Data Model for Network Element Threat Surface Management
To add.
Manageability Considerations
<Add any manageability considerations>
Security Considerations
<Add any security considerations>
IANA Considerations
<Add any IANA considerations>
References
Normative References
[IANA_YANG]

YANG Parameters
IANA
n.d.
[RFC5209]

Network Endpoint Assessment (NEA): Overview and Requirements
P. Sangster
H. Khosravi
M. Mani
K. Narayan
J. Tardo
June 2008
RFC 5209
DOI 10.17487/RFC5209
[RFC8248]

Security Automation and Continuous Monitoring (SACM) Requirements
N. Cam-Winget
L. Lorenzin
September 2017
RFC 8248
DOI 10.17487/RFC8248
[RFC7950]

The YANG 1.1 Data Modeling Language
M. Bjorklund, Ed.
August 2016
RFC 7950
DOI 10.17487/RFC7950
[RFC6241]

Network Configuration Protocol (NETCONF)
R. Enns, Ed.
M. Bjorklund, Ed.
J. Schoenwaelder, Ed.
A. Bierman, Ed.
June 2011
RFC 6241
DOI 10.17487/RFC6241
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC8340]

YANG Tree Diagrams
M. Bjorklund
L. Berger, Ed.
March 2018
BCP 215
RFC 8340
DOI 10.17487/RFC8340
[RFC6991]

Common YANG Data Types
J. Schoenwaelder, Ed.
July 2013
RFC 6991
DOI 10.17487/RFC6991
[RFC8343]

A YANG Data Model for Interface Management
M. Bjorklund
March 2018
RFC 8343
DOI 10.17487/RFC8343
[RFC7317]

A YANG Data Model for System Management
A. Bierman
M. Bjorklund
August 2014
RFC 7317
DOI 10.17487/RFC7317
Informative References
[RFC9472]

A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information
E. Lear
S. Rose
October 2023
RFC 9472
DOI 10.17487/RFC9472
[I-D.ietf-opsawg-mud-tls]

Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices
Tirumaleswar Reddy.K
Nokia
Dan Wing
Citrix Systems, Inc.
Blake Anderson
Cisco Systems, Inc.
23 August 2024
Internet-Draft draft-ietf-opsawg-mud-tls-18
[I-D.palmero-ivy-ps-almo]

Asset Lifecycle Management and Operations: A Problem Statement
Marisol Palmero
Cisco Systems
Frank Brockners
Cisco Systems
Sudhendu Kumar
NC State University
Camilo Cardona
NTT
Diego Lopez
Telefonica I+D
8 July 2024
Internet-Draft draft-palmero-ivy-ps-almo-02
Acknowledgments
This document was prepared using kramdown.