Main Nav

Does anyone have a documented process, guidelines, or procedures taken when a user reports a compromised account? We are looking to create such documentation in order to establish consistency in our trouble ticket handling of such cases.
 
Thanks in advance!
 
Bob
 
 
 
 
Robert E. Meyers,  Ms.Ed.
Manager, Security Awareness
  Information Security Services
West Virginia University
office: (304) 293-8502
remeyers@mail.wvu.edu


Comments

I’m looking into doing this as well so I’d be interested in any templates others have developed as a jumping off point.

-------------Baylor University-------------

Derek Tonkin

Information Security Analyst

Information Technology Services - Security

derek_tonkin@baylor.edu        254-710-7061

---------------Sic 'em Bears---------------

 

Message from akirbyco@gmail.com

You could take a look at how Google is handling the DNS changer infections. http://krebsonsecurity.com/2012/05/google-to-warn-500000-of-dns-changer-...
Might be a fine line but isn't a compromised account different than a compromised machine ? And probably necessitate a different remediation procedure ? -----Original Message----- From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Aaron Kirby Sent: Wednesday, May 23, 2012 12:22 PM To: SECURITY@LISTSERV.EDUCAUSE.EDU Subject: Re: [SECURITY] Compromised Accounts Procedures You could take a look at how Google is handling the DNS changer infections. http://krebsonsecurity.com/2012/05/google-to-warn-500000-of-dns-changer-...
Message from akirbyco@gmail.com

Good point. I would say that the compromised account could be a result of a compromised machine so it would seem to make sense not to decouple the process.
Bob,

Here's our Policy and procedure for Securing Network Connected Devices (downloads as a PDF):   http://policy.business.buffalo.edu/Policy%20Library/Securing%20Network%20Connected%20Devices.aspx

Cheers,
   Rick
-- 
Rick Lesniak
IT Policy and Communications Officer
SUNY University at Buffalo

From: Robert Meyers <remeyers@MAIL.WVU.EDU>
Reply-To: The EDUCAUSE Security Constituent Group Listserv <SECURITY@LISTSERV.EDUCAUSE.EDU>
Date: Wednesday, May 23, 2012 12:29 PM
To: <SECURITY@LISTSERV.EDUCAUSE.EDU>
Subject: [SECURITY] Compromised Accounts Procedures

Does anyone have a documented process, guidelines, or procedures taken when a user reports a compromised account? We are looking to create such documentation in order to establish consistency in our trouble ticket handling of such cases.
 
Thanks in advance!
 
Bob
 
 
 
 
Robert E. Meyers,  Ms.Ed.
Manager, Security Awareness
  Information Security Services
West Virginia University
office: (304) 293-8502
remeyers@mail.wvu.edu


I'm trying to address compromised accounts, and not compromised machines.  While the two are often coupled, we are trying to address the specific concern of codifying responses to reports from users that account credentials appear to have been hacked, hijacked, stolen, etc.
 
Thanks to all for the discussion.

Bob
 


 
 
Robert E. Meyers,  Ms.Ed.
Manager, Security Awareness
  Information Security Services
West Virginia University
office: (304) 293-8502
remeyers@mail.wvu.edu


>>> On Wednesday, May 23, 2012 at 1:41 PM, Aaron Kirby <akirbyco@GMAIL.COM> wrote:
Good point.  I would say that the compromised account could be a
result of a compromised machine so it would seem to make sense not to
decouple the process.



I guess my situation is kind of different (or I’m misinterpreting what you’re asking) in that I’m looking for what information to gather/maintain when we confirm a compromised account from the point of discovery to the point of re-enabling or removing the account.  What data is meaningful to gather for the dual purposes of record-keeping and establishing trends/metrics.

-------------Baylor University-------------

Derek Tonkin

Information Security Analyst

Information Technology Services - Security

derek_tonkin@baylor.edu        254-710-7061

---------------Sic 'em Bears---------------

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY@LISTSERV.EDUCAUSE.EDU] On Behalf Of Robert Meyers
Sent: Wednesday, May 23, 2012 12:51 PM
To: SECURITY@LISTSERV.EDUCAUSE.EDU
Subject: Re: [SECURITY] Compromised Accounts Procedures

 

I'm trying to address compromised accounts, and not compromised machines.  While the two are often coupled, we are trying to address the specific concern of codifying responses to reports from users that account credentials appear to have been hacked, hijacked, stolen, etc.

 

Thanks to all for the discussion.


Bob

 



 

 

Robert E. Meyers,  Ms.Ed.
Manager, Security Awareness
  Information Security Services

