NET.3.4 Network Access Control

Description

Introduction

Network Access Control (NAC) secures network access at the end device level through identity verification (authentication) and regulation (authorization). In this building block, end devices refer to all IT systems connected at the access layer of a campus network. NAC can be used in both wired and wireless networks. An identity can, for example, be securely verified via accounts with certificates. The subsequent authorization assigns appropriate network segments and permissions to end devices via authorization rules, thereby establishing access rules. End devices can also be denied network access.

For example, a printer can be identified as such via NAC and securely authenticated with a valid certificate. Once the printer has been successfully authenticated, it is then assigned to the network segment designated for the printer through NAC authorization.

NAC solutions use either the techniques described in IEEE 802.1X (Port Based Network Access Control) or so-called MAC address authentication. In IEEE 802.1X, authentication takes place via the Extensible Authentication Protocol (EAP) between software on the end device—the so-called supplicant—and the so-called authenticator, which is implemented by an access switch, WLAN access point, or WLAN controller. A central RADIUS server (Remote Authentication Dial-In User Service) is additionally used for authentication. The RADIUS server is also called the authentication server or AAA server (Authentication, Authorization, Accounting). In MAC address authentication, the end device is authenticated via its MAC address.

A NAC solution based on IEEE 802.1X therefore comprises the following components:

• Authentication Server or RADIUS Server
• Supplicant on an end device
• Authenticator on an access switch or a WLAN component (WLAN access point or WLAN controller)
• Central NAC identity management, which can be implemented as integrated identity management on the server or can draw on existing directory services

In this building block, a NAC solution encompasses all the components described above. If an individual component of the NAC solution is meant—e.g., the RADIUS server—that component is actually named as such. The RADIUS server and the NAC identity management are considered the central components of a NAC solution in this building block.

For a NAC solution to be used sensibly and for network access to be adequately secured, many points must be defined and the named components of the solution must be coordinated with each other. Furthermore, NAC-specific processes (e.g., measures to resolve faults) must be defined and existing processes (e.g., commissioning of end devices) must be adapted.

Objective

The objective of this building block is to establish information security as an integral component of NAC. A NAC solution should ensure that access to the network is regulated through identity-dependent authorization rules. This protects information that is processed, stored, and transmitted over networks.

Scope and Modeling

The building block NET.3.4 Network Access Control is to be applied to the elements of a NAC solution. This includes affected networks, clients, and central components.

To create an IT-Grundschutz model for a specific information domain, the entirety of all building blocks must generally be considered. As a rule, several building blocks apply to the topic or target object.

This building block addresses NAC solutions based on IEEE 802.1X and MAC address authentication via RADIUS. The focus is on the following partial aspects of a NAC solution:

• general specifications for NAC for both the central components and the end devices
• requirements for authentication and authorization
• specifications for the management and operation of a NAC solution

The following content is also relevant and is addressed elsewhere:

• Directory services (see APP.2.1 General Directory Service)
• Network architecture and design (see NET.1.1 Network Architecture and Design)
• WLAN-specific aspects (see NET.2.1 WLAN Operation and NET.2.2 WLAN Use)
• General operational aspects (see building blocks of layer OPS Operations)

This building block does not address the following content:

• Port security and general aspects for network components (see NET.3.1 Routers and Switches)
• Proprietary NAC implementations not based on IEEE 802.1X
• The implementation of a RADIUS server on network components (access switch, WLAN access point, or WLAN controller)
• Administrative authentication to network components via RADIUS
• General aspects for end devices (see building blocks of layers SYS.2 Desktop Systems, SYS.3 Mobile Devices, and SYS.4 Other Systems)
• General aspects for servers (see SYS.1.1 General Server) and virtualization (see SYS.1.5 Virtualization)
• General aspects for identity and access management (see ORP.4 Identity and Access Management)

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for building block NET.3.4 Network Access Control.

Insufficient Planning of the NAC Solution

If not all IT systems and information relevant to NAC are recorded in an IT asset management system, a NAC solution cannot be adequately planned. End devices may then not receive network access or may receive access to the wrong network segment.

If the requirements for the NAC solution have not been sufficiently collected and analyzed, this can also lead to inadequate planning. For example, it is then possible that the switches used cannot fulfill the requirements of the planned NAC solution or that the planned RADIUS server is incorrectly dimensioned. Another consequence could be requirements that are too strict or too lenient for the authentication and authorization methods used. This could result in end devices being denied network access or insecure authentication methods being used even though secure methods would be possible. Overly broad communication permissions could also potentially be obtained thereby.

Insufficiently Coordinated Integration of End Devices into the NAC Solution

Missing or insufficiently implemented orchestration tools, security policies, requirements catalogs, and resources for recording all end devices can result in end devices being integrated into the NAC solution in an insufficiently coordinated manner. This makes it difficult to implement a secure and operationally friendly authentication method per end device group and to design a corresponding commissioning process. As a result, the communication capabilities of end devices could be negatively affected. In addition, devices requiring protection may inadvertently be positioned in incorrect network segments.

If end devices are insufficiently standardized or NAC-specific end device requirements are insufficiently supported, this can also result in insecure authentication methods being used even though strong authentication would fundamentally be possible.

Use of Insufficiently Secure Protocols in NAC

If secure EAP authentication methods are not technically supported, it may be necessary to use insecure authentication protocols such as EAP-MD5 or MAC authentication. In this case, spoofing, replay, or man-in-the-middle attacks are more easily possible and it cannot be ruled out that unauthorized IT systems gain access to the network. If end devices with weak authentication protocols are not restricted in terms of the destinations they may communicate with and the protocols they may use, unauthorized IT systems that have gained access through one of the attacks mentioned above can also obtain broad communication permissions.

Incorrect Configuration of the NAC Solution

Due to human errors, insufficient processes, or insufficient staffing capacity and the resulting time pressure, it can happen that NAC-specific parameters at end devices, access switches, or RADIUS servers (NAC ruleset) are incorrectly configured. This can cause the entire NAC solution to unintentionally behave incorrectly, resulting, for example, in end devices being unable to reach required resources or not receiving network access.

If MAC addresses are deliberately registered incorrectly, too many resources can thereby be enabled by assigning incorrect network segments or other incorrect authorization parameters.

Insufficient Validation of Configuration Changes

Insufficient change processes that do not validate or only inadequately validate configuration changes favor errors in the configuration. This can result in too many or too few sensitive resources being accessible for end devices, or network access being completely denied to them. If NAC is disabled at switch ports without a compelling reason, for example, unauthorized end devices can potentially access the network without restriction. If new software on end devices is insufficiently validated, this can, for example, lead to interference between software components and influence the functionality of the supplicant.

Insufficiently Protected Network Access

If NAC is temporarily or permanently disabled at switch ports, network access is insufficiently protected. This makes it possible for unauthorized persons to access the network or for insecure IT systems to obtain overly broad communication permissions. As a result, information can be accessed without authorization, and information can be manipulated or deleted. Malware can also be introduced in this way.

If end device compliance is insufficiently checked, this can also lead to insufficiently protected network access—for example, if the end device has insufficient virus protection and malware is thereby introduced.

Failure or Insufficient Reachability of Central NAC Components

An insufficient or insufficiently implemented NAC concept, disrupted NAC components or a disrupted network, insufficient requirements analysis, insufficient processes, or denial-of-service attacks (DoS attacks) can cause the central NAC components to fail or become unreachable. This affects the ability of end devices to communicate. For example, depending on the switch configuration, if all RADIUS servers fail, end devices have either no or unrestricted network access.

Tracking of Users

An insufficient administration concept, insufficient implementation of the conceptual design, excessive storage periods, or insufficient coordination with the works council and data protection officers could result in person-related log data being insufficiently protected. As a result, user profiles could be created that enable employees to be tracked over time.

Requirements

The following are the specific requirements of building block NET.3.4 Network Access Control. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

Additional roles are defined in the IT-Grundschutz Compendium. They SHOULD be filled insofar as this is sensible and appropriate.

Exactly one role SHOULD be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled with priority for this building block.

NET.3.4.A1 Justified Decision to Deploy NAC (B) [Institution]

The institution MUST fundamentally decide whether and to what extent NAC is to be deployed. The decision made MUST be documented together with a justification at an appropriate location.

If NAC is deployed, the following points MUST be appropriately addressed:

• Network areas and network components for which NAC is to be implemented
• Handling of internal end devices and external devices
• Consideration of NAC in the procurement of new IT systems

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

NET.3.4.A2 Planning the Deployment of NAC (S)

The deployment of NAC SHOULD be comprehensively and in detail planned. The planning SHOULD include at minimum the following aspects:

• Creation of requirements catalogs for end devices, access switches, and RADIUS servers
• Review and if necessary supplementation of IT asset management
• Creation of a specific NAC concept
• Definition of procurement, operational, and incident processes for NAC components
• Migration planning
• Monitoring and logging of the NAC solution
• Connection to security-relevant components (e.g., firewalls, virus protection, vulnerability scanners, system for central detection and automated real-time review of event messages)
• Additional functions such as profiling, end device compliance checking and integrity checking, as well as encryption at Layer 2 with MACsec

NET.3.4.A3 Creation of a Requirements Catalog for NAC (S)

The requirements for the NAC solution SHOULD be collected in a requirements catalog. The requirements catalog SHOULD cover the fundamental functional requirements and address all NAC components (e.g., end devices, access switches, and RADIUS servers).

The requirements catalog SHOULD be coordinated with all affected specialist departments, the responsible committees, and the institution’s policies. The requirements catalog SHOULD be regularly and as-needed updated.

If NAC components are procured, associated requirements SHOULD be taken into account.

The NAC solution SHOULD be tested based on the requirements catalog.

NET.3.4.A4 Creation of a NAC Concept (S)

Based on the decision from NET.3.4.A1 Justified Decision to Deploy NAC and the requirements for the NAC solution, a NAC concept SHOULD be created. The NAC concept SHOULD be coordinated with the segmentation concept in accordance with NET.1.1 Network Architecture and Design. Furthermore, at minimum the following aspects SHOULD be defined in the NAC concept:

• Network areas in which NAC is to be introduced
• Authentication and authorization
• Use of additional functions
• Configuration specifications for affected end device types, access switches, WLAN access points, and WLAN controllers
• Structure of the RADIUS infrastructure and the fundamental ruleset for NAC
• Connection to external security components such as firewalls or virus protection
• Connection to directory services

The NAC concept SHOULD describe all technical and organizational specifications. In particular, all relevant processes and the migration SHOULD be addressed.

The NAC concept SHOULD be regularly reviewed and updated as needed.

NET.3.4.A5 Adaptation of Processes for End Devices Regarding NAC (S)

For end devices to be integrated into the NAC solution, NAC SHOULD be appropriately taken into account in all relevant processes. In particular, the processes for commissioning, replacement, changes, and faults SHOULD be adapted.

A process SHOULD be defined for the central management of end devices for supplicant software, configuration, and identity features (e.g., certificates) required for NAC on end devices.

NET.3.4.A6 Definition of Emergency Processes for NAC (S)

If the chain of effect in NAC is disrupted, consideration SHOULD be given to temporarily deactivating the security mechanisms of NAC to an appropriate extent.

In the emergency measures defined in the emergency process, productivity and information security SHOULD be weighed against each other. The following options for emergency measures (RADIUS-down policies) SHOULD be considered:

• Existing connections are maintained through mechanisms such as temporary suspension of re-authentication, but all new login attempts are rejected, so that the planned security level is maintained.
• Dynamic assignment is suspended for new login attempts, and instead a fixed, predefined assignment of network segments by access switches is made, so that at least basic communication is possible.
• NAC is deactivated on the access switches or on individual ports of an access switch, so that unrestricted communication can continue.

RADIUS-down policies SHOULD be coordinated with the relevant security policies of the institution.

NET.3.4.A7 Use of Secure Authentication Methods (S)

End devices SHOULD use secure authentication methods according to the state of the art. End devices SHOULD be automatically authenticated based on certificates or access accounts.

Insecure authentication methods SHOULD only be used in justified exceptional cases and the decision SHOULD be documented.

NET.3.4.A8 Definition of NAC-Specific Roles and Permissions for the RADIUS Server (S)

In the roles and permissions concept for the RADIUS server, the various groups that need to access a RADIUS server due to NAC for administration purposes SHOULD be taken into account. This SHOULD be particularly carefully planned when a central RADIUS server is provided for the entire institution. At minimum, the following groups with NAC-specific access to the RADIUS server SHOULD be considered in addition to general IT Operations:

• the respective organizational units that administer access switches (RADIUS clients) for their network area
• the respective persons responsible for end device groups who manage the identities (e.g., MAC addresses) of their corresponding groups
• the first-level support that analyzes erroneous RADIUS releases and, if necessary, adjusts the corresponding approvals

NET.3.4.A9 Definition of an Adapted NAC Ruleset (S)

A NAC ruleset SHOULD be defined for the NAC solution that implements the NAC concept and specifies how end devices may access the network. For each end device or end device group, it SHOULD be defined whether unrestricted network access is permitted, whether access is denied, or whether only segments with restricted communication capabilities are reachable.

