AI セキュリティ概要

要旨 - AI セキュリティをどのように対処するか？

このイニシアチブ (OWASP AI Exchange) についての詳細、貢献や参加の方法については ホーム をご覧ください。 カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/summary/

AI はとてつもない好機を与える一方で、セキュリティ脅威などの新たなリスクももたらします。そのため、潜在的な脅威とそれに対するコントロールを明確に理解した上で、AI アプリケーションに取り組むことが不可欠です。簡単に言えば、AI セキュリティに対処するための主な手順は以下のとおりです。

  • AI ガバナンス を導入します。

  • このドキュメントの AI セキュリティ資産、脅威、コントロールを使用して セキュリティプラクティスを拡張 します。

  • AI システムを開発する場合 (独自のモデルをトレーニングしない場合でも):

    • データおよび AI エンジニアリングを従来の (セキュア) ソフトウェア開発プラクティス に組み込みます。

    • このドキュメントで説明している脅威を理解して、適切なプロセス コントロール と技術的コントロールを適用します。

  • AI サプライヤ が適切なコントロールを適用していることを確認します。

  • データと権限を最小限に抑え、ガードレールや人間の監視などの監視を追加して、AI の 影響を制限 します。

AI システムは、たとえば、大規模言語モデル、線形回帰関数、ルールベースのシステム、統計ベースのルックアップテーブルなどがあることに注意してください。このドキュメント全体を通じて、どのような脅威とコントロールがどのような役割を果たすかが明確になっています。

このドキュメントについて

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/about/

このページでは AI セキュリティの概要を説明し、次のページでは AI に対するセキュリティの脅威とそれに対するコントロールに関する主要なコンテンツを攻撃対象領域ごとにまとめています。

  1. 一般的なコントロール: AI ガバナンスなど

  2. 使用による脅威: 回避攻撃など

  3. 開発時の脅威: データポイズニングなど

  4. 実行時のセキュリティ脅威: 安全でない出力

各ページの下部、または左側のサイドバーでページ間を移動できます。右側のサイドバーにはページ上のさまざまなセクションが表示されます。小さな画面ではメニューから移動できます。

ここでいうセキュリティとは認可されていないアクセス、使用、開示、中断、改変、破壊を防止することを意味します。改変には AI モデルの動作を望ましくない方法で操作することが含まれます。

AI Exchange イニシアチブは OWASP により採択されており、Rob van der Veer によって起こされました。セキュリティ標準の橋渡し役、Software Improvement Group のシニアディレクター、AI とセキュリティで 31 年の経験を持ち、AI ライフサイクルに関する ISO/IEC 5338 の主執筆者、OpenCRE の創設者であり、現在は CEN/CENELEC で EU AI 法に関するセキュリティ要件に取り組んでいます。

この資料はオープンソースの継続的デリバリによって常に進化しています。著者グループは 50 人の専門家 (研究者、実務家、ベンダー、データサイエンティストなど) で構成しており、コミュニティの他の人々も意見を述べることができます。貢献ページ を参照してください。 これは EU AI 法、AI セキュリティに関する ISO/IEC 27090、AI プライバシーに関する ISO/IEC 27091、OWASP ML Top 10、OWASP LLM Top 10 などの進行中の主要なイニシアチブへのインプットとして機能し、さらに多くのイニシアチブが世界中で一貫した用語と洞察から恩恵を受けることができます。

このページでは以下について取り上げます。

  • 脅威の概要

  • 脅威とコントロールのさまざまな概要: マトリックス、周期表、ナビゲータ

  • 関連する脅威とコントロールを選択するためのリスク分析

  • さまざまなトピックに関する議論 (... についてはどうですか): ヒューリスティックシステム、責任ある AI、プライバシー、生成 AI、NCSC/CISA ガイドライン、著作権

脅威の概要

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/threatsoverview/

脅威モデル

私たちは三つのタイプの脅威を区別します:

  1. 開発時 (データを取得および準備し、モデルをトレーニング/取得するとき)

  2. モデルの使用 (入力の提供と出力の読み取り) を通じて

  3. 実行時 (本番環境) にシステムへの攻撃によって

AI では、3 つのタイプの攻撃者の目的 (開示、欺瞞、妨害) に対して、6 つのタイプの影響を区別します:

  1. 開示: トレーニングデータやテストデータの機密性が損なわれる

  2. 開示: モデル知的財産 (モデルパラメータ やそれにつながるプロセスとデータ) の機密性が損なわれる

  3. 開示: 入力データの機密性が損なわれる

  4. 欺瞞: モデル動作の完全性が損なわれる (モデルが望ましくない動作をするように操作されて欺かれる)

  5. 妨害: モデルの可用性が損なわれる (モデルが機能しないか、望ましくない動作をする - 欺くためではなく妨害するため)

  6. 開示/妨害: AI 固有ではない資産の機密性、完全性、可用性

このような影響をもたらす脅威はさまざまな攻撃対象領域を使用します。たとえば、トレーニングデータの機密性は開発期間中にデータベースにハッキングすることで侵害される可能性がありますが、特定の個人のデータを入力して、モデル出力の詳細を見るだけで、その個人がトレーニングデータにあるかどうかを知ることができる メンバーシップ推論攻撃 によって漏洩する可能性もあります。

AI セキュリティマトリクス

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/aisecuritymatrix/

コントロールの概要

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/controlsoverview/

