All you need to know about MaxPlane Security

Most of the security incidents we help customers recover from are not
sophisticated. They are an unpatched plugin, a forgotten staging site, or a file
upload endpoint that trusted its input. The attack itself is usually automated
and indiscriminate. What varies is how long it takes the owner to notice.

Today we are introducing the MaxPlane Security Suite, which adds two managed
security layers to your servers: Edge Shield, which inspects HTTP requests
before they reach your application, and the Integrity Engine, which watches
your application files for malicious changes and helps you recover from them.

In this post, we walk through how both components work, how to roll them out
without breaking your production sites, and where the boundary sits between what
we handle and what remains your responsibility.

Solution overview

The suite has two independent parts. You can install either one on its own, and
neither is enabled during normal server provisioning.

Edge Shield runs inside your server's web tier as a compiled module. It
inspects incoming requests at the reverse proxy, before they are passed to PHP,
Node.js, Python, or whatever runtime your application uses. Requests that are
blocked here never reach your application code.

Integrity Engine runs as part of the MaxPlane agent already installed on your
server. It scans application files on a schedule, on demand, or in real time as
files change, and it can quarantine and repair what it finds.

Both report into the MaxPlane panel, and both write to your team's audit log.

How Edge Shield inspects requests

Edge Shield is built around a scoring model rather than a simple block list.

A block list is binary. A request either matches a known-bad pattern or it does
not. In practice that approach produces a lot of false positives, because plenty
of legitimate requests contain strings that look alarming out of context. It also
misses payloads that nobody has written a pattern for yet.

Instead, each request Edge Shield inspects is evaluated against several hundred
individual heuristics, grouped by attack class. Injection analysis tokenizes
query parameters and looks at the resulting structure rather than matching text.
Other groups cover command execution, path traversal, cross-site scripting,
protocol violations, and client reputation.

Each heuristic that matches contributes a weighted amount to a running score for
that request. No single heuristic decides anything on its own. Edge Shield acts
only when the total score for a request crosses the threshold you have
configured.

Two things follow from this design.

First, you get a confidence signal, not just a verdict. A request that scored 5
and a request that scored 30 are different events, and we record which
heuristics fired, what each one was worth, and how they were classified. When you
review an event later, the reasoning is all there.

Second, sensitivity is adjustable. Edge Shield ships with tiered sensitivity
levels. Higher levels catch more, and also flag more legitimate traffic. A public
marketing site and an internal API have different tolerances, and you can set
them differently.

We want to be clear that scoring is probabilistic. It is a good general-purpose
filter and it is not a proof. We show you the evidence behind each decision
precisely because you sometimes need to disagree with it.

How the Integrity Engine watches files

The Integrity Engine runs in one of three modes, and most customers use more than
one.

On-demand scans run when you click Scan Now. Scheduled scans run daily or
weekly at a time you pick. Real-time monitoring is the mode worth explaining.

Rather than walking your filesystem on a timer, the real-time watcher subscribes
to file change notifications from the kernel at mount scope. When a file is
written anywhere under your application directories, the watcher is notified
directly and inspects that file. Detection typically happens within a second of
the write, and the idle cost is close to zero, because nothing is scanning when
nothing is changing.

Real-time monitoring needs a resident scanning daemon, which uses roughly 1 GB of
memory. On servers with less memory available, we offer a lighter on-demand-only
mode instead. The panel tells you which one your server can support, and what you
give up by choosing the lighter option, before you install anything.

Threat intelligence updates

Detection content ages. A rule set that was accurate a year ago is a rule set
with gaps today, so the suite pulls updated intelligence from several sources on
an ongoing basis.

The Threat Exchange is worth a note. Servers participating in the network
contribute signals about attacks they observe, and the aggregated reputation data
flows back out to all participants. In practice this means an attacker who has
been hitting other infrastructure is often already known to your server by the
time they reach it. The value of this scales with the size of the network, which
is why it is on by default.

If you have licensed commercial detection content, you can bring it with you.
Rule packs import from an upload, an authenticated URL, or a repository. On
import we validate the pack against a live configuration test, work out which
identifier range it uses, and warn you if it overlaps with something you already
have installed.

Imported packs are pinned to a checksum. If the checksum changes, the install
fails rather than proceeding. We know this is stricter than most tools, and it is
deliberate: rule content loads with elevated privilege, and a vendor who
republished a pack and a vendor who was compromised look identical from our side.
Clearing the pin is a manual step, on purpose.

Rolling it out

Enabling a firewall on a live site is the kind of change that goes wrong quietly,
so the default path is conservative. Protection is gated at three levels, and all
three start off.

1. Install on the server. Edge Shield is never installed as part of routine
provisioning. Installing it compiles a module, modifies your web server
configuration, and pins your web server package to the version the module was
built against. That is not something we do to your server without being asked.

2. Enable for an application. Installing the engine does not protect
anything by itself. Applications are enabled individually, and an application
that has not been enabled is unaffected, including on a server where other
applications are protected.

3. Move from observation to enforcement. A newly enabled application starts
in Observation Mode. Requests are inspected, scored, and logged, and nothing
is blocked.

We recommend leaving a new application in Observation Mode for about a week.
When you are ready to switch to Enforcement Mode, the panel shows you what
would have been blocked over that period, using your own traffic. If a scheduled
job or an admin workflow would have been caught, you find out before it breaks
rather than after.

Handling false positives

Any request filter eventually flags something legitimate. What matters is how
long it takes to fix.

