Best Practices For Account Management

FacebookTwitterGoogle+LinkedInEmail
Description
Best Practices for Account Management As a continuance of our previous less addressing security controls for account management, we now look at best practices for Account Management in general. We begin with special situations as multiple accounts, multiple roles, and shared accounts and how rights and permissions can be granted for each type of account permitting different types and levels of access and permission to perform certain actions within a level of access. You’ll also learn when it may be necessary to have a shared account and how it should be managed. We’ll discuss Account Policy enforcement and what that entails including why it’s necessary to have strict password generation, expiration, reuse, and recovery policies. [toggle_content title="Transcript"] Today we would be looking at best practices for account management. We have best practices that will be followed we need to mitigate issues associated with users with multiple accounts; multiple roles and we also need to look at shared accounts. For multiple accounts best practice within any enterprise is that we don't have users just coming up with multiple accounts every day. Unless they are clear situations where a user needs to have multiple roles only then should they have multiple accounts. Sometimes you have a person to conduct administrative duties also possibly not administrative duties they could have multiple roles so they might need multiple accounts. This also helps to support the principle of least privilege if you have multiple accounts the privileges in each account are different. We should also be concerned about shared accounts. Sometimes in an enterprise it could be that you have accounts for consultants. These people come and go periodically they come and go. These accounts have to be properly monitored to see what sort of privilege they have; shared accounts would allow multiple users use an account over time. We have to ensure there's proper documentation for who's having access to what account for a certain period of time even if it's a shared account. That's our way we can keep watch over accountability to know who logged on to the system, who did what and when. For multiple accounts it is bad practice that a user has an account to use in January and maybe and another account to use in February at the end of the day all year long they have multiple accounts within the system. Only under very clear situations should user’s have multiple accounts possibly they’re carrying out multiple roles or job functions. We will now discuss some accounts policy enforcement. We have to have credentials management one of the topics we look at under this is credential management. In some organizations or some environments some users usually have more than one password or user ID. It usually becomes a burden trying to remember all your user I.D.'s and the Corresponding passwords. So we have solutions in place to store the user credential within the local system and these will then be encrypted using the password. So this is how credentials could be managed so that user’s are not writing down their ID and passwords or your user ID and passwords on paper’s that they leave around plugged in the desk. So using the solution on the local system the user can store their user ID’s and their password and also encrypt that with some software password as well to encrypt the credential management solution. We also have group policy, group policies can be used to enforce password properties like length, complexity and age. You can use it to enforce accounts lockout policies threshold and duration across the enterprise. So when you implement a group policy this can be used in Microsoft environments or other computing environments to enforce policies like these passwords length, enforcement, audit account event, assign specific rights and controlled over permissions across the enterprise for all our users group policies use to achieve this we also look at password complexity, it is good practice to have password complexity what this means is we have passwords that have uppercase, lowercase, special characters and numbers. This gives complexity to the password it makes it difficult for someone trying to guess your password so you would have uppercase, lowercase, special characters and numbers all mixed around in your password to defeat the malicious person trying to compromise your password. Another best practice with passwords is that we carry out password explorations passwords should be made to expire after thirty to sixty days. More users should have a password at least all year around the same password periodically we've made the passwords expire. Best way to achieve this is to . . . You automate it such that the user server account is down everyday till they change their passwords. Well periodically in any enterprise you would notice that users forget their passwords, users lose their passwords when users go on vacation one other thing they forget is their password. So we should have clear cut measures by which we do password recovery some organizations offload the burden of password recovery to the users themselves. Probably the user would log on to the server and would click on a button that says forgotten password. A link is then sent to their email where they could reset their passwords. It is bad practice that we use reversible encryption to store passwords in the server because that way anybody could go into the server to recall their passwords and that defeat the entire purpose of having the password. We also could disable passwords a staff has been terminated, a stuff is on probation, we could disable the password. The essence of disabling the password is such that nobody has the use of that account, the user themselves or any other persons that have previous knowledge to the account do not know cannot use the account anymore. A staff has left the organization, a staff died, a staff is terminated voluntarily or involuntarily you disable the password. Another best practice we follow with account policy enforcement is something called the lockout policy. What this policy dictates is that after several failed attempts the user account would lock out so the malicious person is trying to gain unauthorized access to a system after several failed attempt putting in the right passwords the account should lock-->out. How many failed attempts should trigger the lock-->out we call that the lockout threshold. So the lockout threshold this is the number of failed attempts that trigger a lockout. Many organizations will set these between three and five. We set that between three and five If you make it too low the actual owners could make a mistake and you’re locking too many people out of the account and if you make it too high you could give enough opportunities for malicious person to gain knowledge of the password. So between three and five you set the password threshold if the number of failed attempts get to that the account is locked out for certain duration of time. The duration for which the account is locked out is called the lockout duration the lockout duration this could be determined by the enterprise and enforced by the administrators. We could have a lockout duration of thirty minutes, forty five minutes that is the total duration of time for which the account is locked out. Another best practice with passwords and account policy enforcement is password history. If we implement password history we dictate how many new password a user could use before they can re-->use a previously used passwords. So if we say our password history is four the user must have four new passwords before they can reuse a password they've used already. So, if I had a password A another password, B another pass word, C another password, D until I’ve used one, two, three, four say I have now a password, E so until I’ve used this then could I repeat one more A or B or C or D. So if a user has not used four new passwords they cannot reuse a frequently use password, this is to allow users create randomness in their use of their password. Password reuse, the policy could dictate that a user cannot reuse the same password in the same year. So if you have one password you've used already possibly for duration of that year you could re-->use that password again, this is also to deter anyone knowing your passwords able to compromise your account. Our password length is a very important topic; best practice dictates that the password length should be at least the minimal of six to eight characters minimal. If you make the password too short it’s very easy to compromise, very easy to crack but if you make it minimum six to eight characters you are increasing the complexity at which the password could be compromised. If you then add that to password complexity where you’re throwing special numbers uppercase, lower case and special characters it becomes very very difficult to compromise your passwords. Another important account policy enforcement to look at is group based privileges and user assigned privileges. All users on the network having access to resources should be assigned privileges and these privileges could include permissions like, permission to read like modify this should be dictated across the enterprise for every user. However if you're having to manage large groups of users it's much easier if you create groups such that you create a group, assign the privileges to the group and if you have multiple users you simply add them as members to the group. This way you’re signed the permissions once and you add as many members as should join the group the moment they become a member of the group they inherit the permissions that govern the group and if you don't need them having the permissions anymore all you do is remove their membership of the group. This way they lose the permissions from that group, so permissions could be user assigned privileges which are individual’s assignments and you could also have group based privileges. With all these accounts and privileges being issued we need to do periodic user access reviews. We need to review what users have access to the system, what level of access do they have. Sometimes we add on permissions periodically so that users could achieve certain objectives. Maybe a user has gone on vacation another user has to relieve them we give permissions but are we removing these permissions? So, periodically we need to do user access reviews to see who has work permission and why? Otherwise we could result in a situation where users have excessive permissions and these defeats the principle of least privilege. Users should only have the permission they need to do their work no more, no less. So, it is good practice that periodically throughout the year we do access reviews, who has had access? Why do they have access? And we check review, the permissions for all our users. Why does a user still have access to a certain resource? We need to know. It could be that they had a resource they had access to resource in January for a project, but we're talking this is September they still have access to the same resource, they no longer working on the project. So, those accesses should be revoked. We also should do continuous monitoring; continuous monitoring of user access it should be an ongoing process for account management. We need to do reviews of account access probably for escalation of rights, monitor new users account, monitor group memberships, monitor, and permissions assigned to groups, monitor failed log on, we continuously monitor these all year long. We could have everything okay by one month, but by the next month or by the next week, issues could arise. So, we do continuous monitoring, continuous monitoring of all our accounts, and continuous monitoring of group membership. Privileges collisions these are best practices we need to do for account policy enforcement. [/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