Thursday, April 27, 2023

Don't update promptly

I was reading an article about cybersecurity strategy and how some principles could be brought on table for a business to hold a stable cybersecurity posture, like having global policy with all its procedures, guidelines and baselines, maintaining a disaster recovery plan for potential cybersecurity incidents and adhering to reknown security frameworks and standards like NIST 800-53a and ISO 27001.

In that article there was one principle mentioned however, that doesn't flow nice with the best practices as far as my experience has taught me, that principle is "apply update as soon as it is available... or .. update promptly.."

As matter of fact, when we operate critical systems we are so cautious that when an update is available, we set a delay period to observe and inspect potential feedback, so in case a reported bug or misconfiguration was originated by the applied update we would have kept our systems safe until a secure update has been released.

A well respected business would have setup redundancy or pre-production environment for their critical systems. This allows the IT department to test eventual updates without impacting the availability of the business operations and ensure only safe updates are applied on the live systems. Another good policy would be to apply the update gradually, system by system, instead of applying it on all at once, this can stop further damages if the update causes an incidents on the impacted systems, and consequently keep our systems running in fail-safe state. 

How not apply update promptly in a simple diagram

In some cases when critical update is released to fix a vulnerability that has already an exploit in the wild, we may get pressed to apply the update and give some degree of relief to the stockholders or we may show some wisdom that there is no threat and we need to test the update beforehand. This actually bowls down to risk assessment in regard of the time we have to apply the critical update before the risk becomes real and unavoidable.


  1. It is quite the opposite. No one can take responsibility for running non-gold bits.

    1. What about risks on untested update ? or do we have to assume gold bits are mine and yours and everybody else ?


What do you think ?