This article was written by Omer Singer and originally appeared on the Snowflake Blog here: https://www.snowflake.com/blog/5-lessons-we-learned-validating-security-controls-at-snowflake/
You may have read about Snowflake’s IPO last year. But you probably didn’t hear about all the work that the Snowflake security team did in preparation. Our corporate security program went through a security analytics review to ensure that it satisfied the new security policy requirements resulting from the IPO. Here are a few lessons that we learned when setting up automated security control validation on our Snowflake security data lake.
Lesson #1: You learn something new when you measure for the first time
Ignorance might be bliss for some people but not for security analysts. That’s why answers to questions such as “Do we have visibility into all of our corporate server activity?” can be enlightening. For example, when we joined event logs together with asset inventory in Snowflake, the analytics pointed to systems that needed attention.
Visibility gaps aren’t good, but why should anyone expect things to be perfect if measurement happens infrequently or not at all? Although getting unexpected results didn’t feel great at the time, it led us to ask hard questions and get closer to our target state.
Lesson #2: SQL can be better than English for defining security policies
One of the best things about being part of Snowflake’s security team is gaining SQL skills. Although SQL is the preferred query language for data analysts around the world, cybersecurity analysts generally use a polyglot of proprietary search syntaxes. This prevents many in our field from putting data to work in meaningful ways, perpetuating a cycle of manual effort without enough time to invest in better analytics and automation.
We found that SQL is easy to learn, and it can be a great way to encode security policy. English-language policy definitions can be ambiguous, too general, or too specific, but SQL provides a structure to hold everyone accountable. For example, we translated key Center for Internet Security (CIS) benchmarks to SQL and then ran them as scheduled queries against the latest asset and configuration details. The results saved us so much time in audit preparation and management updates that the effort quickly paid for itself.
Lesson #3: When all else fails, add context
In some cases, all our efforts would not have been enough to meet 100% of a certain control. Applying contextual data can help to focus attention on what matters most. HR records can be used to enrich cloud configuration data with details on a user’s organization and employment status (see Figure 1).
Figure 1: Applying context to activity and configuration data
For directing our efforts around security awareness training, we centralized training module progress, HR records, and phishing alerts. This approach enabled us to measure and improve the training rates specifically for members of high-risk teams based on the nature of their role and how frequently their organization is targeted by attackers. In certain targeted groups, we measured an improvement from around 60% to nearly 90% completing their training (see Figure 2).
Figure 2: Measuring how targeted messaging improves employee training rates
Lesson #4: Automation can happen only after good detection
Knowing that we could never expand the security team as fast as the rest of Snowflake was growing, we used automation to overcome bandwidth challenges. We learned, however, that automation isn’t an option until the data and the analytics deliver consistently accurate findings. For example, we wanted to automatically notify IT when the corporate network still had a user ID for an employee who had left the company.
When the relevant details were first collected to the security data lake and joined together, the results had some bugs. For example, results included employees that had changed teams and still required access to the office Wi-Fi. If we repeatedly flagged the wrong users to IT, they might lose trust in the process, and our notifications would end up routed to the junk folder. Instead, we focused on dashboards that displayed detection results. Only when everyone was satisfied with the validity of the analytics did we set up ticketing and alerts to automatically drive action. Eventually, we could step back and let insights from the data drive change in employee behavior and improve our overall security posture (see Figure 3).
Figure 3: Tickets and messages based on automated analytics
Lesson #5: Executives love executive reports
Our leadership has deep experience from public companies and previous IPOs. We wanted to give them confidence in Snowflake’s security controls. While presentations could help reflect our progress, we wanted the data to speak for itself. Through reports and dashboards, executives had a direct view into security controls, ensuring that leadership received accurate information.
As seen in the tracking dashboard (Figure 4), our data-driven approach drove big gains in key controls. Senior stakeholders could access and interact with live BI reports, showing the security team’s accomplishments.
Figure 4: Hard work showing results, reported live
The security team at Snowflake is proud of the role they played in the successful IPO, but we don’t plan to stop there. Now that we have established a security data lake with dozens of data sources and analytics for validating many of our security controls automatically, we continue to expand our program to meet new requirements and challenges. For example, we hope that by mapping security controls to teams and individuals, we can boost accountability and drive further posture improvement.
Sometimes a new project requires collecting additional data sources. Other times, we turn to our data analytics team for help in expressing a complex requirement as SQL. We also get off-the-shelf integrations, analytics, or automation from our vendors. It’s a rewarding experience that builds over time and keeps us learning.