| Internet-Draft | Network Element TSM YANG | September 2024 |
| Hu, et al. | Expires 22 March 2025 | [Page] |
This document defines a base YANG data model for network element threat surface management that is application- and technology-agnostic.¶
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 22 March 2025.¶
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.¶
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.¶
The following terms are defined in [RFC7950] and are not redefined here:¶
The following terms are defined in [RFC6241] and are not redefined here:¶
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¶
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.¶
The meaning of the symbols in this diagram is defined in [RFC8340].¶
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 |
RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. Please remove this note.¶
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|
+---------+ +---------+ +---------+ +-------------+
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:¶
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.¶
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:¶
Abnormal service IP address:¶
Weak service security configuration:¶
Abnormal Service port:¶
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.¶
To add.¶
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.¶
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.¶
...¶
<Add any manageability considerations>¶
<Add any security considerations>¶
<Add any IANA considerations>¶
This document was prepared using kramdown.¶