Qiita
You are not logged in to any team
Log in to Qiita:Team...
Community
List of all usersList of all organizatioinsAdvent Calendar
Qiitadon (β)
Community GuidelineHow to write good articles
Sign upLog in
1473690211 @t_nakayama0714
Edited at

ゼロから考える脆弱性対応

セキュリティ脆弱性運用

はじめに

こんなツイートを見かけました。

たしかにそうだなぁ。力試しに書いてみよう。

脆弱性とは

さて最初に、これから考えていく脆弱性とはなんでしょうか。
いつものようにWikipediaで見てみます。

脆弱性（ぜいじゃくせい）は、英語の vulnerability の日本語訳である。この分野での意味は「 弱点 」であり、セキュリティホール（安全性欠陥）と類似している。ただし、セキュリティホールがより具体的な欠陥を指す傾向があるのに対して、脆弱性は欠陥だけではなく、たとえ意図した（要求仕様どおりの）動作であっても、攻撃に対して弱ければ、つまり「弱点」があれば用いるという点が異なる。

脆弱性情報と向き合う場合、英語ソースは避けて通れないので「 脆弱性 = vulnerability 」は必ず覚えておきましょう。
ちなみに脆弱性のページはセキュリティホールのページへリダイレクトされます。じゃあセキュリティホールはなんだというと...

セキュリティホール は、 脆弱性についての俗表現 である。 脆弱性は、コンピュータソフトウェアの欠陥（バグ、不具合、あるいはシステム上の盲点）の一つで、本来操作できないはずの操作（権限のないユーザが権限を超えた操作を実行するなど）ができてしまったり、見えるべきでない情報が第三者に見えてしまうような不具合をいう。ハードウェアおよびそれを含めたシステム全般の欠陥を指すこともある。

しれっと書いていますがセキュリティホールが「脆弱性の俗表現」ではなく「脆弱性に ついて の俗表現」というところがポイントですね。指し示すものがイコールではないということです。

脆弱性の説明にあるように、セキュリティホールがあくまで 意図しない欠陥を指す のに対し、脆弱性は結果的に弱点となってしまった 仕様などを含む ということが呼び分けの線引になります。
ほとんどの場合、脆弱性もセキュリティホールも「 システムに対して望ましくないもの 」という文脈で語られると思うので、これらの齟齬で致命的なコミュニケーションロスとなることはないと思いますが、一応頭に入れておくとよいでしょう。

以上のように、 (脆弱性) ⊃ (セキュリティホール) となるため、引き続き脆弱性というものの対応について考えていきたいと思います。

脆弱性対応の考え方

脆弱性も様々なリスクの1つと考えられますので、ハイレベルな視点では リスクマネジメント の考えが同様に適用できます。

結論から先にまとめると、脆弱性対応には大きく4つのゴールがあります。

  • 回避
    • パッチ適用などで根本的/恒久的な対応を行い、脆弱性リスクを回避する
  • 低減
    • ワークアラウンドなどで不完全ながらも対応を行い、脆弱性リスクを低減する
  • 移転
    • アウトソーシングや保険契約などを行い、脆弱性リスクを移転する
  • 保有
    • 対応を行わず、脆弱性リスクを保有する

リスクマネジメント
(引用: リスク戦略について - 目木知明のERM研究室)

この記事をみるであろうSEのような方々のミッションは、情報収集や整理、技術分析を行った上で 意思決定者の決定と組織アクションをこの4つのゴールに導くこと です。
SEとして働いている場合、移転は不慣れな考え方かもしれませんが、出口のパターンとしては認識しておくのがよいかと思います。

脆弱性対応の流れ

脆弱性、というものの対応を一般的に考える場合は以下のような流れになるでしょう。

  1. 脆弱性の認知
  2. 脆弱性情報の収集
  3. 脆弱性対応方針の決定
  4. 脆弱性対応の実行
  5. 振り返り

シーケンシャルな手順に見えますが、実際には「 その時点で持っている情報を元に、進めるところまで進む 」のイメージです。
特に、脆弱性が報告された直後では 情報が出揃っていなかったり、 少し遅れてより重大な情報が追加されたり することもよくあります。
そうしたことを踏まえ、常に自分の情報を最新化しつつ、最新情報をもとに脆弱性対応に向かっていくサイクル的な動きになります。

それでは、各ステップを確認してみましょう。

1. 脆弱性の認知

とにかく脆弱性というものは認知しなければはじまりません。
知らない脆弱性には対応できないので、なんとかしてきっかけを仕入れることが脆弱性対応のはじまりです。

インターネットでは脆弱性情報の発信を行っている団体や個人がたくさん存在します。
それらを日常的に確認しておくことで、出来る限り早く脆弱性の尻尾を掴むことができます。

脆弱性データベースサイト

