少し年齢がばれるが、脆弱性管理の黎明期にITとサイバーセキュリティの現場で泥臭い仕事をしていた。スキャンを実行して結果を報告し、それなりに生産的だと感じていた。だが現実には、見えているものしかスキャンしていなかった。特定のエンドポイントに対する認証情報がなければ、実際にスキャンしているわけではない。玄関の鍵を確認して、それで終わりにしていただけだった。
私は10年以上前から、攻撃の大半は「侵害の瞬間」においては「内部者による攻撃」だと言い続けてきた。攻撃者は侵害された認証情報を使う。フィッシング、クレデンシャルスタッフィング（流出したID・パスワードの組み合わせを使った不正ログイン攻撃）など、入手経路はさまざまだ。侵害が起きる時点では、それらは「正規の」ユーザーとして行われる。これが、スキャンと防御の考え方を一変させた。未認証スキャンが語るのはストーリーの一部、しかもごく一部にすぎないということを意味した。
この教訓はネットワークとWebアプリケーションの領域では十分に学び取られている。だがモバイルはどうか。モバイルアプリのセキュリティはいまだ同じ罠にはまり続けている。そして、それは多くの組織が認識しているよりもはるかに大きな問題である。
触れられないものはテストできない
根本の問題は極めて単純だ。モバイルアプリのセキュリティテストの多くはログイン画面を超えられない。テストツールが認証できないため、ログイン前に見える範囲しか分析しない。推計によっては、モバイルアプリの実際の攻撃対象領域（アタックサーフェス）の最大95%が未検証のままだという。金融取引、個人データ、内部API、規制対象情報といった機微な領域はすべてログインの裏側にある。ログイン画面が存在する理由はまさにそこにある。そして、ほとんどのセキュリティテストが飛ばしてしまうのも、まさにそこなのだ。
最近、アラン・スナイダー氏（NowSecure CEO）とモバイルアプリのセキュリティ課題について話す機会があり、この点は会話の中で繰り返し出てきたテーマだった。静的解析はアプリのコード全体を見渡せるため有用である。だがスナイダー氏が指摘したように、動いているデータは、実際に動かさない限りテストできない。ユーザーがクレジットカード番号を入力するワークフローがあるなら、データが安全に扱われているかを知るには、実機でそのワークフローを実際に動かしてみる必要がある。ソースコードを読むだけでは判断できない。アプリを動かし、実ユーザーと同じように操作し、何が起きるかを見る必要がある。そのためにはログイン画面を通過しなければならない。
回避策は常に苦痛を伴ってきた。アプリのUIが変わるたびに壊れるカスタムスクリプト。年1回しか実施できないほど高コストな手動のペネトレーションテスト（侵入テスト）。あるいは制約を受け入れ、できる範囲だけをテストする。いずれも望ましい選択肢ではない。モバイルアプリの数と複雑さが増え続ける中で、状況はさらに悪化している。
侵害された認証情報とモバイルの盲点
過去2年間、侵害成功の手口の1位は「侵害された認証情報」だった。VerizonのDBIR、Googleの脅威レポート、Mandiantの調査結果はいずれも同じことを示している。侵害された認証情報に対する一次防御は認証だ。MFA（多要素認証）の実装、ログインワークフロー、セッション管理がそれに当たる。これらをテストしていないなら、最も一般的な攻撃ベクトルに対する防御をテストしていないのと同じである。スナイダー氏はこの点について、シンプルだが効果的な主張をした。ログイン画面には理由がある。機微な領域を守るためにある。セキュリティテストがそこを超えないなら、本当に重要なものをテストしていないことになる。
ここでモバイルは、本来そうあるべきではない形で見過ごされてしまう。組織はモバイルを二次的な懸念事項、Webアプリの小さな画面版として扱いがちだ。だがバックエンドシステムへの認証済みアクセスを持つモバイルアプリは、Webアプリと同様に、それらのシステムへの入口である。攻撃者はWebの正面玄関から入るか、モバイルの正面玄関から入るかなど気にしない。どちらか一方から入れればよいだけだ。
データは、これが単なる理論上のリスクではないことを示している。Enterprise Strategy Group（現在はOmdiaの一部）とGuardsquareによる調査では、過去1年に少なくとも1件のモバイルアプリ関連のセキュリティインシデントを経験した組織は62%に上り、1組織あたり平均9件だった。金銭的影響は1回の攻撃あたり100万ドルから2000万ドルで、平均はおよそ700万ドルに着地している。
メリンダ・マークス氏（Omdiaのサイバーセキュリティ担当プラクティスディレクター）は次のように述べている。「企業は業界を問わず、モバイルアプリを通じて外出先でもアプリケーションを使える利便性を顧客に提供したいと考えています。しかし、とりわけモバイルアプリケーションについては、開発したアプリケーションに厳格なセキュリティテストを常に施しているとは限りません。多くのアプリケーションに決済が含まれているため、攻撃者にとって狙う価値の高い標的になり得ます」
さらに、偵察（リコン）という観点では、モバイルはむしろ魅力的なベクトルだという議論もある。スナイダー氏は、頻繁に目にするパターンをこう説明した。攻撃者は企業のモバイルアプリをダウンロードし、自分のデバイス上でリバースエンジニアリングし、組織のAPIを列挙する。すべてローカルで行える。Webアプリへの攻撃ではファイアウォールやネットワーク監視が活動を検知する可能性がある一方、モバイルアプリの偵察は攻撃者のハードウェア上で起きるため、組織側には見えない。さらに、いまなお約20〜25%のアプリがデバッグシンボルを有効にしたまま出荷されており、それが偵察を容易にしているという。修正は簡単で、スイッチを切って無効化するだけだが、多くのチームが実行していない。
テレメトリーの問題
モバイルアプリに起因すると明確に断定された、SolarWinds級の侵害はまだ起きていない。これが、組織がモバイルセキュリティの優先度を下げても構わないと感じる理由の一部になっている。だが、より率直な評価は「おそらく分かっていないだけ」なのだと思う。多くの企業は、侵害をモバイルにまで遡って相応の確度で特定できるだけのテレメトリーを持っていない。私がこの点をスナイダー氏に投げかけると、彼も同意した。もちろん侵害はモバイル経由でも起きている。起きていないと考えるほうが非現実的だ。組織側が遡れないだけである。
こう考えてみてほしい。私のスマートフォンはOneDrive、Microsoft 365、Salesforceに接続している。デスクトップからアクセスするのと同じバックエンドシステムだ。もし侵害が私のスマートフォン経由で起きた場合、セキュリティチームのテレメトリーは、攻撃者がモバイルアプリから侵入したのか、デスクトップから侵入したのかを判別できるほど粒度が細かいだろうか。多くの場合、モバイルアプリには、その種の決定的証拠を提供できるだけの実行時テレメトリーがない。「証拠がないこと」は「存在しないことの証拠」ではない。可視性のギャップである。そしてセキュリティチームがすでに手一杯であるほど、測定しにくいリスクから目をそらすのは都合がよい。
知らぬ間に抱えているサプライチェーン
一般的なモバイルアプリの約70%はサードパーティーコードで占められている。SDK、ライブラリ、コンポーネントなど、アプリ開発者が書いたものではないコードだ。これはソフトウェアサプライチェーンであり、多くの組織が十分に追跡できていないサプライチェーンリスクを伴う。Gravy Analyticsの侵害は好例である。人気アプリに組み込まれたデータブローカーのSDKが位置情報やユーザー情報を収集し、消費者の意味ある同意がないまま、そして多くの場合そのSDKを組み込んだアプリ開発者の同意もないまま販売していた。「無料」のSDKが、誰にも気づかれないところで顧客データを収益化していたのだ。この件の報告を見たとき、私はこう思った。組織は、デプロイ後にそれらのコンポーネントが何をしているのかに十分注意を払っているのだろうか。SDKが更新され、振る舞いが変わったらどうなるのか。
規制も追いついてきている。カリフォルニア州をはじめ米国の各州、そしてEUはいずれも、ユーザー同意とデータ収集に関する要件を強化した。AppleとGoogleもアプリストアでより厳格なプライバシールールを適用している。これは前向きな進展だ。だが同時に、組織はアプリがデータをどう扱っているかを実際にテストする必要があることを意味する。自社コードがどうしているかだけでなく、サードパーティーコンポーネントが何をしているかも含めてだ。これは認証済みの動的テストなしには効果的に実行できない。
さらに、サプライチェーンの問題にAIを重ね合わせてみよう。組織は、自分たちが書いた30%のコードのどこにAIがあるかは把握できるかもしれない。だが残りの70%はどうか。スナイダー氏が述べたように、「モバイルアプリにAIが1つ入ることはない。20入る。これらのコンポーネントがすべてAIを追加していくからだ」。それぞれがデータをどう扱うかを精査する必要があり、またそれぞれが、静的解析だけでは見えない形でアタックサーフェスを拡大する。
モバイルはもはや二次チャネルではない
こうした状況を一層切迫したものにしているのが、世代交代である。私の家でもそれを目にする。末っ子は今年20歳になるが、ほぼすべてをスマートフォンでこなす。私なら反射的にノートPCで開くようなことでも、彼女は考えることなくモバイルで処理する。彼女が「スマホでこれやって」と頼むと、私は「リンクを送ってくれ、PCで開く」と返してしまう。あの画面で彼女がどうやってあれこれを成し遂げているのか、文字どおり理解できない。だが、外れ値は彼女ではない。私のほうである。
Adobeのアナリティクスデータによれば、直近のホリデーシーズンのデジタル小売売上のうち、モバイルが53%を占めた。その割合は毎年2〜3ポイント上昇している。年齢層が若いほど、モバイルファーストである可能性が高いだけでなく、モバイルオンリーである可能性も高い。このトレンドが続く年が増えるほど、事業にとってのモバイルアプリの重要性と、そこに向けられるセキュリティ上の注意の少なさとのギャップは、正当化しづらくなっていく。
NowSecure AI-Navigatorが認証のボトルネックに挑む
今回スナイダー氏と話すきっかけになったのは、NowSecure AI-Navigatorのローンチだった。認証のボトルネックに正面から対処する新機能である。NowSecureは約10年にわたりモバイルアプリのセキュリティテストを手がけ、期間の大半で認証済みテストを提供してきたが、そのプロセスは脆いスクリプトと手作業の設定に依存しており、アプリが更新されるたびに破綻していた。
AI-Navigatorは、AIを用いてログインプロセスを自動化する。セキュリティチームはプラットフォーム経由で認証情報を提供し、ボタンをクリックするだけでAIがアプリ内を遷移し、認証を処理する。アプリのバージョン間でUIが変わっても、自動で適応する。スナイダー氏によれば、早期導入企業ではテスト時間が90%以上短縮され、数日から数分へと縮んだという。
私は、AIに認証を扱わせることのセキュリティについて尋ねた。誰もがまず思い浮かべる疑問である。スナイダー氏は、AIはあくまでナビゲーションのためだけに使われると強調した。ログイン画面への到達方法を見つけ、アプリ内を辿るためだ。実際の認証情報の挿入は、まったく別の機能が担う。「認証情報がAIモデルに触れることは絶対にない。学習されることも、ログに残ることも、保存されることもない」とスナイダー氏は説明した。この種の分離は重要である。1つのセキュリティ問題を解決するために、別の問題を作り出してはならない。
認証済みの動的テストがモバイルアプリセキュリティの必須要件（テーブルステークス）になりつつあるのかも尋ねた。スナイダー氏は、マインドセットの転換はまだ必要だが、実務上の障壁は取り除かれたと述べた。「いまや、簡単で、速く、継続的にやっても非常に費用対効果が高い」と彼は言う。「以前存在した障壁はなくなった。それが大きなニュースだ」。AI-Navigatorは現在Android向けに提供されており、iOS対応もまもなくだという。
ギャップを埋める時だ
モバイルアプリは、もはや「あればよい」ものではない。多くの組織にとって、それは顧客が事業と接点を持つ主要な手段である。デジタル収益の半分超がモバイル経由で、しかもその割合が毎年上がり続けているのなら、モバイルアプリのセキュリティを二次的な関心事として扱うのは理にかなわない。
認証済みの動的テストを実行するためのツールは存在する。誤ればどれほどのコストを払うことになるかというデータもある。現時点で障壁になっているのは、それを実際に優先するという意思決定だけだ。
