Product Update: Query Federated Search integrated with FortiCNAPP

Introduction

The Cloud Native Application Protection Platform (CNAPP) category represents a consolidation of the cloud security space. Namely, Cloud Security Posture Management (CPSM), Cloud Workload Protection Platform (CWPP), and Cloud Detection & Response (CDR), with some additional capabilities also covered. One of the earliest in the CNAPP category is Lacework, acquired by Fortinet and rebranded as FortiCNAPP.

CNAPPs provide as close to a single pane of glass (I know, we hate that term too) for cloud security taskings. The CNAPP represents a near real-time asset inventory, alongside all compliance, configuration, and vulnerability data along with other pieces of kit to automate remediations, send alerts, prioritize vulnerabilities, and more.

Multiple customers are using Lacework in production, so we sought to both enable their cloud security teams to search across the massive amount of CNAPP data while also bringing important cloud security context to security operations teams. Let’s talk about it.

Why CNAPP?

As mentioned in the introduction, CNAPPs are the closest thing to “sensor fusion” in the cloud security space, bringing together what are typically disparate tools run by different teams all with a cloud-native twist. Cloud-native is a term that is bandied about too often, really it just means “things that run on the public cloud”. Not VMWare ESXi, not Hyper-V, not Rancher or Consul. So AWS, GCP, Azure, and Oracle Cloud specific flavors of vulnerability management, anti-virus, security orchestration, and otherwise.

True intelligence – the processing and analysis of data and information to support timely decision making – is the lifeblood of just about every single business and security subdiscipline. So in a way, a CNAPP is just an intelligence cycle management tool for your cloud. It’s not enough just to rip through “best practices” configurations nor is it enough to even attempt to roll golden images in production to fight against vulnerability density. True cloud security requires all inputs coming into a platform that maintains visibility of ownership, resource hierarchy, network connectivity, vulnerability data, software assets, configurations, et al.

In the past, I worked at Lightspin (acquired by Cisco), which was another CNAPP. I’ve built my own CNAPP before it was called that with my team at IHS Markit (acquired by S&P Global) that used a proprietary targeting algorithm running on data on Amazon Neptune, a property graph database. Suffice to say, I have a pretty good sense of what a good CNAPP is, and Lacework is a good CNAPP. However, we’re not here to sell Lacework or cloud security in general, but a lot of folks talk about bridging cloud security and your Security Operations Center (SOC). So let’s do that.

Bringing CNAPP to the SOC

Depending on the organization, your SOC may not be involved in cloud security efforts at all. If your SOC owns vulnerability management or EDR, they may have some involvement in it, but typically it is a dedicated cloud security team managing all of the efforts including administration. However, when you have mainline EDR and MDM tools also running on the cloud, access to the source cloud data is important.

The importance is not just for context, it’s also understanding novel cloud-based attacks or gaining intelligence on the total impacts against the specific hosts in question. What may be otherwise considered a low priority alert in EDR can rise to the top depending on other configurations and factors impacting the host. Just like there is resistance to bringing data engineering skills to SOCs, there is about the same with bringing cloud security chops into the SOC, since all three are drastically different skillsets.

Query Federated Search and our security data mesh is all about getting access to the data you want to get the answers you need, without needing to know how to navigate in a specific console or write any Python code, SQL, SPL, KQL, or otherwise. CNAPPs to us are no different, it’s just another source to hook up and enable security operators with access to answers.

At its core, the main “node” in Lacework is the concept of a machine, which can represent any number of IaaS on the cloud. Along with the configuration and asset data, you can retrieve vulnerability information as well as information about users who access them, files on the system, and software inventory. Alerts are also tied to the machines, as well as audit logs which capture changes to them. Lacework goes beyond that with other capabilities which are out of scope for the integration as we designed it with a customer as the design partner.

Now you can search for a hostname or IP address and get the records in Query from Lacework, Entra ID, Microsoft Intune, and Defender 365 (or Crowdstrike, or other EDRs) all in one. You can get the file and user data from Lacework, log data stored in Azure Log Analytics, S3, or Snowflake, as well as get threat intelligence and OSINT data if the host is public as well. All with one search, your SOC analysts and other security professionals can get all angles of related data on a host which is greatly bolstered by the CNAPP.

What Now?

If you want to get started, check out our docs and then reach out to the team to get a demo or a tenant if you are a Lacework user.

Use another CNAPP like Orca Security or Wiz? We are more than happy to partner with you to build the integration!

SecDataOps Savages are standing by.

Stay Dangerous