CLIENT: Kozjak Power Distribution DOOEL🇲🇰North Macedonia

Bedem - Vulnerability Management Across Corporate IT and Substation OT

Vulnerability Management for a North Macedonian Grid Operator

Designed and built a clickable vulnerability management platform for a Skopje electricity distribution operator: scanner findings merged into one list, ranked by real-world risk, triaged to owner teams with SLA dates, and OT fixes planned into maintenance outages - with substations assessed passively, never scanned.

Scope of Work
Product design, UI build and clickable demo
Industry
Cybersecurity / Vulnerability Management
EnergyEnterprise
Compliance & Certifications
IEC 62443CVSS v4.0CycloneDX and SPDXLaw on Personal Data Protection (North Macedonia)

Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.

Impact

5 Screens
Clickable end to end

Dashboard, findings list, finding detail, triage queue and patch windows. Each of the 26 demo findings opens its own detail page with evidence, remediation, exceptions and history.

9 Inputs
Behind every priority

CVSS, EPSS, CISA KEV, exposure, asset criticality, exploit maturity, OT safety impact, attack vector and compensating controls add up to a 0 to 100 risk score, banded P1 to P4 with 2 override rules.

Passive Only
OT assessed without probing

Substation and control-centre findings come from passive sensor traffic. Active scanning of an OT zone needs an approved exception tied to a patch window with an engineer on site.

26 Findings
Realistic demo data

22 IT and OT assets, 16 vulnerabilities, 10 remediation tickets, 9 patch windows, 6 scan sources, 8 IEC 62443 zones and 13 items in the triage queue.

The Problem

Kozjak's security team of four exported CSV files from three scanners into a spreadsheet of more than 60,000 rows, where one missing patch on one server appeared three times. Everything at CVSS 9.8 looked equally urgent, so an actively exploited flaw on an internet-facing VPN gateway sat for five weeks. Nobody trusted the list of substation devices, risk acceptances lived in emails with no end date, and answering the regulator's question on open critical vulnerabilities in control systems took two people a week.

Our Solution

Bedem pulls findings from network, agent, endpoint, container and code scanners and from passive OT sensors, merges duplicates, ranks each finding by real-world risk and routes it to an owner team with an SLA date. OT fixes are planned into the grid team's maintenance outages with vendor qualification and a pre-work checklist, and a finding closes only when a rescan or passive observation shows it is gone.

The Challenge: One Risk Picture for IT and the Grid

Kozjak runs offices, billing and a container platform alongside about 140 substations with RTUs and protection relays, and a SCADA and distribution management system in two control centres. The same vulnerability process has to work for both, even though the rules for fixing them are very different.

Severity Is Not Risk

A CVSS score measures how bad a flaw is, not how likely it is to be attacked. Bedem has to weigh it against the EPSS probability, membership of the CISA KEV catalogue, exposure and how critical the asset is, and store CVSS v4.0 and v3.1 side by side because many records still carry only the older score.

Substations Cannot Be Scanned

An earlier attempt to scan an RTU network with a standard IT scanner froze two older devices. OT assets have to be found and assessed from mirrored network traffic, where firmware versions are inferred and can be wrong, so every OT match carries a confidence level.

OT Fixes Wait for an Outage

Following IEC TR 62443-2-3, Kozjak installs only patches the vendor has qualified, and a relay or RTU can be updated only during a planned maintenance outage. A P1 in a substation needs a compensating control now and a fix in the next qualified window, not a 7-day deadline.

Exceptions Without an End

Risk acceptances were agreed by email with no expiry, so nobody knew which were still valid. Each one needs an approver at the level the policy sets, controls with evidence and a review date, and re-approval when a covered finding's priority rises.

Our Approach: From Scanner Exports to a Clickable Platform

01

Spec and Rules Research

Mapped 11 roles, from vulnerability analyst and OT engineer to outage planner, risk committee and vendor engineer, 38 screens across the staff app and a vendor portal, and the data model for assets, IEC 62443 zones and conduits, source records, deduplicated findings, tickets, patch windows, exceptions, SBOMs and versioned policies. Wrote down the rules the design follows: CVSS v4.0, EPSS, CISA KEV as a priority signal only, IEC 62443, no active scanning of OT by default and verification before closure.

02

Clickable Demo on a Production UI Kit

Built 5 key screens on a production dashboard kit: the dashboard with latest import per source, KPI cards, the ingest pipeline, risk by zone and needs-attention items; findings with status pills, filters and grouping; finding detail with the priority breakdown and deduplicated scanner evidence; the triage queue with merge candidates side by side; and the patch window calendar with vendor qualification and the pre-work checklist. All actions run on local state.

03

What a Production Build Adds

Imports from Tenable, Qualys or Rapid7, Microsoft Defender, Trivy, Semgrep and passive OT sensors such as Nozomi Networks, the NVD, EPSS, CISA KEV and CSAF advisory feeds, two-way Jira or ServiceNow tickets, the grid team's outage planning API and Entra ID sign-in. Plus an append-only audit log, the remaining screens for assets, exceptions, verification, SBOMs, reports and settings, the vendor portal, and a Macedonian interface.

Why It Works: Every Priority Shows Its Working

Priority You Can Check

Finding detail lists each input with its value and the points it adds under policy v14, so the risk score adds up on screen. The band and any override, such as KEV listed and internet-facing = P1, are shown with it, and the findings list carries the top reason on every priority chip.

One Finding, Many Scanners

Records from different scanners for the same asset, vulnerability and location merge into one finding with its sources listed. Near matches go to a merge candidates tab, where the two records sit side by side with the differing fields highlighted.

OT Rules Built In

OT findings show their passive evidence and a confidence of confirmed, probable or inferred, and low-confidence matches wait in triage for an engineer. Finding detail states that active scanning of the zone needs an approved exception.

Patches Planned Into Outages

OT outages come read-only from outage planning, with feeders, the on-site engineer and energy not supplied. Each window shows its tickets with vendor qualification status and a pre-work checklist, and a warning appears when a P1 has no window before its SLA date.

Related case studies

View all: Cybersecurity
Logo
Oceanlab

Enterprise Software Engineering - Human + AI

Languages

Locations

Global Headquarters

21 Merchant Road, 3rd Floor, Singapore 058267

Main corporate office and leadership operations

North America Office

548 Market Street, PMB 12345, San Francisco, CA 94104

Client operations and business development

India Office

402 Shivalik Shilp II, SG Highway, Ahmedabad 380015

Engineering and delivery center

© 2026 - Copyright. All Rights reserved Oceanlab