- Business customers need to send confidential / personal information via email, and they need to send this to non-Intranet users
- Company Security Policy (HIPAA compliance) requires confidential information to be encrypted in emails outside of the company firewall
The following alternatives were identified
1.Pull Type Architecture
2.End-to-End Encryption via S/MIME v3
3.Providing users with extranet facing outside the company firewall mail server (Variation of Infonet)
4.Pretty Good Privacy (PGP) Encryption
5.Transport Layer Security (TLS), Boundary-to-Boundary Encryption
The following changes are required for application interface by any Email Encryption alternative
1.Restrict the emails addresses in the "To" field for emails/notifications to valid emails
2.Restrict the emails addresses in the "To" field for emails/notifications to specific email domains 3.Prevent users from typing in email addresses
Advantages and Disadvantages of Alternatives
Alternative -1 A: Pull Type Architecture (all users treated the same)
Description:
• This option is suitable for systems that have a large user base and implement several automated alerts. The emails generated are recreated as webpages and hosted within the company firewall. The recipients are sent email alerts with the url of their message webpage and a token. The recipients authenticate using their id and the token to access their email message. There is security required to access the information via the link / URL, etc. (This was assumed to be within the Company Firewall.) This does not address emails going outside of the company firewall.
• Pros:
– No additional software installation required
– Uses proven standards such as SSL/Https
– Does not require any certificates
• Cons:
– Requires customization of the application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address emails going outside of the company firewall (referrals or lab results).
• Complexity:
– Medium (Due to management of tokens)
– Recipient needs to use the VPN to get into the company Intranet
– High Level Effort Estimate:
• Requires COTS involvement (maybe 2 resources)
• Mini solution (Infrastructure hosting team)
• Application development team (revise reporting) – 2 resources
Alternative -1 B: Pull Type Architecture (only applies to users Outside the company firewall)
Description:
• This option is suitable for systems that have a large user base and implement several automated alerts. The emails generated are recreated as webpages and hosted within the company firewall. The recipients are sent email alerts with the url of their message webpage and a token. The recipients authenticate using their id and the token to access their email message. The users inside the company firewall should have a company Lotus notes account, and can get confidential information through Lotus Notes.
• Pros:
– No additional software installation required
– Uses proven standards such as SSL/Https
– Does not require any certificates
• Cons:
– Requires customization of application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address confidential content information within emails going outside of the company firewall (referrals or lab results).
• Complexity:
– Medium (due to management of tokens as well as the need to be able to identify that this is an outside user as opposed to a internal user)
– Recipient needs to use the VPN to get into the company Intranet
Alternative -1 C: Pull By sftp Type Architecture (requires Outside users identification & ID’s)
This option is suitable for systems that have a large user base and implement several automated alerts. The emails that are generated are for notification only that a report or file exists on a secure ftp site. This report or file is then available for the user to pull it. The recipients authenticate using a secure ftp ID and password (This was assumed to be inside the company Firewall.)
This does not address emails going outside of the company firewall. If the user doesn’t have access to company Intranet, this solution is not feasible (Referrals).
The user would require a secure ftp client and certificates
Pros:
– No additional software installation required on the server side (clients would need a secure ftp)
– Uses proven standards such as SSL/Https
• Cons:
– Requires customization of application to build this functionality
– Does not meet Business Client’s perceived requirement (the information be contained in the email)
– This does not address confidential content information within emails going outside of the compay firewall (referrals or lab results).
– Users would need an additional ID and password (may be able to use existing ID).
• Complexity:
– Medium (Due to management of ID’s and certificates)
– Recipient needs to use the VPN to get into the company Intranet
Alternative -2: End to End Encryption via S/MIME v3.---
Description:
• The client will utilize the X.509 Certificates for both the sender and the receiver to encrypt the message. The message will remain encrypted from client to client. Internal users can use their VPN PKI certificates while partners will be required to purchase their own certificates. (Could use digital signatures from the server to the user to verify the right person…)
• Pros:
– Uses proven standards such as RSA-based encryption and X.509 Certificates.
– Most email client platforms claim cross platform compatibility.
– No customization of COTS application required.
– Medium implementation cost (purchase RSA certificate, people receiving need to purchase as well, and need a package to encrypt the message)
• Cons:
– Cross Platform compatibility is still an emerging feature in these products
– Places burden on the end users for certificate management (harvesting certificates, enrolling, revocation etc)
– High Maintenance and Support cost (to support end users)
– Risk that security-checking email services such as policy based message scanning and antivirus scanning could be bypassed, potentially violating company security policy standards, since the message is encrypted end to end.
– Since Lotus Notes is not on the server, we would need to add an encryption tool on the server.
– Requires software approval / deviation due to not being in company standard software category
• Complexity: Medium
Alternative -3 PROVIDING USERS WITH EXTRANET FACING, OUTSIDE THE COMPANY FIREWALL MAIL SERVER (Variation of Infonet)
Description:
• This option is suitable for all types of user bases and Email models. Company will host an Email Server for Partner mailboxes within the company firewall for all company partner companies to share secure communication. The partner users will connect to the External Email Server via a secure tunnel and access the emails through either Outlook, iNotes Client or Notes Client. Need to research if the messages stored in the external notes server are encrypted or not.
• Note: Company could provide the outside vendors a Lotus Notes account and Account ID. However, company policy may not support giving outside suppliers email access who do not have a COE seat. Client (COTS vendor) would still need to encrypt, so we’d still need a tool for that.
• S/MIME is an extension that allows additional functionality and it uses certificates to manage, although certificates are costly.
• Pros:
– It will be a single vendor based solution eliminating all needs for cross platform compatibility.
– There is no requirement for key management
– Low cost of maintenance and support.
• Cons:
– Implementation costs higher than option 2 (certificates already in place, so no additional cost for those)
– Need to research security compliance at the External Notes server.
– Not sure if internal IT would support, given complexity of changes to the infrastructure.
– Business customers may not want to force people to have a company email ID.
– There’s a risk that company may lose HIPAA exemption because outside electronic transmissions of medical information may require auditing.
• Complexity: High
Alternative -4 PRETTY GOOD PRIVACY (PGP) Encryption
Description: The sending server will utilize a Public Key to encrypt the message, and the receiver decrypts the message with a Private Key. Company requires Private Keys for its users. Private keys would need to be purchased and managed for outside users.
• Pros:
– Uses proven standards (PGP)
– Most email client platforms claim cross platform compatibility.
– No customization of COTS application required.
– Medium cost (purchase Private Keys for the client)
• Cons:
– End user would need to install key.
– Key management must be performed by a Certificate Authority (IT vendor or other organizations)
– High Maintenance cost (to support end users)
– Would need an encryption tool on the server
– Risk that security-checking email services such as policy based message scanning and antivirus scanning could be bypassed, potentially violating company security policy standards, since the message is encrypted end to end.
• Complexity: Medium
Alternative -5 Transport Layer Security (TLS), Not an end-to-end encryption solution.
Description: TLS is a variation of the tried-and-true Secure Sockets Layer (SSL) protocol that we use to protect Web traffic. Using TLS to encrypt communications between two email gateways has a number of security benefits. First, each mail server authenticates to the other, making it harder to send spoofed email. Second, the contents of the emails sent between the two servers are encrypted, protecting them from prying eyes while in transit. Finally, the encryption of the conversation between the two hosts makes it exceedingly difficult for an attacker to tamper with the email's contents.
· Pros:
o Secure transfer from server to server.
o Digital signatures sent and received from the server level.
o TLS and SMTP are extremely interoperable
o Do not need a digital certificate to run TLS on the mail server
· Cons:
o Not highly scalable
o This solution is dependent upon the security environment of the receiving server, which may not be compatible with company security policy requirements.
· Complexity:
o Low-medium
Comparison (Equal Weight)
Comparison (Weighted)
Recommend: Alternative #2
End to End Encryption via S/MIME v3
We recommends Alternative #2 for the following reasons:
•Emails with Confidential and Personal data are encrypted outside Company Firewall
•Proven Industry Standard
Sending Party Considerations (Our Company):
•Does not need to manage specific certificates (Use Existing PKI)
•An encryption module needs to be added to the Mail server
•Requires software approval/deviation
•Requires hosting approval
•Requires Security Policy approval
Receiving Party Considerations (Partners):
•All recipients would be required to have a approved email domain account
•Encrypted emails may violate partner's email security-checking process and/or policy
•Use the company's PKI system without any certificate management
•OR email user would have to purchase/manage/renew his/her own certificate
Encryption Modules
•Appliance Module: Entrust Messaging Server
• Software Module: CompanyCRYPT
Posts
