CISSP合格ノート・CBK#06 セキュリティ構造とモデル (Security Architecture & Models)

CBK#6 セキュリティ構造とモデル (Security Architecture & Models)



go to menu page

CBK#6 セキュリティ構造とモデル (Security Architecture & Models)

6.1. セキュリティモデル (Security Model)

└ 特定のセキュリティポリシーを適切にサポートするための要件を概説するもの。

6.2. コンピュータアーキテクチャー (Computer Architecture)

6.2.1. 中央演算装置 (CPU: Central Processing Unit)
マイクロプロセッサ。

├ 制御ユニット、整数論理演算ユニット(ALU、Arithmetic Logic Unit)、主記憶装置(primary storage)を持つ。
├ CPU が必要とする命令とデータは主記憶装置に保持される。
├ 主記憶装置は命令を保持する一時記憶領域で、命令はCPU が解釈しデータ処理をする。

バッファーオーバーフロー(Buffer overflow) 。

├ 処理されるデータはブロック単位でCPU に入力される。 
└ ソフトウェア命令において入力されるデータのブロックの大きさを適切に設定されていないと、余分なデータが入り込み実行されてしまう。

実記憶装置(Real storage) :

└ 命令とデータが処理されると、システムの記憶領域、実記憶装置に移動される。

6.2.2. メモリ (Memory)
RAM / ランダムアクセスメモリ(Random Access Memory) :

└ 電源が切れると内容が消える揮発性メモリである。

RAMのタイプ:

├ スタティックRAM (Static RAM) :
└ データを保存すると、継続的にフラッシュしなくても保持されている。
└ ダイナミックRAM (Dynamic RAM) :
電荷が漏洩し減少していくため、保存されているデータを定期的にリフレッシュする必要がある。
ROM/リードオンリーメモリー(Read-only memory) :
└ 不揮発性メモ、ROM内に保存されたソフトウェアはファームウェアと呼ばれる。
EPROM/ (Erasable and programmable read-only memory) :
└ 保持しているデータを電気的に消したり書いたりできる。

6.2.3. キャッシュメモリ (Cache memory)

└ RAM の一部で、高速な読み書きに使用される。

6.2.4. PLD. プログラマブル・ロジックデバイス(Programmable Logic Device)

└ プログラミング処理によって変更できるコネクションや内部ゲートを持つ集積回路

6.2.5. メモリマッピング (Memory Mapping)
実メモリもしくはプライマリメモリ(Real or primary memory) :

├ CPU が直接アクセスできる。 
└ 実行されているプログラムに関連する命令やデータの格納に利用される。

セカンダリメモリ(Secondary memory) : 
└ より遅いメモリ(磁気ディスク等)で、不揮発性のストレージを提供する。

順次メモリ (Sequential memory) :

├ その場所に直接アクセスするのではなく、先頭から順に探すことによって情報が得られる。 
└ 磁気テープなど。

仮想メモリ (Virtual memory) :

└ プライマリメモリと協働してセカンダリメモリを使用し、CPU に対して、実メモリロケーションのように見える大きなアドレススペースを提供する。

8.2.6. メモリアドレッシング (Memory addressing)
レジスタアドレッシング(Register addressing) :

└ CPU 内のレジスタや、主記憶装置内で指定された特殊目的レジスタをアドレッシングする。

直接アドレッシング(Direct addressing) :

├ メモリ位置の実際のアドレスを特定することにより主記憶装置のある部分をアドレッシングする。 
└ メモリアドレスは通常実行されるメモリページか、ページ0に制限されている。

絶対アドレッシング(Absolute addressing) :

└ プライマリメモリスペース全てのアドレッシング。
インデックス付きアドレッシング(Indexed addressing) :
└ プログラムの命令で定義されたアドレスの内容を、インデックスレジスタの内容に加えることによりメモリアドレスとする。この、計算によって出された有効なアドレスが、要求されたメモリ位置へのアクセスに使用される。したがって、インデックスレジスタがインクリメントあるいはデクリメントされると、メモリ位置の範囲にアクセスできる。

含意アドレッシング(Implied addressing):

└ プロセッサ内のオペレーションが実行されなければならないとき、例えば算術操作の結果としてセットされた桁上がりビットをクリアする場合などに使用される。この操作は内部レジスタに対して行わなければならず、また内部レジスタは命令自体の中に指定されるので、アドレスを与える必要はない。

間接アドレッシング(Indirect addressing) :

