I’ve always liked those Holiday Inn Express commercials with the theme of “Stay Smart.” The commercials portray an “expert” stepping in to save the day. In one, a “nuclear expert” takes charge of a reactor about to melt down. In another a “doctor” arrives to deliver a baby just in the nick of time. The tag line is funny because the so-called expert turns out not to be a nuclear scientist or a doctor, but just an average person who stayed at a Holiday Inn Express. That made them “smart.” Don’t worry; I’ll bring this discussion back to encryption momentarily.
Just last month, reports surfaced of broken encryption security for some Kingston, Verbatim, and SanDisk secure USB storage devices. Not all of the vendor’s devices were affected, but some of their most popular products were. All these products were NIST-certified, causing some industry commentators to erroneously question the certification process. Being a big believer in independent certification, I’d like to weigh in on this controversy and set the record straight.
As it turns out, the weakness, in these devices, was not in the actual AES encryption, but in the key management processes. All the affected vendors quickly released replacements or patches to fix the problem, which is the right thing to do. But it was fascinating to watch some of the responses to this problem. Many commentators complained that the FIPS-140 testing was faulty, or that FIPS-140 testing was irrelevant. The implication is that FIPS-140 does not really give you any assurance of security, and therefore, also by implication, that it is not important.
This is really the wrong conclusion. Let me talk a little about FIPS-140 certification and what is does mean.
First, FIPS-140 certification is not a guarantee of security. It is an assurance that encryption and related security algorithms have been implemented in compliance with published standards, that an application uses good practices in exposing it’s operational interfaces, that start up tests validate that the application has not been modified or corrupted, that cryptographic material is not exposed in application logs or leaked to memory, and that an independent expert has reviewed the source code. Going through a FIPS-140 certification is a grueling process for an encryption vendor and almost always results in finding some issues that need to be addressed to make the product more secure. Companies that engage in FIPS-140 certifications produce better products, and become better security designers in the process.
Is the FIPS-140 testing and certification process perfect? Of course not. That’s not a standard anyone can meet. In fact, NIST is working on a project right now to enhance the process. Believe me, the new certification process (probably to be named FIPS-140-3, for version 3) will not be weaker than the current process, it will be better.
The lesson from the encrypted USB problem is not that FIPS-140 certification is meaningless. It’s that doing encryption right is really difficult. If you want a secure USB storage device, you would NEVER consider using a product that was not FIPS-140 certified. We have plenty of experience of broken security on non-certified products. Problems with certified products are rare, but do happen. Usually you will find that a problem with a FIPS-140 certified product is with some aspect of the application that was out of scope for the certification. That’s the case for the encrypted USB devices that had problems.
To bring us back full circle, I just want to say that no responsible Enterprise should trust a non-certified USB device, anymore than you or I should trust a “doctor” to perform surgery because that “doctor” stayed at a Holiday Inn Express. The sad fact is that many large corporations today are putting their trust in encryption vendors who have not FIPS-140 certified their products. The management of these companies would never consider using a $100 secure USB device without certification, but do entrust the protection of huge amounts of sensitive data to non-certified vendors. In this age where too many try to pass themselves off as experts, it often takes an organization like NIST to certify the expertise behind something as important as encryption.
I’m proud of our NIST certifications – we will never back down from our commitment to provide you with the best security products and our commitment to independent certification. You can learn more about FIPS-140 certification on our web site, or directly from NIST at www.NIST.gov.
Patrick
As we near year’s end, I realize that the biggest change in data protection for 2009 has nothing to do with technology. Instead, it involves a shift in attitude.
The old attitude: “We have to put up all of the barriers to secure our data. We’ll throw on new intrusion detection, firewall, web filter, data loss prevention appliances, and put all-hands on deck to protect the perimeter!”
The new attitude: “Despite our best efforts, data gets out. We need to protect it from abuse.”
I think this new attitude reflects the reality that the threats to data security are ever more sophisticated, and the number of loss points has increased exponentially. The bad guys are amazingly successful at installing malware inside our networks and hiding their presence.
Cyber crooks don’t want to get noticed, they want to steal as much data as they can before we find them.
To make the situation more difficult, we are awash in new technologies that magnify the potential for loss. Social networks, instant messaging, smarter phones, SaaS, cloud computing, and on and on. There is just no way a self-respecting IT security organization can keep up with the pace of change. Innovation is fun, but it sure isn’t easy to secure.
Due to this challenge we are slowly coming to the realization that we have to encrypt sensitive data everywhere it lives and travels. This means encrypting data on laptops and other portable devices, on the wire as we transmit data on internal and external networks, on our backup tapes, and in our databases where we permanently store data. We’ve been slow coming to this realization because encryption is one of the harder technologies to deploy. It takes more work and more resources (hardware and human) to do it, and there is really no magic bullet we can shoot at the problem. So we are starting the hard slog to get encryption deployed on our systems.
I’m not suggesting that everyone unplug their firewalls, web filters and DLP appliances and deploy encryption. These solutions all have their place and are important in the security eco system. But we simply can’t be secure without encryption to protect the data. Now before you get fired up to tell me “encryption is not a panacea,” I’ll head those comments off by saying “I know that.” You have to do a lot of things to minimize the threat of data loss. (Please reread the first sentence of this paragraph). I’m just saying that we’re not going to mitigate that threat without encryption as a part of the plan.
The bad guys are really smart – we have to give them that. I fully expect that we will see attacks on encryption and key management solutions. In fact, we’ve already seen attacks on weak encryption and bad key management techniques. So I am not naïve about encryption being immune from these types of attack. But encryption done right provides a big barrier to jump over. I personally think that we have to make the leap and get busy implementing strong encryption of our sensitive data.
As you start to work on encryption projects, here are a few things to think about:
- Performance is really important. Be sure to test the performance of your encryption solution on a large set of data. Badly performing encryption is one of the hardest problems to fix.
- Cross platform compatibility is crucial. If you encrypt on one platform, you don’t want to have to decrypt data in order to transfer it to another platform. That just opens another door for loss. Be aware that not all AES encryption is done the same way.
- NIST certification is important. Regulations and best practices recommend independently certified encryption and key management solutions, so procuring certified solutions can help position you for the future. NIST certification also answers the question about cross platform compatibility.
I know encryption is not easy to implement. That’s why PTSS focuses on doing encryption right and easing your way into what should now be an integral part of your overall data security plan.
Patrick
Tokenization has become a hot topic lately as Enterprise customers attempt to minimize their exposure to the loss of sensitive data. Tokenization is an alternative to encryption and one-way hashes for data protection. But I think it is time to dispel some of the myths about tokenization, and discuss where this technology can be helpful in minimizing your risk.
First, tokenizing data does NOT let you bypass PCI compliance requirements. If you are a Level 1 merchant (and Level 2 at the end of 2010), you will still have to perform an annual PCI audit by a qualified QSA auditor. If you are a Level 3 or Level 4 merchant, you will still need to complete the self-assessment and meet the requirements of PCI. In some cases tokenization can help minimize the impact of PCI compliance, but in most cases it is not going to provide a significant benefit. This same is true for HIPAA and state privacy regulations.
If you are using payment-network-assigned tokens as replacements for credit card numbers, you are going to benefit by a reduction in the need to encrypt the account number and related cardholder information. In this case, when you send a payment authorization to the payment network, the response contains a token that you can store for later use. When you settle the authorization, or when you make future authorizations for recurring payments, the token will be used instead of the original credit card number. You never store the original credit card number in your database. That reduces the work you need to do to protect sensitive information, but does not get you out of PCI compliance. Only a small number of payment networks now support tokenization, so it is unlikely this is going to help you in the near term.
If you create the token on your local server, you will probably get very little relief from PCI, HIPAA, and other privacy regulations. If the token allows recovery of the original data, you have all of the normal obligations to protect the data. And, your risk may actually increase if you store the tokens for multiple applications in the same database, or if you store those tokens on the same server as the production data. For example, let’s say you store credit card numbers in the token database along with employee social security numbers, and customer account numbers for electronic funds transfer. If you have a compromise of the token database, you now have an exposure to multiple compliance regulations. Unauthorized access to the token database means you have to assume you’ve lost sensitive data for several applications.
There is one area where tokenization can provide an immediate and significant benefit – minimizing exposure in test, QA, and user acceptance environments. Many companies use multiple test and QA environments as they migrate system changes into production. To do this, you need realistic data in your test and QA databases. It is common to take snapshots of production data and use this for testing. However, this practice exposes sensitive data to a much larger group of people. Using tokenization, to replace sensitive data with bogus data, greatly reduces the risk of exposure.
The main problem I see with tokenization is that it lacks a proper definition by any standards group. It was heartening to see Visa issue some guidelines on best practices for encryption and tokenization just this month. While these are not yet formal standards, they do represent a good framework at which to look at tokenization. I was satisfied to see that our products match up with these best practices.
As many of you already know, we are just now releasing version 2 of our tokenization support. It provides an implementation of tokenization that will help you protect test and QA environments, allows separation of tokens from the production database, provides a common token database for Windows, Linux, UNIX, and System i applications, and meets proper standards for encryption and token creation. And of course it matches the Visa Best Practices guidelines for creating tokens so that you are prepared for future developments in this regulatory environment.
I hope this helps you cut through the haze of bogus information floating around about tokenization. As always, if you need more information about encryption, tokenization, or data security, you can get answers on our website or contact me directly.
Patrick
In the last few months we’ve seen a lot of discussion about data loss due to deliberate insider threats. Despite some very visible cases of infiltration by malicious insiders, recently IDC published a research report showing that more than half (52 percent) of insider data losses are accidental. This report challenges us to think differently about how to protect our sensitive data.
Just to keep things in perspective, protecting sensitive data is important to the survival of our businesses. It’s been estimated that data breaches can result in about an 8 percent loss in business and customers, combined with the cost of about $200 per record in remediation and legal costs. In today’s economy that is a hit no business can afford. So how do we protect against accidental data loss?
Most of us are putting our attention toward protecting our data from malicious attacks. We are deploying Data Loss Protection (DLP) products, doing better background checks, and deploying ever more sophisticated firewalls and intrusion detection systems (IDS). This study would indicate that we should look much more carefully at the routine activities of our employees and contractors.
The IDC study indicated that negligence, unintentional malware exposure from web browsing, and excessive privileges accounted for the top three accidental insider data losses. And it is not just full time employees who are responsible – contractors, temporary employees, and out-sourcing agencies are also big contributors to the problem. Good people inadvertently do bad things. But regardless of the intent, the impact on the company is the same. As cartoon character Pogo once said “We have met the enemy and he is us.”
How can we protect from this threat?
The IDC study concludes that there is no single technology that can mitigate this threat. We need to use a combination of encryption, monitoring, data loss protection, and education to minimize the potential for loss. A big part of the change is one of attitude – we need to realize that our trusted employees can and simply do make mistakes.
This propensity for error makes it all the more important to protect information in our core database systems. That’s why we were one of the first companies to incorporate access controls and system logging inside our encryption products. From the beginning, we felt it was important to limit who could and could not decrypt sensitive information, and to be able to track that activity.
As long as humans are part of the equation, we have to take encryption of data at rest and in motion very seriously. We can’t yet stop accidents from happening, but using strong encryption and proper key management can ensure that when accidents do occur, they aren’t fatal to your Enterprise.
Just last week a group of cryptographers announced a practical attack on some versions of 256-bit AES encryption. This announcement initially created quite a stir in the cryptography community, before reality set in and the scope of the vulnerability was defined. The attack is quite sophisticated and represents a major step toward breaking AES. While you might think that 256-bit AES encryption is the strongest encryption you can deploy because it has the largest key, in fact, key size is only one aspect of the strength and reliability of encryption. And in this case a weakness in key handling at the 256-bit level exposed a weakness in some, but not all, versions of AES encryption.
At this point you are probably asking yourself – am I at risk?
The answer is – that depends. Is your encryption solution NIST certified as Patrick Townsend Security Solutions are, or is it an open source or proprietary solution that some programmer hacked together on their own?
The recent attack that everyone’s talking about used 256-bit AES encryption that implements 10 or less rounds (repetitive processing that transforms the input using the encryption key) during the encryption process, combined with a set of related encryption keys and known plaintext values. The good news is that NIST defines the minimum number of rounds for standard 256-bit AES encryption at 14. There is no known practical attack on 256-bit AES encryption that implements 14 rounds.
If you are using a NIST-certified AES encryption solution you can now relax (our Alliance AES encryption solutions are NIST certified on all platforms).
If you are NOT using a NIST certified solution, or if you don’t know if your solution is NIST certified, you have some work to do. First, rather than ask your vendor if they are NIST certified, you can determine if your vendor has completed NIST certification by looking at the NIST AES Validation list. A NIST AES validation is specific to the operating system and hardware platform. Be sure you find a match with your implementation. If your vendor is not on the list it’s time to pick up the phone, call your encryption vendor, and ask some questions:
• Does your implementation use 256-bit AES encryption?
• How many rounds are used, and can the number of rounds be independently verified ?
• Where did you get your implementation of AES? Which Open Source version did the developer start with?
• Is the solution NIST compliant? Can the vendor prove it? If it is not NIST certified, why not? Do they have a plan to get their solution certified?
• Can the vendor replicate the published NIST encryption results to validate that the code is working correctly?
You should get some clear answers to these questions. If your vendor experiences one of those “deer in the headlights” moments, or if the answers are not clear and simple, you may have a vulnerable version of an encryption solution on your hands. Your vendor might say something like “Well, it’s an implementation of Rijndael, so it’s Okay”. This is why independent laboratory certification from NIST is important. Some older versions of Rijndael used a smaller number of rounds, and less talented encryption programmers may not even understand what the difference is.
NIST certification is not an absolute guarantee that a security vendor has done encryption right. Nor is it a guarantee that there won’t eventually be a weakness in the encryption algorithm. But NIST does represent the very best in encryption standards and guarantees that your vendor has had some independent review of its encryption solution. Doing encryption right is important not only to guarantee that your solution is less vulnerable to attack, but also to give you the peace of mind that your data can be decrypted by you when you need it.
While this published attack on 256-bit AES will probably not pose a significant risk to your encryption strategy, it will serve as a wake-up call to many organizations that it is time to get serious about encryption vendors. Any serious vendor of encryption will take the minimum step of completing NIST certification. We all think it is a good idea for teenagers to have a driver’s license, security vendors should get NIST certified, too.
Bruce Schneier has a really good description of the attack and it is well worth reading. I really like Bruce’s view on security in general. He writes well on a wide variety of security topics and brings a nuanced view to the subject. You can sign up to get his email newsletter on his web site.
One last thought: the cryptographers who found this weakness were not up to anything bad. The study of encryption ciphers and the attempt to compromise them (called cryptanalysis) is an important part of keeping encryption secure. You REALLY should worry about using encryption that is home-grown, or out of the mainstream, because the only ones trying to find the weakness are the bad guys. And they are not going to tell you if and when they break your encryption. They are going to exploit it as much as possible and your business will suffer. Don’t wait for that to happen. Realize that the right time to take a good hard look at your encryption solution vendor is now.
As business use of the Internet was taking off in mid-1998 I began hearing this consistent message from IBM AS/400 users: “We need encryption to protect our data as it moves over the Internet.” I only needed to hear this a few times before I began looking at incorporating encryption options into our file transfer applications.
My research included talking to a handful of encryption vendors, before finding an application called “Pretty Good Privacy,” or PGP. The application was the work of Phil Zimmermann and a small cohort of fellow off-the-map developers. I researched Phil a bit before contacting him, and — uh oh — I found he had been in trouble with the US government back when encryption was considered a “munition.” So it was with a little hesitation that I decided to place a call to this “outlaw” programmer.
By this time, the controversy over Phil’s activities had died down, and many of the restrictions on encryption had been relaxed. I found it surprisingly easy to get his phone number, get Phil on the phone, and see what he thought about using PGP on large systems.
We had a good conversation about PGP and its prospects for becoming a commercial standard for data protection. Phil was very helpful and we discussed some of the technical issues in porting PGP to the AS/400. He encouraged me to take the leap into the PGP project, and gave me referrals to the development team in charge of the commercial version of PGP. That call and his encouragement were crucial to our efforts over the next 10 years to bring PGP encryption to large IBM platforms.
After some twists and turns, and a few months of laboring in the trenches, we released the first version of PGP for the AS/400. The port to the AS/400 turned out to be a really big challenge. The C compiler was in its infancy, and we struggled with its limitations. And the ASCII to EBCDIC conversions were a nightmare. But we got the product released in 1999. It was very popular and remains so today. We now have hundreds of customers using PGP to protect their data.
PGP is now the de facto standard for whole file encryption in eCommerce. It is deployed by banks, insurance companies, medical suppliers, payroll servicers, and a wide variety of other organizations. Almost every organization on planet Earth deploys PGP to protect sensitive data. Phil’s vision of PGP becoming a widely accepted method of protecting data has become a reality.
Of course, PGP has been through some changes over the years. New encryption algorithms have been added such as AES and Elliptic Curve Cryptography. The product found a new home at PGP Corporation, and has undergone steady development since then. We have a great relationship with the folks at PGP, and many of them have been working with the product from the first days.
PGP Corporation recently completed a FIPS-140 certification of the PGP technology, and this was an important step. As we watch the evolution of security standards, I believe that independent certification by NIST will be crucially important in the months and years ahead. I know from personal experience that certification is hard to do and demands a deep commitment on the part of an encryption vendor. But there is no substitute for the rigor and discipline that it requires.
Here at PTSS we continue to incorporate PGP into new solutions. It’s a rock-solid platform on which to build. I’m happy to continue working with PGP Corporation, and you’ll be hearing from us soon about some of our new developments that incorporate PGP encryption.
After all these years, I’m grateful for Phil’s words of encouragement back in 1998. And am reminded to never underestimate what a few encouraging words can do. Thanks Phil!
Most of us who work in data security have probably had this experience. You bump into a neighbor on your morning walk, or meet someone at a party and as soon as they find out what field you’re in, they pop the question: “Do you really think it is safe to buy stuff on the Internet?” There are variations on the question, of course. They might ask about on-line banking, using a credit or debit card at the store, using a bank ATM, or almost any other financial transaction. Fielding these questions is one of the unintended consequences of your career choice. But what you tell that near stranger says almost as much as what you don’t tell them.
I usually try to keep my answer short and say something like: “Large retailers are probably compliant with PCI regulations and they are likely to be more secure in relation to credit cards. Smaller retailers may not yet be in compliance with these regulations. However, your credit card issuer is going to protect you from losses due to fraud and theft. Debit card transactions are more secure end-to-end because of encryption, and your merchant likes debit cards because of the lower fees, but your bank may or may not be helpful in the event of a loss. You might have more personal risk when you use your debit card. If you do on-line banking, make sure there is two-level sign on, and make sure your bank will stand behind you in the event of a loss. My advice is to take the normal precautions when using your card, use a credit monitoring service, check your statements regularly, don’t use Internet cafes for payments or banking when you travel, and know your bank.”
The rest of my answer is mainly for industry insiders. For instance, I find it odd that merchants who are PCI compliant are reluctant to make this information public. I would certainly feel better making an on-line purchase if I saw a statement on the check-out page that said something like “We’ve passed a PCI audit with no compensating controls. We are committed to securing your personal information when you buy online from us.” Even with some obligatory fine print from the lawyers, this would signal a sincere effort to protect information. But you never see this type of statement on merchant web sites; even the ones that I know are PCI compliant and really diligent about security. I wonder why . . .
Similarly, I find the difference between debit cards and credit cards to be interesting. Debit cards have long had end-to-end encryption using public/private key encryption. When you swipe your debit card and punch in the PIN code, that PIN is encrypted all the way to the bank. The same isn’t true for credit cards, however, because credit card numbers are simply not encrypted as they flow over various networks. That information is susceptible to loss anywhere along the path from the retailer to the credit card processor. All parties seem to accept this risk simply as a normal cost of doing business, and the bad guys do occasionally breach those networks. So the bottom line is that even if a credit card transaction starts out secure, there are numerous weak points where information can be lost or stolen.
This takes us back to the original question, and my answer that’s more for those of us in data security than for my neighbor. “I think there has been major progress over the last three or four years in data protection, but we have a long way to go before payment transactions are really secure. There are so many ways to expose and lose information, and end-to-end encryption is the only way I know to truly protect it. My hat is off to those merchants and payment processors who are making that long slog to embed encryption at every point in the process. But until encryption is universal, none of our sensitive information will be truly secure.”
To learn more about encryption solutions for retail and other industries, click here.
I recently returned from the 2009 RSA conference in San Francisco, and found it a worthwhile venue for getting the true pulse of the industry. Despite the current economic difficulties it is clear that businesses are still concerned about security and are investing in data leak protection (DLP), intrusion detection, scanning, and system log management. Surprisingly, however, at this year’s show there were very few developments on the encryption front. And in a way, I consider this silence as significant as “the dog that didn’t bark” in a famous Sherlock Holmes story.
For those unfamiliar with “the dog that didn’t bark,” it refers to a Sherlock Holmes story in which a dog’s silence (a non-event) was a critical clue to solving the crime. Similarly, I find the industry’s near silence on encryption to be significant. You see, encryption (and related key management technologies) are necessary tools to fight data theft. Yet the industry has seen a reduction in the number of encryption and key management vendors through consolidation and acquisition. What this near silence signifies however, remains to be seen.
One development that is generating plenty of noise is that the bad guys are getting much better at what they do. The days when a break-in was mostly an opportunity for bragging rights is gone. The attacks now are much more sophisticated and are often well-hidden from security software. The intent is to steal sensitive information and to use it for identity theft and fraud. The result is that we continue to see on-going losses of sensitive information, and the threat is getting harder to detect and prevent.
I remain convinced that until encryption becomes woven into our business applications we will continue to suffer continued losses of sensitive data. I’m not naïve about encryption as the solution – encryption is not a panacea to the data theft problem. It is not sufficient in itself to protect data. But it is a necessary component of a data protection scheme. IDS, DLP, and logging will never provide adequate protection by themselves. Properly implemented encryption has to be a part of any data protection scheme.
On a personal note, I hope RSA returns to the Moscone Center for the next RSA in 2010. The South of Market Area in San Francisco is vibrant and has left its urban decay behind. Great restaurants and cafes are abundant in the area and this is an inviting part of a beautiful city. I’m sure we’ll be exhibiting again next year with some interesting news!
Patrick
Like many of us, your company is probably looking for ways to reduce costs and increase revenues during these tough economic times. For those of you using the IBM i platform, one way to achieve both of these goals is to deploy Web services and XML processing directly on your Power System. XML has rapidly become the de facto standard for data interchange between customers, vendors, and web-based services. It’s much easier to deploy than Electronic Data Interchange (EDI) which often requires expensive software, VAN contracts, and per-document fees. And as a bonus, XML provides built-in encryption to protect sensitive data and satisfy compliance rules.
When the opportunity arises and you need to deploy XML and web services, it’s crucial to integrate with your existing ERP and CRM applications and to get it up and running fast. There are a few critical factors you should look for in a good IBM i web services solution. A successful IBM i web services solution should:
• Be affordable to deploy
• Maximize your RPG and Cobol developer skills
• Solve the complex communications requirements of web services
• Use strong encryption to protect your sensitive data
Many of our customers are using the Alliance XML/400 product to meet the challenges of XML and web services. With a built-in XML-to-DB2 mapping application, secure web communications, and built-in encryption, there is no web service integration project too tough for Alliance XML/400. Here are some examples of recent successful customer projects:
• IBM i order management integration with web-based shopping cart for Weaver Popcorn.
• Lawson purchasing integration with IBM i ERP solution for Bed Bath & Beyond.
• IBM i customer loyalty program integration with RightNow CRM for Bass Pro.
• IBM i integration with Microsoft SharePoint servers for Williams-Sonoma and Pottery Barn.
These projects helped companies reduce costs, increase customer loyalty, and bring on new customers and new sources of revenues.
Alliance XML/400 has stood the test of time and has a rich set of capabilities. It handles the technology challenges that are tough for standard RPG and Cobol application developers. These include Proxy server negotiation, WebDAV file transfer, encryption, Base64 encoding, XML to DB2 translation, and HTTP and HTTPS client and server applications. All of this is available without a requirement for IBM Websphere, the Apache server, expensive hardware upgrades, or time-consuming API programming.
You can read more about Alliance XML/400 here.
I hope you’ll find that by knowing more about XML for System i you’ll be able to profit from the next business opportunity that comes your way.
It’s hard to believe that it’s been 10 years since we brought the first version of Pretty Good Privacy (PGP) to the IBM i platform (then known as the AS/400). I remember a conversation I had early on with Phil Zimmerman about the future of encryption and of PGP itself. At the time Phil was under investigation by the US government over the export of strong encryption. Those were the days when strong encryption was considered “munitions” and subject to export restrictions.
Phil was very upbeat about the future of PGP, despite the obvious challenges, and was confident that one day Enterprise environments would see the benefits of protecting all types of sensitive data. He encouraged me to pursue a commercial version of PGP and lent his support to the idea. We released the first version of PGP for the IBM i in early 1999.
PGP encryption is now in wide use across all types of industries to protect sensitive data. Healthcare organizations use it to protect patient data and medical claims. Retailers use it to protect credit card information and to send data to their banks to prevent check fraud. Banks and insurance companies use PGP to protect customer social security numbers and other private information. And companies across the spectrum use PGP to protect payroll information and bank transfers.
We are now starting to release the newest version of PGP – PGP Command Line 9 – in our Alliance All-Ways Secure product. PGP Command Line 9 has lots of new features including support for advanced encryption methods, integration with PGP Universal Key Server, more target platforms for Self-Decrypting Archives, and much more. Our existing All-Ways Secure customers can upgrade to PGP Command Line 9 for free.
Alliance All-Ways Secure gives you several methods for secure FTP transfer of your PGP encrypted files. You can use SSL FTP to achieve an encrypted transfer, or you can use SSH Secure FTP (sFTP). In either case you combine the security of PGP encryption with the encryption of the actual transfer. Both SSL FTP and Secure Shell sFTP come with full automation features.
Bottom line, you have many options for file encryption. But because we’re no longer living in the 1990s, NOT encrypting is no longer an option. A data loss can have a devastating impact on your company, and PGP encryption is proven technology to help prevent that loss.