The Breach Nobody's System Caught Until the Victims Started Calling

Most incident response begins with something your own systems can show you, such as an alert firing or a ransom note on a screen. The plan assumes the evidence starts inside your environment and that the investigation works outward from there.

In 2008, Isaac Straley got a phone call instead. A graduate student he knew at UC Irvine had gone to file a tax return and found that someone had already filed one in their name. Within an hour or two, more students were describing the same thing. Nothing in the university's own environment pointed anywhere, and nobody yet knew whether the leak was the university's at all.

Isaac is Chief Information Security Officer at the J. Paul Getty Trust. At the time of the case, he was working in security at UC Irvine, where he spent 13 years, and he later became the University of Toronto's first CISO and helped incubate CanSSOC, a shared security operations center for Canadian universities and colleges.

On Episode 18 of the Full Metal Packet podcast, hosts Yegor Sak and Alex Paguis walk Isaac back through that investigation, then widen out to the shared SOC he helped build and to his view that every incident response playbook will eventually break.

TL;DR

• Treat a cluster of victim reports as a detection signal. Isaac moved when five or six graduate students described the same fraud within an hour or two. The commonality of their stories and the timing were the evidence.
• Narrow the population before you hunt for the leak. Isolating about 150 victims, by Isaac's recollection, to a single academic term told the team which records to follow, paper copies included.
• Put a named contact and response timelines in supplier contracts. Isaac insists on both now, after an investigation in which his team had to pick up the phone and keep calling.
• Expect the playbook to break, and treat each break as an edit. Isaac would rather finish an incident knowing what the plan missed, because documentation lags reality unless you keep improving it.
• Pool signals with peers who face the same attackers. CanSSOC's shared threat feed pushed blocklists to member institutions within minutes, including ones where security was "a quarter of an FTE if you're lucky."

The Breach Report Came From the Victims

Yegor takes the conversation back 18 years, to a case Isaac says still drives his understanding of what good incident response looks like. In 2008, graduate students at UC Irvine began finding that their federal tax returns had already been filed by someone else. Tax refund fraud is common now, but Isaac says that in 2008 it was still fairly novel, and the way this case arrived matched nothing he was used to.

"Often when you start an incident response process, the signals that you're getting are a SIEM alert or a ransomware note or a machine running slow. You rarely start with the victims coming forward."

The first report reached him because a graduate student he worked with on an advisory group phoned him for advice. A colleague then mentioned being contacted, and about ten minutes later someone else messaged him with the same story. Yegor asks how many reports it took before this stopped looking like scattered fraud. Isaac says it was five or six, and that the count mattered less than what the reports had in common.

"It was the commonality of the stories and the timeline in which they reported."

Had the same reports trickled in over two weeks, he would probably still have flagged them, though maybe without the same urgency. Arriving within an hour or two of each other, they were enough to open an investigation on the strength of what people were describing.

Isaac comes back to this later in the episode when he describes how he designs detection now. He wants detection built for a first signal like this one, arriving from a person rather than a system.

"Your first signal might be a person going, hey, this weird thing happened to me."

He treats that as a design problem, so that people understand what is worth reporting and why. A campaign that repeats "report a phish" without explaining the value gets mixed results, and the strange voicemail asking for something never gets mentioned at all.

Narrowing the Victims to One Academic Term

Alex asks where an investigation starts when the evidence did not come from your own systems. Isaac's first move was to define who had been affected. The team went out to the student community asking who else had been hit, and the fact that every victim was a student gave them natural boundaries to test. Isaac forgets the exact final count and puts it at about 150 people.

"We were able to isolate it to one specific academic term. Not even a school year, one specific term."

That gave the team a defined set of records, and the work became finding every master copy of them and following each one wherever it went, including onto paper. Isaac partnered with a lieutenant from the university's police department, so a criminal investigation ran alongside the technical one.

Yegor asks which decision Isaac was most worried about getting wrong while the scope was still unclear. Isaac points to identifying the cohort, because once it existed the university had a stake in the outcome whether or not the breach was its own.

"I don't know if this is my breach or not. But I know we are involved and I know we have a stake in this. And if it is our breach, I want to get it contained."

Isaac says graduate students rely heavily on their refund income, and at the time the IRS response to a duplicate return was an investigation that could take months.

