1. Management Plane controls 

1.1  Infrastructure Protection 

1.1.1 

  Configure the hostname of the device

It is suggested to define the name of the device following the VCNO node naming convention. Each device’s hostname should contain the country’s initials, the city’s initials, the type of the device (FW for Firewall) and the number of the node 

Required for identification purposes

M

1.1.2

Configure a management IP address 

Set an IP address for management purposes on the devices; this IP address must be on a segregated subnet and management traffic must not go via production interfaces and must adhere to the zoning standard. 

Setting a management IP segregates management traffic and data traffic whilst preventing snooping.

M

1.1.3

Require a loopback address

To ensure continuity of source addressing of the services on the firewall, a Loopback address should be used

Issues can arise if services do not use the same source address, it can potentially cause packets to be handled incorrectly by receiving hosts.

R

1.1.4

Configure login banner 

Display a warning banner when a user connects to the device. The warning banners must be the same on all Firewalls

In some legal jurisdictions it can be impossible to prosecute and it is illegal to monitor malicious users, unless they have been notified that they are not permitted to use the system. 

M

1.1.5

Set at least two IP name servers 

Specify the address of two name servers to use for name and address resolution. The local or the zone internal servers must be used and should be located in separate geographical locations to provide resiliency 

Defining a name server ensures that the authorized/designated server responds to the client request.

R

1.1.6

Configure thresholds for load monitoring 

The network element must generate an event if the amount of CPU usage or memory usage breaks the operator- configured threshold.

Running low in memory is usually caused by increased traffic, which can potentially be an indication of DDoS attack.

M

1.2 Password Policy

1.2.1

Encrypt configuration passwords 

The strongest password encryption method must be applied to all passwords, based on the device’s capabilities, including username passwords, authentication key passwords, the privileged command password, console, virtual terminal passwords, etc. 

Passwords must always be encrypted and they shall never be displayed in plain text, therefore preventing a non-authorised user from having visibility of the passwords.

M

1.2.2

Create a fall back account

Create a local user for fall back access purposes.

The local (fall back) account can be used to access the device if all AAA servers become unavailable, providing emergency access. 

M

1.2.3

Set an encrypted management password 

Define the management or root password for the device. The strongest encryption method must be used, based on the device’s capabilities.

The management password is used to gain access to the exec shell, or equivalent, using the console or a remote connection. 

M

1.3 Unnecessary services 

1.3.1

Disable HTTP web management service and use HTTPS where possible  Disable HTTP web management service and use HTTPS where possible 

Disable the HTTP service, which is an unsecure protocol and shall not be used to manage firewalls. Use HTTPS web management to ensure data is protected across the network.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks.

M

1.3.2

Disable DHCP Server and DHCP relay services 

Disable DHCP server, which are used for dynamic IP assignment, as only dedicated DHCP servers must be able to provide IP addresses to other devices

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks

M

1.3.3

Disable DDNS services  

DDNS should not be used within private address space to prevent inconsistent configurations between services.

Unnecessary services must be disabled, if not needed, to prevent exploitation of vulnerabilities, as they can be used to launch DDoS and other attacks. 

M

1.3.4

Disable the neighbor discovery protocols for external facing interfaces 

The exchange of device information via neighbor discovery protocols must be prohibited via external interfaces (Internet, 3rd party access, external leased line). 

Neighbor discovery protocols must be disabled unless explicitly required, as the protocol can potentially leak device information to rogue users on the network.

M

1.3.5

Prohibit telnet connections 

Define that remote connection can be established to the firewall only via secure protocols. 

Only secure communications must be allowed, in order for the traffic to be encrypted and protected from sniffing attacks.

M

  1.4 Connection security 

1.4.1 

Enable TCP keepalives for inbound and outbound connections where supported

TCP keepalives must be configured, as they check that the device on the remote end of the connection is still accessible

Enabling TCP keepalives ensures that half−open or embryonic connections are deleted by the device.

M

1.5 Interactive Management Sessions 

1.5.1 

Enable SSH Version 2 

Only secure connections must be allowed.

  SSHv2 is considered to be more secure than the v1 which is known to have vulnerabilities. 

M

1.5.2

Generate encrypted key for SSH 

Generate an encrypted key to be exchanged during SSH communication initiation. 

Data is transferred encrypted via SSH communication

M

1.5.3

Define inactivity time out for both console and remote sessions 

A predefined inactivity time-out period must be configured on the firewall to logout remote sessions that have been left idle.

Required for ensuring that the session is used by an authorized user and has not been left unattended. 

M

1.5.4

Define the allowed authentication retries for SSH connections 

Specify the number of attempts a user has before the connection resets.

This ensures that after a set number of attempts the SSH session is disconnected and possible brute force attacks are prevented.

M

1.5.5

Use authentication method for both console and remote management sessions

Define a specific password for remote authentication and specify that an AAA method must be used for authenticating user login via interactive management sessions. 

Necessary service for authenticating and identifying remote login users.

M

1.5.6

Forbid the installation of externally sourced scripts, other than provided by the manufacturer or sanitized first before use

  Scripts can be useful to perform tasks on the device but should only be used under specific circumstances

Externally sourced scripts may have malicious content and should not be installed onto the system under any circumstances.

M

1.6 AAA  

1.6.1

Set the source IP address for the AAA server 

Associate an interface’s IP address to the packet sent to the AAA server regardless of which interface the packet exited the device facilitating the analysis of the logs.

Specifying the address that the device sources management traffic from, ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities

M

1.6.2

Authenticate communication with AAA server

Define a key to be used for communication with the AAA server in- line with password policy 

Communication with the AAA server must be authenticated prior to exchange of any messages for assuring the communication security. 

M

1.6.3

Define the login authentication method to be AAA compliant 

Define that the AAA method must be used for login authentication and for gaining access to the privilege/configuration mode. 

The default authentication method must be AAA compliant, since it provides better security when transferring the packets and supports multiple communication protocols

M

1.6.4

Enable user authorisation 

Authorize a user’s actions depending on the permissions granted from the AAA server, only if he has been authenticated first. 

Ensures that appropriate authorisation and permissions are being granted to the user when accessing the device.

M

1.6.5

  Enable accounting to monitor the user’s actions

Provide information about the user’s actions including authorisation failure, configuration commands, system changes and all the connections made from the network access server, ensuring that periodic updates are sent to the AAA server. 

Information logged by the AAA accounting options can be valuable during the investigation of an attack. 

M

1.7 Logging  

1.7.1

  Define the time zone 

Time zone information shall be expressed in universal time coordinates (UTC) in alignment with NTP servers 

Necessary for synchronizing the log files. Accurate timekeeping is critically important for correlating network events.

M

1.7.2

  Configure timestamps for logging 

Attach timestamp information to the log and debug files. Timestamp information shall express absolute time, not time since the last power-on / reboot of the network element.

Necessary for auditing purposes and for identifying the exact time during which a change took place

M

1.7.3

Logs must be sent to at least two logging servers

Logs should be replicated on at least two logging servers to provide redundancy of events for resiliency purposes.

Logging is critical to device security because it creates an audit trail of system activity. 

M

1.7.4

Set the source IP address for the syslog

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

Specifying the address that the device sources management traffic from ensures that the network can be configured in a prescriptive manner, reducing an attacker’s opportunities.

M

1.7.5

Configure notifications to be sent to a syslog server 

Send logs to syslog server above warning messages including errors, critical & emergencies. 

Allows the administrator to focus on and process the logs that need immediate attention/action and which might pose a security risk. 

M

1.7.6

Enable the logging for all interactive management sessions 

Logging on interactive management sessions must be enabled

Logging is critical to device security because it creates an audit trail of system activity.

M

1.7.7

Define names for firewall policies, where supported

Firewall policy should be named; the name should be the ticket reference from where the policy change was requested.

Naming the firewall policies is required to create an audit trail to allow for changes on the firewall policy to be tracked.

R

1.8 Border Device Filtering 

1.8.1

Enable anti-spoofing for both inbound and outbound traffic where supported 

  Verify that both inbound and outbound traffic from the network has a valid source address. 

Filtering denies any traffic that does not have the source address that was expected on a particular interface

M

1.8.2

Unicast Reverse-Path Forwarding where supported

  Ensure RPF is enabled to verify source addresses. 

A number of different attacks rely on spoofing the traffic source address. By verifying the source address it will enable the firewall to drop attack traffic. 

R

2 Control Plane controls

2.1 Border Gateway Protocol (BGP)

2.1.1

Enable BGP Authentication 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

Authentication between BGP neighbors should be enabled; MD5 password authentication or keychain must be used to secure BGP sessions. 

M

2.1.2

Enable logging for neighbor changes, if applicable 

The device must be configured to log BGP neighbor resets. 

Logging of neighbor changes ensures that all changes are retained and facilitates investigation of a potential attack.

M

2.1.3

Maximum prefixes limit must be enforced for external connected peers 