└ アドレス位置がプログラムの命令内で指定され、最終的に要求する位置のアドレスを含んでいるときのアドレッシング。

6.2.7. CPUモードとプロテクションリング (CPU Modes and Protection Rings)
プロテクションリング(Protection rings) :

├ それぞれのリング内のどのプロセスがアクセスでき、どのコマンドが実行できるかについての厳格な境界を定める。 
└ 内部リング内で動いているプロセス(スーパーバイザーモード/特権モード)は外部リングで動いているプロセス(ユーザモード)よりも多くの権限を持つ。

6.2.8. オペレーションの状態 (Operating states)
実行可能状態 (Ready state):

└ アプリケーションは処理を再開する準備ができている。

管理状態 (Supervisory state):

└ システムは、システムもしくは優先順位の高いルーチンを実行している。

問題状態 (Problem state):

└ システムはアプリケーションを実行している。

待ち状態 (Wait state):

└ アプリケーションは特定のイベント、例えば文字入力やプリントジョブの完了を待っている。

6.2.9. マルチスレッディング、マルチタスキング、マルチプロセシング 
(Multi-threading, tasking, processing)
マルチスレッディング(Multithreading) :

└ 1つのアプリケーションが、異なるスレッドを使用するコールを一度に複数実行できる。

マルチタスキング(Multitasking) :

└ CPU が一度に複数のプロセスやタスクを実行できる。

マルチプロセシング(Multiprocessing) :

└ コンピュータが複数のCPU を持ち、命令の実行にそれらをパラレルで使用することができる。

6.2.10. 入出力装置管理 (Input/Output Device Management)
デッドロック状態(Deadlock situation):

└ 使用後に構造が壊されてリリースされない場合、リソースは他のプログラムやプロセスに使用されなければならない。


6.3. システム構造 (System architecture)
6.3.1. 高信頼コンピューティング基盤 (TCB: Trusted Computing Base)

├ コンピュータシステム内のプロテクションメカニズムのトータルな組み合わせとして定義されている。
├ ハードウェア、ソフトウェア、ファームウェアを含む。
オレンジブックに由来する。
オレンジブックでは、高信頼システムとは、アクセス権やセキュリティポリシーに反することなくユーザのために機密性の高い、あるいはそれ以外のデータの完全性を守るための対策を活用するハードウェア、ソフトウェアとして定義されている。
└ システム内の全ての防御メカニズムを網羅して、セキュリティポリシーを施行し、期待されるように振る舞う環境を提供する。

6.3.2. セキュリティ境界 (Security perimeter)

├ TCBの外部のリソースとして定義される。
└ 機密情報が意図しない方法で流れないようにするために、信頼されたコンポーネントと信頼されていないコンポーネントとの間のコミュニケーションをコントロールしなければならない。

6.3.3. 参照モニタ (Reference monitor)

├ 抽象的な機械で、サブジェクトのオブジェクトに対する全てのアクセスを仲介し、サブジェクトが必要なアクセス権を持った上で許可されないアクセスからオブジェクトを保護して有害な変更から守る。
└ これはアクセス制御コンセプトであり、実際の物理的コンポーネントではない。

6.3.4. セキュリティカーネル (Security kernel)

├ TCBの中のメカニズムから成り、参照モニタコンセプトを強化する。
├ TCBの中心部分で、高信頼コンピューティングシステムを構築するアプローチとして最も一般的に使われる。
(3つの要件)
├ 参照モニタコンセプトを実行するプロセスを分離し、不正防止機能がなければならない。
├ 参照モニタは全てのアクセス試行に対して呼び出され、これを回避することができてはならないしたがって、参照モニタは完全でかつフールプルーフ機能が備わっていなければならない。
└ 完全かつ包括的にテスト・検証することができるように十分に小さくなければならない。

6.3.5. ドメイン (Domains):

サブジェクトがアクセスできるオブジェクトの集合として定義される。

実行ドメイン (Execution Domain):

└ 特権ドメイン内のプログラムは異なるドメイン内のプログラムが、環境に悪影響を及ぼさないことを保証しながら命令の実行やデータの処理を行うことができる必要がある。

セキュリティドメイン (Security Domain):
サブジェクトあるいはオブジェクトが割り当てられたプロテクションリングに対して、直接の相関を持つ。
└ プロテクションリングの番号が小さいほど特権が高く、セキュリティドメインが大きい。

6.3.6. リソース隔離 (Resource isolation):
ハードウェアセグメンテーション(Hardware segmentation):

└ メモリは論理的にだけでなく物理的にも分離される。

6.3.7. セキュリティポリシー (Security policy):

└ ルール、実行、手順をまとめたもので、機密情報をどのように管理、保護、配布するかについて定めている。
複数レベルセキュリティポリシー(Multilevel security policy) :
└ 高セキュリティレベルから低セキュリティレベルへの情報フローを阻止するセキュリティポリシー

6.3.8. 最小特権 (Least privilege)

└ リソースやプロセスは、機能を遂行するために必要なレベル以上の特権を持たないということを意味する。

6.3.9. レイヤー化 (Layering)

└ 構造化されたヒエラルキー構造で、基本機能は低いレイヤーで、より複雑な機能は高いレイヤーで処理する。

6.3.10. データ隠蔽 (Data hiding)

└ 異なるレイヤーのプロセスがお互いにコミュニケートする必要がない場合には、そのためのインターフェイスを持たない。

6.3.11. 抽出(Abstraction)

└ オブジェクトのクラスが特定のパーミッションを割り当てられ、受け入れられるアクティビティが定義される。これによりそれぞれのオブジェクト毎にクラスが扱われないため、異なるオブジェクトの管理が容易になる。

 

6.4. セキュリティモデル (Security Models)

セキュリティポリシーを実行するのに必要なデータ構造と技法の仕様を定めることにより、ポリシーの抽象ゴールを情報システムの言葉にマッピングする。


6.4.1. 状態機械モデル (State machine model)

└ システムのセキュリティを検証するために状態が使用される。 つまり、現在のパーミッションおよびオブジェクトにアクセスしているサブジェクトのインスタンスは全て捕らえられなければならない。

状態遷移(State transitions) :

├ 状態を変えることができるアクティビティ。
├ 状態機械モデルを採用したシステムは、その存在の全てのインスタンスにおいてセキュアな状態である。 
├ セキュアな状態で起動し、コマンドを実行し、セキュアにトランザクションを行う。
サブジェクトはセキュアな状態においてのみリソースへのアクセスを許可される。

6.4.2. Bell-LaPadula モデル (Bell-LaPadula model)

└ 情報の機密性問題を形式的に扱う。

複数レベルセキュリティシステム(Multilevel security system) :

├ Bell-LaPadula モデルを採用したシステムでは、異なるクリアランスを持つユーザがシステムを使用し、システムは異なる分類のデータを処理する。
├ 情報が分類されるレベルは使用される操作手続きを決め、格子を形成する。
├ 格子(Lattice)認証されたアクセスの下限と上限。
├ アクセスコントロールの機密性の面を実現する状態機械モデルである。
├ アクセス制御行列とセキュリティレベルが、異なるオブジェクトへのサブジェクトのアクセス可否を決めるために使用される。
├ このモデルではサブジェクト、オブジェクト、アクセス操作(読み、書き、読み書き)、セキュリティレベルが使用される。
└ 情報フローセキュリティモデルで、情報は下位のあるいは比較できない分類のオブジェクトには流れない。

(主要なルール):
シンプルセキュリティ属性 (The simple security property):

├ あるセキュリティレベルのサブジェクトはより上位のセキュリティレベルのデータを読むことができない。
└“no read up”と呼ばれる。

スタープロパティ (star* property):

├ あるセキュリティレベルのサブジェクトはより下位のレベルに書き込むことができない。
├“no write down”と呼ばれる。
└ セキュアな状態は、セキュアコンピューティング環境と、セキュリティ維持オペレーションによって許可されたアクションとして定義される。

強化スター属性 (Strong star* property):

サブジェクトは、機密度がより高いオブジェクト、またはより低いオブジェクトに対して読み込み/書き込みを実施できない。


基本セキュリティ定理(Basic Security Theorem) :

├ システムがセキュリティ状態で初期化され、全ての繊維がセキュアであれば、その後の状態は入力に関わらずセキュアである。
└ このモデルは機密性を提供するが、システムが保持するデータの完全性は扱わない。

6.4.3. Biba モデル (Biba model)

├ コンピュータシステムの完全性について最初に取り組んだモデル。
├ 階層格子モデルの完全性レベルに基づく。
├ 情報フローモデルであるセキュリティレベルから別のセキュリティレベルへの情報フローについて扱う。
├ 状態機械モデルを採用している。
サブジェクトが下位レベルのデータを読むことができるときに脅威となる、データの完全性の問題を扱っている。
├ 不正ユーザによるデータの変更を防ぐ。
└ あらゆる完全性レベルからのより上位レベルへの情報フローを阻止する。

(主要なルール):
シンプルインテグリティ属性 (Simple Integrity Condition)

サブジェクトは、完全性がより低いオブジェクトを読み取る事が出来ない。
└ “no read down“
インテグリティスター属性 (Integrity star* property)
サブジェクトは完全性がより高いオブジェクトに書き込むことは出来ない。
└ “no write up“
呼び出し属性
サブジェクトは、完全性がより高いサブジェクトにメッセージ(サービスの論理要求)を送信する事が出来ない。

 

6.4.4. Clark-Wilson モデル (Clark-Wilson model):
完全性の3つ全ての目標が対象

├ 不正ユーザによるデータの変更を防ぐ。
├ 正規ユーザによる不適切な変更を防ぐ。
└ 内部と外部の整合性を維持する。

定型化されたトランザクション

├ 内部整合性を維持/保障する。
└ ユーザは、内部整合性が保障される方法でのみデータを操作できる。

責務の分離 (第一の完全性目標と責務の分離を実装)
├ 操作を細分化する。
├ 各部をそれぞれ異なる担当者が実行する。
├ 外部との整合性を保障する。
└ 正規ユーザによる不正な変更を防ぐ。

- 商業アプリケーションにおいて、許可されたユーザが許可されていないデータの更新、不正、エラーを行うことを防止することに焦点をあてることにより情報の完全性を守る。
- ユーザはオブジェクトに直接アクセスしたり操作したりすることができず、プログラムを通じてオブジェクトにアクセスしなければならない。
- また、操作を様々な部分に分けてそれぞれの部分を別のユーザが行わなければならない職務分離も採用している。 このことにより許可されたユーザが許可されていないデータの更新を行うことを防ぎ、完全性が守られる。
- システム外部からの情報を追跡するために監査も必要である。

6.4.5. Chinese Wall Security Policy (Brewer and Nash Model)

├ 公正な競争を確保する。
├ 動的に変化するアクセス許可の実装に用いられる数学的理論
├ ウォール(壁)を定義し、サブジェクトウォールの反対側にいるオブジェクトにアクセスすることのないように、一連の規則を策定する。
├ 各人は、以前アクセスしたデータと軋轢を起こさないデータにのみアクセスが出来る。
├ 利害関係の衝突がないようにするため、制御機能を設置できるようにする。
├ ある会社のデータにユーザがアクセスした場合、競合のデータは自動的に「使用禁止」と見なされるようにできる。
├ 同じ競合データベース内で、競合データを分離する方法。
└ ユーザがオブジェクトに対しての不正な実行が出来ないことの保障を試みる。

6.4.6.情報フローモデル (Information flow model)

├ フローの方向だけでなく、あらゆる種類の情報フローを扱うことができる。
├ オブジェクトセキュリティモデルに基づく。(オブジェクトのセキュリティ属性に従う)
└ 不正な情報フローが許可されていない場合にシステムはセキュアである。

6.4.7. 非干渉モデル (Non interference Model)

└ 上位セキュリティレベルで行われたアクションが、下位で行われたアクションに対して影響を与えたり干渉したりすることのないよう保証する。

 

6.5. 運用のセキュリティモード (Security Modes of Operation)
6.5.1. 専用セキュリティモード (Dedicated Security Mode)

├ 全てのユーザにクリアランスもしくは承認が与えられており、またシステム内で処理されるデータに関して「知る必要」がある。
├ 全てのユーザには、システム上の情報へのアクセス承認が与えられ、この情報に関して機密保持契約に署名している。
└ システムでは情報の分類レベルを1つ使用することが出来る。

6.5.2. システム高度セキュリティモード (System-High Security Mode)

├ 全てのユーザには、情報アクセスのためのセキュリティクリアランスもしくは承認が与えられているが、システム内で処理される情報に関して「知る必要」は必ずしもない(データの一部のみ)。
└ 全てのユーザには最高レベルのクリアランスが必要だが、ユーザはアクセス制御行列を通じて制限される。


6.5.3. 分割セキュリティモード (Compartmented Security Mode)

├ 全てのユーザにはシステムで処理される情報へのアクセスのクリアランスが与えられるが、「知る必要」や正式なアクセス承認はないかもしれない。
├ 職務を遂行するために必要がないため、ユーザはある程度の情報へのアクセスのみに制限されている。
├ また、ユーザはデータに対する正式なアクセス許可は与えられていない。
├ コンパートメントはそれぞれのレベルでのサブジェクトのアクセスの回数が制限されているセキュリティレベルである。
└ CMW / コンパートメント(Compartments): もし必要なクリアランスを持っているなら、ユーザはデータの複数のコンパートメントを処理することが出来る。

6.5.4. 複数レベルセキュリティモード (Multilevel Security Mode):

└ システムで処理される情報に対する正式なアクセス許可を全てのユーザが持っていないとき、同時に2つ以上の情報分類レベルを処理することを許可する。

6.5.5. 信頼と保証 (Trust and Assurance)
信頼(Trust):

└ 顧客に対して、当該システムにどれくらいのセキュリティを期待できるか、どのレベルのセキュリティが提供されるかについて述べる。

保証(Assurance):

└ 全てのコンピューティング状況において、システムは正しく、また期待されたように動く。


6.6. システム評価方法 (System Evaluation Methods)

└ システムのうちセキュリティに関連した部分、つまりTCB、アクセス制御メカニズム、参照モニタ、カーネル、保護メカニズムを評価する。

6.6.1. オレンジブック (The Orange Book) / TCSEC
TCSEC: Trusted Computer System Evaluation Criteria

├ 製品について、うたわれているセキュリティプロパティがあるか、特定のアプリケーションや機能に適切であるかを評価する。
├ 評価においては、システムの機能、効率性、保証について調べセキュリティ要件の典型的なパターンを扱うクラスを使用する。
└ オペレーティングシステムに的を絞っている。

セキュリティレベルのヒエラルキー区分:

├ A. 検証された保護 (Verified protection)
├ B. 必須の保護 (Mandatory protection)
├ C. 任意保護 (Discretionary protection)
└ D. 最低限の保護 (Minimal security)
セキュリティポリシー、責任追跡性、保証、文書化領域)
セキュリティポリシー (Security policy):
 └ 明確でしかもきちんと定義され、システム内のメカニズムによって実行される。

識別 (Identification):

└ 個々のサブジェクトはユニークに識別されなければならない。

ラベル (Labels):

└ アクセス制御ラベルはオブジェクトに適切に関連付けられていなければならない。

文書化 (Documentation):

└ テスト、デザイン、仕様ドキュメント、ユーザガイド、マニュアルを含む。

責任追跡性 (Accountability):

└ 監査データは、責任追跡性のために残し、保護しておかなければならない。

└ ソフトウェア、ハードウェア、ファームウェアは個々にテストすることができ、それぞれがライフタイム中効率的にセキュリティポリシーを実行しなければならない。

継続的保護(Continuous protection):

└ セキュリティメカニズムとシステム全体は、異なる状況にも継続的に期待通りにまた受け入れられるように働かなければならない。

評価レベル

D. 最低限の保護 (Minimal Protection)
C1. 任意セキュリティ保護 (Discretionary Security Protection)    DAC
C2. アクセス制御による保護 (Controlled Access Protection)    DAC
B1. ラベル式保護 (Labeled Security)    MAC
B2. 構造化保護 (Structured Protection)    MAC
B3. セキュリティドメイン (Security Domains)    MAC、ACL
A1. 検証された設計 (Verified Design)    MAC

 

6.6.2. レッドブック (The Red Book) / TNI
TNI: Trusted Network Interpretation.

├ ネットワークとネットワークコンポーネントのセキュリティ評価トピックを扱う。
└ 隔離されたローカルエリアネットワークと広域インターネットワークシステムの両方を扱っている。

(扱っているセキュリティアイテム)
コミュニケーションの完全性(Communication integrity)

├ 認証 (Authentication)
├ メッセージ完全性 (Message integrity)
└ 否認防止 (Non repudiation)

サービス拒否の予防 (Denial of service prevention)

├ 運用の継続 (Continuity of operations)
└ ネットワーク管理 (Network management)

コンプロマイズ予防(Compromise protection)

├ データの機密性
トラフィックフローの機密性
└選択的ルーティング(Selective routing)

レーティング

├ なし(None)
├ C1 . 可(Minimum)
├ C2 . 良(Fair)
└ B2 . 優(Good)

6.6.3. ITSEC 
情報技術セキュリティ評価規格
(ITSEC: Information Technology Security Evaluation Criteria).

├ ヨーロッパでのみ使われている
(2つの主要な属性)
 機能と保証(Functionality and Assurance.)
