More Thougths on Maintenance, Updates and Fixing

The issue of maintenance, updates and software fixing actually deserves a few more considerations.

Since a long time, security experts have been saying that software updates are essential for the security of operating systems and applications. A long time ago instead, software updates were considered only when new features or features’ updates were needed. It took a long time but by now, at least for mainstream applications, periodic (eg. daily, weekly, monthly etc.) software updates, in particular for security issues, are standard.

Still there are many unresolved issues. First of all there are still systems which are not updated regularly, among them there are some “mission critical” ICT systems considered so critical that updates are not applied for fear of breaking the system or interrupting the service, and, at the opposite end, some consumer embedded systems considered to be of so little value that a security update feature has been dropped altogether. (In my previous post I briefly mentioned these two classes of systems.)

But there are two other aspects that must be considered. The first one is the time that it takes between the release of the security patch or update by the software vendor or maintainer, and its installation on the system. As in the case of both Bash Shellshock and OpenSSL Heartbleed, patches and updates have been released out of the normal schedule, and they should have been applied “immediately”. To apply “immediately” a patch released out of the normal schedule, one should at least have a way:

  1. to know “immediately” that the patch has been released
  2. to obtain and apply “immediately” the patch to the systems.

Obviously to do this one needs to have some established emergency security procedure in place. One cannot rely on someone reading/hearing the news somewhere and deciding by herself to act as a consequence.

The second aspect, again also relevant in the two incidents mentioned before, is what to do in the time between the announcement of the existence of the bug and the availability of the patch, what is called a 0-day vulnerability. Again there must be some well established emergency security procedure which indicates what to do. The minimum is to assess what is the security risk of running the systems un-patched, to investigate if there are other countermeasures (like signatures for IPS or other network filters, detailed monitoring etc.), and in the extreme case just to turn off the service until the patch is available.

It seems easy, but it is not yet easy to put in practice.

Diverting and Tampering with Internet Traffic

This is really a disturbing news. Renesys has announced that this year there have been many cases of traffic redirection via BGP which look suspicious at the least.

Without entering in details of how BGP works, it suffices to say that BGP is (together with DNS) the hardcore infrastructure protocol which makes the global Internet working. BGP is used to build traffic routes so that the data can flow from one network to another. Each Internet provider (ISP) uses BGP to announce his own networks to the other ISPs and to learn where and through whom to send data to other destinations.

It is well-known that BGP has some weaknesses in particular due to its trusting that every ISP would not try to cheat. Indeed it possible in some particular situations that an ISP could announce the networks of another ISP and manage to receive all traffic for these networks. In this way, it could be possible to divert the traffic and possibly read it (if it is not encrypted) and tampering with it.

From the Renesys blog entry it seems that this has actually happened this year and that those involved claimed that these incidents have been due to “bugs” in some “vendor BGP software” and that there were no malicious intentions. Let’s just hope that this is true and that there will be introduced soon ways to prevent this to happen in the future.