Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
転生CISOサバイバル・ガイド / CISO Career Transition Surviv...
Search
Hokuto Hoshi
February 18, 2025
Technology
2
380
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
Hokuto Hoshi
February 18, 2025
Tweet
Share
More Decks by Hokuto Hoshi
See All by Hokuto Hoshi
Connecting organisation with Technology
kanny
0
210
Why Slack - 5 years of Cookpad with Slack
kanny
0
86
Security by builders - セキュリティ監視をクラウドで「つくる」 / Security by builders
kanny
7
2.7k
セキュリティ担当者から見た re:Invent と AWS Security Hub / Impression of re:Invent and AWS Security Hub
kanny
2
4.2k
自由でセキュアな環境のつくりかた / Building free and secure cloud environment
kanny
1
4.9k
事例でわかる、AWS 運用を支える サポート活用方法と エンタープライズサポートという選択 / AWS Enterprise Support and Cookpad
kanny
2
2.5k
AWS で加速する機械学習 / Accelerate Machine Learning with AWS
kanny
1
1k
クックパッドのログをいい感じにしているアーキテクチャ / Logging architecture at Cookpad
kanny
23
15k
クックパッドの機械学習を支える基盤のつくりかた / Machine Learning ops at Cookpad
kanny
4
8.7k
Other Decks in Technology
See All in Technology
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
120
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
100
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1k
生成AIの利活用を加速させるための取り組み「prAIrie-dog」/ Shibuya_AI_1
visional_engineering_and_design
1
140
【Developers Summit 2025】プロダクトエンジニアから学ぶ、 ユーザーにより高い価値を届ける技術
niwatakeru
2
890
AndroidXR 開発ツールごとの できることできないこと
donabe3
0
110
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
6
1k
管理者しか知らないOutlookの裏側のAIを覗く#AzureTravelers
hirotomotaguchi
1
240
開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience
kaminashi
0
190
10分で紹介するAmazon Bedrock利用時のセキュリティ対策 / 10-minutes introduction to security measures when using Amazon Bedrock
hideakiaoyagi
0
170
2.5Dモデルのすべて
yu4u
2
610
AWSでRAGを実現する上で感じた3つの大事なこと
ymae
3
1k
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
540
It's Worth the Effort
3n
184
28k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
For a Future-Friendly Web
brad_frost
176
9.5k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Adopting Sorbet at Scale
ufuk
74
9.2k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.4k
The Invisible Side of Design
smashingmag
299
50k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
© LayerX Inc. 転⽣ CISO サバイバル‧ガイド Hokuto Hoshi CISO, Head
of DevOps and Corporate Engineering, LayerX Inc.
[email protected]
2025/02/18
© LayerX Inc. 2 $ whoami • 株式会社LayerX 部⾨執⾏役員 CISO
兼 コーポレートエンジニアリング室 室⻑ 兼 バクラク事業部 PlatformEngineering 部 DevOps グループマネージャー • 料理レシピサービスのセキュリティエンジニア、SRE、 コーポレートエンジニア、新規事業開発、監査補助など を経験し、2020年からイギリス⽀店出向、2023年に CTO 兼 CISO。2024年1⽉より現職 星 北⽃ (HOSHI, Hokuto)
© LayerX Inc. 3 • as CISO ◦ 全社の情報セキュリティの統括、戦略を描きながら実際の対策まで ◦
ポリシー、社内情報システム、プロダクトセキュリティ ◦ インシデントレスポンス • as コーポレートエンジニアリング室 ◦ 全社のITファシリティおよび情報システムの統括 ◦ PC, ネットワーク, オフィス機器, SaaS, ディレクトリ, etc • as DevOps グループマネージャー ◦ バクラク事業の技術基盤 (サービスインフラ, CI/CD をはじめとした開発基盤) のリード • ざっくり⾔うと「サービスを直接開発する以外の技術領域だいたい全部」が守備範囲 普段やっていること
LayerX について
5 © LayerX Inc. すべての経済活動を、デジタル化する。 会社概要 会社名 株式会社LayerX(レイヤーエックス) 代表取締役 代表取締役CEO 福島
良典 代表取締役CTO 松本 勇気 創業 2018年 8⽉1⽇ 資本⾦ 約132.6億円 拠点 東京本社 〒104-0045 東京都中央区築地1-13-1 銀座松⽵スクエア 5階 関⻄⽀社 〒530-0002 ⼤阪府⼤阪市北区曽根崎新地1-13-22 御堂筋フロントタワー 内 中部⽀社 〒466-0064 愛知県名古屋市昭和区鶴舞1-2−32 STATION Ai 内 九州⽀社 〒810-0801 福岡県福岡市博多区中洲3-7-24 WeWorkゲイツ福岡 11F 内 従業員数 385名 (2024年10⽉末時点)
6 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、AI SaaSとAI DXの事業を展開 事業紹介 バクラク事業 企業活動のインフラとなる業務を
効率化するクラウドサービス Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 社内のナレッジやノウハウをデータ ベース化するAIプラットフォーム AI SaaSドメイン AI DXドメイン
© LayerX Inc. 7 • スタートアップとして早い段階からセキュリティにも投資 ◦ ブロックチェーンなど⾦融に関係する事業領域も影響 ◦ バクラク事業開始
(2021年) 以前よりセキュリティ担当者をおく • 2024年1⽉に星が⼊社、2024年12⽉に1名⼊社 ◦ 発表時点で 2 (AI SaaS ドメイン) + 1 (AI DX ドメイン) = 3名 LayerX と情報セキュリティ
セキュリティロードマップ?
© LayerX Inc. 9 Timeline View 便利
© LayerX Inc. 10 • 取り組むことの⽬標を明確にするため • どの順番で何に取り組むべきか、段階的な計画を整理するため • ステークホルダーと共通認識を持つため
• リスクを想定し、評価するため • 進捗を管理するため • etc… なぜ⼈はロードマップをつくるのか
© LayerX Inc. 11 • ⻑期 (数年単位) のロードマップはあまりそぐわない (※個⼈の⾒解です) ◦
どんどん変化する事業計画やプロダクト、組織 ▪ 事業だけでなく共通機能への期待も変わる ▪ リソースも潤沢でなく、またかけられるコストが変動する ◦ 事業環境、外的環境の変化 ◦ そもそもセキュリティ機能がなく「まず0を1にするところから」という場合もある • ⼀定の「未来の⾒通し」は必要 ◦ 直近1.5年くらいで取り組むこととその順序 ◦ 準備に時間がかかるもの (各種認証など) ◦ ⼈材の採⽤ (= 組織として獲得すべき能⼒) スタートアップとセキュリティロードマップ
転職してきたセキュリティマネージャーが、 “未来の⾒通し” を⽴てられるようになるまで
© LayerX Inc. 13 • 知識や最近の動向キャッチアップについては⼤前提 ◦ 事業会社がセキュリティ組織を持つ⼤きな価値は「判断」ができること ◦ 判断のもとの⼀つになるのが知識や最近の動向
• 事業に対する理解 ◦ 「事業が何をしているか」といった⼤雑把な話ではなく、「事業がどのような流れで成⽴し ているか」をしっかり把握する ◦ お客様を理解する。どういった業界か、どのような⼈がいるのか、コミュニケーションのス タイル、選定において気をつけているポイント、etc • 組織に対する理解 ◦ 組織構造や、「この⼈に聞けば何かが進む」という⼈を⾒つける • 同僚との信頼関係 ◦ セキュリティに関する相談が舞い込んでくる状態を⽬指す ◦ 「この⼈は、⼀緒に事業課題を解決してくれる」と思ってもらうことが⼤切 セキュリティの “未来の⾒通し” に必要なこと
© LayerX Inc. 14 • 事業に対する理解度がなくなる • 組織に対する理解度がなくなる • 「歴史」がわからなくなる
◦ ある意思決定 (施策) が⾏われた背景 ◦ 過去の取り組み ▪ ドキュメントによって補完可能だが、「⾃分で判断したこと」に対する感覚と異なる • 社内における信頼関係がなくなる ◦ 「前職でこういうことをやってた⼈」 ◦ 知り合いも多少いたので完全なゼロではなかったのは救い 転職するとどうなるか できる限り早い段階で乗り越え、信⽤してもらうことをゴールにする
⼿を動かし ⽿を傾け ⾜を運ぶ
© LayerX Inc. 16 • ⾃部署のメンバーだけでなく、他部署のメンバー、マネージャー、営業など ◦ ミーティングでも良いしランチでも良い • それぞれの同僚のやっていること、得意なことなどを教えてもらう
◦ 「◯◯のことはこの⼈に聞こう」と⾃分が思えるインデックスを構築する • セキュリティについてのヒアリングは軽くても良い ◦ いつでも聞きに来てくれる/⾏ける関係性が⼤事 まずは話す 話のネタになるような⾃⼰紹介を 持っていくとよい
© LayerX Inc. 17 • 運がよければある。なければない (幸運にもありました) • 特にあって助かった情報 ◦
チームがどう成⻑してきたのか ◦ どういった⽬標を持って活動してきたのか ◦ それまでどういった考えのもとでその判断をしていたのか • 引き継ぐまでの “積み重ね” が⼀定インストールされることで、} 何かを変える時に準備できる ◦ 歴史に沿った判断なのであれば、怖がらずに進んでよい ◦ 歴史に沿わない判断も、変更するために必要な説明のしや すさが圧倒的に違う • Thanks @ken5scal 引き継ぎを受ける
© LayerX Inc. 18 • ⾃社が展開しているサービスをとにかく触る ◦ 運営側ではなく1⼈のユーザーとして理解する • ヘルプページなどユーザー向けリソースを読む
◦ ユーザーが知るべきことが体系的にまとまっている ◦ セキュリティに関しても、何が⾃明で何がそうでないかがわかる • 事業の流れを把握する ◦ どう営業され、契約がなされ、履⾏されるのか ◦ どういう考え、要望があり、これから何をつくるのか ◦ ⼈に聞く、社内ドキュメントを読む • 守るべき事業の価値を理解できたといえるところまでやる 事業を知る
© LayerX Inc. 19 • セキュリティチェックシート100本ノックがおすすめ ◦ 回答からその後の質疑までを⼀貫して担当する ◦ 主にセキュリティの⾯から「何を気にされているのか」を考える良い機会になる
▪ 頻出だが答えられない質問はないか? ▪ よりよい答えが返せるようなところはないか? ◦ toC ビジネスから toB ビジネスにマインドを切り替えるのに⼀番役に⽴った • 商談に同席する ◦ 機会が得られれば積極的に参加すべき ◦ 難しければ録画や議事録などへのアクセスをもらう お客様を知る
© LayerX Inc. 20 • ルールなどドキュメントを把握する • (なければ) セキュリティの質問チャンネルを設けて、質問が集まるようにする ◦
LayerX の場合、もともとあったのでそこのヌシになるようにした • Slack などでセキュリティについて話しているところを⾒つけて⾸を突っ込む ◦ ⼤量のチャンネルに⼊ってキーワード登録していた ◦ ちゃんと課題が解決するように突っ込むのが⼤事 • 実際の課題に取り組んで解決していく ◦ 相談ごとの解消 ◦ ⼩さなルールなどの最適化 (プロセスを減らす、別の対策を設けて緩和するなど) ◦ 認証規格などのオペレーション影響の調査 社内の課題を解決する
© LayerX Inc. 21 • 1⼈のエンジニアとしてオンボーディングを受ける ◦ 利⽤している技術やアーキテクチャ、コードのライフサイクルを学ぶ • インフラ環境を⾒て回り、コードを読む
◦ 当然全部は⾒きれないので、気になるところ (認証, 制限など) • 過去の脆弱性診断などの情報を読む ◦ 修正のやり取りなどについて振り返っておく 技術を知る
© LayerX Inc. 22 • コスト低く修正可能なコードの修正 • インフラレイヤで特定されていたが解消しきれていなかった課題の修正 • 障害対応
• お客様の社内ネットワーク環境のトラブルシュート ◦ セキュリティに関する仕組みがネックになっていることが多い 技術課題を解決する
© LayerX Inc. 23 • ドキュメントを書く • ガイドラインを書く • 技術のアップデート情報を社内の事情に置き換えながらレポート
• 知⾒‧経験を社内に向けて発表する • 他の⼈がセキュリティに取り組むことをサポートする 発信する
© LayerX Inc. 24 普通では?
© LayerX Inc. 25 • はい • 要は「専⾨分野をもって、事業の⼀員として課題発⾒と解決にあたる」というだけの話 • 「セキュリティの判断軸がわからない」という時は、何かが⾜りてない時かも
普通では?
“未来の⾒通し” と優先度 諸説あるけど、⾃分はこうしていますという例
© LayerX Inc. 27 • 対象となるデータの重要性 ◦ 失ってはいけないデータは何か?漏らしてはいけないデータは何か? ◦ 何かあると事業を⽌めるデータか?
• 事故の起こりやすさ ◦ 全社で起こり得るものか?特定部署のみで起きることなのか? ◦ ⼈によって処理されるのか?システムによる処理か? ◦ 事故の成⽴難易度はどのくらいか? • レバレッジ ◦ (かけるコストに対して) どのくらいの規模にリーチできるのか? ◦ 組織のブレーキ機能を果たすのか?アクセルを踏ませることができるのか? ◦ 事業に明らかなインパクトがあるか? (顧客との関係など) • ここまでの話に取り組んでいれば、ある程度の解像度と芯を持って考えられるはず 優先度のつくりかた
© LayerX Inc. 28 • 対策されていない事故は、あらゆるものが常に「今」発⽣しうる ◦ あくまで可能性の問題 • 対応の順序を厳密に決めたからといって、その順に守れるわけではない
◦ 明確に差がないのであれば、腹をくくって進めてしまうほうがよい • ⼀⽅で「流⾏」は存在する ◦ 明らかな流⾏ (⼤規模な攻撃など) の兆しがあるならば優先度を上げてしまう 優先度のつかいかた
© LayerX Inc. 29 • セキュリティの管理策には、「よく知られた」フレームワークがある ◦ ISO27001 (ISMS), ISO27017
◦ CIS Controls ◦ クラウドベンダーの CSPM • リスクアセスメントの⼿法、起こりがちな事故をベースにした管理策がまとめられており使わない ⼿はない ◦ ⽬⽴ちやすい⾼度な攻撃より「ふつうのこと」で事故る可能性のほうがはるかに⾼い ◦ 資産を管理する、ログを取得する、バックアップをとる、アカウント管理... ◦ 実装もよく知られたものやサービスが多い • ここまで把握してきた現状をマップしてしまうのも良い ◦ ⼤きな変更、⽣産性への悪影響を伴うものは時期や是⾮を考える ▪ 例. 事業上の繁忙期や決算期を避ける ▪ 例. 部分的に開始して広げる 「よく知られたこと」はとっとと⽚付ける
© LayerX Inc. 30 • 相談のチャンネルを広げる ◦ 複数回以上同じ相談が来るなら、何らかの課題がある可能性が⾼い ▪ 現状のポリシーそのもの、情報の検索性など
• 事業そのものに触れ、セキュリティにつながる情報を得る ◦ 開発の状況などにフォローすべき点はないか ▪ テストの状況、レビューなど ◦ 気づかれていないリスキーな状況はないか? ◦ 事業活動はうまく回っているか?セキュリティが阻害している部分はないか? • たくさんの⼈と話す ◦ 「そういえば…」から始まる相談は多い 事業課題を常に収集する
© LayerX Inc. 31 • セキュリティに関する情報は溢れている ◦ すべてに⽬を通すのは難しい ◦ 気に⼊るニュースサイトや
Blog 、SNS などに留めても良いと思う ▪ 積読が増えて⽬が届かないよりよほど良い • 別のことに置き換えられないか考える ◦ 例: ソフトウェアの脆弱性情報を収集し、パッチを当てるかを都度判断して適⽤ -> パッチが出たらとにかく当て、リリース前のテストでキャッチする‧迅速にロールバック できるようにする 情報収集過多に気をつける
© LayerX Inc. 32 • 「セキュリティに理解がある経営」 = セキュリティに無限にお⾦を払う経営 ではない ◦
⾃分の場合は「セキュリティについて対話できる経営」 • お⾦の使いどころを⾒極めて予測する ◦ 恒久的に⽀払うコストなのか、時間を稼ぐためのコストか ◦ ⾼い90%のソリューションか、安い60%のソリューションか • 1.5年後くらいの⽀出を考えながらコミュニケーションをとる ◦ 予算を決められる⽴場なら CFO や CEO ◦ 決められない⽴場なら上⻑ コストに意識をもつ
© LayerX Inc. 33 • (特に⼩さいうちは) チームの能⼒を広げる採⽤を意識する ◦ 積まれた課題をメンバーのカバレッジで⾒た時に⼤きく⽋けている部分 ◦
誰かがカバレッジを広げるという前提ももちろんあり ◦ 複数⼈で総合格闘技を戦うことができればよい • ヘルスチェックができる指標をもつとよい ◦ 組織全体に対する⼈数割合など ◦ コストに関する考え⽅も同じ • ⼈を採⽤するには時間がかかる ◦ 1.5年の⾒通しが必要なもう⼀つの分野 チームの広げかた
© LayerX Inc. 34 • 「⽬標」レベルで良いので、プランを⽴て、⾏動し、修正する ◦ いわゆるふつうの PDCA サイクル
◦ 変更することを恐れない ▪ それ以上に事業が変わるのだから、むしろ変わらないとまずいと思うべき 以上、繰り返し
おわりに
© LayerX Inc. 36 • 事業が⼤きく変わる環境では、セキュリティへの要求も変わり続ける ◦ セキュリティも事業の⼀部なので当然のこと • 芯を持ちながら⾃ら変わり続けることで、楽しく波に乗れる
• そのための事業理解 ◦ ⼿⾜を動かし、対話をして、信頼関係を結ぶという「ふつう」の話 まとめ
© 2024 LayerX Inc. 37 We are hiring! LayerXのプロダクトメンバーと美味しいお酒やご飯を囲み ながら、プロダクトやチーム、技術の話をゆる〜く行うイベン
トを定期的に行っています。 直近の予定は以下のとおりです。 LayerX Casual Night ※原則招待制です。参加希望の方はLayerX社員へご連絡ください! LayerX Casual Night LayerX Open Door アカウント登録が一切不要なカジュアル面談を公開しています。 ・私と雑談してみたい ・質問したいことがある ・選考に進むか悩んでいる などなど、お気軽にお申し込みください。 日程 テーマ 3/19(水) 19時ごろ〜 🍻 Craft Beer Night
© LayerX Inc. Fin.