You have had the phone call. You know the one – it typically comes on a Friday afternoon at the end of an easy week. The call goes something like this:
Why wasn't the box checked? Was it ever checked? Did someone uncheck it? Who did or did not do this? Most likely you will never really know.
No matter how well planned out, how many test scripts are run or how many times you explain it, something always goes wrong. Just like death and taxes, problems are inevitable, but you can avoid those phone calls.
Go back to that nice relaxing Friday, but this time start in the morning and pull up your daily monitoring report and see that a critical box has been unchecked by Joe. You follow up with Joe and find out it was done for a good reason, but Joe forgot to recheck the box when he was done.
The difference in the two scenarios is timely information on critical configuration. So how do you get that to happen? Monitoring controls. The first step to having monitoring controls is to have an appropriate design. I use the following methodology when designing monitoring controls:
Key processes
Everyone has some type of defined area of responsibility. If you can't define your areas of responsibility, stop – you have bigger problems, and you aren't ready for monitoring. The purpose of this phase is to list any major processes that fall under your responsibility. Say you are responsible for the Windows environment, for example, for server maintenance and administration. In that case, you would most likely have the following key processes:
Having high-level bullet points of responsibility is a great tool. It will help you in so many ways, from managing your priorities to disaster recovery to monitoring for errors.
Failure analysis
The next step in the design process is to take a deeper look at each of your key processes. The goal is to ultimately identify where things are likely to fail and ca
To continue reading for free, register below or login
To read more you must become a member of SearchWinIT.com
use you problems. This is done by taking a process and asking a few questions.
Let's analyze privileged user administration. Here are the questions I would consider when performing a failure analysis:
You are likely to come up with several more questions that will help lead you to your final list of all the areas in which your process is likely to break and result in a problem.
Identification of control points
Armed with your key processes and your points of failure, you can now go through the last exercise in control planning – identifying your control points. A control point is something that gives you that warm fuzzy feeling. Knowing that it is in place and working allows you to trust the system.
To get a clear picture of where your control points are, look over your failure analysis. You should have a quick response to each of the weaknesses. Maybe you have a weak provisioning process with lots of workarounds. If you have a program that logs administrative login or sends an alert every time someone logs into the box with a local account, then you can still feel comfortable with having a secure environment.
If you are like most other IT managers, you will have identified some gaps at the end of this process that you don't have controls for. There is no time like the present to design and implement controls to address the potential failures.
With a clear picture of your process, failure and control environment, you can now look forward to the next step in the process – implementation of control monitoring. Here you can pull out your WMI scripts, Active Directory queries and other tools.
Russell Olsen is the CIO of a medical data mining company and previously worked for a Big Four accounting firm performing technology risk assessments. He co-authored the research paper "A comparison of Windows 2000 and Red Hat as network service providers." Russell is a CISA, GSNA and MCP.
