Trustworthy Computing Isn't Just for Microsoft
It takes two to make the security world go round.
- By Roberta Bragg
Last week, Microsoft issued four security bulletins and provided
patches that fix the multiple vulnerabilities described in the bulletins.
I hope you've carefully evaluated your needs for these hotfixes,
tested and applied them to vulnerable computers. However, I'd like
you to take a minute to broaden your understanding of the security
process by considering what these vulnerabilities and their respective
patches tell us about "Trustworthy Computing."
When I use the term Trustworthy Computing, I'm not just thinking
of the narrow definition of the term. Trustworthy Computing isn't
just Microsoft's responsibility to produce more secure software
and be responsive to the security needs and requirements of its
customers. Yes, it should be an expression that describes their
accountability for them and for us. But it should also be an expression
of our accountability. I often hear people judging how Microsoft
is doing, but I rarely hear these same people owning up to their
own participation--or lack thereof--in security programs. What about
you? If everyone invested in an analysis of their own security posture,
perhaps we really would get something like Trustworthy Computing.
So what do the latest security hotfixes tell us? Let's take a look.
Yes, they tell us that Windows software still has a few flaws that
need remediation. But dig down into the details provided with the
security bulletins and you'll find that those organizations that
already practice sound security principals may already be protected
against the possible exploitation of these problems. Certainly,
their risk of compromise by malicious code that takes advantage
of these vulnerabilities is less. For example, bulletin MS04-011
is composed of 13 issues. Read details of each issue and you'll
find that the risk from most of these issues can be greatly reduced
if you use the following common good security practices:
Block unnecessary ports, both outgoing and incoming; from and
to networks; and from and to hosts. Do not open ports commonly
used in attacks
Establish and appropriately configure a firewall between your
network and any trusted network such as the Internet
Use a personal firewall on vulnerable mobile computers and other
Use IPSec or TCP/IP filtering to block access to specific ports
on a host
Limit the number of users that have elevated privileges. Audit
the use of these privileges
Review user accounts and disable or delete idle accounts. Carefully
guard account assignments so that only appropriate users get accounts
on the network
Establish a strong account/password policy and train users in
creating and using strong passwords
Read e-mail in plain text
Open messages in the restricted sites zone
Apply updates, services packs and patches
Granularize "log on locally"; every user does not
require access everywhere
Here are several of the vulnerabilities and recommendations for
mitigation or workaround. Please note that I'm not suggesting you
refuse to patch or use these methods instead of patching systems.
My point is that if you're following standard security best practices,
including applying patches, your systems may be protected against
much more than the threats you are already aware of. If you follow
standard security best practices you may find that you're protected
from threats no one's aware of.
As a side note, the bulletin also mentions the dilemma that security
can cause. Some mitigations or workarounds require steps that will
prevent computers from fulfilling their role. An example is the
SSL vulnerability mitigation. The bulletin says to block ports 443
and 636 at the firewall. If you do, no SSL connections can occur,
making sales on your commercial Web site impossible. The list below
is not comprehensive.
LSASS Vulnerability: A standard firewall configuration probably
protects from a remote attack that might take advantage of this
vulnerability. Use of Internet Connection Firewall can also provide
protection. Blocking via IPSec or advanced TCP/IP filtering can
also be done.
LDAP Vulnerability: Block LDAP ports by firewall. This affects
Windows 2000 domain controllers only. Block 389, 636, 3268, 3269
(Where clients must authenticate to DCs across networks, blocking
these ports will prevent it. Configure VPNs or other ways to allow
PCT Vulnerability: Use of Web Publishing with ISA Server can
block attempts to exploit. Disable PCT using the registry key
Knowledge Base article 187498 has more information.
Winlogon Vulnerability: Permission to modify user objects in
a domain is necessary. Give permission only where necessary and
vet administrators. Audit changes to user objects. Review records.
Metafile Vulnerability: Read e-mail in plain text format.
Help and Support Center Vulnerability: Open messages in the
restricted sites zone. (This is the default for I.E. 6, Outlook
2002 and Outlook 2003; apply the Outlook e-mail security update
to Outlook 98 and Outlook 2000.)
Utility Manager Vulnerability: Disable this service (recommended
in the Win2K hardening guide; the user must have valid logon credentials.
Use software restriction policies.
Local Descriptor Table Vulnerability: The user must have valid
logon credentials and be able to logon locally.
Windows Management Vulnerability: The attacker must have valid
H.323 vulnerability: Block firewall ports 1720 and 1503.
Virtual DOS Machine Vulnerability: Must have user account and
About the Author
Roberta Bragg, MCSE: Security, CISSP, Security+, and Microsoft MVP is a Redmond contributing editor and the owner of Have Computer Will Travel Inc., an independent firm specializing in information security and operating systems. She's series editor for Osborne/McGraw-Hill's Hardening series, books that instruct you on how to secure your networks before you are hacked, and author of the first book in the series, Hardening Windows Systems.