Preventing Identity Theft Through Privacy Architecture


Contents

Introduction
Summary
Problem: The Impact of Identity Theft on the Enterprise
      Privacy Emerges as a Critical Issue
      In the Interest of Privacy
      Motivations of Identity Thieves
Solution: Creating the Privacy Architecture
      Establish a Privacy Policy
      Establish Business Controls and Processes
      Deploy the Technical Infrastructure
      Compliance and Incident Response
Conclusion
References




Introduction

Because of an increased awareness of identity theft, enterprise information security teams must now manage privacy in addition to firewalls, IDS, and antivirus systems. This paper addresses how to begin creating the enterprise privacy architecture.

Summary

Identity theft awareness is at an all-time high due to several very visible incidents in the United States. For the individual victims of identity theft, the repercussions are at best time-consuming and annoying, and at worst, they can be very damaging to one's personal financial history. In addition, another set of victims consisting of retailers and financial institutions have had to absorb millions of dollars due to fraudulent actions by the perpetrators of identity theft.

Many of the recent newsworthy identity theft incidents occurred because enterprises entrusted with the Personally Identifying Information (PII) of individuals did not adequately protect that information. Recent legislation compelling public disclosure of such incidents means that an enterprise's misstep with PII data can expose that organization to substantial financial losses, a loss of trust with customers, partners, employees and shareholders, significant amounts of bad press, and even criminal charges.

The crime of identity theft strikes directly at the trust and goodwill necessary for the success of the online economy. Customers who fear that their information will be stolen will be much less likely to engage in online commerce, electronic voting, or any other activity that requires sensitive personal information to be transmitted over a network.

Fortunately, actions can be taken to minimize the chances of your organization being the next big identity theft story on the evening news. This paper discusses the identity theft challenge and details recommended actions to help ensure that the PII entrusted to your organization stays secure.

Problem: The Impact of Identity Theft on the Enterprise

Privacy Emerges as a Critical Issue

Through the first half of 2005, identity theft emerged as a critical issue in the media. In the first six months of the year, up to 50 million individuals were estimated by the Privacy Rights Clearinghouse to have had their personal information put at risk due to theft or loss. While most of these individuals were in the United States, as a trans-national problem, national borders do not limit scope of identity theft. For example, out of the 40 million people recently put at risk through a breach of CardSystems, a credit card processor in the United States, 20,000 individuals were citizens of Singapore.

While the technical definition of PII may vary from one legal jurisdiction to the next, it is generally understood to include that information which is specific to an individual person that would be considered among the most sensitive information about that person. This may include the person's financial information such as their salary, information about their bank accounts, credit card numbers, or tax history, as well as other information such as their personal medical records, and common unique identification material such as a Social Security Number or other identifiers such as a driver's license or passport content.

The U.S. Federal Trade Commission received 246,000 reports in 2004 from individuals who reported that their personal information had been actively misused. That number appears to represent only the beginning, and some estimates put the number of actual fraud victims in the United States at 10 million. The number of victims outside the United States is generally unknown because most other countries do not collect statistics on such incidents. Regardless, identity theft is widely acknowledged to be a global problem. Damages from identity theft totaled US$5 billion for consumers, and an additional $48 billion to financial institutions and retailers. The damage brought by a high-profile incident may not just affect individuals, but may affect the ability for an enterprise to continue business operations entirely. In CardSystems' case, the security breach and subsequent security audits were enough to compel Visa and American Express to suspend operations with the company, which depends on these relationships to provide service to its customers. CardSystems has publicly stated that these actions may force the company out of business. In another recent example, a single PII breach at ChoicePoint, a broker in financial information, cost the company $11.4 Million through the first half of 2005.

Media reports have alerted individual consumers to the problem. Dozens of stories in major newspapers, magazines, and television have instilled a sense of insecurity in the public, and perhaps rightly so. Nobody likes the idea that their most personal information stored in an anonymous database that they neither know about nor control has been compromised, and when it happens, the work required by a victim is often substantial. The Identity Theft Resource Center has noted that each individual who is victimized by identity theft spends an average of 600 hours to clear his or her name.

