Internet DRAFT - draft-hu-network-element-tsm-yang
draft-hu-network-element-tsm-yang
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
<Add any manageability considerations>
7. Security Considerations
<Add any security considerations>
8. IANA Considerations
<Add any IANA considerations>
9. References
9.1. Normative References
[IANA_YANG]
IANA, "YANG Parameters", n.d.,
<https://www.iana.org/assignments/yang-parameters>.
[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,
<https://www.rfc-editor.org/info/rfc5209>.
[RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and
Continuous Monitoring (SACM) Requirements", RFC 8248,
DOI 10.17487/RFC8248, September 2017,
<https://www.rfc-editor.org/info/rfc8248>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
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,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>.
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, <https://www.rfc-editor.org/info/rfc9472>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
mud-tls-13>.
[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,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
ps-almo-00>.
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]
