The Visibility Problem in Defence Networks
A typical defence network spans multiple generations of equipment from multiple vendors. Cisco routers sit alongside Juniper switches. Legacy SCADA systems share infrastructure with modern IP networks. Encrypted communication endpoints coexist with unclassified administrative systems.
Each vendor provides its own management console. Each console has its own alert format, its own severity classification, and its own view of network health. The security operations centre (SOC) team responsible for defending this network must switch between a dozen different dashboards to understand what is happening.
This is not a monitoring strategy. It is a fragmentation problem.
During a security incident, when seconds matter, analysts waste critical time:
- Logging into different vendor consoles to check device status
- Manually correlating alerts from different systems that may be describing the same event
- Translating between different severity scales and alert formats
- Piecing together network topology from multiple incomplete views
What "Single Pane of Glass" Actually Means
"Single pane of glass" is an overused term in enterprise IT. Many products claim unified visibility while actually providing a dashboard that aggregates a few data sources and leaves gaps everywhere else.
True unified monitoring for defence networks means:
1. Every Device, Every Vendor
The monitoring platform must support every device on the network regardless of manufacturer, age, or protocol. This includes:
- Modern network equipment (switches, routers, firewalls) via SNMP, NetFlow, syslog
- Legacy systems that only support older protocols
- Endpoint devices (workstations, servers, IoT/OT devices)
- Wireless access points and controllers
- Encrypted communication endpoints
- Physical security systems (cameras, access control) if they are on the IP network
2. Normalised Data Format
Raw data from different vendors arrives in different formats. Cisco syslog messages look nothing like Juniper log messages, which look nothing like Windows Event Log entries. The monitoring platform must normalise all of this into a common data model so that:
- Alerts from different vendors can be correlated
- Search and analysis work consistently across all data sources
- Historical analysis does not require vendor-specific query languages
3. Real-Time Topology Awareness
The platform must maintain a live map of network topology:
- Which devices are connected to which
- What paths traffic takes through the network
- When new devices appear or existing devices disappear
- When connectivity between devices changes
Topology awareness transforms alert analysis. Instead of "Device X generated an alert," the analyst sees "Device X, which is three hops from the classified data centre and directly connected to the perimeter firewall, generated an alert."
4. Intelligent Alert Correlation
Modern networks generate thousands of events per second. Without intelligent correlation, the SOC team drowns in noise. The monitoring platform must:
- Group related alerts from different sources into unified incidents
- Suppress duplicate notifications for the same underlying event
- Escalate alerts based on the criticality of affected assets
- Provide context (what changed, what is affected, what is the blast radius)
Why Defence Networks Are Different
Defence network monitoring has requirements that commercial solutions rarely address:
In a defence SOC, the consequences of missing a critical alert are not measured in downtime or revenue loss. They are measured in compromised operations, endangered personnel, and strategic disadvantage.
Air-gap operation. The monitoring platform cannot depend on cloud services for threat intelligence, analytics, or storage. Everything must run locally.
Classification boundaries. Defence networks often span multiple classification levels. The monitoring platform must respect these boundaries while still providing useful cross-boundary visibility to authorised analysts.
Operational security. The monitoring system itself must not become a security liability. It must not expose network topology to unauthorised users, and it must not create new attack paths through its own infrastructure.
Reliability under stress. During an actual attack, network conditions degrade. The monitoring platform must continue operating even when significant portions of the network are under duress.
Building DRISHYA for This Reality
DRISHYA was designed from the ground up for defence network monitoring. It is not a commercial network management tool with a "government edition" label. Every design decision was made with defence operational requirements as the primary constraint.
Key architectural choices:
- Agentless monitoring where possible, to minimise the footprint on monitored devices
- Protocol flexibility to support everything from modern APIs to legacy SNMP v1
- Local processing of all analytics and correlation with no cloud dependency
- Role-based access control aligned with defence organisational structures
- Audit logging of every analyst action for compliance and accountability
- Redundant deployment so that monitoring survives the loss of individual components
The result is a platform where a single analyst can see every device, every alert, and every traffic flow on the network from one screen, and can drill down to any level of detail without switching tools.
The Operational Impact
When a SOC team moves from fragmented vendor dashboards to unified monitoring, the operational impact is immediate:
- Mean time to detect (MTTD) drops because correlated alerts surface threats faster
- Mean time to respond (MTTR) drops because analysts have full context without tool-switching
- False positive rate drops because correlation eliminates redundant alerts
- Analyst cognitive load drops because one interface replaces a dozen
For defence networks where the stakes are highest, unified monitoring is not a nice-to-have. It is an operational requirement.
DRISHYA is Tosh Defence's single-pane-of-glass network monitoring platform. Learn more about DRISHYA.