2 How OCSS Works
The following information explains how Oracle® Communications Security Shield (OCSS) features and operations work in the software and in your network.
Call Traffic Operations with OCSS in the Network
The Oracle Communications Session Border Controller (OCSBC) sends a REST API request to Oracle® Communications Security Shield (OCSS) for each new call attempt on a realm configured for OCSS. In the API calls, the OCSBC sends specific data from the INVITE and BYE to OCSS. OCSS runs a series of verifications on number plan information and performs look-ups for information to determine the reputation score and enforcement action. OCSS also uses random response codes (from a list of valid ones) to obfuscate the actual reason for blocking a call. OCSS communicates the enforcement action to the OCSBC, which applies the action to the call.
OCSBC to OCSS Connectivity
The Oracle Communications Session Border Controller (OCSBC) uses the following process when connecting to Oracle® Communications Security Shield (OCSS):
- The OCSBC waits up to ten seconds for a policy response from OCSS. After the time out period, the OCSBC allows the call automatically.
- When five consecutive request timeouts occur in a ten second window, the OCSBC stops sending requests to OCSS for fifteen seconds. During this time period, the OCSBC automatically allows all calls.
- After the initial fifteen second delay, the OCSBC samples traffic by sending every sixth message to OCSS and waiting ten seconds for a reply to the request.
- When the OCSBC receives a response to a policy request, it resumes sending requests for all traffic to OCSS.
How Call Reputation Scoring Works
After Oracle® Communications Security Shield (OCSS) verifies the phone number plan information and performs look-ups, it determines the reputation score and corresponding enforcement action for the call.
When calculating the reputation score for the called number and calling party number, OCSS looks at call behavior, the number intelligence, risky destinations, and previous scores. For the calling-party number, an optional Premium service is available where OCSS uses a third-party to obtain additional information about the calling-party number to use in the calling-party number reputation scoring. The additional information provides more accuracy because scoring is based on Public Switched Telephone Network (PSTN) details, provider, and caller-type information.
OCSS uses various inputs to compute a reputation score. While the inputs used for the computation are the same for all calls, the values of the inputs can differ greatly. For example, determining that a number that is premium-rate is a binary decision and does not exist on a spectrum, while the outbound call rate to a number does. Such variation leads to different reputation scores. After OCSS computes the reputation score, the range that the score fits into determines the classification of the call.
OCSS determines reputation scores on a scale of 0 to 100 points. The following table shows the Call Classification and Reputation Score Matrix for the Premium subscription.
| Call Classification | Reputation Score Range (Not configurable) | Type of Caller or Call | Examples | Default Actions (Configurable— Allow | Block |Redirect) |
|---|---|---|---|---|
| Acceptable | 0-10 |
|
|
Block Call |
| Critical Risk | 11-30 |
|
|
Block Call |
| Severe Risk | 31-50 |
|
|
Block Call |
| Significant Risk | 51-60 |
|
|
Block Call |
| Suspicious | 61-65 |
|
|
Allow Call |
| Good | 66-100 |
|
|
Allow Call |
Note:
You can enable OCSS to override the configured reputation score enforcement action and block calls that do not pass Secure Telephony Identity Revisited (STIR) validation. See Autonomous Threat Protection General Settings.See Mid-Call Updates
OCSS Enforcement Actions
The following list describes of all the enforcement actions that Oracle® Communications Security Shield (OCSS) can perform and a description of the conditions that cause enforcement. Some enforcement actions occur only on inbound calls, while others occur on both inbound and outbound calls. OCSS instructs all actions, unless otherwise noted. The following list is organized by the three phases of a call (pre-establishment, mid-call, and post-call).
Pre-Call Enforcement Actions
- Allow
- Trigger and Description—When OCSS determines that no pre-call information is available that warrants alternate action on a particular call it allows the call. If OCSS times out, it defaults to Allow. Successful queries to OCSS and timeouts both cause the system to maintain a counter associated with the caller number.
- Block Per Deny List
- Trigger and Description—When OCSS determines that the caller exists on a deny list, it blocks the call. Because OCSS enforces the blocking action prior to the call being established, no call information traverses the enforcement point into the network. When OCSS instructs denylist-blocking, it maintains a counter associated with the caller number indicating the call was blocked due to deny listing and it identifies the type of deny list.
- Block Due to Reputation
- Trigger and Description—When any of the data obtained from resources provides enough information for OCSS to determine that the caller has a sufficiently low reputation, it blocks the call. You can set the reputation score threshold through the Dashboard in the thresholds configuration. When OCSS instructs blocking due to reputation, it maintains a counter associated with the number indicating the call was blocked due to reputation.
- Throttling
- Trigger and Description—When OCSS identifies a
caller number that crossed the threshold for the allowed frequency of calls
made within a given window of time, it blocks the call. When the frequency
falls below the window, OCSS allows any
received calls from the number to pass through. When OCSS instructs
blocking due to rate limiting, it maintains a counter associated with the
caller number indicating the call was blocked due to rate limiting.
Note:
You might see some fluctuation where the actual value sometimes differs from the configured value. - Rate Limit
- Trigger and Description—OCSS declares a Telephony Denial of Service (TDoS) attack when the attempted call rate reaches the maximum call attempt rate threshold that you set for Network-wide TDoS and Overload Protection. When the attempted call rate reaches the threshold, OCSS randomly drops calls such that the rate of calls allowed to traverse the Session Border Controller matches the rate that you set. 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.
- Re-Direct
- Trigger and Description—Based on your configuration and various locally tabulated and Cloud obtained data, the OCSS might determine that rerouting the call is a better choice than blocking the call. When rerouting the call, OCSS provides the relevant call routing information for the enforcement points to route the call. One example of the determination to reroute a call instead of blocking it is when the reputation score is high enough not to warrant blocking the call but low enough to require further manual authentication by a more qualified endpoint than originally designated. Another example is a call that is designated to be routed to an Interactive Voice Response instead of a live agent. The required data fields for this type of call include the deny lists that you can specify, resulting in rerouting instead of blocking. When OCSS instructs this action, it maintains a counter associated with the caller and indicates that the call was rerouted and for which reason.
Mid-Call Enforcement Actions
- Block
- Trigger and Description—During the course of a call, information that was not available at call initiation might arrive about the call from external sources that warrants blocking the call. OCSS determines the necessity to terminate the call and initiate an API call to the enforcement points when a late response indicates that the call must be blocked, and only if the call was allowed during the pre-answer phase. Upon reception of this indication, the enforcement points will terminate the call without warning. The option to terminate a call may also be initiated based on call volume exceeding the prioritized limits. For example, if you set a maximum of 25 incoming calls and OCSS is operating at the maximum when a high priority user calls, it will drop a low priority call to make room for the high priority call. The system will tabulate the call termination and context, which you can access to see the statistics.
Mid-Call Updates
When the response from OCSS is received after the guard timer on the Oracle Communications Session Border Controller (OCSBC) expires, and the enforcement action on the call is "allow", OCSS reassess the scoring using the data from the OCSS response and can update the enforcement action accordingly.
The updated enforcement action can include blocking the call or terminating the call, which the OCSBC can perform in a mid-call update. For example, after receiving the late response or mid-call request, OCSS re-calculates the reputation score for the call using the new information. If the previous action was "allow", and the new reputation score results in "block", the OCSS sends a mid-call instruction to the OCSBC to enforce the new action. If the call still exists on the OCSBC, 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.Scenarios for Enabling or Disabling Mid-Call Updates
Sometimes you might want the Oracle® Communications Security Shield (OCSS) 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 OCSS 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
When the response from the OCSS service is received after the guard timer on the Oracle Communications Session Border Controller (OCSBC) expires, and the enforcement action on the call is "allow", the OCSS service reassess the scoring using the data from the OCSS service response and can update the enforcement action accordingly. The updated enforcement action can include blocking the call, which the OCSBC can perform in a mid-call update. For example, after receiving the late response or mid-call request from the OCSS service, the OCSS re-calculates the reputation score for the call using the new information. If the action before the mid-call update is "allow" and you configured "block" for a low reputation score, the OCSS sends a mid-call instruction to the OCSBC to enforce the "block" action when the new reputation score results in "block". If the call still exists on the SBC as of the mid-call update, the OCSBC terminates the call.
Note:
When you enable mid-call updates, OCSS 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.Scenario for Disabling Mid-Call Updates
IT security teams might consider mid-call updates from OCSS towards an Oracle Communications Session Border Controller (OCSBC) as unsolicited externally initiated communication from, or crossing, untrusted domains. Corporate firewalls block such traffic flows by default due to potential cyber security risks. Your security team may need to approve the mid-call data flow, which requires effort and time. Certain firewall changes may be required, as well.
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, call agent, employee, or for outbound calls, by 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 OCSS from reassessing calls based on new information. In scenarios where mid-call updates are disabled and OCSS reassess the call, the resulting action is to allow the call so that the mid-call update towards the OCSBC has no affect on the call. The OCSS Dashboard shows the reassessed results and the analytics reports, always providing the latest findings per call.
Note:
When you disable mid-call updates, OCSS 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 OCSS Installation and Maintenance Guide.
Inbound Call Labeling
When an inbound call goes through Oracle® Communications Security Shield (OCSS), OCSS adds the P-OCSS-Call-Info header to the SIP INVITE. The information in the header can improve call labeling, which can help you make more informed decisions about your network.
- route calls to the correct queue, such as a call agent, and select the appropriate Interactive Voice Response (IVR) menu for inbound calls.
- route a higher risk caller to a menu with restricted options, such as the ability to pay an outstanding bill but not the ability to change account information.
- route a call from a mobile phone to an IVR menu optimized for mobile calls, such as a shorter, reduced number of selections.
- route certain call-types through an additional verification step.
- After receiving a mid-call update, the Session Border Controller (SBC) does not add any of the call-info parameter information to a SIP message.
- OCSS removes the P-OCSS-Call-Info header from outbound SIP messages on untrusted realms.
- OCSS captures configuration changes to call labeling in the Activity Log.
- The ci-key contains the SessionID that OCSS generates, which you can use to view more details about the call in the Call Traffic Analytics Display Operations. The SessionID metric is in the Policy Results Statistics Attributes group.
P-OCSS-Call-Info Header Element Descriptions
The P-OCSS-Call-Info Header contains parameters that specify the type of
information available for calls that pass through Oracle® Communications Security Shield (OCSS). The
header requires Source and key. The other elements are optional.
Note:
The order of parameters that you see may vary from the following example.label-info-params = [ci-reputation-score] / [ci-category] / [ci-type] / [ci-device] / [ci-callerid-attest] / ci-source / ci-key
ci-score = "Reputation Score calling number" EQUAL 1*3DIGIT
ci-source = "origin" EQUAL "OCSS"ci-category = category EQUAL ("critical-risk" / "high-risk" / "severe-risk" / "significant-risk" / "suspicious" / "good" / "trusted" /"acceptable" / "verified")
ci-callIerid-attest = "calledID-attest" EQUAL ( "trusted" / "verified" / "not-verified"/ "failed")
ci-type = "type" EQUAL ("fraud-risk" / "spam-risk" / "call-center-call" / "spoofed-call")
ci-device = "device" EQUAL ("fixed" / "mobile / "other" / "pager" / "payphone" / "personal" / "premium" / "prepaid" / "toll-free" / "voicemail" / "voip" )
ci-key = "key" EQUAL "sessionID"The following table lists and describes the header parameters.
| Header Element | Description |
|---|---|
| source | (Required) Specifies OCSS as the source of the data in this header. When the source is not available at the time of header creation, the header does not include this element. |
| key | (Required) Includes the unique call ID generated by OCSS. This unique call ID allows for correlating call records between OCSS and other systems. |
| category | (Optional) Specifies the call categories. See the OCSS documentation for more
information about the call categories.
When the call category is not available at the time of the header creation, the header does not include this element. The header also supports the following
values.
|
| callerid-attest | (Optional) Specifies the trust level of the calling number. This information is based on the STIR/SHAKEN information provided by the Service Provider or SIP Trunk provider and the call category. Valid values: Trusted (reserved for future use) | Verified | Failed | Not Verified. |
| type | (Optional) Specifies the type of suspicious or potentially fraudulent call. When the type information is not available at the time of the header creation, he header does not include this element. |
| device | (Optional) Specifies the device or line type associated with the calling number. When the device information is not available at the time of the header creation, the header does not include this element. See "P-OCSS-Call-Info Codes, Types, and Values" for information about how to interpret the codes from the INVITE headers. |
| score | (Optional) Specifies the Reputation Score that OCSS determined for the Calling Number. |
The following example shows an INVITE configured for source, type, score, and key after passing through OCSS from the Session Border Controller.
Note:
The order of parameters that you see may vary from the following example.INVITE Request
INVITE sip:alice@example.com SIP/2.0
...
P-OCSS-Call-Info:
;source=OCSS ;category=severe-risk
;type=spam-risk ;device=voip
;score=41
;key=eyJzaXBUaHJlYWRJZCI6MywiY2FsbElkIjoid2xzcy1kNmNlNDczMi01NjYyODIyNl82NzAzOTc4M0AxNTIuMTg4LjI1MS4xNDIiLCJmcm9tVGFnIjoiNmVjNzRjYjEiLCJ0aW1lc3RhbXAiOiIyMDIyLTAxLTEyVDIwOjExOjAwLjAxMFoiLCJzYmNJZCI6IlNCQ0xFQzYzNTBOQ0UwMUEiLCJyZWFsbSI6InZ6X3dzYXRmXzAxX291dCJ9P-OCSS-Call-Info Codes, Types, and Values
Oracle® Communications Security Shield (OCSS) does not display the P-OCSS-Call-Info on the Dashboard. You must interpret the codes from the INVITE headers.
The following table lists the phone number type and name, and ci-device value for each phone type code.
| Number Type and Name | ci-device Values |
|---|---|
| FIXED_LINE Number | fixed |
| Mobile Number | mobile |
| PREPAID (for prepaid mobile) | prepaid |
| toll-free number | toll_free |
| VOIP (non-fixed VOIP) | voip |
| Pager | pager |
| Payphone Number | payphone |
| Invalid | |
| RESTRICTED_PREMIUM (Restricted Number) | premium |
| Personal | personal |
| Voice mail number | voicemail |
| Other | other |
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 (OCSS) can detect and mitigate call flooding by way of parameters you set in the Threat Vector Thresholds configuration. A threat vector is an angle of attack from a fraudster, such as Telephony Denial of Service (TDoS), Traffic Pumping, and Toll Fraud. Each type can produce artificially high traffic loads. OCSS also lowers the reputation score of the caller as the flooding persists, which can cause an enforcement action.
- TDoS—Excessive network-wide inbound call volume that exceeds the configured detection threshold and can lead to overloading OCSS, causing a service outage. To mitigate Telephony Denial of Service (TDoS), you can set the number of call attempts per Oracle Communications Session Border Controller (OCSBC) per time interval that you want to allow plus the action to take when OCSS detects a TDoS attack. When the call rate exceeds the configured threshold, the SBC performs the configured action.
- Traffic Pumping—High levels of inbound call volume to specific number ranges that can impair service or parts of a network but may not cause an outage. The Traffic Pumping threat detection service monitors the inbound call rate per number-range for an interval of time. When the call rate exceeds the configured upper threshold for five minutes, the OCSBC performs the configured action. When the call rate falls below the configured lower threshold for five minutes, the OCSBC stops enforcing the configured action.
- Toll Fraud—An increase in call volume or call duration to high risk countries or high-risk phone numbers that does not impair the service. To mitigate Toll Fraud, you can set the number of call attempts and the call attempt rate per OCSBC per time interval that you want to allow as well as the allowed call duration during business hours and non-business hours. You can also set a cost threshold for calls to high-risk destinations and the action you want the OCSBC to take when OCSS detects toll fraud.
You can view data about call flooding activity in your network in the Autonomous Threat Protection and Call History tiles on the OCSS Dashboard.
Note:
OCSS 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, even when the enforcement action is Continue or Rate Limit.OCSS Phone Number Format Requirements
Oracle® Communications Security Shield (OCSS) requires the following conventions for phone numbers for inbound and outbound calls.
Note:
If your Session Border Controller does not use phone numbers in the E.164 format, Oracle may need to work with you before deploying OCSS to determine how to normalize your phone numbers to work effectively with OCSS.- The general number format convention is country code followed by the subscriber phone number <country code><subscriber phone number>. The country code can be up to three digits long. The subscriber phone number may include an area code and is typically seven to eleven digits long, depending on the national number conventions. For international formatting, you may format the number with a + character (+<country code><subscriber phone number>, for example, +15551234567) or without the + character. For outbound calls to international destinations you can use either the + character or the international dialing prefix for your country. Check with your SIP trunk provider for the number format convention it supports.
- You can use wild cards at the end of the phone number to indicate a range. For example: To specify a seven digit phone number that begins with 91920, enter 91920xx.
- If you choose to configure the Presentation Number, you must use only the number format convention supported by the SIP trunk provider. When you use multiple SIP trunk providers, you must use a Presentation Number format that each SIP Trunk provider can support. For example, in the United States you use [country code][area code][local phone number] or the more commonly used [area code][local phone number]. In the European Union and United Kingdom you use [+][country code][area code][local phone number].
How OCSS Manages Nonconforming Calling Numbers
When a calling number does not conform to E.164 phone number conventions, even after normalization, Oracle® Communications Security Shield (OCSS) provides you with ways to specify call treatment.
- The originating entity, originating Service Provider, or intermediate networks may have added the nonconforming phone number due to a configuration error, lack of validation, or incorrect or incomplete information. Some possible configuration errors include errors in one or more normalization rules, incorrect number length, or the number contains prefixes and suffixes. Typically, a nonconforming number seen in such scenarios is not malicious or ill-intended.
- A configuration error in the Number Normalization rules. This scenario is an error condition, and is not malicious by nature.
- Malicious use of nonconforming numbers to disguise the originator of the call or use of improperly formatted numbers to gain access or detect vulnerabilities. These are threat scenarios.
OCSS can consider nonconforming calling numbers as threats when the call classification is set to Critical, Severe, or Significant, (Premium Edition) or High (Standard Edition), and a nonconforming calling number is present after number normalization. With Continue as the enforcement action, OCSS continues call processing which includes the Access Control List and Threat Detection. With any other enforcement action, OCSS stops processing the call and performs the configured action.
OCSS reports threats from nonconforming calling numbers to the Threats by Count tile on the Dashboard as a threat type.
Note:
Nonconforming call management applies to both the Standard and Premium editions. The settings displayed for Call Classification depend the edition.Reputation Score Call Classifications for the Premium Edition
The Premium Edition of OCSS provides the following reputation score call classifications and scores for nonconforming calling numbers.
Critical Risk—OCSS considers calling numbers that do not conform to E.164 requirements as threats. When you set the classification to Critical Risk, OCSS displays Nonconforming Number as a threat type on the Threats by Count and expanded Autonomous Threat Protection tiles on the Dashboard. Default reputation score: 21.
Severe Risk—OCSS considers calling numbers that do not conform to E.164 requirements as threats. When you set the classification to Severe Risk, OCSS displays Nonconforming Number as a threat type on the Threats by Count and expanded Autonomous Threat Protection tiles on the Dashboard. Default reputation score: 41.
Significant Risk—OCSS considers calling numbers that do not conform to E.164 requirements as threats. When you set the classification to Significant Risk, OCSS displays Nonconforming Number as a threat type on the Threats by Count and expanded Autonomous Threat Protection tiles on the Dashboard. Default reputation score: 51.
Suspicious—(Default) OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 65.
Acceptable—OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 10.
Good—OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 71.
Reputation Score Classifications for the Standard Edition
The Standard Edition of OCSS provides the following reputation score call classifications and scores for nonconforming calling numbers.
High Risk—OCSS considers calling numbers that do not conform to E.164 requirements as threats. When you set the classification to High Risk, OCSS displays Nonconforming Number as a threat type on the Threats by Count and expanded Autonomous Threat Protection tiles on the Dashboard. Default reputation score: 21.
Suspicious—(Default) OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 51.
Acceptable—OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 10.
Good—OCSS does not consider nonconforming calling numbers as threats. Default reputation score: 76.
Note:
You cannot configure the reputation scores.Enforcement Actions
OCSS provides the following enforcement actions that you can specify for nonconforming calling numbers.
Block Call—OCSS denies the call.
Redirect Call—OCSS redirects the call to the number you specify.
Continue—(Default) OCSS processes the calling number against your Access Control List and Threat Detection settings when you set the call classification to High Risk (Standard Edition), Critical Risk, Severe Risk, or Significant Risk (Premium Edition).
Configure Nonconforming Number Handling
Oracle® Communications Security Shield (OCSS) defaults to the Suspicious call classification and the Continue enforcement action for nonconforming numbers. You can change the call classification and enforcement action from the Call Classification page on the Settings tab.
- For more explanation of the parameters in the following procedure, see How OCSS Manages Nonconforming Calling Numbers.
Note:
The settings displayed for Call Classification depend on whether your subscription is the Standard Edition or the Premium Edition.- Access the Settings tab, and click Call Type Classification.
- On the Call Type Classification page, do the following:
- Enforcement Action—Set the enforcement action you want for nonconforming calling numbers. Default: Continue. Valid values: Block | Redirect | Continue.
- Call Classification—Set the call classification you want for nonconforming calling numbers. Default: Suspicious. Valid values for Premium Edition: Critical Risk | Severe Risk| Significant Risk | Suspicious | Acceptable | Good. Valid values for Standard Edition: High Risk | Suspicious | Acceptable | Good.
- Click Save.