Episode 15 of The Security Podcast of Silicon Valley aired on April 2, 2022, with Jon McLachlan hosting. The guest was Benjamin Schmoker Scott, then a security engineer on the threat intelligence team at Salesforce (Podbean, Apple Podcasts, Spotify). The episode is called “Salesforce Security Engineer, Benjamin Schmoker Scott, Navigating the Cyber Security Landscape.”
Ben worked where security meets abuse: phishing, stolen logins and free accounts put to bad use. The line that sums up the episode:
“any useful product will be abused”
Benjamin Schmoker Scott, at 14:54
This page follows the conversation in order: a section for each part of it, seventeen figures, thirteen clips from the tape, the full transcript, and five tools: a quiz, a scorecard for how ready your product is for abuse, a calculator for the analyst hours that enrichment takes, a timeline, and a to-do list. Where the decodes of the tape disagree on a word, the transcript puts its best guess in brackets, and the page doesn’t quote or retell those words.
From a railroad internship to threat intelligence
Jon opened by reading Ben’s career from LinkedIn. It started with an internship at Union Pacific Railroad, in security operations, and went on to cyber defense at Sandia National Laboratories, security engineering, and work as a technical investigator. Then came ThreatConnect, security at Tile, and security at Yahoo, with advising through RavenFlight on the side. At the time of the episode, Ben was a security engineer on Salesforce’s threat intelligence team.
Sandia is one of three research and development laboratories of the National Nuclear Security Administration, part of the U.S. Department of Energy. It was established in 1949 to advance national security through science-based technology (Wikipedia). RavenFlight’s LinkedIn page lists incident response, threat detection and virtual CISO work, and the company was founded in 2016 (LinkedIn).
Graduate-level classes as an undergraduate
Ben’s university had a strong security program, and some of its classes were being tested at a graduate level while Ben was still an undergraduate:
“So I got to do reverse engineering, physical security, rewritable card, like the NFC card.”
Benjamin Schmoker Scott, at 1:29
Operating system internals were on the list too. Friends from the same program went through the same internship program at Sandia and, in Ben’s words, did some amazing things.
Hex editing and game mods
Ben started early. Video game modifications were popular, and they led to hex editing and to working out how hardware and drivers behave:
“You just figure out how to make things work, like weird driver things, weird hardware things.”
Benjamin Schmoker Scott, at 2:21
During and after a computer science degree, the focus moved to defense: how to handle vulnerabilities, and how to deal with bad actors on platforms.
From Flash bugs to no-click exploits
The field changed a lot in that time. Ben put the old targets in one line:
“It used to be like Flash, Internet Explorer, Java bugs.”
Benjamin Schmoker Scott, at 2:42
Those platforms are deprecated now, and the work had moved to things like no-click exploits in WhatsApp. Adobe officially discontinued Flash Player on December 31, 2020 (Wikipedia). Internet Explorer 11 lasted a little longer, as What happened after the tape shows.
Briefing generals as an intern
As an intern at U.S. Strategic Command, Ben worked on projects and write-ups, and briefed senior officers:
“got to present to three and four star generals.”
Benjamin Schmoker Scott, at 3:24
Strategic Command is one of the Defense Department’s unified combatant commands, responsible for strategic deterrence, global strike, and running the department’s Global Information Grid (Wikipedia). The lesson Ben took from it was that experience doesn’t depend on age. Because the field was so new, it was possible to become an expert in something early.
Lunch at BSides
Jon and Ben first met at BSides, over lunch. Jon remembered leaving inspired. Ben was sure the two had talked about cryptography and Jon’s company. BSides is a series of community-run security conferences, organized by local groups, that began in 2009 with talks Black Hat had turned down (Wikipedia).
Information, and intelligence
Jon asked what threat intelligence is. Ben’s answer:
“I see it as applied knowledge.”
Benjamin Schmoker Scott, at 4:46
It works the way military intelligence does. Information is a single fact: this site is suspicious, or this domain points to this IP. Intelligence connects facts: the domain pointed to that IP on the same day a link to the site went out in a phishing email from a known address. It can go further, to who sends those emails, or which intrusion group a phone number belongs to.
“making information actionable and giving context around it”
Benjamin Schmoker Scott, at 5:34
It also helps the organization through high-impact incidents.
From analyst to engineer
Ben has experience as an analyst, and as a computer scientist Ben also writes code. The day job was security engineering: scripts, tools and platforms, built on AWS and a lot of serverless, and integrated with platforms that Salesforce’s large security engineering team builds. It included database design and other software engineering work. Ben was moving from security operations and intelligence analysis toward building:
“frankly, it has more legs as a career.”
Benjamin Schmoker Scott, at 7:04
Corporate security, and a hand for product teams
Jon asked whether the work was closer to product security or to stitching logs into action. Mostly the second. The team covered employees and corporate security, with some overlap with product and user security, which each product team owns. When the team saw bad actors abusing a product, or a wave of phishing reports about a platform, it stepped in. Product teams are busy with their own jobs, and they don’t always have that context.
Where the data comes from
Jon asked whether the team read hacker magazines like 2600. Ben’s answer was a collections function: the part of the team that gathers the data it turns into intelligence. Sources include vendors such as FireEye and CrowdStrike, private and public publications, government output, and other people in the community who share what they see. The work is knowing how to read a large amount of it.
Feeds, reports and false positives
Some sources are long-form prose reports. Others are feeds of indicators, such as bad IPs and URLs, and they’re treated differently. A feed raises a question first:
“how do I know this isn’t a false positive?”
Benjamin Schmoker Scott, at 9:46
Ben’s work included adding context: whether other places have reported the same indicator, and what VirusTotal or PassiveTotal say about it. VirusTotal pools many antivirus products and online scan engines. It launched in June 2004, and Google bought it in September 2012 (Wikipedia).
On episode 12, which aired about ten weeks earlier, Pulsedive founder Dan Sherry and co-founder Grace Chi talked about demystifying threat intelligence.
Enrichment
Jon called it context building, and remembered Ben’s word for it, enrichment. Ben walked through a domain name, which on its own is only data. PassiveTotal can say who registered it and when, which TLS certificates go with the IPs it points to, when those certificates were minted, and whether anything is running there, such as a server or an RDP service. VirusTotal can say which files, and which digests of those files, were downloaded from that IP. For phishing or a malware dropper, that tells you a lot.
Block it, or break it
Context decides what you can block. A VPS somewhere is fine to blacklist, since nobody knows what’s coming out of it. A big hosting provider is different:
“it’s probably going to break something if we just block it.”
Benjamin Schmoker Scott, at 10:26
Ben’s examples were an IP at GoDaddy or AWS. It may be doing something bad, but blocking it outright would probably break something. Jon added the same tension from the customer side: you can block employees from reaching a bad IP over the VPN, or drop all outside traffic from it, but dropping traffic can break customer integrations. Keeping customers working and keeping day-to-day operations running is the whole game.
Machine learning, and a second step at login
The team could add indicators to Salesforce’s corporate firewalls. Product teams decide what they filter, and the threat intelligence team influenced them with example data. Those teams mostly worked from a corpus of known bad data with machine learning, to judge on the fly how suspicious a login is and whether to ask for more authentication. Jon summed it up as raising the bar one step at a time, such as asking for a 2FA token when a login comes from a suspicious IP.
Ben said Google does something similar. It checks the source IP, and it checks for teleportation: a login from Seattle and then one from overseas may not be legitimate, even with valid credentials. Ben remembered Google saying at BSides that in a large share of cases, the attacker had valid credentials, from keylogging or credential stuffing. Credential stuffing takes usernames and passwords stolen in one breach and tries them on other sites, with large-scale automated logins (Wikipedia). So a password no longer proves who someone is. What counts is a profile of the user.
On episode 5, Leigh Honeywell of Tall Poppy described harassment that starts the same way, with an old leaked password tried on other sites.
On episode 86, Trevor Hilligoss of SpyCloud described phishing kits that pass a real password and MFA through to the real site and keep a copy of the session cookie.
Any useful product will be abused
Jon asked when a company should start caring about all this. Ben pointed to an idea from Facebook, abuse engineering: build the product with the abuse cases in mind. And Ben’s own rule has a corollary:
“if your product is abused, that means it’s useful.”
Benjamin Schmoker Scott, at 14:58
Jon agreed: you get hacked, or abused, once you’re big enough to matter.
What a startup can do
Startups have to move fast, and Ben’s advice kept it simple. Use a login platform people understand, such as Google authentication with SAML. For break-glass moments, when a user wants to do something major on their account, a phone number to text them is a good workaround. Ben didn’t think every account needs 2FA for every use case. For a bank, Ben said:
“you should probably have that.”
Benjamin Schmoker Scott, at 15:49
A bank can ask for a code before a wire transfer, even after login. For an everyday SaaS tool, Ben called that overkill, and Jon added that when little is at stake, it’s a barrier to entry and extra friction. One middle path Ben had seen: ask for a phone number after people start using the product, and gate some features behind it, such as messaging other users. Jon called it a fair trade. You give a phone number, and you get more features.
Trust in a 20-year-old product
Jon asked about the business case at a company as big as Salesforce, and answered it himself: trust with the end customer. Ben gave an example from the core CRM. Customers can set up IP allow listing, so their account only accepts logins from their own VPN egress range. Salesforce can’t make every customer use it, because it doesn’t know their ranges, and forcing it would add friction. So it tells security-conscious customers about the feature and tries to make it easy to set up.
Ben said 2FA in the core CRM was opt-in, for a similar reason. People had used the product for 20 years:
“now I’m going to move your cheese around.”
Benjamin Schmoker Scott, at 18:06
Jon agreed: what has worked should keep working unless there’s a serious security need to change it.
Heroku and free compute
Salesforce also runs products that work almost like separate companies, with their own code bases, workflows, authentication and abuse models. Ben named Heroku, and Marketing Cloud with Pardot, which started as two companies. Ben called Heroku a huge abuse model:
“for the price of a free email address, you can get some compute”
Benjamin Schmoker Scott, at 18:44
Salesforce bought Heroku in 2010 for $212 million, and ExactTarget, an email marketer, for $2.5 billion in 2013 (Wikipedia). The email marketing platforms have their own login flows and back ends. One product’s free trial may be a little more free than another’s. Someone might talk a customer success representative into an exception: they’ll pay next month, but they need to send a billion emails now. Ben’s point was that salespeople want to close deals and do right by customers, which is the opposite incentive from security’s.
Jon had negotiated with SaaS sales teams himself, and guessed that malicious users have the same conversation with them. Ben added that the abusers look like a legitimate company, with a website and a phone number.
Talks worth finding
Jon asked for resources on preventing platform abuse. Ben named Facebook’s abuse engineering presentations, talks at ShmooCon on dealing with abuse, and Netflix’s approach. In Ben’s telling, Netflix starts from the developer side and makes it easy to write secure code and deploy it securely:
“they do like a paved road that makes it easy to do that.”
Benjamin Schmoker Scott, at 21:01
A developer can still go off-road, but Netflix wants teams on the paved road, where everything is set up for them.
Jon asked about Spinnaker, and Ben agreed Netflix is behind it. On the paved road, a team skips custom authentication and integrates with the main service, plus anti-DDoS, filtering and security response. Spinnaker is an open-source continuous delivery platform that Netflix originally developed and Google extended, released on November 16, 2015 (Wikipedia). Ben recommended Netflix’s talks on SlideShare and the BSides talks on YouTube.
The best day: stable code and real people
Ben’s best day:
“any day that I can push out production code and it’s stable is a good day”
Benjamin Schmoker Scott, at 22:05
Another came from helping investigate large-scale phishing. Stopping bad behavior means people don’t get compromised, don’t lose money, and maybe don’t lose their freedom. Jon put it this way: so much of our lives runs through computers that protecting them touches people’s lives. Making compilers slightly faster doesn’t matter as much to Ben. The same was true at Yahoo, working on phishing and e-crime in Yahoo Mail, where one click could hurt a real person.
The worst day: five hours for one header
Ben had no bad day to report, and said Salesforce wasn’t too bad a place to work. The frustrating days come from vendor tools that break, or APIs that don’t work as you expect, when the fix turns out to be a small change to some header that better documentation would have saved. Jon knew the feeling: around hour four, you start to suspect it’s a config.
What happens when you type google.com
Ben’s favorite interview question comes from a GitHub repository called What Happens When. It answers what happens when you type google.com into a browser and press enter, in detail (GitHub). Ben gives a candidate five or ten minutes and watches where they start: DNS, HTTP, TLS, certificates or cryptography. Jon pointed out that a TCP SYN isn’t the first packet. It’s the DNS request for the domain.
The question also shows how a person explains things. Ben cited a line attributed to Richard Feynman:
“if you understand something, you can explain it to a 12-year-old.”
Benjamin Schmoker Scott, at 26:07
Ben tries to explain without buzzwords and without skipping steps. Jon called that the mark of a great communicator. Even experts forget the layers, Ben said, and at this point JSON parsing is probably one of them.
Trust as the number one value
Ben went back to the business case. Salesforce had made a point of it:
“trust is our number one value.”
Benjamin Schmoker Scott, at 27:09
Drilling that in, inside and outside the company, showed customers that Salesforce takes security seriously and spends real money on it. In Ben’s view, big companies now treat security as a bottom-line risk, after events like SolarWinds, IP theft and espionage. The SolarWinds attack began with a supply chain compromise of its Orion software, used widely in government and industry (Wikipedia). For a small company, the stakes are higher:
“If you’re a small company, it’s just existential.”
Benjamin Schmoker Scott, at 27:41
If people lose confidence in your site because it was compromised, that’s the end.
Top line or bottom line
Jon loved that Salesforce uses trust for growth. It’s part of how the company sets itself apart. Jon often meets people who treat security as a way to limit losses, amortizing the cost of a rare, expensive event and budgeting against it. Jon’s view: use security to attract growth, and you flip that calculation.
Ben said it used to be more about the bottom line. Big banks treated card fraud as a cost of business, reversed transactions, and moved liability around, to a customer who turned out to be a money mule, for example. Ransomware changed that. When you’re ransomed, you can’t move the liability anywhere.
Cyber insurance that’s hard to collect
Ben had opinions on cyber risk insurance, and they weren’t good. It was sold as something it has a hard time paying out on, with edge cases and clauses for why it won’t pay:
“people scrambled to buy to cover their liabilities and make the financial people happy”
Benjamin Schmoker Scott, at 30:03
Ben also raised the problem of becoming uninsurable. Jon pointed to Target, which was hacked and lost card data, then doubled down and built one of the strongest security teams around, working with the FBI on threat intelligence. Ben added that outside security circles, people forget. The Target breach ran from November 27 to December 15, 2013, and up to 40 million credit and debit cards may have been compromised (Wikipedia).
On episode 2, Andrew Gontarczyk, then CISO of Pure Storage, took the other side and called cyber insurance a no-brainer.
Automate it, or buy it as a service
Jon saw more automation and self-service tools coming. Ben agreed, and said it’s why the focus was on engineering over analysis:
“having rooms full of people staring at the news and clicking buttons is not going to scale”
Benjamin Schmoker Scott, at 31:47
Outside big government security operations centers, that model won’t last, and there aren’t enough people to hire. Ben put the number of people in the entire West who can do this work at three digits. Paying a company to automate parts of it is like handing off email or hosting. Jon agreed: as these things become services, security can scale.
Ben’s examples were AWS offering as a service what used to take separate companies, and running Active Directory as a managed service in Azure. That doesn’t remove the threat model, but it moves it to someone else, who patches and manages it. It also puts all the juicy data in one place, and Azure had seen recent break-ins. Ben still came down on the side of the service, with more trust in Microsoft than in doing it yourself.
Jon’s closing line was the same idea: let the folks who wrote the software run the software.
What happened after the tape
Heroku was breached five days later. On April 7, 2022, attackers got an access token for a Heroku account used for automation. In May, Heroku confirmed that the attack reached OAuth tokens used for its GitHub integration, and salted and hashed customer passwords. The tokens were then used in targeted attacks on GitHub repositories, with npm the main target GitHub named (Wikipedia).
Heroku ended its free plans. In August 2022, Heroku announced that its free plans would be discontinued, and cited fraud and abuse as reasons (Wikipedia). Ben had described that abuse model on the tape: compute for the price of a free email address.
Internet Explorer 11 reached its end. For Windows 10 Semi-Annual Channel versions, support ended on June 15, 2022, about ten weeks after the episode, and it was disabled for good on February 14, 2023 (Wikipedia).
ShmooCon ran its last year. The convention, organized by The Shmoo Group since 2005, held its last year in 2025 (Wikipedia).
Heroku changed course again. In March 2024, Heroku announced it was moving onto Kubernetes. On February 6, 2026, it announced a new engineering model that puts security, reliability, support and stability ahead of new features (Wikipedia).
Did you catch it? A seven-question quiz
Seven questions from the episode. Each answer links the moment in the transcript or its section.
Quiz · seven questions
Did you catch it?
Pick an answer to see whether you caught it.
-
How did Ben describe threat intelligence?
a. "I see it as applied knowledge." Transcript, 4:46.
-
What does enrichment add to a domain name?
b. From sources such as PassiveTotal and VirusTotal. See Enrichment.
-
Why not block a suspicious IP at a big hosting provider?
c. "it's probably going to break something if we just block it." Transcript, 10:26.
-
What's the corollary of "any useful product will be abused"?
a. "if your product is abused, that means it's useful." Transcript, 14:58.
-
What did Ben suggest a startup use for logins?
c. With a phone number for break-glass moments. See What a startup can do.
-
What could you get on Heroku for the price of a free email address?
b. "for the price of a free email address, you can get some compute" Transcript, 18:44.
-
What is Ben's favorite interview question?
a. Five or ten minutes, and Ben watches where the answer starts. See What happens when you type google.com.
Is your product ready to be abused?
Eight questions on how ready your product is for abuse, built from the episode. Each tip links the section behind it.
Scorecard · eight questions
Is your product ready to be abused?
Answer for the product you ship today. If two answers fit, pick the lower one.
-
Do you write down abuse cases when you design a feature?
- No
- For big features
- For every feature, next to the use cases
Build the product with the abuse cases in mind. See Any useful product will be abused.
-
What does a login from a suspicious place trigger?
- Nothing, a valid password is enough
- An alert someone reviews later
- A second step, such as a code or a 2FA token
A valid password doesn't prove who the user is. See Machine learning, and a second step at login.
-
How do people sign in to your product?
- A login system we wrote ourselves
- Our own, with some hardening
- A platform people understand, such as Google or SAML
Use understood login platforms. See What a startup can do.
-
What can a brand-new free account do?
- Everything a paying account can
- Most things, with soft limits
- The basics, with more after a phone number or payment
Free compute for the price of an email address invites abuse. See Heroku and free compute.
-
Before you block an IP or a domain, do you add context first?
- We block what the feed says
- Sometimes
- Always, so we don't break a hosting provider
A block can break more than it stops. See Block it, or break it.
-
Can sales grant exceptions, such as bigger free trials, without a security check?
- Yes, anytime
- With a manager's sign-off
- No, abuse checks come first
Abusers talk to sales too. See Heroku and free compute.
-
Do product teams see what security sees about abuse of their product?
- No
- After an incident
- Yes, with example data they can use
Product teams are busy and often lack the context. See Corporate security, and a hand for product teams.
-
How much of your indicator enrichment is automated?
- None
- Some
- Most of it, with people on the hard cases
Rooms full of people clicking buttons won't scale. See Automate it, or buy it as a service.
A useful product with no abuse controls gets found. Start with a second step on suspicious logins and limits on new free accounts.
The basics exist, but gaps remain. Write abuse cases into design, and add context before you block.
Abuse is part of the design. Keep feeding product teams example data, and automate the enrichment.
How many analyst hours does enrichment take?
Ben’s point was that people clicking buttons won’t scale. This calculator shows the hours that hand enrichment takes, and what automation saves.
Calculator
How many analyst hours does enrichment take?
Four numbers: indicators a day that need context, minutes to enrich one by hand, the share you can automate, and hours an analyst works a week.
At 200 indicators a day, enriching each one by hand takes 20.0 hours a day, about 2.5 analysts' time. With 70% automated, it takes 6.0 hours, about 0.8 analysts.
The calculator counts five working days a week and only the enrichment itself. The default numbers are placeholders, yours to change. Ben gave no figures for these on the tape.
From Sandia to Heroku’s new model
Salesforce and Heroku, the tools and conferences on the tape, the incidents it named, and this show. Filter by topic.
Timeline
From Sandia to Heroku's new model
- Sandia National Laboratories
Established, to advance U.S. national security through science-based technology (Wikipedia).
- Salesforce founded
A customer relationship management company, sold as software as a service (Wikipedia).
- VirusTotal
Launched by Hispasec Sistemas (Wikipedia).
- ShmooCon
The first event (Wikipedia).
- Heroku
In development, as a cloud platform as a service (Wikipedia).
- BSides
Begins with talks Black Hat turned down (Wikipedia).
- Salesforce buys Heroku
For $212 million (Wikipedia).
- Google buys VirusTotal
The scanner joins Google (Wikipedia).
- Salesforce buys ExactTarget
An email marketer, for $2.5 billion (Wikipedia).
- The Target breach
Through December 15, with up to 40 million cards at risk (Wikipedia, on this page).
- Spinnaker
Netflix's continuous delivery platform goes open source (Wikipedia, on this page).
- RavenFlight
Founded, per its LinkedIn page (LinkedIn).
- SolarWinds
A supply chain attack through the Orion software (Wikipedia, on this page).
- Flash Player discontinued
Adobe ends the plugin (Wikipedia, on this page).
- Episode 2
Andrew Gontarczyk on building a security team (episode page).
- Episode 5
Leigh Honeywell on online harassment (episode page).
- Episode 12
Dan Sherry and Grace Chi of Pulsedive on threat intelligence (episode page).
- Episode 15
Ben on the show (Podbean, transcript).
- The Heroku breach
An automation account's token, then OAuth tokens for GitHub (Wikipedia, on this page).
- Internet Explorer 11
Support ends for Windows 10 Semi-Annual Channel (Wikipedia).
- The end of Heroku's free plans
Announced, citing fraud and abuse (Wikipedia, on this page).
- Heroku on Kubernetes
Announced at KubeCon Paris (Wikipedia).
- ShmooCon's last year
Twenty years after the first one (Wikipedia).
- Episode 86
Trevor Hilligoss of SpyCloud on crime as a service (episode page).
- A new model for Heroku
Security, reliability, support and stability first (Wikipedia).
What to do this week
Five things, in the order of the episode.
- Add context before you block. Pick one feed you act on, and check what blocking its top IPs would break, as in Block it, or break it.
- Put a second step on suspicious logins. Ask for a code or a 2FA token when a login comes from a new or unlikely place, as in Machine learning, and a second step at login. Why Passwords Still Get Stolen covers credentials that keep the private key in hardware.
- Write abuse cases into design. For the next feature, list how it could be abused next to how it will be used, as in Any useful product will be abused.
- Limit what a free account can do. Gate the features that cost you money or reach other users, as in Heroku and free compute. The scorecard shows where else to look.
- Get help with it. Our Product Security team builds abuse controls into your product, and 24/7 Monitoring & Response watches for the logins and traffic that get past them. Penetration Testing finds the abuse paths before someone else does, and vCISO Services gives you a security leader to set priorities. If you want to talk it through, book 15 minutes with us.