It’s important to match credentials to the task at hand. In this video, you’ll learn about differences between accounts used by personnel, third-parties, devices, services, and administrators.
The credential management process we use with our usernames, passwords, and other credentials is a critical part of our data security strategy. Without the proper credential management, your data would be accessible to anyone. It’s remarkable then how often the implementation of passwords might be on a system. And I have, in more than one occasion, run into an application that stored the passwords as part of the application itself. This is certainly not a secure way to manage credentials. Instead, all of the passwords need to reside on the server side. The client will type in passwords on demand, and you certainly don’t want to store passwords as part of the operating system or the applications.
We also want to be sure that the communication process for the application especially during the login process is encrypting these credentials. If we’re using TLS, for example, to communicate to a web server, then we know that that entire communication process is encrypted. We certainly don’t want to send our login credentials across the network in the clear, and we may want to check to be sure that our applications are using an encrypted form of communication.
We also want to be sure that the person who’s logging into his system is logging in with their own personal account. This is an account that is not shared with someone else, that the only person who could be logging in with this account is the single owner of that account. In the operating system, this username is associated with an identification number, so we always want to be sure that the user ID, the identification number used by the operating system, and the single user logging in is always the same person. When you authenticate to an operating system, it allocates a section of the storage drive to be associated with your own personal files. And even if someone else was to log in to the same physical system, they would not normally have access to your private files. This is a feature of the operating system, and it’s an important reason why we have separate personal accounts for different people.
Another important security policy associated with these user accounts is that the users do not have privileged access and certainly not privileged access by default. We want to be sure that the user accounts are configured to allow them to do the work that they need to do, but no additional access to the operating system. This not only limits what individual users can do in the operating system, but it also limits any malware that’s running as that users rights and permissions, and keeps that malware from accessing any restricted part of the operating system. These personal accounts, or user accounts should be the default for everyone connecting to the network. Even the IT department will use a user account during the normal day, and if they need additional access to the operating system, they’ll use an elevated account for a temporary time frame.
Beyond the accounts that user might have to log in to the local network, there may be third party accounts that they use to log into external systems. This is common when accessing a cloud based system, which probably doesn’t have a way to authenticate to your local user database. So if someone’s logging in to a cloud platform for payroll purposes, or they’re using cloud based enterprise resource planning software, and they probably have a third party account that they’ve created on that website. There might also be business partners or vendors that log into our local computer system. Those are third party accounts used by someone outside of the organization, and they could be connecting to our network from anywhere on the internet.
In both of these situations, it’s always good to have some additional forms of authentication. So something like two-factor authentication, or multifactor authentication, would be a valuable addition to these accounts. If we do have third party accounts that we use to access cloud based services, or we have business partners or vendors that are connecting to us, then we may want to perform occasional audits to make sure that those accounts are also safe. And of course, just as we have with our personal accounts, third party accounts should also be unique accounts that are tied to an individual. We should never allow account sharing either internally or with our third party accounts.
We also need to define additional credential policies for our mobile devices such as our smartphones and our tablets. Our security team could deploy device certificates, which would identify that device as a trusted piece of hardware and one that has already been validated by the security team. We might also require that the users have screen locks, and there are standards for the type of screen lock and the way that they would unlock the system. Those policies and standards can be pushed out through the Mobile Device Manager, or MDM, so that you have a uniform set of policies for all of your mobile devices.
And we can add additional credential management on top of that by requiring certain geography based checks to ensure that someone using this account is located in an area that we would expect them to be. We can also require additional authentication factors such as a biometric, and we might also associate a device with the user so that the only people who could authenticate from that mobile device are the people registered to that device. There might also be credentials used on a device that you never see. These are probably used by the services that are running on your device, which are background processes that normally are not seen on someone’s desktop. If you’re running a web service, a database service, a prince bulla, or any one of the many services running in an operating system, you want to be sure that those services have the correct credentials.
It’s common to use different credentials for different services, depending on the access that they need to the operating system. For example, a web service has certain rights and permissions they need to access files on the system, but those rights and permissions are probably very different than a database service. So the login name and password we would use for the web service would probably be different than the database service.
One challenge with managing these non interactive services is there’s no way to prompt the service for a password change. So we need to have policies in place that would allow us to make changes to these credentials and have those changes pushed out to all of these service accounts. During the normal workday, you have a user account configured on your system, and that’s the one that’s normally used to perform your day to day functions. But there may be times when you need elevated access to an operating system, and in Windows, that elevated access is the administrator account, and in Linux, it’s the route account.
These elevated accounts provide complete access to the operating system, so you would be able to configure the hardware, the device drivers, install additional software, and perform any other function in that operating system. This is why the common best practice is to run with a user account normally, and only use the elevated accounts when it’s required. If you make a mistake while using the elevated rights and permissions, you could cause some significant damage to the operating system that normally would not be allowed from a user account. This also prevents malware and other types of malicious software from gaining enhanced access to the operating system, and could limit the scope of a virus outbreak.
You would obviously have additional security controls associated with these credentials. If you’re logging in with administrator or route access, then you should probably be using some type of multifactor authentication. And it might also be a good idea to occasionally change the password for these accounts to ensure that only authorized users have access to these enhanced credentials.