]> China Southern Power Grid

huff@csg.cn

China Southern Power Grid

hongdk@csg.cn

Huawei Technologies

frank.xialiang@huawei.com

Operations and Management Area Working Group This document defines a base YANG data model for network element threat surface management that is application- and technology-agnostic.

Introduction With more and more advanced network attacks on network infrastructures, one important thing of network device security management is to increase the security visibility. To achieve this, on the one hand, the device normal security posture should be defined in advance, so that the abnormal security status or operation of the device can be identified timely. On the other hand, from the attacker perspective, how to comprehensively define the threat surface of device, and manage potential risks through timely monitoring is becoming vital. Network element threat surface management has a similar concept as 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.". Comparing with EASM as a larger system and methodology, this document presents a specific implementation for network device threat surface management. Furthermore, the difference between the threat surface and attack surface is clarified briefly here: The threat surface may not have vulnerabilities or be an attack surface. However, it is exposed to the attackers and faces threats from them. Therefore, its security risk is high. However, the attack surface can be accessed by attackers 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 with corresponding attack vectors will become an attack surface. In the past, the IETF has existing work about security posture definition, collection, and assessment, including the concluded Network Endpoint Assessment (NEA) and Security Automation and Continuous Monitoring (SACM) working groups . They have mainly finished the standard definition of general use cases and requirements, architecture and communication protocols, and software inventory attribute definition and so on. 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 , are all aiming to propose the specific security posture model definition. Similarly, this document proposes the device threat surface YANG model. of this document defines the basic framework of the threat surface management. 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 interface exposure:
  • Definition: The interface has the IP (including primary and secondary IP addresses) configured for local access.
  • Recommended security hardening operation: If the address does not have service requirements, delete the management interface. Otherwise, check and set the corresponding access control policy, such as ACL, is configured.

With the existing definitions of A YANG Data Model for Interface Management and A YANG Data Model for IP Management , the interface exposure information can be retrieved with NETCONF Subtree Filtering mechanism as following example: ds:operational

]]> In addition, the realtime change of the above information can be notified on time with NETCONF pub/sub mechanisms as following examples: ds:operational

]]>

Service Exposure Here, services refer to the corresponding protocols 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.

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. With the existing definitions of A YANG Data Model for Network Inventory , the version and vulnerability information can be retrieved with NETCONF Subtree Filtering mechanism as following example: ds:operational ]]>

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 management of IP implementations. The data model includes configuration and system state. The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document obsoletes RFC 7277. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. 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. Huawei Technologies Nokia Vodafone TIM Cisco This document defines a base YANG data model for network inventory that is application- and technology-agnostic. This data model can be augmented with application-specific and technology-specific details in other, more specific network inventory data models.

Acknowledgments This document was prepared using kramdown.