DURG · Cybersecurity
Understand your security state. Prove it with evidence.
DURG connects security information that would otherwise remain fragmented across assets, observations, vulnerabilities, security checks, alerts, investigations, governance and remediation.
- Product
- DURG
- Company
- Radanor
- Area
- Cybersecurity
- Current version
- v0.9.0
DURG builds an evidence-backed model of the security state of an environment, and uses observation, context, governance, remediation and verification to keep improving that state.
The problem
Security information rarely arrives connected.
Most organizations already hold what they need to reason about their security state. The difficulty is that it is spread across systems and teams that were never designed to work together — an asset inventory in one place, vulnerability results in another, endpoint telemetry elsewhere, investigations in a ticket queue, governance obligations in a document, and remediation work in a change process.
When those threads are not connected, the picture has to be reassembled by hand. It is slow, hard to reproduce, and the parts that were never observed tend to be treated as if they were fine.
DURG exists to hold that picture together — not by replacing the systems that produce the information, but by modelling the security state those systems describe.
- Assets
- What exists, and in what state
- Observations
- What was seen, and when
- Vulnerabilities
- Known weaknesses on those assets
- Security checks
- Whether a control holds, and on what evidence
- Alerts
- Activity that warrants attention
- Investigations
- What was examined, and by whom
- Governance
- Which obligation a check belongs to
- Remediation
- What was changed, and whether it held
DURG is not positioned against the tools that produce this information. It is the layer that connects them.
Security State Model
One model of the environment.
At the centre of DURG is a Security State Model: a structured representation of an environment that relates assets, evidence and alerts to the governance, remediation and verification that follow from them.
DURG
Security State Model
Assets
Exposure
Evidence
Checks
Alerts
Incidents
- Governance
- Remediation
- Verification
- Assurance
Observed facts at the base.
The model is built from what was observed, and when — rather than from assumptions about what is probably true. Where nothing has been observed, the model says so.
Action at the top.
Governance, remediation, verification and assurance operate on the model rather than alongside it, which is why verification can close the loop.
The lifecycle
A continuous security-state lifecycle.
The model is maintained by a repeating cycle. Each stage produces the input for the next, and verification feeds back into observation — so the security position of an environment can be described and improved rather than merely asserted.
Observe
Collect state from assets, services, endpoints and security telemetry.
Evidence
Record what was observed, when it was observed, and how it maps to a security check.
Understand
Assemble individual observations into a model of the environment and its exposure.
Prioritise
Rank what matters using reachability, context and the weight of the governing control.
Remediate
Drive the work to close the gap, with an owner and a record of what was done.
Verify
Re-observe the environment to confirm the change actually holds.
Assure
Maintain a standing, evidence-backed view of the security state.
Returns to 01 · Observe
Capabilities
What DURG does.
DURG’s capabilities are organised the way the security state itself is: what exists, what is exposed, what is evidenced, what is investigated, what is governed, what is remediated, and what is assured.
01 / 08
Visibility
A current, structured record of what actually exists in an environment.
DURG maintains a model of the assets in an environment and the state of each one. Records are built from observations rather than from a one-off import, so the model reflects what was actually seen, and when.
Visibility is the foundation the rest of the platform reasons over. If the record of what exists is stale or incomplete, every conclusion drawn from it is unreliable.
- Asset identity
- A stable identity for each asset, with the attributes needed to tell it apart from similar systems.
- Operating systems
- Operating system and version, as observed on the asset.
- Installed software
- Installed packages and applications, with versions.
- Running services
- Services that are actually running — not only software that is installed.
- Listening ports
- Ports the system is listening on, and the service that owns each one.
- Observation state
- When each asset was last observed, and whether that observation is still current.
02 / 08
Exposure
What is exposed, judged in context rather than in isolation.
Exposure in DURG is not a single number. It is the product of what is present on a system, whether that system can actually be reached, and what surrounds it.
- Vulnerabilities
- Known weaknesses associated with an asset, its operating system and its installed software.
- Running services
- Services that are active, as distinct from software that is merely present.
- Listening ports
- Open listeners on the asset, with the service behind each one.
- Reachability
- Whether a service can be reached from where it matters, based on observed network position.
- Contextual exposure
- Exposure assessed alongside asset role, reachability and the checks that apply to that asset.
Vulnerable does not automatically mean externally exposed.
A vulnerable package on a host that nothing can reach is a different problem from the same package on an internet-facing service. DURG keeps those two facts separate — the presence of a weakness, and the reachability of the thing that carries it — so that prioritisation reflects the environment rather than the raw count.
03 / 08
Evidence & Security Checks
Checks resolved by evidence, with unknown kept strictly separate from pass.
A security check in DURG is a question with a defined, observable answer. Each check resolves to one of three states, and the state is derived from evidence rather than from an operator’s judgement.
- PASSEvidence was collected and the expected condition was met.
- FAILEvidence was collected and the expected condition was not met.
- UNKNOWNNo evidence was collected, or the evidence collected is not sufficient to decide.
Evidence freshness
Evidence ages. DURG records how current the evidence behind a check is, so a control verified some time ago is never presented as if it had been verified now.
- CURRENTThe evidence was collected recently enough to support the check’s result.
- STALEThe evidence exists but has aged beyond the point where it still supports the result.
- UNKNOWNNo usable evidence is held for the check, so its state cannot be established.
Missing evidence is never recorded as a pass.
A check with no evidence resolves to UNKNOWN. It is not promoted to PASS and it is not hidden. An unverified control is an open question, and treating it as satisfied is how assurance quietly stops being true.
04 / 08
Detection & Investigation
Security activity that stays attached to the asset and to its history.
Detected activity is only useful when it can be investigated together with the context that produced it. DURG keeps an investigation attached to the asset, its exposure and its check results rather than detaching it into a separate queue.
- Security events
- Activity collected from endpoint and security telemetry.
- Alerts
- Events that meet defined conditions and warrant attention.
- Incident investigations
- Structured investigations that hold findings, decisions and outcomes in one place.
- Assignment
- Investigations have an explicit owner, so responsibility is never implied.
- Timelines
- A chronological record of what happened, and when it was examined.
- Investigation context
- The asset, exposure, checks and evidence relating to an investigation, held alongside it.
- Historical alert association
- Earlier alerts for the same asset or condition, so that a repeat is recognisable as a repeat.
05 / 08
Advanced Hunting
Bounded, declarative hunting rather than unrestricted database access.
Analysts need to ask questions that no pre-built report anticipated. DURG supports that with declarative hunting over the security state model: a defined, bounded way to describe what you are looking for.
Hunting runs against the model DURG maintains. Queries are expressed declaratively instead of as arbitrary database access, so they stay scoped to defined entities and fields, and a saved hunt can be run again — the same question, asked the same way, against a model that shows what has changed.
- Declarative queries
- Describe the condition you are looking for, not the shape of a database.
- Bounded scope
- Queries run against defined entities and fields rather than unrestricted access.
- Reproducible results
- Saved hunts can be re-run as an environment changes, so answers stay comparable.
Why not raw database access?
Exposing an unrestricted query interface over security data makes results difficult to bound, review or reproduce. A declarative hunting surface keeps the questions explicit and the answers repeatable.
06 / 08
Governance
Frameworks, controls and checks connected in a chain you can follow.
In DURG, governance is a traceable chain rather than a separate reporting exercise. A framework contains controls; a control is mapped to the checks that demonstrate it; a check produces evidence.
Because the chain is explicit, the question “why is this control considered satisfied?” has an answer that ends in evidence rather than in an assessment note.
- Framework
- The set of obligations an organization has chosen to be measured against.
- Control
- A statement from that framework which the organization is expected to meet.
- Check mapping
- The link between a control and the checks that can demonstrate it.
- Security check
- The observable question whose result contributes evidence to the control.
- Evidence
- The recorded observation that supports the check’s result.
- Framework
- Control
- Check mapping
- Security check
- Evidence
A control is not satisfied because someone said so.
A control is satisfied when its mapped checks carry current, passing evidence. When that evidence goes stale or disappears, the control returns to an unresolved state rather than keeping its previous result.
07 / 08
Remediation & Verification
Work is tracked to completion — and completion is verified, not assumed.
Remediation in DURG is a workflow with a record: what the problem was, what work was performed, by whom, and what the environment looked like afterwards.
The last step is the one that matters most. Changing a system and marking the item closed is not the same as confirming the condition no longer exists.
- Security problem
- The finding that needs to be addressed, together with its evidence.
- Remediation
- The work planned or performed to resolve it.
- Work performed
- A record of what was actually changed, and when.
- New observation
- The environment is observed again after the change.
- Verification
- The check is re-evaluated against the new observation, and the result is recorded.
- Security problem
- Remediation
- Work performed
- New observation
- Verification
Marked fixed is not the same as verified fixed.
A closure note is a statement of intent, not evidence. DURG treats verification as a separate step that produces its own observation, so the record shows what the environment confirmed rather than only what was reported.
08 / 08
Continuous Assurance
A standing view that keeps pace with the environment.
Assurance is the outcome of the lifecycle running continuously rather than once. As an environment changes — new assets, new services, patched systems, aged evidence — the model changes with it, and the assurance position is recomputed from evidence.
DURG is careful about what that means in practice. Continuous assurance is not a guarantee that an environment is secure. It is a maintainable, evidence-backed answer to the question “what do we actually know, and how do we know it?” — including the parts where the honest answer is that we do not know yet.
Telemetry and attribution
Built around Wazuh telemetry.
Wazuh provides important endpoint and security telemetry. DURG builds security-state, governance, investigation, exposure, remediation and assurance workflows around that telemetry.
Capabilities that come from Wazuh remain Wazuh capabilities, and DURG does not present them as its own. Attribution matters — both for operators who need to know where a signal came from, and for the integrity of the open-source ecosystem this work depends on.
Wazuh project websiteExternal link. Wazuh is an independent open-source project.
Where DURG fits
A security-state layer, not another point tool.
DURG is not an antivirus, an endpoint detection and response agent, a vulnerability scanner, a log platform or a compliance certificate. Those categories solve different problems, and many organizations already run products in several of them.
DURG works with the information those systems produce. It builds the model that connects them: what exists, what has been verified, what is exposed, what is being worked on, and what is genuinely assured.
- Alongside, not instead of
- DURG consumes telemetry and findings from the systems an organization already operates.
- Evidence as the unit of truth
- Conclusions are traceable to observations, including the observation that something was not observed.
- Verification built in
- Remediation is not complete until the environment confirms it.
Request a DURG demo
See how DURG models a security state end to end — from observation and evidence through governance, remediation and verification.