DNS Shield · Platform

Inside the platform

What a DNS verdict is worth once it reaches a correlation engine.

DNS Shield is not a protective DNS tool bolted onto the platform. It is a native layer whose verdict makes every other layer more accurate.

Inside the platform

The SOC that receives the detection

The case for a DNS-layer control is not only that DNS abuse goes unnoticed. The security operations center that receives the detection already works under conditions that make one more alert source a liability. Four conditions build on each other, and the fourth is caused by the first three.

1
Siloed tooling. A firewall, an endpoint tool, a DNS filter, an identity provider, a mail gateway and an exposure product, each with its own schema and console, none aware of what the others saw.
The iCollector normalizes DNS telemetry into the shared context-aware model at collection time, so correlation is not retrofitted afterward by a connector.
2
Alert volume without meaning. A large share of alerts is never investigated. A million related alerts would be one incident.
Weighted multi-signal scoring and four confidence bands, with only the Confirmed band refusing by default, so the queue holds the verdicts that need judgment.
3
No cross-layer visibility. The ability to see one adversary action expressed at once in the network, identity, endpoint and exposure layers, and to treat those expressions as one object. Without it the organization holds all the evidence and possesses none of the picture.
ClearSkies TDIR as the single correlation hub, resolving those expressions into one incident with one timeline, one explainable risk score and one owner.
4
Correlation debt. The consequence of the first three. Manual correlation does not scale with telemetry growth, so every added sensor widens the shortfall rather than closing it.
The Autonomous Analyst absorbs first-line triage, and correlation collapses low-confidence signals into one incident.
Four conditions the SOC already works under; DNS Shield answers each at the point it appears.

DNS Shield addresses all four conditions at once rather than one of them. It adds the earliest signal in the attack chain, and it routes that signal into a correlation engine rather than into another console.

Why the DNS signal is worth correlating

  • TIMING

    The query precedes everything else

    The query precedes the connection, the handshake, the request and the payload. Every other layer begins its work later, which makes the DNS verdict the earliest fixed point available to correlate against.

  • POPULATION

    Coverage reaches every device

    Resolver coverage reaches devices no agent can be installed on. Cross-layer visibility is only as wide as its narrowest layer, and the DNS layer widens the one that previously constrained the whole picture.

  • BASELINE

    A record of normal resolution

    A continuous, high-volume record of normal resolution per tenant, which sharpens anomaly detection in every other layer rather than only in DNS.

  • ENFORCEMENT

    Prevention, not observation

    A verdict at resolution time lets the platform prevent rather than only observe, which is a different class of action from alerting on a connection that has already completed.

What the signal becomes once normalized

The value of a DNS event is not the alert but the entity behind it. The iCollector normalizes DNS telemetry into the shared context-aware model as it is collected, and the Centric-AI Fabric resolves it to the same entities every other layer uses: user, host, identity, domain, asset and session. Where the Agent forwarded the query, the device, process and signed-in user arrive with it. That is the join key that links a network event to an endpoint event and an identity event, with no analyst making the link by hand. Because every add-on normalizes into the same model, severity bands, confidence bands, technique tags and tenant scoping are the same across layers, so the SOC learns one model rather than six.

A DNS event, an endpoint event and an identity event resolve to the same entities in the Centric-AI Fabric — user, host, identity, domain, asset and session — and the same severity bands, confidence bands, technique tags and tenant scoping apply across layers.

Correlation is possible because the schema was shared before the event arrived, not because a connector translated it afterward.

Log forwarding moves records between systems; it does not move meaning, because the receiving system still has to work out what the records refer to. That is the difference between a native add-on and an integrated third-party product.

One direction, one destination

  • Findings out

    Refusals, threat classifications, and tunneling and beaconing detections are reported to the TDIR engine as they are produced, both as enrichment on existing detections and as detections in their own right.

  • One direction, and one destination

    The reporting relationship runs from DNS Shield to the TDIR engine and nowhere else. DNS Shield receives no intelligence back in exchange, and it exchanges no signal with any other add-on: ClearSkies DNS Shield and ClearSkies ASM each report to the engine independently and never to each other.

  • Where the work happens next

    Correlation, ATT&CK context, the cross-layer risk score and the response decision all take place inside the engine, the only component holding what every layer reported.

