安全な通話と迷惑メール対策

Webexは、安全な通話体験の一環として、このような攻撃に対する強力な脅威保護を提供します。 Webex Calling次の機能は、これらの脅威を軽減するのに役立ちます。

コントロールハブに関する動揺したポリシー
管理者ブロック
ユーザーブロック
認定通話評価プロバイダー（CCRP）統合

STIR/SHAKENポリシーを使用したスパム対策

サービスプロバイダーは、消費者をスパムコールから守るためにネットワークでSTIR/SHAKENを使用しています。このフレームワークは、 FCCガイドラインの一部として米国とカナダですでに有効になっています。発信者ID情報を検証することで、不審な電話にフラグを付けるのに役立ち、見慣れない番号からの電話にユーザーが自信を持って応答できるようになります。

STIR/SHAKEN スタンダードを理解しています

安全な電話識別情報の再検討（STIR）とトークンを使用した署名ベースの主張された情報の取り扱い（SHAKEN）は、相互に関連する標準のフレームワークです。これにより、相互接続された電話ネットワークを介して送信される通話は、発信元のサービスプロバイダーによって発信者IDが正当なものとして署名され、消費者に届く前に受信側のサービスプロバイダーによって検証されます。

SIP verstatP-Asserted-Identityヘッダーのパラメータを介して検証結果を伝えるために、終端サービスプロバイダーは次のオプションを使用します。

TN-Validation-Passed— 検証が成功し、発信者番号へのA、B、Cの証明という結果になりました。
TN-Validation-Failed— 発信者を確認できませんでした。
No-TN-Validation— これは、さまざまな理由で検証に失敗したことが原因である可能性があります。例：E.164番号の形式が正しくありません。

SHAKEN認証レベルA、B、Cでは、発信元のサービスプロバイダーが発信者番号との関係を証明します。

A: サービスプロバイダーは、発信者が電話番号を発信者IDとして使用する権利を持っていることを証明できます。
B：顧客は知られています。ただし、発信者番号を使用する権利があるかどうかは不明です。
C：AまたはBの要件を満たしていません。例: 国際電話。

Verstatの価値と証明

Webex Callingverstat着信コールのパラメータを処理し、シスコクライアントの発信者IDのディスポジションを表示します。

この表は、verstat 発信者IDをクライアントに通知するために使用される情報を示しています。

Vertsat値	認証レベル	シスコのクライアントに表示される値
TN-検証合格しました	提供されていません	確認済みの発信者
	A	確認済みの発信者
	B	スパムの可能性
	C	スパムの可能性
TN-検証-失敗	任意の値	潜在的な詐欺
TN-検証なし	任意の値	スパムの可能性
verstatパラメータはありません	任意の値	スパムの可能性

ユニファイドコール履歴をサポートするシスコのクライアントでは、コール履歴レコードの発信者 ID の性質に従ってアイコンが表示されます。

Webex Appでは、証明書テキストとアイコンが表示され、 MPPデバイスではアイコンのみが表示されます。

オンネット通話の検証

PSTN通話に加えて、オンネット通話の発信者IDの処分は次のルールに従って行われます。

Webex Callingユーザー間のオンネット通話-確認済みユーザー（アイコン付き）。
Cisco Unified Communications ManagerWebex Calling ユーザーからユーザーへのオンネット通話—確認済みのユーザー（アイコン付き）。オンプレミスのCiscoユニファイドコミュニケーションマネージャーユーザーからの通話は、設定されたエンタープライズダイヤルプランと一致する発信者IDに基づいて分類されます。
Webex CallingCisco Unified Communications Managerユーザーからオンプレミスユーザーへのオンネットコール：Ciscoユニファイドコミュニケーションマネージャークライアントには表示されません。

コール転送、コールパーク、コールピックアップ、コール転送、発信者IDなどの通話中機能の場合、発信者IDのディスポジションは最初のコールレッグのverstat値の処理に基づいて行われます。

