IT Security Office Services
The IT Security office will scan for known vulnerabilities on a regular basis. Currently, vulnerability
scanning occurs on the first full week of each month.
We typically scan all of the University owned subnets. These scans are opt out - please contact us
at
security@duke.edu, if you do not wish to be scanned, or if you
wish to set up alternate scanning arrangements for your machines.
To scan for vulnerabilities, we:
- Scan from a machine in the oit.duke.edu domain.
- Use nessus and
nmap.
- Due to the number of machines, and the nature of the scans, these scans are spread
over four days.
- We are looking for vulnerabilities and weaknesses rated as Critical, High or Medium by Nessus from within all of the Nessus plugin families EXCEPT CGI abuses,
and the \"Local\" Security checks. Currently, this means we are now checking
for roughly 1800 different vulnerabilities and are only targetting roughly 600 specific
ports per machine.
We run our vulnerability scans over the course of a week. We scan several subnets each day, and get
the reports out as soon as possible after the scans have finished on Thursday. The current schedule is:
- Monday: subnets belonging to OIT, DataCom, Computer Operations, and Internal Audit
- Tuesday: subnets belonging to Arts & Sciences
- Wednesday: subnets belonging to Duke internal departments (i.e. Student Affairs, HR, Finance,
Facilities, etc)
- Thursday: subnets belonging to Law, Fuqua, NSOE & Marine Lab, Divinity, Graduate School, and libraries
Duke has processes in place for purchasing duke.edu digital certificates from either GeoTrust or Thawte.
To order a digital certificate from GeoTrust, go to
https://products.geotrust.com/orders/essl/essl.do?ref=237349DUK77552. To order a wildcard certificate,
use this link:
https://products.geotrust.com/orders/essl/essl_wildcard.do?ref=237349DUK77552. You do not need a
GeoTrust account to order a certificate. Once the certificate has been ordered,
both the University IT Security Office and the Health System Information Security Office will receive
email notifications that there is a certificate waiting for approval, and the appropriate office will
confirm the request with you (if needed), and approve it.
The main difference in the GeoTrust ordering process (versus the Thawte process) is that the orderer
pays with a procurement card. There are also several options for how long you want the cert to last, and
you can get a discount if you're switching from a competitor's certificate to GeoTrust.
GeoTrust is now the preferred provider for Duke. However, you may still purchase certificates from
Thawte as well; instructions on how to do so are at:
www.security.duke.edu/thawte.html.
The University IT Security Office runs Intrusion Detection/Intrustion Prevention systems to protect
University assets and detect compromised machines on University networks. The systems are occasionally
used to quarantine misbehaving machines. (If you suspect your machine is quarantined, please contact the
OIT Service Desk (684-2200) for assistance.
The University IT Security Office runs a password cracking program against all Duke NetIDs on a
quarterly basis. The process is:
- Users whose passwords are easily cracked will be notified via email and asked to change their passwords immediately to
something more difficult for computer programs to break.
- Accounts that were easily compromised will be rechecked within 2 weeks, and every 2 weeks thereafter, in
order to find users with cracked passwords who didn't change them. The users will be notified again.
- After 3 notifications, the NetID account's password will be expired, and the user will have to change their
password to be able to use their NetID. If they can't remember their password to change it, they'll have to
call the Help Desk and answer their Challenge-Response challenges to have it changed for them
(see the OIT Password Reset Policy
page for more information). If the user has an expired password and has not set up their challenges,
they'll have to go to the Help Desk with photo identification in order to get their password changed.
Background
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.
Assessment
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.
Notification
After determining the nature of the incident, the system administrator(s)
or end user responsible for the machine or account will be contacted.
Response
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 sncident 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.
Failure to Respond or Repair
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.
Post-Incident
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.
Revisions
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)
