Before the proliferation of the personal computer or the Internet, an invasion of privacy was typically viewed as something the government did. The worry then was having your phone tapped, having your mail read, or being followed. Today, every transaction we’re involved in is an opportunity for our privacy to be invaded. Whether it be using a discount card in a grocery store, purchasing a house, or buying software on the Internet, we risk having our information shared with people who might pass it on or use it in an undesired fashion. Every privacy infraction lowers customer trust and affects commerce in a negative manner. If you look at the current state of the financial markets, it’s due more to the lack of trust in companies to do the right thing than real business reasons.
Important
Most privacy threats are information disclosure threats. When performing threat analysis, you should look at all such threats as potential privacy violations.
Would you feel just as comfortable buying a new Porsche from a used car lot as from a Porsche dealership? You probably answered no to this question even though you have no real evidence that it would be a bad idea. It’s all about trust. Respecting customer privacy is a crucial ingredient in building trust. People will not feel comfortable purchasing your products and services or investing in your company unless they trust you. By developing a privacy strategy for your company, you can visibly show that you care about your customers’ privacy. The alternative is possibly having to respond to a privacy violation, unnecessarily losing customers, or having to pay out a lot of money due to litigation.
Many companies invade your privacy in order to make new customers. This invasion is often just annoying and causes no loss of money or long-term damage. Think about all of the spam mail that you get or the phone calls at dinner time. This type of contact can be placed into two categories: unsolicited contact from individuals or companies with which you have a relationship and the same from those with which you don’t have a relationship. In the case of the former, companies are taking advantage of their relationship with you to request other business. I’m sure you’ve received requests to buy insurance from your credit-card companies and frequent calls from cable and phone companies asking if you want to take advantage of a new special. In either case, it’s an annoyance and it makes you think less of the company, sometimes to the point of terminating your relationship with them or never starting one. Don’t drive away customers by engaging in these practices.
Malicious invasions of privacy occur when someone accesses your personal information to benefit from it through unethical or illegal means. Many companies make a business out of selling your contact information. Thousands of people have had their credit-card numbers stolen either for resale on a Web site or for use by the thief. Hopefully, your company is not directly involved in malicious invasions of privacy. You could, however, be encouraging it by not taking the necessary steps to protect your customer’s sensitive information.
Note
I once took advantage of a great deal on color printer cartridges being sold on the Internet and saved lots of money. The next week someone in Korea had made several purchases by using my credit-card number. I’ve never been to Korea.
Privacy legislation has been slow to realize itself in the United States. To make things more difficult, in the current global climate personal privacy is at odds with the need for national security. Several reports on privacy have been created by various government agencies, beginning with the paper, "Records, Computers and the Rights of Citizens," from the Department of Health Education and Welfare in July1973 (http://aspe.hhs.gov/datacncl/1973privacy/tocprefacemembers.htm). However, most of the reports created since the release of this paper had no real teeth when it came to litigation. In 1998, the Federal Trade Commission (FTC) came out with the Fair Information Practices (http://www.ftc.gov/reports/privacy3/fairinfo.htm), which was an attempt to take the core ideas from the various privacy papers and combine them into a single document that could be used for litigation when there was a concern about the improper handling of someone’s personally identifiable information (PII).
Personally identifiable information is any information that can be used to identify or locate someone. The obvious examples of PII are someone’s name or address. The less-obvious examples of PII are a PO Box number or license plate number. Even though these two values don’t directly identify someone or their location, they can be used to find the owners. In addition, an account ID and TCP/IP address can be considered PII if they can be correlated with PII. Special care should be taken to protect any PII that is being stored by your company or application.
In October of 1998, the European Union (EU) published the EU Directives on Data Protection, (http://www.cdt.org/privacy/eudirective/EU_Directive_.html), which covered how PII should be handled. This directive prevents EU countries from sharing PII with countries outside of the EU that do not have the appropriate privacy protections in place. This would have had a devastating impact on American companies doing business with companies in the EU. In absence of other legislation, the Department of Commerce came out with the Safe Harbor Principles in July of 2000. These principles were recognized by the European Commission to provide adequate protections. Companies in the U.S. that agreed to abide by these principles were permitted to do business with EU companies.
The Safe Harbor Principles (http://www.export.gov/safeharbor/) consist of seven tenets, which are used to govern how personal information should be handled by companies. Companies that build applications should understand how these tenets will apply to their collection of data or creation of applications that collect data. The following sections describe the seven tenets.
A user from whom you collect data should be clearly informed of how you plan to use his data. Each Web site that exists for your company should have a privacy statement written for it, and each page should point to it. There will be cases where some pages will collect data and you’ll want to place a custom privacy page for that site that will reflect how that data is used. For client-side applications, you should have a menu that can be used to display the privacy policy for the application. It should describe the disposition of any data that is stored for the application. You should also describe the contents of any data that is sent to a Web site and under which circumstances the data will be sent out.
The presentation of the privacy policy should be made during installation of the application or during the first-run experience. When building an application that enables users to collect information from their customers, be sure to include features that make it easy for them to present their privacy policy for their customers.
A user that enters data into your applications should have a way to set her privacy preferences before her data is collected or used. For example, she should be able to indicate whether you can contact her via e-mail or phone or if you can share her contact information with third parties. Also, you should add features to your application to permit users of the application to permit their customers enter their privacy preferences. For example, if you create a Customer Relationship Management application, add settings in each contact record to permit the storage of settings (such as how a customer can be contacted). See the "Building a Privacy Infrastructure" section later in this chapter for examples of how to do this.
Onward transfer is the sharing of someone’s personal information with third parties. The sharing of information with third parties should not happen without the permission of the owner of the information. The exception is when the third party is acting as your agent and complies with your privacy policies. Your applications should include a permission setting for sharing data with third parties.
Users should have access to their information in order to validate its accuracy and make changes where appropriate. Users should also have the right to remove any data you might be keeping on them when it is not needed for your business purposes. Access to the data must be provided in any easy and inexpensive manner. It doesn’t have to be direct access and might not be immediate, but changes to user data must be propagated to all data stores and partners that might hold copies of the data.
Ample precautions should be taken to protect a user’s data from improper access. Your application should contain security features that permit the protection of sensitive information. In addition, to mitigate abuses, it should contain auditing features to track access to the data by people who have permission to access the data.
The integrity of a user’s data should be maintained at all times. At the outset you should only collect information from a user that is necessary to fulfill your previously agreed upon purposes. A user’s information should be complete and current before it is used for any purpose. Ensure that your user’s personal information is guarded from inappropriate modifications and that the data is not changed unless the user has requested or provided authorization for the change. There may be some associated data that you may add to supplement the user’s data and that is okay.
When users need to address a privacy issue with your company, there should be a clear and conspicuous manner in which they can reach you. Providing an e-mail address or Web form, which is easily accessible from a Web site, is the most common means companies use to permit customers to communicate their complaints. Failing to provide this forces customers to seek other means, which could result in lost revenues.
One good way to encourage trust in your company is to participate in one of the online trust programs provided by an independent organization. By joining one of these programs, you give visitors to your Web site some recourse if they have issues with their privacy. Figure 22-1 shows some organizations that provide a certification program. These include BBBOnline (http://www.bbbonline.com), ESRB (http://www.esrb.org/wp_join.asp), and TRUSTe (http://www.truste.org/programs/pub_how_to_join.html).
Depending on the type of information you’re storing for customers, data handling falls under the purview of one of several pieces of privacy legislation. Table 22-1 outlines some of the U.S. Federal privacy laws.
Table 22-1. U.S. Federal Privacy Laws
|
Act |
Comments |
URL |
|---|---|---|
|
Computer Fraud and Abuse Act (CFAA) |
This act restricts the access to anyone’s computer or the modification of any data contained on their computer. This includes downloading data from someone’s computer without permission. | |
|
Gramm-Leach Bliley Act (GLBA) |
This act governs the handling of financial information. If you are storing financial information, you need to be familiar with this act. | |
|
Health Information Portability Accountability Act (HIPAA) |
This act governs the handling of medical information. If you’re storing health information, you need to be familiar with this act. | |
|
Children’s Online Privacy Protection Act (COPPA) |
This act governs the collection of information from children under 13 years of age. |
Obviously, this book covers a great deal in the area of security. Although security is a component of privacy, there is unique distinction between the two. Security’s purpose is to restrict access to sensitive information from people who shouldn’t have it. In the case of privacy, people who have legitimate access to data need to comply with users’ preferences when it comes to how that data is handled. To be more specific, good privacy means adhering to the Safe Harbor Principles. One case in which privacy and security can conflict is when you want to log information about a user or transaction to maintain security. Carefully consider whether the logs now contain information that should be governed by the privacy policy. If the logs do contain PII, you either need to eliminate that or be prepared to handle the logs as private information.
To ensure a successful privacy program at your company, you should assemble a team of people focused on privacy. The fact that you are building a privacy team and making an effort in this area will help to earn your customer’s trust. Your privacy team can benefit your company in the following ways:
By building a privacy strategy for your company
By creating a privacy training program
By creating a consistent message for the public
By responding to privacy issues against your company in an effective manner
By ensuring compliance with privacy statutes when
Building Web sites
Creating applications
Handling personal data
Depending on the size of your company, you might want to have a Chief Privacy Officer (CPO) and a privacy advocate in each major group. Your company should get involved in privacy conferences and join at least one privacy organization. The Council of Chief Privacy Officers (http://www.conference-board.org/search/dcouncil.cfm?councilsid=173) is one such organization that could benefit your company.
Figure 22-2 provides an example of how a privacy organization could be developed within a company. The CPO reports to a corporate executive and leads a team of people responsible for developing and executing on the corporate privacy strategy. Each major group in the company has a privacy advocate who works closely with the CPO to ensure that the privacy message is spread consistently across all groups in the company.
The CPO is the person who is ultimately responsible for the corporate privacy vision and execution strategy. The CPO should have executive sponsorship and the authority to enforce the company’s privacy policy across all groups. The CPO should be current on all privacy legislation that might impact your company and should at least monitor the evolution of privacy across the industry. In a company developing products and services, you don’t want to lag behind your competitors when it comes to building products that enable privacy protection. In this regard, the CPO should work with each development team so that they understand their responsibility in protecting data and so that appropriate reviews are completed before any product is released.
The privacy advocate plays a major role in disseminating the CPO’s privacy vision. He should also be prepared to formalize this vision into an action plan that is tailored for the team on which he works. In general, the privacy advocate will be responsible for the following types of tasks:
Training his team on the importance of privacy
Assisting with the creation of privacy statements
Assisting with the design of privacy features
Ensuring that privacy is part of each design specification sign-off
Heading the post-development privacy review for each component
Assisting in the resolution of any privacy issues that might involve the team
Whether you’re creating Web services or client-side applications, privacy should play an important part of your strategy for success. It will improve your customer’s confidence in your products and set you apart from the competition. When designing an application, look at your design from two perspectives. If you’re building an application that collects information from a user, be sure to adhere to the seven tenets of Safe Harbor (described earlier in this chapter). If you’re creating an application that enables others to collect data, have you added features to permit users of your application to store their customers’ privacy preferences? The remainder of this chapter will look at how to develop software with privacy in mind and give examples of privacy features that will add value to your applications.
As with security, you save time and money by focusing on privacy throughout the development process. The privacy advocate for the team should understand your process of developing software and be able to devise a plan to make sure that privacy fits into the process seamlessly. Figure 22-3 offers an example of a development process that includes privacy.
During the design phase, the privacy section of the design template should be reviewed to ensure that the important privacy design points have been covered. During the development phase, the privacy content, such as the privacy policy and any P3P (Platform for Privacy Preferences) content for your Web sites, should be created. (I explain P3P later in the chapter.) Also, the contents of all cookies, logs, and any data sent to the Internet from your application should be documented and a statement of how they are used should be created. During the test phase, testers should validate your privacy implementation and content; this should include working with the privacy advocate to review the wording of any documents you created. The review phase should include a privacy review of each component and should be attended by the privacy advocate. During intermediate releases such an alpha, beta, or Release Candidate, you might get feedback from customers, analysts, or the media on your privacy implementation. Feed this back into the design phase, and make the appropriate changes to your products.
The privacy specification template should be part of the overall feature design template used by your development teams. Use the privacy specification template to outline any privacy issues that exist with a feature and the plans to mitigate them. The more thorough you are flushing out privacy problems during this phase the more smoothly the review process will go at the end of the development cycle. This area of the feature specification should be reviewed before approval of the feature. Your privacy advocate should work with your design team to create a specification template that matches your development requirements. See the sidebar The Privacy Specification Template for an example.
The privacy review template is used to review the privacy aspects of a component, which may consist of several features. Here is where you ensure that possible privacy risks are mitigated. All privacy content and settings should be accounted for. The privacy advocate should drive this portion of the component review. Any action items that come out of this review should be resolved before release of the product. A full sample template can be found with the book’s sample files in the folder Secureco2Chapter22.
The privacy policy statement applies to Web sites and applications. Create one for each application or service you’re planning to deploy. Your corporate privacy group, which should include your legal and public relations departments, should review this policy during the review process of a product. The policy should be reviewed again for each successive release, including service packs. The privacy policy should address each of the seven tenets of the Safe Harbor Principles, where appropriate.
This is an important document, and a current copy should be kept with your corporate privacy group for tracking. The TRUSTe Web site (http://www.truste.org/bus/pub_resourceguide.html) describes how to create a privacy statement and shows examples. Microsoft’s privacy statement can be viewed at http://www.microsoft.com/info/privacy.htm.
The Platform for Privacy Preferences Project (P3P), http://www.w3.org/P3P, is a standard that was defined by the World Wide Web Consortium (W3C). It was developed to permit Web sites to define their privacy policy in a manner that can be easily consumed by individuals and applications. Why should this interest you? If you use Internet Explorer 6, you may have seen the small eye on the status bar with the do-not-enter icon, as shown in Figure 22-4. That’s evidence of P3P at work.
When the icon shows up, it indicates that the Web site does not comply with your privacy settings. Either its privacy policy conflicts with the one you setup in the browser or it does not have one at all. These sites will not be permitted to place cookies on your computer. Other browsers also have P3P features that provide warnings of out-of-compliance Web sites. Your Web sites should implement P3P such that a P3P warning is not displayed with the browser privacy setting set to Medium. Defining P3P for your Web site goes hand-in-hand with creating a privacy policy and is easy to implement. See the section on implementing P3P coming up.
When designing your application, you should be forever vigilant about respecting your customer’s privacy. Part of that respect will consist of making it easy for your customer to indicate her preferences. The other part will be thinking of clever ways to defend her preferences. Remember that most of the time the people infringing on users’ rights are people who have legitimate access to data. This section will investigate different ways to record and protect a user’s privacy preferences.
Hopefully you’ve read about the importance of implementing P3P for your Web site. First we’ll look at how P3P works, and then we’ll see how easy it is to implement. To see how the P3P feature works in Internet Explorer 6, go to any Web site by using the Internet Explorer 6 browser and select Privacy Report from the View menu. For Web sites that have not implemented a privacy policy by using P3P, you’ll get the display shown in Figure 22-5.
For Web sites that do have P3P implemented, you should see a display similar to that in Figure 22-6. You have to admit that having a Web site that shows this display is going to make your customers feel more comfortable. Having the TRUSTe icon is an added bonus that will add to your site’s credibility.
The first step to creating P3P content is to create the policy reference file. The reference file is used to point to the XML policy file for your site. It must be named P3P.xml and stored in the directory W3C below your Web site root. For example, Microsoft’s reference file can be found at http://www.microsoft.com/w3c/p3p.xml. Here’s an example of an XML reference file:
<META xmlns="http://www.w3.org/2000/12/p3pv1"> <POLICY-REFERENCES> <POLICY-REF about="Policy.xml"> <INCLUDE>*</INCLUDE> <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/> </POLICY-REF> </POLICY-REFERENCES> </META>
When Internet Explorer 6 is attempting to display a site’s privacy policy, it looks in the W3C directory of the Web site for the file P3P.xml and reads the POLICY-REF tag from the file to determine the location of the XML version of the site’s privacy policy file. This is the second file that you’re going to create. It represents a condensed version of your full privacy policy.
Below is a sample of an XML version of a privacy policy. The discuri attribute points to the full privacy policy for the Web site. It can be accessed from the Internet Explorer 6 display by the "here" link. The remainder of the fields in the file are parsed by Internet Explorer 6 and placed in the report window. The statement blocks at the bottom of the file represent the privacy statements for the Web site that describe how data is handled. This particular example has two policy statements. The first one indicates that standard Web log information along with the browser type are stored by the Web site. The data is kept for administrative and development purposes for the recipient’s use only and retained for stated purposes. Visit http://www.w3.org/P3P for a full description of the other fields.
<POLICY xmlns="http://www.w3.org/2000/12/p3pv1" discuri="policy.htm" opturi="http://msdn.microsoft.com/privacy"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">Microsoft</DATA> <DATA ref="#business.contact-info.postal.street">One Microsoft Way </DATA> <DATA ref="#business.contact-info.postal.city">Redmond</DATA> <DATA ref="#business.contact-info.postal.stateprov">WA</DATA> <DATA ref="#business.contact-info.postal.postalcode">78052</DATA> <DATA ref="#business.contact-info.postal.country">USA</DATA> <DATA ref="#business.contact-info.online.email">michael</DATA> <DATA ref="#business.contact-info.telecom.telephone.intcode">1 </DATA> <DATA ref="#business.contact-info.telecom.telephone.loccode">425 </DATA> <DATA ref="#business.contact-info.telecom.telephone.number"> 8828080</DATA> </DATA-GROUP> </ENTITY> <ACCESS><nonident/></ACCESS> <STATEMENT> <PURPOSE><admin/><develop/></PURPOSE> <RECIPIENT><ours/></RECIPIENT> <RETENTION><stated-purpose/></RETENTION> <DATA-GROUP> <DATA ref="#dynamic.clickstream.server"/> <DATA ref="#dynamic.http.useragent"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <PURPOSE><pseudo-analysis required="opt-in"/></PURPOSE> <RECIPIENT><other-recipient/></RECIPIENT> <RETENTION><indefinitely/></RETENTION> <DATA-GROUP> <DATA ref="#user.home-info.postal.postalcode"> <CATEGORIES><demographic/></CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY>
This file can be placed anywhere on your Web site as long as it expressed in the reference file. Once you have these two files in place, Internet Exlorer 6 will be able to display your policy in the report screen when users select View->Privacy Report. You will still want to create a full privacy policy for your Web site that describes your company’s privacy policy in detail. For assistance with creating a full privacy policy, visit the TRUSTe site at http://www.truste.org/bus/pub_resourceguide.html.
The final piece to the puzzle involves creating the compact policy. The compact policy is what Internet Explorer 6 uses to determine whether to display the privacy icon on the status bar. The compact policy is a condensed representation of the XML policy and uses codes defined in the P3P specification. You can read more about compact policy at http://www.w3.org/TR/P3P/#compact_policies. Figure 22-7 shows the compact policy for the XML page shown above. Once you have the compact policy in place, you will have fully implemented P3P. For a detailed description of how to implement and deploy P3P for your Web site, visit http://msdn.microsoft.com/workshop/security/privacy/overview/createprivacypolicy.asp.
Note
Internet Explorer 6 suppresses P3P verification for Intranet sites.
When building client-side applications that capture a user’s information, you should have a privacy statement that describes how the data will be handled and you should provide the user with settings to set her preferences. For example, you might collect registration information from the user or send data to a Web site to download background information for your application. You could configure your Help menu to assist the user in accessing privacy commands. If you provide a software development kit for your application for other software developers, a Privacy Policy menu option could point to a document referenced in the registry or, better yet, to your privacy policy on your Web site. A Privacy Settings menu option could call an interface in a DLL that could be implemented by the developer.
Figure 22-8 shows the privacy options dialog in the Microsoft Windows Media Player 9 beta, which is displayed to the user when the application first runs.
So far the examples have covered the case where your application collects personal information on behalf of your company. What if your application collects data users of your application obtain from their customers? Say you’re building a Customer Relationship Management application. The users of the application will probably collect contact information from their customers. How will they determine whether these customers want to receive e-mail? You could add a privacy settings dialog box to permit them to store their customers’ privacy preferences without having to create a separate database. Figure 22-9 shows a dialog box for collecting contact information. Figure 22-10 shows one for setting privacy options.
Many applications have features that keep track of files you’ve opened, Web pages you’ve visited, or media you’ve played. What if a user didn’t want that information tracked or wanted to be able to clear it when he wanted to? Adding such a feature could help your users sleep better at night.
Let’s make believe that the Detroit Lions are your favorite football team. This season the Lions are losing all their games, and after each game you go on a tirade around the house complaining about the loss. It gets so bad that your family has had enough and you are ordered to stay away from football. No TV, no Internet, and no conference calls with friends to commiserate. Later in the season you find out that the Lions are going to the Super Bowl! (I did mention that this was make-believe!) So late that night, after everyone’s asleep, you sneak down to the basement, go to the Lion’s Web site, download some streaming media of the last game, go to a chat room, and start celebrating with your online friends. Then you hear footsteps coming down the stairs and it’s your spouse. With a cover-your-tracks feature, you could easily press a button, close down all the applications, and bring up Solitaire without anyone knowing what you were doing.
If your application does record the last used files or sites visited, make sure that it does so on a per-user basis and that this information is stored either in HKCU or within the user’s profile.
Windows Media Player 7 caused some problems by sending information about music CDs and DVDs to a server at Microsoft. The idea was to retrieve the list of songs from a central database and help ensure a nice user experience. The problem comes when someone might be viewing a movie that they may not want others to know about. One obvious example is adult-oriented material, but another you may not have considered is material of military value. Some behaviors are just fine when you’re dealing with an ordinary home user, but if traffic is coming out of a military base, it could be another matter entirely. If your application is going to send any type of data back to servers controlled by your company, make sure that you notify the user, allow them to opt in or out, and allow the administrators to disable the behavior for all users on that system.
You are at a large conference and about to announce the latest version of your financial application. So far the industry pundits are raving about your new privacy features. Then an analyst asks one last question: "How do you prevent the application administrators from running off with the customer’s money?" In today’s climate, you better have a good answer. After putting the finishing touches on your privacy features, ask yourself again, "Now how can they get to the data?" When you feel the answer is, "They can’t," bring in an outside specialist, give him administrative privileges to the network and your application, and dare him to read a credit-card number. If this scares you, it might be because you’re using only security techniques and not privacy techniques. In this section, we’ll look at various ways to keep the good guys from gaining too much access.
Many users will have legitimate access to the data stored in your application, and that’s okay. When analyzing access requirements, start by making sure that only legitimate users can access your application or data. The network administrator should not necessarily be your application administrator. Then you’ll want to control the level of access that each user has. Just because a person needs to send e-mails to customers doesn’t mean that person should be able to see credit-card numbers. And if you do it right, credit-card numbers will never be visible to users. Think about being able to make the statement, "Your credit-card numbers are never visible to our employees!" We’ll get to that later. Now take a look at Figure 22-11; notice how access to an application can be progressively screened. Don’t give people an opportunity to betray your trust. Security should not just be about read, write, and delete access. When building an application, look at building workflows that can isolate sensitive information and transactions.
When users have access to sensitive information, they will be tempted to view it. One way to curb their temptation is to add auditing. When adding auditing to your application, ensure that it also tracks read accesses. The audit logs should be backed up frequently and should not be able to be deleted. Yes, this is hard. But imagine if you were selling the only application that offered this feature! It’s worthwhile notifying users that their actions are logged.
Damaging the reputation and trust of online commerce is the fact that hackers have been able to compromise servers and steal credit-card numbers or other valuable customer information. Rather than storing data in plaintext, you should encrypt sensitive data by using a good cryptographic algorithm, and a well-protected key.
Now that you have the data secure, you should also look at transferring the data securely. Look at the flow of data from its origin to its final destinations. Are all paths secured against information disclosure threats? We’ve covered various ways to secure communication traffic in this book; here I just want to remind you to include communication security as part of your end-to-end solutions.
You’ve got security in place: auditing is turned on, and the communications links and data storage are encrypted. What else do you need? How about encryption between partners and insurance that only the data that is necessary for the transaction is transferred? If a person’s social security number and birth date aren’t needed for transactions, don’t send them. If possible, don’t even collect the information. Work with partners that think the way that you do about privacy. Build solutions that use the minimum amount of information, and reveal it to as few people as possible.
Note
If your company works with untrustworthy partners, people will view your company as untrustworthy also.
In Figure 22-12, a user fills out a form to purchase something over the Internet and provides credit-card information. The client request is transferred over SSL/TLS to the Web server. The Web application encrypts the data and sends it to the database server optionally over IPSec. If the data is already encrypted, you may not need to encrypt the application-level payload. The application on the database server stores the encrypted data in the database. When the order needs to be filled, the credit-card information is sent to the processing center over EDI (Electronic Data Interchange) in encrypted form by using a key known to the company and the EDI center. The credit-card processing center is able to decrypt the packet and make the appropriate transfers. In this manner, no human being ever sees the credit-card number unencrypted. There is a small risk if you have a phone order center or if a customer needs to verify an order after placement. Strong auditing procedures can mitigate risks in these areas.
Letting customers control the collection, use, and distribution of their personal information builds customer trust. Privacy is a complex issue that is a moving target. As you design and build your product or service, protecting your customer’s privacy should be one of your highest priorities. Like security, privacy should be a design consideration that benefits not only customers but also partners as they build and distribute solutions using your software. Make sure you collect personal data from customers in compliance with current legal standards.