When we're talking about users and their clearances or subjects and their clearances, how did they get these permissions? How do they get these privileges? Well, usually somebody is providing a service, provisioning them. Provisioning is much more than just user creation. Provisioning includes creating the account, but it may include much more than creating an account. For a start, there may be many accounts. One for the network, one for a particular Cloud-based system, one for a local application. Maybe a code to unlock a device, an encrypted disk, maybe a code to enter the building. There may be lots of different accounts that need provisioning, but it's not just about accounts, either. We may want, depending on the type of role to undertake, some background check, some kind of check on the individual, some identification processes. Identification is part of the provisioning process and bear in mind when we're looking to ultimately create accounts, should we clone somebody else's account? Let's say we have a user that leaves and somebody else replaces that person, should we just change the name on the account? Well, probably not. To manage the risk appropriately, what's considered best practice is to have a template based on the role's needs. The idea of least privilege and need to know. Why don't we copy existing accounts that are in use? Well, those accounts often get changed. Just think about a user that's worked in an organization for five years. They start with a standard set of privileges, but maybe they move within the organization, they change roles, or maybe they are seconded to work on a project. They're granted extra permissions or privileges, and you see this all the time, this creeping upwards of privileges. If we use that account now as a template of other accounts, we've got a problem. By default, we are giving people too many permissions. A very common problem. When we're talking about provisioning accounts, who do we provision them for? Well, not just users. Typically, our devices authenticate as well. Our devices authenticate services like wireless, allowing us to log on. All of these checks typically are related to our level of confidence that we need, the level of assurance that we need. The process of checking somebody's identity, that they are who they say they are, is known as identity proofing. Just think about when you sign up for a social media account. If you signed up for a social media account about 10 years ago, commonly there were no checks. You could sign up with any name and you'd be given access to the account. These days, we're in 2022 at the time of recording, these days, typically the same social media accounts just want to link your identity to you. How do they do that? Well, they send an email or a text message just to check that there is a real person behind it. But think again, maybe about another type of identity proofing. What if you want a passport or a driving license? There's a high level of assurance, high level of confidence that is required, and so more checks are undertaken. There is a more formal process. Again, this whole management of users is very dependent on our needs as an organization. The level of confidence, the level of checking varies and it should vary. Absolutely, the right thing to do. Identification is part of our identity and access management toolkit, gives us a level of confidence. Once we've identified somebody, we can give them credentials, they can log in. As part of this user life cycle management, we need to think about the other end of the equation. What happens when somebody leaves? Again, it's not just about deleting one account. Usually, we may need to remove them from payroll, we may need to revoke access to physical sites. Usually, these days users have more than one account. It's not always the case, but maybe they have access to multiple accounts. Do we need to terminate any other access? We have usually two ways in which somebody leaves the organization or at least we can group the way somebody leaves an organization into one of two categories. Voluntary or involuntary. Voluntary is, I'm resigning. I would like to leave, please. That's voluntary. Involuntary is where somebody is fired or they're made redundant. They didn't want to resign, they are being forced to leave. Sometimes with this deep provisioning, we have a visibility issue. We may not be aware of all the accounts that that user has access to, maybe a wired wireless codes or access to a Cloud-based systems. Do we always remember which accounts we've created and then subsequently to revoke access to them? Not always. Certainly, I've seen examples when auditing organizations, examples of senior members of the organization who have left and six months later their account is still active. Sometimes being used, sometimes not. Common mistake, common problem. We've talked about people starting, we've talked about people leaving, what about people moving within an organization? This last category is the one typically we do least well. People changing roles, gaining additional privileges, moving within an organization. Do we remember to make sure that the access is corrected? We're not just talking about normal users, we also have some user accounts that have additional privileges and capabilities. We have normal user accounts, which is what we've just been referencing, but we have service accounts. Service accounts don't login. When you run a computer, when you boot a computer up, turn it on, these run. These are service or system accounts. They can run with an identity and so you could create an account, for example, a backup account. A backup account has high levels of access typically, but it doesn't belong to any one individual. Nobody logs in with the backup account ordinarily. It's running as a service on each computer that is being backed up. The operating system itself also has a security context. It runs as system. We have other administrative accounts on Linux or Unix-based systems, we have the idea of the root account. In more Windows type environments, it's very common to see enterprise administrators, domain administrators, and backup accounts. The idea of a domain administrator refers to a security domain, a group of computers logically linked together. Usually an organization will have a security domain. Then you have a single point of administration, set of servers that control everything on that network. You might have multiple security domains within an organization and to manage all of this, we'd have an enterprise administrator. One enterprise may consist of multiple domains. Differentiating identification and authentication. Identification, we want to know who somebody is, who the subject is before we give them credentials to log in. Once we've identified them, then we give them the credentials, then they can login, they can authenticate. Very commonly in the finance world as well, we have another control, segregation of duties. Separating out the different roles. Here we see something that existed long before computers did. To prevent fraud or misuse of funds, organizations have a requester role. You want to buy something, maybe you want to buy a new server, so you place a request. As a requester, you cannot now approve that process. We need multiple people involved. The quest to request and makes the request somebody else objective separate, has to then approve it. In some organizations, many organizations, you may have multiple levels of approval. Maybe for requests under $1,000, you have a single approver. If the threshold, if what you're buying is more than $10,000, for example, maybe one approver can approve up to $1,000, but then it gets escalated up to another approver. I've seen organizations with six or seven approvers where you have requests heading into the millions. It means we've got different levels of checking. No single person can corrupt a process. If that requester is corrupt, well, it doesn't matter the approvers or not. That's the idea. We've got different checkpoints. If we want to cover up the process now, we would need people to work together. We'd need collusion. We'd need to get lots of people to abuse the process together. The more people that are needed to complete a process, the more difficult it is to perpetrate fraud, for example. Again, related to separation of duties, we have the idea of dual controls. Here we need two or more people to initiate a process. My mental image here is always of a missile launch. If you think about Hollywood movies, two people turning a key or two people pushing a button to launch a missile, for example, may sound far fetched, but it's a really easy example of a dual control. Needs two people's judgment, not just one. Again, helps prevent a single person being able to compromise a process. In order to compromise it now, it would require collusion, doesn't prevent collusion. This User Life Cycle Management, we've talked about the provisioning and deprovisioning of accounts. We also want to make sure we have appropriate reviews of our user access. Again, good practice to do this at least annually, to check the permissions that are allocated to make sure that we don't have what we call privileged creep. We've talked about identification, checking who somebody is before we let them have access to an account or two accounts. Once they have access, then they can authenticate. The idea of authentication is that there is a check to make sure that person trying to login is who they say they are. In Chapter 1, we referenced single factor versus multi-factor. Single factor one type of checking, for example, something you know, or something you have or something you are. Multi-factor is where we use two or three of those types together. Usually where we need more assurance. Multi-factor authentication of good use case might be when we're logging in as domain administrator, giving us the extra assurance that that person is who they say they are. Once you've logged in, we said you don't have access to everything and that implies that is a set of decisions. You click on one folder, you are granted access, a decision has been made. You click on another folder, you do not have access, for example. Again, a decision has been made. The ongoing decision-making is performed usually by the operating system and this is what we call authorization. We know who you are. You've logged in, you've proved who you are, you've authenticated. But just because you've authenticated doesn't mean you have access to everything. In fact, we may want to check those authorizations. What you are accessing, that you're entitled to access, and also what you're trying to access that you cannot. This moves us onto the concept of auditing. Auditing is logging, but also checking those logs. Those authorizations successful or unsuccessful have been logged. Let's take a look. Who's been trying to login? Who's been accessing things that they shouldn't or using privileges that they are entitled to, but perhaps in ways that they shouldn't? All of our checking here relates to a level of assurance that we need. We may have different processes for user accounts than we have for privileged accounts, for example.
