Implementing Appropriate Security Controls When Performing Account Management

FacebookTwitterGoogle+LinkedInEmail
Description
Implementing Appropriate Security Controls When Performing Account Management In this lesson we discuss the strategies for establishing single vs. multiple entity accounts when establishing administrative and user accounts to access and or manage network resources. For example, we discuss why it’s an important best practice to have a separate administrative with only specific admin rights and a separate user account for restructure user rights for network admins, and to have separate user accounts with and without admin rights for users who have different roles within the organization to prevent abuse of power. [toggle_content title="Transcript"] The first item we look at is to mitigate issues associated with users with multiple accounts or multiple roles. It is good practice that when you have user account on your systems, each account is for only one entity. If you must have multiple users perform the same type of roles you need to have a different account for each entity. Possibly you have 4 administrators, Administrator A, administrator B, administrator C and administrator D. These 4 individuals should log on to the system with different accounts. Yes they are 4 administrators but they should each have their independent account otherwise it becomes an issue who did what. Was it person A, B, C or D? There can be no room for accountability. Their accounts have to be different from each other for us to say it was administrator A who did it or B, C or D. It's bad practice that users can just demand different accounts periodically. The system will see these accounts as a different person. Unless a user is performing multiple roles, they should only have one account within the system. Where a user is performing multiple roles, the user could have 2 accounts provided one account is only used for administrative purposes and the other account is used for basic user roles. It's bad practice to have an administrator periodically changing roles and still using the same account. There could be abuse of power. The principle of least privilege dictates that 'the user should have only the permission required to do their work' so it would be inappropriate for an administrator to Also have user roles and carry out those user roles while logged on as the administrator. An administrator that is also performing user roles should have one account for administrator roles and another account completely different for the basic user roles. If you must have multiple accounts it is also good practice that the 2 accounts do not share the same password. On the administrator account you could have a different set of passwords to what you have on the user account. We don't use the same password on multiple accounts even if they are used by the same user. Next, we must perform account policy enforcement. All the rules that apply to the account must be the same across the board for all the users. Rules for password complexity, use for even the identification nomenclature, meaning the user ID. Some organizations would do first initial last name. This has to be the same across the board for all the users. Administrators do not change the nomenclature as they wish. This would create confusion and result in user errors and possibly account management issues. So the account policies should be enforced across the board for all the users. How the users can log on to the system whether locally or on the domain. All of these have to be considered. Next we talk about password complexity. When creating the policies for the users, if we implement password complexity it means that the users must log on using passwords that are very complex. This involves the use of the uppercase, lowercase, special characters and some numbers. All of these have to be into the password before the password meet the requirements of the password complexity. The use of password complexity makes it tougher for malicious persons to easily crack our passwords. Usually we have 2 types of basic password attacks. Something called Brute force and another called Dictionary attacks. In the Brute force attack, malicious person is sat at the system trying to guess one character after the other hoping to successfully guess the password and in the software dictionary attack, the malicious persons will gather a dictionary of words not necessarily the English dictionary but it could be words about the user. May be their hobby or their lifestyle and these words are used in software to try to attack the password but if we introduce complexity passwords, the malicious persons are kept guessing. It's difficult to tell what characters appear first and subsequent characters after that because you use uppercase, lowercase, special characters and numbers and these are mixed up in no particular sequence to further confuse the malicious persons. It is good practice that we expire passwords periodically. Users should be encouraged to change their passwords. However, if you encourage your users to change their passwords some might not change their passwords so best practice is you implement it as a control. That way it can always be enforced across the board. Everybody is given a count down and their passwords are periodically expired. This way they are forced to change the password. You expire the passwords after a period of 30 to 60 days or 90 days based on the policy dictation. Where your users are also going on vacation, best practice is that you expire their passwords. When you expire the password of an individual going on vacation it means themselves and other persons who might know the passwords cannot use the passwords. This way we are able to guarantee that only the user as we see then know the passwords. For password recovery, periodically our users might forget their passwords. It most happens when users go on vacation when they return. "Oh I have forgotten my password. I cannot log in". There are many strategies by which we could carry out password recovery. In some cases these users could have a link on the site such that if they forget their passwords they just make a request and this request is serviced via email. A link is then provided to the user via email with which they are able to recover the passwords. The users could also call the help desk and the administrators can possibly after identifying the users properly, authenticating users through a password reset after which the user is prompted to change password at first log on. This way it ensures that the administrators no longer know the passwords for which the user is accessing the systems. It's bad practice that a system's admin can do password recovery for a user by just looking in the server. For these purposes, passwords should not be saved with reversible encryption. If you save your passwords with reversible encryption anybody having access to the server could reverse the process and thereby decipher what the password is. Malicious person can also do this. Passwords should be saved using hashing which is a one-way process. If we provide the data it should be hashed and saved on the servers. This way nobody else can reverse that process to decipher what the password is. Best practice is also that the length of our passwords should be at least a minimum of about 8 characters. Nothing less than that. Characters less than eight are very easy to decipher, very easy to crack and gain unauthorized access into our systems. We should do at least a minimum of 8 characters. Passwords could be as much as a 127 characters but as humans we find it difficult to retain long sets of passwords in memory. A minimum of 8 characters is best practice over here. It's also good practice to disable passwords that are no longer in use. You could disable passwords for accounts. In some cases you might even disable the use of a password if the account is a non-sensitive account. A non-sensitive account where you might allow guest users coming and use the system, you could disable the use of a password thereby no password is required to access the system. Only for non-sensitive accounts that have non-sensitive privileges whereby the users could not abuse the system. We have account lock out. After several failed attempts, the policies dictate that the account should be locked out. Where a user has failed to log on by producing or providing the correct credentials, the system should lock out. No more access to the system. The number of failed attempts that trigger the lock out is what we call the lock out threshold. Best practice is that we set the lock out threshold to between 3 and 5. Anything lower than that could lock out the real user even if they were to make a typo and anything above that if you make it 7 to 9 or something like that, it gives the malicious persons enough opportunities to guess the passwords right. We want to set it between 3 and 5. How long should the user stay locked out for if they provided the wrong credentials? This is what we call the lock out duration. The duration could be 20 to 30 minutes or 40 minutes. Well it could be any minutes as dictated by the policy. This is set on the servers and implemented through account policies that are passed through group policy objects. Next we have user assigned privileges. What our users could do when they log on. These are assigned through privileges given to the user accounts. The privileges dictate what the users can do on the systems that they can read, write, modify or have access to certain directories dictated by the privileges assigned to the users. However if we sometimes have to issue permissions to multiple users, best practice is that we create a group. This way we assign the permissions only once and multiple users needing access to such permissions we make them a member of that group. Once the user has become a member of the group, they inherit the permissions that govern the group and if we need them not having the membership anymore we simply remove their membership of the group and automatically they lose the privileges that are assigned. This is a very efficient way to manage privileges. It ensures that rather than having to issue 3000 persons the same types of privileges and we are having to do it over 3000 times. We simply do it once by assigning the privilege to one group and you make the 3000 users a member of that group. They automatically inherit the permissions that govern that group as they become a member. [/toggle_content]
Learn on the go.
The app designed for the modern cyber security professional.
Get it on Google Play Get it on the App Store

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play
 

Support Cybrary

Donate Here to Get This Month's Donor Badge

 
Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel