Posts from ‘Cybercrime’
Ipswitch Conversations at RSA Conference
There is so much to absorb at RSA Conference. The largest gathering of security vendors, solution providers and practitioners in the U.S. certainly didn’t disappoint as the Moscone Center was buzzing with security education and of course lots of thought provoking conversations.
Many of the people I spoke with shared similar concerns of data breach risk, tighter compliance and auditing requirements, and their lack of visibility and control over the tools that people are using inside their organization to share files and data with other people. IT leaders are feeling
pressure (and rightfully so) to regain control over how people share files with other people. It was also great hear so many people talking about migrating to the public and private clouds in order to take advantage of benefits such as quick provisioning and elasticity.
My favorite conversations at conferences are usually the ones I have with current customers…. And RSA was no exception. Quite frankly, the key insights I learn from talking with customers help me do my job better. Many thanks to the dozen or so Ipswitch customers that stopped by our booth and shared stories of how they have successfully consolidated and replaced the various homegrown file transfer tools and scripts, various vendor products, and manual processes they had been relying on with an Ipswitch MFT solution, resulting in improved efficiencies in their business processes as well as a simplified way to demonstrate compliance and consistently enforce security policies for all their file transfer and file sharing activities.
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.
Hey SEC, it’s Frank Kenney at Ipswitch. I don’t mean to rock the boat but I had a few quick questions regarding your recent announcement that you are requiring companies to notify their customers of a breach or risk of breach.
- What’s a “breach”? Does it mean the bad guys came in and took the data? Or maybe the data was left unencrypted? Or perhaps an executive lost his or her BlackBerry? Wikipedia talks about breaches of confidence, breaches of contract and breaches of faith. Is it all or none of the above?
- What does “notify” mean? Email? Snail mail? SMS? Press release? Facebook status update? Tweet? We just don’t know. And when do they need to send that out? When it happens (or it happened?) When it was discovered? When it was fixed? This is key and I say this because the breaches that happened were reported months after they actually happened. So when?
- And by “customers”, do you mean people who pay for my services? What if my services are free like social networks? Does free = exempt? What if I give you my email and contact info, does that make me a customer?
- What in the world is “risk of breach” and why shouldn’t I just fix it instead of telling my customers?
If you don’t mind I’d like to give the public in general my 2 cents…
The real story is this: we should all take these breaches seriously because at some point they will impact us individually. We must make it crystal clear to our service providers, our Internet providers and in some cases our employers that there needs to be policies and enforcement around the proper use and retention of our private information. We must also make clear that these same providers must put processes in place to better communicate and resolve any future data breaches. In much the same way we now see consumers making purchase decisions based on the carbon footprint of their suppliers/providers, the same approach will be taken when it comes to private confidential information. We at Ipswitch believe putting a secure managed file transfer solution in place will allow these suppliers to stem breaches by giving them visibility into how data is being accessed and for what purpose BEFORE these breaches happen.
Word has quickly spread that a serious weakness has been discovered in the Secure Sockets Layer (SSL) protocol that allows attackers to silently decrypt data that’s passing between a web server and an end-user browser.
All reports indicate that this vulnerability affects the SSL protocol itself and is
not specific to any operating system, browser or software/hardware product. This is an information disclosure vulnerability that allows the decryption of encrypted SSL 3.0 and TLS 1.0 traffic. It primarily impacts HTTPS web traffic, since the browser is the primary attack method.
SSL and TLS are two of the industry standard technologies that Ipswitch File Transfer solutions use to encrypt data while in-transit. Additional technologies such as AES transport encryption, PGP file encryption, and the encrypted FTPS and SFTP protocols are also used to secure data. As always, we recommend a defense-in-depth approach for protecting sensitive data.
At this point the vulnerability is not considered a high risk. Ipswitch is closely monitoring the situation closely and will implement recommendations and provide updates if this turns into a serious threat. We agree with Microsoft’s recommendation to prioritize the RC4 cipher suite and to enable TLS 1.1 in client and server. And given the choice, use the unaffected FTPS and SFTP protocols (and not HTTPS) until this vulnerability investigation is complete. Microsoft has also issued a fix fix that enables support for TLS 1.1 in Internet Explorer on Windows 7 and Windows 2008.


