Quantifying Cyber Risk: The Art and Math of Attack Surface Scoring (Part 4)

 

We have come a long way. In Part 1 I showed the why, in Part 2 I turned that into a scoring method, and in Part 3 I explained how I normalize and model those scores. Now, this is the part I enjoy the most where how I take those scores and actually do something useful with them.

This is written from my point of view on how I prioritize, fix, transfer, and keep measuring so the work actually reduces risk and proves value.

Step 1: Decide What to Fix First

A high score doesn’t always mean full-scale panic. I combine four things when I pick my next move:

• Exposure (how visible/exposed it is)
• Criticality (what the business impact would be)
• Exploitability (ease of attack based on vuln data)
• Cost to fix (time, money, operational disruption)

I usually bake this into a quick prioritization matrix: score each axis, then sort by a combined priority index. That gives me a ranked list that’s defensible when I speak to ops or execs.

Step 2: Pick a Risk Treatment

Once prioritized, I choose one of four options:

• Mitigate by adding controls, patch, configure, reduce exposure. This is the usual path.
• Transfer by moving risk via insurance, vendor contracts, or outsourcing certain services.
• Accept by documenting low-likelihood/low-impact items and monitor them.
• Avoid by retiring or redesign risky systems that aren’t worth keeping.

The choice depends on ROI: sometimes spending RM50k to avoid an expected RM1.5M loss is an easy yes; other times, acceptance makes sense because the remediation cost outweighs the benefit.

A Practical Remediation Playbook (My Shortlist)

When an item reaches the top of my list, this is how I run it:

1. Triage - validate the finding, reproduce if needed, and confirm business owner.
2. Scope the fix - quick impact assessment: downtime required, rollback plan, testing window.
3. Estimate cost & time - get an ops estimate and any licensing costs.
4. Plan & schedule - coordinate maintenance windows, change approvals, and comms.
5. Implement - apply config changes, patches, or microsegmentation rules.
6. Verify - re-scan, review logs, and confirm the score has dropped.
7. Document & close - capture lessons learned and update runbooks.

I keep this tight and repeatable. It’s the difference between long To Do lists and real risk reduction.

Risk Transfer & Contracts

For things I can’t or shouldn’t fix, I look at transfer:

• Insurance: Understand the policy limits, exclusions, and what controls are required to qualify. Insurance can lower residual risk but read the fine print, it’s not magic.
• SLAs & contracts: Push stronger security clauses to vendors and require evidence (pen tests, SOC reports).
• Third-party managed services: For SMBs especially, it’s often cheaper to buy a managed stack that includes detection and response rather than building it from scratch.

Continuous Assurance (Keep It Moving)

Fixing something once isn’t enough. I set up an automation loop:

• Feed scan results, asset inventory, and SIEM alerts into the scoring engine.
• Recalculate scores on a schedule (I run daily or weekly depending on velocity).
• Alert when a score jumps above a threshold or when remediation regressions happen.
• Measure the delta after remediation by asking did our score drop? By how much? That’s the ROI metric I track.

This is how the program stays alive.

Measuring ROI & Proving Value

Executives don’t want technical talk; they want outcomes. I focus on two simple KPIs:

• Residual risk reduction — change in aggregate score (or expected annual loss) after remediation.
• Cost avoided — use FAIR/Monte Carlo results to show estimated loss avoided versus remediation spend.

Example pitch: “We spent RM120k on controls across five assets and reduced expected annual loss from RM1.4M to RM520k and that’s RM880k of exposure avoided.” Numbers like that move budgets.

Communication: Keep It Simple

I use a three-part format for leadership updates:

1. Top 3 risks this month - one-liners with impact numbers.
2. What we did - short bullets: patches applied, vendor changes, segmentation work.
3. What we need - budget asks or decision points.

For boards I convert expected loss into a simple chart (before vs after) and use plain language: no jargon, just business impact.

How I Run Post-Remediation Checks

After a fix, I don’t just trust the ticket to close. I:

• Re-scan the asset and verify the new score.
• Check related logs and telemetry for any suspicious activity during the change window.
• Confirm with the business owner that functionality is intact.

If the score didn’t move as expected, I treat it as a failed remediation and re-open triage.

Governance & Roles (Quick Notes)

To scale this, assign clear owners:

• Risk owner — business unit exec who owns impact decisions.
• Technical owner — ops/infra team responsible for fixes.
• Program owner — security lead who runs the scoring and governance.

Define thresholds for automated actions vs approval-required items. That keeps pace without chaos.

Wrapping Up (Make It Repeatable)

If there’s one thing I want you to take away: measurement without action is just data. The secret sauce is a tight loop: score, prioritize, act, verify, and report. Do that consistently and security stops feeling like a firefight and starts feeling like running a business.

And that’s the end of the series! Thanks for reading and I’ll see you in the next blog. :-)