3 steps for getting started with security service edge
Before getting started with security service edge (SSE), formulate a migration strategy. Check out these three expert tips for tackling SSE with maximum efficiency and ease.
Security service edge is a new approach for securing data, apps and devices regardless of where they are located.
Think of SSE as a scaled-down, security-only version of Secure Access Service Edge (SASE). SASE encompasses a huge range of security and networking services that, in practice, can be an excessively heavy lift for many organizations.
SSE offers three of the same major security technologies as SASE does:
SSE omits SASE's other capabilities, most notably its WAN-related services. By implementing SSE instead of SASE, organizations can achieve many of the same security benefits while having easier and faster migrations.
Achieving SSE requires having CASB, SWG and ZTNA technologies in place, each of which involves its own significant planning and migration efforts. Plan to migrate users, devices, data and apps to SSE in phases -- as would be advisable for any major technology update. Design and implement a small pilot first to identify and address any major issues. Then, expand that pilot incrementally to include additional users, devices, data and apps.
One note of caution: Generally, an organization will need to finish migrating its users' on-premises and cloud-based services and applications before enjoying SSE's full security advantages. One of the main benefits of SSE is that services and apps are no longer open to direct contact from anywhere. Instead, users access them via SWGs, which act as intermediaries that apply security policies and monitor for threat activities. CASBs and ZTNA provide further security benefits, such as authentication, access control and behavioral analysis.
It's important to keep the migration period relatively short, if possible, to achieve stronger security sooner.
Until all users have migrated to SSE, however, the services and applications they access will remain more exposed and at higher risk of compromise. It's therefore important to keep the migration period relatively short, if possible, to achieve stronger 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 may frequently check device health, user behavior and other usage characteristics. In general, this is overwhelmingly positive for the organization's security posture, though it might cause some unpleasant surprises and operational disruptions at first.
Whenever feasible, especially in initial pilots, run the SSE in a monitoring-only mode, without enforcement, to see what the technology would have blocked and why. This will often unearth existing security policy violations, and in some cases will 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 which CASB, SWG and ZTNA technologies it includes, an SSE might have one or more gaps in its security controls. Fortunately, it's generally relatively easy to fill those gaps by acquiring additional network security services. Any of the SASE security controls not already part of SSE, such as firewall as a service or data loss prevention, are obvious candidates to consider.
If an organization's SSE would require multiple additional controls, it may be best to take a step back and consider if a full SASE implementation would be better. There are certainly advantages to acquiring one SASE platform instead of integrating several disparate SSE and SASE components. But if SASE is too large or expensive a proposition, adding individual controls to SSE is often still a preferable approach.
