minor fix for security doc

docs/securiticontent.md

@@ -1,6 +1,6 @@
 # Security Part
 
-サイバー セキュリティの目的は、組織に対して発生するサイバー セキュリティ上のリスクを把握し、許容可能なレベルに管理することです。
+サイバーセキュリティの目的は、組織に対して発生するサイバー セキュリティ上のリスクを把握し、許容可能なレベルに管理することです。
 
 サイバーセキュリティは人、組織のプロセス、システムの実装を包括的にカバーする必要がありますが、サイバーセキュリティのエリアでは様々な組織によって管理、実証されている基準やフレームワークが存在し、適切なものを選択することで、適切なコストで抜け漏れの少ないサイバーセキュリティを実現することができます。
 
@@ -14,42 +14,42 @@
 
 - 識別 (Identify) : ビジネス環境、資産、脅威を識別し、リスクを把握する。
 - 防御 (Protection): 特定されたリスクに対して適切な保護策を検討し、実施する。
-- 検知 (Detect) : サイバー セキュリティ イベントの発生を検出する。
+- 検知 (Detect) : サイバーセキュリティのイベントの発生を検出する。
 - 対応 (Respond) : 検知されたサイバーセキュリティ インシデントに対処する。
-- 復旧 (Recover) : サイバー セキュリティ インシデントによって阻害された機能やサービスを復旧する。
+- 復旧 (Recover) : サイバーセキュリティのインシデントによって阻害された機能やサービスを復旧する。
 
-フレームワークの機能は識別から開始され、まず組織の資産と資産に対する脅威が識別されるため、新しいテクノロジーを導入する際にもリスクを検討することができます。また、識別された脅威に対してセキュリティ対策を検討することになるため、リスク ベースのアプローチとなり、実際に組織にとって必要なセキュリティ対策が実装されやすいという特徴があります。
+フレームワークの機能は識別から開始され、まず組織の資産と資産に対する脅威が識別されるため、新しいテクノロジーを導入する際にもリスクを検討することができます。また、識別された脅威に対してセキュリティ対策を検討することになるため、リスクベースのアプローチとなり、実際に組織にとって必要なセキュリティ対策が実装されやすいという特徴があります。
 
 フレームワークは CIS CRC、ISO 27001 (ISMS)、NIST SP800-53 などの重要なセキュリティ基準を参照しています。これによりフレームワークの信頼性を説明することが可能になり、またこれらの基準とフレームワークを併用することを容易にしています。フレームワークのカテゴリー自体は包括的でありながらも項目の数はコンパクトであり、小規模な組織でも管理しやすいものになっています。
 
-## 識別 (Identify)
+## 識別 (Identify) の実装
 
 識別では組織のビジネス環境や所有する資産、内部および外部の脅威、関連するサプライチェーンなどを識別します。リスクの可能性は脅威の存在に対して存在するため、脅威を把握することで管理されていないリスクを減らすことができます。
 
 <!-- Identify を脅威だけにすることも検討-->
 
 ### 脅威の特定
 
-サイバー セキュリティの目的は、組織に対して発生するサイバー セキュリティ上のリスクを把握し、許容可能なレベルに管理することです。リスクの可能性は脅威に対して存在するため、脅威を把握することで管理されていないリスクを減らすことができます。
+サイバーセキュリティの目的は、組織に対して発生するサイバーセキュリティ上のリスクを把握し、許容可能なレベルに管理することです。リスクの可能性は脅威に対して存在するため、脅威を把握することで管理されていないリスクを減らすことができます。
 
 この脅威を識別する取り組みは脅威モデリングと呼ばれますが、AI/ML システムでは従来の脅威に加えてさらに深く議論すべき課題があると考えられています。
 
 #### 従来の脅威
 
-組織のAI/ML システムシステムは、既存のインフラストラクチャの一部として動作するため、従来のシステムに対して発生する脅威は、前提として考慮する必要があります。
+組織の AI/ML システムシステムは、既存のインフラストラクチャの一部として動作するため、従来のシステムに対して発生する脅威は、前提として考慮する必要があります。
 
-サイバー セキュリティではシステムが満たすべき要件を機密性、完全性、可用性という 3 つの要素として整理しています。
+サイバーセキュリティではシステムが満たすべき要件を機密性、完全性、可用性という 3 つの要素として整理しています。
 
-サイバー セキュリティの基本 3 要素
+サイバーセキュリティの基本 3 要素
 
 - 機密性 (Confidentiality) : 権限のある主体だけが情報を読み取ることができること
 - 完全性 (Integrity) : 権限のある主体だけが情報を変更することができること
 - 可用性 (Availability) : 情報が必要なときに利用できること
 
-より詳細な議論のために、この他に真正性(Authenticity)、信頼性(Reliability)、責任追跡性(Accountability) 、否認防止（non-repudiation）という 4 要素が追加されることもあります。
+より詳細な議論のために、この他に真正性 (Authenticity)、信頼性 (Reliability)、責任追跡性 (Accountability) 、否認防止（non-repudiation）という 4 要素が追加されることもあります。
 
