Fraud and Spam Detection

Why Risk Assessment and Detecting Fraud and SPAM Calls is Challenging

Fraudulent calls (including robocalls, reconnaissance, and others) look like every other phone call when they arrive at your Call Center or (Unified) Voice Communications Platform. Detecting fraud is often challenging due to several factors.

Examples of fraud are often rare relative to the broader base of normal transactions. The imbalance in the data makes using classification algorithms difficult because there is not enough “signal” in the data to produce an accurate model.

Patterns of fraud change quickly. Using historical data, even when you have enough examples, may not be helpful as fraudsters constantly change tactics. A model that learned patterns of past fraud well may still not be able to detect future instances of fraud. More importantly, the ability to rebuild models on the latest data and redeploy those models within hours, not days, weeks, or months, enables detecting new patterns of fraud while the patterns are still relevant.

The Benefits of Dynamic Risk Assessment

Detection of anomalous behavior and classification are problems typically solved using Machine Learning.

While the rules may work great initially, they become less useful over time as technology evolves and attack methods change. Bad actors want to achieve their goals with as little effort as possible, so they will not waste resources trying the same approach that does not work again and again. Bad actors will find a way around the static barrier. We do not want predictive algorithms to memorize input data. Rather, we want the algorithms to generalize to more effectively handle data they have not encountered before. Assigning a probability to potential fraud can help prioritize which cases to investigate first. We say “potential” fraud because machine learning models are not perfect, they can make mistakes.

Dynamic Risk Assessment Using Machine Learning with the Premium Edition

Oracle® Communications Security Shield Cloud Service (Security Shield) uses common machine learning techniques for identifying potential fraud including Anomaly Detection, Classification, and Clustering.

Security Shield uses unsupervised machine learning for outlier detection and segmentation of abnormal and risky behaviors from normal behaviors. Security Shield clusters the data first to get a “first order” grouping of similar cases. Then Security Shield can build an anomaly detection model on the records assigned to each cluster, which allows finding unusual cases within each cluster.

Using supervised machine learning, based on network data (number attributes) and listings (customer feedback and traffic pattern detection outputs) Security Shield can classify risky transactions, risky prefixes, and risky carriers. Higher risk scores indicate a higher likelihood of fraud, enabling organizations to prioritize their resources and focus on specific calls or users that warrant further investigation.

The preceding techniques, by themselves, may produce useful results but could result in too many false positives. To help mitigate the problem, Security Shield combines multiple machine learning techniques and models to improve the accuracy and robustness of fraud detection. Applying the notion that multiple sources are better than one source, Security Shield uses one or more each of anomaly detection, classification, or clustering models as input for an ensemble of techniques used to identify which calls are potentially fraudulent. If any model identifies potential fraud, the call is internally classified as such. Security Shield limits the potential fraud cases to those where multiple approaches agree on potential fraud.

Given the imperfect performance of machine learning algorithms, a call flagged as fraud may only merit further investigation. By assigning a risk score and risk category, Security Shield indicates the probability of potential fraud. Security Shield determines the risk probability on a scale of 0 to 100 points.

The score, threat data, and number-related data can help prioritize which cases to investigate first and how to treat potential fraudulent calls.

Security Shield Risk Assessment Data Inputs

Oracle® Communications Security Shield Cloud Service (Security Shield) uses phone numbers to monitor traffic patterns, determine phone number-related attributes, and intelligence data.

Traffic Patterns: Activity from a phone number and the range it belongs to, call duration, and diversity of called numbers.
Phone Number Attributes: The carrier of record, line type, number type, tenure (how long is number seen), diversity of called numbers.
Intelligence Data: Third party fraud database, customer feedback (labeled data, other).

The model is dynamic and adaptive and takes in many inputs and variables into account to determine risk including:

Risk and Fraud Investigation Recommendations

While the Oracle® Communications Security Shield Cloud Service (Security Shield) risk classifications and threat classifications provide useful information for determining the call treatment, the flagged calls (by risk classification or threat classification) may warrant only further investigation.

When you investigate a possible risk or fraud call or determine which call actions to apply, consider the following recommendations.

Understand why a call is identified as fraud, which may be critical to opening an investigation. Security Shield provides call insights to help you understand why a call is flagged as potential fraud or high risk.
Use the analytics capability to find the additional details, such as call insights, and examine the traffic pattern.
Determine if the caller is an existing customer, which type of customer (residential or business), or use any other information that can be a proxy to determine if it is a good caller or not (such as annotation in CRM).

User Feedback

Oracle appreciates your feedback on how Oracle® Communications Security Shield Cloud Service (Security Shield) assessed the risk of a call. Customer feedback, for example by labeled data, is how supervised machine-learning techniques learn.

Your feedback improves the detection of potential fraud and new tactics of fraud. Your feedback will also help Oracle to improve higher accuracy of the fraud and risk prediction for you.

Given the imperfect performance of machine learning algorithms, Security Shield involving millions of real-time calls daily, some degree of error is expected. Your feedback, in combination with our own internal monitoring and investigation is important to reduce the false positive and false negative rate.

