Most companies who use cloud services to deploy applications, websites, databases and related solutions have a problem.
While each cloud vendor may have a secure solution for their own cloud service and offer a rich set of security tools to its customers, how can companies ensure that they are protected across all the different boundaries of cloud implementations they employ? This is especially important if they don’t want to implement multiple independent security mechanisms, or have to deal with security logs and data flows that are incompatible?
Why is this an issue? Because the average company has three-five different instances of cloud services deployed in their business– from public cloud to private cloud to hybrid cloud, to on-prem cloud — in addition to legacy data center implementations. All of these have their own way of protecting the organization from malware, data exfiltration and more general attacks. And with increased emphasis on regulatory compliance requirements, the capability to manage all these disparate systems is crucial.
Although I estimate that about 50 to -60 percent of companies have implemented a SIEM (security Information and event management) solution, which in theory aggregates threat intelligence information from a variety of sources (data center, network routers, end points, cloud servers and so on), it may or may not be fully integrated with each instance of cloud in a multi-cloud environment. In fact, we’ve seen organizations that rely on the available public cloud threat detection infrastructure by itself, rather than even try to integrate with a complete SIEM solution.
That practice essentially makes each cloud instance a standalone threat management system and requires the security group to monitor multiple information sources to see if they are under attack. Further, it’s quite possible that a particular SIEM does not support the APIs for a particular cloud instance that companies are using. And what should companies that have not implemented a SIEM system do to manage their security? At best this is a messy situation, and at worst, it can expose companies to unneeded security risks present within the gaps.
With so many corporate cloud service providers working with enterprises (e.g., AWS, Google Cloud, Microsoft Azure, Oracle, IBM, SAP, Alibaba, Baidu, Tencent and so on.), it is imperative that organizations find a way to share relevant security-oriented data from each and aggregate/consolidate that information into a single system that can fully collect and analyze a complete set of all data, and then identify and pinpoint any security breaches in the total enterprise environment.
This sounds simple enough, but is no easy task given the complexity of interactions and the variety of data and network interactions taking place, not to mention that many SIEMs are very difficult to use for data analysis purposes and many companies fall back to simple alerts which are important but not sufficient.
So how does an enterprise extract data from multiple cloud environments and analyze the necessary data from their SIEM (e.g., Splunk, McAfee, IBM, HP, RSA and others)?
One approach to combating this complexity and siloed approach to security is the Open Cyber Security Alliance. Its stated goal (from its website) is to bring “together vendors and end users in an open cybersecurity ecosystem where products can freely exchange information, insights, analytics and orchestrated response. The OCA supports commonly developed code and tooling and the use of mutually agreed upon technologies, data standards, and procedures.”
While this is a generic open sourced security data sharing group, it may have multiple longer-term ramifications not only with stand alone systems, but with cloud-based systems as well. In the mean time, various cloud vendors are taking their own approach while the open systems work plays out over the next 1-2 years or more.
One example of how a multicloud environment for security may be implemented is the IBM Cloud Pak for Security. IBM’s approach is to pre-package a solution that has built-in integrations with the leading cloud platforms and SIEM tools (e.g., Splunk, AWS, Azure, Google Cloud, McAfee or others). It uses Red Hat’s Open Shift platform. Open Shift allows interconnections to almost any Linux environment and includes nearly all cloud-based systems. But IBM’s approach still requires connectors to be built to clouds and security tools, and if you need one not currently supported, IBM services will need to build it for you.
Microsoft also wants to be your primary cross-cloud provider of security services, but has a more disjointed approach with its myriad of security products. Unlike IBM that is trying to merge all of its products into a single package, Microsoft has a number of distinct products like Azure Security Center, Microsoft Application Security Services, and Microsoft Cloud App Security (A Cloud App Security Broker, or CASB). This raises the complexity of security management.
For its part, Google Cloud tends to have much greater focus on its own security than trying to integrate across all different cloud platforms. It has a rich set of tools that cover infrastructure security, network security, endpoint security (primarily Chromebooks), data security and Identity and Access management (IAM). It does have some cross platform capability, but it needs to do more.
Bottom line: For most organizations, it’s going to remain a multicloud, multi-vendor world for the foreseeable future. The question is, will the security models of all the leading vendors merge to allow companies to take advantage of a single pain of glass to manage all aspects of security and enable better threat management and analytics?
Until we get to a fully compatible, industry standard way of interacting with all of the security mechanisms inherent in the various clouds, the answer is no. But I expect within the next two to three years, we’ll see a vast improvement in data sharing and standard interfaces across cloud and security vendors that will make the job of security much easier for most organizations.