The terms unified and integrated are often used interchangeably in the software world. However, security leaders must understand the differences between deeply unified and API-based integrated platforms within an organization and how they can significantly impact everything from cost to efficiency. First, it is essential to define the terms.
API-Based Integration: integrated XDR platforms are usually developed by several vendors and consist of several security solutions logically created by different teams with different criteria; they do not share a data structure, functionalities, etc. In addition, these architectural and design differences are repeated for each of the vendors that are integrated. Often integrated XDR solutions are connected by APIs, have entirely different data with more than one unconnected database, and do not work seamlessly together with other technologies.
Deeply Unified: Unified platforms are developed by a vendor with access to the source code of the security solutions and have a shared data structure. It allows vendors to deeply integrate their security controls and create a unified platform, collaborative use cases that cannot be implemented otherwise, and a shared data structure within a unified database.
Now that we better understand what sets unified and integrated XDR platforms apart, here are six critical reasons why implementing a multi-domain detection and response solution, an XDR, via API is not ideal.
Unified vs. Integrated XDR Platforms: What's the difference?
1. Deep integrations through unification versus integration
It is more important to get comprehensive data, logs, and telemetry unification for a deep and meaningful native integration that enables new detection and response capabilities over time. Integrating security controls via APIs is often superficial as they don’t share the same data structure.
2. XDR becomes vulnerable to API versioning
The sustainability of an API-based XDR in the medium-to-long term is risky. Vendors may apply API changes requiring constant updates to take advantage of new and existing API features. These changes and updates can lead to integration and compatibility issues, adding more workload to the security teams.
3. Lack of standard integration capabilities
Even in the short term, the lack of standards in the APIs makes XDR implementations highly dependent on what other vendors implement in their security control, making it difficult to consistently retrieve the same data and consistently respond to attackers regardless of the integrated solution. This makes it challenging to implement a consistent and complete multi-vendor and cross-domain security program.
4. Lack of flexibility to evolve at the same speed as threat actors
Threat actors are continually evolving and creating new evasion techniques. Hunting for new threat actor techniques requires new activity sensors, collecting and automating the analytics of the new type of telemetry and data. It is a very active and dynamic job. It requires monitoring new behaviors, collecting new telemetry, and implementing new data correlation capabilities across multiple domains. In other words, proactive detections and responses are a dynamic feature, while API integration is static; once realized, it remains static for a long time as it is costly to evolve, becoming a drag on the security effectiveness of the security teams.
5. Security and scalability issues
Not all APIs are secure, which is the primary concern for vendors when using them. APIs can make the embedded platform vulnerable to cyberattacks. APIs can also make the platform's performance depend on their design and vertical and horizontal scalability. Therefore, if an API has some scalability issues, it will affect the performance of the overall platform.
6. Lack of implementation access for deep integration and adaptability to new requirements
Efficient cross-domain unified security and the ability to detect new cross-domain attack techniques are only possible if the integration of security controls is native, with the same data structure, and driven by a single vendor with access to the controlling source code. This unification in a single security platform is the only possible way to build use cases that would not otherwise be possible. See the use cases of WatchGuard’s “Better Together” security approach.