ヨルダン中央銀行：顧客の口座を支えるモバイルバンキングアプリをテストしましょう。

1. 01

   Instructions of Cyber Risks Resilience、第35条(a)

   重要システムのペネトレーションテストを少なくとも年1回行う

   条文の内容

   重要システムのペネトレーションテストを、少なくとも年1回、またはシステムの抜本的な変更後に実施します。範囲は、システムとそれを支えるシステムの機密性に基づいて定めます。テストは、内部・外部ネットワークだけでなく、アプリケーションのレベルでも実施します。テストは第三者が実施してもかまいませんが、同じ第三者に連続して2年を超えて委託してはなりません。

   出典：Instructions of Cyber Risks Resilience、第35条(a)

   モバイルアプリにとっての意味

   モバイルバンキングアプリが重要システムを支えている場合、アプリとそのAPIは年次のペネトレーションテストの対象となり、抜本的な変更の後には新たなテストの対象にもなります。

   Ostorlabによる支援

   AIエージェントによるペネトレーションテストは、リリースするビルドを対象に、ログインの先までアプリとそのAPIをテストし、AIエージェントによる各検出結果に再実行できる実証済みのエクスプロイトを付けます。年次テストの合間にも、リリースごとに実行できます。

   お客様が担うこと

   年次テストの範囲設定、テスト実施者の選定と交代、何を抜本的な変更とみなすかの判断。

2. 02

   Instructions of Cyber Risks Resilience、第35条(b)および(c)、Cybersecurity Framework、G.9.5

   脆弱性を評価し、新たな不備を監視する

   条文の内容

   重要システムとそれを支えるシステムの脆弱性とセキュリティ上の不備を定期的に評価し、見つかった不備に対処し、新たな不備を検知するためにシステムを継続的に監視します。フレームワークは、重要かつ機密性の高いシステムについて、適用済みの管理策を迂回する形と経由する形の両方で、少なくとも月1回の脆弱性スキャンを強く推奨しています。

   出典：Instructions of Cyber Risks Resilience、第35条(b)および(c)、Cybersecurity Framework、G.9.5

   モバイルアプリにとっての意味

   年次のペネトレーションテストの合間にも、アプリとそのAPIには定期的な自動スキャンが必要であり、検出結果は修正され、追跡されなければなりません。

   Ostorlabによる支援

   CI/CDパイプラインからビルドごとに自動スキャンを実行し、手動で起動しなくてもストアのリリースを監視できます。パイプラインを定期実行すれば、リリースの合間も週次のペースを保てます。検出結果はクリティカル、高、中、低で評価され、チケットとして追跡され、修正のリリース後に再テストされます。

   お客様が担うこと

   インフラとネットワークのスキャン、およびシステムごとのスキャン頻度。

3. 03

   Cybersecurity Framework、G.2.2およびG.2.3

   開発の全工程でセキュリティをテストする

   条文の内容

   セキュアな開発ライフサイクルを定めます。コーディング中は静的コード解析を、テスト中は脆弱性スキャンとペネトレーションテストによる動的コード解析を行い、結果をレビューして修正します。セキュアコーディングは、少なくともOWASP Top TenとCWE/SANS Top 25に対応しなければなりません。アプリケーションの保護を、機能、ソースコード、鍵、文字列の難読化に頼るべきではなく、修正はリリース前に十分にテストしなければなりません。

   出典：Cybersecurity Framework、G.2.2およびG.2.3

   モバイルアプリにとっての意味

   アプリの各リリースは、ストアに届く前に静的テストと動的テストを通過すべきです。アプリ内に隠した鍵は管理策にはなりません。

   Ostorlabによる支援

   Mobile SASTは、組み込まれたSDKにまたがるテイント解析を含め、ソースコードなしでAPK、AAB、IPAを直接解析します。Mobile DASTはアプリを実行し、通信、スタックトレース、スクリーンショットを取得します。Ostorlabは、APIキーやトークンなどのハードコードされたシークレットも、リリース前に見つけます。

   お客様が担うこと

   脅威モデリング、コードの作成者以外による手動コードレビュー、開発者のトレーニング。