Webex Callingユーザーへの着信が転送され、発信者番号が変更されると、 verstat発信者IDの処分は着信リクエストの値に基づいて決定されます。

サポート対象デバイス

スパム検出は次のシスコエンドポイントでサポートされています。

Webexアプリ—デスクトップとモバイルのバージョン42.5以上。
MPP電話—ファームウェアバージョン11.3.7以降の6800、7800、8800、9800のMPPデバイスをサポートします。

管理者設定

コントロールハブを使用してユーザー通知をプロビジョニングします

管理者は、未確認の発信者にユーザー表示を送信するように設定できます。管理者は、STIR/SHAKEN検証に失敗した通話をブロックするように設定できます。これにより、潜在的な詐欺電話がユーザーのエンドポイントに送信されなくなります。

組織レベルで通知設定を行うには、次の手順に従ってください。

1	コントロールハブにサインインしてください。
2	「サービス」>「通話」に移動します。
3	サービス設定に行き、発信者ID認証までスクロールします。
4	トグルを使って次のオプションを有効にします。発信者番号の検証に失敗した呼び出しをブロックする-有効にすると、STIR/SHAKENの検証に従って検証に失敗したすべての呼び出しがブロックされます。これらの通話はユーザーのエンドポイントにはルーティングされません。ただし、発信者番号は着信側ユーザーの通話履歴に追加されます。デフォルトでは、この値は無効になっています。未確認の発信者からの通話を通常の通話として表示-このオプションはデフォルトで有効になっています。未確認の発信者からの電話は、表示されずにエンドポイントに送信されます。組織のPSTNサービスプロバイダーがネットワークでSTIR/SHAKENを有効にしている場合は、この設定を無効にできます。無効にすると、未確認の発信者からの電話は、ユーザーのエンドポイントで「迷惑メール」として表示されます。通話表示機能と着信者番号設定は、Webex Callingアメリカ合衆国とカナダの地域にのみ適用されます。他の場所では、発信者番号の設定に関係なく、通話は通常どおり表示されます。

CUBEをスパム表示用に設定してください

verstat情報を渡すにはWebex Calling、Webex CallingローカルゲートウェイまたはCUBEを使用して接続されたオンプレミスのPSTNを使用する米国とカナダの組織は、CUBEでこれらの設定を行う必要があります。

サービスプロバイダーがSTIR/SHAKENをサポートしているPSTNからの電話の場合：

verstatPSTNサービスプロバイダーが新規通話設定時にパラメータを送信する場合は、CUBEを設定します。

ここで参照されているタグは、ローカルゲートウェイ設定ガイドに基づいています。
verstatサービスプロバイダーがパラメータを送信していないときでもこの設定を行っても、通話には影響しません。


voice class sip-copylist 200
 sip-header From
 sip-header P-Asserted-Identity
 sip-header P-Attestation-Indicator
dial-peer voice 200
 voice-class sip copy-list 200
voice class sip-profiles 100
 rule 90 request INVITE peer-header sip P-Asserted-Identity copy "(;verstat=[A-Z|a-z|-]+)" u01
 rule 91 request INVITE sip-header P-Asserted-Identity modify "@" "\u01@"
 rule 92 request ANY peer-header sip From copy "(;verstat=[A-Z|a-z|-]+)" u02
 rule 93 request ANY sip-header From modify "@" "\u02@"
 rule 94 request INVITE peer-header sip P-Attestation-Indicator copy "(.*)" u03
 rule 95 request INVITE sip-header P-Attestation-Indicator add "P-Attestation-Indicator: Dummy Header"
 rule 96 request INVITE sip-header P-Attestation-Indicator modify "Dummy Header" "\u03"
 rule 97 request INVITE sip-header P-Attestation-Indicator modify "P-Attestation-Indicator: $" "Remove: Me"
 rule 98 request INVITE sip-header Remove remove

サービスプロバイダーがSTIR/SHAKENをサポートしていないPSTNからの電話の場合：