Asked later by Yegor whether the case shaped the shared SOC he went on to help build, Isaac points at this stage of the work. What he took from it was less about response than about the detection capability you build beforehand, because knowing where the data went and what happened to it could have made a big difference.

"I think we could have cut down the investigation work significantly with better signals and sources."

That is why he now thinks so much about log design and what he calls the observability pipeline, which means collecting good signals from everything, deciding what to keep, then enriching and routing it. Mo Balakrishnan's team shows the payoff in Episode 14, reconstructing a live attack from telemetry it had collected before it needed it.

Keeping Victims and Leadership With the Investigation

The affected students organized themselves quickly, with a couple of them acting as go-betweens, and Isaac recalls updating them about once a week. Those updates said the investigation was continuing and not much more. He held back detail because the students were already under strain, while making sure they knew the university was staying with it.

"We're not dropping this. We got your back. We're taking this seriously."

He is proud of that part, because it would have been easy to drop the investigation once it became clear the compromise was not in the university's own environment. He would not build an incident response process primarily around empathy, but he treats communication with the people affected as essential.

"I don't think you have to give away the investigation farm to help people understand that something's going on and we're on top of it."

Alex then raises the resourcing problem. With no confirmed breach and no plan written for this kind of start, he asks how Isaac decided how much effort to commit, and whether anyone pushed back. Isaac says there was little pushback, which he credits partly to the university's focus on its students and partly to regular leadership updates. Each touch point covered the same ground:

• the avenues being investigated
• what had been found
• where the dead ends were
• where a new lead had appeared

His concern was the case turning into a cold case that consumed resources without showing movement, and showing progress at each touch point is what kept leadership backing it.

Dead Ends and a Fake Tax Office

Yegor jokes that a third-party breach is about the best outcome available, since you can point at somebody else, and asks what single piece of evidence settled it.

"There wasn't a smoking gun artifact."

The technical investigation reached a logical conclusion on every path except one. The only places where these particular data sets appeared were health insurance processes, and the remaining question marks sat with third parties that had received the records to process insurance claims or deliver medical services. Those partners were open with the team, Isaac says, to the point of sitting down together in conference rooms with network diagrams, security plans and logs.

The criminal investigation supplied the next lead. The fraudulent returns were producing paper refund checks, and those checks were going to a location near one of the suppliers. Isaac and university officers flew out to work with local law enforcement, and when officers entered the premises they found what Isaac describes as a tax return processing office that was entirely fake, furnished with props and nothing else.

Alex points out that CISOs rarely do this kind of field work. Isaac has not done it since and says much of it would now go to professional services, but the skill it demanded applies just as much at a desk.

"The skill I think is not just knowing how to follow the threads, but knowing when to follow the threads."

One Document, and a Name in the Contract

On site at the supplier, the team kept the method it had used at home and interviewed everyone who had handled the data. The supplier had worked to remove Social Security numbers from its systems and resisted the idea that any remained, until one interview turned something up.

"Somebody was like, yeah, there is this one document."

The supplier had acquired another company, and a transition document created during that process still held the data, with only a few people able to access it. Isaac stresses that the supplier was a victim as well, and says the case led to arrests and convictions, though he deliberately kept his distance from the legal side. Asked by Yegor whether UC Irvine had been singled out, he thinks the attack was opportunistic.

The case also changed what Isaac asks of suppliers before anything goes wrong. Alex asks whether he now thinks differently about chain of custody for sensitive data, and Isaac admits he still lacks a clean answer. The practical part he can do today sits in the contract, and it comes straight from having to keep calling a supplier in 2008.

"I am very insistent on contracts that the supplier designates a person and the timelines of response are codified."

Konrads Klints ran into the same gap in Episode 15, where a strong relationship with Microsoft counted for little without an operational contact who could act immediately. Alex adds that finding out the breach was not yours brings relief, but the people who handed over their data still hold you responsible. Isaac agrees, and leaves the legal question to lawyers and courts.

"I think you have a responsibility to handle these things with fortitude and grace."

Your Playbook Is Going to Break

Isaac's broadest lesson from the case reaches past suppliers altogether.

"Your diligence with your supply chain matters. And at the end of the day, none of that matters because your playbook is gonna break, your incident response plan is gonna break, and you have to be ready for it."

Yegor sums that up as advice to throw the playbooks out, since you will never use them. Isaac recognizes the joke and pushes back anyway.