4. 04

   Cybersecurity Framework、H.2.1(2)

   モバイルバンキングアプリを堅牢化する

   条文の内容

   モバイルバンキングとWebバンキングについて、アプリは初回利用時に顧客の携帯電話番号とデバイスのIMEIまたはESNを検証し、最長5分の無操作でセッションを終了し、有効性が確認されたデバイスを最大3台まで認めつつ同時セッションを禁止し、TLSピンニングなどの中間者攻撃対策の手法を用い、機密データをキャッシュせずデバイスに保存するデータを暗号化し、root化・脱獄されたデバイスへのインストールを防止しなければなりません。

   出典：Cybersecurity Framework、H.2.1(2)

   モバイルアプリにとっての意味

   これらはいずれも、アプリのテスト可能な特性です。ピンニングとroot検知は、回避を試みる攻撃者にも耐えなければなりません。

   Ostorlabによる支援

   Mobile Shielding Scanはroot化・脱獄済みの環境でアプリを実行し、root・脱獄検知、改ざん防止、アンチインストルメンテーション、TLSピンニングの回避を試み、アプリがワークフローをブロックするのか、起動を拒否するのか、動作を続けるのかを示します。Ostorlabは、ローカルストレージ、キャッシュ、ログ、スクリーンショットにトークンや個人データがないかも調べます。

   お客様が担うこと

   シールド製品の選定と設定、およびデバイス登録の手続き。

5. 05

   Cybersecurity Framework、H.2.1(1)およびH.4(2)

   機密性の高い操作に認可の要素を追加する

   条文の内容

   アカウントの有効化、パスワードのリセット、金融取引、受取人の追加・変更には、帯域外のワンタイムシークレット、時間ベースまたはハッシュベースのOTP、暗号学的認証器を用いて、追加の認可要素を実装します。ワンタイムシークレットの有効期間は最長5分です。電子チャネルを通じた連絡先情報の変更には多要素認証が必要であり、通知と第2の要素は変更前の電話番号またはメールアドレスに送信します。

   出典：Cybersecurity Framework、H.2.1(1)およびH.4(2)

   モバイルアプリにとっての意味

   受取人、リセット、連絡先情報の変更時のステップアップ認証は、不正を行う者が回避しようとする管理策です。アプリから何が送られてきても、サーバー側で機能しなければなりません。

   Ostorlabによる支援

   Ostorlabはテスト用アカウントでSMS、メール、TOTPによるワンタイムコードを入力し、攻撃者による操作の試みも含めて、MFAの強制とステップアップ認証のフローを、口座情報の変更の背後にあるAPI呼び出しとあわせてテストします。

   お客様が担うこと

   認証方式と、ワンタイムシークレットを送るチャネルの選定。

6. 06

   Cybersecurity Framework、G.3（7.4、7.6、8.3）およびH.3(5)

   要素を正しく数え、3回の失敗でロックアウトする

   条文の内容

   認証が多要素とみなされるのは、異なる要素の認証器を少なくとも2つ使用する場合に限られます。デバイスの検証、知識ベース認証、位置情報、行動バイオメトリクスは認証要素ではありません。電子決済サービスへのアクセスは、認証または認可の試行に最大3回失敗した時点でブロックしなければならず、一時パスワードは速やかに失効させなければなりません。

   出典：Cybersecurity Framework、G.3（7.4、7.6、8.3）およびH.3(5)

   モバイルアプリにとっての意味

   信頼済みデバイスとSMSコードは、両方を同時に入手できるのであれば2つの要素とは言えません。ロックアウトと失効はバックエンドで強制しなければなりません。

   Ostorlabによる支援

   認証後のテストでは、ログインとログアウト、トークンの更新、タイムアウト、セッションの無効化、MFAの強制を確認し、通信の解析によって認証情報がアプリからバックエンドへどのように送られるかを示します。

   お客様が担うこと

   パスワードポリシー、ロックアウトの期間、再有効化の手続き。

