Incident Response - For Users

Scope

This document applies to all individuals authorized to use SDSC's IT resources. The prescribed actions and processes described in this document apply to situations involving any SDSC Host (as defined in the SDSC Security Policy) as well as any of the IT resources provided by SDSC.

Background

Incident response does not only involve IT staff and security. Users, such as yourself, play a big part too, as they are often the first to realize something "odd". However, with respect to incident response, users also have the ability to do the most damage. By attempting to investigate incidents on their own, a user may inadvertently destroy evidence or warn the intruder of our knowledge of their presence.

The procedures described in this document are designed to provide an effective means of transferring the responsibility of handling an incident or potential incident from the user to security staff with minimal loss of evidence and risk of alerting an intruder. We encourage you to make use of this process whenever you suspect an incident, not only when you know one has occurred.

Identifying a Possible Security Incident

Incidents are not always easy to spot. Sometimes you will see clear-cut evidence of a security incident, such as a warning from your antivirus software, or a host obviously acting under the control of someone else. Other times, the clues may be more subtle:

• Did you notice login activity on your account from hosts that you don't normally log in from?
• Has your computer been unusually slow or unstable lately?
• Do you end up at websites that do not correspond to the URL you entered?
• Do you get warning notifications when you haven't before?
• Have you observed any unexpected configuration changes?

These are just examples, and do not encompass all possible signs of an incident. Use these examples to give you an idea of what to be attentive for, and fine-tune your intuition. Generally speaking, should you find yourself using a computer and thinking "Huh, that's odd, this isn't right...", you are probably looking at a potential security incident.

Incident Response Procedure for Users

Please follow the steps below upon discovering a possible security incident.

Observe a Problem

You notice something seems wrong, or off. Intuition tells you that there might be a problem. This is the initial discovery of a possible incident.

Stop What You're Doing

That's right! Do not keep working and "get to it later", and PLEASE do not investigate on your own. You may end up destroying valuable evidence!

Hands Off!!

Do not use the affected machine or service. Do not log out, shut down the machine, or attempt remediation. Please leave everything in the state that you saw upon observing a problem.

Inform Security

Contact Security using the contact information provided at https://security.sdsc.edu. During business hours, you may also drop by in person. After hours or when in doubt, SDSC Operations can forward your message on to the appropriate on-call personnel.

Please do not include details in your initial contact. "I have a possible incident to discuss" is more than adequate. The information you provide may not be kept secret, and thus, alert an intruder to our knowledge of their presence.

Similarly, for the same reasons, until authorized by Security, do not talk about the incident or share details with anyone (including colleagues) except the Security group or designated incident response personnel. (You can, however, inform your colleagues that you are having "technical trouble".)

Take Notes

On paper! We will contact you to gather this information.

Try to capture your frame of mind and context of the moment.

• What were you doing when you made your observation?
• What did you observe that made you feel like something was awry?
• If the observation is a recurring issue, when did you first notice it?
• Have you noticed anything else odd?

Security will also ask you questions about your computer and accounts on SDSC resources. This is a good time to think about the answers to these questions:

• Does the affected host or service contain PHI, PII, or other sensitive data?
• Is the affected host or service used to access PHI, PII, or other sensitive data?
• Is the password for your login to the affected service used anywhere else, including offsite?
• Do any of your colleagues use the affected host or service as well?
• Who maintains the affected host or service? (Some resources are maintained by SDSC IT staff, some are maintained by individual projects.)
• Where do you normally access the affected host or service from?
• Did you touch or access the affected host or service after observing a potential incident?
  • You know you were not supposed to do that, right?
  • What did you do?

Finally, in certain circumstances an incident handler in the Security group may request some of your passwords, such as when an account compromise is suspected, or for elevated privileges on a possibly compromise host. Unless this request is made in person (i.e. a face-to-face encounter), by one of the Security group members, you must not give out any passwords. Otherwise, you may be talking to the intruder!