日夜脆弱性の情報が更新されるデータベースサイトです。ベンダ依存のものまで含めると色々ありますが、一旦3つほど。

  • CVE - Common Vulnerabilities and Exposures
    • おそらく最も有名な脆弱性情報サイト
    • CVE番号による「脆弱性の識別」を主な目的としており、多くの関連サイトで脆弱性を論じる際の共通言語となっている
      • 脆弱性を特定して喋る際には「 CVE-XXXX-YYYY の件ですが...」とするのが最も正確
  • National Vulnerability Database
    • CVEが公開した脆弱性情報を詳細に扱うサイト
    • CVSS(Common Vulnerability Scoring System)によって危険度の評価を行っているのが特徴
  • JVN - Japan Vulnerability Notes
    • 名前からも分かるように、日本の脆弱性情報データベース
    • 日本に影響の大きい脆弱性情報により焦点を当てた情報展開を行っている

Webサイト

IT系ニュースサイトの他に、セキュリティ情報を専門に扱っているサイトもいくつかあります。
話題になれば当然色々なニュースサイトで取り上げられるのですが、「最近はこうした攻撃が増えており」というようなトレンド情報はこういったサイトを眺めていると感覚が掴めるようになります。

SNS

あとはSNSです。
団体のSNSアカウントならまだしも、個人のものだとセキュリティ用に分離している人は少ないため、それだけノイズが多くなります。
一方で「 OpenSSLが来週大きな発表をするらしい... 」みたいな情報もつぶやいてくれるので、最速で情報を得たい場合は個人アカウントなど人のつながりで戦っていく必要があります。
どういう人達をフォローするのがよいかというのは既にまとまっていたのでそちらをご覧ください。

有料サービス

みんなが欲しいところはビジネスになります。
したがって脆弱性情報の認知に関しても、有料サービスがいくつかあります。

大体どこのサービスも配信して欲しい脆弱性情報カテゴリを指定しておくと、新規情報がPushされたりするようなサービスです。膨大な脆弱性情報のフィルタリングをお金で処理するようなイメージですね。
JPCERT/CCが 早期警戒情報 なるものを出していたりしますが、オープンなサービスではなく政府系組織や一部の大規模簿IT事業者などにのみ配信されるようです。

2. 脆弱性情報の収集

気になる脆弱性を見つけたら、次はその脆弱性についてさらに詳細な情報を集めます。

  • 脆弱性の種類
  • 脆弱性の内容
  • 脆弱性の状態
  • 脆弱性の影響有無

脆弱性の種類

日夜新しく発見される脆弱性は様々ですが、大枠で捉えた場合、種類という意味ではいくらかボリューム感を下げることができます。

CWE というのはその略称の通り、「共通脆弱性一覧」というような意味をもちます。
新しく発見されたCVEがどのCWEに属するのかを知ることで、その新しい脆弱性が どういったタイプの脆弱性なのか を大づかみに知ることができます。

例えば、最近話題になっている Spectre脆弱性 では CWE-200 にカテゴライズされているため、「情報のリーク(information leak)」に関する脆弱性だとわかります。

当然ながらこの後もより詳細に脆弱性の内容や原理の調査をしていくことになると思いますが、「結局これってどういう脆弱性なの？」っていう問いは幾度も繰り返すことになるため、このCWEの認識は脆弱性対応全体としては意外と重要になってきます。

脆弱性の内容

脆弱性の種類がイメージできたら、次は詳細に脆弱性の内容を把握します。
ただし、「 新規脆弱性の内容を理解、他人へ共有できる 」というのも立派なスキルであるため、一朝一夕でできるようなタスクではなかったりします。
最初のうちはリタイアしてしまうことも多いかもしれませんが、周囲の分かる人に教えてもらったり、どこかの誰かがブログで解説してくれるのを読み漁ったりするなどして、少しでも理解しようと日々を重ねるのが大事です。

時事ネタとして Spectre脆弱性 を引き続き取り上げますが、今回の場合であれば

なんかで技術的背景含めて解説されています。本当にありがたいです。

脆弱性の状態

「脆弱性の状態とはなんぞや？」という方もいるかと思いますが、以下のことを確認しましょう。

  • 対策方法が確立されているか
  • 攻撃方法が公開されているか
    • 脆弱性を突く簡単な攻撃コードのことを PoC(Proof of Concept)コードといいます
  • 攻撃事例が確認されているか
    • 世間一般の攻撃事例に加え、自システムの該当ログも必ず確認しましょう

それぞれ○×だと思うと、この○×のみで態度を変えるとすれば以下のような感じになると思います。

対策方法 攻撃方法 攻撃事例 温度感
○ ○ ○ 可及的速やかな対策が望まれる
○ ○ × 速やかな対策が望まれる
○ × ○ 速やかな対策が望まれる
○ × × 様子見してもOK
× ○ ○ ちょうヤバイ
× ○ × けっこうヤバイ
× × ○ けっこうヤバイ
× × × 対策もわからないので様子見安定