While the numbers about identity theft vary greatly, nobody disputes that the problem is getting worse, and that identity theft is being increasingly used to facilitate traditional offline criminal activity.

In the Interest of Privacy

While reports of identity theft have been around in the media for some time, a rise in public disclosures of PII theft and loss have been largely driven by a law enacted in July 2003 by the State of California. The law, known as the Security Breach Information Act (SB 1386), requires that companies notify residents of California when there is a reasonable chance that their PII has been compromised or lost. The intent of the law was to define PII, specify how it was to be protected, and compel disclosure by companies who had lost control of that PII. Since most organizations do not store PII for California residents in a separate database from other individuals, companies have found as a matter of practicality that they need to notify all potential victims of a breach, and not just those who are residents of California. Because of this, individuals across the United States and the rest of the world have benefited from the California law.

Based on the impact of the law, the state of Washington has enacted its own PII breach disclosure law, known as SSB 6043, which went into effect on July 23, 2005. More than 30 states, the United States Congress, and the provincial government of Ontario, Canada are currently evaluating similar disclosure laws. Laws in other countries will likely follow.

In addition to SB 1386, other laws such as Health Insurance Portability and Accountability Act (HIPAA) in the United States and the European Union Privacy Directive may affect your organization. These various laws may specify how PII is to be collected, stored and transmitted. The increase in privacy laws also coincides with an increase in corporate governance regulation, exemplified by the Sarbanes-Oxley legislation. Many enterprises may find it useful, therefore, to integrate privacy efforts into the overall corporate governance effort.

To minimize the risks of your enterprise being the source of the next PII breach, it needs to address the problem from an architectural standpoint. Individual point solutions to try and protect PII data (such as establishing virtual private networks between routers in the corporate network) are likely to be insufficient, because the avenues for PII theft or loss are numerous. An organization's privacy architecture will have many aspects, not all of them technical in nature. In addition to an organization's information security team, other groups such as an organization's legal, audit, and public relations functions will likely need to be engaged.

Motivations of Identity Thieves

While the means of identity theft are numerous, from phishing (“fishing”) e-mails to dumpster diving for paper records, there are three primary reasons that one commits identity theft. Understanding the motivations and capabilities of identity thieves is crucial to implementing effective countermeasures.

The first and most obvious motivation for an identity thief is financial gain. By assuming someone else's financial identity, the attacker can realize substantial financial gain, whether by draining the bank account of the victim, or by using the victim's identity and resume to get a well-paying job. When most people think of identity theft, they are usually considering identity theft in the context of financial gain for the attacker.

Another motivation for identity theft is avoidance of prosecution. In this circumstance, the identity thief, who may already be engaged in other criminal activity, assumes the identity of the victim so that a history of arrests, convictions and other run-ins with law enforcement are deflected onto someone else. The victim is then suddenly burdened with the criminal history that was created by the attacker. The disassociation between the attacker's criminal activity and the history of that activity permits the attacker to continue criminal activity or to otherwise operate within society without having to disclose that activity (such as when renting an apartment, applying for a job, etc.).

The last motivation for the identity thief is the motive of revenge. In this case, the identity thief is actively seeking to harm the victim (which could be the individual whose information was stolen or the company where that information resided) by making day-to-day life uncomfortable or dangerous.

It appears that most identity thieves have relatively limited resources, but a few recent incidents have highlighted that organized criminals are starting to put substantial financial resources and time into identity theft (as observed by the U.S. Federal Trade Commission). The thieves who compromised ChoicePoint did so by creating several front companies at an estimated cost of US$12,000, and were able to use ChoicePoint data brokerage products over an estimated six-month period. There is a clear distinction between the identity theft of an individual and that of a large number of people. About two-thirds of the cases of identity theft are limited to one particular individual and have relatively modest beginnings, such as the loss of a wallet. However, the cases of identity theft that involve enterprises usually involve hundreds, thousands or millions of individuals.

Solution: Creating the Privacy Architecture

Privacy architecture protects and governs the use of PII. Unlike purely technical architectures, privacy architecture has both technical (for example, the configuration of a router or server) and nontechnical aspects (such as the business controls put on PII). The components of the organization's privacy architecture should compliment one another and be designed to realize the same overall goals.

