Improving the Security of Windows Platforms

[Rodney Petersen <rpetersen () EDUCAUSE EDU>]

I am writing to report on the ongoing effort to establish a dialog
between Microsoft and the EDUCAUSE/Internet2 Security Task Force.  A
delegation representing the Task Force visited with officials from the
Microsoft Security Business Unit in September to discuss security
practices, vulnerabilities and future plans.  The planning for this
event began in the Summer and became all the more urgent following the
events of August and September.  

There have been a series of ongoing meetings and discussions over the
past several months where we learned more about Microsoft's plans and
conveyed the concerns and needs of institutions of higher education.  We
are optimistic that several of the problems identified will be remedied
in the forthcoming XP SP2
(http://msdn.microsoft.com/security/productinfo/XPSP2/default.aspx
<BLOCKED::http://msdn.microsoft.com/security/productinfo/XPSP2/default.a
spx> ).  Nonetheless, we will monitor progress and continue to engage
Microsoft on the security needs of higher education institutions and
home users.

Below is a draft of our suggestions for "Improving the Security of
Windows Platforms" that has been the subject of numerous discussions.
It was recently submitted to Microsoft for their consideration.  I
wanted the participants of the Security Discussion Group to be aware of
the steps we've taken.  Additionally, I invite you to review the
document and let us know if you have any feedback.

Thanks,

Rodney Petersen
Security Task Force Coordinator, EDUCAUSE



DRAFT

IMPROVING THE SECURITY OF WINDOWS PLATFORMS

EDUCAUSE/Internet2 Computer and Network Security Task Force
March 4, 2004


The EDUCAUSE/Internet2 Computer and Network Security Task Force, on
behalf of the Higher Education community, offers the following
suggestions for improvements in security and integrity of Microsoft
Windows platforms.  While the suggestions are aimed at the Windows
operating system, many of them can be applied to other Microsoft
products.  They are intended to complement, not replace, Microsoft's
other security initiatives.  We believe that implementation of these
suggestions would be of significant value to all market segments, not
simply Higher Education.

Poor computer security is one of the greatest challenges in Higher Ed
information technology today, and arguably one of the greatest risks to
Microsoft's business.  We have a common interest in improving this
situation and look forward to serious responses and thoughtful
discussion of each suggestion, leading to consensus on implementable
ideas and an aggressive timetable.

We are especially anxious to offer clarifications of any suggestions
deemed unclear, and to engage in discussion about any deemed unsuitable
for Microsoft's entire customer base.  Colleges and universities reflect
the broadest possible spectrum of IT scenarios, with both tightly
managed and totally unmanaged populations of computers of varying
vintage.

Our suggestions fall into 6 categories:

                * Improve management of access and privilege at the
local platform level

                * Provide better defenses at the platform perimeter,
including sensible defaults

                * Make transport level security and encryption the
default wherever possible

                * Facilitate software updates and patch management for
site-based customers

                * Enhance both platform and group management
capabilities

                * Create effective educational materials for
non-technical users

Most of our suggestions should be assumed to include an implicit request
for improved configuration and management via Group Policy, particularly
with regard to the Internet Connection Firewall. Moreover, the User
should not be able to override Group Policy without explicit permission
from the GP manager.


1. LOCAL SYSTEM ACCESS MANAGEMENT

1.1 Changes Impacting the Administrator Account

1.1.1 Require all accounts to have a strong password (non-null, with
sufficient complexity), or at the very least require every account with
privileges greater than 'user' to have a strong password.

1.1.2 Use the 'principle of least privilege' so that the User does not
normally run in "Admin mode".  In particular, modify the software
installation model to ask for the Admin password at the time some
privileged action is attempted, e.g. installing patches or updates.

1.1.3 The requirement for escalated privileges is also a HUGE problem
with applications, both from third-parties and Microsoft.  Microsoft
should make strong efforts to discourage vendors from requiring admin
privileges to run an application.

1.1.4 The next time Microsoft releases a new ADM file which extends the
Group Policy editing UI there should be a setting to easily deny the
SeNetworkLogonRight to the local administrator account. This would
enable customers to prevent, in many cases, the use of the local
administrator account over the network. Note that this does not prevent
a user account that is a member of the local administrator's group from
having the ability to be used over the network.

        Making this change lowers that attack area exposed by the
administrator account in many situations. This is useful since it is
relatively easy for an attacker to determine the current username or SID
of the built-in Administrator account. Furthermore, the use of this
setting should encourage the use of well defined user accounts for
remote system administration which should provide customers with a much
better audit trail to determine who made what changes to a system.

1.1.5 Some applications still consider the passing of the Administrator
username and password over the network an interactive logon. Microsoft
should phase this out, and ensure that it is properly detected as a
network logon. As an example, Microsoft has made this change with the
advent of IIS 6.0. However, Remote Desktop and Terminal Services still
consider a network logon to be an interactive logon.  Microsoft should
perform an internal audit regarding this issue and publish a document
which clearly states to customers which products improperly distinguish
between network and interactive logons.

1.2 Routinely make greater use of "auditing."  Auditing is crucial to
determining what is occurring or might have occurred on any given
system.  

1.2.1 Auditing should be enabled by default with basic values for each
audit setting defined reasonably to be useful while avoiding collecting
too much data. e.g. that that might be sensitive in certain
environments.

1.2.2 Microsoft should work with EDUCAUSE, and others, to develop some
standard audit policy templates for vertical markets, and provide a
mechanism to install and apply a chosen default policy during operating
system installation.

1.2.3 Improve the event logging functionality, particularly with regard
to security logging.  Every event with a remote source should have the
IP address logged.  This feature should be added to all currently
supported versions of Windows.  All security related events should be
logged at a basic level detail, particularly failures.

1.2.4 Microsoft should provide a freely available tool to log events in
real time to a central server. The tool should send the information via
the syslog or "reliable syslog" protocol.

1.3 Consider what additional things might increase the "hassle factor"
for hackers, e.g. not revealing the account list, etc.


2. NETWORK ACCESS AND PERIMETER DEFENSE

2.1 By default, deny incoming connections to all but a minimum number of
necessary service ports via an integral firewall.  While this is
believed to be resolved in Windows XP SP2, Windows Server 2003 and all
future Microsoft products will benefit from this proposal.

        For standalone and home machines, by default only a minimal set
of necessary ports should be opened.

        For machines that are joined to a domain, the default settings
should come from Group Policy and the domain administrators should have
the ability to grant or deny permission to users to reconfigure their
local firewall.

2.2 Fix the firewall protection gap.  The IP stack must not become
active until the firewall is also active, whatever that takes. This gap
now occurs at boot time for about 10 seconds.  This has been known to
allow machines to become infected.

        While we understand this will be fixed in Windows XP SP2,
Windows Server 2003 and all future Microsoft products will benefit from
this proposal.

2.3 Provide functionality to immediately place the computer in a mode
where all (not-already-established) inbound connections are denied, and
which permits outbound connections only to the Windows Update service
and/or other site(s)/port(s) as configured by the user or Group Policy.
This functionality could/should be provided by the built-in firewall.

        The default state for a newly built machine should be this
protected mode.  User or Group Policy could change the restrictions
after the machine becomes operational.  This restricted mode should also
be accessible from the 'F8 menu' during boot, and via a Windows-key
combination whenever Windows is loaded.

2.4 Extend the functionality in 2.3 to provide a set of configurable
network security profiles.  The profile would define what programs,
services, and users could access the network and where they are
permitted to go.  Inbound traffic would be restrictable in a similar
way.  Configuration may be set by the user, via Group Policy, or through
a trusted mechanism similar to that which is used for Web Proxy
Auto-Detection (WPAD).

2.5 Enhance or refine the interactions between the built-in firewall and
applications that want to do something prohibited by current rules.
E.g. give users the option of opening the port just for the session, or
for a fixed time interval, or "forever" (but with periodic reminders
about ports left open.)

2.6 Make it easy for users to establish their own local perimeter
defense via access lists. (Important if they need to run insecure
protocols within their workgroup.)  The access list should accept IP
addresses, CIDR ranges, or broadly defined groups such as "all computers
in the domain/workgroup my computer is in", or specific machines by name
(that get translated to GUID so that things work seamlessly even after a
machine rename)

        The whole UI for setting up ACLs needs a lot of work.

2.8 Facilitate the application of Group Policy assignments to computers
across the perimeter.

        In the Higher-Ed environment, as with many others, it is common
for machines to travel back and forth across the network perimeter.
Unfortunately, the complete processing of Group Policies, including
software assignments to machines, is greatly impeded by stronger
perimeters. Although many VPN solutions exists which enable a user to
authenticate and tunnel through the perimeter, few solutions properly
tackle VPN authentication of the machine's account to the VPN so that
full group policy processing can occurring during machine startup. Some
of the group policy processing can only be done at startup, so this
creates a catch-22 situation for many customers.

        Microsoft's CMAK (Connection Manager Administration Kit) can be
used to manage this problem in a homogenous Microsoft environment. It
requires the Microsoft VPN and Microsoft Certificate Services. It also
requires that the machines were boot strapped inside the perimeter.
These requirements are not acceptable to some Higher-Ed sites. We would
like to see Microsoft develop a more generic solution in conjunction
with some of its 3rd party partners such as Cisco.


3. TRANSPORT ENCRYPTION

3.1 By default, use IPSEC standards wherever possible to identify
servers and/or protect transmissions, etc.  The existing configuration
interfaces need to be vastly improved and functionality added to 'sanity
check' the new settings before they are implemented.  It's far too easy,
currently, to render a domain unusable due to overly secure IPSEC
configurations.

