Please report any problems to firstname.lastname@example.org or use our support form. See release notes for more info https://wiki.doit.wisc.edu/confluence/display/ST/Confluence+5.1.5
Protection of Sensitive Information during Transmission (ITransmit)
Protection of Sensitive Information during Transmission (ITransmit) is developing recommendations for policy and guidelines that complement and extend the previous initiative that addressed Storage and Encryption of Sensitive Information (IEncrypt).
Monday, Sep 19, 2011, 3:00-4:00, Rm 3207 CS.
- Agenda Review
- Re-visiting process, charter, and deliverables
IT Policy Program
Examples of charter and deliverables:
- Current situation and need to re-visit?
- Where are we at in the process?
- What are we delivering to the CIO?
- Do we need to revise the charter? If so, how?
- Need to re-visit goals and deliverables:
- We spent too little time on process and brainstorming at the beginning.
- As a result we did not develop a clear understanding of what we're trying to accomplish and what we're delivering.
- We're at step 3 (elaboration) of the IT policy process, delivering recommendations to the CIO
- This team is following up on a previous recommendation, so we can and should be more detailed
- Expectation going in what that we would recommend guidelines (at least.) It was not specified if these would be in finished form, or an outline.
- OK as is. We need to interpret what it means in terms of goal and deliverables.
- Our goal (in a nutshell):
We're trying to keep sensitive information out of clear text email.
(This is an oversimplification since it ignores many other use cases, but it captures the essence of the problem for the average end user.)
- We're delivering:
- guidelines, definitely
- principles, probably, example:
- Use strong encryption technology
- Follow technical standards
- Delete extra copies of sensitive information
- Don't send SI if you can avoid it
- Don't collect SI if you can avoid it
- policy, maybe, waiting until we're further along to decide
- procedures, definitely not
- We need to develop "point of view" documents. These are one-pagers, that explain "Why we care" and "What to do" (not procedure, but actions.) Points of view include at least:
- End user
- Point of view documents should be outlines rather than final form. Communications and others will help complete them. Don't forget to include:
- What to do if you receive unencrypted sensitive information (e.g. contact sender, mention encyption options for future exchanges.)
- Cloud services
- For sysadmins, developers and power users who need to match technical solutions with cases, there are excellent examples available, such as:
- We want to recommend:
- Policy? (Maybe)
- Communications Strategy, (perhaps with supporting material in Appendices)
- Follow on implementation team(s) or project(s) to look at technical solutions useful to the average end user, for example:
- Use of the MyUW or MyWebSpace to exchange SI
- Document Exchange Services (local or cloud)
- How we use some combination of solutions to exchange SI with colleagues at other orgranizations
- Moving forward
- What issues do we need to think about?
- How do we want to go about doing that?
- See above, plus a lot of what we've already written is still applicable:
- We've already written most of the background listed in the charter, but we should check that.
- We have some of the principles outlined.
- Next Steps?
Action: Gary will edit the document, and we continue improving it.
- ITransmit Meeting 2011-10-03 11:30-12:30, Rm 2281 CS.
- ITransmit Meeting 2011-10-31 3:00-4:00, Rm 3207 CS.
- ITransmit Meeting 2011-11-14 3:00-4:00, Rm 3207 CS.
- ITransmit Meeting 2011-11-28 3:00-4:00, Rm 3207 CS.