Host-Based Security in Windows Vista

Most of the new security changes directly affect the Windows Vista computer-the host. This section starts with the boot and startup changes, and then discusses the operational aspects.

Boot Changes

There are major differences in the Windows Vista boot sequence, including the Boot Configuration Data store, new boot files, new system recovery tools, and BitLocker Drive Encryption technology.

Boot Configuration Data

In most of today's PC-based systems, the BIOS is responsible for locating the primary boot drive, which loads the system partition, which then loads the operating system.

A newer emerging boot process open standard called Extensible Firmware Interface (EFI) will work on EFI-enabled computing devices. EFI is a more flexible framework for bridging the boot-up gap between hardware and software, storing EFI-related variables in non-volatile RAM. EFI will allow operating systems to move more transparently beyond traditional desktop and laptop computer form factors (for example, to PDAs, cell phones, wearable computers, and so on). EFI-enabled operating systems require more hierarchal complexity than a simple text file can provide.

The Boot Configuration Data (BCD) store replaces the Boot.ini file used in previous versions of Windows. If Windows Vista is the only OS installed on a boot volume, the boot.ini file will not be created or used. However, the boot.ini file is still supported for legacy dual-booting scenarios on computers with an AT/BIOS chip.

The BCD store and its associated editor, Bcdedit.exe, are intended to interface Windows Vista and later operating systems with EFI. Unfortunately, the complete EFI standard emerged too late to be included in 32-bit versions of Windows Vista. EFI support is available in 64-bit versions of Windows Vista and Longhorn.

Windows Vista's boot process now includes the following new files (among others):

• Bootmgr, a hidden file located in the root directory of the boot volume, controls boot flow and multi-boot options on a dual-or multi-boot situation

• The BCD store is a (non-hidden) hierarchical binary file stored in the hidden \boot folder. Microsoft describes it as a registry hive file, but it is not supposed to be accessed using normal registry tools. On EFI-enabled computers, BCD will be stored under \EFI\Microsoft\Boot on the EFI system partition.

• Located in the hidden \boot folder is also a hidden 64K Bootstat.dat file created at install, and one or more hidden BCD log files named BCD.log, BCD.LOG1, BCD.LOG2, and so on, which can be used for diagnostic purposes.

• Winload.exe (located in \Windows\System32) is the new OS loader, replacing NTLDR. It loads the kernel files, HAL, and boot device drivers into memory.

Firmware-independent BCD can work with PC AT/BIOS or EFI-enabled computers and is designed to handle multiple versions of Windows and even non-Windows operating systems. If a legacy (i.e., prior to Windows Vista) version of Windows is installed on a separate partition on the same computer as Windows Vista, the legacy Windows program will still use its own NTLDR and boot.ini files.

The BCD store should be managed using the new command-line program, Bcdedit.exe located in \Windows\System32 or with the BCD WMI provider. Administrative privileges are required to view and modify BCD settings using Bcdedit.exe. You can type in Bcdedit.exe /enum to see current settings or Bcdedit.exe /export to export current settings. Type in Bcdedit.exe /? topics to get a full list of commands and syntax.

Note

To get an administrative command prompt, all you need to do is right-click on a shortcut to the command prompt and select "Run as administrator …".

The System control panel applet still interfaces with the global boot settings that allow administrators to pick the boot order and boot manager timeout setting. Msconfig.exe interfaces with the BCD store as well. As was possible with the Boot.ini and Bootcfg.exe files in previous versions, a troubleshooter can set special diagnostic parameters or EMS parameters, or enable kernel debugging using Bcdedit.exe. Bootcfg.exe is included with Windows Vista, but cannot modify the BCD store. It can be used only to view and modify legacy Boot.ini files on dual-boot systems. Bcdedit.exe can also be used to modify earlier versions of Windows.

Note

Winresume.exe is located in \Windows\System32 and helps Windows Vista resume from hibernation along with the hidden Hiberfil.sys file in the root directory that would hold the saved memory contents.

You can read more about BCD and EFI at http://www.microsoft.com/whdc/system/platform/firmware/bcd.mspx.

System Recovery

Windows Vista includes major improvements to Microsoft system recovery tools, including the Windows Pre-Installation Environment (WinPE), Windows Recovery Environment (WinRE), and the Startup Recovery Tool (SRT).

WinPE essentially replaces the DOS boot diskettes and/or Recovery Console needed in previous versions of Windows. It loads a mini-version of the Windows Vista OS, and can be used for deployment scenarios, troubleshooting, and system recovery.

WinPE is loaded from the large \sources\boot.wim (Windows Imaging) file located on the original installation media during Windows Vista's initial install, but can be loaded from any bootable media, including a USB Flash Memory drive. During installation of Windows Vista, WinPE boots to the first GUI the user sees. During this time a user can press Shift+F10 to exit the displayed GUI to a WinPE command prompt.

WinPE runs completely in memory (requires 256MB memory), and has the following features:

• Provides full access to FAT and NTFS file systems (for file copying, data recovery, and so on)

