Risk register: exposure, what attackers see first

Your Sunday briefing · Risk series

Over two Sundays, your register has taken shape. The first episode named the ten scenarios that would stop the business; the second put four names against each one. One thing is still missing, and it is the first thing an attacker looks at: where could each of these scenarios start?

A register describes what the business fears. An attack surface describes what the business shows. Until the two are linked, the register is a list of consequences with no way in, and nobody can say which of your ten scenarios is closest to happening.

A register read from inside, an attack that starts outside

Most registers are written in a workshop, around a table, from what the team knows about its own systems. That is necessary for consequence: only finance and operations know what ten days without invoicing cost. But for likelihood, the workshop has a blind spot. It judges how likely a scenario is from the internal inventory, while the attacker starts from what they can see from outside: services that answer, open admin interfaces, advertised versions, credentials in circulation.

Public methods make the same distinction. NIST's SP 800-30 guide to risk assessment breaks likelihood into two parts: the likelihood that a threat event is initiated, and the likelihood that it results in an adverse impact once initiated. Exposure weighs directly on the first. ISO/IEC 27005, for its part, describes an event-based approach, which starts from risk sources and their consequences, and an asset-based approach, which goes down to each asset's vulnerabilities: linking a scenario to its entry points is where the two meet.

What this changes: a scenario's consequence is decided inside. Its likelihood, to a large extent, is read outside.

Linking each scenario to its entry points

Go back to your ten scenarios. For each one, ask a single question: through which internet-facing points could an attacker trigger it? Three examples, taken from our list in the first episode:

• Ransomware on the ERP. Typical entry points: the remote access appliance (VPN), the employee access portal, email, a provider's remote support tool. If one of them carries an exploited flaw or an open admin interface, the scenario moves closer.
• Compromise of executive email. Entry points: the email login portal, the level of multi-factor authentication protecting it, executive credentials found in leaks, lookalike domains imitating yours.
• Personal data breach. Entry points: the customer portal, web forms, shared cloud storage, web applications that query the customer database.

The same entry point often serves several scenarios. The VPN appliance feeds ransomware, intrusion through a provider and loss of critical access. That is a useful clue: entry points that appear in several scenarios are the ones whose exposure matters most, because a single flaw there pushes several lines of the register up at once.

What exposure changes, and what it doesn't

Exposure doesn't change the consequence. Ten days without invoicing cost the same whether the attacker came in through the VPN or through email. It changes likelihood, and it changes it fast. Four signals, observable from outside, are enough to move it:

1. An entry point carries an exploited flaw. A flaw in the KEV catalog on a reachable service is the strongest signal. Our Saturday article explains how to spot it.
2. An admin interface is exposed. The console of a device or application reachable from the internet shortens the path of any scenario that runs through it.
3. A device is end-of-life. It will get no more patches: every flaw found in it stays open.
4. Credentials are in circulation. Organization accounts found in leaks make possible the scenarios that start with a simple login.

These signals don't belong in a footnote in a corner of the register. They change the ranking: a scenario whose main entry point carries an exploited flaw moves ahead of a more severe scenario with no known way in. That is exactly the trade-off leadership must be able to make.

Who watches a scenario's exposure

Last Sunday we separated four roles: the person who accepts, the one who treats, the one who watches and the one who reports. Exposure is the job of the one who watches. For each scenario, they keep the list of entry points up to date and alert two people when one of the four signals appears: the one who treats, so they act, and the one who accepted the risk, because a risk accepted on the basis of low exposure is no longer the same risk when exposure rises.

This is the mechanism most registers lack. The acceptance was decided in March on a snapshot of exposure; in October a new entry point appeared, and nobody reopened the decision. A simple rule fixes it: any new signal on an entry point reopens the acceptance of the scenarios that depend on it.

This week's test: thirty minutes, three scenarios

Don't do all ten at once. Take the three scenarios with the heaviest consequence, and bring together the person who watches and someone who knows the infrastructure.

1. For each scenario, list the internet-facing entry points where it could start. Three to five per scenario are enough.
2. For each entry point, answer yes or no to the four signals: exploited flaw, exposed admin interface, end-of-life, credentials in circulation.
3. Count the entry points that appear in more than one scenario, and those with at least one yes.

Three results should get your attention. A scenario with no entry point identified: either it is badly written, or you don't know what you expose. One entry point shared by all three scenarios: that is your priority this week, ahead of everything else. Questions nobody can answer without running a scan: your register is judging likelihood blind.

What you should have next Sunday

One more page in your register: for your three main scenarios, the list of their entry points, the state of the four signals for each, and the name of the person who watches them. And a written rule: a new signal reopens the acceptance. You can extend the page to the other seven scenarios over the coming weeks.

Where FortaRisks fits

The four signals can be read from outside, continuously, and that is the job of Forta Exposure: every exposed service is identified with its version, then matched against exploited flaws. Forta Cockpit makes the link with the register: every finding becomes a ranked risk, before and after your controls, and a dated acceptance reopens on its own when it falls due. To see right now what an attacker sees of your organization, our free exposure report gives you in 48 hours, from outside and read-only, a score, ranked findings and a 30-day action plan.

Next Sunday: the threat, who is really targeting your sector. Exposure tells you where a scenario can start; the threat tells you who intends to trigger it. How to add it to the register without drowning it in intelligence.

Sources: NIST, SP 800-30 Rev. 1, Guide for Conducting Risk Assessments (September 2012) · ISO, ISO/IEC 27005:2022, guidance on managing information security risks · CISA, Known Exploited Vulnerabilities Catalog