<sarcasm> Okay, sit down, I have some shocking news for you. TLS has been hacked, broken, smashed to bits. The technology that secures almost all of the secure Internet traffic we rely upon daily has been cracked. We’re all doomed, our bank accounts are going to be plundered, and ecommerce will come to an end. We might just as well all return to the trees; we made a good go of it, but society as we know it is done.</sarcasm>

In all seriousness though, the latest blow to the technologies that help to secure significant amounts of traffic on the Internet was delivered this week by Thai Duong and Juliano Rizzo, two security researchers who plan to demonstrate proof of concept code at the Ekoparty Security Conference in Buenos Aires, Argentina, that can actually decrypt TLS 1.0 traffic. It is a proof of concept, not a zero day exploit already developed into a Metasploit plug-in, so there’s no need to panic quite yet.

TLS 1.0 is one of the most commonly used encryption protocols for securing traffic, including HTTPS, SMTP/TLS, and secure versions of POP3 and IMAP. We use it whenever our clients access our email servers using any secure protocol including web mail, and when we send TLS protected mail between our systems and our partners.

Defined in RFC 2246, it was proposed as a replacement for SSL 3.0, which is actually still widely used today. TLS 1.0 is a Cipher-block chaining protocol, where a block of plaintext is XOR’d with the block of ciphertext that precedes it. BEAST uses a type of cryptologic attack called a “known plain-text” attack to figure out the encryption, exploiting a vulnerability in TLS 1.0 that has long been theorized as a problem with the protocol.

TLS 1.1 and 1.2 both exist as successors to TLS 1.0, and neither are vulnerable to this same flaw, but have not been widely implemented in part because the flaw in 1.0 wasn’t real, at least, not until now. Internet Explorer can use both, but they must be enabled. SChannel in Windows 2008 and 2008R2 can use them as well, but again, must be enabled. The easiest way to do this domain wide for Windows users is to use a group policy to enable “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”, but don’t do that just yet. This can have some undesirable effects on a typical PC. Read this KB article and test carefully before making a system-wide change like this, and then keep in mind that Chrome, Firefox, and most other browsers cannot use TLS 1.1 or 1.2 at the time of this writing. Even with Windows software, this setting is advisory only. It enables them to use TLS 1.1 and 1.2, but it doesn’t force them to. Many websites using HTTPS only implement TLS 1.0, and clients will be able to fall back to that.

The duo’s proof of concept application is called BEAST, for Browser Exploit Against SSL/TLS, and apparently does to a very effective job of decrypting authentication cookies used by websites to grant users access to secured content that requires authentication. Apparently the attack works like this: a bit of JavaScript is injected into a user’s browser session when they visit a compromised website or click on a link that takes them to a site set up to deliver the code; it then works with a network sniffer to capture encrypted cookies passed between the client and a server, which it is then able to decrypt.

To exploit a system, an attacker must first deliver the JavaScript to the browser, and then must have a sniffer in place to capture the packets. A well patched system, running current antivirus, and protected by mechanisms like a proxy server, should be difficult to attack. If an attacker can do all of that to a user, they can probably do anything else they want already, which means they probably already own the victim’s computer.

The good news is that the exploit for this vulnerability, and the proof of concept application, were both developed by good guys. By demonstrating that this sort of attack possible and practical, it will likely motivate developers of browsers and web servers to deploy TLS 1.1 and 1.2 capable versions of their software. Google has already released a patch that, while still using TLS 1.0, defeats this particular attack, and the developers of OpenSSL and the Network Security Services libraries used now have real reasons to implement the stronger protocols.

So, what can be done to help mitigate this? Follow the points below:

1. Keep up-to-date on all vendor patches, both for your operating system and all applications you use.
2. Keep antivirus software up-to-date, use real-time scans, and perform scheduled full scans regularly.
3. Close all browser sessions, and use a fresh session with no other open tabs whenever you need to browse to a secure site, like your bank, credit card, webmail, etc.
4. Close that browser completely when you log off.
5. Consider disabling JavaScript in your browser.
6. Consider using a sandboxed version of a browser.
7. Watch for, and implement, updated libraries for encryption as soon as they are available from your vendors.

In researching for this article, I came across a handy website that can show you just which protocols your browser uses to secure an HTTPS session. It uses a self-signed certificate, so be ready to get a warning dialog, but check out https://www.mikestoolbox.net/ to see some interesting information about your browser, and to test any changes you make to supported encryption protocols.

Keep Calm and Carry On

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

It doesn’t matter if your company uses email to communicate corporate secrets, confidential financial information, or just an invite to the annual picnic; people who weren’t intended to see the message shouldn’t be able to.

To prevent prying eyes from having the opportunity to read your corporate emails encryption is usually the first choice among email administrators who understand security. However, according to a study done by Princeton University titled “Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted E-Mail” there are still many barriers to companies implementing email encryption:

• The belief that encryption is not needed because a company is too small
• Encryption flags a message as being important or secret
• Encryption solutions are too complicated for users
• Email encryption solutions are too hard to implement and set up
• Using encryption makes the company look paranoid
• Receiving encrypted messages can be annoying

To quote one respondent of the study, “normal people don’t encrypt normal email messages.”

Lack of understanding

It seems that with so many responses like this, most people have a lack of knowledge when it comes to email encryption.

So let’s start with when someone would want to use encryption. Ask yourself, “Does it matter who reads this email?” For any messages where the answer is no, encryption isn’t necessary.

But if you answer yes, the messages should be secured. Considering 99 percent of all email still travels over the Internet without being secured, it would be safe to assume that there are messages in that 99 percent where the answer to our question would be yes so an understanding of email encryption is certainly warranted.

