脅威分析はじめました / freee-getting-started-to-threat-analysis-2023

Transcript

1. 脅威分析はじめました PSIRT kaworu/taichi 2023年4⽉16⽇
2. ここに円に切り抜いた画像を入れてく ださい kaworu 2022年1⽉にfreeeへ⼊社。 Web脆弱性診断の業務を主に担当してます。 セキュリティエンジニア
3. ここに円に切り抜いた画像を入れてく ださい taichi 2020年8⽉⼊社、インフラ周りのセキュリ ティをやってます セキュリティエンジニア
4. 　 ⽬次 01 はじめた背景 02 脅威分析の概要 03 取り組んだ内容 04 まとめ
5. 　 ⽬次 01 はじめた背景 02 脅威分析の概要 03 取り組んだ内容 04 まとめ
6. freee PSIRTです • PSIRT = Product Security Incident Response Team • プロダクト絡みのセキュリティインシデントに対応することを主任務としつつ、 プロダクトのセキュリティ強化を⾏っています • セキュリティ周りの相談をプロダクトの開発チームから受け、何らかのアドバイ スをしたり、脆弱性診断をやったりもしています
7. 7 Plan Code Build Test Deploy Configure Monitor Code Review Response Logging Detect SAST SCA E2E IaC CSPM Vulnerability Assessment コードレビュー
 静的解析
 動作検証
 脆弱性スキャン
 脆弱性診断
 ログを取る
 異常検知
 インシデント対応
 構成管理
 ポリシー検証
 PSIRTの日常…DevSecOpsへの取り組み 開発と運用にsecurityを埋め込む
