| Internet-Draft | Network Element TSM YANG | September 2024 |
| Hu, et al. | Expires 3 April 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 3 April 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.¶
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 [RFC5209][RFC8248]. 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 [RFC9472], and the extended MUD YANG model for (D)TLS profiles for IoT devices proposed in [I-D.ietf-opsawg-mud-tls], are all aiming to propose the specific security posture model definition. Similarly, this document proposes the device threat surface YANG model.¶
Section 2 of this document defines the basic framework of the threat surface management.¶
Based on the above definitions, Section 3 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 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 [RFC8343] and A YANG Data Model for IP Management [RFC8344], the interface exposure information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as following example:¶
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name/>
<type/>
<enabled/>
<oper-status/>
<admin-status/>
<if-index/>
<phys-address/>
<ipv4>
<address/>
</ipv4>
<ipv6>
<address/>
</ipv6>
</interface>
</interfaces>
</subtree-filter>
</get-data>
</rpc>
¶
In addition, the realtime change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8639][RFC8640][RFC8641] as following examples:¶
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
<interface>
<name/>
<type/>
<enabled/>
<oper-status/>
<admin-status/>
<if-index/>
<phys-address/>
<ipv4>
<address/>
</ipv4>
<ipv6>
<address/>
</ipv6>
</interface>
</interfaces>
</interfaces>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
¶
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:¶
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.¶
With the existing definitions of A YANG Data Model for Network Inventory [I-D.ietf-ivy-network-inventory-yang], the version and vulnerability information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as following example:¶
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
<get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<network-inventory
xmlns="urn:ietf:params:xml:ns:yang:ietf-network-inventory">
<network-elements>
<network-element>
<ne-id/>
<ne-type/>
<name/>
<hardware-rev/>
<software-rev/>
<software-patch-rev/>
<product-name/>
<components>
<component>
<component-id/>
<name/>
<hardware-rev/>
<software-rev/>
<software-patch-rev/>
<product-name/>
</component>
</components>
</network-element>
</network-elements>
</network-inventory>
</subtree-filter>
</get-data>
</rpc>
¶
<Add any manageability considerations>¶
<Add any security considerations>¶
<Add any IANA considerations>¶
This document was prepared using kramdown.¶