Types of encryption

There are hundreds of encryption solutions available for home and corporate users. Some are extremely hard to break; others can be broken rather easily by someone who knows what they are doing. Others still have been completely untested. These solutions generally fall under one of two types of encryption: Symmetric or Asymmetric.

Symmetric Key Encryption

A basic definition of symmetric key encryption is where both parties share a single secret key. This works best to prevent casual viewing or the accidental disclosure of sensitive information.

It works by the user typing their email message and, using the shared secret key, encrypting it into cipher text. The cipher text message is then sent to the recipient(s) where the same shared secret key is used to turn the encrypted message back into plain text for reading.

Symmetric key cryptography commonly relies on algorithms such as AES, Twofish, RKZIP, DES, Blowfish and IDEA.

Asymmetric Key Encryption

Also called public-key cryptography, asymmetric encryption requires two separate keys. One is used to encrypt the plain text of the message, called the public key, and another, called the private key, will decrypt the cipher text. The way it works is that a public key and private key are created and mathematically linked to each other. The public key is then published so anyone with access to this key can send encrypted messages to the holder of the private key, which is not shared.

This is very different than the single shared key or symmetric encryption and no longer requires a secure exchange or the single shared key as necessary with symmetric encryption.

The asymmetric method works when the email sender writes the message in plain text and encrypts it using the public key. The encrypted message, now in cipher text, is sent to its intended recipients. The recipient needs to use the sender’s private key to decrypt the message back into plain text so it can be read.

The algorithms that asymmetrical encryption relies on are RSA, PGP, DSA and Diffie-Hellman.

To add an additional layer of security to public-key encryption, some senders use a digital signature as well. The digital signature signs a message with the sender’s private key. Recipients use their public key to verify that the sender is who they claim to be. Not only is the confidentiality of the message now protected, but the authenticity as well.

You can see where this could be used to help fight phishing scams, especially when an internal email address is spoofed to compromise user credentials or steal information.

Even if you decide that encryption should be added to your existing layers of email security, end-users still have to buy in or they will continue to send plain text messages that are not protected. In part two, we will look at some of the stigmas that are associated with using email encryption and how you, as an email administrator, can overcome them with your users.

Understanding Email Encryption (Part 1)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

When Epsilon Data Management disclosed a breach of its email system panic struck cyberspace. Names like JP Morgan Chase, Citi Bank, Staples, Verizon and Hilton were listed as some of the customer databases that had been compromised as a result.

As many customers of these companies started receiving emails explaining that their email was exposed in the breach and could be used in illicit activities, email administrators starting looking at what they could learn as a result of this catastrophe.

Lesson One – Take Security Seriously

A Ponemon Institute study titled The State of IT Security: A Study of Utilities and Energy Companies stated that companies were more concerned with preventing network downtime than they were stopping a cyber-attack.

Of course, no one should find this surprising. After all, if an e-commerce site or CRM portal goes down, business can come to a halt. No business means no income so by all means this is going to take precedence. Besides, anyone who has been tasked with securing any type of technology doesn’t have the ROI that upper management is looking for when giving a project the go ahead.

In order to prevent another incident like Epsilon from happening, cyber security needs to be at the forefront of IT and management’s agendas. With the increasing problem of Advanced Persistent Threats, email security needs to be looked at and any weaknesses shored up.

Lesson Two – React Appropriately

The breach of Epsilon happened on March 30^th. By April 1^st it was disclosed to the public. This gave Epsilon, and their clients, ample time to put together a response based on the details of the data breach. For this, they should be applauded.

Far too often companies who are victims of this type of cyber crime spend so much time spinning their wheels deciding how to soften the blow of negative press that they forget the ramifications it can have on individual customers.

By making the details known from the beginning, the customers of Epsilon’s corporate clients were able to receive fair warning about phishing scams and other illicit activity that would certainly be a result of their email being exposed.

Lesson Three – Heed the Warning Signs

Another thing Epsilon did right was that they discovered the breach quickly. Had they not recognized that there was unusual activity going on, the breach would have yielded much more than the 2 percent of the customer base that had be compromised.

Epsilon was warned, along with other companies, that there was a high likelihood of a malicious hacking attack that would take place against email distributors. To mitigate this threat Epsilon beefed up its monitoring capabilities to watch for anomalies.

Lesson Four – Segment Your Data

Security professionals who have analyzed the data breach, such as Anup Ghosh, Founder and Chief Scientist for Invincea, think that this may be the work of a single attack.

“As we learn more about this breach, it could be very possible that a single intrusion was utilized to gain access to the data across all of these brands. Is this indicative of a potentially broader threat from a cloud perspective? Maybe yes, maybe no – only time will tell as we learn more and pull back more layers of both onions,” he went on to say.

It is a common suggestion in the security world that data should be segmented. For example, Client A’s data should be kept apart from Client B and Client C, or data should not be stored on the same server as web applications (which is common when it comes to default installations). Yet while this is often suggested, it is hardly ever practiced.

Segmenting data protects you because in the event one data set, application, network segment, etc. is compromised, all of your stored is not exposed as a result. It basically makes the attacker work harder for a big pay day. Of course if you are monitoring appropriately you will be able to spot the intrusion before more data is stolen.

The truth is Epsilon was not the last large company to have sensitive information regarding customers stolen. It will happen again. However if we can take the lessons learned and make security even tighter, then the gap between such incidents will continue to widen.

Lessons We Should Learn From Epsilon

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Advanced persistent threats make email security a necessity

Most email administrators consider security to be a large part of what they do. With so many laws and regulations governing the storage, discovery and retrieval of email messages, security has become a second job to many.

