Fractals are a really cool mathematical concept that reflect an almost recursive like pattern, that reoccurs at smaller and smaller scales.  The classic Mandelbrot image is a perfect example of this – the larger forms come first, then as you scale down, more details emerge, all in perfect alignment and part of a cohesive pattern.  Does your security architecture follow a similar pattern, or is it just fractured?

We’ve all heard the statistics – an average organization will have 100 security tools from 65 different vendors.  On the face, that sounds like an overly complex, unmaintainable architecture, and to be sure, in most cases it is.  The disparate teams across security and IT are constantly seeking their own unicorn solution for a nit problem, without any perspective on how it all will (or won’t) work together.  That’s the classic fractured architecture, and fixing it is something organizations are working to correct, but it’s a large effort.  Entrenched tools, calcified processes, and personal or team agendas all contribute to the fractured nature of most organizations.

And that’s where the fractal concept comes in.  Security is fundamentally an information management problem, so the biggest part of the picture is the information and analytics platform (which is far broader than just a SIEM).  The other big rocks are major information sources – identity, endpoint, network, application, data, and as well as the incident response and threat hunting platforms. Fractals direct us to work on the largest piece first, then iterate down to the next largest and so forth.

Getting the information and analytics platform right is the starting point, and needs to be owned by the security team.  Once that fundamental core is in place, then we iterate down to the next level, for example, endpoint.  Following the fractal concept, we again look for the largest components, perhaps asset management, configuration management, patch management, and anti-malware.  This level is where the fracturing tends to start as each of those four has its own constituency, many of who don’t live in the security organization.  They may own their own budget, have their own preferences or niche needs, and may or may not play well with others.  But following fractals, we focus on the biggest parts at this level – is there a platform that does multiple of those?  Yep, but it’s an 80% solution, so there’s gaps.

So we iterate down to the next level before confirming that solution choice.  After doing a risk assessment on those gaps, we may decide to close them with another tool or may decide to go with the 80% and accept the risk. But always in the context of the overall architectural picture.   If we just whack the finding with another tool, we’ll fracture the picture.  I saw one team that had – seriously – 11 agents running on their endpoints, placed there by separate teams with overlapping capabilities.  Fractured for sure.  They’d never looked at ‘endpoint’ as a whole.  When we finished the building that piece of the as-is architecture, the common emotion was surprise.  Needless to say there was quick consensus that this was a viable target for consolidation.

Fractal architectures allow an organization to transform in sections, rather than trying to do a big bang – got an audit finding on endpoint?  Work on that bubble.  Just make sure that the team doing so understands how it fits into the overall picture.  This isn’t rocket science, it’s just architecture.  And internal politics, but that’s another article.

So how many tools will you end up with?  As with any architect, my answer is “It depends.”  Some organizations may have a robust architecture with a handful of tools, and another may have the proverbial 100.  It’s all based on the organization’s risk tolerance and regulatory environment. The key is that every solution is there by intentional design, integrated as part of the big picture. Otherwise it’s just a bunch of fragments – no matter how pretty each one might be.