Identity and Account Management Solutions
Controls for identity and account management are fundamental security practices. They aim to protect against purposeful or unintentional unauthorized access, working closely with authentication and authorization solutions discussed in the last two posts.
We can analyze those controls by considering the management methods during the account life-cycle (account management) and how the company designates and enforces account access and activity (account policies). But before presenting these domains, it’s essential to define a couple of concepts that will appear often in the foreground and background of those explorations.
Firstly, it’s good practice to avoid using shared accounts, which makes controlling and auditing users’ activity difficult. So, each employee must have a unique account set, including identity, attributions, and credentials.
The next logical step is to understand the different account types, defined mainly by the level of privileges each account has. An administrator account (e.g., a domain or enterprise admin) has extensive access rights. Even though those rights are necessary to perform system management, users must use them for everyday routine tasks, such as accessing email or editing texts and spreadsheets. This habit unnecessarily exposes the admin account, which attackers seek after for its high privileges.
The best practice is to assign a standard user account for daily tasks and only use admin privileges for specific tasks. Linux and Windows have mechanisms that provide such functionality: respectively, sudo and RunAs. Windows’s User Account Control (UAC) also asks for admin approval for any application activity requiring higher system privileges. It’s also worth pointing out that devices often come with pre-installed admin accounts, sometimes with default and easy-to-guess passwords. Those factory accounts must be deactivated, and adequately secured credentials must replace default passwords.
The second concept is the least privilege. It states that a company must assign the minimum access rights necessary for the user to execute their organizational tasks and attributions. So, an attacker seeking to gain deeper system access cannot exploit an account’s unnecessary rights.
Separation of duties means that more than one person should carry out a task or function. In other words, no single user should solely be responsible for a transaction, from approving to executing it. Since it prevents a single employee from misusing a company’s assets, this control helps the organization avoid fraud, theft, or sabotage.
Account baselining is a procedure that establishes regular, line-of-business activity aligned with the company’s role attributions. This procedure provides a reference point for monitoring activity deviations, which might indicate violations. Additionally, since baselining operationalizes organizational role attributions, it facilitates auditing and updating those according to new business and security demands.
Finally, it’s essential to highlight the role of directory programs for account management and policy enforcement. Windows Active Directory (AD) is the most well-known tool, but OpenLDAP is an excellent open-source alternative. AD uses the concept of objects, which include users, machines, groups, and the rules/policies themselves. Effective logical access models and account policy enforcement heavily rely on AD functionalities.
Account Management
Account management encompasses controls delineating account parameters and assigning them rights across their life cycle. Those controls act during onboarding and offboarding procedures, account review/auditing, time of day/location restrictions, and logical access control models. It’s worth noting that the previously discussed concepts of account types, least privilege, account baselining, and separation of duties are behind the account management processes.
Onboarding and Offboarding
Onboarding refers to the procedures for setting up the account at the beginning of the employee’s contract and admittance into the company. An Identity Provider (IdP) generates and assigns an identity and a set of credentials while also managing authentication procedures. It may also involve assigning specific devices to the user. IdP and Windows AD integration largely automate onboarding, which minimizes IT staff intervention.
Offboarding is the opposite process, de-provisioning the user’s identity, credentials, and assets. The company must follow specific guidelines regarding data, intellectual property, and certain mobile management settings (e.g., bring your own device [BYOD]). Standards such as ISO/IEC 27001 and 27002 recommend that organizations revoke credentials before an employee’s contract termination, avoiding violations such as sabotage and sensitive data exfiltration.
Account Review and Auditing
As business and security demands evolve, companies must update account parameters. Simultaneously, employees may change their roles and accumulate attributions and privileges, which can compromise the least privilege and separation of duties implementations. Reviewing and auditing work to prevent such situations while providing better adaptation to an ever-changing environment. This practice aligns with the principle of continual improvement advocated by standards such as the previously mentioned ISO 27001 and 27002. Access rectification is a formal type of account review, which is the responsibility of a Chief Information Security Officer (CISO).
It’s good practice to execute reviews and audits annually for accounts that access general applications and quarterly for sensitive and critical systems. Companies may change account baselines, providing new reference points for their roles. Credentials may be de-provisioned and again provisioned for recently promoted employees or those who changed roles.
Time and Location Restrictions
Companies may determine rules regarding account logins, precisely when and where access occurs.
Time-of-day rules may restrict access to specific hour intervals, blocking login attempts in off-business times when there is less monitoring. OSs differ in how they deal with already logged-in users. Windows’ Automatically Log Off Users functionality, for example, forces log-off on an already logged-in user when the login interval expires. In a complex and closed enterprise environment, Kerberos and Windows AD may enforce such a rule with the Enforce User Logon Restrictions option, typically enabled by default.
Location restrictions rely on technologies that collect user location data from GPS and other wireless networks:
- Geofencing triggers an action when the user crosses into or out of a defined boundary. This action may be permitting or blocking account access;
- Geotagging associates location data to a file, such as what happens when a photograph has metadata on the location where it was taken;
- Geolocation gathers user location data mainly from GPS, but it can also use alternative methods, such as cell data.
Systems may incorporate location data into their account login management, especially when the user is supposedly logged in within a timeframe too short for travel between two sites. For example, a user working in an office in Los Angeles logged into the system and, after 4 hours, did the same in a machine from Sydney, which isn’t possible since the flight duration between those cities averages 15 hours.
Logical Access Models
Companies must choose a particular model of reference to attribute access rights to their accounts. A previous post discussed such models in detail, so we’ll present an abridged version here.
- User-based models attribute rights to discrete users. They are compatible with tightly controlled environments (e.g., government and sectors dealing with patents). Conversely, these models aren’t scalable and are expensive and complicated to manage;
- Role-based models, on the other hand, distribute rights to roles or groups. Users who fill those roles inherit their rights profile. Users may belong to multiple groups with conflicting rights. If a user belongs to two groups, with one of them having a more liberal rights profile while the other being more restrictive, the user will always end up with the second one. Role-based models are significantly scalable and easier to manage. AD is an excellent technology for reliably establishing logical access models, especially role-based ones.
Account Policies
Account policies are a subset of policies that regulate basic account parameters, i.e., passwords, lockout, and expiration. Again, AD’s Group Policy Objects (GPOs) aggregate such rules and may apply them to users, machines, groups, and, at a high level, to Organizational Units (OUs), which encompass the previous entities.
Passwords
Password policies determine central aspects such as length, complexity, reset, rotation, and age/history.
A good practice is establishing a minimum length of 8 characters since it isn’t so long that the user can’t remember it while being sufficiently resistant to most brute-force attacks.
Concomitantly, the password must be complex, i.e., it has to include at least 3 of the following character types: uppercase letters, lowercase letters, numbers, non-alphanumeric characters (aka special characters), and other Unicode characters that may be considered alphanumeric. Additionally, the user must avoid applying their account name as the password. Combining these measures helps reduce the effectiveness of dictionary attacks.
Another central issue is password reset. The system must not recover the old password but provide a new one instead. Such operations must include identity validation, which may happen through challenge-response methods (e.g., a challenge question) or a recovery code sent by email or instant messaging.
Another good security practice is periodically renewing passwords, which may happen in 30 to 90 days, depending on the application’s sensitivity and criticality. In Windows, this age is set through the Maximum Password Age option. Additionally, most standards recommend that this change may occur between business cycles, maintaining good security while preserving productivity and reducing work loss.
Through Enforce Password History, Windows can enforce a rule that blocks the repeated use of old passwords after a pre-defined number of times the user creates and applies unique passwords (ideally, 24 unique passwords). This control must be combined with a minimum password age (of at least two days) for increased effectiveness. This way, a user or an attacker cannot circumvent enforced password history through rapid password rotation.
Some observations regarding maximum and minimum password age in Windows:
- If a maximum password age is set, the minimum password age must be less than the maximum;
- If the maximum password age is set to 0, the minimum password age can be set at any number between 0 and 998 days
Account Lockout and Expiration
Policies can handle login lockout after failed attempts. This type of control prevents an attacker from repeatedly trying to guess a user’s password. Those policies establish criteria such as:
- The maximum number of failed attempts before lockout. Good practice dictates a maximum of 5 attempts. Any less than that, and requests to the help desk increase. If set to 0, the lockout doesn’t happen. In Windows, this rule is represented by the Lockout Threshold feature;
- The period between one failed attempt and the subsequent attempt. This is known in Windows as Account Lockout Counter;
- The time during which an account remains locked before it automatically unlocks. In Windows, if set to 0, the account only unlocks after admin intervention. This Windows option is named Account Lockout Duration Policy.
Account expiration is an adequate control for contractors and temporary workers. In Windows, the admin can establish a specific date through the Account Expires option. After this date, the system revokes the account and all its credentials and privileges.
