Threat Model - Simple SMTP

This page is intended to model threats associated with a basic Direct Project conversation between two e-Mail clients, each using a "full service" e-Mail Client that provides e-Mail security (S/MIME), Address Book (key store), and DNS services. This configuration presumes no new development is necessary as all components of the solution are off-the-shelf today. Although messages may contain multiple recipients, we have constrained this model to only one for simplicity. The Source and Destination should not be considered mandated to both follow the same configuration, they are modeled together for simplicity of documentation. There are of course a number of other possible configurations that alter the threat profile; these will be evaluated on separate pages as appropriate.

This threat assessment followed the Threat Model Process. Other Deployment Models have been similarly assessed and are cataloged on the Threat Models page.

Pre-Conditions:

All normal Direct Consensus Proposal - Assumptions are in play. Specific to this configuration:
 

1. The Human/Organization that is sending the documents is responsible for verifying the address and obtaining the destination security keys. This is often done with a simple 'test' message that contains no sensitive data, but is confirmed as being correct through a direct phone call.

Benefits:

• No specialization (Direct) is needed. This configuration utilizes 100% off-the-shelf e-mail clients available today (wikipedia comparison of e-mail clientsshows that there is a subset of e-mail clients that support S/MIME but it is still a significant (~20) number).
  • Does not mandate TLS, but does offer it as a point-to-point additional protection (also commonly available today).
• No PHI is exposed to any HISP
• e-Mail client 'sent' mail folder is archive of items Disclosed. Inspection of this folder can determine if an inappropriate exposure (non-secured PHI) has happened Note that hard drive folders can also be used to store any e-Mail attachments for tracking and access.

Drawbacks:

• This configuration requires that the Sender or Receiver maintain an e-mail client that has the capability to handle S/MIME, and the address book.
• This configuration is harder to automate inside an EHR/PHR workflow
  • Use of Windows-MAPI interface can mitigate this problem
  • Use of e-Mail toolkits that support the necessary functionality can mitigate this problem

Diagram:

The following diagram depicts the key components and arcs involved in this conversation:

Arc 1 - Source e-Mail Client Looks up Keys based on Destination Direct Address

In this arc, the e-mail client uses the native address book of the e-mail client to retrieve the certificate of the destination address. The certificate is validated to assure it is whole, complete, has not expired and is not revoked. Because this arc occurs completely within the trusted boundaries of the Source, it is expected that the agent will be able to securely make this request using standard secure programming practices. We will not further model this arc in this document.
 
 

Arc 2 - Source e-Mail Client fetches locally-configured private keys and anchor certificates

In this arc, the e-Mail client queries a local configuration resource such as a database, file system or certificate store for the private keys and anchor certificates associated with the source address. Because this arc occurs completely within the trusted boundaries of the HISP, it is expected that the agent will be able to securely make this request using standard secure programming practices. We will not further model this arc in this document.
 
 

Arc 3 - Source e-Mail Client resolves Destination SMTP Server addresses

In Arc 3, the e-Mail Client queries its locally-configured DNS server for the MX records corresponding to the domain name of the destination address. The public DNS hierarchy is utilized, that is the configured DNS server forwards non-local MX requests through the distributed public DNS hierarchy.
 
 

Arc 4 - Source e-Mail Client sends encrypted/signed message to Destination SMTP Server

In this arc, the source e-Mail Client establishes an normal SMTP connection (non-secured) to the destination SMTP server. The encrypted message is sent over this channel using standard SMTP mechanisms.
 
 

Arc 5 - Destination e-Mail Client fetches message from Destination SMTP Server

In this arc, the destination client first establishes an normal (non-secured) POP3 or IMAP4 connection to its configured mail server. The client then sends standard requests to receive message headers and contents over this connection.
 
 

Arc 6 - Destination e-Mail client fetches locally-configured private keys and anchor certificates

In this arc, the e-Mail client queries a local configuration resource such as a database, file system or certificate store for the private keys and anchor certificates associated with the source address. Because this arc occurs completely within the trusted boundaries of the Destination, it is expected that the agent will be able to securely make this request using standard secure programming practices. We will not further model this arc in this document.
 
 

Arc 7 - Destination e-Mail client fetches and verifies public certificates for source address

Signature validation is done using the certificates embedded in the message itself, so these certificates do not need to be fetched. However, as the e-Mail client explores the certificates and issuing chain hierarchy searching for a configured anchor certificate, intermediate certificates may need to be fetched and in all cases revocation status must be determined.
 
 

