Skip to content

2024: The Year of the Security Platform or the Year of the "Frankencloud"?

Frankencloud - Defence in Depth Featured Image

2024 has been officially branded as the "Year of the Security Platform" by vendors, but lurking behind the marketing fanfare is the risk of creating a "Frankencloud" - a patchwork of disjointed security products masquerading as an integrated solution. 

Indeed it would seem this is a little bit more than a marketing slogan, as one major security vendor’s announcement around platformization saw their stock value drop as they focused on longer-term goals (PAN). Two quick things: First spellcheck hates the word platformization and maybe it should. Is this even a real word? Second thing - this quarterly results focus for public companies sucks. I wish more public companies would take a longer-term view. 

Back on topic….

At Fortinet Accelerate 2024 earlier in April,  you were invited to “step into the Platform Era” and focus on the convergence of the network and cybersecurity, adopting a platform-centric approach. 

But is this new? I was on the Cisco Security Customer Advisory board for a couple of years around a decade ago and they certainly had a vision that included a broad approach to security, albeit mostly network-centric. Once a year, we would be introduced to approximately half a dozen new acquisitions that were intended to be integrated into Cisco’s overall security portfolio. Ultimately, did this result in a security platform? Products were integrated to some extent, and there was always a vision of an overarching management layer (Cisco Prime at the time). 

2023 saw Microsoft announce Entra Internet Access and Entra Private Access. While this isn’t their first foray into the world of proxies and private application access, it is their first “as-a-Service” offerings in these categories and expands the breadth of their security platform offerings considerably. Zscaler has moved the other way, from having cloud-based network security into the world of Endpoint DLP, CNAPP, deception and data protection. 

Hello, Defence in Depth, My Old Friend

When I started my career, defence in depth was a standard approach when it came to security architecture. This was well before terms like EDR and SASE existed. Back then it typically meant selecting more than one security vendor. For example, an enterprise network may have had an external firewall e.g. CheckPoint, an SLB/reverse proxy in the DMZ e.g. F5 and then another firewall which segregated internal network zones such as a Cisco ASA. The theory was that these layered controls and vendors reduced the risk of a single point of failure causing a widespread security incident. Defence in depth does not necessarily mean using different vendors but sometimes this can be desirable. 

I would argue that the same theory can be applied to the existing discussions regarding security platforms. There are clear benefits to a platform approach, especially with the proliferation of security tools, but equally, there are clear risks. Therefore, it is about being deliberate in where you adopt a platform play, but also where you may choose to have the independence of vendors. Much has been made of Microsoft's recent security challenges, and for some that has been enough to push the diversification strategy. 

For example, you may choose to have a predominant security platform but still select point products for use cases such as EDR or secure coding.

One Ring to Rule Them All

One Ring to Rule Them All

So 2024 is the year you feel trendy and you’re heading down the One Ring /  Isildur's Bane path but how do you select the right security platform amongst the noise?

Here are my thoughts:

  1. Make sure it is actually a platform - Simply having one vendor’s products does not make it a platform. Most security vendors with platform plays have made extensive acquisitions. The question is how well have they been integrated? If they aren’t integrated well, you may be getting a platform in a commercial sense only (Enterprise Licence Agreement anyone?). I would check specifically on:
    • Whether there is a shared code base between any of the products
    • What benefits do you get around simplifying management? A single pane of glass is not necessarily the right answer but a level of UI consistency, IAM and RBAC integration, and multi-tenancy depth (if a service provider) can be a considerable benefit. 
    • How threat feeds and telemetry are shared between the products within the platform
    • Whether logging/alerting is consistent for ingest into your SIEM / SOAR or service management systems
  2. Choose a predominant architecture - The heritage of your vendor often determines how they structure their platform and how this fits your business. A firewall vendor will likely centre around firewall/appliance architectures - their SASE solution may be simply deploying firewalls in the cloud (not sure this is actually SASE..). An EDR vendor may be highly capable of building into adjacent areas around the endpoint, but identity or network security may not be their strong point. A vendor who started in the SASE space is likely to orientate around cloud-based solutions. Simply put, if you select a vendor whose solutions don’t align with your technology architecture, you can end up with constant friction. Round peg, square hole. 
  3. Allow for the anomalies (and alliances) - Be clear on the security domains that your platform of choice won’t cover, and don’t force something that doesn’t fit. If the overall goal with a platform play is the consolidation of security tools, this doesn’t mean you have to consolidate ALL tools. You may also find vendor alliances that allow you to select two or three best-of-breed vendors who work well together and have pre-built integrations. This could help you achieve some consolidation but not at the expense of quality. 
  4. It’s all about execution - The marketing looks great. The marketecture looks great. The deployment is a hot mess. Sound familiar? Often the vision runs ahead of execution, and the vision is what we buy into. It can be difficult to thoroughly test a solution before deployment, but due diligence is important, especially if you are putting more eggs in one basket. Again, being clear on the vendor's underlying architecture(s) is part of this, as would be getting under the hood and maybe speaking to some existing customers. 

Focus on needs…..

Finally, come back to your business needs. Buying tools for tools' sake can be a gigantic waste of time and money. Buying a platform doesn’t solve this and can actually perpetuate the problem by giving you access to more things you don’t need. 

If you use a security framework which contains a list of domains and associated risks and controls allowing you to prioritise based on your business needs and identifiable risk, this is going to get you better mileage than simply focusing on the technology. 

Security platforms can allow you to consolidate a lot of point solutions, but not all platforms are created equal. 

If you remember one thing from this blog, remember the term “Frankencloud”. I was first introduced to this term about a decade ago and it was used to describe the worst in platform plays - cobbled together solutions that simply don’t work. In fact, they created dissynergies (cool word aye). Aristotle may have coined the term: “The whole is greater than the sum of its parts”, but he’d never met Frankencloud….