• Menu

0 recente resultaten

12 much needed updates for security updates

Our society is increasingly dependent on a well-functioning digital infrastructure. Vulnerabilities in that infrastructure can have a major impact on our society. It is therefore increasingly important to remedy vulnerabilities quickly. Our process of updating could use an update.

A two page summaryEuropean Cyber Security Perspectives 2018 of this article can be found in KPN's European Cyber Security Perspectives 2018, on pages 75 to 77.

The impact of vulnerabilities and updates

A vulnerability could affect anyone. If your most intimate photos are out there for the world to see because of a bug in some software, that's a major headache. Especially if it's caused by you deciding not to install that one update, because it would also upgrade your operating system and make your phone even slower.

But the consequences of vulnerabilities surpass the personal. An incident with a computer system can have fatal consequences if a hospital is affected. Our society is in disarray if, because of a problem, our super markets are not restocked for three days or no electronic payments are possible. The consequences for our democracy and the rule of law, should we decide to digitize our voting process, need hardly be discussed.

And the risks are not just there for the vulnerable systems themselves. It's one thing if you don't mind others peeking in your child's bedroom, but others could use your camera just as well to shut down parts of the internet. One of the largest DDoS attacks on the internet was performed through poorly secured webcams"Record-breaking DDoS reportedly delivered by >145k hacked cameras".

Even though resolving vulnerabilities in our digital infrastructure is tremendously important, we do not act like it is. Installing patches that remove those vulnerabilities seems to be something with the lowest possible priority. As an example: the solution for the vulnerability that made the rapid spread of the Wannacry ransomware possible had been available for two months – it was merely not installed in many places. We should do better and here are some ideas.

Update 1: security updates should be installable

That sounds very obvious, which of course it is. But still. Now we're laughing about the silliness of many things on the internet of thingsInternet of Shit – and insecure as well., but simultaneously they fail miserably at security. Eleven year old Reuben PaulReuben spoke about his hack at a large Dutch security conference. was playing around with his teddy bear and hacked the poor thing via a wireless connection. And the most annoying fact: on many of these devices, you can't install security updates. Neither can the manufacturer, especially not remotely. The device may be smart, but its manufacturer definitely is not.

The only solution that remains is to throw out and replace the device when a vulnerability is discovered. A more sustainable solution: it should be 'not done' to sell products that are connected but cannot properly be updated. As a consumer, you should expect nothing less.

Government shouldn't abuse the security update mechanism for offensive measures which actually weaken security.

Update 2: no updates without upgrades

We also need to think about the large changes to a system, such as the upgrade to a new version of the underlying operating system. Maybe your grandpa took his first steps on a computer with Windows XP, which – contrary to all warnings – he hasn't upgraded since. Unwise, of course, because Windows XP has been end-of-life for years. The same holds for the robot in the factory that fits car doors onto a chassis. Management is faced with the choice: keep using the existing robots running on the outdated software and accept the risk, or making a major investment in new robots.

Of course grandpa would do well to upgrade, but how to stimulate that? How many warnings should he be allowed to click through? Or should an ancient computer just not be able to boot anymore? For a large factory with many dependencies, things may not be that simple. Maybe there should be a rule that in such a case a computer may no longer be connected to a network? It's a difficult dilemma for the software manufacturer as well: at a certain point, software should be allowed to become end-of-life, and you really cannot expect software updates after that.

Update 3: updates shouldn't break anything

Another obvious point. One of the reasons hospitals in the United Kingdom were affected by the Wannacry ransomware was that people are exceedingly cautious about making changes to the software of such systems. Understandable. If the software isn't thought out well, an update could make the system go down or crash. You don't want that in a hospital, a police station or at air traffic control. Therefore, such institutions test updates thoroughly before installing them.

This has to be done more cleverly. A security update should be installable quicky, especially if the potential consequences of the vulnerability are large. Trustworthy updates require them to be small atomic changes which are thoroughly tested before made available. It also means that manufacturers should inform users well about the nature of the update, the potential consequences of applying the patch and possibly even assist where the software is used in devices upon which lives depend.

Manufacturers are not going to deliver the solution.

Update 4: the update process itself could use an update

Sometimes people take long to install updates for other reasons, for example because they estimated that the vulnerability will not be abused quickly. Our estimate: better to have a short and controlled disruption, than an unexpected and longer one – with possible loss of sensitive data. For example, the French Renault factories that were hit with Wannacry were closed for two daysNews item about the downtime of five Renault factories..

Sometimes, process-related problems are the cause of slow installation of updates. Some organizations are required to have the entire updated system be recertified before they may take it into production again. If such an organization has to go through the entire certification process every time they install an update, patches will be cumulated and the actual patching becomes a protracted affair. What also happens: an organization depends on an external manufacturer for administration of its computer systems and has to wait for them.

