Facebook:脆弱性診断研究会 の 「第47回 脆弱性診断ええんやで(^^) for ルーキーズ」で発表した内容です。

1. WEBサービスのセキュリティ対策
～ライフサイクルごとの対応～
第47回 脆弱性診断ええんやで(^^)
for ルーキーズ
2017/03/25
株式会社アールワークス INOUE

2. 概要
• 本日は「脆弱性診断の手法」の勉強会なので、
サーバの脆弱性対応全体像についてお話をさせ
て頂こうと思います。
▫ サービスのライフサイクルを考える
▫ ライフサイクルの各ステージで、対策を行う
▫ 対策として使えるアプリケーション

3. お前誰よ
• 所属
▫ サーバ運用会社(MSP:Managed Service Providor)に所属し
ています。
 複数顧客の運用をしていたので、多少は汎用的な知見があると
思います。
 2016/10頃から、セキュリティ関係専門で仕事をすることにな
りました。
• 個人
▫ OSSの脆弱性スキャナ Vuls で少し顔を出しています。
 昨日03/24に2回目のミートアップがあり、少し喋りました。
▫ Facebook「脆弱性診断研究会」も見てます。
▫ 車/バイクのレース、釣り、ダイビング、居合、してます/
ました。
▫ バイノーラル録音で、環境音を撮るのが好き
40歳以上で無名でダメなエンジニア
（元エンジニア）が勉強会で登壇するときの
注意：
http://blogs.itmedia.co.jp/fukuyuki/2017/03/
40.html
- 最初の自己紹介30秒以下にしろよ：

4. サービスライフサイクル
• 脆弱性対策/セキュリティ対応
▫ 今までは
 「出来上がったサービス」に対して対応していた
 アップデート等が考慮されていないので、対策が困
難な場合がある
▫ これからは、作る段階からセキュリティ対策をす
る
 設計段階から、フェイルセーフやアップデートや安
全なコード設計を意識する
 アプリケーション以外は、
アップデートができれば大体のものは解決できる！

5. アップデートで解決できる？
• 最近出た脆弱性は、ほぼアップデートで解決可能。
▫ OS
 Windows (Kernerl、ブラウザ、SMB等の脆弱性)
 Linux (Kernel, bash, BIND, NTPなど)
 Cisco IOS
▫ ミドルウェア
 WordPress
 Apache Struts2
 Java
▫ クライアントアプリケーション
 Adobe Reader, Flash Player

6. アップデートで解決できないものもある
• 自分で作成したアプリケーション
▫ ミドルウェア上で動かす、サービス
 ミドルウェア=Tomcat, Struts2, Wordpress, …
 ミドルウェアの脆弱性ではなく、作成したサービスやWEBア
プリケーション自体の設計ミスなど
 自分で作るより、多数のユーザが利用する製品を使う方が、セ
キュアになる = 多くの目に触れるのでProofされている
 だから、作ったら脆弱性検査をする
• そもそもEOLな製品
▫ サポートから外れたOS
 WindowsServer2000、Windows xp、RHEL5…
▫ サポートバージョンから外れたパッケージ
 OpenSSL 0.9.8
 PHP 5.6以前(ActiveSupport until 2017/01/19)…

7. とはいえ！
アップデート大切。
• アップデートができるように設計
▫ 運用上、アップデートができる体制にする
▫ サービス終了までにEOLとならないような、利用
製品選択
• アップデートで解決できないものは、より慎重
に作る
▫ サービス作成時に、脆弱性検査をする
▫ リリース前に、脆弱性検査をする
▫ サービスに、EOLが近いものを使わない

8. ライフサイクルとして対応する
サービス設計時から脆弱性対応ができる設計が必要
▫ 運用フェーズで、アップデートができるように計画
▫ EOLが近い製品を使わない
▫ ステージング環境の用意
• 作成
▫ 構築しながらの、脆弱性検査
▫ なるべく新しいバージョンの、言語/ライブラリを利利用
• 運用
▫ 脆弱性情報の収集と、適用
▫ ステージング環境での、本番アップデート前試験
• 寿命
▫ OSごと捨て去ることで、古いOSサポートの呪縛を防ぐ

9. ライフサイクルとして対応する
サービス設計時から脆弱性対応ができる設計が必要
▫ 運用フェーズで、アップデートができるように計画
▫ EOLが近い製品を使わない
▫ ステージング環境の用意
• 作成
▫ 構築しながらの、脆弱性検査
▫ なるべく新しいバージョンの、言語/ライブラリを利利用
• 運用
▫ 脆弱性情報の収集と、適用
▫ ステージング環境での、本番アップデート前試験
• 寿命
▫ OSごと捨て去ることで、古いOSサポートの呪縛を防ぐ
本日利用する OWASP ZAP での検査や、
OWASP Dependency Check による検査
メール/RSSなどによる収集
Vuls などでの状況把握

10. 開発時に使えるもの
• OWASP ZAP
▫ OWASP Top10などを「よくある脆弱性」を基に、自分で
検査する
▫ 脆弱性の知識量がないと使えないかも？
 「脆弱性診断ええんやで(^^) for ルーキーズ」などで知識を増
やす
 最終段階では専門業者に委託するのもあり
▫ 未知の脆弱性を検査
• OWASP Dependency Check
▫ WEBアプリケーションが利用している既知の脆弱性が存在
するコンポーネントを、検査/発見するものです
▫ 古いライブラリやミドルウェアなどを検知可能
▫ 既知の脆弱性を検査

11. 運用時に使えるもの
• Vuls
▫ https://github.com/future-architect/vuls/
▫ 残存する脆弱性を可視化する
 yumやaptなどでパッケージの更新があるかを確認
し、changelogから抽出したCVE番号から影響度を
可視化する
 yumやaptなどのパッケージマネージャでは、「更
新がある」ことしかわからず、「更新しないことで、
どのような脆弱性が残っているのか」がわからない

12. vuls
• Demo
▫ http://usiusi360.github.io/vulsrepo/

13. 脆弱性情報検知後の対応
• Vulsを使う
▫ サーバに残存する脆弱性が、CVE番号でわかる
• 検知後は…
▫ 対応をする必要がある
 脅威度の判定:トリアージ
 CVSS Scoreだけでなく、Vectorを見る
 アップデート
 パッケージ更新できる設計
 ワークアラウンド
 パッケージ更新できない場合
適用可否を判断するのは、
難しい
→アップデートできる構成
を!

14. まとめ
• 脆弱性対応は、ライフサイクルで考えましょう
▫ WEBアプリケーション作成時には、OWASP Zap
やDependency Checkで検査
▫ 運用段階になったら、Vulsなどで残存脆弱性を可
視化し、アップデート
• 何よりも
▫ パッケージ類は、アップデートで脆弱性はある程
度防げる
▫ 構築時からアップデートできるように設計

15. Appendix: Vuls
• Vuls
▫ https://github.com/future-architect/vuls/
▫ https://github.com/usiusi360/vulsrepo
• Vuls meetup Vol.1, Vol.2
▫ https://vuls-jp.connpass.com/
• IDCF テックブログ
▫ http://blog.idcf.jp/entry/idcf-vuls
▫ http://blog.idcf.jp/entry/idcf-vuls2
• Vuls関連リンク集
▫ http://qiita.com/usiusi360/items/aeb3cd3630badfac
db4e