ML エンジニア向けの AI リスク評価
ML システムをセキュリティで保護する納得のいく理由があるにもかかわらず、28 社の企業にまたがる Microsoft の調査では、業界のほとんどの実務家がまだ、敵対的な機械学習 (ML) に対処できていないことがわかりました。 28 社の企業のうち 25 社は、その ML システムをセキュリティで保護するための適切なツールが整備されていないことを示しました。 その上、それらの企業は明示的にガイダンスを探しています。 この準備不足は、小規模な組織に制限されるわけではなく、Fortune 500 企業から政府機関、さらには非営利組織にまでに及ぶことがわかりました。 お客様は AI システムをセキュリティで保護する必要性は認識していても、その方法がわからないだけです。
このドキュメントは、組織が自身の AI システムのセキュリティ体制を評価するための最初のステップです。 ただし、組織で従うべきさらに別のフレームワークを追加するのではなく、その内容を、既存の従来のセキュリティ リスク評価フレームワークに適用できる方法で提供しようと努めました。
このドキュメントには、次の 3 つの目標があります。
- AI システムのセキュリティに対する包括的な観点を提供する。 運用環境の設定での AI システムのライフサイクルの各要素 (データ収集から、データ処理、モデル デプロイまで) を調べました。 また、AI サプライ チェーンや、AI システムに関連するバックアップ、回復、コンティンジェンシー計画に関する制御とポリシーについても対処しました。
- 重要な AI 資産への脅威と、それらをセキュリティで保護するためのガイダンスの概要について説明する。 エンジニアやセキュリティの専門家を直接支援するために、AI システム構築プロセスの各ステップでの脅威ステートメントを列挙しました。 次に、既存の手法を AI システムのコンテキストでオーバーレイして補強する一連のガイドラインを提供します。
- 組織が AI セキュリティ リスク評価を実行できるようにする。 このフレームワークは、組織内の AI システムのセキュリティの現在の状態に関する情報を収集し、ギャップ分析を実行して、セキュリティ体制の進行状況を追跡するに役立ちます。
Microsoft では、これを Microsoft 全体にわたる利害関係者、つまり Azure セキュリティ、エンジニアリングにおける責任ある AI 戦略、Microsoft Security Response Center、Azure セキュリティ、エンジニアリングと研究における AI、倫理、および影響 (Aether) の各担当者と協力して策定しました。
はじめに
このドキュメントを使用して、継続的な情報セキュリティの取り組みやビジネス目標と整合した AI システムのセキュリティ保護に関するディスカッションを開始することをお勧めします。 AI システムは従来の IT インフラストラクチャの上に構築されているため、このドキュメントでは、AI システムと、従来の制御を含めることに重点を置いています。
ここでは、AI システムに関連する次の領域について説明します。
| 管理者向けの制御 | 説明 |
|---|---|
| 機械学習のセキュリティ ポリシー | 機械学習、人工知能、情報セキュリティを管理する文書化されたポリシーに関連する制御とポリシー。 |
| 技術的な制御 | 説明 |
|---|---|
| データ コレクション | 機械学習と人工知能に使用されるデータの収集、格納、分類に関連する制御とポリシー。 |
| データ処理 | 機械学習と人工知能に使用されるデータの処理とエンジニアリングに関連する制御とポリシー。 |
| モデル トレーニング | モデルの設計、トレーニング、検証に関連する制御とポリシー。 |
| モデル デプロイ | モデルとサポート インフラストラクチャのデプロイに関連する制御とポリシー。 |
| システム監視 | 機械学習システムの継続的な監視に関連する制御とポリシー。 |
| インシデント管理 | AI システムに関連するインシデントが処理される方法に関連する制御とポリシー。 |
| 事業継続とディザスター リカバリー | モデルの盗難、サービスの低下、またはその他の AI 固有の脆弱性による知的財産の損失に関連する制御とポリシー。 |
Microsoft では、一般的な ISO27001:2013 標準の制御とポリシーの既存のフレームワークを適応し、それを AI システム構築プロセス全体にわたって (データ収集の段階から AI システムへの脅威に対する対応まで) マップしました。 組織は、ISO27001:2013 から実装された既存の制御の一部またはすべてを備えているか、または既存の情報セキュリティの取り組みの一部として、いくつかのリスク フレームワーク (NIST 800-53、PCI-DSS、FedRamp など) に既に準拠している可能性があります。
AI システムを適切にセキュリティで保護できないと、この評価で対処される AI システムだけでなく、より一般に情報技術やコンプライアンス環境全体にまでリスクが増加します。
このドキュメントの目標は、これらの既存の取り組みのいずれかを置き換えることではなく、AI システムのセキュリティ保護を既存のツールとフレームワークの観点から説明し、それを AI 構築プロセスのすべての部分に拡張することです。
ここに示されているガイダンスは規範的ではありません。それには、基になるプラットフォーム、基になるデータの種類、アルゴリズムの選択などのより多くのコンテキストが必要になります。 Azure Machine Learning のお客様の場合は、エンタープライズ セキュリティとガバナンスに関する記事を参照してください。
推奨される重大度、可能性、影響
すべての制御が AI システムのセキュリティにとって決定的に重要であるわけではありません。 そのため、作業に適切に優先順位を付けるために、組織は、特定の制御を実装しないことのビジネスへの影響に関連する重大度の評価を使用して各制御を評価する必要があります。 ある組織は、重要な制御のリスクを受け入れ、代わりに、リスクを減らすための補完的な制御を実装することを選択する可能性があります。 最終的に、これらの評価はアクティビティを規定するためではなく、リスク ベースの意思決定を導くために役立ちます。
重要度
侵害の重大度は、AI モデルのユース ケースによって異なります。 幸いにも、使用されているデータまたはシステムが、機械学習が統合される前に重大な懸念事項であった場合は、それを同じままにする必要があります。 同様に、使用されているモデルが他の入力のない "市販" のものである場合、そのモデルが使用されているコンテキストによっては、侵害の重大度は低くなる可能性があります。 差分プライバシーなどの手法によって、侵害の潜在的な影響が軽減される場合があります。 ただし、このコンテキストでは、システム、データ、またはモデルの重要度は低下しません。 いずれか 1 つの防御的な実装に依存するのではなく、多層防御戦略を使用してモデルを保護することをお勧めします。
推奨される重大度レベル
重大として推奨される場合
- AI モデルが機密の個人データ、分類されたデータ、または PCI、HIPAA、GLBA などのコンプライアンス要件によって管理されるデータでトレーニングされているか、またはそれらのデータを取り込む場合
- AI モデルが、侵害がビジネス運用に大きな悪影響を与えるビジネス クリティカルなアプリケーションまたはシステムで使用されている場合
- AI モデルが、物理的な危害または死亡が可能性のある結果であるアプリケーションで使用されている場合
- AI モデルが重要なインフラストラクチャ (水、電力、健康など) をサポートするシステムで使用されている場合
高として推奨される場合
- AI モデルが機密の個人データ、機密情報、または通常であれば組織によって重要と見なされるデータでトレーニングされているか、またはそれらのデータを取り込む場合
- この AI モデルの侵害がビジネス運用に大きな、ただしスコープ指定された影響を与える場合
- AI モデルがビジネス クリティカルなアプリケーションまたはシステムで使用されている場合
中として推奨される場合
- AI モデルが、機密データの種類が含まれているトレーニング データのサブセットでトレーニングされている場合
- この AI モデルの侵害が運用環境にデプロイされたモデルに影響を与える場合
- AI モデルが、重要度は低いが、ビジネス向けのアプリケーションで使用されている場合
- AI モデルが運用環境で使用されていないが、運用モデルに関連した情報を持っている場合
低として推奨される場合
- AI モデルが、運用環境で使用されていないデータでトレーニングされている場合
- AI モデルが運用環境で使用されておらず、運用モデルに関連した情報も持っていない場合
情報として推奨される場合
- データが検査されたソースから分類されていない場合
- AI モデルが運用環境で使用されていない場合
Likelihood
可能性には、モデルの可用性と手法の可用性という 2 つの主要な構成要素があります。 攻撃の可能性を減らすために、組織は、次のような制御を実装する必要があります。
- 攻撃面を削除するか、または攻撃面を列挙しにくくする。
- 問題が確実に迅速に解決されるように、ログ記録やアラート生成が設計どおりに機能していることを確認する。
- すべてのサポートしているシステムがセキュリティ要件に関して最新の状態になっていることを確認する。
制御には、ゲーティング エンドポイント、ネットワークのセグメント化、またはレート制限が含まれる場合があります。 トラフィック フローやネットワークまたはパイプライン図には特別な注意が必要です (侵害している攻撃者、外部向けのエンドポイント、パイプラインを経由した逆方向の処理など)。
影響
影響は、組織に与える影響に関連しています。 ML システムが攻撃される可能性のあるさまざまな方法に習熟することから始め、運用モデルが組織に影響を与える場合がある方法を検討することをお勧めします。 詳細については、「機械学習の障害モード」の記事を参照してください。 この習熟が完了したら、それを重大度マトリックスにマップできます。
重大度マトリックス
次の表は、組織の運営を開始するための基本的なリスクと脆弱性の重大度マトリックスです。 セキュリティ アーキテクト、機械学習エンジニア、AI レッド チーム メンバーを招集して、同様の分類を完成させることをお勧めします。
| 攻撃の種類 | Likelihood | 影響 | 悪用可能性 |
|---|---|---|---|
| 抽出 | 高 | 低 | 高 |
| 回避 | 高 | Medium | 高 |
| 推論 | Medium | Medium | Medium |
| 反転 | Medium | 高 | Medium |
| ポイズニング | 低 | 高 | 低 |
"セキュリティで保護された AI の設計と開発は、BCG における AI 製品開発の礎石です。 AI システムをセキュリティで保護する社会的な必要性がますます明らかになるにつれて、Microsoft の AI セキュリティ リスク管理フレームワークのような資産が基礎的な貢献になる可能性があります。 私たちは既に、このフレームワークで見つかったベスト プラクティスをクライアント向けに開発する AI システムに実装しており、Microsoft が全体業界の利益のためにこのフレームワークを開発してオープン ソース化したことを嬉しく思っています。" —Jack Molloy、シニア セキュリティ エンジニア、ボストン コンサルティング グループ
基本的な使用
このドキュメントの残りの部分は、次の構造に従っています。
- リスク制御には、この制御でどの領域が対応されるかについての説明が含まれています。
- この制御の目的と、それによって実現されると想定される内容。
- 軽減されるリスクについて説明している脅威ステートメント。
- 制御を実装するためのガイダンス。 Microsoft では、正当なビジネス上の理由から、すべてのガイダンスを実装できるわけではないことを理解しています。 実装できないガイダンスを文書化することをお勧めします。
次の表は、AI システムのリスク評価から取得された制御であり、リスク カテゴリの構造の各部分を説明するためのメモが追加されています。
制御の例
それの読み取り方
1.データ収集
プライマリ カテゴリ
機械学習と人工知能に使用される、すべてのソースからのデータの収集と格納に関連する制御とポリシー。
大まかに、このカテゴリ内のどのような制御が対応するかについて説明します。
2.データ ソース
コントロール カテゴリ
目的: トレーニング済みのモデルに使用される収集されたデータの整合性を確保するため。
この制御で軽減されるリスクについて説明します。
脅威ステートメント: データが、機密の個人データや、モデルのセキュリティに影響を与える場合があるその他の望ましくないデータを含む可能性があるか、または組織にコンプライアンス リスクを発生させる信頼できないソースから収集されます。
この制御を実装しないことの結果を説明するステートメント。
制御: データは、信頼できるソースから収集する必要があります。 信頼できるソースの一覧を保持し、更新する必要があります。 信頼できないデータを収集するための承認は、ケース バイ ケースで検討する必要があります。
この制御のベスト プラクティスを説明する具体的な詳細事項。
ガイダンス:
- モデルのトレーニングの前にデータを確実に信頼できるものにするために、すべての妥当な取り組みを実施する必要があります。 信頼できないデータや不明なデータにより、後でパイプライン内にセキュリティの脆弱性が導入される可能性があります。
- 機密の個人データが含まれているデータは、データ サイエンスの目的で使用されるかどうかにかかわらず、適切にクリーニングまたは格納してアクセスする必要があります。
- データをそのコンテキストに対する考慮なしに収集すると、不正なデータが含まれたデータセットが得られる可能性があります。 データ収集の取り組みでは、著作権で保護された素材、データ侵害、データを誤って漏洩させるセキュリティで保護されていないエンドポイントに注意する必要があります。
ガイダンスは、上記の条件を満たすための推奨事項です。 Microsoft では、組織がそれぞれに妥当な方法で問題を解決する余地を残すために、これらを製品とベンダーに依存しない方法で提供します。
機械学習のセキュリティ評価
はじめる前に
この評価の目的は、組織が AI システムによって導入されたビジネス運用へのリスクを明確に表現し、追跡、修復できるように支援することです。 この評価は、次のために使用する必要があります。
- 組織内の AI セキュリティの現在の状態に関する情報を収集する。
- ギャップ分析を実行し、推奨事項を実装するためのロードマップを構築する。
- この評価を毎年または半年ごとに実行することによって、セキュリティの進行状況を追跡する。
組織にセキュリティ プログラムがない場合、この評価は開始点になりません。 組織は、この評価の推奨事項を実装する前に、機能する情報セキュリティ プログラムを用意する必要があります。 詳細については、クラウド導入フレームワークにある Azure のセキュリティ ガイダンスに関する記事を参照してください。
データ コレクション
機械学習と人工知能に使用される、すべてのソースからのデータの収集と格納に関連する制御とポリシー。
目的: AI システムで使用される収集されたデータの整合性を確保するため。
データ ソース
制御: データは、信頼できるソースから収集する必要があります。 信頼できるソースの一覧を保持し、更新する必要があります。 信頼できないデータを収集するための管理者の承認は、ケース バイ ケースで検討する必要があります。 信頼できないソースが承認された場合は、それを文書化する必要があります。
脅威ステートメント: データが、機密の個人データや、モデルのパフォーマンスに影響を与える場合があるその他の望ましくないデータを含む可能性があるか、または組織にコンプライアンス リスクを発生させる信頼できないソースから収集されます。
ガイダンス:
- 入力データは、AI システムで使用する前に、管理者の承認によって検証され、信頼される必要があります。
- AI システムのために収集されたデータは、使用または格納する前にレビューする必要があります。
- 必要に応じて、収集されたデータは、望ましくないエントリをクリーニングする必要があります。
- データのソースは文書化し、そのデータと共に保持する必要があります。
- モデルをトレーニングするために使用される推論データは暗黙的に信頼するべきではなく、新しいデータとして扱う必要があります。
- データ収集の取り組みは文書化し、監査する必要があります。 収集されたデータには、文書化されたポリシーへの準拠に責任を負う所有者が含まれている必要があります。
機密データの種類
制御: AI システムのために格納されたデータが、その機密度とユース ケースに従って適切にセキュリティで保護、追跡、分類されていることを確認するため。 この制御には、適切なデータ分類ラベル、アクセス ポリシー、ライセンス情報、説明的な統計情報、発信元のソース、収集の日付が含まれます。
脅威ステートメント: AI システムで使用されるデータが、必要な属性、メタデータ、またはドキュメントがないため、誤って使用、格納、またはアクセスされます。
ガイダンス:
- 機密データの種類のプライバシーと保護を含むデータ ポリシーを開発し、そのポリシーを AI システムの使用または作成に関連するすべての担当者に伝達します。
- AI システムで使用されるデータの機密性と整合性を保護するトレーニングおよびデプロイ パイプラインを実装します。
データ ストレージ
制御: データは、文書化された分類プロセスに従って適切に格納する必要があります。 データセットはインデックスを作成し、資産管理およびアクセス制御ポリシーに制約される資産と見なす必要があります。
脅威ステートメント: データが安全でない方法で格納されているため、認可されていない関係者またはシステムによって改ざんまたは変更される可能性があります。 データが適切に分類されていないため、機密情報または機密の個人データの開示につながります。
ガイダンス
- 開発または AI 研究のシステムまたはアカウントが運用データベースにアクセスできないことと、その逆を確認します。
- AI システムで使用されるデータは、文書化された分類ポリシーに従って分類および保護する必要があります。
- AI システムで使用されるデータは、文書化された資産管理ポリシーのもとに追跡されます。
- 機密性の高い AI ユース ケースに使用されるデータは、承認および管理されたシステムに格納されます。
- データへのアクセスを監査する必要があり、アクセスを要求するユーザーは、管理者の承認を含む正式なアクセス制御プロセスを経る必要があります。
- 機械学習プロセスで使用されるデータをインターネットに公開するべきではありません。
- インターネット (またはその他の信頼できないソース) から取得されたデータは、管理者の承認を含むフィルター処理プロセスを経る必要があります。
- データセットは、正式な変更制御プロセスが設定された状態でバージョン管理する必要があります。
データ アクセス
制御: データセットは、使用する前に、暗号化ハッシュによって適切に追跡および検証する必要があります。
脅威ステートメント: データセットが認可なしで変更されます。
ガイダンス:
- データセットに対してロールベースのアクセス制御を適用する必要があります。
- 定期的なアクセス監査を実行して、データセットへのアクセス権を持つアカウントがデータセットにアクセスできることを確認します。 各アカウントが通常の範囲内で動作していることを確認します。
- 中央の追跡プラットフォームが使用されていない場合は、生のアクセス ログを経由したデータへのアクセスの目的をレビューする必要があります。 各アカウントが通常の範囲内で動作していることを確認します。
- サード パーティ リソース プロバイダー、請負業者、またはその他の外部関係者には、契約を締結することなく、会社のトレーニングまたはテスト用データ資産への過剰または不適切なアクセス権を与えるべきではありません。
データ整合性
制御: データセットは信頼され、AI システムのライフサイクル全体にわたって信頼されたままである必要があります。
脅威ステートメント: データセットが、変更を監査または追跡する機能なしで、AI ライフサイクル中に変更されます。
ガイダンス:
- 承認されたデータセットへの認可されていない変更によって、そのデータセットのレビューが実行されるように、データセットを一意に識別する必要があります。
- データセットとその暗号化の説明は、中央の場所で追跡する必要があります。 データセットへのアクセスを監査する必要があります。
- データセットへの変更には、中央の追跡サービスに送信される前に、更新された暗号化の説明と管理者の承認が含まれている必要があります。
データ処理
機械学習と人工知能に使用されるデータの処理に関連する制御とポリシー。
目的: データのその未加工の形式から、トレーニングの準備ができている中間形式へのセキュリティで保護された処理を確保するため。
処理パイプライン
制御: 処理パイプラインは、適切にセキュリティで保護する必要があります。
脅威ステートメント: 脅威アクターは、データ処理パイプラインを変更することによって、システムへの認可されていない変更を行うことができます。
ガイダンス:
- 運用システム内を移動するすべてのデータがデータ サイエンスの取り組みに関連するわけではありません。 必要なデータのみを解析し、セキュリティで保護された運用環境の設定から開発設定に移動されたすべてのデータが確実に適切に追跡されるようにすることが重要です。 特定の種類のデータは、開発環境に移動できない可能性があることを考慮してください。 データ サイエンスをセキュリティで保護された中間環境で実行することが必要になる場合があります。
- データ処理のライフサイクル全体にわたるデータ アクセスの適切な監査が重要です。 個別のアカウントがないと、アクセスの十分な監査を実行できない場合があります。 さらに、ビジネス プロセスへの潜在的な影響なしに、インシデントに対応する機能を実行することはできません。 1 つのアカウントの侵害により、セキュリティで保護された運用環境から送信されるすべてのデータの侵害が発生します。
- データ サイエンス プロセスには、厳密なコンプライアンス境界の外部にあるリソースが必要になることがあります。
- データ サイエンス プロセスは常に、既存の要件に準拠している必要があります。 このプロセスには、データ サイエンス リソースおよびプロセスの準拠環境への移動が含まれる可能性があります。
- データは、そのライフサイクル全体にわたって追跡する必要があります。この追跡には、より大きなデータセットのサブセットが含まれます。 モデルを、それがトレーニングされたデータまで遡ってトレースできることが必要です。 さらに、そのデータのコピーが完全な状態で存在する必要があります。
データセットの切り口
制御: モデルの構築のために含まれているデータのサブセット (一時的なカテゴリ別のスライスなど) と、それがセキュリティの危険 (フィードバックでの過度の強調によるプライバシーの漏洩、ポイズニングまたは整合性など) を知らせる可能性を確保するため。
脅威ステートメント: 脅威アクターは、データのサブセットを再構築または回復することによってデータの一部を回復できます。
ガイダンス:
- データのサブセットは、それ自体がデータセットです。 これらのサブセットは、親データセットと同じメタデータが添付されている必要があり、同様に機密データの種類がないかどうかレビューされる必要があります。
- 機械学習の手法に関連したポリシー (SLA、偏りのメトリックなど) によっては、特定のデータセット (サブセットを含む) はすべて、モデルの構築で使用される場合、これらのメトリックに関する最小限の文書化された標準を満たす必要があります。 データセットには、常にメタデータを添付する必要があります。
- 既存のポリシーに違反するデータセットにはすべて、管理者によって承認されている文書化された例外が必要です。 その例外には、必要なメタデータに加えて、例外の文書化された理由が含まれている必要があります。
- モデルの構築に使用されるデータはすべて、中央の場所で追跡する必要があります。 データは、いつでも監査できる必要があります。 さらに、追跡対象外のデータでトレーニングされることがわかったモデルは、必要なメタデータを含む既知のデータセットと一致するまで運用環境から取得する必要があります。
- データセットは、すべてのメタデータが更新され、データのユーザーがその内容と統計プロパティを理解できるように、適切にバージョン管理する必要があります。 必要に応じて、機密のユース ケースには管理者の承認を必須とする必要があります。
モデル トレーニング
モデルとアルゴリズムのトレーニングに関連する制御とポリシー。
モデルの設計
制御: モデル トレーニング コードは、責任者によってレビューされます。
脅威ステートメント: モデル コード内の不適切なコードや脆弱性によって、可用性、整合性、または機密性のリスクが生成されます。
ガイダンス:
- モデルの設計や研究は、適切な環境で行われる必要があります。 モデルの設計やアーキテクチャがモデルの有効性に大きな影響を与える場合があります。 運用環境は、研究の場でも、設計の有効性に関する立証不可能な主張をテストするためのものでもありません。
- 運用システムのためのモデルの選択は、管理者がレビューして承認する必要があります。 このプロセスは開発段階の早い時期に実行し、使用可能な任意のメカニズム (Excel、DevOps、Git など) を使用して追跡する必要があります。 例外は文書化する必要があります。
- 多くの場合、モデルはドメイン固有であるため、組織でのその使用期間全体にわたってモデルに十分なドキュメントが付属している必要があります。
- モデルのメタデータにユーザーがアクセスできることと、モデルの承認されていない使用が文書化して適用されることを確認します。 新しいメタデータが適切に添付して追跡されている限り、ユーザーが既存のモデルを微調整することは許容されます。
モデル トレーニング
制御: モデルの選択基準 (メトリックと予約セット) は、デプロイ時に予測される可能性がある自然なドリフトとすべての敵対的な条件を模倣します。
脅威ステートメント: 理想的な条件のもとでトレーニングされたモデルは、敵対的な設定でデプロイされた場合は脆弱である可能性があります。
ガイダンス
- トレーニングおよび検証セットでは、自然な一時的な依存関係を考慮する必要があります。 たとえば、マルウェア分類子の場合は、検証セットに、トレーニング セットに含まれているものより後のソフトウェア バージョンのみを含める必要があります。
- インターネット上で当然検出される可能性がある一般的な破損を使用してデータセットを強化することによって、モデルの堅牢性を明示的に追加します。
- 敵対的な再トレーニングを使用して、明示的に最悪の条件でトレーニングします。
- 実験とそれに関連付けられているメタを追跡します。
モデルの選択
モデルの選択は、一連の候補からの 1 つのモデルの選択で構成されます。ここで、各候補には、モデル パラメーター、トレーニング アルゴリズム、トレーニング ハイパーパラメーターの固有のセットがあります。 優れたモデルの選択基準は多くの場合、一般的な予約データセットで測定されるか、または K フォールド検証セット全体で平均された 1 つの定量化可能なメトリック (最小損失、最大検出率など) に基づいています。
制御: モデルの設計とトレーニング アルゴリズムには、明示的または暗黙的なモデルの正則化が含まれます。
脅威ステートメント: モデルがトレーニングまたは 1 つの検証データセット、あるいはその両方に過剰適合しており、障害モードに対してより脆弱になっています。
ガイダンス:
- 計算的に可能な場合は、K フォールド クロス検証を使用して 1 つの予約セットへの過剰適合を防止する必要があります。
- 選択されたモデルが過剰適合していないことを検証するには、それらが異種の予約セットで適切に動作していることを確認します。
- プロセスが存在することを確認します。
モデルのバージョン管理
制御: モデルは、新しいトレーニング データがトレーニング パイプラインに流れると、継続的に再トレーニングされます。
脅威ステートメント: インシデントが発生しますが、関連するモデルを調査のために見つけることができません。
ガイダンス:
- モデルがトレーニングされるたびに、新しいバージョンが割り当てられるようにモデルをバージョン管理します。 運用環境のモデルを運用前環境のモデルから区別するには、my_model_dev_1.1 や my_model_prod_1.1 などの修飾子を使用する必要があります。 このバージョン管理は、問題を運用環境または運用前環境のどちらかの問題に分離するのに役立ちます。 既存のセキュリティで保護された SDL プロセスまたはポリシーを参照します。
モデル デプロイ
モデル、アルゴリズム、サポート インフラストラクチャのデプロイに関連する制御とポリシー。
セキュリティ テスト
制御: 運用環境に移行されたモデルは、適切にセキュリティで保護されます。
脅威ステートメント: AI システムが、デプロイの前に、脆弱性を十分にテストされていません。
ガイダンス:
- 新しい AI システム、アップグレード、新しいバージョンに対して、正式な受け入れテストの条件が定義および文書化されていません。
- 新しい AI システム、アップグレード、または新しいバージョンは、正式なテストを使用して実装する必要があります。
- 情報システム、アップグレード、または新しいバージョンのテストには、自動ツールを使用する必要があります。
- テスト環境は、最終的な運用環境にきわめて類似したものにする必要があります。
- 独立したセキュリティ レビューの頻度、範囲、方法を文書化する必要があります。
セキュリティとコンプライアンスのレビュー
制御: 基になるネットワークの堅牢な管理は、ML システムとインフラストラクチャのセキュリティ保護にとって重要です。
脅威ステートメント: セキュリティで保護されていないネットワークへのアクセスによる ML システムの侵害。
ガイダンス:
- ML システムへのゲートウェイ デバイスは、ドメイン間のトラフィックをフィルター処理し、認可されていないアクセスをブロックするように構成する必要があります。
- 関連する法定要件、規制要件、契約上の要件は、明示的に定義および文書化し、特定の制御や個々の責任と共に対処する必要があります。
- セキュリティで保護された構成ガイドラインも文書化、実装、またはレビューする必要があります。
- ML ネットワークをドメインに分離するための基準は、組織のアクセス制御ポリシーまたは組織のアクセス要件と整合性のあるものにする必要があります。
- 段階的な制御のセットを可能にするために、セキュリティで保護されたゲートウェイ、VPN、ML システムのルーティングなどのメカニズムを十分に実装する必要があります。
- ユーザーと ML エンジニアは、パブリックにアクセス可能なシステム、内部ネットワーク、重要な資産の使用を適切に分離および制限するために、制御の実装に関する要件を採用するか、またはそれに従う必要があります。
システム監視
機械学習システムとサポート インフラストラクチャの継続的な監視に関連する制御とポリシー。
ログとログ レビュー
制御: ログ記録と監視は、セキュリティ上の理由から ML システムにとってきわめて重要です。
脅威ステートメント: 調査中に、ML システムのログが見つかりません。
ガイダンス:
- ログ記録と監視は、すべての AI システムとそのコンポーネント (ストレージ、パイプライン、運用サーバーなどを含む) にまたがって一貫して実行する必要があります。
- イベントおよびセキュリティ ログは、異常な動作がないかどうか定期的にレビューする必要があります。
- システム アクティビティに関する統合レポートとアラートは、管理者またはセキュリティ担当者が生成およびレビューする必要があります。
インシデント管理
ロールと責任
制御: セキュリティ ログは、中央の場所で収集する必要があります。
脅威ステートメント: 調査中に、セキュリティ アナリストが形式化されたプレイブックを所持していません。
ガイダンス:
- 組織は、サービスの損失、機器の損失、施設の損失、システムの誤動作、システムの過負荷、人的エラー、ポリシーまたはガイドラインに関するコンプライアンス違反、物理的なセキュリティの侵害、制御されていないシステム変更、ソフトウェアの誤動作、ハードウェアの誤動作、アクセス違反の各コンテキストで AI システムのインシデントを報告するための正式なプロセスに従う必要があります。
- 正式なインシデント対応およびエスカレーション手順を開発して、情報セキュリティ イベントのレポートを受信したときに実行するアクションを文書化する必要があります。
- インシデント対応手順を定期的にテストし、応答のメトリックを追跡する必要があります。
事業継続計画
計画、レビュー、結果
制御: インシデント後に、ML システムを修復して回復できることを確認します。
脅威ステートメント: インシデントにより、重要な ML システムに対する永続的な機密性、整合性、または可用性の問題が発生します。
ガイダンス:
- 重要な AI 資産を識別してインベントリする必要があります。
- 組織は、AI システムに対する攻撃が発生した場合のビジネス継続性計画 (BCP) またはディザスター リカバリー (DR) プロセスを開発する必要があります。
- 組織は、攻撃に対して重要な AI システムを失うことの影響に関連する優先順位付けされたリスクを識別する必要があります。
- 組織には、重要な AI システムに対して繰り返しのスケジュールで運用されるビジネス継続性のテストが必要です。
関連情報
- ISO 27001 付録 A 制御 - 概要 (isms.online)
- PCI Security Standards Council の公式サイト
- 機械学習の障害モード
- AI/ML システムと依存関係の脅威のモデル化
- AI/ML からセキュリティ開発ライフサイクルのバグ バーへのピボット
- エンタープライズ セキュリティとガバナンス
質問、コメント、またはフィードバックがある場合は、atml@microsoft.com にお問い合わせください。
GitHub リポジトリから、このドキュメントの PDF をダウンロードしてください。