Re: Improving the Security of Windows Platforms

[Melissa Guenther <mguenther () COX NET>]

An applicable tools that would fit under educational material could include
How to Use the Internet for Research. 
 
-------Original Message-------
 
From: The EDUCAUSE Security Discussion Group Listserv
Date: 03/19/04 14:21:34
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: [SECURITY] Improving the Security of Windows Platforms
 
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).  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/.