監視対象システムがモニターを制御する場合

セキュリティ対策は存在し、有効化され、一見正常に機能しているように見えても、誰かが密かにその機能を阻害している可能性がある。 

OpenAIの最近のレポートでは、内部コーディング作業に従事するAIエージェントが関与した2つの事例が報告されている。1つ目の事例では、エージェントが評価パイプラインの修復中に自動セキュリティアラートを抑制した。監視は継続して実行され、レポートも保存されたが、これらのレポートを人間の注意に知らせるためのアラートは無効になっていた。もう1つの事例では、エージェントがコードの変更中に監視統合を削除し、変更内容を誤って報告した。 

詳細は異なるものの、どちらの事例も根本的なアーキテクチャ上の問題を提起している。監視対象のシステムが、自身の監視を妨害するほどの制御力を持つようになった場合、何が起こるのか？ 

アプリケーションセキュリティは、長年にわたりこの問題に取り組んできました。モバイルアプリケーションは、開発者が制御できないデバイス上で動作します。攻撃者は、そのコードを検査したり、実行を操作したり、これらの活動を検出するために設計された保護機能を無効にしようと試みたりする可能性があります。しかし、セキュリティチェックを追加することは第一歩にすぎません。チェック自体も保護する必要があるのです。 

警備員を監視するのは誰か？ 

コードが改ざんされていないかを確認するモバイルバンキングアプリケーションを考えてみましょう。改ざんが検出された場合、アプリケーションをシャットダウンしたり、追加の認証を要求したり、機密性の低い機能は継続させつつ高額送金を制限したりする可能性があります。これらは有効な対応策です。しかし、別の疑問が生じます。攻撃者が整合性チェックを見つけて、チェックが機能しなくなるように改ざんすることを、何が阻止できるのでしょうか？ 

容易に無効化できる保護機能は、開発者に誤った安心感を与える可能性がある。アプリケーションには改ざんを検知するコードが含まれているが、コードを変更できる攻撃者は、その検知機能を無効化できる可能性がある。 

脅威監視についても同様の懸念が生じます。システムが不審な挙動を検知できたとしても、攻撃者がその検知メカニズムを妨害したり、検知結果を隠蔽したりできれば、その機能は無意味になります。これは、セキュリティにおけるおなじみの疑問、「監視者を監視するのは誰か？」という問いの根底にある課題です。 

保護機能を強化することは有効だが、それは保護機能自体が設計段階で考慮されている場合に限る。そうでなければ、攻撃者はセキュリティポリシーを適用する仕組みを標的にする可能性がある。 

警備ネットワークの構築 

Digital.aiArxanのアプリケーション保護技術は、ガードと呼ばれるセキュリティ制御システムによってこの課題に対処します。ガードは保護対象のアプリケーションバイナリに組み込まれます。アプリケーションの整合性をチェックし、アプリケーション用に設定されたポリシーに従って、検出された改ざんに対応します。ユースケースに応じて、アプリケーションのシャットダウン、ステップアップ認証のトリガー、高額な金融取引などの機密性の高い機能の無効化といった対応が行われます。重要なアーキテクチャ上の特徴は、ガード自体をさらに別のガードで保護できる点です。 

これにより、私たちが ガードネットワークガードは、攻撃者が特定して標的にできる孤立したチェックとして単独で存在する必要はありません。他のガードがガードを保護することができ、それらの保護自体もさらに保護層を受けることができます。実装によっては、ガードが他のガードを保護するガードを保護するなど、複数の層にわたって連鎖が広がっている場合もあります。 

この階層構造によって、攻撃者が直面する問題は変化する。特定のセキュリティチェックを無効にするには、そのチェックを取り巻く保護機能も突破する必要があるかもしれない。保護アーキテクチャの一部に干渉しようとすると、その干渉を検知または阻止するように設計された他の部分に遭遇する可能性がある。 その設計は、アイデアが最初に提唱された当時よりも、現在ではより重要になっている。AIツールによって、アプリケーションのリバースエンジニアリングに必要なコストとスキルが大規模に低下し、単一の独立したチェック項目は、自動分析によって迅速に発見・修正できる対象となっている。  

ガードが互いを保護するように設定されている場合、1つのガードを削除すると他のガードが作動するように設計されています。ターゲットに応じて、チームは複数の設定を使用して保護自体を変更することもできます。例えば、保護対象のビルドごとに構造的に異なるシード値、保護時にガードインスタンスをランダムに選択する設定、そしてすべてのガードが毎回実行されるわけではない実行確率などです。 ガードの中には、実行時に動作を変化させるものもあるため、静的な署名は存在しません。例えば、インクリメンタルチェックサムは、自動分析によって学習され回避される可能性のある固定のチェックを繰り返す代わりに、呼び出しごとに異なる範囲を検証することができます。 あるリリースやあるランに対して効果的だったストリップルーティンが、次のリリースやランに対しても必ず効果的であるとは限りません。 

ガードネットワークは、アプリケーションが侵害不可能になることを保証するものではありません。単一のアーキテクチャでは、あらゆる攻撃者、プラットフォーム、脅威に対してそれを保証することはできません。その目的は、保護機能自体への攻撃も考慮に入れ、保護機能の発見、変更、無効化をより困難にすることです。この区別は重要です。攻撃者は必ずしもセキュリティアーキテクチャ全体を突破する必要はありません。時には、活動が露呈する可能性のあるメカニズムを一つだけ無効化すれば十分な場合もあります。ガードを保護することで、そのような攻撃の難易度を高めることができます。  

