Posts from ‘MFT’
Over the last few weeks, we’ve been putting the final touches on our next generation of services that will be delivered via the cloud. As with any product or service release, there comes a fair amount of planning including ensuring that one has the best site into competitors, forecast and of course customers. We’ve worked closely with industry analysts, our end-users and prospects and our own internal resources to best understand how and where we should position our cloud services. In presentation after presentation and in conversation after conversation, we were presented market slides showing the enormous growth and opportunity within the overall software as a service (SaaS) markets. The natural reaction is to get excited about all the money we can make in this space; before we did, I issued a strong warning to our team:
“In very much the same way that software is analogous to infrastructure, software as a service is not analogous to infrastructure as a service. That includes integration as a service. The profile of the consumer of SaaS will more than likely expect that things like integration, interoperability, transformation and governance will be part of the service subscription.”
In a nutshell what I was saying was… do not look at forecasts for SaaS and assume that the opportunities for IaaS follow the same trends. If users create content by using services that are delivered via the cloud, they have a reasonable expectation that this content can be shared with other services delivered via the cloud (not necessarily by the same vendor). For example, creating content via salesforce.com and sharing that content with gooddata.com should be as simple as granting the necessary permissions. After all, my Facebook, Twitter and Google+ information is shared by clicking a few buttons. Make no mistake, integration and interoperability are nontrivial, but part of the expectation of using cloud services is that the consumer is shielded from these complexities. As more and more cloud service platforms and providers build in integration and governance technologies the need for a separate IaaS provider will likely diminish.
Don’t get me wrong, I still believe that there is a place for technologies such as managed file transfer and business-to-business integration and collaboration; I definitely believe that Ipswitch will play a significant role in the evolution of those markets. Expect the role of Ipswitch to be evolve as well; not only will we provide the best mechanisms for moving content of any size but we will also govern (or let you govern) that movement and the entire experience around it. This is the centerpiece of Ipswitch’s Cloud strategy.
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!
Email is the world’s collaborative tool and is the electronic ‘sending’ system of choice between people, both within and across organizations.
While the capabilities of transferring files via email hasn’t improved much in the past 10 years, the size and sensitivity of files has multiplied ten-fold.
Email usage is ungoverned at most organizations, meaning that employees can attach any file they have access to and send it to anyone in the world. For CIOs, it’s about more than just security – it’s also about visibility. If you can’t see the files flowing within and from your organization, you can’t protect them.
And how about employees, who are bound and determined to quickly transfer needed information (which may be confidential) with customers, co-workers and partners? For the majority of workers, not sending that file for security’s and visibility’s sake is not an option. Employees will choose ‘productivity’ over ‘security’ if they are given the choice.
Please do take some time to identify and evaluate the tools your employees use to share information with other people and ask yourself if it’s being done in a visible, secure and well managed way. You’ll likely want to rethink how people are really sharing information at your organization.
