By now, you have likely heard the term “Zero Trust”. From tech seminars and industry events to webinars and whitepapers, it is popping up everywhere. CISOs and CTOs are constantly inundated with calls and messages from different vendors proclaiming different ways their solutions can help them transition to this security model. At this year’s RSA Conference, there was a deluge of vendors touting Zero Trust security solutions and I could only imagine being in a CISO or CTOs shoes as they debate the right solution for their organization.
In deliberating the right Zero Trust approach, it’s important to not lose sight of the principles behind the security model. Some of these are that trust is not a property of location, one must always verify every user, device and network flow on the network and never trust any of them, and policies must be dynamic and calculated from as many sources of data as possible. In addressing lateral threat movement within the private network, Zero Trust pushes for stricter identity verification for every person and device trying to access private resources.
Legacy access solutions have focused on building and enforcing policies around network identities of users and devices (i.e IP addresses, vlans, etc.). While these have served their purpose over the years, they are not aligned with current realities. Users are diverse, mobile and accessing internal resources using different forms of devices. In addition, there are also non-human controlled devices accessing internal resources. All of these serve as entry points for threats to infiltrate the network and exfiltrate sensitive data.
There’s a need for application access controls/policies to be adaptive to the changing threat landscape and aforementioned trends around users and devices. Imagine a user utilizing a legacy remote access solution. In this scenario, he or she is a member of the sales organization and can access the network from any location. If this person uses his or her credentials to access from a different continent within an hour of the last access, the remote access solution may not be sufficient in determining the user is legitimate. In this case, the remote access solution allows access to finance department applications leading to the ability to download payroll data on a Saturday night at 11pm. This is clearly not an acceptable situation. In another scenario with the same salesperson, the remote access solution is also insufficient in restricting access to sensitive sales data from the users device if it is affected by an OS vulnerability. If this device vulnerability is exploited by malware, the access solution is not able to inspect traffic from the device to determine what data is being stolen.
However, an Identity-aware proxy(IAP) can! Originally touted by Google with its BeyondCorp initiative, the identity-aware proxy is a broker that performs adaptive access controls using digital identities. It not only authenticates and authorizes each user’s access to each application, it also sits inline for the data plane as well. As a result, the user gets full layer 7 security and control of every request to your application. And because it’s in the cloud, it can be in-line to the datacenter, IaaS and SaaS applications. The IAP will capture signals from devices that allow for stricter access control for users accessing resources on a private network.
So for the user mentioned previously, the IAP will track his or her location and force a two-step verification to ensure it is the user attempting to login. The IAP, via integration to user data stores, will also know the user is part of the Sales department and enforce policies that prevent unauthorized access to certain applications, e.g. the applications from finance department as previously mentioned. Time of day policies would allow the IAP to ensure that user is unable to download that payroll data at 11pm on a Saturday night. Signals containing important device information (such as OS version, disk encryption, firewall and patch status etc) would be received by the IAP and used in assigning a risk score to the device. This risk score would be used by the IAP to enforce strict access control to internal applications and prevent any devices from being exploited by malware and used as an entry point into the internal network. Also, with layer 7 visibility into user traffic, IAP is able to inspect user traffic and prevent network layer attacks (DDOS) or application layer attacks such as SQL injections, XSS, etc. Plus, where the user may have experienced poor performance of applications when accessing for remote locations (e.g. a different continent), the IAP is able to optimize the connectivity at network, transport and application layers to provide a fast and seamless experience for the user accessing said applications.
Interested in learning more about an Identity Aware Proxy Solution? Read more about the Akamai approach at www.akamai.com/zerotrust.
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Chinedu Egonu. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/A20r-4j7xUo/why-identity-aware-proxies-are-key-to-adaptive-access-controls.html