STPAの第2ステップで肝となる「CS図」は物理モデルではない：今こそ知りたい！STAMP/STPAの勘所（3）（3/3 ページ）

より複雑なシステムの安全性解析の理論とその分析手法である「STAMP/STPA」を実践する上での勘所をTips形式で簡潔に分かり易く説明する本連載。第3回は、STPA分析において“最もSTAMPらしい手順”であるCS図（コントロールストラクチャー図）の構築について解説する。

[石井正悟，MONOist]

CS図構築の誤った例と正しい例

　上記の注意点を見逃して、あるいは勘違いしてCS図構築を誤った例と正しい例を示す。（正しい例とは、唯一の正解ではない）。この例の題材は、JASA（組込みシステム技術協会）のSTAMP広場から流用した。

システム概要と問題意識の共有

　図3は、一般的な企業の小規模ネットワークを分析対象として、ステークホルダー間でシステム概要の認識を共有するために作成したシステム構成図（ポンチ絵レベルの概念図）である。

　そして、この開発案件の関係者は、悪意ある攻撃からシステムを守るため、赤枠で囲った部分の安全確保が重要と考えている。

図3　システム構成図の例［クリックで拡大］

誤ったCS図の例

　図4は、システム仕様を実現するためのシステム構成図をそのままCS図として使った、誤ったCS図の例である。前述した図3のシステム構成図の黒枠で囲った社内ネットワークシステムのコンポーネントを全てCS図に組み込んで、配置を変えただけのモデルになっている。

図4　誤ったCS図の例［クリックで拡大］

正しいCS図の例

　アクシデント／ハザードが絞り込めていれば、直接関与しない構成部分は省略、抽象化できる。この社内ネットワークシステムの分析においては、「ネットワーク装置に関連するアクシデント／ハザードについて安全分析する」ことをステークホルダー間で認識共有しているので、図4で挙げた誤ったCS図に対して次の点を修正した。

• 直接制御できない外部レンタルサーバは分析対象の範囲外とする
• ネットワーク装置との関係に着目するのに社内サーバと公開サーバは区別する必要がない
• 外部レンタルサーバを省略し、社内サーバと公開サーバは抽象化して一つのサーバとする
• システム仕様として、外部レンタルサーバが直接制御できるものだとしても、「サーバ」としてひとくくりにしてよい
• 権限（責任）の上下関係を明確にする

　そして修正された正しいCS図の一例が図5である。

図5　正しいCS図の例［クリックで拡大］

まとめ

　本記事で解説したCS図作成の重要ポイントは以下のようにまとめられる。

• CS図は物理モデルではなく、機能モデルである
• 分析対象ハザードに絞り込んでモデリングする
• 各コンポーネントの責任を明確にする
• 抽象的なレベルで始める

　これらの重要ポイントは、CS図構築後のレビューの観点ともなる。レビューの観点は他にもある。

• コンポーネントやコントロールアクション、フィードバックの名前は特定の物理的な実装名ではなく、機能を説明しているか
• コントロールアクション、フィードバックの名前が「コマンド」または「フィードバック」のような曖昧で漠然とした名前でないか
• 全てのコントロール対象の物理的プロセスは、1つ以上のコントロールをされているか（必須ではないが、しばしば間違いが見つかる）
• 競合している場合も含めて責任の関係が見えるか
• 責任を満たすために必要なコントロールアクションが含まれているか
• 責任を満たすために必要なフィードバックが含まれているか（コンセプト開発の初期にはフィードバックが不明なこともあるが、後の分析ステップで欠落しているフィードバックを識別できるので、CS図を初期構築した時点で全てが列挙されていなくても分析を先に進めるとよい）
• 双方向のコントロールアクションが含まれていないか

　これらのレビューの観点について本記事では詳述しないが、レビュー時のチェック項目として参考になれば幸いである。

---

　次回は、UCA（非安全なコントールアクション）の書き方についてのTipsを紹介する。（次回に続く）

筆者プロフィール

石井 正悟（いしい しょうご）

京都大学理学部卒業後、東芝にてOSカーネル、仮想計算機、システム高信頼化技術、システムシミュレーション技術の研究開発に携わる。その後IPAにて、STAMP、FRAMなどの安全性解析手法の調査研究に従事。STAMP普及促進のため、書籍「はじめてのSTAMP」シリーズ発行、STAMP支援ツール「STAMP Workbench」開発や各種教材作成などを担う。現在はIPA専門委員としてSTAMP普及活動に関わる。

・IPA デジタル基盤センター STAMPサイト