Need for an ecosystem of security tools

On an average enterprises are using more than 75 security tools to monitor and alert on security incidents and the list is growing. In addition, more than half of these enterprises do not know whether all of these tools are working as expected. This security tools bloating has occurred due to the following reasons.

• Massive digitization and automation in a hyper growth manner across industries.
• Adoption of new technologies, open source software, public cloud and SaaS services by organizations.
• Ever growing cyber security threats landscape.

Security teams need to stay ahead of the game and continue to mitigate risks as soon as possible. Finding a balance between efficient use of security tools and mitigating security risks in a fast fashion is difficult. As a result, across the board cybersecurity leaders are asking the following questions.

1. How can they converge existing tools to be more cost efficient?
2. How can they reduce onboarding and offboarding time for any new or existing tool?
3. How can security tools work better with existing security tools securely?
4. How can these tools process enterprise data within the boundaries of their environment?

Traditionally, enterprises use data lake architecture to gather security tools data from multiple sources into a single place and run analytics on top of that. While this architecture has facilitated teams to ingest large amounts of data into a single database it doesn’t scale and the process is not efficient for modern security teams due to the following reasons.

• Slow data ingestion: Before the data can be ingested to the central data lake, the data ingestion team needs to write the necessary scripts to ingest that data through API calls. Even with existing ingest tools which can automate data ingestion, it’s not a zero touch effort. In addition, many of the security tools do not provide rich APIs to ingest all the data through APIs from the get go. Most of the time, these tools need to change their APIs to accommodate 100% of all customer’s data ingested. This delays the onboarding process significantly.
• Dependencies on the analytics team: Security Engineers and architects are not great at writing sophisticated SQL statements. So they rely on the security analytics teams to write custom queries and run the analytics on the data obtained from these tools. Especially, when the security teams need to obtain intel from multiple data sources. This becomes another huddle to utilize these tools holistically. For example, if we need to combine signals from a PAM tool with signals from a vulnerability scanning tool, security teams rely on the analytics teams to deliver the necessary queries.
• Non uniform schema across the board: Today, the onus is on the user or the customer of these tools to determine what data they need to ingest and store in their environment. With storage cost becoming a non-issue, users wouldn’t mind obtaining a standard schema of data from these vendors if the ingestion process becomes more efficient. In fact enterprises would prefer to have 100% of their raw data handy in their environment as soon as possible.
• Lack of controls that take advantage of signals from multiple tools: Today, cybersecurity teams suffer from signal fatigue because they receive tens of thousands of signals every day. They need to correlate these signals and build analytics on top of that to reduce false positives. These tools work in silos. Even some of the basic repetitive signals that require data from more than one tools are not available by default with these tools. They are great at alerting the area they cover. However, due to the lack of contextual information, false positive rate is awfully high with these alerts. For example, just showing log4j vulnerabilities presence in an environment doesn’t really help. Whether they can be exploited is equally critical. None of the tools provide that level of details today. It is a travesty that there are new tools being built now to manage all the security tools that are out there.
• Security data sharing across tools is risky: Security teams are not comfortable to share signals received from one tool with another tool because traditional data lake architecture requires a movement of data from customer’s environment to the vendor’s environment.

Snowflake as a modern data cloud platform is able to solve these challenges for security tools through its security data lake architecture. Following Snowflake features is enabling security tools and customers of Snowflake to address above challenges effectively.

1. Share data securely: Owners of the data get to decide what data is shared with whom and for how long. Secure data sharing enables customers of these tools to share only the relevant data with other security tools securely with time bound controls.
2. Bring processing next to data not the other way around: With Snowpark container as a service, security tools and apps can process customer’s data within customers’ environment. No need to transmit data out of the customer’s environment and process it.
3. Store customer data directly in the customer environment: Snowflake’s connected apps model enables these security tools to store security signals for any customer directly in these customers’ accounts. Security tools can define a standardized schema that every customer of these tools can use and store directly in their Snowflake account. The need for data ingestion can be completely eliminated.
4. Stronger together model: Tools can partner with each other to extend additional controls without moving security data out of the customer’s environment. This will take the burden out of customers to write custom queries combining signals from multiple sources.

The Cybersecurity industry needs an ecosystem of Cybersecurity apps like Andorid or iOS mobile apps ecosystem. As customer 0 for Snowflake, I have experienced the above benefits first hand and I have seen how my security vendors are starting to take advantage of these features with Snowflake. Snowflake data cloud is able to provide a rich platform which will enable security vendors to build a rich ecosystem of apps that customers of these apps can directly use without the need to go through some of the inefficient processes. Future Cybersecurity companies will look to build new features which can leverage this ecosystem and consume signals from other Cybersecurity tools because their customers are going to demand that.