The Data Model of Network Infrastructure Device Management Plane Security Baseline
draft-lin-sacm-nid-mp-security-baseline-02

Abstract

This document provides security baseline for network infrastructure device management plane, which is represented by YANG data model. The corresponding values of this YANG data model can be transported between Security Automation and Continuous Monitoring (SACM) components and used for network infrastructure device security evaluation.

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 September 2, 2018.

Copyright Notice

Copyright (c) 2018 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Terminology
• 4. Tree Diagrams
• 5. Data Model Structure
• 5.1. Administrator Account Management Security
• 5.1.1. Administrator Account Configuration Security
• 5.1.2. Administrator Login Security
• 5.1.3. AAA Configuration Security
• 5.1.4. Administrator Access Statistics
• 5.2. System Management Security
• 5.2.1. SNMP Management Security
• 5.2.2. NETCONF Management Security
• 5.2.3. Port Management Security
• 5.3. Log Security
• 5.4. File Security
• 6. Network Infrastructure Device Security Baseline Yang Module
• 7. Acknowledgements
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A.
• Authors' Addresses

1. Introduction

Besides user devices and servers, network infrastructure devices such as routers, switches, and firewalls are crucial to enterprise network security. Security baseline provides a minimal set of security requirements that are essential to protect enterprise network. The security baseline and organization specific requirements can then be used to assess the security posture of network infrastructure devices.

In order to address threats and attacks to network infrastructure devices, different security functions and configurations are implemented in application layer, network layer and infrastructure layer. Network layer is typically categorized into three planes of operation: management plane, control plane and data plane. All the planes should be protected and monitored to provide network security.

This document focuses on security baseline for network infrastructure device management plane. Management plane provides configuration and monitoring services to network administrator or device owner. Unauthorized access, insecure access channels, weak cryptographic algorithms are common security issues that break management plane security. Security configuration and monitoring should be implemented to ensure proper control of network infrastructure devices. A number of security best practices have been proposed, such as disabling unused services and ports, discarding insecure access channels, and enforcing strong user authentication and authorization. In this document, we propose a minimal set of configuration and status requirements that are expected to be widely applicable to common network infrastructure devices. Additional requirements can be supported by specific vendors. Thus interoperability and extensibility can be achieved.

Interface to Network Security Functions (I2NSF) working group provides standard interfaces for controlling and monitoring NSFs, the work of this document is different from that of I2NSF working group. The main differences include:

• I2NSF focuses on flow-based NSFs, while this document works on network infrastructure devices (physical or virtual) including routing and forwarding devices as well as network security devices.
• I2NSF focuses on the provision and monitor of I2NSF policy rules for flow-based NSFs, while this document doesn't work on the functional configuration of NSFs policy rules. This document focuses on security configuration of account management, system management protocols, system ports, log, and local file system to provide operation security. For example, configuration of firewall rules is out of scope, but the configuration of ACL rules for remote access administrator is considered in this document.

YANG data model is used in this document to model the security baseline for network infrastructure device management plane. [I-D.birkholz-sacm-yang-content] defines a method of constructing the YANG data model scheme for the security posture assessment of the network infrastructure device by brokering of YANG push telemetry via SACM statements. In this document, we follow the same way to define the YANG output for network infrastructure device security posture based on the [I-D.ietf-sacm-information-model].

Besides management plane security baseline, the security baselines for control plane, data plane, and infrastructure layer of network infrastructure devices are described in [I-D.dong-sacm-nid-cp-security-baseline], [I-D.xia-sacm-nid-dp-security-baseline] and [I-D.dong-sacm-nid-infra-security-baseline] respectively.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Terminology

This document uses the terms defined in [RFC6020].

4. Tree Diagrams

Tree diagram defined in [I-D.ietf-netmod-yang-tree-diagrams] is used to represent the YANG data model of network infrastructure device management plane security. The meaning of the symbols used in the tree diagram and the syntax are as follows:

• A module is identified by "module:" followed the module-name. The top-level data nodes defined in the module, offset by 2 spaces. Submodules are represented in the same fashion as modules, but are identified by "submodule:" followed the (sub)module-name.
• Groupings, offset by 2 spaces, and identified by the keyword "grouping" followed by the name of the grouping and a colon (":") character.
• Each node in the tree is prefaces with "+--". Schema nodes that are children of another node are offset from the parent by 3 spaces.
• Brackets "[" and "]" enclose list keys.
• Abbreviations before data node names: "rw" means configuration (read-write) and "ro" means state data (read-only), "x" is used to mark rpcs and actions, "w" denotes the input parameters to rpcs and actions, and "u" indicates the use of a predefined grouping.
• Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a "list" and "leaf-list".
• Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
• Ellipsis ("...") stands for contents of subtrees that are not shown.
• Curly brackets and a question mark "{...}?" are combined to represent the features that node depends on.

5. Data Model Structure

This document focuses on network infrastructure device management plane security, including security of account management, system management protocols, sytem ports, log, and local file system. Both security configuration and runtime state of security controls are taken into consideration. Four submodules will be illustrated in the following sections to represent the security baseline for:

• Administrator account management security
• System management protocol security and port management security
• Log security
• Local file system security

There exists a multitude of YANG models for network devices and network protocols. For management plane security, several RFCs and drafts has defined some related parts. But an overall data model of management plane security is still missing. Moreover, the related data models may only focus on part of the security functions. Besides defining new YANG models or groupings, the following sections will also reuse the existing YANG models and provide additional attributes or groupings for the missing parts. Appendix A provides a summary of existing YANG models and the relationship to the security baseline defined in this document.

5.1. Administrator Account Management Security

The "admin-account-management-security" submodule is divided into four parts:

submodule: admin-account-management-security
  +--rw admin-account-management-security
     +--rw admin-account-config-security
     +--rw admin-login-security
     +--rw aaa-config-security
     +--rw admin-access-statistics
		

5.1.1. Administrator Account Configuration Security

In order to provide basic protection of administrator accounts, configuration requirements on account names and passwords should be applied. The commonly applied security controls includes: the account name should not be too short, the password should contain multiple types of characters, password should be resetted after a period of time, the new password should be different with the past one, etc. The following data model illustrates these kinds of security controls.

  +--rw admin-account-config-security
     +--rw account-name-requirement!
     |  +--rw account-name-min-length            uint8
     +--rw account-password-requirement!
     |  +--rw password-min-length                uint8
     |  +--rw password-expire-days               uint16
     |  +--rw password-complexity-check?
     |     +--rw password-character?
     |     |  +--rw password-character-type      enumeration
     |     |  +--rw password-character-min-type  uint8
     |     +--rw check-past-password?
     |     |  +--rw past-times                   uint8 
     |     +--rw check-account-name?             boolean 
      +--rw account-password-encryption          identityref		
			

5.1.2. Administrator Login Security

Network infrastructure devices typically can be managed through command line interface (CLI) or web user interface. The web user interface provides basic maintenance and management functions. Sometimes an administrator still needs to use the CLI to implement complex or fine-grained management. If insecure access channels have to be used, several security controls should be enforced.

  +--rw admin-login-security
     +--rw (user-interface-type)
        +--:(console)
        |  +--rw console-authen-mode           identityref
        |  +--rw console-user-level            uint8
        +--:(vty)
        |  +--rw vty* [vty-number]
        |  +--rw vty-number                    uint8
        |  +--rw vty-user-authen-mode          identityref
        |  +--rw vty-user-level                uint8
        |  +--rw (service-type)
        |     +--:(telnet)
        |     |  +--rw telnet-enable           boolean
        |     |  +--rw telnet-server-source?   uint16
        |     |  +--rw telnet-server-port      inet:port-number
        |     |  +--rw telnet-timeout?         uint16
        |     |  +--u common-security-policy
        |     +--:(ssh)
        |        +--rw ssh-enable              boolean
        |        +--u ssh-server-grouping 
        |                   [I-D.ietf-netconf-ssh-client-server]
        |        +--u ssh-server-security-hardening
        |        +--u common-security-policy
        +--:(web)
           +--rw web-authen-mode               identityref
           +--rw web-user-level                uint8
           +--rw http-server-source            uint16		
           +--rw https-ipv4-enable             boolean		
           +--rw https-ipv6-enable             boolean
           +--rw https-source-port             inet:port-number		
           +--rw https-timeout                 uint16
           +--u common-security-policy 
           +--u tls-server-grouping	   
                           [I-D.ietf-netconf-tls-client-server]
		   

