Wegweiser
All notes

Website security with nothing to set up

Every tenant now has Website Security Light: a passive look at a client's public websites, running on an account of its own, with nothing to connect first. Advanced adds active tests and decisions that later scans respect. And the device, client and group pages now read in order, each analysis opening on its verdict and closing on what to do.

On Monday, scanning a client's website started with a Fenrir account of your own, connected under Integrations. From today it does not. Every tenant has Website Security Light, and there is nothing to connect or configure before you can use it.

Light: it looks and never attacks

Light is a passive check. It crawls the site the way a visitor's browser would and reads what comes back: security headers, TLS, cookies, outdated JavaScript libraries, and what the site gives away that it should not. It never sends attack traffic. A website is checked at most once a day, and rescanned monthly or when you ask.

The one thing that has not changed is permission. A website is still only checked after a master names it and records that the client has agreed, with a name, a date and the version of the wording they agreed to. A passive check still sends requests at somebody else's live server, and that is their decision to make, whatever tier the scan runs on.

The two switches that used to come before that decision, connecting a credential and then arming the tenant, are now one switch under Integrations > Fenrir, and it starts on. Switch it off and website security disappears completely: no card on the client page, no chat tool, no scheduled scans. The history is kept, so switching it back on brings everything back.

An account of its own

Behind the scenes, every tenant scans through a Fenrir account of its own, created the first time it is needed. That matters more than it sounds. A scanner remembers things across the scans one account has made of a site: that one is already running, what changed since the last one, which findings somebody has already decided about. Two MSPs can easily look after the same website, and on a shared account each of those memories would cross from one to the other. Separate accounts make that impossible rather than something to filter out.

The plan lives on the scanner's side too, and the scanner enforces it. A Light account cannot start an active scan, whatever Wegweiser believes about it, so a mistake on our side costs a refused request and never an attack nobody asked for.

Advanced

Website Security Advanced adds active tests that probe for real weaknesses, weekly rescans, the evidence behind each finding (exactly what was sent and what came back), and decisions that later scans carry. We switch it on for your account; ask at support@wegweiser.tech. Your history comes with you.

Moving up does not start attack traffic by itself. Scans stay passive until a master chooses a deeper default under Integrations > Fenrir, so the upgrade and the first active test are two separate decisions.

A decision that sticks

Some findings are not a problem here. A library version the scanner flags that the vendor has already patched in place, or a risk the client has looked at and accepted. On Advanced a master can now say so, with a note, and for an accepted risk a date to look at it again.

The decision is written to the scanner as a standing rule for that website and that finding, so every later scan carries it rather than raising it again next month. Settled findings are listed apart on the card and in the client report under "Settled by decision", left out of the tally and the open count, and named as settled when you ask the chat about the site.

Before this, a finding marked as a false positive in Fenrir was recorded here as fixed, which it never was. The first scan after this release brings those back, marked as settled, and does not count them as regressions.

Findings that read in order

The findings on a device page were one long document whose only divider between two analyses was a hairline. Open a healthy check and it ran straight into the next one. The security audit arrived with boxes and an accordion of its own, in a style nothing else on the page used.

Each check is now its own sheet with its severity down its edge, under the band the rail names: Needs attention, Watch, Healthy. The filter chips hide a whole band. Healthy checks sit together in one list, and opening one lifts it out onto a sheet of its own, so an open analysis has a visible end.

Every analysis opens on its verdict, as a sentence. A short verdict used to run straight into the next sentence without a full stop, and the score line was then printed again underneath. And every analysis now ends on what to do about it: the recommended action is set apart from the paragraphs above it, and "No action needed" takes the same place, quietly.

The security audit reads like everything else now, with a verdict of its own: "Lynis hardening index 67 of 100, with 2 warnings and 33 suggestions", then its warnings, then its suggestions by area.

The client page, in chapters

A client's page was a loose collection of cards, and the two things that face the outside world, uptime monitoring and website security, got lost among them and read as an afterthought.

It is four chapters now, in the order of the questions you bring to a client: Overview (how are they), Estate (where is the score being lost: groups worst first with their device counts, the event forecast, site bandwidth), Public surface (uptime monitoring and website security together, two readings of the same thing: is it up, and is it sound), and Analysis and reports.

A rail down the side names each chapter with its state, the way the device findings rail names checks with their scores: a monitor that is down, the worst website grade, how many machines are forecasting errors. On a phone it becomes a row of chapter links.

The bar at the top used to show the number of groups, a creation date printed as a raw number of seconds, and an ID. It now shows the groups with their devices, the uptime monitors, and the website grade. "All up" is only said when every active monitor has actually reported up; with the monitoring server unreachable, the page says it does not know. The date moved under the client's name, as "Client since".

The group page, same shape

A group opens on the same bar as a device and a client: how many devices and how many are online, how many need attention, and the lowest scoring device, one click away. Then the devices, worst first, so the machine to look at is the one at the top. Then the analysis and the health history, which used to take half of the first screen.

Deploy Agent moved below the device list, where it had been sitting above it. An empty group is a page for deploying, so there it comes straight after the overview.

The analysis cards on client and group pages open on the analysis's verdict too, rather than on its first few hundred characters.

Also

Every PDF report's footer names your company and the client, group or machine it is about. A machine reports its own name, and a name containing markup could have been read as markup rather than printed as text, which the report renderer would then follow. Names are now always text, and the renderer only opens Wegweiser's own files (the cover, the fonts, your logo), so nothing inside a report can make it fetch anything else.

And a passkey sign-in that failed for any reason other than a cancel did nothing at all: the page's error message crashed before it could appear. It now tells you what went wrong.

More notes

  1. What only goes wrong the first time

  2. Agent release log

  3. A case, put to the test