Windows Security Basics

Microsoft's extremely dominant share of the desktop operating system marketplace makes an in-depth understanding of Windows security principles a critical component of any security practitioner's professional knowledge. Unfortunately, Microsoft did not design the underlying platform with security concerns in mind. The rush to bring new versions of Windows with greater functionality to market, combined with Microsoft's admittedly low (until recently) priority on security issues, resulted in a complex patchwork of security mechanisms with serious flaws. This is the reason Microsoft releases “Critical Security Updates” to members of the Windows product line on a very regular basis.

The operating systems produced by Microsoft generally fall into two families:

  • Network Operating Systems. Contain functionality designed for collaborative environments, such as an office. Security features designed into these operating systems (such as the share-level security described in the “File/Folder Sharing” section of this chapter) allow the assignment of different access privileges to a variety of users. Products in this family include Windows for Workgroups, Windows NT, Windows 2000, and Windows .NET Server.

    EXAM TIP

    Know Your Operating Systems You may find tricky questions on the TICSA exam that test your knowledge of the security features present in various versions of Microsoft Windows. Remember that more advanced functionality—such as user-level security—is found only in the network operating system line. If you see a question about the new Windows XP operating system, keep in mind that .NET Server is a network operating system, and Windows XP Professional includes advanced networking capabilities that permit it to work closely with Windows 2000 and .NET Servers, whereas Windows XP Home is more limited in its networking capabilities, far less able to exploit such networking capabilities.


  • Desktop Operating Systems. Generally function well in a standalone or small workgroup environment. They include Windows 3.1, Windows 95, Windows 98, Windows Me, and Windows XP Home Edition/Professional. These products do not have the features necessary to function securely in a large networked environment and should be avoided in the workplace if possible.

Obviously, security strategies vary greatly for these two families of products. A home office with one or two computers running a desktop operating system and a DSL connection to the Internet probably requires only minimal protection, such as a router with built-in firewall functionality and a good desktop antivirus package. A networked corporate environment with many systems and users requires a well-thought-out, detailed security plan.

The remainder of the discussion in this chapter focuses on the security functionality of the Windows network products, as this is also the focus of the TICSA exam. Most of the topics discussed in this chapter apply to all networked versions of Windows, but the focus is on Windows 2000, the most recent addition to the line. If you're familiar with Windows NT, you may want to brush up on Windows 2000, making sure you have at least a passing familiarity with Active Directory. Windows .NET Server was still in beta testing as this book went to press.

Users and Groups

Security in the networked versions of Windows revolves around the concept of users and security groups. Active Directory offers a variety of security groups (Universal, Global, Local, and Domain Local) that contain members from varying layers of the directory (discussion of the exact membership requirements is beyond the scope of this book).

The Active Directory Users and Computers (for Windows 2000 and above) and User Manager for Domains (for Windows NT) tools facilitate the creation of user accounts and the assignment of users to security groups. It's good practice to create a hierarchical system of security groups that allows the assignment of permissions to the smallest possible subset of users who require those permissions. The case study at the end of this chapter offers an example of this process in action.

EXAM TIP

Active Directory Groups Active Directory allows the creation of two different types of groups—security groups and distribution groups. Both can be used as recipients of electronic mail, but only security groups can have permissions (and restrictions) on network resources. In native-mode installations, you can alter the type of group, but this is not possible in mixed-mode installations.


When possible, you should always strive to assign resource permissions to groups rather than specific users. This facilitates the transfer of permissions when the role of a user changes. Instead of modifying numerous file permissions for transferred personnel, administrators simply need to modify group membership and the transferred user inherits the proper permissions.

File/Directory Security

Windows allows the application of security rights to all levels of the file system—from the highest-level directory down to the individual file level. Administrators manage these permissions using the Properties sheet of the affected object. There are six types of permissions that apply to files and directories:

  • Read. Allows users to view the contents of an object along with the permissions and attributes of that object.

  • Read & Execute. Adds the ability to execute a program file.

  • Write. Allows users to modify the contents and attributes of an object as well as to create new objects.

  • List Folder Contents. Allows users to view the contents, attributes, and permissions of a folder.

  • Modify. Includes Read & Execute and Write permissions as well as the ability to delete existing objects.

  • Full Control. Adds the ability to take ownership of an object and alter object permissions to the rights granted by the Modify permission.

