Identity and Access Management

The Provisioning Process

There should be formal processes and approvals for provisioning accounts and privileges. The user access request should be made by and attributed to the user’s manager and should be fully documented. As part of the provisioning process the identity of the person being approved access needs to be verified and the level of access that individual should have identified.

Standardised roles should be reviewed and approved by all key parties including security. Naming conventions should avoid indicating the level of privilege a user might have, to prevent potential hacking.

Access control should be handled centrally by a systems administrator typically located in your NOC (Network Operations Centre) or SOC (Security Operations Centre).

When staff leave the organisation a user’s account should be disabled and then purged.

Consider access to devices used and the facility, as well as to applications and network services.

Least Privilege Approach

The ‘Principle of Least Privilege’ should be adopted. Review privileges as staff roles change i.e. when major changes to privileges are made. Consider if new privileges are being provisioned what other privileges should I take away. Give users the minimum privileges practical and then work forward letting users request further access if required. Not taking this approach will inevitably lead to what is referred to as ‘authorisation creep’. Auditing to ensure privileges have been trimmed through the change control processes is also required.

Fraud Prevention

Too much authority as outlined above can lead to potential fraud and decreased security. A separation of critical duties is also important. e.g. purchasing and accounts payable privileges should not be allocated to the same person. Another approach is to ensure that one person can do any part of the process but not all of them. The process can also have thresholds to not eliminate but mitigate risk. Auditing mentioned earlier means staff also means fraud is more difficult. To further mitigate fraud Job Rotation, Mandatory Holidays, Dual Controls and auditing as a deterrent will help. These measures mean that to commit fraud staff have to collude with one another, which is inherently risky for them.

User Identification

Two types of access need to be supported human or device.

Identification depends on 3 things. Something the claimant:

  1. KNOWS (e.g. pin or password)
  2. HAS (e.g. RSA Access Token) or the claimant
  3. IS (e.g. biometric information).

Ideally more than one form of identification should be used, this is called multi factor authentication.

Backend systems will confirm the identity (called ‘proofing’) and provide access token to control access such as a Kerberos ticket. This is typically time bounded e.g. 10 hours typically.

Strong complex passwords with expiry dates should be enforced. This is partly training and partly automation. Also need to prevent reuse of passwords and the maximum amount of retries before lock out or time delay.

Additional layers of authentications may include passphrases or specific pieces of information only known to the user (‘cognitive passwords’). It should be noted that this approach can be potentially compromised by personal information available from social media.

Remote Users may have different identification and access requirements from internal onsite users.

Password Resets

Password resets can be handled by a Help Desk associate or via self-service.

  • The Helpdesk associate manually re-authenticates the user using information held on record. In some cases, this is not as thorough as it should be and can be a potential weak link. Temporary passwords should have a very short shelf life and a forced password reset is incorporated at the next log in. The fact that the user is forced to change the password ensures the principle of Non-Repudiation is maintained
  • Self service generally uses an email to the users recorded email address with a link. This can be further secured by a pin provided to or by separate device creating a 2 factor authentication of the useR.

Password Attack Vectors

Bruteforce attack – a hacker tries all possible combinations of a password

Dictionary attack – this is where the password is checked for real words, having a longer password makes this more difficult. Variants of this include a dictionary search with potential substitutions of numbers and characters or use of uppercase characters.

Rainbow Attack – reverse engineering of hash tables that have been stolen using a form of brute force attack. This may be possible without having full access. The danger of this exploit is that all user accounts in the hash table are jeopardised. It is prevented by adding a salt to hashed passwords and there are standard approaches for doing this. The salt adds characters to the hash value to further defend against this form of attack. Microsoft Active Directory is unfortunately still prone to this form of attack.

Replay Attack – if someone has access to the network, they can apply a sniffer (protocol analyser) to identify login credentials from within the network. The login information may not readable but can be used to re-apply authentication and spoof the user to the server, thus gaining access without knowing the log on details. Many modern systems are protected against this exploit through authentication expiry approaches.

Social Engineering – the easiest, most common and successful approach. It involves tricks to get you to reveal your log on credentials generally by establishing some form of trust. Examples are fake calls from Help Desks, email spear fishing attacks etc.

Current Authentication Protocols

  • EAP – Extensible Authentication Protocol – this is a standardised authentication API for any form of authentication including passwords, certificates and biometrics or any other form of authentication.
  • MS-CHAP – Microsoft’s implementation of CHAP

Something the User ‘Has’

  • A token device - such as an RSA Secureid – uses synchronised clocks on the device and the domain controller
  • A smart card - these can be ‘contact’ in nature where you have to pass the card through a reader or ‘contactless’ where the card is detected by being in close proximity e.g. with contactless payments.
  • A smart phone authenticator - such as Google Authenticator or something similar
  • A Digital Certificate - ‘signed’ and provided by a certification authority such as Verisign

Note that devices need to be supplemented by another form of authentication or it is insecure i.e. 2 factor authentications.

Biometrics Options (something the User ‘Is’) include:

  • Finger print (laptops) or palm print (time and attendance) recognition
  • Iris or retina scan
  • Voice print
  • Facial recognition (iPhone X)