The structure of "ssh-server-security-hardening" is:

grouping ssh-server-security-hardening:
  +--rw ssh-authen-mode*          identityref 
  +--rw ssh-dh-exchange-min-len?  uint16
  +--rw ssh-server-port?          inet:port-number
  +--rw ssh-rekey-interval?       uint16
  +--rw ssh-timeout?              uint8
  +--rw ssh-retry-times?          uint8
  +--rw ssh-compatible-ssh1x-enable  boolean
  +--rw ssh-server-source?        uint16
			

The structure of "common-security-policy" is:

grouping common-security-policy:
  +--rw authen-fail-ip-block?
  |  +--rw ip-block-enable           boolean
  |  +--rw retry-interval            uint8
  |  +--rw retry-time                uint8
  |  +--rw block-time                uint16
  |  +--ro blocked-ip*   [ip-address]
  |     +--ro ip-address             inet:host
  |     +--ro unblocked-interval     uint16
  +--rw authen-fail-account-block?
  |  +--rw account-block-enable      boolean
  |  +--rw retry-interval            uint8
  |  +--rw retry-time                uint8
  |  +--rw block-time                uint16
  |  +--ro blocked-account*   [account-name]
  |     +--ro account-name           string
  |     +--ro unblocked-interval     uint16
  +--rw ip-white-list*?              inet:host
  +--rw login-delay-enable?          boolean
  +--rw authentication-code-enable?  boolean
  +--rw acl-name-list*?              [I-D.ietf-netmod-acl-model]
			

In the above structure, several groupings are used.

• When an administrator log in to a device through SSH based service, e.g. STelnet, the device acts as a SSH server. Thus, the grouping "ssh-server-grouping" defined in [I-D.ietf-netconf-ssh-client-server] is used. This grouping only focuses on SSH-specific configuration, transport-level configuration such as what ports to listen-on is not included. Thus, configurations related to security hardening of SSH server, for example, configuration of port number and rekey interval, are added as grouping "ssh-server-security-hardening" in this document.
• When an administrator log in to a device through web interface, the device acts as a web server. Thus, the grouping "tls-server-grouping" defined in [I-D.ietf-netconf-tls-client-server] is used. This grouping also focuses on TLS-specific configuration, additional security configuration nodes are provided to augment it in this document.
• Grouping "common-security-policy" is defined to provide the re-usability of common security policy to protect the devices from password brute force attacks. Different types of security controls can be used according to different deployment scenarios and device capabilities.

5.1.3. AAA Configuration Security

Authentication, Authorization, and Accounting (AAA) provides user management for network devices. RADIUS (Remote Authentication Dial In User Service) and TACACS (Terminal Access Controller Access Control System) are the commonly used AAA mechanisms. In order to implement AAA, network infrastructure devices act as RADIUS/TACACS clients to communicate with RADIUS/TACACS servers. Configuring the connection to AAA servers and security controls should be implemented.

