SmartAdvice: Best Practices For Using SAP In Multilingual Settings

Analyze your busines processes before selecting code pages when using SAP in a multilingual environment, <B>The Advisory Council</B> says. Also, don't count on a Windows NT Workstation security patch support extension; and there are two basic options when selecting an E-mail encryption technology for your sensitive mail.

InformationWeek Staff, Contributor

April 7, 2004

3 Min Read
InformationWeek logo in a gray background | InformationWeek

Question C: What methods do you recommend for securing E-mail sent over the Internet?

Our advice: There are many good reasons for implementing an E-mail encryption policy for your sensitive mail. It builds trust with your suppliers and clients while providing added protection for your company's intellectual property and confidential information. By implementing and enforcing a transparent E-mail encryption policy, you're sending a message to your staff that E-mail is an important form of communication with your partners, customers, and suppliers.

Fortunately, E-mail encryption and security methods in various forms are stable and long-established technology. Although there are other systems, when all is said and done, there are two standard but incompatible systems currently available. Your choices are S/MIME or PGP, both mature, proven applications with many well-documented installations worldwide.

PGP (Pretty Good Privacy), originally developed by Phil Zimmermann in 1991, quickly gained a reputation as a solid E-mail encryption utility because of its ease of use and free availability. S/MIME (Secure Multipurpose Internet Mail Extensions) was developed by RSA Security Inc. starting in 1995, and backed by a consortium of major E-mail vendors. Most E-mail client software, including free clients such as Microsoft Outlook Express (but not AOL or browser-based E-mail services like Hotmail or Yahoo mail), support S/MIME.

Whatever system you choose, the main drawback to securing all mail is that the encryption process itself adds significantly to both the size of the E-mail file and the CPU power it takes to encrypt and decrypt the message. One common alternative is to encrypt just the signature rather than the entire body of the E-mail. That uses fewer resources, and assures the recipient that the mail is actually from you, but it doesn't protect the confidentiality of the message.

When implementing, consider:

  • Follow industry best commercial practices for normal communications;



  • Use commercial-grade encryption (DES/AES) for "sensitive" information;



  • Choose either S/MIME or PGP as your E-mail encryption standard--they are not interchangeable; and



  • Base your encryption standard on your customers' and clients' policies for compatibility.

Since the technical mechanisms are well understood, the decision to implement an encryption E-mail policy is more driven by your business requirements and the systems that are common to your industry.

-- Beth Cohen

Anurag Gupta, TAC Expert, is a principal software architect with Intel. He has 11 years experience in performance, architecture, and enterprise technologies.

Peter Schay, TAC executive VP and chief operating officer, has 30 years of experience as a senior IT executive in IT vendor and research industries. He was most recently VP and chief technology officer of SiteShell Corp. Previously at Gartner, he was group VP of global research infrastructure and support, and launched coverage of client/server computing in the early 1990s.

Beth Cohen, TAC Thought Leader, has more than 20 years of experience building strong IT delivery organizations from user and vendor perspectives. Having worked as a technologist for BBN, the company that literally invented the Internet, she not only knows where technology is today but where it's heading in the future.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights