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).
I recently ran into some unneighborly security. It happens all the time to those of us who know how to build, upgrade, secure, and troubleshoot hardware and software.
I’m over at my neighbor’s house and he says, “Hey, you work with computers, so can you take a look at mine?”
There goes the afternoon.
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)
IT admins and IT auditors often don’t see eye-to-eye, and they don’t usually think their goals are similar.
The IT auditor just has to work a little harder to convince the IT admin of that. I’ve worn both hats, so I know it can be done.
Filed under Audit, Security
During an audit, I had a vendor provide me with access to data I shouldn’t have, no questions asked. I didn’t ask for the access, I just needed some information for my audit.
The audit involved checking some vendor software to determine whether it is patched by IT on a regular basis. I obtained from IT a screenshot of the version number of software that was installed, but needed to know the last couple of versions released by the vendor. The admin was going to send me the URL because he said I probably wouldn’t find it the info on the vendor’s site. After a couple days of waiting for the URL, I took matters into my own hands and went to the vendor’s website.
A lot of company data is lying around unprotected, making it very easy to steal. No, I’m not talking about picking up other people’s documents at the printer. Stealing printouts isn’t hard, but it can be risky, especially if the printer is a busy one. Besides, it has 2 other problems:
- Your chances of picking up confidential data are low at any given time.
- The person will look for the printout and wonder what happened to it.
There’s a much better way that is fast, easy, simple, raises no suspicion, and is basically impossible to detect, if you do it correctly. Can you think of what it is?
Minutes later, one of the security techs met me at Lynn’s cube with a box that we quickly filled with the contents of her desk: files, CDs, DVDs, notedpads, books, etc. The other help desk analysts in adjacent cubes looked at us with silent questions on their faces.
I noticed that one of them was a new employee that had attended my security presentation in employee orientation last week, so he knew who I was. That meant rumors would spread quickly. While I never enjoyed walkouts, they reminded the staff that security incidents have consequences.
This is a multi-part series. See Internal Attacker Detected: Part 1, Internal Attacker Detected: Part 2, and Internal Attacker Detected: Part 3.
Others on my team had already imaged the old computer and had started imaging the new one across the network as soon as my meeting with Lynn began (by design, she was not told of the meeting beforehand). Both images would be sent off to the Forensics team.