脅威モデルとコントロール - 全般

  1. AI ガバナンス: AI リスクに対するガバナンスプロセスを導入し、情報セキュリティとソフトウェアライフサイクルのプロセスに AI を組み込みます。

    (AIPROGRAM, SECPROGRAM, DEVPROGRAM, SECDEVPROGRAM, CHECKCOMPLIANCE, SECEDUCATE)

  2. AI システムは IT システムであるため、従来の 技術的な IT セキュリティコントロール を適用します。

  3. データサイエンティストはリスクベースの データサイエンスセキュリティコントロール を適用します。

  4. データを最小限に抑える: 保存時および転送時のデータ量、保存時間を開発時、実行時に制限します。

    (DATAMINIMIZE, ALLOWEDDATA, SHORTRETAIN, OBFUSCATETRAININGDATA)

  5. モデルが間違いや操作によって望ましくない方法で動作する可能性があるため、動作への影響を制御 します。

    (OVERSIGHT, LEASTMODELPRIVILEGE, AITRANSPARENCY, EXPLAINABILITY, CONTINUOUSVALIDATION, UNWANTEDBIASTESTING)

すべての脅威とコントロールについては AI Exchange の詳細なコンテンツで説明します。

脅威モデルとコントロール - 生成 AI をトレーニング/ファインチューニング

下図は、トレーニングやファインチューニング が組織によって行われる状況においての、生成 AI への脅威とコントロールにのみ制限しています (注: これはコストが高く、専門知識が必要であることを考慮すると、あまり一般的ではありません)。

脅威モデルとコントロール - 生成 AI を現状のまま

下図は、モデルが組織によって 現状のまま 使用される生成 AI への脅威とコントロールにのみ制限しています。プロバイダ (OpenAI など) がトレーニングやファインチューニングを行っています。そのため、いくつかの脅威はモデルプロバイダの責任です (機密データや著作権があるデータ、プロバイダでの操作)。とはいえ、モデルを使用する組織はこれらのリスクを考慮し、プロバイダからその保証を得る必要があります。

多くの状況では、現状のままのモデルが外部にホストされるため、セキュリティは、セキュリティ構成を含め、サプライヤがデータをどのように処理するかによって決まります。API はどのように保護されていますか？仮想プライベートクラウドとは何ですか？外部モデル全体ですか、それとも API だけですか？鍵管理は？データ保持は？ログ記録は？そのモデルは機密性の高い入力データを送信することでサードパーティのソースに接触しますか？

AI セキュリティの周期表

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/periodictable/

OWASP AI Exchange によって作成された以下の表は、AI に対するさまざまな脅威と、それに対して使用できるコントロールを示しています。すべての資産、影響、攻撃対象領域について整理しており、AI Exchange ウェブサイトの包括的なカバレッジへのディープリンクを付与しています。 一般的なガバナンスコントロール はすべての脅威に適用されることに注意してください。

資産と影響
ライフサイクルと攻撃対象領域
脅威/リスクのカテゴリ
コントロール

モデル動作の完全性

ランタイム - モデル使用 (入力の提供 / 出力の読み取り)

ランタイム - デプロイされるモデルへの侵入

開発時 - エンジニアリング環境

開発時 - サプライチェーン

トレーニングデータの機密性

ランタイム - モデル使用

開発時 - エンジニアリング環境

モデルの機密性

ランタイム - モデル使用

ランタイム - デプロイされるモデルへの侵入

開発時 - エンジニアリング環境

モデル動作の可用性

モデル使用

モデル入力データの機密性

ランタイム - すべての IT

任意の資産, CIA

ランタイム - すべての IT

任意の資産, CIA

ランタイム - すべての IT

従来の資産に対する従来のランタイムセキュリティ攻撃

従来のランタイムセキュリティコントロール

任意の資産, CIA

ランタイム - すべての IT

従来のサプライチェーンの従来の攻撃

従来のサプライチェーンマネジメントコントロール

ナビゲータ図

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/navigator/

以下のナビゲータ図はすべての脅威、コントロール、リスクとコントロールの種類を含むそれらの関係を示しています。

画像をクリックすると、クリック可能なリンクを含む PDF を取得できます。

関連する脅威とコントロールをどのように選択するか？　リスク分析

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/riskanalysis/

このドキュメントには多くの脅威とコントロールを記載しています。状況や AI の使い方によって、どの脅威がどの程度関連しているか、どのコントロールが誰の責任であるかが決まります。この選択プロセスはユースケースとアーキテクチャに照らして、リスク分析 (またはリスク評価) を通じて実行できます。

リスクマネジメント入門 組織はリスクをいくつかの主要な領域に分類します。戦略、運用、財務、コンプライアンス、評判、テクノロジ、環境、社会、ガバナンス (ESG) です。脅威は一つ以上の脆弱性を悪用するとリスクになります。このリソースで説明しているように、AI の脅威は複数のリスク領域にわたって大きな影響を及ぼす可能性があります。たとえば、AI システムに対する敵対的攻撃は、運用の中断、財務モデルの歪曲、コンプライアンスの問題を引き起こす可能性があります。潜在的な影響の概要については AI セキュリティマトリクス を参照してください。

AI システムの一般的なリスクマネジメントは、通常、AI ガバナンス (AIPROGRAM を参照) によって推進され、関連する AI システムによるリスクとそれらのシステムに対するリスクの両方を含みます。セキュリティリスク評価は、通常、セキュリティマネジメントシステム (SECPROGRAM を参照) によって推進され、このシステムは、AI 資産、AI 脅威、AI システムを考慮に含めることが求められます (これらが対応するリポジトリに追加されている場合)。

組織は一般的に ISO 31000 または ISO 23894 などの類似の規格に基づくリスクマネジメントフレームワークを採用することがよくあります。これらのフレームワークは下記の四つの主要なステップを通じてリスク管理のプロセスをガイドします。

  1. リスクの特定: 組織に影響を及ぼす可能性のある潜在的なリスク (脅威) を認識します。潜在的なリスク (脅威) を特定するには「使用による脅威」セクションを参照してください。

  2. 発生可能性と影響度の推定によるリスクの評価: リスクの深刻度を判断するには、リスクが発生する可能性を評価し、リスクが顕在化した場合の潜在的な影響を評価する必要があります。発生可能性と影響度を組み合わせて、リスクの全体的な深刻度を測定します。これは一般的にヒートマップの形で示されます。詳細については以下を参照してください。

  3. すべきことの決定 (リスク処置): リスクに対処するための適切な戦略を選択します。これらの戦略には、リスクの軽減、移転、回避、受容があります。詳細については以下を参照してください。

  4. リスクコミュニケーションとモニタリング: リスク情報を利害関係者と定期的に共有し、リスクマネジメント活動に対する意識と支援を確保します。効果的なリスク処置を確実に適用します。これには、リスクとその属性 (深刻度、処置計画、オーナーシップ、ステータスなど) の包括的なリストであるリスク登録簿が必要です。詳細については以下を参照してください。

リスクマネジメントの手順を一つずつ見てきましょう。

1. リスクの特定

組織に影響を及ぼす可能性のある潜在的なリスク (脅威) を選択するには、該当する脅威の技術的およびビジネス的な評価が必要です。これを行う方法については、リスクの影響の種類ごとに以下で説明します。

望ましくないモデルの動作

モデルの動作に関しては、このドキュメントのスコープがセキュリティであるため、攻撃者による操作に焦点を当てています。その他の望ましくない動作の原因には一般的な不正確さ (ハルシネーションなど) や特定のグループに関する望ましくない偏見 (差別) があります。

This will always be an applicable threat, independent of your situation, although the risk level may sometimes be accepted - see below.

Which means that you always need to have in place:

Is the model GenAI (e.g. a Large Language Model)?

  • Prevent prompt injection (mostly done by the model supplier) in case untrusted input goes directly into the model, and it is important that the model follows its policy instructions about how it communicates. Mostly this is the case if model input is from end users and output also goes straight to end users, who could show that the model can misbehave (e.g. be politically incorrect), which can lead to reputation damage.

  • Prevent indirect prompt injection, in case untrusted input goes somehow into the prompt e.g. you retrieve somebody's resume and include it in a prompt.

Sometimes model training and running the model is deferred to a supplier. For generative AI, training is mostly performed by an external supplier given the cost of typically millions of dollars. Finetuning of generative AI is also not often performed by organizations given the cost of compute and the complexity involved. Some GenAI models can be obtained and run at your own premises. The reasons to do this can be lower cost (if is is an open source model), and the fact that sensitive input information does not have to be sent externally. A reason to use an externally hosted GenAI model can be the quality of the model.

Who trains/finetunes the model?

  • The supplier: you need to prevent obtaining a poisoned model by proper supply chain management (selecting a proper supplier and making sure you use the actual model), including assuring that: the supplier prevents development-time model poisoning including data poisoning and obtaining poisoned data. If the remaining risk for data poisoning cannot be accepted, performing post-training countermeasures can be an option - see POISONROBUSTMODEL.

  • You: you need to prevent development-time model poisoning which includes model poisoning, data poisoning and obtaining poisoned data

If you use RAG (Retrieval Augmented Generation using GenAI), then your retrieval repository plays a role in determining the model behaviour.This means:

  • You need to prevent data poisoning of your retrieval repository, which includes preventing that it contains externally obtained poisoned data.

Who runs the model?

Is the model predictive AI?

  • Prevent an evasion attack in which a user tries to fool the model into a wrong decision. Here, the level of risk is an important aspect to evaluate - see below. The risk of an evasion attack may be acceptable.

In order to assess the level of risk for unwanted model behaviour through manipulation, consider what the motivation of an attacker could be. What could an attacker gain by for example sabotaging your model? Just a claim to fame? Could it be a disgruntled employee? Maybe a competitor? What could an attacker gain by a less conspicuous model behaviour attack, like an evasion attack or data poisoning with a trigger? Is there a scenario where an attacker benefits from fooling the model? An example where evasion IS interesting and possible: adding certain words in a spam email so that it is not recognized as such. An example where evasion is not interesting is when a patient gets a skin disease diagnosis based on a picture of the skin. The patient has no interest in a wrong decision, and also the patient typically has no control - well maybe by painting the skin. There are situations in which this CAN be of interest for the patient, for example to be eligible for compensation in case the (faked) skin disease was caused by certain restaurant food. This demonstrates that it all depends on the context whether a theoretical threat is a real threat or not. Depending on the probability and impact of the threats, and on the relevant policies, some threats may be accepted as risk. When not accepted, the level of risk is input to the strength of the controls. For example: if data poisoning can lead to substantial benefit for a group of attackers, then the training data needs to be get a high level of protection.

Leaking training data

Do you train/finetune the model yourself?

If you use RAG: apply the above to your repository data, as if it was part of the training set: as the repository data feeds into the model and can therefore be part of the output as well.

If you don't train/finetune the model, then the supplier of the model is responsible for unwanted content in the training data. This can be poisoned data (see above), data that is confidential, or data that is copyrighted. It is important to check licenses, warranties and contracts for these matters, or accept the risk based on your circumstances.

Model theft

Do you train/finetune the model yourself?

Leaking input data

Is your input data sensitive?

  • Prevent leaking input data. Especially if the model is run by a supplier, proper care needs to be taken that this data is transferred or stored in a protected way and as little as possible. Note, that if you use RAG, that the data you retrieve and insert into the prompt is also input data. This typically contains company secrets or personal data.

Misc.

Is your model a Large Language Model?

  • Prevent insecure output handling, for example when you display the output of the model on a website and the output contains malicious Javascript.

Make sure to prevent model inavailability by malicious users (e.g. large inputs, many requests). If your model is run by a supplier, then certain countermeasures may already be in place.

Since AI systems are software systems, they require appropriate conventional application security and operational security, apart from the AI-specific threats and controls mentioned in this section.

2. 発生可能性と影響度の推定によるリスクの評価

To determine the severity of a risk, it is necessary to assess the probability of the risk occurring and evaluating the potential consequences should the risk materialize.

Estimating the Likelihood: Estimating the likelihood and impact of an AI risk requires a thorough understanding of both the technical and contextual aspects of the AI system in scope. The likelihood of a risk occurring in an AI system is influenced by several factors, including the complexity of the AI algorithms, the data quality and sources, the conventional security measures in place, and the potential for adversarial attacks. For instance, an AI system that processes public data is more susceptible to data poisoning and inference attacks, thereby increasing the likelihood of such risks. A financial institution's AI system, which assesses loan applications using public credit scores, is exposed to data poisoning attacks. These attacks could manipulate creditworthiness assessments, leading to incorrect loan decisions.

Evaluating the Impact: Evaluating the impact of risks in AI systems involves understanding the potential consequences of threats materializing. This includes both the direct consequences, such as compromised data integrity or system downtime, and the indirect consequences, such as reputational damage or regulatory penalties. The impact is often magnified in AI systems due to their scale and the critical nature of the tasks they perform. For instance, a successful attack on an AI system used in healthcare diagnostics could lead to misdiagnosis, affecting patient health and leading to significant legal, trust, and reputational repercussions for the involved entities.

Prioritizing risks The combination of likelihood and impact assessments forms the basis for prioritizing risks and informs the development of Risk Treatment decisions. Commonly organizations use a risk heat map to visually categorize risks by impact and likelihood. This approach facilitates risk communication and decision-making. It allows the management to focus on risks with highest severity (high likelihood and high impact).

3. リスク処置

Risk treatment is about deciding what to do with the risks. It involves selecting and implementing measures to mitigate, transfer, avoid, or accept cybersecurity risks associated with AI systems. This process is critical due to the unique vulnerabilities and threats related to AI systems such as data poisoning, model theft, and adversarial attacks. Effective risk treatment is essential to robust, reliable, and trustworthy AI.

Risk Treatment options are:

  1. Mitigation: Implementing controls to reduce the likelihood or impact of a risk. This is often the most common approach for managing AI cybersecurity risks. See the many controls in this resource and the 'Select controls' subsection below. - Example: Enhancing data validation processes to prevent data poisoning attacks, where malicious data is fed into the Model to corrupt its learning process and negatively impact its performance.

  2. Transfer: Shifting the risk to a third party, typically through transfer learning, federated learning, insurance or outsourcing certain functions. - Example: Using third-party cloud services with robust security measures for AI model training, hosting, and data storage, transferring the risk of data breaches and infrastructure attacks.

  3. Avoidance: Changing plans or strategies to eliminate the risk altogether. This may involve not using AI in areas where the risk is deemed too high. - Example: Deciding against deploying an AI system for processing highly sensitive personal data where the risk of data breaches cannot be adequately mitigated.

  4. Acceptance: Acknowledging the risk and deciding to bear the potential loss without taking specific actions to mitigate it. This option is chosen when the cost of treating the risk outweighs the potential impact. - Example: Accepting the minimal risk of model inversion attacks (where an attacker attempts to reconstruct publicly available input data from model outputs) in non-sensitive applications where the impact is considered low.

4. リスクコミュニケーションとモニタリング

Regularly sharing risk information with stakeholders to ensure awareness and support for risk management activities.

A central tool in this process is the Risk Register, which serves as a comprehensive repository of all identified risks, their attributes (such as severity, treatment plan, ownership, and status), and the controls implemented to mitigate them. Most large organizations already have such a Risk Register. It is important to align AI risks and chosen vocabularies from Enterprise Risk Management to facilitate effective communication of risks throughout the organization.

5. Arrange responsibility

For each selected threat, determine who is responsible to address it. By default, the organization that builds and deploys the AI system is responsible, but building and deploying may be done by different organizations, and some parts of the building and deployment may be deferred to other organizations, e.g. hosting the model, or providing a cloud environment for the application to run. Some aspects are shared responsibilities.

If components of your AI system are hosted, then you share responsibility regarding all controls for the relevant threats with the hosting provider. This needs to be arranged with the provider, using for example a responsibility matrix. Components can be the model, model extensions, your application, or your infrastructure. See Threat model of using a model as-is.

