At a company I worked at recently, I ran across a Sharepoint site and wondered whether I could download data that I wasn’t supposed to see.
Now I understand the purpose of SharePoint and company intranets is to share data, but even then, some data should be restricted to a limited number of people.
So I decided to check (before doing things like this, you better know How to Stay Out of Jail).
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….
Most of the team deployed to the 2 departments and started emptying wastebaskets in the ‘wastebasket audit‘ exercise, collecting all the trash in large carts on wheels.
Two others were posted as look-outs in the main hallways outside the target department.
I carried my black bag of tools and approached THE door.
I pulled out my favorite flat-head screwdriver. Originally, I was going to remove the closing arm at the top of the door and then pry the hinge pins out of the hinges.
This is the fifth and final post in a series. See the previous post, Behind Locked Doors: Part 4. Start with Behind Locked Doors: Part 1.
I had to get that database fast.
After a long security team meeting, garnished with lots of pepperoni and green olive pizza, we divided the staff into 2 teams. Team A started scanning and probing the target department’s servers in search of vulnerabilities that would provide us with admin access over the network.
Team B started planning a physical intrusion in case Team A failed.
After a couple hours, I was notified that the vulnerability team came up short. None of the identified vulnerabilities could be used to escalate our permissions.
A member of the physical intrusion team called maintenance and requested help from a specific maintenance guy: Zeke. The security team member said that we “needed Zeke’s help locating an electrical breaker panel” in a certain department.
This is the fourth post in a series. See Behind Locked Doors: Part 3. The next post will be the conclusion.
A couple days after I provided Leeda with access to the suspect’s email, her number flashed on my phone again.
I picked up the phone and said, “Hi, Leeda. Find anything interesting in that guy’s email?” I knew she wouldn’t tell me much, but I pried anyway. It was second nature.
I could hear the Internal Audit manager’s smile when she said,”Nice try, Mack. You know that street only goes one way, and you’re headed in the wrong direction.”
This is the third post in a series. See Behind Locked Doors: Part 2.
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)
A new IT auditor needs some help dealing with database patching issues and how far you need to dive into technology during an IT audit.
Take a moment to read his comment and add your thoughts. I’ve put in my 2 cents. Let’s get a good discussion going.
I think any auditor can chime in, as audit scope and audit limitations are not unique to IT audit.
Dinesh’s comment appears in What IT Auditors Ought to Know – and Don’t!