セキュリティ・キャンプ2024 全国大会 B1 プロダクトセキュリティの展望(#seccamp2024)

セキュリティ・キャンプ2024 全国大会 B1 プロダクトセキュリティの展望 藤田 尚宏 (@tanafuji_sec), 米内 貴志 (@lmt_swallow)

講義の基本的な流れ ● 概説と資料の紹介 ● ワークショップの導入と実施 ● 空き時間で資料を斜め読みする ● ディスカッション ● まとめ

概説

ポイント セキュリティは”社会”や”技術” の両方の要素に依存して成り立っている

概説の構成 1. 繋がる社会 ソフトスキルの話 ● 俯瞰する力 変化への対応 可 能 威 性 脅 便 感 利 心 線でつなぐ ● 相互作用、相互関係 安 点でみる ● 1. 繋がる社会 ● 2. 進化する技術 ● 3. 資産の保護 2. 進化する技術 負担を減らす手段 リスクへの対処 面で理解する ● 現在地点の認知 ● 解決すべき課題の設定 プロダクトセキュリティを取り巻く社会 3. 資産の保護

俯瞰する力 変化への対応

俯瞰する力 と 変化への対応 ● ○ ○ ○ ○ 点を増やす ● ● ニュースや専門家の情報発信を見る 何かを作ってみる 何かに参加してみる 何かの資格を取ってみる 異なる前提や関係性を理解する ○ ○ ○ 線を引く 面を増やす 広く浅い情報収集と、得意分野の深い知識や経験 時代の潮流（業界、技術、政治） 動くマネーの規模 前提を合わすためのコミュニケーション 観点や尺度を変えてみる ○ ○ ○ 事業のフェーズや規模 素人向けとプロ向け 組織やチームの中と外

歴史は繰り返さないが、韻を踏む “ History doesn't repeat itself, but it often rhymes” - Mark Twain ● ● ● ● 20 数年前までは Google 日本語検索はなかった 10 年前までは Slack はなかった 2 年前までは 生成AI はなかった インターネットの世界に物理も加わる（ex: IoT機器、自動車、宇宙、etc…） ● 過去を学んで知識（点）を養う → 新たな技術が出たときに、線を増やすだけで面が作れる * JNSAセキュリティ年表 https://www.jnsa.org/aboutus/chronology/index.html

• https://www.jnsa.org/aboutus/chronology/index.html

繋がる社会 〜身近にあるプロダクト〜

プロダクト 製品（せいひん、プロダクト、英 : product）とは、主に工業において原材料、原級を加工し精製した品物 のこと。 工業を営む企業においては主要な商品である。 完成する前の段階では、「仕掛品」や「半製品」と呼ばれ、加工後の最終成果品は「完成品」（最終製品）と いう。類似の名称に、製造品がある。 製品とは、有形の物に限定されない場合も多い。サービスも製品の1つとされる。教育サービス、金融商 品、イベント等、列車や映画館の座席予約も製品である。企業が顧客に提供して対価を得る物や行為の すべてが、製品と考えられる。 ISO 14001:2004（環境マネジメントシステム）では、製品とはプロセスの結果である とされ、サービス、ソ フトウェア、ハードウェア、素材製品に分類される。 製品 - Wikipedia

• https://ja.wikipedia.org/wiki/製品

繋がるインターネットの世界（生活） これらは全て「プロダクト」 ● ● ● ● ● ● ● ● ● SNS、写真共有、動画共有 メール ゲーム、マンガ 乗り換え案内 ニュース 学習 銀行、ポイントカード 決済 会員証（ジム、ガソリン、宅配等） * 緑は 2024年セキュリティ・キャンプ 全国大会講師が所属する企業で提供する主なプロダクト

物理の世界、繋がる世界（生活） 物理社会とインターネットの境界はほぼなくなった 配送 販売 販売元 出荷 配信 販売 個人間 取引

繋がるインターネットの世界（仕事） これらも全て「プロダクト」 ● ● ● ● ● ● ● ● ● オフィスソフト 人事、給与計算、会計 チャット ウェブ会議 様々な業務ツール（1on1、目標） データ分析基盤 インテリジェンス 開発支援（IDE、コード管理） 業務特化型のサービス ○ 医療、物流、広告、 セキュリティ * 緑は 2024年セキュリティ・キャンプ 全国大会講師が所属する企業で提供する主なプロダクト

物理の世界、繋がる世界（仕事） 独自システム 伝達 ・電話線 ・FAX ・郵送 ・メール 独自システム （手動） パッケージ* 変 化 共通言語 （プロトコル） ・広域網 ・専用線 ・API ・RPC SaaS （自動） * パッケージ：特定の業務や業界において共通で利用できる機能をまとめたシステムとして販売されるもの。

システム 相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体。一般性の高い 概念であるため、文脈に応じて系、体系、制度、方式、機構、組織といった多種の言葉 に該当する。 それ自身がシステムでありながら同時に他のシステムの一部でもあるようなものをサブ システムという。 システム - Wikipedia

• https://ja.wikipedia.org/wiki/システム

進化する技術 〜ウェブとクラウド〜

進化する技術 〜ウェブとクラウド〜 ● ● ここまで: 社会はどんどんプロダクトにつながっていっている！ ここから: それらプロダクトは、 ○ ○ どう生み出されているのだろう？の話 どう技術的には構成されているのだろう？の話

前提: プロダクトは投資の上で生まれている ● プロダクトを取り巻く構造 ○ ○ ○ ○ ● 提供者はコストを払ってプロダクトを生む 提供者はコストを払ってプロダクトを届ける 利用者はコストを払ってプロダクトを調達する プロダクトは、利用者に 価値を供する 提供者は様々な投資をしている ○ ○ 作る、届けるの両方に投資している ある瞬間お金が尽きれば全てが止まる ■ 黒字だとしても倒産しうる（ PL≠CF） ■ 投資できない = 作れない+届けられない ■ 💰が尽きないよう各社は頑張っている

プロダクトの将来のための投資 3 パターン

①+②: 新たな価値を早く・大きく届ける投資のために リードタイム = 投資総量 ÷ 時間あたり投資可能量 = (不要な投資 + 必要な投資) ÷ 時間あたり投資可能量 新たな価値 （B2B SaaS の例） = 新たな利用者あたり価値 × 新利用者数 = (対応可能になった UJ - 顧客に不要な UJ) × UJ 達成での顧客リターン × 新利用者数 *UJ: User Journey ● 早く・大きく価値を届ける投資をしたい → 上記各因数の強化が肝要 ○ ○ 例: 早く届けるために、 ”不要” なことを減らし、時間効率のよい投下をする 例: 大きく届けるために、たくさんの人の、残業の一番の原因を解消するものを作る

①+②: 新たな価値を早く・大きく届ける投資を PdM で リードタイム = 投資総量 ÷ 時間あたり投資可能量 = (不要な投資 + 必要な投資) ÷ 時間あたり投資可能量 新たな価値（B2B SaaS の例） = 新たな利用者あたり価値 × 新利用者数 = (対応可能になった UJ - 顧客に不要な UJ) × UJ 達成での顧客リターン × 新利用者数 *UJ: User Journey ● ● ● 不要な投資: 作る前に PSF を確かめて最小化する 対応可能になった UJ: 前項を通し、重要な UJ を特定して最大化する UJ 達成での顧客リターン: 顧客業務を理解し、インパクトを推定する

①+②: 新たな価値を早く・大きく届ける投資を技術で リードタイム = 投資総量 ÷ 時間あたり投資可能量 = (不要な投資 + 必要な投資) ÷ 時間あたり投資可能量 新たな価値（B2B SaaS の例） = 新たな利用者あたり価値 × 新利用者数 = (対応可能になった UJ - 顧客に不要な UJ) × UJ 達成での顧客リターン × 新利用者数 *UJ: User Journey ● 時間あたり投資可能量 = 一人の時間あたり投資可能量 × 人数 ○ ○ ● PJに参画可能な母集団や、人当たり生産性が最大化できるような技術を採用する 高速に調達できる計算資源（クラウド）を活用して作る 新利用者数: 市場のサイズ × 市場内で選んでくれる割合 ○ ○ 技術力で非機能要件を極め（例 : 高速! 安全! 等）て差別化する 新興技術（LLM）等を活用し、過去の不可能を可能にする

届いている価値は減衰・消失する 届いている価値の減衰（チャーン） ● ● ● ユーザー増による体験低下 新機能追加時の既存機能デグレ … 届いている価値の消失 ● ● ● 障害・災害によるサービス停止 セキュリティインシデント …

③ 届いている価値を維持する投資を技術で (1) 届いている価値の減衰（チャーン） ● ● ● ユーザー増による体験低下 新機能追加時の既存機能デグレ … 技術投資アプローチ例 ● ● ● モニタリング（RUM, APM, o11y 一 般）での早期発見 Continuous Integration プロセス での早期発見 …

③ 届いている価値を維持する投資を技術で (2) 届いている価値の消失 ● ● ● 障害・災害によるサービス停止 セキュリティインシデント … 技術投資アプローチ例 ● ● ● ● 高可用性のあるインフラ設計 事前リスク評価/残存リスク処理 危機有事にむけた事前訓練 …

小まとめ: プロダクトは投資のもと生まれる ● プロダクトは、提供者の投資のもと生まれる ○ ○ ● 投資は、プロダクトが顧客に選ばれ、顧客に届くことで回収される 投資効率を高める → より次の投資に繋がる → よいプロダクトへ！ 投資効率を高めるために、技術以外も含む様々な管理が用いられる ○ ○ ○ プロダクトマネジメント（ PdM）、技術的マネジメント、 … プロダクトにいい投資をするには、多様な専門性が求められるということ みなさんが思い浮かべる「技術」も、そこで求められる専門性の一つである

小まとめ: 技術も投資効率を高める重要な要素である ● 「技術がある → 成功する」は偽である ○ ● 当然「超セキュアである」も「成功する」の十分条件ではない だが、依然として、技術は早く・大きく・ずっと届けるための要素である ○ ○ だからこそ、技術スタック（使うもの）も、技術組織（使う人）も、たくさんこれまで「どうベターにできる か？」が議論されてきた。ビジネス上大事なのである。 (当然プロダクトセキュリティに向き合う上でも、この動向を理解しておく必要がある )

進化する技術 〜ウェブとクラウド〜 ● ● ここまで: 社会がプロダクトにつながっていっている これから: それらプロダクトは、 ○ ○ どう生み出されているのだろう？の話 どう技術的には構成されているのだろう？の話

インターネットの歴史（参考） インターネット歴史年表 - JPNIC ● ● ● ● ● ● ● 1960年代 軍事目的の研究 1970年代 暗号技術 1980年代 メール技術、ドメイン技術 日本にインターネットが来る 商用ISPの運用開始 1990年代 HTML技術の普及 Yahooを始め各種ウェブサイト開設 2000年代 家庭向けISPの普及（ISDN定額、ADSL、FTTH） iPhoneの普及（個人がインターネットと繋がる） AWSを始めクラウドサービス普及 コンピュータ・ウィルスの流行 2009年 Gumblar（ウェブサイト改ざん）の流行 2010年代 DDoSや情報窃取等のウェブサイトに対する 攻撃が本格化

• https://www.nic.ad.jp/timeline/

プロダクトを支える技術（例示） 〜 インターネットの歴史の上に昨今のプロダクトが構成されている 〜 NFC / IC ブロックチェーン QRコード 生成AI HTML JavaScript ブラウザ コンテンツ モバイルアプリ データベース CSS パスキー アプリケーション プロトコル (言語 / ミドルウェア) ドメイン CDN 無線LAN サーバ 家庭N/W クライアント環境 認証技術 OAuth 2.0 論理N/W 物理N/W サーバ環境（オンプレまたはクラウド）

インターネット標準化（RFC） ● ● ● ● RFC 675：TCP RFC 9114 - HTTP/3 RFC 6749 - The OAuth 2.0 Authorization Framework RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format インターネット技術の標準化プロセス～RFCとは？ “インターネット技術の標準化を推進する団体としてIETFがあります。 IETF(Internet Engineering Task Force) では、新しい技術仕様についてオープンな議論が行われ、ここでの議論を経てインター ネット技術の標準「RFC(Request ForComments)」が生まれます。 RFCとはインターネット利用者、運用担当者、開発者等に有益と判断された情報を公開するための文書シリーズで、インター ネット技術の発展に伴い常に新しいRFCが発行され続けています。”

• https://www.nic.ad.jp/ja/newsletter/No32/075.html

IT インフラ（オンプレとクラウド） オンプレ ● ● ● ● ● ● データセンタまたはホスティング システム要件 / 性能要件 発注 / 梱包 / 納品 / 開梱 セットアップ（手順 /スクリプト） 追加発注 / 追加セットアップ 電源 / バックアップ装置 クラウド登場前まではオンプレしかなかった クラウド ● ● ● ● ● アカウント発行 セットアップ（IaC） 弾力性 / 拡張性 / 可用性 / 柔軟性 / 自動化 セルフサービス デメリット： ○ ○ ○ セキュリティ(設定不備、データ保護) 依存性 コスト オンプレ回帰の潮流もあるが、全体としてはクラウ ドへの移行が進んでいる (*) (*) 令和5年版情報通信白書（第 8節）を参照 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd248200.html

• https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r05/html/nd248200.html

クラウドの利用形態と責任範囲 ・Software ・Platform as a Service ・Infrastructure クラウドの設定ミス対策ガイドブック (令和6年4月26日) https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00209.html

• https://www.soumu.go.jp/menu_news/s-news/01cyber01_02000001_00209.html

新たなIAMセキュリティの課題 「シャドーアクセス」とは、クラウド環境における、監視されていない、許可されていない、 目に見えない、安全でない、一般的に許可を与えすぎているアクセスのことです。つま り、アプリケーションやデータへの意図しないアクセスです。「シャドウアクセス」の影響は 甚大であり、進化するクラウドを持つあらゆる組織に影響を及ぼす恐れがあります。 出典：翻訳WGが「シャドーアクセスの定義： 新たなIAMセキュリティの課題」を公開しま した！（CSAジャパン） https://www.cloudsecurityalliance.jp/site/?p=33143

• https://www.cloudsecurityalliance.jp/site/?p=33143

シャドーアクセスの例 インターネット アプリEを業務目的で利用 アプリA アプリB アプリC アプリD ユーザA ユーザB ユーザC ユーザD 会社のアカウント 会社のアカウント 会社の口座 会社の口座 ・請求から気付くことがある ・ポリシーである程度制御できる アクセス アプリE ユーザE 個人のアカウント ・気付けない ・ポリシーも効かない

クラウドネイティブ クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウド などの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築お よび実行するための能力を組織にもたらします。 このアプローチの代表例に、コンテ ナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、および 宣言型APIがあります。 これらの手法により、回復性、管理力、および可観測性 のある疎結合システムが実現し ます。 これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更 を最小限の労力で頻繁かつ予測どおりに行うことができます。 CNCF Cloud Native Definition v1.1（日本語版） https://github.com/cncf/toc/blob/main/DEFINITION.md#日本語版

• https://github.com/cncf/toc/blob/main/DEFINITION.md#日本語版

クラウドネイティブと技術選定 ● 間違い： ○ ○ ○ ● あるべき姿： ○ ● ◯◯が流行っている → ◯◯を使ってプロダクトを開発する Kubernetes…、TypeScriptが…、Rustが… ただしエンジニア採用戦略上は有効 プロジェクトの要件、チームのスキルセット、各種コスト、経験値等を考慮 例：Kubernetesを選ぶ理由 ○ ○ メリット：回復力、管理力、可観測性 デメリット：学習曲線、管理の複雑さ、初期設定、トラブルシューティング → 短期間・単発イベントのサイト開発にKuberenetesを使うべきか？ → 開発からデプロイまでの迅速さではサーバレスには敵わない

技術の潮流を掴む ● ● ● ● ● ニュースやプレスリリース 新たなサービス形態の登場 新しい技術標準（RFC）や活発なOSSの更新 ◯◯ Foundationsや◯◯ Conferencesなどのコミュニティ動向 行政機関や法律改正の動向 歴史は繰り返さないが、韻を踏む ● 既存の概念やサービスが組み合わさって新たな形態が生まれることもある

技術進化に伴う法律の変化 ● ● ● ● ● ● ● ● ● 2000年：不正アクセス禁止法施行[1] （不正アクセス行為の禁止） 2002年：特定電子メール法[2] （迷惑メール配信の禁止） 2011年：著作権法[3] （違法ダウンロードの禁止） 2011年：ウイルス罪[4] （作成, 供用, 取得等の禁止） 2012年：改正不正アクセス禁止法[5] （他人の認証情報不正取得の禁止） 2014年：サイバーセキュリティ基本法[6]（国の責務を定義） 2017年：資金決済法改正[7] （暗号資産を金融資産として定義） 2022年：改正個人情報保護法[8] （漏えい時の報告義務化） 2023年：改正不正競争防止法[9] （デジタル空間における模倣行為の防止） [1] 不正アクセス禁止法に係る調査・研究｜警察庁 Webサイト [2] 特定電子メールの送信の適正化等に関する法律 (特定電子メール法) | 消費者庁 [3] 平成24年通常国会 著作権法改正について| 文化庁 [4] 不正指令電磁的記録に関する罪 [5] 1 - 不正アクセス禁止法改正Ｑ＆Ａ平成24年３月 [6] サイバーセキュリティ基本法｜国民のためのサイバーセキュリティサイト [7] 利用者向けリーフレット「平成29年４月から、『仮想通貨』に関する新しい制度が開始されます。」について [8] 令和２年改正個人情報保護法特集 [9] 不正競争防止法のこれまでの改正について

• https://www.npa.go.jp/bureau/cyber/what-we-do/research.html
• https://www.caa.go.jp/policies/policy/consumer_transaction/specifed_email/
• https://www.bunka.go.jp/seisaku/chosakuken/hokaisei/h24_hokaisei/
• https://www.keishicho.metro.tokyo.lg.jp/kurashi/cyber/law/virus.html
• https://www.npa.go.jp/bureau/cyber/pdf/6_QA.pdf
• https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/basic/basic_legal_11.html
• https://www.fsa.go.jp/common/about/20170403.html
• https://www.ppc.go.jp/news/kaiseihou_feature/
• https://www.meti.go.jp/policy/economy/chizai/chiteki/kaisei_archive.html

内閣官房（令和６年６月〜） サイバー安全保障分野での対応能力の向上に向けた有識者会議 ● ● ● ● 官民連携の強化 通信情報の活用 アクセス・無害化措置 横断的課題 a. b. c. d. e. f. サイバーセキュリティ戦略本 部・NISC・関係省庁が連携 した施策の推進 重要インフラ事業者等の対 策強化 政府機関等の対策強化 サイバーセキュリティ人材の 育成・確保 中小企業を含めた対策強化 その他の論点 https://www.cas.go.jp/jp/seisaku/cyber_anzen_hosyo/index.html

• https://www.cas.go.jp/jp/seisaku/cyber_anzen_hosyo/index.html

アイスブレーク：身近なWebプロダクトを紹介しよう 1. 隣の人とペアを組む 2. １分間、軽く雑談しながら考えタイム 3. １分間、Aさんが知っているサービスを紹介 4. １分間、Bさんも知っているサービスを紹介 5. １分間、両方のサービスを組み合わせて何か新しい ことができないか話し合う 6. 全体に話し合いの結果を紹介する(1分 x 5チーム)

いいアイデアですね！では、このアイスブレークを始めましょう！ 1分: Aさんが知っているサービスを紹介します。 A: 私は「Uber Eats」というサービスを使っています。これは、自宅にいながら自分の好きなレストランから食事を注文できる便利なア プリです。たくさんの種類の料理が選べるし、配達も早いんですよ。 1分: Bさんも知っているサービスを紹介します。 B: 私は「Airbnb」というサービスを利用したことがあります。これは、世界中の人々が自分の家やアパートを貸し出すことができる サービスで、旅行先でホテルよりもリーズナブルに宿泊することができます。 1分: 両方のサービスを組み合わせて何か新しいことできないか話し合います。 A: 「Uber Eats」と「Airbnb」を組み合わせると、どうでしょうか？例えば、旅行先で泊まった Airbnbの宿泊先から、その地域のローカ ルな美味しい料理をUber Eatsで注文して、自分たちの宿で楽しむことができますね。 B: そうですね！それだと、地元の食文化を体験しながら、快適な空間で食事を楽しむことができますね。また、地元の料理を提供し ているAirbnbホストも増えるかもしれませんね。 1分: 全体に話し合いの結果を紹介します。 A: みなさん、私たちは「Uber Eats」と「Airbnb」を組み合わせて、旅先での食事体験をより楽しいものにする方法を考えました。地元 の料理を堪能しながら、Airbnbの宿泊先でくつろぐことができます！ B: そして、これにより地元の経済を支援することもできますね。これから旅行する際は、ぜひこの組み合わせを試してみてください！

狙い ● 共感的傾聴 ● 積極的なフィードバック ● 創造的な結びつき ● ファシリテーション ● 要約スキル

資産の保護 〜セキュリティの目的〜

セキュリティの目的 セキュリティは、システムなどの資産が安全であるこ とを担保する手段である セキュリティで保護する対策の例 ・ 個人利用のシステム ：不正アクセス対策 ・ 業務システム ：情報漏えい対策、業務継続性（BCP） ・ IoT機器 ：ボット化対策、不正アクセス対策 ・ ブロックチェーン ：改ざん耐性

セキュリティとは 安全・保護・担保 ≠ 規制、保守 ● 人、建物、または国を危険または犯罪から安全に保つ ために行われること ● things that are done to keep a person, building, or country safe from danger or crime ● あなたに起こりうる悪いことからの保護 ○ ● protection from bad things that could happen to you 財産など、借りたお金を返せない場合に誰かにあげると約束するもの ○ something such as property that you promise to give someone if you cannot pay back money you have borrowed from them - ロングマン現代英英辞典より抜粋して翻訳

資産とは システムやソフトウェアも資産 資産とは、会計学用語であり、財務会計および簿記における勘定科目の区分の一つ。会 社に帰属し、貨幣を尺度とする評価が可能で、かつ将来的に会社に収益をもたらすことが 期待される経済的価値のことをいう。資産の額の総合計を総資産と呼ぶこともある。 広義では、経済主体（家計、企業、政府）に帰属する金銭・土地・建物・証券など の経済 的価値の総称のことをいい、一般的用法ではこの意味で用いられる。 https://ja.wikipedia.org/wiki/資産

• https://ja.wikipedia.org/wiki/資産

情報セキュリティの３大要素（CIA） 情報セキュリティマネジメントに関する日本工業規格「 JIS Q 27000シリーズ」で定められている ● ● ● 機密性(Confidentiality) ○ 定義：認可されていない個人、エンティティ又はプロセスに対して、情報を使用させず、また、開示しない特性 ○ つまり、当事者だけが使える 、他人に見せない 完全性(Integrity) ○ 定義：正確さ及び完全さの特性 ○ つまり、変更履歴やバックアップ のこと 可用性(Availability) ○ 定義：認可されたエンティティが要求したときに，アクセス及び使用が可能である特性 ○ つまり、使いたいときに いつでも使える ＋α 真正性、責任追及性、否認防止、信頼性

JIS Q 31010:2022 リスクアセスメント技法 リスク ＝ 脆弱性 ｘ 脅威 ｘ 資産価値 ● リスク： ○ 定義：目的に対する不確かさの影響。 ○ つまり、リスク ≠ 被害。リスクは大きさで測る。 ● 脆弱性： ○ 定義：一つ以上の脅威によって付け込まれる可能性のある、資産又は管理策の弱点。 ○ つまり、攻撃者にとって狙いやすい弱点のこと。 ● 脅威： ○ 定義：システム又は組織に損害を与える可能性がある、望ましくないインシデントの潜在的な原因。 ○ つまり、攻撃者が行う攻撃の可能性 や意思、災害の発生可能性 のこと。 ● 資産価値： ○ 定義：CIA(機密性・完全性・可用性)が損なわれた時の事業上の影響(損害) ○ リスク分析では、CIAそれぞれを段階的に評価したりする。

https://www.docswell.com/s/tanafuji-sec/KLL3PD-2023-05-18-144600#p13

• https://www.docswell.com/s/tanafuji-sec/KLL3PD-2023-05-18-144600#p13

リスクへの対策方法 大 移転 ⬆ 小 保有 被害 頻度 低 ➔ 高 回避 低減 ● 軽減 ○ スイスチーズモデル 技術選択の幅を狭めないために、多層防御 で"対策"を検討する。 ● 受容 ○ 脅威の影響が小さい場合、工数や期日の兼ね合いから一時的にリスクを"受容"す る。 ● 移転 ○ 脅威の影響が大きく、頻度が低い場合、保険加入などの”転嫁”を検討する。 ● 回避 ○ セキュリティを理由に”やらない ”を決めること。”開発者体験”が悪くなる。 リスクマネジメントの分野(JIS Q 31000:2019 リスクマネジメント－指針)に おいて、リスク対策は軽減/受容/移転/回避の４つに分類される。

資産に対する脅威 ● クラウド漏洩、「凡ミス」多発 2024年4月3日付 日経電子版 (link) ○ ● ● 機密性（マイナンバー情報流出） 米病院、サイバー攻撃の的 2024年4月9日付 日経電子版 (link) ○ 可用性（業務停止のリスク） ○ 完全性（データ破損） ゼロデイ攻撃への備えはあるか？ 企業の意外な対策 ○ CIA全てを侵害する起点となり得る 2024年3月13日付 日経電子版 (link)

• https://www.nikkei.com/article/DGKKZO79746100S4A400C2CM0000/
• https://www.nikkei.com/article/DGKKZO79878490Y4A400C2FFJ000/?type=my#AAAUAgAAMA
• https://www.nikkei.com/article/DGXZQOUC286PC0Y4A220C2000000/

サイバー犯罪者がシステムを狙う動機 ● 組織的な背景 ○ ● 金銭 、諜報、地政学、思想（ハクティビズム） 個人的な背景 不正のトライアングル 動機 ・ ストレス（怒られたくない） ・ 儲かると思った、収入を上げたい ・ 好奇心（何が起こるか見てみたい） 機会 不正 動機 機会 ・ 目の前に標的（脆弱性）がある ・ 隠蔽・ごまかし 正当化 正当化 ・ みんなやってる ・ 周囲に対する不公平感 ・ 虚栄心、自己顕示欲 Ethical Hacking 表裏一体 ・ 高い倫理観 ・ 正しい知識 ・ 適法性

攻撃者の目線と防御側の目線 本クラスで主に扱う範囲 B1,B2,B3,B4,B5,B6 B4で扱う Red Team CNSSI 4009-2015で定義 ● ● ● 攻撃シミュレーション(TTP) サイバー攻撃時の影響調査 ブルーチームの機能性評価 ● ● ● ● 脆弱性診断 ペンテスト ペイロード エクスプロイト CTF バグバウンティ Purple Blue Team Purple Teamに明確な定義はない ● ● ● ● Red / Blueの間 相互理解 相互連携 情報共有 CNSSI 4009-2015で定義 ● ● ● 長期にわたるセキュリティ運用 監視による攻撃検知 防御シミュレーション ● ● ● ● ● ● ● 脆弱性評価 セキュリティ体制の確立 セキュリティ設計、実装、レビュー セキュリティ緩和手法の提供 脅威とリスクの特定 ソリューションの統合 サイバーセキュリティ強化 ハードニング インシデント対応演習

• https://csrc.nist.gov/glossary/term/blue_team
• https://csrc.nist.gov/glossary/term/red_team

C 脅威解析クラスのスコープなので対象外 用語：TTP(Tactics, Techniques, and Procedures) 〜サイバー攻撃者の振る舞い〜 The behavior of an actor. A tactic is the highest-level description of this behavior, while techniques give a more detailed description of behavior in the context of a tactic, and procedures an even lower-level, highly detailed description in the context of a technique. アクターの振る舞い。タクティクスはこの振る舞いの最上位レベルの記述であり、テク ニックはタクティクスの文脈で振る舞いをより詳細に記述し、プロシージャーはテクニック の文脈でさらに低レベルで非常に詳細に記述する。 NIST SP 800-150 https://csrc.nist.gov/glossary/term/tactics_techniques_and_procedures

• https://csrc.nist.gov/glossary/term/tactics_techniques_and_procedures

プロダクト開発・運用へのセキュリティの組み込み(例) 安全なクラウドネイティブ実現へ：内製開発におけるプロダクトセキュリティ強化の軌跡と開発チームとの協調 - CNDT2023 | ドクセル

• https://www.docswell.com/s/tanafuji-sec/5YW68E-cndt20231211#p19

スタートアップでの再現性は？ ● 前スライドは、比較的体力のある大企業の例 ● スタートアップで同じことをやるのは困難 ● 組織のフェーズや扱うデータの種別により求められるセキュリティの対応可否が異 なる

組織の成長フェーズに応じたセキュリティへの対応 セキュリティの文化醸成や実装は早いに越したことはないが、適期がある。 組織 スタートアップ（シード・ アーリー） スタートアップ（ミドル・レ イター） 中小企業 大企業、エンタープライズ プロダクトの状 況 プロトタイプ、PMF 安定収益、スケール 単一プロダクト、複数サブ システム 複数チーム 複数プロダクト 複数ユニット セキュリティへ の対応 開発優先。 経験則的なセキュリティ強 化。 規制や外圧*、セキュリ ティ侵害を受けてから強 化する。 CTO(相当)がセキュリ ティも担う。 セキュリティチームや専属 メンバーの立ち上げ。 セキュリティ人材の属人 的、英雄的な活動によりセ キュリティを維持。 セキュリティの民主化。 ガバナンスにより全員がセ キュリティを意識する。 仕組み化により組織横断的 で広範なセキュリティ施策を 展開する。 * 規制や外圧の強さ ＝ 求められるセキュリティ水準の高さはデータ種別や規模により異なる 金融、医療、政府機関 ＞ 個人情報 ＞ 機密情報・知財 ＞ データ基盤 (購買、IoT等）＞ その他(従業員、財務情報等 )

実装すべきセキュリティコントロールは？ CIS Critical Security Controls Implementation Groups(IG) ３段階、全153種のセキュリティコントールを定義 ● ● セルフアセスメント リスク分析の基準とする ● IG1: 基礎レベル、56種のコントール ○ ○ ● IG2: 中級レベル、+ 74種のコントール ○ ○ ● 全企業必須で対応すべきレベル 従業員情報、財務情報などの非機密情報 組織にセキュリティ担当者がいるレベル 法令遵守、顧客や企業の機密情報 IG3: 上級レベル、+ 23種のコントール ○ ○ 専門のセキュリティ対応組織があるレベル 規制やコンプライアンスの監視、機密情報の整合性、社会福祉に関わる https://www.cisecurity.org/controls/implementation-groups

• https://www.cisecurity.org/controls/implementation-groups

CIS Controls v8とIG 01 組織の資産の棚卸しと管理 02 ソフトウェア資産の棚卸しと管理 03 データ保護 04 組織の資産とソフトウェアの安全な構成 05 アカウント管理 06 アクセス制御管理 07 継続的な脆弱性管理 08 監査ログ管理 09 電子メールと Webブラウザの保護 10 マルウェアからの防御 11 データ復旧 12 ネットワークインフラストラクチャ管理 13 ネットワーク監視と防御 14 セキュリティ意識向上とスキルトレーニング 15 サービスプロバイダの管理 16 アプリケーションソフトウェアのセキュリティ 17 インシデントレスポンスと管理 18 ペネトレーションテスト https://www.cisecurity.org/controls/

• https://www.cisecurity.org/controls/v8

セキュリティ対応組織 活動成果｜ISOG-J：セキュリティ対応組織の教科書第3.1版

• https://isog-j.org/output/2023/Textbook_soc-csirt_v3.html

ディスカッション：セキュリティ要件の違いを検討しよう 1. 2. 3. グループを2,3名ずつ、４つに分ける a. スタートアップ（シード・アーリー期） 3人の会社 b. スタートアップ（ミドル・レイター期） 50人程度の会社 c. 中小企業 300人以下の会社 d. 大企業、エンタープライズ 1,000人以上の会社 ランサムウェア対策の実現方法について a. 検討時間は15分 b. 具体的な対応策を３つ検討して提案してください c. 検討にあたって考慮したことを発表する 発表する

ヒント グループA グループB グループC グループD 組織 スタートアップ（シード・ アーリー期） スタートアップ（ミドル・レイ ター期） 中小企業 大企業、エンタープライズ 共通 ・組織の規模やフェーズに応じて、どのようなリスクが最も高いか ・セキュリティの原則は、特定、防御、検知、対応、復旧 ・現実的に実施可能かを検討する ヒント ・シンプル且つ効果的な対 策を優先する ・クラウドサービスや外部 リソースを活用する ・基本的なセキュリティ教 育とバックアップ戦略 ・成長に伴うリスクの増加 に対応 ・組織的なセキュリティポリ シーの整備 ・セキュリティ担当者の設 置や専門家のコンサルティ ング ・組織的なセキュリティプログラ ム ・どのチームがインシデントに対 応するか ・継続的なセキュリティトレーニン グと監査 ・高度なセキュリティインフラ の整備 ・インシデントレスポンス計 画と定期的な訓練

結果 グループA グループB グループC グループD 組織 スタートアップ（シード・ アーリー期） スタートアップ（ミドル・レイ ター期） 中小企業 大企業、エンタープライズ 提案例 ・多要素認証（MFA）の導入 ・特権管理者権限の分離 ・クラウドバックアップの利用 ・初期のセキュリティ意識教育 ・マルウェア対策機能の有効化 ・キーパーソンレベルでのインシデ ント対応手順の確立 ・組織で利用する端末やソフトウェア を資産管理する ・エンドポイント保護ソリューションの 導入 ・データ管理プロセスを確立する ・パッチ管理の自動化 ・監査ログ機能の有効化 ・バックアップ、復旧用データの環境 分離 ・インシデント報告フローの確立 ・従業員向けの定期的なセキュリ ティトレーニング ・ソフトウェアやライブラリの許可リストを作 成する ・データフローの整備する ・データ暗号化とアクセス制御の強化 ・アカウント管理の中央集権化 ・脆弱性管理ツールの導入 ・ウイルス対策ソフトの中央集権化 ・定期的なバックアップと復旧のテスト ・脅威モデリングの実施 ・セキュアコーディングトレーニング ・CSIRT組織の組成 ・データ漏えい保護（DLP）の導入 ・機密データのアクセスロゴを実装 ・ロールベースのアクセス管理 （RBAC） ・コードレベルのセキュリティチェック ・侵入テストと脆弱性評価の定期実 施 ・大規模なセキュリティオペレーション センター（SOC）の運用 ・インシデント対応基準の策定 考慮点 コスト効率を重視、迅速な導入 スケーラビリティと従業員数の増加 に対応 安定性と成長を考慮した中期的なセキュリ ティプラン グローバル対応と法令遵守、統合的 なセキュリティアプローチ 発表メモ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・

注意：組織規模と被害規模は比例しない ● ● ● 少人数でスケールしやすいプラットフォームビジネスは、迅速な成長を遂げる一方 で、保有するデータ量が多くなるため、データ侵害が起きた場合のリスクが非常に 高くなる。 組織のスケールとセキュリティ施策のスケールが一致しない場合、特に新興企業に おいては、セキュリティリスクが顕在化しやすい。 成長過程で早期に強固なセキュリティ体制を構築することが重要。 メガバンク vs FinTech企業

セキュリティにおけるコミュニケーションの役割 https://www.docswell.com/s/tanafuji-sec/5YW68E-cndt20231211#p37

• https://www.docswell.com/s/tanafuji-sec/5YW68E-cndt20231211#p37

コミュニケーションのパターン 口頭 ● 即応性 ● 柔軟性 ● 感情伝達 ● 非言語伝達 ● 誤解（雰囲気・緊張） 文書 ● 記録性 ● 時間効率 ● 正確性 ● 誤解（文脈・背景・意図） 聞く力 ● ● ● ● 集中 共感 フィードバック 質問 伝える力 ● 明確 ● 簡潔 ● 感情表現 ● 視覚的な補助 会話形式 ● 双方向性 ● 柔軟性 ● 即時対応 発表形式 ● 情報の一貫性 ● 時間効率 ● 専門性 読み解く力 ● 文脈理解 ● 批判的思考 ● 要約 ● 推論 書く力 ● ● ● ● ストリーム形式 ● リアルタイム性 ● 連続的 ● 即時フィードバック スナップショット形式 ● 明確性 ● 記録性 ● 集中性 論理的思考 表現 構成 編集

フリーディスカッション