Unfortunately, many administrators either forget, or simply aren’t aware, that securing email requires much more effort than hardening the email servers against attack. In order to fully protect your organization’s email and their contents the mailbox also needs to be defended. Especially when you consider how popular Advanced Persistent Threats are becoming with large cyber crime syndicates who use email not only as a way to harvest sensitive information, but also as a method of attack through phishing and social engineering.

By implementing the following tips into your security plan you can help protect against these, and the many other threats that your organization may face:

Create email policies to regulate the communication of confidential information

Email communication has become second nature in the workplace. It is quick, easy and it gives us a record of our conversation so we can refer back to any information at a later date. However, if the conversation contains sensitive information like login credentials, financials, personal information, and the like, then it can be extremely valuable to anyone who may harvest those emails.

By simply setting up, and enforcing, policies that restrict certain information from being sent via email you can mitigate the damage done if emails are exposed. At the very least, your policy should state that user logins and passwords (and/or PINs) not be communicated via email.

Teach users to encrypt their messages

One of the best analogies I have seen to describe the need for encrypting emails is one that compares email to a postcard. Basically, anyone who comes across it can read the contents if they want. This can be stopped by encrypting emails to prevent eavesdropping.

Encryption is a hard thing for many people. It requires additional steps, training and, in some cases, third-party software (such as PGP) yet it is really the only way to keep your messages private in transit.

Encryption shouldn’t be limited to sending and receiving messages alone. Any email that is stored on a hard drive (think personal folders), a network drive, backup servers or archive systems should also be protected from any prying eyes.

Get rid of old email

A long time ago, storage space was a precious resource. Nowadays inboxes can be easily scaled to hold enormous amounts of data. Unfortunately that provides a greater possibility that an attacker will find something valuable.

Email should be moved, or deleted, when their life cycle is up. Make sure to check with any regulations regarding discovery and archiving before getting rid of the old stuff, but if you combine this with encryption you will be taking great strides to protect older emails.

Practice good network security habits

Make sure that desktops are continually scanned for malware that could possibly expose email login credentials, filter Internet content to protect against malicious websites, understand how to properly use a firewall and update server and client software as needed.

In addition to the employing technology to help secure your email systems you should also consider human factors as well. One of the ways that people first discover that their systems have been compromised is by noticing an anomaly. Be on the lookout for log-ins that just don’t seem right whether it be the IP address, the time of day or even the length of time.

This can be one of the most tedious tasks to undertake when it comes to security but it is by far the most important.

Put the right solutions in place

In many small and medium-sized enterprises, the email administrator alone cannot be as vigilant as he or she would like. Even in organizations where there is team of professionals dedicated to security use necessary security tools to help them do their jobs. Smaller companies need to understand this as well.

By employing technologies that help manage email, backup and recovery, archiving and security, you are plugging the little holes that provide that chink in the armor most attackers are looking for.

No one said that email security is going to be an easy task, but it is one that cannot be ignored just because it’s too hard or it costs too much.

Tips for Better Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In just one week Google, the International Monetary Fund and Citigroup have all made headlines as a result of email associated with them being under attack. The reason we continue to see companies make the news as a result of email attacks is that email security is sometimes ignored when it comes to training users properly and making good decisions. In some cases, having the latest and greatest when it comes to security tools even creates a false sense of security that causes us, and our users, to overlook the little things. A multi-layered defense that has been properly configured with all the best technology can be rendered useless if the little things are forgotten.

This list displays some of the most common mistakes that are made when it comes to email security and a brief description of what you can do to prevent them.

Leaky emails

There are many times when sensitive information is passed along via email. If everything is encrypted properly you, and your users, often assume that it will only be seen by the appropriate people. Unfortunately this isn’t always the case. Too many times a recipient may answer an email with sensitive information and hit the reply all button without checking to see who will be receiving the email.

The fix: Put a policy in place that addresses sensitive emails and reply to emails. However a policy alone isn’t enough. Make users aware of the policy through training and keep a record that all users were trained/informed of the policy and repercussions of not adhering to it.

Trusting others

When we receive emails from family, friends and business colleagues we often blindly open them without much concern. Especially if they are contacts we communicate with on a regular basis. However malware can easily be spread through emails by attachment or embedded code and links.

The fix: HTML in emails should be blocked if this is a concern, as should the ability for your users to receive attachments that are scripts or executable files.

Passwords that are easy to guess

Remember when Sarah Palin’s personal email account was breached? It was because her password was easy to guess using information the attacker found on her Wikipedia page. Companies often list information on corporate sites that provide attackers enough information to guess passwords as well.

The fix: Enforce strong passwords or password phrases for all users. Also, make sure that people don’t give up information that may be used to guess their passwords when providing bios.

Ignoring malware protection on the desktop

While scanning all emails for malware needs to be done, the desktop should not be ignored. And all too often it is. Malware definitions are outdated, software is not configured to run properly or protection is completely left to the user.

Even if you have a policy that enforces strong passwords, a keystroke logger can easily give up even the most complex password combination.

The fix: Email administrators should work closely with IT security to make sure that the desktop and network security isn’t lax so passwords are tougher to expose.

Failing to check on backups

Some companies and industries are required, by law, to back up and archive emails for a set period of time. Others are not required to do so. Regardless of the laws, every person and company should be in the practice of backing up emails. Emails often provide important records and information that could be lost.

But what happens if you need to restore your emails and find that something went wrong? Maybe the backup was incorrectly configured or the backup location was insecure. In any event, the inability to restore emails from a backup can render the entire solution useless.

The fix: Frequently test the ability of your backup solution, and staff, to restore emails.

