opsawg F. Hu Internet-Draft Y. Huang Intended status: Standards Track China Southern Power Grid Expires: 24 April 2025 L. Yan Huawei Technologies 21 October 2024 YANG Data Models for Security Configuration Check draft-hu-opsawg-sec-config-yang-00 Abstract Security configuration refers to the status setting of product security features/functions to reduce network security risks during product use. This document defines YANG data models for the security configuration check. 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 24 April 2025. 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 24 April 2025 [Page 1] Internet-Draft YANG Data Models for Security Configurat October 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Categorization of Security Configurations . . . . . . . . . . 3 2.1. Weak Algorithms . . . . . . . . . . . . . . . . . . . . . 4 2.2. Insecure Protocols . . . . . . . . . . . . . . . . . . . 5 2.3. Insecure Features Status . . . . . . . . . . . . . . . . 7 2.4. Short Key length . . . . . . . . . . . . . . . . . . . . 10 2.5. Unchanged Default Settings . . . . . . . . . . . . . . . 12 3. YANG Data Model for Security Configuration Check . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Weak or incorrect configurations are the main factors of network insecurity. Insecure configurations can be exploited to easily launch a network intrusion by attackers. It is reported that more than 95 per cent of the attacks are successful because of missing software updates or bad system configurations. The top 3 high-risk configuration items are default password, unnecessary opened ports, and insecure protocol or algorithm. The default accounts and passwords make it easy for attackers to guess and successfully access the network. The unnecessary opened ports increase the exposed surface of the attack. Although security protocols can improve security, using known vulnerable algorithms or protocol versions will greatly reduce the attack difficulty. Security configuration checks can reduce network security risks during the usage of devices. The first step of the security configuration check is to collect security configuration information from devices. Then, the value of the collected configuration item will be compared with the security configuration benchmark to determine whether the configuration item is secure. The security configuration benchmark is the recommended value of the configuration item to ensure basic device security. Hu, et al. Expires 24 April 2025 [Page 2] Internet-Draft YANG Data Models for Security Configurat October 2024 In the past, the IETF has existing work on security posture definition, collection, and assessment, including the concluded Network Endpoint Assessment (NEA)[RFC5209] and Security Automation and Continuous Monitoring (SACM) working groups [RFC8248]. The security configuration benchmark of the management plane [I-D.lin-sacm-nid-mp-security-baseline] has been defined in SACM. This document focuses on the first step of the security configuration check and defines YANG data models for security configurations to be collected. In this document, the security configuration check will be categorized first. Second, the YANG data models will be built according to the categories. 1.1. Terminology 1.2. Requirements Language 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 Diagrams The meaning of the symbols in this diagram is defined in [RFC8340]. 2. Categorization of Security Configurations Figure 1 depicts the categorization of the security configuration check: +-----------------------------+ | Security Configuration Check| +---------------+-------------+ | +-------------+------------+-----------+-----------+ | | | | | | | | | | | | | | | +-----v-----+ +-----v----+ +-----v----+ +----v---+ +-----v-----+ | Weak | | Insecure | | Insecure | | Short | | Unchanged | | Algorithm | | Protocol | | Features | | Key | | Default | +-----------+ +----------+ | Status | | Length | | Settings | +----------+ +--------+ +-----------+ Figure 1: Categorization of Security Configuration Check Hu, et al. Expires 24 April 2025 [Page 3] Internet-Draft YANG Data Models for Security Configurat October 2024 The security configuration check is categorized into weak algorithms, insecure protocols, insecure feature status, short key length and unchanged default settings. 2.1. Weak Algorithms Here, algorithms refer to any algorithms used in any softwares or protocols for security purpose, such as key exchange, encryption, signature, and integrity check. The weak algorithms are the algorithms that is considered insecure, such as MD5, 3DES. Take TLS as an example, security algorithms used in TLS are called cipher-suites. With the existing definitions of YANG Groupings for TLS Clients and TLS Servers [RFC9645], the algorithms supported by TLS can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example: ds:operational In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example: Hu, et al. Expires 24 April 2025 [Page 4] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational 2.2. Insecure Protocols Here, protocols refer to any protocol used in a device for the communication to any other devices in any layers. Insecure protocols can be the protocol without security mechanisms, such as TCP and HTTP, or the older version of the protocols, such as TLSv1.1 and SNMPv1. Common Protocols and their YANG models are listed as follows: Hu, et al. Expires 24 April 2025 [Page 5] Internet-Draft YANG Data Models for Security Configurat October 2024 +===========+=======================================+ | Protocols | YANG models | +===========+=======================================+ | TLS/DTLS | [RFC9645] | +-----------+---------------------------------------+ | SNMP | [RFC7407] | +-----------+---------------------------------------+ | SSH | [RFC9644] | +-----------+---------------------------------------+ | IPsec | [RFC9061] | +-----------+---------------------------------------+ | HTTP | [I-D.ietf-netconf-http-client-server] | +-----------+---------------------------------------+ | TCP | [RFC9648] | +-----------+---------------------------------------+ | UDP | [I-D.ietf-netconf-udp-client-server] | +-----------+---------------------------------------+ Table 1: Common Protocols and Their YANG Models Take SNMP as an example. With the existing definitions of a YANG data model for SNMP configuration [RFC7407], the protocol version of SNMP can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example: ds:operational In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example: Hu, et al. Expires 24 April 2025 [Page 6] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational 2.3. Insecure Features Status Security features include security functions and configurations. Insecure features are classified as follows: * all interfaces listening * all interfaces binding * unconfigured security configurations - unconfigured ACL hardening - unconfigured keys - unconfigured passwords - unconfigured timeout period * disabled security functions - disabled account locking - disabled certificate verification Hu, et al. Expires 24 April 2025 [Page 7] Internet-Draft YANG Data Models for Security Configurat October 2024 - disabled allowlitst - disabled blocklist - disabled encryption function - disabled authentication function - disabled security protocol Listening or binding all interfaces may cause the exposed attack surface to increase. Setting the security configurations and enabling the security functions will enhance the device's security. The submodule "ietf-security-config-features", which defines the configuration parameters of security features, has the following structure: submodule: ietf-security-config-features +--rw security cofig +--rw security features* [name] +--rw id? unit64 +--rw name string +--rw description? string +--rw status boolean The "status" true means the security feature is enabled or configured, and false means the security feature is disabled or unconfigured. The submodel "ietf-security-config-features" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The feature status information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example: Hu, et al. Expires 24 April 2025 [Page 8] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example: Hu, et al. Expires 24 April 2025 [Page 9] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational 2.4. Short Key length Short Key length means the key is not long enough to meet the security requirement. The submodule "ietf-security-config-key", which defines configuration parameters of key length, has the following structure: submodule: ietf-security-config-key +--rw security cofig +--rw key* [key id] +--rw key id unit64 +--rw usage? string +--rw length unit64 The "usage" describes the key is used by which algorithm of which protocol or software. The submodel "ietf-security-config-key" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The key length information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example: Hu, et al. Expires 24 April 2025 [Page 10] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example: Hu, et al. Expires 24 April 2025 [Page 11] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational 2.5. Unchanged Default Settings Default settings required to be changed include the default security- related configurations set by manufacturers and the default port defined by protocols. Unchanged default settings are classified as follows: * Unchanged default certificates * Unchanged default PKI domains * Unchanged default keys * Unchanged default ports Using the default certificates, PKI domains, or keys set by manufacturers may have a risk of being cracked. Using the default port number of a protocol may cause being sniffed and monitored. The submodule "ietf-security-config-default-settings", which defines configuration parameters of default settings, has the following structure: Hu, et al. Expires 24 April 2025 [Page 12] Internet-Draft YANG Data Models for Security Configurat October 2024 submodule: ietf-security-config-default-settings +--rw security cofig +--rw default settings* [name] +--rw type enumeration {certificates, PKI domains, keys, ports} +--rw id? unit64 +--rw name string +--rw description? string +--rw changed boolean The "changed" true means the default setting has been changed, and false means unchanged. The submodel "ietf-security-config-default-settings" can be used with NETCONF [RFC6241] Subtree Filtering mechanism for configuration information collection. The default setting information can be retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the following example: ds:operational In addition, the real-time change of the above information can be notified on time with NETCONF pub/sub mechanisms [RFC8641] as the following example: Hu, et al. Expires 24 April 2025 [Page 13] Internet-Draft YANG Data Models for Security Configurat October 2024 ds:operational 3. YANG Data Model for Security Configuration Check 4. Security Considerations 5. IANA Considerations 6. References 6.1. Normative References [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [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, . Hu, et al. Expires 24 April 2025 [Page 14] Internet-Draft YANG Data Models for Security Configurat October 2024 [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, December 2014, . [RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024, . [RFC9644] Watsen, K., "YANG Groupings for SSH Clients and SSH Servers", RFC 9644, DOI 10.17487/RFC9644, October 2024, . [RFC9648] Scharf, M., Jethanandani, M., and V. Murgai, "YANG Data Model for TCP", RFC 9648, DOI 10.17487/RFC9648, October 2024, . [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, July 2021, . [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, . 6.2. Informative References [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, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . Hu, et al. Expires 24 April 2025 [Page 15] Internet-Draft YANG Data Models for Security Configurat October 2024 [I-D.lin-sacm-nid-mp-security-baseline] Lin, Q., Xia, L., and H. Birkholz, "The Data Model of Network Infrastructure Device Management Plane Security Baseline", Work in Progress, Internet-Draft, draft-lin- sacm-nid-mp-security-baseline-04, 22 October 2018, . [I-D.ietf-netconf-http-client-server] Watsen, K., "YANG Groupings for HTTP Clients and HTTP Servers", Work in Progress, Internet-Draft, draft-ietf- netconf-http-client-server-23, 15 August 2024, . [I-D.ietf-netconf-udp-client-server] Feng, A. H., Francois, P., and K. Watsen, "YANG Groupings for UDP Clients and UDP Servers", Work in Progress, Internet-Draft, draft-ietf-netconf-udp-client-server-05, 17 October 2024, . Acknowledgements Contributors Xubin LIN China Southern Power Grid linxb2@csg.cn Authors' Addresses Feifei HU China Southern Power Grid Email: huff@csg.cn Yu HUANG China Southern Power Grid Email: huangyu@csg.cn Lei YAN Huawei Technologies Email: ray.yanlei@huawei.com Hu, et al. Expires 24 April 2025 [Page 16]