3 steps to get started with Security Service Edge

The security services edge is a new approach to securing data, applications and devices, wherever they reside.

Think of SSE as a small, secure-only version of Secure Access Service Edge (SASE). SASE encompasses a wide range of security and networking services that, in practice, can be an excessively heavy burden for many organizations.

SSE offers three of the same core security technologies as SASE:

SSE omits SASE’s other capabilities, including its WAN-related services. By implementing SSE instead of SASE, organizations can gain many of the same security benefits while having easier and faster migrations.

Consider the following three practical tips for getting started with SSE.

1. Plan a gradual SSE migration

Achieving the ESS requires the implementation of CASB, SWG, and ZTNA technologies, each involving its own planning and migration efforts. Plan to migrate users, devices, data, and applications to SSE in phases, as would be advised for any major technology update. Design and implement a small pilot project first to identify and resolve major issues. Then expand this pilot incrementally to include additional users, devices, data, and applications.

One caveat: Typically, an organization will need to complete the migration of its users’ on-premises and cloud services and applications before realizing the full security benefits of SSE. One of the main advantages of SSE is that services and applications are no longer open to direct contact from anywhere. Instead, users access them through SWGs, which act as intermediaries that enforce security policies and monitor threat activity. CASBs and ZTNAs provide other security benefits, such as authentication, access control, and behavioral analysis.

It is important to keep the migration period relatively short, if possible, to strengthen security sooner.

However, until all users have migrated to SSE, the services and applications they access will remain more exposed and more at risk of compromise. It is therefore important to keep the migration period relatively short, if possible, to achieve enhanced security sooner.

2. Monitor first, then enforce policies

SSE components, especially ZTNA, tend to be much more restrictive than the legacy security technologies they replace. For example, SSEs can frequently check device health, user behavior, and other usage characteristics. In general, this is extremely positive for the organization’s security posture, although it can lead to unpleasant surprises and operational disruptions at first.

Whenever possible, especially in initial pilots, run the SSE in monitor-only mode, without an app, to see what the technology would have blocked and why. This will often reveal existing security policy violations and, in some cases, indicate where an SSE policy may need to be relaxed – at least temporarily – to account for real-world behavior.

3. Identify controls to add to SSE

Depending on the CASB, SWG, and ZTNA technologies included, an ESS may have one or more gaps in its security controls. Fortunately, it’s usually relatively easy to fill these gaps by acquiring additional network security services. Any SASE security controls that aren’t already part of SSE, such as Firewall as a Service or Data Loss Prevention, are obvious candidates to consider.

If an organization’s HSE requires several additional controls, it may be best to take a step back and consider whether a full SASE implementation would be best. There are certainly advantages to acquiring a SASE platform instead of integrating several disparate SSE and SASE components. But whether SASE is too big or too expensive a propositionadding individual controls to SSE is often still a preferable approach.

Source link