In the course of daily departmental operations, the University IT Security Office often becomes aware of compromised machines or accounts. In such cases, Duke is obligated to remove the threat in order to protect other computers and services, both on and off of campus.
For the purposes of this document, a computer is considered to be compromised if it is executing commands or programs at the direction of an unauthorized individual or agent (a hacker). A vulnerable computer is one that will allow an unauthorized individual or agent to run programs on the computer. An account is considered to be compromised if it is under the control of someone other than the account owner.
When the University IT Security Office is made aware of a compromised machine or account, the first step will be the classification of the incident. Such incidents can be broadly categorized as follows:
Category 1) A compromise which is actively causing problems for other computers or users. Compromised accounts will always be considered a Category 1 incident.
Category 2) A compromised machine that is not actively causing problems.
Category 3) A computer believed to be vulnerable to a known exploit.
It should be noted that these classifications are fairly broad and some degree of subjective judgment is called for in making determinations.
After determining the nature of the incident, the system administrator(s) or end user responsible for the machine or account will be contacted.
For incidents in Category 1, a compromised machine or account which is actively causing problems, it is expected that the administrator for the machine will take it off the network immediately, or that the account owner will address the problem immediately. If the machine’s administrator is not identifiable or unreachable, OIT may deny network access for the machine or account.
For incidents in Category 2 it is assumed that the compromised machine or account will become the top priority for the administrator and that the and the issue will be addressed as soon as possible. If there is a need for the machine to remain online after the notification, the administrator will respond to the Security Office giving an outline of what steps are currently being taken and how soon the machine will be repaired, in no case should this be longer than one week. If the compromised computer begins to cause problems, it will become a Category 1 incident and will be treated as such. However, a compromised account must always be addressed immediately.
For incidents in Category 3, a computer believed to be vulnerable to a known exploit, handling the incident will be at the system administrator's discretion. If the machine is later compromised, then the machine will fall into one of the two incident categories above.
In the event that the notification of a Category 1 or Category 2 security incident receives no response the University IT Security Office will have the machine removed from the network.
For Category 1 incidents, the University IT Security Office may have the machine removed from the network or the account locked within 15 minutes if there is no response.
For Category 2 incidents, a failure to respond will generate a second notification in 2 business days. If this second notification is not responded to in 1 business day, the machine may be removed from the network. Computers which remain compromised after 3 calendar days from the date of the first notification are also subject to removal from the network. If during that time, the incident moves to a Category 1 incident, the machine may be pulled from the network immediately.
At the discretion of the Security Office, machines involved in Category 1 incidents may be left online for a longer period of time depending on the severity of the network abuse that is observed and the criticality of the computer involved. In no case shall this be longer than 3 calendar days.
After a Category 1 or Category 2 incident, system administrators are encouraged to share details of the event with the rest of the system administrator community at the IT Security Liaisons group meetings.
To adjust to the changing security environment, the procedure above is subject to revision. The current version of the procedure will always be posted on the IT Security Office's website (http://www.security.duke.edu/incident-procedure.html)