What Is the Role of Security Architects in SASE?

Imagine your organisation is launching into an ambitious network and security upgrade programme. Senior staff are talking about Secure Access Service Edge (SASE), Security Services Edge (SSE), Zero Trust Edge (ZTE) and so forth. As a security architect, what contributions would you make to such a programme?  

Here are some considerations derived from our recent engagements in this area, grouped by our phases of network transformation. This guidance is weighted towards the front-end preparations because they will cascade into the later execution stages. 

Understand

Gartner defined SASE as combining “network security functions … with Wide Area Network (WAN) capabilities (i.e., Software-Defined WAN) to support the dynamic secure access needs of organizations.” [1]

Depending on the local understanding of SASE, SSE and ZTE, the scope of the programme may eventually cover most network and network security services. In some cases, the scope can sometimes also consume areas like endpoint management. In all cases we have seen, consolidating siloed security services is either a driver or the key benefit being envisaged. This can reduce overheads and licensing for a stack of security appliances or subscriptions. It is similar to the trend of multiple endpoint security capabilities being consolidated in the Extended Detection and Response (XDR) market segment. 

At this phase our example Security Architect, Alice, is rigorously analysing the business drivers, or collecting them if they are not explicit. They can be ‘push’ types like datacentre exit, work from home demands, or a ‘pull’ from business leaders or new opportunities to enable any user to access any application, anywhere. These goals can subsequently determine the security drivers and prioritised attributes that the business actually wants from the solution, and provide a scorecard for comparing vendors.

As well as considering the risks and benefits of the proposed solution, Alice should collect the risks of doing nothing and the risks in delivery, e.g. potential disruption to service desk, forward proxies, the existing Citrix setup or IP allowlisting. Top dependencies or assumptions for this programme are a directory of strongly-attested identities and a configuration management database. As well as risks, enablers for security and the business should also be considered. These are the opportunities available for flexibility, consolidation, greater resilience, cost saving and standardisation. Some of these second-order benefits may not have been recognised – or could be overstated. 

Assess

With the strategy in place, it is time to move to tactical detail and only after that select an architecture and assess vendors. Guidance from researchers Gartner is not to ‘Confuse technical with enterprise architecture…Focus on strategy (business and information architecture) before addressing tactics (solutions and technical architecture)’. [2]

The dominant approach for analysing needs is currently top-down, looking from the user and application layer in the OSI model down to the implications it means for the physical layer, but for realism Alice will bear in mind the bottom-up constraints, e.g. availability of vendor Points of Presence in target regions of the globe, and the costs her organisation has invested in existing MPLS contracts and their lifespan.

In assessing solutions that deliver the logical security services, the security architect will mostly be advocating for the least complexity possible. The industry consensus is in favour of a platform approach rather than multiple best of breed vendors being integrated (which brings more overhead), much like XDR. Thinking ahead, Alice notes that a SASE programme with a ‘single pane of glass’ might present an opportunity to reduce the operational complexity, number of service providers or even bring capability in house. 

At this phase, Alice is ensuring difficult conversations take place that assign responsibility for security services to the various component tools. Nowadays, services like antimalware or authorisation can occur at many levels and an increasing number of software tools have such add-on features. There is a difference between layered controls (good) and duplication of role, control gaps, or contention between software (bad!). A RACI-type matrix is advisable here to identify what software does what. This is reflected in Gartner’s Cyber Security Mesh Architecture. The result can inform the enterprise security controls framework, either imagined outside-in from external threats into the data asset, or imagined by control type – preventive, detective, corrective.

There are many non-functional requirements which are not security, but which might lack a champion and Alice may need to pick these up: portability, traceability (vendor’s transparency in logging and auditing), reliability, training requirements and integrability. On integration, the top API integrations to focus on are between: 

The network underlay and overlay providers (if different);

The SDWAN provider and SSE provider;

All components and IdP, ePKI, and MDM [3];

The SSE provider to SIEM/SOAR [4], to enable the Zero Trust tenets of dynamic policy and maximum information collection and to support security operations and incident response (assume breach). [5]

It is a truism that Zero Trust is a journey, and that SASE is not a single product. So Alice takes particular interest in the roadmap of when each solution is planned to come online. Alice tries to influence it by identifying dependencies and contributing cost/benefit input to the sequencing based on risk reduction. For example, a no-brainer first step in the remote working environment is secure remote inbound access, then a close second is usually securing the high threat from outbound access, using a Secure Web Gateway. After those, CASB, FWaaS, or Web API Protection as a Service may be most suitable. [6] Some flexibility is advisable throughout because sometimes the eventual vendor can provide these included in the same SKU, if an All-In-One Zero Trust Edge provider, a term used by Forrester. [7]

Design

Turning to the transitional and target architectures, Alice participates in continually iterating these. We strongly advise clients design architectures in the order: conceptual, logical then physical. The security architect may also represent helpful views that other architects do not, such as domain interrelationships, data flow diagrams, end-to-end UML authentication flows, trust relationships and threat modelling representations of the ecosystem using a tool like Threatdragon. [8] These discretionary activities can identify and avoid security antipatterns like service chaining. 

She participates in vendor assessment and workshops with potential providers to understand their recommendations, weigh up the solution and agree the ongoing management, whether outsourced or more in-house.

Planning of the transition of existing to new providers should be given close attention, including ensuring there is not security regression whilst two regimes are in force for routing, access or authorisation. The programme design should include security-based use cases to be validate in pilots. In our experience, unforeseen high-priority security issues or risks can surface during the programme, e.g. flat OUs or VLANs so the programme should expect security resources to be diverted at times to resolve these.[9]

Deliver

If a systems integrator or Managed SASE provider has been selected, this provides the opportunity to have co-managed network and security capabilities. Naturally the Request For Proposal and contract should be written to maximise the benefits that these providers bring like deep expertise and faster responsiveness to released vulnerabilities, and to mitigate the drawbacks like lack of control of their staff and infrastructure, and costs of change, e.g. firmware upgrades. 

Alice can learn a lot from how her organisation has managed previous security rollouts, for example PKI which in some cases was wrongly treated as set-and-forget or was too heavy-handed – reasonable exceptions were not approved where it was unsuitable. 

At some of our recent engagements with enterprises we see aspects of programme rollouts devolved to subsidiaries and brands. In these circumstances clear playbooks and reference patterns at the level of physical and component architecture (the ‘Builder’s and Tradesman’s Views’) can assist autonomous IT teams to make the changes confidently.

Manage

To ensure security operations are set up for success, Alice now ensures that the new SASE features are providing at least as much useful telemetry as the retired services: VPN concentrators and potentially Next Generation Firewalls in branch locations. If a proxy-based TLS interception capability was phased out in the programme, compensating controls like session-key forwarding and traffic fingerprinting may be required.

Alice also ensures the different planes of the solution are being monitored and risk-managed on an ongoing basis: the Management Plane that configures the network and security services, the Control Plane of decision points and policies, and the Data Plane of traffic itself. The SOC need training, potentially from the vendor or an external specialist, in handling the new telemetry, updating playbooks and use cases.

Final Thoughts

Here is our best practice guidance for those looking to begin their own network and security upgrade programme. 

• Engage security architecture expertise early in the planning process.
• Remain flexible about the means to achieve fixed ends, as programme items and products themselves will evolve.
• Although the strategy is an overall security improvement, look and test for security regressions during tactical changes. 
• Decide on what minimum set of architecture views and documents are needed to support the project.
• Trace the particular requirements and roadmap items to the business goals that justify them.
• Think about the long term: network and security management, resourcing the security monitoring and phasing in further SASE capabilities.