Security, et al

A couple months ago I did a real training for free (tm) session on Top 11 Dos and Don’ts of Managing Access Control in the Windows/AD Environment and many of you were impressed like me with how Quest Access Manager simplified or eliminated many of my recommendations. 

At the time of the webinar, Alex Binotto from Quest indicated a number of your questions about Access Manager would be addressed in the upcoming release of 1.1 which is now here.  New features include:

• Remote Windows Scanning - reduces the number of agents to be installed
• Support Windows Clusters
• Support for storage devices – NAS (NetApp/EMC/etc.)
• Delegation/Segregation of Duties - now you can limit users of Access Manager to what I would call "look but don't touch".  That means they can assess and report on access permissions across the network without the ability to modify access control. 

Nice job, Alex and company.  If you'd like to watch my webinar referenced above click here.  To learn more about Access Manager click here.

Prism Microsystems recently announced a free - but real - consolidation and search solution for logs.  And it really works.  It's called EventTracker PULSE and it's based on Prism's flagship log management solution - EventTracker - which frequently sponsors my webinars.

PULSE is free, will collect pretty much any kind of log including Windows security logs, text file logs and syslog events.  PULSE consolidates all of those events into an efficient repository that allows you to search logs as well as efficiently store logs for long term archival.

PULSE uses EventTracker's agent optional architecture and I was surprised to see that Prism included EventTracker functionality for automatically deploying and managing agents.

The search feature is modeled after Google and very easy to use.  PULSE doesn't have a number of EventTrackers enterprise features such as reporting, web-based management, alerting, correlation, etc but if you need solid log collection, archival and ad hoc seach capability - check out PULSE at by clicking here.   

Windows is the largest and most widely used operating system in the world.

Security is arguably the most demanding discipline within the field of IT.

Combine Windows and Security and for some you have an oxymoron. Regardless how you feel about Windows, if you use it you have to secure it. So while it may be fashionable to arbitrarily bash Microsoft on all things security related, I don’t believe it serves my clients’ or readers’ best interest.

In this blog as with the rest of my work I will continue to bring you an informed, independent take on Microsoft security issues focused on practical solutions. I think practical solutions are important.

Many in the security field seem to share the sentiments of a mainframe security office from my past who said, "If you can do your job, I’m not doing mine." Another common habit is what I call security cynicism. You can find a hole or vulnerability in every control and security technology if you look hard enough. And there’s a place in the world for the Bruce Schniers to do that. Without that complacency and stagnation would insue.

However, most of us can’t live in the theoretical world. We live in the applied world and have to apply technology and controls to limit risk. After all, our employers aren’t in business to be secure. There in business to do business.

I welcome your comments.

Yesterday, Microsoft gave its monthly advance notification of security bulletins ahead of this coming Patch Tuesday. There are 2 new vulnerabilities in Windows and I bet you they are workstation-centric.

Have you noticed what I’ve noticed? The majority of Microsoft security updates these days are workstation-centric.

By a workstation-centric security update I mean the patch applies to a program normally executed on workstations (as opposed to servers) or involves interactive activities normally performed by users at workstations such as web browsing, working with document files and reading email.

At first blush that might seem good since we typically view servers as more critical than workstations. But there are at least 3 reasons why workstation vulnerabilities may be just as much a nuisance as server vulnerabilities.

1. Patch deployment effort. There are more workstations than servers. Ergo, more work deploying patches.

Furthermore, many of your workstations are mobile and it’s more complicated if not impossible to reach out to those systems and patch them.

2. Work-arounds exist for many security vulnerabilities but expecting users to follow them isn’t realistic.

You might be able to trust professional IT server administrators to follow work around procedures to avoid exposure to an unpatched vulnerability but you can’t count on end users.

3. Most importantly, workstations are critical to security.

If you can take over a workstation you can become the user who logs on at that workstation and access the same network resources and applications to which the legitimate user has access.

I don’t see this trend of workstation vulnerabilities going away anytime soon so we might as well fine tune our workstation patch management process. It will be interesting to see how well Vista and IE7 combat this trend.

The value of the Authenticated Users special principal is overrated. This is especially true with regard to the common recommendation to replace occurrences of the Everyone special principal in ACLs with Authenticated Users. This recommendation is made out of the over hyped risk that granting access to Everyone in file permissions would allow anonymous users (aka Null Sessions) to access those files.

Actually there’s very little risk of that. By default Windows Server 2003 doesn’t allow null sessions to access any folders you share – period. See [Network access:Shares that can be accessed anonymously] under Security Options in any group policy object.

The real risk with Everyone and Authenticated Users is the scope of these special principals and how they are effected by trust relationships. On a member server both Everyone and Authenticated Users include all local accounts in the server’s SAM, all domain accounts in the server’s domain and all accounts in any trusted domains. That means all users in the entire forest.

But as soon as you set up a cross forest trust or an external trust to a domain outside the forest Everyone and Authenticated Users immediately includes all users from that trusted domain. Any resources that you originally granted to either of these principles with the intent of giving everyone in the forest access are suddenly accessible to many more users.

In general I say that trusting another domain or forest doesn’t result in granting access to any resources; that trust relationships are about authentication. But resources that grant access Everyone and Authenticated Users are the exception to that statement.

Instead of using either of these principles I recommend using Domain Users which is a real global group in AD as opposed to a special principle. AD automatically adds new user accounts to Domain Users. But the nice thing about Domain Users is that since it is a global group it is prohibited from having any members from outside its domain. Therefore when you use Domain Users in ACLs you can rest assured you are granting access to that domain’s users and no one else.

While global groups are limited in terms of their members, global groups can be used in ACLs anywhere in the forest and in externally trusted domains and forests. If you want the ability to grant access to all users within the entire forest without adding each domain’s Domain Users group, just create a Forest Users universal group and add each domain’s Domain Users group as a member.

I’m excited to be part of SANS’s Log Management 2006 Summit July 12-14, 2006 in Washington DC.

I’ll be there presenting sessions along with Eric Fitzgerald from Microsoft. Eric is Microsoft’s resident expert on Windows audit and security logging.

The Log Management Summit is a user-to-user, non-commercial conference on what works in log management.

Join us to learn about the strengths and weaknesses of competing technologies, where users will share lessons learned about what to log, what to keep and what to report.

I have a post summit workshop entitled "Uncovering Secrets from the Windows Security Log".

Click here to learn more and to register http://www.sans.org/logmgtsummit06/summit.php.

A couple hours ago, my Google sidebar lit up with new postings about the new vulnerability in Word, discovered by Symantec, that apparently opens a back door.

I am frustrated at the total lack of detail on this so far and no other recommendation than to be careful about Word attachments - even blocking them at the email gateway.

How long does it take to produce a signature update or give more information about how bad the vulnerability is?

The reports I’ve seen say it opens a back door but what kind of back door? Does it open a port for incoming connections or does it actively check a rogue site for zombie commands? Are you protected if you have Windows Firewall?

So far the best information I’ve seen is at http://isc.sans.org/diary.php?compare=1&storyid=1345.

If you have thoughts or information on this let me know. I’ll make sure you receive credit.

Bad news: The back door door does actively connect back to a malicious website (apparently a server in the 3322.org domain) and accepts commands.

Good news: It appears that most AV vendors have succedded in getting a signature out.

The SANS Internet Storm Center is doing a good job keeping up to date on this.

See http://isc.sans.org/diary.php?storyid=1346.

Microsoft just released an official advisory on this vulnerability and the advisory contains 2 good recommendations you might consider to mitigate the threat until Patch Tuesday:

1) Use the Word Viewer to view documents since the viewer isn’t vulnerable. For this recommendation to work you would need concientious cooperation from your users.

2) Run Word in safe mode. Since you can accomplish this change via group policy it’s a bit more interesting. Microsoft documents the many registry keys necessary for changing all the places necessary to make sure Word runs in safe mode and provides links to documentation on creating custom Administrative Templates. But unfortunately they stop short of just creating the template. Why should countless admins do have to code and test this individually?

Here’s the advisory link: http://www.microsoft.com/technet/security/advisory/919637.mspx.

Hopefully your AV vendor has already provided updated signatures for catching affected word documents. If your AV technology covers the likely infection vectors you may just wait until the patch is available instead of trying to implement these workarounds.

I just learned from the EventTracker Newsletter about a new draft recommendations document from the National Institute of Standards and Technology entitled "Guide to Computer Security Log Management".

This 64 page document could be an influential piece of work for log management solutions and certainly something you shouldn’t ignore if you are implementing a log management system in your organization.

You can download the document from http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf.

This project and the SANS Log Management Summit (see earlier post) and the popularity of my security log encyclopedia and course demonstrate that they day of the security has come!