The NAC ruleset SHOULD also specify the basis on which access control is performed. For this purpose, the authentication methods used and the conditions for successful authentication SHOULD be defined for all end devices.

NET.3.4.A10 Secure Use of Identities (S)

Individual identities SHOULD be used for NAC authentication. Identities used by more than one end device SHOULD only be used in justified exceptional cases.

All information required for successful authentication SHOULD be secured against unauthorized access according to the current state of the art.

NET.3.4.A11 Secure Configuration of the NAC Solution (S)

All components of the NAC solution SHOULD be securely configured according to the state of the art. For this purpose, corresponding standard configurations and operational manuals SHOULD be developed and provided.

The specified and implemented configurations for the components of the NAC solution SHOULD be regularly reviewed and adapted if necessary.

On end devices, user permissions SHOULD be restricted such that they cannot manipulate the configuration parameters for the supplicant, cannot deactivate the supplicant, and cannot read out the keys or passwords for NAC.

For access switches or for individual ports of access switches, NAC authentication SHOULD only be deactivated in justified and previously defined exceptional cases. Technical measures SHOULD be used for this, supplemented by organizational measures if necessary.

NET.3.4.A12 Monitoring of the NAC Solution (S)

The central RADIUS servers and all access switches with an authenticator, as well as all other central services essential to the NAC solution, SHOULD be integrated into the most comprehensive and uniform monitoring possible. Supplementary to general monitoring according to OPS.1.1.1 General IT Operations, all NAC-specific parameters that ensure the functionality of the NAC solution or the corresponding services SHOULD be monitored.

In particular, the availability of the RADIUS protocol SHOULD be checked. For this purpose, RADIUS requests to active accounts SHOULD be generated to check the entire NAC chain of effect including the external directory services.

For the access switches, the NAC status SHOULD be incorporated into monitoring in order to detect deactivation of NAC.

Deviations from defined states and threshold values SHOULD be reported to IT Operations.

NET.3.4.A13 Creation of Validation Specifications for the NAC Configuration (S)

Validation specifications for the NAC solution SHOULD be created to ensure that the NAC components adequately implement the NAC concept. The validation specifications SHOULD in particular take into account the different functional details for the various NAC components.

Validation SHOULD be carried out as a target/actual comparison regularly and as needed for the central NAC components and the access switches.

NET.3.4.A14 Implementation of Additional Measures When Using MAC Address Authentication (S)

End devices that cannot be authenticated using a secure EAP method and are identified based on their MAC address SHOULD NOT be classified as trusted end devices. Network access SHOULD be restricted to the necessary minimum.

For this purpose, additional measures such as the use of communication restrictions or subsequent end device profiling of end device activities SHOULD be implemented.

NET.3.4.A15 Connection of Virus Protection to the NAC Solution (S)

Every end device SHOULD be checked for malware before it is connected to the institution’s network and before it accesses IT systems of the institution. For this purpose, appropriate virus protection SHOULD be coupled with NAC authentication and authorization for the NAC end devices.

If the virus protection program reports malware, the NAC solution SHOULD respond with appropriate measures.

NET.3.4.A16 Logging of Events (S)

Supplementary to OPS.1.1.5 Logging, status changes to NAC components and all relevant NAC-specific, potentially security-critical events SHOULD be logged. In addition, all write configuration accesses to the central NAC components SHOULD be logged.

It SHOULD be defined which log data is captured with what level of detail and which data is consolidated on a central logging instance.

Log data SHOULD ONLY be transmitted via secure communication paths.

Security-critical events such as RADIUS-down or an unusual number of RADIUS requests SHOULD trigger an automatic alarm.

NET.3.4.A17 Positioning of the RADIUS Server in the Management Area (S)

The RADIUS server SHOULD be positioned in a protected network segment within the management area (see NET.1.1 Network Architecture and Design). Communication requests to the RADIUS server SHOULD only be permitted from trusted sources. These SHOULD be restricted to a minimum.

The RADIUS server SHOULD NOT communicate directly with end devices but exclusively via the authenticator on the access switches. Requests from access switches SHOULD only be accepted from the common management network segment.

NET.3.4.A18 Documentation of the NAC Solution (S)

The NAC solution with all NAC components SHOULD be appropriately documented.

