Security Posture Recommendations

Your security posture is the set of settings that decide what this instance guarantees. You can see what yours is currently set to on the admin dashboard, under Security Posture.

This page suggests values for three common situations. They are advice, not settings — nothing here changes anything until you change it.

You are accountable for these decisions

GeoHazardWatch does not and cannot decide whether your configuration is appropriate for your situation. You alone are accountable and responsible for that decision and for its consequences.

That is not a formality. Software that asserts a security posture on your behalf misplaces the accountability: it invites you to select a label and stop thinking, and the label cannot know where your instance sits, what data is on it, who can reach it, or what you have promised anyone about it. Only you know that.

So these are three descriptions of situations, with the values that usually suit them. Read the one closest to yours, decide what your deployment actually needs, and own the outcome. Where a recommendation is wrong for you, it is wrong — change it.

There is deliberately no button that applies one of these, and no report telling you how far your instance deviates from one. See Why there is no score below.

The three situations

These are not a scale from weak to strong. They are three different situations, and the right one for you is whichever describes yours — not whichever sounds most secure.

What to set

Every name below is an ordinary configuration key. You can change any of them on the admin configuration screen, and every change is recorded in the audit log.

Session and cookie

session.secure is false on baseline for a real reason, not laziness. A browser will not send a Secure cookie over plain HTTP, so an instance on your own network without TLS that sets this to true locks itself out of its own sessions — you would not be able to sign in. Set it to true only once the instance is actually reached over HTTPS.

If something in front of this instance terminates TLS, set ngdpbase.server.trust-proxy as well. The two are read together, and turning on one without the other is a known way to get a confusing result.

Identity and registration

Open registration is reasonable on a network where you already trust everyone who can reach the instance. Once anyone can find it, whether strangers may create their own accounts is a decision worth making deliberately rather than inheriting.

Login throttling

Locks always expire, on every one of these. A permanent lock on a known username is a way for somebody to keep you out of your own instance.

Audit

on-failure decides what happens when auditing is configured and cannot work. continue runs without an audit trail and says so on the dashboard; refuse-boot stops the instance serving until you fix it — it stays running so you can sign in and repair the configuration.

page-read records who looked at what, not only who changed what. It is one entry in ngdpbase.audit.events, the map that names every recorded action with what happens when its record cannot be written (on-failure) and an enabled switch; set only the switch you mean to change. That is noise on a general-purpose instance and the entire point on one holding records about people.

retentiondays of 2190 is six years, which is what documentation-retention expectations in health regimes typically assume. Check what your own obligations actually are rather than taking that number from this page.

Content sanitisation

Worth checking on your own instance: filters.security.enabled ships false, while the individual controls beneath it — cross-site scripting prevention, HTML sanitisation, dangerous-content stripping — all ship true. Those individual settings do nothing while the master switch is off. If you expected content filtering to be running, look at this one first.

Outbound network

Empty is the recommendation in all three situations. This instance refuses outbound requests to private address ranges by default, which is what stops a page author from making the server fetch something on your internal network. Add a range here only when you have a specific need, and add the narrowest one that meets it.

Hardening the audit log's storage

You can point the audit log at its own volume with ngdpbase.audit.provider.file.logdirectory. No new setting is needed — it is already separate from where the application logs go.

Two things it buys:

• It isolates failure. A full or failed content volume does not stop auditing.
• It allows different permissions. A separate location can be made append-only by the operating system, so the instance can add records but cannot rewrite or truncate them.

Two things it does not buy, stated plainly because the difference matters:

• It does not make the log durable. Records are held briefly in memory before being written, and a different disk receives the same writes at the same moment.
• It does not survive the machine. A separate local disk is the same computer. Anyone who can delete records in one location can delete them in the other.

Why there is no score

Nothing here measures your instance against these recommendations and tells you how far off it is. That is deliberate.

There is no authoritative value set for a deployment under a compliance regime. Consultants in the field err toward caution, and no two assessors agree on the same instance. A number this project invented, presented to you as a deviation, would be software asserting a judgement it cannot support — and you would reasonably act on it.

What you get instead is stronger: this instance states what it is set to, records every change to those settings, and reports any subsystem that is configured and not working. Facts, with no interpretation layered on top.

What this instance cannot do for you

Configuration is a small part of any compliance regime, and the parts these pages cannot touch are usually the larger ones: agreements with your suppliers, risk analysis, training the people who use the system, and what you do when something goes wrong. No setting on this page addresses any of those.

Multi-factor authentication is not available on this instance at all. If your situation requires it, ngdpbase.auth.required-factors showing ["password"] is telling you something important.

Where to see your own settings

This page is advice. The Security Posture section of the admin dashboard is what your instance is actually set to — open that alongside this page when you are deciding what to change.