Q: What about sensitive data in Request Tracker (RT)?

• Should Request Tracker be used to keep sensitive data?
• Can I use Request Tracker to send or receive high risk data such as Personally Identifiable Information (PII)?
• Can I use Request Tracker to send, receive, or store Social Security Numbers (SSNs)?
• Can I use Request Tracker to send, receive, or store payment (credit) card numbers?
• Can I redact information from a history entry in Request Tracker?
• Can I remove credit card numbers or social security numbers from an RT ticket?

Context

• Request Tracker (RT) at MIT
• Ticket tracking via help.mit.edu

Answer

Short answer

The short answer is No.

Slightly longer answer

The Request Tracker service on help.mit.edu is explicitly not designed to hold, archive, transmit, or process sensitive information. This includes social security numbers, financial account numbers, payment card numbers, and other information covered under Massachusetts PIRN regulations.

Why not?

• MIT's central Request Tracker system is a large system allowing some level of access by virtually every member of the MIT community
• The system is designed as a general-purpose trouble ticket system; it is not designed to secure sensitive data, a business requirement that can not usually be retrofitted onto a general-purpose system
• The nature of our Request Tracker instance as MIT's central trouble ticket system is to send and receive massive amounts of email directly to and from hundreds of thousands of email addresses both inside and outside MIT; email is inherently insecure and can be subject to interception and misdirection
• Request Tracker retransmits email sent to it based on notification policies set for individual queues, so the ultimate recipients of incoming email are not always known to the originator
• Request Tracker cannot encrypt email between arbitrary sets of senders and recipients; although it will retransmit encrypted email, the nature of Request Tracker's notification and retransmission system makes it very difficult to use client-side encryption
• Access control is delegated to individual queue administrators and there is no central policy enforcement capability beyond the securing of and protecting the integrity of the system itself
• Queue administrators have complete control over who they wish to grant access to, which may or may not be in compliance with access policies for sensitive data
• Request Tracker does not offer a screen timeout feature, so ticket view screens accidentally left open will remain so on a user's desktop

Accidentally received sensitive information

In the event sensitive information is accidentally received as part of a Request Tracker ticket, MIT recommends you shred the ticket or request shredding of a specific history entry from Request Tracker administrators. See Can I delete attachments or individual history entries in RT? and I need to edit a history entry, how do I do this? for more information.

See also

• IS&T Security
• Information Protection at MIT