These five tips may seem basic and simple. But that is the point. Working in IT we often gravitate towards the more complex issues and ignore simple techniques and solutions until it is too late. By taking the time to do the little things when it comes to security, we build an even stronger foundation for all the bells, whistles and technologies that really impress us and our bosses.

5 Simple Mistakes When it Comes to Email Security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Information leaks can be harmful to an organization’s profitable operation. Microsoft Exchange 2010, with its rights management features, can give a company the kind of control over its information to reduce the risk of such leaks occurring.

In an Exchange environment, rights management can be imposed through the Active Directory Rights Management Server. Rights Management was introduced by Microsoft to its Windows Server product in 2003 and later renamed when Windows Server 2008 debuted. The name change reflected improved integration with Active Directory.

Rights Management allows administrators, as well as others, to control access to documents, emails and web pages. It also can be used to limit what can be done to those things. For example, functions such as printing, copying, altering or forwarding can be enabled or disabled for documents or emails. What’s more, administrators can bundle rights in templates that can be applied across a system.

The reason behind rights management is a simple one. Information that should be for internal eyes only should not be exposed to external scrutiny. Rights management aims to plug the leakage of confidential information, either intentionally or unintentionally.

What’s to fear from information leakage? Given the rising interest among regulators in data breaches and the appearance of new laws punishing organizations with lax attitudes toward leakage, a company can face financial penalties for failing to adequately secure the transmission and storage of certain kinds of data, such as customer records. Moreover, because more and more states are requiring companies to report data breaches, the adverse publicity could cost an organization customers and for public companies, market capitalization.

In addition, unauthorized airing of sensitive information can be exploited by competitors to diminish an organization’s competitive advantage in the marketplace. Imagine the impact of information about a planned acquisition or new product being released in the wild prematurely.

Rights management isn’t a bulletproof solution to leakage problems. You can bar a user from forwarding a message that contains sensitive information. Determined users, though, will find a way around rights management. For example, email text can be selected, copied and pasted into an unprotected message and leaked that way, or if copying is prohibited, a would-be leaker can display the message on their computer, whip out a cell phone, take a photo of the screen and forward the message to others that way. In an age when appearance is often a substitute for substance, though, rights management shouldn’t be short changed. With rights management in place, when a leak does occur, an organization can claim that it took all reasonable steps to protect the information within the Exchange infrastructure.

Two traditional ways to control information leaks are TLS, or Transport Layer Security, and email encryption. Both protect the initial access to data, but are less effective in providing constant protection of it.

TLS only protects messages in transit one SMTP host to another. Moreover, it only guarantees protection for the first SMTP “hop.” So you can require TLS protection when you send a message from your SMTP server to another one, but that other server need not use TLS when it moves the message on the next stage of its journey. When the message arrives at its destination, it sits unprotected in an inbox. What’s more, the recipient can do anything with the message–copy, forward or print it.

Email encryption solutions are usually left to the user’s discretion. Ordinarily that’s not the best way to promote consistent or effective email security. Not only are there costs associated with encryption–deployment of a public key infrastructure and maintenance of certificate management and private key protection schemes–but once a message is decrypted, an organization loses all control over what can be done with the message. In addition, encrypted messages can’t be inspected by an organization until they’re decrypted. That prevents your security programs from immediately inspecting messages for malicious content or for violations of messaging policies.

Rights management in Exchange addresses the security deficiencies found in the traditional methods of controlling leaks. It can shut down the ability of someone receiving a rights protected message from forwarding, modifying, printing, faxing, saving, cutting, copying or pasting its content.

What’s more, that level of protection can be extended to attachments. In addition, expiration dates can be imposed on messages and attachments so they can be viewed for a certain amount of time and the snipping tool can be disabled when viewing a rights protected message.

Of course, as mentioned before, there are ways to circumvent rights management. Third-party screen capture programs, for instance, can still be used to nab an image of a rights protected document. Content can be transcribed into another application, too. Nevertheless, rights management can be a significant barrier to information leakage in an organization.

Plugging Leaks using Rights Management

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Securing remote Outlook client access to Exchange

As more businesses embrace the distributed workforce, moving more and more employees from the traditional cubicle farm into more of a work remotely arrangement (whether these employees are the classical road warriors, or simply working from their own home office) one of the most important resources they will need to access is of course email. As more and more companies embrace SharePoint as an Internet connected portal, and as other applications move to the cloud these remote users have less and less reason to come into the office to connect to the corporate network. This may present the Exchange administrator and/or architect of the next email system with the question of whether to design a solution that depends upon a VPN connection, or to deploy a solution using Outlook Anywhere.

Both are perfectly secure and valid solutions for connecting Outlook clients to Exchange, and both have definite advantages and disadvantages. This article will discuss both solutions, and present the pros and cons of each.

Decision Points

There are some decision points that may make your choice obvious. The first question to ask is, “What do clients need to access remotely?” If the answer is “email only,” then Outlook Anywhere will be a great fit. If the answer includes regular access to other corporate resources, then VPN is probably the right way to go.

Outlook Anywhere

Outlook Anywhere is the new name for RPC-over-HTTPS. Here, we connect Outlook to Exchange by tunneling the RPC connections through an HTTPS connection. The HTTPS connection is  secured by a certificate that can use a 1024, 2048, or larger public key to secure the exchange of the 128 bit symmetric session key, giving us what is essentially 128 bit encryption. When using Outlook Anywhere, only the traffic generated by the Outlook client accessing the Exchange server is sent over the encrypted connection. All other traffic goes out the client’s Internet connection, and is encrypted or not depending on the application. Let’s look at the pros of this access method.

• It’s easy to set up on the client. The client just needs to launch Outlook and authenticate.
• It’s easy to support in the data center. The firewall engineer needs only to permit TCP 443 through to Exchange, and the DNS admin only needs to support a couple of DNS entries for autodiscover.
• It’s secure. Using certificates from a trusted CA, Exchange offers a 128 bit encrypted connection to Outlook clients, or you can use 256 bit encryption with SSL offloading.
• Requires only standard protocols (HTTP, HTTPS, and DNS) from the client’s network, meaning that it should work from any hotspot or guest network that supports web surfing.

Of course, you can’t have pros without cons.

• Using Outlook Anywhere, clients only have access to Exchange.
• Some organisations do not permit connectivity to anything from the outside unless it goes through a VPN connection.
• Without SSL offloading, the encryption from Outlook Anywhere can place additional load on your Exchange CAS servers.
• Clients who only connect to Outlook Anywhere do not process login scripts or connect to your other internal servers, such as WSUS or your antivirus servers.

I have seen that last con present problems to a number of organisations with a large remote work force. If everything a remote user needs is accessible over the Internet, they don’t have a reason to connect to the VPN so that you can manage their machines, patch them, etc. Direct Access is a great way to work around this limitation, but only if all of your remote users run Windows 7.

VPN

There are dozens if not hundreds of different VPN solutions available, offering PPTP, IPSEC, or SSL connections. With the choice to route some or all traffic through the VPN, connected clients can access other internal network resources, and route all their traffic through the VPN to protect them when connecting from hotspots or other open networks. While connected to the VPN, clients can connect to WSUS for updates, or be polled by SCCM, etc. So to call out some of the pros:

• Full connectivity to all internal network resources (depending on configuration.)
• Support for stronger encryption, with some solutions including AES256.
• VPN connected clients can be polled/managed by other internal systems.

Of course, if it was the perfect solution, everyone would do it. Here are some of the more obvious cons.

• VPN solutions can be extremely expensive. If they are licensed by the concurrent connection, you may need to support more clients than you have licenses.
•  The bandwidth consumption will be much higher than for Outlook Anywhere clients. If you do not split tunnel, then all client traffic will traverse the VPN before going back out to the Internet.
•  Except for SSL VPNs, most require more outbound ports and ip types that web access alone, and many Internet hotspots don’t support outbound VPN access.

Consider the following points when trying to decide which solution to deploy.

1. They are not mutually exclusive solutions. You can offer Outlook Anywhere for users when they only need to access email, and also have VPN access for when they need the more connected experience.
2. If you have chosen to outsource email to a hosted service provider, you may be accessing Exchange using Outlook Anywhere anyway, unless you specify that you want access restricted to only your networks, and to have your clients first connect to your VPN before transiting the WAN to reach the hosted Exchange environment.

Outlook Anywhere versus VPN

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Welcome to part two in a series on securing email. In part one we introduced the challenge, and three influences; compliance, technology, and support.

In this post, we’re going to look at two of the prevailing methods for securing email exchanges between servers… the way two businesses might wish to secure the email exchanges between them to prevent eavesdropping or interception on the Internet. We’ll look at SMTP/TLS and at routing SMTP over a VPN connection, and look at the pros and cons of each method.

In server to server solutions, we are looking at securing email exchanges between the MTAs controlling email for two different companies. These companies do not share email systems, or private network connections between them, so all SMTP mail will move from server to server using the Internet.

SMTP/TLS

One standard method of securing email is SMTP/TLS. This secures the transmission of SMTP messages between servers that support this using a session key securely exchanged by the servers using a certificate; much like HTTPS transmissions are secured.

Pros:

• As a standard, it is growing in acceptance, and most major mail servers include support for the technology today.
• Certificates from public CAs are readily available, and trusted.
• There are varying levels of encryption available.
• This is seamless to the user, and requires no client configuration.

Cons:

• Managing certificates requires knowledge and some degree of administrative overhead, and is often considered the responsibility of the information security department.
• Troubleshooting network issues is more complicated since all of the traffic after the certificate exchange is encrypted.
• Email messages between the client* and their mailbox server are not protected, and can be accessed by the email administrators, network engineers, or others with access to the internal networks at either company.
• Many companies use either self-signed, or internally generated certificates. You may have to ‘trust’ these certificates, which requires additional configuration on your server as well as a willingness to relax your security posture, or obtain an exception to policy.
• Encryption does require additional processing power, and this will have to be handled by your SMTP edge server, which may also be doing anti-x, and content screening.

Routing SMTP traffic over a VPN tunnel

Another method is to establish a VPN connection between enterprises and route the SMTP traffic between entities over this tunnel. VPNs are a robust and widely accepted method of encrypting data in transit, and companies may already have a VPN in place for extranet access.

Pros:

• Practically all companies with an Internet connection have the necessary hardware to support a VPN connection.
• Offloading the encryption to the firewall/router/vpn concentrator reduces the load on the mail system.
• Troubleshooting network issues is easier.

Cons:

• In most companies, this will require the network team or the information security team’s involvement to set up, maintain, and support the VPN.
• Email messages between the client* and their mailbox server are not protected, and can be accessed by the email administrators, network engineers, or others with access to the internal networks at either company.
• Troubleshooting issues can be delayed if the multiple departments involved do not immediately engage and work together towards resolution.
• Unless routing is carefully implemented (policy-based routing of only SMTP, or using /32 addresses) problems with traffic not intended for the VPN tunnel like DNS queries and HTTP traffic can be adversely affected.

Whether using SMTP/TLS or VPN, you will likely find yourself working with at least one other group within your IT team. Ensuring that everyone involved understands the chosen technology, the importance of supporting the solution, and the need to work together will help minimise any issues and ensure a quick and successful resolution to any issues.