• RADIUS configuration security: The subtree marked with [RFC7317] uses the RADIUS server configuration subtree of RADIUS client model defined in [RFC7317]. For security hardening, enabling message authenticator and checking RADIUS attributes are illustrated. Besides, the actions that may be taken when authentication fail event or authorization check fail event happens are modelled.
• TACACS configuration security: The following subtree models the configuration of the connection to TACACS servers as well as security controls to authentication or authorization check failure.

   +--rw aaa-config-security
      +--rw (aaa-mode)
         +--:(radius)
         |  +--rw radius-server* [name]             [RFC7317]
         |  |  +--rw name                           string
         |  |  +--rw (transport)
         |  |  |  +--:(udp)
         |  |  |     +--rw address                  inet:host
         |  |  |     +--rw authentication-port?     inet:port-number
         |  |  |     +--rw shared-secret            string
         |  |  +--rw authentication-type?           identityref  
         |  +--rw message-authenticator-enable?     boolean
         |  +--rw check-radius-attribute*?          identityref		 
         |  +--rw authorization-check-fail-policy?  boolean
         |  +--rw authen-fail-policy!?
         |     +--rw retry-interval                 uint8
         |     +--rw retry-time                     uint8
         |     +--rw block-time                     uint16
         +--:(tacacs)
            +--rw tacacs-server* [name]
            |  +--rw name                           string
            |  +--rw (transport)
            |  |  +--:(tcp)
            |  |     +--rw address                  inet:host
            |  |     +--rw authentication-port?     inet:port-number
            |  |     +--rw shared-secret            string
            |  +--rw authentication-type?           identityref     
            +--rw authorization-check-fail-policy?  boolean
            +--rw authen-fail-policy!?
               +--rw retry-interval                 uint8
               +--rw retry-time                     uint8
               +--rw block-time                     uint16
			   

5.1.4. Administrator Access Statistics

The statistics of the current online administrators and the failed login attempts are useful for the monitoring of network infrastructure devices. The structure is as follows:

  +--ro admin-access-statistics
     +--ro online-admin-list
     |  +--ro total-online-users        uint8
     |  +--ro online-users* [account-name]
     |     +--ro account-name           string
     |     +--ro ip-address             inet:host
     |     +--ro mac-address            yang:mac-address
     +--ro online-fail-admin-list
        +--ro fail-users* [account-name]
           +--ro account-name           string
           +--ro ip-address             inet:host
           +--ro mac-address            yang:mac-address  	  
			

5.2. System Management Security

The "system-management-security" submodule is divided into three parts:

submodule: system-management-security
  +--rw system-management-security
     +--rw snmp-security 
     +--rw netconf-security
     +--rw port-management-security                         
		

5.2.1. SNMP Management Security

Simple Network Management Protocol (SNMP) is a network management standard to monitor network devices. Three SNMP versions are available: SNMPv1, SNMPv2c, and SNMPv3. [RFC7407] defines community-based security model for SNMPv1 and SNMPv2c, view-based access control model and user-based security model for SNMPv3. The following module reuses the subtrees defined in RFC7407 for SNMP security configuration, and only supplements ACL configuration for VACM group.

  +--rw snmp-security                [RFC7407]
     +--rw target* [name]
     |  ...
     +--rw target-params* [name]
     |  ...
     +--rw community* [index]
     |   ...
     +--rw vacm
     |   +--rw group* [name]
     |      +--rw name                 snmp:group-name
     |      +--rw access* [context security-model security-level]
     |         ...
     |         +--rw acl-name-list*    string
     +--rw usm
        ... 					
		    

5.2.2. NETCONF Management Security

The NETCONF server model defined in [I-D.ietf-netconf-netconf-client-server] supports both the SSH and TLS transport protocols. To conduct more security controls on NETCONF based operations, authorization rules can be used to control which operations can be done and which resources can be accessed.

  +--rw netconf-security
     +--rw listen {listen}?        [I-D.ietf-netconf-netconf-client-server]
     |  ...
     +--rw call-home {call-home}?  [I-D.ietf-netconf-netconf-client-server]
     |  ...			
     +--rw netconf-authorization?
        +--rw task-group-rules* [task-group-name]
        |  +--rw task-group-name             string
        |  +--rw task-group-rule*   [rule-name]
        |     +--rw rule-name                string
        |     +--rw rule-type                identityref
        +--rw user-group-rules* [user-group-name]
           +--rw user-group-name             string
           +--rw user-group-rule*   [rule-name]
              +--rw rule-name                string
              +--rw rule-type                identityref
	 