7. 07

   Cybersecurity Framework、I.3

   第三者に公開するAPIを保護する

   条文の内容

   情報アクセスと決済指図のプロバイダーについて、第三者はAPIを利用する前に認証されなければならず、相互TLSが強く推奨されます。同意を登録する前にユーザーを少なくとも2つの要素で認証し、クライアントはAPIレベルで認証し（OAuth 2.0とOpenID Connectを強く推奨）、ユーザーはいつでも同意を取り消せるようにします。

   出典：Cybersecurity Framework、I.3

   モバイルアプリにとっての意味

   アプリの背後にあるAPIとオープンAPIには、誰が呼び出しても、すべてのリクエストで機能する認可が必要です。

   Ostorlabによる支援

   OstorlabはTLSピンニングがあってもアプリの通信を傍受し、認可の不備（BOLA、BFLA、IDOR）、トークンとセッションの悪用、列挙、リプレイ、自動化などの不正利用についてAPIをテストし、各検出結果にリクエストとレスポンスの証拠を付けます。

   お客様が担うこと

   第三者のオンボーディング、VPN接続、同意管理、APIのリスクカタログ。

8. 08

   CBJ Guidance on Combating Financial Fraud in the National Payment System、内部統制手続き、C、D、G

   不正対策をアプリに組み込む

   条文の内容

   モバイルアプリへのアクセス、取引の実行、新しいデバイスでのアプリの有効化を含め、少なくとも2つの要素で顧客を認証し、SMSのOTPのみに頼ることは避けます。異常なセッションや、信頼されていないデバイスから新しい受取人への送金には、第3の要素を求めます。モバイルアプリは脱獄やroot化を検知し、アプリをブロックするか機密性の高い機能を制限すべきであり、同時ログインまたはデバイスの台数を制限すべきです。

   出典：CBJ Guidance on Combating Financial Fraud in the National Payment System、内部統制手続き、C、D、G

   モバイルアプリにとっての意味

   不正対策は、アプリと決済APIの中にあります。root化デバイスの検知、デバイスのバインディング、ステップアップのルールは、不正防御の一部です。

   Ostorlabによる支援

   Ostorlabは、アプリとそのAPIにある不正対策に関わる管理策をテストします。認証、ステップアップ認証、セッション管理、デバイスの保護、そして決済の背後にあるビジネスロジックです。

   お客様が担うこと

   取引モニタリング、不正対策部門、ブラックリスト、顧客への啓発。

9. 09

   Instructions No. (65/2016)、第9条および附属書5

   テストの証拠を監査人に示す

   条文の内容

   監査委員会と外部監査人は、毎年第1四半期中に、年次の内部IT監査報告書と外部IT監査報告書をCBJに提出します。監査プログラムは、特に、脆弱性評価とペネトレーションテストの効率性と十分性、電子チャネルと電子決済システムの運用管理策を対象とします。

   出典：Instructions No. (65/2016)、第9条および附属書5

   モバイルアプリにとっての意味

   監査人は、アプリがどのようにテストされ、何が見つかり、それが修正されたかを確認します。

   Ostorlabによる支援

   スキャン結果、再現手順付きの検出結果、再テストの結果により、アプリの管理策がリリースごとにどのようにテストされ修正されたかを、日付入りの記録として残せます。

   お客様が担うこと

   監査そのもの、ITガバナンスのフレームワーク、CBJへの報告。

公開されているCBJ文書の英語版の要約です（2026年9月27日時点で確認）。一部の文書は、記載のとおり特定のライセンスの種類に適用されます。本ページは法的助言ではありません。