The ultimate guide to Windows 7 security
- — 21 April, 2010 20:28
Multiple active firewall policies . Prior to Windows 7, when a user had multiple network interfaces active, only one Windows Firewall profile (i.e. Home, Domain, Work, or Public) could be used. This created potential security vulnerabilities, such as when a computer was both wired to the local network domain and connected to a less restricted wireless network. Windows 7 can now detect multiple networks and apply the appropriate firewall profile to the right interface.
Improved System Restore. System Restore now includes the user's personal content files. Older versions backed up and protected only the Windows system files. System Restore also allows you to see what files would be restored in each version of the System Restore files. It's not perfect, but it's nice to see what will occur if you were to choose a particular restoration point.
Smooth remote access . DirectAccess allows remote users to securely access enterprise resources (such as shares, Websites, applications, and so on) without connecting to traditional types of VPNs. DirectAccess establishes bidirectional connectivity with a user's enterprise network every time a user's DirectAccess-enabled portable computer connects to the Internet, even before the user logs on. The advantage here is that users never have to think about connecting to the enterprise network, and IT administrators can manage remote computers even when the computers are not connected to the VPN.
Once DirectAccess is enabled, when a user's computer connects to the Internet, it's as though he or she is on the organization's local network. Group policies work, remote management tools work, and automatic push patching works.
Unfortunately, DirectAccess has fairly involved requirements, including Windows Server 2008 R2 (to act as the RAS server), Windows 7 Enterprise or Ultimate clients, PKI, IPv6, and IPSec. But as companies put the necessary pieces into place, they should look into using DirectAccess as their default VPN technology for Windows 7 and later clients.
Managed Service Accounts . Service accounts are often highly privileged, but difficult to manage. Best-practice recommendations dictate changing service account passwords frequently, so as to avoid the risk of password attacks. However, Windows service accounts often require two or more coordinated, synchronized password changes in order for the service to continue running without interruption; prior to Windows 7 and Windows Server 2008 R2, service accounts were not easy to manage. If a service account is enabled as a Managed Service Account, Windows will take over the password management and simplify management of Kerberos SPN (Service Principal Names).
Like DirectAccess, Managed Service Accounts have a lot of requirements, including a schema update and mandatory use of PowerShell 2. Still, if service accounts are a hassle in your environment -- and you know they are -- consider enabling this new feature when your infrastructure is prepared.
Virtual Service Accounts . Virtual Service Accounts (VSAs) are related to Managed Service Accounts in that Windows takes over the password management. However, VSAs are for local service accounts and don't require a schema update or nearly the amount of effort to configure and use.
When a VSA controls a service, the service accesses the network with the computer's identity (in a domain environment), which is much like what the built-in LocalSystem and Network Service accounts do, except that VSAs allow each service to have its own separate security domain and corresponding isolation.
Creating a Virtual Service Account is pretty easy. Open the Services console (services.msc) and modify the service's logon account name so that it's the same as the service's short name, such as ex. NT SERVICE\ServiceName$. Then restart the service. That's it.
When the infrastructure can support it, consider using Managed and Virtual Service Accounts functionality to manage service account password security.
AppLocker application controlThe leading cause of malware infections may surprise you. Most machines aren't exploited due to missing patches (although this is the second biggest cause), unpatched zero days (almost never a factor), drive-by downloads, or misconfigurations. Nope, most systems are infected because users are duped into intentionally installing programs that a Website or email says they need. These socially engineered Trojans come in the guise of antivirus scanners, codecs required for a media player, fake patches, and just about any other bait the bad guys can concoct to lure end-users into installing their Trojan executable.
The most effective means of thwarting these threats in an enterprise environment is preventing end-users from installing unapproved programs. If you leave the decision up to end-users, they will almost always make the wrong choice. If they didn't, malware wouldn't be nearly as common as it is today.
Microsoft's most sophisticated solution to the problem is AppLocker, an application-control feature included in Windows 7 (Ultimate and Enterprise editions) and Windows Server 2008 R2. AppLocker is an improvement on the Software Restriction Policies (SRP) introduced with Windows XP Professional. AppLocker allows you to define application execution rules and exceptions based on file attributes such as path, publisher, product name, file name, file version, and so on. You can then assign policies to computers, users, security groups, and organizational units via Active Directory.
Configuring AppLocker. You can configure AppLocker locally using the Local Computer Policy object (gpedit.msc) or via Active Directory and Group Policy Objects (GPOs). AppLocker relies on the built-in Application Identity service, which is normally set to manual startup type by default. Administrators should configure the service to start automatically.
Within the local or group policy object, AppLocker is enabled and configured under the \Computer Configuration\Windows Settings\Security Settings\Application Control Policies container.
By default, AppLocker rules do not allow users to open or run any files that are not specifically permitted. First-time testers will benefit by allowing AppLocker to create a default set of "safe rules" using the Create Default Rules option. The default rules authorize all files in Windows and Program Files to run, along with letting members of the Administrators group run anything.
One of the most notable improvements over SRP is the ability to run AppLocker against any computer using the Automatically Generate Rules option to quickly create a baseline set of rules. In a few minutes, dozens to hundreds of rules can be produced against a known clean image, saving administrators anywhere from hours to days of work.