永続性のあるセキュリティの実現に向けて私たち（エンジニア）ができること

2019/6/1 Legacy Code Meetup Kagoshima 2019での、西村の講演資料になります

Transcript

1. 永続性のあるセキュリティの実現に向けて 私たち（エンジニア）ができること 株式会社リクルートテクノロジーズ プロダクティビティエンジニアリング部 プラットフォームセキュリティグループ マネジャー 西村 宗晃
2. 自己紹介 西村 宗晃（にしむねあ） 国内携帯電話メーカーにおけるセキュリティ コンサルタントなどを経て、2016年より現職。 リクルートグループにおけるセキュリティ事 故の未然防止に取り組む。趣味はブラウザの 脆弱性を探すこと。著書にブラウザハック （監訳）。主な講演歴に、CODE BLUE 2017、 PacSec 2016、Internet Week 2016 2
3. 本日のテーマ システムの開発や運用保守が続く限り、そのセキュリティもまた、持続可能であることが 求められます。高度な専門性を要求されるサイバーセキュリティの分野において、個人に 依存せず永続的な仕組みを作るには、どのようにすれば良いのでしょうか？、話者がこれ までに行ってきた脆弱性対策の取り組みを中心に、いくつかの事例を紹介します。 本発表で紹介する内製ツールの一部はGitHubで公開しています。 セキュリティ向上に是非お役立てください。 3
4. 私達の役割 セキュリティの技術専門組織として、プロダクトの脆弱性対策を横断的に支援 • 300を超えるプロダクト（年間売上高100億円を超えるものも多数） プロダクトA 企画 開発 運用保守 プロダクトB 企画 開発 運用保守 プロダクトC 企画 開発 運用保守 事業会社 A 事業会社 B リクルートテクノロジーズ（横断組織） サイバーセキュリティ部 （セキュリティ統制施策の推進） ITエンジニアリング本部 プラットフォームセキュリティG プロダクトD 企画 開発 運用保守 … … 支援 支援 支援 支援 支援 連携 4
5. プロダクトの脆弱性対策は組み合わせが大切 ネットワーク機器 サーバOS サーバミドルウェア アプリフレームワーク Webアプリ 自分たちで作ったもの 外から調達したもの • 開発者向けセキュリティ教育 • セキュリティレビュー • Webアプリ脆弱性検査 • パッチマネジメント • プラットフォーム脆弱性検査 分類 効果的な脆弱性対策 5
6. 対策の方法によって外部委託の難しさは異なる プラットフォーム脆弱性検査 パッチマネジメント Webアプリ脆弱性検査 セキュリティレビュー 開発者向けセキュリティ教育 汎用的な教育は委託可能だが、自社プロダクトの利 用技術にフォーカスした教育は困難 Webアプリ脆弱性検査と同様 △ ◦ 要因 外部委託の難しさ ✕ ◦ △ 設計／実装のリスクをレビューできる人材は社会全 体として不足しており、持続的な供給に課題 多くのWebアプリの場合、ベンダーに経験とスキル の蓄積があり、持続的な供給や品質面で安定性あり 自社プロダクトの状況に応じた判断や、対策方法の 提示が求められるため委託が困難 6
7. 外部委託による充足や補完を考慮した内製化が理想 パッチマネジメント セキュリティレビュー 開発者向けセキュリティ教育 自社プロダクトの利用技術を題材とした、応用的な教育を中心に内製化 内製化の方針（例） 設計／開発のアウトプットに対する具体的なレビューを中心に内製化 脆弱性の技術的な分析や、自社プロダクトの特性に応じた影響判断など、 全てのオペレーションを内製化 プラットフォーム脆弱性検査 Webアプリ脆弱性検査 監査目的ではなく、セルフチェックで行う簡易検査を中心に内製化 新規技術を採用するプロダクトのように、一般的な脆弱性検査の項目では カバーできない部分を中心に内製化 7
8. 本日紹介するプラクティス 2. パッチマネジメント 1. 開発者向けセキュリティ教育 3. プラットフォーム脆弱性検査 8
9. 1. 開発者向けセキュリティ教育 9
10. 背景 セキュリティ人材に求められるスキルの多様化 • SecBok2019によれば、脆弱性対策に要するスキルだけでも156種類※1 • 扱う技術領域も、OS、NW、プロトコル、アプリ、暗号など多岐に渡る • 技術の進化は早く、新しい技術の組み合わせによる新たなリスクも発生 • → 得意な技術分野や、視点の異なる人材の協力が不可欠 社会全体としてセキュリティ人材の不足 • 開発のことがわかるセキュリティ人材は特に希少 • → 社内エンジニアにセキュリティスキルの習得を促す方が早い ※1 SecBok2019 ソリューションアナリストの前提必須スキル数より https://www.jnsa.org/result/2018/skillmap/ 10
11. 理論・実践の両方が重要 • 理論：情報セキュリティ全体における脆弱性対策の取り組みを俯瞰的／構造的に理解 • 実践：脆弱性対策に必要なスキルと勘を育む 理論を身につけるには ① セキュリティ勉強会 実践で学ぶには ② 留学制度 ③ ハンズオン型研修 セキュリティのわかるエンジニアを育成するには 11
12. ① セキュリティ勉強会 誰でも任意で参加できる勉強会を週次で開催 • 情報セキュリティの一般的な取り組みと、自社における取り組みを紹介 • 有識者から学ぶ（例：認証と認可の講義はリクルートIDのアーキテクトに依頼） 社内での取り組み 12
13. ② 留学制度 セキュリティ部署に3〜6ヶ月間留学 • 設計／開発のリスク分析や脆弱性調査などをメンバーとともに実施 • 後半は自身の強みを活かした卒業研究を実施 過去の卒業研究テーマ • インフラエンジニア  AWS WAFの有効性の検証 • データサイエンティスト  脆弱性検査の統計に基づくリスクヒートマップの作成 在籍する職場で役立つセキュリティスキルの獲得 • プロダクトのソースコードから脆弱性を見つけ、正しく修正するスキル • 設計資料のセキュリティリスクを評価し、正しく言語化するスキル • 社内セキュリティルールの具体的な理解 社内での取り組み 13
14. ② 留学制度 - 卒業生の活躍 “攻撃系と正常系、2つのデータセットを用意し、8種類のマネー ジドルールとカスタムルールを用いて、「どの程度攻撃を検知で きるか」と同時に「過検知がどの程度あるか」を検証。さらに、 運用に備えて仕様や構築手順もチェックした。“ https://ascii.jp/elem/000/001/730/1730216/ “データサイエンティストとしての仕事の幅が広がったのは間違 いないです。セキュリティのルールの背景がわかったことでより 繊細なデータの取り扱い方に詳しくなれましたし。” https://recruit-tech.co.jp/blog/2019/02/12/ryugaku_redteam/ 社内での取り組み 14
15. ③ ハンズオン型研修 新人研修のセキュリティ教育で開催 • 2日間かけて、脆弱性の発見、攻撃の再現、リスク評価、コード修正までを学ぶ • 攻撃される恐怖を通じて、セキュリティを「自分ごと化」してもらう 脆弱性を仕込んだ架空のアプリ「Bad SNS」を活用 • 埋め込まれている脆弱性は毎年異なる • 2018年度版は技術評論社「WEB+DB PRESS Vol.103」に掲載 • 高成績を収めた参加者に翌年の講師を打診 社内での取り組み 15
16. ③ ハンズオン型研修（2019年度版） 講師の志向から、受講生には「半端なく完璧な実装力」が求められた 社内での取り組み ※1 https://twitter.com/yoshiki_shibata/status/1113764554704449538 問題を半端なく完璧に実装した 講師の平松さん 16
17. Bad SNS 2019 を体験してみよう！ 17
18. Bad SNS 2019を起動 1. Dockerをインストール 2. 以下のコマンドでSNSを起動 3. ブラウザで以下のURLをアクセス SNS本体：http://localhost:10080/ メール受信機能（検査対象外）：http://localhost:10080/mailhog/ $ docker pull ommadawn46/badsns2019 $ docker run --privileged -d --rm -p 10080:80 --name badsns2019 ommadawn46/badsns2019 18
19. Bad SNS 2019の脆弱性を探す 4. 初回はSNSの「新規利用はこちら」からアカウントを作成 5. SNSのソースコードは、平松さんのGitHubから入手 https://github.com/ommadawn46/badsns2019 19
20. Bad SNS 2019にはこんな脆弱性が含まれている - 1 • 友だち検索機能の応答にパスワードハッシュが含まれている • ハッシュ値なので不正ログインはできないように見えるが・・・ 20
21. Bad SNS 2019にはこんな脆弱性が含まれている - 2 • 取得したハッシュ値をGoogle検索すると元のパスワードが特定できる • APIの応答からハッシュ値を削除し、MD5を強固なハッシュ方式に変更する ユーザ影響を与えずにMD5を変更する方法は？ 21
23. エクスプロイト駆動開発（EDD） 最初に攻撃コードを書き、刺さらなくなるまでコード修正を繰り返す • 脆弱性を修正したコードをGitにpushすると、 CIでビルド → コンテナ生成 → デプロイ → 攻撃（エクスプロイト）が行われる • 開発環境は2017年受講生の與那城さんが作成 社内での取り組み 23
24. 2. パッチマネジメント 24
25. 脆弱性は速やかな対応が求められる 脆弱性の開示から1日以内に攻撃が観測されたケースも • 2014年 Shellshock（CVE-2014-6271） • 2017年 Apache Struts 2（S2-045/CVE-2017-5638） 攻撃者 エンジニア 脆弱性を分析 脆弱性を分析 攻撃コードを作成 影響調査 脆弱性対応 攻撃活動を開始 世の中に脆弱性情報が開示 攻撃が来る前の対応が求められる 25
26. 速やかな対応には備えが不可欠 各プロダクトのシステム構成情報の把握 • 利用しているソフトウェアの把握 • インフラ構成や外部ネットワークとの接点の把握 • リクエストフィルタリングの適用可能箇所の把握 脆弱性情報の収集と影響調査 • 脆弱性情報の定期的な収集（開発元のMLやRSSの購読など） • 攻撃コードの確認（パッチのテストコードや攻撃ツールのコードリポジトリなど） • 自社プロダクトにおける影響の分析 事前の対応方針策定 • 脆弱性の影響度に基づく対応フローの確立と意思決定者による合意 26
27. しかし備えは難しい・・・ 各プロダクトのシステム構成情報を把握できない • 開発しているプロダクトの全量が把握できない • 利用しているソフトウェアの数が多く、収集が困難 脆弱性の影響を調査できない • 影響を判断できるだけの情報が手に入らない • 脆弱性の内容を見てもどのようなリスクがあるのかよくわからない 事前の対応方針が決まらない • パッチを当てられない場合のフローなど、検討しなければいけないケースが案外多い 27
28. そして作られる歪んだルール 全てのサーバが対象 • 外部から攻撃を受ける可能性に基づいて、対応の優先度を付ける 必ずパッチを適用 • コンフィグの変更や不正リクエストの遮断など、他にも様々な手段がある CVSS基本スコアが10.0なら即座に対応 • CVSS基本スコアで判断するのは危険 • 脆弱性の中身を分析し、対応要否を判断する習慣を付ける 28
29. CVSSに基づく影響判断の課題 – 公称値としての信頼性 評価基準に一貫性・透明性がなく、公称値としての信頼性に欠ける • 評価機関によってスコアが異なる※1 CVSS評価パラメータ 選択肢 攻撃元区分 ネットワーク・隣接・ローカル 攻撃条件の複雑さ 高・中・低 攻撃前の認証要否 複数・単一・不要 機密性への影響 全面的・部分的・なし 完全性への影響 全面的・部分的・なし 可用性への影響 全面的・部分的・なし 任意のコードが実行できる脆弱性なら 全面的な影響とする解釈や、ユーザプ ロセス上での任意コード実行であれば 影響は部分的とみなす解釈が存在する 複雑さの基準が不明確。例えば、不正 なファイルを開かせることで発現する 脆弱性を、複雑とみなす場合もあれば、 攻撃は容易とみなす場合もある ※1 例えば Ghostscriptにおける任意コード実行可能な脆弱性（CVE-2018-16863）は、NIST評価9.3に対し、JPCERT/CC評価7.8と乖離 29
30. CVSSに基づく影響判断の課題 – 複雑なスコアリング方式 リスクシナリオが複数存在する脆弱性はスコアが高くなる • バッファオーバーフロー脆弱性で想定されるリスクシナリオ ① 境界外のメモリ番地へのアクセスによるプロセス停止（攻撃は比較的容易） ② 巧妙なメモリ番地にアクセスさせることによる任意コード実行（攻撃は一般的に困難） CVSS評価パラメータ ① プロセス停止のリスク ② 任意コード実行のリスク 最終的なCVSSスコア 攻撃元区分 ネットワーク ネットワーク ネットワーク 攻撃条件の複雑さ 低 高 低 攻撃前の認証要否 不要 不要 不要 機密性への影響 なし 全面的 全面的 完全性への影響 なし 全面的 全面的 可用性への影響 部分的 全面的 全面的 CVSS スコア 5.0 7.6 10.0 30
31. 脆弱性管理基盤 RAFFLESIA の構築 社内インフラやアプリ開発環境から構成情報を収集し、脆弱性を自動検知 • 脆弱性の検知には、VulsのServer Mode※1やTrivy※2を活用 社内での取り組み コンテナ利用環境 RAFFLESIA アプリ開発環境 社内各種インフラ 構成管理ツール コンテナレジストリ 各種脆弱性情報 開発中 開発中 ※1 https://speakerdeck.com/knqyf263/vuls-server ※2 https://github.com/knqyf263/trivy 31 構成情報
33. 脆弱性判断の仕組み作り 脆弱性の内容に基づく対応判断 • 一次情報（パッチの修正差分やBTSのチケットなど）を調査 • 調査方法は留学制度などでスキルトランスファー 脆弱性の緊急判断フローを確立 社内での取り組み 33 当該のソフトウェアを 利用している可能性が高い 脆弱性を悪用された場合の ビジネス影響が大きい 攻撃が容易である 緊急対応  RAFFLESIAに利用登録あり  DL数やスター数が多い  他  機密情報漏洩の可能性が高い  横断的な事業継続影響あり  他  制限なくネットから攻撃可能  他ユーザの関与なしで成立  攻撃コードが既に存在する  他
34. 3. プラットフォーム脆弱性検査 34
35. 検査の目的と課題 目的 • プラットフォーム層（自社開発したWebアプリ以外）の脆弱性管理 • 外部からアクセス可能なポートの把握 • 外部から識別／推定可能なソフトウェアの把握（CMSのプラグインなど） • → 管理のためには定期的な検査が効果的 課題 • 検査ツールによる大量の過検知と、その精査に要する人員 • ツールのライセンス管理やベンダー契約のため、セキュリティ部署が検査を仲介 • → 運用人員のコストがボトルネック 35
36. Kubernetes環境 簡易プラットフォーム検査ツール CASVAL CASual Vulnerability AnaLyzerの略 • OSSの検査ツール群のラッパー（現在はOpenVASのみ） • UIやAPIを通じて、いつでも、誰でも、簡単に検査を実施可能 • 過検知の判断を不要とするため、事前に選択した緊急度の高い脆弱性のみを通知 社内での取り組み CASVAL API 開発者 検査対象 CIツール 緊急度の高い脆弱性以外を フィルタリング 結果通知 検査依頼 検査依頼 検査結果 検査 UI 36
38. CASVALを試す GitHubで公開中 • https://github.com/recruit-tech/casval • 環境構築方法はREADMEを参照 38 案件管理ツール（CASVAL ORIGIN） 遠隔実行モジュール（CASVAL REM）
39. まとめ 39
40. まとめ • ベンダーによる充足や補完関係を考慮した内製化が理想 • 基盤の展開とスキルトランスファーの二軸で永続化を図る • 基盤の展開：セキュリティ強化に必要なナレッジを仕組み化 • スキルトランスファー：専門スキルを社内エンジニアに展開 • 肝となるのは両者を促進する組織作り 40
41. ご清聴ありがとうございました