Automating Threat Mapping for Multicloud Environments

As enterprises adopt to micro-services and cloud based architecture, they are slowly moving from a single cloud deployment to a multicloud deployment involving a mixture of private and public cloud platforms. Multicloud deployments will accelerate in the future due to the myriad of benefits they offer. We observed that many of our large customers are using multiple public cloud providers for various reasons:

• Reliability: Deployment on multiple public cloud reduces the risks of any downtime and service failure.
• Platform specific functionality/capability: Customers are using particular cloud providers for specific needs. For example, some prefer to use Google Cloud for AI/ML tasks, Azure for Windows functionality etc., while they might prefer AWS for serverless functionality.
• Reduce dependency: Adoption of a multicloud strategy helps customers reduce their dependency on a particular cloud infrastructure provider and avoids vendor lock-in problems in the future.
• Cost: Depending upon their infrastructure needs, some cloud services are cheaper for customers.

While there are many advantages of hybrid and multicloud deployments, it also complicates monitoring and securing your infrastructure for various reasons as described below.

• Cross cloud visibility: Built-in tools provided by cloud service providers obviously work only for that particular cloud service provider. There is a lack of open/free cross cloud tooling for visibility.
• Increased attack surface: Multicloud deployments use a diverse set of services and libraries, resulting in increased attack surface. Multiple endpoints further exacerbate this problem.
• Integrity Monitoring: Monitoring tools provided by CSPs are specific to those CSPs and output logs are in different, inconsistent formats. There is no uniform way to holistically monitor the integrity of the whole infrastructure.
• Incompatibility: Different non-uniform and legacy security tools no longer work on all the existing cloud infrastructure.
• East-west traffic explosion: Network traffic across multiple clouds can no longer be easily analyzed. Cloud specific traffic mirroring solutions solve only part of the problem. This gives rise to blind spots and enables attackers to move laterally within the infrastructure easily without being detected.
• Extra complexity: There is also added complexity of multiple clouds due to multiple configurations, network settings etc., which developers and security analysts have to deal with to detect and protect from attacks. As attacks get more complex and multi-stage attacks become more common, we need a standard way to visualize and monitor application infrastructure across different cloud infrastructures.
• K8s, service meshes, serverless … : Adoption of service meshes and orchestration tools like Kubernetes further complicate the visibility and, hence, security issues.

Deepfence uses lightweight non-intrusive user-space sensors to provide solutions for the above mentioned problems in multicloud deployments as shown in the architecture diagram. Our community edition ThreatMapper addresses first two problems, namely visibility and measuring attack surface, whereas our Enterprise Edition addresses the other security challenges like integrity monitoring, east-west traffic analysis (including visibility into encrypted traffic), and multi-stage attack prevention in hybrid and multicloud architectures.

Deepfence provides both macro and micro-level visibility up to process level details and consolidates all the available information to provide a uniform centralized view to holistically manage all your security needs in contrast to piecemeal solutions available today. Our last few articles focused on integrating three most popular cloud platforms today: AWS, Azure, and Google Cloud. We also described how to manage your vulnerabilities using ThreatMapper and how to integrate the results with popular SIEM tools.

Deepfence Runtime APIs

Deepfence Runtime APIs abstract all cloud provider, Kubernetes, service mesh, and container runtime specific gory details from users. Think of this as one uniform API to visualize, manage, and control security aspects for services running anywhere – i.e. managed pure greenfield container deployments or a mix of containers, VMs, and serverless platforms on Azure, AWS, and Google cloud.

Our powerful set of APIs enables users to automate their security analysis and response process such as vulnerability scanning as well as retrieve, delete, and compare the vulnerabilities found.

This example python script shows how some of these APIs work to authenticate, enumerate the hosts, and start vulnerability scans on a subset of nodes.

Essentially, you can use the runtime API to stream your multicloud infrastructure over a websocket and programmatically consume all changes happening across your infrastructure and take actions like scanning a new pod that came online or scanning a group of VMs provisioned recently, down to the level of process or an individual connection.