While installing and configuring some new software on my Windows server, I noticed that the IT department forgot to remove some previous software components from my server.
I remember seeing the notice that the software was being uninstalled and replaced by another package.
I could have removed the left over components myself (I am admin on the server), but I wanted to see if they would ever be removed. Did the Windows server team forget about this, or did the team not concern itself with such things? Maybe the procedures don’t include a process to ensure all components are removed.
I waited about 2 months, but the components were not removed.
Since some of you are newer to the blog, I thought I’d bring a couple of my favorite posts to your attention.
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.
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.
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.
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?
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.
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.
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:
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?
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.
Lenny Zeltser suggest 5 steps that mid-market organizations can take down the security path:
- Identify key data flows
- Understand user interactions
- Examine the network perimeter
- Assess the servers and workstations
- Look at the applications