Cybersecurity Testing Expert Discusses AI in Security Products

Simon Edwards, CEO and Founder of SE Labs, is a cybersecurity testing expert with more than three decades of experience spanning security research, product evaluation, technical journalism, and industry standards. Before founding SE Labs in 2015, Edwards ran Dennis Technology Labs, where he led security testing initiatives, and earlier spent many years as a technology journalist and editor. He has also held senior leadership positions with the Anti-Malware Testing Standards Organization (AMTSO), including Chairman, Director, and Co-Chair. Edwards has been testing security products since the mid-1990s and pioneered early real-world anti-malware testing approaches designed to evaluate how security technologies perform against complete, internet-delivered attacks rather than isolated malware samples.

SE Labs is an independent cybersecurity testing and advisory company that evaluates how security technologies perform against realistic attacks. Its researchers replicate attacker techniques across the full attack chain to assess products including endpoint protection, Endpoint Detection and Response (EDR), cloud security services, firewalls, email security, and network detection technologies. Alongside public comparative testing, SE Labs provides certification, advanced security testing, product validation, and advisory services for enterprises and cybersecurity vendors. The company publishes its testing methodologies and threat emulation frameworks and is certified to ISO/IEC 27001:2022 and BS EN ISO 9001:2015 for the provision of IT security product testing.

Your career spans more than three decades across technology journalism, security consulting, independent testing, and leadership roles with the Anti-Malware Testing Standards Organization (AMTSO). How has that experience shaped the way you separate genuine advances in AI-powered cybersecurity from technologies that are primarily being positioned as “AI” for marketing purposes?

Journalism taught me to question claims, while independent testing taught me that the only reliable answer comes from evidence. Cyber security companies have used machine learning and automated decision-making for many years, so adding “AI” to a product name does not necessarily represent a technical advance.

Three basic things to consider: What is the AI actually doing? What measurable security outcome does it improve? And can an independent tester reproduce that improvement?

If the answer is simply that the product analyses a large amount of data or automates an existing process, the AI label may be more about positioning than capability.

A genuine advance performs well against unfamiliar or brand-new attacks, improves protection or response, reduces the burden on analysts, and does so without introducing unacceptable risks. Anything else is either a non-improvement or a downgrade!

“AI-driven” has become a common claim across cybersecurity products. What are the most important capabilities that should be independently tested before an organization accepts that an AI-powered security platform actually delivers what the vendor promises?

I would not begin by testing whether a product contains AI. I would begin by testing the security claims being made for it. I don’t really mind how a product works, as long as it works. This is the exact goal of the PIVOT testing programme, which is gaining a lot of traction in the industry right now.

Testing this way means exposing the product to complete attacks and measuring whether how it responds. It should probably detect the activity and then might go on to preventing the attack from progressing. This depends on how the product it is built and configured. And the marketing claims its vendor is making.

We also need to examine the investigative story presented to the customer. Did the system understand what happened, connect the relevant events and make the evidence visible to the person who must act on it?

The test should include unfamiliar variations, realistic customer configurations and normal business activity. It must also measure false positives, resource demands and actions that can be considered as being potentially unsafe. If the system is autonomous, we need to know when it acts, why it acts, what permissions it uses and whether its decisions can be reversed.

We’ve seen a few stories in the news about AI security going rogue and exceeding its boundaries and potentially the law. The important question is not whether the platform appears intelligent. It is whether it produces consistently better and safer security outcomes.

Autonomous AI agents can potentially execute reconnaissance, exploitation, lateral movement, and other stages of an attack far faster than a human attacker. How does cybersecurity testing need to change when attacks begin operating at machine speed?

The unit of testing needs to change from the individual technique to the complete campaign operating under time pressure. By that I mean, rather than trying out different ways of attacking over a morning or a week, testing certain security measures needs to happen fast. Otherwise it’s not realistic, and realism is very important.

Traditional tests may leave convenient gaps between stages so that each event can be examined separately. An autonomous attacker may compress reconnaissance, exploitation and lateral movement into a much shorter period. That could expose weaknesses that are not visible in slower tests, including delays in telemetry, overloaded systems and defensive actions that arrive only after the attack has achieved its objective.

To give you an extremely basic example, if we hack into a Mac, download all of its files and steal the account passwords, it’s not much use if the anti-virus pops up a day later with the bad news.