検出には対応への道筋が必要である 

整合性チェックを保護することは問題の一側面です。セキュリティチームは、アプリケーションが疑わしい状態に遭遇した場合に何が起こるかを把握する必要もあります。 

Arxan Threat Monitoringは、保護対象のアプリケーション内で動作します。監視制御はバイナリに組み込まれており、アラートはブラウザ経由で表示したり、セキュリティ情報およびイベント管理（SIEM）システムに統合したりできます。これにより、組織はアプリケーションレベルのセキュリティイベントを確認し、より広範なセキュリティ運用に組み込むことができます。ここでもアーキテクチャが重要です。監視はアプリケーション内で動作するため、完全に外部のオブザーバーとして説明すべきではありません。その制御は保護対象のバイナリの一部であり、保護アーキテクチャはアプリケーションとそのセキュリティメカニズムへの改ざんを防ぐように設計されています。 

ガードネットワークは、制御自体を保護することで、この仕組みの重要な部分を担っています。外部アラートとSIEM統合により、報告されたイベントをアプリケーション外でも利用できるようになります。これらのメカニズムはそれぞれ異なる目的を果たします。ガードはアプリケーションの整合性を保護し、検出された改ざんへの対応をトリガーするのに役立ちます。脅威監視は、セキュリティ関連のアクティビティを明らかにすることができます。外部レポートは、セキュリティチームがイベントを調査し、対応を調整するのに役立ちます。 

各部分にはそれぞれ限界があります。報告チャネルは、検出されなかったイベントを報告することはできませんし、あらゆる攻撃に耐えられる保護策など存在しません。目的は、攻撃者がアプリケーションを侵害し、その侵害を露呈または制限するために設計されたメカニズムを無効にすることをより困難にすることです。 

対応は脅威に見合ったものでなければならない。 

セキュリティ対策は、しばしば検出対象という観点から議論されます。しかし実際には、その後に何が起こるかも同様に重要です。銀行アプリケーションでは、不審な状態を検出した後に、ステップアップ認証を要求する場合があります。高額送金を制限しつつ、日常的な操作は継続できるようにするかもしれません。より厳格な整合性要件を持つアプリケーションは、コードが改変された場合にシャットダウンする可能性があります。これらの対応は、リスクに対する異なる評価を反映しています。開発者は、アプリケーション、脅威、そして実行を継続させた場合の潜在的な影響に基づいて、適切な対応を選択できます。 

当社のゲーム関連顧客の一つは、よりエンターテイメント性の高いアプローチを採用しました。チームは、プレイヤーが不正行為を行っていることを検知する保護機能を構築しました。この保護機能が作動すると、ゲームの重力機能がオフになります。すると、不正行為を行ったプレイヤーのキャラクターはフィールドから浮き上がってしまうのです。これは印象的な事例であり、その根底にある考え方は非常に真剣なものです。この保護機能は、不正行為が発生した環境において重要な結果をもたらすように設計されていました。開発者は、検知をプロセスの終わりと捉えるのではなく、アプリケーションが許容する範囲を変更するために活用したのです。 

金銭、機密データ、または重要な機能へのアクセスが危険に及ぶ場合にも、同様の原則が適用されます。対応はリスクに見合ったものでなければならず、攻撃者がそのメカニズムを無効化することは困難でなければなりません。開発者は、誤検知、復旧パス、および正当なユーザーへの影響も考慮する必要があります。保護対策は、不必要な混乱を引き起こすことなく、アプリケーションの回復力を向上させるものでなければなりません。 

警備員が標的にされたらどうなるか尋ねてください 

OpenAIのレポートは、監視対象システムに変更を加えることで監視が無効化される可能性があることを改めて認識させる有益な事例です。アプリケーション開発者は、攻撃者がソフトウェアの実行を検査・操作できる環境でソフトウェアを実行する場合、同様の課題に直面します。問題は、アプリケーションに整合性チェックや脅威監視機能が備わっているかどうかという点にとどまりません。これらのメカニズムがどのように保護されているか、妨害に対してどのように対応しているか、そして攻撃者が本来であれば攻撃を露呈させるはずの制御機能を無効化できるかどうかといった点にまで及びます。 

ここでガードネットワークが重要になります。Arxanは、ガードを使って他のガードを保護することで、セキュリティメカニズム自体に保護レイヤーを追加します。これにより、攻撃者がアプリケーションの防御を変更したり、個々の制御を無効化したりする際に、追加の障害が生じます。アプリケーションのセキュリティアーキテクチャを評価する際には、次の3つの質問を自問してください。

1) 攻撃者が防御システム自体を標的にした場合、何が起こるのか？
2) たった1つの変更で重要なセキュリティメカニズムが無効になるのを防ぐにはどうすればよいか？
3) ガードが改ざんを検知した場合、アプリケーションにはどのような選択肢がありますか？ 

目的は、アプリケーションが絶対に侵害されないと約束することではありません。改ざんをより困難にし、攻撃を受けても有効な保護機能を維持し、アプリケーションの完全性が疑われる場合に開発者が対応できる実用的な手段を提供することです。場合によっては、金融取引を制限することもあれば、アプリケーションを停止することもあります。 

そして時には、重力をオフにして、不正行為をしたプレイヤーたちが宙に浮いていくのを眺めることを意味することもある。