Danny Lieberman

How much of your value is at risk? | 5x founder, 4 exits, 1 flop.

[Danny Lieberman @flaskdata]

https://t.co/KGqSsqZCdy

[Danny Lieberman @flaskdata]

I personally like reuse as a principle because minimalism isn't just about having fewer things. It's about needing fewer different things.

- for software architecture, product design, and business processes.
- and for your work and personal life

[Danny Lieberman @flaskdata]

It's election time in Israel and the US
and there is a lot of noise.
Do you want a more minimalistic life? Company? Product?
I'd frame the 3 principles of minimalist design as:

1. Simplicity — Remove everything that doesn't contribute to the purpose. Every element must earn its place.

2. Reuse — Prefer existing components, patterns, and solutions over creating new ones. Reduce duplication and unnecessary variation.

3. Clarity — Make the purpose, structure, and behavior immediately understandable.

Minimize cognitive load.

Or, more provocatively:

Remove. Reuse. Reveal.
- Remove what isn't essential.
- Reuse what already works.
- Reveal what matters.

[Danny Lieberman @flaskdata]

Let’s chat about ways we can fix this for you. Let me know what times are best.

[Danny Lieberman @flaskdata]

From Sexy Starts to Messy Middles to Funky Finishes
Why I'm writing this to you.

As a serial Israeli tech founder specializing in cyber and privacy for medtech with customers like Amgen, Verily, Walmart Vision and innovative Israeli device companies, I realized MedTech CEOs have substantially more risk exposure than they think until it is too late.

Most CEOs lack the quantitative exposure in dollars necessary to properly prioritize cyber investments to protect enterprise value.

The first way to fix this is not intuitive - assume you will fail.

Instead of success, assume you want to fail

In this series of posts I will give you 23 anti-design patterns that guarantee failure and solution for each anti-design pattern.

Anti-pattern 1 - BrainFog

• Uncertainty on what your product does
• Uncertainty on who it’s for

Solution: Say your positioning in 10 words or less.
• What does your product do, who it’s for?

[Danny Lieberman @flaskdata]

@timhuyn thats awesome! The team picked their own papers and once every 2 weeks we had a rotation where a person would get up an give a short talk about what they learned.

[Danny Lieberman @flaskdata]

Does reading security papers makes your RA/QA team better at pricing the CEO’s bets?
The system lead at one of my startups worked at NY Life.
The CIO allocated first hour of the day to read research papers.
I loved the idea and adopted it as an SOP for my teams.

A recent paper on Arxiv shows sensitive information recovered from an AI processor’s electromagnetic emissions.

The POC uses a probe close to the silicon, controlled processor settings, and specialized measurement equipment.

Interesting research.

Now comes the work that matters for your device.

Can someone get sufficiently close?
Can they collect a useful signal through the packaging?
Does the attack apply to your hardware and model?
Would the information recovered have meaningful consequences?

RA/QA can leverage side-channel attacks into design decisions.

And you'll know if you read.

[Danny Lieberman @flaskdata]

What evidence would make you move a new research finding into your product’s risk analysis?

[Danny Lieberman @flaskdata]

Does your threat analysis consider what an attacker could learn from a legitimately purchased unit?

[Danny Lieberman @flaskdata]

Your engineers, RA/QA and CFO love standardization of hardware and software.
Could it also help an attacker study it and mount a side-channel attack?

• Same processor.
• Same runtime.
• Same model.
• Same configuration.

That consistency helps engineering, manufacturing, support, and change control.

It may also let an attacker study a unit they own before approaching one they don’t.

For physical side-channel attacks, the important question is whether measurements learned on one unit transfer to another.

That transfer is an assumption to test. Hardware variation, enclosures, interference, and operating conditions may change the result.

Here is the risk story I would investigate:

acquire a device → characterize its leakage → attempt inference on another unit.

Where does that story become impractical for your product?

Standardization creates commercial value. Understanding its security consequences helps protect that value.

[Danny Lieberman @flaskdata]

@boardyai @hf0 30

[Danny Lieberman @flaskdata]

As hardware gets better and small local models improve - the economics favor cheap hardware and local LMs.

Are you betting on local LMs and edge AI?

That’s a bet I think a lot of AI medical device developers will make this year.

You can sell robust privacy, predictable performance, and offline operation.

But can you ignore side channel attacks?

[Danny Lieberman @flaskdata]

Is encryption a magic bullet for medical devices?
It wasn't even a required countermeasure in the HIPAA Security Rule.
Thinking about what risks really count is the closest you'll get to magic bullets.

So when your engineer says, “It’s encrypted.”

• Which part of the patient’s journey does that protect?
• What's encrypted?
• Where encrypted?
• How encrypted?

A local clinical AI device runs in a Raspberry Pi edge device with a small local LM

patient information → encrypted storage → inference → clinical output.

Encryption protects the stored information. TLS protects information crossing a network.

During inference, the processor uses the information.

The side-channel research in my latest essay examines leakage from that computation through electromagnetic emissions.