もちろん、脆弱性の内容に大きく依存するのでこれが全てではありませんが、「 対策が確立されていないのに攻撃コードが出回っていて、攻撃事例も報告されているのが最もヤバイ 」っていう認識は持っておくべきでしょう。

脆弱性の影響有無

脆弱性があったとしても、該当機器がなければ騒ぐ必要も当然ないですし、攻撃しようがない仕組みになっていたとしたらそれも気にする必要はありません。
そういう意味で、対象の脆弱性が自システムに影響があるのかどうかを調べる必要があります。観点としては以下となります。

  • 該当バージョンの有無
  • 攻撃条件の成立可否

該当バージョンの有無

脆弱性は影響範囲をもちます。最たるものがソフトウェアバージョンで、「 バージョンX以降 」であったり「 バージョンYからZの間 」などと表現されたりします。
ソフトウェアによっては、バージョンの前後関係が読みづらかったりすると思うので、バージョンの読み方も日頃からある程度慣れておく必要があります。
読み方については以前まとめたのでそちらもどうぞ。

OpenSSLバージョンの読み方はいつまで経っても慣れない印象があります...。

また、そもそも「 どこに何が入っているかわからない 」というケースも多くあります。
最もかっこ悪い方法は「1台1台に入って調べる」ですが、緊急の場合などはちまちまやってもいられないため、TeratermマクロやCapistrano、Ansibleなどで自動化するとか、最近であればリアルタイムに実機をスキャンする技術にも注目が集まっています。

脆弱性対応はそれ単体で済むこともありますが、こうした仕組みが整っていないことによっても対応が厄介になったりするので、日頃から「スムーズに脆弱性対応できそうか」という観点で訓練(?)してみるのもたまには必要だと思います。

攻撃条件の成立可否

脆弱性には 攻撃の成立条件 があります。

最も分かりやすく、厄介なのが「 外部から攻撃可能 」というものです。
DNSやWebサーバなどの外部に公開せざるを得ないサーバについての脆弱性であれば、攻撃条件は容易に達成することができ、攻撃の危険性は非常に高いと考えられます。
一方で、一般に外部露出することのないDBサーバなどに関連する脆弱性ではそもそも攻撃の条件をクリアすることができなかったりします。
ただし、複数の脆弱性を用いてこれらの条件を突破するケースもあるため、安易に「条件をクリアできない」と決めつけてはいけないことも頭に入れておいてください。

また、この手の議論で最も厄介なのが「 悪意ある内部犯行者 」の存在をどう捉えるか、というところがあります。
例えばDBサーバの攻撃条件に「サーバ内での任意プログラム実行」というものがあったとします。一般的な外部犯行者を想定する場合、

  • インターネットから内部ネットワークに侵入し
  • DBサーバの所在を突き止め
  • DBサーバにログインできる

という条件をクリアする必要がありますが、内部犯行者がこれらの条件を突破することは非常に容易になります。
このあたりの厄介さは ベネッセ個人情報流出事件 などでも広く認識されたところですが、やりすぎると水掛け論とか性善説/性悪説みたいな話になってしまうので、脆弱性対応が滞る原因にもなってしまいます。
このあたりのポリシーは日頃から組織ですりあわせておくべきですし、基本的には セキュリティ教育 や 適切な権限分離 などで内部犯行者を極力想定しなくてもいいような組織にしておきたいものです(願望)。

3. 脆弱性対応方針の決定

これまで集めた情報を元に、脆弱性を評価し、対応方針を決めます。
対応方針としては、先に挙げたように

  • 回避
    • パッチ適用などで根本的/恒久的な対応を行い、脆弱性リスクを回避する
  • 低減
    • ワークアラウンドなどで不完全ながらも対応を行い、脆弱性リスクを低減する
  • 移転
    • アウトソーシングや保険契約などを行い、脆弱性リスクを移転する
  • 保有
    • 対応を行わず、脆弱性リスクを保有する

のいずれかになります。

方針の決定にあたっては、2段階で考えることが多いでしょう。

  • 対応が必要な脆弱性である
    • 回避、低減、移転のいずれかになる
  • 対応が不要な脆弱性である
    • 保有になる

対応必要性の評価

すでに脆弱性の検討をしていることを含め、脆弱性対応にはヒト/モノのコストがかかります。
必要性に関していえば、「お金をかけるほどのことであるか」というのがポイントです。

情報収集でいけば、

  • 脆弱性の状態
  • 攻撃の成立条件

などで、「リスクが顕在化する可能性が低い」と評価できる場合には対応なしで終わることが多いでしょうし、実際多くの脆弱性は「影響なし、または軽微のため静観」という処理を受けると思います。

対応方針の選択基準

では 対応が必要 となった場合、さらには何を基準にして対応方針を選択するのでしょうか。
先に述べたNVDの CVSS で区切るなど、組織によっても考え方は様々かと思いますが、わかりやすい例では「 コストに換算してしまう 」というものがあります。
攻撃がサービス可用性に影響を与えるものだとしたら、停止想定時間に応じた 機会損失 をコスト換算することができるでしょうし、個人情報の流出に関するものだとしたら 賠償金 で換算することもできるでしょう。
あとはそのコストと脆弱性対応によるコスト、および発生確率を天秤にかけて方針を選ぶことになります。

機会損失については自組織で構えるKPIをベースにするとよいでしょうし、賠償金に関しては数々の事例をもとに相場が認知されつつあります。

あ　秘匿性＝『低』レベル→５００円〜１０００円
　　住所・氏名など
　　特殊事情はない

い　秘匿性＝『中』レベル→１万円
　　秘匿性『中』レベル情報の例
　　ア　クレジットカード情報
　　イ　収入・職業に関する情報

う　秘匿性＝『高』レベル→３万円
　　秘匿性『高』レベル情報の例
　　ア　スリーサイズ
　　イ　エステの施術コース

また、セキュリティ事故が起きたことによる「 社会的信頼の失墜 」みたいなこともあるので、当然全てがコスト換算できるとは言えませんが、最終的な決定者が決断するに足るだけの情報を出来る限り準備することが必要です。

4. 脆弱性対応の実行

方針が決まればあとは実行です。
SEとしては「回避」「低減」に関わると思いますので、これらを実行する上でのポイントをまとめます。
ちなみに「移転」の場合はこんな感じの 損害保険 を契約したりすることになるでしょう。

恒久対応と暫定対応

システム運用をしていると各所で聞かれるのがこの2つです。
対応期限の問題や、対応難易度/コストの問題で恒久対応に至れないケースも現実には多くありますが、「暫定対応である」ことはどこかに記録しておく必要があるでしょう。
特に、脆弱性対応では初動対応が重要であるがゆえに、暫定対応で目先の脅威が去ると、つい「 終わった感 」が出てしまいます。
組織的には「暫定対応でよい」と合意したわけではないのに、なし崩し的に暫定対応で終わっているケースなども出てきます。

後々の言った/言わないを避けるためにも、「 いま自分たちがやっているのはどういう対応なのか？ 」ということは必ず気にしましょう。

運用回避

暫定対応の中でも、パラメータ変更のようなテクニカルな暫定対応もあれば、人間的ないわゆる 運用回避 という対応があります。
短期的にみると運用回避は 対応として楽な部類 であることが多いです。基本的には利用者に対して「 ～しないようにしてください 」というようなアナウンスになるでしょう。

一方で、人は完全ではないので何かの拍子に再度問題が顕在化する可能性もありますし、利用者側の制約が徐々に積もっていき 謎の儀式じみてくる なんてこともあると思います。
こちらもやはり、対応の緊急性という観点で運用回避という手段は必ずしも悪いものではないのですが、積極的に採用してよい手段かというとそれもまたどうかという側面があります。
エンジニアとして清く正しく生きることは中々大変ですが、そうありたいと思います。

5. 振り返り

毎回必ず、というわけではないのですが、たまには振り返りをしてみましょう。

  • 脆弱性情報を検知してから方針の決定まで
  • 方針の決定から実行の完了まで

など、タイムアタック的に定点観測してみたり。
脆弱性を理解するという点では 自分の問題、速やかにシステムの調査ができたかという点では システムの問題、速やかに検討や実行ができたかという点では 組織の問題 が振り返りから見えてくるかもしれません。

世の中には CSIRT という専門の組織もあるくらいですから、何か問題がありそうだと思ったら、色々なCSIRT組織や、そこで働く人たちのマインドを調べてみるとよいでしょう。

中の人のマインドとか、日頃の働きぶりを見ていると「CSIRTって、職業というか 生き方 だな...」って思うことがよくあります(笑)

おわりに

脆弱性っていう未知なるものを型にはめて捉えすぎるのもそれはそれで問題ですが、取り付く島もないっていうのも問題なのである程度自分の中でフレームワークを構えるのは悪いことじゃないと思いました。
あとはこのサイクルをいかに自分のものにして、色々な調査や判断を速やかにまわしていけるかですが、 すごいエンジニア(仮称) になるとほんと 反射神経的にスイスイ動いている イメージなので、自分もそうなれるように日頃からこのあたりの態度や動き方はさらに訓練しておきたいなぁと思いました。

Report article

Help us understand the problem. What is going on with this item?


Feedback

We don't reply to any feedback.
If you need help with Qiita, please send a support request from here.