情報脅威科学、脆弱性およびリスク管理

当初、このテキストは、「 情報の危険性 」というトピックに関する チェンバレンのコメントへの回答として作成されましたが、最終的には別の投稿のボリュームにまで成長したため、この形式で公開されます。
そもそも、元の投稿の著者に100％同意できる唯一のポイントは、「セキュリティ」という用語の非構築性です。 語源のおかげで、情報に対する危険がないことを保証するための規律として情報セキュリティの概念を作成することにより、この用語は将来誤解を招く可能性が非常に高くなります。 この主題分野のより正確で反射的なエッセンスは、このトピックの名前として使用される用語です。 しかし、残念なことに、物語はそうではなく、「IB」という用語は、例えば「ハッカー」という用語と同じくらい広く解釈され、IB自体の混乱と理解不足があります。 情報セキュリティの基礎となるもの、このサブジェクト領域のフレームワーク内で解決されるタスク、およびこれがどのように発生するかを把握してみましょう。

少しの情報理論

残念ながら、私たちの質問に対する答えを得るには、理論を少し掘り下げる必要があります。 ここまで、「セキュリティ」という疑わしい用語を残して、対象分野の名前の最初の要素である「情報」について考えてみましょう。 この用語の単一の標準化された定義はないため、多くの分野で最も一般的で広く使用されているものを取り上げます。

情報は、信号、メッセージ、ニュース、通知などで表される世界に関する意識的な知識であり、保存、変換、送信、使用の対象です。

情報は保存、変換、送信、使用の対象であるという事実にもかかわらず、これらのアクションを実行する手段（キャリア、ソース、送信チャネル、受信機）から分離して考えることができます。その組み合わせは「情報システム」という用語でよく知られています（ IP）。 以下、「IP」という用語は、情報技術の主題分野よりも広い意味で使用され、そのようなシステムを実装するための技術的方法のみに限定されないことに注意する価値があります。 情報は、そのシステムと4番目の次元（つまり、時間を意味します）に関係なく、累積的、非連想的および非可換的、集中、老化、散乱など、属性属性と呼ばれる多くの属性を持っています。 特定のシステムと組み合わせて情報を検討し、時間を考慮すると、情報には、客観性、信頼性、完全性、正確性、関連性、冗長性、関心のあるセキュリティなど実用的な新しい特性があります。 実用的なプロパティは、時間のばらつきにより、呼び出し状態に対してより正確であり、安全性も例外ではありません。 これは、情報が現在安全であれば、つまり それがセキュリティ状態にある場合、これはまだしばらくの間そうであることを意味しません。 しかし、どの情報を安全と呼ぶことができますか？ このプロパティのプラグマティズムから、考慮されている期間中に保護されたシステムで保存、処理、および送信されるプロパティが従います。 言い換えれば、情報自体は、それ自体は安全でも安全でもあり得ませんが、情報が「存在する」システムによって完全かつ完全に決定されます。 システムのセキュリティ状態は、次の3つの必要な状態で構成される累積的なプロパティですが、常に十分な状態ではありません。

- 機密性 --情報を受信する権利を持つIPエンティティのみが情報を受信できることを意味します。
- 整合性 、-情報が不正な変更の対象ではなかったことを意味します。
- アクセシビリティ --情報にアクセスする権利を持つ各IPサブジェクトには、それを実現する機会があることを意味します。

リストされた状態は、いわゆる標準情報セキュリティモデル「CIA」を形成します。 特定のIPの詳細と実装の詳細、さらに特定の情報ストリームまたはコンポーネントに応じて、他の条件も考慮される場合があります。 そのため、技術情報システムで広く使用されているSTRIDE脅威モデリングの基礎となるセキュリティモデルでは、さらに3つの状態が導入されています。

- 信ity性 -サブジェクトまたはIPオブジェクトは、識別または主張されたとおりのものであることを意味します。
- 許可 、-オブジェクトに関連する本物のエンティティのアクションの範囲が制限されることを意味します。
- 魅力 、-IPのサブジェクトには、オブジェクトに関連するアクションの作成者を拒否する機会がないことを意味します。