This has to change: as we become more dependent on our digital infrastructure, the priority with which we apply patches should increase accordingly. It means that the processes for applying patches should be structured differently.

Update 5: fixing vulnerabilities is a lifetime commitment

How much did your mobile phone cost? The answer most of us give: a few hundred euros. Sometimes even up to a thousand. What do you think is the lifespan of that phone, what is its useful lifetime? A bet? A few years. Five or six, if you include second-hand use. And what is on there? Everything about you: your holiday pictures, your most intimate chats, your internet banking. Therefore, it's not unreasonable to expect the manufacturer of your phone to support it for at least this period of six years. That if a vulnerability with impact on the security of your data comes to light during that time, an update will be provided that resolves this vulnerability. Reality is different. Some mobile phone models were already unsupportedTweakers.net wondered: are manufacturers allowed to sell insecure phones? on the day the phone was sold – as new.

And this is the easy part: the support for a few yearsThe Dutch consumer organisation Consumentenbond demands in court at least two years support. Once we have connected everything to the internet, we're talking about lifespans of a decade or even more for some devices. Older cars or fridges should also receive those updates. It would be dumb if a car could no longer be driven safely, just because the manufacturer does not want to provide necessary support. In the case of mechanical malfunction, your local garage may be able to help, but because the source code of the software often is a company secret, they cannot do this any more. From the viewpoint of the environment it is a complete disaster to have to replace a car after ten years, just because security updates will no longer be provided. And then the situation becomes rather sticky: what to do if the manufacturer has meanwhile gone bankrupt?

In future companies may should be required to insure themselves. Whenever they put a product on the market, they should deposit a large amount of with an independent third party. If the company loses interest in maintaining the product or the company goes bankrupt, the deposit can be used to provide the necessary product support or pay for the damage.

Manufacturers should distinguish between security updates and other updates.

Update 6: automatic installation of security updates by default

I know one thing for sure: if I myself need to check regularly for security updates, I will often be vulnerable. This will possibly be less of an issue if my connected device looks for new updates on its own, and notifies me if new updates are available. But this notification occurs obviously right when I need to focus on my work. The apps on my phone, however, are almost always up-to-date: it happens automatically, I hardly notice it. Once every few days I check what has changed. But for the vast majority of users and devices, this works excellently. Especially if the security updates are just that: security updates – see below. Of course there are situations in which you do not want this, that's why it should be possible to disable such automatic updates.

The argument that you don't want automated changes to a running system will quickly surface. As a hosting provider of websites, you do not want to run the risk of an update breaking your websites. But the solution should then not be to disable updates, but to improve those updates. The manufacturer should say: we have so much confidence that our product still works after an update, that we do not even ask you if you want to install the update. If it gives you any shit, we will resolve that shit. And yes, there will always be exceptions to this rule – but those should be just that: exceptions.

Update 7: knowing for certain that your update is not malware

What do you do if your browsers shows a pop-up window that urges you to install an update quickly to prevent you losing your files? Does your decision change if you see this pop-up after hearing on the news this morning about a worldwide attack with ransomware? There's a good chance you will click the 'install' button. But there is a similarly good chance that you're not installing a security update, but the feared malware. The point is, in many cases checks on the authenticity of an update are not well thought out. Is the offered update actually coming from the manufacturer?

The system should be designed in such a way that the user only installs security updates from a trusted source, usually the manufacturer. For a large part this can be enforced technically. The authenticity of the update server can be checked cryptographically. Of course, this means that the manufacturer needs to make even more effort in protecting its infrastructure as that has become a bigger target.

Without a proper process for security updates the only solution is to throw out and replace the device once a vulnerability is discovered.

Update 8: a security update is separate from feature updates

In Apple's announcement of the new version of their mobile operating system, iOS 11, quite some attention was given to the face liftNews item: the iOS Control Center has seen its third major overhaul in three years of the so-called lock screen and notification center. New design, new settings. That's nice for those who want these things. But anyone who is happy with the current functionality may just decide to not install the update. Although the choice is understandable, it's not without undesired consequences. If you do not install this update, you are also deprived of the security updates, which you do want. The same holds for other changes in the phone, such as changes in the settings or the permissions that an app requires.

This has to change: manufacturers should distinguish between security updates and other updates. The user should be able to install security updates that resolve vulnerabilities, without being forced to accept changes in the functionality. The updates of UbuntuUbuntu allows you to have your computer only check for security updates are a good example of this. There, you can choose to have your computer only install security updates, while ignoring all other updates.

Update 9: a security update is unconditional

Or, to put it more strongly, every hurdle that hinders the installation of an update should be removed where possible. That means that the availability of an update may not depend on the contractual agreements between the manufacturer and the user, or that the user may be forced to pay for an update that resolves a vulnerability. And another thing: an update should not hinder the user unnecessarily. Suppose that you drove your car to your dentist appointment, but that you're not allowed to turn off the engine while the update – which takes another twenty minutes – is installing. Or that you want to turn on the lights when you get home, but that the app on your phone first has to process a large update.

