Difference between revisions of "April 19, 2016 Security Conference Call"
Line 79: | Line 79: | ||
==Minutes== | ==Minutes== | ||
+ | Cochair - Kathleen | ||
* Approved Security WG April 12, 2016 Minutes | * Approved Security WG April 12, 2016 Minutes | ||
* Discuss Lloyd's suggestion - See Discussion Items below. (Item listed below under discussion) | * Discuss Lloyd's suggestion - See Discussion Items below. (Item listed below under discussion) | ||
* Privacy & Security by Design/NOW Privacy Impact Assessment (PIA) Cookbook - update - Rick, Mike | * Privacy & Security by Design/NOW Privacy Impact Assessment (PIA) Cookbook - update - Rick, Mike | ||
− | -(Mike): | + | -(Mike): |
-The PSS concept is to separate two items merging together in the standards process and calling it a Privacy Impact Assessment (PIA) | -The PSS concept is to separate two items merging together in the standards process and calling it a Privacy Impact Assessment (PIA) | ||
-The PIA (Privacy Impact Assessment) correlates to the Privacy Risk Assessment | -The PIA (Privacy Impact Assessment) correlates to the Privacy Risk Assessment | ||
Line 95: | Line 96: | ||
- Example: (Security level event) corrections to labels could be made, but it does not make the resource a new version, it remains the same version with a correction. | - Example: (Security level event) corrections to labels could be made, but it does not make the resource a new version, it remains the same version with a correction. | ||
− | -Mike Davis is seeking to sponsor | + | -Mike Davis is seeking to sponsor a Trust Framework project to create considerations on the Policy side, and not burden this on the PIA. |
− | |||
-We may include a non-normative checkoff list for follow on specification | -We may include a non-normative checkoff list for follow on specification | ||
Line 103: | Line 103: | ||
-encompasses the HL7 standard development process developer would initiate the PIA at the development process==>incorporate Privacy and Security considerations during the development process ===> then use the PIA to complete the assessment at the end of the process (covering the entire life cycle) | -encompasses the HL7 standard development process developer would initiate the PIA at the development process==>incorporate Privacy and Security considerations during the development process ===> then use the PIA to complete the assessment at the end of the process (covering the entire life cycle) | ||
- It will reference the Privacy Design Principals to assist in completing the Privacy Impact Assessment | - It will reference the Privacy Design Principals to assist in completing the Privacy Impact Assessment | ||
− | |||
Next Section Review (Project Need/Impact) | Next Section Review (Project Need/Impact) | ||
Line 114: | Line 113: | ||
-Ballot Period: Early September balloting cycle | -Ballot Period: Early September balloting cycle | ||
(Document reviewed during call) | (Document reviewed during call) | ||
− | + | -Motion to Approve Security to Co-Sponsor PIA: 2/0/0 (John moved & Glen seconded) | |
− | -Motion to Approve Security to Co-Sponsor PIA: 2/0/0 (John & Glen | ||
− | |||
-Next Step: The PIA will be brought up for vote to CBCC | -Next Step: The PIA will be brought up for vote to CBCC | ||
− | |||
Suggestion: | Suggestion: | ||
-Have a note section for developers of possible optional mitigation (Kathleen) | -Have a note section for developers of possible optional mitigation (Kathleen) | ||
− | |||
− | |||
− | |||
* PASS Access Control Services Conceptual Model - Diana | * PASS Access Control Services Conceptual Model - Diana |
Revision as of 17:47, 26 April 2016
Back to Security Work Group Main Page
Attendees
x | Member Name | x | Member Name | x | Member Name | |||
---|---|---|---|---|---|---|---|---|
x | Kathleen ConnorSecurity Co-chair | x | Duane DeCouteau | . | Chris Clark | |||
x | John MoehrkeSecurity Co-chair | . | Johnathan Coleman | . | Aaron Seib | |||
. | Alexander Mense Security Co-chair | . | Ken Salyards | . | Christopher D Brown TX | |||
. | Trish WilliamsSecurity Co-chair | . | Gary Dickinson | x | Dave Silver | |||
x | Mike Davis | . | Ioana Singureanu | x | Mohammed Jafari | |||
x | Suzanne Gonzales-Webb | . | Rob Horn | . | Galen Mulrooney | |||
x | Diana Proud-Madruga | . | Ken Rubin | . | William Kinsley | |||
x | Rick Grow | . | Paul Knapp | x | Mayada Abdulmannan | |||
x | Glen Marshall, SRS | . | Bill Kleinebecker | . | Christopher Shawn | |||
. | Oliver Lawless | x | Chris Shawn | . | Serafina Versaggi | |||
x | Beth Pumo | . | Russell McDonell | . | Paul Petronelli , Mobile Health | |||
. | Christopher Doss | . | Kamalini Vaidya | . | [mailto: TBD ] |
Agenda DRAFT
- ( 5 min) Roll Call, Agenda Approval
- ( 5 min) Approve Security WG April 12, 2016 Minutes
- ( 15 min) Discuss Lloyd's suggestion - See Discussion Items below.
- (10 min) Privacy & Security by Design/NOW Privacy Impact Assessment Cookbook - update - Rick
- ( 5 min) PASS Access Control Services Conceptual Model - Diana
- ( 5 min) Joint Vocabulary Alignment Update - Diana
- ( 5 min) PASS Audit Conceptual Model – Diana
- ( 5 min) FHIR Security report out - John
Note that there will be a FHIR Security call at 2pm PT/5pm ET See agenda at FHIR Security Agenda
Minutes
Cochair - Kathleen
- Approved Security WG April 12, 2016 Minutes
- Discuss Lloyd's suggestion - See Discussion Items below. (Item listed below under discussion)
- Privacy & Security by Design/NOW Privacy Impact Assessment (PIA) Cookbook - update - Rick, Mike
-(Mike): -The PSS concept is to separate two items merging together in the standards process and calling it a Privacy Impact Assessment (PIA) -The PIA (Privacy Impact Assessment) correlates to the Privacy Risk Assessment - The Security WKG created a Security Assessment Cookbook for use by projects in a Standards Development process - Our Needs will be met across the board with Risk Assessment and OIA - Some issues that can arise regarding labeling:
(1) Issue: When is it legal for a server to modify the labeling of a resource? - Example/Answer: If the partner puts handling instructions they should not be modified, it should be part of the trust framework
(2) Issue: There should be considerations on when labels can be changed, such as ones put on error. - Example: (Security level event) corrections to labels could be made, but it does not make the resource a new version, it remains the same version with a correction.
-Mike Davis is seeking to sponsor a Trust Framework project to create considerations on the Policy side, and not burden this on the PIA. -We may include a non-normative checkoff list for follow on specification
(Rick) -Scope Updates to PIA: To provide a framework to identify and Privacy and Security Risk associated with the use of PII -encompasses the HL7 standard development process developer would initiate the PIA at the development process==>incorporate Privacy and Security considerations during the development process ===> then use the PIA to complete the assessment at the end of the process (covering the entire life cycle) - It will reference the Privacy Design Principals to assist in completing the Privacy Impact Assessment
Next Section Review (Project Need/Impact)
- Assessing Project impact
- PIA cookbook will be informative
Low Risk: The Cookbook will reference the Privacy by Design Principals. The OASIS is a Work in progress and the document referenced should a published Standards.
Target Dates: -Review dates for cook book: June -Ballot Period: Early September balloting cycle (Document reviewed during call) -Motion to Approve Security to Co-Sponsor PIA: 2/0/0 (John moved & Glen seconded) -Next Step: The PIA will be brought up for vote to CBCC Suggestion: -Have a note section for developers of possible optional mitigation (Kathleen)
- PASS Access Control Services Conceptual Model - Diana
-Call ended NTR
- Joint Vocabulary Alignment Update - Diana
-Call ended NTR
- PASS Audit Conceptual Model – Diana
-Call ended NTR
- FHIR Security report out - John
-Call ended NTR
Discussion Items
Suggestion from Lloyd on capturing potential Privacy and Security issues in FHIR: "One thing we could do is add a QA rule expecting a "Security & Privacy Considerations" section in the Notes area for each resource. It would be a "warning" rule, meaning that work groups could ask for it to be suppressed for a given resource if they determine that there are none. That would help prompt work groups to think about it and also ensure a consistent place for it to appear. (General security considerations about the use of FHIR, including the passages Kathleen highlighted should be handled in the "Security" section of FHIR, I think rather than interspersed on all of the different pages.) If the security WG thinks this is a good idea, perhaps they could put together some bullet points highlighting the types of considerations they'd like work groups to consider when filling out the section. My leaning would be to make this an FMM 3 issue as it probably makes sense for the resource design to stabilize a bit before expecting WGs to go through a full security/privacy analysis."