circular memory buffer or log file rotation), or logging stops.
2.11.5. Ability to Maintain Accurate System Time
Requirement.
The device MUST maintain accurate, "high resolution" (see
definition in Section 1.8) system time.
Justification.
Accurate time is important to the generation of reliable log data.
Accurate time is also important to the correct operation of some
authentication mechanisms.
Examples.
This requirement may be satisfied by supporting Network Time
Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct
connection to an accurate time source.
Warnings.
System clock chips are inaccurate to varying degrees. System time
should not be relied upon unless it is regularly checked and
synchronized with a known, accurate external time source (such as
an NTP stratum-1 server). Also note that if network time
synchronization is used, an attacker may be able to manipulate the
clock unless cryptographic authentication is used.
2.11.6. Display Timezone And UTC Offset
Requirement.
All displays and logs of system time MUST include a timezone or
offset from UTC.
Justification.
Knowing the timezone or UTC offset makes correlation of data and
coordination with data in other timezones possible.
Examples.
Bob is in Newfoundland, Canada which is UTC -3:30. Alice is
somewhere in Indiana, USA. Some parts of Indiana switch to
daylight savings time while others do not. A user on Bob’s
network attacks a user on Alice’s network. Both are using logs
with local timezones and no indication of UTC offset. Correlating
these logs will be difficult and error prone. Including timezone,
or better, UTC offset, eliminates these difficulties.
Warnings.
None.
2.11.7. Default Timezone Should Be UTC
Requirement.
The default timezone for display and logging SHOULD be UTC. The
device MAY support a mechanism to allow the operator to specify
the display and logging of times in a timezone other than UTC.
Justification.
Knowing the timezone or UTC offset makes correlation of data and
coordination with data in other timezones possible.
Examples.
Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or
UTC -6 depending on the time of year and exact county in Indiana)
are working an incident together using their logs. Both left the
default settings, which was UTC, so there was no translation of
time necessary to correlate the logs.
Warnings.
None.
2.11.8. Logs Must Be Timestamped
Requirement.
By default, the device MUST timestamp all log messages. The
timestamp MUST be accurate to within a second or less. The
timestamp MUST include a timezone. There MAY be a mechanism to
disable the generation of timestamps.
Justification.
Accurate timestamps are necessary for correlating events,
particularly across multiple devices or with other organizations.
This applies when it is necessary to analyze logs.
Examples.
This requirement MAY be satisfied by writing timestamps into
syslog messages.
Warnings.
It is difficult to correlate logs from different time zones.
Security events on the Internet often involve machines and logs
from a variety of physical locations. For that reason, UTC is
preferred, all other things being equal.
2.11.9. Logs Contain Untranslated IP Addresses
Requirement.
Log messages MUST NOT list translated addresses (DNS names)
associated with the address without listing the untranslated IP
address where the IP address is available to the device generating
the log message.
Justification.
Including IP address of access list violations authentication
attempts, address lease assignments and similar events in logs
enables a level of individual and organizational accountability
and is necessary to enable analysis of network events, incidents,
policy violations, etc.
DNS entries tend to change more quickly than IP block assignments.
This makes the address more reliable for data forensics.
DNS lookups can be slow and consume resources.
Examples.
A failed network login should generate a record with the source
address of the login attempt.
Warnings.
* Source addresses may be spoofed. Network-based attacks often
use spoofed source addresses. Source addresses should not be
completely trusted unless verified by other means.
* Addresses may be reassigned to different individual, for
example, in a desktop environment using DHCP. In such cases
the individual accountability afforded by this requirement is
weak. Having accurate time in the logs increases the chances
that the use of an address can be correlated to an individual.
* Network topologies may change. Even in the absence of dynamic
address assignment, network topologies and address block
assignments do change. Logs of an attack one month ago may not
give an accurate indication of which host, network or
organization owned the system(s) in question at the time.
2.11.10. Logs Contain Records Of Security Events
Requirement.
The device MUST be able to send a record of at least the following
events:
* authentication successes,
* authentication failures,
* session Termination,
* authorization changes,
* configuration changes,
* device status changes.
The device SHOULD be able to send a record of all other security
related events.
Justification.
This is important because it supports individual accountability.
See section 4.5.4.4 of [RFC2196].
Examples.
Examples of events for which there must be a record include: user
logins, bad login attempts, logouts, user privilege level changes,
individual configuration commands issued by users and system
startup/shutdown events.
Warnings.
This list is far from complete.
Note that there may be privacy or legal considerations when
logging/monitoring user activity.
2.11.11. Logs Do Not Contain Passwords
Requirement.
Passwords SHOULD be excluded from all audit records, including
records of successful or failed authentication attempts.
Justification.
Access control and authorization requirements differ for
accounting records (logs) and authorization databases (passwords).
Logging passwords may grant unauthorized access to individuals
with access to the logs. Logging failed passwords may give hints
about actual passwords. See section 4.5.4.4 of [RFC2196].
Examples.
A user may make small mistakes in entering a password such as
using incorrect capitalization ("my password" vs. "My Password").
Warnings.
There may be situations where it is appropriate/required to log
passwords.
2.12. Authentication, Authorization, and Accounting (AAA) Requirements
2.12.1. Authenticate All User Access
Requirement.
The device MUST provide a facility to perform authentication of
all user access to the system.
Justification.
This functionality is required so that access to the system can be
restricted to authorized personnel.
Examples.
This requirement MAY be satisfied by implementing a centralized
authentication system. See Section 2.12.5. It MAY also be
satisfied using local authentication. See Section 2.12.6.
Warnings.
None.
2.12.2. Support Authentication of Individual Users
Requirement.
Mechanisms used to authenticate interactive access for
configuration and management MUST support the authentication of
distinct, individual users. This requirement MAY be relaxed to
support system installation Section 2.4.5 or recovery of
authorized access Section 2.12.15.
Justification.
The use of individual accounts, in conjunction with logging,
promotes accountability. The use of group or default accounts
undermines individual accountability.
Examples.
A user may need to log in to the device to access CLI functions
for management. Individual user authentication could be provided
by a centralized authentication server or a username/password
database stored on the device. It would be a violation of this
rule for the device to only support a single "account" (with or
without a username) and a single password shared by all users to
gain administrative access.
Warnings.
This simply requires that the mechanism to support individual
users be present. Policy (e.g., forbidding shared group accounts)
and enforcement are also needed but beyond the scope of this
document.
2.12.3. Support Simultaneous Connections
Requirement.
The device MUST support multiple simultaneous connections by
distinct users, possibly at different authorization levels.
Justification.
This allows multiple people to perform authorized management
functions simultaneously. This also means that attempted
connections by unauthorized users do not automatically lock out
authorized users.
Examples.
None.
Warnings.
None.
2.12.4. Ability to Disable All Local Accounts
Requirement.
The device MUST provide a means of disabling all local accounts
including:
* local users,
* default accounts (vendor, maintenance, guest, etc.),
* privileged and unprivileged accounts.
A local account defined as one where all information necessary for
user authentication is stored on the device.
Justification.
Default accounts, well-known accounts, and old accounts provide
easy targets for someone attempting to gain access to a device.
It must be possible to disable them to reduce the potential
vulnerability.
Examples.
The implementation depends on the types of authentication
supported by the device.
Warnings.
None.
2.12.5. Support Centralized User Authentication Methods
Requirement.
The device MUST support a method of centralized authentication of
all user access via standard authentication protocols.
Justification.
Support for centralized authentication is particularly important
in large environments where the network devices are widely
distributed and where many people have access to them. This
reduces the effort needed to effectively restrict and track access
to the system by authorized personnel.
Examples.
This requirement can be satisfied through the use of DIAMETER
[RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos
[RFC1510].
The secure management requirements (Section 2.1.1) apply to AAA.
See [RFC3579] for a discussion security issues related to RADIUS.
Warnings.
None.
2.12.6. Support Local User Authentication Method
Requirement.
The device SHOULD support a local authentication method. If
implemented, the method MUST NOT require interaction with anything
external to the device (such as remote AAA servers), and MUST
work in conjunction with Section 2.3.1 (Support a ’Console’
Interface) and Section 2.12.7 (Support Configuration of Order of
Authentication Methods).
Justification.
Support for local authentication may be required in smaller
environments where there may be only a few devices and a limited
number of people with access. The overhead of maintaining
centralized authentication servers may not be justified.
Examples.
The use of local, per-device usernames and passwords provides one
way to implement this requirement.
Warnings.
Authentication information must be protected wherever it resides.
Having, for instance, local usernames and passwords stored on 100
network devices means that there are 100 potential points of
failure where the information could be compromised vs. storing
authentication data centralized server(s), which would reduce the
potential points of failure to the number of servers and allow
protection efforts (system hardening, audits, etc.) to be focused
on, at most, a few servers.
2.12.7. Support Configuration of Order of Authentication Methods
Requirement.
The device MUST support the ability to configure the order in
which supported authentication methods are attempted.
Authentication SHOULD "fail closed", i.e., access should be denied
if none of the listed authentication methods succeeds.
Justification.
This allows the operator flexibility in implementing appropriate
security policies that balance operational and security needs.
Examples.
If, for example, a device supports RADIUS authentication and local
usernames and passwords, it should be possible to specify that
RADIUS authentication should be attempted if the servers are
available, and that local usernames and passwords should be used
for authentication only if the RADIUS servers are not available.
Similarly, it should be possible to specify that only RADIUS or
only local authentication be used.
Warnings.
None.
2.12.8. Ability To Authenticate Without Plaintext Passwords
Requirement.
The device MUST support mechanisms that do not require the
transmission of plaintext passwords in all cases that require the
transmission of authentication information across networks.
Justification.
Plaintext passwords can be easily observed using packet sniffers
on shared networks. See [RFC1704] and [RFC3631] for a through
discussion.
Examples.
Remote login requires the transmission of authentication
information across networks. Telnet transmits plaintext
passwords. SSH does not. Telnet fails this requirement. SSH
passes.
Warnings.
None.
2.12.9. No Default Passwords
Requirement.
The initial configuration of the device MUST NOT contain any
default passwords or other authentication tokens.
Justification.
Default passwords provide an easy way for attackers to gain
unauthorized access to the device.
Examples.
Passwords such as the name of the vendor, device, "default", etc.
are easily guessed. The SNMP community strings "public" and
"private" are well known defaults that provide read and write
access to devices.
Warnings.
Lists of default passwords for various devices are readily
available at numerous websites.
2.12.10. Passwords Must Be Explicitly Configured Prior To Use
Requirement.
The device MUST require the operator to explicitly configure
"passwords" prior to use.
Justification.
This requirement is intended to prevent unauthorized management
access. Requiring the operator to explicitly configure passwords
will tend to have the effect of ensuring a diversity of passwords.
It also shifts the responsibility for password selection to the
user.
Examples.
Assume that a device comes with console port for management and a
default administrative account. This requirement together with No
Default Passwords says that the administrative account should come
with no password configured. One way of meeting this requirement
would be to have the device require the operator to choose a
password for the administrative account as part of a dialog the
first time the device is configured.
Warnings.
While this device requires operators to set passwords, it does not
prevent them from doing things such as using scripts to configure
hundreds of devices with the same easily guessed passwords.
2.12.11. Ability to Define Privilege Levels
Requirement.
It MUST be possible to define arbitrary subsets of all management
and configuration functions and assign them to groups or
"privilege levels", which can be assigned to users per Section
2.12.12. There MUST be at least three possible privilege levels.
Justification.
This requirement supports the implementation of the principal of
"least privilege", which states that an individual should only
have the privileges necessary to execute the operations he/she is
required to perform.
Examples.
Examples of privilege levels might include "user" which only
allows the initiation of a PPP or telnet session, "read only",
which allows read-only access to device configuration and
operational statistics, "root/superuser/administrator" which
allows update access to all configurable parameters, and
"operator" which allows updates to a limited, user defined set of
parameters. Note that privilege levels may be defined locally on
the device or on centralized authentication servers.
Warnings.
None.
2.12.12. Ability to Assign Privilege Levels to Users
Requirement.
The device MUST be able to assign a defined set of authorized
functions, or "privilege level", to each user once they have
authenticated themselves to the device. Privilege level
determines which functions a user is allowed to execute. Also see
Section 2.12.11.
Justification.
This requirement supports the implementation of the principal of
"least privilege", which states that an individual should only
have the privileges necessary to execute the operations he/she is
required to perform.
Examples.
The implementation of this requirement will obviously be closely
coupled with the authentication mechanism. If RADIUS is used, an
attribute could be set in the user’s RADIUS profile that can be
used to map the ID to a certain privilege level.
Warnings.
None.
2.12.13. Default Privilege Level Must Be ’None’
Requirement.
The default privilege level SHOULD NOT allow any access to
management or configuration functions. It MAY allow access to
user-level functions (e.g., starting PPP or telnet). It SHOULD be
possible to assign a different privilege level as the default.
This requirement MAY be relaxed to support system installation per
Section 2.4.5 or recovery of authorized access per Section
2.12.15.
Justification.
This requirement supports the implementation of the principal of
"least privilege", which states that an individual should only
have the privileges necessary to execute the operations he/she is
required to perform.
Examples.
Examples of privilege levels might include "user" which only
allows the initiation of a PPP or telnet session, "read-only",
which allows read-only access to device configuration and
operational statistics, "root/superuser/administrator" which
allows update access to all configurable parameters, and
"operator" which allows updates to a limited, user defined set of
parameters. Note that privilege levels may be defined locally on
the device or on centralized authentication servers.
Warnings.
It may be required to provide exceptions to support the
requirements to support recovery of privileged access (Section
2.12.15) and to support OS installation and configuration (Section
2.4.5). For example, if the OS and/or configuration has somehow
become corrupt an authorized individual with physical access may
need to have "root" level access to perform an install.
2.12.14. Change in Privilege Levels Requires Re-Authentication
Requirement.
The device MUST re-authenticate a user prior to granting any
change in user authorizations.
Justification.
This requirement ensures that users are able to perform only
authorized actions.
Examples.
This requirement might be implemented by assigning base privilege
levels to all users and allowing the user to request additional
privileges, with the requests validated by the AAA server.
Warnings.
None.
2.12.15. Support Recovery Of Privileged Access
Requirement.
The device MUST support a mechanism to allow authorized
individuals to recover full privileged administrative access in
the event that access is lost. Use of the mechanism MUST require
physical access to the device. There MAY be a mechanism for
disabling the recovery feature.
Justification.
There are times when local administrative passwords are forgotten,
when the only person who knows them leaves the company, or when
hackers set or change the password. In all these cases,
legitimate administrative access to the device is lost. There
should be a way to recover access. Requiring physical access to
invoke the procedure makes it less likely that it will be abused.
Some organizations may want an even higher level of security and
be willing to risk total loss of authorized access by disabling
the recovery feature, even for those with physical access.
Examples.
Some examples of ways to satisfy this requirement are to have the
device give the user the chance to set a new administrative
password when:
* The user sets a jumper on the system board to a particular
position.
* The user sends a special sequence to the RS232 console port
during the initial boot sequence.
* The user sets a "boot register" to a particular value.
Warnings.
This mechanism, by design, provides a "back door" to complete
administrative control of the device and may not be appropriate
for environments where those with physical access to the device
can not be trusted.
Also see the warnings in Section 2.3.1 (Support a ’Console’
Interface).
2.13. Layer 2 Devices Must Meet Higher Layer Requirements
Requirement.
If a device provides layer 2 services that are dependent on layer
3 or greater services, then the portions that operate at or above
layer 3 MUST conform to the requirements listed in this document.
Justification.
All layer 3 devices have similar security needs and should be
subject to similar requirements.
Examples.
Signaling protocols required for layer 2 switching may exchange
information with other devices using layer 3 communications. In
such cases, the device must provide a secure layer 3 facility.
Also, if higher layer capabilities (say, SSH or SNMP) are used to
manage a layer 2 device, then the rest of the requirements in this
document apply to those capabilities.
Warnings.
None.
2.14. Security Features Must Not Cause Operational Problems