By Most security teams read threat reports and move on. The problem is that a spike in DDoS attack duration, an anomalous API incident rate, or a DNS configuration gap does not trigger a portfolio review or a board conversation unless someone explicitly maps the data to a coverage decision. When that mapping does not happen, organizations carry risk they have not consciously chosen to accept.
In this interview on TFiR, Steve Winterfeld, Advisory CISO at Akamai, walks through a practical framework for turning threat intelligence data into security decisions, covering DDoS, API security, generative AI risk, and DNS.
Guest: Steve Winterfeld, Advisory CISO at Akamai
Show: TFiR
Here is what every security leader and CISO needs to know.
Technical Deep Dive
Q: How should a CISO use a threat intelligence report to reassess their security portfolio?
Steve Winterfeld, Advisory CISO at Akamai, recommends starting with the data points that show dramatic increases, specifically DDoS attack duration, bot activity volume, and API abuse rates. When those numbers have shifted significantly, the immediate question is whether current security capabilities can defend against the latest attack scope and duration. If they cannot, the CISO must decide whether to allocate additional budget or escalate the gap to the board as a risk acceptance decision.
“The first things I like to do is where I see a dramatic increase in DDoS or APIs, a dramatic increase in bot activity, dramatic increase in the length of an attack, then I want to go look at my security capabilities and make sure that my current capabilities are able to defend against the latest scope and duration of attack.” — Steve Winterfeld, Advisory CISO, Akamai
Q: What does a zero API incident rate actually indicate for a security team?
Winterfeld treats a zero API incident count as a red flag, not a clean bill of health. When industry data shows 96% of organizations experience API security incidents and an individual organization reports none, the more likely explanation is a gap in detection visibility or reporting accuracy rather than an absence of attacks. Security leaders should use the benchmark as a validation check on their own tooling and observability before concluding their environment is secure.
“If we’ve had zero API incidents and I know the industry standard is 96%, then I’m worried about whether my reporting is accurate, whether my visibility is accurate.” — Steve Winterfeld, Advisory CISO, Akamai
Q: How should a CISO communicate unmitigated risk to the board when security capabilities fall short?
When a capability gap is identified and a budget increase is not immediately available, Winterfeld recommends escalating the specific risk to the board and making the acceptance decision explicit. The board should understand the nature of the exposure, the current capability ceiling, and the options available. This shifts risk ownership from the security team to leadership and creates a documented decision trail.
“Do I put more budget into that or do I go and communicate to the board that risk and make sure the board wants to accept that risk.” — Steve Winterfeld, Advisory CISO, Akamai
Q: Is a finance-sector threat report relevant to organizations outside financial services?
Winterfeld argues that even sector-specific reports carry cross-industry value because finance and commerce consistently rank in the top tiers for most attack categories. Different industries land at different positions in the threat distribution, but the attack techniques, attacker behaviors, and tooling documented in a finance report remain relevant benchmarks for any organization. The data helps security teams understand what adversaries are doing broadly, not just within one vertical.
“Finance is usually in the top three for most kinds of attacks. Commerce is usually in there. Different industries fall at different levels. But it’s a good look.” — Steve Winterfeld, Advisory CISO, Akamai
Q: What are the three layers of generative AI risk a CISO must account for in their security strategy?
Winterfeld outlines three distinct protection surfaces that emerge as organizations adopt AI. First is the risk from employees using AI tools, which requires policy and data governance controls. Second is AI embedded in third-party purchased capabilities, which expands the vendor risk surface. Third is AI offered as a capability directly to customers, patients, or clients, which introduces both attack exposure and liability. A complete AI security strategy must address all three layers independently.
“I’ve got to protect my employees’ use of AI. I have to protect my buying capabilities that have AI embedded in it. And I need to protect where I’m offering AI as a capability to my customers.” — Steve Winterfeld, Advisory CISO, Akamai
Q: Why is DNS frequently overlooked in enterprise security programs and how should teams address it?
Winterfeld flags DNS as an area where security programs routinely leave gaps, often because DNS infrastructure is treated as a networking concern rather than a security surface. Akamai’s threat report includes data on the most common DNS configuration errors and provides a checklist that security teams can use to audit their current DNS posture. The checklist format makes it actionable without requiring deep DNS expertise from the security team.
“DNS is easy to overlook. There’s some stats on the most common errors, and there’s a great checklist to use to make sure you’re not leaving a gap in your DNS program.” — Steve Winterfeld, Advisory CISO, Akamai
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: Now these reports, they play a very critical role in informing, educating users. When cyber leaders look at a report like this, how should they actually use the data in a practical way so they turn insights into actions.
Steve Winterfeld: So for me, the first things I like to do is where I see, you know, a dramatic increase in, and take the example of DDOs or APIs, a dramatic increase in bot activity, dramatic increase in the length of an attack, the duration of a DDoS attack. Then I want to go look at my security capabilities and make sure that my current capabilities are able to defend against the latest, you know, turbo Mirai scope and duration of attack. And if not, then I’ve got to make a decision to do I put more budget into that or do I go and communicate to the board that risk and make sure the board wants to accept that risk. And so those are the first things I kind of do is say, do I need to readjust my portfolio of risk? The second is a lot of this is around understanding what the criminals are doing. So as I look at some of the more technical aspects of the report, then I want to go in and say, okay, how many incidences of API security have we had? And if we’ve had zero API incidents, and I know the industry standard is 96%, then I’m worried about is my reporting accurate, is my visibility accurate? You know, and so that’s kind of a validation check. API. Again, looking at the API stats in here, and if mine don’t kind of correlate. And again, this is a finance report. We did a global report. But at the end of the day, you know, if, even if I’m not in finance, it’s important for me to go look, you know, and say, what is here? Finance is usually in the top three for most kind of attacks. Commerce is usually in there. Different industries fall at different levels. But it’s a good look. The generative AI stuff. I think what we want to look at here is where am I in my strategy development? I’ve got to protect my employees use of AI. I have to protect my buying capabilities that have AI embedded in it. And I need to protect where I’m offering AI as a capability to my customers, customers or clients or patients or. And as I look at all this, you know, this is a great report to help me kind of understand what kind of aspects I need to bring into that strategy. And the last is, you know, DNS is easy to overlook. We really did a great report. The guys on the team that dug into this around DNS, the there’s some stats on the most common errors, and there’s a great checklist to use to make sure you’re not leaving a gap in your DNS program.
