Re: Improving the Security of Windows Platforms

[Davina Pruitt-Mentle <dp151 () UMAIL UMD EDU>]

I  would like to see a stronger statement related to the last entry--e.g.,

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.  Student, Faculty, Staff and educators
understanding of the causes and effects of viruses, Trojan horses, etc.
is often limited.  Written, streaming video, CD-ROM, and DVD versions of
basic instructional material must be available to ensure all end users
(specifically educators and students) are able to maintain the integrity
of their school networks and guard against educational fraud.  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.





Rodney Petersen wrote:

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


--

Davina Pruitt-Mentle

Director

Educational Technology Policy, Research and Outreach

College of Education

University of Maryland College Park

http://www.edtechoutreach.umd.edu/

(301) 405-8202



The sender believes that this email and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent.  This
message and its attachments could have been infected during
transmission.  By reading the message and opening any attachments, the
recipient accepts full responsibility for taking protective and remedial
action about viruses and other defects.  The sender's employer is not
liable for any loss or damage arising in any way from this email or its
attachments.


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