CompTIA CYSA+ CS0-002 – Identity and Access Management Solutions Part 3

7. IAM Auditing (OBJ 2.1)

IAM auditing. In this lesson, we’re going to talk about auditing and monitoring and logging. First, let’s talk about IAM auditing, because I am auditing is necessary for us to use if we want to detect compromises of legitimate accounts, any kind of rogue account use or an insider threat. The idea with IAM auditing is to look through our systems to see if there’s anything bad happening. And one of the best ways to do that is by monitoring and logging. Now, one of the most key logs we’re going to be looking at is our audit logs. Audit logs contain a log of all file access and authentications within a network based operating system, an application, or a service. As we go through our audit logs, we’re going to be accounting for all of our user actions. As we look through that and we see which users did which things.

Were they supposed to be able to do those things and why were they doing those things. As we look through that, we can figure that out. That would help us determine if there was some rogue account use going on. Also, we’re going to use this to detect intrusions or attempted intrusions. For instance, if I look in there and I see that somebody tried logging into the same account multiple times and failed, that could be an indication that somebody’s trying to break into that account. That would be an attempted intrusion, or it’s an indication that somebody just forgot their password. Now, again, we’re going to have to look at these and make the intelligent guess based on what we’re seeing. If I look through my audit logs and I see that somebody tried logging in with a and then AA, and then AB and then AC, what does that look like to you? To me, it looks like a brute force logging attempt.

And so I would want to go and look at that, turn that access off, and then go into a further investigation. Now, one of the things we have to worry about here is logging. And logging can be a really good thing, but it can also be a really dangerous thing for us. Now, why would logging be dangerous? Because we can become buried in logs. Obviously, the more events that are logged, the more difficult it’s going to be for us to analyze and interpret those logs. Therefore, it’s important for us as cybersecurity analysts for us to choose what to log and how much to log, and we have to do this carefully. The other challenge with logs is that they get overwritten when logs reach their maximum allocated file size, they’re going to actually start overwriting the older logs. So you need to make sure that you have a way to back up those logs and be able to look at them in the future.

For example, we talked earlier about intrusions. How long does it take before the average intrusion is found? Over half of the time it took months. So if you have logs that are being overwritten every seven days, you’ll never be able to find it. So you need to be able to think about that as well as you think about your maximum allocable sizes or if you’re going to offload those logs to another system where you can store them for longer. Another thing you have to think about when you’re storing these logs is how are you going to keep them secure? Are you going to encrypt them, are you going to make sure there’s confidentiality to them and are you going to hash them to make sure there’s integrity? You want to make sure that these logs aren’t being modified because an attacker, when they break into your system, one of the things they want to do is cover their tracks and they will do that by modifying your logs.

Now, when you start determining what to log, this can be a challenge for a lot of security personnel. Most people just say I’m going to log everything, but that can be gigabytes of information every hour or every day and you might not have enough data to store it all on your system. So you have to think about what you want to store. Now, to figure this out, you should take a look at the audit policy recommendations. This is a document on Microsoft’s website and it’ll give you some recommendations on how they say you should configure your audit policy. Some typical categories that are covered underneath these recommendations are things like the account log on and management events, and how many of those you should be capturing.

The process creation, the object access, things like file systems and file shares, things like changes to your audit policy or changes to system security and integrity. Like for instance, if somebody turns on or off a firewall, on or off an antivirus and things like that. All of these are things you should consider as you’re determining what to log because these are some of the big rocks. Now, if you want to configure all of this, again, you can refer to that Microsoft document but essentially you’re going to go into your group policy object and you’re going to go in there and configure these things, either enable them or disable them based on how much you want to log and what you want to log. Now again, the reason logging is so important is because it is the primary method we use to uncover account access violations.

This is known as a log review. We’re going to go through and look at these logs. If you’re logging everything but you never look at the logs, they’re worthless to you. Logs are only good if you open them up and actually look at them. Now, what are you going to be looking for in this log review? Well, multiple consecutive authentication failures. That’s a good indication that somebody is trying to break into your network. You might look for unscheduled changes to a system’s configuration that might tell you that they’re infected with malware. You might look at sequencing errors or gaps in logs. This can tell you you have a modification problem. Somebody might have broken into your system and deleted some of the logs, or they modified the logs. All of these are things you have to worry about.

