Cyber Security Insurance Requirements
Multi-Factor Authentication On The Internal Network
Become compliant, same-day, to new Cyber Insurance requirements for on-site or remote multi-factor authentication to privileged servers, routers, resources with a Agilicus AnyX identity-aware proxy. Multi-Factor Authentocation on the Internal, Local Network, Any Device. Want to learn more?
Risk Reduction Insurance Controls Overview
Like many companies, you have implemented multi-factor authentication in your VPN. This protects you from external threats related to password guessing and spear-phishing. However, it does not protect you once the VPN is up (a field called privileged access management). Nor does it protect you from users who are physically connected to your network (a field called lateral traversal).
Implementing Multi-Factor Authentication on the local network is more challenging than the single choke point of the VPN. You must contend with a variety of devices and methods. Your managed switches, routers use SSH with a single password. Your voice switch has a web-based interface with a local user set. You have a set of servers which use a combination of Remote Desktop (RDP) and Virtual Network Computing (VNC) interfaces for graphical administration.
A new urgent business requirement is handed to your team: in order to renew your CyberSecurity Errors and Ommissions insurance, you must have multi-factor authentication for any privileged access. Your VPN is no longer enough since local administrators bypass it. As you madly scan changelogs on RADIUS and TACACS+ for your network devices, your colleague is mired in the documentation for the miscellaneous servers and web-based management devices and applications. How can you become compliant, rapidly, without a lot of risky rework and upgrades?
Zero-Trust Identity-Aware Web-Application Firewall And Proxy
Imagine if you had a proxy that participated in your existing authentication without configuration. Single-sign-on using your existing Office 365, Azure Active Directory, Google Workplace, etc. It would allow seamless access to each resource, regardless of location (local network or remote). It would enforce multi-factor, or, participate in the existing multi-factor inherent in your existing authentication system. A user would ‘remote desktop to server A’, be presenting with a challenge to prove who they were, and then, be instantly connected.
Imagine if this same proxy would operate seamlessly on Remote Desktop (RDP), VNC, SSH,and HTTP (as well as arbitrary TCP). In addition it could handle a shared directory natively. This would cover most requirements.
- Who. Who is this user? This is called Authentication. As part of this flow a second-factor is required.
- What. What is this user allowed to do? This is called Authorisation. It is more fine grained than ‘allow all’ (which is the VPN approach), instead it is ‘allow-read to this file between 2 and 4am’ granular.
- How. How do we get the user to the resource? This is called Access. It works from any network, without a VPN.
Enforcing Multi-Factor Authentication
Multi-factor authentication dramatically increases security. The risk correlation between someone guessing your password, and someone stealing something you have is low. In a nutshell, multi-factor is at least two of “something you know, something you have, something you are”.
Different methods exist to enforce multi-factor. They range from code-generators (TOTP, e.g. Google Authenticator, Authy), push-based notification (WebAuthN, WebPush, SMS), and device-based (YubiKey, in-device TPM, etc). In the Agilicus AnyX platform you can choose any of these individually to satisfy your needs.
Enforcement occurs as often as needed. Some policies are every access, some are good for e.g. 4-hours per device, etc. The user will be seamlessly be prompted to provide their second factor as needed.
As part of any compliance program you must prove “we did what we said”. In practice this means an audit on each and every access transaction. This is an area a VPN is very weak: you get a record saying “user X was assigned an IP”, but nothing saying “user X then attempted unsuccessfully to sign-in to remote desktop Y”.
These audit records might be sent to a SIEM, or merely be used for day-to day user diagnostics and tracing. Or perhaps even some day on a suspected breach to figure out the extent.
A fine-grained audit program with ongoing monitoring reduces risk, increases compliance.
Quick compliance is possible with an identity-aware proxy. Multi-factor authentication on-behalf of each resource provides fine-grained audit, precise control. Using existing identity providers means authentication is single-sign-on, and convenient for users, leading to easier adoption.
A Zero-Trust Network Architecture need not be a rip-and-replace, it can be a “why didn’t we do this earlier” after the first day.
Would you like to discuss? The Chat icon on the left is staffed by our team, or