]> China Southern Power Grid

huff@csg.cn

China Southern Power Grid

huangyu@csg.cn

Huawei Technologies

ray.yanlei@huawei.com

OPS opsawg YANG Node Tags Security Configuration Check 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.

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. In the past, the IETF has existing work on security posture definition, collection, and assessment, including the concluded Network Endpoint Assessment (NEA) and Security Automation and Continuous Monitoring (SACM) working groups . The security configuration benchmark of the management plane 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.

Terminology

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 when, and only when, they appear in all capitals, as shown here.

Tree Diagrams The meaning of the symbols in this diagram is defined in .

Categorization of Security Configurations depicts the categorization of the security configuration check:

Categorization of Security Configuration Check

The security configuration check is categorized into weak algorithms, insecure protocols, insecure feature status, short key length and unchanged default settings.

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 , the algorithms supported by TLS can be retrieved with NETCONF 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 as the following example: ds:operational ]]>

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: Common Protocols and Their YANG Models

Protocols	YANG models
TLS/DTLS
SNMP
SSH
IPsec
HTTP
TCP
UDP

Take SNMP as an example. With the existing definitions of a YANG data model for SNMP configuration , the protocol version of SNMP can be retrieved with NETCONF 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 as the following example: ds:operational ]]>

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
  • 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: 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 Subtree Filtering mechanism for configuration information collection. The feature status information can be retrieved with NETCONF 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 as the following example: ds:operational ]]>

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: 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 Subtree Filtering mechanism for configuration information collection. The key length information can be retrieved with NETCONF 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 as the following example: ds:operational ]]>

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: 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 Subtree Filtering mechanism for configuration information collection. The default setting information can be retrieved with NETCONF 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 as the following example: ds:operational ]]>

YANG Data Model for Security Configuration Check

Security Considerations

IANA Considerations

References Normative References This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document defines a collection of YANG definitions for configuring SNMP engines. This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module. The three IETF modules are "ietf-tls-common", "ietf-tls-client", and "ietf-tls-server". The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers. The IANA module is "iana-tls-cipher-suite-algs". This module defines YANG enumerations that provide support for an IANA-maintained algorithm registry. This document presents three IETF-defined YANG modules and a script used to create four supporting IANA modules. The three IETF modules are ietf-ssh-common, ietf-ssh-client, and ietf-ssh-server. The "ietf-ssh-client" and "ietf-ssh-server" modules are the primary productions of this work, supporting the configuration and monitoring of Secure Shell (SSH) clients and servers. The four IANA modules are iana-ssh-encryption-algs, iana-ssh-key-exchange-algs, iana-ssh-mac-algs, and iana-ssh-public-key-algs. These modules each define YANG enumerations providing support for an IANA-maintained algorithm registry. This document specifies a minimal YANG data model for TCP on devices that are configured and managed by network management protocols. The YANG data model defines a container for all TCP connections and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342). This document describes how to provide IPsec-based flow protection (integrity and confidentiality) by means of an Interface to Network Security Function (I2NSF) Controller. It considers two main well-known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSF Controller to one or several flow-based Network Security Functions (NSFs) that rely on IPsec to protect data traffic. This document focuses on the I2NSF NSF-Facing Interface by providing YANG data models for configuring the IPsec databases, namely Security Policy Database (SPD), Security Association Database (SAD), Peer Authorization Database (PAD), and Internet Key Exchange Version 2 (IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. This memo provides information for the Internet community. This document defines the scope and set of requirements for the Security Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Huawei Huawei Fraunhofer SIT This document provides security baseline for network device management plane, which is represented by YANG data model. The corresponding configuration values and status values of the YANG data model can be transported between Security Automation and Continuous Monitoring (SACM) components and used for network device security posture assessment. Watsen Networks This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Support is provided for HTTP/1.1, HTTP/2, and HTTP/3. INSA-Lyon INSA-Lyon Watsen Networks This document defines two YANG 1.1 modules to support the configuration of UDP clients and UDP servers.

Acknowledgements

Contributors Xubin LIN
China Southern Power Grid
linxb2@csg.cn