West Virginia University
office: (304) 293-8502
remeyers@mail.wvu.edu

>>> On Wednesday, May 23, 2012 at 1:41 PM, Aaron Kirby <akirbyco@GMAIL.COM> wrote:

Good point.  I would say that the compromised account could be a
result of a compromised machine so it would seem to make sense not to
decouple the process.



When I become aware of an account compromise, I (run a script to) disable the password and create a ticket (in WebHelpDesk.com) with a few custom fields, below. The user *must* go through the helpdesk because self-service challenge questions and SMS callbacks could be changed with password alone. The "How Compromised?" question is required. We only started doing this a few months ago, so I don't know how useful the metrics are going to be. The other questions are optional, just to remind helpdeskers what to do. How Compromised? () Phishing () Malware () Disclosed to a "Friend" () Other (specify in notes) () Unknown Client has been told their password must be completely different than the original? () No () Yes Instruct client to change password on: [] Handhelds [] Mail Clients [] Restart Workstation Phishing accounts for the vast majority, but we have had a few passwords presumed disclosed by malware, and a case where a student was sharing their password to a parent, raising questions of online quiz integrity. Yes, we've seen several cases where password was phished, student resets their password to something that differs from the original by only one digit, repeat.
We follow a similar process and also verify that no rules have been added to mail accounts to forward or delete messages. Lesley A. Bidwell Director of Networking and Telecommunications Services SUNY College at Oneonta 607 436 2628 Lesley.Bidwell@oneonta.edu
Message from pollockj@evergreen.edu

Our process is still evolving - this hasn't happened frequently. In the most recent case, we observed that the contents of the mailbox had been deleted and some rules set to delete incoming mail. I had a conversation with the user and said not only should the original password not be reused, it should be changed on any other account where it had been used (there may have been information concerning social networking accounts in the mailbox folders, etc.) The user reply was "You mean, like on my bank account?" Sigh... Joe Pollock Network Services The Evergreen State College
Message from m.hodgett@qut.edu.au

We have had a process in place for a while now. Basically, the steps are; . lock out the account and inform the helpdesk to expect a call . when the user calls the helpdesk an incident is logged . both the incident and the user are passed to the ITsec team . the user is interviewed. This is an opportunity for understanding how the account was compromised, profiling the users, as well as raising the users security awareness . the incident and user are then passed to a team that has the ability to unlock accounts and change passwords From this process we gather stats and this has helped develop detection methods and focus awareness campaigns. Matthew On 24/05/12 05:41, Pollock, Joseph wrote: > Our process is still evolving - this hasn't happened frequently. In the most recent case, we observed that the contents of the mailbox had been deleted and some rules set to delete incoming mail. > > I had a conversation with the user and said not only should the original password not be reused, it should be changed on any other account where it had been used (there may have been information concerning social networking accounts in the mailbox folders, etc.) The user reply was "You mean, like on my bank account?" Sigh... > > Joe Pollock > Network Services > The Evergreen State College > >
some of this was mentioned by others in the thread... the list of "what to do" is in our internal wiki abbreviated here: immediate cleanup: * scramble password * remove sessions in webmail * clean email queues * remove sessions in vpn * any other successful logins from the same ip? ** did account login from other suspect ips? (we use a homegrown system similar to columbia's GULP) post threat cleanup: * clean identity in webmail * add ip addresses to watch list ** 2000+ ip addresses in our watch list * add email addresses to watch list * report phishing page via firefox * submit web form with fake credentials, aka phish the phishers (: * follow up with abuse@ emails or 'report abuse' links on web pages * log report follow up with individual: * how did this happen? ** did you "share your password" with anyone? ** did you "upgrade your quota"? ** did you "verify your account"? * reset password ** make sure it's different and not a simple "add digit" variation. ** was this compromised password used elsewhere? (bank,etc) to quote dr gregory house: "Everybody lies." we've had hundreds of phished accounts since 2008. we estimate 90+% users were phished. we watch for anomalies in behaviour.
The real answer is "It depends on the level of access the compromised account has with regard to sensitive information", but for the most general case I'd add: - Check to ensure the 'password reset questions' weren't modified by the hacker (we've seen this) - Ensure any forwards and/or other filter modifications put in place by the hacker are removed (deliver and forward rules allow the hacker to reset passwords for remote sites linked to the local user's university email account) - Restore email messages that were deleted by the hacker. -- KS Keith Schoenefeld Information Security Analyst Baylor University 254-710-6667
Close
Close


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.