IT Security Information — Report an Incident

Last Updated: 06/16/2017

Reporting an Incident - Quick Steps

Notify the following agencies to report the suspected event:

Determine the extent of the intrusion

  • Change system password
  • Check the /etc/passwd file for new accounts
  • Review log files
  • Look for modifications made to system software and configuration files
  • Scan system for new binaries (including user directories)
  • Check other local systems
  • Check for systems at remote sites that may have been proxied to this system
  • If determined system was indeed compromised, go to "Recovery steps"

Follow these recovery steps

  • Make copies of the log and configuration files
  • Disconnect system from the network
  • Make a list of local system users
  • Notify users of the event and estimated downtime
  • Force users change their passwords during next login
  • Supply ITS and system administrators of dependent systems with the users list
  • Check for, and delete "expired" accounts
  • Reinstall system software from vendor-supplied media
  • Continue with the steps recommended in "Secure your system"

Notify the agencies below of the suspected event

Whenever you suspect the system under your responsibility has been compromised, it is strongly recommended that you contact the following agencies:

University IT Security Office

  • Please email the pertinent intrusion alert to IT Security office staff will assist you in handling the intrusion, and will also notify all relevant agencies as required.
  • To send sensitive information, please encrypt the data using PGP.  If you receive your email on the compromised system, please indicate this, and include an alternate address at which you can be reached.

Local Support Center

  • It is imperative that in addition to the email notification above, you also notify your local support center. Since email is not guaranteed to be read continuously, notifying the IT Service Center assures that the IT Computer Imergency Response Team (ITCIRT) is immediately notified

Other relevant agencies

  • Various departments have internal support arrangements and notification procedures. Notifying the IT Security Office and the IT Service Center should not stop anyone from also using departmental notification procedures. In many cases, intrusions either started on a neighbor's machine or sprung to a neighbor's machine. It is imperative that you notify known local system administrators of a potential or real intrusion. This increases the chances of a quick discovery of an intrusion and helps contain and limit its scope.

Determine the extent of the intrusion

  1. Change system password
    While at times suspected intrusion may turn out to be a "false alarm" it is imperative that you change all passwords to privileged accounts on the suspected system, as well as on other proxied systems. Remember that privileged accounts include those to which administrative functions have been delegated (e.g., accounts listed in "sudoers," accounts which have been granted backup permissions, full access to local device, etc.)
  2. Check the /etc/passwd file for new accounts
    Inspection of the /etc/passwd file can reveal an intrusion. It is possible that the intruder(s) created new account(s) with special privileges. Such accounts are usually used by the intruder(s) as a back door into the system.
  3. Review log files
    Unless you already have a clear data file of how the system has been compromised, the first thing to do is examine the log files for unusual events.
  4. Look for modifications made to system software and configuration files
    This is a more difficult and time-consuming task, but often necessary to avoid a redundant system re-install. This step is productive only in cases where you already have configured your system previously with security in mind. This is to say, you have installed and ran software like Tripwire, which registers the MD5 checksum of various systems binaries, etc. In such case, you can systematically detect Trojan horse binaries or modifications to system configuration files. If you have not previously run system security software, go to the next step.
  5. Scan system for new binaries (including user directories)
    A scan of your system can detect newly installed software in directories accessible only through privileged access. This in turn can reveal intrusion. Scanning user directories can reveal binaries or scripts with the setuid/setgid bits turned on, also indicating a potential intrusion.
  6. Check other local systems
    In many cases, when a system is compromised, the attack either started on another local machine or sprung to other local machines. This is more likely in environments with several servers configured for trust relationships or in departments that share the same local network segment (broadcast domain). Pay close attention to the login records on your system and systems which:
    • have common user accounts
    • "trust" your system (e.g., permit remote shell functions, obtain password files, etc.) 
  7. If determined system was compromised, go to "Recovery steps," below.

Recovery steps

  1. Make copies of the log and configuration files
    Immediately make a copy of pertinent log files and store them on a system that doesn't participate in a trust relationship with the compromised system. If you take advantage of a loghost service, notify the loghost administrator of the compromise so that he or she can extract log information as well.
  2. Disconnect system from the network
    At this point, it has been determined that an intrusion took place. While it may not be obvious, the intrusion can still be in progress. Thus it is imperative to disconnect the system from the network.
  3. Make a list of local system users
    Prepare a list of local users (preferably this list already exists with all the pertinent information: username, first name, last name, phone number, etc.).
  4. Notify users of the event and estimated downtime
    Since the system has been compromised, the worst should be assumed. There are many implications on local users. The intrusion will also affect users' accounts on other systems. It is imperative to notify the users on the affected system as quickly as possible of the event, the possible ramifications and estimated unavailability of the system. Possible ramifications are explained in the next two paragraphs.
  5. Force users to change passwords before next login
    Since the worst should be assumed, all users' passwords should be expired immediately. This will force users to change their passwords upon next login. On systems that use more advanced forms of authentication (ssh, kerberos, etc.) expiring the passwords is not sufficient, as these applications (e.g., ssh) do not use the regular APIs or forms of authentication. In such cases, passwords have to be modified (as opposed to expired) and other steps, pertinent to each application's authentication specifics, must be applied.
  6. Supply OIT and relevant system administrators with the users list
    Most likely, users on the compromised system also have accounts on other systems, in particular ITS systems. Again, since the worst has to be assumed, those users' passwords on all accounts have to be treated as recommended in the previous paragraph. For this, the list of usernames has to be supplied to ITS through the established contact in the IT Security Office.
  7. Check for and delete "expired" accounts
    Many systems have a tendency to accumulate "dormant" accounts. "Dormant" accounts are those of individuals who are no longer with the department or the university, or simply accounts that have not been used for extensive periods. Such accounts represent a significant security threat and thus need to be disabled, or better, deleted.
  8. Reinstall system software from vendor-supplied media
    This is the ultimate "sanitation" step after an intrusion. Reinstalling all system files from vendor-supplied media guarantees that all system files are "clean." Configuration files have to be examined and cleaned as well. It is important to understand that reinstalling the system from a backup is NOT recommended, as the backup files also may have been compromised. While this, and all the steps above are tedious and time-consuming, they are imperative in the "sanitation" process. Without this step, you can never be sure that the compromised system was indeed "purified". However, without performing the steps recommended in the previous paragraph, your system will not be secure enough to prevent a similar intrusion. Please, carefully read the instructions. Remember to apply all appropriate security patches once the system installation is complete (preferably prior to reconfiguration).