First published: 31st July 2007
In the July/August 2007 Editorial of Visual Systems Journal, Editor Mike James raises the problem of increased security breaking existing applications, specifically, Windows Firewall preventing a WMI application from working. Our Chief Consultant, Allan Dyer responds:
"Security is Everyone's Business". Specifically, developer's have a responsibility to consider and implement security when designing and building their applications. Too many systems are built using the "get it working first, secure it later" approach, which leads to many of the security disasters we see today.
The application in question was designed to contact other computers across a (possibly hostile) network, apparently without thought on who or what would be allowed to make connections, or how those connections would fit network security policies. Windows Firewall is a method for implementing the security policy of your organisation, don't blame it when it refuses to let you break the rules your organisation chose. Why didn't the security team know that RPC was a required service before they decided to deploy Windows Firewall with a configuration that blocked it? There does need to be more communication between the application and security teams, so the issues can be discovered and resolved at an early stage.
MSDN does have an article specifically addressing the Windows Firewall settings needed for WMI. I found them with a search for "WMI firewall".
I appeal to developers to design in security from the beginning, the "get it working first, secure it later" approach creates difficult security problems for the future.
Updated: 14th July 2007
Mike James responded, agreeing about the dangers of the "get it working first, secure it later" approach, but pointing out that in XP SP2 the firewall is on by default and blocks WMI, the user doesn't make a choice and doesn't even know about it; and the instructions in "Windows Firewall settings needed for WMI" do not work.
On the first point, end users don't have the expertise to understand the implications of XP SP2 and its defaults, but end users aren't deciding to use WMI, either. As a default for end users, blocking a service that they are not using is a sensible precaution. It is probably the coporate IT department that is using WMI, and they should have the expertise to preduct what happens when XP SP2 is deployed, or at least test it before they roll it out. And, as a developer, you should be aware of the services your application is using, and the security implications.
I am not saying this is easy, you are using WMI on top of DCOM on top of RPC, and it is the features of RPC that make it difficult to secure. However, the problem of securing RPC is well-known, at least in security circles - I have a book on Firewalls published twelve years ago that discusses the problem. Why have developers continued building on RPC without improving the security during those years? Presumably, security was not a priority for them - "secure it later". It is later, and we have to face the conflicting requirements created by leaving security out of the design requirements.
On the second point, the easy answer is, "Blame Microsoft". On the other hand, this is an excellent opportunity for Microsoft to demonstrate how seriously they are taking security nowadays by promptly fixing this.
I can't say what considerations the team that decided on the Windows Firewall defaults considered, but blocking a group of services that are not normally used or needed by ordinary users seems reasonable. Maybe they could have provided clearer information about the choices for IT departments and developers.