Software Components NOT Removed from Servers

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.

Advertisement

Quote: Not Concerned about General Ledger Changes

Last week I was meeting with one of our company’s Accounts Payable clerks, who told me she was not concerned about some upcoming General Ledger changes.

2 changes that were submitted by developers on her behalf.

2 changes she didn’t know anything about, so she didn’t consider them her problem.

This post is a Quote of the Weak post. For more info on these types of posts, see the Quote of the Weak topic under About.

 

Quote of the Weak: We Have a Plan to Address that Risk

As an auditor, I am told all the time by the business that “we have a current project plan that is addressing that risk”, which implies that I shouldn’t waste everyone’s time writing up an audit issue regarding the problem.

It means that the risk isn’t as big as it appears.

Really?

Quote of the Weak: No end goal

The other day I was in a meeting to discuss a new analytics project and discovered the team had no end goal.

When the discussion started with the software to be used, I knew they were already off track.

Mack-the-Auditor Gets Audited! Part 3

This is the third of 3 posts; this post describes how I audited the auditors and my perspective on the whole thing.

Read the first post (background) and the second post (audit results).

Mack-the-Auditor Gets Audited! Part 2

This is the second of 3 posts; this post describes the audit, some speed bumps, and the audit results.

Read the first post here, which provides the background on the audit and the audit’s scope.

Mack-the-Auditor Gets Audited! Part 1

Usually, I’m the one doing the auditing, but this time, I (Mack) was the one who was audited.

It was a great experience for me.

Well, sort of. No one likes being audited (ahem). But it gave me a fresh perspective of how others feel when I audit them.

This is the first of 3 posts; this post contains some background info on the project that was audited, and the second one discusses the audit and the results, and in the third post, I describe my perspective on the whole thing, and some takeaways.

Auditor Struggles, Part 4

This is Part 4 of a Case File series that describes how real auditors tried to apply questionable methods to auditing and data profiling. See Part 1, Part 2, Part 3.

Does the Process X team provide metrics around their process?” I asked.

“Yes,” the most senior auditor replied, showing me the web page where the Process X metrics were displayed.

After reviewing the page briefly, I said, “I see they do metrics by month. You have a year’s data; are you planning to understand how they prepare their metrics and re-calculate them to see if you get the same numbers?”

Auditor Struggles, Part 3

This is Part 3 of a Case File series that describes how real auditors tried to apply questionable methods to auditing and data profiling. See Part 1 and Part 2.

I looked at the third page of the handout and asked, “What is this?”

“A list of Active Directory (AD) groups and the user IDs in each group. I searched AD for any group containing the system name,” the junior auditor said, “and identified these 6 groups. I then downloaded all the members of these groups from AD into Excel.”

Auditor Struggles, Part 1

Some auditors struggle with basic auditing. So when these auditors try to data analysis, well you can imagines how that goes.

I recently met with a team of auditors to give them input on what data profiling would be appropriate to perform. And what analytics might be insightful.

This is Part 1 of a 4-part Case File series that describes how real auditors tried to apply questionable methods to auditing and data profiling. Do not try these methods at home or work. Don’t even dream about them, awake or asleep. 

A Sneaky Way to Analyze IT Controls

When auditors need to identify and understand IT controls, they search the company intranet, review policies, look for Github repositories, review inventories, schedule meetings, and analyze IT asset data.

I stumbled on a better way to get insight into the IT controls in my company, and I didn’t have to email anyone, do any research, or frankly, anything outright. The IT controls came after me.

Fortunately, the IT controls were blind to the fact that I am an IT auditor. To them, I was just an ordinary bloke. But that didn’t last long (more on that later).

It Began a Few Years Back

It all started a couple years ago when I was building the infrastructure required to support our data analytic efforts in internal audit.

Quote of the Weak – Clean Data Manually

If you are in IT, audit, or security (or any other job requiring data analysis), you should NOT be cleaning data manually.

Let me share a recent experience with you….

A young IT auditor texted me at work and asked for some Active Directory user account data that I capture automatically every week, using some scheduled ACL scripts.

If you’re not familiar with my ‘Quote of the Weak’ series, I described it briefly in About. For a list of posts in this series, see here.

Do you have User IDs Hidden in the Cloud?

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

The Simplest, Cheapest, and Most Effective Disaster Recovery Plan Ever

About a decade ago, I personally witnessed the handover of the simplest, cheapest, and most effective disaster recover plan ever.

Let me first give you a little background….

I worked for a great IT director, who moved to another company, much bigger, and brought me with him.

In the new company, he again was responsible for all IT, and he brought me along to manage security and disaster recovery.

If I named this company, at least 25% of you would recognize it, even those of you around the world–true story, too.

Behind Locked Doors: Conclusion

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.

Behind Locked Doors: Part 4

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.

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.

Behind Locked Doors: Part 1

It all started when the phone rang, which was typical.

Typical in the days when I was a security manager…

“Information Security, Mack here,” I said, as I continued to read the magazine in front of me.

“Hey Mack, this is Leeda. I need your help,” the voice said, as my mind started coming back online.

Leeda was a manager in Internal Audit; when I heard from her, it usually meant I had to carve a few weeks out of my schedule. Fast.

Data Center Failure: Conclusion

In previous posts, I described how I gained access to the data center area and then the data center proper.

I had bypassed door #1 and door #2.

My new colleagues were not 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. :)

Data Center Failure

One company I worked at had a sad data center failure, and I’m not talking a power outage or a fire or theft.

When I arrived at this company, it had no security department. Few security processes. Little security.

And the company also made two interesting mistakes when it hired me.

Vendor Provides Access, No Questions Asked

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.

Internal Attacker Detected: Conclusion

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.

Internal Attacker Detected: Part 3

Tim said, “Mack, like you suggested, I connected to her new PC over the network and searched her hard drive for the hacker tools–they’re back, plus a few new ones. And her antivirus is turned off again.”

This is a multi-part series. See Internal Attacker Detected: Part 1 and Internal Attacker Detected: Part 2.

After discussing my action plan with the CIO, Legal, and Human Resources, I met with the contractor’s manager, Sue, and explained the situation. Both the hacking tools and turning off a security service were serious violations of security policy. I had recommended the person be walked out and told her that the CIO, Legal, and HR agreed.

Internal Attacker Detected: Part 2

Two days later, I walked up to the well organized desk of Tim, the malware tech that told me about the hacking tools that he’d found on a contractor’s PC.

“Tim, did you find any bear paw in the trap we set?”

This is a multi-part series. See Internal Attacker Detected: Part 1.

Tim turned around, and I could immediately tell he was not happy. His jaw was tight, his hair was clumped, and his blurry eyes told that he had not been to bed in the past 24 hours.

Internal Attacker Detected: Part 1

A while back when I worked in IT security, an internal attacker popped up on our radar…

I answered the phone and heard a tech from the anti-malware team say, “I think we have a problem, Mack. Got some time to come down and see what I found?”

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?

Case File: Audit Server Disappeared

My friend Brenda is an auditor who came to work one day and couldn’t connect to her department’s audit server.

Brenda called the help desk and told them she couldn’t connect. She wasn’t sure what the server’s name was, so the help desk had a bit of trouble finding it.