Security Service Edge (SSE) is an approach to network security, promising seamless connectivity and protection for remote or office-based users and cloud applications. Does implementing SSE then negate the need for robust access management practices?
The short answer is no. While SSE offers significant access control capabilities, it’s important to understand its limitations and how it complements dynamic, fine-grained access management strategies.
What Is SSE and Why Use It?
SSE is the convergence of a few different technologies, including:
- Secure Web Gateways (SWGs): Monitor and filter web traffic to protect against malware, phishing, and other web-based threats. It inspects web traffic at the application level in real-time, applies URL filters, and inspects content for potentially malicious content. The same component often provides access only to authenticated users that use a device that is managed by the organization. This functionality is sometimes separately called out as “Zero Trust Network Access” or ZTNA
- Firewall as a Service: performs network level packet inspection, filtering and VPN functions
- Cloud Access Security Brokers (CASBs): These are gateways between corporate networks and cloud services. They enforce security policies through filtering and inspection (similar to SWGs) and provide visibility to cloud usage
As you can see, these technologies are mostly about network access control, which enables these components to detect whether a user is accessing cloud-hosted services from a permitted location and device, and has met the authentication criteria, whether they are downloading or exfiltrating data they should not be, and block them from accessing certain websites or parts of websites. This provides a secure baseline for organizations to filter out rogue traffic that may represent an attack, or the beginnings of an attack.
And as you can see, some SSE components provide protection at an application level, whereas other components function at the network level.
Access Management
Identity and Access Management (IAM) is a combination of authentication (the act of asserting a user’s identity) and authorization (the decisions about what that user has access to). Although the term “access management” is sometimes used to indicate all of IAM, for our purposes here I am only using it to refer to the management of the authorization part.
Access management is typically determined at an application level, even though it may imply network level access control. For example, a Wi-Fi router will authorize whether the user has access to the WiFi network at an application level, but the actual result of that enforcement is whether or not the user can use the Wi-Fi network itself.
Interplay Between SSE and Access Management
Traditionally, access management has been specified and enforced at a coarse-grained level (e.g. “users in the ‘network admin’ group have access to administrative features of ‘cloud platform’ service”). SSE components will make sure the user is accessing from a managed device in good standing, and is accessing the requisite cloud platform admin URL, but they will not have any opinion on what the user is accessing within that cloud platform
The Access Gap
Once an attacker has stolen a user’s identity or if the attacker is a genuine insider with malicious intent, they can trick the SSE into thinking they are legitimate users, and pass through unnoticed through SSE components since they are technically accessing legitimate resources as legitimate users. However, what they are doing with those resources may be disastrous (e.g. encrypting all data in order to ask for ransom). Traditional coarse-grained access management is also insufficient to prevent such attacks
Dynamic, Fine-grained Access Management
What is really needed is an access management strategy that can automatically fine-tune a user’s access to only those resources that are needed based on the user’s current task. E.g. Network admin Andi is permitted to access the S3 bucket “123” in the AWS platform because they are working on an open support case “ABC” that relates to that S3 bucket, and the case has been approved for exceptional access. Once the case is closed, or Andi is no longer working on that particular case, they lose their access.
SGNL
This is the core problem that SGNL solves with its Continuous Access Management platform. It provides a solution that works at enterprise-scale, through integration with existing business systems and data-centric human building-block readable policies that can be reused across various applications. Request a demo to see it in action!