社内ネットワークインフラのセキュリティ対策

STAMPとSTPAについて

STAMP (System-Theoretic Accident Model and Processes) には、安全解析手法STPA (System-Theoretic Process Analysis) と事故分析手法CAST (Causal Analysis based on System Theory) があります。

システムの開発においては、機能要求のみではなく、安全分析が必要です。STPAを利用することで、安全分析を十分に行うことが期待されます。FMEA (Failure Mode and Effects Analysis) などの古典的な手法は創発事故の分析には適していません。それに対して、STPAは、創発事故の分析に適した安全分析手法です。

このページでは、IPAのSTAMPのページ の用語に従っています。そのため、STPA Handbook の用語とは異なる場合があります。

以下の事例についてご意見等をいただきたく存じます。(メールアドレス: info@jfp.co.jp)

なお、他の事例に関しては 組込みシステム技術協会 (JASA) のSTAMPページ を参照してください。

社内のネットワークインフラの例

概要

本例は社内ネットワークインフラを対象として安全分析を行った事例です。対象とするシステムは一般的な企業の小規模ネットワーク構成を実例としています。

社内ネットワークシステムのセキュリティ対策を要求仕様としてモデル提示し、そのシステムのアクシデントのうち、ヒューマンエラーに関する部分だけを抽出するようにしました。アクシデントからハザード要因を特定し、STAMP/STPAを用いて安全分析を行い、その結果に従い対策を抽出しました。(本来であれば更に要求仕様を更新して、再度アクシデント・ハザードの見直しを行っていくのですが、今回はそこまで実施していません。) システム要求と安全要求を満足させることを目標とします。

ダウンロード

以下のファイルを開くには STAMP Workbench が必要ですので、STAMP Workbenchをインストールしてください。

安全分析で期待される効果

  • 作成時に安全だと思っていた要求仕様に、対応可能な考慮の抜け・漏れ、想定される危険があることを発見できます。
  • 現状の情報整理・情報共有を行い、関係する作業メンバーの間で認識を統一し、理解レベルを向上させます。
  • 情報整理と安全性分析の結果により環境設定を見直し、安全性を向上させます。

分析対象ネットワーク構成

一般的な企業の小規模ネットワーク構成を想定する。

装置の説明

  1. ネットワーク装置: ブロードバンドルーター、ファイアーウォール、IDS等の装置を想定している。それらをネットワーク装置という概念でまとめて示すものとする。VPNサーバーの機能はネットワーク装置が実現するものとする。
  2. 公開サーバー: オンプレミスのWebサーバー、Mailサーバー、DNSサーバー等のDMZに配置してインターネット/社内LANからのアクセスが可能なサーバーを想定している。
  3. 社内サーバー: 社内用ファイルサーバー、NAS、ADサーバー等の社内LANに配置して外部からアクセスできないサーバーを想定している。
  4. 社外レンタルサーバー: 社外の信頼の置けるレンタルサーバー事業者から借りているクラウド上のWebサーバー、Mailサーバー、DNSサーバー等のインターネットからのアクセスが可能なサーバーを想定している。

要求仕様

当該ネットワークの管理に関する要求をまとめる。

ネットワーク装置
  • 装置はネットワーク管理者により適切に管理される。
  • 装置へのログインは、社内LANまたはVPN接続した端末からの要求だけに制限する。
  • DMZにある公開サーバーを適切なフィルタリングを行って公開する。
  • 適切なセキュリティを確保したVPN接続を可能とし、VPN接続したユーザーに対して社内LANへのアクセスを提供する。
  • 動作ログを適切に保存し、ネットワーク装置管理者に通知する。
  • 異常検知時はメールなどを用いてネットワーク装置管理者に通知する。
公開サーバー
  • サーバー管理者により適切に管理される。
  • サーバーの管理者ログインは、社内またはVPN接続した端末からの要求のみに制限し、またアカウントによるアクセス制御を行う。
  • 特定のサービスを社内/社外に公開する。
  • 社内向けのサービスは外部に公開しない。(例: DNSの再帰問い合わせ、SMTPのポート25、SSH、社内ポータルサイトなど）
  • 動作ログを適切に保存し、サーバー管理者に通知する。
  • 異常検知時はメールなどを用いてサーバー管理者に通知する。
社内サーバー
  • サーバー管理者により適切に管理される。
  • サーバーの管理者ログインは、社内またはVPN接続した端末からの要求のみに制限し、またアカウントによるアクセス制御を行う。
  • サービスは社内LAN及びVPN接続した端末からの要求のみに制限し、特定のサービスを利用する場合はユーザーアカウント制御を必須とする。
  • 動作ログを適切に保存し、サーバー管理者に通知する。
  • 異常検知時はメールなどを用いてサーバー管理者に通知する。
社外レンタルサーバー
  • 外部レンタルサーバー事業者により適切に機器のメンテナンスがされるものとする。
  • サーバー管理者により適切に管理される。
  • 管理者ログインは外部レンタルサーバー事業者の用意する方法によりセキュアなアクセスが実現されているものとする。(多要素認証など)
  • サービスを一般に公開する。(Webサイトなど)
  • サービスのうち、必要があればユーザーアカウント制御を行ってサービスの利用を制限する。(Web UIを使用したWebサイトのBlog更新等)
  • 動作ログを適切に保存し、サーバー管理者に通知することが可能とする。
  • 異常検知時はメールなどを用いてサーバー管理者に通知することが可能とする。

安全分析の実施

以下、STAMP Workbenchを用いて安全分析を行った。

前提条件の整理

あらゆる場面を想定すると発散しすぎて分析が困難になるため、前提条件を設けることでヒューマンエラーに注目した分析を行うことにし、要求事項を限定した。

例) ハードウェア故障や、メーカー等から提供されるソフトウェアの不具合などについては想定範囲外とした。

アクシデント、ハザード、安全制約の識別

以下のアクシデントを想定した。

  • ネットワーク装置が正常にサービスを提供することができない。
  • 公開サーバーが正常にサービスを提供することができない。
  • 社内サーバーが正常にサービスを提供することができない。
  • 社外レンタルサーバーが正常にサービスを提供することができない。
  • ネットワーク装置が攻撃などで不正利用され、損害を出した。
  • 公開サーバーが攻撃などで不正利用され、損害を出した。
  • 社内サーバーが攻撃などで不正利用され、損害を出した。
  • 社外レンタルサーバーが攻撃などで不正利用され、損害を出した。

上記のアクシデントを元にハザードと安全制約を特定した。前提条件により、発生するハザードを一定程度絞り込んだ。

分析対象の登場人物の抽出

  • 装置: ネットワーク装置、公開サーバー、社内サーバー、外部レンタルサーバー
  • 人員: ネットワーク装置管理者、公開サーバー管理者、社内サーバー管理者、外部レンタルサーバー管理者

社内外のユーザー、ネットワーク利用者についてはCA (コントロールアクション) がないため、直接の分析対象としなかった。また、自社で管理していないインターネット上のサーバーについてもCAがないため同様に直接の分析対象としなかった。

CS (コントロールストラクチャ) の構築

以下のCS図を作成した。

  • プログラムの更新情報、脆弱性情報を外部からの入力「プログラム更新・脆弱性情報」として記載した。
  • 悪意のあるネットワーク利用者からの攻撃を外部からの入力「不正アクセス・攻撃」として記載した。

UCA (アンセーフコントロールアクション) の抽出

CS図のCA (コントロールアクション) から4種類のUCAを検討して抽出した。今回の分析ではStop too soon/Applying too longのUCAは適用なしとした。各サーバーのサービス提供開始の遅れ、提供終了の遅れについては非UCAとした。

HCF (ハザードコーザルファクター) の特定

UCAからHCF表を作成した。今回の分析では外部レンタルサーバーに関する部分のHCFのみを検討・分析した。

  • 外部レンタルサーバー管理者と外部レンタルサーバー
  • 外部レンタルサーバー管理者と公開サーバー管理者

対策検討

HCF表から対策を検討した。今回の分析では外部レンタルサーバーに関する部分の対策のみ検討した。

STAMP/STPA分析の感想

小規模のネットワークインフラのセキュリティ対策について安全分析を実施しましたが、登場人物や条件を絞っても検討すべき項目が意外と多くなることに気付かされました。そのため、今回は一部分のUCA→HCF→対策抽出までとしました。分析を容易にするために、あえて分析しない項目を増やすなどの分析範囲の制限を実施した方が良いだろうとの感想を持ちました。このことは、安全分析においては、特定の個所に焦点を当てて (限定して) 行うことがよいというセミナー講師陣の見解に当てはまります。

得られた対策から、ネットワーク管理作業には日々のチェックと対応が基本として重要であることを再認識しました。

自動運転ヘリコプターによる山林火災の消火システムの例

この節では、仮想の自動運転ヘリコプターによる山林火災の消火システムを、STPAで解析したものを示します。これらのファイルを開くには STAMP Workbench が必要ですので、STAMP Workbenchをインストールしてください。

今回は2人の担当者がそれぞれにSTPAを行いました。両者の違いとしては、まずシステムの構成が異なっています。例えば、1案では制御用コンピューターがヘリコプターにあるが、2案では地上基地に制御用コンピューターがあるという違いがあります。また、1案ではコントロールストラクチャー図に自動運転ヘリコプターに搭載されているセンサー類が記載されていますが、2案ではセンサー類を記載せず、かわりに自動給油装置などを重視しています。2案の方が機能安全要求モデルが簡潔ですが、といってこのことが機能安全要求モデルとしてふさわしいというわけではありません。

本来は、製品 (システム) 機能要求の仕様を同じにしてから、すなわち製品機能要求分析 (以下、要求分析と呼ぶ) を経てから、機能要求の安全分析 (以下、安全分析と呼ぶ) を行うべきでした。この事例は製品機能要求を機能要求の作成者と安全分析の担当者とが共通にしてから始めた分析ではありません。したがって、両者の間に機能要求の認識の違いがあります。しかし、この例が示すように、安全分析の過程で両者の機能要求の違いが明らかになりました。このことは、要求分析が完了してから安全分析を行うことが基本でありますが、安全分析によって機能要求が変更になる場合もあることを示しています。

今回のSTPAでは、制御用コンピューターをヘリコプターに搭載するか、地上基地に配置するか、という二つの方式の比較を行えるよう、非安全なコントロールアクションの抽出までを行いました。これにより、非安全なコントロールアクションの抽出までを行ったところで、二つの方式を比較できることが分かりました。どちらの方式にするかを決定したら、ハザード要因の特定と対策の立案までを行いたいと考えています。