Since some of you are newer to the blog, I thought I’d bring a couple of my favorite posts to your attention.
Tag Archives: server
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.
The phone rang half a ring before I heard a familiar “Hello?” on the other end.
“Hi, James, it’s Mack. I need a favor from you, and I need today, before 5 pm.”
“Not urgent, huh?”, James teased.
“Not really, I just need it today. And I need you to keep it quiet,” I warned.
This is the second post in a series. See Behind Locked Doors: Part 1.
First, why do you need to be dauntless?
Because you’re going to need to obtain your data from a number of different sources; the bigger your company, the more likely you’ll need to call on and question more than a handful of people.
Because comparing and tracking all the servers that are on one list, but not another can be a challenge.
Because it his highly LIKELY that you WILL find something and the server team will not be happy.
In my previous post, I described a data center failure that I discovered as the newly hired security manager of a prominent company.
In this post, I describe my next adventure.
NOTE: Some of the details below were changed a bit to protect the guilty. I tweaked their noses enough. :)
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).
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?