If an external party is not open about how certain risks are mitigated, consider requesting this information and when this remains unclear you are faced with either 1) accept the risk, 2) or provide your own mitigations, or 3)avoid the risk, by not engaging with the third party.

6. Verify external responsibilities

For the threats that are the responsibility of other organisations: attain assurance whether these organisations take care of it. This would involve the controls that are linked to these threats.

Example: Regular audits and assessments of third-party security measures.

7. Select controls

Then, for the threats that are relevant to you and for which you are responsible: consider the various controls listed with that threat (or the parent section of that threat) and the general controls (they always apply). When considering a control, look at its purpose and determine if you think it is important enough to implement it and to what extent. This depends on the cost of implementation compared to how the purpose mitigates the threat, and the level of risk of the threat. These elements also play a role of course in the order you select controls: highest risks first, then starting with the lower cost controls (low hanging fruit).

Controls typically have quality aspects to them, that need to be fine tuned to the situation and the level of risk. For example: the amount of noise to add to input data, or setting thresholds for anomaly detection. The effectiveness of controls can be tested in a simulation environment to evaluate the performance impact and security improvements to find the optimal balance. Fine tuning controls needs to continuously take place, based on feedback from testing in simulation in in production.

8. Residual risk acceptance

In the end you need to be able to accept the risks that remain regarding each threat, given the controls that you implemented.

9. Further management of the selected controls

(see SECPROGRAM), which includes continuous monitoring, documentation, reporting, and incident response.

10. Continuous risk assessment

Implement continuous monitoring to detect and respond to new threats. Update the risk management strategies based on evolving threats and feedback from incident response activities. Example: Regularly reviewing and updating risk treatment plans to adapt to new vulnerabilities.

... についてはどうですか？

機械学習以外の AI についてはどうですか？

AI を理解するのに役立つ方法は、AI が機械学習 (現在主流の AI タイプ) モデルと ヒューリスティックモデル から構成されていると考えることです。モデルはデータに基づいて計算方法を学習した機械学習モデルであることも、ルールベースのシステムなどの人間の知識に基づいて設計されたヒューリスティックモデルであることもあります。ヒューリスティックモデルは依然としてテストのためにデータを必要とし、さらに人間の知識を構築して検証するために分析を行うこともあります。 このドキュメントは機械学習に焦点を当てています。とはいえ、ここではヒューリスティックシステムにも適用される、このドキュメントの機械学習の脅威を簡単に要約します。

  • モデル回避はヒューリスティックモデルでも可能です - ルールの抜け穴を見つけようと試みます

  • 使用によるモデル盗用 - ヒューリスティックモデルからの入出力の組み合わせに基づいて機械学習モデルを訓練できます

  • 使用による過度の依存 - ヒューリスティックシステムも過度に依存することがあります。適用された知識は誤りの可能性があります

  • データポイズニングとモデルポイズニングは知識を向上させるために使用されるデータを操作したり、開発時や実行時にルールを操作する可能性があります

  • 分析やテストに使用されるデータの漏洩が依然として問題になる可能性があります

  • 知識、ソースコード、設定が知的財産である場合、機密データとみなされる可能性があり、保護が必要です

  • たとえばヒューリスティックシステムが患者を診断する必要がある場合、機密性の高い入力データが漏洩します

責任ある AI や信頼できる AI についてはどうですか？

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/responsibleai/

AI には、リスクを軽減しながら良い結果をもたらすという点で、さまざまな側面があります。これは、責任ある AI や信頼できる AI と呼ばれることが多く、前者は倫理、社会、ガバナンスを重視し、後者はより技術的、運用的側面を重視します。

主な責務がセキュリティであるなら、最善の戦略はまず AI セキュリティに焦点を当て、その後に他の AI の側面について学ぶことです。たとえ、対応する責任を負っている同僚が警戒を怠らないようにするためであってもです。結局のところ、セキュリティ専門家は一般的にうまくいかない可能性のあるものを特定することに長けています。さらに、いくつかの側面は侵害された AI の結果である可能性があり、したがって 安全性 (safety) などを理解しておくと役立ちます。

