Attachments

  File Modified
Microsoft Word 97 Document ExceptionRetrievalEscrowedKeys.doc Revised concept document on exception retrieval of escrowed keys Jun 14, 2010 by Greg Kroll


From: Brooker-Gross, Susan
Sent: Friday, June 04, 2010 10:54 AM
To: Dunker, Mary; Benchoff, Phil; Cooper, George; Galligan, Frank; Herrington, Karen; Rooney, Kevin; Kroll, Greg; Marchany, Randolph; Medaghri Alaoui, Ismael
Subject: Soft PDC project: key retrieval

I’ve attached (and will post to the wiki) a concept document that I think would get us going on appropriate methods for key retrieval by someone other than the person him/herself.

  • No labels

3 Comments

  1. Greg Kroll

    Randy Marchany's response to the concept document:

    From: randy.marchany@gmail.com randy.marchany@gmail.com On Behalf Of randy marchany
    Sent: Saturday, June 05, 2010 5:45 PM
    To: Brooker-Gross, Susan
    Cc: Dunker, Mary; Benchoff, Phil; Cooper, George; Galligan, Frank; Herrington, Karen; Rooney, Kevin; Kroll, Greg; Marchany, Randolph; Medaghri Alaoui, Ismael
    Subject: Re: Soft PDC project: key retrieval

    All, Here are my comments on Susan's concept doc.

    1. Point 1.a - Probably the most common scenario we've seen so far. In this case, the key escrow solution doesn't have to be technologically advanced. A simple procedure like writing the passwords on a form and sealing copies of it in a set of envelopes is adequate. This is most important to consider since the biggest fear is that someone would hold the data "hostage". If it's a copy, let them think they're holding it hostage (smile).

    2. Point 1.b - I don't agree with the last sentence: "Therefore, separating employees must un-encrypt university records and transmit—SECURELY—to appropriate supervisor or university office." Seems to me that providing the password to the supervisor and them verifying the password works is sufficient. If you have a viable key escrow system like the simple one I mention in point 1 or something more sophisticated then this isn't an issue.

    3. Point 2 - I believe policy 7035 is going to to have to be modified to account for encryption of data/email. Our office has aided in numerous fraud investigations and frankly, we've been lucky so far. Our forensic forms do ask for encryption keys if any exist. However, there is no policy requirement that the keys be "escrowed" or that the person be required to give up the key.

    4. Point 3 - there are procedures already in place for this as a result of the shootings. The ITSO participated in a couple of such retrievals. I think we should check with the Dean of Student Affairs to get a copy of their procedures. It's proven. Also, when Judy was killed, I believe Wanda ran Ophcrack against her desktops to get access.

    5. Point 4 - If we're not talking about PDC type keys, why would these requests go to IMS? If a dept has their own system, wouldn't it make sense to ask them?

    6. The question: "In any of these situations, should there be administrative retrieval (i.e., retrieval by a disinterested party) rather than providing the retrieved key to the requesting party?"

    • very dependent on the situation. Definitely in the case of a legal investigation.

    The next question: " What happens to the retrieved key after the extenuating circumstance is over?"

    • I would guess it's the dept's responsibility to change the key asap.

    The concept doc has some good questions to consider.
    -r.

  2. Greg Kroll

    Susan Brooker-Gross's response to Randy:

    From: Brooker-Gross, Susan
    Sent: Monday, June 07, 2010 2:43 PM
    To: Marchany, Randolph
    Cc: Dunker, Mary; Benchoff, Phil; Cooper, George; Galligan, Frank; Herrington, Karen; Rooney, Kevin; Kroll, Greg; Marchany, Randolph; Medaghri Alaoui, Ismael
    Subject: RE: Soft PDC project: key retrieval

    Referencing Randy’s numbering. . .
    2.Point 1.b. See wording change attached.
    3. I wouldn’t think that Policy 7035 would be the appropriate place for an “encryption policy.” Do we want a policy that requires any encryption on university devices to have an access plan, such that failure to make arrangement for access is itself a violation of policy, subject to serious disciplinary action? I think such a policy would go through governance rather than be an administrative policy, particularly to really push the disciplinary issues.
    4. Point 3—These are the current procedures that IT personnel should be following: http://www.it.vt.edu/publications/pdf/RetrievalandReleaseofInformationProcedures.pdf. The post 4-16 practices include the transmission to a student’s family through the Dean of Students and Office of Recovery, or an employee’s department head on request. Jeb is the designated manager and conveyor of the information and should be coordinating requests for information.

  3. Greg Kroll

    Phil Benchoff's response to Susan:

    ----Original Message----
    From: Benchoff, Phil benchoff@vt.edu
    Sent: Monday, June 07, 2010 3:52 PM
    To: Brooker-Gross, Susan
    Cc: Marchany, Randolph; Dunker, Mary; Cooper, George; Galligan, Frank; Herrington, Karen; Rooney, Kevin; Kroll, Greg; Medaghri Alaoui, Ismael
    Subject: Re: Soft PDC project: key retrieval

    On Mon, Jun 07, 2010 at 02:43:22PM -0400, Brooker-Gross, Susan wrote:
    > Referencing Randy???s numbering. . .
    > 2.Point 1.b. See wording change attached.
    > 3. I wouldn?t think that Policy 7035 would be the appropriate place for an ???encryption policy.? Do we want a policy that requires any encryption on university devices to have an access plan, such that failure to make arrangement for access is itself a violation of policy, subject to serious disciplinary action? I think such a policy would go through governance rather than be an administrative policy, particularly to really push the disciplinary issues.

    I haven't seen the original document since catdoc won't read it, but
    the access issue above isn't any different than not having an appropriate
    backup of the data. Even under the "hold the data hostage" scenario,
    it's no different than an employee deleting or changing data. I don't
    think the word "encryption" belongs in a policy except as a possible example
    of dealing with the actual issue.

    Phil