Open the event in the panel and choose Add exclusion for this rule. The form
is pre-filled with the rule identifier, the matched target, and the URI pattern
taken from the event itself. You see the exact directive that will be written, we
validate it against a live configuration test, and then it is applied to that one
application. Other applications on the same server keep the rule.

Every configuration change the suite makes follows the same sequence: take a
backup, write the change, validate the result, and reload only if validation
passed. If validation fails, we restore the backup and report the error. A
configuration that does not validate is never loaded into your running web
server.

Responding to a detection

Finding a malicious file is the easy part. What happens next decides whether you
have a short incident or a long outage.

When the Integrity Engine finds something, it quarantines the file. Quarantine
records the original path, ownership, permissions, and hash in a manifest
alongside the file, and stores it inside the application's own home directory so
that disk quotas and ownership still work correctly. Nothing is deleted, and the
quarantine can be reversed.

What happens after quarantine is configurable per application, because a
customer-facing store and a staging copy do not need the same response.

Restore from snapshot. We find your most recent backup snapshot from before
the file was first seen as infected, and restore just that path. Not the whole
tree. Ownership and permissions are restored to the application's user, not to
root, which is a detail that causes real problems when tools get it wrong.

Restore from source control. For applications connected to a repository, we
fetch the canonical version of the file using the deploy credential the
application already has. No new credentials are involved.

Staged cleaning. For files that cannot simply be replaced, such as a
legitimate file with injected code, the cleaner works on a copy. Your live file
is untouched. You get the original and the cleaned version side by side as a
diff, and you decide whether to apply it. If the cleaner cannot actually improve
the file, we tell you that instead of reporting a successful clean that did not
happen.

Checksum repair. For managed content platforms, we verify core, plugin, and
theme files against known-good manifests and restore the ones that do not match.

You can set an ordered preference, so an application might try a snapshot
restore first, fall back to source control, and fall back to quarantine alone if
neither is available.

Event delivery

Security monitoring that stops working without telling you is worse than no
monitoring, because you will assume the quiet is good news.

The agent tracks its position in the event stream with a durable cursor, and
advances that cursor only after the panel confirms it received the events. If the
panel is unreachable, the agent holds its position and retries. When the
connection comes back, the backlog is delivered rather than dropped. We tested
this by cutting the connection during an active attack simulation; every event
generated during the outage arrived after recovery.

Log rotation is handled explicitly, so events are neither lost nor duplicated
when the underlying file is rotated. Under very high volume there is a hard rate
ceiling to protect the panel, and anything suppressed by that ceiling is counted
and reported. A flood that saturates the pipeline still shows up as a flood, not
as a gap in the graph.

On top of the raw events, you get hourly rollups for trend analysis, audit log
entries for every security action, and configurable notifications for detections,
completed and failed remediations, and unusual attack volume.

The shared responsibility model

We want to set expectations clearly, because a security product that oversells
itself causes real harm.

MaxPlane operates a shared responsibility model. We secure and monitor the
infrastructure layer. You remain responsible for the security of the application
you deploy on it. The Security Suite reduces your exposure and buys you time. It
does not make an insecure application secure.

Concretely, here is what these tools cannot do for you.

Edge Shield inspects requests. It does not understand your business logic. If
your application lets an authenticated user request another customer's invoice by
changing an ID in the URL, that request is well formed, correctly authenticated,
and entirely legitimate as far as any request filter can tell. Only your
application knows it should be refused.

The scoring model is probabilistic, which means it has false negatives. That is
inherent to the approach, not a defect we intend to fix, and anyone telling you
their filter catches everything is describing a product that does not exist.

The Integrity Engine detects known-bad and suspicious files. It will not detect a
legitimately signed dependency that was compromised upstream and looks exactly
like the package you meant to install.

So the following stay with you, and we would encourage you not to treat any of
them as optional:

• Validate input and encode output in the application. Parameterized queries
  prevent SQL injection. A rule set only catches attempts at it. Edge Shield
  should be your second line of defence, never your first.
• Get authentication and session handling right. Enforce strong passwords,
  offer multi-factor authentication, expire sessions properly. No perimeter
  control can tell a legitimate login from a stolen password used correctly.
• Check authorization on every request. As above, broken access control is
  invisible from the outside.
• Keep dependencies patched. This is the single highest-value thing on this
  list. Most compromises we see exploit a vulnerability that had a fix available.
• Keep secrets out of your repository and out of web-accessible directories,
  and rotate them when people leave.
• Apply least privilege. Sensible file permissions, minimal service accounts,
  scoped database users. This limits what an intrusion can reach.
• Test your backups. Our snapshot-based recovery is only as good as the
  snapshot behind it, and an untested backup is an assumption.

If you do these things, the Security Suite covers the gaps and shortens your
response time considerably. If you do not, it will catch some attacks and miss
others, and you will eventually have a bad week. We would rather say that plainly
now than have you find out later.

Getting started

The Security Suite is available on MaxPlane plans and is enabled per team.

1. Open your server and go to the Security tab.
2. Install the Integrity Engine, Edge Shield, or both. Installation runs in the
   background and does not interrupt your sites.
3. Enable protection for one application, starting with a low-traffic or
   non-critical one.
4. Leave it in Observation Mode for a week and review the events.
5. Switch to Enforcement Mode when the data looks clean, and add exclusions for
   anything legitimate that got flagged.

Then repeat for your remaining applications. There is no requirement to enable
everything at once, and we would suggest you do not.

If you have questions about rolling this out across a larger estate, contact
support and we will help you plan it.