TechNet Build’06TechNet Build’06

““The Secure Well Managed The Secure Well Managed Infrastructure Tour”Infrastructure Tour”

Desktop ManagementDesktop Management

Bruce CowperRick Claus

Canadian IT Pro AdvisorsMicrosoft Canada

Session GoalsSession Goals

• Introduce you to Desktop hardening• Discuss common scenarios of locking down a

desktop• Look at some of the tools available to help you

take control• Examine common scenarios for effective

Desktop Management.

Top Ten Immutable Laws for Top Ten Immutable Laws for SecuritySecurity

1) Nobody believes anything bad can happen to them, until it does.

2) Security only works if the secure way also happens to be the easy way.

3) If you don't keep up with security fixes, your network won't be yours for long.

4) It doesn't do much good to install security fixes on a computer that was never secured to begin with.

5) Eternal vigilance is the price of security.

6) There really is someone out there trying to guess your passwords.

7) The most secure network is a well-administered one.

8) The difficulty of defending a network is directly proportional to its complexity.

9) Security isn't about risk avoidance; it's about risk management.

10)Technology is not a panacea.

What Can I do?What Can I do?1) Focus on security concerns.

2) Make it easier to deploy secure desktops and servers.

3) Introduce methods for deploying updates and service packs from the start, and maintaining them.

4) Emphasis on securing computers from the start.

5) Focus personnel on need for ongoing vigilance.

6) Complex passwords from the start.

7) Focus on standard, well documented desktops and servers.

8) Simplify desktop/server creation and maintenance.

9) Introduce risk assessment; focus on how to weigh and consider security risks.

10) Embed security policies and procedures into builds and maintenance.

Establishing Hardened Baselines Establishing Hardened Baselines for Workstationsfor Workstations

Workstation HardeningWorkstation HardeningGeneral Rules• Deploy secure systems, don’t try to make them secure

after the fact– If you don’t know what you have, you can’t protect it

• Keep it Simple– Make it easy to deploy (images, scripts)– Make it easy to maintain (automatic updates, SMS)– Eliminate unneeded applications and services

• Develop change procedures for desktop image builds; track and justify all edits to the defaults

• Establish your baseline, benchmark typical performance, monitor against that

Workstation HardeningWorkstation Hardening8 Basic Steps to Hardened Baselines

1. Decide upon baseline applications– Enterprise-wide: what goes on every desktop?

Every server? – Check for known security problems with those

applications

2. Decide which Components to include– Add/Remove Programs options

Workstation HardeningWorkstation Hardening8 Basic Steps to Hardened Baselines

3. Decide which Features to enable– Technologies beyond what is available in

Add/Remove Programs (such as Windows Update)

4. Decide what Security Template settings to include– Use Security Guides as the foundation– Don’t forget custom settings beyond out-of-the-box

(sceregvl.inf)

Workstation HardeningWorkstation Hardening8 Basic Steps to Hardened Baselines

5. Decide on Additional Lockdowns– Drawn from Product Group recommendations,

security alerts, security experts, best practices– Group Policy beyond Security Templates (Internet

Explorer, Outlook, etc.)– Services (varies according to role)– Access Control Lists (ACLs)– Windows Firewall can be configured as part of build

(new in Windows XP SP2)

Workstation HardeningWorkstation Hardening8 Basic Steps to Hardened Baselines6. Automate / Document the entire build

– Even if bit-copy images are the end result– Scripts are accountable; people are not so

easily queried (Examples:)• Answer File for Operating System• Silent non-interactive installations• Security Template INF• Windows Scripting Host (WSH) and Windows

Management Instrumentation (WMI)• Custom Installation Wizard for Office• Internet Explorer Administrative Kit for IE

Workstation HardeningWorkstation Hardening8 Basic Steps to Hardened Baselines

7. Test Logged in as Normal User (workstations)– By far the greatest numbers of application failures

occur logged in as Normal User– Even developers should run as Normal User and

