An email security and anti-spam solution is probably one of the most important security products you can buy to protect both your network and your company’s overall employee productivity. To add to the pressure of making the correct decision, there are a lot of email security and anti‐spam solutions and products on the market. So how do you select the right product at the right price for your organization?
This blog post will cover the first five of 10 things that you need to consider when comparing email security and anti-spam solutions.
1. Understand the difference between ‘affordable’ and ‘cheap’
One way some manufacturers cut costs is by using extremely cheap components in their email security appliances, resulting in a high percentage defects on arrival, as well as a high failure rate in the field. Another way they often make prices look low is by showcasing the low‐end models that offer limited functionality. In this scenario you’ll have to buy several appliances to do the work, meaning double or triple the cost.
2. Can I buy it from my trusted reseller, or do I have to order it over the phone?
Some SMB email security and anti‐spam solution vendors try to sell both direct to the customer and through a reseller network, resulting in a poorly organized reseller network. This means customers are forced to rely on the corporation for pre‐ and post‐purchase support -- usually over the phone -- rather than in person, even if they are in a completely different geography or time zone.
3. Understand the real TCO
One question to ask regarding price is what the ‘real’ total cost of ownership is. If your email security and anti‐spam solution requires ongoing management and attention, it means ultimately higher costs throughout the life of the appliance. If the vendor does not offer appliances that are designed to be centrally administered, you’ll spend even more time on overall management rather than on other critical IT business initiatives.
In some instances you’ll also need to buy a completely separate appliance for administration of inbound and outbound email traffic, in addition to a separate module for reporting. Numerous purchases can and will skew your TCO.
4. Consider your company’s growth prior to purchase
Many email security and anti‐spam solutions are designed to handle only small volumes of users and traffic. Their mail processing systems can’t handle the high‐volume mail loads of an organization with thousands of users or those with significant throughput environments.
5. The ease of setup
Some email security and anti‐spam vendors claim their products can be up and running in 15 minutes and require no IT expertise. But installation is usually not this simple and many times they have no install wizard available for system setup.
In our next blog post, we’ll review the next 5 things to consider when comparing email security and anti-spam solutions. If you have questions (or horror stories) we’d love to hear from you, so please leave a comment below.
Posted by Chris McKie on Jun 20, 2011 at 9:37 AM0 comments
Fresh on the heels of the massive email security breach at Epsilon, we’re seeing a renewed interest in email security solutions and email encryption. And that’s a good thing! It’s not just Epsilon that experiences email security breaches, just do a Google searchon ‘email security breach news’ and see for yourself. One study -- Email still the top source of data loss, by Help Net Security -- revealed that more than 35 percent of companies surveyed had investigated a leak of confidential or proprietary information via email over a 12-month period. On average, respondents estimated that as many as one in five outbound email messages contain content that poses a legal, financial, or regulatory risk.
According to the Ponemon Institute’s annual U.S Cost of a Data Breach Study, non-compliance costs are 2.65 times higher for organizations than compliance costs. That means that companies with ongoing investments in compliance-related activities save money compared with organizations that fail to comply with government and industry mandates. In short, it pays to be compliant.
Email encryption is an essential component of regulations that are designed to protect the privacy and reliability of business and personal information.
Email Encryption Laws and Regulations
The following list includes just some of the requirements that are driving encryption adoption in the United States and around the world.
- HIPAA and HITECH Encryption is now a primary aspect of HIPAA (Health Insurance Portability and Accountability Act) since the passing of HITECH (Health Information Technology for Economic and Clinical Health Act) regulations in 2009. HITECH requires healthcare providers to notify individuals when their protected health information (PHI) is breached. For example, if a hacker hijacks unencrypted PHI in transit from a physician’s office, the physician practice would have to inform the patients and the Department of Health and Human Services of the breach. However, if the electronic PHI is transmitted in encrypted form, notification is not necessary even if there is a security breach. Email encryption grants safe harbor because it can be assumed that the transmitted data is unreadable by unauthorized individuals.
- PCI DSS (Payment Card Industry Data Security Standards) is very clear. Requirement 4 mandates the encrypted transmission of cardholder data across open, public networks.
- EU Data Protection Directive (also known as Directive 95/46/EC) was designed to protect the privacy of all personal data collected for or about citizens of the EU. According to the Information Law Group’s Code or Clear? Encryption Requirements, encryption is becoming a mandatory checklist item to establish “reasonable” security for sensitive categories of data for the EU, and “… it would be difficult to defend an organization’s security measures for sensitive data as ‘reasonable’ without reference to such [email encryption] standards or industry practices.”
- SOX (Sarbanes-Oxley Act) governs the integrity of financial operations of publicly traded companies with the primary goal of protecting “investors by improving the accuracy and reliability of corporate disclosures made pursuant to securities laws.” Although email encryption is not explicitly mandated as part of the internal controls, SOX implies the need for encryption to protect the integrity and confidentiality of financial information.
- GLBA (Gramm-Leach-Bliley Act) requires that all financial institutions maintain safeguards to protect customer information. Although GLBA does not expressly require email encryption, it does require that financial institutions implement the necessary technological controls to protect the privacy and security of customer financial information. The Federal Financial Institutions Examination Council (FFIEC) recommends that institutions employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. If a financial institution does not deploy encryption to the degree expected by the FFIEC, then the institution must demonstrate that it considered the use of encryption and justify why it chose not to deploy it. Financial institutions, therefore, must carefully evaluate the need to encrypt emails to protect against unauthorized access to sensitive information.
- California Security Breach Notification Act (SB 1386) requires a business, regardless of its location, that owns or licenses personal information about a California resident to implement and maintain reasonable security procedures and practices to protect the personal information from unauthorized disclosure. If protected information is acquired by an unauthorized person, then the business must promptly give notice, but only if the data was not properly encrypted.
- Nevada Statute, passed in 2008, made Nevada the first among a growing number of states to specifically require email encryption for those that contains personal customer information. The statute states that, “A business in this State shall not transfer any personal information of a customer through an electronic transmission other than a facsimile to a person outside of the secure system of the business unless the business uses encryption to ensure the security of electronic transmission.”
Posted by Chris McKie on Jun 06, 2011 at 12:12 PM0 comments
Title I of the Commercial Privacy Bill of Rights Act of 2011 is comprised of two rights -- the Right to Security and the Right to Accountability. This posting focuses on the second part, the Right to Accountability.
Similar to the Right to Security, this section is short. In essence it says that each “covered entity” (see the previous post for what that entails), shall:
1. Have reasonable accountability for the adoption and implementation of policies consistent with this Act;
2. Develop a process for responding to non-frivolous individual complaints about how their personally identifiable information (PII) is collected, used and managed;
3. And lastly, document and communicate how it complies with this Act upon request from an authorized party, such as the FTC.
What this section really says can be narrowed down to one word: POLICY
Legislation aside, if your businesses or organization manages sensitive data, you should already have a formal, written policy as to how information is safeguarded, managed and accounted. So for many, this requirement is nothing new to what they should already have in place.
That being said, there are many SMB organizations that would be affected by this Act and do not have a security policy in place. It follows then, that for this reason, requiring businesses to have a security policy in place may be extremely beneficial for businesses and consumers.
And the easiest way to make a policy? Borrow from the Deming Wheel.
Here is a brief outline to writing any business process or policy:
- PLAN -- put your plan in writing, assign an owner, and define how your business will comply with this Act;
- DO -- put your plan in place, test it, train others on it and make it known in the organization;
- CHECK -- make a checklist, regularly audit the process, verify and document results;
- ACT -- improve on the process where possible.
In summary, the whole issue of accountability boils down to putting data security policies in place that are “proportional to the size and structure” of your business or organization. Even if this Act does not become law, creating a formal security policy is certainly the prudent thing to do for any business.
Posted by Chris McKie on May 10, 2011 at 12:01 PM0 comments
In the latest Draft of the “Commercial Privacy Bill of Rights Act of 2011,” the first Title, “Right to Security and Accountability” is actually quite short – in fact, the Right to Security section contains just 53 words. The key provision reads, “…to require each covered entity to impose reasonable security measures to protect covered information it collects and maintains.”
First, what is a “covered entity?” The Act defines a covered entity to be: any person that collects, uses, transfers or maintains covered information concerning more than 5,000 individuals during any consecutive 12-month period. Keep in mind; a “person” can also be a corporation, non-profit organization, or any other entity that the Federal Trade Commission has authority over.
What this says is that the Act will affect just about every size and type of organization that collects records on more than 5,000 people a year. That is huge in terms of scope!
Next, what is “reasonable security?” This is fairly easy to define, although it may seem vague. In law, the “reasonable standard” is often deemed to be a standard for what is fair and appropriate under usual and ordinary circumstances.
Here, the industry (both hackers and security vendors) will play a significant role in helping to define what is “reasonable security.” Certainly having a firewall is a start. But, is a firewall from 2003 “reasonable” by today’s standards? Possibly not. Given that hackers are more sophisticated than ever and utilize extremely nefarious techniques that constantly evolve, the traditional firewall from even a few years ago may not be sufficiently capable to meet today’s reasonable security needs.
Next we answer what is “covered information.” Covered information means personally identifiable information (PII), unique identifier information (UII) and any information that is collected, used or maintained in connection with PII or UII that may be used to identify an individual.
Some industry regulations, such as PCI DSS, have similar requirements, so for many businesses this is nothing unusual. The Act specifies that home addresses, email addresses, telephone numbers, cookies, user IDs, as well as the usual suspects of social security numbers or other government issued identifiers are all “covered information.”
Bottom line: Personal privacy is worthy of protection, which is exactly what this Act aims to achieve. The scope of this Act will certainly mean that nearly every business will have to, at a minimum, reexamine their security posture to ensure that they are reasonably secure. In the wake of the Epsilon breach, the “Right to Security” seems unquestionable. What remains, then, are the questions of the other provisions in this Act, and what they mean to consumers and businesses.
More to come on part two, where we examine the second half of Title I, “Right to Security and Accountability.” There we analyze the impact of “accountability.”
Posted by Chris McKie on May 03, 2011 at 8:03 PM0 comments
If you’ve followed security news over the past few days, you’ve probably seen a lot of hoopla about a TCP split-handshake vulnerability that can affect firewalls and other networking and security devices. Many of the media’s articles characterize this complicated TCP connection attack as, “a hacker exploit that lets an attacker trick a firewall and get into an internal network as a trusted IP connection” or as a “hole” in firewalls. I’m not sure that these descriptions properly characterize this vulnerability, and I suspect many administrators may not really understand how this attack works (let alone what it does and doesn’t allow an attacker to accomplish). I hope to try and rectify that in this post.
Before I jump into a description of this attack, WatchGuard XTM owners probably want to know if they are vulnerable to this attack. The answers is, No. Our XTM appliances do not allow TCP split-handshake connections. Furthermore, we also enable a feature called TCP SYN checking by default on our devices, which further protects against TCP state-based attacks. Later in this post, I’ll go into more detail on how we tested this, but for now, know that our appliances are not susceptible to this attack. With that out of the way, let’s look at this attack.
What is the TCP Split-Handshake Attack?
To understand the TCP split-handshake attack you need to understand how network devices build TCP connections. I’m going to assume you are familiar with the TCP three-way handshake. If not, this guide will walk you through it. Most network administrator understand this three-way handshake technique quite well, and many gateway security devices (like stateful firewalls) are designed to enforce it. However, less people know about another legitimate way to build TCP connections, called the simultaneous-open handshake. With a simultaneous open connection, both a client and server send a SYN packet to each other at about the same time. Then both sides also send ACK packets to each other in response. This slightly different variant of the TCP handshake doesn’t happen much in the real world, however, it’s a perfectly legitimate way to start a TCP connection (according to RFC 793).
This brings us to the TCP split-handshake (also sometimes called a Sneak ACK attack). As the name suggests, the split-handshake combines aspects of the normal three-way handshake with the simultaneous-open handshake. Essentially, a client sends a SYN packet to a server, intending to complete a normal three-way handshake. However, rather than completing the client’s three-way handshake, a malicious server starts by replying as though it were doing a simultaneous-open connection, and then starts its own three-way handshake in the other direction -- from server to client. So in essence, even though the client started the connection to the server, the logical direction of this connection gets reversed.
This is a fairly quick and high-level description of this attack. If you are a technically oriented person that wants to know the nitty-gritty details, I highly recommend you read, The TCP Split Handshake: Practical Effects on Modern Network Equipment. It is the defacto document describing this attack. If you just want the highlights, I also recommend this article. It characterizes the attack well, without diving too deep into the technical detail.
So What Can an Attacker Accomplish with this Attack?
OK. At a high-level, you now know that the TCP split-handshake attack is a sneaky way that a malicious server can reverse the logical direction of a connection that a client initiates. But what exactly does that mean? What can an attacker do with that, and how bad is it?
First, you should know that this attack cannot punch holes in your firewall, willy-nilly, without user interaction. A key mitigating factor to the attack is that a client within your network must first make a connection to a malicious server on the internet, before this attack can even start. Some of the descriptions of the attack, which claim an external attacker can trick a firewall into giving them access as a trusted IP, seem to leave this fact out. So if you were worried that external attackers can just hop through your firewall on their own, don’t be.
Furthermore, when this attack succeeds, the attacker isn’t even getting free reign on the victim computer or your network either, instead the attacker has only reversed the logical direction of your client’s initial connection. This could be bad, as I will explain in a second, but it is not immediate full access to the victim computer or your network.
What this attack really comes down to is an IPS (or other security content-filtering) evasion attack. The key issue is this attack logically reverses the direction of a perfectly legitimate connection your client initiated. This doesn’t really mean the attacker can do anything new on the victim computer, but it may confuse gateway security scanning services that protect your client. Many security systems, like IPS, antivirus (AV), and other content-filtering systems rely on the direction of traffic to decide how to scan it, or even if they will scan it. If an attacker can confuse the gateway devices as to the direction of traffic, it may be able to evade security scanning or IPS policies.
Let’s look at a real world example. Say an unpatched client in your network connects to a malicious drive-by download web server that is not leveraging the split-handshake attack. The malicious web site tries to get your client to execute some javascript that forces your client to download malware. If you have gateway IPS and AV, your IPS may detect the malicious javascript, or your AV may catch the malware. In either case, your security scanning would block the attack.
However, if the malicious web server adds the TCP split-handshake connection to the same attack, your IPS and AV systems may be confused by the direction of the traffic, and not scan the web server’s content. Now the malicious drive-by download would succeed, despite your gateway security protection.
So to summarize, the TCP split-handshake attack may help malicious servers to bypass security scanning services on your gateway security devices. However, it will not allow external attackers to bypass your firewall policies, and it requires an internal client start the connection in the first place.
Is My X-brand Network Device at Risk?
Now you know the true impact of TCP split-handshake attacks. They don’t allow attackers to totally bypass firewalls without user interaction, but they could help attackers evade your security services, assuming your clients connect to them. The next question is, are my network devices vulnerable?
To help you answer that question, I’m going to share how I tested WatchGuard’s XTM appliances.
The authors of the paper I mentioned earlier (The TCP Split Handshake: Practical Effects on Modern Network Equipment) included a special Ruby script in their paper called fakestack.rb. This script sets up a server on port 8080, that listens for incoming connections, and replies to those connection using the TCP split-handshake connection method. If this malicious connection succeeds, the script reports, “The handshake’s a LIE!” You can use this script to test your network equipment, and see whether or not it allows TCP split-handshake connections to complete.
I recommend you use fakestack.rb with a Linux computer. I used my Backtrack 4 installation. Fakestack.rb requires another ruby script called PacketFu, which in turn requires something called PcapRub. The whitepaper above explains these dependencies. Once your have all this installed, you simply have to disable your computer’s local host firewall (on 8080 at least), and run fakestack.rb (sudo fakestack.rb eth0 8080).
Once you have fakestack running, I recommend you first get a client to connect to it directly, without any firewall or gateway device in the mix. This way you can see what happens when the split-handshake connection succeeds. Open a web browser (IE or Firefox) on a Windows computer that is on the same network, and try to connect to the IP of the computer running fakestack, on port 8080 (http://x.x.x.x:8080). You will not see anything in the web browser. However, if you look at fakestack’s output, you will see it generating packets, sending certain replies, and if the attack works, it returns that “handshake’s a lie” message.
Once you have fakestack working, testing your own network gear is simple. Simply put the fakestack computer on the external side of your firewall, IPS, or security appliance, and get an internal client to try to connect to fakestack. If fakestack returns the handshake is a lie message, then you know your security gear may be vulnerable to this attack. However, if you don’t get the handshake is a lie message, fakestack wasn’t able to complete the split-handshake connection, and your device must be doing something to prevent it.
This is the test I did with our XTM appliances. When a client behind an XTM appliance tries to connect to fakestack, the connection never completes. Meanwhile, the XTM logs report:
2011-04-15 19:18:37 Deny 192.168.39.204 192.168.39.38 63316/tcp 8080 63316 0-External Firebox tcp syn checking failed 40 31 (Internal Policy) proc_id=”firewall” rc=”101″ tcp_info=”offset 5 A 1845100933 win 64″
2011-04-15 19:18:37 Deny 192.168.39.204 192.168.39.38 63316/tcp 8080 63316 0-External Firebox Denied 44 31 (Unhandled External Packet-00) proc_id=”firewall” rc=”101″ tcp_info=”offset 6 S 794513233 win 64″
Our packet handling engine does not recognize split-handshake connections as legitimate connections. Furthermore, split-handshakes trigger our TCP syn checking feature too, which is enabled by default.
This test shows that WatchGuard devices don’t allow split-handshake connections. You can use the same test to figure out whether or not your other network security devices handle TCP split-handshake connections properly.
Summary
So in summary:
- The TCP split handshake attack is not an attack that allows attackers to punch holes in firewalls without user interaction. However, it is a significant vulnerability that could allow attackers to evade security services like IPS, assuming the attacker can entice the victim to a malicious server.
- WatchGuard XTM appliances are not vulnerable to the TCP split-handshake attack, since we do not allow split-handshake connections. We tested this using a script designed by the discovers of the attack, called fakestack.rb.
- If you want to know how your other network gear responds to TCP split-handshake connections, use fakestack.rb to test.
I hope this post helped clear up some potential misinterpretations about this complex vulnerability, and has shown you its true severity and impact. Feel free to share your thoughts and ideas about this flaw in the comments section. I find it quite interesting and would love to discuss it.
Posted by Corey Nachreiner on Apr 19, 2011 at 11:46 AM0 comments