Identity Theft Prevention Program Proposal
Authors:- Eric Goldman
16 Mar 2009 :: Security :: #red flag rule #red flags #credit
The following is a mock memo to the CEO of a credit card company. This letter provides a high level overview of the Red Flags rule (see references for background information) and is meant to gain executive management’s support in implementing the regulated requirements for complaince with the FACT 2003 Law.
Identity Theft and Compliance with Red Flags Rule Requirements
This memo addresses concerns and requirements related to the Red Flags Rule, which is a component of the “Fair and Accurate Credit Transactions Act of 2003” (FACT 2003). As a creditor organization, we are required to meet certain requirements outlined in sections 114 and elsewhere in the FACT 2003 law. In order to comply with this rule we are required to implement a set of policies and procedures in order to prevent, detect, and mitigate identity theft and data breaches related to our customers. private and personal information. The FTC originally set a deadline for compliance of November 1, 2008; however, this date has been extended to May 1, 2009. Therefore, it is crucial that we rapidly develop and implement our identity theft prevent program before this date.
There are four high level requirements for a Red Flags Rule compliant program, in this memo I will address each component in its own section.
Identifying “Red Flags”
One of the primary requirements of the rule is that we must identity the specific events or patterns of activity which are “red flags”. This requires a thorough analysis of our current business practices and procedures in order to identify where data leakage could possibly occur. This also includes reviewing our information systems and record keeping facilities to identify possible red flags. There are a few key ideas to consider in the identification process. The first area to focus on is prior incidents of fraud related to a given account. This includes reviewing records for past discrepancies, credit freezes, or data which seems fictitious or was used in fraud committed or attempted on other accounts (in other words attempts at using known attack vectors). After ruling out unusual activity and data, it is important to monitor suspicious documents and activity related to documents. Examples of red flags in this context would include information which appears fraudulent (fake addresses or phone numbers), identification or other descriptions which are inconsistent with known data or conflicts with other documents for that account, and new information which does not match prior records such as a cardholder’s signature or a number of attempts to guess a pin number. Additional red flags include information, documents, or personal details that were used to commit fraud in the past or data which already matches an existing account. Beyond documentation and records, specific actions could also constitute red flags. For example, a suspicious activity would be if the billing address is changed on an account and that request is then followed by a name request change on the account. Other examples would be unusual activity patterns, purchases in distant locations in a relatively short period of time, if postal mail if returned or found undeliverable, or a record of suspicious account access. Lastly, clear red flags exist when either the account holder, law enforcement, or another creditor gives notice of a red flag being found in their system or that an investigation is pending. This list is not exhaustive at this point, but indicates the general direction and provides many applicable examples which are relevant to our business. Over time new identification criteria may arise, but in general we will define our criteria broadly enough to cover a wide range of suspicious activity and documents, both internally and externally. Finally, we plan to forge relationships with other organizations and to share our identification strategies in order to reduce identity theft throughout the industry. This last step is important because thieves will not limit their attacks to one company or service; cooperation will help defeat large scale distributed attacks and will allow us all to benefit from a shared knowledge bank.
How to Detect “Red Flags”
Once we have identified actions or data which constitutes red flags, we must implement strategies to detect the existence of these red flags. This will require some changes to our procedures and practices as well as some modifications to our information system and other record keeping assets. Detection occurs at two main stages, (1) the creation of a new account and (2) during modification and access of existing accounts. When new accounts are created, it is important to verify information and to make sure that supplied information and documents are consistent. This includes validating information against known data such as names or addresses used in past fraud attempts or crimes. Using our own databases and possibly external law enforcement or partner databases we can validate records and user supplied information during the account creation process. Additional steps we may take include contacting government entities to verify supplied data or contacting the customer directly in order to match the supplied identity to the real person. For existing accounts, we must check for red flags whenever data is accessed or modified. For example, when an attempt it made to access an account whether online, in person, or over the phone, we will not provide access unless they have sufficient data to assert ownership of the account. Furthermore, a red flag will be raised after a pattern of failed authentication attempts on an account, such patterns will be determined for each individual system or process. Unusual account activity can be calculated on any given account based on normal operations. For example, if a user on average charges $1,500 a month, a onetime charge of $2,000 will trigger a red flag on the account. Frequent address changes or modifications of other personal can also be programmed into the account maintenance system. Red Flags are also triggered when combinations of unusual activity occur, for example an address change and an above average charge made within five days of the account update. Detection will be done both manually and automatically; inside of our record management systems we will develop algorithms to scan and check for irregularities on a schedule and will also train our staff on how to identify attempted frauds or malicious activities when providing customer service.
Responding to “Red Flags”
In the above sections we have identified a methodology to identify and then detect red flags. Once a red flag has been detected, appropriate action must be taken. The response to any particular red flag is based upon a few key factors: This includes the threat rating for a given flag, a consideration of other red flags currently on the account or in its past, and the total volume of red flags at any given time. All red flags deserve a response, and will be addressed; however, by using the above factors we can prioritize higher valued red flags which could lead to high cost attacks or attacks which will affect a larger number of our customers. The threat rating for a particular red flag is determined by the type of activity or the pattern it matches. For example, an irregular purchase of $500 has a lower threat rating than a $5,000 unexpected charge. Next, we would examine the number of red flags related to an individual account. If an account suddenly has irregular charges spread over a large geography and additionally there was a recent billing address change, the combination of these flags would create a higher priority case. In addition, even accounts with resolved red flag investigations result in a higher priority because this could indicate a slow moving attack on the account. Lastly, we look at the total number of red flags at a given time. If we notice a large amount of red flags at any given time, this could indicate a breach of our security, an error in system processing, or any of a number of other activities which could lead to a large number of breaches. During a time when there is a large quantity of total red flags, all accounts are at a higher risk and any additional individual red flags could also be related to this general increase.
Once a total threat score has been assigned to an account, we can evaluate the proper response. If the account has a very high number of red flags, or a high total threat score we may need to immediately freeze that account. We would then audit the account and look at the specific red flags and see how they could be related. When the account if frozen, we would most likely also get the account holder involved to evaluate the situation and to see if the customer was aware of the suspicious activity. In less severe cases, we may not have to contact the individual, but would simply put the account on a higher state of monitoring and review by a human auditor. However, in most cases we will contact the account holder. Once red flags have been evaluated, we can add case notes to the account for each specific flag and inactivate the flags, leaving them there for historical analysis. However, in some cases we may make notes and leave the red flag active depending on the individual situation.
In addition to evaluating specific accounts, we must look into unusual activity which seems to be attempting to reverse engineer our systems and processes. For example, multiple instances of accounts being opened under different identities at the same bogus address should trigger a non-account specific red flag. By investigating these seemingly unrelated but similar red flags we may be able to prevent reverse engineering or penetration efforts. Upon review of these and in some cases account specific red flags, we may determine that certain system designs could pose a potential weakness and reengineering efforts will be put into place. In some cases, the activity may enable us to track down and identify the criminal. It is important to remember that individual accounts may be targeted as well as our organization as a whole because both options could present high value targets for attackers.
Ensuring the Program Continues to Reflect Current Risks Over Time
Lastly, our program must be continually evaluated over time to ensure it is up to date and addresses the evolving challenges we will face in preventing identity theft. In order to remain current, the security team will research identity theft reports and forensic reports from both within and outside of our organization. We will also perform our own penetration testing and internal auditing on systems and employees. This will allow us to see how well we are able to detect and monitor red flags. The results of these tests and possible additional external auditing will be used to create new educational and training initiatives within our organization. The results will also be used to assist in reengineering policies, practices, and systems to minimize the occurrence of current and future fraud and identity theft incidents. By proactively evaluating the circumstances and techniques used by identity criminals we will be better prepared to prevent and defend against data leakage and identity crimes. Over time we seek to continually minimize the occurrence of red flags, while increasing identification and detection efforts.
Conclusion
The implementation of our identity theft prevent program is currently already under way. The security team is working on expanding upon the concepts above in order to create policies and practices to address the problems as outlined above. We believe that the development of this plan will not only allow us to meet compliance with FACT 2003 and other similar laws, but will help increase customer confidence and will also minimize the high costs of dealing with the aftermath of a data breach or identity theft incident. The policy development is already under way and the security team will be submitting it for board approval within the next 30 days.
References
108th Congress. 2003. FAIR AND ACCURATE CREDIT TRANSACTIONS ACT OF 2003. US Government Printing Office. [Online] 2003. [Cited: February 13, 2009.] http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=108_cong_public_laws&docid=f:publ159.108. Public Law 108-159.
City of Palo Alto. 2008. Procedures for Customer Credit Safety [Draft]. Palo Alto, CA : s.n., 2008. 080911 syn 6050547.
McGrath, James C. and Kjos, Ann. 2006. Information Security, Data Breaches, and Protecting Cardholder Information: Facing Up to the Challenges. Payment Cards Center, Federal Reserve Bank of Philadelphia. Philadelphia, PA : Federal Reserve System, 2006.
Privacy Rights Clearinghouse. 2009. A Chronology of Data Breaches. Privacy Rights Clearinghouse. [Online] February 10, 2009. [Cited: February 13, 2009.] http://www.privacyrights.org/ar/ChronDataBreaches.htm#9.