5.2.3. Port Management Security

The current status of the ports that are available on the network infrastructure devices can be retrieved and compared to the communication matrix.

  +--rw port-management-security
     +--rw port-list*  [port-number]
        +--rw port-number       inet:port-number
        +--rw port-status        boolean		
		

5.3. Log Security

To monitor the running status and diagnose faults or attacks on network infrastructure devices, the activities of network administrators, the operations conducted on devices, and the security notification of abnormal events are needed to be recorded in logs. Besides, policy should be defined to deal with log overflow. Log records can be outputted to console, or stored locally, or outputted to remote Syslog server. The following defined "log-mode" subtree reuses the security configuration of log remote transfer in [I-D.ietf-netmod-syslog-model], and adds access control for locally stored log files.

submodule: log-security
  +--rw log-security
     +--rw log-record
     |  +--rw admin-activity
     |  |  +--rw admin-online-offline      boolean
     |  |  +--rw admin-create-delete       boolean
     |  |  +--rw admin-lock-unlock         boolean
     |  |  +--rw admin-level-change        boolean
     |  |  +--rw admin-attribute-change    boolean
     |  |  +--rw resource-activity
     |  |  |  +--rw file-delete-modify     boolean
     |  |  +--rw security-config-activity
     |  |  |  +--rw log-policy-change      boolean
     |  |  |  +--rw log-operation-event    boolean
     |  |  |  +--rw log-storage-event      boolean
     |  |  |  +--rw security-policy-change boolean
     |  |  +--rw broke-security-policy     boolean
     |  |  +--rw session-event             boolean
     |  +--rw operation-activity
     |  |  +--rw system-config-change      boolean
     |  |  +--rw system-status-change      boolean
     |  |  +--rw service-status-change     boolean
     |  |  +--rw software-update           boolean
     |  |  +--rw cmd-operation-event       boolean
     |  +--rw key-cert-status-operation    boolean
     |  +--rw security-alg-operation       boolean
     +--rw alert-notification
     |  +--rw login-fail-threshold         uint8
     |  +--rw system-abnormal              boolean
     |  +--rw attack                       boolean
     |  +--rw log-overflow-lost            boolean
     +--rw (log-overflow-action)
     |  +--:(rewrite-when-overflow)        boolean
     |  |  +--ro rewrite-numbers           uint16
     |  +--:(discard-new-logs)             boolean
     |     +--ro discard-numbers           uint16
     +--rw (log-mode)
        +--:(file) {file-action}?
        |  +--rw user-level-for-read       uint8
        |  +--rw user-level-for-delete     uint8
        +--:(remote) {remote-action}?      [I-D.ietf-netmod-syslog-model]
           +--rw destination* [name]
              +--rw name                   string
              +--rw (transport)        
              |  ...
              +--rw signing! {signed-messages}?
                 ...
			

5.4. File Security