AI の側面を明確にし、それらがセキュリティとどのように関係しているかを見てみましょう。

  • 正確性 (Accuracy) はその「ビジネス機能」を実行するのに十分に正しいかどうかを指します。不正確であると、(物理的な) 安全性の問題 (運転中に車のトランクが開いてしまうなど) やその他の有害な間違った判断 (ローンの不当な拒否など) などの危害につながる可能性があります。セキュリティとの関連は、ある種の攻撃が望ましくないモデル動作を引き起こすことであり、これは定義上、正確性の問題です。とはいえ、セキュリティの範囲ではそのような攻撃のリスクを軽減することに限定されており、正確なモデルの作成 (トレーニングセットの代表データの選択など) の問題全体を解決するものではありません。

  • 安全性 (Safety) は危害から保護されている、あるいは危害を引き起こす可能性が低い状態を指します。したがって、AI システムの安全性は危害 (一般的に物理的な危害を意味しますが、それに限定されません) のリスクがある場合の正確性のレベルのことであり、さらに (正確性とは別に) それらのリスクを軽減するために設けられたものです。これには正確性を保護するためのセキュリティに加えて、モデルのビジネス機能にとって重要な多くの安全性の対策を含みます。これらはセキュリティ上の理由だけでなく、他の理由 (不適切なトレーニングデータなど) でモデルが安全でない決定を下す可能性があるため、安全性とセキュリティの間で共通する懸念事項であることに注意する必要があります。

  • 透明性 (Transparency): アプローチに関する情報を共有すること、ユーザーおよび依存するシステムに正確性のリスクを警告すること、さらに、多くの場合、ユーザーは使用されているモデルについての詳細とそれがどのように作成されたかを知る権利を持っています。そのため、セキュリティ、プライバシー、安全性の間で共通する懸念事項になります。

  • 説明可能性 (Explainability): 情報を共有すること、特定の結果がどのようにしてもたらされたかをより詳しく説明することで、ユーザーが正確性を検証するのに役立つこと。正確性を検証することとは別に、ユーザーが透明性を取得でき、異なる結果を得るには何を変更する必要があるかを理解することができます。そのため、セキュリティ、プライバシー、安全性、ビジネス機能の間で共通する懸念事項になります。特別なケースには、プライバシーとは別に説明可能性を法律で要求されている場合であり、この懸念を共有する側面のリストに「コンプライアンス」を追加します。

  • 堅牢性 (Robustness) は、入力に予期したバリエーションや予期しないバリエーションがあっても正確性を維持する能力です。セキュリティの範囲ではそのようなバリエーションが悪意のある場合 (敵対的堅牢性) に関するものであり、通常のバリエーション (一般的堅牢性) に対して必要な対策とは異なる対策が必要になることがよくあります。正確性の場合と同様に、セキュリティ自体は通常のバリエーションに対する堅牢なモデルの作成には関与しません。この例外は一般的堅牢性、敵対的悪意のある堅牢性の場合であり、この場合には安全性とセキュリティの間で共通する懸念事項になります。これはケースバイケースで異なります。

  • 差別からの自由 (Free of discrimination) 保護された属性に望ましくないバイアスがない、つまり、モデルが特定のグループ (性別、民族など) を「不当に扱う」ような体系的な不正確さがないこと。差別は法的および倫理的な理由から望ましくありません。セキュリティとの関係は、望ましくないバイアスを検出することで、攻撃によって引き起こされる望ましくないモデル動作を特定するのに役立つことです。たとえば、データポイズニング攻撃はトレーニングセットに悪意のあるデータサンプルを挿入します。最初は気付かれませんが、モデル内の原因不明のバイアスが検出されることによって発見されます。「公平性 (fairness)」という用語は差別問題を指すために使用されることもありますが、プライバシーにおける公平性は、と名声、倫理的使用、プライバシー権など、個人に対する公平な扱いを指す幅広い用語であることがほとんどです。

  • 共感性 (Empathy)。セキュリティとの関係は、AI の特定のアプリケーションを検証する際に、常に実現可能なセキュリティレベルを考慮すべきであるということです。十分なレベルのセキュリティを個人や組織に提供できないのであれば、共感性とはそのアイデアを無効にするか、他の予防措置を講じることを意味します。

  • 説明責任 (Accountability)。説明責任とセキュリティの関係は、セキュリティ対策はその対策に至ったプロセスを含めて実証可能であるべきということです。さらに、セキュリティインシデントを検出し、再構築し、対応して、説明責任を果たすためには、他の IT システムと同様に、セキュリティ特性としてのトレーサビリティが重要です。

  • AI セキュリティ。AI のセキュリティの側面は AI Exchange の中心的なトピックです。簡単に言うと、以下のように分けられます。

プライバシーについてはどうですか？

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/privacy/

Just like any system that processes data, AI systems can have privacy risks. There are some particualar privacy aspects to AI:

  • AI systems are data-intensive and typically present additional risks regarding data collection and retention. Personal data may be collected from various sources, each subject to different levels of sensitivity and regulatory constraints. Legislation often requires a legal basis and/or consent for the collection and use of personal data, and specifies rights to individuals to correct, request, and remove their own data.

  • Protecting training data is a challenge, especially because it typically needs to be retained for long periods - as many models need to be retrained. Often, the actual identities of people involved are irrelevant for the model, but privacy risks still remain even if identity data is removed because it might be possible to deduce individual identities from the remaining data. This is where differential privacy becomes crucial: by altering the data to make it sufficiently unrecognizable, it ensures individual privacy while still allowing for valuable insights to be derived from the data. Alteration can be done by for example adding noise or aggregating.

  • An additional complication in the protection of training data is that the training data is accessible in the engineering environment, which therefore needs more protection than it usually does - since conventional systems normally don't have personal data available to technical teams.

  • The nature of machine learning allows for certain unique strategies to improve privacy, such as federated learning: splitting up the training set in different separated systems - typically aligning with separated data collection.

  • AI systems make decisions and if these decisions are about people they may be discriminating regarding certain protected attributes (e.g. gender, race), plus the decisions may result in actions that invade privacy, which may be an ethical or legal concern. Furthermore, legislation may prohibit some types of decisions and sets rules regarding transparency about how these decisions are made, and about how individuals have the right to object.

  • Last but not least: AI models suffer from model attack risks that allow attackers to extract training data from the model, e.g. model inversion, membership inference, and disclosing sensitive data in large language models

