A YANG Data Model for Network Element Threat Surface Management
draft-hu-network-element-tsm-yang-00

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]