8. 最近のPSIRTの課題 「脅威」の評価基準に対する 認識がそろっていない 障害訓練での失敗
9. 「脅威」の評価基準に対する認識が揃っていない • 「脅威」= 「情報資産に損失を与える要因」 ◦ 攻撃とか、設定ミスとか • セキュリティに対する温度感や気にする場所が 開発チームによってまちまち ◦ 脅威を過剰に恐れていたり、逆に全く気にし ていなかったり… ◦ PSIRTとしても⾊々説明はするが、意思決定 の背景‧根拠がちゃんと伝わり腹落ちしてい るかがわからない
10. 「障害訓練」での失敗 • この間の障害訓練でボコボコにされました ◦ 障害訓練については「freee 障害訓練」で検索 ◦ サイバー攻撃を受けるシナリオでした • 敗因はいくつかあったが… ◦ ⼀番⼤きいのは、「freeeのプロダクトに刺さ りうる脅威をぱっと思い浮かべ、事象の原因 である可能性として検討することができな かった」こと
11. 原因の仮説 freeeにリアルに刺さりうる脅威を 過不⾜なく‧視覚的にわかりやすい形で 整理できていない事が原因では？ 「脅威」の評価基準に対する 共通認識がない 障害訓練での失敗
12. 脅威分析はじめました 脅威を正しく恐れ、正しく対処するために、 あり得る脅威を理解する「脅威分析」をやろうという話が始まりました
13. 　 ⽬次 01 はじめた背景 02 脅威分析の概要 03 取り組んだ内容 04 まとめ
14. 脅威分析の流れ 分析対象の 特徴理解 脅威の特定 脅威の評価 対策 フィードバック 設計資料‧コードから 構成図を書く 構成図を⾒ながら 刺さる脅威を列挙 列挙された脅威が どのくらい深刻か評価 対応有無‧優先度決め コード‧運⽤等の改善に よって、 脅威を解消したり、 許容可能なレベルに落とす
15. 分析⼿法ー着眼点の違いから 脅威（⼈） 脅威からみていくアプローチ 現実世界の攻撃にあわせる 資産（システム） 伝統的なアプローチ 可能な限り⽳を埋めていく “コンプライアンス型”
16. STRIDE Spoofing なりすまし Repudiation 否認 Tampering 改ざん Information Disclosure 情報漏えい Elevation of Privilege 特権の昇格 Denial of Service サービス拒否 データの流れを把握し、攻撃側の目線で、脅威を6つに分類する どのような脅威が発生しうるかを洗い出す手法。
17. STRIDE Spoofing なりすまし Repudiation 否認 Tampering 改ざん Information Disclosure 情報漏えい Elevation of Privilege 特権の昇格 Denial of Service サービス拒否 データの流れを把握し、攻撃側の目線で、脅威を6つに分類する どのような脅威が発生しうるかを洗い出す手法。 シンプルで取り組みやすそう
18. 　 ⽬次 01 はじめた背景 02 脅威分析の概要 03 取り組んだ内容 04 まとめ
19. 対象の選定 対象を選びたい…最初のトライなのでシンプルなものを
20. WEB画⾯ W A F 管 理 画 ⾯ A L B プロダクトA プロダクトB プロダクトD DB S3 Redis プロダクトC S3 taichi member member kaworu 分析対象の特徴理解（構成図作成）
21. STRIDE Spoofing なりすまし Repudiation 否認 Tampering 改ざん Information Disclosure 情報漏えい Elevation of Privilege 特権の昇格 Denial of Service サービス拒否 データの流れを把握し、攻撃側の目線で、脅威を6つに分類する どのような脅威が発生しうるかを洗い出す手法。
22. WEB画⾯ W A F 管 理 画 ⾯ A L B プロダクトA プロダクトB プロダクトD DB S3 Redis プロダクトC S3 taichi member member kaworu 脅威の特定（STRIDEを列挙） I/E 将来的に管理画面 ができた場合、それ を把握できないリス ク S Redis認証がない I 保持期間が長すぎる・退 会(?)したユーザのものを 保持している R/I DB共用 S アクセス制御IAMベース or IPベース E 従業員がconsole経 由でPIIを持ち出し - S3 - DB いろいろ 外から叩ける必要 のないAPI
23. WEB画⾯ W A F 管 理 画 ⾯ A L B プロダクトA プロダクトB プロダクトD DB S3 Redis プロダクトC S3 taichi member member kaworu 脅威の特定（STRIDEを列挙） I/E 将来的に管理画面 ができた場合、それ を把握できないリス ク S Redis認証がない I 保持期間が長すぎる・退 会(?)したユーザのものを 保持している R/I DB共用 S アクセス制御IAMベース or IPベース E 従業員がconsole経 由でPIIを持ち出し - S3 - DB いろいろ 外から叩ける必要 のないAPI I S3 復号鍵漏洩 I 実装不備（フロントの制御） I エラー発生時の マスキングもれ （社内漏洩） R/T ロギン グ漏れ zero day zero day
24. WEB画⾯ W A F 管 理 画 ⾯ A L B プロダクトA プロダクトB プロダクトD DB S3 Redis プロダクトC S3 taichi member member kaworu 脅威の特定（STRIDEを列挙） I/E 将来的に管理画面 ができた場合、それ を把握できないリス ク S Redis認証がない I 保持期間が長すぎる・退 会(?)したユーザのものを 保持している R/I DB共用 S アクセス制御IAMベース or IPベース E 従業員がconsole経 由でPIIを持ち出し - S3 - DB いろいろ 外から叩ける必要 のないAPI I エラー発生時の マスキングもれ （社内漏洩） R/T ロギン グ漏れ zero day zero day T/I: 入力 値の検証 I: 直接アクセス(アク セス設定の不備) いろいろWAF Bypass I: 機微な情報 の露出 T: Open Redirect R: Access log D DoS/DoW S/T/I: 実装にお ける脆弱性 I: 直接アクセス(アク セス設定の不備) T/I/E: 不要なポート やサービス I: 既知の脆弱 性 I: 既知の脆弱 性 I: キャッシュコント ロールの不備 S/I: MITM S/T/I: 実装にお ける脆弱性 D Lack of rate-limiting I 暗号化されてない重要 情報 S/D 実装不備 XSSとか無限ループによる DoS とか S/T/E SSRF S/T/E 導線はないけど知っていれば叩ける APIの存在 I 実装不備（フロントの制御） I S3 復号鍵漏洩
25. 脅威の評価
26. 脅威の評価 結果：管理画⾯から対策をしよう！
27. 脅威分析の流れ 分析対象の 特徴理解 脅威の特定 脅威の評価 対策 フィードバック 設計資料‧コードから 構成図を書く 構成図を⾒ながら 刺さる脅威を列挙 列挙された脅威が どのくらい深刻か評価 対応有無‧優先度決め コード‧運⽤等の改善に よって、 脅威を解消したり、 許容可能なレベルに落とす Done ToDo Done Doing
28. 脅威分析の流れ 分析対象の 特徴理解 脅威の特定 脅威の評価 対策 フィードバック 設計資料‧コードから 構成図を書く 構成図を⾒ながら 刺さる脅威を列挙 列挙された脅威が どのくらい深刻か評価 対応有無‧優先度決め コード‧運⽤等の改善に よって、 脅威を解消したり、 許容可能なレベルに落とす Done ToDo Done Doing 年末年始の闇に飲まれなぁなぁに… (あるあるですよね)
29. 脅威分析再始動 時は流れ、2023/02末ごろ… 社内で数年育てられていた共通認可基盤が部分的に稼働し始める PSIRTとしては、「この基盤が導⼊されていれば認可周りはOK」と⾔いたい そうすれば開発チームもPSIRTも時間短縮‧安⼼感UPできてハッピー 新しい仕組みでコスパもよい、いい題材なのでは… ということで、この基盤を対象にした脅威分析が再始動しました
30. まずは構成図を書きます 権限基盤の理解を深めるために、まずは主要機能にある程度フォーカスした図を書いた
31. まずは構成図を書きます • 認可基盤を主役とし、その主要機能に フォーカス ◦ 今回は構成要素間のデータの流れに着 ⽬。逆にインフラはあまり考えない • 基盤を利⽤する「導⼊先アプリケーショ ン」は、すべての攻撃リクエストを素通 りさせる⾮常に脆弱なものを想定 • メンテナンス⽤の経路も考慮に⼊れる。 ここが⾒過ごされ情報漏洩に⾄ったケー スも多い
32. まずは構成図を書きます 実はだいぶ苦戦しました • 分析対象を深く知らなかった ◦ 「なんかいい感じに認可やってくれる基盤」くらいの解像度 ◦ 資料はとても充実していたがムズカシイ。都度開発元に⾊々質問して教えて もらいました • envoyを噛ませるナウい認可の仕組みの理解が浅かった • gRPCを思い出すのに⼀⼿間 → この基盤を腰を据えて研究する事ができただけでも成果
33. 刺さる脅威を考える(予定) 今回もSTRIDEでいく予定 • 図を眺めながら、刺さりそうな脅威をとりあ えず列挙してみる • 「Elevation of Privilege」も試すかも 脅威 脅威 脅威 脅威 脅威 脅威 脅威 脅威
34. 刺さる脅威を考える：Elevation of Privilege Adam Shostack⽒によって開発されたカードゲーム。 トランプでやる⼤富豪のようなルールのゲームを通して、サービスに刺さりうる 脅威をSTRIDEベースで洗い出すことができる。Githubで無償公開されています。 (※1) 有志による⽇本語訳バージョン(※2) もあります。 ※1 https://github.com/adamshostack/eop ※2 https://github.com/KiiCorp/eop-ja
35. 認可基盤に対する脅威分析の今後 分析対象の 特徴理解 脅威の特定 脅威の評価 対策 フィードバック 設計資料‧コードから 構成図を書く 構成図を⾒ながら 刺さる脅威を列挙 列挙された脅威が どのくらい深刻か評価 対応有無‧優先度決め コード‧運⽤等の改善に よって、 脅威を解消したり、 許容可能なレベルに落とす Done Doing ToDo ToDo
36. freeeの脅威分析の今後 「freeeは新しいサービスがどんどん⽣えてくる環境なので、キャッチアップが⼤変」 だが、 「PSIRTとしてはサービスの中⾝まで知り、刺さりうる脅威を整理しておきたい」 というジレンマを解消するための⼿段として、脅威分析を活かしたい プロダクトのセキュリティを考える上での共通⾔語として脅威分析を活かすためには、 やはり⼿順の効率化が必要 ここは場数を踏んで慣れていきたい
37. 　 ⽬次 01 はじめた背景 02 脅威分析の概要 03 取り組んだ内容 04 まとめ
38. まとめ • 脅威分析：システムに刺さりうる脅威を、様々な視点から炙り出す取り組み ◦ 構成図を書き、刺さる脅威を列挙‧評価し、対策する • 急所となりうるシステムだけでも、図を書いてみましょう • 様々なセキュリティ施策のコスパがよくなりそうという⼿応えがある • なんとなく怖いなぁと思っている⼈ほど、やってみると意外な収穫があるかも
39. 参考⽂献等 • ⽯川 朝久 . 「脅威インテリジェンスの教科書」. 技術評論社. 2022年. 400ページ • 「STRIDE」https://learn.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20) • 「Elevation of Privilege」https://github.com/adamshostack/eop • 「Elevation of Privilege 脅威モデリングカードゲーム」https://github.com/KiiCorp/eop-ja • 「メルカリの脅威モデリングプロセス | mercari engineering」 https://engineering.mercari.com/blog/entry/20220426-threat-modeling-at-mercari/ • 「継続的なセキュリティ対策をするために脅威分析をしました | PLAID Engineer Blog」 https://tech.plaid.co.jp/threat-analysis