The first component of the privacy architecture consists of a privacy policy. This document will define what PII consists of, how such information can be used, and how it must be protected. Business controls and processes that define how the business itself will collect, manage, and use PII are the second component of the privacy architecture, and should be created to fulfill the strategy and privacy policy across the enterprise. The third component, the technical infrastructure consists of the hardware and software infrastructure over which PII data is going to be stored, transmitted, or manipulated. This infrastructure should then be designed to enforce the privacy controls that have been established.

Figure 1. Privacy Architecture

An organization's privacy architecture should consist of a sustained effort to understand the nature of the privacy risks facing the organization, an assessment of how best to collect and secure PII, and constant education regarding privacy issues for individuals who might come into contact with PII. The initial assessment and implementation of the enterprise privacy architecture must then be followed with vigilance and audit to ensure that any continued gaps in the program or breaches are identified and addressed. Like any other aspect of an organization's information security program, managing privacy risk is a cyclical activity, rather than a one-time task. There are many steps that can help start your organization's privacy program.

Establish a Privacy Policy

Most companies do not have any single point of ownership for any privacy issues that may emerge. The lack of privacy ownership within the organization can exacerbate incident prevention, because in the absence of clear privacy leadership, privacy concerns will tend to not be taken as seriously. The organization should avoid a situation in which all security and audit teams believe that privacy is “someone else's problem” and therefore nothing ever gets done to address privacy challenges.

Many organizations have established a chief privacy officer (CPO), or have given the responsibility for privacy to a chief security officer (CSO). This type of clear ownership is necessary so that all organization have an unambiguous source of privacy direction within the organization.

Cross-functional communications within the enterprise will be required to roll out an effective privacy strategy. A surprising number of information security teams do not have working relationships with other parts of the enterprise that are responsible for different facets of security. When it comes to privacy, a relationship with the organization's legal team is important, because privacy is largely a regulatory-driven issue. It will be necessary for the information security team to get expert advice on what privacy requirements apply to the organization and how those requirements ought to be fulfilled. Representatives from the legal team should be able to assist in creating the organization's privacy policy. Additionally, technical groups such as the networking, system administration and helpdesk may need to be involved, as well as representatives from nontechnical groups such as corporate audit/compliance, physical security, and public relations.

Once the right stakeholders are assembled, a privacy policy needs to be defined. Most corporate Websites have a basic privacy policy that details how information about site visitors are collected and used, but any existing privacy policy should be reevaluated in light of the need to protect specific types of PII. A privacy policy should define what constitutes PII and how an organization will collect, use and protect that data. It should cover not just customer information, but information about the company's employees and others who may submit PII information, although a policy that addresses employee concerns might be located on an intranet Website, and not on the public Website.

A policy, in turn, needs the backing of senior management. A conservative policy limiting the collection and use of PII is likely to meet with significant resistance in an organization that may be used to liberal use of that material. Without visible management support, a privacy policy may be routinely ignored by individuals who still see value in doing things “the old way.” It is important to note that a privacy policy is considered a legally binding promise to individuals as to how their information will be collected. Failing to implement a published privacy policy may leave the enterprise open to legal action.

Once defined, a privacy policy must then be clearly communicated to affected individuals to ensure that they understand the protections the organization promises in exchange for collecting and using an individual's PII. The American Advertising Federation has created a set of guidelines for privacy policies for enterprises that transact business over the Internet:

  1. An organization's privacy policy must be easy to find, read, and understand. Your home page is the best place to post it. Many sites provide a link to the policy on every page. At the very least, the policy should be posted on every page where information is collected.
  2. It must be available at or before the time that information is collected or requested.
  3. The policy must state clearly:
    • What information is being collected
    • How the information will be used
    • Who is collecting the information
    • If the information will be distributed to another party
    • With whom that information will be shared
    • What information will be shared
    • How your company protects the security of this information
    • How your company ensures the data is as accurate as possible
    • How consumers can access their information
    • Options for individuals who want to restrict the information collection
    • How your company will enforce this policy, including whom to contact if consumers have any questions
  4. Individuals must be allowed to decide whether you can use their information.
    • If the information may be used for purposes other than that for which it was originally collected, individuals should have the opportunity to refuse the use of their information.
    • If the information is distributed to third parties for unrelated use, individuals should have the opportunity to refuse to have their information distributed.
  5. Individuals must be assured their data is secure.
    • Your company should take reasonable steps to assure collected information is accurate.
    • Your company should take reasonable steps to protect information from loss, misuse, or alteration.
    • Your company should take reasonable steps to ensure that any third party to whom you transfer the information is aware of your privacy and security policies and has similar policies in place.
  6. Your company must take steps to ensure that information is accurate.
    • Your company should have a way to identify inaccurate information, such as reasonable consumer access to information or protections against accidental or unauthorized alteration.
    • Your company should have a way to correct inaccurate information.

Establish Business Controls and Processes

Working with other stakeholders of the privacy architecture, the information security team should work to establish specific business controls on how PII is to be managed that fulfills the requirements set out by the privacy policy. This step should heavily involve those groups within the enterprise that wish to collect and use PII, and focus on creating business controls only where they would be effective and manageable. Financial institutions, data brokers, and other organizations that collect market- and trade-sensitive personal information should evaluate how the controls around those products and services might enable identity theft.

Part of this process involves understanding where and how the organization currently collects and uses PII. In a large organization, multiple groups may collect PII in their own data repositories, which translates to a number of possible points of attack for the privacy thief. The information security team should ascertain where PII exists within the organization.

Third parties, such as extranet partners or application service providers, present unique challenges. It is generally accepted that if an individual provides PII to an enterprise that in turn sends that PII to a third party performing work on behalf of that enterprise, the original company is still responsible for the privacy of that information as the original data steward of that information. Following this principle, organizations should understand to the extent possible how any third parties may protect that data, and take reasonable steps to verify that those third parties implement similar security precautions for the PII entrusted to them.

Once existing use of PII has been identified, the enterprise should reconsider those existing uses. Many poor privacy practices developed over time to provide convenience and expediency. While these practices may have been appropriate for the times in which they were created, they should be reevaluated in light of the requirements of the privacy policy. For example, it is still relatively common for corporations doing business in the United States to use a person's Social Security Number (SSN) as a unique identifier for an individual rather than bother creating a unique numbering scheme. Another practice that has been highlighted by recent incidents is that of keeping PII on mobile devices such as personal digital assistants (PDAs) and laptop computers. These devices can be easily lost or stolen, and even if the thief was stealing the device for nothing more than its physical value, the value of tends of thousands of individuals' PII on that device can be considerably greater.

These types of broad use and distribution of PII are high-risk activities that can provide ample opportunity for the identity thief to capture targeted information. PII usage and distribution should follow the principle of least access, ensuring that only the absolute minimum number of people in the organization have access to PII as is necessary. By reevaluating your use of PII within the organization, you can then establish business controls to minimize the target footprint that must then be defended by security technology.

Finally, the importance of privacy education within the enterprise cannot be stressed enough. Many recent high-profile privacy breaches had very little to do with network or host security. While the firewalls may be deployed and the servers hardened against attack, identity thieves find that it is often the employees of the organization that remain the weakest link in the corporate security armor. A substantial amount of effort by the organization should go into education for those entrusted with PII to increase their sensitivity to privacy issues, awareness of the privacy policy, and resistance to social engineering attacks. Privacy protection can also be reinforced by general security best practices, such as never leaving a laptop unattended or in an otherwise insecure location.

Deploy the Technical Infrastructure

Many products and technologies can assist in mitigating the risk of a privacy breach. However, an architectural evaluation of technology solutions is necessary. While attackers need to only find one weakness in the enterprise privacy architecture, the defender must protect effectively across all possible points of attack. This may mean that the technology architecture consists of anything from a Cisco(R) Catalyst(R) 6500 SSLSM (SSL Services Module) to provide encryption and authentication for the Internet-facing corporate Website that takes online orders, to having paper shredders or other methods of secure document disposal in convenient locations, to ensuring that employees are issued badges with photographs to help verify that an employee in an area where PII is handled actually belongs there.