elevate privileges only when and if required– Must solve incompatibilities before deployment

8. Scope out Administrator and Service Account Access

Security Templates

Use a Security GuidelineUse a Security Guideline• Microsoft Security Solutions (MSS) Security

Guidelines and Guides– A standard– Auditors like them– They are tough, thorough, and accepted– Variants of these security templates have been used in

some of the strictest security environments known– Developed by personnel who simulate attacks on

networks for a living– MSS Security Templates for Government Security

replacing NSA Templates

Available Scenario TemplatesAvailable Scenario Templates

• “Implementing Common Desktop Management Scenarios with the Group Policy Management Console”– Lightly Managed – Mobile – Multi-User – AppStation – TaskStation – Kiosk

• Used with the GPMC

Group Policy Beyond Security Group Policy Beyond Security TemplatesTemplates

Group PolicyGroup PolicyGroup Policy Management Console

• Security decisions should not stop with security templates – Windows Update– Secure Terminal Services– Office Preferences

• Prior to GPMC, only third party options for exporting Group Policy settings beyond the security template INF file

• Custom ADM files can be built– Extension of Group Policy choices to include

customer’s own registry edits

Group Policy – Common Desktop Scenarios

ServicesServices

Locking Down ServicesLocking Down Services

• Dump running services from a typical baseline– Net start > services.txt

• Study results for the following:– Which services require an account to start?

• Will a local account work?• Narrowly define permissions account requires• Audit for activity against that account in the future

– Which services are unnecessary?• Start with Security Guides list of services to disable

• Maintain settings in security template

Access Control ListsAccess Control Lists

Access Control Lists (ACLs)

• Extensive ACL edits have been done in the past to harden systems– Particularly on NT and 2000– NSA led the way– File and Registry Permissions– Not as necessary with Windows 2003 (if it doesn’t have to

support legacy trusts); Security Guide does not recommend ACL edits for W2K3

• Rough summary of typical edits:– Substitute Authenticated Users for Everyone (Anonymous SID

exposure)– Remove unused or more exposed groups such as Power

Users from all ACLs– Remove Batch or Interactive ACLs on particularly vulnerable

executables

Limit AccessAdministrator and Service Accounts

Limit and Control AccessLimit and Control Access• All the protection in the world can be circumvented by

poor Administrator and Service Account maintenance and monitoring

• Most attacks are internal• Most users and even administrators do NOT require full

administrator status to get their jobs done– Example: developers can do most of their development

logged in as a Normal User, and should be encouraged to do so

• Use of Run As to elevate privileges ONLY when required for a specific task

Limit and Control AccessLimit and Control AccessAdministrators• Train Administrators to use passwords with more than 15

characters– Phrases are easy to remember (spaces allowed in 2000 and 2003)

• Make sure all Administrators have at least two accounts – Normal User for daily tasks (e-mail, word processing) – Separate account with Administrator permissions (audit this

account closely)

• Consider using local groups on individual servers to limit who can administrate

Limit and Control AccessService Accounts• Use passwords with more than 15 characters and

extended characters (Alt + Numbers)• Limit the damage if the account is compromised

– See if a local account can be used instead of a domain account• However, won’t work for accounts that must communicate with

other servers • SQL agents, for instance, often require connectivity to other

servers– Narrow permissions of what the account can do

• Audit these accounts closely

Workstation ApplicationsWorkstation Applications

How to Choose Secure Applications• Keep the focus on the lowest common denominator:

what must be on every desktop? Every server?• Research for security breaches on all software planned

for installation (not just the operating system)• Gather the necessary updates and patches

– Windows Update Catalog – Microsoft Security Alerts– Vendor sites for third-party applications– Forums and sites like http://www.securityfocus.com and http://

Groups.google.com

Choosing Components

• Choose as few components as possible• Set to No (do not install) even if that is the

default (for accountability later)• Avoid installing IIS on the workstations • Avoid commonly attacked components, such as

