Vuls祭り5の10分LTで話した、脆弱性トリアージの考え方。

1. 脆弱性トリアージの
考え方
2019-06-17 INOUE KEI

2. WHO AM I
井上圭
参加コミュニティ
• OWASP Kansai
• OWASP Nagoya
• セキュリティ共有勉強会
• 情報セキュリティ勉強会
• ssmjp
• ハニーポッター技術交流会
• Attack & Defense
• OSSセキュリティ技術の会
運営コミュニティ
• IoTSecJP東京
• 脆弱性対応研究会
職務経験
• 警備会社基幹システム郡運用
• システム運用会社での運用
• セキュリティコンサルティング
趣味
• 車やバイク、のレース参加
• ハニーポット観察
• インシデント調査
• ドローンセキュリティ
• アンチドローン、カウンタード
ローン
• いろいろなログを見ること
• 銃器、軍事関連
• レザークラフト
直近
• OWASP Kansai Lcoal Chapterで
「ログ」と「ドローン」の話をしました。
• OWASP Connect in Tokyo#2で
「Dependency check」の話をしまし
た。
#この発言は個人の見解であり所属す
る組織の公式見解ではありません

3. 今日のLT内容
いつもは「1 時間だけしゃべるね」といいながら1.5-2.0時間話してしま
うので、特定の項目に絞って話します。
脆弱性のトリアージについて検討してほしい事
• 「リスク」に見合った対応をしよう
• リスク、とは？
• リスクに見合った対応、とは？
• RHEL系の情報はRHを見よう
• バックポートというものがありまして…
• その他
• もっとkwsk

4. 脆弱性のトリアージについて

5. トリアージ
Q: 発見された脆弱性、全てに対応する必要はありますか？
A: 理想としては対応したほうが良いですが、現実には無理です。
発生しえる影響度で優先度をつける必要があります。
脆弱性対応それ自体は、工数や時間や費用が掛かります。
全ての脆弱性を一律に対応するのは、理想ではありますが、費用対
効果としてはあまりよくないものがあります。
この「どこまで許容するか」「どこからは対応が必要か」を考える際に、
トリアージという手法を行います。
図1: 社団法人横須賀市医師会の災害時医療救護活用マニュアル
http://www.yokosukashi-med.or.jp/topics/saigaimanual/3.htm
現存する限られた医療資源（略）を最大限に活用
して、救助可能な負傷者を確実に救い、可能な限
り多数の傷病者の治療を行うためには
傷病者の傷病の緊急性や重症度に応じて、治療
の優先順位を決定し、この優先順位に従って患者
搬送、病院選定、治療の実施を行うことが大切で
ある。

6. リスクに見合った対応を。
医療では「傷病の緊急性や重症度」ですが、情報システム系では「リ
スク」を基にトリアージを行います。
「リスク」は、脆弱性それ自体だけではわかりません。システムの置か
れている環境を考慮する必要があります。
• よく利用されているCVSSは、「脆弱性、それ自体の影響度」を示し
ます。
• その為、リスクと同じとはならないことも多いです。
• 例えば、「CVSS v3 BaseScoreが8.5」であっても、「リスクは
低い」という場合もあります。
今回は、「リスク」について話します。

7. リスク、とは
IPAの「情報セキュリティマネジメントとPDCAサイクル」を確認してくだ
さい。
https://www.ipa.go.jp/security/manager/protect/pdca/policy.html
という訳にはいかないので
概要を説明します。

8. リスクに対する考え方
脆弱性に対し、以下のようにリスク評価をし、リスクに対する対応を検討します。
リスクの評価
• Vulsなどを利用し、残存する脆弱性を検出する
• CVSS等を利用して、脆弱性それ自体の影響度を確認する
• 上記影響度を、システムの置かれる環境を加味して、リスクを判定する
トリアージ
• リスク判定に基づき、対応優先順位をつけていく
リスクに対する対応
• リスクについて（保有｜低減｜回避｜転移）を決める
時間がないので、この部分だけを少し掘り下げます。

9. 例えば
脆弱性対応におけるリスクに対する対応は、以下のように置き換えてもよいかと思
います。
• リスクの保有
• リスクの持つ影響力が小さい為、そのリスクを許容範囲として受容する事
• 影響は少ないから対応しない、など
• リスクの低減
• 本来は、対策をすることで脅威発生の可能性を下げること
• リスク保有できず 回避/移転できない場合の対応として、アップデートを行う
事、などを想定
• リスクの回避
• 別の方法に変更する事で、リスクが発生する可能性を取り去る事
• Bindの脆弱性が多数出るので、比較的脆弱性が発見されていない
PowerDNSへ切り替える
• 但し、回避した先でも、別の脆弱性等でリスクは発生する。
• リスクの移転
• 別の機器で対応するなどの、リスク発生を別の場所に移転する事
• ApacheStruts2の脆弱性にWAFで対応する、など
• 但し、完全に移転できるとは限らない場合もあることに留意
おそらく時間がないので
概要のみのお話し

10. 次、RHELの話
CVEなどの情報で脆弱性が発見されたことを認知する場合が多いと
思います。
CVSSのBaseScoreを見ることが多いと思いますが、Red Hat自身が
出しているScoreと値が異なる場合があります。
• バックポートでのメンテナンスになる為、CVSS等で対象とされてい
るバージョンとは異なります。
• 詳しくは 森若さんの資料参照
• https://speakerdeck.com/moriwaka/red-hat-enterprise-
linuxfalsexiu-zheng-hadofalseyounichu-he-sareruka
RHELに限らず、ディストリビュータが出している情報を優先して確しま
しょう。

11. もっとKWSK
このような話をもっと詳しく聞きたい場合は…
• ConnpassのFutureVulsグループで開催している「既知の脆弱性
はこう捌け！〇〇デモとVulsによる効率的な脆弱性管理」などの
セミナに参加するとよいかもしれません
• https://futurevuls.connpass.com
• 私が、1時間枠で話しています。 （毎回時間オーバーしてしま
います…）
• 商用版FutureVulsの押し売り、はしません！
• 私が個人的に開催している「脆弱性対応勉強会」に参加するとよい
のでは！
• https://zeijyakuseitaioukenkyukai.connpass.com
• 最近は「ログ分析の初歩」「Vuls導入ハンズオン」等をやりまし
た。
[PR]
※この記事は個人の感想であり、効果・効能を示すものではありません

12. 以上です。