*Email messages between the client and their server may be protected separately, using encrypted MAPI (Outlook to Exchange) or TLS/SSL protected versions of SMTP, POP3, and IMAP.

Be sure to check back for part three of this series, where we’ll look at the pros and cons of two client side solutions, PGP and S/MIME.

Securing Email Part Two-Server to Server

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Most users will agree that email is a mission critical business tool. Confidential business information, proposals, and contracts are sent via email daily all over the Internet, and most of our users never give a second thought to the sensitive, privileged, and sometimes even critical information that they are sending over an unencrypted transmission, there for anyone with a protocol analyser to read.

They may not even realise that they could be violating company policy, contractual obligations, or even legal statutes regarding the transmission of confidential information. All companies should have policies regarding the transmission of sensitive information through email. While a policy that prohibits any such information being sent using email could greatly reduce the chance of disclosure, the reality of business communications is that this is not a practical approach.

This is part one of a three part series, where we will discuss some of the issues that surround and influence securing email. In part two of this series, we will discuss the pros and cons of server side solutions; SMTP/TLS and routing email over VPN connections. And in part three, we will look at the pros and cons of client side solutions; PGP and S/MIME. If you’d like to understand more about why we would want to encrypt email, please read on.

To secure the email sent between organisations, you need to consider not only what capabilities your system has, but what your IT team can support, what your users can work with, and what your clients/customers/vendors have on their systems. While there are many different standards-based ways to protect email, there is no one single standard. We are still in the early “VHS versus Betamax” stages of seeing how the industry will shake this out, so we may find ourselves needing to support more than one standard unless we are in the position to dictate to our partners the standards to use. Be careful though; when working with customers, they may be doing the dictating, and when dealing with the public, you may find that there is no standard you can use unless you are prepared to support end users whose systems are outside your control.

Compliance

In the United States, HIPPA and Massachusetts 201 CMR 17 are both laws that include requirements for the transmission of Personally Identifiable Information (PII,) sometimes called Non-Public Information (NPI) and the need to protect this information from unauthorised access. For companies that accept credit cards, compliance with the Payment Card Industry standards (PCI) is a requirement.

You may also find yourself required to meet the contractual obligations of a vendor, customer, or business partner. Work with your legal team to determine what requirements affect your email systems to ensure that you meet all such laws and business agreements, and with your information security team to make certain that you understand and comply with any corporate policies. Raise awareness within the business of your capabilities, and ensure that you are involved in any discussions with partner organisations regarding messaging between your systems.

Technology

Review the capabilities of your current email system on both the server and the client to ensure that you fully understand what you can, and cannot do. Server standards like SMTP/TLS can help to secure server to server communications, but so too can routing SMTP traffic over a VPN. Most clients can support either S/MIME or PGP, but not all can, and both of these solutions can be costly, and require significant expenditures in licensing or certificates.

The flip side of this coin has to do with what encryption may mean as it pertains to your normal administration. Server to server encryption will make it more challenging to troubleshoot SMTP exchanges between servers, and will require more setup efforts, certificate management, and CPU cycles on your gateways. S/MIME or PGP encrypted messages may be secure, but they also cannot be screened for content or malware, so exceptions may be necessary on your protection mechanisms, and the associated risks will have to be understood and accepted.

Support

While securing email may seem to be strictly the task of the email team, your choice of solution(s) may involve others. In many companies, PKI Administration falls under the Information Security team’s purview. VPN connections may be handled by the network team. Client-side solutions may require the application or desktop support teams to deploy and support. When considering your options, involve all of these teams to ensure that the solution you choose does not run into a brick wall when another team will need to implement and/or support some part of it.

Consider these aspects, and stay tuned for part two of this series, where we will discuss server side solutions.

Securing Email Part One – The Challenges

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Thanks for sticking with us, and welcome to part three of this series on securing email. In part one we introduced the challenge, and three influences; compliance, technology, and support. And in part two, we looked at SMTP/TLS and routing SMTP over a VPN for server side solutions. In this final part, we’re going to look at client side solutions to ensure we are securing our email from sender to recipient.

There are two standard ways to do this. Both utilise the services of a PKI, and will require client side configurations. As such we may also find that we need to work with yet another part of the IT department; our desktop support team. They own the desktops and will likely be responsible for the client side configuration necessary with either of these solutions.

When securing email using client to client solutions, we may find this to be the most challenging approach for a number of reasons. We will need to ‘touch’ the clients, and we will need to ensure that we are implementing a solution that is compatible with the recipient systems. On the server side, we can split up our SMTP exchanges, sending some out to the Internet in the clear, others over a VPN, and still others using SMTP/TLS. When working with client side solutions, we need to make sure that what we implement on our clients is the same as what our partner organisation has implemented on their clients. If we have two partner organisations where one chose S/MIME and the other went with PGP, then we may need to purchase both for all the clients that must communicate with both partners.

S/MIME

Addressed in RFC 5751, S/MIME is designed as an end to end encryption mechanism for email, using PKI encryption with certificates obtained from a certificate authority.

Pros:

• S/MIME allows for digital signing, encryption, non-repudiation, and key escrow to prevent data loss.
• Can be used to protect emails between internal users as well.
• Data is protected from the original client through to the intended recipient, and cannot be viewed on the internal network or on any intermediate server.
• SMTP traffic between servers remains in the clear, so protocol messages can be seen for troubleshooting issues without compromising the integrity of the email contents.

Cons:

• Each user’s mail client must be configured to support S/MIME.
• To support both non-repudiation and key escrow, each user must have two different key pairs.
• Before a client can send someone an encrypted email, they must obtain the addressee’s certificate/public key.
• Most webmail applications (a critical need for many clients) cannot support S/MIME.
• Anti-malware and content screening cannot scan the contents of an S/MIME encrypted email. Exceptions must be configured to allow mail to pass uninspected, and you must accept the risk that such email may contain malicious code or content that violates policy.

PGP

PGP and its compatible GPG, uses key pairs to provide encryption and signing of email messages (and of files.) There are several open source products as well as commercial ones available for many common email clients.

Pros:

• PGP allows for digital signing, encryption, and non-repudiation.
• Can be used to protect emails between internal users as well.
• Data is protected from the original client through to the intended recipient, and cannot be viewed on the internal network or on any intermediate server.
• SMTP traffic between servers remains in the clear, so protocol messages can be seen for troubleshooting issues without compromising the integrity of the email contents.
• Certificates are not required.
• Several PGP key servers exist to facilitate key exchange between users.

Cons:

• Each user’s mail client must be configured to support PGP.
• To send an encrypted mail to a recipient, you must obtain their public key. Without a certificate authority to act as a trusted third party, you must arrange to obtain that key through a method you are willing to trust.
• Commercial products can be very costly at the enterprise level.
• Most webmail applications (a critical need for many clients) cannot support PGP.
• Anti-malware and content screening cannot scan the contents of a PGP encrypted email. Exceptions must be configured to allow mail to pass uninspected, and you must accept the risk that such email may contain malicious code or content that violates policy.

With either solution, you can securely send email between users without concern for any unauthorised users viewing the contents of the email; even your email system administrators. If this is a requirement for your organisation, then either of these solutions can help you to meet this requirement. Look at both, discuss what solutions may be in place with your existing partners, and determine which has the best fit for your organisation.

Securing Email Part Three – Client to Client

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Encryption is an important component to an email system so choosing an encryption solution should be done carefully. What should be considered when evaluating an encryption protection scheme for an organization’s email system? Here are some suggestions to keep in mind.

One important consideration is whether or not a solution uses open standards. Since email is based on an open standard, there are advantages to basing any protection placed on top of it on open standards, too.

One advantage is open standards assure that data can be recovered in the future. If your vendor uses open standards, then you don’t have to worry about accessing your data should you decide to move to another provider in the future or should your vendor go belly up during the next recession.

Another consideration when choosing an encryption solution is mobility. Mobility is important because email must be accessible to a variety of devices from anywhere. Wherever an organization’s workers travel, they’ll want to check their messages and an email encryption solution needs to accommodate that without creating any hassles.

A solid encryption solution should be able to use a mobile device’s native email application. You don’t want to force your workers to learn another interface for their mobile device or leave an email program they’ve become accustomed to in order to work with encrypted messages. Making things harder for users is a sure fire way to invite them to look for ways to circumvent the system. Those ways are almost always insecure and make your organization vulnerable to a raft of unsavory cyber types.

How will the new encryption solution jibe with your existing architecture? For example, do you want only outbound mail to be encrypted, or do you want mail within your organization encrypted, too? A flexible encryption solution will mesh with what you have in place. You want the encryption solution to acclimate itself to your needs and not have to bend your needs to accommodate the solution.

A flexible encryption system is also important for dealing with future uncertainty. Companies grow. Today’s 500 user company is tomorrow’s 1000 user one. Your encryption system needs to be able to adjust to those kinds of changes. If it can’t, it can affect the system architecture for your entire organization down the road. It can lock you into architectural models that are inadequate to meet the new needs of your company.

For example, today you may be satisfied with an encryption solution that just handles your email. Tomorrow, you may want to expand the scope of that encryption solution to include protecting files, folders, disks and other devices. If that’s the case, then you need to ask yourself, will the encryption solution force you to alter your infrastructure to accommodate that kind of expansion? Will it require you to create a new set of encryption keys for your users? Will it involve embarking on a training program for your organization to learn the new system?

In addition, an organization has to look beyond its own walls when picking an encryption solution. Will it be interoperable with your partners or others you do business with? Just as your users won’t be happy with a solution that forces them to alter established work practices, your organization’s customers and business partners won’t be enamored with a solution that imposes burdens on their existing systems. So when evaluating solution alternatives, interoperability with a variety of encryption systems is an important feature to consider.

With more and more companies coming under regulatory scrutiny and being compelled to comply with rules, regulations and laws governing how data is treated by organizations, as well as the growing pressure to incorporate cloud services into business operations, encryption solutions are becoming more important than ever. In some cases, encryption is required to meet legal requirements–as in Nevada where businesses must encrypt any personal information of a customer that is electronically transmitted. In the case of the cloud, encrypting data sent there just makes good sense to ensure information can’t be snooped either in transit or wherever it’s stored in the nimbus. For those reasons, among others, choosing an email encryption solution for your organization that satisfies not only external demands on it but its internal needs, both in the present and in the future is a decision that needs judicious consideration.

What to look for in an email encryption solution

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

If you’re even remotely connected to the healthcare industry, you have been, or will be, affected by the Health Insurance Portability and Accountability Act (HIPAA). This regulation mandates security and privacy in several areas, including the storage, access, and communication of sensitive or private healthcare information.

Firewalling, along with access controls that include authorization and authentication, are critical to HIPAA compliance, although email security is also a vital part of it. Healthcare organizations and covered entities, as well as patients themselves, often rely on email as an efficient way to communicate information. However, ordinary email may be inadequate.

It would be a mistake to neglect email in a HIPAA compliance initiative, and any incidence of exposed–or even potentially exposed–personal health information via email would result in a failed audit. HIPAA does not stop at stored medical records, it includes any sort of record, including email. There are two fronts to consider; immediate email security, and the security of archived email files, both of which are essential for compliance. Archived email files in a HIPAA-compliant firm should be subject to access controls (authorization and authentication). In day-to-day email, there is also a risk of deviating from compliance. If an email contains regulated information under HIPAA, then it also must be protected against unauthorized access. Since email goes over the unprotected Internet, encryption would be the only logical way to address this.

The biggest risks are either not using available encryption, or not having it available at all, consequently, training of all staff to use encryption is a big part of the process.

While some health care organizations simply take the approach of forbidding any covered information from being sent via email, in reality, that’s not always practical. Instituting a policy of never sending patient information via email, particularly if email encryption is not in use, may lead to liability as well–since it is very likely that despite policy, rushed employees may still resort to email. The best approach is to ensure that those emails are protected.

Indirectly too, email protection such as anti-virus and anti-spam technology is also part of the grander HIPAA scheme, since these will help ensure that the network itself does not suffer downtime or lost data due to email-based attacks.

HIPAA and email security

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Kevin Nixon ran a fascinating article on encryption at Information Security Resources yesterday, disputing the need for end-to-end encryption, saying that it’s not such a great idea after all.

I’ve never used encryption for my email personally, though plenty of people do. And for some users, like the President when he’s using his BlackBerry, I’d have to say that it’s essential. But Kevin’s argument bears consideration, especially when applied to ordinary usage.

A couple of simple examples of end-to-end are VPNs, where encryption starts at a VPN client in a remote location, and ends at the VPN server in the main office. Also, SSL–which is used widely over the Web–provides another example: End-to-end starts at the user’s Web browser and ends at the Web server on the back end. The limitation here, according to Kevin, is that the traffic arrives at its destination before being evaluated. He makes a good point. The concept behind end-to-end encryption may be a good one, but it needs an extra step.

Security experts advocate multiple layers of security; for example, both perimeter security and endpoint security are considered essential. But, when traffic (including email) is encrypted, it may not be able to be analyzed by the firewall or by any perimeter-based intrusion detection engines, thereby eliminating the effectiveness of one of multiple layers. Kevin also cites S/MIME as a particular concern, since the contents of an encrypted email cannot be analyzed for malicious content until after it has been decrypted. This means that the malware prevention has to take place on the desktop for the first time–instead of using the desktop security as a “final check” after traffic has already run the gauntlet of other perimeter-based security.

There are some solutions, which involves an extra device or a firewall that is equipped to analyze encrypted traffic; this approach decrypts traffic, analyzes it for malicious content, and then either sends it in the clear or re-crypts it for the rest of the journey.

Encrypted email not for everyone

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Sending unsecured email is very risky and in some cases even against company policy. One of the best ways to secure your email is by use of encryption. The sender types up their email and then hits the secure button or encrypt button depending on the email client used and then hits the send button. What happens underneath is that the sender’s text message is encrypted with their private key and when the recipient receives the email message they then decrypt the message using the sender’s public key.

Another approach to sending email in a secure manner is to use the Secure Socket Layer (SSL) connection. Two applications such as a client and a server will use an encrypted channel to send and receive information to/from one another. The application sends data through the SSL channel which itself is using the default TCP/IP port 443. Data passes through the secure channel so that both sender and receiver can read and understand the transmitted data. The secured channel protects the data from being read by an unwanted third party.

Another approach to sending secure email through an SSL channel is to encrypt the data with the public key of the specified recipient before sending it into and through the secured SSL channel. So even if the SSL channel is hacked or sniffed then the hacker still cannot see the plain text message because they would not possess the intended recipient’s private key needed to decrypt the message. This approach adds a second layer of encryption onto the email communication process if SSL is used for the communications. The result is that encrypted messages are sent and received within an already encrypted data communication channel.

It is possible to add a third layer of security to the email communication process by placing a central server – an email gateway – between the clients who are sending and receiving the encrypted emails through the already encrypted SSL channel. This server can act as a repository for the encrypted emails and forward them on to the intended recipients when requested to do so.

The benefit of such an arrangement is that the server only hosts the encrypted messages and can be used to keep costs and CPU cycles down to a minimum if such a server is hosted at another site by another company who specialized in this methodology. Remember that the private keys are not distributed so the hosted encrypted emails cannot be decrypted by any outside third party.

Secure Email Methods

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The Nevada law that requires businesses to encrypt data that is transmitted to customers took effect this month, and is expected to have an impact far beyond the state’s borders. An article in today’s Wall Street Journal highlighted some of the challenges of the bill, to which all companies doing business with people in Arizona must comply.

Nevada is just the first of several states that are considering similar laws. Already, more than 40 states have breach notification laws, which require businesses to notify customers if their personal information is stolen or exposed. But beyond requiring notification, these laws do very little to prevent the attacks from occurring in the first place. There’s a big difference between telling someone, “your personal information was exposed,” and requiring action to prevent it from being exposed. The Nevada law is the first that takes this tactic, going much further than any notification law ever has.

According to the Journal article, notification laws reduce identity theft by only about two percent. Clearly, these laws have been a failure. Notification laws do nothing at all to address the core problem, they only attempt to address the after-effects.

The Arizona law puts some real teeth into the issue of identity theft. While you may still be liable under notification laws to give notice of a breach or potential breach, the new Nevada law means you have to take action to prevent it from happening by using encryption. And what’s more, if you don’t do it, it will cost you, and cost you plenty. Under the regulation, if you did comply with the mandate to use encryption, if a breach still occurs, your damages are capped at $1,000 per incident. However, if you did not use encryption, civil penalties are unlimited.

New law requiring email encryption takes effect

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators