I’ve written before how some periodic reviews provide management with little assurance, but management doesn’t realize how little.
My previous post focused mostly on server access￼. In this post, I want to look at normal user access.
For example, let’s assume your company has a policy that states that all IDs must be assigned within an Active Directory group. In other words, IDs are assigned to groups, and groups are assigned to assets; IDs should not be assigned directly to an asset.
Assume the control you are testing states that user access is reviewed annually.
In my last post, I described Why Internal Auditors Should Care about Robotic Process Automation.
In this post, I’ll explore whether RPA can replace analytic packages like ACL, IDEA, R, and Power BI.
That might seem like a strange question, but a few managers and a VP have asked me just that recently. Here’s how I’ve answered it.
It’s 10 o’clock in the cloud. Do you know where all your user IDs are? Are some hidden in the cloud?
Cloud security if often cloudy because it’s not on premise where you can control it easier.
That means you may have powerful user IDs in the cloud that your security team knows nothing about, which means….
One of my current clients is trying really hard to do periodic access reviews.
They know that mistakes are made in granting access, that users get access and eventually don’t need it anymore, but don’t tell anyone, and that some users leave the company without their manager’s knowledge (I never have understood how that happens, but it does; it has happened in every Fortune 500 company in which I’ve worked).
When checking system access, make sure you look at all the different items that affect the user’s access. For example, the user might need one or more of the following:
- Application ID
- Application role or group
- Membership in an local server group, Active Directory (AD) group, or UNIX Group
- Access to the application’s share and/or folder on the server
- Database ID
- Database role, including access permissions (read/write)
- Other permission (from a home-grown application code or enterprise identify management system)
If you haven’t determined how server virtualization changes your audit plans, you better get moving. I’m not just talking about a virtualization audit (more on that later), but the audits that you typically do every year or on a multi-year cycle.
For example, if every year you do an audit on all networks, servers, applications, and databases that host your key financial reporting or PHI systems, you’re looking at policies and procedures, configuration management, security (including patching), user access, logging, and so on. But do you first consider whether those assets run on virtualized servers?
I found some really pathetic password help pages on a company’s intranet while I was there visiting.
This is a large company that most people would recognize, and it is subject to plenty of government regulations. Overall, I’ve heard the security is pretty tight, but since I’ve never worked there, I can’t speak from experience. Except, that is, the experience I mentioned in an earlier post, Randomly Generate Weak Passwords. Perhaps all their security is what Bruce Schneier likes to call “security theater.”