セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート / cloudnative-architecture-of-asm

セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート

アーキテクチャConference 2024 の登壇資料です。
https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/lYOp8vXZ

Transcript

1. © 2024 Finatext Holdings Ltd. セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 Satoshi Tajima, Finatext Holdings Ltd. アーキテクチャConference2024
2. © 2024 Finatext Holdings Ltd. • クラウドサービスの利用拡大により、組織の保有するIT資産は、 その種類も数も増加し、全体像の把握が難しくなってきている • 多種多様になったIT資産の一覧や、そのリスクをより適切に管理するために、 Attack Surface Management (ASM) の実施が重要になっている • ASM を クラウドネイティブに実現するアーキテクチャを紹介 • より深い・有意義なASMを実現しようと思ったときにでてくる ハードルについてもお伝え 1 (最初に) 前半のまとめ
3. © 2024 Finatext Holdings Ltd. 2 Background 本日のプレゼンテーションのコンテキスト
4. © 2024 Finatext Holdings Ltd. • IT資産 ◦ 対象: ドメインやIPアドレスのリスト ◦ 取得方法: 管理台帳や、WHOISの情報などを参考に取得する • アクセス可能 ◦ 主にインターネットからアクセス可能なポートが存在することを意味する ◦ HTTPやSMTPやSSH等のプロトコルが代表的 • 脆弱性 ◦ 主にCVEが採番されているような、ソフトウェアの既知の欠陥 ◦ 設定の不備や機密情報の公開 ※ASMという言葉が使われ始めたのは比較的最近だが、 これに類する施策はずっと前から行われていたというニュアンスで “従来の” というワーディングを使っている。 3 “従来の” Attack Surface Management (ASM) とは 組織の外部からアクセス可能なIT資産を発見し、その脆弱性を継続的に検出・評価する取り組み
5. © 2024 Finatext Holdings Ltd. • 会社: 株式会社Finatextホールディングス ◦ 金融の基幹システムをSaaSにして提供している会社 ◦ 複数の金融領域(証券・保険・貸金)の基幹システム(toB)を提供し、 かつ基幹システム上で稼働するサービス(toC)も提供している マルチプロダクト企業 • 発表者: 田島 悟史 (X: @s_tajima) ◦ 株式会社Finatextホールディングスの取締役CTO/CISO ◦ 最近はAppleのPCC(Private Cloud Compute)に興味があります ▪ https://github.com/apple/security-pcc ▪ https://security.apple.com/documentation/private-cloud-compute/ 4 会社紹介 & 自己紹介
6. © 2024 Finatext Holdings Ltd. • AWSアカウント数: 約200アカウント • 保有ドメイン数: 約260ドメイン • DNSレコード数: 約4,200レコード (※TXTレコード等も含む) • DNSレコードの変更頻度: 約250回/月 (※直近3ヶ月の実績) 5 Finatextグループの環境 マルチプロダクト
7. © 2024 Finatext Holdings Ltd. • AWSアカウント数: 約200アカウント • 保有ドメイン数: 約260ドメイン • DNSレコード数: 約4,200レコード (※TXTレコード等も含む) • DNSレコードの変更頻度: 約250回/月 (※直近3ヶ月の実績) 　=> 人力で台帳管理するには多すぎる規模 6 Finatextグループの環境 マルチプロダクト
8. © 2024 Finatext Holdings Ltd. • ほとんどのプロダクトをAWS上で構築 • AWSアカウントは大量にあるものの、すべて1つのOrganizatoionの配下 • ソースコードはすべて1つのGitHub Org上で管理している 7 Finatextグループの環境 クラウドベース
9. © 2024 Finatext Holdings Ltd. • ほとんどのプロダクトをAWS上で構築 • AWSアカウントは大量にあるものの、すべて1つのOrganizatoionの配下 • ソースコードはすべて1つのGitHub Org上で管理している 　=> 従来のASMの考え方でカバーできないリスクが存在する 　=> 一方で、従来のASMで使えなかった手法が使える 8 Finatextグループの環境 クラウドベース
10. © 2024 Finatext Holdings Ltd. 9 クラウドネイティブなASM “従来の” ASMとの違い
11. © 2024 Finatext Holdings Ltd. “従来の” ASM の要素に加えて... • IT資産 ◦ 対象: クラウドリソースも含まれる ◦ 取得方法: クラウドサービスのAPI等から動的に収集する ◦ 例) IAM Role・S3バケット • アクセス可能 ◦ クラウドサービス特有の仕様にもとづくアクセス ◦ 例) AWSのIAM Roleに対するAssumeRole • 脆弱性 ◦ クラウド特有の仕様にもとづく脆弱性 ◦ 例) AWSのIAM Roleにおける、Trust Relationshipの設定ミス 10 “クラウドネイティブな” Attack Surface Management (ASM) とは 組織の外部からアクセス可能なIT資産を発見し、その脆弱性を継続的に検出・評価する取り組み
12. © 2024 Finatext Holdings Ltd. “従来の” ASM の要素に加えて... • IT資産 ◦ 対象: クラウドリソースも含まれる ◦ 取得方法: クラウドサービスのAPI等から動的に収集する ◦ 例) IAM Role・S3バケット • アクセス可能 ◦ クラウドサービス特有の仕様にもとづくアクセス ◦ 例) AWSのIAM Roleに対するAssumeRole • 脆弱性 ◦ クラウド特有の仕様にもとづく脆弱性 ◦ 例) AWSのIAM Roleにおける、Trust Relationshipの設定ミス 11 “クラウドネイティブな” Attack Surface Management (ASM) とは 組織の外部からアクセス可能なIT資産を発見し、その脆弱性を継続的に検出・評価する取り組み => 必ずしも発見・検出・評価が “外部” からである必要はない => “内部” における施策も合わせて紹介
13. © 2024 Finatext Holdings Ltd. 12 FinatextグループのASMのアーキテクチャ ASMをクラウドネイティブに実現している方法
14. © 2024 Finatext Holdings Ltd. 13 FinatextグループにおけるASMのアーキテクチャ ASMに関連する取り組みの全体像
15. © 2024 Finatext Holdings Ltd. 14 FinatextグループにおけるASMのアーキテクチャ ASMに関連する取り組みの全体像 => ASMにおいて重要性の高い部分を抜粋して紹介
16. © 2024 Finatext Holdings Ltd. 15 FinatextグループにおけるASMのアーキテクチャ DAST (Dynamic Application Security Testing) • アプリケーションの実際の動作環境に対して リクエストを送信して、脆弱性を検査・検出する手法 • 検査の対象を、Route53のAPIを使って動的に取得 • 検査のロジックは Playwright を使って自前で記載 ◦ 現時点ではそれほど複雑な検査ではないため、 入出力の柔軟性や内部挙動の制御の容易さを重視している • 検査の内容は以下のような簡易的なもの ◦ 公開されたコンテンツ(HTMLやJS)に機微な情報が含まれていないか ◦ 公開すべきでないコンテンツ( .git/ や .aws/ 等)が公開されていないか
17. © 2024 Finatext Holdings Ltd. 16 FinatextグループにおけるASMのアーキテクチャ DASTのアーキテクチャ
18. © 2024 Finatext Holdings Ltd. • クラウドサービスの設定不備による 脆弱性を検知するための仕組み • AWSのSecurity Hubや、内製のツールを活用 • パブリックアクセス可能なS3 Bucketを検知したり、 任意のPrincipalからAssumeRole可能なIAM Roleを検知したりできる 17 FinatextグループにおけるASMのアーキテクチャ CSPM (Cloud Security Posture Management)
19. © 2024 Finatext Holdings Ltd. • OSやミドルウェアやライブラリに存在する 既知の脆弱性を検知する仕組み • アプリケーションの依存ライブラリに対してはDependabotを OSの依存パッケージに対してはECR image scanningを活用 • DependabotやECR image scanningによるアラートは、 そのままだとFalse Positive(対応の必要性が低いアラート)が多いので、 KEV Catalog というデータベースと突合し、ノイズを削減している 18 FinatextグループにおけるASMのアーキテクチャ Dependency Scanning
20. © 2024 Finatext Holdings Ltd. 19 クラウドネイティブなASMの今後 現在の課題と改善の予定
21. © 2024 Finatext Holdings Ltd. • 現状は、表面的にわかる脆弱性 (機微な情報が公開されていないか等) しか 確認できていない • 本来は、より深い検査も行いたい ◦ 使われているテクノロジーの特定 ◦ CVE-XXX に該当する脆弱性の有無 ◦ OWASP Top 10 や OWASP API Security に該当する脆弱性 (の一部)の有無 • 一方で、これらの実現には一定の考慮事項がある ◦ 本番環境の稼働に影響を与えないことの担保 ◦ 検査対象が自社保有資産であることの担保 20 現在のASMの課題 DASTの検査深度
22. © 2024 Finatext Holdings Ltd. • 現状DASTの診断対象は、Route 53 のAPIベースでしか取得できていない ◦ つまり、DNSレコードの登録のないリソースが拾えていない • よりカバレッジをあげるためには、S3やALBやCloudFrontの APIを直接使いリソースのリストアップをする必要がある • 一方で、これを内製でやりきるのは大変 ◦ 様々なクラウドリソースの情報を個別に収集する仕組みを作る手間 ◦ 新しいサービスや機能も次々登場する ◦ Route53 からの取得情報との重複をどのように扱うべきか 21 現在のASMの課題 DASTの検査対象のカバレッジ
23. © 2024 Finatext Holdings Ltd. • クラウドサービスの利用拡大により、組織の保有するIT資産は、 その種類も数も増加し、全体像の把握が難しくなってきている • 多種多様になったIT資産の一覧や、そのリスクをより適切に管理するために、 Attack Surface Management (ASM) の実施が重要になっている • ASM を クラウドネイティブに実現するアーキテクチャを紹介 • より深い・有意義なASMを実現しようと思ったときにでてくる ハードルについてもお伝え 22 前半のまとめ