"I think it's a feature, not a bug, that by the time you have written them, they are somewhat not helpful."

He would rather finish an incident and discover the plan did not cover it at all, because that gap is what improves the next version. He still values playbooks as training tools and as documentation that better automated workflows can be built on, which is why he calls documentation a lagging indicator that is acceptable as long as you keep improving it.

It is also why he likes tabletops, red teaming and chaos engineering, because every real incident he has handled has broken the plan somewhere. Micah Czigan works from the same premise in Episode 16, where a team has to pivot when the attack comes from a direction nobody drilled.

Isaac applies the same logic to compliance in his closing advice. Universities carry heavy compliance requirements, and clearing them can feel like being finished. So can winning an institution-wide rollout after months or years of arguing for it, such as MFA for everyone and then phishing-resistant MFA.

"Really it's like step one of 20."

Alex reaches for Mike Tyson's line about everyone having a plan until they get punched in the face. Isaac agrees that checklists and frameworks have value as a baseline showing what has worked broadly, but says your threats and your business are your own to build for. John Verry draws the line between passing an audit and being secure in Episode 9.

"I just don't want people to get caught up in a good place to start being a good place to finish."

Policy That Has to Earn Its Authority

The episode opened before the 2008 case, on what makes higher education hard to secure. Asked by Yegor about the biggest challenge in the sector, Isaac describes institutions running everything from point-of-sale systems and student laptops to research nuclear reactors, under pressure to be lean while still serving everyone, and without command-and-control authority to fall back on.

Yegor raises a point from their intro call, that policy at a university does not carry the weight it does in an enterprise. Isaac splits it into what he calls capital P policy and little P policy, and the two behave very differently inside a decision-making structure that is decentralized by design.

Yegor asks how much of that difference is technical and how much is hubris. Isaac says fifty-fifty, if he is honest. Specialized research instruments carrying their own certifications cannot take MFA the way a managed Windows fleet can. Some people simply do not want to be told what to do, and Isaac sees an academic environment as one that encourages that. He sees an upside too, because it rules out checklist security and "because I said so" as ways of getting anything done.

"You really gotta know what you're talking about."

A security leader who understands the risks and how people actually use the technology earns a hearing, and Isaac likes the credibility that requirement forces.

What Six Universities Could See Together

CanSSOC began with six Canadian universities facing a shared problem. Threats were growing, and even well-resourced institutions could not assemble the right expertise alone. Isaac says the value of pooling visibility goes beyond distributing threat information more efficiently, because institutions that collaborate this closely can be attacked across their boundaries.

Isaac's example has one group of attackers footprinting from a university's compromised VPN while another stages attacks from a second university's research systems. To each institution that traffic looks like normal collaboration, and only the combined signals show the chain.

Alex asks whether the promised benefit ever actually materialized, with one institution's incident protecting the others. Isaac says it did. CanSSOC built a shared threat feed, so indicators from an incident at one institution went into it, and for members without capable local staff, often places where the security person was a quarter of an FTE at best, the network and phishing blocklists went straight in. Within minutes, he says, those blocks were stopping activity the receiving institutions had not yet seen.

Yegor asks about the downsides, and Isaac names three:

• Complexity, from bridging many governance processes and technology stacks.
• Autonomy against value, since members need room to change their own technology, and each change shifts the ground under the shared service.
• A shared point of failure, whose monitoring and log retention choices every member inherits.

Yegor then asks whether a shared SOC lets security leaders rely less on indirect influence. Isaac would not call it command and control, but says an appeal to peer expertise does work in the sector, "whether it is peer professionalism or peer pressure."

"Peer reviewed command and control."

That is Yegor's summary, and Isaac takes it. His closing advice to higher education leaders makes the same point in fewer words. Do not go it alone, because whatever institutions compete for, they are not in competition on cybersecurity.

Research That Draws Nation-State Attention

Isaac turns next to the Citizen Lab at the University of Toronto, which, as he describes it, researches the use and abuse of technology where it meets politics, including identifying tools and techniques governments use to spy. Isaac treats it as one point on a wider spectrum.

Universities do plenty of work someone objects to, from research reactors to animal experiments, and research in general draws nation-state interest because so much innovation and intellectual property still comes out of universities. A group like Citizen Lab concentrates that attention rather than creating it.

Protecting research like that, in Isaac's view, means balancing the group's needs against the institution's, which he calls the job itself, with no fixed answer because the threats keep changing.

