Will the Internet world end on April 1st? This is at least the impression I got from reading the press in the last couple of days. It seems that some story spun off and started to develop a life of its own.

What is really going to happen on April 1st? I quote the blog of our colleagues over at the Microsoft Malware Protection Center:

So what can we expect on April 1, 2009?  Based on the relatively small number of Conficker.D-infected machines, we believe it’s doubtful that we might experience anything out of the ordinary on April 1.  We will however, just as we normally do, take action on anything unusual that might arise from this.  To remain protected, please ensure that your systems are patched with MS08-067, keep your security software signatures updated, and clean any systems you identify that are infected with any variant of Conficker.

As I wrote earlier in my blog: Your focus should be deploy MS08-067 (if you have not done so yet) and clean your systems (if they are infected by Conficker) and, please, do not focus on any “end of the world” theories at the moment.

If you need additional information, please consult our different websites:

• Microsoft Conficker guidance page for IT Professionals and those focused on security in the enterprise: http://www.microsoft.com/conficker.
• Microsoft Conficker guidance page for consumers and home users: http://www.microsoft.com/protect/computer/viruses/worms/conficker.mspx.
• The Microsoft Malware Protection Center (MMPC) encyclopedia page for the Conficker family of malware: http://www.microsoft.com/security/portal/Entry.aspx?name=Win32/Conficker (especially focus on the “Analysis” section).
• The Microsoft Malware Protection Center blog: http://blogs.technet.com/mmpc/.
• The Microsoft Security Response Center Blog: http://blogs.technet.com/msrc/.

Enjoy the weekend

Roger

I pretty often have discussions about Patch Management with our customers. I think it is a very important discussion as I see too many customers not patching at all.

However, taking the shining examples – they often look at the Microsoft product suite “only”. You might remember that I blogged about my experience with this on my home PCs: 98% unpatched – and I am one of them :(

Now, this transfers to the enterprise business as well. If you look at our latest Security Intelligence Report, we have an interesting chart to show you the whole problem:

This chart shows the Microsoft share of the industry-wide vulnerability disclosures. What I want to show you with this chart is that our share of vulnerabilities in 1H 2008 is below 3%, which means for you if you are implementing a patch management strategy, you have to make sure that you cover the other 97% of vulnerabilities as well.

I am well aware of the fact that this does not show your risk distribution. Based on your usage of our technology as well as the fact that criminals use our platform more for attacks as there is more to gain because of the wide distribution, your risk profile will be distributed differently. However, there is no discussion that you need to cover all the products you have in place.

The actual reason, why I write this post are two articles I read today, which show perfectly what can happen if you omit the rest of your environment – including your hardware:

• Hacking The Router Patching Conundrum
• New worm can infect home modem/routers

On our website there are several good resources with regards to patch management:

• Ten Principles of Microsoft Patch Management
• Update Management
• Update Management Process

Conficker showed us again that a sound patch management process is the foundation for your defense/security/risk management strategy. So, please if you did not yet deploy security updates – please go ahead and start. The earlier the better and base it on the principles of patch management referenced above:

1. Service packs should form the foundation of your patch management strategy
2. Make Product Support Lifecycle a key element in your strategy
3. Perform risk assessment using the Severity Rating System as a starting point
4. Use mitigating factors to determine applicability and priority
5. Only use workarounds in conjunction with deployment
6. Issues with Security Updates are documented in the Security Bulletin Master Knowledge Base Article
7. Test updates before deployment
8. Contact Microsoft Customer Support Services if you encounter problems in testing or deployment
9. Use only methods and information recommended for detection and deployment
10. The Security Bulletin is always authoritative

Roger

I would love to know… You probably saw a lot of blog posts recently about “Conficker to strike back on April 1st” or similar.

If you are interested in what is know about Conficker and April 1st, read our encyclopedia entry on Conficker.D and you should choose the “Analysis” tab there, which gives you the details.

To be clear from my side: Please, concentrate on deploying the Security Update and cleaning Conficker (if you are infected) much more than being sidetracked by that.

Roger

I was recently caught in a tricky problem: The clock of one of my host servers ran out of sync.. – significantly. The core problem was that my Mediacenter (which is domain integrated) started to record about 6-8 minutes too late but this is not the reason why I post.

The actual reason was that I tried to resolve this: My DCs are virtualized – one on a Hyper-V server and one on a Virtual Server. As both have the corresponding add-ins installed, by default the guest synchronizes the time with the host. If the host clock is now not accurate anymore, this is transferred to the guest (which is a DC and which then synchronizes this across the whole infrastructure). As this happens slowly, I did not realize this until my Mediacenter did not capture the whole news anymore…

Now I checked the time server settings of my DC and it synchronizes its clock with time.windows.com and NTP is open for the DC – therefore the synchronization is successful, resets the clock to the right time and then the Hyper-V Integration Services kick in and set the clock back to the time of the host (which is wrong) and the wrong time is again synchronized across the network . (I hope this was now confusing enough)

What I did now – and what I would suggest that you do that (at least with the knowledge I have today) – is disabling the time synchronization between host and guest at least for DCs as they update their time from the time server as described above. Since then, my time is correct again.

Roger

P.S. As you know – I am Swiss. And one of the worst thing which could happen to a Swiss is an incorrect watch

You might have seen several reports that MS09-008 does not protect you from the vulnerabilities. We reviewed these claims and customers who have deployed MS09-008 are protected from the four vulnerabilities.

If you want to have the details, you should consult our Security Research & Defense Blog, where we posted MS09-008: DNS and WINS Server Security Update in More Detail as the problem is somewhat more complex than just “yes/no”

Roger