ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24×7 managed detection and response across endpoint, network, cloud, identity, and log sources
Eyes-on-glass SOC and continuous threat hunting
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Get ultimate assurance that your environment is free from threat actors
Quickly recover from cyber attacks and breaches
24×7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Cloud-based SIEM platform providing visibility across all your data sources
Manage your external footprint, publicly available data, and Dark Web leaks
AI triage, investigation and response on the tools you already run
Fully featured distrubuted NDR for on-premises and public cloud environments
Deploy honeypots and honeytokens and stay ahead of threat actors
Every alert investigated, with a verdict and the evidence behind it
Integrated endpoint agent providing deep visibility, response and forensics
Log management and threat detection across any of your log sources
A SecOps platform purpose-built for industrial and OT environments
ThreatDefence puts security and compliance at the heart of our service, keeping your data protected at all times.
See how we keep your data secure.
Guides, case studies, and advisories in one place
Read what our customers say about us
Solution briefs and datasheets
Technical support and knowledge base
What to check in your Microsoft 365 tenant
Remote code execution flaws that need patching now
Essential Eight monitoring, reporting, and evidence for ongoing compliance
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to Incident Response and Digital Forensics
Read how cyber range helps to train cyber defenders
How AI agents investigate alerts and run security operations
How AI SOC platforms work, from integrations to autonomy
Free ebook: a practical guide to adopting an AI SOC platform
How brand impersonation works and how to detect and stop it
How lookalike domain attacks work and how to take them down
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Where SOAR playbooks fit, where AI agents take over, and how the two work together.
AI SOC hyperautomation transforms cybersecurity ops by autonomously detecting, analyzing, and remediating threats.
Honored to Support the Launch of the University of Technology Sydney Cybersecurity Precinct!
ThreatDefence Cyber had the privilege of meeting with Honeywell Dubai’s Digital City leadership to explore synergies in OT/SCADA and…
Read More
Equinox to support companies with ready to use, end-to-end SecOps infrastructure, including a full stack platform able to capture and…
ThreatDefence had an amazing time at AISA CyberCon 2024, connecting with industry leaders and advancing cyber security conversations.
OT network detection and response monitors communications between industrial systems to identify suspicious activity and support investigation. Passive sensors observe traffic from controllers, engineering workstations, and supervisory systems, helping security teams understand what is connected and what is changing.This guide explains how OT NDR works, which signals matter, and how to deploy and operate it around the needs of the plant.
Operational technology controls physical processes. It operates pumps, turbines, production lines, valves, and power distribution. A security incident can affect equipment, production, the environment, and people.
Security controls must account for those consequences. NIST’s OT security guidance explicitly addresses the performance, reliability, and safety requirements that distinguish these environments.
Many industrial devices have long operating lives, limited computing resources, and tightly controlled maintenance windows. Installing endpoint software may be unsupported, and active discovery or testing needs careful assessment.
Network monitoring provides another way to build visibility. A passive sensor analyzes copied traffic without sending discovery requests to the equipment it observes.
That visibility still needs operational context. A command that is expected during maintenance may require immediate investigation during production.
OT NDR combines traffic collection, industrial protocol analysis, asset context, and investigation.
Sensors receive copies of communications from switch mirror ports or network TAPs. Placement determines which systems and connections are visible.
Supported protocol analysis identifies the meaning of visible communications, such as a request to read data, write a value, or perform an engineering operation.
The system records communication relationships, services, and activity patterns. Approved engineering hosts, operating modes, and maintenance windows add context.
New connections, unexpected commands, and unusual access become findings for assessment. Analysts examine the network evidence alongside engineering records, access logs, and information from other security tools.
Security and operations teams decide what action is appropriate. Containment follows agreed procedures that account for the process and its dependencies.
Controllers, HMIs, engineering workstations, and supervisory systems.
Mirror ports or TAPs copy the traffic. Nothing is sent to the equipment.
Supported industrial protocols decoded into reads, writes, and engineering operations.
Findings examined with engineering records, access logs, and other security tools.
Action agreed with the site team, around the process and its dependencies.
Industrial visibility requires more than identifying an IP address and port. An OT-aware solution connects communication details with the equipment and process involved.
Relevant protocols may include Modbus/TCP, DNP3, OPC UA, EtherNet/IP, and S7comm. The useful question is which operations the product can interpret in the traffic your site actually uses.
Protocol support does not guarantee visibility into every command. Encryption, proprietary extensions, device versions, and capture quality can limit what is available.
Traffic can reveal device identities, services, roles, and relationships. Some protocols also expose vendor, model, or firmware information.
Discovery should distinguish observed facts from inferred classifications. Quiet devices, serial-only equipment, and systems outside monitored segments may need other inventory sources.
Asset criticality, approved engineering tools, production schedules, and change records help determine whether an event is expected.
Findings should show where activity occurred and which boundaries it crossed. Access from a corporate workstation to a controller has a different significance from routine communication within an approved control cell.
The Purdue model provides a familiar way to discuss industrial systems, from enterprise services down to the physical process. It can help organize monitoring coverage, although actual site architecture should determine placement and policy.
Asset placement varies between architectures. The model is a planning aid rather than a requirement for every connection to pass through every level.
Likewise, a network connection that appears to skip a level is not automatically malicious. Compare it with the site’s approved communication design.
Industrial threat detection becomes more useful when findings explain what changed and why it matters.
A finding should support an investigation rather than declare an operational outcome it cannot verify. Capturing a command request does not establish that the device accepted it or that the physical process changed.
Industrial asset records can become incomplete as sites expand, equipment is replaced, and contractors introduce temporary connections.
Passive OT asset discovery helps maintain a picture of communicating systems. It can show addresses, observed services, available device details, and relationships between assets.
Validate that picture with engineers and existing records. Useful context includes:
This also improves vulnerability assessment. A product or firmware match needs validation before a vulnerability is treated as confirmed.
Prioritization should consider exposure, exploitability, operational consequence, and available safeguards. Where patching must wait, agreed compensating controls can reduce risk until the change is possible.
Industrial incidents can involve direct manipulation of control systems or disruption through surrounding business infrastructure.
These examples do not establish that one monitoring product would have prevented the incidents. They show why industrial security needs evidence across access paths, engineering systems, and operational dependencies.
An OT investigation should answer both a security question and an operational question: was the activity authorized, and what could it affect?
Identify the source, destination, asset roles, and relevant zone boundaries. Confirm ownership and criticality with site records.
Review available commands, responses, timing, and related connections. Document which details were observed and which remain unavailable.
Compare the event with maintenance plans, vendor access, engineering work, and commissioning activity. An approved account alone does not establish an approved action.
Examine the remote-access gateway, jump host, engineering workstation, and relevant identity records. Look for activity that preceded or followed the industrial connection.
Ask the site team to verify controller status, process conditions, alarms, and engineering records. Network evidence contributes to that assessment without replacing it.
AI agents can help gather records, correlate activity, and prepare findings. Access to sensitive OT evidence and tools should remain explicitly scoped, with operational decisions retained by authorized people.
Containment needs to preserve a safe operational state. Even disconnecting an engineering workstation or blocking a boundary connection can affect supervision, support, or production.
Agree response procedures before an incident. They should identify:
Potential actions include restricting a compromised corporate host, terminating an unauthorized vendor session, or disabling an affected account. Each requires assessment against the site’s dependencies.
Controller changes, setpoint changes, firmware updates, and other actions affecting plant safety or availability require operational approval.
This approach reflects the joint OT cybersecurity principles led by ASD’s ACSC, which place safety first.
Passive collection avoids placing the sensor in the control traffic path. It still requires sound engineering, approved changes, and validation.
Map critical assets, zones, remote-access routes, and communication paths. Select monitoring points that address the highest-priority risks.
Use suitable mirror ports or TAPs and confirm what they supply. Check capacity and whether both directions of relevant conversations are visible.
Control management access and the path used to send evidence to the platform. Passive capture does not automatically create a one-way security boundary.
Where hardware-enforced unidirectional transfer is required, design and validate it specifically.
Confirm that the installation and switch configuration do not affect required communications. Test collection health and document gaps.
Start with agreed boundaries and critical segments, then extend coverage using the results. Include different operating modes and planned maintenance in the validation.
Joint secure-connectivity guidance recommends monitored, controlled OT access and an isolation plan established during system design.
Frameworks help organize monitoring requirements and assess what remains uncovered.
The series addresses industrial automation and control system security. Part 3-2 includes partitioning a system into zones and conduits and assessing their risks.
Communication maps and monitoring evidence can support that work, alongside the other controls and processes required for the environment.
NIST provides OT security guidance covering system characteristics, risks, and security measures. It helps teams plan controls around operational performance, reliability, and safety.
ATT&CK for ICS describes adversary tactics and techniques, including remote services, program changes, operating-mode changes, and actions affecting control or safety functions.
Use it to map detection hypotheses to available evidence and identify techniques that need additional visibility.
Monitoring records can support assurance and audit activities. Their value comes from showing coverage, investigated findings, decisions, and follow-up actions.
Evaluate the solution against your actual equipment and operating procedures.
Protocol depth: Which protocol versions and operations can it interpret? Ask for examples using representative traffic.
Asset identification: Which details are observed directly, which are inferred, and how are uncertain classifications handled?
Coverage: Can it monitor relevant boundaries, distributed sites, remote access, and required industrial segments?
Investigation: Does each finding include supporting records, operational context, and visible limitations?
Integration: Can findings connect with engineering records, identity logs, endpoint data, and existing SOC tools?
Response: Who makes decisions, and how are plant-affecting actions prevented from running without approval?
Evidence retention: Which metadata and packets are retained, for how long, and who can access or export them?
Operational support: Who monitors sensor health and investigates urgent findings outside business hours?
A useful trial includes routine production, approved maintenance, and agreed test scenarios. Review the quality of the evidence and its usefulness to both engineers and analysts.
ThreatDefence uses passive sensors to monitor industrial communications, identify observed assets, and investigate changes across IT and OT environments.
Network findings feed into the ThreatDefence AI SOC platform alongside endpoint, identity, and other connected evidence. AI agents gather context and prepare assessments, while our 24x7 SOC works with your team to investigate findings and coordinate response.
Cases keep network records, available packet captures, timelines, decisions, and follow-up actions together. Capture and retention are configured to your requirements, and actions affecting the plant remain subject to operational approval.
Explore ThreatDefence NDR
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
OT NDR is network detection and response designed for operational technology. It analyzes industrial communications, builds context about observed assets, and identifies activity that may threaten control systems or their supporting infrastructure.
OT monitoring must account for physical processes, equipment constraints, and operational dependencies. A security action that is acceptable on a business workstation may interrupt control or supervision in an industrial environment.
Passive discovery analyzes copied traffic without sending discovery queries to controllers. Confirm the product’s configuration and any additional features separately, because a platform may also support active collection methods.
No. Discovery depends on communication being visible to the sensor. Silent devices, isolated segments, and serial or fieldbus systems may require additional inventory sources or suitable integrations.
Sometimes. Some protocols expose identifying details, while others do not. Record whether a version was observed, inferred, or supplied from another source, and validate it before relying on a vulnerability match.
It can analyze observable connection information, but encryption may hide commands and application content. Additional endpoint, application, or engineering records may be needed to explain the activity.
No. It provides a useful reference for discussing industrial architecture. Placement should follow the site’s actual zones, critical systems, communication paths, and risks.
It can show an observed request and available response. Confirming the physical outcome may require controller records, process telemetry, alarms, and assessment by the operations team.
AI can assist with evidence gathering and investigation. Actions affecting controllers, setpoints, firmware, plant availability, or safety require explicit operational approval. Response authority should be defined and enforced by the platform.
Yes, with appropriate industrial expertise, access controls, and operating procedures. A shared platform helps connect activity across environments, while the site team retains authority over plant-affecting decisions.
What Is Network Detection and Response?
Lateral Movement Detection
AI SOC Platform Guide