Security, for the reviewer

Credentials

• The operator's password is never stored. Anything Vantage does as you (an agent deploy, a Hyper-V change, a Windows Update install, an inventory read by delegation) takes your password for that action, holds it in memory, hands it to the child process over standard input, never as a command-line argument, and forgets it. The audit line records your user name and the words "credential not stored".
• Remote screens and shells: the server picks the target, Vantage cannot read the password. The browser RDP console (Hyper-V guests, Windows servers, XenServer guests) speaks RDP in the browser; Vantage opens the connection to an object it has on record, through a one-time ticket bound to you, and carries the bytes. Your password travels inside RDP's own sign-in (CredSSP), encrypted by the browser for the server, so Vantage carries it and cannot read it. SSH in the browser pins each host key on first use, refuses a changed one before any credential is sent, keeps a password you type for that sign-in nowhere, and is for administrators only. Remote Desktop can still be a downloaded .rdp file signed in with your own Windows session.
• The per-server agent secret is issued exactly once, at enrolment or redeploy, by that one endpoint, and never returned by any read. Agent reports are signed with it (HMAC over the UTF-8 bytes). A rotation keeps a grace window on the previous secret so a server mid-rotation is never locked out; a rotation is never made before the new path is proven.
• Stored credentials never come back out. Appliance accounts, the per-pool XenAPI credential, the MaxMind licence key, the mail server’s password or API key, the UniFi controller’s API key, the key of a reputation database you add by URL, the NetScaler callout token and the download proxy’s password are encrypted with a machine-local key on the server and are never returned by a read endpoint; a status says only that one is stored.
• NetScaler: read with one account, change with another. Monitoring over NITRO reads with a read-only account. Changes made over NITRO (the object editor, enforcement rules, packet captures, a failover) use a configuration account that exists only where NetScaler Configuration is licensed, and only for an explicit administrator action or a rule an administrator saved, never by collection. A separate account is defence in depth; where you have only one read-write account the same one may be used, by your choice, and the page says so. Automation workflows that run over SSH (command jobs, certificate deployment) sign in with the appliance’s own SSH sign-in, show what they will send before anything is sent, and are started or scheduled by an administrator.

Certificates and TLS

• Pinned before a credential is sent. A XenServer coordinator's certificate, a NetScaler’s NITRO certificate, the NetScaler GUI’s certificate when it is opened through Vantage, and a UniFi controller’s certificate are recorded by SHA-256 on first use. A changed certificate is refused, and the credential is not sent, until an administrator accepts the new one by hand. A changed pin is never re-learned automatically, and never in bulk.
• No bypass switch. There is deliberately no "skip TLS verification" option anywhere: not for appliances, not for pools, not for the licensing portal, not in the connection test. A certificate this server does not trust is a refusal in words with the two ways to trust it.
• The portal's certificate is verified against the machine's store plus the public roots (certifi where installed); the download's SHA-256 is checked before a package is offered for install.
• ACME: the External Account Binding credential is never stored; the certificate's private key is generated on the appliance and never passes through Vantage.

What leaves your network, and when