Now, another thing you need to worry about is doing a manual review. Now a manual review helps you look at your user accounts and make sure they actually have the right permissions. Why do you need to do this? Well, because in every company, people get hired and people get fired. And as people are hired, they’re given permissions. When they’re fired, they should be losing permissions. And if they move even jobs within the company, they should have different permission levels based on the job they have. So doing a manual review will make sure that those permissions are accurate for those users. This is an important thing and another reason why we like to put people in and out of groups to give them permission. As opposed to giving people permissions directly on different file shares or different services.

It’s easier to take them and remove them from groups than it is to find every single place that they have been given permission. So keep that in mind and try to use role based authentication as you set up your systems. Now, the other thing we’re going to do is a recertification. And this is part of our manual review. A recertification essentially, is a manual review of all the accounts, the permissions, the configurations and the clearance levels. And you’ll do this at a given interval that might be monthly, quarterly, every six months, every year, every five years. I don’t care what it is, that’s for you and your organization to determine based on your risk appetite. In my organization we do this once a year. Now, it’s a pretty long time for most organizations, but we have a small staff and we don’t have people hiring and firing very commonly. So for us, a recertification isn’t something that takes a big priority based on our risk appetite and our risk posture.

8. Conduct and Use Policies (OBJ 5.3)

Conduct and use policies. In this lesson, we’re going to do a quick review of conduct and use policies. Now this should be a very quick review because you’ve covered all this in your security plus studies. When we talk about security policies, these security policies can be used to do lots of different things. And one of them is to direct the behavior of your end users. And that’s really what we’re going to focus on here in our conduct and use policies. Now, there are three main types types of conducting use policies we’re going to cover. These include code of Conduct, the Privileged User Agreement, and the Acceptable Use Policy. First, let’s talk about a code of Conduct. Now, a code of conduct is a defined set of rules, ethics and expectations for employees in a particular job role.

So if I’m going to hire somebody as a system administrator, there’s a code of conduct that should go along with that. For instance, as a system administrator, I have the technical ability to log in and look at anybody’s files on the network. Should I do that? Of course not. That would be against the code of conduct. Essentially another way of saying this is it goes against my ethics. And so you might have a formal written document that says these are the things that you’re going to be allowed and these are the things you’re not allowed to do. And that goes into that code of conduct of telling people what their ethics should be for that particular position. Another thing we might look at is a privileged User Agreement.

Now, this essentially can be a contract with terms stating that a code of conduct for certain employees is assigned based on their higher level permissions on the network and data systems. As I just mentioned, as a system administrator, I can log in and look at your email if you’re on my network. Well, I shouldn’t do that. And so we’re going to have a contract with you that says you shouldn’t do that. And if we find out you are doing that, we’re going to fire you. Right? This is a big deal. And so we want to make sure we have a privileged User agreement. This privileged User Agreement is for all system administrators on a given network. Now the other one we have is what’s known as an Acceptable Use Policy, or AUP. And this is one that’s given to all the users on the network.

This is a policy that governs the employees use of company equipment and internet services. For example, what things might be in an AUP? Well, this document which we give to all employees is going to specify certain things. For instance, at one of the large organizations I used to work at, they had things in there like, you can’t go to Ebay because you shouldn’t be buying and selling things on company time. You shouldn’t be going to porn sites. You shouldn’t be going to gambling sites. You shouldn’t be going to Facebook because we want you working and not on social media all day.

And so all these are different things that you can put in your acceptable use policy. Now, are these transferable to every organization? Well, no. Some organizations are going to allow certain things. For instance, my employees are allowed to be on Facebook. Why? Because we have a study group there and we want to be able to support you. So during the day, I expect my employees to be on Facebook because I want them on Facebook so that when you put up a question, they can see it and they can help you. That’s the idea of an acceptable use policy. For us, Facebook is acceptable, but I don’t want them sitting there gambling all day. I want them doing their job right now.

On the other hand, if you work for a porn company, then looking at porn as part of your job, that might be acceptable. If you work for Google as one of the people who tries to curate what is safe search and not, you might come across a lot of porn in your job and that’s okay under your acceptable use. It just depends what your company puts as part of its values and what they want to allow. So again, there is no one size fits all answer here. But on the exam, if you start seeing things that talk about what employees are and aren’t allowed to do with company equipment and internet services, that is the idea of an acceptable use policy. So choose that answer and you’ll do fine.

