適応し続けるプロダクトとセキュリティ

プロダクトを通じて価値を提供することは、複数のステークホルダーが絡む不確実性に向き合うことを意味します。
不確実性は、内的・外的に関わらず絶え間なく変化し続け、その変化の幅・スピードはあがるばかりです。
また、マルチプロダクトから始まる新興プロダクトも近年では見られるようになってきています。
プロダクトを支えるにあたって、プロダクトにおける情報セキュリティも原則に従いつつ、常に最善手を変化させていく必要があります。
本講義では、プロダクトの価値を確保するにあたって取り組むべき要素や、変化し続けるにあたってみるべき姿勢・指標をハンズオン等で提供したいと思います。

Transcript

1. @ken5scal, 2023/08/09 B5: 適応し続ける プロダクトとセキュリティ
2. 今年のBクラス • Webプロダクトセキュリティへのいざない • 開発プロセスを攻撃者の視点で捉える • クラウドネイティブセキュリティの実践と戦略 • Webサービスにおける安全な認証とID連携の実装 • ソースコード解析によるWebアプリケーションの脆弱性調査 • Policy as Code入門 • 適応し続けるプロダクトセキュリティ
3. • Webプロダクトセキュリティへのいざない • 開発プロセスを攻撃者の視点で捉える • クラウドネイティブセキュリティの実践と戦略 • Webサービスにおける安全な認証とID連携の実装 • ソースコード解析によるWebアプリケーションの脆弱性調査 • Policy as Code入門 • 適応し続けるプロダクトセキュリティ 今年のBクラス
4. なんか、フワッとしている!!
5. あくまでもとっかかりに • 最適解は、 以下の状況によって変わります • 組織の採用方法、組織の状況、既にいる人等 • 変化に適応するための引き出しを、様々な入出力からつくるのが大事です • インプット: 書籍、先輩、隣のインストラクターや受講者等 • アウトプット: 業務、OSS、研修、執筆等 • 本講義をとっかかりとして使ってくれると嬉しいです。 • それで、「俺が（多分）正しい」という根拠のない自信を持てるようになると 最高です。
6. 自己紹介 • @ken5scal（鈴木研吾） • LayerX（本業） • デジタル庁（副業） • 個人活動「Secure旅団」 • 定期刊行: 忙しい人のためのセキュリティ・インテリジェンス • PodCast: Secure Liaison • 著作・翻訳・監訳: ゼロトラストネットワーク等
7. すべての経済活動を、デジタル化する LayerX
8. すべての経済活動を、デジタル化する LayerX 横断部門（人事、広報、経営管理、セキュリティ・SRE・情シス） • 横断的なセキュリティ・システムの運営 • 資産の証券化・小口化金融商品化 • 資産運用の効率化
9. よろしくお願いします!
10. アジェンダ • どのような変化が身の回りにあるか • なにが変化をもたらすのか • 変化が起こると自分の身に何がおこるのか • プロダクトはどのような影響を受けるのか • セキュリティのポジションはどうすべきなのか • どのように実現していくのか
11. どのような 「変化」があるか
12. Workshop: その1 • 直近（数日〜数ヶ月）のみなさんが肌で感じた変化 • その変化に対して何をしたか、それは何故か • しないという決めも１つのアクション！ • 思考5分 + （任意・指名）発表５分
13. Workshop: 例「ブランドリニュアール対応」
14. Workshop: その1 • 直近（数日〜数ヶ月）のみなさんが肌で感じた変化 • その変化に対して何をしたか、それは何故か • しないという決めも１つのアクション！ • 思考5分 + （任意・指名）発表５分
15. 例: セキュキャン Bクラス
16. 2020~2021年分のBクラス • インフラ系 • クラウド時代における分散Webシステムの構成とスケーリング（2020) • つくって学ぶ、インターネットのアーキテクチャと運用(2020, 2021) • 分散アーキテクチャ時代におけるWebシステムの開発と運用 (2021) • L7プロトコル・Webブラウザ系 • マクロな視点から捉える Web セキュリティ(略) (2020) • ちいさなWebブラウザを作ってみよう(2021) • デジタルID系: • Digital ID Era: The important parts (2021) • バグハンティング系 • Learn the essential way of thinking about vulnerabilities through post- exploitation on middlewares (2020) • 趣味と実益のための著名なOSSライブラリ起因の脆弱性の探求 (2021) • その他 • Real World Security (2020)
17. 2022~2023年分のBクラス • コンプライアンス・ガバナンス系 • Policy as Code (2022, 2023) • アジャイル開発系 • モダンな開発環境のセキュリティおよびCI/CDパイプラインのセキュア化 (2022) • ソフトウェアサプライチェーンセキュリティのこれから(2022) • マイクロサービス/分散モノリス的アーキテクチャへの攻撃手法(2022) • Webプロダクトセキュリティへのいざない(2023) • 開発プロセスを攻撃者の視点で捉える(2023) • クラウドネイティブセキュリティの実践と戦略 (2023) • Webサービスにおける安全な認証とID連携の実装 (2023) • 適応し続けるプロダクトとセキュリティ(2023) 技術的要素をある程度継承しつつ、 「プロダクト開発」をコアにしている
18. 例: 業務環境
19. エンタープライズにおける環境変化 • ~2005: 顧客管理といった特定の機能に特化したSaaSの増加 • 2006: よりコアなシステムのクラウド化 • 2010?: iPhoneのビジネス上での活用 • 2014: 第４スタートアップブーム • 2016: （オリンピックを起因とした）リモートワークの広がり • 2020: （コロナ禍を起因とした）リモートワークの広がり
20. 見出し 5IF
    /FFEMFTTMZ
    $PNQMFY
    )JTUPSZ
    PG
    4BB4
    4JNQMJ fi FE
    IUUQTXXXQSPDFTTTUIJTUPSZPGTBBT