リストされた状態はすべて永続的な特性ではないため、いつでも1つまたは複数の状態に違反する可能性があることは明らかです。 これは脅威と呼ばれます。

脅威科学

実際、前述のSTRIDEは、リストされているIP状態のそれぞれに対する違反の脅威の名前の略語です。

- なりすまし 、-真正性;
- 改ざん 、-整合性;
- 拒否 、-魅力;
- 情報開示 、-機密性;
- サービス拒否 、-可用性。
- 特権の昇格 、-承認。

すべての脅威が各IPオブジェクトに関連するわけではないことは明らかです。 関連する脅威を識別するために、それらのモデルが構築されます。 脅威モデルの構築には多くのアプローチがありますが、最も一般的で正式なアプローチはデータフロー図（DFD）に基づいています。 このアプローチの詳細な議論は、別のかなり大きな記事のトピックであるため、一般的なストロークで検討します。 まず、シミュレーションシステム用に最上位のDFDが構築されています。 従来、このような図の要素は次のとおりです。

- プロセス 、-情報を処理または転送するIPコンポーネント。
- インタラクター 、-IPに関する任意のコンポーネントとの情報交換を実行するIPに関する外部コンポーネント。
- ストレージ 、-情報を保存または転送するIPコンポーネント。
- データストリーム 、-プロセス、インタラクター、ストレージ間で情報を交換するためのチャネル。
- 信頼の境界 、-データフローを通過し、信頼できるIPコンポーネントを信頼できないIPコンポーネントから分離します。

その後、各コンポーネントタイプに対する脅威の関連性（これらはすべてプロセスに対する脅威です;インタラクターのSとR、ストレージのT、R、I、DおよびデータストリームのT、I、D）および情報にも基づいていますデータフローによる信頼限界の交差について、検討中のモデルの現在の脅威のリストが作成されます。 次に、図の各要素の分解が、このコンポーネントが個別のISであるかのように実行され、必要に応じて、内部を循環するデータフローも信頼の境界によってマークされます。 受け取ったDFDに基づいて、現在の脅威のリストが再構築され、以前の脅威を補完します。 このプロセスは、モデルの達成された詳細レベルが新しい実際の脅威の導入をやめるまで、または分解が可能になるまで再帰的に繰り返されます。 その結果、タイプ図が得られます（写真は記事から取られています。リンクは以下にあります）。



...そして、小規模システムの場合でも、問題のIPに関連する情報脅威のリストは非常にまともです。 モデルの十分な詳細度に達すると（実際にはこの程度はかなり達成可能です）、私たちに関連するすべての脅威のリストを取得することに注意してください。 このプロセスについて、さらに詳しく、図を使用して、たとえばここで読むことができます 。 さらに、STRIDE： Threat Modeling Toolを使用して脅威モデリングプロセスをさらに自動化できる非常に便利なVisioベースのツールもお勧めします。このドキュメントには、プロセスのかなり詳細な説明と、実際のシステムの既製モデルの例（TMTとVisual Studioを統合するためのプラグイン）が含まれていますTFS、正確には）。

ただし、構築したモデルではIP実装の詳細を考慮していないため、ほとんどの場合、現在の脅威のかなりの部分が閉じられます。 たとえば、インタラクターとプロセス間の信頼境界を通過する情報を交換するために安全なチャネルが使用される場合、対応するデータストリームの脅威TおよびIは既に閉じられています。 これに加えて、暗号化ツール（クライアント証明書、デジタル署名）を使用してインタラクターの信頼性を確認する場合、このコンポーネントで脅威Sを閉じることなどについて話し合うことができます。 最終的に、IPに対策が実装されていないすべての脅威のリストを取得します。 システム内のこのような脅威の存在を条件付ける条件は、脆弱性と呼ばれます。

脆弱性

正式には、「脆弱性」とは、システムまたはその個々のコンポーネントに関連する特定の情報の脅威の実現を促す一連の要因と条件です。 1つの脆弱性が一度に複数の脅威の実装に寄与する可能性があります。 脆弱性は常に脅威を実装するための特定の方法ではなく、脅威の実装が多くの脆弱性の組み合わせを引き起こし、それらのいずれかを排除することにより、この脅威を閉じますが、それはそのままにしておきます。残りの脆弱性をすべて排除するまで、その実装に役立つシステム条件。 そして、ここで私たちは興味深い問題に直面しています：脅威がすでに閉じられている場合、それらを排除することは価値がありますか？ とにかく、特定されたすべての脅威を排除する価値はありますか？ 結局のところ、それらのいくつかを実装することによる損害は、それらを引き起こす脆弱性を排除するために費やされる資金よりも著しく低いかもしれません。 そもそも、どの脅威を閉じる必要があるのか​​、次にどの脅威を閉じ、どの脅威を閉じないのかを理解するにはどうすればよいですか？ これを行うには、特定された各脆弱性を検討し、特定の情報の脅威がそれを通じて実現される可能性を推定し、実装による損害を評価する必要があります-脆弱性の修正コスト、人件費など、私たちにとって興味深いいくつかの要素を考慮に入れる必要があります つまり、システム内の各脆弱性の存在に関連するリスクを評価する必要があります。

リスク管理

このプロセスは情報セキュリティの分野に固有のものではなく、リスク管理の規律に言及しているため、何が何であり、リスク評価方法は汚れのようなものです。 それにもかかわらず、技術情報システムの脆弱性リスクを評価するために、2つの方法が伝統的に使用されています。 1つ目はDREADと呼ばれ、このスケールが考慮に入れる要因の略語です：

- 損傷の可能性 、-脆弱性の悪用による脅威の実装による損傷の評価。
- 再現性 、-脆弱性の悪用の再現性;
- 悪用可能性-脆弱性の悪用の容易さ;
- 影響を受けるユーザー 、-脆弱性の悪用による脅威の実装によって影響を受けるユーザーの対象者の評価。
- 発見可能性-脆弱性の検出可能性。

識別された脆弱性のそれぞれについて、リストされた要因が0〜10で評価され、合計リスク値が次の式で計算されます。

Risk_DREAD =（ダメージ+再現性+エクスプロイタビリティ+影響を受けるユーザー+発見可能性）/ 5

次に、そもそもどの脆弱性を解決する必要があるのか​​を理解します。 ただし、DREADは本質的に非常に評価的であり、たとえば、推定される脆弱性が実現する脅威や、システム全体のセキュリティ状態への影響など、多くの要因を考慮していません。 より詳細な評価のために、CVSS（Common Vulnerability Score Sytem）スケールが使用されます。これは、少なくとも1つのbugtraqメーリングリストに登録している全員が満たしています。 脆弱性の説明では、 AV：N / AC：L / Au：N / C：N / I：N / A：Cなどのベクトルは？ まあ、これはCVSSです。 スケールは非常に複雑で、非常に多くの要因を考慮しているため、ここで詳細に描くことは合理的ではありません。 このスケールの仕様はここにあり、計算機（式はDREADよりも少し複雑なので）があります 。

最初のトピックで見掛け倒しに起因し、情報セキュリティ管理プロセスの本質的な最終目標であるという事実にもかかわらず、リスク評価：情報システムの特定の脆弱性の悪用に関連する情報セキュリティリスクのアイデアを得て、これらのリスクを許容可能なレベルに減らすため。 これ以上ではありませんが、それ以下です。

実際、これが情報セキュリティの主題分野に関連するすべてです。 ただし、元のトピックおよびそれに対するコメントでは、いくつかの質問が提起され、ここでは未回答のままでした。 それらを考慮して、ここで終了します。

分類、標準、認証