9. Account and Permissions Audits (OBJ 2.1)

Permissions Audits. In this lesson, I’m going to show you how we perform Account and Permission audits. And we’re going to jump into the lab environment to do this. As I do this, we’re going to be using one of my Windows domain controllers that I built in my lab. The first thing we’re going to do is we’re going to open up the server manager. Once we’re inside the server manager, we’re going to go into the active Directory users and computers. From here we’re going to expand the Corp Five one Five support. com domain and select the Audit Ou container. Now in this example, what I’m going to do is pretend that my company is being audited. So I’m going to have several people who are going to come in to perform an audit. These are going to be people like Anthony Stevens, Catherine Ruez, Douglas Price, Irene Taylor and Luke Picard. All of them should have received a user account and then placed in the Audit Ou container.

Now when I look here, I only see that four of those people are there. I’m missing Anthony Stevens. So we’re going to want to go ahead and find Anthony Stevens and put him in this Ou and then verify he has the right permissions to do this. We’re going to right click on corp five one five support and select Find. From here we can type in the user’s name Anthony Stevens and click Find. Now once we find him in the search results, we can rightclick that account, select Move and select the appropriate container. In this case Audit Ou and click OK. At this point we can close the Find dialog box. Now we don’t see his name in this pane yet. That’s because we haven’t refreshed it. So let’s right click in the pane and select Refresh. Now we see Anthony Stevens. Let’s go ahead and verify his permissions are correct.

We’ll right click on Anthony Stevens and click on Properties. Once we’re in Properties, we’re going to select the Account tab here under Account Options. We want to verify that the user must change password at Next logon is selected because we gave him a temporary password of password for him to log in the first time. And then we want to select the Password Never Expires option and ensure it’s unchecked. That way he has to change his passwords in accordance with our policies. Now let’s go ahead and take a look at our Log on Hours. Go ahead and click on Log on Hours. And from here we can see that this user is not able to access his accounts on the weekends. Now this table is going to show us a 24 hours day and any white cells are deny access and any blue cells means allow access. Because he’s going to be working Monday through Friday, he should only be able to use it during those working hours and not during the weekends.

So at this point we’re going to go ahead and click Cancel, and then we’re going to click Log on to button. In the Log on Workstations dialog box, we can verify that he’s only able to log on to Audit Alpha computer. This means that this auditor has one machine he’s assigned to, and this can help us verify, since we’re giving auditors special permissions, that they can’t do it on any other systems, or if their account is compromised, they can minimize the damage. From here, let’s take a look at the member of tab to see what groups Anthony Stevens belongs to. Now, as we look at this, is there anything that looks abnormal? Well, yeah, it shows that he’s a domain admin. That is a big security risk. So we want to go into the domain admin, click on that in the member of list, and then remove it.

At this point, we’ll confirm it by saying yes, and then we can click the Add button and select the right group for him, which in our case is SEC Glo Audit, which is going to be for our auditors who are performing their audits here this week. Now, at this point, Anthony’s account is all good. We’ve looked through the permissions, we’ve checked the log on times, and we made sure he’s member of the right groups. And now we would go through and do the same thing for Catherine, Douglas, Irene, and Luke. Once we’re done looking through all of their accounts, we can then move on to our next section. And our next thing we’re going to look at is any other IAM issues we may have. One of the big ones is making sure that we go through our accounts and make sure that any accounts on the domain are cleaned up according to our policy.

For example, we might want to go into the users container and then select View Filter Options. From here we can select the following types of objects radio button and check Users and hit OK. Now we can see all the users on this system. For example, here in the users, you can see two accounts that are actually not supposed to be there. For example, you see the guest account. You should right click on this and disable that because it could be used by attackers the other way. One I like to disable is administrator. Instead of using the administrator account, using the word administrator, you should select something that isn’t as easily guessed by an attacker. Since the administrator account is a default built in account on all Windows systems, attackers know to look for it. So instead, you should create another administrator account that’s not named administrator and then disable the administrator account.

• Category: Uncategorized