Too many false positives, where calls are identified as potential fraud when they are not fraudulent, can have significant negative side effects. If each instance of suspected fraud needs to be manually investigated, such investigation is expensive and time consuming, potentially allowing other real instances of fraud to go unchecked.

Dynamic Risk Assessment Using Machine Learning with the Standard Service

Oracle® Communications Security Shield Cloud Service (Security Shield) – Standard Service verifies the calling phone number, tracks behavior, and determines the risk score. The risk score expresses a probability of risk. You can configure call treatment for calls based on the phone number, behavior, or risk.

Security Shield determines the risk probability on a scale of 0 to 100 points.

Call Flooding Mitigation

Artificially high call attempt rates, called “call flooding”, can severely impact your business by overloading your phone lines. Call flooding, whether intentional or unintentional, can slow or prevent legitimate calls from getting through and possibly create a service outage.

Intentional call flooding includes calls from attackers who want to harm or harass the target entity. Unintentional call flooding might result from a call to action on social media or an error in the configuration of call traffic. Oracle® Communications Security Shield Cloud Service (Security Shield) can detect and mitigate call flooding by way of parameters you set in the Threat Vector Thresholds configuration. You can view data about call flooding activity in your network on the Security Shield Dashboard.

Note:

Security Shield does not count multiple calls in a call flooding scenario against your subscription total. It counts too-frequent multiple calls to a single number as one call, regardless of the enforcement action.

Threat Vector Thresholds

Edit Threat Vector Thresholds

Security Shield Enforcement Actions

You can configure Oracle® Communications Security Shield Cloud Service (Security Shield) to apply a call treatment other than ALLOW.

The following list describes the enforcement actions that (Security Shield) can perform.

Allow (default)

Trigger and Description—You configure ALLOW in an Access Control List, Non-E164 Number, Anonymous Caller, Call Type, and Calls Classification. Another condition for ALLOW is when Security Shield processing takes long and a time out occurs.

Required Data—NA

Inbound or Outbound—Both

Enforcement Location—NA

Block per Access Control Lists

Trigger and Description—When Security Shield determines that the caller exists on a Access Control List with the action set to Block, it blocks the call. Because Security Shield enforces the blocking action prior to call establishment, no call information traverses the enforcement point into the network. Security Shield also uses random response codes (from a list of valid codes) to obfuscate the actual reason for blocking a call.

Required Data—User-defined deny list

Inbound or Outbound—Both

Enforcement Point—Session Border Controller or Session Router

Block Due to Risk Score Action or Threat (call type) Action

Trigger and Description—For a given risk category or call type for which the enforcement action is set to BLOCK, Security Shield blocks the call when the call falls into that risk category or call type. Security Shield also uses random response codes (from a list of valid codes) to obfuscate the actual reason for blocking a call.

Required Data—Risk Category or Call Type

Inbound or Outbound—Both

Enforcement Location—Session Border Controller or Session Router

Exclude per Access Control Lists

Trigger and Description—When you configure Exclude for a phone number on an access control list, Security Shield allows inbound calls while still evaluating against TDoS, Traffic Pumping, Spoofing, and Toll Fraud threat detection. Exclude ignores the risk assessment and classifies excluded calls as "Good". The Exclude action does not evaluate against Fraud Risk, Spam Risk, and Call Center call detection.

Required Data—Access Control List

Inbound or Outbound—Inbound

Enforcement Location—NA

Rate Limiting Due to Traffic Pumping

Trigger and Description—Rate limiting applies only to Traffic Pumping. When the attempted call rate reaches the threshold you configured for Traffic Pumping, Security Shield randomly drops calls based on the configured rate limit.Security Shield drops calls silently to the rate of calls defined by the configured rate limit. You set the call attempt rate threshold on the Threat Vector Thresholds tab on the Autonomous Threat Protection page. You can set a threshold from 1-10,000.

Required Data—NA

Inbound or Outbound—Inbound

Enforcement Location—NA

Re-Direct Due to Risk Score Action or Threat (call type) Action

Trigger and Description—For a given risk category or call type for which the enforcement action is set to REDIRECT, Security Shield redirects the call to the configured new target number. When rerouting the call, Security Shield provides the relevant call routing information for the enforcement points to route the call.

An example of rerouting a call is when you want skilled agents or your security team handle the caller validation. Another example is a call routed to an Interactive Voice Response system with minimal permission instead of a live agent.

Redirect Due to Access Control List

Trigger and Description—When Security Shield determines that the caller exists on a Access Control List with the action set to REDIRECT, it reroutes the call to new destination.

For example, you can reroute known fraud numbers or internal numbers that need no further authentication or validation by way of an Access Control List.

Mid-Call Updates

To avoid lengthy post-dial delays, Oracle® Communications Security Shield Cloud Service (Security Shield) uses a guard timer to respond back within a maximum time interval. When this happens, SSecurity Shield sends back an enforcement action along with other available information. The default action is ALLOW, but in some circumstances the action may be of one of the other types.

