We rely on many different logical security methods to protect our systems. In this video, you’ll learn about least privilege, access control lists (ACLs), zero trust, multifactor authentication, and more.
One of the things you’ll notice in your work environment is that everybody’s workstation has a different set of rights and permissions. That’s because we don’t want to give administrative access to everyone in the organization. If malware or an attacker finds its way onto one of those systems, they would effectively have full access to all devices on the network. Instead, we want to provide just the right amount of rights and permissions to allow someone to do the work that they normally do.
We refer to this minimum set of rights and permissions as least privilege. This means that the user’s access to data should be limited to only what’s required to do their job, and any applications that we’re setting up will run with those limited privileges. Implementing least privilege on your network provides everyone with the access they need to do their work, but it also restricts any access by malicious software or malicious actors.
One of the problems with many organizations is that they put all of their security on the border of their network, leaving the inside of their network very susceptible to any type of attack. To address this issue, many organizations are moving to a zero-trust implementation. This means that no device on the network is trusted, whether it’s outside the network or inside the network. This means that every user, every device, every application, and anything that happens inside of the organization needs to be authenticated.
There needs to be a level of trust associated with all of these devices, regardless of where they reside. This means you’ll find many organizations implementing additional security controls on the inside of their networks, such as multi-factor authentication, data encryption, perhaps the updating of system permissions, adding additional firewalls inside of the network, and additional reporting and analytics on everything that happens on the network from a security perspective.
One common type of logical security is an Access Control List, or an ACL. An access control list can be used to allow or deny traffic through a particular point on the network. We commonly associate the term ACL with a series of rules inside of a router interface. But broadly, an ACL can apply to many different types of technology in different areas of the network. A common set of criteria that we often use with ACLs are things like a source IP address or destination IP address so that we can determine whether that traffic is allowed or denied based on its source or destination.
Perhaps we evaluate the TCP port numbers, UDP port numbers, whether this is the ICMP protocol or some other type of protocol. We can even combine these different criteria to create a more complex ACL and create more security on the network. Once we’ve created the criteria, we also need to create the disposition. Do we allow traffic that matches this ACL? Or do we deny this traffic? And we use ACLs in many other parts of the network as well. If you’ve ever configured rights and permissions in a Linux operating system or a Windows operating system, you have effectively configured an access control list.
When you log into a service these days, you’re often asked for more than just a username and a password. Those additional factors are referred to as multi-factor authentication. This requires us to provide additional information during the login process to prove that we are really who we say we are. For example, you may be logging on to a system that asks you for a password. That’s something that. You might also have to reference a mobile app and provide the code that’s inside of that app. That’s something we have because the phone is something we have to carry with us. And this app might also require GPS location during the authentication process to prove that you really are nearby when you’re logging in.
If you didn’t have your phone, you wouldn’t be able to provide the code. And if you were in a different country, you would be providing a different GPS location. We can very broadly refer to these different factors as something you know, something you have, something you are, and somewhere you are. In our example here, the memorized password is something we know. The mobile app and the code that it provides is something we have. The location of where we are is obviously somewhere you are. And if we had to use some type of biometric, such as a fingerprint, that would be something you are.
This is only an example of some of the most popular factors. There are other factors that could be used as well. And combining these together allow us to create a stronger authentication process. These days, it’s very common to see authentication use your email address as one of those authentication factors. If we use that email address during the registration, it’s common to also receive a confirmation email in our inbox. That way, we can click on that message and confirm that the email we provided during registration is associated with an actual email address, and it’s one that we know that we can access.
You might also find that this is the only process used for authentication. We provide our email address. We have to wait to receive an email confirmation. And then by confirming that email message, we’re allowed access into that service. These services might also use that email for additional capabilities. For example, if you need to reset your password or modify information that’s in your profile, they might require the email to be able to confirm that process. This email might also be used later for additional verification.
For example, if we need to change a password or modify part of our profile, it may ask us to confirm that with an email confirmation. In our discussion of multifactor authentication, I described an app on your phone that provides you with a code you need during the login process. This is a very common way to provide a pseudorandom token generation on a device that you carry around with you wherever you go. If you don’t have a mobile phone, you could also use a physical token generator that’s connected to your keychain. Most of us know where our keys might be, and therefore we know where our token generator is located.
Since most of us are carrying our phone around with us anyway, having that token generation on the phone is very convenient. And since we have to authenticate to be able to gain access to the app, it provides another layer of security during the authentication process. Another factor commonly used during authentication is to receive a text message with that code. This is referred to as the Short Message Service, or SMS. During registration, you provide your email address, your password, and also your mobile phone number.
When you log in next time, you provide your username and password. The system is going to send you an SMS message on your phone, and then you would use the code from that SMS message to be able to complete the login process. There are a number of significant security problems with text messaging as a factor of authentication. One of them is that the phone number you’re using on your phone can be reassigned to a different phone.
This is often done with social engineering, where the attacker will contact your phone company and have them move that phone number to the attacker’s phone. This means that the text messages that normally would come to you would be redirected to the attacker. Now the attacker only needs your username and your password, and they can then use your phone number to complete the login process and gain access to your account.
Some authentication systems will call you directly and speak the number to you over the phone. So you might receive a phone call and it says your code is 162517. Then you have to type that in to be able to complete the authentication process. And as you’re already aware, having this type of authentication associated with your phone number creates a number of security problems. Obviously the phone call itself can be redirected. Someone can easily forward your phone to a different number, and now all of your phone calls go to a third-party telephone. This phone number, of course, can also be added to another phone. So instead of you receiving this phone call, the phone call instead goes to the attacker, and they now have the token required to log in.
If you are using some type of token generation program on your phone, you may have one that has a code that changes every 30 seconds or so. We refer to this as a time-based one-time password algorithm. The one-time password is the one that is shown on the screen. And if we add a time-based aspect to this, that number will change after a certain duration of time. This means that even if we’re not using the phone or looking at the app, there is still a change to the code every 30 seconds.
This works by having a secret key that is originally configured both on the phone and the authentication server. By keeping those systems synchronized to the time of day, both sides will know what the code should be at any particular time. So when you log in, you’ll put in your username, you’ll put in your password, and then you will refer to the app to determine what the pseudorandom code should be at that particular time of day.
This is probably one of the more popular forms of one-time password algorithm that you’ll find. So if you’re using the Google Authenticator, it’s using TOTP. The same thing applies to Facebook, Microsoft, and other authentication types as well.
Sometimes synchronizing to the time of day isn’t possible. In that particular case, you may just want to use an OTP option, that is a One-Time Password creation tool. This means that you’ll have an app that provides you with the code, and the next time you log in, you’ll use that code. Once you use that code, you can discard it and then go to the next code in the list that you’ll use for the next login process.
Just like the time-based one-time passwords, the OTP process has a different token every time. Since this is a seemingly random number, it’s effectively impossible to guess what the next set of numbers might be. And just like the time-based systems, there are OTP apps that you can use on your phone and hardware tokens that you can connect to your keychain. Either one of them will work to provide you with a different key each time you log in to that system.