Planning and executing a successful cyber security roadmap is the cornerstone of every Chief Information and Security Officer’s strategy. One of the most difficult elements of these strategies is trying to predict technology changes and future initiatives that are needed to protect your organisation.
A CISO must not only predict what technology is needed but how these technologies will evolve over time. Change is happening at breakneck speed, and if you intend to keep up, you need to be looking beyond where you think the finish line might be.
Technology vendors have a history of disrupting one another by improving and widening the functionality of their tooling and often growing into adjacent technology sectors. This is not surprising considering the commercial drivers which underpin their business models of growth and survival. An example that neatly illustrates this is the firewall market that moved from rather simple devices that block source, port and destination of IPv4 packets into a multi-faceted security solution that incorporates intrusion protection, intrusion detection, proxy, and layer 7 functionality and routing. During the development path of expansion, the firewall (now called unified threat managers or UTMs) swallowed up and made obsolete several standalone technology solutions that once existed left and right of their technology portfolio.
This brings us to the market in which ParaFlare operates: Detection, Response and Containment. The fundamental tools that typically exist in this ecosystem are Security Information and Event Management (SIEM), Extended Detection and Response (XDR) and Security Automation and Orchestration Platforms (SOAR). Let’s cover each, and their history, to help understand why convergence is on the horizon.
Going back 30 years we did not really have a cyber security market. In fact, we just looked at computers through a lens of making them perform tasks for humans, rather than making them secure. As one can imagine this quickly led to vulnerable systems that were easy to subvert. As security awareness increased, developers and technology companies caught up, and the humble security alert was born. The alerts became more sophisticated prompting a need to monitor and aggregate them in one place. We had thousands of devices, software and hardware generating alerts that needed investigation, so centralised logging and the SIEM was born.
The SIEM is used to aggregate all the alerts across an ecosystem and present them in a way that the alerts can quickly be sorted, rationalised, visualised, actioned. The SIEM industry flourished and became the mainstay of every mature Security Operations Centre. However, as fast at the SIEM grew in capability so did the sophistication of attackers which demanded more advanced methods of detection.
One facet of adversary attacks that grew at an alarming pace was subversion of the humble operating systems – particularly Windows and Linux. These systems needed to be monitoring in a way beyond the logging/alerting methods of the past given they represented a common stop on the pathway to a successful cyber breach. After all, security alerting in many cases is an artificial construct and requires a developer to decide that their product should provide alerting feedback to the user of their systems. Often this forethought is not enough to cover all combinations and permutations of a sophisticated attacker.
Extended Detection and Response (XDR) was borne out of the need to provide additional visibility of these operating systems given they presented such a significant ‘attack surface’ in any environment. Attack surface is the area of opportunity within a technology environment in which an attacker can take advantage. If you consider the thousands of users operating on a personal computer with a 20GB operating system in their device, it’s not hard to calculate that there is a significant amount of code there that needs protecting.
In recent times XDR and SIEM have continued to compete for attention as the ‘industry standard’ to detect a cyber-attack. However, neither has proven sufficient to provide an effective level of visibility. What we have seen happen over the past three years is XDR vendors are mimicking SIEM through developing and integrating data lakes to their platforms to allow for log and alert storage external to the operating system. Likewise, SIEM vendors are releasing XDR tooling to complement their alerting data in what appears to be a natural unison of two solutions that approach the same problem to some extent in different ways.
Security Automation and Orchestration (SOAR) tooling is the natural progression of most established technologies through automating tasks that are repetitive and can provide the desired output without human interaction. XDR and SIEM vendors are all racing to prove that their SOAR capabilities are superior through partnering with established SOAR providers or natively providing such functionality. These developments continue to blur the lines of what is an XDR, SIEM or SOAR tool in much the same way that firewall vendors of the past encroached on tooling that complemented their core offering.
In the future it will be hard to make a case for a standalone SIEM, XDR or SOAR solution given each technology now provides native functionality (albeit in their infancy) provided by their competition. The challenge for CISO’s is when to jump into a solution that displays adjacent features. Ultimately it will be a decision of when their chosen core product (SIEM/XDR) will be ‘good enough’ at adjacent functions to dispense with their standalone. That day is not today but I can see it developing in the near future.