verstatPSTNプロバイダーが着信時に情報を送信しない場合は、Control Hubの「未確認の発信者からの通話を通常の通話として提供する」設定のデフォルト値を変更しないでください。設定が無効になっていると、ユーザーのクライアントに「迷惑メール」と表示されます。

認定された発信者評判プロバイダー Webex Calling

Webex Calling 認定通話評価プロバイダー（CCRP）の統合により、安全なコラボレーションを引き続き強化しています。この統合により、新たな脅威から積極的に保護されるため、期待どおりのシームレスなコミュニケーション体験を楽しむことができます。

この機能は、リアルタイムのレピュテーションインテリジェンスを使用して着信PSTN通話を動的に評価し、既知の脅威をブロックしたり、 CAPTCHA検証を通じて不審な発信者に異議を申し立てたり、信頼できる通話を中断することなく接続できるようにしたりすることで、自動的に対策を講じます。 認定プロバイダーのMutareを通じて北米に本社を置くお客様が利用できるこのクラウド管理ソリューションは、最小限の設定でスパムやビッシング攻撃に対するエンタープライズグレードの保護を提供します。つまり、あなたのチームは最も重要なこと、つまり正当な電話をかけてきた人と有意義な会話をすることに集中できるということです。

着信者番号のスクリーニング

Webex Calling発信者情報と一緒に着信者番号をMutareに送信します。管理者はMutareポータルでカスタムルールを設定して、ダイヤルされた番号に基づいて異なるスクリーニング処理を適用します。たとえば、本線にはCAPTCHA認証を要求し、直通電話への通話にはCAPTCHA処理を一切行わないようにすることができます。 Mutareは、発信者番号、着信者番号、またはその両方の組み合わせに基づいて、許可、ブロック、またはCAPTCHAアクションを返すことができます。レピュテーションスコア自体は発信者番号に基づいています。

宛先を意識した保護が重要な理由

受付デスク、メインライン、カスタマーサービス回線、コールキュー、キャンペーンのフリーダイヤル番号など、一般向けの番号は、スパム、ロボコール、テレフォニーサービス拒否トラフィックの標的になることがよくあります。組織全体のスパムポリシーは、すべての着信通話に同じルールを適用します。着信者番号のスクリーニングでは、各宛先に適切なレベルの保護を適用できるため、リスクの高い電話番号は、組織全体の通話処理を変えることなく、より強力な管理を行うことができます。

ユースケース

一般的な使用例は次のとおりです。

受付とメインライン保護 — 電話を会社の受付やメインスイッチボードにCAPTCHAでルーティングし、直通の従業員番号は軽いスクリーニングを行うか、対応を許可します。これにより、組織内のすべてのインバウンドコールにCAPTCHAを要求しなくても、フロントデスクスタッフのロボコールの負荷が軽減されます。
電話のサービス拒否フラッド対策- 公開されている1つの番号が大量の悪意のあるトラフィックの標的になった場合は、そのDIDだけにブロックまたはCAPTCHA処理を適用し、組織の他のユーザーの保護は変更しません。
コールキューとコンタクトセンター- エージェントにキューパイロット番号で電話が届く前に迷惑メールをスクリーニングして、ロボコールや大量のエントリーポイントでの迷惑なトラフィックによるエージェントの時間の無駄を減らします。
規制対象のハイリスク回線 —金融サービス、医療、政府機関のお客様は、詐欺ホットライン、患者スケジューリングライン、代理店の連絡先番号など、機密性の高い電話や一般向けの電話を、宛先固有のポリシーで保護できます。

機能のワークフロー

次の手順では、この機能の仕組みを説明しています。

