6 Requirements for Cybersecurity Platforms
At the RSA Conference earlier this year, you couldn’t walk more than 10 feet on the show floor without a security vendor pitching you on its technology “platform.” Yup, Check Point, Cisco, FireEye, Forcepoint, Fortinet, McAfee, Palo Alto Networks, Symantec, Trend Micro, Webroot, and lots of others are now busy pitching platforms and will continue to do so.
Okay, but what is the actual definition of this term? In general, vendors use the word “platform” to describe an integrated amalgamation of point products that creates a common and interoperable architecture. It’s safe to say that all vendors agree upon this platform characteristic. Beyond this basic functionality, however, there doesn’t seem to be much consensus on security technology platform requirements.
Given this market omission, my esteemed colleague Doug Cahill and I came up with a short list of “must have” platform requirements.” In our view, a security technology platform must go beyond tightly-coupled product integration and include the following:
1. Coverage from endpoints to data centers to clouds. Platforms must provide comprehensive coverage that includes endpoints (i.e., PCs, mobile devices, IoT devices, etc.) and networks as well as physical servers, virtual servers, and cloud-based workloads (VMs, containers, etc.). The best platforms will also offer strong integration with common threat vectors like email security and web security. Note that many vendors may not offer mobile or IoT device support in their security platforms today. Before purchasing from these companies, CISOs should assess security technology platform roadmaps to gauge schedules for future functionality and device support.
2. Prevention, detection, and response capabilities. First, a security technology platform must greatly improve threat prevention when compared to today’s potpourri of point tools. Each individual tool should offer best-of-breed security efficacy while the platform should provide incremental threat protection as more tools are glued together. Beyond threat prevention, each tool should also act as a sensor for collecting security telemetry. Platforms will be back-ended by some type of security analytics services that process, analyze, and act upon this growing volume of security data. Security platforms must also offer well-defined and flexible options for responding to and mitigating threats including automated and manual options. For example, the platform should be able to automatically find and block retrospectively installed files and IoCs when new threat (that include these files and IoCs) are detected in the wild or offer options for quarantining systems, deleting files, or restoring systems/workloads to a known good state.
3. Hybrid deployment options. Today’s security technology world includes ubiquitous cloud services, costly security operations, and data privacy concerns. Therefore, vendors shouldn’t be dogmatic about platform deployment but rather offer flexible implementation options so customers can pick and choose the best fit. In other words, individual security tools and the platform management plane should be offered in on-premises and/or cloud-based form factors. Customers can then pick and choose how they want to glue the whole thing together without sacrificing functionality or technology integration benefits.
4. Cloud-based services. Security technology platforms should include a myriad of cloud-based services for things like threat intelligence analysis/sharing, static/dynamic file analysis, reputation list compilation/distribution, machine learning modeling, etc. In some cases, these services will be transparent to customers while they will be offered as upgrade options in others.
5. Central management and reporting. All individual tools must plug into a central management plane offering role-based access control that can be customized for different users, views, and functions. Management functionality must include policy management, configuration management, and detailed reporting from individual tools, groups of tools, or across the entire architecture. Management data must also be easily exportable to other tools (i.e., SIEM, GRC tools, automation/orchestration systems, etc.).
6. Openness. While security technology vendors want customers to buy their whole enchilada, it may take years to replace disparate tools owned by different budget holders. In many cases, large organizations have established best practices around certain point tools and will never swap them out. Given this market reality, security technology platforms must be open for easy third-party technology integration by offering developer support, technology partnerships, and well documented and standards-based APIs as a core part of their platform.
Finally, leading security platform vendors will supplement their technology with an assortment of managed services. Once again, customers should be able to choose which parts of the platforms they ‘own,’ which they outsource, and where they need staff and skills augmentation.