21. 情報システムのSaaS化による変化 - Trusted -> Untrustedͷϒϥ΢β ΞΫηεཁ݅૿Ճ - DMZʹϦόʔεϓϩΩγΛ௥Ճ ͢Δ͜ͱͰे෼ରॲՄೳ 5SVTUFE
    6OUSVUFE
    %. Ϧόϓϩ
22. サービス環境でさえas a Serviceへ 5SVTUFE
    6OUSVUFE
    %. Ϧόϓϩ ։ൃऀ޲͚κʔϯ ౿Έ୆
23. ॏཁͳσʔλ
    0O
    αʔόʔ 社会情勢やサービスの変化に伴う業務データの分散と 経路の多様化 業務データ ϙϦγʔɾϧʔϧͷఠཁ デー タ 業務ア プリ 業務ア プリ 業務ア プリ 業務ア プリ ॏཁͳ
    σʔλ ॏཁͳ
    σʔλ ॏཁͳ
    σʔλ ॏཁͳ
    σʔλ 業務 データ 業務 データ 業務 データ 業務 データ
24. それに伴う攻撃の指向 • 管理機能がアンバンドリングされたことによる攻撃領域の増加 • JumpCloud breach traced back to North Korean state • Okta con fi rms another breach after hackers steal source code • Uber suffers data breach after attack on third-party vendor • Hackers exploiting MobileIron vulnerability | 2020-11-30 • みんな大好きソフトウェア・サプライチェーン
25. 例: LayerX
26. 決算結果の例 • 黒字から赤字へ（2020 -> 2021) • 赤字拡大 https://signal.diamond.jp/articles/-/1614 https://catr.jp/companies/4ecbc/56242
27. 当社変化の要因 = 事業ピボット • ブロックチェーン事業から、複数事業に分化 • ミッションと他社の現状、 市況（採用、ビジネス、経済）
28. 単一事業から複数事業へ • 次の特性をもつよう、事業・組織を変更 • データを中心にして「リバンドリング」できる複数プロダクトの連携 • 非連続的成長を念頭においたプロダクトの創出 • 複数プロダクトを運営できる組織構造 ॏཁͳσʔλ
    0O
    αʔόʔ 業務データ デー タ 業務ア プリ 業務ア プリ 業務ア プリ 業務ア プリ ॏཁͳ
    σʔλ 業務 データ 業務 データ 業務 データ 業務 データ
