Fraud WG Meeting 2006 11 28 Face to Face IRT SanFran

From CDGWiki

Contents 1 Details 2 Attendance 3 Notes 4 Working Group Suggestions

[edit] Details

• Face-to-face meeting at the IRT in San Francisco
• Tuesday, November 28, 2006 from 2:00pm to 3:30pm PST (local time)
  

[edit] Attendance

• Aeris Communications
• Bell Mobility
• BTC Bahamas
• China Unicom
• Cibernet
• Fair Isaac
• Gemalto
• KDDI
• Setar
• Skylink Russia
• Sprint
• Syniverse
• Telesystems of Ukraine
• Verisign
• Verizon

[edit] Notes

• Fraud definitions presented by Kerry

• Overview of fraud tools presented by Kerry

• Question about whether there are any low-tech, proactive approaches to preventing subscription fraud

• Response from Kerry that many carriers actually start out with low-end approaches, such as website verification, call-back, social security number checks, etc... However, these approaches are typically labor intensive and often lack scalability.

• Concern expressed regarding RUIM based phones: is it easy to copy key information from an RUIM?

• UPDATE: Later discussion indicated that the concern regarding susceptibility of keys was not really with RUIMs; rather, the issue is that from an operational perspective, there are operators today that use values such as ESNs, MINs, etc... (or values derived from these) rather than randomly generated values as keys. If you know that an operator uses such a scheme, it would be easy to create clones with the correct keys. This operational issue needs to be addressed by the working group. However, it is not an RUIM issue. Once provisioned into an RUIM, key values are not readable.

• Concern expressed that a device could be cloned after it has completed A12, and that the clones could be used in that network until the A12 authentication period has expired.

• Even if this were to occur, the clone would fail data authentication by the serving PDSN when it attempted to establish a data session.

• Monitoring tools

• David from Fair Isaac discussed typical international roaming fraud methods
• High-usage reports versus near real-time monitoring techniques...the difference is essentially that near real-time monitoring could reduce a potential 24-36 hour window for exploitation a potential 10 minute window
• Much of the roaming fraud seen today is being committed by organized criminals
• Subscription fraud is often simply a means to commit roaming fraud, fraud involving premium rate numbers, revenue share schemes, and collusion
• The main threat in roaming fraud is coordinated attacks using many phones to generate a high level of fraud in a short amount of time

• Use of origination triggers for fraud prevention

• An operator discussed their use of real-time SS7 origination triggers setup in the TIA-41 REGNOT profile. This approach involves analysis of digits during a call origination attempt, allowing for real-time determination of whether the call should proceed or be forwarded to fraud prevention

• Internally developed mechanism that works well for the operator that is using it
• Provides ability to deny calls on a real-time basis
• Believes that their exposure is down to 15-20 callers per month

• Data fraud versus data abuse

• Operators have seen little data "fraud"; most of the problems observed thus far can be considered abuse of data service

• Authentication capabilities and status survey

• 20 people responded to the survey

  • Summary of survey results was presented/discussed

• The current high priority items for the team per the October 2006 Conference call are:

1 - Fraud tools for prevention, detection, & visibility - KerryW (Sprint)

2 - Authentication recommendations, policies, settings - JeffP (Sprint)and BryanG (Qualcomm)

• Authentication whitepaper update

• Document was reviewed at the last conference call
• Bryan reviewed the recommendations from the paper
• It was recommended that text be added that specifically addresses the use of RUIMs. Gemalto offered to provide input for this.
• Next steps will be to move forward with releasing the current version of the document as #138 and introduce an update that adds additional information about the role of RUIMs in authentication.
• No additional comments

• Fraud issues are discussed in the roaming agreement, partner qualification, and checklist documents for both voice and data

• References to fraud in these documents were provided
• There was not sufficient time to review these references in detail during the meeting, so review was deferred to a follow-up conference call

[edit] Working Group Suggestions

• Recommendation that we consider broadening the scope of the working group beyond roaming fraud to all fraud issues?

• An observation by Skylink is that they don't have a dedicated fraud group, but they do have fraud people associated with specific products (e.g. BREW fraud person, SMS fraud person, etc…). Therefore, it is difficult to identify who should attend for "roaming" fraud.

• The working group meetings are not long enough to “roll up our sleeves and get work done”. We will not be able to get key people fly somewhere to attend an hour and a half meeting

• Key fraud people need to attend the meetings. The group does not not believe that we will be able to get these people to attend the meetings in China or South Korea, but might be able to get them to attend Miami.

• We should consider having a separate Fraud Forum independent of the IRT where key people could attend, identify their highest priority fraud concerns, and begin to work through potential solutions.

• Operator suggested utilizing the CDG Steering Committee to emphasize the importance of this working group at the Executive level.

• Recommendation to survey vendors for all fraud related products/services with brief description of capabilities.

• Recommendation to survey carriers for;

• Contact information of person and department responsible for roaming fraud and fraud in general, along with next level management contacts
• Details of most impacting roaming fraud issue (revenue/subs/roaming partners) within the last 5 years including type of fraud issue, regional area and resolution

• Provide a method to provide this information via an anonymous portal
• Only share data with carriers that have provided their information