FTP, Simple TCP/IP, and SNMP

Commonly Encountered Commonly Encountered ProblemsProblems

Applications Won’t RunApplications Won’t Run• Biggest problem with desktops• Usually legacy applications that are unaware of

security contexts– Symptom: Runs as administrator, fails as Normal User– Doesn’t understand profiles– Often due to more restrictive file and/or registry

permissions in the new OS– Occasionally due to hard-coded calls to previous

operating system APIs

Applications Won’t Run (cont)Applications Won’t Run (cont)• Windows XP SP2 introduced new, secure-by-

default changes– RPC Interfaces no longer allow anonymous remote

connections by default– DCOM Remote Launch and Activation limited to

administrators by default– Windows Firewall on by default– Access to system services using RPC blocked by

default

SolutionSolution Applications Won’t Run

• Ideally, upgrade or re-develop, but this can be prohibitively expensive

• Use Application Compatibility Toolkit on Windows XP– Construct a custom SDB fix– Work with Compatibility Modes to emulate other operating

systems• Use Sysinternal’s regmon.exe and filemon.exe to isolate

permissions– Develop a custom INF to loosen the necessary settings

• Goal: Figure out the minimal settings necessary to get the application running

Filemon & Regmon

Configuration Management of Configuration Management of Security TemplatesSecurity Templates

• Ongoing changes will be inevitable, particularly to manage desktop application requirements

• Security settings should evolve as the environment does– Example: NT 4.0 trusts go away

• Complexity and number of settings makes this a challenge

Solution Solution Configuration Management of Security Templates

• Layer security template deltas1. Start with standard MSS template

2. Overlay Customer Delta from security standard

3. Overlay Application specific loosening of ACLs• Make it clear what was adjusted for each application• Can remove template if application goes away later

• Merge everything at the end; but maintain original files to provide accountability

• Auditors receive deltas with justifications for the changes; much faster certification

Challenge: INFs Don’t Capture all Challenge: INFs Don’t Capture all Security Related SettingsSecurity Related Settings

• Security Template INF files have limited scope• Need to extend Group Policy into other areas

such as:– Secure e-mail settings– Internet Explorer settings– Windows Update client settings

• Need to be able to transport these settings to other systems easily

SolutionSolution INFs Don’t Capture all Security Related Settings

• Extend choices through use of ADMs1. Run Group Policy (gpedit.msc)

2. Right click Administrative Templates, choose Add/Remove Templates, pick the ADM file (e.g. Outlook ADM file)

• Can be added as part of the build (locally) OR• Distributed via GPOs and AD• Can add custom settings

Rollback Security SettingsRollback Security Settings

• Need to be able to confirm whether a reported problem is due to the security templates

• If Access Control List (ACL) edits have been made, these “tattoo” the system permanently, even when a GPO is used– How to roll back to out-of-the-box permissions?

• Need to be able to do this on a standalone system

SolutionSolution Rollback Security Settings

• Utilize INF files that are applied as part of the original setup of the operating system:– Defltwk.inf– Defltdc.inf– Delftsv.inf

• Can be loaded like any other security template: via MMC Security Configuration Editor or secedit.exe

Security Analysis tool

Microsoft Security Solutions Microsoft Security Solutions (MSS) Security Guides(MSS) Security Guides• Windows 2000 Hardening Guide, Windows XP and

Windows 2003 Security Guides available• Threats and Countermeasures• Security Templates• Custom sceregvl.inf• Guides coming out for all key Microsoft enterprise

systems, such as Exchange 2003

• Best common sense, field tested source for security lockdowns

Secure Configuration Resources: Tools• Setup Manager• Security Template Snap-In• Security Configuration Editor Snap-In• Secedit.exe • Group Policy Management Console• Security Configuration Wizard• Application Compatibility Toolkit• Sysinternals Regmon and Filemon

Questions and AnswersQuestions and Answers

blogs.technet.com/canitproblogs.technet.com/canitpro

© 2004 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.