Securing the Network

To implement a secure ActivID AS authentication system, it is important to understand the communication dependencies between ActivID AS and other components within the overall network system.

Critical Warning about Cookies

All browsers MUST use cookies to avoid becoming liable to session hijacking. For further information on Cookie Theft/Session Hijacking, go to https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Cookie_Theft/Session_Hijacking

Recommended Network Deployment

The following figure illustrates the recommended network deployment and typical communication flows.

As illustrated in the previous figure, network deployment can mean a configuration that requires connectivity with a variety of external components. ActivID AS must be connected to, and accessed by, network devices and clients. This requirement makes those devices and clients vulnerable to cyber-attacks that might be targeted at the ActivID AS hardware and its related software.

The best way to protect ActivID AS and related dependent entities from network-based cyber-attacks requires a layered approach that is based upon the Open System Interconnection (OSI) model, which consists of seven layers. The layers relevant to the network communication are layers 2 to 4, specifically the Data Link, Network, and Transport layers. The following figure illustrates the seven layers of the OSI model.

Note: A detailed explanation of the OSI model is beyond the scope of these recommendations. The illustration of the OSI model is included for reference purposes only. HID Global assumes that the reader possesses an in-depth knowledge of the seven layers or is willing to access additional reference sources for this material.

Recommended Network Configuration

To prevent Layer 2 attacks, devices that are located on the same IP network must be unable to communicate with each other using the Data Link Layer. A separate network must be used for ActivID AS and related software, and this network must be separated both physically and logically from any other device.

In some network environments, the previously suggested level of separation is neither practical nor feasible. In such cases, ActivID AS should be protected at the Data Link Layer by using private Virtual Local Area Networks (VLANs). Using private VLANs (PVLANs) or using a separate physical network forces all communications to be routed, and thus pass through a Layer 3 device (such as a router, firewall, or a Layer 3 switch).

Note: Standard network switches operate at the Layer 2 level in the OSI model, while a Layer 3 switch is a high-performance device that performs network routing and can support the same routing protocols as network routers do.

Every device on the network infrastructure should be configured with Access Control Lists (ACLs), including switches, firewalls, and routers. ACLs can be customized to adapt to the environment in which they are used, and should be implemented using the minimum privileges required to perform the desired tasks. The ports required for ActivID AS communication are listed in the following table.
ActivID AS and related software should be deployed with two separate network interfaces – one interface which is made public for ActivID AS operators and users – and another interface used for connections with back-end components and potential back-up systems.
Intruder Detection Systems (IDS) should be deployed on both network segments that are connected to ActivID AS. Host-based Intrusion Protection Systems (IPS) should be installed on ActivID AS.

Rate Limiting and Denial of Service Prevention

ActivID AS does not embed a rate-limiting feature. It is recommended that you deploy it behind a reverse proxy, load balancer, API Gateway or Web Application Firewall that provides this capability to prevent resource starvation and Denial of Service attacks.

The rate limits to set depend on the deployment architecture and the workflows that ActivID AS will serve. For example, a customer using API-based or RADIUS authentication flows, would need to allow hundreds of requests per second (or more) as the requests come from a small number of client applications that manage the connections of all the end users.

However, a customer mainly using ActivID AS for Single-Sign On, SAML, or Push Authentication should consider much lower threshold as the end users are connecting to the ActivID AS without intermediary. In the latter case, it is suspicious for a single client to request many authentications in a very short period of time.

In general, it is advised to define a configuration that differentiates System Users (that is, RADIUS front-ends, Service Providers, Open ID clients, etc) that are typically in an internal network and need a high rate and burst to operate, from end users (connecting via browsers to access the ActivID Authentication Portal and HID approve apps) that might come from the internet and should be more strongly rate-limited.