This year we had already at least two bugs which someone claims “have threatened to take down Internet”: OpenSSL Heartbleed and Bash ShellShock.

I will probably be unconventional, but by now I believe that, in particular for the Bash ShellShock bug, a much bigger security problem lies elsewhere.

Indeed my personal experience with the Bash ShellShock has been that most affected systems have been fixed overnight by the next automatic scheduled system update. Some critical systems have been manually updated in a matter of a couple of minutes without any process interruption. So all systems have been fixed as a matter of usual maintenance of ICT systems.

So where is the problem? Why so much hysteria about it? How is it possible that even very large and well-know systems have been attacked exploiting this bug?

Since it seems that as of today there are still many (too many) systems vulnerable to both the OpenSSl Heartbleed and Bash ShellShock, we have to conclude that the problem does not lie with the availability of the fix but with the maintenance procedure of the systems themself.

It is then not so much a problem of the bug itself, but of those managing or designing the systems which adopt this software, and any software at this point.

I can see two major areas where there can be maintenance problems:

• large systems which are built with the approach “if it is not broken, do not fix it”: often in this case maintenance, even security patches, is not applied, update and patching procedures are complex and executed rarely; of course, if the system has not been designed or configured with the possibility of being easily updated or patched, any vulnerability in any software component can become a real big problem
• similarly but even worse, are embedded systems which have been designed with the “build it once and forget about it” approach: in this case just the idea of maintenance has not been considered, or it exists only in the form of re-installing the full software (but only if you know how to do it and if a fixed new version of the full software has been made available).

It seems to me that more than blaming those writing and maintaining these software components, we should first think about how to maintain the software on our systems, which are the procedures for normal updates and security updates, etc.