この投稿を読んでいる間に、誰かが脅威モデリングが非常に骨の折れる日常的なプロセスであると感じていた場合、彼は絶対に正しいです。 これは非常に低レベルのアプローチであり、非常に良い結果を達成することができますが、人件費は非常に深刻です。 一方、技術情報システムを検討する場合、個々のグループ間で共通する何かを選択することは非常に可能です。 例としてWebアプリケーションを考えてみましょう。モデル構築の最初の反復で特定された共通の脅威をどのように多くの異なるWebアプリケーションが持つと思いますか？ ほとんどの。 そのため、実装の詳細に関係なく、IPの仕様が各Webアプリケーションに関連するいくつかの基本的な脅威のセットを既に提供している場合、毎回新しいモデルを作成するのはなぜですか？ そして、特定のツール、Webアプリケーションの実装手段を考慮に入れた特定の一般化されたモデルの検討の結果として、 WASCとOWASPからの脆弱性分類が現れました 。 XSS、SQLi、LFI、CSRF、さまざまな設定ミスなど -それはそこからです。 そして、これらは脆弱性ではありません。 これらはクラスです。 脆弱性は、特定のIPに固有の特定の要因と条件になります：SQLクエリのテキストを生成するとき、またはHTMLドキュメントのテキストを生成するときの入力データのスクリーニングの欠如、ユーザーパラメーターで送信されるパスフラグメントの不十分な制御、HTTPリクエストのソースの信頼性の制御の欠如.p。

しかし、特定のIPから切り離して、XSSの操作によってどの情報の脅威を実装できるかを誰かが言うことはできますか？ さて、主なことは理解できます：サーバーからユーザーのブラウザに渡されたドキュメントの整合性の違反、そして何ですか？ セッショントークンのプライバシー違反？ はい、そうかもしれません。 そして、これには少なくともなりすましと議論の余地があります。 また、管理者セッションがハイジャックされた場合、権限が増加します。 そして、セッションが止められないが、CSRFの条件がある場合は？ 脅威の同じセットまたは別の？ そして、概して、開発者はそれを必要としますか？ 結局のところ、コードにXSSの条件が含まれていない場合、これらの脅威が何であれ、その操作を通じて実装できる脅威も存在しないことは確実です。 IPエンジニアリングの特定の主題分野における脆弱性分類は、次のレベルの抽象化にすぎません。これにより、骨の折れる脅威モデリングから抜け出し、すでに策定された特定の対策を実施できます。 そしてもちろん、システムが一般化モデルに準拠していないほど、これらの対策の効果は低くなります。

標準はさらに高度な抽象化であり、システムのセキュリティステータスを保証するだけでなく、他の人にシステムの提供を納得させるために設計されています。 規格は一般化されすぎて、そこに記載されている対策の有効性について語ることができません。 この標準に準拠していることを確認する文書を受け取るだけでなく、十分に保護されたシステムを持つというタスクに直面している場合は、他のタスクを解決し、ほぼすべてのシステムについて補足および明確化する必要があります。 認証に関しては、これは規格の主な目的の直接的な結果です。 そして、多くの大企業や州に関心があるため、これは特定のビジネスに従事し続けるために経験しなければならない避けられない悪と呼ばれています。 標準-標準、認証-認証、および情報セキュリティは、プロセスと交差していますが、それらは「少し」異なっています。

元の投稿の著者へ

情報セキュリティの測定は非常に困難です。 また、技術IPでも人が主な要因であるため、数学とアルゴリズム化の言語に移行することは困難です（これは、PMに開発およびプロジェクト管理プロセスを詳細にアルゴリズム化するよう求めることとほぼ同じです）。 少なくとも彼らが開発しているからです。 しかし、ここでのポイントは、このすべてがこの主題分野の目標ではないということです。 私自身は、基準を順守する必要性について賢く語り、脅威をモデルに呼んで「夏のオフィスでの過ごし方」というトピックに関する悲惨なエッセイを呼び出し、脅威の用語を理解せずに対策を導入しようとする「ホワイトカラー労働者」が好きではありません。上で声をかけた、彼らは本当に近い。 すべては選択です-「情報セキュリティの専門家」はい。 したがって、誰かがIPセキュリティの評価として制限付きで動作を開始する場合、またはどのシステムにも危険がないことを確認する必要性について話す場合、私はあなたに尋ねます：彼の目に指を突いて、それが私からだと言ってください 情報セキュリティのタスクは、脆弱性を特定し、その悪用に関連するリスクを管理するすべての関連する脅威を識別することです。

脅威の調査、脆弱性、リスク管理。