Posts from ‘Compliance’
Encryption: Transport versus File
This morning I was asked if I recommended using transport encryption or file encryption to protect company files and data.
My answer: “Use both of them, together!”
For starters, here’s a real quick summary of both encryption types:
- Transport encryption (“data-in-transit”) protects the file as it travels over protocols such as FTPS (SSL), SFTP (SSH) and HTTPS. Leading solutions use encryption strengths up to 256-bit.
- File encryption (“data-at-rest”) encrypts an individual file so that if it ever ended up in someone else’s possession, they couldn’t open it or see the contents. PGP is commonly used to encrypt files.
I believe that using both together provides a double-layer of protection. The transport protects the files as they are moving…. And the PGP protects the file itself, especially important after it’s been moved and is sitting on a server, laptop, USB drive, smartphone or anywhere else.
Here’s an analogy: Think of transport encryption as an armored truck that’s transporting money from say a retail store to a bank. 99.999% of the time that armored Brinks truck will securely transport your delivery without any incident. But adding a second layer of protection – say you put the money in a safe before putting it in the truck – reduces the chance of compromise exponentially, both during and after transport.
One last piece of advice: Ensure that your organization has stopped using the FTP protocol for transferring any type of confidential, private or sensitive information. Although it’s an amazing accomplishment that FTP is still functional after 40 years, please please please realize that FTP is does not provide any encryption or guaranteed delivery – not to mention that tactically deployed FTP servers scattered throughout your organization lack the visibility, management and enforcement capabilities that modern Managed File Transfer solutions deploy.
August 2011: Yale University announced that 43,000 social security numbers posted to an insecure FTP server have been available to Google search engine users for the past 10-months.
May 2011: Southern California Medical-Legal Consultants (SCMLC) disclosed that the medical records of 300,000 injured workers were available online to the public through Google search.
For Yale, it seems that the file containing the names and social security numbers was stored in a FTP server which was used for open source work – That means that ANYONE could access the information without even being asked for a username/password. Although IT Director Len Peters said “there is no indication that the information has been exploited”, that sounds to me an awful lot like “nobody has told us that their information was breached but we don’t have the visibility or audit trail to know for sure.”
For SCMLC, an internal server exposed documents containing health information (including names and social security numbers) of California residents who applied for workers’ compensation benefits. The files were neither encrypted nor password-protected. According to Joel Hecht, President of SCMLC, “We take data security and privacy very seriously, unfortunately, our internal security policies and procedures were not followed.” In theory he’s saying the right things and his company may (or may not) have the proper tools and systems in place, but the key here is they lacked the proper management and enforcement of access controls and security policies. Now there are a gazillion reasons wanting to keep health information confidential, and in this case that list would include workers compensation information being read by possible future employers and impacting hiring decisions.
Ipswitch’s Frank Kenney sums things up nicely in a recent article on the increasing security risks of web-searchable databases:
“In many cases organizations don’t know that they’re wide open. The databases that exist today have ultimately been designed to allow the easiest access from a multitude of devices and places. In many people’s minds they think that there is a measure of safety for the data sitting underneath the application because the application is secure. But your database is sitting out there and it came configured out of the box to be connected to the Internet.”
So take this opportunity to identify what Web-facing databases you have and really dig into the information they contain. If you are exposing any sensitive or confidential information, take measures to properly manage that data, control access to it, set up security policies and of course ensure visibility into all files being uploaded or downloaded from the server.
Definitely not. To begin with, there are numerous kinds of encryption—some of which can actually be broken quite easily. One of the earlier common forms of encryption (around 1996) relied on encryption keys that were 40 bits in length; surprisingly, many technologies and products continue to use this older, weaker form of encryption. Although there are nearly a trillion possible encryption keys using this form of encryption, relatively little computing power is needed to break the encryption—a modern home computer can do so in just a few days, and a powerful supercomputer can do so in a few minutes.
So all encryption is definitely not the same. That said, the field of cryptography has become incredibly complex and technical in the past few years, and it has become very difficult for business people and even information technology professionals to fully understand the various differences. There are different encryption algorithms—DES, AES, and so forth—as well as encryption keys of differing lengths. Rather than try to become a cryptographic expert, your business would do well to look at higher‐level performance standards.
One such standard comes under the US Federal Information Processing Standards. FIPS specifications are managed by the National Institute of Standards and Technology (NIST); FIPS 140‐2 is the standard that specifically applies to data encryption, and it is managed by NIST’s Computer Security Division. In fact, FIPS 140‐2 is accepted by both the US and Canadian governments, and is used by almost all US government agencies, including the National Security Agency (NSA), and by many foreign ones. Although not mandated for private commercial use, the general feeling in the industry is that “if it’s good enough for the paranoid folks at the NSA, it’s good enough for us too.”
FIPS 140‐2 specifies the encryption algorithms and key strengths that a cryptography package must support in order to become certified. The standard also specifies testing criteria, and FIPS 140‐2 certified products are those products that have passed the specified tests. Vendors of cryptography products can submit their products to the FIPS Cryptographic Module Validation Program (CMVP), which validates that the product meets the FIPS specification. The validation program is administered by NIST‐certified independent labs, which not only examine the source code of the product but also its design documents and related materials—before subjecting the product to a battery of confirmation tests.
In fact, there’s another facet—in addition to encryption algorithm and key strength—that further demonstrates how all encryption isn’t the same: back doors. Encryption is implemented by computer programs, and those programs are written by human beings— who sometimes can’t resist including an “Easter egg,” back door, or other surprise in the code. These additions can weaken the strength of security‐related code by making it easier to recover encryption keys, crack encryption, and so forth. Part of the CMVP process is an examination of the program source code to ensure that no such back doors exist in the code—further validating the strength and security of the encryption technology.
So the practical upshot is this: All encryption is not the same, and rather than become an expert on encryption, you should simply look for products that have earned FIPS 140‐2 certification. Doing so ensures that you’re getting the “best of breed” for modern cryptography practices, and that you’re avoiding back doors, Easter eggs, and other unwanted inclusions in the code.
You can go a bit further. Cryptographic modules are certified by FIPS 140‐2, but the encryption algorithms themselves can be certified by FIPS 197 (Advanced Encryption Standard), FIPS 180 (SHA‐1 and HMAC‐SHA‐1 algorithms). By selecting a product that utilizes certified cryptography, you’re assured of getting the most powerful, most secure encryption currently available.
- From The Tips and Tricks Guide to Managed File Transfer by Don Jones
To read more, check out the full eBook or stay tuned for more file transfer tips and tricks!