└ セキュリティ製品とセキュリティシステムの両方のクライテリアで、その両方を評価対象(TOE: Target of Evaluation)として扱っている。

 

6.6.4. コモン・クライテリア (Common Criteria)
 国際的な評価基準.

├ 評価保証レベル(EAL: Evaluation assurance level):
├ プロテクション・プロファイル(Protection profile):
└ セキュリティ要件、その意味、理由の集合で、EAL 評価に相当する。

(2つの主な属性)

機能と保証(Functionality and Assurance.)

└ プロテクション・プロファイルの5つのセクション:
├ 記述要素 (Descriptive elements)
├ 根拠 (Rationale)
├ 機能要件 (Functional requirements)
├ 開発保証要件 (Development assurance requirements)
└ 評価保証要件 (Evaluation assurance requirements)


6.7. 認証 (Certification) <-> 認定 (Accreditation)

対象となる運用環境システムが適切に動作することを評価するためのシステム

6.7.1. 認証 (Certification)

├ システムのセキュリティ機能と防護柵を総合的に(技術的)に分析すること。
├ セキュリティコンポーネントとその整合性の技術的な評価で、認定のために行われる。
└ セキュリティメカニズムと制御およびそれらの効率性の査定プロセスである。

6.7.2. 認定 (Accreditation)

├ システムの全体的なセキュリティが適切であることを、マネジメントが正式に受け入れること。
└ 認証プロセスの結果の情報をマネジメントが公式に受け入れること。


6.8. オープンシステム (Open Systems) <-> クローズドシステム (Closed Systems)
6.8.1. オープンシステム (Open Systems)

├ 公開された仕様に基づくシステムで、サードパーティーベンダがアドオンコンポーネントや装置を開発できる。
└ 異なるベンダの異なるOS、アプリケーション、ハードウェア装置との間の相互運用性を提供する。

 

6.8.2. クローズドシステム (Closed Systems)

├ 業界の標準に従わないアーキテクチャーを採用している。
├ 異なるタイプのシステムやアドオン機能との間のコミュニケーションを簡単にするための相互運用性と標準インターフェイスは採用されていない。
└ 独自仕様であり、似たシステムとだけコミュニケーションができる。


6.9. セキュリティモデルとセキュリティ構造に対する脅威
6.9.1. コバートチャネル (Covert Channels):

許可されていない方法で、エンティティーが情報を受け取る方法で、セキュリティメカニズムでコントロールされない情報フローである。

コバートタイミングチャネル(Covert timing channel) :

└ システムリソースの使用を調節することによって情報を他のプロセスにリレーする。

コバートストレージチャネル(Covert storage channel) :

├ プロセスがあるストレージロケーションにデータを書き込むときに、他のプロセスが直接あるいは間接にそれを読むこと。
└ この問題はプロセスが別々のセキュリティレベルにある場合に生じる。 したがって機密データの共有のためのものではない。

対策:

├ こうしたチャネルに対してユーザができることはあまりない。
└ HTTPを使ったトロイの木馬に対しては、不正侵入検知システムや監査によって隠れたチャネルを見つけることが出来る場合もある。

 

6.9.2. バックドア (Back Doors)
メンテナンスフック ( maintenance hooks)とも呼ばれる。

└ 開発者だけが知っていて呼び出すことが出来る、ソフトウェア内の命令。

 

対策:

└ コードのリビューとユニットテスト、統合テストを行うことによってバックドアを見つけることができる。

バックドアに対する防御策
├ ホスト型不正侵入検知システム。
├ 設定ファイルや機密情報の書き換えから防ぐためにファイルシステムパーミッションを使用する。
├ 厳格なアクセス制御
ファイルシステムの暗号化
└ 監査

 

6.9.3. タイミング問題 (Timing Issues)
非同期攻撃とも呼ばれる。

└ システムがタスクを完了するために必要な一連のステップのタイミング差を利用する。


対策:

├ ホスト型不正侵入検知システム
ファイルシステムパーミッションと暗号化
├ 厳格なアクセス制御
└ 監査

8.9.4. バッファーオーバーフロー (Buffer Overflows)

smashing the stackとも呼ばれる。
└ プログラムに入力されるデータの長さをチェックせずにCPUで処理する場合に起こる。

対策:

├ 適切なプログラミングと望ましいコーディングの実践。
├ ホスト型不正侵入検知システム
ファイルシステムパーミッションと暗号化
├ 厳格なアクセス制御
└ 監査

go to menu page

 

ここまで

narto.hatenablog.com