はじめに

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

・脆弱性ってなんだろう
・脆弱性対応ってなにしたらいいの？
・情報を集めよう
・該当機器を洗いだそう
・対応方法を決めよう
…
みたいなまとめほしいけど意外とないから作りたい…作るしかなくない…？
— ナツヨさん@インフラ女子の日常 (@infragirl755) 2018年1月15日

たしかにそうだなぁ。生きてるシステムを運用する現場SEの気持ちになって力試しに書いてみよう。

おことわり

最初に記事スコープのおことわりです。
「対策」「対処」「対応」、似たような言葉ですがこれらを並べて考えたことはあるでしょうか？
記事名には「 脆弱性対応 」という言葉を使っていますが、「対応」ということでこの記事のスコープを少し狭く取っています。

対策・対処・対応の違い

対策: 何かが起きる前に講じる処置や手段のこと。
対処: 何かが起こってから状況に応じて適切な処置をとること。
対応: 何かが起こってから相手の動きや状況に応じて行動すること。

ということで、この記事で述べるのは基本的に「 脆弱性が起こってから 」(ちょっと日本語おかしいですが)のことです。
対策というと、「そもそも脆弱性対応がやりやすいように備える」とか「そもそも脆弱性対応が発生しにくいようにデザインする」とかの話になってきますが、一旦その未来志向の脆弱性対策は本記事のスコープ外とします。
また、対策をスコープ外とすることで、一気に外れてしまう観点が「 自ら作りこんでしまうアプリの脆弱性 」のことです。定期的に セキュリティ診断 などを業者に依頼しているなら、認知にはじまり本記事の流れで対応することが可能ですが、多くの場合はそうもいきません。
この話はこの話で開発からテストにかかる手法やエンジニア教育、加えて日頃の運用や監査体制まで色々なところで対策を講じるべき内容となってくるので、それも含めてこの記事では触れないようにしています。悪しからず。

上の説明では、対処と対応の違いが微妙ですが、リンク先の記事にもある通り「対処はなにかしらこちらが状況を受けて 必ずアクションを起こす が、対応は アクションを起こさない場合もある 。つまりただ単に受けるだけの時もある。」というのがポイントのようです。
後で述べますが、「脆弱性に対して何もしない(リスクの保有)」ことも1つの脆弱性対応の姿だと思うと非常にしっくりきますね。

脆弱性とは

さて、そもそも脆弱性とはなんでしょうか。
いつものようにWikipediaで見てみます。

脆弱性 - Wikipedia

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

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

セキュリティホール - Wikipedia

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

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

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

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

脆弱性対応の考え方

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

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

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

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

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

脆弱性対応の流れ

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

脆弱性の認知
脆弱性情報の収集
脆弱性対応方針の決定
脆弱性対応の実行
振り返り

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

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

1. 脆弱性の認知

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

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

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

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

CVE - Common Vulnerabilities and Exposures
- おそらく最も有名な脆弱性情報サイト
- CVE番号による「脆弱性の識別」を主な目的としており、多くの関連サイトで脆弱性を論じる際の共通言語となっている
  - 脆弱性を特定して喋る際には「 CVE-XXXX-YYYY の件ですが...」とするのが最も正確
National Vulnerability Database
- CVEが公開した脆弱性情報を詳細に扱うサイト
- CVSS(Common Vulnerability Scoring System)によって危険度の評価を行っているのが特徴
JVN - Japan Vulnerability Notes
- 名前からも分かるように、日本の脆弱性情報データベース
- 日本に影響の大きい脆弱性情報により焦点を当てた情報展開を行っている
  - 最近報告された圧縮解凍ソフト Lhaplus に関する脆弱性報告などがその活動をよく表している
JVN iPedia
- 上のJVNと同じ団体が運営しているものの、微妙に支援団体が異なり、JVNと実は性格が異なる
  - JVNは早期警戒パートナーシップの維持運営など、日本における脆弱性情報の 速報性 を特に重視している
  - JVN iPediaはJVNが取り扱う脆弱性に加え、広く脆弱性情報の蓄積を意図している
- MyJVN API を提供しており、Slackなんかと連携させると捗る
  - さまざまなソフトウェアが脆弱性対策情報を取得できる「MyJVN API」

Webサイト

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

JPCERT/CC
- JPCERTコーディネーションセンターによる情報セキュリティポータル
- 国内状況を勘案した注意喚起などを行っている
情報セキュリティ - IPA
- IPAによる情報セキュリティポータル
- 発信情報は上のJPCERT/CCと似ているが、タイムリーな情報というよりは年次報告書などの大掴みなトレンド情報に着目するとよい
Security NEXT
- セキュリティニュースサイト
- 日頃の時事ニュースに加え、 個人情報漏洩事件・事故一覧 といった事故事例が多く掲載されている
各種ベンダー系セキュリティブログ
- トレンドマイクロセキュリティブログ
- セキュリティ：脆弱性情報ブログ - サイオス

SNS

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

【保存版】セキュリティ担当になったらフォローすべきtwitterアカウント【随時更新】

有料サービス

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

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

2. 脆弱性情報の収集

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

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

脆弱性の種類

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

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

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

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

脆弱性の内容

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

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

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

脆弱性の名前

基本的に脆弱性はCVEが(機械的に)命名する、CVE番号で呼ばれることがほとんどです。
一方で、先に挙げた Spectre脆弱性 や、そのセットで語られる Meltdown脆弱性 など、キャッチーな名前がつく脆弱性が存在します。

最近のものでいけば、

名前	CVE	対象
Heartbleed	CVE-2014-0160	OpenSSL
Shellshock	CVE-2014-6271	bash
FREAK	CVE-2015-0204	SSL/TLS
Badlock	CVE-2016-2118	Samba
KRACKs	CVE-2017-13077	WPA2

などがあったりしますが、名前を見れば「あー、そんなのもあったなー」と思われる方も多いのではないでしょうか。
他にも色々な 名前付き脆弱性 があります。

名前付き脆弱性（Branded Vulnerabilities）のまとめ

基本的に、名前がつくものは脆弱性が深刻かつ広範に影響するものが多いため、見慣れぬ名前の脆弱性を見かけたら、とりあえず内容は確認したほうがよいでしょう。
ただ、よくよく調べてみると、こうした脆弱性に名前を与える習慣はつい最近、2014年の Heartbleed脆弱性 あたりから始まったことらしく、最近では若干過熱気味なところもあるようです。

脆弱性の状態

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

対策方法 が確立されているか
- 対策の確立されていない脆弱性のことを ゼロデイ脆弱性 といいます
攻撃方法 が公開されているか
- 脆弱性を突く簡単な攻撃コードのことを 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つです。
対応期限の問題や、対応難易度/コストの問題で恒久対応に至れないケースも現実には多くありますが、「暫定対応である」ことはどこかに記録しておく必要があるでしょう。
特に、脆弱性対応では初動対応が重要であるがゆえに、暫定対応で目先の脅威が去ると、つい「 終わった感 」が出てしまいます。
組織的には「暫定対応でよい」と合意したわけではないのに、なし崩し的に暫定対応で終わっているケースなども出てきます。

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

運用回避

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

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

解消確認

脆弱性対応行った後にPoCコードなどを再度適用し、攻撃が効かなくなったことを確認するのは当然として、 類似の脆弱性が報告されていないか についても必ず確認しましょう。
構図がシンプルな脆弱性であればあるほど、IT業界様々な部分に同様の構図が見られ、 芋づる式 に類似の脆弱性が報告されることがあります。
昨今のオープンなIT業界であるが故の波及現象ですが、最後の最後で残念なことにならないためにも、終わりをしっかり確認しておきましょう。

ただ、対応の最中にいる人にとって、次々の新しい脆弱性とパッチが出てくるこのあたりは中々気力を削がれる局面ではあります...。
がんばれSE超がんばれ。

5. 振り返り

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

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

など、タイムアタック的に定点観測してみたり。基本的にニュースになりやすい一般の脆弱性対応はスピード勝負なところが非常に大きいです。⁴
脆弱性を理解するという点では 自分の問題、速やかにシステムの調査ができたかという点では システムの問題、速やかに検討や実行ができたかという点では 組織の問題 が振り返りから見えてくるかもしれません。

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

日本CSIRT協議会
CSIRT奮闘記 - ITPro

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

おわりに

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

しれっと書いていますがログがしっかり取れているかに加え、ログから攻撃の有無を確認することもかなりのスキルが必要になります ↩
とはいえ、新しい情報が出たりすると評価がガラリと変わったりするので「あくまでその時点の評価」であることを忘れないようにしましょう ↩
Webサイト系の脆弱性だと、脆弱なドメインが晒されたりするので事故がなくても実質対応が必須になることが多いです ↩
それ故に、脆弱性の認知から対応完了までの時間を明確にルールとするところも多いでしょう ↩

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