Testing security responses to AI attackers therefore needs high-resolution instrumentation and precise measurement of detection and response latency. It should examine whether performance deteriorates as the volume and speed of activity increase, and whether the defence can interrupt an attack without waiting for a human decision at every stage.

The attack may also adapt to what it discovers. Testing must reflect that while preserving ground truth, evidence and replayability. Machine speed should not mean abandoning controlled methodology. We need to continue to design controlled tests that can operate and measure events at the same speed as the systems being evaluated.

SE Labs uses realistic attack scenarios based on the tactics and techniques of threat groups such as Scattered Spider. How do you recreate these adversaries in a controlled environment while ensuring the test reflects how a real attack would unfold rather than simply testing against a predefined checklist?

We start with the adversary’s objectives, known behaviours and likely decision-making, rather than treating its techniques as a shopping list.

The test follows a realistic attack chain through reconnaissance, initial access, execution, privilege escalation, post-compromise activity and lateral movement. Importantly, the tester can use only information actually discovered during the reconnaissance and attack. We do not give the attacker knowledge that would not be available in a real engagement.

The scenario is bounded and carefully controlled, but it is not simply a sequence of predetermined button presses. If one route is blocked, the attacker may pursue a credible alternative within the rules of the test. That allows the security product to influence how the scenario unfolds.

At the same time, every important action and result is recorded so that we can explain the outcome and compare products fairly. Controlled does not have to mean rigidly scripted. It should mean safe, observable and supported by evidence.

Cybersecurity products have traditionally been evaluated heavily on their ability to detect threats. Why should organizations increasingly look at protection, containment, and incident response when evaluating AI-driven security systems?

Detection is not the same as defence. A platform can generate an accurate alert while still allowing the attacker to achieve the objective. This is why the PIVOT testing programme includes both detection and protection as joint and separate parts of the overall testing.

You can compare cyber security detection to a CCTV camera. It should notice an intrusion and give you clues about what happened, but it won’t stop an intruder physically. Cyber security protection is much more active. It can eject or otherwise neutralise an attacker, preventing harm.

Organisations need to know whether the product prevented the initial activity, interrupted the attack chain, restricted lateral movement, protected important assets and supported recovery. If an attack succeeds, the next questions are how quickly it was contained and whether the customer received enough reliable information to respond effectively.

This becomes particularly important with AI-driven systems because, while they may produce very convincing summaries of what happened, a persuasive explanation is not a substitute for protection. The explanation must be supported by evidence and must lead to an appropriate action.

We therefore measure detection and protection separately. We also examine whether the claimed detection was genuinely visible and useful to the customer. Ultimately, the value of a security system lies in changing the outcome of an attack, not merely observing it.

As security platforms introduce autonomous agents capable of investigating alerts and taking remediation actions, how should independent labs test the entire human-and-AI workflow rather than evaluating the underlying detection technology in isolation?

The test should follow the entire process from the first malicious activity to the final security outcome, which could be the attack being stopped or succeeding entirely – or somewhere in-between.

We need to examine what the agent observed, what it concluded, what it recommended or did, what the human operator was shown and how the operator responded (or what options they were presented with). That includes the quality of the evidence, the clarity of the handover, the time required, the number of interventions and whether the human could understand, challenge or reverse the agent’s decision.

Different operating modes also matter. An agent that recommends an action for approval presents a different risk from one that can automatically isolate systems, disable accounts or change security controls.

A system has not succeeded simply because its underlying detector identified the attack. If it creates an incomprehensible queue, hides important evidence, recommends the wrong response or takes a disruptive action, the overall workflow has failed. Independent testing should measure the combined performance of the technology, its autonomous components and the people expected to use them.

One risk with standardized security benchmarks is that vendors can optimize products specifically for the test. How can independent testing remain reproducible and fair while also introducing enough unpredictability to reveal how products perform against unfamiliar attacks?

Reproducibility does not require giving participants the exam questions in advance.

A credible test should publish its methodology, environment, scoring principles, product configuration and evidence requirements. Vendors should understand the rules and have a fair opportunity to verify that their products are operating correctly. However, the precise attack campaign, payloads and some of the attack paths should remain unknown until the test is conducted.

