From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Authentication

From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Start my 1-month free trial Buy for my team

Authentication

“

- [Instructor] If an application contains sensitive or private information, then chances are, you don't want to allow just anyone to access the data within that app. Think of your app like a bank vault and the data like the gold stored within that vault. Before you allow someone to just waltz into the vault, they need to prove to you that they're allowed to be there. The locked door that stands between that person and all that gold is an example of an authentication control. Authentication controls require that users prove they are who they say they are before they're granted access to any sensitive data within the app. You'll likely have additional authorization controls that determine what a user can do once they're logged in, but it's your authentication controls that keep unauthorized users out of your app in the first place. The ability to validate a user's identity and to determine what that user's allowed to access is one of the fundamental controls of not just application security, but of the entire information security practice in general. There's even a dedicated term for this specific practice: identity and access management, or IAM. A lot of folks overlook the notion that IAM is actually two separate disciplines rolled into one. Identity management focuses on identifying all of the system or application accounts tied to a real person. While access management focuses on what that person can do with those accounts. The two disciplines are very closely related, and the activities you perform on one side of that fence will either be influenced by or have an impact on the controls on the other side of the fence. There are three types of IAM events that your app needs to know how to handle. Joiner events indicate when a user's relationship begins with your application. If someone starts a new job, then when they're hired, that activity means that they now need to be able to log in to the apps that they'll be using to do their job. That's a joiner event. Mover events indicate that something has changed, something that might impact what the user can access. Promotions, maternity leaves, paternity leaves, sabbaticals, short-term disability leaves, there's a pretty long list of possible mover events. But leaver events indicate when someone shouldn't be able to access that app anymore. When someone leaves an organization for a higher-paying job at a new company, then their old access at that original company should be turned off. Traditionally, we've controlled access to applications through usernames and passwords. That's made it pretty simple to control who can log in, but unfortunately, attackers have figured out ways to bypass those controls. So we've had to start exploring stronger authentication methods. The term strong authentication refers to additional layers of security in the authentication process. While complex passwords might seem stronger, they're still just passwords. Strong authentication requires something else in addition to passwords. One of the earliest examples of strong authentication was adding a time-sensitive token to the authentication process. Users can only log in if they enter a valid username, password, and secret code, one that changes every few seconds. Since that secret code is always changing, it becomes much harder for users to bypass the log in screen, even if they've already compromised the user's password. Now, you might hear people using the terms two factor and multifactor interchangeably. In truth, they are almost the same. Two factor requires one additional factor of authentication, while multifactor allows for one or more additional factors. In addition to secret tokens, you can use things like digital certificates, location data, even biometrics, when enforcing strong authentication controls. Another authentication control you should be aware of is single sign-on, or SSO. With SSO, a user only needs to log in once. After that, all of the apps a user accesses perform authentication behind the scenes. The user gets a seamless experience without needing to remember multiple sets of credentials. If a user needs to log in to apps that live outside of your organization, you can still perform your IAM tests while simplifying the user experience if you start using federated identity, or federation. Federation functions much like single sign-on, although the back end is more complicated. The user authenticates against an identity provider, an IdP, who is responsible for validating that user's identity. If that validation process is successful, the identity provider then contacts the app, sometimes called a service provider, or an SP, and says, "Yeah, the user checks out. Let him in." Security assertion markup language, or SAML, is popular for a lot of business-to-business app activity. While OpenID has found popularity among consumer-facing applications. We also need to keep in mind OAuth, which is sometimes grouped into this lot, although technically, it's used for authorization instead. When you're selecting the right authentication controls for your app, you'll find yourself constantly balancing security against convenience. Single sign-on sounds great, until an attacker compromises the credentials that allow access to the SSO portal. When that happens, the attacker has access to every app where SSO is enabled, unless, that is, you're requiring strong authentication for that single sign-on process. Your job is to figure out the right mix for each app that you want to secure. By examining your options for authentication controls, you can create the best possible user experience while protecting your apps against possible compromise.

Contents