"I don't think that there is a playbook for how you protect somebody who's doing innovative work. I really don't."

Alex presses for something practical. Isaac's answer is to map it out as best you can, then test it:

• who the actors are
• what they are doing
• which technology is actually in use
• what the impacts would be

"If you try to do a threat map and a threat model and it's hard to do, I don't think you understand the problem enough."

Each place where he cannot write the risk down becomes the next thing to go and understand. The document is a means of finding gaps, and he warns against treating a written threat model as the finished work.

Where DNS Fits in the Signal Pipeline

Isaac's detection lessons come down to keeping records before you know which question you will need them to answer, and turning a shared indicator into a block quickly. DNS covers a narrow part of that. Control D provides two capabilities for it:

• Real-Time DNS Logging keeps historical query records, lets you choose where they are stored and how long they are retained, and streams DNS activity into your SIEM so it sits alongside your other sources.
• Custom Filtering lets you maintain your own blocklists, so an indicator shared by a peer can become a block across your network.

Our guide to DNS logging best practices covers what to capture and how long to keep it.

Neither would have found a transition document at a supplier, since DNS records show where devices tried to connect and say nothing about where a file was copied or who opened it.

Continue the Argument

• Episode 9: Why Your Audit Passed But Security Failed: Shadow AI & Compliance Theatre separates a working security program from compliance theater.
• Episode 14: I Unplugged The Entire Company To Stop A Live Breach shows what telemetry collected before an incident makes possible once one starts.
• Episode 15: Your Incident Response Plan Is Missing One Phone Number shows that the person you can reach at a supplier matters more than the strength of the relationship on paper.
• Episode 16: How Retained NetFlow Found a Five-Year APT Nobody Else Saw follows incident command past the edge of the runbook, when the scenario does not match the plan.

Browse the full Full Metal Packet series.

Isaac Straley is Chief Information Security Officer at the J. Paul Getty Trust. He was previously the University of Toronto's first CISO, where he also served as CISO for CanSSOC and was named CISO of the Year at CISO Forum Canada 2021. Before that he spent 13 years at UC Irvine, most recently as CISO for risk and compliance and campus privacy officer.

Full Metal Packet is hosted by Control D co-founders Yegor Sak and Alex Paguis. Watch Episode 18 on YouTube, or listen on Apple Podcasts and Spotify.

Common Questions Answered in Episode 18

How do you investigate a data breach when nothing shows up in your own logs?

Start with the people affected. Define who they are and what they have in common, then use that boundary to decide which records to trace. Isaac's team narrowed its victims to one academic term and followed every copy of the matching records, including paper ones, interviewing everyone who had handled them.

How can you tell whether a breach came from a third-party vendor?

Usually by eliminating your own systems path by path until the remaining questions sit with partners who received the data. In Isaac's case, physical evidence from the criminal investigation pointed toward one supplier, and interviews there found a document holding the data after the supplier had said none remained.

What should vendor contracts say about incident response?

At minimum, a named contact at the supplier and codified response timelines. Isaac insists on both after an investigation in which his team had to keep calling a supplier to get answers. Contracts do not give you visibility into the supplier's data handling, so they work best alongside tracking what you share and with whom.

Why do incident response playbooks fail in real incidents?

Because each one is written for incidents someone anticipated, and the incident that arrives usually differs in some way. Isaac treats each gap an incident exposes as an input, improving the playbook where it fell short and testing it with tabletops and red teaming, so that the documentation keeps catching up to reality.

What is a shared security operations center?

A security operations function that several organizations fund and use together, pooling detection signals and expertise. Canada's CanSSOC began with six universities. Pooled visibility can reveal attacks that cross institutional boundaries and lets one member's indicators protect the others, at the cost of added complexity and a shared point of failure.

Why is cybersecurity harder in higher education?

Universities run very different technology for very different missions, and decision-making is deliberately decentralized. Security leaders can set accountability centrally but rarely mandate one implementation for everyone, so they rely on credibility and influence rather than authority.

How should you communicate with victims during a breach investigation?

Regularly, even when there is little new to report, with enough detail to show the investigation is active but not so much that it compromises the work or adds to people's stress. Isaac's team updated affected graduate students about once a week through a couple of student go-betweens, telling them the work was continuing and that the university was not dropping it.