3.2 Enhance the ICF and/or "IP Security" capabilities to allow blocking
based on whether the connection was initiated by the workstation or not.
For TCP this may only require enhancing the filters to block on "initial
connection" (SYN) packets, but for UDP it requires maintaining flow
state.  Final behavior of Windows XP SP2 may affect this proposal;
however, Windows 2003 and future products should benefit from the same
capabilities.


4. SOFTWARE UPDATES AND PATCH MANAGEMENT

4.1 Make CD-ROM images available for download so that campuses can burn
their own patch/update CDs, at least for campus owned systems.  There
should be a variety of images available, including ISO images that
already have the patches applied.  We often require systems to be
completely reformatted and reinstalled when the system has become
compromised and should not have to reinstall all updates and patches
again as well.  We do understand that access to certain images may need
to be controlled in order to conform to licensing agreements.

        At the very least, the equivalent of the "critical update"
patches, etc. should be available this way.

4.2 Security-related patches or updates should not require "the original
CD" !!  (c.f. the Office security patches)

4.3 Provide or identify a set of tools that will probe a system for
vulnerabilities, perhaps by severity level so a subset could be done
quickly.  These tools would be used either (a) the first time a new
machine is seen on the network, (b) every time a machine connects to the
network, or (c) on demand by the user by going to a trusted web site
(preferably locally).  Make sure these tools provide consistent results!

4.4 Create an event log entry for whenever a windows update or SUS site
was visited (include its name), and if the machine received a clean bill
of health (no updates to install).  This info could be used in domain
logon scripts and VPN quarantine scripts to quickly identify how
up-to-date a machine is regarding OS patches

4.5 Microsoft has made great strides in improving patch management with
Microsoft Update and SUS, however, we would also like to see Microsoft
provide an easy to configure, free, service that could be used to keep
the images on a customer's BINL (RIS) server up to date.


5.  SYSTEM MANAGEMENT ISSUES

5.1 Develop a "dashboard" tool with "idiot lights" or other activity
indicators that could alert users to unexpected actions on their
machine.  This might require hooks into state variables and/or counters
in the OS.  All events should be logged in detail.

5.2 When evil traffic is encrypted, the only security management hooks
will be in the end-system.  Microsoft needs to anticipate this scenario
and figure out what kinds of behavioral/threshold or other kinds of
system/security management data we need to be able to get from the
end-host stack to determine whether bad things are happening or not.
e.g. Bagle next-gen worm infection that is using encryption on port 443
to hide it's traffic.)

5.3 Provide improved hooks, as necessary, to increase the capabilities
of Group Policy to manage (or not) all aspects of a system that has been
joined to a Domain.  While some specific areas have been noted above,
this proposal is a broad request for improvements throughout the
Microsoft product line.

        For example, it should be possible to create a GPO that
specifies a set of ports as 'closed'.  A user for a machine covered by
that GPO should not then be prompted to open the port when an
application tries to use it.  This will break some applications,
however, that's the actual intent: managed systems cannot be left to the
mercies of users who don't know enough of the implications to make
reasonable decisions regarding the security of their system.

5.4 In cases where an unchangeable externally set policy (e.g. Group
Policy) breaks an application or functionality, by default the user
should be presented with a dialog to that effect.  The functionality to
control this error message from within the Group Policy, including
disabling it, may also desirable.

5.5 Support tools or ways in which sites can provide "preferred
configuration settings" for platforms that they manage.  For example, a
site-managed web site that provides a "set site defaults" button.
Clearly such a capability must be protected carefully, to avoid problems
such as hackers turning off all protection.  Probably this function
should be available only when operating in "network safe" mode (see
Section 2.3).

5.6 Universal Plug And Play (UPNP) presents serious security
implications which must be understood and considered very carefully in
all environments.  Higher Ed would like to work further with Microsoft
to better understand the capabilities, security implications, and
safeguards.


6. USER EDUCATION AND SECURITY AWARENESS

6.1 Work with Higher Ed to create effective educational materials to
increase (a) understanding of what a computer is, and (b) security and
"good driving" principles.  Written, streaming video, CD-ROM, and DVD
versions should be available.  A goal is "technology literacy" as well
as doing the right thing with regard to security and configuration. The
resulting material should be freely reproducible.


Acknowledgements

The principal authors of this document were Terry Gray (Univ. of
Washington), James Morris (Univ. of Washington), and David Wasley (Univ.
of California).  Significant comments and improvements were suggested by
Paul Hill (MIT).  The original genesis of this document was Terry Gray's
"Seven Point Plan for Improving Windows Security" and subsequent
discussions with Microsoft in September, 2003 and January, 2004.  Thanks
to Diana Oblinger (Microsoft) and Rodney Petersen (EDUCAUSE) for
narrowing the gulf between our respective communities.


**********
Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at 
http://www.educause.edu/cg/.