[BreachExchange] Email security: why end users should never be the first line of defence

Audrey McNeil audrey at riskbasedsecurity.com
Thu Aug 17 19:18:08 EDT 2017


https://www.scmagazineuk.com/email-security-why-end-users-
should-never-be-the-first-line-of-defence/article/677892/

Why is it that cyber-security breaches always need a scapegoat?  All too
often, end-users are held responsible when a cyber-criminal infiltrates an
organisation via email. Whether it is the front-desk receptionist or the
CEO, if an individual has been targeted, the attack can be (often unfairly)
positioned as their fault. This way of thinking has inspired organisations
to spend vast amounts of time and money educating end-users about IT and
latterly cyber-security. The logic being, the biggest threat comes from
within – if they can eliminate ‘reckless' end-user behaviour, they can
prevent an attack.

This notion is clearly flawed. We don't blame people for getting mugged or
burgled because they didn't know how to defend themselves. Email was
designed for function, not security, and users shouldn't have to contend
with IT defence issues in their daily work. Anyone can fall victim to a
determined cyber-criminal. Even the most experienced and wary end-user is
susceptible.

The email threat landscape

Email scams come in many different shapes and forms. They commonly involve
some form of identity fraud to dupe the recipient into granting access
sensitive information, or the transmission of malicious content to infect
the end-user's computer and network. A very well-informed end-user may be
able to spot clues indicating malicious intent, but new, more complex
attack tactics are being developed all the time. Punycode, for example, can
be extremely hard to detect. This sophisticated form of encoding uses
Unicode characters as substitutes for regular alphabet characters, and can
make fake URLs very difficult to recognise.

The point here is that there is a long list of possible routes for
cyber-criminals to infiltrate an organisation via email. Given this
complexity, it's impossible for a business to expect its employees, who
have jobs they need to focus on, to act as a line of defence. The question
is then, how can an organisation defend itself?

Fight fire with fire

As a starting point, organisations need to stop spending money on training
users to act as a first line of defence. User training only perpetuates a
culture of blame.  At most, they should be taught a healthy level of
cynicism. No matter how many millions an organisation spends on training,
all it takes is one small mistake to allow a criminal in. Something as
innocuous as opening an infected attachment in an email, from someone
impersonating a known and trusted sender, can cost an organisation much
more than just money. After all, how can a user realistically be trained to
be ‘careful' every time they open an attachment?

The next step lies in removing users completely from the line of defence.
Instead, organisations need to implement quarantine tools to identify,
isolate and remove email security threats before they can even reach an
email server or user's inbox. Systems protected by solutions that can
detect common fraud techniques like domain impersonation and reply
redirection, as well as perform content checks to identify spam and
malware, are immediately better protected than those reliant on end-user
training.

What's more, advances in artificial intelligence and machine learning can
help these solutions keep pace with the threat. Algorithms, combined with
large training sets, can help solutions learn and improve through
experience. Each attempted security breach enhances a solution's ability to
accurately detect which emails are safe and which are compromised.

While people are arguably more intelligent than machines in certain
situations, their behaviour is also more unpredictable. A company's best
defence is robust email security solutions – a front line built on
technology, not training.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170817/056d7616/attachment.html>


More information about the BreachExchange mailing list