1	シスコのCCRPであるMutareで評判サービスを購読してください。詳細とMutareでCCRPサービスにサインアップするには、CCRPにアクセスしてください。 Webex Calling お客様はConnect with Mutareを使ってサインアップしてください。 Mutareのオンボーディングチームがサブスクリプションプロセスを案内し、アカウントが適切にプロビジョニングされていることを確認します。
2	サブスクリプションが完了すると、 Mutareは組織固有の会社IDとシークレットキーを用意します。これらの安全な認証情報は、Webex Callingお客様の環境とMutareの評判プラットフォームとの間の信頼できるつながりを築きます。これらの認証情報はコントロールハブで設定する必要があります。
3	組織のセキュリティ体制とビジネスニーズに合わせて評判の閾値レベルを設定して、通話処理ポリシーをカスタマイズしてください。詳細については、次の設定セクションを参照してください。
4	設定を保存すると、Webex Calling 組織のWebex環境とMutareのCCRPプラットフォーム内の専用テナントとの間の安全な接続が自動的に確立されます。
5	PSTNの着信コールがに着きます。Webex Calling
6	通話が宛先にルーティングされる前に、SIP Fromヘッダー（または必要に応じてP-Asserted-Identity）Webex Callingから発信者の番号を抽出します。
7	発信者の番号と着信者の番号を含むリアルタイムのクエリがMutareに送信されます。
8	Mutareは評判スコアを返します。発信者番号、着信者番号、またはその両方の組み合わせに基づいて設定されたカスタムルールが適用される場合、 Mutareはプロバイダールアクションを返すこともできます。
9	Webex Callingプロバイダールールアクションが返されたときにそれを適用します。それ以外の場合は、設定されたスコアしきい値が適用されます。
10	通話が接続されたり、CAPTCHAでチャレンジされたり、プロバイダーのルールアクションや設定されたスコアしきい値に基づいてブロックされたりします。

発信者評価プロバイダーを設定する

発信者評価プロバイダーとポリシー設定を組織レベルで行うには、次の手順に従ってください。

1	コントロールハブにサインインしてください。
2	サービス > 通話に移動します。
3	「設定」に行き、発信者評価サービスまでスクロールします。
4	発信者評価プロバイダーとポリシー設定を構成するには、トグルを有効にしてください。プロバイダー — ドロップダウンリストからプロバイダーを選択します。会社ID —プロバイダーが受け取った会社IDを入力してください。シークレットキー — プロバイダーが受け取ったシークレットキーを入力します。 CCRPにサインアップすると、プロバイダーポータルから会社IDとシークレットキーを取得できます。通話処理ポリシー —レピュテーションのしきい値レベルを設定することでポリシーを設定できます。しきい値スコアは、0.0から5.0までの範囲を定義します。システムは、下限しきい値を下回るすべての通話を拒否します。システムは、より高いしきい値以上の値の呼び出しをすべて受け入れます。発信者の評判スコアがコンテストのチャレンジ範囲内になると、システムは発信者にCAPTCHAを要求します。 [変更を適用する] をクリックして [保存] をクリックします。着信者番号に関するカスタムルールについては、 Mutareポータルでルールの条件とアクションを設定します。カスタムルールでは、発信者番号、着信者番号、または両方の組み合わせを使用して、許可、ブロック、またはCAPTCHAチャレンジアクションを指定できます。 Control Hubで、発信者評価プロバイダーの資格情報とスコアしきい値ポリシーを引き続き設定します。アカウントの有効期限が切れている場合は、発信者評価プロバイダーに連絡してください。ライセンスが復元されたら、「もう一度試す」オプションをクリックして期限切れの状態を元に戻します。

コールフィルタリングの優先順位階層

CCRPとの統合により、Webex CallingWebex Calling優先順位階層内で機能する高度なスパム回避ソリューションが提供され、迷惑電話からユーザーを保護します。これにより、正当な通話が確実に届きます。

Mutare CCRPプラットフォームが、着信者番号を含むカスタムルールに対してプロバイダールールアクションを返す場合は、Webex Callingスコアしきい値処理を適用する前にそのアクションを適用します。

Webex Callingでのコールフィルタリングの優先順位は次のとおりです。 Spam mitigation using STIR/SHAKEN policy