When Security Shield compiles a full response after the guard timer expires, and the initial enforcement action was ALLOW, Security Shield updates the enforcement action (based on the risk category or call type) and sends the updated action back. When calls are BLOCKED or REDIRECTED based on a partial response, Security Shield sends no mid-call update back. If the call still exists on the Oracle Communications Session Border Controller, it is terminated.

Note:

If you change the Cloud Communication Service (CCS) public IP address (WAN interface), it may take up to twenty four hours for mid-call updates to resume.

See Scenarios for Enabling or Disabling Mid-Call Updates

Call Flow with Security Shield in the Network

Either the Oracle Communications Session Border Controller (SBC) or the Oracle Session Router (OR) sends a REST API request to Oracle® Communications Security Shield Cloud Service (Security Shield) for each new call configured for Security Shield. In the API calls, the SBC sends specific data from the INVITE and BYE to Security Shield. Security Shield communicates the enforcement action to the SBC, which applies the action to the call.

SBC to Security Shield Connectivity

The Oracle Communications Session Border Controller (SBC) or the Oracle Communications Session Router (SR) uses the following process when connecting to Oracle® Communications Security Shield Cloud Service (Security Shield):

The SBC waits up to two seconds for a policy response from Security Shield. After the time out period, the SBC allows the call automatically.
When five consecutive request timeouts occur in a ten second window, the SBC stops sending requests to Security Shield for fifteen seconds. During this time period, the SBC automatically allows all calls.
After the initial fifteen second delay, the SBC samples traffic by sending every sixth message to Security Shield and waiting ten seconds for a reply to the request.
When the SBC receives a response to a policy request, it resumes sending requests for all traffic to Security Shield. You can define a list of three Cloud Communications Service (CCS) IP addresses. The SBC will attempt to connect to Security Shield starting with the CCS at the top of the list and if that is unsuccessful it attempts connection establishment by way of the next one on the list. Only when all three CCS connections do not respond will the SBC follow the process starting with the first bullet above.

Scenarios for Enabling or Disabling Mid-Call Updates

Sometimes you might want the Oracle® Communications Security Shield Cloud Service (Security Shield) to reassess calls and make mid-call updates to change the enforcement action, which might result in call termination. Or, you might not want the Security Shield to make mid-call updates because you want to avoid call termination. The following scenarios explain the circumstances and reasons.

Scenario for Enabling Mid-Call Updates

In the Cloud Communication Service (CCS) Installation procedure, the Activation script provides the option to use a WAN server certificate and WAN server private key that you supply. When you specify the WAN server certificate and WAN server private key parameters in the Activation script configuration, Security Shield enables mid-call updates.

When you enable mid-call updates, Security Shield uses port 443. If you specify some other port (other than 9000) CCS will use the specified port and allow mid-call updates. See the next scenario for port 9000 behavior.

Note:

If you change the CCS public IP address (WAN interface), it may take up to twenty four hours for mid-call updates to resume.

Scenario for Disabling Mid-Call Updates

Mid-call updates that occur after the SBC continues call processing may affect calls in progress, for example, calls answered by an Interactive Voice Response (IVR) system, a call agent, an employee, or a customer. Depending on your configuration, the typical mid-call update might terminate the call. Such termination can occur without warning causing agent dissatisfaction, customer dissatisfaction, and possible compliance issues. When regulatory compliance reasons do not allow you to block calls, Oracle recommends that you disable mid-call updates.

Disabling mid-call updates does not stop Security Shield from reassessing calls based on new information. In scenarios where mid-call updates are disabled and Security Shield reassess the call, the resulting action is to allow the call. The Security Shield Dashboard shows the reassessed results and the analytics reports, always providing the latest findings per call.

In the Cloud Communication Service (CCS) installation procedure, the Activation script provides the option to use a WAN server certificate and WAN server private key that you supply. When you leave the WAN server certificate and WAN server private key parameters empty in the Activation script configuration, Security Shield disables mid-call updates.

Note:

When you disable mid-call updates, Security Shield uses port 9000. If you specify some other port, CCS will use the specified port and allow mid-call updates. CCS will not disable mid-call updates when you specify a port other than 9000.

See "Enable or Disable Mid-Call Updates" in the Security Shield Installation and Maintenance Guide.

About Disabling Mid-Call Updates

In the Cloud Communication Service (CCS) installation procedure, the Activation script provides the option to use a WAN server certificate and WAN server private key that you supply. When you leave the WAN server certificate and WAN server private key parameters empty in the Activation script configuration, Oracle® Communications Security Shield Cloud Service(Security Shield) disables mid-call updates.

Note:

When you disable mid-call updates, Security Shield uses port 9000. If you specify some other port, CCS will use the specified port and allow mid-call updates. CCS will not disable mid-call updates when you specify a port other than 9000.

See "Enable or Disable Mid-Call Updates" in the Security Shield Installation and

Maintenance Guide.