Re: Response to phishing e-mails

["Jones, Mark B" <Mark.B.Jones () UTH TMC EDU>]

Revocation of computer access is an interesting consequence.  Isn't this the 
same as termination or expulsion?  Is it possible to be a student or an 
employee without accessing computing resources?  But I suppose it is easier to 
get away with saying "stop or you lose computer access" than saying "stop or 
you are fired/expelled".

> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Nick
> Semenkovich
> Sent: Wednesday, October 29, 2014 3:08 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Response to phishing e-mails
>
> > 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://urldefense.proofpoint.com/v1/url?u=https://nick.semenkovich.com
> /&k=yYSsEqip9%2FcIjLHUhVwIqA%3D%3D%0A&r=o50KCUcRVN10tgtglyNVF
> w2kmizyPIIFTSGui%2BBSZ5A%3D%0A&m=EkctPLbQ0Tj9cNISV3bzN6s5R8G%
> 2Fev5d20mZcbwo8wk%3D%0A&s=1ee06cad0a6a88748022060819eb8e4dda3
> 1bb84fde6913f8ecfff1b3da3724f

Attachment: smime.p7s
Description: