Wannacry or Conficker: How to prevent worms in real life

There is plenty of published info about Wannacry; I am not replicating any here. How can your company avoid being hit? It is simple and it is complicated. First we need to understand why companies don't apply patches:

  1. They don't know it should be done.
  2. They feel they are too busy to do it.
  3. They feel it creates issues, with no obvious benefit.
  4. They don't do it often enough.
  5. There are no immediate drawbacks of stopping to patch, eventually it becomes normal not to do it.
  6. The people responsible to do it move on to new jobs, and the new ones don't get promotions or are rewarded for doing it. Why bother?

Preventing worms is a team effort between the Systems teams and Security teams. Security teams are responsible for monitoring new vulnerabilities and patches, and handing over that information to the System team.

Back in 2008, my team and I stopped Conficker from affecting Bankia's systems.

(From Wikipedia): Conficker, also known as Downup, Downadup and Kido, is a computer worm targeting the Microsoft Windows operating system that was first detected in November 2008.[1] It uses flaws in Windows OS software and dictionary attacks on administrator passwords to propagate while forming a botnet, and has been unusually difficult to counter because of its combined use of many advanced malware techniques.[2][3] The Conficker worm infected millions of computers including government, business and home computers in over 190 countries, making it the largest known computer worm infection since 2003

The Systems team applied patches in periodic batches, for servers and workstations. It is the only reasonable way to do it in a large state. What lazy Security teams do is to forward everything immediately to Systems, and shift the blame to them if the patches are not applied. This is the Cry Wolf approach. We forwarded nothing. We just requested the inclusion in the next batch of security patches with one exception. Remote executable vulnerabilities affecting the most used OS in the bank.

We requested once or twice a year urgent application of patches. As we did not request it often, the Systems team listened to us when we did. When the patch that prevented Conficker came along, we asked for it to be applied immediately. And it was.

Bankia was never affected by Conficker. This did not make the news.

Patching should be done. And it should be boring.

Avoid getting your organization in the news. Find a way to collaborate with your Systems team.

New O-ISM3 version soon to be published

The new O-ISM3 version has been submitted for approval to the Security Forum of The Open Group. The main novelties of the new version are:

  • Improved definition of types of metrics
  • Added guidance on how to use metrics
  • Improved definition of maturity levels
  • Improved definition of management practices
  • Tweaks in some processes
  • Moved ISM3/ISO27001 guidance to a dedicated paper (already published)

What is the Maturity of your ISMS?

Maturity is a measurement of the ability of an organisation for continuous improvement in a particular discipline (as defined in O-ISM3). The higher the maturity, the higher will be the chances that incidents or errors will lead to improvements either in the quality or in the use of the resources of the discipline as implemented by the organisation. Find out what is the maturity of your ISMS with five simple questions. (In order to make it easier you can download free of charge the Maturity Assessment Tool)
. I mapped the Cobit, CMMI and O-ISM3 Maturity and Capability levels in this document:

And you can learn more about Maturity and Capability in this presentation:

Pages