In cybersecurity, integration has become a near-obligatory requirement for organisations considering new products. They want to know new products will complement existing investments to collectively produce more effective and efficient solutions.
But as of late, the term convergence has emerged as another key capability and expectation of technology platforms.
I’d like to explore how these terms differ and how those differences will shape security outcomes in the future.
Let’s start with a stone-cold definition. According to the Merriam-Webster Dictionary:
- Integrate means “to end the segregation of and bring into equal membership in society or an organisation”
- Converge means “to come together and unite in a common interest or focus”
Are we splitting hairs here? Are they much of a muchness?
These days, integration typically refers to the establishment of a common communication channel or route between disparate solutions to solve a particular challenge – usually to enable data sharing of some sort. Standard examples we hear sound like, “we’ve integrated this tool with that platform via API/Syslog/PowerShell” or various other methods.
Convergence approaches things differently by consolidating features and capabilities onto a common scalable architecture and platform. To take a common example from daily life (nowadays, anyway), converged networks such as Cisco WebEx, Zoom, and Microsoft Teams to name just a few, amalgamate voice, video, and data services within a unified infrastructure.
Convergence aims to deliver the following benefits:
- Lower costs and complexity
* Consolidating vendors and technology stacks should reduce licensing and operational costs, as well as management overhead
- Enabling new digital business scenarios
* Apps, services, APIs, and data shareable to partners and contractors with lower risk exposure.
* Avoiding app bloat, fewer agents per device, consistency of experience regardless of user location or device
* Cloud-based centralised management with distributed policy enforcement and decision making
While these benefits may not come as a surprise to some, many could argue that integration could very well yield the same outcomes and thus, the differences are negligible. Let’s take a moment to walk through a real-world example to show the contrast between the two.
Challenges and Benefits
It may be helpful to elaborate with examples to highlight just some challenges typically faced with integrations.
Let’s consider an organisation that wants to improve its security attentiveness and overall posture by blocking access to websites and Cloud services based on business risk, not just standard reputational checks. In this given scenario, let’s assume the organisation has mandated that its lines of business must ensure Cloud services being used must store their data encrypted when at rest.
In order to achieve this from a workflow perspective, they would need to integrate the business risk attributes for a given website (such as whether or not data at rest is encrypted) from a Cloud Access Security Broker (CASB) solution, along with the content filtering and blocking capabilities from a Secure Web Gateway (SWG) solution. Usually, this would be done via custom API integration; assuming that no further re-architecture work or implementation of data sharing platforms is needed.
Considering this, ask yourself what happens if/when:
- The API is changed during an upgrade?
- The SWG appliance requires a patch or version upgrade?
- The personnel who wrote or implemented the integration leave the organisation?
- Credentials and/or certificates used to authenticate between the solutions need to be refreshed?
- The connection between the solutions breaks down, is the customer ultimately responsible for restitching the products together? Or are the respective vendors then called into action?
Now, let’s reflect on the benefits we mentioned earlier. Complexity goes out the window the moment we begin to mention bespoke integration via coding and credential/certificate management. Version control for the code, along with the dependence on version specific APIs, draw out more complexity as change management for each iteration of the configuration needs to be tested. In addition, we need to consider the additional complexity brought by the need to open up firewall ports between the various components involved to make this integration work.
Centralised management and enforcement don’t exist as the two solutions and their ontologies don’t align. That is, a risk attribute for a Cloud service in the CASB product cannot be natively stored in the SWG as its ontology lacks this concept. This means that they must resort to a common lower value ontology which is common across the two – in this case, the URL. The resultant integration means a dumbed-down list of URLs must be used. This list would be routinely and regularly pushed from the CASB to a list within the SWG. At that point, its accuracy and timeliness become highly dependent on the synchronisation and polling period between the two products.
With this, ease of use diminishes as attrition in personnel brings about lost institutional knowledge and know-how unless knowledge is transferred or sufficiently documented. Also, in the event of an incorrect block on a website, troubleshooting would become troublesome.
We could simplify this integration and remove some of the barriers mentioned above were we to use a Cloud-delivered SWG – however challenges such as different ontology, API management, credential management and integration testing remain unchanged.
So then, how does one go from integration to convergence? The answer is simple – acceptance of the need to change the approach and a willingness to get it done.
In order to adequately address the use case at hand, the technologies involved need to come together to ultimately become one. While this seems like something that could be blurred in a Cloud-delivered offering through converging parts of the UI with microservices from both products, doing so would technically fall into the integration bucket as ontologies and UI/UX remain different and would lack simplification. So, what would it take to converge CASB and SWG solutions?
- Merging ontology – Bringing both CASB and SWG elements together. An example of this may be, using the same Cloud “Service Group” object in both solutions
- Leveraging common capabilities – It doesn’t just stop with ontology. The solutions need to merge other components such as incident management, logging, dashboards, policy definitions, user authentication, etc. This convergence would not only improve the end user experience, but also reduce future technical debt in maintaining overlapping capabilities and components
- Refactoring UI/UX – Rethinking and re-working the user experience to bring about the simplest flow to achieve the converged use cases
In the figure below, we have a policy example that creates a grouping of all high-risk Cloud services, current and future, that can be used as a restriction for web access. The result is that any high-risk Cloud service will be blocked by the Cloud-native SWG, preventing users from accessing these services to keep them safe from accidental data loss and/or malware. All this with no bespoke integration, no polling or pulling, no scripts, no firewall rules, no credential or certificate management and most importantly, no complexity!
Now, this is just but one example of convergence as part of McAfee’s Unified Cloud Edge (UCE) solution. Further convergence is necessary to refactor many of the data protection workflows traditionally kept separate from other enterprise security platforms.
According to an industry survey conducted by McAfee, only 31% of companies said their Cloud security tools could enforce the same DLP policies at their Devices, Network, and Cloud Services.
As part of McAfee’s Unified Cloud Edge solution, the convergence of Data Loss Prevention (DLP) policies and attributes with SWG and CASB technologies will ultimately lead to the unification of data classifications, rules, incidents, workflows, and so much more across Devices, Networks, and Cloud environments.
Blended threats require a blended security response. Converging security practices and capabilities creates a whole that’s greater than the sum of its parts. Even something as simple as unifying an organisation’s security visibility – spanning from Device to Cloud – through a converged and centralised portal yields powerful gains in specific incidents and over the long run.
Converging security processes should align your security operations with your business goals and amplify your organisation’s performance of its most important functions. A converged security program protects your organisation’s key assets and helps get them back up and running faster when something does go wrong. Ultimately, converged security practices can be part of your organisation’s competitive advantage.
If you’d like to discuss any of the points covered here, or more specifically McAfee’s converged security solutions in further detail, please feel free to reach out to me.
* Special thanks to my manager Sahba Idelkhani for his guidance and input into this blog *