Traditional health monitoring works at the protocol layer: 'port open', 'HTTP 200 returning', maybe 'page content contains this word'. These answers say the server is serving, but not WHAT content it is serving.
Modern problems live precisely in this gap. If an attacker bypassed WAAP and dropped a webshell on the server, the health probe keeps saying 'server is healthy'. If a deployment failed and the server is responding with the old binary, the protocol probe still reads 200 OK. If an operator manually changed a config file, the baseline drift goes silent.
At cluster scale the situation is worse. 9 of 10 servers have the new version, 1 doesn't; the health probe sees all as healthy, a user request unluckily lands on the stale server. Or conversely, 1 server has an attacker-dropped file, the rest of the cluster is clean, but that one server keeps receiving traffic because nobody is watching.
ETM Server Integrity and Deployment Intelligence fills that gap: file, directory, binary, and configuration state on the server are continuously observed; changes flow as events to ADC and SOC; routing decisions move past the outer shell.
The agent on the server runs file-level continuous inspection; it detects changes and binds live to ADC routing decisions and SOC event systems.
Selected critical files (webroot content, application binaries, config files, TLS certificates) are periodically hashed. Merkle-style aggregate hashes are produced for directory trees. Change is detected instantly via hash comparison.
Files appearing outside the expected baseline, existing files being modified, or expected files going missing all produce instant events. A new .aspx/.php/.jsp file dropping into the webroot is flagged as a webshell suspect.
Hash comparison runs across servers serving the same application service. A single server diverging from the expected distribution (drift or compromise) is split off; traffic shifts to consistent peers.
When change is detected, ADC traffic policy can react automatically: warm-up period, gradual routing, temporary isolation. New deployment events get a smooth traffic shift; unauthorized changes get traffic cut.
File integrity and deployment intelligence aren't only security — they're part of the operational decision plane.
Content files held in web server vhost roots (HTML, ASP, ASPX, PHP, JSP, JS, CSS, assets) are periodically hashed at file and directory-tree levels. Operators define which directories are observed and which extensions are sensitive through policy. Unexpected changes appear as instant events.
When an attacker bypasses WAAP and tries to drop a webshell on the server, ETM catches the new executable extension (.aspx, .php, .jsp, etc.) appearing in the webroot in real time. The server can be quarantined automatically, traffic cut, SOC alerted. This is the LAST layer after WAAP.
An application binary or artifact hash change is interpreted as a deployment event. ADC waits for this event: a server receives reduced traffic while health metrics stabilize, full traffic resumes when warm-up completes. The manual 'pull from load balancer, deploy, put back' cycle automates.
When configuration files drift from baseline — Apache conf, Nginx conf, IIS application config, systemd units, cron definitions — an alarm rises. Operators intervene before unauthorized change settles; planned changes are met with baseline updates.
Critical system binaries, libraries, and utility hashes are compared with baseline. Binary change from rootkits, supply-chain compromise, or manual interference is caught instantly; the server is moved to isolation, kept open for forensics.
When ownership, permissions, or ACL entries on critical files and directories change, events are produced. Unauthorized privilege escalation, file ownership change, or opening write permission to sensitive configuration becomes instantly visible.
Baseline hash comparison runs across servers serving the same application service. If 9 of 10 match and 1 differs, the differing one is a drift or compromise suspect. Automatic quarantine or operator-approved isolation can apply.
When an operator opens a maintenance window, changes inside that window don't raise alarms; baseline updates per policy. Expected deployment events aren't read as 'unauthorized change'; surprise changes still trigger alarms.
If post-deployment ETM telemetry (GC time, error rate, restart frequency) shows degradation, ETM correlates it with the deployment event. ADC routing prefers servers carrying the previous version hash; the rollback team is notified automatically.
Every file/config/binary change is written to the audit trail and forwarded to SIEM. Which server, when, which file changed from which hash to which hash — the evidence chain is ready for audit. Live support for PCI DSS, ISO 27001 A.12, and sectoral audit requirements.
Integrity monitoring is not just a technical feature; it is the live management layer for enterprise deployment and security processes.
Which directories are observed, which file extensions are sensitive, which files are ignored (logs, cache, temp files) — all governed by policy. Different profiles can be defined for web server, application server, and database server.
Critical files (system binaries, TLS certs) can be hashed at seconds; medium-priority (config files) at minutes; low-priority (static content) at hours. Disk IO load stays under control.
Integrity events bind live to ADC routing policy. 'New file detected + WAAP attack context present → isolate', 'Hash drift detected → lower priority', 'Deployment detected → warm-up' — these rules are defined by operators.
CI/CD pipelines can notify ETM API of deployment events; ETM interprets them as expected change, triggering routing coordination instead of alarms. After deployment, ETM signs the new baseline.
High-priority events — webshell suspicion, binary tampering, cluster drift — go directly to SOC alarms. Events are enriched: which server, which file, hash comparison result, last-modified timestamp, suggested action.
Every integrity event is recorded in the audit trail. When the auditor asks 'which file changed on which server in the last 30 days?', the answer is live. PCI DSS, GDPR Article 32, and sectoral audit requirements get an automated evidence chain.
Even if WAAP missed the attack, a new executable file dropping into the IIS vhost directory is caught by ETM in real time. The server is automatically pulled from the cluster, traffic cuts, SOC gets an instant alert; the device stays open for forensics.
When DevOps deploys a new version, ETM catches the application binary hash change; ADC routes traffic to the server gradually. When health metrics (CPU, GC time, error rate) stabilize, full traffic resumes. The manual 'pull from LB, deploy, put back' cycle disappears.
9 of 10 servers in production match the baseline hash; one shows different. Outdated version, manual intervention, or compromise? ETM quarantines that server automatically; operators investigate. A user request doesn't unluckily land on the wrong version.
After a new release, ETM telemetry shows GC time stretched, error rate climbing, restart frequency rising. ETM correlates with the deployment event; ADC routing prefers servers carrying the previous version's hash. The rollback team is informed automatically; the deployment decision is data-supported.
When a critical system binary's hash drifts from baseline on a server — rootkit, supply-chain compromise, or unauthorized change — the server is split from the cluster, internet access cut, only ETM management channel kept open. SOC investigates remotely for forensics.
Let's see ETM Server Integrity live in your own backend — a deployment session covering baseline definition, ADC binding, and SIEM flow on a pilot server group.