1
Safeguarding Our Email
Via TLS
TLS Webinar
Presented by:
Jim Rogers, Director of Distribution Technology, The Hartford
Tim Woodcock, President, Courtesy Computers
Jeff Yates, Executive Director, Agents Council for Technology
Webinar will begin shortly!
2
Safeguarding Our Email
Via TLS
TLS Webinar
Presented by:
Jim Rogers, Director of Distribution Technology, The Hartford
Tim Woodcock, President, Courtesy Computers
3
Agenda
Submit questions via the Question & Answer Log
First 40 Minutes:
eMail Usage
Security - Why you should care
Benefits
Resources
Q&A–
Last 20 Minutes:
TLS Configuration of MS Exchange 2007
Q&A
4
Background
Email has become a major component in every day
agency/carrier business interactions.
Mail sent over the Internet is typically unprotected
The need to protect email continues to grow
The use of, and reliance on, email within core business
5
Why Protect e-Mail?
e-Mail often contains sensitive customer information
Required by business contract
Is easily accessible to prying eyes on the Internet
6
Existing Regulations and Standards
Gramm-Leach-Bliley Act (GLBA) Standards for Safeguarding Customer Info.
non-public personal information (NPPI) in paper, electronic, or other form
NPII: personally identifiable information provided by a consumer or resulting
from a transaction for a consumer
written information security program to address internal/external risks
physical, technical and administrative safeguards
oversee service providers
Security Breach Notification Laws (Various states)
first/last name and SSN/drivers license/state ID/financial account + password
when not encrypted
must notify any resident of the state of a breach without unreasonable delay
Payment Card Industry Data Security Standards (PCI-DSS)
cardholder data
certification of compliance with PCI-DSS depending upon level of merchant
firewall, encryption in storage/transmission, antivirus, etc.
7
Recent Regulatory Developments
Nevada 597.970
“Restrictions on transfer of personal information through electronic
transmission”
Massachusetts 201 CMR 17.00
“Standards for The Protection of Personal Information of Residents of
the Commonwealth”
California Department of Motor Vehicles
8
TLS: Transport Layer Security
Provides secure e-Mail communications across the Internet
through a standardized, secure, and non-proprietary
mechanism
Eliminates the “drawbacks” that plague the commonly used
tools and services
Is built-in to most modern e-Mail systems and just needs to
9
How Does TLS Work ?
At transmission time, TLS creates an encrypted
communication session between email servers
The e-Mail is then sent through a protected “tunnel”
The servers de-crypt the message and send it along to the
client
Carrier Agency Partner Client ClientEncrypted
10
Transport Layer Security: TLS
“My ssn is: 999 65 9999” “My ssn is: 999 65 9999” “$erm840 kkfd8820& l1k6ss” Encrypted Message Safe/Secure Standard Protocol
Available on most email systems
Transparent to end-users
Eliminates the need for hosted services
11
Benefits of TLS
Provides the confidentiality of emails across the Internet
Requires no changes to the client
Is a standards-based protocol that is implemented on most
e-Mail gateways and appliances
It’s free, no additional licensing is needed. Security
certificate is required.
12
How Do I Get TLS ?
TLS is a standards-based protocol enabled on most
server-based email systems
Talk with your system support staff or e-Mail service
provider
Most agencies that have an up-to-date in-house mail server
are TLS capable. Agencies with a hosted Microsoft
Exchange server are TLS capable as is gmail. Those with
hosted email using hotmail and yahoo are not currently TLS
capable
13
Detecting TLS
Talk to the email server administrator
Some email contains a tag line if sent via TLS…. at
the bottom of the email
More on this in our technical discussion
How do you determine if TLS is
active….
14
Carriers supporting TLS
Some carriers are TLS enabled automatically for their agents who send emails with TLS to them; others activate agencies for TLS only upon request. Please check with your carrier or look in the “Security & Privacy” section on ACT website for specific carrier info:
Allied/Nationwide Chubb
Cincinnati CNA
Concord Group Insurance EMC
Fireman’s Fund Grange Insurance Harleysville
The Hartford
Liberty Agency Markets
MetLife – MetLife Auto & Home MMG Insurance OneBeacon Progressive RLI Corporation Summit Holdings Travelers Westfield W.R. Berkley Companies
Insurance Agent
Protected Tunnel
Encrypted
Carrier Rep Policyholder MS Exchange 2003 TLS Required Mode MS Exchange 2007 TLS Opportunistic ModeTLS enabled Email Solution
MS Exchange 2003 – TLS Required Mode
Both the sender and the receiver must maintain a directory of each other’s email domains in order
for a TLS encrypted email to be exchanged
If the receiver has TLS enabled in opportunistic mode, not Required mode, the email will still
transmit in an encrypted format.
If the receiving party does not have TLS enabled, the sender’s email will be sent but it will not be
encrypted.
Policyholder No TLS encryption enabled
Email sent/received
is not encrypted!
Insurance Agent
Protected Tunnel
Encrypted
Carrier Rep Policyholder MS Exchange 2007 TLS Opportunistic Mode MS Exchange 2007 TLS Opportunistic ModeEmail sent via Tumbleweed with a secured link that the user opens
MS Exchange 2007 – TLS Opportunistic Mode
A sender with TLS Opportunistic Mode enabled will check to see if the receiver has TLS enabled. If the
receiver has TLS Opportunistic turned on, the outgoing email will be encrypted. If he does not, there are
two potential scenarios depending on the sender’s infrastructure.
1) the email is sent out with no encryption
2) the sender sends the email out via an encryption tool such as Tumbleweed or ZixSelect
Policyholder
No TLS enabled
Email sent/received
is not encrypted!
TLS enabled Email Solution
-TLS Summary
Environment Conditions Result MS Exchange 2007 Opportunistic Mode Sender ReceiverTLS Enabled TLS Enabled Emails are sent and received encrypted
TLS Enabled TLS not Enabled Email is sent but it is not encrypted
TLS not Enabled TLS Enabled Email is sent but it is not encrypted
MS Exchange 2003 Required Mode
Sender and Receiver maintain each other’s email domain addressees in their respective TLS registries
Emails are sent and received encrypted
Sender maintains Receiver’s email domain address
Receiver does not maintain Sender’s email domain address
Email will not be sent out.
Sender does not maintain Receiver’s email domain address
Receiver maintains Sender’s email domain address
Email will be sent but not in encrypted format
18
Additional Considerations
Important to have your technical support implement TLS
Your technical support can tell you which of your carriers
and clients are enabled for TLS
If using an external spam/anti-virus filter, you need to
make sure it is enabled for TLS.
Also, some of these external spam/anti-virus providers
offer a hosted email option that can be enabled for TLS
Many hosted email solutions are not enabled for TLS
(e.g., hotmail and yahoo), but gmail provides some secure
options
You also need to make sure that the connections between
your email server and your remote computers and mobile
devices are encrypted
Use your real-time tools wherever possible to transmit
client personal information because it is encrypted
If TLS or Real Time not available, send application
19
20
21
TLS Links
ACT Web site for TLS Article,FAQs, & TLS enabled carriers
www.independentagent.com/act
“Security & Privacy” Quick Link
Technical Links
http://msexchangeteam.com/archive/2006/10/04/429090.aspx
22
How to Configure TLS
• Will cover how to procure SSL Certificates
• Representative purposes only and steps here may not
be suitable for all environments
• Will cover Exchange 2003 and 2007
• If you are on a different platform, please consult your
technical support
23
Several Sources for Security Certificates
certificate authority (CA)
-an entity that issues digital certificates
Verisign
http://www.verisign.com
Network Solutions
http://www.networksolutions.com
GoDaddy
http://www.godaddy.com
Comodo
http://www.comodo.com/
Digi-Sign
http://www.digi-sign.com
HOW TO: Use Certificates with Virtual Servers in Exchange Server
Difference between Exchange 2003 & 2007
Exchange 2003
•
requires a valid X.509 server certificate
(suitable for TLS usage)
•
DOES NOT support ‘Opportunistic TLS’
•
Requires to manually configure TLS (minimum 6 steps)
•
Difficult to monitor TLS transmit-receive success/failures
Exchange 2007/2010
•
requires a valid X.509 server certificate
(suitable for TLS usage)
•
‘Opportunistic TLS is automatically enabled
(by default)
•
Easy to monitor TLS transmit-receive success/failures
•
Greater Message Control with Robust ‘Transport Rules’ Features
• Block, Bounce, Copy, append, Send to Archive, Quarantine
Verifying successful TLS session
with MS Office 2007
26
Follow Up
• Follow up email with our email addresses
• PowerPoint & Recording of presentation posted
on “Security & Privacy” link at
www.independentagent.com/act
• See more detailed info about security & privacy
laws and regulations in the Appendix section of
the posted PowerPoint
Mutual TLS
With Mutual TLS authentication, each server verifies the
identity of the other server by validating a certificate that is
provided by that other server.
In this scenario, where messages are received from external
domains over verified connections in an Exchange 2007
environment, Microsoft Office Outlook 2007 will display a
‘Domain Secured’ icon.
Mutual TLS Enabling Process with Exchange 2007
Process for ‘Server to Server’ Mutual TLS
1. Configure an additional IP Address (as necessary)
2. Create & Configure the SMTP Send Connector
3. Create & Configure SMTP Receive Connector
4. Test & Verify Mutual TLS between remote domain server
Mutual TLS Enabling Process with Exchange 2007
Mutual TLS Demonstration Scenario
1. Insurance Carrier requires a ‘Mutual TLS’ Session
between their mail server and the agency’s mail server
2. Small agency with single Microsoft Exchange Server
3. No ‘Edge Transport Servers’ are present in their network.
Verifying x.509 Certificate in Exchange 2007
Verifying x.509 Certificate in Exchange 2007
Verifying x.509 Certificate in Exchange 2007
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Configure Additional IP Address (as needed)
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Send Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
Create Receive Connector for Mutual TLS
59
Appendices
Nevada 597.970
Who it applies to:
“a business in this state”What information it applies to:
first/last name and SSN/drivers license/state ID/financial account + password when not encrypted
Examples:
tax ID of small businesses, commercial fleet drivers’ license numbersWhat is required:
Encryption of electronic transmission, except facsimilesWhat this means:
Organizations doing business in or with other organizations in Nevada must support encryption if sharing data through e-mail, web sites, batch file transfers (FTP), Real Time, file uploads, wireless, web conferencing, etc.Effective Date:
October 1, 2008Security controls to consider:
email……..TLS*, proprietary solutions file-uploads….PGP, SFTP, FTPS, other web site, Real Time…SSL wireless….802.11i, LEAP, WPA2 enterprise batch file transfers.…PGP, SFTP, VPN web conferencing….SSL
Massachusetts 201 CMR 17.00
Who it applies to:
all “entities” that own, license, store or maintain personal information about a resident of Massachusetts
What information it applies to:
first/last name + SSN/drivers license/state ID/financial account - password when not encrypted of any resident of the state
Examples:
Insureds, claimants, employees Applications for insurance, claims, premium payments, claim payments, personnel records, etc.
What is required:
• Designating someone to maintain a comprehensive written security program • Assessing internal and external risks to electronic and paper records
• Imposing disciplinary measures for violations of the security program
• Other common elements of a security program: monitoring, updating safeguards, annual review of program, etc.
Massachusetts 201 CMR 17.00
New items of note:
• Security of paper and electronic records taken off site • Assigning unique user IDs and securing passwords
• Terminating logon accounts and passwords of terminated employees • Contractually requiring vendors to comply with these requirements • Limiting time this information is retained (records management)
• Documenting breaches and conducting post-incident reviews of incidents
• Encryption of portable devices required (laptops, PDA’s, phones, Blackberries, CD, DVD, USB drives)
• Encryption of transmitted information where feasible
• Reasonably update firewalls and patching of systems connected to the Internet
Massachusetts 201 CMR 17.00
What this means for our industry / security controls:
•
Agents, carriers and vendors must have a formal security
program including specific physical, technical and administrative
security measures, including third party oversight and
management of portable devices
•
Increased need for carriers and vendors to modify their systems,
web sites, and Real Time interfaces to support industry
standards for user administration and password management in
agencies
•
Implementation of TLS where technically feasible
•
Organizations must have security staff or consultants available
for administration of firewalls and patching of servers and
workstations
For more information see:
California DMV
Who it applies to:
• Entities that provide access to entities that are authorized DMV “requestors” • Entities that access DMV information on behalf of authorized “requestors”
What information it applies to:
• Personnel information provided by the DMV
• Examples: MVR (CLUE, scoring, resident addresses)
What is required:
• Various requirements depending upon the circumstances. For example….
Those organizations with direct access to DMV systems and information must:
• lockdown servers
• user accounts must lock out after 5 unsuccessful logon attempts • users must select their own passwords and expire within 90 days
• potential security incidents must be reported within 1 business day to the DMV
Those permitting direct electronic access to information must identify the account
ID’s being used for that access so that it can be programmed into the system
California DMV
Individuals with access to DMV information must sign a security agreement form
(1128), even if that individual is in another organization. Agreement requires
• No password sharing
• Storing passwords in a secure place
• Any administrator or other with incidental access must sign agreement as well
What this means for our industry / security controls:
• Carriers/vendors using DMV information to provide interactive rating information to agencies, must store agency account IDs so that these IDs can be passed through their systems.
• Carriers/vendors which access this information for agencies or pass this information to agencies, must retain specific logs of all such access for 2 - 5 years
• Carriers/vendors which access this information for agencies or pass this information to agencies must provide a copy of the agency contract upon request.