Security & Trust Meeting 2010-06-24

Notes from NHIN Direct Security & Trust Meeting

Date: June 24, 2010
Time: 2pm-3pm
Attendees: Don Jorgenson, Laurie Tull, David McCallie, Vassil Peytchev, John Moehrke, Eric Heflin, Sean Nolan, Arien Malec, Uvinie Hettiaratchy, Jack Ousey, Brett Peterson
Actions for this week

#	Date	Action	Status	Owner	Due Date
30	6/24/10	Provide background information on comparable threat assessments already done for SMTP and S/MIME approach	Open	WG	6/25/10
31	6/24/10	Draft initial SMTP threat assessment and post to wiki	Open	Sean	6/24/10
32	6/24/10	Provide IHE and HL7 model	Open	John Moehrke	6/24/10
32	6/24/10	Review threat assessment wiki page	Open	WG	6/24/10

Actions from last week

#	Date	Action	Status	Owner	Due Date
28	6/3/10	Address issues related to revocation checking with CRL	Open	WG	6/17/10
29	6/3/10	Address how implementations should demonstrate that they are as simple as possible for small providers to use	Open	WG	6/17/10

Agenda

• Review security and trust considerations in Consensus Proposal
• SMTP threat assessment

Notes
Arien Malec

• Need review on the SMTP threat assessment
• Ability to take incoming 5322 message and S/MIME encrypted attachment.
• On the receiving side verifying the ability to decrypt the signature as the core security model.
• Suggest that we concentrate on that portion of the leg.
• If we can get through that, focus on the edge connectivity portion of the overall workflow orchestration. I suspect that this leg is the most important and most critical to do a risk analysis on.

Sean Nolan

• Posted link on agenda slide for today’s meeting. Please take a look at it.
• Tried to pull out each of the arcs and for each arc describe the risk mitigation.

John Moehrke

• Like the diagram and it’s useful to see what we’re focusing on.
• We are going to focus only on the SMTP environment, so there’s no Karen’s cross.
• Do we want this basic SMTP model only? Is this sufficient at this point in time? Or do we need other configurations as well?

Arien Malec

• Let’s get this right and then we can leave the threat assessment model for each of the edges as encapsulated piece of work.

John Moehrke

• We need to start simple because it will be difficult enough to get into the flow of doing a security risk assessment. If we can focus on this simplistic case, that’s fine. This is clearly the agent model.

Sean Nolan

• This is a model with a HISP running agent.

John Moehrke

• So link 1 and link 7 are only server side protected?

Arien Malec

• Let’s leave link 1 and link 7 sides out.

Sean Nolan

• I’d like to leave numbers in there since they portray the steps, but not necessary now.

John Moehrke

• Did you mean we are not considering 2 and 5?

Arien Malec

• No, we are, these are in scope.

Sean Nolan

• No edges are the key.

John Moehrke

• I would also indicate that 2 and 5 should also be considered inside the box. You must tell developer what to do on 2 and 5, but not so much on interoperability perspective. So primarily looking at 3, 4 6.

Arien Malec

• From a processing perspective, it’s 1, 2, 5 and 7. From my experience in implementing, taking an incoming message has a specific logic. Deciding whether you need to sign and encrypt, and then extracting the package that has potential for programming error/misconfiguration with the potential for leaving PHI. There’s a strong programming error threat potential in that particular step – primarily on incoming side.

Sean Nolan

• It’s really about User input validation.

Arien Malec

• Yes, user input validation and user input standardization.

John Moehrke

• Not sure what you mean.

Arien Malec

• More of a web app.

Sean Nolan

• I propose that if we’re ok on scope, I can make a new wiki page with a table with columns for each threat, the mitigations in place and related notes.

Eric Heflin

• One of the things we’ve been doing as a first step in other workgroups is to do a landscape survey. What else has been done that we can leverage? It’s likely that someone else has modeled a security threat model for SMTP based system.

Sean Nolan

• We have a huge library of things too, so was going to look through those as well. I’d love to hear from others as well.

John Moehrke

• The other part of that is that HL7 and IHE have a process they’ve adopted. It would be useful to the group to be aware of that. Applying the risk assessment to a specification is different from an implementation of something. There are points where you do have to say you assume the programmer is not going to do something wrong. This way, you keep the group away from straying towards things that have nothing to do with specification you’re writing.

Sean Nolan

• I agree.

Arien Malec

• Let me see if I can re-state what I’ve heard as the actions on the table.

1) Proposal for an open invitation to respond if we know of threat assessments done for SMTP infrastructure. Also, if we know of threat assessments done in particular to S/MIME approach, we should make those available.
2) I think John was volunteering to point us to the appropriate process that IHE and HL7 uses that we could adopt if it makes sense.
3) With agreed upon scope, Sean will take first pass at enumerating the attack surface and potentially describing some of the mitigations.

• Did I capture this right?

John Moehrke

• I heard that Sean would also itemize the threats.

Arien Malec

• Yes, that’s what I meant.

Sean Nolan

• Agreed.

John Moehrke

• I’d be happy to present the model that HL7 and IHE are using, but not sure if we want to diverge into that longer discussion.

Arien Malec

• If it makes sense to adopt it without debating it, then happy to do that. No need to invent a model.

John Moehrke

• It really is simple risk assessment against a specification.

Arien Malec

• What I’d like to do at this point is go around the room to see if we agree on these set of actions. Would also like to ask for volunteers to review table that Sean is creating.

Round the Room
Feedback on threat assessment proposal process and volunteer to review

Name	Feedback/Comment
Laurie Tull	Don’t think I’m qualified to volunteer. Agree with what we decided.
David McCallie	I like the approach. I have one question about the entities on the diagram. There are a couple of places where data can queue and be stored. I wonder if those need arcs and circles or this is about just transactions.Sean Nolan Actually not a bad idea to have an arc for data at rest. I can add those.
John Moehrke	In favor
Eric Heflin	Makes sense, in favor.
Jack Ousey	In favor, also not qualified to help out but will provide information when possible.
Don Jorgenson	In favor, and will review proposal.
Vassil Peytchev	In favor, and will review proposal.

Arien Malec

• This is probably better done as offline work than online work. What I thought I heard was that Sean was going to take the first crack. I would suggest that we break early and the team that has committed to review Sean’s work should dive in.

Sean Nolan

• It likely to be this evening.

Arien Malec

• Prefer to use native pages of wiki to make edits.

John Moehrke

• I will send out spreadsheet template that’s offered. Unfortunately, IHE’s servers are down.

NHIN-D_SMTP_Threat_Model_SPN_20100624.jpg