In the world of Cyber, one of the mantras that CISOs and their
IT Security teams keep hearing about is the need to keep up with the software
patches and upgrades for their systems on a regular basis. But unfortunately, many of them fail to do
this. In fact, a recent study by the Ponemon
Institute found that over 42% of businesses were impacted by a security breach,
and a lot of that could have been mitigated by simply applying the needed
patches.
More information about this study can be seen at the link
below:
From what I have seen, there have been many tidbits of
advice offered on the web, but there are few places that actually offer a
central place for some key tips. So,
this is the purpose of this blog, and here we go:
1)
Decide what updates are needed:
The
notion with many CISOs is that they should download and apply everything, then
all will be good. However, the opposite of this could
happen. There may be some patches that you
may not need, and in the end, it could
cause more harm than good. So, you need
to sit down and figure out which
patches are needed the most, and work from there. Ideally, you should designate somebody from your IT Security team to look for the newest
patches and decide which is the most
critical to download. But of course, this
person should not have all of the authority
to do so, you should probably have a meeting at least once a week to review
what the patches are and what
is needed first. To help address what is
indeed critical, use some kind of ranking
system, and keep it simple. For example,
you can use a scale of 1-10, where “1” would be
the least needed and “10” would be the most needed. Or, if you want to use an established framework, then the Common
Vulnerability Scoring System (aka “CVSS”) could be used. Here is their
ranking system:
*7.0–10.0
is critical
*4.0–6.9
is important
*0.0–.3.9
is optional
2)
Test your patches:
As you download your needed
patches, make sure you test them out first in a sandboxed environment. This is an isolated area to see how well it
would work, and how it will co mingle with your software applications and even
hardware. It is very imperative
that you do this first before you put them into the production environment!!! Many vendors are notorious for
having glitches in their patches, and as a result, rather than fixing the
problem, it makes it worse, and leaves you that much more open to a breach. And once you decide a patch is safe enough to
be applied, it is also very important that you do it in a phased in, planned
approach.
3)
Apply the patches one at a time:
One other key rule that as a CISO
you need to keep in mind is that apply your patches one at a time, don’t
ever rush to do them all at once, as this could cause things to get messed
up!!! So for example if you have ten patches to be
applied, test them one at a time in the sandbox (or in parallel if you can
create a multiple number of them). Once
they have been approved for the production environment, then apply them one at
a time. By doing it this way, you are
more or less assured that everything will go through in a seamless fashion,
with no major hiccups or downtime.
4)
Have a Change Management Team:
This is the fancy techno jargon for
documenting all of the patches you have downloaded, and intend to apply. In this regard, you should have a representative
from each department in your company attend the weekly meeting, in order to get
their input as to how they could possibly be affected by the patches. For example, you may think that applying them
is necessary from a Cyber standpoint, but these patches can also have effects
on other applications that are used by the differing departments. Therefore, you need to have buy in and
approval from these representatives.
Just don’t simply make a blanket statement that they are needed,
customize your pitch as to how it will be relevant to everybody on the Change
Management Team.
5)
Guage the success:
After you have applied your needed
patches, it is then important to gauge how successful they have been. Of course, which metrics to be used are entirely
dependent upon your own requirements, but a good rule of thumb would be if you
experience less security breaches than before.
A good reference to start with is at this link:
https://blog.gitnux.com/patch-management-metrics/
My Thoughts On This:
In one of my first jobs in IT, I was the one that was
responsible for the entire patch management process. To give you idea of what it entailed, here is
what was done, on a weekly basis:
*Monday: Go to vendor’s
website, check for any new patches. Have
a meeting with the team later in the day to see what is needed.
*Tuesday – Wednesday:
Download the patches in a sandbox environment, using isolated
servers. Review results, and submit them
to the Change Management Team.
*Thursday: Get
feedback from Change Management Team, and get the necessary approvals.
*Friday: Notify the
end users of patch schedule, and the times when interruptions could be expected. After people leave for the weekend, start the
patch update process into the production environment. This should be done only after hours
or on the weekends!!!
As you can see, the patch management process is in itself a full-time
job, so the need is imperative to have a dedicated resource for this. As I indicated in the schedule above, this needs
to be done on a weekly basis, with no change in schedule. Given the Cyber Threat Landscape of
today, it is imperative that all of this is done on a timely basis. By adhering to a strict schedule, you will
have the proof that you are trying to be compliant.
No comments:
Post a Comment