• Nothing to us on a timer unless you opt in. The dashboard contacts the licensing portal when an administrator presses Activate online, Check for a new license, Check for updates or Download. The timed contacts with DTR Networks’ portal are each an opt-in, and none is on until you turn it on: the company’s Uptime page (the external targets’ settings and results to and from uptime.dtrvantage.com); the fleet report (a summary of each product’s state, alert counts, build and licence to manage.dtrvantage.com, every five minutes by default; an update an administrator approved, or a renewed licence, can come back on it); the remote console (the dashboard pulls requests from the portal and answers them); and a subscription to the Vantage reputation list (the dashboard presents its own licence, Installation ID, host name and build to updates.dtrvantage.com and receives the list; nothing about your estate goes with it). The fleet report and the remote console count only with a cloud management key the portal issued for that installation, carrying the scopes you allowed; the dashboard verifies it offline and the key can be forgotten on the page. A trial installation is private: it cannot open either.
• Other outbound calls, none of them to DTR Networks. The bundled geolocation database is refreshed once a month from download.db-ip.com (a public file; nothing is sent; switch it off in Settings > Geolocation). To place your servers on the attack map, the dashboard asks a public-address service (api.ipify.org, then ifconfig.me, then icanhazip.com) what address it is seen from, unless you place them by hand or switch that off. A reputation database you add by URL is pulled from that URL on its schedule; none is added by default.
• The remote console carries no dashboard password. A portal user with access to the account opens the dashboard through a relay: the portal presents a signed, short-lived assertion naming that installation and a role no higher than the cap you set on the dashboard; the dashboard signs the session in as cloud:<user> with an audit line saying "credential not stored"; the portal strips every Set-Cookie; the session ends after four hours idle (settable) and eight hours absolute. VM consoles, RDP and SSH are carried as streams to the targets the dashboard resolves; a NetScaler's own GUI opens on an address made for that session and appliance alone, refused once the session ends. A Windows account needed for actions as you is asked once for the tab and held in the page's memory only.
• Licences verify offline. A key is an Ed25519-signed file checked against an embedded public key; there is no phone-home and no licence server in the request path. The consequence, stated plainly: a revoked key keeps working on its installation until it expires; revocation refuses updates and re-issues, it does not reach into a dashboard.
• Firewall integrations are off until you switch them on, in Settings (Firewall integrations). While they are off, no external reputation list reaches any firewall — the NetScaler, the Windows servers’ rule or UniFi — and nothing is sent to a controller; the reputation databases still sync and answer lookups. Switched on with UniFi set up, the dashboard writes one IP group (the shared block list) to your own UniFi controller when the list changes, checks it every minute and reads it back; the API key is encrypted on the server and never shown again, the controller’s certificate is pinned on first use, and Vantage creates at most the one drop rule you ask it to and never changes or removes a rule it did not make. Cisco Meraki and other firewalls are coming soon, under the same rules.
• Geolocation is local first. Address lookups read a database on the server: DB-IP’s free City Lite, which the installer carries, or a MaxMind database you supply. The online provider is off by default and, when on, sends only the address, budgeted per pass. Looking an address up across the reputation databases contacts nothing but the reverse-DNS asked for.
• HDX Insight and syslog are decoded and stored on your host. No record is relayed anywhere.
• No MAC address is sent to a lookup service. The estate map names a device's manufacturer from the IEEE registry held on your own server; the operator downloads that public file from the dashboard (a plain GET, nothing of your estate goes with it) or uploads it by hand. A device identifier is inventory, and a service receiving one also receives your address and the time.
• The security posture is a read. The agent asks the box about itself (Defender's status, the endpoint services, the firewall profiles, the threats found) and changes nothing; the operator's WinRM read of the same facts writes nothing either, and stores no credential.

The Windows agent

• Deliberately not an administrator. The agent runs as a shared least-privilege service account, so a password stored for monitoring is not a password worth stealing. Running it as SYSTEM was considered and rejected.
• Granted exactly what its collectors need, and the deploy log says so: Event Log Readers for the Security log, Remote Management Users for the scheduled inventory's fallback identity. Where the Security log’s own access list leaves Event Log Readers out, Fix collector rights adds a read entry for that group on that log alone; where a Group Policy sets the log’s access, it names the setting and changes nothing. One opt-in widening: the Hyper-V collector adds the account to Hyper-V Administrators on that host only, because nothing narrower lets an account enumerate guests; it is granted only when that collector is ticked and the log says the group can also control guests.
• Windows Update scans run as a scheduled task as SYSTEM, because the Windows Update Agent refuses a search to a non-administrator; the agent may start that task and read its file, nothing more. Installs are started by the operator, whose account registers a one-off task that installs as SYSTEM, in a folder only SYSTEM and Administrators may write; the task is removed once its result is read, and it never reboots the server.
• Blocking is done by a SYSTEM task, not by the agent. Windows refuses a firewall change to a non-administrator, so where sign-in protection runs, the agent writes the addresses to block into a file and a scheduled task, “DTR Vantage firewall sync”, running as SYSTEM, applies them to one Windows Firewall rule: single addresses only, never a range, loopback or broadcast, at most 2,000, with its result written into a folder only SYSTEM and Administrators can write. The agent account may read the task, nothing more.
• Agents update themselves from your dashboard only. The dashboard offers the new agent scripts in a reply signed with that server’s own secret; the agent checks the signature, each file’s size and SHA-256 and that it parses, keeps the previous copy and puts it back if the new one keeps failing, and waits while an installation is running on the server. The scripts that run as SYSTEM are never replaced this way; they change only with Update agents. Between reports the agent holds one connection to the dashboard open so an offer arrives at once; nothing listens on the server. Automatic updates can be switched off in Settings.
• The agentless inventory installs nothing and writes nothing on the target. It reads over WinRM, on demand as you by delegation or on a schedule as the server's own identity.
• Deployment is as you, over WinRM, with your own credential for that run; the agent is a signed-report PowerShell service, not a binary from a third party. It runs inside DTR Vantage’s own launcher, so Task Manager names it, only where Windows on that server calls the launcher’s signature valid; elsewhere it runs in powershell.exe and the page says why.

Device lockdown

• A separate component, on enrolled machines only. Device lockdown runs as a SYSTEM scheduled task on the machines you enrol with a site key, because removing local administrators and setting machine policy needs it. The monitoring agent on your servers is unchanged and still runs as a least-privilege account.
• Each machine holds its own key, made in the machine’s key store and never exported, and signs every call it makes; there is no password for a device. The dashboard keeps only the public half and refuses a call whose clock is more than ten minutes off or that it has seen before. A site key is kept as a hash for matching; revoking it stops new enrolments, and machines already enrolled stay.
• Nothing is opened inbound. Machines call manage.dtrvantage.com, which carries the calls to your dashboard over the remote console’s connection, so the remote console must be switched on with a key that allows it. The portal bounds the calls (size, rate, an installation that exists and is connected) and authenticates nothing itself: your dashboard checks the machine’s signature, and the machine checks the policy’s, so the portal can carry a call but cannot forge either. A private trial cannot enrol machines.
• The policy is signed on your server with a key that never leaves it, and checked by the machine before it is applied and again before a cached copy is applied offline. An allowance to install is signed and names one machine. The codes read over the phone are computed from a per-device secret issued once at enrolment, kept encrypted and never returned, and a code is never written to the audit log.
• Vantage signs its own device script, and enrolled machines trust its root. So that the script runs under application control, it is signed with a code-signing certificate Vantage makes for itself, and the device installer adds that certificate’s root to the machine’s Trusted Root and Trusted Publisher stores. The private keys are made on your Vantage server, kept there encrypted with the machine-local key, and never leave it. Every enrolled machine trusts that root, so protect the Vantage server as you would any signing system.
• A newer device script is checked before it touches the disk: its signed offer and its SHA-256 are verified, and a script that keeps failing to finish a run is put back to the previous copy.

Actions and audit

• Reading is licensed apart from changing. Without a management module the product reads; with one, every change is a specific, confirmed action by an administrator or operator, in the system's own API (NITRO, XenAPI, the Hyper-V cmdlets), never a scraped GUI.
• Every action is an audit line naming who, what, and the system's own answer; NetScaler changes are also a row in a configuration log with the appliance's words.
• Blocking on a NetScaler is configuration you see first. An enforcement rule shows the exact NITRO commands before a Save, writes only objects Vantage names (a data set, responder policies, the callout and its monitored virtual server), and a rule rolled back or deleted removes what it made, read from the appliance. A condition you add to a policy can only narrow what it drops, and every value is checked before it reaches the appliance. A hand-kept list is a data set on the appliance and holds while Vantage is down; the self-learned list is asked per client through the callout and fails open by default, so a Vantage that does not answer lets requests through (an administrator can choose otherwise, and is asked first). Integrated Caching is switched on for the callout only where it is licensed, and only after a no-cache policy is bound so nothing else is cached.
• Data-destroying actions are administrator-only (VM delete, snapshot revert, host power, Hyper-V remove) and confirmed in words first.
• Roles: viewer, operator, administrator, mapped from AD groups; administrator-only controls are hidden in every place they appear, not just one.
• Who is signed in, and ending a session. Settings > Authentication lists every open session: who, their role, how they signed in, from which address and browser, and when they were last active. An administrator can sign one session out, or one person out everywhere, and the “keep me signed in” that session was given stops working too, also after a restart. Windows (IIS) and remote-console sessions are listed and ended where they belong, and each row says so.
• Each person’s view is their own. Sorts, folds, open tabs and pinned views are kept per signed-in account on the server, so someone else signing in on the same computer sees their own choices. They hold no credential and no setting that changes what Vantage does.
• Files you hand over for analysis are not kept. A NetScaler support bundle holds the whole appliance, so it is read and deleted and only the analysis stays; a packet capture is read and not kept, and a capture Vantage takes on a NetScaler is deleted from the appliance afterwards; nothing in either leaves the server. Secrets in the lines quoted back are blanked before they are shown.
• A syslog line never changes what Vantage stores on its own. A state change arriving in the syslog is a hint until the appliance confirms it, because a UDP datagram can be lost or forged; a forged line costs one extra read, never a false alarm.

The update path

• An update is applied by a system task apart from the service, from a package whose SHA-256 was verified at download: stop, back up, deploy, restart, roll back on failure, and report the outcome to the page. The task's inbox is writable by SYSTEM and Administrators only.
• The updater never touches what it does not ship: it does not change the site's certificate, and applies from a file you can inspect first.
• The installer ships the dashboard compiled. Its modules are Python 3.12 bytecode, not readable source; an update package carries source, which the updater seals again on the box. The Windows agent stays a readable PowerShell script.

Deployment footprint

• One Windows Server VM with IIS in front. Nothing is installed on the appliances or pools; one small agent per Windows server, and the device component only on machines you enrol. The database lives on the box and is backed up by the updater; collectors per location, for an estate spread over several sites, are coming.
• The browser consoles install nothing: a Hyper-V VM's screen, a Windows server's desktop and a XenServer guest are drawn by an RDP client running in your browser, and SSH by a terminal in your browser; the dashboard only carries the connection. The password goes to the server inside the RDP sign-in, encrypted by your browser, and is kept nowhere.
• The NetScaler callouts have a port of their own (TCP 8095 by default): it answers the callout addresses and their health check and nothing else — never the sign-in page — and drops any cookie or sign-in header before the dashboard sees a request. Each ask carries a token, and the block rule leaves a request carrying it out, so the callout's own request is never judged again. The port speaks plain HTTP, so keep the path between the appliances and the server on your own network; Windows Firewall opens it for the Domain and Private networks, not only the appliances. The appliances reach it through a monitored virtual server, so a Vantage that does not answer is let through at once rather than waited on, and a callout written by an earlier build stays where it is until the appliance's monitor reaches the new port.
• The Webroot download proxy is off until you switch it on. For appliances that cannot reach the internet, Vantage can relay their NetScaler IP Reputation downloads (TCP 3128 by default, with its own Windows Firewall rule). It accepts only tunnels to Webroot’s download servers on port 443, never terminates TLS, so it cannot read what it carries, and asks for a password it generates, stored encrypted and never shown back.

Every connection, by direction

What a firewall review needs to open, and what is off until someone switches it on.

Reporting a vulnerability

Write to dtrvantage@dtrnetworks.com. The same address is published at /.well-known/security.txt (RFC 9116), so a researcher who never read this page still finds it.

What happens next: you hear back from a person within one business day, and a confirmed finding is fixed in the next build rather than queued behind features. You are told when the fix ships and which build carries it, and credited in the release notes if you want to be. There is no bounty programme; there is a reply, a fix and a thank-you. Please give us the chance to ship the fix before publishing details.

How fast a fix reaches an installation

Every change ships as a numbered, cumulative build, so a security fix is never held for a release train. A fix is published to the dev channel first, where DTR's own estate and the accounts marked early-access run it; when it has held there it is released to everyone. Each installation then takes it from its own Settings page (Check for updates, Install now) or from the update zip by hand, applied by a system task with backup and rollback. Nothing is pushed into a customer's server without an administrator asking, which is why this page and the release notes say plainly which build carries a fix.

What it is built on

Not a full software bill of materials; the pinned list for any build is yours on request. The dashboard is Python 3.12 on Windows Server with these packages, installed from PyPI or from wheels you stage offline:

Each build's installer names the packages it installs, and a build that updates a dependency says so in its notes. We follow the advisories for the packages above; a vulnerable dependency is handled as a vulnerability report, on the cadence described above.

Certifications, stated plainly

Vantage is not SOC 2 or ISO 27001 audited today. What stands in its place is the design on this page: nothing of yours in a cloud we run, no operator password stored, no TLS bypass, an agent that is not an administrator, every action audited on your own server. Because the product runs entirely inside your network, the controls an audit would attest to on our side largely do not exist on our side; they are yours, on the VM you installed.

What we support when your process needs evidence: your security questionnaire answered from this page and the docs; a walkthrough of the source with us (the installer ships the dashboard compiled; the agent is a readable PowerShell script); a penetration test against your own installation, with our help reading the results; the audit log and the configuration log as exports. If an audited attestation is a hard requirement, say so early and we will tell you honestly whether we can meet it.

Questions we are asked

Can you see our data? Not unless you send it. There is no cloud tenant; what reaches us is an activation code, a licence check when you press Check for updates, the external Uptime targets if you publish them, a request for the Vantage reputation list if you subscribe to it, and, only with the cloud management key you chose to paste in, the calls your enrolled machines make, the fleet report's summary counts and what a portal user with access to your account views through the remote console.

What if a Vantage server is compromised? It holds the appliance and pool credentials and the integration keys encrypted with a key on that machine, the agent secrets, and, where Device lockdown is used, the keys that sign its policies and its device script; it holds no operator password. The NetScaler configuration account and the UniFi API key are worth rotating first; the monitoring accounts are read-only by design; and with Device lockdown, remove its root from the enrolled machines until the server is rebuilt.

Can we review the code? The dashboard is Python, shipped compiled; we walk through the source with you on request. The agent is a readable PowerShell script on each server. Ask.