• Creates and formats disk partitions

• Driver injection, where critical drivers can be loaded before WinPE boots fully

• Detects and enables most hardware devices, and supports 32-bit and 64-bit device drivers

• Enables TCP/IP networking support

• Runs a robust Win32 API, which supports most 32-bit applications, scripts, batch files, ActiveX, and HTML applications

• Text-based console, WinRE, with several built-in diagnostic tools and commands (including Diskpart, Drvload, Net, and Netcfg)

WinPE was previously available to XP environments with Software Assurance agreements, but in Windows Vista everyone gets an improved version known as WinPE 2.0.

Startup Repair Tool

If Windows Vista fails to boot up and load properly, WinPE (often loaded on an OEM hard drive partition) will automatically load WinRE and the Startup Repair Tool (SRT). Microsoft did a lot of research on bootup system failures and their causes. SRT analyzes the startup logs looking for the problem. The SRT and its Setup Repair Wizard can fix upwards of 80 percent of all known failures (according to Microsoft).

If the failure cannot be automatically repaired, the SRT will attempt to roll back the system into a previously known good state. Only time will tell if the new rollback is better than it was in previous versions. If the rollback does not repair the problem, the SRT will provide detailed diagnostic information and offers additional support options.

Administrators can use WinPE, WinRE, and the SRT to diagnose and repair damage, malicious and otherwise. Because WinPE allows 32-bit applications to be run and recognizes NTFS partitions, it is possible to run fully functional antivirus and malware removal tools. Access to NTFS partitions assumes the user has appropriate administrative permissions, of course, and that the boot drive is not encrypted.

BitLocker Drive Encryption and TPM

In previous versions of Windows, malicious attackers have been successful in booting around the operating system protections provided by Microsoft. If the attacker can boot up on another operating system (for example, Linux, Knoppix, and so on) that can read NTFS partitions, the attacker can copy data and password hashes from the exploited system.

To prevent physical "boot-around" attacks, the Enterprise and Ultimate versions of Windows Vista have the ability to encrypt the entire OS boot volume using a new feature called BitLocker Drive Encryption. When enabled, the primary boot volume remains encrypted until decryption keys are supplied. The key can be stored in a Trust Platform Module (TPM) chip located on the mother board or on a USB key (and, for backup purposes, a recovery key can stored in Active Directory as well if the domain controllers have been upgraded with the appropriate schema).

A TPM chip is a specialized cryptographic chip located on the motherboard or added on via an interface card, with a supporting TPM-enabled mother-board and Trusted Computing Group-(TCG-) compliant BIOS. Among many other possible functions, a TPM chip can securely protect the BitLocker decryption key. The TPM can be configured to automatically decrypt the Bit-Locker volume decryption key when Windows boots (and is in control of security), or to require a PIN to be entered by a local user, or read from a USB flash memory drive, or a combination of all three. If a TPM chip is used, it will also verify that the hardware has not been tampered with. This is why it is crucial to turn off BitLocker before upgrading the BIOS on your computer. Otherwise the TPM will detect that the hardware has been tampered with and will lock the system and require a recovery key to boot it.

In order for BitLocker to work, the participating primary boot drive must have two NTFS partitions. The first is for the unencrypted boot information, and the second holds the encrypted partition. There is a new Control Panel applet to enable, configure, and disable BitLocker. 

Note

Windows Vista contains a new MMC console, Tpm.msc, for administrating and initializing TPM, which must be enabled before turning on BitLocker, if you wish to use the TPM to store BitLocker keys.

Security Defaults

Windows Vista has considerably stronger default security settings than Windows XP Pro, particularly the early versions. Here are some of the default settings:

• Administrator account is often disabled, but can be enabled.

• User Account Control is enabled.

• Internet Explorer is in Protected Mode (covered below) for all security zones except the Trusted sites zone.

• Most inbound connections are blocked by Windows Firewall (most outbound connections are allowed by default, but many programs and services are blocked from communicating out).

• Automatic Updates is enabled.

• Windows Security Center is activated.

• Windows Defender (and SpyNet) is enabled by default.

• A password-protected screensaver is enabled by default.

These settings make Windows Vista relatively secure out-of-the-box. The Windows Security Center display will appear reporting on the current status of most of the items in the preceding list and allow you to make adjustments, if needed.

Windows Defender

Windows Vista actively uses Microsoft Windows Defender (see Figure 1), which was previously released as an extended beta trial for XP SP2 users. Bought originally from Giant Software, Windows Defender is an excellent spyware prevention and removal program. It allows scheduled scans and real-time protection. When enabled, the real-time protection monitors the registry, auto-start locations, services, and Internet Explorer for spyware-like activity. In independent tests with other competitors, it always ranks near the top in accuracy.

Figure 1: Windows Defender is included in Windows Vista.

By default, users are joined to Microsoft's SpyNet online community. SpyNet membership instructs Windows Defender to send each user's personal decision on what to do with newly identified potential spyware (i.e., allow or remove) to the SpyNet database. Collected responses are used to identify new spyware, which then updates the Windows Defender definitions.