The researchers needed controlled conditions and a probe close to the processor. Applicability to a medical device needs its own assessment.

But “we use encryption” does not answer that particular threat.

That is why I like writing risk as a story.

[Danny Lieberman @flaskdata]

This is where RA/QA’s knowledge of actual use can change the engineering analysis.

What deployment assumption have you seen fail once a device reached the field?

[Danny Lieberman @flaskdata]

Here's a question for RA/QA teams for validation - Who can get physically close to your AI medical device?
And for how long?

Imagine the same device deployed in three places:

A controlled procedure room.
A shared clinic.
A patient’s home.

The hardware and software are identical. Physical access is very different.

For a side-channel threat, that difference matters. An attacker may need equipment close to the processor, time to collect measurements, and conditions that make the signal useful.

Those requirements belong in the risk story.

Who can approach the device?
Can they touch or open the enclosure?
Would anyone notice equipment placed nearby?

A laboratory demonstration becomes relevant to your product only when you examine those assumptions.

[Danny Lieberman @flaskdata]

What evidence supports the privacy claim across the device’s actual operating environment?

“The data stays local” describes the architecture.

How would you word the privacy claim you could defend?

[Danny Lieberman @flaskdata]

RA/QA: “The patient data never leaves the device.”

Would you sign off on that claim?

Moving clinical AI onto the device has real advantages. Less dependence on connectivity. Faster responses. Less patient data sent to cloud services.

But follow the data one step further:

patient → prompt → processor → output.

The processor has to use the sensitive information. Its physical activity can reveal information about what it is doing.

The research I discuss in this week’s essay demonstrates that possibility under controlled laboratory conditions, with a probe close to the processor.

That does not establish an attack from a hospital hallway.

It does give RA/QA a new question

[Danny Lieberman @flaskdata]

Read the full article here
https://t.co/spijEVURtv

[Danny Lieberman @flaskdata]

Local doesn’t mean private
Side-channel attacks on edge AI in medical devices.

I was a technician in a communications battalion in the Israeli Army. We provided communications infrastructure for an armored division. Two of us handled encryption of trunk communications. Our equipment sat in an armored van and the lines in and out were physical cabling.

I was trained as a physicist. Sitting in the van - I often wondered how much of the radiation leaking from those cables could be remotely detected, and at what distances.

Today - I got an answer to my old question.

Researchers at University of Amsterdam recently demonstrated a proof of concept attack extracting output tokens and user prompts via electromagnetic emissions.

See this article on Arxiv published Oct 9, 2026.

The deployment of large language models (LLMs) on edge devices is largely motivated by privacy concerns over sharing sensitive user data with cloud servers.

The authors demonstrate that keeping inference local does not eliminate privacy risks

They put a near-field probe next to the processor and measured what the chip radiated while it was computing.

[Danny Lieberman @flaskdata]

Healthtech AI projects fail because we don't price failure.
And I'm as guilty as anyone else.
Here are 5 things I'd write in your AI project post-mortem.

① You didn't have Metrics. Not the measurement. Not the sample frequency. Not who sees the numbers and when.

② You treated Time as free. Six months of your team feeding data into a system that produced nothing useful. Failure is a learning experience with a price-tag.

③ You ignored Rework. When the AI output is wrong — and it will be, at some point — someone pays to fix it. That someone is you.

④ You closed your eyes on Opportunity cost. Projects got deleted because this one burned the budget. They don't appear in the failure report.

⑤ You assumed Reputation will be a win. Risk-taking is rewarded (or not) but improvement requires risk quantification. Not vocabulary.

If you can't say how your healthtech AI project will grow enterprise value — in dollars, weeks, and headcount — you're not ready to execute.

And neither are the consultants on LinkedIn selling you frameworks instead of answers.

Which of these five did your last project skip?

[Danny Lieberman @flaskdata]

When AI imaging systems process a scan - there is a 4 step handoff - patient->DICOM->AI->clinical action

Where in your current pipeline is patient identity hard-checked before clinical execution?

[Danny Lieberman @flaskdata]

Federated learning does not assure patient data privacy

Complex software systems are like dysfunctional families - they have unexpected threat surfaces.

A new NeurIPS 2026 paper showed a proof of a federation learning threat surface: the model updates exchanged during federated training can contain enough information to reconstruct individual chest X-rays, CT images and pathology tiles.

Model inversion attacks
In federated learning, each hospital trains the model locally and sends gradients or updated parameters to a coordinating server. The server combines those updates into a shared model.

The problem is that gradients are not harmless metadata. They encode information about the examples that produced them.

Model-inversion attacks exploit that information to reconstruct training samples. Earlier attacks worked mainly against small batches or unrealistic configurations. Newer attacks—including Robbing-the-Fed, LOKI and Scale-MIA—use specially constructed model layers to recover inputs in closed form at clinically realistic batch sizes.

In our models, that single failure mode averages a $4.1M+ single-loss expectancy.

See https://t.co/Jfz1V2EDq8