AI プライバシーは二つのパートに分けることができます。

  1. AI セキュリティに対する脅威とそのコントロール (このドキュメント) は、以下を含みます。

  • トレーニングデータとテストデータ、モデル入出力における個人データの機密性と完全性の保護 - 以下で構成します。

    • 転送時および保存時の個人データの「従来型」セキュリティ

    • 個人データを取得しようとするモデル攻撃 (モデル反転など) に対する保護

    • 個人データの最小化/差分プライバシー (最小保持を含む)

  • モデルの動作が個人のプライバシーを侵害する可能性がある場合のモデル動作の完全性保護。これはたとえば個人が違法に差別される場合や、モデルの出力がプライバシーを侵害するアクション (詐欺調査を受けるなど) につながる場合に発生します。

  1. セキュリティに関するものではありませんが、個人のさらなる権利に関する脅威とコントロールは GDPR などのプライバシー規制でカバーされます。これには使用制限、同意、公平性、透明性、データの正確性、訂正/異議申し立て/消去/請求の権利が含まれます。概要については、OWASP AI ガイドのプライバシーパート を参照してください。

生成 AI (LLM など) についてはどうですか？

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/genai/

はい、生成 AI は現在の AI 変革をリードしており、AI セキュリティの中で最も急速に変化しているサブフィールドです。とはいえ、クレジットスコアリング、不正検出、医療診断、製品推奨、画像認識、予知保全、プロセス制御など、多くの重要なユースケースには他のタイプのアルゴリズム (予測 AI と呼びましょう) が引き続き適用されることを認識することが重要です。このドキュメントでは関連するコンテンツには「生成 AI」のマークを付けています。

重要な注意: セキュリティ脅威の観点からは、生成 AI は他の形式の AI (予測 AI) とそれほど違いはありません。生成 AI の脅威とコントロールは一般的な AI と大部分が重複しており、非常によく似ています。とはいえ、一部のリスクは (はるかに) 高くなります。低いものもあります。生成 AI 固有のリスクはごくわずかです。生成 AI と予測 AI ではコントロールカテゴリが大きく異なるものがあり、主にデータサイエンスコントロール (トレーニングセットへのノイズ追加など) です。多くの場合、生成 AI ソリューションはモデルをそのまま使用し、組織によるトレーニングを一切行わず、セキュリティ責任の一部を組織からサプライヤに移します。それでも、既製のモデルを使用する場合は、依然としてそうした脅威に注意する必要があります。

LLM による主な新しい脅威は何ですか？

  • まず第一に、LLM は脆弱性のあるコードを作成するために使用されたり、攻撃者がマルウェアを作成したり、ハルシネーションによって害を及ぼす可能性があるため、セキュリティに新たな脅威をもたらしますが、AI Exchange の範囲外であり、AI システムへのセキュリティ脅威に焦点を当てています。

  • 入力について:

    • プロンプトインジェクションは全く新しい脅威です。攻撃者は細工した命令や、時には隠された命令で、モデルの動作を操作します。

    • また、企業秘密や個人データを含む、大量のデータをプロンプトで送信する組織も新たにあります。

  • 出力について: 出力にはインジェクション攻撃を含んだり、機密データや著作権で保護されたデータを含む可能性があるという事実が新たにあります (著作権 参照)。

  • 過度の依存は問題です。私たちは LLM に物事を制御および作成され、LLM がどれほど正しいかを過信し、また、LLM が操作されるリスクを過小評価していることがあります。その結果、攻撃は大きな影響を与えることになります。

  • トレーニングについて: トレーニングセットは非常に大きく、公開データに基づいているため、データポイズニングを実行することは容易です。また、汚染された基礎モデルはサプライチェーンの大きな問題でもあります。

生成 AI セキュリティの特徴は以下の通りです。

No.
生成 AI セキュリティの特徴
OWASP for LLM TOP 10

1

2

3

4

5

LLM Top 10 でのカバーなし

6

7

LLM Top 10 でのカバーなし、異なるアプローチを使用する LLM06 を除く、上記を参照

8

9

生成 AI 参考情報:

NCSC/CISA ガイドラインについてはどうですか？

カテゴリ: ディスカッション パーマリンク: https://owaspai.org/goto/jointguidelines/

英国 NCSC / CISA の 安全な AI システム開発のガイドライン を AI Exchange のコントロールにマッピングします。 脅威とリンクしているコントロールを確認するには、AI セキュリティの周期表 を参照してください。

  1. 安全な設計

  1. 安全な開発

  1. 安全な展開

  1. 安全な運用と保守

How about copyright?

Category: discussion パーマリンク: https://owaspai.org/goto/copyright/

Introduction

AI and copyright are two (of many) areas of law and policy, (both public and private), that raise complex and often unresolved questions. AI output or generated content is not yet protected by US copyright laws. Many other jurisdictions have yet to announce any formal status as to intellectual property protections for such materials. On the other hand, the human contributor who provides the input content, text, training data, etc. may own a copyright for such materials. Finally, the usage of certain copyrighted materials in AI training may be considered fair use.

AI & Copyright Security

In AI, companies face a myriad of security threats that could have far-reaching implications for intellectual property rights, particularly copyrights. As AI systems, including large data training models, become more sophisticated, they inadvertently raise the specter of copyright infringement. This is due in part to the need for development and training of AI models that process vast amounts of data, which may contain copyright works. In these instances, if copyright works were inserted into the training data without the permission of the owner, and without consent of the AI model operator or provider, such a breach could pose significant financial and reputational risk of infringement of such copyright and corrupt the entire data set itself.