For example, in PIVOT we do not disclose which attack groups we are going to replicate until after the testing is complete. Real targets don’t get a heads-up before an attack starts!

We can combine a standard core, which supports comparison over time, with unfamiliar variations that test general capability. Baselining and a hidden quiet period can establish how the product behaves before the attack. Configuration should then be controlled, logs preserved and any claims checked against the tester’s own evidence.

Fairness means applying the same rules and standards of evidence to every participant. It does not mean repeating an attack so predictably that a vendor can recognise the benchmark instead of recognising the threat.

In addition, radical transparency helps vendors to reproduce attacks, which is important if they want to fix any problems they encounter, such as failing to detect or protect against a threat. SE Labs essentially trains its clients when they run into problems.

Autonomous security agents introduce a different category of risk because a false decision could trigger an unnecessary or even disruptive remediation action. How should testing measure false positives, incorrect reasoning, and potentially harmful autonomous actions alongside traditional detection accuracy?

Traditional false-positive testing is only the first layer. With an autonomous agent, we need to distinguish between a false alert, an unsupported conclusion and an incorrect action. Each has a different potential impact.

Tests should expose the system to legitimate activity that resembles malicious behaviour, as well as incomplete, ambiguous or misleading evidence. If the agent consumes untrusted content, testing should also examine whether that content can influence its decisions improperly.

The reasoning should be judged by whether the conclusion is supported by the available evidence, not by how plausible or confident the explanation sounds. For autonomous actions, we should measure scope, proportionality, use of permissions, approval controls, auditability and reversibility.

The scoring must reflect consequences. An unnecessary alert is inconvenient; disabling an important account or isolating a critical system could disrupt the organisation. A useful safety measure therefore needs to consider both the frequency of errors and the damage each error could cause.

All that said, sometimes the customer chooses a policy that causes problems. This isn’t necessarily the security vendor’s fault.

Generative AI and increasingly capable open-source models are lowering the barrier to automating parts of the attack process. Do you expect AI to make cyberattacks fundamentally more sophisticated, or is the larger danger that attackers will simply be able to operate at dramatically greater scale and speed?

My expectation is that the more immediate danger is scale, speed and reduced cost.

AI can help attackers gather information, personalise social engineering, modify code and coordinate parts of a campaign. Some attacks will become more sophisticated as a result, particularly when AI helps connect existing techniques or adapt them to a particular target. But AI does not remove the need for access, credentials, exploitable weaknesses or mistakes by defenders.

AI is also not very good at producing reliable exploits, which is hard enough for a skilled human to achieve. So that reduces the likelihood of fundamentally more sophisticated attacks, in my strong opinion.

The larger change is that activities that previously required time, skill or a team of people can be attempted more quickly and across many more targets. AI can raise the competence of relatively ordinary attackers while allowing capable attackers to run more operations simultaneously.

That is significant even if the underlying attack techniques are not revolutionary. The danger is not necessarily a completely new form of cyber attack. It is familiar attacks becoming faster, cheaper, more personalised and much more numerous.

As defensive and offensive AI agents become more autonomous, what will a credible cybersecurity testing environment need to look like to keep pace? Could we eventually reach a point where security products need to be continuously challenged by adaptive AI adversaries rather than evaluated primarily through periodic security tests?

A credible environment will need to resemble a living organisation rather than a collection of isolated targets. It should include endpoints, identity systems, email, networks, cloud services, realistic users and normal business activity. It must also provide complete instrumentation so that every decision and consequence can be reconstructed.

Adaptive adversaries could be given objectives and boundaries, then allowed to choose routes according to what they discover and how the defensive product responds. The test would still need controlled starting conditions, a reliable description of what actually happened and the ability to replay important events. Without those things, adaptive testing could become impressive-looking but scientifically weak.

I do expect testing to become more continuous, particularly when products, models and policies can change frequently. However, continuous challenge should complement rather than eliminate periodic comparative testing. Organisations need both: controlled benchmarks like PIVOT that support accountability and comparison, and ongoing adaptive evaluation that reveals how systems behave as the threats and the products themselves change.

I think we should worry more about the fact that relatively unskilled humans can breach systems and networks, rather than the robots creating the next generation of cyber attack technology.

Thank you for the great interview, readers who wish to learn more should visit SE Labs.