Security Check-up

Running a Security Check-up

The Security Check-up is a read-only report of every security-relevant setting on your installation, gathered on one screen. Use it before an audit such as Cyber Essentials Plus, after an upgrade, or whenever you need to show somebody how the platform is actually configured rather than how you remember configuring it.

Where to find it

Architect Panel → Security:

• Security Check-up — the full report, section by section

Architect Panel → Configuration:

• Site Settings — where most of the settings the report reads are changed

The Status Panel button in the Architect Panel header also opens a Security Configuration card, which shows how many settings need review and has its own Security Check-up button. The card and the report are worked out by the same checks, so their numbers always agree.

What the report covers

The report is divided into thirteen sections, each with a contents button at the top that jumps to it and shows how many findings in it need attention:

• Authentication methods: which sign-in methods are switched on, and each Active Directory domain, Azure AD tenant and SAML provider.
• Multi-factor authentication: whether 2FA is available, whether it is enforced and for whom, which methods are offered, and how many enabled local accounts have an authenticator app.
• Password policy: length, composition, common-password and username checks, history and expiry.
• Brute-force protection: blocking by IP address and by account, what is blocked now, and failed sign-ins in the last seven days.
• Sessions: the idle timeout, cookie flags, database session checks and the timeout warning.
• Accounts and access control: accounts with administrative or architect access, dormant accounts and disabled accounts.
• Data protection, Audit and logging, Integrations and exposure, Security headers, HTTPS certificate, TLS and ciphers and Platform and PHP: encryption at rest, file storage, the audit chain, API keys, response headers, the certificate the site presents and the server software.

Each section is a table with four columns: Setting, This installation (the value actually in force), Assessment and Notes.

The five assessments

• OK: the setting meets the usual expectation.
• Review: acceptable in some circumstances, but worth a deliberate decision.
• Action needed: a gap an assessor would record against you.
• Not implemented: the platform has no setting for this control, or has one it does not enforce. These are stated plainly rather than shown as configured, and they are not counted as something you can clear.
• For information: context such as counts and current values, not a finding.

Running a check-up

1. Open Security Check-up. The header confirms which site the report describes and the date and time it was produced.
2. Read the five summary tiles at the top. Each shows how many findings carry that assessment, and each is also a filter: untick OK and For information to leave only the findings that need a decision. A note under the tiles says how many findings the filter is hiding, with a Show all button.
3. Work through the sections with the most findings first, using the contents buttons.
4. Where a finding counts something (accounts, blocked addresses, encrypted fields), use its button, such as View accounts or View blocked addresses, to list the entries behind the number. Long lists show the first 200 and say so.
5. Where a finding names the screen that changes it, the button in the Notes column opens that screen directly. Findings marked Set in config/config.php are held in the server configuration and are changed by your hosting administrator.
6. Use Print this report to keep a dated copy as evidence. The printout includes the date and the site address from the header.

Nothing on the screen changes anything

The report only reads. Opening it, filtering it and listing entries alter no setting, so it is safe to give it to an auditor or a new administrator. To change a finding, follow its button to the screen that owns the setting, save there, and reopen the report to confirm the assessment has moved.

What goes wrong

• A finding still shows the old value after you saved. Reopen the report from the panel rather than relying on the copy already open; it is assembled when the screen loads.
• A setting is switched on but marked Review. Read the note. Some settings only take effect when another one is on; the report calls these "Enabled, but INERT" rather than letting them pass.
• "That list is not available on this installation." The data that list reads from is not installed on your site, usually because the feature it belongs to has not been set up.

Worked example

An organisation preparing for Cyber Essentials Plus opens the Security Check-up and filters it down to Action needed and Review. It finds four items: 2FA is available but not enforced, blocking by account is disabled, the minimum password length is 8 with no common-password check, and 23 enabled accounts have not signed in for 90 days. The administrator follows each Site Settings button in turn, uses View accounts to export the dormant list for managers to confirm, and prints the report before and after as evidence of the change.

Recommendations

• Run it after every upgrade, not only before audits, because new settings arrive with new releases.
• Filter to Action needed and Review to get a working list, then show all again before printing.
• Do not record a Not implemented control as present in an audit return; the report says so for a reason.
• Keep the printed copies with your audit evidence, dated.
• Use the entry lists for dormant and privileged accounts as the starting point of an access review.

Fixing Common Check-up Findings

