第2回:セキュリティ評価モデルに基づくセキュリティ設計手法 (2/3)

セキュリティ・アーキテクチャ
EAのセキュリティ要件を実現するSA

第2回:セキュリティ評価モデルに基づくセキュリティ設計手法
著者:みずほ情報総研  金子 浩之、佐久間 敦   2005/4/6
前のページ  1  2   3  次のページ
実稼動環境を考慮したリスクアセスメント

   まず、情報システムが実稼動段階に入った場合を想定してみよう。情報システムは、ある特定の業務プロセスをシステム化して運用するため、特定の設置環境や特定の体制によるシステム運用といった、その情報システム固有の環境が存在する。そのため、情報システムのセキュリティ設計では、当然のことながらその実稼動環境において想定される固有のセキュリティ問題を考慮していかなければならない。

   つまり、
情報資産と脅威を洗い出したうえでの事前のリスクアセスメントが重要であり、セキュリティ設計の初期の段階から、情報資産に対する脅威とリスクを具体的な脆弱性とともに分析し、残存するリスクを見極めていく必要がある。
技術、環境管理の側面をカバーする目標設定

   リスクアセスメントで残存リスクを把握した後は、そのリスクがシステムに対して許容される範囲にとどまるようにするため、最低限の合理的なセキュリティ対策の目標を設定する。セキュリティ目標は、ITによる技術的な目標、対象システムの稼働環境における設置や接続などの環境面での目標、運用体制などの人や手続き上の対策として行うべき管理面での目標、といった各側面の目標からリスクを洗い出し、整理していく。

   この整理段階で重要なのが、個々のセキュリティ目標が、リスクを低減させるための本質となる目標かどうかを十分検討することと、これらのセキュリティ目標全体としての整合を取ることである。目標概念をある一定の範囲でそろえ、シンプルな構造となるようにセキュリティ目標の設定をしていくのが重要となる。


セキュリティ目標に対する要件策定

   最適化されたセキュリティ目標を設定した後は、これらの目標を実現するために必要となる技術的なセキュリティ要件、環境管理面でのセキュリティ要件を明らかにしていく。ここでは、CCが提供するセキュリティ要件のカタログ情報(機能要件の雛形となるもの)やISMSなどを参考にして、対象システムのセキュリティ要件を策定していく。情報システムの設計で要件の定義が重要であるのと同じく、セキュリティ設計においても、要件をいかに的確に定義できるかがカギとなる。


実装、運用における「保証」の枠組み

   策定されたセキュリティ要件に基づき、セキュリティ対策としての情報システムへセキュリティの実装、運用体制の整備などを進めることになるが、現実には100%完璧なセキュリティを実現するのは難しい。

   そこで、まず情報資産の価値、損害や被害のリスク、セキュリティ対策のためのコストなどを総合的に勘案して、実現可能なセキュリティレベルを設定する。そして、それをクリアするための対策としてセキュリティ対策を位置づける。問題は、各種の対策が本当にそのレベルをクリアしているかをどのように「保証」するかということになる。ここでいう「保証」とは、システムの開発者、運用者が相応の対応を行なうことによって、セキュリティ対策として十分とみなすことができる具体的手段を設定し、講じることである。

   セキュリティ評価モデルにおける保証構造のイメージを図2にしめす。ここでは、検討対象とするシステムについて、設計から実装、導入を経て運用に至るまでに作成される代表的なドキュメントと、各ドキュメントの主なシステムの領域をしめしている。

EA/SAの対象とするシステムの保証構成のイメージ
図2:EA/SAの対象とするシステムの保証構成のイメージ
(画像をクリックすると別ウィンドウに拡大図を表示します)


   これらのドキュメントは、設計内容や操作手順を表現するために記載したものもあれば、システムの設計や運用を進める上での方針、手続きのほかに、これらの方針や手続きにしたがって確かに実施されたことの証拠となる記録を含んでいる場合もある。

   ここにしめすようなドキュメント群によってシステムセキュリティを漏れなく、効果的に表現しようとした場合、システムのセキュリティを定義するために体系的に意味ある分類で構成することが重要であり、そのためには、システムのアーキテクチャやライフサイクルを意識して、ドキュメントや証拠を構成することが必要となってくる。

   そこで、セキュリティ評価モデルでは、システムアーキテクチャやシステムライフサイクルを踏まえ、システム管理の側面から保証の対象範囲を構造化し、システム全体として、また個々の管理構造の単位として、システムの実装及び運用において何を「保証」すべきかを明らかにしていく。

   図2の例では、システム全体としての設計や導入管理、システム全体の運用管理のほか、アプリケーション開発管理、システムインフラ管理、システム利用者管理の側面からなる保証構造をしめしている。このワークフレームにより、セキュリティ問題に対する具体的対策の信頼性を担保する基準がしめされる。

前のページ  1  2   3  次のページ


みずほ情報総研
著者プロフィール
みずほ情報総研株式会社  金子 浩之
みずほ情報総研株式会社 情報セキュリティ評価室 室長
経済産業省が進めるITセキュリティ評価認証制度の認定を受けた評価機関(情報セキュリティ評価室)においてITセキュリティ評価・コンサルティング事業を担当。そのほか、最近では、システムのセキュリティ評価技術の研究開発、情報セキュリティをはじめとする受託調査、研究開発、システムセキュリティ評価、システム監査等に従事。


みずほ情報総研
著者プロフィール
みずほ情報総研株式会社  佐久間 敦
みずほ情報総研株式会社 システムコンサルティング部
情報セキュリティをはじめとする情報政策関連調査研究、政策立案コンサルティング、IT関連技術動向調査等を担当。最近のプロジェクトは、情報セキュリティ人材育成に関する調査研究、重要インフラにおけるセキュリティ現況調査など。現在、日本ネットワークセキュリティ協会スキルマップ検討ワーキンググループリーダーを担当。


INDEX
第2回:セキュリティ評価モデルに基づくセキュリティ設計手法
  今回は
実稼動環境を考慮したリスクアセスメント
  「セキュリティ・アーキテクチャ」の効用
EAのセキュリティ要件を実現するSA
第1回 セキュリティ・アーキテクチャのコンセプト
第2回 セキュリティ評価モデルに基づくセキュリティ設計手法

人気記事トップ10

人気記事ランキングをもっと見る