Re: Response to phishing e-mails

[Nick Semenkovich <nick () SEMENKOVICH COM>]

> We've only had two egregious repeat offenders.  Each of these users responded to three simulated phishing exercises 
> and two or three actual phishing scams.  For these two users we've had to have an official letter to their 
> supervisor, Dean, and HR notifying them that continued issues may result in suspension or revocation of computer 
> access.  We don't like to have to get to that point, but sometimes it is necessary.  Thankfully - that has worked 
> well.  They have not fallen for any additional phishing scams/simulations in the last year and a half.  It has turned 
> one of the two users into an excellent reporter of phishing messages.  Sometimes you are forced to take a more 
> forceful approach to impress upon them that there are potential consequences to the individual (and not just the 
> college).
>
>
> Paul Chauvet
> Information Security Officer
> State University of New York at New Paltz


The larger issue is whether to treat security as a problem with your
users, or a problem with what you've set up for them.

When it's treated as a problem with your users, it's a never ending
stream of new students & staff, one-off punishments, etc. -- and it's
too easy to put the problem on others.


For the users who get phished, the question shouldn't be "How can we
make our users better?" but instead -- "How can *we* be better?"


Why not ask:

- How is it that our users can secure their Twitter accounts with
two-factor, but not their access to our e-mail systems, HR, and
payroll? (That arguably borders on negligence in more regulated
fields, like banking and healthcare.)

- Why is it even *possible* that having just a single user's (probably
weak) password can result in high levels of access (VPN connectivity,
spam/phishing mail sent, payroll changes, educational FERPA-protected
records, etc.)?

- Why do we allow a user, who's been connecting to Webmail from the
US, to suddenly authenticate to POP from China or EC2 and send 10,000
messages to domains we've never sent mail to before?


Punishing the two users who responded to simulated phishing improved a
*tiny* aspect of those two user's security, but it doesn't address the
larger problem (and you probably left them feeling like IT was an
adversary, and not a friend).

- What if instead, you just required their accounts use two-factor?
(Looks like you're using Jasig's CAS -- have you tried Chris
Hyzer/UPenn's Open Two Factor?)

- What if you scoped important services (HR / payroll, registrar,
etc.) to campus IPs only?

- What if you set SPF hardfail, published a _domainkey policy, and
established a basic DMARC policy? (A bunch of servers in China are
sending mail as @newpaltz.edu -- how many of those do you think are
phishing attacks?)


I don't mean to pick on New Paltz by any means -- you at least have a
sane SPF policy. A number of people discussing phishing in this thread
don't even publish SPF records (!!!), and show huge volumes of
spam/phishing impersonating their domains from lack of DMARC / sane
SPF, etc.


- Nick

-- 
Nick Semenkovich
Laboratory of Dr. Jeffrey I. Gordon
Medical Scientist Training Program
School of Medicine
Washington University in St. Louis
https://nick.semenkovich.com/