Most installations show the same handful of findings the first time the Security Check-up is run. This article takes the common ones in turn: what the finding means, where it is fixed, and what to check afterwards.

Where to find it

Architect Panel → Security:

• Security Check-up — the findings and their assessments
• Disabled User Accounts — identities that may not sign in
• Blocked IP Addresses — addresses blocked now
• Blocked User Accounts — accounts blocked now

Architect Panel → Configuration:

• Site Settings — 2FA, password policy, blocking thresholds and session settings

Admin Panel → User Administration:

• All Users — the accounts the dormant and administrator lists point at

Multi-factor authentication

• Enforcement: "Optional - not enforced for anybody" (Action needed). 2FA is available but nobody is required to use it. Turn on enforcement in Site Settings, after checking enrolment: see 2-Factor Authentication.
• Enforcement: "Enforced for specific groups only" (Review). Accounts outside the listed groups can sign in with a password alone. Check that every group with administrative access is on the list.
• E-mail codes: "Offered as the ONLY method" (Action needed). A code sent to the account's own mailbox is close to a single factor. Ask your hosting administrator to offer an authenticator app as well, and treat e-mail as the fallback.
• Accounts with an authenticator app, shown as "X of Y". Only authenticator apps count here: an account that uses SMS or e-mail codes alone is counted as without one. Use View accounts to list the rest and chase the people concerned before you enforce.

Password policy

• Minimum length below 12 (Review below 12, Action needed below 8). The note explains that 8 is accepted alongside multi-factor authentication or common-password blocking, and 12 without. Raise it in the Password Policy group of Site Settings: see Password Policy.
• Block common passwords switched off. Switch it back on; it ships on.

Brute-force protection

• Blocking by IP address: Disabled or Blocking by account: Disabled (Action needed). Failed sign-ins are not being counted, so password guessing is unthrottled. Turn both on in Site Settings. Blocking by account matters even when blocking by address is on, because it stops guesses spread across many addresses.
• More than 10 attempts allowed (Review). Cyber Essentials expects lock-out or throttling after no more than 10 failed attempts. Lower the threshold.
• CAPTCHA on the sign-in form (Not implemented). There is no setting for this. The blocking settings above are what protect the sign-in form.

Sessions

• Idle timeout longer than a day (Review). Shorten Maximum Session Idle Time in Site Settings, and consider the timeout warning so people are not caught out: see Session Management.
• "Enabled, but INERT" against tying a session to its IP address or browser (Review). The setting is on but does nothing, because database session verification is off. Either switch verification on or switch the inert setting off so the configuration says what it does.
• Cookie flags marked Set in config/config.php. These are changed by your hosting administrator, not on any screen.
• Absolute session lifetime and Concurrent session limit (Not implemented). Record them as absent; there is nothing to configure.

Accounts and access control

• Enabled accounts with no successful sign-in in 90 days (Review when above zero). Use View accounts to list them. The list includes accounts created recently and never used, so check the creation date before acting. Disable accounts nobody needs rather than deleting them, so the audit trail still resolves.
• Accounts with administrative access. A count, not a finding, but the list behind it is the one an assessor will ask for. Confirm each person still needs it, and that administrators use a separate account for everyday work where your policy requires it.
• Accounts explicitly disabled. Identities refused at sign-in whatever their password, listed on Disabled User Accounts.

Checking your fix

1. Change the setting on the screen the finding's button opens and save it.
2. Reopen Security Check-up from the panel.
3. Confirm the assessment has changed and read the new note, which sometimes points at a related setting.
4. Check the Security Configuration card on the Status Panel: its count of settings to review should have fallen by the same amount.

Worked example

A housing association's first check-up shows nine findings needing a decision. The administrator turns on blocking by account at 10 attempts in 15 minutes, raises the minimum password length to 12, and shortens the idle timeout from fourteen days to four hours with the warning switched on. The 2FA finding is left at Review while enrolment rises, with enforcement planned for the following month. The dormant list of 31 accounts goes to team managers, and 27 are disabled within a week. The rerun shows two findings left, both with a recorded reason.

Recommendations

• Fix the Action needed findings first; they are the ones an assessor records against you.
• Do not switch a setting on just to turn it green; read the note to see what it costs your users.
• Record a reason for every Review you keep, so the next check-up does not reopen the same debate.
• Pass the config/config.php findings to your hosting administrator as a single list.