The Ultimate Guide to Windows 7 Security

Page 5 of 6

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 control

The 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.

| 1 2 3 4 5 6 Page 5
Shop Tech Products at Amazon
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.