Onam Security technical whitepapers

From cloud inventory to a confirmed, MITRE-mapped, scored attack path — the method, step by step.

• How primitives compose into a chain, rather than matching a pre-authored shape
• Verification: why only edges confirmed by evidence are walked
• MITRE ATT&CK mapping and how a path gets ranked

A methodology paper, not a benchmark. The examples come from a demo tenant and are illustrations, not customer results.

How Onam puts a FAIR-style loss estimate on each finding — with every input shown, so a board can see what drives the number.

• Loss magnitude and frequency, and where each input comes from
• Which inputs describe your business, and how to set them
• Why findings on attack paths carry more weight than isolated ones

An estimate is only as good as the inputs and data classification behind it. It orders findings; it does not predict a breach.

Why every engine writes the same finding contract into one store — and what that makes possible that a drawer of separate tools cannot.

• The shared finding contract every engine conforms to
• Why correlation is a property of the data model, not a feature bolted on later
• What a single graph buys you across posture, identity, data and runtime

One data model is an architectural choice with real trade-offs — it constrains how fast any single engine can diverge.

How Onam evaluates a control once and reports it against 78 frameworks — and reads each gap alongside the attack paths it sits on.

• One control evaluation, many framework projections
• 78 compliance frameworks over a single control set
• Why a compliance gap matters more when it sits on an attack path

Framework mapping gives your auditor evidence per control, kept current between audits.