Some of my Favorites

Since some of you are newer to the blog, I thought I’d bring a couple of my favorite posts to your attention.

Behind Locked Doors: Part 3

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.

Behind Locked Doors: Part 2

This time, it was my turn to call someone for help.

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.

Server Audit for the Dauntless

If you’re looking for an insightful server audit, and you’re dauntless, you might want to jump on this train.

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.

Data Center Failure: Going Behind Door #2

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. :)

Periodic Access Review Problems

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).

How Virtualization Changes Audits

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?

Securing Virtual Servers

Here’s my take on the issues that I found with the following quote from SC Magazine (for more info, see Quote of the Weak (Securing Virtual Servers):

We don’t treat the virtualization servers any different than the physical servers when it comes to security. We treat them the same. Security is security.

Searching for Secrets

I was visiting a friend at large, public company doing some benchmarking when we had to schedule several meetings with IT to gather data. My friend “Meako” starting entering attendees into his online calendar to see whether we could get some important meetings scheduled during the next week.

Quote of the Weak (Securing Virtual Servers)

When I read the following in SC Magazine, my brain identified and attempted to process so many issues at once that I experienced multiple memory and neural page faults and felt physical pain:

Conclusion: Audit Server Disappeared

In Case File: Audit Server Disappeared, I noted that a friend of mine learned that  IT had, on its own prerogative, wiped a server belonging to Internal Audit because “it never appeared to be used.”

Some of you already commented on some of the issues involved in this incident and the normal IT activities that should have prevented this incident (or at least alerted IT that something was wrong). Let’s review those comments and I’ll add some other details and comments.

Case File: Trouble Bites Auditor

As an auditor, I’ve been accused many times of looking for trouble. I have to admit that it’s true, because that’s my job. But too often, trouble comes looking for me. Sure it makes my job easier, but it also makes me scratch my head.

When I was in IT operations, before I got into security and audit, I was always thorough and followed common sense and company policy. However, any projects that I was doing that might draw the eyes of either of those departments, I double-checked prior to delivery. Most bosses don’t like surprises, and I was always a details guy. Besides, why poke the bear?

Always Attack the Lone Reed

In nature, predators watch for young, weak, or isolated animals. So do attackers. So should you.

When scoping a security assessment or audit, always keep an eye out for the lone reed. In other words, take special note of the one item (process, account, device, etc.) that has the same function as others in its category or class, but is a bit different. That item often has weaknesses the others don’t have.

How to do an Easy Server Share Audit

Okay, so you’re not up to a wastebasket audit? Too demeaning, too sneaky, too many sticky candy wrappers? How about a simple server share audit?

Many companies have shared drives, and then they have “over-shared” drives, those locations where anyone who needs a space to store files that they share with a couple departments. Or perhaps your company just doesn’t lock their shares according to the least privilege principle.

5 Security Steps for Non-Big Businesses

Lenny Zeltser suggest 5 steps that mid-market organizations can take down the security path:

1. Identify key data flows
2. Understand user interactions
3. Examine the network perimeter
4. Assess the servers and workstations
5. Look at the applications