Recently we have been implementing two Drupal patches, which were labelled as ‘Highly Critical’ (https://www.drupal.org/sa-core-2018-002 / https://www.drupal.org/sa-core-2018-004). Without disclosing details of the patch Drupal even warned website admins that a patch was going to be released at a specific date/time and that admins should be ready for its release.
By providing a pre-announcement about the patches a lot of hype and attention was drawn to them and they were given the moniker drupalgeddon2. In doing so, this also puts attackers on high alert that there is a severe vulnerability that could be exploited. Once the highly critical patches were released attackers reviewed the code contained within and worked out what the exploit is that the patch is mitigating against.
It didn’t take long for people to start publishing these exploits online. This meant that if you weren’t patched you were at real risk of being hacked -you may not be targeted specifically but automated attacks don’t ‘choose’ their targets.
Drupal aren’t the only organisation that assign risk ratings to security advisories or highlight when an important patch is going to be released, it’s something that is fairly standard within the IT industry.
Would it be better not provide risk ratings?
I believe there is an argument that all patches should be released without a risk rating, or ‘unrated’ and the onus should really be on the owners of the applications to patch regularly. By not providing a risk rating, or pre-announcing when a patch is going to be released this creates a lot more work for attackers as they aren’t effectively signposted to where vulnerabilities exist within the code.
Will people regularly patch though?
There is a strong argument against this, which is that many people still don’t patch regularly. Unfortunately, there are some people who face constraints which mean they can’t easily patch regularly. There are also people who feel that their site isn’t big or important enough to be targeted. In order for it to work it would take a change in thinking around patching -often the kind of change that is triggered after an organisation has experienced being hacked first hand.
The future of patching
I don’t know what the future of patching will look like -perhaps there will be more automation where patches are more actively added to websites. This currently exists but there is always a risk that by doing this you can break a website anyway which is why manual intervention is preferred.
I don’t see the need for patching will ever disappear, and I think we will see more and more highly critical patches being released across all applications as more people take the security of the applications they provide more seriously.
For now it would seem that the only way of getting people to apply patches is to give them a high-risk rating and make enough noise about them so that people take notice.
We offer our clients a Monthly Security Protection service which provides monthly security patching for our client’s applications. The service we offer also covers zero-day exploit patches which we apply to the relevant applications as soon as we are happy that the patch is stable.