No add-on reads the findings of another.

The governing rule is the platform’s own: no component acts on the intelligence of another. Every signal goes to the TDIR engine, which ingests, normalizes and correlates it, so a DNS verdict is checked against what every other layer reported before an analyst sees it. ClearSkies ASM contributes the exposure picture; ClearSkies ITP the compromised accounts that turn a suspicious resolution into a credible account-takeover risk; ClearSkies ETMR the endpoint telemetry that confirms whether the process behind the lookup is itself suspect. No add-on reads the findings of another. The engine reads all of them, governed playbooks turn the assembled picture into a coordinated response, and the Autonomous Analyst pre-investigates each detection.

A worked cross-layer walkthrough

The chain below runs across four layers. It was chosen because the DNS verdict is the pivot rather than the alarm: the exposure finding that opens it is genuinely ambiguous, and it is the resolution behavior that settles what it means.

1
ASM. A supplier-hosted portal used daily by procurement has changed hosting provider and presents an unfamiliar certificate. Severity: informational, because suppliers re-platform routinely.
The supplier domain is registered as an entity and linked to the procurement group, so the exposure change becomes a watched object rather than a closed ticket.
2
DNS Shield. Lookups to that domain begin returning addresses on infrastructure that also serves a cluster of domains registered in the previous week. The evasive-infrastructure policy scores the pattern as Likely and resolution is refused.
The resolution behavior is joined to the same supplier entity, converting an ambiguous hosting change into evidence of hostile infrastructure, with a technique tag and a timestamp.
3
ITP, and the Agent. Procurement users are authenticating successfully against the new host, severity low because the accounts are legitimate. Each lookup arrived carrying the workstation, the browser process and the signed-in user, on and off the network alike.
The identities are joined to the same domain entity and to the refused resolutions, producing an ATT&CK-mapped supplier-compromise sequence, and the incident opens with an owner, a user group and a device list, so attribution is already complete.
Four findings, three consoles, no incident. None escalated on its own severity, and no analyst holding all three.
One incident, one explainable risk score, one owner. A governed playbook sinkholes the domain, notifies the supplier contact of record, and holds procurement in step-up authentication. An exposure change no one could act on becomes a confirmed supply-chain compromise with a contained blast radius.
ASM, DNS Shield and ITP or Agent each report independently to the TDIR engine, which resolves the fragments to one incident. No add-on communicates with another.

Bought from separate vendors, the same capabilities arrive as separate consoles, data models and licenses, correlated by a person who first has to work out that four findings all point at one supplier, and a link that was never made shows up nowhere as a gap. Native integration takes that risk away.

Standalone or native add-on

DNS Shield is deployed in one of two ways, and the choice is commercial rather than technical. The detection engine, the policies, the confidence bands and the Agent are the same in both. What differs is where the verdict goes once it is produced.

What differsStandaloneNative add-on
Infrastructure, policies and attributionResolver scopes plus every Agent device, on-network and off, under the same policies and four confidence bands, with device, process and user where the Agent is deployedIdentical
Where the verdict goesThe DNS Shield console, plus export to a third-party SIEM or SOARClearSkies TDIR, correlated with every other layer, with the attribution used as the join key
Triage and responsePerformed by the analyst or existing tooling, with inline refusal, sinkhole or redirectPre-investigated by the Autonomous Analyst, with Active Defense and governed playbooks driven by the correlated incident
ReportingDNS Shield reporting and exportOne risk register, one ATT&CK coverage layer, one audit trail

An organization that starts standalone and later licenses the platform is not onboarded again. Tenants, resolver scopes, policies, Agent enrollments and log history all carry over. The change is switching on the TDIR pipeline, not a migration project, so the deployment cost is paid once whichever way an organization starts.

See a verdict reach an incident

A working session on your own resolver scope, showing what a refusal looks like by the time it reaches an analyst.