As your organization evaluates new products and technologies, consider how that new product or technology may help or harm your privacy architecture. Does the Java application support encryption for its messaging queues? Does the new database support established encryption algorithms for its records, such as AES, or is it some proprietary system that's never been evaluated by the security community? Can encryption even be enabled without crippling the performance of the database? Is the hospital's network architecture designed to keep patient's medical records on a separate VLAN from the network that allows patient's relatives to have basic Internet access? Does the laptop user encrypt the hard drive and lock the laptop to their desk? Should PII information need to ever reside on a laptop in the first place?

Asking specific questions like these to the organization's managers, IT staff, and technology vendors should help you choose appropriate products to help fulfill your privacy requirements. New applications and architectures should be designed with the organization's privacy policy and obligations in mind. Existing infrastructure should be retrofit and brought into compliance as is required by your privacy policy and governance practices.

Compliance and Incident Response

After the privacy architecture is initially established, the information security team should move into a phase of audit and incremental improvement to verify compliance with the privacy policy and identify areas of unaddressed risk that may need to be corrected. It is vitally important for an enterprise's privacy architecture to include continual verification, because privacy controls can erode over time if such controls are never tested. These audits can be conducted by a trusted third-party auditor, or by an internal group that is independent and objective in accordance with the enterprise's audit and internal controls program.

Even with a functioning privacy architecture, incidents can still happen. This is why the enterprise's incident response plans should include procedures that describe how a privacy breach should be handled. It is important to recognize that a suspected or actual theft or loss of privacy information will be a stressful event for both those within the organization, as well as to those individuals whose PII may have been compromised. In addition to the obvious response from the information security team and other technical teams, other groups such as the legal and corporate crisis communications teams will likely have to respond.

These response plans should be created and practiced before an incident ever occurs, because improvisation of the response will likely make things worse. If a public disclosure is required by the nature of the incident, a faulty or poorly managed response in full view of the public can magnify the damage sustained by the enterprise, escalating the situation rather than containing it.

Conclusion

For information security teams already working to keep their enterprises secure from a plethora of different threats, managing the new challenges around privacy may appear to be adding additional work in a time when resources are already stretched dealing with existing security problems. But a privacy architecture should compliment, not complicate, the existing efforts of the security team, because most of the tasks involved in creating a privacy architecture also follow principles of good information security architecture and operations.

Creating a privacy architecture requires sustained effort on multiple levels throughout the enterprise, but it doesn't have to be all about risk mitigation; an organization can enjoy meaningful business benefits as well. In addition to meeting regulatory requirements, security-savvy organizations that expend that effort can transform themselves into privacy advocates in the eyes of their customers, employees, and others whose PII they may be entrusted with. This can result in increased brand value, goodwill, and willingness to transact business over the Internet, all of which can add bottom line value to the enterprise.

References

Privacy Policy Guidelines for Online Businesses from the American Advertising Federation
http://www.aaf.org/government/policies.html

U.S. Federal Trade Commission Identity Theft resources
http://www.consumer.gov/idtheft/

“Just How Common is Identity Theft?”, MSNBC.COM
http://www.msnbc.msn.com/id/8409283/

Motivations of Identity Thieves
http://www.identitytheft.org/oraltestimony.htm

California's PII disclosure law (SB 1386)
http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

Washington's PII disclosure law (SSB 6043)
http://www.leg.wa.gov/pub/billinfo/2005-06/Pdf/Bill%20Reports/House/6043-S.HBA.pdf

U.S. Department of Health and Human Services HIPAA information
http://www.hhs.gov/ocr/hipaa/

U.S. Federal Trade Commission information on the Financial Modernization Act of 1999 (Section V pertains to digital privacy)
http://www.ftc.gov/privacy/glbact/

European Union Privacy and Data Protection Directive 95/46/EC
http://europa.eu.int/comm/justice_home/fsj/privacy/

Acknowledgments

Rakesh Bharania is a Senior Security Specialist with Cisco Systems specializing in network security, web architecture security, and risk assessments.

Back to Top

 


This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.


Back to Top