Network Working Group F. Hu Internet-Draft D. Hong Intended status: Standards Track China Southern Power Grid Expires: 5 September 2024 L. Xia Huawei Technologies 4 March 2024 A YANG Data Model for Network Element Threat Surface Management draft-hu-network-element-tsm-yang-00 Abstract This document defines a base YANG data model for network element threat surface management that is application- and technology- agnostic. Status of This Memo 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 5 September 2024. Copyright Notice Copyright (c) 2024 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. Hu, et al. Expires 5 September 2024 [Page 1] Internet-Draft Network Element TSM YANG March 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology and Notations . . . . . . . . . . . . . . . . 4 1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Prefix in Data Node Names . . . . . . . . . . . . . . . . 5 2. Definition of Threat Surface . . . . . . . . . . . . . . . . 6 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Interface Exposure . . . . . . . . . . . . . . . . . . . 6 2.3. Service Exposure . . . . . . . . . . . . . . . . . . . . 7 2.4. Account Exposure . . . . . . . . . . . . . . . . . . . . 8 2.5. Version and Vulnerability . . . . . . . . . . . . . . . . 8 2.6. Operation Key Points . . . . . . . . . . . . . . . . . . 8 3. YANG Data Model for Network Element Threat Surface Management Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Network Element Threat Surface Management Tree Diagram . . . 9 5. YANG Data Model for Network Element Threat Surface Management . . . . . . . . . . . . . . . . . . . . . . . 9 6. Manageability Considerations . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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, and its essence is basically the same as External Attack Surface Management (EASM) proposed by Gartner in recent years. Gartner https://www.gartner.com/reviews/market/external-attack-surface- Hu, et al. Expires 5 September 2024 [Page 2] Internet-Draft Network Element TSM YANG March 2024 management defines EASM 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. Hu, et al. Expires 5 September 2024 [Page 3] Internet-Draft Network Element TSM YANG March 2024 * 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. 1.1. 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: Hu, et al. Expires 5 September 2024 [Page 4] Internet-Draft Network Element TSM YANG March 2024 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 1.2. 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. 1.3. Tree Diagram The meaning of the symbols in this diagram is defined in [RFC8340]. 1.4. 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. +========+========================+=============+ | 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 | +--------+------------------------+-------------+ Table 1: Prefixes and corresponding YANG modules RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please remove this note. Hu, et al. Expires 5 September 2024 [Page 5] Internet-Draft Network Element TSM YANG March 2024 2. Definition of Threat Surface 2.1. Overview Figure 1 depicts the overall framework of the network element threat surface management: +------------------+ | Threat Surface | +--------+---------+ | +-------------+----+-------+------------+ | | | | | | | | | | | | | | | | +----v----+ +-----v---+ +-----v---+ +------v------+ |Interface| | Service | | Account | | Version & | |Exposure | |Exposure | |Exposure | |Vulnerability| +---------+ +---------+ +---------+ +-------------+ Figure 1: Network Element Threat Surface Management Framework 2.2. 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. Hu, et al. Expires 5 September 2024 [Page 6] Internet-Draft Network Element TSM YANG March 2024 - 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. 2.3. 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: Hu, et al. Expires 5 September 2024 [Page 7] Internet-Draft Network Element TSM YANG March 2024 - 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. 2.4. Account Exposure To add. 2.5. 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. 2.6. 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. ... Hu, et al. Expires 5 September 2024 [Page 8] Internet-Draft Network Element TSM YANG March 2024 3. YANG Data Model for Network Element Threat Surface Management Overview To add. 4. Network Element Threat Surface Management Tree Diagram To add. 5. YANG Data Model for Network Element Threat Surface Management To add. 6. Manageability Considerations 7. Security Considerations 8. IANA Considerations 9. References 9.1. Normative References [IANA_YANG] IANA, "YANG Parameters", n.d., . [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, . [RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", RFC 8248, DOI 10.17487/RFC8248, September 2017, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . Hu, et al. Expires 5 September 2024 [Page 9] Internet-Draft Network Element TSM YANG March 2024 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for System Management", RFC 7317, DOI 10.17487/RFC7317, August 2014, . 9.2. Informative References [RFC9472] Lear, E. and S. Rose, "A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information", RFC 9472, DOI 10.17487/RFC9472, October 2023, . [I-D.ietf-opsawg-mud-tls] Reddy.K, T., Wing, D., and B. Anderson, "Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices", Work in Progress, Internet-Draft, draft-ietf-opsawg-mud- tls-13, 23 January 2024, . [I-D.palmero-ivy-ps-almo] Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D. Lopez, "Asset Lifecycle Management and Operations: A Hu, et al. Expires 5 September 2024 [Page 10] Internet-Draft Network Element TSM YANG March 2024 Problem Statement", Work in Progress, Internet-Draft, draft-palmero-ivy-ps-almo-00, 20 October 2023, . Appendix A. Acknowledgments This document was prepared using kramdown. Authors' Addresses Feifei Hu China Southern Power Grid Email: huff@csg.cn Danke Hong China Southern Power Grid Email: hongdk@csg.cn Liang Xia Huawei Technologies Email: frank.xialiang@huawei.com Hu, et al. Expires 5 September 2024 [Page 11]