3.7 Given a scenario, implement identity and account management controls

  • Identity
    • Identity Provider (IdP)
    • Attributes
    • Certificates
    • Tokens
    • SSH Keys
    • Smart Cards
  • Account Types
    • User Account
    • Shared and Generic Accounts/Credentials
    • Guest Accounts
    • Service Accounts
  • Account Policies
    • Password Complexity
    • Password History
    • Password Reuse
    • Network Location
    • Geofencing
    • Geotagging
    • Geolocation
    • Time-Based Logins
    • Access Policies
    • Account Permissions
    • Account Audits
    • Impossible Travel Time/Risky Login
    • Lockout
    • Disablement


Identity

We have talked about users and security, and providing access to each user, but how do we give a user his credentials?

  • Identity Provider (IdP).  It starts with the Identity Provider.  The Identity Provider is a system that manages the user identities.  It helps us manage Single Sign On by confirming a user’s identity to multiple resources.

    There are different types of IdP, as will be discussed later.

  • Attributes.  Attributes are the properties of the person.  They might include his username, name, e-mail address, and telephone number.  The attributes are supposed to identify a person.

  • Certificates.  We can better identify a person with a certificate.  The certificate is digitally signed by the IdP.  By signing the certificate, the IdP is vouching for the identity of the user.  When a user logs in to a device, he presents his certificate to the resource, and the resource verifies that the identity of the user is valid.

    The user can also use his certificate to digitally sign documents.

    The certificate is normally installed on the user’s computer.

  • Tokens.  We can put the user’s certificate onto a USB device called a token.  This allows the user to take his certificate to other places.  If the user wants to log in to a device, he inserts his USB token.

  • SSH Keys.  SSH is a tool that allows us to use a public/private key combination to log in to a server.  It is common with UNIX devices and with Cisco network devices.  The user must generate a private key and public key pair.  The user then deploys the public keys to any remote servers that he wants to log in to and saves the private key to his computer.  When the user connects to a remote server, he uses his private key to authenticate with the server.

  • Smart Cards.  We can store our certificates on a smart card instead of a token.  To use a smart card, the device must have a smart card reader.

Account Types

In any system, there are several types of accounts.

  • User Account.  This is the standard account.  There may be multiple types of user accounts with different levels of privileges and access.

    • An organization may grant administrative privileges to all user accounts, to some user accounts (based on business need) or to none of the user accounts.  The organization must weigh the benefits of granting these privileges against the risk of damage.

    • A large organization can group different privileges and access into groups, and then assign the groups to accounts as required

  • Shared and Generic Accounts.

    • A shared account is one that is used by multiple users.  For example, a shared mailbox can be used by multiple helpdesk agents.

    • It is better to allow each user to log in with their own account, and then delegate access to them, rather than give multiple users the password to one account.  They will be able to access the same information, but their activities can be accounted for.

    • A generic account is one that may be used by a device such as multi-function printer/scanner or conference room phone.  This device must connect to the corporate network and access specific resources.  Generic account credentials usually do not change.

    • A generic account is risky.  For example, a photocopier may store the generic account username and password in plain text.  The organization must take precautions to ensure that only the device in question can authenticate with that account or use other methods to allow devices to access the network.

      Sometimes a generic account is necessary for legacy devices.

    • The generic account should be assigned the least amount of privileges required for it to perform its tasks.

  • Guest Account.  A guest account is granted to visitors and contractors.  The guest account typically has limited privileges.  Guest accounts should be locked out when not required.

  • Service Account.  A service account is used for maintenance.  For example, a software application running on a server may require a service account to download/install updates.  The service account may not be permitted to log in to a computer.

  • Privileged Account.  A privileged account is also known as an admin account or an elevated account.  The privileged account will have more access than the user account.  In a large organization, there can be different levels of privilege/access, or groups of privilege/access (for example, domain administrator, email administrator, etc.)

Account Policies