Windows allows permissions to be granted (“Allow” permissions) and explicitly denied (“Deny” permissions). It is important to note that Deny permissions always override Allow permissions. If a user is a member of multiple groups and one of those groups has a “Deny” permission on a particular object, Windows denies the user that permission, regardless of what other permissions are granted by membership in other groups. Users control permissions to objects they own through the object's Security sheet such as the one shown in Figure 8.1.

Figure 8.1. The Security tab of a file or directory's property sheet allows the assignment of permissions to users and groups.


Windows also provides mechanisms for the flow of permissions from higher-level objects to subordinate objects. This permission flow, or inheritance, is the default behavior of Windows; however, administrators can explicitly disable inheritance for objects by deselecting the “Allow inheritable permissions from parent to propagate to this object” check box on that object's Security tab of its Properties sheet. Refer back to Figure 8.1—this check box is at the very bottom of the sheet.

Group Policies

Group Policy Objects (GPOs) supply administrators with a means to enforce numerous restrictions on network users and computers at the Active Directory site, domain, and organizational unit level. GPOs control a wide variety of Windows and software settings, including

  • Audit settings

  • Password policies

  • Desktop look and feel

  • Contents of the Start menu

  • Floppy/CD-ROM access

  • Internet Explorer homepage

Keep in mind that this is an extremely short subset of the hundreds of properties that Group Policy Objects govern. To gain a better understanding of GPOs, try your hand at Exercise 8.2 at the end of this chapter.

Event Logs

All Windows installations maintain three event logs that track user and system activity:

  • Application log. Shows messages generated by applications running on the machine.

  • Security log. Displays the success and failure records from audited activities.

  • System log. Records errors, warnings, and information events generated by the Windows operating system itself.

Figure 8.2 shows a snapshot of Event Viewer in action. Notice that six different logs are shown in the left pane of this figure. Windows 2000 adds additional event logs when a machine offers certain services. This image is from a machine installed as an Active Directory Domain Controller.

Figure 8.2. Use the Windows Event Viewer to investigate abnormal system behavior and monitor system activity.


In Windows 2000, GPOs control the level of auditing performed by the operating system. By default, Windows disables all auditing and, therefore, the security event log contains no data. To enable auditing, simply create a GPO and configure it to monitor success and failure for one or more of the following nine classes of events:

  • Account logon events

  • Account management

  • Directory service access

  • Logon events

  • Object access

  • Policy change

  • Privilege use

  • Process tracking

  • System events

The Event Viewer provides a useful high-level view of system events. If you need further information about an event, you can double-click the entries in the Event Viewer to see information such as that shown in Figure 8.3.

Figure 8.3. Double-click on entries in the Event Viewer to see detailed information.


Securing the Registry

The Windows Registry contains configuration information vital to the operating system and installed applications. Under normal circumstances, end users never have a need to access or modify Registry information. Therefore, it's a good idea to eliminate or severely curtail Registry permissions for most users on your network.

Access to the Registry occurs through the use of two tools—Regedit.exe and Regedt32.exe. If you want to prevent users from accessing these tools entirely, simply set the file permissions (see “File/Directory Security” in this chapter) to deny Execute rights to them.

WARNING

Beware of the Registry In general, Windows is a very user-friendly operating system that is difficult to damage. Most system administration activities utilize graphical tools that warn you before you make alterations to the system with potentially serious consequences. The Registry is not one of those tools. It allows direct access to the “guts” of the operating system. Before you grant a user access to any portion of the Registry, make certain you're confident that they know what they're doing. Your system is on the line.


If you require a more granular solution, each Registry node (whether it is a single value or a higher-level node known as a key) has its own access control list. You can find these ACLs by selecting the node in REGEDT32 and choosing Permissions from the Security menu. You can apply Allow and Deny permissions to Active Directory users and groups through this tool.

Password Security

As with any operating system, it's critical to ensure that Windows users have strong passwords on their accounts. See the “Password Policies” section of this chapter for some general suggestions that apply to all operating systems. In Windows, the default Administrator account has full control of all system resources—it's especially important to ensure that this account has a well-protected, strong password.

Windows allows the creation of password policies, such as minimum password length, password aging, and complexity requirements through the use of Group Policy Objects. An example of such an object appears in Figure 8.4.

Figure 8.4. Windows allows the application of password policies through the Group Policy tool.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.109.171