通話処理と報告

治療タイプ	アクション/結果
ブロックします	電話は着信側のユーザーには提供されません。電話は603の原因でリリースされました。通話は、着信側ユーザーの通話履歴に「ブロック済み」という内容で記録されます。
チャレンジ (キャプチャ)	電話をかけてきた人には、チャレンジに合格するための試みが3回与えられます。数字を入力する間に15秒のタイムアウトがあります。チャレンジに合格した場合 — 通話は成功し、迷惑メールとしてマークされません。チャレンジが失敗した場合、または発信者が断念した場合-通話は解除され、履歴に「ブロック済み」として記録されます。
許可します	通話は、何も表示されずに通常の通話としてユーザーに表示されます。
Mutareからの応答がない、または遅い	通話は、STIR/SHAKEN認証の結果とともにユーザーに表示されます（ PSTNキャリアから入手できる場合）。

通話がSTIR/SHAKEN処理後に潜在的な迷惑メールとしてマークされたが、レピュテーションスコアが高いか、MutareのコールレピュテーションサービスのCAPTCHAテストに合格した場合は、ユーザーへの通常の通話として表示されます。Webex Calling
通話がSTIR/SHAKEN処理後に確認済み発信者としてマークされたが、レピュテーションスコアが低かったり、Mutareの通話レピュテーションサービスのCAPTCHAテストに失敗した場合、その通話はブロックされます。

通話データとレポートを強化するために、レピュテーションサービスからの情報を取り込むために、通話詳細記録（CDR）に次のフィールドが追加されました。

コールスコア
コールレピュテーションサービスの結果
発信者の評判スコアの理由

これらのフィールドの詳細については、Webex Calling詳細な通話履歴レポートを参照してください。

グループ機能の発信者評判スコアリングプロセス

発信者評価スコアリングは、着信コールが最初にシステムに入ったときに、各着信に対して1回だけ実行されます。このプロセスは、ワークスペース、自動応答、コールキュー、ハントグループなどのグループ機能を含む、あらゆる種類のエンドポイントを対象としています。グループ機能からのコールを受信する宛先では、初期評価はグループまたは機能のエントリポイントですでに行われているため、追加の発信者評価チェックは行われません。レピュテーションチェックに失敗した通話で、着信者番号がグループ機能に割り当てられている場合は、通話履歴のエントリは作成されません。

着信者番号のスクリーニングでは、着信者番号は元の着信者番号、または通話の最初のルーティングターゲット（コールキュー、ハントグループ、その他のグループ機能の番号など）です。 Webex Calling 通話が後で別の宛先にルーティングされても、追加のレピュテーションチェックは実行されません。

コールバックヘッダーを含む緊急電話番号からのコールバックコールは、評判プロバイダーによる審査を受けません。

サポートとサービスのパートナーシップ

CiscoとMutareは、発信者評価サービスの統合について、お客様が迅速かつ専門的な支援を受けられるように、サポートパートナーシップを確立しました。 Webex Callingインフラストラクチャ、コールルーティング、またはコントロールハブの設定に関する問題については、お客様は標準サポートチャネルを通じて Cisco Technical Assistance Center (TAC) に連絡する必要があります。評判スコアの計算、プロバイダーポータルへのアクセス、アカウントの提供、請求に関する質問など、CCRPサービス特有の問題については、お客様はMutareの専任サポートチームに直接問い合わせてください。

このサポート体制により、各問い合わせが適切なチームに届き、最も効果的かつ効率的な解決が可能になります。

制限事項

ユーザーは、通話履歴にあるブロックされた通話リストを定期的に確認して、誤検知がないか確認する必要があります。誤ってブロックリストに番号が表示された場合、特にブロックしてはいけない不在着信があった場合、ユーザーは管理者に連絡してそれらの番号のブロックを解除してもらう必要があります。

Cisco AI Assistant

コメントありがとうございます。