]> China Southern Power Grid

huff@csg.cn

China Southern Power Grid

hongdk@csg.cn

Huawei Technologies

frank.xialiang@huawei.com

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 . 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 , and the extended MUD YANG model for (D)TLS profiles for IoT devices proposed in , seems as the continuation of the definition of the specific security posture model. 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, of this document defines the YANG model for the device threat surface management.

Terminology and Notations The following terms are defined in and are not redefined here:

• client
• server
• augment
• data model
• data node

The following terms are defined in and are not redefined here:

• configuration data
• state data

The terminology for describing YANG data models is found in . 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 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 .

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
yang	ietf-yang-types
ianahw	iana-hardware
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 depicts the overall framework of the network element threat surface management:

Network Element Threat Surface Management Framework

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 , 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 , 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 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 n.d. This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community. This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 7223. This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. Informative References To improve cybersecurity posture, automation is necessary to locate the software a device is using, whether that software has known vulnerabilities, and what, if any, recommendations suppliers may have. This memo extends the Manufacturer User Description (MUD) YANG schema to provide the locations of software bills of materials (SBOMs) and vulnerability information by introducing a transparency schema. Nokia Citrix Systems, Inc. Cisco Systems, Inc. This memo extends the Manufacturer Usage Description (MUD) specification to allow manufacturers to define (D)TLS profile parameters. This allows a network security service to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software, malware, or security policy-violating traffic on an endpoint. Cisco Systems Cisco Systems NC State University NTT Telefonica I+D This document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model. The primary objective for this problem statement document is to validate and prove that the framework can measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset.

Acknowledgments This document was prepared using kramdown.