Security policy (preview)

The security policy sets what a console password must be, how many wrong guesses lock an account, and how long a console session lasts, for everyone who signs in to your console. You can set each rule yourself or start from a compliance framework preset. This page describes the preview of Settings > Security policy and how to change the policy.

Caution

In the released version, Depot 0.4.1, Settings > Security policy shows settings that are not yet applied, under the notice Mockup. The policy in force is still the built-in one: at least twelve characters, screened against known-breached passwords, five failed attempts then a fifteen minute lockout. Nothing on the page is saved. The rest of this page describes the preview.

How the policy works

The policy is one set of rules for the whole organization, shared with Authentication, which holds the two-factor rules.

• Built-in floor. Every password is at least 12 characters and is screened against known-breached passwords. The policy can raise these rules, never lower them.
• Compliance baselines raise it further. When a compliance baseline selected in Profiles asks for a stricter password rule, sign-in enforces the stricter value, and the field shows a hint such as Raised to 14 by a compliance baseline selected in Profiles.
• Session limits apply to every console session from the moment you save, and lockout rules to the next failed sign-in.
• Password rules apply when someone next changes their password. A stricter save also makes them apply at the next sign-in, as described in What a stricter policy does.
• Every change is recorded in the audit log, and every owner is notified.

Before you begin

• You need the client:manage permission to change the policy. Anyone with client:read can view it.
• Read What a stricter policy does. Saving a stricter policy signs everyone out, including you.

Choose a framework

The Framework list on the Compliance framework card fills in every control on the page with a preset. The controls stay read-only until you choose Custom, so a reviewer can see exactly what a preset turns on.

Framework	Minimum length	Remember previous	Expiry (days)	Lock after	Lock for (minutes)	Idle timeout (minutes)	Second factor
CJIS Security Policy	12	10	90	5	10	30	Required for everyone
CMMC Level 2	12	24	90	5	15	15	Required for everyone
HIPAA Security Rule	12	0	90	10	15	15	Optional
ISO/IEC 27001	12	24	90	10	15	15	Optional
Microsoft security baseline	14	24	0	10	10	1,440	Optional
NIST SP 800-171	12	24	90	5	15	15	Required for everyone
NIST SP 800-53	12	24	90	5	15	15	Required for everyone
PCI DSS 4.0	12	4	90	10	30	15	Required for everyone
SOC 2	12	4	90	10	15	15	Optional
DISA STIG	15	24	60	3	15	15	Required for everyone

Every preset requires a capital letter, a number, and a symbol, and sets the maximum session length to 168 hours. Every preset also sets the second-factor requirement on the Authentication page, where the requirement stays locked until you choose Custom here. A preset does not change which second factors are accepted or whether devices can be remembered.

The framework name is a label for your reviewers. Outpost enforces the values in the fields, not the name.

Set the rules yourself

1. Go to Settings > Security policy.

2. In Framework, choose Custom.

3. On the Passwords card, set:

   Field	Range	What it does
   Minimum length	12 to 128	The fewest characters a password can have.
   Remember previous	0 to 24	How many earlier passwords a person cannot reuse. 0 turns it off.
   Expiry (days)	0 to 730	How old a password can get before it must change. 0 means passwords never expire, which NIST SP 800-63B advises.
   Require a capital letter, Require a number, Require a symbol	On or off	Composition rules. The page warns that these tend to produce weaker passwords and that length and screening do more.

   Screen against known-breached passwords (always on) cannot be turned off.

4. On the Lockout card, set Lock after (failed attempts), from 3 to 20, and Lock for (minutes), from 1 to 1,440.

5. On the Sessions card, set Idle timeout (minutes), from 5 to 43,200, and Maximum length (hours), from 1 to 2,160. The idle timeout cannot be longer than the maximum length.

6. Select Save. If the change is stricter, confirm with Save and sign everyone out.

The defaults, which match the policy built into Depot 0.4.1, are a 12 character minimum, no history, no expiry, no composition rules, a lock after 5 failed attempts for 15 minutes, a 1,440 minute idle timeout, and a 168 hour maximum session.

What a stricter policy does

A save is stricter when it raises the minimum length, adds a composition rule, starts or shortens password expiry, or (on the Authentication page) widens the second-factor requirement, stops accepting a factor, or stops passwordless sign-in. Before saving a stricter policy, the console asks: Saving signs everyone out, including you. People whose password no longer meets the policy will be asked to change it.

After you confirm:

1. Every console session ends, yours included. The page says The policy was saved. Everyone has been signed out, including you. Sign in again to continue.
2. When they next sign in with their password, a person whose password no longer meets the policy sees Choose a new password, with Your organization’s password policy has changed. Choose a new password to continue. and the list of rules under A new password has to be:. They cannot use the console until they choose a new password, or select Sign out.
3. From then on, a password older than Expiry (days) is caught the same way, with Your password has expired. Choose a new one to continue.

Until the policy has been made stricter at least once, Outpost does not re-check existing passwords at sign-in and does not expire them, even where a compliance baseline names a maximum age.

Raising Remember previous, or changing lockout or session limits, does not sign anyone out. Those rules apply at the next password change or on the next request.

Verify

The page shows Saved. next to Save. Sign in again if the save signed everyone out. The change appears in the audit log.

If something goes wrong

Message	Cause	Fix
Somebody else saved the policy while you were editing. Reload to see their version, then make your changes again.	Another person saved the policy, on this page or the Authentication page, after you opened it.	Select Reload and make your changes again.
You need the client:manage permission to change the security policy.	Your role can view the policy but not change it.	Ask an owner.
The policy was not saved. Check the highlighted field.	A value is outside its range.	Correct the field named under it.

Related

• Authentication
• Manage your console account
• Access rules