[BreachExchange] People, Passwords, And Patches: Fixing The Basic Flaws In Your Security System Can Be Easier Than You Think

[Audrey McNeil]

https://www.healthitoutcomes.com/doc/people-passwords-and-
patches-fixing-the-basic-flaws-in-your-security-system-
can-be-easier-than-you-think-0001

If you’ve ever gone hiking with a group in the wilderness, you’ve probably
heard this corny joke: What do you have to do to outrun a bear? Answer: You
don’t have to outrun the bear; you just have to outrun the slowest member
of your group.

Most breaches are not the result of brilliant hackers; most are, instead,
the result of persistent efforts by moderately skilled bad guys who
continually test for weaknesses. If your system doesn’t have the common
weaknesses, the hackers will move on to easier targets. Like bears, they
don’t waste time and energy running down the more elusive prey.

People, Passwords And Patches: Getting The Basics Right

If you want to make your data safer within the constraints of limited
resources, you should focus your attention on three basic areas: People,
passwords and patches. Keep your patches up to date, enforce the use of
strong passwords where they are most needed and educate everyone in your
organization on good security behaviors. None of these measures requires
major investments or expenditures, though they do require attention.

People: Teach Them How To Stay Out Of Trouble

The first rule of using email is, “Don’t click on links in email.” Phishing
as a criminal art form has reached very sophisticated levels, and even
experienced users can be fooled. For example, Apple iOS users are seeing
counterfeit popups on web sites and within emails asking for their Apple
ID, and the fakes are virtually identical to the authentic ones within
Apple apps.

But even poorly-crafted phishing can work when the user is in a hurry or
the email comes from a familiar-sounding address. Education is the only way
to prevent users from clicking on dangerous links.

There are essentially three kinds of education: the annual,
everyone-gets-a-review, refresher course; timely education to respond to a
particular event or threat; and the polite reminder that recurs frequently.
In all cases, education should be relevant to the situation, and should be
offered in a form that is engaging enough to be memorable. If your IT team
doesn’t have education-specific skills, get help from your organization’s
education and training team.

When testing the effectiveness of education put the tests into a real-word
context and attach logical consequences to failures. One company I know
about had a strict policy of locking up the physical laptop whenever an
employee left the desk. If you failed to do so, your laptop could be
confiscated and you’d have to spend a couple of hours going through a
procedure to retrieve it. Conversely, if you were caught following the
policy, your name would be entered into a prize drawing and you’d get a
little card on your desk congratulating you for being so attentive. The
combination of immediate positive and negative feedback resulted in a whole
lot of names in those prize drawings, and very few unattended laptops that
could be stolen or compromised.

A similar approach could be used to test employee response to phishing
emails and other education topics. For example, you could send a test
phishing email, and anyone clicked on the link would have their screen
freeze and would have to go through a tedious process to get it unfrozen,
plus attend a mandatory security refresher course. Conversely, if an
employee saw the email and reported it to IT appropriately, the employee
could win a small prize, or even simply public recognition of their
savviness.

What you don’t want to do is to punish failure in ways that seem unfair.
Mild embarrassment and inconvenience are usually enough to convince folks
to avoid the action in the future, and positive reinforcement can create
allies in your cause.

Passwords: Greater Access Demands Stronger Protection

The greater the access to data on any system, the stronger the password
should be and the more often it should be changed. Setting rules for strong
passwords, and enforcing those rules, is basic security hygiene. If the
rules can be enforced electronically, all the better.

The use of weak passwords is common. I have a colleague, a former hospital
CIO, who recounts a story about a physician practice administrator who quit
unexpectedly, without sharing the password that gave access to the
financial accounts. By sitting with one of the administrator’s coworkers
and asking a few questions, he guessed the password within a half-hour
without using any electronic tools. And this was the password that
protected all the organization’s financial assets.

When I do client security assessments with the NTT DATA team, I often find
organizations using the default password shipped with a device. That’s a
flaw that’s easy to fix.

The website Ars Technica tested a list of 16,449 passwords that had been
converted using the MD5 cryptographic hash function, which is a one-way
encryption used to store passwords on a website in a way that can’t be
unencrypted. The Ars Technica deputy editor, who was a newbie to hacking,
used freely available software and cracked half of the encrypted passwords
in a few hours. When three experts got the list, they cracked 90 percent of
them. One guy unscrambled 80 percent of the list in about an hour. And the
amount of repetition was astounding. The passwords your users are dreaming
up, based on pet names, birthdays and other information easily found on
their Facebook pages, are creampuffs for most hackers.

Consider having minimum standards for strength, but no maximum for the
number of characters, because the longer the password, the harder to crack
with automated tools.

Also, you should have strict, role-based access behind those strong
passwords, to limit the damage in case a password is stolen or discovered.
And if anyone has the “keys to the kingdom” in your organization, make sure
the person has a password that is long, complicated, impossible-to-guess
and changed frequently

Patches: Time Is Your Enemy

It has been commonly reported that one recent high-profile breach was the
result of slow action on implementing a security patch. The flaw was
discovered on March 7 and a patch was issued the same day, but the victim
waited a full two months to install the patch. That gave the criminals
plenty of time to discover the flaw and create a way to exploit it.

As we are all shaking our heads over the lack of wisdom in their
procrastination, it’s worth noting that they are not alone. Research firm
voke found that 82 percent of security breaches and failed audits in 2015
could have been prevented with a patch or configuration change. Nearly half
of the companies surveyed had delayed 10 days or more before applying a
patch, and some had patches that were a year overdue.

I’m sure that a fair number of people reading this article have been guilty
of this lapse at some time during their own career, and not because they
are lazy or inattentive. Often there are good reasons to delay implementing
a patch. If you are within a few days of a major software upgrade, and
don’t have time to do the appropriate testing of the patch, it may seem to
make sense to wait. But days can turn into weeks, leaving your systems
vulnerable. While your reasons for delay may seem rational and justified,
the delay puts your systems at risk.

You can mitigate this risk by doing a simple assessment. Ask yourself if it
is likely the upgrade will be delayed (not uncommon), and how many of your
servers are involved. If delay is likely, you may be better off taking the
time to do the patches and testing immediately. If only a few servers are
involved in the upgrade, move forward with the patches on other servers
instead of waiting to do all the servers at one time. That reduces the
number of vulnerable locations in your system.

If you have a production-equivalent environment for testing, you can use it
to test patches immediately. Once you know the patch is not causing
problems, you can apply the patch to all your servers, even if there is an
update pending.

If you delay doing patches because the staff member responsible for patches
is on a two-week vacation, it’s time to do some cross-training or use
system-automation tools to ensure that this critical business need is met.

And Finally…There’s No Good Reason Not To Do The Basics

When you look at these basics – people, passwords, and patches – ask
yourself: If a business had the personal information of my family members,
do I expect them to follow through on the basics? We’d bet the answer is
yes.

In the past, you might have been able to describe a reason not to follow
through with the easiest of tasks. No longer. The stakes are too high, and
the steps to follow are simple. There’s no excuse anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180111/0d53f1a0/attachment.html>