EP 42 — Snowflake’s Jacob Salassi on the Science of Product Security

In this episode of the Future of Application Security, Harshil speaks with Jacob Salassi, Director, Product Security at Snowflake, a cloud computing and data management company. They discuss how Snowflake approaches product security — from what they expect engineers and developers to do, to their risk-based reporting — and why Jacob takes a scientific approach to it. They also discuss how Jacob’s team creates property graphs to better understand risk flows and what to prioritize, automated threat detection, how they’re writing more intelligent detections at scale, and the challenges of big data to product security.

Topics discussed:

• How Snowflake approaches product security, including: 
  • How they build autonomy for engineers through repeatable processes
  • How they optimize for business value and not just security outcomes, and 
  • Why they take a quantitative risk-based reporting approach
• Why Jacob takes a “science, not art” approach to product security, and why he defines product security as anything related to the security posture of the service.
• The ways in which data- at- scale and disparate data sources prove to be a challenge for threat detection, and why security teams can benefit from pulling together those sources so they can uniformly analyze data across systems.
• How Jacob’s team created and scaled a repeatable and structured method to risk assess every new feature that’s being shipped.
• How this method of risk assessment and scoring helps uncover dynamics in their environment, gives developers better prioritization of their work, and enables automated threat detection.
• Challenges to the observability problem of who can own and access data, how many people are ingesting APIs, how much it’s costing, and other access concerns.
• The ways in which they’re communicating KPIs and risk posture through live dashboards, and how they’re thinking about powering quantitative risk analysis and forecasting through those dashboards.

Guest Quotes: 

“Something we think a lot about is doing science and not art. … What we try to really focus on is understanding exactly what we expect developers to do, what we expect security partners to do, and what we expect security engineers to do.” 

“Security engineers need help to understand the business value and how to optimize for the business value and not to just arbitrarily optimize for security outcomes. What we want to do is have a process that helps them clearly identify what are the mission goals, what are the risks to that mission.” 

“Threat actors are moving across systems, things are moving across systems. Therefore, your ability to uniformly analyze data across systems becomes either a strength or a weakness.”

“We’re going to understand how to ask a better question in the risk assessment or how to know which technology we need to build, because in some cases, it’s just going to remain risky. … But we’re going to get better at systematically describing what you as a developer are going to do about it.” 

“We want to compare what they told us to what they deployed. And essentially I want the set of properties that I compare between those two things to be one-to-one.”