Ten years ago a security leader could work in relative obscurity. The team rarely briefed the board, incidents mostly meant data leaving the building, and nobody outside the function paid close attention. But two things ended that. Ransomware turned a security incident into an operational and economic event, closing pipelines and factories and stores. And then AI compressed the time a security team has to respond, which pulled chief executives into conversations about cyber risk they had previously delegated. The role changed underneath the people doing it.
And still, what has not caught up is the standard security leaders hold themselves to, as most measure themselves against the budget they were handed rather than against the threat they face. But the two are not the same thing, and that gap is the ground this issue covers today.
Welcome to Issue 03 of InfoSec Leadership by InfoSec Relations, featuring Joe Sullivan. He was among the first federal prosecutors in Silicon Valley dedicated full-time to cybercrime, then served as Chief Security Officer at Meta, Uber, and Cloudflare, and now advises companies and boards through his company Joe Sullivan Security. You can also watch our full podcast interview here.
Let's get started.
Attribution, Hacking Back, and CISO Liability
A former federal cybercrime prosecutor and Big Tech CSO on attribution, active defense, and the personal exposure security leaders now carry.
Ask a group of security leaders whether attribution is worth the effort and the answer divides sharply along the lines of where each of them started. Sullivan has watched it happen repeatedly. "Every time I see the topic of attribution come up in one of my CISO Slack groups, it's a very polarizing topic," he says. People who came into the field from law enforcement ask who is on the other side, because that is the question an investigation exists to answer. People who came in from engineering ask how to stop the thing from happening again.
"Both instincts serve a purpose," Sullivan reasons, being careful not to dismiss either one. He himself arrived from the first camp, having spent eight years at the Department of Justice working technology crime before moving into industry. But he concedes the practical pull of the second, noting that the calculation changes the moment you move inside a company. "When our job is inside the company, we don't get to think very often about attribution, because it's our job to prevent the company from getting hurt by anyone." Budgets are finite, and a security leader would usually rather spend the next dollar hardening something than naming someone.
That means attribution is rarely a philosophical choice. It follows from who you hired, what industry you operate in, and which attacks keep knocking against your perimeter.
Law Enforcement Cannot Move Without What Companies Hold
The strongest case for attribution has little to do with the satisfaction of naming an adversary. It has to do with who now holds the evidence.
Sullivan in our interview traced the argument back to his days at eBay, where he led the team fighting fraud after leaving government. The company trained users against phishing, built automated defenses against account takeover, hunted fraudulent listings, and modeled risk across everything it could see. "None of it was enough," he recalls. "Because a single organized criminal group in one country had worked out how to defraud the platform, got good at it, and watched the technique spread through their network." And this led to a conclusion no amount of engineering could deliver, so Sullivan started flying to that country himself. Between 2004 and 2008 he made the trip seven times, first to train the police who would investigate the pattern, then the prosecutors who would charge it, then the judges who would hear it.
"We realized we couldn't stop the attacks just by sitting at eBay headquarters using technology," he reflects. "We had to create an environment where people worried they'd get in trouble with the law." That is the entire logic of deterrence, and it does not function without evidence.
Here is the part that should give security leaders pause. Before the internet, most of what police needed to investigate a crime was reachable by police. But with the rise of internet technologies and the movement of everyday life onto them, that is no longer true. "Now all of that data is in the hands of private companies," Sullivan says. Companies see the attacks, the addresses, sometimes the originating machines. This means attribution that stays inside the company produces no consequence for anyone. Only once shared with law enforcement does it become the mechanism that puts attackers at risk.
Build Prevention First, Then Detection, Then Attribution
For most organizations the question is not whether attribution matters in principle but whether it deserves any of a constrained budget. Sullivan's answer in our conversation was refreshingly blunt, arguing against buying threat intelligence.
He shared an observation from his consulting work that most security leaders might resonate with. Companies fund security at the bare minimum. A chief executive with a hundred dollars spends it on product, then on sales, then on more product. Everything classed as a cost of doing business, whether legal or finance or security, gets what it needs to function and nothing beyond. "When you give money to the security team, your revenue doesn't grow," he says. The industry has never made that argument well.
Given that reality, sequencing matters more than ambition. Financial services firms invest in threat intelligence because they are under constant attack by people who can convert access directly into money. A small or mid-sized company without that risk profile should not. "You should focus on getting your foundations in place," Sullivan says, underscoring identity and access management, device management, and cloud security. "You have to do those first."
The order he describes is worth writing down. Invest in prevention, then build detection, and treat attribution as a function that grows out of detection rather than one you buy separately. Only mature organizations reach the last stage, and reaching it early tends to mean skipping something more useful. That in reality is not maturity, it is misallocation wearing the costume of maturity.
AI Will Help With the Part Humans Were Always Bad At
Sullivan is more optimistic about AI in cybersecurity than about most things, and he shared his reasoning in structural terms rather than enthusiastic ones.
Split security work into prevention on one side and detection with attribution on the other. Then ask what these systems are actually good at. "Finding a needle in the haystack, getting through a large volume of data much more quickly than a human ever could," he says. "And what is detection and attribution all about? Finding needles in haystacks." The capability maps onto the problem almost exactly.
Through his part-time work with a venture firm investing in security startups, he is watching that shift arrive in two forms. Some companies apply models to data that already existed and nobody analyzed well. Others send agents onto the internet to pose as victims or as other criminals, operating at a scale and persistence no human team could sustain. "That's stuff humans just didn't have the bandwidth or patience or resources to do until now."
Being careful about the timeline, in the short term he sees little change. Over a longer horizon he expects meaningful gains, which tracks a familiar pattern, because leaders building cyber resilience tend to overestimate what they can achieve in a single year and badly underestimate what they can achieve in five.
Plenty Happens Between Passive Defense and Hacking Back
The argument for letting companies strike back resurfaces every few years, usually driven by frustration rather than by a new idea. Sullivan understands the impulse and treats it seriously. "Too many attacks happen, too many people get hurt, too many companies suffer from ransomware," he says. "When you keep getting punched in the face, it feels good to punch back."
And on where the line belongs between defending yourself and going on offense, he is unequivocal about who draws it. Because that decision belongs to the government, as "companies shouldn't make it on their own."
What interests him more is how much room already exists on the legal side of that line, which most organizations never use. Microsoft has spent years filing civil suits against attackers and running coordinated takedowns of compromised infrastructure, with lawyers seated beside the investigators and engineers throughout. Sullivan shared a smaller example from his own tenure. While he was at Facebook the company came under attack and noticed that the domain registration the attackers depended on had lapsed. So they registered it themselves, took it over, intercepted the traffic, and used what they saw to warn other victims. "We don't have to be a hundred percent passive." This is entirely legal, genuinely useful, and far rarer in practice than it should be.
He is also equally clear about why full offense unnerves him, and the reason is operational rather than legal. Consider the common tactic of flooding a phishing site with fabricated credentials to poison the attacker's harvest. Five thousand entries creates noise. A million entries in five minutes might take the hosting provider offline and disrupt every legitimate business behind it. "The internet is a very connected and interdependent world," he cautions, as the damage from a miscalculated response lands on people who were never part of the fight. Most companies handed permission to go on offense would decline it, and to much extent he thinks they would be right to.
Liability Is Moving Toward the Person Who Made the Call
The governing question underneath all of this is who answers when something goes wrong, and the answer is shifting.
Sullivan also describes a pattern governments have followed before. Corporate liability comes first. Then regulators notice that employees still make poor decisions because nothing reaches them personally, and the enforcement moves toward individuals. "We've seen enforcement actions, like the one the government in the United States brought against me, where they want to hold individuals accountable," he briefly shared his experience, and notes that similar laws are appearing well beyond the United States.
His view on where that accountability should start will be uncomfortable in some boardrooms. "If you're going to hold individuals accountable, ideally you start at the CEO," he says, because that is the person making strategic decisions. The corollary matters just as much for anyone running a security function. "Security leaders should never operate in a vacuum. They should always be coordinating with their board and their CEO on anything that gets into this category." This is because the decisions that generate personal exposure are almost never purely technical ones, and the person carrying the risk should never be the only person in the room who saw it coming.
Keep Lawyers in the Room and Skip Law School
After his own case, Sullivan fielded the same question from security leaders over and over. Should they go learn the law themselves?
"My answer is always no. That's a different function's job." The instinct behind the question is understandable but the conclusion it leads to is wrong. A security leader is a technical and operational leader who owns technical and operational risk. Legal expertise belongs to lawyers, and the fix is to have them present rather than to acquire their training.
What he insists on instead is structural. Legal counsel should be in the room for these conversations as a matter of routine. "We should never be saying, legal said do A, but we're going to do B. That's not how we operate in security." Each function names the gray areas it can see, counsel identifies what is clearly across the line, and the company makes a strategic decision with both pictures in view.
That last step belongs to the chief executive. "Executives take calculated risks constantly," Sullivan draws a distinction worth sitting with, "because no company gets built by people unwilling to attempt something unproven." It's important to understand this because security leaders are not trained for that kind of judgment and should not pretend otherwise. The job is to understand your own role precisely, then make sure everyone else involved lands on the right side of the law.
Trust Gets Built Before the Crisis, Never During
The most portable advice in the conversation costs nothing and almost nobody does it.
"Nobody performs well under pressure," Sullivan says. "Trust isn't built then. Trust is built ahead of an incident." His recommendation to the leaders he often advises is to run tabletop exercises with the chief executive and the lawyers in the room, working through the questions that will otherwise arrive mid-crisis. Who decides whether to pay a ransom. How much the company invests in attribution. What the organization actually believes about disclosure.
That last question is the one he presses hardest, because a company's answer is a choice rather than a given. He watched a strong version of it at Cloudflare, where every incident and outage produced a detailed technical post explaining what happened. During his first major incident there he called the chief executive with a status report, and the second question back was who would be writing the blog post. "I was thinking about stopping the bleeding and making sure the company was okay," Sullivan shares, reflecting his own instinct in the moment. The chief executive was already thinking about transparency, assigned the writing to someone with capacity, and the account published by the following morning. That is genuine, true leadership.
The point is not that every company should publish incident postmortems. It is that the culture had been decided long before anything went wrong, so nobody had to negotiate it while the clock was running.
Sharing Beats Silence When Attackers Work a Vertical
Sullivan wants security teams to bias toward sharing information, and his argument turns out to be self-interested rather than idealistic.
Attackers who find a technique that works rarely use it once. He watched the pattern repeatedly at Cloudflare, where the denial-of-service mitigation product gave him a view across many victims at once. An extortion crew would work out how to disrupt the video traffic underpinning one category of company, hit the first target, then move methodically through its competitors. A company that solves the problem and tells nobody leaves every peer in that vertical exposed to a technique already known and already beaten.
Being realistic about the reluctance, he names the simple truth underneath it, that no company wants to advertise it was vulnerable. But the calculation changes once you count what flows back. "If they felt that being transparent led to others being transparent with them, so that they'd get information and be in a better place, they'd be more likely to do it," he says.
The same logic answers the harder question of what to do when you cannot tell whether you are facing criminals or a state. Sullivan's position is that the distinction matters less than security teams assume, because the job is to stop the harm either way. What should trigger a change in approach is persistence. When an adversary keeps returning no matter how many times you push them out, defense alone stops being a strategy, and that is the moment to bring in law enforcement and peers and pursue disruption collectively. "The bad actors have no trouble sharing information and approaches with each other," he says. "So the good actors need to get comfortable sharing with each other more as well."
Doing Your Best With the Budget Is Not the Same as Secure
Asked what he wants boards to ask their security leaders, Sullivan turns the question toward the profession itself, and this was one of the sharpest things he said.
"I feel like in cybersecurity we've accepted a level of security that's not good enough." Years of underfunding produced a coping mechanism that hardened into a standard. A security leader delivers a great deal with a constrained budget, concludes reasonably enough that the work was good, and stops there. "But that doesn't mean the company is secure," Sullivan points out plainly. "There's a difference between doing a job with a limited set of resources and being secure."
He wants boards to make that distinction sayable out loud. "Saying you're not secure is not saying you're not doing a good job." And he exhorts security leaders to answer with something more useful than reassurance. The format he suggests is a menu. Here is what your hundred dollars bought. Here is what another hundred would add, and another after that, and here is what world-class actually requires. "We don't have that honest conversation enough."
The underlying failure is one of the reference points. "We know what good looks like. We know what world-class looks like, but we don't hold ourselves to that standard. We hold ourselves to what we could do with the resources and risk profile we inherited."
Biggest Risks Exist Between Your Teams
For the one thing security leaders most consistently get wrong, Sullivan points somewhere unexpected. Hiring, and more precisely how teams get carved up.
Compliance frameworks encouraged the field to organize into verticals, and those verticals became the shape of the organization. "When I go into security organizations, the biggest risks I see are the gaps between the teams they set up." His example is the wave of fraudulent remote workers who took jobs at technology companies under false identities and used the access to steal data. It took roughly three years for anyone to catch the pattern, by which point thousands had been hired.
The reason it went unseen is the part worth internalizing. The risk fell between existing functions, so no team owned it. "If you asked everybody on the security team whether they were doing a good job, they'd all say yes. But holistically the company was not doing a good job, because of the way the team was set up."
His prescription is to interrogate your own structure on a regular basis. Are you building silos. Are people empowered to think about risk across the whole picture. Do they have the bandwidth to step back at all, or is everyone on a treadmill of alerts and configurations, declaring the job done when their own queue empties. "If people are just in narrow lanes, they're not thinking holistically about risk, and the world is too dynamic and changing too fast," he says.
CISO Action Plan
Attribution and active defense make for good debate, but the calls that decide outcomes get made long before an incident. Here is what Sullivan recommends that security leaders should settle now.
- Sequence your investment: prevention, then detection, then attribution. Identity and access management, device management, and cloud security come first. Attribution grows out of a detection function rather than arriving as a separate purchase, and only mature organizations get real value from investing there directly.
- Decide what you will share, and with whom, before you need to. Most larger US organizations already name their law enforcement contacts inside the incident response plan. If yours does not, fix that, and register with the FBI's Internet Crime Complaint Center and CISA's reporting channel so the path is known rather than improvised.
- Join the peer channel for your sector. Attackers who find a working technique move through a vertical company by company. Your sector ISAC is where that pattern surfaces early enough to matter, and the value only flows if you contribute as well as consume.
- Run a tabletop with your CEO and your general counsel in the room. Work through who decides on ransom payment, how much attribution is worth, and what the company believes about disclosure. CISA publishes free tabletop exercise packages if you need a starting structure. Trust does not get built during the incident.
- Keep counsel in the room and stay in your lane. You own technical and operational risk. Lawyers own the legal boundary. Never run a plan that contradicts legal advice, and never treat legal fluency as a substitute for having legal present.
- Map the gaps between your teams, not just the teams. Ask which risks would fall between your current functions and go unowned. Give someone the bandwidth to look across the whole picture rather than clearing their own queue and calling it done.
- Take the budget conversation to the board as a menu. Show what the current investment buys, what each additional increment would add, and what world-class actually requires. Saying the organization is not yet secure is not the same as saying the team is underperforming.
For the engineering view of how fast this is all moving, our Offensive Engineering issue 'Machine-Scale Cloud Security' goes inside a four-hour window between advisory and widespread exploitation, and the trust gap holding back automated response.
Thank you for reading InfoSec Leadership.
If you found this analysis useful, please subscribe to the InfoSec Leadership newsletter so you never miss an update.
Lead with clarity, defend with purpose.
S Pattnaik Technical Contributor and Volunteer Host
This issue draws on InfoSec Relations' interview with Joe Sullivan, Attribution and Active Defense, with a Former Prosecutor and CSO, hosted by S Pattnaik for InfoSec Leadership.
