This chapter begins the section on Identity and Access Management. This chapter, along with the next two, are very intertwined. It’s another occurrence of CompTIA splitting things out in a weird way.
This section is important to security because controlling access to computer systems and resources is a foundational part of security. This chapter talks about proper authentication and authorization, among other topics.
This is a continuation of my blog post series on the CompTIA Security+ exam, where I share my studying and connect it to real-world events.
Identification, Authentication, Authorization and Accounting
One at a time…
Identification is the process of assigning a computer ID to a specific user, computer, network device, or computer process. For security purposes, IDs shouldn’t be shared or descriptive of job function. They must be unique.
Authentication is the process of verifying an identity that has already been established in a computer system. Authorization is the process of permitting or denying access to specific resource. If you want to read more about authentication vs authorization in-depth, here’s a blog post that I wrote about it.
Accounting is the process of “ascribing resource usage by account for the purpose of tracking resource utilization.” It’s also very handy for forensics after a security incident has occurred.
Multifactor Authentication
You’ve probably heard about this, as many online services are pushing people to enable 2FA. Multifactor authentication is the combination of two or more types of authentication. Having multiple factors increases security and decreases risk of unauthorized people gaining access.
Choose from the following:
- Something you are: this refers to biometrics (fingerprints, eye scans, etc.)
- Something you have: security tokens or other items that a user can physically possess.
- Something you know: a password, pincode, or answers to “challenge” questions.
- Something you do: an action you take that you perform uniquely, such as signing your name.
- Somewhere you are: your location, as determined by GPS or other location services.
All of the policies, protocols and practices to manage this identity information across systems, or even across organizations, is called identity federation.
Single sign-on (SSO) is when you can use a set of credentials for authentication between systems. This makes things easier for the user, but if the credentials are compromised, the attack surface is much larger.
When given domains trust each other, authentication for one domain can be trusted by the other domain. If this process is transitive (i.e. A trust B, B trusts C, so A trusts C), then it is called transitive trust. If it is just two parties trusting each other, that’s called (creatively) a two-way trust relationship.
Account Types
There are many different types of accounts, and different ways to manage these individual accounts in larger numbers.
User accounts are needed when accessing a computer system. They should belong to a single person, so as to allow tracking of access and activities. Again, user IDs for these accounts need to be unique. Once a user account is created, permissions are assigned. These permissions determine what a user is allowed to do on a system.
The two exceptions to the uniqueness rule is for shared/generic accounts, and guest accounts. Shared accounts are accounts that are shared among two or more people. This might be a generic account, which has limited functionality (i.e. a browser at a kiosk) where tracking doesn’t buy you anything, and the overhead for individual accounts isn’t worth it. Guest accounts are similar–very limited functionality accounts where it doesn’t make sense to create individual accounts for each short-term visitor.
Service accounts are those that are used to run processes that don’t require human intervention to start, top or administer. A good example is batch jobs.
Privileged accounts have more access than regular user accounts. These are usually root or admin level accounts. They can do a lot of damage, so make sure that these are limited to only the people who should have them, and that you track and audit these accounts regularly.
General Concepts
Account management (also called privilege management) is “the process of restricting a user’s ability to interact with the computer system.” These interactions include “viewing, modifying and deleting data, running applications, starting and stopping processes, and controlling computer resources.”
Least privilege was covered in a previous chapter, but we see it again. It is the idea that privileges should be limited to what a user/app/process needs to perform its tasks, and nothing more.
Onboarding and offboarding are the adding of people to a project, or removing them from a project. We’ll come back to this later with account disablement.
Permission auditing and review… hopefully by now, the book has beat it into your head that you need to regularly audit things. Permissions are one of those things. You need to regularly review that user accounts on a system are needed, justified, and actually represent real, still-employed people. Then audit permissions granted to those people.
Similarly, usage auditing and review is the examination of logs to determine what users have been up to (are these things allowed? should they continue to be allowed?)
Account maintenance is the routine screening of all attributes for an account (can some of this be automated?)
Time-of-day restrictions can be a helpful security measure. Assuming your workers have regular shift hours, this is where the system limits account access or privileges during non-working hours. Location-based policies restrict access or privileges too, but this is based on where the user is when they are accessing a system.
Recertification goes hand-in-hand with audits. This is a process by which you determine if all users are still employed and/or have them re-authenticate themselves. Since the latter happens in-person, this can be a pretty serious disruption.
Standard naming convention… the book starts this off by saying that it’s controversial, then doesn’t really say anything of import. In some places, naming conventions are good–they help clear up confusion among users and allow users to extract meaning from a name. In other places, this is bad, because attackers are extracting meanings from names, too.
Lastly, group-based access control is where you assign privileges and manage users at the group level instead of the user level. This will get covered much more in a future chapter.
Account Policy Enforcement
Access to most systems involves a password of some sort. Your organization should have and enforce policies around passwords.
Credential management is the set of processes, services and software used to store, manage and log the use of user credentials. This can be done through various tools or platforms. The book offers the example of Window’s Group Policy Objects (GPOs) that allow for the enforcement of password rules.
Passwords should be sufficiently complex, as defined by complexity rules. This is a combination of uppercase/lowercase, numbers, and special characters. Yes, you’re right. This isn’t the most up-to-date advice for passwords, but it’s what the Security+ exam wants to hear. You should also make sure that password length is sufficient (and that your policy is enforced). Get dat entropy.
Your organization might also want to consider limitations on password reuse. This means you’ll have to store a password history for each user, and enforce rules about how long each password can be used.
You can set expiration dates on an account. For example, this might be useful for contractors. You’ll need to work hand-in-hand with HR to do this. You should also have a method of account recovery, and, like all other plans, this should be practiced.
If someone leaves the company for some reason, you should disable their account. Why not just delete it? Account removal can “orphan” items that don’t have other forms of ownership. Save removal for later, and for now, just completely disable the account.
Account lockouts are similar, but instead of permanently blocking access to a system, it’s a temporary blocking of access due to login failures, etc. This can be automated.
See you in the next chapter for more identity and access services. : )