Secure Software Development Practices in Recruit February 7, 2020 Muneaki Nishimura Platform Security Group Manager Productivity Engineering Department Recruit Technologies Co., Ltd.

自己紹介 西村 宗晃（にしむねあ） 株式会社リクルートテクノロジーズ プロダクティビティエンジニアリング部 プラットフォームセキュリティグループ グループマネジャー 2016年3月中途入社（4年目） 2

主な経歴 2002年 札幌のベンチャーでWebデザイナー • 不況でデザインの仕事が激減、菓子パンのレビュー※1で生計を立てる 2005年 国内電機メーカーで携帯電話のLSI開発 • Nokiaのエンジニアからセキュリティ技術を学ぶ 2011年 ソニーグループでWeb✕モバイル分野のセキュリティ担当 • 開発プロセスにおけるセキュリティ標準の策定など 2016年より現職 3 ※1 https://tech.nikkeibp.co.jp/it/atcl/column/17/030300065/071800015/

特技はOSやブラウザの脆弱性探し MozillaとGoogleの報奨金で土地のローンを完済 4 https://www.youtube.com/watch?v=8yClLHKOzIU

モジラ銀行のテーマ 報奨金を貰えた喜びを歌に 5 https://www.youtube.com/watch?v=a4YfAeFauq0

現職における私の役割 セキュリティの技術専門組織として、プロダクトの脆弱性対策を横断的に支援 • 300を超えるプロダクト（年間売上高100億円を超えるものも多数） プロダクトA 企画 開発 運用保守 プロダクトB 企画 開発 運用保守 プロダクトC 企画 開発 運用保守 人材メディア領域 販促メディア領域 リクルートテクノロジーズ（横断組織） サイバーセキュリティ部 （セキュリティ統制施策の推進） ITエンジニアリング本部 プラットフォームセキュリティG プロダクトD 企画 開発 運用保守 … … 支援 支援 支援 支援 支援 連携 6

最初は社内に潜む脆弱性を探していたのですが… 社内インフラや商用プロダクトの脆弱性リスクを攻撃者の目で早期発見 7 https://scan.netsecurity.ne.jp/article/2017/08/02/40016.html

防御する側が圧倒的に不利な戦いであることに気付き… 攻撃と防御の非対称性 8 攻撃する側 一つでも穴を見つければ勝ち 防御する側 すべての攻撃を防がなければ負け

防御する側の仕組み作りにシフト 基盤構築✕開発支援の二軸で各プロダクトのセキュリティ品質向上を図る 9 開発支援 基盤構築 人材メディア リクナビ タウンワーク : 脆弱性管理基盤 簡易脆弱性 検査スキャナ モバイルアプリ 脆弱性スキャナ ： セキュリティ 要件定義 設計・実装 レビュー 探索型 脆弱性検査 … セキュア 開発プラクティス セキュア開発 プロセス構築支援 販促メディア じゃらん ホットペッパー グルメ Airシリーズ ゼクシィ スタディサプリ カーセンサー SUUMO ホットペッパー ビューティー :

脆弱性管理基盤（RAFFLESIA） インフラやアプリ開発環境から構成情報を集めて脆弱性を自動検知 10 コンテナレジストリ RAFFLESIA コードリポジトリ 各種インフラ 脆弱性情報 アプリ構成情報 コンテナ構成情報 インフラ構成情報

簡易脆弱性検査ツール（CASVAL） 11 Kubernetes 検査環境 API 開発者 検査対象サーバ CIツール 緊急度の高い脆弱性以外を フィルタリング ③結果の通知（緊急なものだけ） ①検査依頼（API） ①検査依頼（GUI） 検査結果 ②疑似攻撃 UI ： 開発者が自由に使える脆弱性スキャナ 拡充予定 https://github.com/recruit-tech/casval

ハンズオン型開発者教育（Bad SNS） 架空のSNSアプリを題材に、脆弱性の発生原理を学ぶ 12 https://github.com/ommadawn46/badsns2019 2018年度版はWEB+DB PRESSに掲載

セキュアソフトウェア開発プラクティス（SSDP） 将来のリスク （開発組織とプロセスの 成熟度評価） 現状のリスク （現行の脆弱性リスク評価） 13 将来の脆弱性リスク低減を目的として、開発組織と開発プロセスの評価と 改善を行うためのフレームワーク SREの信頼性階層モデルに基づき、リスクを可視化 リスク低減効果のあるプラクティスを導入 ① リスクの可視化 ② 検知したリスクへの事後対応 ③ 根本原因の洗い出し ④ 再発防止策の検討 ⑤ 開発計画への組み込み ⑥ 開発組織への浸透

セキュアソフトウェア開発プラクティス - 今後の展望(1) QA・リリース 要件定義・基本設計 詳細設計・実装 防ぐべき脆弱性 • 機能の悪用 ポイント詐欺・ランキング不正・ 業務妨害・他ユーザへの迷惑行為 ・・・ • セキュリティ機能の不在や不備 多重応募の検出ロジックの不在、 本人確認の不在／バイパス・・・ • コーディング不備による脆弱性 SQLインジェクション、XSS、 ディレクトリトラバーサル・・・ • 3rdパーティライブラリの脆弱性 StrutsやWordPressの脆弱性・・・ • セキュリティ要件の実装不備 • サーバ設定の不備 • リリース後に公表された 3rdパーティライブラリの脆弱性 対策 セキュアソフトウェア開発プラクティス（SSDP） ？？ 14 来期の検討テーマ 社内アーキテクトがセキュリティ面の方針策定を可能とするための仕組み作り

セキュアソフトウェア開発プラクティス - 今後の展望(2) 交通の危険予知トレーニングをベースとしたアプローチを検討中 15 スピードも出てないし、特に危険はないと思います。 左の自転車が飛び出してくる危険があるかもね。 右の車の間から急に人が出て渡ろうとするかもしれ ないぞ。その対応で慌てて急ブレーキを踏んだら、 バスの乗客が転倒する恐れもあるよね。 思い付くリスクの質と量を トレーニングにより高めていく http://www.nasva.go.jp/fusegu/documents/h20/bus_ts_all_h20.pdf

セキュアソフトウェア開発プラクティス - 今後の展望(3) 身近なアーキテクチャを元に「悪用されないか？」という視点を鍛えていく パスワードリマインダにアクセス メアドと新しいパスワードを入力 指定されたメアドに紐づく 利用者のパスワードをリセット メアド 新しいパスワード 変更 Q1. 次のパスワードリセットの仕組みにはどのようなリスクがあるか？ 16

Security. Faster, simpler and closer to you.