Security Watch

Trustworthy Computing Isn't Just for Microsoft

It takes two to make the security world go round.

• By Roberta Bragg
• 04/19/2004

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 systems

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 authentication traffic.

PCT Vulnerability: Use of Web Publishing with ISA Server can block attempts to exploit. Disable PCT using the registry key HKLM\Ssytem\CurrentControlSet\Control\SecurityProviders SCHANNEL\Protocols\PCT_1. 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 logon credentials.

H.323 vulnerability: Block firewall ports 1720 and 1503.

Virtual DOS Machine Vulnerability: Must have user account and local logon.