Re: FYI: Another round of spear Phishing

["Mclaughlin, Kevin (mclaugkl)" <mclaugkl () UCMAIL UC EDU>]

I would not call using deception to educate an unethical activity.  I often
use deception when teaching my Information Security course and when running
our day long cyber warfare event.  I agree that asking for real data in the
scenario being outlined below, or causing public embarrassment is a bad idea
and could have some legal (security breach) ramifications but designing a
more passive gotcha scenario that doesn't embarrass or use any form of
sensitive data could be beneficial.  Example:  (IMO) sending an email which
has them click on a link to go to a website and have a banner on the website
that educates them about the dangers of phishing seems to be a perfectly
acceptable Information Security measure.

 -Kevin


Kevin L. McLaughlin
CISM, CISSP, GIAC-GSLC,PMP, ITIL Master Certified  
Director, Information Security
University of Cincinnati
513-556-9177 (w)
513-703-3211 (m)
513-558-ISEC (department)
 
 
 

CONFIDENTIALITY NOTICE: This e-mail message and its content is confidential,
intended solely for the addressee, and may be legally privileged. Access to
this message and its content by any individual or entity other than those
identified in this message is unauthorized. If you are not the intended
recipient, any disclosure, copying or distribution of this e-mail may be
unlawful. Any action taken or omitted due to the content of this message is
prohibited and may be unlawful.
 


-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Curt Wilson
Sent: Thursday, June 19, 2008 12:54 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] FYI: Another round of spear Phishing

My $.02 is that a significant awareness campaign needs to be put forth 
to educate users as much as possible, and then supplement with some type 
of testing of the control. Despite awareness raising attempts, it's 
likely that some users will fall for it anyway (as many .edu's have 
seen). Spoofing the attackers and asking for username and passwords in 
email is an outright bad idea - plain text transmission, storage of 
plaintext password in outbox, destination mail server and & eventual 
recipient host (page file, browser cache, mail client, etc). Way too 
many leak points to be an effective strategy (it reduces security), let 
alone the ethical implications. That being said, there may still be room 
for some assessment & testing to help raise awareness.

We as a community are familiar with using various tools such as Nessus 
and other tools (Core, metasploit, webapp inspection tools, brain, etc) 
to perform authorized vulnerability assessments and penetration testing 
where appropriate, but the ethical and organizational considerations of 
IT/security staff preying upon the users perception vulnerabilities (aka 
"social engineering") may create a scenario where the attackers (who 
have no such scruples) may have an advantage if we can't find effective 
prevention countermeasures. I once heard someone say that the attackers 
should not be the first ones to test your defenses. I agree with this 
philosophy, and while system development and design should always 
include security from inception, we all know this doesn't always happen. 
How can we apply thIS principle here in the current wave of attacks, and 
for attacks that haven't yet been invented? The number of attack vectors 
is staggering. There are proponents and opponents of penetration 
testing, but as long as universities with their unique culture offer a 
soft underbelly to the attackers we have work to do. Finding helpful 
ways to supplement awareness training with testing and assessment for 
user perception vulnerabilities should be considered, imho, and the 
topic should be explored further.

One practical approach that I'm sure many of you already do is reject 
the bogus "reply-to" email addresses at the mail server(s). This assumes 
you know all of the "reply-to" email addresses. This at least stops the 
message from being sent, but it doesn't directly educate the user. Not 
to mention this is not effective when someone is using gmail or other 
off-campus webmail that you don't control. IPS rules could also be 
useful, but less practical in the event of SSL/TLS webmail.

Targeted education for those people who fall for the real attacks is a 
good idea and I'll bet they won't fall for a similar trick again (fool 
me once...) But this depends upon security staff being aware of all the 
attackers "reply to" addresses, which is easy when you have many 
messages from the same sources but what about a highly targeted spear 
phish? In that case, you'd better hope that the user is fully patched 
and aware.

How can we best be proactive against these types of attacks instead of 
just reacting?

Bob Bayn wrote:
> Dean Halter wrote:
> > I certainly agree that no one wants to look the fool.  It's just that the
> > folks that are going to fall for the test would probably also fall for a
> > scam.  I am curious to hear what others think of using "deception" to
> > educate.
>
> My educational experience is replete with "trick questions" on
> exams I took.  The ones that tricked me are the ones I remember
> best.
>
> I am beginning the discussions here about constructing a phake
> phish as an awareness device.  We'll see who we get on board with
> the idea and how we might deploy it.  I'm thinking of a limited
> phish spam at some of our employees, and a little followup in
> the student paper (which will probably get picked up by the news-
> starved local paper) and then maybe a followup phish spam to some
> students in the fall, with more publicity followup.
>
> One question is which kind of "phish" to use as a model: 1) the
> one that asks for an email password by return email or 2) one
> that directs the user to a look-alike website at a clearly bogus
> URL.  We've been getting a LOT of the email reply variety lately.
>
> --
> Bob Bayn  ride-a-bike (435)797-2396
> Network Security Team coordinator
> Office of Information Techology
> Utah State University


-- 
Curt Wilson
SIUC IT Security Officer & Security Engineer

Attachment: smime.p7s
Description: