Government Can Force You to Decrypt Your Data

Written by John P Mello Jr on January 31, 2012 – 4:00 pm -

Administrators confident about the safety of their data encrypted on company laptops should start squirming if a recent court decision passes muster in the United States.

The case involves a Colorado woman who has been ordered to open the encrypted drives on her laptop for federal investigators.

Unlike the cops on television shows and movies, who always seem to have a computer wizard on hand to decrypt a hard drive or crack a password, law enforcement authorities in Colorado, stymied by the encryption on a notebook in the possession of Romona Fricosu, simply went to a judge and asked him to order her to type in her password so they could see what was in the encrypted files.

In arguing against opening the files, Fricosu claimed doing so would violate her civil rights, in particular her Fifth Amendment rights against self-incrimination. Her reasoning was that the government, by forcing her to give up her password for decrypting the drive, were forcing her to incriminate herself if there were anything on the drive tying her to their criminal investigation of a mortgage scam. They believe Friscou is involved the scam that defrauded banks in the Colorado Springs area of some $900,000. Continue reading Government Can Force You to Decrypt Your Data

Subscribe to my RSS feed

Plugging Email Leaks Becoming Tougher Than Ever

Written by John P Mello Jr on December 16, 2011 – 4:00 pm -

There’s an appealing logic to the notion that as technologies focused on a problem improve, the problem will diminish. That’s not always the case, however, and it may not be so when it comes to plugging email leaks.

Technologies don’t develop in bubbles. While improvements in Data Loss Prevention (DLP) technology are advancing, so are other technologies, technologies and trends that can offset or undermine those improvements. Continue reading Plugging Email Leaks Becoming Tougher Than Ever

Subscribe to my RSS feed

Understanding Email Encryption (Part 2)

Written by Jeff Orloff on August 23, 2011 – 4:00 pm -

In Understanding Email Encryption Part 1 I covered not only why encrypting email is important, but also the two different types of email encryption: asymmetrical and symmetrical.

There was another section that briefly mentioned some of the barriers that impede buy-in from management when it comes to an encryption solution. But these were only touched upon.

Unfortunately when it comes to making a pitch for encryption, those who understand the need for it are an easy sell. Those who either don’t understand it or see the need for it often cite one or more of these stigmas that are attached to email encryption as reason to avoid it. Continue reading Understanding Email Encryption (Part 2)

Subscribe to my RSS feed

Understanding Email Encryption (Part 1)

Written by Jeff Orloff on August 9, 2011 – 5:32 pm -

Understanding email encryptionIt 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. Continue reading Understanding Email Encryption (Part 1)

Subscribe to my RSS feed

Misconceptions About Email Security

Written by Jeff Orloff on July 25, 2011 – 6:13 pm -

When you don’t understand something that your job requires you to know, the most logical thing to do is research the topic and learn as much as you can about it. For many people who find security as part of their job description, learning as you go is the only option available. Yet despite the fact that there is so much information readily available to us, misconceptions regarding email security still confuse many professionals tasked with maintaining the confidentiality, integrity and availability of email services. Continue reading Misconceptions About Email Security

Subscribe to my RSS feed

Tips for Better Email Security

Written by Jeff Orloff on June 27, 2011 – 6:34 pm -

Advanced persistent threats make email security a necessity

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. Continue reading Tips for Better Email Security

Subscribe to my RSS feed

Exchange Server RPC Encryption Requirements

Written by Mike Rede on November 9, 2010 – 4:42 pm -

In his article, “Outlook 2003 and RPC Client Access Array Encryption”, Tonino Bruno describes a situation he encountered while deploying Exchange Server 2010 into his environment.

The situation is related to one of the architectural changes that were made to Exchange server 2010. A new RPC Client Access service was introduced which changed how the clients access the server. Outlook MAPI mailbox connections were moved from the back end mailbox servers to the Client Access servers in the middle tier. This new service also changed the Outlook MAPI mailbox connections to be made from the domain controllers/global catalog servers to the Client Access servers in the middle tier in a similar manner. In previous versions Outlook clients made direct RPC connections to the mailbox server. Now, they go to the Client Access Servers. These changes are effected during the deployment of Exchange Server 2010 while creating a RPC Client Access Array.

Note that it is only Exchange 2010 CAS servers deployed prior to Service Pack 1, or upgraded to Service Pack 1, which have this RPC encryption requirement setting which creates an environment for the following problem to occur.

Continue reading Exchange Server RPC Encryption Requirements

Subscribe to my RSS feed

Troubleshooting SMTP/TLS with OpenSSL

Written by Ed Fisher on September 7, 2010 – 4:59 pm -

b10921Encrypting transmissions between servers using SMTP/TLS can protect email from prying eyes, but as with all transport layer encryption, it makes troubleshooting issues on the network much more difficult. With WireShark, or even running debug at the firewall, it is relatively easy to diagnose issues by simply observing the SMTP messages between mail servers to see if there are problems. When those messages are encrypted, your visibility into the network goes away, and you are left with event logs and other diagnostics. One of the more common problem areas you run into when using SMTP/TLS has to do with the certificates in use. Unfortunately, this also results in some of the most cryptic messages you’ve ever seen in event viewer, syslog, or /var/log/mail.d.

Fortunately, you can do some fairly low level troubleshooting of certificate issues with a little OpenSSL magic. If this sounds useful to use, please, read on.

Continue reading Troubleshooting SMTP/TLS with OpenSSL

Subscribe to my RSS feed

Tokens offer more than token resistance to crackers

Written by John P Mello Jr on February 19, 2010 – 4:54 pm -

With token architecture, tokens are substituted for sensitive information on the network.

With token architecture, tokens are substituted for sensitive information on the network.

Encryption has become increasingly important as a means of protecting sensitive information from poachers. As widely publicized data breaches have brought information security under closer scrutiny by governments and industry consumer protection agencies, encryption is no longer an option for many companies but a necessity.

While encryption offers a strong measure of protection for a company’s data, it also imposes additional burdens. For example, encrypted data takes up more space than unencrypted data. that means encrypted data bumps up the demands on a concern’s storage systems. In addition, broad use of encryption can, in some industries, increase the cost of compliance audits, as all systems using encryption must meet the standards of regulators both public and private.

One way to relieve the burden encryption places on organizations that’s gaining popularity is tokenization. Not only does this technology reduce the storage requirements created by encrypting data, but it improves security and curbs compliance costs. The fewer the places that sensitive data is stored in a system, the fewer the places subject to compliance audits.

Tokenization saves space by substituting tokens for encrypted information within a system. Typically when a piece of information is encrypted, it is returned to its original location–a record in a database, for example–in encrypted, or cybertext, form. With tokenization, after information is encrypted, it’s stored in a central location, typically a data vault, and a token representing that data is returned to the original location. That token, which takes up less space than its encrypted analog, can be used anywhere the original information would be used. So if the data is used in multiple locations, space is saved because encrypted forms of it need not be stored at those locations. What’s more, the encrypted data is stored at only one location making it easier to secure.

Continue reading Tokens offer more than token resistance to crackers

Subscribe to my RSS feed

Gmail and encryption

Written by Dan Blacharski on January 25, 2010 – 5:18 pm -

Gmail has always had an encryption option, but until this week, it has been turned off by default. Now IT people, who tend to be a bit paranoid (but in a good way), would have gone through the trouble to switch on the SSL encryption option, but most ordinary users would simply not be aware that it exists. And for that matter, all those paranoid IT people probably wouldn’t have even used Gmail to begin with.

Google announced last week that it would start encrypting all Gmail traffic. In a blog post, Google noted that they initially rolled out the option to always use https back in 2008. This allows email to be encrypted on the path between the user’s web browser and Google servers. However, when Google first enabled the option, it was off by default. Now, SSL will be used by default, with users gaining the option of selecting “Don’t always use https” from the Settings menu. Some may choose to not enable the extra security option for performance reasons, but in reality, the performance hit will be minor, especially for broadband users—and well worth the extra couple of milliseconds. The login page will still remain encrypted. Using encrypted email can stop several types of attacks, such as man-in-the-middle attacks where an attacker may be snooping email in a public WiFi spot. Using encryption also prevents attacks such as DNS poisoning attacks where a domain name record is hijacked and redirected.

Google decided to make the upgrade just hours after they revealed information about having been victimized by specialized attacks, including certain attacks on Chinese human rights activists’ accounts. Users are cautioned however, not to get lulled into a false sense of security, thinking that turning on Gmail’s encryption option is going to prevent all potential attacks—because it certainly won’t. The same anti-virus, anti-spam and anti-malware software installations should continue in full force, regardless of any added encryption.

With Google making the switch, the next big question is whether the other main free email services like Hotmail or Yahoo! Mail will follow suit; my guess is that they will.

Subscribe to my RSS feed