🔄
top of page

Latest Articles

脅威から情報資産を守るための分析手法 〜脅威に対して先手を打つ〜

  • Pipeline Co. Ltd.
  • 2021年2月15日
  • 読了時間: 7分

脅威から情報資産を守るための分析手法 〜脅威に対して先手を打つ〜
脅威から情報資産を守るための分析手法 〜脅威に対して先手を打つ〜

情報セキュリティ対策は、守るべき情報資産と、それに対する脅威から守るためにどこに対してどのように実施するのか、を漏れなく把握し、優先度を設定して効果的に対策したい。この一連の作業はベクトプラクティスがある。したがって、各組織において特殊な事情を加味する必要はあるものの、ゼロベースから試行錯誤しなくてもよい。


このベストプラクティスはセキュリティ要求工学の分野における考察に存在する。そこには、脅威がシステム上にあると仮定して、それが発生したときのリスクを洗い出し、各リスクへの対策はどのようなものがあり、対策ができているか等を考察、評価するための手法がある。一般的には脅威分析と呼ばれており、脅威分析は考え方だけでなく、分析・識別・評価する作業方法も含まれる。


セキュリティ対策において、そこに無限にリソースを割り当てることは現実的ではないので、対策の網羅性をカバーしつつ、優先順位付けを行うことになるが、脅威分析はそれも考慮されており、また、これがセキュリティ対策を進めていく過程での舵取りとなるため、重要なツールであるといえる。


脅威分析のステップ

脅威分析の一連のプロセスを以下に示す。

  1. DFDを作成し、信頼境界線を引く・・・データの流れを可視化し、その中から対策すべき箇所を可視化する

  1. 攻撃者のゴール・目的の分析・・・攻撃者は攻撃によりどのような成果が得られるのかを分析する→Attack Treeのルートが決まる

  1. 被害の分析・・・さまざまな攻撃により発生する被害によってどのような困ることがあるのかを分析する→脅威評価において影響度を決定する情報となる

  1. 資産の識別・・・攻撃者の目的や被害に合致する要素を抽出する→脅威評価において情報資産の価値を算定する対象が決まる

  1. 脅威の識別・・・抽出した資産に対して攻撃者がどのような攻撃を仕掛けてくるかを分析する (STRIDE法など)→脅威評価において難易度を決定する情報となる。あわせて、Attack Treeのノードとツリー構造ができる。

  1. 脅威の評価・・・洗い出した攻撃手段を検証し(Attack Treeは検証材料となる)、影響の大きさをDREAD指標で評価する



DFDを作成する作業について 〜信頼境界線を引く〜

DFDでは、流れるデータの大まかな種類やデータの保存場所、登場人物などを描く。まずここで網羅性を高める。次に、入力と出力のどちら側になるのかを経路に加える。これにより、実際に発生するデータの動きが可視化される。

また、もし網羅性を高めた結果、図が複雑になり、可視化に影響するようであれば、データフローを大まかにパターン分けして、それらパターン毎に描くという工夫も必要になる可能性はある。


DFDが仕上がると、信頼レベルが異なる範囲が見えてくるだろう。その範囲の境界に当たるところを信頼境界線と呼ぶ。例えば、ユーザ-Webサーバ間の【リクエスト】→【レスポンス】が発生するところや、Webサーバがデータベースへ【問い合わせ】→データベースからWebサーバへデータを【応答】するところ等が相当する。作業としては信頼境界線を引くことになるわけだが、この意図は、セキュリティ的な問題は信頼境界線をまたぐ際に発生しやすいということからである。→Attack Surface(攻撃面)の存在 

信頼境界線に注目して対策を考えると、全てではないものの、多くの作業はそこにおいて行われることになるだろう。


信頼レベルの設定は、どこまで自組織でセキュリティをコントロールしているのかの度合いで変わる。言い方を換えると、信頼境界線は信頼レベルの設定を変えると境界線が移動する。極端な例では、全て信頼できない(信頼性=0)とすると、信頼境界線は存在しないということになる。ただし、こうしてしまうと、対策を考える手数が膨大になり、対策を実現するコストも膨大となる。したがって、現実性を考慮して信頼レベルの設定をしていくことになる。


また、信頼境界線の範囲内は完全に脅威はないという訳ではないことにも注意が必要だ。例えば、範囲内にあるアプリケーションの不具合や設定ミスにより、重要な情報を意図せず外

部に出力してしまうといったように、内部起因の可能性も考える。


図1
図1

図1 DFDの一部と信頼境界線


Attack Tree(脅威ツリー)

Attack Tree(脅威ツリー)で攻撃者の目標に対してそれを達成する手段を洗い出し、ツリー構造で記録する。ツリー構造は次のようになる。

・攻撃者の目標を洗い出して、その目標をツリーの1番上(ルート)に記載する

・目標に対する攻撃手段を洗い出し、それらをノードに記載する

・ノードは複数分岐・階層になり得る。

      図2
図2

図2 Attack Treeの例


脅威モデリング(STRIDE)

攻撃者がどのような攻撃を仕掛けてくるかを分析する際の考えるポイントとなる。これまで発生してきた攻撃パターンを分類したものである。それは以下のようになっており、英語の頭文字をとって、SPRIDEと呼んでいる。


なりすましSpoofing)・・・悪意ある第三者が正規のユーザを装う(例:攻撃者がシステムにログインする)

改ざんTampering)・・・データを改ざんする(例:攻撃者がデータベースに記録されている情報を誤った情報に書き換える、情報を削除する(破壊行為)、正規ユーザが被害を受けるように誘導する仕組みの書き込みを行う。例えば、SQLインジェクションといった手法がある。)

否認Repudiation)・・・ログの消去により証拠隠滅を図る(例:攻撃者がWebサーバのアクセスログを消去する)

情報の漏えい・意図しない開示Information disclosure)・・・個人情報など公開してはいけない情報が漏えいする

DoS攻撃Denial of Service)・・・サービスに多大な負荷をかける(例:攻撃者が意図的にWebサーバにアクセスを集中させて、その結果Webサーバは要求処理ができなくなる。これにより正規ユーザの正常なアクセスが阻害される。)

権限昇格Elevation  of  privilege)・・・管理者権限を持っていないユーザが管理者権限の操作ができるようになる(例:攻撃者がWebサーバ内で不正なプログラムを実行する)


 さらに、Attack Libraryとして脅威の具体例なども記録する。ここに、過去に洗い出された情報を蓄積していく形をとる。この情報はセキュリティ対策において有益な情報となる。


DREAD評価とリスク値の算出尺度

DREADとは、以下のことを指し、ある脅威が資産に対してどれだけの影響を与えるのかを評価する際のポイントとなる。


潜在的な損害Damage  potential)

再現可能性Reproductivity)

脅威の発生時の成功の可能性Exploitability)

影響ユーザAffected  users)

発見可能性Discoverability)


これらの観点で、リスク値の算出を以下のような尺度により行う。

攻撃難易度・・・簡単普通困難(【脅威の発生可能性】(技術的に実現されるものか(再現可能性))×【脅威の発生時の成功の可能性】(自組織内で対策されていれば=低、対策が進められている最中=中、対策できていなければ=高))+発見可能性を考慮する場合もあり(脆弱性が公開されている場合は発見可能性は100%であり、度合いを調整する事項では無くなる)

影響度・・・(情報資産の価値(重要度=影響ユーザ数・種類)と関連、ここには潜在的な損害も考慮)


こうして、対策すべき事柄と着手タイミング、かけるべきコストが明らかになり、対策着手の優先順位が確定する。そして対策が実装されることになるが、その結果を次の脅威分析に反映させることも必要だ。こうして、分析と対策のサイクルを繰り返すことになる。


脅威分析のコスト削減

脅威分析は自組織内の人のみで行うよりも、外部の視点も取りいれた方が対策の網羅性を高められる可能性がある。その点では、様々な組織におけるセキュリティ対策に関わってきた経験豊富なセキュリティ会社と連携して分析を進めると、模索のコストが削減されるだろう。

また、外部クラウドサービスを利用している場合は、各サービスで責任分界が定められているため、サービス運営側の責任において管理する範囲においては自組織では考慮する必要は発生しないだろう。例えばAWS(Amazon Web Service)では「責任共有モデル」 1)を採用している。AWS側では物理的な設備〜ハードウェア〜クラウドサービスを実現するソフトウェアが責任範囲、ユーザ側はクラウドサービス上でユーザサービスを実現するために構築されたシステムやデータ、ユーザサービス内のセキュリティ等が責任範囲となっている。この点も考慮して分析コストを下げることができる。


情報共有モデル
情報共有モデル

図3 AWSの「責任共有モデル」出典1)


最後に

ここでは、脅威が発生する前に手を打つ手段として有効な脅威分析を紹介した。

脅威分析は1回行えば安心というものではなく、対策とその過程で得た情報を蓄積していくことを繰り返す、という継続的な改善活動が必要であることを強調したい。



(出典)


Latest Articles

Latest Articles

bottom of page