15 Mar (E)SAE DEEP DIVE SERIES PART 8 – Fine-Grained Password Policies
This month we have reached step 6 of our Top Ten Controls. Today we are talking about Fine-Grained Password Policies. Who now thinks:
MOMENT, the BSI doesn’t recommend changing your password regularly anymore….
Well, we will discuss this issue further below. ATTENTION spoiler, we still recommend a regular password change.
But now back to the content. Here is our infographic on the subject:
Why Fine-Grained Password Policies?
With Fine-Grained Password Policies you can assign different password policies to different groups of users.
Sounds simple, and it is. However, this capability was only introduced with Windows Server 2008. As Grandpa Harrie reminds us in our infographic, before that there was only the possibility to configure a single policy for the whole domain in the Default Domain Policy.
Why do you want different password policies for different user groups?
If you only look at the security aspect, of course all passwords should be very long and complex. In the real world, however, the aspect of usability must also be considered. Is it reasonable for a normal user to enter a thirty-digit password every time after getting a coffee and unlocking their computer (we all lock our computers, right?)? Probably not.
That is why a balance should be struck between security and usability for each user group. And this is where Fine-Grained Password Policies come in.
Especially if you have implemented a tiering model (for more information check out last month’s blog) you can very easily identify the different user groups based on the tier classification.
From our point of view, you should distinguish between the following groups:
- „normal“ end users
- Admin Accounts (Tier2)
- Admin Accounts (Tier1)
- Admin Accounts (Tier0)
- Service Accounts
How are Fine-Grained Password Policies configured?
Fine-grained password policies are configured either in Active Directory Administrative Center or via Powershell.
You can configure the same settings, except for the Kerberos settings, as for the Default Domain Policy. Additionally there is the value “Precedence”. This is used when multiple policies are linked to a user group to decide which policy is applied.
This brings us to an important difference to traditional password policies or GPOs. Fine-Grained Password Policies are not “linked” to OUs or AD sites but to AD groups. This may seem strange at first glance, but it increases flexibility tremendously.
You have to adapt your user lifecycle process in a way that the user is directly assigned to the corresponding group used for linking the policy when it is created.
What fine-grained password policies do we typically use in the (E)SAE context?
What would one of our blogs be without a concrete recommendation? Of course, the concrete settings have to be adapted to the concrete circumstances, but the following policies have proven to be a good starting point:
It is important to configure the default domain policy with a long password in case a user is created and not added to one of the policy groups. Since no user wants a 30 digit password, they will immediately contact the help desk and the correct assignment can be made.
Passwords? Passwords are so two thousand and seventeen
Seriously, are passwords and / or the regular changing of them still up to date?
With a lot of attention in the press (1,2,3), the BSI has removed the passage in its 2020 basic protection catalog that says passwords must be changed regularly. Does this mean that everyone can use their current password forever?
From our point of view, this question needs to be looked at in a more differentiated way. Since most articles in the press did not quote the complete recommendations, but only excerpts, here are the complete passages first. First, the 2019 version:
“ORP.4.A8 Regulation of Password Use [User, Head of IT]
The institution SHALL regulate password use in a mandatory manner. This SHALL specify that only passwords of sufficient length and complexity are used. Passwords SHOULD be changed at reasonable intervals. Passwords SHALL be changed immediately as soon as they become known or suspected to unauthorized persons. Passwords SHALL be kept secret. Default passwords SHALL be replaced with sufficiently strong passwords and predefined logins SHALL be changed. It SHOULD be verified that the possible password length is also checked to the full extent by the IT system. If login attempts are unsuccessful, the system SHOULD not give any indication if the password or user ID is incorrect.”
“ORP.4.A8 Regulation of password use [users, IT operations] (B)
The institution SHALL regulate password usage in a mandatory manner (see also ORP.4.A22 Regulation of Password Quality and ORP.4.A23 Regulation of Password-Processing Applications and IT Systems). This SHALL include consideration of whether passwords should be used as the sole authentication method, or whether other authentication features or methods may be used in addition to or instead of passwords.
Passwords MUST NOT be used more than once. A stand-alone password MUST be used for each IT system or application. Passwords that are easy to guess or are kept in common password lists MUST NOT be used. Passwords MUST be kept secret. They MUST ONLY be known personally by the user. Passwords MUST ONLY be entered unobserved. Passwords MUST NOT be stored on programmable function keys on keyboards or mice. A password MUST ONLY be written down for deposit in case of an emergency. It MUST then be stored securely. The use of a password manager SHOULD be reviewed. A password MUST be changed if it has become known or suspected to unauthorized persons.”
Why are we quoting all of this? Because, from our point of view, the omission of the sentence “Passwords SHOULD be changed at appropriate intervals.” has received too much attention without considering the other changes.
Passwordless and Multi-Faktor
First, the BSI postulates that “It MUST be considered whether passwords should be used as the sole authentication method, or whether other authentication features or methods can be used in addition to or instead of passwords.”
In plain language, this means one should use passwordless authentication methods or multi-factor authentication (MFA). Certainly, technologies for passwordless authentication already exist today, but in practice it is unfortunately the case that not every application in the company supports them. Things look better with MFA, but even that is not guaranteed. Also, not every MFA method is equally secure.
Length and Complexity
If you read carefully, you will notice that the sentence “It SHALL be specified that only passwords of sufficient length and complexity are used”. has also been omitted. Does this now mean that single-digit passwords are completely sufficient? Probably not.
Furthermore, the BSI recommends that “A password MUST be changed if it has become known or is suspected to have become known to unauthorized persons”. So every organization must first ask itself whether it is able to detect whether the password has become known to unauthorized persons.
Except for super obvious things like a ransomware attack, this is a pretty difficult thing to do in practice. You have to correlate logs and monitor user login behavior to do this. Fortunately, today there are services like Defender for Identity, which does just that. However, not every organization wants to send their AD logs to Azure or pay for the corresponding licenses for each user (e.g. EMS E5).
Therefore, our statement on changing passwords is: Until an organization is able to detect if a password is being used by unauthorized people and/or has implemented multi-factor authentication across the board, passwords should be changed regularly.
If you do use passwords and change them regularly, fine-grained password policies are a great way to strike a balance between security and usability.
Of course, even when using fine-grained password policies, one should not neglect to educate and train users and administrators.
Conclusion of Conclusion 😉
Even if the press would have us believe otherwise, passwords will probably be with us for a while yet. Fine-grained password policies help to find the balance between security and usability for the different risk classes.
In our January blog, we started an SAE deep dive series and explained how to use Hyper-V as a secure hypervisor in an (E)SAE scenario. Since by far not all our customers use Hyper-V, but many also use VMWare...15 June, 2020
(E) SAE Deep Dive Series Part 1: Hyper-V Host Guardian Service (HGS) and Shielded VMs in an EASE Environment
After the success of the first ESAE series, we decided to launch a deep dive series in which we go into a little more detail on various measures....16 January, 2020
After Hyper-V HGS and VM protection with VMWare, now the third part of our (E) SAE Deep Dive Series follows. Maybe you follow us on LinkedIn, Xing, Facebook, Instagram or Twitter and ...15 July, 2020