Everything your institution's network team provides, in one pass.
Two things go onto your estate: a lightweight PROTEKT Agent on the endpoints you choose, and a passive PROTEKT Network Sensor at each internet edge. Everything else — detection, correlation, triage, response — runs in the PROTEKT SOC. Tell us who you are and this page becomes your provisioning brief.
Nothing is submitted from this page. Your entries personalise the brief — and set the sensor count and sizing tier — you send us at the end.
Nothing inbound. Nothing in the traffic path. Two telemetry sources, one SOC, your portal.telemetry in motionmirror copy
Transmits nothing onto the network
The sensor's capture interface has no IP address and never sends a packet. Agents speak outbound-only, over encrypted channels, to the PROTEKT SOC.
Cannot block or modify traffic
The sensor inspects a mirrored copy — it has no position in the traffic path. Response actions are decisions made with your team, never automatic network intervention.
Fails safe
If the sensor, an agent, or an uplink fails, the only consequence is a gap in visibility. Nothing PROTEKT deploys can cause a network or endpoint outage.
Plane one — Endpoint telemetry
A · The PROTEKT Agent
Your team deploys · we operate
A lightweight service installed on the endpoints your institution chooses to protect — labs, staff machines, servers. It watches the machine, not the person: telemetry goes outbound over an encrypted channel to the PROTEKT SOC, and the footprint is small enough to be invisible on shared lab hardware.
Item
Detail
Supported systems
Windows 10/11 and Windows Server 2016+ · macOS · major Linux distributionsMixed estates are normal — most campuses are Windows-majority with Linux servers and macOS pockets
Footprint
Background service — typically under 1% CPU and ~100 MB memoryNo reboot required to install. No user-visible interface on the endpoint.
Deployment
Your standard software distribution: Group Policy, Intune, SCCM/MECM, Jamf, or scripted install for Linux fleetsEnrollment credentials and packages are issued at onboarding — one package per device group
Connectivity
Outbound only, encrypted, to the PROTEKT SOCExact egress details ship with the enrollment package; nothing inbound to any endpoint
What the agent observes
System and security event logs
Critical file integrity changes
Process and service activity
Configuration and patch posture
Known-vulnerable software present on the device
What it never does
No keystroke capture
No screen recording
No reading or uploading of personal file contents
No browsing surveillance
No access for anyone outside the PROTEKT SOC and your named contacts
✓
Device groups for the first rollout identified
Start where telemetry earns the most: servers and staff machines first, labs second, residence networks by policy decision. A phased rollout beats a big bang.
✓
Deployment mechanism confirmed
Whichever tool already pushes software to those groups — GPO, Intune, SCCM, Jamf, or scripts. We supply packages in the format your tooling expects.
✓
Endpoint egress approved
Outbound encrypted connectivity from agent networks to the PROTEKT SOC (details issued with enrollment). If your egress is proxied or filtered by network segment, tell us which segments in the brief.
Plane two — Network telemetry
B · The sensor host
Your team provides
One virtual machine per internet breakout, on your existing virtualization platform. Sizing is driven by mirrored traffic volume, not device count — the table below adjusts to the edge capacity you selected at the top of the page, so what you see is your tier.
Resource
Specification
Sizing tier
StandardDefault — refine by selecting your internet edge at the top of the page
vCPU
8Multi-threaded inspection headroom for the tier's traffic band
Memory
32 GBFlow tables and inspection buffers scale with traffic volume
Disk
200 GBThin-provisioned; alert-only output is small — standard shared storage (NAS/SAN) is fine
Operating system
Ubuntu Server 24.04 LTSWe install onto an empty VM with console access, or your team deploys from a standard template
Interface 1 — management
Routed server network, static IPOutbound-only; exact egress rules in section D
Interface 2 — capture
Connected to the mirror destination (section C)No IP address assigned. Passive receive only.
✓
VM created to the specification above
Place it on a host with uncontended CPU and memory for the full allocation — inspection throughput degrades quietly under contention.
✓
Capture port group configured for mirrored traffic
The capture port group must have Promiscuous mode: Accept and Forged transmits: Accept — without this, the virtual switch silently discards every mirrored frame and the sensor sees nothing. Isolate it: a dedicated virtual switch (or isolated port group) used only by this sensor, no VLAN routing, no other VMs attached.
Preferred designDedicate one physical NIC on the host, patched directly to the mirror destination port, mapped to that isolated switch. Mirrored traffic stays away from every other workload.
✓
Offloads disabled on the capture path
Disable LRO/TSO on the capture path where configurable — coalesced frames reduce detection accuracy.
Plane two — Network telemetry
C · The traffic mirror
Your team provides
One SPAN / port-mirror session copying your internet-edge traffic to the sensor. The single most important choice: mirror the internal (LAN-side) interface of the perimeter firewall — before address translation — so every alert names a real internal host instead of a translated address. That is the difference between an actionable alert and a useless one.
Parameter
Requirement
Source
LAN-side interface of the perimeter firewall — the campus↔internet path, pre-translation
Direction
Both transmit and receive on the source portA one-directional mirror blinds half of every conversation
Destination
The port patched to the sensor's capture interface
VLAN tags
Preserve (802.1Q) where the platform supports itStripped tags are workable; preserved tags give per-segment attribution
Scope, phase one
Internet-edge path onlyInternal and inter-VLAN links are a phase-two conversation — one clean mirror beats three noisy ones
✓
Mirror session configured — LAN-side source, both directions
✓
Destination port speed matches or exceeds the mirrored link
If the source link is 10 Gbps, the destination port must be 10 Gbps. A 1 Gbps destination on a 10 Gbps source produces significant, predictable packet loss — the mirror drops silently, and detection quality degrades with it.
✓
Mirror session ownership agreed
The mirror lives on your equipment, so its health is monitored on your side: if a switch reboot or configuration change disrupts it, your team restores it and notifies us; we validate the feed on restoration — and we alert your contacts whenever telemetry stops arriving. Shared responsibility, stated up front.
Do I need more than one sensor?One sensor per traffic chokepoint — not per subnet or VLAN. The edge mirror above already carries every segment's traffic to and from the internet, so one sensor covers the whole campus's north-south path no matter how many VLANs it's carved into. Movement between internal segments is watched from the endpoint side by the PROTEKT Agents, and network-level internal mirrors are a phase-two addition to the same sensor, not new ones. Additional sensors are needed only for additional internet breakouts or separate campuses — which is why we ask for that count at the top of this page.
Not sure your network can mirror?Most modern campus switches and firewalls support port mirroring (SPAN). If yours doesn't — or you're not certain — don't stop here: alternative deployment patterns exist. Email hello@protektor.cloud before provisioning and we'll design around it.
D · Network access
Your team provides
Everything PROTEKT deploys speaks outbound only. Nothing inbound from the internet is required — the sensor and every agent originate their own encrypted connections to the PROTEKT SOC.
From
Protocol / Port
Destination
Purpose
Sensor VM
UDP 51820 outbound
PROTEKT SOC endpoint address provided at onboarding
Encrypted telemetry tunnel
Sensor VM
TCP 443 / 80 outbound
OS and detection-content repositories
System and detection rule updates
Sensor VM
UDP 123 outbound
Your NTP source, or a public pool
Time synchronization — accurate timestamps are what make correlation and investigation possible. If your NTP source is internal, ensure this VM is permitted to reach it.
Agent networks
Encrypted, outbound
PROTEKT SOC details issued with the enrollment package
Endpoint telemetry
✓
Egress rules above approved and in place
✓
Install access arranged
Console or SSH access to the sensor VM for our initial setup, by whichever mechanism your policy prefers: your jump host, a temporary VPN account, or a supervised session.
E · Six answers
Your team answers
Answer these right here — they flow straight into your brief below. Each question says why we ask and where the answer usually lives, and every card has a note field if anything needs explaining. Question six is the one that most often moves a go-live date.
01Internet link capacity and typical peak utilizationOPEN
Confirms the sensor sizing — if sustained traffic exceeds 10 Gbps, we adjust before install, not after.
Where to find it: your ISP agreement, or the throughput graph on your edge firewall / router.
Edge capacity
Typical peak utilization
Add a note
02Make and model of the device providing the mirrorOPEN
Where to find it: your network diagram or asset register — the switch or firewall the mirror will come from.
Add a note
03Is a virtualization host with a free physical NIC within patching distance of that device?OPEN
The preferred design patches the mirror straight into a dedicated NIC on the host.
Who to ask: your virtualization / data-centre team — a host in the same rack or row with an unused NIC.
Add a note
04Does the network support remote mirroring (RSPAN / ERSPAN) to where a host lives?OPEN
With no adjacent host, remote mirroring carries the copy across the network instead — workable, with a slightly different configuration on both sides.
Who to ask: your network team — RSPAN/ERSPAN capability on the path between the mirror device and the host.
Add a note
05Primary and secondary operational contactsOPEN
Who receives alert notifications, and who we call when the sensor, an agent fleet, or a telemetry feed needs attention.
Add a note
06Does the mirror configuration require change-window approval?OPEN
Approval lead time, not technical work, is what usually threatens the date — if a change-advisory cycle is involved, lodge the request the week provisioning begins.
Who to ask: your change management process — does a SPAN / mirror change need approval, and what is the usual lead time.
Usual lead time
Add a note
✓
All six answers complete
This ticks itself as you answer above — 0 of 6 so far.
F · What happens, and when
Typical: five working days
From provisioning to live telemetry. Once the host, mirror, and first device groups exist, everything inside them is ours for the duration of the engagement: install, tuning, detection-content updates, software lifecycle, and 24/7 operation from the PROTEKT SOC.
Day 0
Brief received; change request lodged if required
Your team
Day 1–3
VM + mirror provisioned; first agent groups staged
Validation is defined, not vague: a benign test detection is triggered on the network path and on an enrolled endpoint, both alerts are confirmed visible in your institution's PROTEKT portal with correct host attribution and accurate timestamps, and a written sign-off note records it. That note is the line between "provisioned" and "protecting."
For validation day, have ready: one enrolled endpoint to trigger the benign test, access to your PROTEKT portal during the session, and your primary contact available for a 30-minute call.
The last step
Your deployment brief
Generated from this page
This is what the deployment looks like from your institution's side — built from your entries and your checklist. Send it to us before provisioning and we come back with the enrollment package, the SOC endpoint details, and a named engineer.
Deployment brief — your institution
Endpoints in scope
—
Internet edge
—
Network sensors
1
Sensor tier
Standard
Provisioning items
0 of 0 complete
Primary contact
— to be confirmed
Derived: select your internet edge and breakout count at the top of the page.