This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "April 19, 2016 Security Conference Call"

From HL7Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by the same user not shown)
Line 77: Line 77:
 
Note that there will be a FHIR Security call at 2pm PT/5pm ET
 
Note that there will be a FHIR Security call at 2pm PT/5pm ET
 
See agenda at [http://wiki.hl7.org/index.php?title=HL7_FHIR_Security_2016-26-05 FHIR Security Agenda]
 
See agenda at [http://wiki.hl7.org/index.php?title=HL7_FHIR_Security_2016-26-05 FHIR Security Agenda]
 +
==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."
  
 
==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 98:
 
- 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 an event for Trust Framework to create considerations on the Policy side, and not burden this on the PIA.  
+
-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 will provide a second standard of Considerations
 
 
-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 105:
 
-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 115:
 
-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:  12/0/0 (John moved & Glen seconded)  
-Motion to Approve Security to Co-Sponsor PIA:  2/0/0 (John & Glen voted to approve)  
 
 
 
 
-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
Line 133: Line 128:
 
* FHIR Security report out - John
 
* FHIR Security report out - John
 
-Call ended NTR
 
-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."
 
 
==Minutes==
 

Latest revision as of 17:49, 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 ]

Back to Security Main Page

Agenda DRAFT

  1. ( 5 min) Roll Call, Agenda Approval
  2. ( 5 min) Approve Security WG April 12, 2016 Minutes
  3. ( 15 min) Discuss Lloyd's suggestion - See Discussion Items below.
  4. (10 min) Privacy & Security by Design/NOW Privacy Impact Assessment Cookbook - update - Rick
  5. ( 5 min) PASS Access Control Services Conceptual Model - Diana
  6. ( 5 min) Joint Vocabulary Alignment Update - Diana
  7. ( 5 min) PASS Audit Conceptual Model – Diana
  8. ( 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

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."

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: 12/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