Malicious Software Removal Tool

The Microsoft Malicious Software Removal Tool is executed by default during new installs and when the system is updated with Microsoft Update. Originally written for Windows XP SP2, the Malicious Software Removal Tool checks for and removes only the most popular malware at the time of its download. It does not check for all malware as a more general anti-malware program might.

Microsoft created the tool in response to failed installations of its updates due to malware. Many of the failed installations could be traced to customers having actively compromised and exploited computers. The installed malware programs would prevent Microsoft's new software from being installed, which the users then blamed on Microsoft.

Microsoft uses both Windows Defender and the Malicious Software Removal Tool to gauge how popular a particular malware program is. This, in turn, helps guide its response. Some very critical dangerous zero-day threats have been measured as infecting only a handful out of 25 million users. When the spread of a threat is small, as in the previous example, Microsoft waits to release the defense patch until the normal monthly "Patch Tuesday" cycle. If the malware is spreading quickly and is a critical threat, Microsoft will often release the offsetting patch "out-of-band" before the normal release date.

Improved Logon Architecture

Windows Vista strengthens existing password authentication and has improved support for smart cards, fingerprint scanners, biometrics, and so on.

LAN Manager Disabled

First, LAN Manager (LM) password hashes are disabled by default. Disabling LM password hashes is the single best step to prevent Windows password cracking (i.e., hash to plain-text conversions) that Microsoft could have made. The option to disable LM hashes was available in past Windows versions, but was disabled by default, so most administrators never did it.

Windows Vista also disables outbound LM and NTLM version 1 authentication protocols, leaving only NTLM version 2 and Kerberos enabled by default (although all four authentication protocols are still accepted inbound for backward compatibility with connecting clients without increasing malicious risk). This step helps prevent password cracking from network eavesdropping programs (Cain, for example). Both decisions are long overdue and have very solid security goals, but may cause problems in some environments with legacy Windows computers and applications.

Better Support for Additional Authentication Methods

Microsoft has also made it easier to integrate non-password authentication methods, and even multiple, simultaneous authentication methods, in the logon process. Since Windows 2000 you can use smart cards for authentication, and more recently, you can replace the logon interface with one from third-party providers to log on with RSA SecurID tokens, for example. However, you can use only one authentication method at a time. Windows Vista has a completely new Winlogon architecture and a new Credential Providers API that gives improved built-in support for smart cards, USB tokens, two-factor authentication, and more, and allows for multiple credentials to be used at the same time.

In past versions of Windows, end users interacted with the Microsoft Graphical Interface for Network Authentication (GINA), implemented in Msgina.dll, to logon. Winlogon.exe handled the logon process, but the Microsoft GINA displayed the logon dialog box where the user typed in their user account name and password (and any other necessary information such as target domain name). When administrators wanted to add another form of authentication, it required (in most cases) that the Microsoft GINA be replaced by another vendor's GINA. For instance, if biometrics were implemented, the Microsoft GINA would be replaced by the biometrics vendor's GINA, so it could prompt users for a copy of their fingerprints, instead of a password.

Unfortunately, when a vendor replaced the original GINA, the vendor's software was now in total control of the user's logon security. Replacing the original GINA often caused problems or prevented the use of other Windows features (for example, Terminal Services, Remote Desktop, and so on) and broke many other applications. To make matters worse, many vendors poorly coded their replacement GINAs so it weakened overall security. Microsoft, having not written the GINA, could not patch it, and getting vendor patches often proved complicated.

In Windows Vista, a new Credential Providers API replaces the legacy GINA and all user logons are accomplished through a new user logon interface (Logonui.exe). Vendors must write their authentication interfaces and programs to interface with the new Credential Providers API (see Figure 2 for an old versus new comparison). The Credential Providers API interfaces with the logon user interface (called LogonUI), and the LogonUI can handle multiple vendor implementations at once. Vendors use COM programming to ask the LogonUI to gather the necessary data on their behalf.

Figure 2: The new Windows logon process provides more granular hooks for enhancement.

Windows Vista ships with built-in password and smart card credential providers, but Microsoft is working heavily to influence other credential providers into using the new API.

Session Isolation

Another huge improvement has been made to logon session security. Multiple user sessions can be started in Windows at one time. One session is always started when Windows starts and the services are loaded. Another session is started when the first user logs on. Additional sessions can be started (for example, using RunAs, Remote Desktop, Terminal Services, Fast User Switching, and so on). The first session is numbered Session 0, and additional sessions are given incremented numbers (for example, Session 1, Session 2, and so on). Unbeknownst to most users, many applications (for example, antivirus software) actually run in additional sessions.

In previous versions of Windows, all the programs started by the first user ran in Session 0, along with the already started services and other kernel mode processes. Additional sessions could be started, but could easily interact and communicate with the other sessions. This allowed applications and services in one session to talk to users and software in other sessions. For example, the background running antivirus scan (running in a different session) could send a message (for example, "Virus found!") to the user computing in Session 0.

Unfortunately, there are two weaknesses to this method. First, having a regular user whose interactive desktop is in the same session as system services presents an obvious security problem. Second, allowing additional sessions to communicate with and interact with the first session (i.e., Session 0) opens up other potential vulnerabilities. Attackers used a class of attacks called "shatter" vulnerabilities to exploit more privileged sessions using less privileged sessions (i.e., privileged escalation).

In Windows Vista, Session 0 is reserved for Windows kernel code and system services. Users never interact with Session 0 directly, and other sessions cannot communicate directly to Session 0. This prevents many different types of attacks, including the whole class of shatter attacks. Unfortunately, this also means that any application that installs itself as a service will no longer be able to directly interact with Windows system services (for example, graphics driver, and so on) or with the end user (which is often the done by many poorly written services). Service applications will have to be re-written to work correctly or interface with the end user for Windows Vista.

A new service called the Interactive Service Detection Service is available to help bridge legacy service applications until they can be re-written. When the new service detects a legacy application trying to send a message to the interactive user, the message will be intercepted, and the user prompted to accept the incoming communication from the application. Although getting the approval of a user before being able to accept a dialog box from an application may appear draconian, session isolation is a much needed improvement for Windows security. Without it, Windows would continue to be very vulnerable to local privilege escalation attacks.

Service Hardening

Microsoft has done more than separate the services from the user and application sessions. It has also made every default installed Windows service follow a least privileged security model. Each service was reviewed, and unnecessary permissions were removed. On the book's Web site you will find a complete list of services in Windows Vista, along with their associated security settings.

Windows XP introduced the lower privileged service accounts of Local Service and Network Service, which replaced Local System when possible. Windows Vista continues this trend, and percentage-wise, more services use non-Local System security contexts than any of the previous Windows operating systems. Windows Vista introduces even more service security.

Every service is assigned a SID, which is something the previous operating systems did not do. This allows the service to be tracked uniquely, and makes it easier to assign permissions. The Service Control Manager (SCM) reviews the privileges a service needs during start up and removes unnecessary privileges.

Once started, the service cannot be given new or additional privileges. The SCM adds many services to the Restricted SID to further restrict what a service can do. By default, a service can only write to an object that specifically allows services to write to it. For example, the Remote Procedure Call service cannot replace system files, modify the registry, or modify other system services or applications (for example, antivirus scanning protection). This change alone would have prevented the Blaster worm outbreak a few years ago.

Services are now allowed to have failure actions even when the service doesn't become fully inoperable. In past operating systems, failure actions could be defined only when the service stopped responding and crashed completely. Now, high CPU utilization loads, memory leaks, and so on can trigger recovery actions.

On a slightly related note, services can now avail themselves of a new Automatic startup type called delayed start. Delayed start services don't immediately start when the system boots, but instead wait a short period of time, and even then start with low priority.

Services are also assigned a default network firewall policy and connection scope. It makes it harder for a local service to initiate outbound connections attacking other non-local networks. Many of the previously successful buffer overflow attacks worked by overrunning a service and then using the infected host to attack remote networks. This change would have significantly lessened the impact of the Blaster and SQL.Slammer worms. Microsoft is working with vendors to help them follow the new service hardening methodologies. Services that don't may not work in Windows Vista.

Enhanced Device Driver Experience

All Microsoft device drivers are extensively tested for security, reliability, and digitally signed by default. All critical system drivers must be signed to be loaded into the kernel smoothly. On 32-bit systems, unsigned drivers will send a warning to administrators, but can still be loaded. On 64-bit systems, unsigned drivers cannot be loaded-period. Windows Vista even ships with a list of device drivers known to cause problems and not allow them to load.

The Windows Vista Device Driver Experience allows administrators to sign their own drivers and have the ability to restrict what devices and device drivers can be installed in their own environments. Administrators can even place a device driver on a network share and point managed computers to automatically install it.

User-Mode Driver Framework

According to Microsoft and Mark Russinovich, 99 percent of "blue screens" are caused by incorrectly written third-party device drivers. Windows Vista's new User-Mode Driver Framework (UMDF) is a new device driver methodology that attempts to prevent operating system crashes. With UMDF, a UMDF service running in the Local Service (not Local System) security context hosts all UMDF device drivers. UMDF drivers cannot directly access kernel mode code, memory, or hardware. Developers using the new UMDF host driver can be assured that their software additions will not compromise Vista's kernel causing critical operational errors.

Portable Media Device Control

Whether users can use portable media devices, such as USB flash memory drives, CD-ROMs, DVDs, and so on, can now be controlled. Administrators can decide whether to allow read-only or read and write access to the portable media, on a per machine or per user basis. Of course, settings can be controlled using group policy. This enables administrators to make theft of confidential data more inconvenient and makes injecting malicious code accidentally harder. The Device Manager applet contains a new Auto-play applet, which allows administrators to choose which media devices will allow auto-play or not.

ReadyBoost Memory

Windows Vista's ReadyBoost technology will also allow USB flash memory drives (256MB–4GB) and other memory cards (for example, SD memory, Compact Flash, and so on) to be used for additional page file virtual memory to increase Windows performance when more memory is needed. It's restricted to one device per computer, and the USB device must support USB 2.0 and fast memory transfers. All paging file data stored on the USB device is first stored on the local hard drive, and then cached to the USB device. All data stored on the USB flash memory device is automatically encrypted using 128-bit AES. When the device is unplugged, Windows Vista immediately drops back to using the local drive cache.

User Account Control

User Account Control (UAC) is certainly the most talked about security improvement to Windows Vista, and has the most end-user experience impact. Called User Account Protection during early development, UAC was created to minimize the risk of a user being logged in as an administrator when not conducting administrative business (e.g. browsing the Web, picking up e-mail, etc.). If regular end users and administrators were not logged in as members of the Administrators group all the time, the majority of all popular malware and hacker attacks would not work. Not running as an Administrator constantly is one of the most significant security improvement steps any Windows user can take.

However, if an end user isn't an administrator, it means she cannot install new applications, or easily manage her own environment. Previous versions of Windows could be very unfriendly for users without admin privileges. For example, non-admin users could not:

• Change their system time or time zone

• Change power management settings

• Change the default programs

• Install Internet Explorer add-ons or change security settings

• Create a share

• Add a printer

• Add a new device

With the exception of modifying personal profile and desktop settings, a non-admin user can't modify Windows much at all. And that is the intent. A non-admin user shouldn't be able to do anything that would affect the security of Windows. Unfortunately, most organizations would find their end users rioting if the end users could not install their own programs, drivers, and change system configuration settings.

The net effect of the way that previous versions of Windows handled admin versus non-admin users was that most companies made all their end users members of the local Administrators group. Microsoft didn't make matters better by making all newly created user accounts automatically members of the Administrators group by default on non-domain computers.

Windows Vista and UAC to the rescue! UAC ensures that even if a user is logged on with an admin-level account all the time, that they don't have administrator-level privileges enabled all the time. UAC works by assigning all admin users two security access tokens-one non-admin used most of the time and one admin only used when needed. UAC only enables Administrator privileges when needed and only on additional approval by the user.

Secure Desktop

Microsoft has gone to great effort to secure the desktop environment against malicious code and malware. Prior versions of Windows also had what is called the Secure Desktop. The Secure Desktop is where logon dialog boxes, password change dialog boxes, and so on show up. In Windows Vista, that is also where UAC dialog boxes show up by default. This prevents them from being dismissed by malware on the user's desktop.

When UAC dims the rest of the screen while you answer a UAC or application message you are actually seeing the Secure Desktop (see Figure 3). The OS actually takes a screenshot of your desktop, puts a gray mask over it, and displays that as the background behind the UAC dialog box. So, even if the user was able to move their mouse cursor or keyboard focus off the correct foreground object, there would be nothing to click on or to respond to. The background is an image with no real controls or objects. It's a brilliant idea that prevents many attack types.

Figure 3: The UAC elevation dialog box is on the secure desktop.

Mandatory Integrity Control

All security principals (user, computer, service, and so on), or processes acting on behalf of a security principal, and resources are now assigned an integrity SID in their access token. This is another huge improvement to Windows security, and is the keystone technology that allows Microsoft to implement UAC, Internet Explorer-Protected Mode, and many other significant advances. Understanding this new feature is critical for Windows administrators and security managers.

In all NT-class versions of Windows (i.e., NT, XP, Server 2003, Windows Vista, and so on), after a security principal logs on and is successfully authenticated, it is assigned an access token. The access token holds (among many items) the security principal's individual security identifier (SID), the SIDs of the groups they belong to, and assigned user rights. When a security principal or a process on behalf of a security principal attempts to access an object, the security principal's access token is handed over for inspection by the Windows security manager process (Lsass.exe). The access token essentially says, "This is who I am and the groups I belong to, and the rights I have." The Windows security manager compares to the access token to the object's access control list (ACL) to determine effective permissions.

Windows Vista adds a new integrity SID to the access token. Its value can indicate low, medium, high, or system integrity. All Windows objects (for example, files, printers, registry keys, and so on) are also assigned default integrity values. System objects are given the highest integrity rating of system. Most users and applications are given medium integrity by default. All normal Windows files and the desktop have medium integrity, but Internet Explorer running in Protected Mode, and all of its add-ons, toolbars, etc., run with low integrity.

When a security principal (or process) attempts to access an object, the security principal's and object's integrity SIDs are checked first. If the security principal's integrity rating is equal to or greater than the object's integrity value, then it is still possible for the security principal to write, modify, or delete the object, if the subsequent NTFS security permissions also allow it. If the security principal's integrity level is lower, the security principal will not be able to write, modify, or delete the object they are attempting to access regardless of their NTFS permissions. Integrity SIDs have precedence over NTFS permissions. This is an incredibly important feature.

The idea is that even if a malicious program is able to "break out" into a system, if it originates from a low or medium integrity process, it will have a hard time modifying the system files of Windows, as they are protected not only by an access control list, but also by the system integrity label. For example, Internet Explorer in Protected mode runs with low integrity. If malware exploits

Internet Explorer and then attempts to leverage that exploit into further compromising the system, the new integrity controls will make it much more difficult to accomplish.

This is yet again another security mechanism that will help prevent malware and hackers from modifying local system resources, especially if those attacks originate using Internet Explorer or on the user's desktop.

Improved File, Folder, and Registry Protection

Microsoft has invested significantly in preventing unauthorized access to files, folders, and registry keys located on Windows Vista. Many folders and files have moved or no longer exist. For instance, the \Documents and Settings folder where profiles and user documents are stored has become \Users. The All Users profile, which is applied for all logon users, has been moved out of the normal profile file (now \Users) and moved to %userprofiles%\public in the root directory, to simplify security on the individual user profiles.

Several potentially dangerous \Windows\System32 files, which all users could execute, have been removed, such as: tftp.exe, tlntsvr.exe, clpsrv.exe, ntbackup.exe, tsshutdn.exe, auditusr.exe, ddeshare.exe, rcp.exe, rexec.exe, rsh.exe, rsm.exe, and telnet.exe. Although why regular end users still have access to debug.exe, edlin.exe, and tskill.exe, still makes you wonder. There are plenty of new files in \Windows\System32, such as Atbroker.exe, Bcdedit.exe, and Bridgeunattend.exe available for users and hackers to explore.

NTFS Changes

Microsoft made several changes to NTFS (Windows NT file system), although most are continuations or improvements from previous Windows versions. NTFS is now more reliable. File or registry keys written to by Transactional NTFS (TxF)-aware applications can be rolled back if the write operation is incomplete for any reason. Making sure a transaction is complete before it is committed permanently is known as atomicity. Databases and Active Directory have had this for a long time; it's just new to NTFS files and registry keys.

NTFS now allows end users to create symbolic links. A symbolic link is a shortcut placeholder that, if chosen, will take the end user or program to another location or resource. NTFS has supported junction points (similar to symbolic links) for directories, but only if they were made programmatically, and even then only barely supported. However, junction points could only refer to local resources, whereas symbolic links can even point to remote resources. Windows Vista allows end users to make, manage, or delete symbolic links on files or folders using the new Mlink.exe utility. And symbolic links will show up in DOS directory listings (dir /ah) with a descriptor attached. In Windows Explorer, symbolic links show up with a modified folder icon (arrow jutting out from the left side).

Windows Vista now supports Previous Version file and folder restores on local files as well as network-based files. By default, the Volume Shadow Copy service is running and protecting files and folders on the system volume. The System Restore feature of Windows Vista regularly makes Restore Points before important events (for example, big installs, bootups, prior to patch updates, and so on), periodically if no big events happen, and can be made manually at any time (using the System Protection tab under the System applet).

Prior versions of System Restore Points made a backup of only Windows system files, but now it captures file and folder changes made under the \Users folder as well. If an end user accidentally makes a file or folder modification they did not intend, they can right-click the file or folder (or parent folder if they deleted the file or folder) and restore a previous version.

Creator Owners Can Be Prevented from Having Full Control

Object creators can now be prevented from automatically having Full Control over an object that they created. Windows Vista has a feature called Owner Access Restriction (OAR), which allows Administrators to define the default permissions given to a Creator Owner for a given resource or location. To do this, Microsoft had to add a Creator Owner access control entry (ACE) as an available security permission that can be modified and controlled.

Per Socket Permissions

Access control list permissions on a resource can be controlled on a per socket (http://www.en.wikipedia.org/wiki/Internet_socket) basis. Discretionary ACLs (security permissions) were available on a per socket basis starting with Windows Server 2003 SP1. Windows Vista allows System ACLS (SACLs) to be set on a per socket basis as well. Although non-programmers won't understand the security significance, it essentially allows programmers to prevent unauthorized applications and security principals from binding to an unauthorized socket. The overall effect can prevent some forms of malware from easily working.

New Built-in Users and Groups

Several new built-in groups have been added to Windows Vista, including:

• Cryptographic Operators

• IIS_IUSRS

• Event Log Readers

Other groups, like IIS_WPG and Power Users, have been deprecated.

File and Registry Virtualization

Many programs (and malware) require administrative access to \Windows\ System32, HKLM\Software, and other Windows critical areas to install and run. However, if given that type of access, they can literally modify Windows itself. Malware often does exactly that. The user is tricked into running a malicious program-perhaps by making him believe he is installing some harmless program-but instead, or in addition to that, the malware maliciously modifies Windows to install keylogging Trojans, backdoors, spyware, and identity theft mechanisms.

Windows Vista uses virtualization technology to permit legacy programs to run even though they do not have permissions to modify critical folder and registry areas. If a low or medium integrity program (by default most legacy programs are given medium integrity and Internet Explorer in Protected Mode is low) attempts to write to the most popular Windows critical areas, Windows Vista will redirect the writes (and reads) to a virtualized, per-user, copy of the file system and registry. So, although it appears to the low or medium integrity program as if they are accessing the normal folder and registry areas, they really are being redirected to a low integrity resource where it can do less overall harm. Virtualization can be enabled or disabled via group policy. By default, the following locations will be redirected to virtualized areas:

• \Program Files

• \Windows

• \Windows\System32

• \Documents and Settings

• HKLM\Software

Overall, Windows Vista's integrity controls and virtualization technology will further complicate malware exploitation.

Windows Resource Protection

Since Windows ME and Windows 2000, the majority of Windows system files have been protected from deletion and unauthorized modification. In ME, the protection was called System File Protection. In Windows 2000 and later, it is known as Windows File Protection (WFP). For example, if a user deleted the Wscript.exe file in the \Windows\System32 folder, it would "magically" re-appear a few seconds later. If a virus modified Kernel32.dll, the modified version would be replaced with an original, unmodified copy.

Although WFP was not created with the intent to defeat computer viruses, that's essentially what happened. If a computer virus modified any protected Windows file, Windows removed the infection by replacing the modified file with a clean copy. WFP wasn't perfect to be sure, but it did have its value, and did lead to the decrease in number of computer viruses. Computer worms and Trojans became more popular with malware writers because they don't rely on modifying legitimate host files to spread.

In Windows Vista, WFP is now called Windows Resource Protection (WRP). Like WFP, it prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Vista. But it does a better job. WFP wasn't prevention. It allowed the protected file to be modified or erased, but quickly responded to replace the modified or deleted file. WRP prevents the modification or deletion in the first place. Even the Administrator or elevated user cannot delete or modify system files. Only the Trusted - Installer Service can do so, subject to integrity controls and NTFS permissions.

Encryption Enhancements

Windows Vista improves upon Microsoft's previous encryption support. First, Windows Vista includes a Suite B-compliant crypto implementation (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm?MenuID=10.2.7). That means that the latest encryption algorithms are available, including kernel support for Asymmetric Encryption Standard (AES) and Elliptical Curve Cryptography (ECC). With kernel support for the newest algorithms, these algorithms can be used for things that in the past were impossible, such as IPsec. Consequently, the default IPsec configuration is to use AES-128 for encryption and SHA-1 for integrity. Diffie-Hellman Group 2 is used for key-exchange to maintain backward compatibility but organizations with a pure Windows Vista/Windows Code-name Longhorn Server deployment may elect to use several algorithms, including Elliptic Curve Diffie-Hellman, P-384 if processing overhead is no objective and security is paramount.

Microsoft has submitted not only its cryptographic providers, but also the code integrity module, BitLocker, the boot loader, and the OS loader validation against the Federal Information Processing Standard (FIPS) 140-2. Validation may take a year or more, however.

Protocols that had security issues in Windows XP are enhanced in Windows Vista, including Remote Desktop Protocol (RDP), which is used in Remote Desktop, Remote Assistance, and Terminal Services. In Windows XP and Windows 2000, RDP was not authenticated, meaning that it is possible to conduct man-inthe-middle (MitM) attacks against it and its encryption. While Windows Vista supports the legacy versions of RDP, the newer default version requires successful authentication first, before the encryption channels are negotiated.

EFS Enhancements

Encryption File System (EFS) was introduced in Windows 2000 and further improved in Windows XP Pro and Windows Server 2003. Available in the Business, Enterprise, and Ultimate editions of Windows Vista, newer EFS has additional improvements, including:

• Smart card integration (EFS keys can be stored on smart cards).

• Offline files are encrypted by user certificates, and not machine certificates as before. This means that if a system is stolen, offline files are actually encrypted with a token that is not present on the system, unlike in Windows XP. This is a significant security improvement in offline files; although the encryption is still only as secure as the user password it is based upon.

• Several new group policy settings.

• EFS uses client-side encryption/decryption (so that encrypted data from remote locations is protected when sent across network).

EFS still has plenty of legitimate competition when it comes to protecting confidential data, but for many environments it can provide a sufficient amount of protection without additional software or costs.

RMS-Integrated Client

Windows Rights Management Service (RMS) is a phenomenal product. Using asymmetric authentication and encryption, it allows access to documents and content to be controlled even after the document or content has been distributed. For example, if an employee leaves a company, their access to even existing documents on their hard drive can be removed with a click of the administrative mouse. RMS was released with Windows Server 2003, and XP Pro clients could download an RMS client. Now, an improved version is included by default. Longhorn Server will integrate RMS with Active Directory Federation Services to support cross-company protected collaboration.

Windows Vista will also include improved digital certificate handling and enrollment, and improved backing up and restoring credentials on local computer.

Unix on Windows

Windows Vista Enterprise and Ultimate contain an entire Unix-based environment capable of seamlessly running many Unix and Linux applications. The downloadable utilities even include the ubiquitous gcc compiler. Open source critics have wanted to pan Microsoft's Subsystem for Unix-Based Applications (SUA) from the beginning, but continuous testing has made believers. This means security administrators can run some of their beloved Unix security utilities on Windows Vista, and it also means another (foreign) area to monitor and secure if used by end user applications.

Improved Patch Management

Up-to-date patch management is necessary to secure any OS. Microsoft has included several patch management enhancements to Windows Vista.

Hot Patching and Restart Manager

Again, Microsoft promises fewer reboots. When Windows Vista patches are downloaded, the new Restart Manager examines the patches and determines what software and processes are affected by the update. As long as the patch does not update critical kernel code (for example, Kernel32.dll, Gdi32.dll, and so on), Restart Manager preserves the state of any opened data, stop the process, applies the patch, restarts the process, and restores the open data back to its previous state.

For example, suppose you are working in Microsoft Office when a Microsoft Word patch gets downloaded. Restart Manager asks the user for permission to proceed, saves the state of any current open Microsoft Word documents, closes the document, unloads Microsoft Word, applies the patches, re-starts Microsoft Word, and re-opens the documents into their previous opened state. Imagine, a patch upgrade to Microsoft Office taking only a few seconds, instead of having to close down, reboot the system, and re-open everything else.

Note

Released in Windows Vista, Windows Installer 4.0 supports the Restart Manager and UAC. No backwards compatibility is planned for previous versions of Windows Installer.

Improved Event Logs

It's hard to get excited about Windows event logs, but there are significant, real improvements to impress anyone who has had to sift through Windows event log messages. Event log improvements include:

• Significantly more event logs all collected in one place

• Improved messages with more detail

• Custom views

• XML formatting

• Running a task in response to a given event (called event triggers)

• More granular event logging

• Event forwarding (collecting events from one or more computers on a single collector computer)

Subscription and Forwarded Events

Microsoft has tried hard to collect more logs into one location. In the past, although the three (or five if you were on a domain controller) generic Windows logs were available in one location, nearly every other application and process had its own logs that were located in a different location.

In Windows Vista, there are dozens of logs by default, each attached to a process, application, or mechanism. For example, there are logs for Internet Explorer, User Account Control, Offline Files, Backup, Setup-related processes, and Group Policy. And vendors can add their logs to the centralized Event Log application.

Note

Sadly, the Windows firewall log does not appear in the Event Viewer or any of its log files.

Each event log message contains more detail and more understandable text (in most cases). Administrators can create customized views (see Figure 4) that pull out only particular events that meet a certain criteria. Events can be collected from multiple sources, both local and remote, and seen as one custom view. Custom view configuration files can be exported, sent, and imported to other computers. In addition, the log and the configuration file data are available in XML format for easy integration with databases and event log management systems.

Figure 4: The new Event Log interface is a vast improvement.

It is important to note that many events have been renumbered in Windows Vista. The rationale is that the events contain more data and a different schema for that data. Most event log management systems are driven by event IDs and changing the schema for existing event IDs would most likely break those event log management systems. Therefore events that have received a modified schema also have a new number.

Any single event log message can be right-clicked and then tied to particular response if it occurs again. By default, an event message can trigger the running of a particular program, sending an e-mail, or displaying a message.

Last, events can be forwarded to other computers or pulled (i.e., subscribed) from other computers. Forwarding and event log subscriptions require that the Windows Remote Management (WinRM) and Windows Event Collector (Wecsvc) services be running.

All-in-all, the Event Viewer application is significantly improved from nearly all angles. Unfortunately, all the improvements will not replace the fact that there are still unrecognizable error messages with little practical detail to help diagnose the real problem. Making sense of it all is not the event log's job, but unfortunately, nobody else seems to have picked up that dropped, and forgotten, gauntlet either.

Note

The Auditpol.exe command will show current audit policy, and replaces the Per-User auditing tool, Auditusr.exe, introduced in Windows XP SP2 and Windows Server 2003 SP1. Auditpol.exe can also be used to configure more granular event logging, such as if you only want to log logon events, but not logoff events. Run auditpol /list /subcategory:* for more details.

Task Manager

Even the security of Task Manager has been improved. Every process and its launching executable can be traced back to the original directory path. This was a feature sorely missing for years. Trojans will now have a more difficult time tricking administrators by hiding as Svchost.exe in C:\Windows\Fonts. You can also click any process and create a dump file, if you are of the hexviewing persuasion.

Increased Emphasis on Backup

A comprehensive security plan always starts and ends with an automated, reliable backup. Microsoft has improved its default backup application. Now named Windows Backup, it can back up the system and/or data to normal backup media (i.e., tape) or to optical disk, USB flash drive, or even to a network share. A complete system image backup can be created using the new CompletePC backup feature. It can be used to quickly restore a completely dead or lost hard drive or computer. A CompletePC restore can be initiated by entering the Windows Recovery Environment (discussed previously) and choosing Windows CompletePC Backup option. And, of course, System Restores and Previous Version restores can also recover user data (if section of the disk where the data is stored is not corrupted) in certain circumstances.