Chapter 15. Auditing and Ongoing Security

     

Computer security is not an absolute. No sane person will tell you, "Your network is secure." There are various levels of assurance and threats that can be mitigated, but ultimately all security is a trade-off. We decide how much time and money we want to spend to provide a given level of security, and then we determine whether the user experience will be acceptable with that security. Time, money, and user experience have nothing to do with security, but they shape the security design.

One of the most common misconceptions is that computer security should be entirely technology-based. Security must be a combination of technology and policy. The technology enables security, but only well-defined policies can ensure the security is employed, maintained , and scrutinized properly. The remainder of this chapter will discuss how these policies can be created and put in place to help ensure the ongoing security of the network. Then I'll discuss the two most important ongoing security tasks : auditing and patching.

Rogue Administrator

This scenario is one that makes even the most experienced security professional cringe. There are no perfect solutions to this scenario, but you'll quickly see where improvements could be made. As usual, the names have been changed.

Kathie Flood was a domain administrator at her company. She became aware that a downsizing effort was underway and her job was in jeopardy. For a plethora of personal reasons, Kathie was very upset about this development. She determined that her continued presence would be felt even after she was fired .

Before her dismissal, Kathie created a new user account in the domain. She created a fictitious user named Scott Culp and propagated the various fields in the user account details to make it look as if Scott were a legitimate user in the same department as Kathie. Kathie then added this account to the Domain Admins group and ensured that it had RAS permissions to access the company remotely.

The results of this scenario are predictable. Once Kathie was dismissed, she waited until the company's most vulnerable time ”for this company, the fifth of each month is a critical time for customer billing. She then connected to the company's network remotely using Scott Culp's credentials and began attacking the company's critical line-of-business servers. With the Scott account in the Domain Admins group, she was able to choose the method of attack. In this particular case, Kathie wrote a script that remotely destroyed critical parts of the operating system and then forced a reboot.

The company had disabled Kathie's user account and retrieved her building access card at the moment she was dismissed. However, this company had no policy in place to audit sensitive group membership, such as the members of the Domain Admins group. No procedures required sign-off or multiple existing administrators to make the changes Kathie made. Before Kathie attacked the network, she was the only person who knew that the Scott Culp account existed or that it was a member of Domain Admins.

Forensics and postmortem analysis eventually provided enough evidence to point to the culprit. Although Kathie was eventually prosecuted for her crime, it made little difference. Because of another administrator's unintentional but complementary failure, there were no recent backups of the data critical to the company's business. The company lost most of its accounts because of the delay caused by this attack. Eventually the company went under.

Simple auditing would have prevented most of this scenario. The creation of Scott Culp, a user who didn't exist in the human resources database, should have been detected immediately. His addition to the Domain Admins group should have also been detected immediately and reviewed against security policy for administration of that group. And though backup procedures normally fall outside the role of the security administrator, they are often the best way to recover from an attack. Security policies should have been created to periodically audit the backups to ensure they were uncorrupted and useful in case of an attack such as this.




Securing Windows Server 2003
Securing Windows Server 2003
ISBN: 0596006853
EAN: 2147483647
Year: 2006
Pages: 139

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net