Cybersecurity Lessons From Lab Med Autoverification

I want to recommend this article to my fellow cybersecurity professionals:

https://thehackernews.com/2026/07/thinking-fast-and-slow-in-soc-case-for.html

It does a nice job laying out reasonable roles for AI (pattern-matching donkey work) and human co-pilots (distinguishing the abnormal from the malevolent).

Since a big part of why Pythia Cyber exists is to get more people in management to see cybersecurity as part of their job, I am going to write the rest of this post as a way to explain this strategy by way of an analogy that is not based in cybersecurity.

Once upon a time I consulted to the laboratory medicine department of a large academic medical center. A large clinical laboratory is not a monolith, it is a conglomeration of different focus areas such as Immunology, Hematology, Chemistry, Virology and some other more obscure areas.

The goal was to interface automated analyzers to the Laboratory Information System (LIS), but not directly because it was common wisdom that a qualified and experienced human being had to review the results before those results were published to the clinicians. So we created middleware to act as a waystation between the analyzer and the LIS by supporting human verification.

Human nature being what it is there were pressure to automate this process at least to some degree. The two areas chosen for autoverification were Chemistry and Hematology because these are very mature branches of laboratory medicine. The move toward autoverification was going very slowly because of lab tech resistance until I had an insight: there was a vocabulary problem.

To Chemistry, "autoverification" meant "catching results which cannot be correct." This was because, at the level of chemical analysis, the human body is a highly bounded system for which this area could make very precise measurements. They didn't want actual autoverfication, they wanted auto-not-verification. For example if a blood specimen registered 0 mEq/L then something went wrong. Human blood has salt in it. So flag the result as invalid. If the specimen had 170 mEq/L then flag the result as needing review because this is possible but unlikely.

To Hematology, in contrast, "autoverification" meant "automatically verifying results which are weird in a way that I already flagged as likely for this particular patient." This was because, at the level of cells and substances found in the bloodstream, a highly variable system for which even precise measurements were open to interpretation. For example, if a patient is being treated for anemia then DO NOT hold up a result with a low result if a human being has already verified recent results for this patient with similar values.

Current day cybersecurity has a similar problem: there are too many data points to review. Having human beings review too many data points tends to make human beings bad at reviewing the data points they do review. We need to lighten the load without endangering the organization. I see the same two options for automation: the Chemistry approach and the Hematology approach.

If you are reviewing data from a strictly limited system then identifying that which should not be is the kind of sophisticated pattern-matching that a properly trained AI can do very well. For example, LAN traffic ought to be circumscribed enough to employ this approach.

If you are reviewing data from a widely variable system then identifying that which has already been flagged at good or bad is the kind of job that a properly trained AI can do very well. For example, web traffic or external email traffic is variable enough to warrant this approach.

Not that in neither case do I advocate going all in on automatic review. The humans have to do their part. Taking another cue from laboratory medicine, we didn't just let autoverification run unattended. Instead we set numbers of automatically verified results to be randomly selected for human review and we kept track of the results of this QA.

Cutting the haystack down to a manageable size is becoming essential for many cybersecurity programs. Making sure that you aren't removing any needles when you cut down the haystack is just as important as keeping your haystack manageable.

Balancing automation and risk is hard. We can help. Ask us how.