Features and Benefits

Take the Next Step

SCB is independent from the servers and clients, and difficult to compromise

Auditing is usually based on the logs generated on the audited server. This model is inherently flawed, as logs of interactive events are usually not too detailed, and there is no way to ensure that the logs stored on or sent by the server are not manipulated by an administrator or attacker. But SCB is an independent device that operates transparently, and extracts the audit information directly from the communication of the client and the server. This prevents anyone from modifying the audited information – not even the administrator of SCB can tamper the encrypted audit trails. SCB also generates detailed changelogs of any modification of its configuration.

Easy integration into your existing infrastructure

To make integration into your network infrastructure smooth, SCB supports different operation modes: bridge, router, and bastion mode. To simplify integration with firewalled environments, SCB supports both source and destination address translation (SNAT and DNAT).

Bridge mode

In Bridge mode, SCB acts as a network switch, and connects the network segment of the administrators to the segment of the protected servers at the data link layer (Layer 2 in the OSI model).

Router mode

In Router mode, SCB acts as a transparent router connecting the network segment of the administrators to the segment of the protected servers at the network layer (Layer 3 in the OSI model).

Bastion mode

Administrators can address only SCB, the administered servers cannot be targeted directly. The firewall of the network has to be configured to ensure that only connections originating from SCB can access the servers. SCB determines which server to connect based on the parameters of the incoming connection (the IP address of the administrator and the target IP and port).

Nontransparent operation

SCB can operate in nontransparent mode as well, extracting the address of the target server from the inspected protocol itself. Nontransparent operation is mainly used in Bastion mode, and simplifies the integration of SCB into the network infrastructure.

Integration to user directories

SCB can connect to a remote LDAP database (e.g., a Microsoft Active Directory server) to resolve the group memberships of the users who access the protected servers. Rules and policies can be defined based on group memberships. When using public-key authentication in SSH, SCB can authenticate the user against the key or X.509 certificate stored in the LDAP database.

Administrators and auditors accessing the web interface of SCB can also be authenticated to an LDAP database. RADIUS authentication (e.g., using SecureID) is also supported both for accessing the web interface, and also to authenticate the audited SSH sessions.

High Availability support

SCB is also available with high availability (HA) support. In this case, two SCB units (a master and a slave) having identical configuration operate simultaneously. The two units have a common file subsystem; the master shares all data with the slave node as soon as the data is received: every configuration change or recorded traffic is immediately synchronized to the slave node. If the master unit stops functioning, the other one becomes immediately active, so the protected servers are continuously accessible. SCB1000d and larger versions are also equipped with dual power units.

Available as a VMware virtual appliance

SCB is officially supported on VMWare ESX systems as a virtual appliance, which is mainly useful in virtual and cloud environments. Note that certain platform-specific limitations apply.

Learn more about the product feature areas as below

• New features
• Protocol control and audit
• Advanced authentication and authorization
• Forensics
• Managing SCB