The evolving security stack critical to a Secure Access Service Edge (SASE) journey is described by Security Service Edge (SSE), which includes fundamental platform requirements such as CASB, SWG, and ZTNA capabilities.
SASE is an architecture—more accurately, a long-term journey—that will revolutionise the way we think about security and networking. However, SSE, as part of SASE, is a collection of cloud-delivered security services that you can get and use right now.
Still, separating clear, advice-based information regarding SSE from the torrent of industry noise and marketing around both SSE and SASE can be challenging.
That’s why, Netskope has announced the release of its new book, Security Service Edge (SSE) for Dummies, the first SSE resource of its kind.
True to the world-famous Dummies series it now joins, this book is intended to be your practical, no-B.S. explainer for SSE, its importance relevant to concepts like SASE, Zero Trust, and secure digital transformation, and fundamentally, how to build and deliver SSE capabilities.
Successful implementation of SASE and SSE is much more than swapping out technology. Zero Trust changes some basic assumptions about how security works. In the on-premises, network-based model, the assumption is that the network is secure and we must verify a person’s identity before granting access. So, we trust the network and verify the user. The typical paradigm granted the person access to everything or nothing—“allow” or “block” were the only choices.
Zero Trust changes this model as follows:
- When a person requests access, that request is evaluated in the context of several conditions. Identity is one of them, but the system also considers where the person is, the time of day, the device, the type of network connection, and many other variables.
- The application to which the person is being connected is also part of that context.
- The desired service level is also an important factor. Is this a life-or-death use of an application or a video game played for fun?
- How the network path is protected may change based on the application being used. If someone is accessing their personal email account, an ordinary Internet connection is used, with Transport Layer Security (TLS) protection negotiated between their email server and email client. If a doctor is accessing patient records, a secure, encrypted, and authenticated path is established, regardless of the capabilities of the underlying network or application.
Based on this context, the confidence level of the person’s session is determined, and the person may be trusted either a little bit or a lot. A person requesting access at an unusual time from an unusual location to a highly-sensitive application (an instance of a low confidence level) likely will encounter a multi-step authentication process. The access granted may be limited to a small set of data and functions, and then in a read-only mode. A worker who’s accessing at their customary time from a secure location (an instance of a high confidence level) may get full access to all data and application capabilities.
Consider this example of a doctor accessing electronic health records via SSE that illustrates Zero Trust principles at work in SSE and how SSE helps bring Zero Trust principles to life:
- A doctor is carrying a facility-owned tablet as they treat a patient in the hospital. Based on the doctor’s identity, location, device, and other factors, the SSE determines it is safe to give the doctor full access to the patient’s records.
- The doctor walks across the street for a cup of coffee. They pop open a personal laptop, connect to the shop’s network, and try to access patient records. The SSE recognizes the doctor but identifies that the hospital does not own the laptop and that the laptop is on an unknown network. The doctor is allowed to view and comment on the records but can’t alter the data.
- The doctor is eating dinner at home; alerted to a crisis, they log their child out of Minecraft to use the family PC to access the patient’s records. The SSE recognizes that this computer is less secure than the hospital’s tablet. Instead of denying access, the SSE provides a series of prompts that enable the doctor to verify their identity further and frame the nature of the reason they need access. The SSE then provides the doctor with a secure set of resources to respond to the emergency —for example, inside an isolated browser session under control of the SSE.
Within network security, you often hear the term Zero Trust Network Access (ZTNA). ZTNA is an excellent choice for augmenting your virtual private network (VPN) to accommodate more remote access scenarios. With ZTNA, users don’t receive access to an entire portion of a network that could allow connections to many services. Instead, ZTNA grants the worker a connection only to the application they’re seeking to use and—as shown in our doctor story—only the minimum access needed to perform the task at hand.
Implementing SSE using Zero Trust principles shrinks the attack surface and is far more data-driven, thus greatly improving the overall security posture. The level of risk presented by a person, an application, or a website undergoes continuous reevaluation. Security is adapting in real time based on changes in context.