Some account security concepts that we can enforce

  • Least Privilege.  The user account should be granted only the least privileges/access required for the user to perform his/her job (or function in the case of a generic account).

  • Onboarding/Offboarding. 

    • User accounts should be tied to an HR management, vendor management, or asset management application.  That is, every account should be accounted for.

    • When the user is first contracted/hired, the organization should identify his role and create an account that provides the necessary privileges.   When an asset is purchased, the account should be created to provide it with access.

    • When the user is terminated or when the asset is disposed of, the account should be locked or deleted.  The account should be locked prior to the user being terminated (this would prevent an angry user from causing damage after learning that he will be fired).  We will discuss HR policies in greater detail later on.

  • Permission Auditing and Review

    • User accounts should be audited to ensure that users are not granted permission to objects that they do not require

    • Auditing should be conducted on a regular basis

  • Usage Auditing and Review

    • No system is perfect; therefore, user accounts should be audited on a regular basis to ensure that all users are active

    • Inactive accounts can be locked out

  • Time-of-Day Restrictions

    • An account can be restricted so that it can only access the system (or specific system resources) during specific times of day or specific days.

    • Workers who operate on a fixed schedule should only be permitted to access the system when required to perform their job

  • Standard Naming Convention

    • User accounts should be given standard names so that there is no confusion

    • Each organization can develop a naming convention based on their own needs

    • The name can include one or a combination of the user’s full name, department, job title, location, and employee ID number

  • Account Maintenance

    • The system should regularly verify that all active accounts belong to active employees/contractors

    • Accounts belonging to terminated users should be deactivated

  • Group-Based Access Control

    • In a large organization, assigning privileges to each account manually can be time consuming and lead to security vulnerabilities (when too many privileges are assigned) or disruption to the business (when not enough privileges are assigned)

    • Instead, groups can be created.  A group is a role that a user plays in the organization.  Each group can be assigned specific privileges consistent with that role.  A user can be assigned to one or more groups.  The user then inherits the privileges that were assigned to each group.

    • For example, an organization may create an “engineers” group.  The engineers group is given the privilege of accessing AutoCAD files.  When a new engineer is hired, he is added to the engineers group.  He now has access to AutoCAD files.

  • Location-Based Policies

    • A location-based policy is one that provides a user with privileges based on his physical location at the time of log in, or based on his office location in general

    • When accessing the network through a mobile device, the user’s GPS location may be used to determine the appropriate policy

  • Password Complexity

    • A password policy may require a user to have capital letters, numbers, special symbols and/or lowercase letters in their password

    • A user cannot repeat a character

    • A user cannot use a dictionary word or their name in the password

    • The password must have a minimum length

    • Passwords that are easy to guess represent security risks

  • Expiration

    • An account can be set to expire (for example, a contract employee with a known termination date should have an account that expires on his termination date)

    • A password can expire after a specific time.  The user would be required to change his password once it expires.  A typical expiry time is three months

  • Recovery

    • If a user forgets his password, he must have a method for resetting it

    • There are several methods
      • Self-service password reset, where the user is authenticated through another method such as answering security questions or receiving an automated phone call/text message.  The self-service password reset is cost-effective because it allows a user to reset his password without involving an administrator. 

        • The danger is that a hacker could reset the user’s password by spoofing/intercepting the phone call or guessing the answers to the security questions.

        • A user may not have set up the self-service password recovery options.

      • An administrator can reset the user’s password after verifying his identity.  If an administrator resets the user’s password, the user should be required to change the password at the next log in.  An administrator should not need to know any user’s password.  There is a risk that by communicating the password electronically or in person, the password could be intercepted.

  • Disablement

    • The user account can be disabled when a threat is detected or when the user is terminated

    • If the account was logged in to from an unusual location, then an administrator may need to review the security logs

    • For example, if a user based in New York logs in to his account in Los Angeles, then there might be a problem, unless this user frequently travels.

  • Impossible Travel Time / Risky Login

    • If the user logs in to his account in New York at 9:00AM and logs in to his account in Los Angeles at 10:00AM, then there is a problem.

    • We can use artificial intelligence and context aware software to determine whether a login is likely to be legitimate. 

    • There are three scenarios

      • The login is very likely to be legitimate.  For example, the user has logged in to his usual desktop computer at 9:00AM in the office that he usually works out of and entered the password correctly on the first attempt.  We should allow the login.

      • The login is very likely to be illegitimate.  For example, the user logged in to his web-based e-mail from Kansas City at 3:00AM.  The user has never been to Kansas City before.  The user typically uses Microsoft Edge but this time he is using Google Chrome.  We should block the login and notify an administrator. 

        We might also lock out the account.  We must find a balance between protecting the data and disrupting the legitimate user.

      • The login may be legitimate, but it is difficult to tell.  For example, the user logged in to his web-based e-mail through his corporate laptop, but he is on a hotel’s network in Boston, and he usually logs in in through his office in Houston.  The network would tell the user that something seems different and ask for more information.  Perhaps the user will receive a text message asking him to enter a code to verify that it is really him.

  • Lockout

    • The user account can be locked after too many incorrect logins

    • The lockout period can be temporary or permanent (for example 15 minutes)

    • The user may have a self-service option to unlock the account, may need to contact the administrator, or may need to wait

  • Password History

    • The system keeps track of every password used by a user

    • A password expires after a period (for example, 3 months)

    • Once the password expires, the user must choose a new password

    • The system verifies that the new password does not match any of the previous passwords

      • Passwords used in the last number of days (for example 450 days)

      • The last number of passwords (for example the last six passwords)

    • An intruder/eavesdropper may have guessed/seen the password and then used it to log in and steal resources.  By changing the password often, the risk that the intruder continues to have access is mitigated.

  • Password Reuse

    • Passwords should not be reused, not even in combination

    • For example, if the user’s password is ‘Apple1’, they might be tempted to choose ‘Apple2’ as the next password

    • This is a bad idea

    • It is difficult to enforce if the system stores one-way hashes of passwords.  The hash of ‘Apple1’ may be quite different than ‘Apple2’.  It can be mitigated by implementing a multi-factor authentication policy.

  • Password Length

    • The length of the password should be at least eight characters to reduce the risk of a brute force attack

A permission issue occurs when

  • A user has permission to access resources that he or she does not require – a user should be able to access only the resources that he or she needs to perform his job.  For example, a user in the marketing department should not be able to see sensitive human resources records.

  • A user does not have permission to access resources required to do his job – the user will not be able to perform his job, which will result in lost productivity.

An organization must have an efficient process to

  • Allow new and existing employees to request access to resources
  • Review requests to access resources and determine if the requests should be granted or denied

  • Grant access to resources; the requests should be reviewed and granted quickly so that the requesting employees can remain productive

  • Review existing access permissions and revoke access to resources that users no longer require

An access violation is when a user attempts (successfully or unsuccessfully) to access a resource that he/she should not be able to access.

An access violation may be accidental or deliberate.  A deliberate access violation may be the result of a person’s curiosity or may be malicious (an attempt to steal or destroy data).  

All access violations should be investigated

  • A successful violation is caused by a system or resource that is not configured correctly.  The system must be configured to prevent unauthorized access.

  • An unsuccessful violation may be caused by a user who is attempting to steal or destroy data, or who legitimately requires access to the resource, but has not been granted access.