The documentation SHOULD at minimum show on which components and end devices NAC is used with which parameters and what dependencies exist between the components. The ruleset for authentication and authorization that exists in software code SHOULD also be additionally documented in simplified, understandable form. Furthermore, the configuration of all NAC components SHOULD be comprehensively documented, categorized if necessary.

The documentation SHOULD be updated with every change and kept current at all times. The currency of the documentation SHOULD be regularly and as-needed checked.

NET.3.4.A19 Proper Management of Identities for Authentication (S)

All identities that enable network access to the institution via NAC SHOULD be appropriately protected and managed. For this purpose, at minimum the following points SHOULD be defined:

• Handling and protection of certificates
• Checking, blocking, and deletion of identities no longer in use
• Process and interfaces for blocking an identity

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered when there are high protection needs. The specific determination is made within the framework of an individual risk analysis.

NET.3.4.A20 Use of MACsec (H)

Data integrity SHOULD be ensured for every data packet. Furthermore, consideration SHOULD be given to encrypting this data. MACsec according to IEEE 802.1AE SHOULD be used for this purpose.

Access switches and end devices that do not support MACsec or for which MACsec is not to be set up SHOULD be recorded. For these, it SHOULD be regularly checked whether the reasons for exclusion still apply.

NET.3.4.A21 Use of End Device Compliance Checking (H)

Before an end device is connected to the institution’s network and before it accesses IT systems of the institution, it SHOULD be checked whether it meets the institution’s compliance requirements (compliance check).

For each end device, it SHOULD be defined which requirements the end device must comply with. End devices that do not meet the institution’s compliance requirements SHOULD only be allowed access to the institution’s network with strong restrictions.

The NAC solution SHOULD be connected to a tool for compliance checking that assesses the status of the end devices and reports it to the NAC solution. On this basis, the NAC solution SHOULD control how end devices may access the network.

NET.3.4.A22 NAC Authorization with Microsegments (H)

End devices with similar requirement profiles and identical protection needs SHOULD be assigned to separate network segments via NAC.

Furthermore, consideration SHOULD be given to whether NAC implements microsegmentation of the end devices to be authorized.

NET.3.4.A23 Use of Standalone RADIUS Servers for Different Network Areas and Functions (H)

Dedicated and standalone RADIUS servers SHOULD be used for NAC. Other functions such as VPN access control SHOULD NOT be implemented on a shared RADIUS server together with NAC functions.

Additionally, consideration SHOULD be given to providing dedicated and standalone RADIUS servers for different networks. In particular, separate RADIUS servers SHOULD be considered to separately secure office and production end devices or LAN and WLAN end devices.

Furthermore, consideration SHOULD be given to establishing standalone RADIUS servers for individual network or functional areas.

NET.3.4.A24 Use of Secure Protocols Between NAC Components (H)

For communication between the central NAC components, protocols that are considered secure according to the state of the art SHOULD generally be used. For communication between the RADIUS server and any directory service used, only secure protocols SHOULD be used.

Furthermore, consideration SHOULD also be given to whether secure protocols should be used for communication between the RADIUS server and access switches.

NET.3.4.A25 Integration of the NAC Solution into Security Monitoring (H)

The NAC solution SHOULD be integrated into security monitoring. This SHOULD be implemented at least for the central NAC components and for the other central services used by the NAC solution.

NAC-specific security events (e.g., frequent rejection of requests or multiple use of identities) SHOULD be incorporated into alerting.

If a system for central detection and automated real-time review of event messages is used for the institution’s IT, the central NAC components and, if applicable, the other central services SHOULD be integrated into it.

NET.3.4.A26 High Availability of Central NAC Components (H)

The central NAC components SHOULD be designed redundantly. All other central services essential to the functionality of the NAC solution SHOULD also be designed for high availability.

The parameters relevant to high availability SHOULD be integrated into monitoring and logging. Status changes and warning messages SHOULD be regularly checked and, if necessary, incorporated into alerting.

RADIUS-down policies, which ensure communication even when the RADIUS service has failed, SHOULD NOT lower the security level of the network.

NET.3.4.A27 Review of the Necessity for MAC Address Authentication (H)

Authentication via MAC addresses SHOULD only be used where technically unavoidable and where security policies permit it.

It SHOULD be checked in advance whether such exceptional cases are necessary. If this is the case, the exceptional cases SHOULD be restricted to the minimum scope.

The justification and the result of the review SHOULD be documented. They SHOULD be regularly and as-needed re-verified.

Additional Information

Good to Know

No additional information is available for building block NET.3.4 Network Access Control.