The user role can be a useful criteria for security management. In this video, you’ll learn the best practices for role-based management and how shared accounts and credentials should be managed.
One of the challenges for a security professional is assigning the right roles of people to the correct resources. We have so many different resources on our networks. There are printers that people have certain permissions and access to. And certainly, files and folders that are on servers have many different permissions and rights depending on who needs access to those particular pieces.
We usually assign access to these resources based on someone’s role. This is much easier than taking each individual person and assigning individual rights and permissions to all of those different resources. Instead, it’s so much easier to say if you are in the marketing department then you have this kind of access to this particular printer, or this particular share on the network. This makes it much easier, so that when somebody’s removed from the marketing department then they would automatically lose access to those particular resources.
We want to make these definitions to be very specific to someone’s role. But we don’t want to make it so specific that it becomes cumbersome to manage. So the marketing department might have some global roles associated with it. But you might need different roles for the management of the marketing department versus the rest of the marketing department. And how you segment out and decide what types of groups or types of roles you create is going be based on the business needs of those particular areas.
If you’ve then assigned different levels of access to a resource– one for the marketing department and a different level of permissions for the marketing managers– then whatever system you’re using, or the resource itself, has to be able to make a determination of what role to put you in. Do we put you in the marketing manager’s role? Or do we put you in the more restrictive marketing role? And the agreement over whether somebody gets more permissions or less permissions is generally based on the type of role system and permissions that you are using in your environment.
A shared account is when more than one person knows how to authenticate in as a particular username. This is sometimes limitations based on the device that you’re using, maybe it only allows for one particular username. But generally, most of the systems that we are using allow you to build separate account names so that you don’t have the situation where you have shared accounts.
This is usually a best practice to avoid shared accounts, although you’ll find some organizations that use the administrator account and is sharing that across multiple users. This is probably not the best idea. But it’s something that is allowed by the operating system.
Just one of many reasons why this is a bad idea can be based on the idea of auditing. If something is changed or modified on a file server, or on the network, it would be nice to know who made that change and when they made that change. But if multiple people are logging in as administrator, for example, then all you know is that the administrator user made a particular change. And you have no idea exactly which user did this.
The concept of narrowing this down to a very specific person is called non-repudiation. We know that if we have a particular user’s name pop up then it really was that user. But if everybody’s sharing the same account there’s no way to have non-repudiation.
Shared accounts are also much more prone to be compromised. When you have so many people that know the username and password for an account it’s just that much more likely the that password is going to get out. And if we do need to change the password on the account then we have to inform every person who is sharing that account name that the password has changed. And then we have to find a way to get them that new password in a way that is secure.
The idea of shared accounts is something that creates a lot of complexity on the security side. And the best practice is to avoid it at all costs.
We want to be able to protect these login credentials at all cost. It is this username and password that gains access inside of your network. And we want to make sure that only the authorized people get access to those particular resources.
One way to protect against somebody gaining access to this is to protect both the username and the password. At no time should you embed some of this information within the application itself. Sounds so easy, if you could just walk up to a machine and it would automatically login for you. But every time you’re doing anything automatically with credentials that means that that user name and that password is being saved in some way inside of your system. If possible, we would like to store those only in your brain, and not in any type of automated system.
We also want to be sure that if we’re sending that authentication information across the network that it’s also protected and encrypted. Very early on in the world of computing we were sending information across the network in the clear. But we found out very quickly that that is an easy way to have your credentials stolen.
So if you are going to send a password over the network, it’s always best to send a hash, or some encrypted form of that, to be sure that no one would be able to SNIP the network, capture those packets, and then have access to your login credentials.