In many-layered defense approaches, you will find a hardened desktop somewhere in the architecture. Many security experts consider the hardened desktop a necessity but it can be a very difficult task to achieve.
If you're like most organizations, users have had the luxury of installing whatever they like, whenever they like. What's more, in large enterprises with heterogeneous business units, you have departments installing all sorts of unsupported applications.
This cobbled together application environment then becomes part of the business process, even though the applications were never part of the design cycle. Situations like this make the hardened desktop approach one of the most difficult layers to deploy in your defense architecture.
Decisions, Decisions...https://o1.qnsr.com/log/p.gif?;n=203;c=204660766;s=9477;x=7936;f=201812281312070;u=j;z=TIMESTAMP;a=20392931;e=iYou have several options on the table when it comes to hardening your desktop. You can buy a COTS (commercial, off the shelf) product to manage desktops. You can download free templates from the Center for Internet Security or NIST or the like. You can use Active Directory's group policy or you can simply lock down host via the local security policy.
Your requirements will drive the approach you adopt, but most large organizations will need a centrally managed solution to accomplish the task.
Let's start with a manual workstation lockdown.
When defining a local security policy you will be working in the following areas: Account Policies, Local Policies, Event Log, Restricted Groups, System Services, Registry and the File System. Once you have a working hardened image, you can then deploy it out across your enterprise.
Make sure that your baseline image does not interfere with supported enterprise apps or you will be going through the lockdown phase many more times than you will like.
MMC to the Rescue
Let's start a Microsoft Management Console (MMC) by doing the following:
- In the run field, type MMC then hit Enter.
This gives you a blank MMC template. Select the Add/Remove Snap-Ins command from the console's File menu. Click the Add button on the Add/Remove Snap-In properties sheet. Scroll to the bottom of the list, select the Security Configuration and Analysis option from the list, and click the Add button. Then click Close and OK.
Create a database. Right-click the console's Security Configuration and Analysis container in the left pane. Select Open Database. Enter a database name in the File Name field of the Open Database window. Click Open.
You will notice 3 canned templates (basic, medium and high) that you can choose from. Microsoft's website can tell you the exact lockdowns that each template provides. Needless to say, be careful here when selecting a template.
Be sure that you select a workstation template and not a server template. Workstation templates end in "WS" and "WK". You can also get pre-defined templates from the Center for Internet Security and other organizations that provide lockdown templates.
Again, be sure you know what each will do before you apply a template.
Browse the tree and check the recommended database settings against your current settings.
To modify a setting, double-click the item in the right pane. The Properties window will appear. Make changes to the item as desired. To disable the setting, deselect the Define This Policy in the Database check box.
After making all changes, save the template. Right-click the console's Security Configuration and Analysis container in the left pane. Click Export Template. Enter a name for the template in the File Name field. Click Save. You can then copy this file to other computers to apply uniform settings across the network.
To apply security settings based on the template on the workstation, right-click the Security Configuration and Analysis container and select Configure Computer Now. Enter the path to the error log file. Click OK to apply the template.
Reboot the workstation and the policy will be in place.
Again, this is just one way to create a hardened image. Now deploying this image can be done with any of your enterprise tools such as SMS, login scripts (using the secedit.exe tool available free from Microsoft) or simply visiting workstations and manually applying the changes.
With Group Policy, an administrator can choose a vast array of configuration settings throughout an enterprise, which are applied against users and computers based on the following membership hierarchy:
- Organizational Unit
Security settings within Group Policy can be manipulated by editing or creating a new Group Policy Object (GPO) from within an MMC snap-in that contains both the Group Policy Editor and the Security Settings extension. The security settings available depend on the type of object to which the group policy is linked (for example, domain objects and local objects do not have all the same settings).
Most security settings in Group Policy are available by double-clicking Administrative Tools in Control Panel, double-clicking Computer Management, double-clicking System Tools, double-clicking Group Policy, double-clicking Computer Configuration, double-clicking Windows Settings, and then double-clicking Security Settings. An administrator can manually define attribute settings or import an existing security template.
As you have noticed by now, that is a lot of double-clicking. Rest assured, the results are well worth the effort.
Once you have a policy in place, it is important to keep your eyes open for conflicts as there will certainly be a trade off between fewer Level 1 helpdesk calls and complex Level 3 incidents.
If you can successfully temper your environment with a good hardened image that isn't restrictive enough to break your business processes, you will certainly see the benefits of hardening the desktop almost immediately.
This article was first published on EnterpriseITPlanet.com.