A limit must be applied regarding how many BGP prefix records a firewall can store in its memory. Must be used on all customer BGP sessions 

Limiting the BGP prefixes is required for ensuring the effectiveness and the functionality of the firewall. 

M

Limit BGP AS path length for external connected peers, if applicable 

Maximum AS path length should be configured to protect elements from errors and mis-configuration. 

Overlong AS paths should not be expected in normal circumstances and are symptomatic of problems within external networks. 

2.1.4

Specify a Time to Live, if unavailable use maximum number of hops for eBGP peers. 

A maximum TTL should be configured so that BGP packets are received from directly connected peers. 

This prevents the firewall from receiving potential malicious or false BGP advertisements and reduces the possibility of the device receiving false firewall updates that would allow an attacker to potentially corrupt the route tables, compromise network availability or redirect network traffic. 

M

2.2 Interior Routing Protocol Security 

2.2.1

Neighbour Authentication 

Neighbor authentication, such as MD5 password or key authentication, depending on the firewalls capabilities, must be used between neighboring devices exchanging routing protocols updates

A strong authentication algorithm will enhance the connection security and ensure that routing messages are exchanged between only authorized neighbors. 

M

2.2.2 

Enable routing only on participating interfaces 

Explicitly enable routing updates for those interfaces that need to participate in the routing updates. 

Ensures that only authorized interfaces participate in the routing procedure, protecting the network from receiving rogue updates. 

M

2.2.3

Enable routing updates only on the participating interfaces

Ensure that non-participating interfaces in routing updates are passive and packets are not sent or received on those interfaces. 

This prevents an interface from sending or receiving packets if it has not been specifically allowed, reducing the size of the device's attack footprint. 

R

2.3 NTP 

2.3.1

Configure at least two NTP servers or create specific NTP access groups 

Configure two NTP servers, which are part of the relative zone in which the device belongs, with one being preferred. Should be located in separate geographical locations to provide resiliency. 

Accurate and reliable time is required in order to ensure that logs can be compared across systems when investigating potential attacks. Using at least two servers provides redundancy. 

M

2.3.2

Authenticate NTP communications

Create an encrypted NTP authentication key and authenticate all NTP connections via the configured key

NTP authentication shall be configured to provide assurance that NTP messages are exchanged between trusted NTP peers, reducing an attacker’s opportunity to affect timestamps on system logs or affect other time-dependent services.

M

2.3.3

Disable NTP on external interfaces

Block an interface from sending or receiving NTP messages. 

  Reduces the footprint of the device by limiting the interfaces it sends NTP packets out of internal interfaces only. 

M

2.3.4

Configure the source address for NTP 

An interface’s IP address must be associated with the packet sent to any external device, regardless of which interface the packet exited the device, facilitating the analysis of the logs. 

By assigning a specific source interface to messages, consistent device identification is ensured and logging management is simplified. 

M

3 Data Plane Controls

3.1 Layer 2 Security 

3.1.1

Disable unused ports 

Disable all unused ports and place them in an unused state that is isolated from the rest of the network. 

Unused interfaces shall be disabled to prevent unauthorized use. 

M

3.1.2

Do not use default VLANs for management traffic 

Set a secure VLAN for management purposes and disable VLAN 1 which is the default in most of the firewall devices. 

Setting a management VLAN segregates management traffic and data traffic and prevents snooping. 

M

3.1.3

Configure interfaces to be in the correct zone 

External interfaces must be identified as untrusted and all internal interfaces must be configured in accordance with the VCNO Zoning Standard. 

By identifying interfaces as untrusted it enables screening to be performed on traffic.

M

3.1.4

Disable source routing

IP source routing must be disabled. 

This feature must be disabled as an attacker can exploit the IP options to affect the way a device forwards the packets and avert security controls 

M

3.2 Connection Controls

3.2.1

Limit concurrent sessions from singular external client 

Limits should be placed on client connections to protect flooding the network.

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.2

Limit the amount of connections received on external interfaces

Limits should be placed on incoming connections to protect flooding the network. 

Attackers can attempt to flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.3

Limit the amount of connections sent on external interfaces 

Limits should be placed on outgoing connections to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place. 

M

3.2.4

Limit requests per second on external interfaces 

Limits should be placed on the number of outgoing connections per seconds to protect flooding the network. 

Services can flood the network causing a denial of service with connections if thresholds are not in place.

M

3.2.5

Screen on untrusted and semi-trusted interfaces on external interfaces 

Screening should be performed on non-trusted interfaces. 

Screening is mandatory on non-trusted network to protect against malicious traffic, 

M