-これらのセキュリティ要素を侵害するものがサイバー セキュリティ上の脅威です。特定のシステムに対して想定される脅威を識別する取り組みを脅威モデリングと呼びます。サイバー セキュリティ上の脅威はデータの入出力に対して発生するため、システムのコンポーネント間のデータフローを記述し、識別されたデータの入出力に対して脅威の分析を行います。  
-組織が管理していないコンポーネントから組織が管理しているコンポ―ネントに対するデータの入出力があったり、組織の管理しているコンポーネントでもセキュリティ レベルの異なるコンポーネント間のやりとりは信頼の境界を跨ぐデータの入出力になるため、注意深く脅威を識別する必要があります。
+これらのセキュリティ要素を侵害するものがサイバーセキュリティ上の脅威です。特定のシステムに対して想定される脅威を識別する取り組みを脅威モデリングと呼びます。サイバー セキュリティ上の脅威はデータの入出力に対して発生するため、システムのコンポーネント間のデータフローを記述し、識別されたデータの入出力に対して脅威の分析を行います。
+組織が管理していないコンポーネントから組織が管理しているコンポ―ネントに対するデータの入出力があったり、組織の管理しているコンポーネントでもセキュリティレベルの異なるコンポーネント間のやりとりは信頼の境界を跨ぐデータの入出力になるため、注意深く脅威を識別する必要があります。
 
 [脅威モデリングの概要](https://learn.microsoft.com/ja-jp/training/modules/tm-introduction-to-threat-modeling/)
 
@@ -59,9 +59,9 @@
 
 AI/ML システムで考慮すべき新しいリスクは [機械学習の障害モード](https://learn.microsoft.com/ja-jp/security/engineering/failure-modes-in-machine-learning) にまとめられています。
 
-このドキュメントではAI/ML システムに発生する問題を意図的な障害と意図的ではない障害の２ つに分類し整理を行っています。
+このドキュメントでは AI/ML システムに発生する問題を意図的な障害と意図的ではない障害の ２ つに分類し整理を行っています。
 
-意図的な障害はアクティブな敵対者によって引き起こされる障害で、機密性、完全性、可用性を脅かす可能性のある脅威と考えることができます。Azure Open AI で既存のモデルを使用する場合、学習データやモデルの管理はプラットフォーム側の管理になりますが、ファインチューニングを行う際の学習データや、クエリの問い合わせを行う際に他のデータベースと連携するような場合には、これらの脅威によって発生する新たなリスクを考慮する必要があります。
+意図的な障害はアクティブな敵対者によって引き起こされる障害で、機密性、完全性、可用性を脅かす可能性のある脅威と考えることができます。Azure OpenAI Service で既存のモデルを使用する場合、学習データやモデルの管理はプラットフォーム側の管理になりますが、ファインチューニングを行う際の学習データや、クエリの問い合わせを行う際に他のデータベースと連携するような場合には、これらの脅威によって発生する新たなリスクを考慮する必要があります。
 
 意図的ではない障害は ML が意図した動作を行わないことによって発生します。従来のシステムでも意図しない動作が行われることはありましたが、これは意図に対して適切ではないプログラムが与えられることが原因であり、プログラムのバグとして意図した動作を行うように修正することが可能でした。
 
@@ -118,7 +118,7 @@ AI/ML システムを脅威モデリングする際に新しく導入すべき
   - マイクロソフトのモデルのトレーニングには使われない
 - カスタマイズ後のモデル（の出力）
 -->
-## 防御の実装
+## 防御 (Protection) の実装
 
 防御では認証と認可に基づく適切なアクセス制御、ネットワークのセグメンテーション、暗号化など、脅威に対するセキュリティ対策を導入します。脅威に対処ができていない状態は脆弱性と呼ばれます。アプリケーションは様々なコンポーネントによって構成されるため、防御にはそれぞれのコンポーネントに対して考えられる脅威と、それぞれのコンポーネントで構成可能な実装のオプションに関する知識が必要になります。
 
@@ -130,7 +130,7 @@ Azure ではプラットフォームの機能としてクラウドセキュリ
 
 <!-- @Scale で導入すべきセキュリティ設定を列挙する-->
 
-### Microsfot Cloud Security Benchmark
+### Microsoft Cloud Security Benchmark
 
 CSPM 機能が基準とするセキュリティ設定は [Microsoft Cloud Security Benchmark](https://learn.microsoft.com/ja-jp/security/benchmark/azure/) に基づいています。Microsoft Cloud Security Benchmark は組織が実装すべきセキュリティ コントロールを次の 12 種類に分類し、ガイダンスを提供しています。
 
@@ -201,7 +201,7 @@ CSPM 機能が基準とするセキュリティ設定は [Microsoft Cloud Securi
 少なくとも問題が発生した際に調査を行うことができることと、責任を明らかにするために説明可能な状態にしておく必要がある。
 -->
 
-## 検知の実装
+## 検知 (Detect) の実装
 
 脅威を検知するために必要なログを収集し、検知を行うための分析を実施する
 
@@ -241,7 +241,7 @@ AllMetrics
   - モデルに対するバックドア攻撃
     [検知で対応する]、あるいはMSの責任
 
-## 対応の実装
+## 対応 (Respond) の実装
 
 - 対応プロセスを準備しておくことは大事
   - 障害モードを検知した場合