20170325 institute of-vulnerability_assessment
- 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などのパッケージマネージャでは、「更 新がある」ことしかわからず、「更新しないことで、 どのような脆弱性が残っているのか」がわからない
- 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