Shield brings prevention-first network security to critical infrastructure environments. Shield blocks malicious traffic at the network layer using the Global Threat Engine and 8.5 billion IP and DNS combinations refined since 2001.
| What it does | Blocks malicious network traffic at the network layer using reputation-based threat intelligence. |
|---|---|
| Who it's for | Security teams needing prevention-first network defense. |
| How it deploys | Shield's five products cover cloud, Shield OnPremise, endpoint, monitoring, and management. |
| What you get | Prevention of known-bad connections with full evidence of what was blocked. |
Public sector and critical infrastructure buyers ask the operational questions first. Will it cause downtime? What does my team have to do? What does it block, and how do I know? This page answers those questions in order, with the kind of specificity your IT and OT teams need to evaluate.
Shield does not force you to turn on blocking before you are ready. Most public sector and critical infrastructure deployments start in observe-only mode and graduate to protect mode on a timeline the customer sets.
Shield runs in observe-only mode and logs every connection that would have been blocked, without blocking anything. Your team sees the traffic patterns, the attempted recon, and the outbound connections to known-bad destinations, with full visibility and zero impact to operations.
Available on Shield Stratus and Shield OnPremise.
Shield blocks known-bad traffic at the network edge. Outbound command-and-control connections are stopped before encryption begins. Inbound recon is blocked at the perimeter. The event log shows exactly what was blocked, when, and why.
Shield Sentinel is a passive carrier-grade monitoring platform. It does not block traffic, does not use threat intelligence, and does not integrate with Shield Command Hub. Sentinel observes and logs network traffic at scale, for organizations that want visibility without enforcement.
Most public sector deployments complete this sequence inside one calendar week. The sequence below is the typical path. Your environment may vary.
Your team and ours walk through the network topology, identify the segments to cover, and confirm the deployment mode (Stratus for cloud, Shield OnPremise for on-network, Sentinel for passive monitoring, Endpoint for reputation-based filtering on Windows and Android).
For Shield OnPremise: typically inline at the perimeter or between network zones, with a span-port option for pure observation. For Stratus: integrated with AWS Gateway Load Balancer in your VPC. For Endpoint: deployed via your existing endpoint management.
Shield is enabled in observe-only mode. Your team sees the event log immediately. Outbound connections to known-bad destinations and inbound recon attempts that would have been blocked are now visible.
Your team reviews the observed traffic with our deployment engineer. We document together what is being blocked and confirm there are no surprises. The duration of this phase is set by you, not by us.
When your team is ready, Shield is switched to protect mode. From that point forward, known-bad traffic is blocked at the network edge. The event log continues, now showing actual blocks instead of would-have-blocked entries.
Public sector and critical infrastructure teams ask precisely what they will be on the hook for. The honest answer is: not much, and we share the work.
Shield does not guess. Every block is tied to a specific entry in the Global Threat Engine, the proprietary 8.5 billion IP and DNS combination database that has been built continuously since 2001. The event log shows the reason for each block.
When a device on your network attempts to reach a destination known to be a command-and-control endpoint, Shield blocks the connection before it completes. Blocking outbound C2 can interrupt ransomware coordination, staging, key exchange, or follow-on command activity, depending on the attack pattern. The earlier the connection is severed, the less the attacker can do.
Before a targeted attack, operators map your network. Shield blocks the inbound recon traffic from known-bad sources before it can fingerprint your perimeter. The attacker never gets the map they need to plan.
If an attacker has already established access and is attempting to exfiltrate data to a known-bad destination, Shield blocks the outbound connection. Data does not leave the network through a destination Shield recognizes.
Behavior-based detection looks at what traffic is doing and decides whether it looks suspicious. That approach generates false positives, requires tuning, and needs a baseline of "normal" before it works. Reputation-based blocking looks at the destination address and decides whether it is on the known-bad list. The destination is either on the list or it is not. This significantly reduces tuning overhead and the volume of alerts that require triage.
We are explicit about boundaries because procurement and audit conversations go better when the answers are precise.
Shield reduces the volume of incidents you have to respond to. When you do have an incident, the Shield event log is one of the first artifacts your incident response team will pull.
The Shield event log gives your IR team a chronological record of blocked connections. That timeline often reveals when the attacker first attempted to communicate with a C2 destination, which is one of the most useful early indicators in an investigation.
Shield logs blocked events including DNS, TCP, and UDP. Permitted destinations, bandwidth by connection, and new internal hostnames, IPs, and MACs are also available. This is the working set of data your IR team uses for scoping and containment questions.
If you have an IR retainer with an MSSP or DFIR firm, Shield event logs and Syslog feeds are the artifacts they will request. We can coordinate directly with your IR team during an incident to support the investigation.
The fastest way to know whether Shield fits your environment is to run it in observe-only mode and look at the event log together. Most POVs complete in under two weeks.
RECOMMENDED NEXT STEP