Do it now, do it later, do it with others
I’m sure many of you reading this have been in the same predicament, facing the dilemma of falling foul of a perverse patching policy due to a ‘human factor’. It was around 11.30pm in a dingy bar in Leeds when it last happened to me and I was at a leaving party of an ex-colleague. Somewhat ‘worse-for-wear’ due to both the intake of Bavarian beverages and the absence of my reading glasses, it suddenly happened. I was useless, at its mercy and it took advantage of me. My phone beeped and vibrated in my pocket and my immediate thoughts switched to disasters at home. After all, who on earth would be calling me at this time at night.
"“Your phone requires you to change your pin every 90 days”"
Great. Just great. I know the message, but couldn’t quite make out all the small print that came with the standard notification. No matter how many cancels, swipes left, right n, there was no getting rid of this message. It;s your phone, but this policy is being forced on you and you are currently inebriated and frankly, without your phone you are neither getting a taxi, nor remembering where you live. If you want to get home, you must now come up with a 6-digit number that you have never used before. That was the easy bit. The harder bit was in the morning when you discover not only have allied carpets applied their trade wall to wall inside your mouth, but there are some 999,950 numbers that you have no chance in guessing which one you used.
This is just one end of the spectrum of perverse patching policy, the overzealous end.
“Would you like to postpone this patch?”
The other end is just as bad. It’s a bit wishy washy, lame duck and generally makes no difference to security at all. It’s where the user has the ability to ignore policy and just carry on – forever. Research presented at CyberUK ’16 demonstrated how human behaviour differs when there isn’t a technical enforcement of the policy. People do prefer to ‘round up’ their patches. Why take a break from work / Netflix / Facebook when you can postpone the update? After all, updating your machine with 10 updates tends to take the same amount of time as just updating it with one! Surely doing 1 ten times is wasteful?
We know that the latency for companies to get a patch out to the user base is never going to stop the true ‘0-day’. Rightly or wrongly, most of us now refer a vulnerability as a 0-day if it is ‘fairly new’. The differential factor being how long the vulnerability has been out in the wild, compared to its disclosure amongst trusted security professionals. The rapid installing of security patches is very effective against disclosed vulnerabilities.
Where a user can delay, postpone or elect not to apply a security fix is just another Perverse Patching Policy.
Perceived Problems of the Perverse Patching Policy
The problem within a perverse patching policy is not normally within policy itself, but it tends to be within the technical enforcement of it. The policy will be correct when it says install all patches as soon as possible. Security professionals and ICT departments just need to understand human behaviour and user needs before creating the controls.
Just because the Security Person desires it, does not mean that all patches must be installed with 30 minutes of receipt. We all dream of a Security Utopia; in reality it only ever exists in the dreams whilst sleeping off Munich’s finest liquid concoctions.
Prevention Prevents the Perverse Patching Policy
The first stage is to understand the risks about different control approaches. What is the organisational risk of a single phone running an outdated app, compared to the legacy web facing SQL server box that still runs a business critical service? Should your organisation treat all patching the same or be more pragmatic about where you want to concentrate your efforts to achieve 100% update saturation? This should give you a baseline that is roughly aligned to your organisations risk appetite.
Next you need to look very closely at your users. Should your DV cleared sysadmin be trusted to postpone a patch for operational reasons? How about the unknown temp who is only here for a fortnight doing keyboard entry? Should ‘Bob’ who developing a new application on a certified environment be allowed to stop all patching? Look at your user needs compared to your organisations needs and determine where the balance lies.
Then there is the actual patch itself. Not all patches carry the same impact or weight. A small patch may fix a single critical vulnerability that only your organisation may suffer from, or maybe just changing the colour of a menu on the office ribbon. Most patches are categorised by their manufacturers as critical/severe/low, but who in your organisation actually readjusts that score based upon the impact against your company?
A patching policy isn’t just a document that sits on a shelf. It shouldn’t only be looked once every 3 years as part of an ISO27001 certification, nor be written to entertain a board by its mere existence. Nor is it a single paragraph of ‘yep, this is a good thing, we’ll do this’. It is neither shelfware nor written on the back of a cigarette packet. It is something of significant value that helps protect your organisation.
The patching policy and its associated documentation needs to be the statement of the organisations approach to keeping secure. It must show how the risk is perceived and how the organisation wishes to protect itself. It needs to describe how we approach the prevention named above, looking at threats, exposure and people.
The Security Implication of Gender
Do it now, do it later, do it with others I’m sure many of you reading this have been...