29. https://comemo.nikkei.com/n/n7332c93f50c7
30. 要は • バカスカ、プロダクトを作って導入する時代 • それに伴ってバカスカ組織が変わる組織 • それに伴ってセキュリティのあり方も変わる時代
31. 変化の構造
32. 先の例は「システム」（系） • 情報システムも、セキュキャンも、当社も「システム」 • システムとは、「何かを達成するように一貫性を持って組織されている、相互につ ながっている一連の構成要素」 • 単なる「集合」ではなく、次のような構成要素を持つ • 要素 • 相互のつながり • 機能 / 目的 ʮ ੈք͸γεςϜͰಈ͘ ― ͍·ى͖͍ͯΔ͜ͱͷຊ࣭Λ͔ͭΉߟ͑ํʯ 講義 内容
33. （再掲）2022~2023年分のBクラス • コンプライアンス・ガバナンス系 • Policy as Code (2022, 2023) • アジャイル開発系 • モダンな開発環境のセキュリティおよびCI/CDパイプラインのセキュア化 (2022) • ソフトウェアサプライチェーンセキュリティのこれから(2022) • マイクロサービス/分散モノリス的アーキテクチャへの攻撃手法(2022) • Webプロダクトセキュリティへのいざない(2023) • 開発プロセスを攻撃者の視点で捉える(2023) • クラウドネイティブセキュリティの実践と戦略 (2023) • Webサービスにおける安全な認証とID連携の実装 (2023) • 適応し続けるプロダクトとセキュリティ(2023)
34. Bクラス内容変化の要因（推測） • 内的要因 • プロデューサーの変更 • 「高度な技術」の定義見直し • 外的要因 • 過去のセキュリティ・インシデント • 新技術の登場 • 上部組織の構造 ※これは要因を探るためのブレストという意図であげています
35. セキュキャン講義内容というダイナミックなシステム B 講義 内容 B, R プロデューサー 選出 セキュリティ インシデント 予算 外部 サービス 運営 R, B
36. 変化するシステムが直面する困難・複雑性 • 非線形 • 複数の境界線 • 限定合理性 • タイムスパンの違い • ブラックボックス性 ʮ ੈք͸γεςϜͰಈ͘ ― ͍·ى͖͍ͯΔ͜ͱͷຊ࣭Λ͔ͭΉߟ͑ํʯ
37. 変化するシステムが直面する困難・複雑性 • 非線形 • タイムスパンの違い • 複数の境界性 • 限定合理性 • ブラックボックス性 ʮ ੈք͸γεςϜͰಈ͘ ― ͍·ى͖͍ͯΔ͜ͱͷຊ࣭Λ͔ͭΉߟ͑ํʯ 未来の予測が困難!!
38. https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm 適応しなければ生き残らない
39. https://www.cbinsights.com/research/report/startup-failure-reasons-top/ どのような失敗要素を迎えるのか
40. 予測困難な状況で プロダクトが生き残るには
41. プロダクト開発における変化への対応とは？ • 予測困難 ≒ Getting Things Doneまでの不確実性が高い • 変化のベクトルも同様にわからない • しかし、 徐々に不確実性を減らさなければならない • 短期間のフェーズにわけ、機動的にサイクルを回す • ボトルネックを解消しなければならない ϓϩδΣΫτͷຊ࣭ͱ͸ͳʹ͔ - https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/
42. 不確実性が高いとは？ • ボラティリティ、リスクがあること • マーケットフィットしないリスク • 間違った施策を取るリスク • 採用に失敗するリスク • 投資では、余剰資産の確保と複数のリスク性のある商品に 投資することが基本 • 組織では、実績・信頼の貯蓄と、新たな領域の発見により、 生存していく https://amzn.asia/d/bJOOq06
43. 不確実性に対処し、システムが取得すべき特性 • 複雑化: • 自己を複雑化することで、学習・多様化し能力を得ること • システム自体が新しいシステム（構造・行動）を作り出せること • ヒエラルキー: • 部分的なシステムと全体的なシステムのバランスを取ること • バランス: 自由、責任、使いやすさ • レジリエンス: • 脆さ・硬直せずに、変動のある環境の中で持続性を持つこと ʮ ੈք͸γεςϜͰಈ͘ ― ͍·ى͖͍ͯΔ͜ͱͷຊ࣭Λ͔ͭΉߟ͑ํʯ
44. 要は • システムの変化に対処するため、プロダクト及び組織自体の変化がこれまで にない速さで行われる、ということ • （再掲）バカスカ、プロダクトを作って導入する時代 • （再掲）それに伴ってバカスカ組織が変わる時代 • （再掲）それに伴ってセキュリティのあり方も大変になる変わる時代
45. • プロダクトを複数事業に分化し、SaaSに預けていた業務機能をリバンドリングす ることを意識した事業を複数作った • 一方、単純にリバンドリングすると従来の職能という箱単衣で使い勝手が悪いまま • データを中心に横串の機能でリバンドリングできるようにした • それにあわせて組織体制や採用戦略を買えた 例: LayerXプロダクトのダイナミック・ケイパビリティの獲得 https://comemo.nikkei.com/n/n7332c93f50c7
46. 例: LayerXにおけるキャッシュフロー管理の繊維 https://signal.diamond.jp/articles/-/1614
47. 中間ポイント
48. Workshop: その２ • 事業会社の「セキュリティ」に携わるときに考慮すべきポイント • ガバナンス、規制・コンプライアンス・監査、文化形成、教育・訓練、リスク管理 • 予算管理 • SOC、(C/P)SIRT、IAM • DevSecOps, クラウドネイティブセキュリティ、認証とID連携、脆弱性、PaC • 想定シチュエーション • そこそこWebプロダクトが普及し始めている • 小規模（50人~100人） • 目標・評価は半年毎 • 上司はCTO • もし自分が最初のセキュリティ人材であれば、何をどこまでやる？ • 思考10分〜１５分
49. １人のセキュリティ人材 が体験してきた変化と その対応
50. 体験してきた変化 - 外部編 • IaaSクラウド化 -> IaaSマルチクラウド化 • コンパウンドスタートアップ • LLM • コロナ　※個人的には大きなインパクトがなかった
51. 体験してきた変化 - 外部編（規制編） ʮ ੈք͸γεςϜͰಈ͘ ― ͍·ى͖͍ͯΔ͜ͱͷຊ࣭Λ͔ͭΉߟ͑ํʯ • （世界的なFintech潮流を受けた） • 2017年の銀行法等の一部を改正する法律 • （マネロン対策の国際協調の潮流を受けた） • 2018年のeKYCを認めた犯罪収益移転防止法 • （世界的な以下略）2021年の個人情報保護改正 • （世界的な以下略）2023年の電気通信事業法改正
52. 体験してきた変化 - 内部編 • 入社１年でブロックチェーン・ビジネスからのピボット • LLM事業立ち上げ • プロダクト・マーケット・フィットしない中での乱 ・大量離職 ※現職以前の話もあります
53. 変化に応じて行った対応 • 個人情報保護の主担当として組織体制、規程作成、委員会、教育をする • 実際の実装担当から 基準作成、管理者にコミットさせる役割を担う • 新しいサービスのリスクを考える • eKYCのシステム要件整理と実装 • 銀行APIとOAuth2.0の仕様把握 • 全体的なガードレールの実装（必要に応じた自前機能の実装） • 等など
54. 国外 規制元B 規制元A 所属企業 ॴଐઌ 別部署 別部署 別部署
55. プロダクト運営に置いて求められるセキュリティ SANS CISO MIND MAP: ݱࡏ͸404 • ガバナンス • 規制・コンプライアンス・監査 • 文化形成 • 教育・訓練 • リスク管理 • 予算管理 • SOC • (C/P)SIRT • IAM • 要は色々 • おそらくどこでも、少人数で回している
56. セキュリティ人材が置かれる現実 • プロダクトの戦略は割りと変わる • 突発的にやりたいことがでてくる • 新しい技術を使いたくなってきたりする • 新しいシステムがどんどん増える・減る・変わる • 直接的に売上には関われないので、意識的に立ち回らない限り、プロダクト をリアタイでみれない • でも変化についていかなければならない • Etc
57. プロダクト開発におけるセキュリティの役割 • ボトルネックにならない • 相談されるようになる • 負けに不思議の負けなし、やるべきことをやる • が、全てが必要・実現できるわけではない • 「安全に“セキュリティを緩める”ことがCISOとしての役割」 • どの程度のリスクであれば許容可能か判断する • あるいはその基準、判断方法を提供する https://enterprisezine.jp/article/detail/17933 • ※組織構造による
58. （再掲）プロダクト運営に置いて求められるセキュリティ SANS CISO MIND MAP: ݱࡏ͸404 • ガバナンス • 規制・コンプライアンス・監査 • 文化形成 • 教育・訓練 • リスク管理 • 予算管理 • SOC • (C/P)SIRT • IAM • おそらくどこでも、少人数で回している • 大事なのは少しずつ進めること
59. Cybersecurity Framework(CSF) • NIST: 米国立標準技術研究所 • 重要インフラを扱う企業・組織のサイバーリス クの管理を支援するための、リスクベース・ア プローチに基づく汎用的なFW • ３要素から成り立つ(Core、Tier、Pro fi le) https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
60. CSF Core https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
61. Core IUUQTOWMQVCTOJTUHPWOJTUQVCT$481/*45$481QEG
62. Tier
63. Pro fi le
64. IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 特化しすぎだと変化に対応しきれない リスク 管理
65. ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 徐々に積層化していく リスク 管理 IAM
66. ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 徐々に積層化していく リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM
67. ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 徐々に積層化していく リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM
68. ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 徐々に積層化していく リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM
69. 変化に伴って、考慮できてなかったFWも見えてくる https://www.cisa.gov/zero-trust-maturity-model https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
70. ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 たまに横に広げる リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 IAM 脆弱性 管理 脅威 分析 SBOM
71. IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 脅威 分析 脆弱性 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SOC SIRT 予算 管理 リスク 管理 脅威 分析 脆弱性 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SIRT 予算 管理 リスク 管理 脆弱性 管理 IAM ガバナ ンス 規制 コンプラ 分化 形成 教育 訓練 SIRT 予算 管理 リスク 管理 脆弱性 管理 IAM ガバナ ンス コンプラ 分化 形成 教育 訓練 SIRT 予算 管理 脆弱性 管理 IAM ガバナ ンス コンプラ 分化 形成 予算 管理 脆弱性 管理 IAM コンプラ 分化 形成 予算 管理 脆弱性 管理 IAM コンプラ 予算 管理 脆弱性 管理 実際はこう
72. どのように層を 重ねるのか、 広げるのか
73. 深化 • 勝ちパターンや強みを維持・向上する • 専門的な領域の深掘り、磨き込みをする • 効率性を重視し、適切な評価と管理で、構造化する • 信頼を獲得するフェーズ
74. 探索 • 新しい機会を感じとることで、生存のための選択肢 を増やす • 多様性を増やすフェーズ • 細かい仮説と実証、実験と機敏さを重視する • 不確実な未来に備えるために、成長・瞬発力を得る
75. T • 韮ともいう（LayerX限定） • T/韮そのものよりも、次が大事 • 確固たる軸を確実に築く • 効果的な探索の仕方を自分なりに見つける
76. 深化の仕方 • 継続的に深める • 一日一つ強くなる（ウメハラ: プロゲーマー） • 確実に責務を果たす • コトに向かう力（南場智子 : 株式会社ディー・エヌ・エー代表取締役会長 ) • コントロール出来るところに集中する • 納期を守る • ルーティンワークをこなす • 説明責任を果たす • 情報をアウトプットする
77. 探索の仕方 • 自分の活動できる時間の20%を余暇に確保する • 全く別領域に手を出してみる • 同領域の知らない階層に足を伸ばす • コトに向かいながら落ちてるボールを拾う • 流行りにとりあえず乗る
78. 探索にかかるコストに向き合うために • 1年以上繰り返しやっている業務を減らす • 委譲と委譲と委譲 • 採用と採用と採用
79. 探索と深化のバランス • 深化をしない場合 • 専門値が深まらない • 信頼貯金が貯まらない • 探索しない場合 • サクセストラップに陥る • プロダクト組織における落ちたボールが永遠に落ちている（セキュリティ 的にはガバナンスに漏れ） • どのように探索と深化を両立するか？
80. 具体と抽象の反復
81. セキュリティ実務という具体と事業存続という抽象 • プロダクト組織内のセキュリティは非機能要件でありコストセンター • だからといって、何ら気にする必要はない。 • ただの役割の違いであり、それによって異なるKPIがあるのは必然 • いくらなんのために使い、どれぐらいの効果があるかを説明する責任はあ る（アカウンタビリティ） https://signal.diamond.jp/articles/-/1614
82. 普段消費する「キャッシュ」の抽象化 • 何をもって自分たちの施策は健全なアクセルを踏んでるといえるのか • キャッシュフロー: 会社を出入りするお金。 事業体 売上、手数料 Equity, debt 給与、税金 システム費、 マーケ費 投資
83. 普段消費する「キャッシュ」の抽象化 • 何をもって自分たちの施策は健全なアクセルを踏んでるといえるのか • キャッシュフロー: 会社を出入りするお金。 事業体 売上、手数料 Equity, debt 給与、税金 システム費、 マーケ費 投資 営業CF: - 本業の収入と支出 - マイナスだと潰れる
84. 大事なCFにおける指標 • Burn = 毎月どれぐらいの現金が減るか • 先月の現預金 - 今月の現預金 • 健全と言われるベンチャーの水準 -> ARR規模のBurn Multiple • Burn Multiple = 月のBurn / 月の新規ARR • Burn Multipleが < 1だと OK~Good • Runway = 今の会社の状態が続く場合、何ヶ月会社が継続するか • 現預金 / Burn • 健全と言われるベンチャーの水準: 1.5年~2年　（18ヶ月~24ヶ月） https://twitter.com/kenichiro_hara/status/1528954522101755904
85. OSSにおける具体と抽象: Policy As Code https://atmarkit.itmedia.co.jp/ait/articles/0204/19/news003.html 内部統制的なポリシー （こっちの話） CNCF的なポリシーは 一般的にはガイドライン やプロシージャ • 内部的統制的な意味でのポリシーは基本的に、自 然言語によるドキュメンテーションである • そのポリシーは（下位文書であるスタンダードやプ ロシージャに沿った）実装や対策と論理的に矛盾し ていてはならない • また、その繋がりを証明可能・監査可能な状態にし て説明責任を果たさねばならない • ただ、現在のポリシー、実装・対策までの統制には 実効性や運用において課題がある • 類似する複数の規制の存在と、それに伴う矛盾 や管理の複雑さ • 上位規制の更新にあわせた各種統制の更新 • 情報システム自体の複雑性の増加 • これらに伴うペーパーワークの工数増大 法令 業界標準
86. https://engineering.mercari.com/en/blog/entry/20220203-defense-against-novel-threats-redesigning-ci-at-mercari/ 未知の脅威に対抗するメルカリのCI再設計 • CIの技術コンプライアンス要件を Platformチームと協力して策定 • コンプライアンス準拠と開発者体験の 指標をミックスし、それを両立しうる PoCを公開
87. Policy as Code • Open Policy Agent • 講義にあったので割愛 • OSCAL: Open Security Controls Assessment Language • 情報システムのセキュリティ対策（Control）を定義し、それに基づいて評 価するための標準化されたデータ中心の評価フレームワーク • Machine-readableな表現による脱メタ認知システム • 法規制・フレームワークなどハイレベルな要件と実装のトレーサビリティを 確保
88. $POUSPM
    -BZFS $POUSPM
    -BZFS *NQMFNFOUBUJPO
    -BZFS "TTFTTNFOU
    -BZFS
89. " catalog": { "uuid": "fa8f6772-40a9-4976-b7fd-e95c5b9ee037", "metadata": { "title": " FedRAMP Rev 4 Low Baseline", "published": "2021-02-05T00:00:00.000-04:00", "last-modified": "2021-10-13T18:23:58.261729Z", "version": "fedramp1.1.0-oscal1.0.0", "oscal-version": "1.0.0", "links": [ { "href": "FedRAMP_rev4_LOW-baseline_profile.xml", "rel": "resolution-source" } ], "roles": [ { "id": "prepared-by", "title": "Document creator" }, { "id": "fedramp-pmo", "title": "The FedRAMP Program Management Office (PMO)", "short-name": "CSP" }, { "id": "fedramp-jab", "title": "The FedRAMP Joint Authorization Board (JAB)", "short-name": "CSP" } ], "parties": [], "responsible-parties": [] }, " groups": [ { "id": "ac", "class": "family", "title": " Access Control", "controls": [ { "id": "ac-1", "class": " SP800-53", "title": "Access Control Policy and Procedures", "params": [ { "id": "ac-1_prm_1", "label": "organization-defined personnel or roles" }, { "id": "ac-1_prm_2", "label": "organization-defined frequency", "constraints": [ { "description": "at least every 3 years" } ] }, { "id": "ac-1_prm_3", "label": "organization-defined frequency", "constraints": [ { "description": "at least annually" } ] } ], "props": [ { "name": "CORE", "ns": "https://fedramp.gov/ns/oscal", "value": "true" }, { "name": “label", "value": "AC-1"}, { "name": “sort-id", "value": "ac-01"} ], "links": [ུ], "parts": [ { "id": "ac-1_smt", "name": "statement", "prose": "The organization:", "parts": [ { "id": "ac-1_smt.a", "name": "item", "props": [ { "name": "label", "value": "a." } ], "prose": "Develops, documents, and disseminates ུ:", "parts": [ { "id": "ac-1_smt.a.1", "name": "item", "props": [ { "name": "response-point", "ns": "https://fedramp.gov/ns/oscal", "value": "ུ" }, { "name": “label”, "value": "1." } 89
90. " profile": { "uuid": "8742196d-86ba-4e72-a411-28867dab43bb", "metadata": { "title": "NIST Special Publication 800-53 Revision 5 LOW MPACT BASELINE", "last-modified": "2021-06-08T13:57:33.97549-04:00", "version": "Final", "oscal-version": "1.0.0", "roles": [ { "id": "creator", "title": "Document Creator" }, { "id": "contact", "title": "Contact" } ], "parties": [ { "uuid": "984e6c07-b5b6-4ab6-b22b-283609c325e6", "type": "organization", "name": "Joint Task Force, Transformation Initiative", "email-addresses": [ "sec-cert@nist.gov" ], "addresses": [ { "addr-lines": [ "National Institute of Standards and Technology", "Attn: Computer Security Division", "Information Technology Laboratory", "100 Bureau Drive (Mail Stop 8930)" ], "city": "Gaithersburg", "state": "MD", "postal-code": "20899-8930" } ] } ], "responsible-parties": [ { "role-id": "creator", "party-uuids": [ "984e6c07-b5b6-4ab6-b22b-283609c325e6" ] }, { "role-id": "contact", "party-uuids": [ "984e6c07-b5b6-4ab6-b22b-283609c325e6" ] } ] }, " imports": [ { " href": "NIST_SP-800-53_rev5_catalog.xml", "include-controls": [ { "with-ids": [ " ac-1", " ac-2", " ac-3", " ac-7", “ུ” ] } ] } ], "merge": { "as-is": true } } } 90
91. { " component-definition": { "uuid": "a7ba800c-a432-44cd-9075-0862cd66da6b", "metadata": { "title": "MongoDB Component Definition Example", "last-modified": "2001-08-26T23:11:47Z", "version": "20210826", "oscal-version": "1.0.0", "roles": [{"id": "provider","title": "Provider"}], "parties": [ { "uuid": "ef7c799a-c50e-49ab-83e0-515e989e6df1", "type": "organization", "name": "MongoDB", "links": [ { "href": "https://www.mongodb.com", "rel": "website" }]}] }, " components": [ { "uuid": "91f646c5-b1b6-4786-9ec3-2305a044e217", "type": "software", "title": "MongoDB", "description": "MongoDB is a source-available, cross-platform document- oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas.", "purpose": "Provides a NoSQL database service", "responsible-roles": [ { "role-id": "provider", "party-uuids": [ "ef7c799a-c50e-49ab-83e0-515e989e6df1" ] } ], "protocols": [ { "uuid": "2b4a1b3a-cbc5-4cc8-bde6-7437c28c4e54", "name": "mongodb", "title": "Primary daemon process for the MongoDB system.", "port-ranges": [ { "start": 27017, "end": 27017, "transport": "TCP" } ] }, { "uuid": "99d8d4e5-e734-4e05-a2f9-7353097b8b61", "name": "mongodb-shardsrv", "title": "MongoDB protocol for sharding with shardsrv option.", "port-ranges": [ { "start": 27018, "end": 27018, "transport": "TCP" } ] }, { "uuid": "6fa762f1-09ca-44d5-a94c-cfceb57debd5", "name": "mongodb-configsvr", "title": "MongoDB protocol for configsrv operation.", "port-ranges": [ { "start": 27019, "end": 27019, "transport": "TCP" }]} ], "control-implementations": [ { "uuid": "49f0b690-ed9f-4f32-aae0-625b77aa6d27", "source": "https://github.com/usnistgov/oscal-content/blob/master/ nist.gov/SP800-53/rev5/xml/ NIST_SP-800-53_rev5_LOW- baseline_profile.xml", "description": "MongoDB control implementations for NIST SP 800-53 revision 5.", "implemented-requirements": [ { "uuid": "cf8338c5-fb6e-4593-a4a8-b3c4946ee2a0", "control-id": "sc-8.1", "description": "MongoDB supports TLS 1.x to encrypt data in transit, preventing unauthorized disclosure or changes to information during transmission. To implement TLS, set the PEMKeyFile option in the configuration /etc/ mongod.conf to the certificate file's path and restart the the component." }, { "uuid": "cf8338c5-fb6e-4593-a4a8-b3c4946ee2a0", "control-id": "sa-4.9", "description": "Must ensure that MongoDB only listens for network connections on authorized interfaces by configuring the MongoDB configuration file to limit the services exposure to only the network interfaces on which MongoDB 91
92. 行政
93. Executive Order on Improving the Nation’s Cybersecurityのメッセージ • 米大統領令14028のSec. 3. Modernizing Federal Government Cybersecurity. • (ii) improving communication with CSPs through automation and standardization of messages at each stage of authorization. • (iii) incorporating automation throughout the lifecycle of FedRAMP, including assessment, authorization, continuous monitoring, and compliance; https://enterprisezine.jp/article/detail/17933
94. ソフトウェアdefinedなシステムが最初のサブDocとなる • NIST SP800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments • CNCFが定義するクラウドネイティブ技術に よって、「回復性、管理力、および可観測性 のある」疎結合システムが実現される。 • ZTAで著名なNIST SP800-207の最初 の例として示唆的と考える https://enterprisezine.jp/article/detail/17933
95. クラウド環境とソフトウェア開発・運用を前提としている • “CICD is a key (略) that integrates security and automation” • すでにクラウド環境・アジャイルガバナンス を環境と定め、ソフトウェア開発・運用が必 須と捉えている節がある。 • その前提で、継続的な開発・運用に欠かせな い業務システムにおけるセキュリティガイダ ンスをリリースしている。 https://enterprisezine.jp/article/detail/17933
96. ガバナンス組織による支援ツールの提供 • CISAによる積極的なツール開発・公開 • OSINTからRedチーム、M365監査まで https://enterprisezine.jp/article/detail/17933
97. デジタル庁 • ゼロトラストアーキテクチャ適用における 属性ベースアクセス制御に関する技術 レポート https://www.digital.go.jp/assets/contents/node/basic_page/ fi eld_ref_resources/f9f14968-6dd3-41dc-a97f-047618caf73c/8159607c/ 20230324_policies_development_management_outline_03.pdf
98. まとめ • プロダクトを取り巻く状況は常に変化する • 変化はダイナミックであり予測困難である • プロダクトが取れる手段は変化に素早く適応することである • セキュリティ人材がそのボトルネックとならない事が重要 • 深化により専門値の深掘りをし、探索で未知のことに手をだし、変化に強く なる • 具体と抽象の反復により、深化と探索を両立していく https://signal.diamond.jp/articles/-/1614
99. So, you want to work in security?
100. https://www.freecodecamp.org/news/so-you-want-to-work-in-security-bc6c10157d23 (຋༁)https://ken5scal.hatenablog.com/entry/ 2017/07/19/%28%E7%BF%BB%E8%A8%B3%29%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82 3%9F%E3%81%84%E3%81%9F%E3%81%84%E4%BA%BA%E5%90%91%E3%81%91%E3%81%AE%E5%BF%83 So, you want to work in security? • 完全もしくは標準的なカリキュラムなどない • 手を動かせ。実践しろ。 • コードを書け • コードを壊せ • 知識を共有しろ • コミュニケーションを怠るな • 辛いことも失敗もある • 助けを求めよう
101. Good luck and happy hacking!