Professional Windows Server 1002003 Security A Technical Reference [Electronic resources]

Roberta Bragg

نسخه متنی -صفحه : 194/ 162

Establish Baselines

You cannot determine which events require investigation as possible security incidents unless you know what is normal. Thus, the first step in detecting abnormality is establishing a baseline. If you know what is ordinary for your organization, it is easier to spot the unusual. For example, do you know how many logon failure events in the event log of a domain controller constitutes ordinary forgetfulness or error on the part of your users? Users will forget passwords and enter them incorrectly, so there will be failed logon events in the logs. If you know how many logon failures are typical, you won't be alarmed to see them but will correctly identify a sudden rise in logon failures as something to investigate immediately. If you have no idea what is normal, you might see a few events as a problem, or count large numbers of events as normal operations. The number of normal failed logons for a specific DC in your system is not a number that can be determined by examining some statistic recorded by another organization. Baselines for event log activity are not the only statistic to consider, either. Do you know the average time it takes to fully replicate changes to the Active Directory across your enterprise? Are spikes in network utilization normal for a specific day of the week, month, time of day, or do they represent a spreading worm?

Attack!

Early in my tests of Microsoft Internet Security and Acceleration (ISA) server, I reviewed the logs several times daily in order to become more comfortable with them. I set up all of its reporting features and thoroughly investigated its operation. Then, I had to travel for a bit. I left ISA in place, but I removed its connection to the internal test network. When I returned, I found the logs full of failed logon attempts. As I watched, more were added. My first instinct in such cases is usually wrong. Typically, I want to disconnect the system under attack from the Internet in order to protect the internal network. But this server's only connection was to the Internet. If the server were compromised, the only loss would be the server itself, and I might learn more by keeping it connected. I left the server connected to the Internet and started investigating.

As I continued to examine the logs, a pattern emerged. A single account was under attack, and the failed logon attempts were occurring with regularity. However, there was some time between them. It was either a sophisticated attack that was trying not to trigger an account lockout, or an individual working very slowly but precisely. The attack had been going on for a few days. What person could ever maintain that pace hour after hour, day after day? It had to be software.

Then, it hit me. The account under attack was an account I set up to be used by the reporting engine. The production of reports draws data from the ISA logs and cannot operate without authentication. Could this be a failure of the reporting engine and not an attack after all? Well, I was half right. It was not an attack. I had set the account password to expire and had not reset it. The password had expired, but the automated process had not. Everything was working as it should, except the system administrator. A quick password reset, the report program could log on, and the incident was over.

This security "incident" was not the result of an attack, but it does point out the need for understanding the systems we are required to protect and for understanding normal activity in the logs.

Many of these baselines may be tracked already as part of network operations. From a security perspective, your job may be simply to help interpret the variations. A number of resources can help, including a web sites such as the Information Technology Professionals Resource Center (ITPRC), which lists and describes products and provides whitepapers on network monitoring at http://www.itprc.com/nms.

Other operations, such as monitoring Active Directory and Group Policy operation and interpreting Windows logs, may not be addressed by traditional network monitoring products and networking staff. They are addressed by a growing number of third-party and Microsoft products, such as Microsoft Operations Manager (MOM). The suitability of any specific product for your network is not within the scope of this book; understanding what to monitor and how to use built-in or resource kit tools is.

NOTE: Resource on Intrusion Detection

Using network monitors for intrusion detection and forensics is beyond the scope of this book. A good resource is The Tao of Network Security Monitoring: Beyond Intrusion Detection by Richard Bejtlich (Addison-Wesley, 2004). This book provides detailed analysis of network traffic captured using free and commercial network monitors.