A security administrator has a number of challenges associated with accounts. In this video, you’ll learn about routine audits, password complexity, account lockouts, and location-based policies.
When an administrator is configuring a user on a system, there are many different policies to consider. For example, the administrator needs to configure a username and password for that system. But there are a number of other considerations associated with the account policies as well.
For example, there may be specific password policies on the system. Or we may require additional authentication if the user is connecting from somewhere outside of the building. Once the user logs in, there are a number of other policies that have to be considered in order to keep all of the data safe on the system.
It’s common in most environments to perform periodic audits to make sure that all of the policies that you’ve configured are indeed being used on the systems. Once you set up a system or a series of accounts, it’s remarkable how quickly things can change. So it’s always useful to have periodic audits that are scheduled throughout the year.
And instead of waiting for an audit, there may be a way to have an alert occur if a particularly important policy isn’t followed. You might have a log file analyzer that can go through the entire logs for all of your systems and if any high profile or high security issues were to occur, you can be informed immediately.
Some of the things to look at during an audit, are there permissions that are being used on the system? Everyone should have permissions that are specific to the job that they’re doing. And the permission should not go beyond the scope of their particular role.
I’ve worked in some environments where everyone on the network was assigned administrator access. In those particular cases, an audit would show that the permissions were definitely not set up properly and that changes would have to be made to everyone’s log in. This is a process that should occur regularly, so you might want to set up a one month, three month, and six month checkup for your network.
Once we have the user policies in place, it would be useful to see how those policies were being followed. You might want to look at different resources on the network and determine how those resources are being used. This might also be a good time to look at the applications in use and make sure that they’re accessing the data in a way that would be considered secure.
The implementation of user passwords on a system is a topic that is of great debate in the industry. There are many ideas and proposals on what the best password implementation might be. So you may want to check internally with your organization and see what the best set of policies would be for you.
The idea behind setting these password policies is to have a password that is considered to be strong. This means that it would resist being guessed by someone, or have someone perform a brute force attack and be able to reverse engineer what that password is. To accomplish this, we need to increase the entropy associated with this password. Password entropy is a way to measure just how unpredictable a password might be.
So we don’t want to use any single words. And we don’t want to use any passwords that might be obvious, such as the name of your dog. And if you use lowercase letters, uppercase letters, and special characters all at the same time in the password, it makes it much more difficult to guess and much more difficult to brute force.
This doesn’t mean that you should start replacing letters with numbers that are very similar. For example, you would not replace a 0 with an O or replace the letter T with the number seven. The attackers have brute force systems that are already designed to replace these letters with these numbers because this is such a common thing for people to do. Instead, you want to use a random set of letters and numbers. And you want to be sure that it’s not something that could be guessed by a third party piece of software.
The minimum password size is generally considered to be eight characters, but a longer phrase or series of words is an even better idea for a password. And if you’ve ever been prompted to change your password and you tried to use a password that was used previously, you may have seen that the password was not able to be reused. This is a good best practice that prevents somebody from using an older password that could possibly have already been identified by an attacker.
One way to prevent an attacker from using a live system to perform a brute force attack would be to implement an account lockout policy. This means that after a certain number of incorrect passwords, the account is automatically locked. And even if the attacker was to eventually find the correct password, they would have no idea because the system has already locked that account and made it so that it would not be accessible.
This is, undoubtedly, the norm for most organizations accounts. That way they can be assured that no one is performing a brute force attack on their live systems. This can be especially problematic if the attackers are trying to brute force a service account because then the services that rely on that account could be locked out and you would have to manually go in and re-enable that service.
Unlike a user account, when a service account is locked, it could affect a large number of people. I have seen situations where an administrator has disabled the brute force protection and account lockout policy for a service account, but that generally is not considered a good best practice. You probably want to know when someone is performing a brute force attack. And if someone locks that account, then you would have at least an idea that particular system is under attack.
It’s also very common if someone leaves the organization or moves to a different part of the company that instead of deleting their account, we would simply disable the account. This means that no one would be able to log in to that account, but all of the files and all of the protected information associated with that account would stay in place on that service. This is especially important if the user has been encrypting data using their account information. And you want to save those decryption keys so that the next person who gets that job will have access to the same data.
We can also use someone’s location to be able to set policies on whether they might have access to a system. This could be done with IP addresses or IP subsetting, especially if it’s on an IP subnet that’s inside of our building. But once someone leaves the building and they’re outside of our control, we may not be able to use network location as one of our policies.
Instead, we may want to take advantage of the geolocation for that user. This can use global positioning system coordinates. It might take advantage of the 802.11 wireless network that someone is connected to or, in some cases, use the IP address of where someone may be connecting from. Each of these have different levels of accuracy associated with them, but combined together, you might get a pretty good idea of where someone might be.
We might combine this location with a policy that uses geofencing. Geofencing allows you to set a policy on where a user might be physically located. So if someone is inside the building, there may be a set of policies associated with their account. But if they are outside the building or if they’re in another city, there may be a completely different set of policies.
And we might also take advantage of geotagging, which is location information that is added to the metadata of documents that a user is storing. So a user might store an image or they might store a movie on their mobile device. And within that image or that movie is metadata that has GPS coordinates of where that user was when they took that picture or made that video.
You can take all of these different location based policies and combine them together into one single permission. For example, you can check an IP address and see that someone trying to log in is associated with an IP address block that is assigned to Russia. You would notice that we don’t have an office in Russia. And perhaps more importantly, that user was in Colorado Springs just an hour ago.
This makes it very difficult for us to believe that this user could now be somehow located in Russia. This means this user would not be granted permission to log in. And we may have additional security controls in place because we may believe that this user’s account could be compromised.
You might also combine this with time based policies. There may be, for example, a lab that should only be used during normal working hours. But if someone tries to access that lab at 3:00 in the morning, we might have an alert fire to tell us that something unusual is occurring. And we would prevent access for that user.