It is therefore increasingly important to remedy vulnerabilities quickly. Our process of updating could use an update.

Update 10: transparent updates

And of course, it does help if the users understands what exactly an update entails. This kind of information is usually to be found in a so-called change log, a list of changes to an app for each and ever version. Whoever has browsed these change logs (when, for example, updating the apps on a iPhone) knows how useless these lists sometimes are. Spotify's mantra is "We’re always making changes and improvements to Spotify." Every update, again and again. The improvements may be welcome, but the change log nonetheless utterly useless. As a user you never know whether installing the update means you will end up with a completely reworked user interface, or that it will fix a vulnerability. These change logs should be used more sensibly: it should contain a detailed description of the changes the update will make.

Update 11: no exceptions, not even for the government

Of course we do not want to suggest any ideas to our government, but to us it seems quite trivial to put a backdoor in WhatsApp. Suppose that the police wants to read the messages of a specific user, but they can't because of the so-called end-to-end encryption. The police might force WhatsApp to push an update to users that disables the encryption of all messages to and from this one user. If the police then wiretap his connection, they can read the messages. Of course, the first time this will be very effective. Maybe the police can use this to prevent the murder of a criminal. But what this also prevents: that internet users install security updates. They can never know for certain that some government isn't abusing that update mechanism to actually weaken security.

Update 12: it should be possible to make a security update

If the manufacturer doesn't know about a vulnerability in his system, he can't write a patch for it. And without that patch, no-one can update and every user remains vulnerable. That's why it is important that vulnerabilities that are found are reported to the manufacturer of the vulnerable software as soon as possible and in a coordinated manner. The consequence of this: governments should not keep vulnerabilities a secret. Another consequence: governments should not participate in the market for unknown vulnerabilities, and they should renounce the purchase of devicesDutch police is known to use such devices from Israely maker Cellebrite that exploit such unknown vulnerabilities.

How do we deploy these updates?

If the outbreak of the Wannacry ransomware has taught us one thing: we need to go to great lengths to resolve vulnerabilities. And like the application of updates itself, it's never too early to start. How do we do that? The answer to that question, unfortunately, is not simple, but the main direction is clear.

Manufacturers are not going to deliver the solution

It seems obvious to look to the manufacturers of hard- and software for help. After all, they develop and produce the computer systems that we want to update later on. However, investing in the update process is not something their shareholders will cheer on: it costs money and yields very little. This is especially true in the short term.

Of course, companies benefit from users that have great confidence in the digital infrastructure they use daily. But the benefits of greater confidence are not directly noticeable, visible or easy to monetize. It has to come from the entire industry. You can be the only company that produces a secure connected doll (at a higher price, of course), but if the rest of the industry puts in too little effort the confidence will not grow. It is not realistic to think that an entire industry will suddenly start to show corporate social responsibility. Too bad.

Even though resolving vulnerabilities in our digital infrastructure is tremendously important, we do not act accordingly.

The government should enforce good behavior, including for itself

No, we shouldn't expect much from the manufacturers. This means that government has a role to play here. The common interests are simply too large to just let this happen. We should force the hand of manufacturers with laws and regulations. It is also not something we can solve by ourselves in the Netherlands, because we depend far too much on foreign manufacturers for our systems. Moreover, even if we have very secure products in the Netherlands, if the rest of the world attacks us, we're still doomed. Ideally we therefore regulate this at the global level. But because that is a long and difficult road, this has to be put on the Brussels agenda soon. Compare it to safety belts in cars: mandatory because of the societal damage (and deaths) we would suffer otherwise, *and* it allows us to drive even faster without great risk.

Those rules should enforce a few things. Manufacturers should be forced to use secure protocols, standards and default settings. Security researchers who discover a vulnerability in a responsible manner should be able to report it without fear of repercussions. Companies should be forced to provide security updates quickly and adequately. They should apply the above updates to that end. The new rules should also ensure that companies are liable for the societal damage they cause if they are negligent about the security of their products. And of course: not only rules, but also strict enforcement if they are violated.

But the government should also consider its own policies. It cannot be the case that the government participates in the market for unknown vulnerabilities, so-called zero days, or that it hijacks the process for installing security updates to create backdoors.

Be critical

You ask what you can do, internet user? Be critical when buying your next internet-connected device. Read the small print on the website of the manufacturer, ask someone you know “who knows about computers” or ask the salesperson. Do you know that the product you're buying will be supported with security updates throughout during its entire lifespan?

Help mee en support ons

Door mijn bijdrage ondersteun ik Bits of Freedom, dat kan maandelijks of eenmalig.

Ik geef graag per maand

Ik geef graag een eenmalig bedrag