The legal challenges surrounding AI are multifaceted. On one hand, there is the question of whether the use of copyrighted works to train AI models constitutes infringement, potentially exposing developers to legal claims. On the other hand, the majority of the industry grapples with the ownership of AI-generated works and the use of unlicensed content in training data. This legal ambiguity affects all stakeholders—developers, content creators, and copyright owners alike.

Lawsuits Related to AI & Copyright

Recent lawsuits (writing is April 2024) highlight the urgency of these issues. For instance, a class action suit filed against Stability AI, Midjourney, and DeviantArt alleges infringement on the rights of millions of artists by training their tools on web-scraped images2. Similarly, Getty Images’ lawsuit against Stability AI for using images from its catalog without permission to train an art-generating AI underscores the potential for copyright disputes to escalate. Imagine the same scenario where a supplier provides vast quantities of training data for your systems, that has been compromised by protected work, data sets, or blocks of materials not licensed or authorized for such use.

Copyright of AI-generated source code

Source code constitutes a significant intellectual property (IP) asset of a software development company, as it embodies the innovation and creativity of its developers. Therefore, source code is subject to IP protection, through copyrights, patents, and trade secrets. In most cases, human generated source code carries copyright status as soon as it is produced.

However, the emergence of AI systems capable of generating source code without human input poses new challenges for the IP regime. For instance, who is the author of the AI-generated source code? Who can claim the IP rights over it? How can AI-generated source code be licensed and exploited by third parties?

These questions are not easily resolved, as the current IP legal and regulatory framework does not adequately address the IP status of AI- generated works. Furthermore, the AI-generated source code may not be entirely novel, as it may be derived from existing code or data sources. Therefore, it is essential to conduct a thorough analysis of the origin and the process of the AI-generated source code, to determine its IP implications and ensure the safeguarding of the company's IP assets. Legal professionals specializing in the field of IP and technology should be consulted during the process.

As an example, a recent case still in adjudication shows the complexities of source code copyrights and licensing filed against GitHub, OpenAI, and Microsoft by creators of certain code they claim the three entities violated. More information is available here: : GitHub Copilot copyright case narrowed but not neutered • The Register

Copyright damages indemnification

Note that AI vendors have started to take responsibility for copyright issues of their models, under certain circumstances. Microsoft offers users the so-called Copilot Copyright Commitment, which indemnifies users from legal damages regarding copyright of code that Copilot has produced - provided a number of things including that the client has used content filters and other safety systems in Copilot and uses specific services. Google Cloud offers its Generative AI indemnification. Read more at The Verge on Microsoft indemnification and Direction Microsoft on the requirements of the indemnification.

Do generative AI models really copy existing work?

Do generative AI models really lookup existing work that may be copyrighted? In essence: no. A Generative AI model does not have sufficient capacity to store all the examples of code or pictures that were in its training set. Instead, during training it extracts patterns about how things work in the data that it sees, and then later, based on those patterns, it generates new content. Parts of this content may show remnants of existing work, but that is more of a coincidence. In essence, a model doesn't recall exact blocks of code, but uses its 'understanding' of coding to create new code. Just like with human beings, this understanding may result in reproducing parts of something you have seen before, but not per se because this was from exact memory. Having said that, this remains a difficult discussion that we also see in the music industry: did a musician come up with a chord sequence because she learned from many songs that this type of sequence works and then coincidentally created something that already existed, or did she copy it exactly from that existing song?

Mitigating Risk

Organizations have several key strategies to mitigate the risk of copyright infringement in their AI systems. Implementing them early can be much more cost effective than fixing at later stages of AI system operations. While each comes with certain financial and operating costs, the “hard savings” may result in a positive outcome. These may include:

  1. Taking measures to mitigate the output of certain training data. The OWASP AI Exchange covers this through the corresponding threat: data disclosure through model output.

  2. Comprehensive IP Audits: a thorough audit may be used to identify all intellectual property related to the AI system as a whole. This does not necessarily apply only to data sets but overall source code, systems, applications, interfaces and other tech stacks.

  3. Clear Legal Framework and Policy: development and enforcement of legal policies and procedures for AI use, which ensure they align with current IP laws including copyright.

  4. Ethics in Data Sourcing: source data ethically, ensuring all date used for training the AI models is either created in-house, or obtained with all necessary permissions, or is sourced from public domains which provide sufficient license for the organization’s intended use.

  5. Define AI-Generated Content Ownership: clearly defined ownership of the content generated by AI systems, which should include under what conditions it be used, shared, disseminated.

  6. Confidentiality and Trade Secret Protocols: strict protocols will help protect confidentiality of the materials while preserving and maintaining trade secret status.

  7. Training for Employees: training employees on the significance and importance of the organization’s AI IP policies along with implications on what IP infringement may be will help be more risk averse.

  8. Compliance Monitoring Systems: an updated and properly utilized monitoring system will help check against potential infringements by the AI system.

  9. Response Planning for IP Infringement: an active plan will help respond quickly and effectively to any potential infringement claims.

  10. Additional mitigating factors to consider include seeking licenses and/or warranties from AI suppliers regarding the organization’s intended use, as well as all future uses by the AI system. With the help of legal counsel the organization should also consider other contractually binding obligations on suppliers to cover any potential claims of infringement.

Helpful resources regarding AI and copyright:

PreviousコンテンツNext1. 一般的なコントロール

Last updated