Welcome to Cash in the Cyber Sheets. I'm your host, James Bowers, and together we'll work with business leaders and industry experts to dive into the misunderstood business of cybersecurity and compliance to learn how to start making money from being secure and compliant. Welcome to Cash in the Cyber Sheets.
Hey everyone, welcome to Cash in the Cyber Sheets. I am your host, James Bowers, Chief Security and Compliance Architect here at Input Output. Very excited to have you here with us today. So if you were listening last week, if you're one of the three people, the subscription's going up.
But if you listened to us last week, we talked about the CDK Global data incident, massive, massive incident impacted over 15,000 auto dealerships across the nation. Big deal. And I think they're finally coming up here on July 3rd or 4th.
So it's been like a week that they've been down, about a week and a day or so, a little bit. So we've been doing a lot of audits with our clients because of the incident, because of where they are in their compliance program, their user access reviews and permissions audits. And I thought today would be a good time to go over really kind of the 10 steps that you need to make sure you're doing good user access audits and permission reviews, and also making sure that you have the appropriate logs.
And with these 10 steps, there's four of them that most people trip up on. Two of those, practically nobody has checked and is always out of compliance somewhere. And those two could end up costing you a lot more during a data incident.
And it can also get you into regulatory hot water. So really, really important to get all of these, and we're going to go over them. And we're also going to have good downloads, a nice infographic and some options for some worksheets and checklists.
So I'll get all that in the description. But other big news before we move on to all of that is we've been talking about going to Apple podcast, Spotify and subscribing. But if you try to do that, we weren't actually there.
It was a long, hard process, but we finally got it set up. So we are now streaming on Apple podcast. We're now on Spotify and we're starting to add a lot of other locations as well.
So please, please, please go wherever you're listening to us. YouTube, Apple, Spotify, please click that subscribe, that follow button. That way you can get all the updates.
You can keep getting news about us. And I say it every week. If there's something you want to hear about, please just write into us.
Let us know. I'm more than happy to cover any topics that that you'd like us to jump into. So with that said, let's jump into our compliance audit and user access reviews.
Now, as a, as a quick primer, what you should be doing at least annually is going through all of your systems and making sure that the users in there, the people that have access are one, the right people that should have access and two, that they have the right permissions. And typically where this gets fouled up and what you're looking for is one, if you have a, an employee that left, they left it, didn't get the notice, or it just didn't propagate to all the systems. So now we've got a, a previous employee that still has access to some, some systems.
Another, another thing that we're looking for is to make sure there aren't any inappropriate accounts. So did somebody break into our system and set up some accounts that we don't recognize? And if so, we want to make sure to dive into that. And that's a really important piece of a lot of regulatory requirements, specifically HIPAA.
They want you to annually at least review those user access lists, review the audit logs, make sure you have everything in place. So it typically, depending on the company, depending on the platform, you probably want to do your user access reviews a little bit more frequently than annually, but at least once a year, you want to go through everything. And what I typically find when we're, when we're doing an audit, when we're reviewing what a client's done, when we're helping them get ready for a certification like ISO 27001 or a SOC 2, when we look at their user access reviews, a lot of times it's just IT pulling up a list of the users and just, just reading those right from the list that they printed to, to validate if those are correct or not.
And with some systems that could be okay, especially if it's a system that doesn't have a whole lot of users. But if we're looking at say our active directory, it's not a good practice just to, just to look at the list that's on the system. You need something to validate it against.
So one of the things that we're, that we're going to go over is making sure that you're comparing that against what HR has and pulling in those other departments in the, in the company, whether that's department managers, whether that's HR, whoever. You need to pull into, but making sure that basically you're validating, Hey, here's what we have. What do you think we should have in matching that up? So we'll go through, I guess maybe the best way here is I'll go ahead and just quickly review the 10 different steps and we'll dive into a little bit of those each.
So number one, we want to identify all of our system. This thing is, it's bugging me like crazy. Let's try that.
It looks bad there, but I can stop playing with it. So we need to identify all of our systems that have sensitive data that can be like PHI, that could be PII, personally identifiable information, PHI being a protected health information on the HIPAA side. It could be a PCI card data or like credit cards, financial data, any of that sensitive data that, that we don't want getting out.
We want to identify every system that processes that stores it and transmits it. Those are going to be very important. And if we, if we don't look at any other systems, we need to make sure that we review those users and their permissions.
At least annually, we talked about this, but comparing the active users against HR records, again, a lot of audits that we see, it's just somebody printing out the current user list and just reading through it and seeing if they recognize anything out of the ordinary, which like we talked about before, typically isn't the best practice because you could miss things. And let's say, for instance, you didn't get the notification before that John Doe left, Bob isn't with the company anymore. You're not going to recognize it when you're just looking at that list.
So you need to match that up to HR. We also want to review user permissions. One, this is just making sure that, Hey, if somebody changed roles, have they got their appropriate permissions? We'll dive into a little bit of that because it's, there's some nuances there and definitely some things to look at.
We want to also identify the number of active administrators in each of the systems. On top of that, that was a long pause. On top of that, we want to confirm that we have break glass access for accounts, which is really kind of the same thing.
And what we'll do is we'll actually dive into that because that's an area that practically nobody looks at and it can seriously, seriously save your bacon if things go sideways. We want to confirm for each of the systems that the password requirements are set up appropriately based on our policy requirements and also that MFA setup based on our policy. And if it's not, we want to make sure to document it.
We need to confirm access to the logs. So this is an area that we'll dive into. And this is one that about, I would say easily 90% of the time is overlooked, but we need to make sure that each of the systems that we're looking at, that they're, that they're getting the correct logs for the system, for that system that meets our compliance requirements.
We also want to ensure that our logs are being retained appropriately to our retention schedule, to compliance requirements. And here's one too, that, that we'll dive into a, where, where people really stub their toe with it and it, you can actually go a little bit too far with it, which can get you into trouble. So there's a kind of a Goldilocks just right kind of, kind of spot for that.
And then finally document everything that you do, review any discrepancies. And I mean, that's, that's part of any audit. So going through the first one, I think it kind of speaks for itself.
Number one, identifying the systems with sensitive data. Do that as part of your data, data flow. And we've talked about this a little bit in other episodes.
And I think what we'll do is actually set up a deep dive into designing a data flow or in a network diagram that we can then turn into a threat model and use for risk assessments, but really just draw out all the different systems that you have, how the data moves between them, who accesses those and identify the ones that have sensitive data. What we typically do is we color code on ours and we color code those red. So we know if we see any red on our data model, on our data flow diagrams, we need to make sure everything is tightened up on those and we should probably be doing user access reviews more than annually.
Cause if to the annual part, if we've got a system, say like Microsoft active directory, uh, Microsoft 365, uh, our, our primary system where we store all of our data, we probably want to review that at least semi-annually if not quarterly or more, uh, depending on how sensitive that data is, if it's something like in this isn't a, this isn't a stab, but something like Canva that it's just putting together marketing materials that if we checked that annually, as long as we don't have any sensitive data in there, that's probably okay. Worst that could happen is somebody could get some of our marketing materials that haven't gone public yet, eventually they probably will anyway. Uh, or they could use our platform and we're paying user costs that we shouldn't be doing, uh, in the scheme of things, that's pretty small potatoes.
So if you're looking somewhere to cut responsibilities and cut some of the requirements, that's a good place to do it. At least do it annually, but still a good place to do it. Now, when you do the audit, very, very important.
You need to include all the relevant parties. And that seems like pretty good, uh, legal speak or probably more like political speak. I'm saying stuff without actually saying anything, but what I mean by that is the easiest way is just get a list from HR.
Hey, who are all of the active employees and what are their current roles? And then as you go through your systems, just match that up. Typically when we go through, go through an audit with a, with one of our clients, we normally find at least one or two little discrepancies in there. So it's always a good thing to do.
What you can also do is this doesn't just need to fall all on it. If there's other admins for systems or there's other say department managers that run a system, these responsibilities can go over to them as the owner of that system to do the user access reviews still needs to go by all the same requirements still needs to hit all of the same boxes, but it doesn't need to fall all on one person. And if you distribute these amongst quite a few different individuals, quite a different owners in the company, it can go a lot faster.
And when I say owners, I don't mean who owns the company, but the owners of a security control or the owners of the system, the ones that are in charge of it. So when we're, when we're comparing against the HR records, we also need to make sure we're reviewing the user permissions and what can happen here is a lot of times what we see is what we call scope creep or permissions creep or privilege creep. And that just means that say I started in a lower position or more of an entry level position, and then I get promoted and then I get promoted again.
Then let's say I moved departments. Well, as I'm moving into all those different areas, as I'm moving into those new departments, I'm getting my access elevated so that I can do all the responsibilities in that new role. But I don't necessarily always have all of my access revoked that I don't need.
So that's where it just kind of creeps. You continue to get more privileges and where this can really be an issue and it can seriously trip you up in an audit is one. If this isn't being managed properly, it shows that you're onboarding, offboarding, and, and or change request process isn't very tight.
And for practically every regulatory standard out there, every compliance standard, that's a pretty big deal. And that can also then just kind of cascade into other issues to where now you're violating segregation of duties, because let's say before I was in purchasing and now I'm moving over to finance, well, in purchasing, I may have had the permissions to make requests. In finance, I may now have the privileges to approve and typically those are separated, but because I had that privilege creep, I had that privilege creep, I'm now able to make requests and approve those requests.
So that, that completely bombs segregation of duties, kind of two eyes on everything. And that's just right there, easily four different controls that you could get hit in during a compliance audit, that you could get hit in during a certification audit, and with that being such a major issue, in some cases that could even keep you from getting a certification, or it could lead to perhaps a regulatory fine. So very, very important to look at users permissions and make sure that they're all, all correct.
What's really going to help here too, is having a reliable permissions structure, like RBAC, role-based access control. And basically what that is, is saying this role has these permissions, this role has these permissions. And rather than managing people's privileges based on each individual user, you're doing it based on the roles or based on departments.
So that way, when you move them, those automatically apply, or at least they should. And sometimes you don't have the systems that can automatically update all of the permissions. That's perfectly okay.
You can still use RBAC principles and just create a checklist. Hey, if somebody's in this position, they need all of these different permissions. Great.
When we move them, we'll just go down the list, check them off, make sure they're all there. So you don't need to have expensive systems to manage these. It can very much be even just paper and pencil, just standard old checklist.
Next thing we want to do, step number four, is we actually want to document how many administrators we have in a system. And this is another Goldilocks moment. We don't want to have too many admins because that's just increasing our attack vector.
It's just more admins or more people with full control. It's more people that could get compromised and more, more people's accounts that could lead to a data incident, which we definitely want to avoid. However, we want to make sure we have enough administrators to where if something happens to one, we're not completely losing access to our systems, to everything.
So typically you need to have with every system, at least two administrators. And whether that's a primary and just a backup, that's perfectly okay, but you want to have at least two administrators. And if you can, you can't always do this, but if you can, you want to limit their ability to remove the other administrator and perhaps have that, it's like a top level admin access or, or some, some different type of a lockdown that you can use.
Now, once we identify the number of active admins, you know what? I don't want to go on just yet because there is one more thing there, and this relates to the permissions, but we also just want to make sure that there's no users that are now an admin that shouldn't be. And that can be very indicative of somebody that started elevating their privileges. Maybe a bad actor has gotten into the system and now they just continue to add more, more access to the role so that they can continue to, to move throughout the organization.
So we want to be real careful with those admin accounts. Now, step five, this is one that a lot of companies overlook, and it's one that company, they, clients and companies argue with me about it all the time saying it's not going to be an issue. And lo and behold, it turns into an issue and it's not a small one.
It's major making sure you have what we call a break glass account or break, break glass access. And a lot of times what that is, is it administrative account where you store the password somewhere secure, like a safe and nobody uses that account. That account is only used.
If all of the other ones can't get you into the system, or if you're having some sort of global problem. And this is where, if it's a primary system, if you can, you want to make the break glass an administrator that can manage users, but is also one that can't be deleted or if they can be, can be deleted. This will go into log in a little bit, making sure that you get alerts that if that user logs in, bells are going off, everybody's getting an email about it because that account should never be used except for in case of emergency, just like a break in the glass of a, to get to a fire extinguisher or the fire alarm, same exact thing.
So we want to make sure that we have those for every account. And when you're setting that up, we want to make sure that we've got all the password requirements appropriately set. We want to make sure that we consider any password expiration.
We want to make sure we consider any multi-factor or IP restrictions for login. We want to make sure we review all the different types of restrictions on users to make sure that when we actually go to use this account, it hasn't say gone dormant or it hasn't been closed for inactivity or the password isn't correct. And now it's not letting us in.
It's very, very important that we make sure that these work. And typically during a user access audit is we'll actually attempt to log in to that break glass admin to confirm that it's working, to confirm everything's right. And that will typically mean that we've got to reset the password and then store that securely again.
But I've seen people lose access to their Microsoft environments and it take upwards of two months to regain access. Two months without access to your Microsoft systems is major. Uh, that, I mean, for some companies, they wouldn't be able to operate.
So it's very, very important that you have this break glass access. Also for, for Microsoft accounts and a lot of other accounts, if you purchase those through a distributor, uh, like a, an it partner or a reseller, somebody that has, um, a wholesaler account through say like Ingram micro or Pax eight, they actually get access as a tenant admin to manage those licenses. But it also allows them to get in.
So I've also, uh, I've seen that used as the backup access. That's perfectly okay. I also recommend that because you always have kind of that, uh, that, that break glass account is going to say, uh, oh shit handle.
Uh, but there it is. Um, you have, you have that, that fallback and if you need technical support, those wholesalers can put more weight. On the Microsoft support team, then you can, and they typically have some direct contacts.
So what may take you weeks may only take them an hour or a day or so. So there may be reasons that you don't set that up, but I do recommend that you, uh, at least consider that there's pros and cons to everything. So our next step is we want to confirm each of the systems that we're using.
Adhere to our password requirements. Those should be identified in our policy. If you don't have a policy for that, we're more than happy to help you with it, but you should have a policy that States what your minimum password requirements are, and you need to make sure that each system is adhering to that, your password requirements and your multi-factor authentication requirements.
And when you start going through and checking each of the password requirements that you have in your policy, you're probably going to find at least like 20% of your platforms don't support them all in, depending on the platform, that's okay. That's perfectly okay. You can do a risk assessment there and say, you know, we're fine with this.
Um, or maybe our password's a little bit shorter than we typically want it, but we have multi-factor so, so we're fine. We, we accept that risk. And as long as you document that to show that, yes, we've identified this.
It's not a surprise to us. We identified it. We reviewed it.
We accepted it. That's typically okay. As long as your reasoning's good, it's typically okay for any type of regulatory or compliance audit within reason.
Um, you can't just accept all risks, but for the most part, if you can make a good argument as to why you made that decision, most regulations and compliance standards are going to be okay with that because not every platform can support everything. However, if it's a platform that is hosting sensitive data, PHI, PII, uh, PCI card data, you don't have as much wiggle room there. So you want to make sure that your requirements at least meet those regulatory requirements and that they match your password requirements.
So MFA is a major, major thing, uh, multi-factor authentication, two-factor authentication. We want to make sure that we have that enabled on every platform that supports it, but we also want to make sure that we've got backup codes or backup access. Now, sometimes there's not a way to get any type of MFA backup code or backup access.
That's okay. That just falls back to those break glass accounts. We have another account that we can get into, and here's something to consider.
Make sure that you don't create a situation where the authenticator on a single device on your phone perhaps is a single point of failure. A lot of times we have all of these different accounts and we've got our primary account, our break glass account on the same authenticator on our phone. Well, if we lose, if we lose that phone or that authenticate authenticator app hiccups, we're up the creek because now we can't get into any of the accounts.
So when you're setting up the MFA, especially for those break glass accounts, make sure that the MFA is on a different system, different platform. Make sure you're not creating a single point of failure. Now the next two, uh, go into logging requirements and practically every regulatory standard out there has some sort of logging requirements from a HIPAA perspective.
They want to make sure that you're identifying appropriate logs for, well, let's just read exactly what they say. So right from H HHS, um, health and human services, um, which supports, which supports HIPAA, uh, the HIPAA security rule does not identify what information should be collected from an audit log or trail or how often the audit reports should be reviewed. Well, that's super helpful.
Thanks for that. When determining reasonable and appropriate audit controls, business associates and entities must consider their risk analysis results, organizational factors, current technological infrastructure, hardware and software security capabilities. All right.
So kind of like before, that's a lot of a political speak of, you need to make sure you're doing the right thing. Um, and that right thing should be appropriate. So helpful, but here's the typical things that we're looking for and we'll tie these into the incident response.
So primary things we want to look for are successful and unsuccessful login attempts. We want to look at, uh, we want to make sure the date and time for each of those is identified when somebody logs in, when they log out, we want to identify where they're connecting from. So typically that's the IP address.
If we can, we want to identify the device, uh, not super critical though. And we also want to be able to identify what that user accessed and what they changed. So, uh, what did they read? What did they write? What did they create? What did they modify and what did they delete? We want to know all those different things for each folder or file.
And here's why that's important for a few reasons. One on the HIPAA side, that's, that's definitely going to satisfy those requirements. If we have those, if we have a data incident, we need to be able to show what users were logged in at what time and what those users were accessing and doing.
And from a regulatory side, they want to know who was impacted from a business perspective side, more so than just knowing who was affected, we want to know who wasn't affected. So if I can show with my logs that, okay, bad actor, a signed in at this time, they only mucked around in these drives and these folders, none of those folders had any client information. And we've done a forensic analysis and we've looked at all of our other logs and we can show they never signed into there.
They never accessed those systems. Those are completely safe. What that does is now I don't need to report to all of those, all of our clients, all of our patients, all of the people that, that we maintain data for because they weren't impacted, they weren't affected.
So that can take what, if I can't show that I've got to assume everybody was impacted, which would, could turn into a major reporting issue. It can turn it into a non-existent issue, more of just an internal kind of an internal oops, internal egg on the face. Let's make sure we tighten things up.
And we skated by on the regulatory side. They're looking to make sure we're able to identify how, how people that were maintaining their data, how they were affected. So it's very important that we confirm on each of the systems that we work with, especially those with sensitive data, that they're getting those logs.
The login, logout, date and times, successful, unsuccessful attempts, IP addresses, and what folders and files were accessed and how they were modified. We want to make sure that we're identifying that and we want to make sure that we have access to those files. This is where in a lot of audits, when we're looking, there's no evidence to show that this was ever reviewed.
You can take a quick snapshot, throw it in your access review folder, wherever you're keeping your evidence. But we typically don't have any evidence, evidence that this is done. And that's typically because it's not being done.
And when we actually look, they don't have any other logs. And that's a major issue because if you have a data breach, OCR, office of civil rights comes in for HIPAA, and you don't have those logs, that's a HIPAA violation that could result in major, major fines. And in certain cases, like with FTC safeguards rules, it goes sideways enough that could even be prison time.
So it's very important to make sure that yes, you actually do have the logs that you do have access to. And why the user access reviews are so important is not all of your systems are going to have all of this information. So you'll want to document that, perform your risk analysis and show that here's the level of risk and here's what's appropriate for this system.
And that's where it ties into what HIPAA was saying in their double speak, political speak, appropriate log access. It ties back to your risk assessment. And if it, if what you're saying actually makes sense, think about it like trying to argue in a courtroom, if you have a case, that works.
So the next one is actually making sure that, that we've got all those logs, but that they're being retained according to our retention requirements. Something like HIPAA requires at least six years since last use. So here's another area that most companies get nailed because most platforms are only securing those logs for 30 days.
Maybe 90 days, even within Microsoft. A lot of times administrators and users assume that they, that they're maintaining all of those logs. If it's not set up correctly, they're not.
So part of your user access reviews should include the log audits. You're already in there in the systems. Make sure you have access.
And here's something else that's important. We want to also make sure in our policies and our retention requirements, wherever we identify those, that we're specific about the type of logs. If you just list logs and that we're going to keep those for seven years, according to your policy, that's every log that is created and that's, that's not possible.
For each, that would mean that for each windows computer, for each Mac computer, I need to maintain every single log on those systems for each network device, I need to do that. It's not feasible. So make sure you identify what type of logs you need to retain.
And that could be as easy as saying user access logs, application logs, um, maybe basic system logs. Get granular if you can, but a little bit of extra work here in the retention schedule and making sure that that's tightened up appropriately will go a long way to helping to protect you during an, during an audit because I've seen, I've seen during certification audits, companies get nailed on this and, um, kudos to the, to the auditor. It's a, it's a pretty good find.
So the final one is, it goes without saying, but make sure you document the review and review any discrepancies. So we're going to identify everything that we did. We're going to store that away so we can show somebody, um, our, our access logs.
If, uh, we can show some, Jesus, we can show somebody that we did those user access audits, uh, to support all of our compliance requirements. So that goes over the 10 different steps, making sure you do a successful and compliant user access audit. And again, number one, identify all of your systems with sensitive data.
Number two, compare active users against HR records. Number three, review everybody's permissions against the roles and against the permissions they should have. Number four, identify the number of admins you have.
Make sure those are correct. Number five, make sure you have that break glass access. The, uh, the uh-oh access.
Step six, confirm the password and MFA requirements actually meet your policy and regulatory requirements. And then eight, make sure that the systems are, uh, maintaining the appropriate logs, make sure that you have access to those and related to that. Step nine, make sure they're being retained according to your compliance and policy requirements.
And finally, with all audits, document, review discrepancies and, and addresses needed. So in the description, we'll have all of these nice little infographic. Just, just helps you go through the list real quick.
We'll also have a link to there, to one of our, um, audit worksheets. It has this information broken down so you can list the system. You can list who's doing the audit, any notes in there.
Quickly identify any discrepancies and then what you're going to do all in one spot, it's designed to have all of the evidence, all of the risk assessment, everything built right into the one sheet. So we'll also have that, um, available for, for purchase through the, through the links as well. Um, but that, that's our, that's our 10 steps for user access audits.
So make sure that you're doing these, make sure that you're at least doing them annually. Go through these steps. It, it can be a little bit annoying, making sure that you've got the break glass, setting up the MFA, splitting those things up, but I guarantee you when things go sideways, you'll be happy you did because rather than spending, say two months trying to regain access to your accounts, you'll just be able to log in with that, uh, those backup accounts.
Or if you're having an audit or an incident, you'll be able to show that you have the logs to, to protect you in the company. So that concludes our time for today, trying to get these to where they're a little bit shorter, a little bit more concise. So I think we did a good job today, but thanks again for listening to cash in the cyber sheets.
Please don't forget. Jump into those, uh, Apple, Apple podcast, Spotify, YouTube, click the subscribe, leave us some comments. Let us know what you want to hear about more than happy to have those.
We'll see you next Thursday, next week, same time, 10 a.m. Thanks for listening. Talk to you again soon.
