Microsoft Security Initiatives in SP1 and SP2 - nothing but a complex toy?
Microsoft Security Initiatives in SP1 and SP2 - nothing but a complex toy?
By Dennis Lundtoft Thomsen
I recently read Kevin Day's book "Inside a Security Mind" - not because I pretend or intend to be a security guru but because I'm aware of the fact that we as a industry need to change focus in terms of security.
Working as a Solution Architect and Managing Consultant I've been pushing security focus to my customers for a long time - both in term of technology itself and more importantly around the processes involved in implementing and supporting technology - and it's quite frankly at times an uphill process. The comment from Kevin Day's book that triggered me to write this article was –
“.. a security device, no matter how expensive or complex, is nothing more than a toy if it does not function within a greater security framework.”
I principally agree with this statement as it relates directly to some of the solutions I have seen at customers and in terms of XP SP2 it reminds me of one of the first customer comments I heard about the Windows XP SP2 firewall - "Very fine – but how do we disable it?". From a short-sighted manageability point of view, I understand the comment, but from a security Point of View the possibility of implementing a managed firewall is an opportunity that I personally would not let go.
The same applies to the security initiatives in Windows Server 2003 SP1. The Windows Server Post-Setup Security Updates (PSSU) that works as a firewall blocking all incoming traffic during OS installation until all required security updates has been installed and the person installing the server presses "Finish" in the wizard that pops up after logon. PSSU is luckily on by default in slipstreamed Windows 2003 SP1 installations. Furthermore the Security Configuration Wizard and its 50+ role-based configurations allows us to create templates/roles for all servers in a organization – allowing us to take a role-based approach towards the security configuration on servers. Using the “scwcmd transform” command takes SCW to the next step by converting our templates to group policies that now can be linked to our OU structure and further enhancing the roll-out of our security policies to servers that are domain members (Be aware though that IIS settings aren’t deployable through group polices and therefore NOT part of the transformation).
One of the main advantages of the enhancements in both service packs is that when properly implemented they are a good start towards the “principle of least privilege”; in terms of OS hardening almost everything incoming is blocked by default – except the settings/roles you have defined as allowed.
This article is not meant to be a review of all the security enhancements in SP1/SP2 but I feel the need to comment that I’m not saying SCW or the firewall in SP2 are perfect. An important feature missing in the firewall is outgoing connections – including which applications are allowed to initiate these (Although I recognize the fact that it would be hard to implement and manage in a corporate environment) another is the many different tools used for security configuration. Furthermore, I think it’s disappointing that Microsoft didn’t have the nerve to enable the firewall by default in a slipstreamed Windows Server 2003 SP1 installation (Although I’m sure they had good reasons for this) – so that “everything” was blocked by default and you had to use SCW to open the server for the necessary applications/usages. Last but not least I’m painfully aware of the work required to actually making these technologies work in an existing production environment (But I personally think it’s worth the effort).
Back to the point that relates to one of the Ten Immutable Laws of Security "Technology is not a panacea" and Kevin’s point about expensive/complex toys. If the full functionality of the Service packs isn’t implemented in your organization or if they are implemented in a environment where the proper processes around security isn’t in place or where simple things as password protected screensavers are disabled (as I’ve seen in our of my enterprise clients, due to a Managing Director that was annoyed with having to unlock Windows when returning to his desk) and/or the rest of the organization isn’t security aware – then whatever security initiatives Microsoft makes it’s almost a dead end game.
I do believe however that the enhancements in SP1/SP2 are much more than toys and that you and I can use it to make a difference - they are way better than the current situation where machines are often attacked during installation or before they are fully patched – and I do believe that if we all try to influence the people around, below and/or above us that we can help to raise the security bar and awareness in our respective companies and in the industry (Just to be clear - I don't think its Kevin’s point either that we should give up on security if all processes/systems aren’t in place ;-)
So come on – let’s join forces and go and test and design the firewall for our XP clients and role-based security based on GPO and SCW for all our servers (Btw. don’t use it with SBS 2003 and do try this Google search for other known issues).
Comments
Anonymous
January 01, 2003
PingBack from http://winblogs.security-feed.com/2005/06/14/microsoft-security-initiatives-in-sp1-and-sp2-nothing-but-a-complex-toy/Anonymous
January 01, 2003
Dennis has written an article which examines the role of Service Pack 1 for Windows Server 2003 and Service...Anonymous
June 14, 2005
I've written an essay on the security initiatives in SP1 and SP2 for the Industry insiders forum and it can be found here ...Anonymous
June 15, 2005
Are you sure about the statement "Furthermore, I think it’s disappointing that Microsoft didn’t have the nerve to enable the firewall by default in a slipstreamed Windows Server 2003 SP1 installation" as it is enabled until our SBS boxes go out and get patches as least. I thought this was true for normal server as well? As far as not allowing outbound filtering of connections, that's discussed in the TechNet Radio and the found that users would just click "sure I want that go outbound" and it served no purpose.
SBS 2003 doesn't need it because we're pretty tweaked as it is, but I do have to <sigh> sometimes when someone says "oh I'm secure I have a firewall and I don't need them inside the network.Anonymous
June 20, 2005
Hi Susan,
Sorry for the late answer, here it goes -
According to my references / testing it is enabled by default during a clean Windows Server 2003 SP1 installation (Although PSSU isn't invoked after an upgrade). But as soon as you press "Finish" in the PSSU Wizard the Firewall is disabled. It is a big step forward but IMHO it should still be enabled after this point and then by using SCW you would open only the necessary ports for your specific server role(s). I do agree that the way outbound filtering mechanisms are handled today in most Personal Firewalls isn’t perfect as non-IT users are inclined to use the "sure I want to go outbound" button – so we need to find a better way to handle this (E.g. open outgoing ports as part of a “SCW” workstation role tool and as part of MSI installation packages for each application).
Btw. keep up the good work with your SBS blog ;-)Anonymous
June 24, 2005
I am a graduate student in Northeastern University CC&IS and am interested in HCISEC issues. HCISEC concerns the design and implementation of UI elements such that a general user can make informed security decisions.
The outbound firewall issue is one of the examples I tend to use regarding the need for HCISEC research. WHY do users just click Yes? For the personal firewalls I've used (ZoneAlarm and Sygate Personal Firewall) the reason is pretty clear:
1) The typical user cannot tell from the information presented whether it is safe to allow the outbound connection because the data presented to enable the choice is confusing/opaque.
How is a typical user supposed to know what to say when they get something like "Would you like to allow WINWORD.EXE to make an outbound connection?"
2) The typical user does not necessarily understand the security ramifications of allowing an outbound connection. Popular understanding of security risks tend to focus around hackers, viruses, and the like trying to get IN.
Extended the above example...what harm could allowing WINWORD.EXE an outbound connection possibly do?
3) If the user does say NO and things break it tends to take a series of rather complex steps to reverse the decision. This gives the user an incentive to say YES just to avoid the hassle of trying to fix it.
To a degree these are user education issues, but to an even greater degree they are a question of how well the technology presents the user with security options and facilitates the users making informed decisions amongst those options.
SSL suffers from all of the same problems as the personal firewalls. So do MOST things that are content to prompt the user on the assumption that the user will always make an informed and appropriate decision.
To reuse the quote from Day's book:
“.. a security device, no matter how expensive or complex, is nothing more than a toy if it does not function within a greater security framework.”
MANY MANY security devices are reduced to toys because they do not function within the greater security framework that is the user's security experience.
Feel free to contact me with any thoughts on these issues.