Server Security Audit: weigh knowledge and performance

Except for the smallest enterprises, all organizations have security audits for certain levels of servers. Regardless of the number of Logon failures, security file access, file deletion, activity directory modification, or other information it collects, most of us need to obtain a certain amount of information.

At TechEd 2011, I initiated a group discussion on audit, which clarified one thing: Windows Local Security Audit clearly identified some security issues. A gentleman's story represents everyone's experience:

Management requires me to provide details about failed logon and successful logon. I told them that we didn't collect the information at present and they ordered us to do it. I enabled the necessary audits, and almost shut them down as soon as possible. Our domain controller cannot handle additional loads at all.

The fact that auditing causes performance loss initially surprised many administrators because it is not entirely intuitive. After all, the domain controller is already running. Why is it so difficult to just mark it? It is indeed difficult: Some people say that auditing is a job in capacity planning in his company. He estimates that his team owns two times the domain controller required to process login traffic because it has enabled almost every possible audit option.

For file servers, rejecting requests to access files is one thing. Opening event logs and marking the facts are completely different operations. Although Windows's local event log architecture is roburst, it is not free of charge. It requires computing power, which can exhaust all the performance of a server. This is also why auditing is almost always balanced between performance and knowledge. The more audit occurs, the less user workloads that the server will eventually process, because it takes more time to audit the workload. Some organizations only deploy more computing resources to handle these workloads. Other enterprises have to adjust the audit volume to keep the servers running at an ideal performance level.

Third-party audit solutions sometimes process higher levels of audit than the local event log architecture. They complete this task by combining three basic technologies:

The agent installed on the server can directly access the Windows application interface API), instead of waiting for the event to be written into the event log. These proxies save on the daily expenses of Event Logs because local audits can be disabled. It usually takes less to retrieve data directly from API traffic.

Audit data can be written in a lazy manner, which means it can wait in queue for logs for a period of time. This is usually not a long time, but it does allow audit to take a secondary place to handle user workloads.

Events are usually transmitted to the central database for writing and removing a little more workloads from the server, because the server does not need to maintain the actual logs.

The Administrator may have to do some lab-based experiments to precisely view the levels of performance created in the server environment, which affects the selected audit configuration. The core information for selecting an audit method is: you cannot have all of them. Management needs to understand that obtaining every bit of information may have a performance impact. Companies need to be willing to pay additional servers, larger servers, or lower performance costs for these impacts.