IP whitelisting is commonly used and treated as a security measure to reduce the attack surface of sensitive resources. Over 30% of Secure Access Cloud customers are using the IP address restriction to limit access to corporate resources from a specific set of IP addresses, while still performing strong user authentication.
Although very effective for specific scenarios, leveraging IP addresses as a ‘definitive’ security measure to validate a connection is trusted is not recommended and maybe abused by a malicious insider or a sophisticated attacker.
In this post I will review the pros and cons of 3 specific IP whitelisting scenarios as well as show potential alternative approaches to increase security while improving user experience.
Scenario #1 - Enforcing ‘office only’ access to cloud resources
Restricting the access to corporate resources such as cloud-hosted environment on platforms such as Azure, AWS or GCP or SaaS resources on platforms such as Box, Salesforce or Office365 to a specific IP address (or IP range) significantly reduces attack surface. In this scenario the IP addresses will represent the public IP address of the corporate office locations.
This any attempt to connect to your environment will be blocked at Layer3, without being given the opportunity to even present a username/password, unless the connection was initiated from the office network. This prevents potential brute force attacks, reconnaissance of your environment as well as a potential exploitation of vulnerable solutions from anywhere else on the Internet.
This approach prevents your users from connecting remotely.
However, remote connectivity may be a business requirement (especially for a business relying on remote workers, or when employees are working from home and need to access the environment.)
In order to address this issue organizations tend to provide remote access to their office network via VPN and then allowing connectivity to the cloud environment with ‘office-only’ IP whitelist rules enforced.
In this case the level of security provided by IP whitelisting overshadowed by the exposure of the entire corporate AND cloud networks to the end-users once VPN’d to the office with the VPN service accepting connections from anywhere on the internet.
This means that if an attacker has managed to leverage stolen credentials to authenticate to the VPN, or leverage the myriad of VPN exploits available (as done by Iranian hackers and discussed at https://www.zdnet.com/article/iranian-hackers-have-been-hacking-vpn-servers-to-plant-backdoors-in-companies-around-the-world/) they have full access to both the corporate network, as well as the cloud based resources.
A better approach to IP whitelisting is restricting access to the resources via a solution which offers strong user and device authentication.
For example requiring a device to present a client certificate before being provided with access to corporate resources will prevent an attacker from being able to attempt bruteforce or exploit vulnerabilities as no access should be granted before successful authentication.
Both Secure Access Cloud (Symantec’s SDP solution) and CloudSOC (Symantec’s CASB solution) support device authentication via multiple methods to prevent unauthorized access to corporate resources in the cloud, on premises or in hybrid environments.
Scenario #2 - Ensuring traffic is going through inspection
In this approach the IP whitelist rule contains the IP address or IP range of your cloud or on-premise inspection point, such as a forward proxy used by CASB or Secure Web Gateway solutions such as Symantec’s CloudSOC and WSS solutions.
Blocking any traffic which didn’t pass through the inspection point reduces the chance of malicious or unauthorized access. In addition it ensures the organizational policies (such as a DLP or specific activity policies) are enforced.
The audit data gathered by these solutions could in turn be used to detect risky activities and may serve as an additional data source for your SIEM or UEBA solution.
Just as with the first scenario, if remote access to the office network is provided via a VPN solution, the level of security provided by IP whitelisting overshadowed by the exposure of the entire corporate AND cloud networks to the end-users once VPNed to the office.
In addition, the IP addresses of the cloud solutions may change or increase over time as today’s cloud infrastructure is dynamic by nature, and scales up and down automatically.
And even if using static IP addresses, these addresses may represent a multi-tenant environment with several of the solution’s customers are using.
Another potential issue has to do with configuration which prevents an end-user from browsing the internet without VPNing into the office. This introduces latency, complicates the user experience, and increases the infrastructure requirements for both the VPN as well as the proxy on-premises.
Prefer cloud or hybrid deployments of the inspection points. Look for a cloud based secure web gateway solution such as Symantec WSS which can seamlessly integrate with an on-premises solution, such as ProxySG to address the remote user scenario without requiring a VPN connection into the corporate network.
Prefer access management solutions which can provide access via a device compliance check, which will ensure the device is compliant with the corporate policy (including passing through the corporate enforcement points).
Scenario #3 - Use known IPs to provide access to 'trusted users'
An IP is NOT an identity!! IP addresses change (expected or unexpected) which causes the IP whitelisting rules to become outdated.
The challenge of reviewing, purging and maintaining IP lists and rules when attempting to create a ‘per-user’ authorization is challenging, and with the growth of the environment the number of users and rules it becomes impossible to stay ahead of the changes.
Rely on authenticating the users rather than machines or dynamically-assigned IP addresses, preferably via your existing authentication provider.
A common practice today is performing strong authentication. A strong authentication differs from 'password only' authentication in the sentence that it is based on something you know (like your password) and something you have (like your smartphone or a security token such as Yubikey). Another form of authentication being commonly used today is 'something you are' in the form of a face or fingerprint recognition.
Prefer access solutions which can integrate with your identity provider and provide strong authentication (or support the IdP based strong authentication mechanisms) when providing access to corporate resources.
The use of IP whitelisting as an additional 'validation' to reduce attack surface is useful as well as a basic policy ensuring the end-users traffic destined to your cloud services is going through inspection.
Never rely on using IP whitelisting to authenticate users to the environment. Always prefer strong user authentication and device identification to identify and authenticate users and devices coming into your cloud environment.
We encourage you to share your thoughts on your favorite social platform.