Risk Assessment and Mitigation Plan

In the interests of keeping scope on the Risk Assessment: We assume good programming practices and good business operational practices. For example we do not include risks of poor protocol implementation that would expose buffer-overflows, or poor operational environment that allows sharing of accounts, key-loggers, and openly readable audit log files.
 
 

Risk Nunber	Arc	Risk	Likelihood (L, M, H)	Impact (L, M, H)	Mitigation	Notes
1	1	The user may send PHI and 'forget' to use S/MIME.	H	H	Although the pre-conditions (Assumptions) sets this as a responsibility of the sender, it is exposed here explicitly as a reasonable accidental risk. Some e-Mail clients can be configured to only send using S/MIME and will thus refuse to send to an address that can't be secured Use of Integrated EHR/PHR with the e-mail infrastructure means user does not have access to e-Mail User Interface e-Mail client 'sent' mail folder is archive of items Disclosed. Inspection of this folder can determine if an inappropriate exposure (non-secured PHI) has happened Use of "Data Loss Prevention" systems to detect and block sensitive information from leaving an organization (benefit of using non-secured channel is that it can be inspected) (see: Gartner report) Use of cloud based secure-email where the necessary functionality (see above) is more easily managed.
2	3	DNS can be spoofed to return an attacker’s IP addresses rather than the correct ones. This could cause messages to be sent to an attacker’s system.	L	L	Messages can only be decrypted by the party holding the private key corresponding to the public certificate used for encryption. Therefore encrypted messages can travel in the wild without risk to the contents. TLS can be used at the SMTP level. This would add another layer of authentication that must be passed, but also adds to complexity of configurations. TLS is only guaranteed to the first point. This is an important step, but there may be other SMTP
3	4/5	potential exposure of TO/FROM routing information (network, wireless, internet mailstop). Exposing that the addressee identified in the TO is having a private conversation with the addressee identified by the FROM. provider-to-provider -- There is no knowledge of the topic of the conversation, it could be golf. provider-to-patient -- There is knowledge of types of conversations where the provider is a specialist	L	L	Each Recipient is in control of who they provide their endpoint address to, and each Sender is in control of who they communicate with. TLS can be used at the SMTP level. This would add another layer of authentication that must be passed, but also adds to complexity of configurations. TLS is only guaranteed to the first point. This is an important step, but there may be other SMTP
4	4/5	When User uses e-mail client - potential for user to place PHI into the subject field, even though we caution against it. The SUBJECT is not commonly protected by current off-the-shelf email systems. exposure of SUBJECT information (network, wireless, internet mail stop). Exposing what ever information is placed into the subject line. Note when an automated process like EHR/PHR is using the Direct specification there is no risk.	M	L	Could MANDATE specific string be in the SUBJECT field - For Example: "Direct" Could be mitigated with TLS TLS is only guaranteed to the first point. This is an important step, but there may be other SMTP Could use more advanced form of S/MIME that is not commonly implemented. (Discourage as a mitigation) Suggest that this risk be documented and flow to training
5	4	Denial-of-Service attack against a recipient that no longer receives messages that have been routed away from their SMTP server.	L	L	Because such an attack would impact all addresses on a given domain, a monitoring system could decide that the lack of incoming messages over a period of time, as well as failure of Source to receive of Delivery Receipts from Destination for a period of time, warrants investigation. SMTP servers openly accepting connections from the Internet should use standard firewall and intrusion detection systems to protect their interfaces.
6	4/5	An attacker intercepts message traffic (network, wireless, internet mailstop).	L	L	The message content is encrypted and signed using S/MIME so no exposure of PHI.
7	5	Interception of POP/IMAP authentication credentials through unsecured network (e.g. wireless) sniffing. Exposed credentials allows attacker to spoof the account.	L	L	The message content is encrypted and signed using S/MIME so no exposure of PHI. TLS can be used at the POP/IMAP level, but adds complexity of configuration
8	5	e-Mail is received that is not S/MIME protected	M	M	the judgment of the receiving user can determine if the information should be trusted or not. Many will choose to simply discard all non-secured as potentially SPAM. The Destination is not responsible for assessing exposure as that is a sender responsibility, although a notification (return e-mail) to the sender indicating that a non-secured e-mail was received (without details) would be recommended as professional courtesy. Care must be taken to prevent automated responses to responses.