Patches, packages, configuration files, password files are critical system files for network infrastructure devices. To provide security, only administrators with certain security privilege levels are allowed to access or operate on these files. For file transfer security, secure protocol should be used. If insecure protocol has to be used, security hardening needs to be implemented.

  +--rw file-security
     +--rw (file-operation)
        +--:(local)
        |  +--rw (file-type)
        |     +--:(patch)
        |     |  +--rw user-level-for-execute   uint8
        |     |  +--rw patch-integrity-check    boolean
        |     |  +--rw integrity-alg*           identityref
        |     +--:(package)
        |     |  +--rw user-level-for-execute   uint8
        |     |  +--rw package-integrity-check  boolean
        |     |  +--rw integrity-alg*           identityref	  
        |     +--:(configuration-file)
        |     |  +--rw user-level-for-modify    uint8
        |     |  +--rw user-level-for-delete    uint8
        |     |  +--rw user-level-for-read      uint8
        |     +--:(password-file)
        |        +--rw user-level-for-read      uint8		
        +--:(remote-transfer)
           +--rw (transfer-channel)
              +--:(ftp)
              |  +--rw ftp-enable               boolean
              |  +--rw ftp-server-port          inet:port-number
              |  +--rw ftp-source-ip            inet:host
              |  +--u common-security-policy		 
              +--:(sftp)
              |  +--rw sftp-enable              boolean
              |  +--rw sftp-server-port         inet:port-number
              |  +--u ssh-server-grouping 
              |               [I-D.ietf-netconf-ssh-client-server]  
              |  +--u ssh-server-security-hardening
              |  +--u common-security-policy
              +--:(scp)
              |  +--rw scp-enable               boolean
              |  +--rw scp-server-port          inet:port-number
              |  +--rw ssh-server-grouping 
              |               [I-D.ietf-netconf-ssh-client-server]
              |  +--u ssh-server-security-hardening
              |  +--u common-security-policy
              +--:(ftps)
                 +--rw ftps-enable              boolean
                 +--rw ftps-server-port         inet:port-number
                 +--u tls-server-grouping 
                              [I-D.ietf-netconf-tls-client-server]
                 +--u common-security-policy
				 

6. Network Infrastructure Device Security Baseline Yang Module

TBD

7. Acknowledgements

8. IANA Considerations

This document requires no IANA actions.

9. Security Considerations

Secure transport should be used to retrieve the current status of management plane security baseline.

10. References

10.1. Normative References

10.2. Informative References

Appendix A.

The following is the whole structure of the YANG tree diagram for network infrastructure device management plane. The existed RFCs and drafts that related this document are listed at the right side.

module: nid-management-plane-security
  +--rw admin-account-management-security
  |  +--rw admin-account-config-security
  |  +--rw admin-login-security     [I-D.ietf-netconf-ssh-client-server]
  |                                 [I-D.ietf-netconf-tls-client-server]
  |  +--rw aaa-config-security      [RFC7317]
  |  +--rw admin-access-statistics
  +--rw system-management-security
  |  +--rw snmp-security            [RFC7407]
  |  +--rw netconf-security         [I-D.ietf-netconf-netconf-client-server]
  |  +--rw port-management-security
  +--rw log-security
  |  +--rw log-record
  |  +--rw alert-notification
  |  +--rw log-overflow-action
  |  +--rw log-mode                [I-D.ietf-netmod-syslog-model]
  +--rw file-security              [I-D.ietf-netconf-ssh-client-server]
                                   [I-D.ietf-netconf-tls-client-server]  
	

Draft [I-D.ietf-netconf-tls-client-server] and draft [I-D.ietf-netconf-ssh-client-server] focus on YANG models for TLS-specific configuration and SSH-specific configuration respectively. The transport-level configuration, such as what ports to listen-on or connect-to, is not included. Draft [I-D.ietf-netconf-netconf-client-server] defines NETCONF YANG model based on the data models defined in the above two documents.

[RFC7317] defines a YANG data model for system management of device containing a NETCONF sever. It summarizes data modules for NETCONF user authentication, and RADIUS server configuration. Three methods are defined for user authentication: public key for local users over SSH, password for local users over any secure transport, password for RADIUS users over any secure transport.

[RFC7407] defines a YANG model for SNMP configuration, including community-based security module for SNMPv1 and SNMPv2c, as well as view-based access control module and user-based security module for SNMPv3.

Draft [I-D.ietf-netmod-syslog-model] defines a YANG model for Syslog configuration, including TLS based transport security and syslog messages signing.

Authors' Addresses