20220926_セキュリティチームの今_for_Drs._Prime_公開用.pdf

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

©10X, Inc. All Rights Reserved. to B領域におけるセキュリティ  ● Stailerにおいてはto Cの領域でセキュリティ品質が担保できていることを説明する必要がある   ● キーワード「セキュリティチェックシート」   ● エンタープライズや古株の企業は独自のセキュリティルールを内部的に持ってることが多く、それらへいかに効率よくかつ本質的な対応をしていくかが課題となる(なってる)   11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

©10X, Inc. All Rights Reserved. Stailerのセキュリティ品質にどう向き合うか  ● 正直、2022/1の当時にこれらのIssueが顕在化していたかと言われるとNo   ● 言ってしまえばTask Force的にリソースを調整してCriticalなIssueに対応したり、SREチームが兼務する形を取る、という選択肢もあった   ● が、兼務や一時的なリソースアサインは関心領域が限定的になってしまったり、取り組みがきちんと続いていかないリスクもあった   ● Stailerの事業計画＝これからのサービス拡大とパートナー増加を考えるとSmallでもいいから早めに取り組みを始めるべきと判断した   13

Slide 14

Slide 14 text

©10X, Inc. All Rights Reserved. 当時の予想＆実際のFact  ● セキュリティ品質の改善は地道でひたすらリスクの芽を整理して潰していくことが求められる足の長い取り組み  ○ そしておそらくこの取り組みはサービスが成長し続ける限り一生終わることがない  ● チームの組成があと3か月 ~ 半年遅かったら今よりもっと後手に回っている状況だった   ● 10Xの場合はセキュリティの専門家がいないという大きなハンデもあったので先手を打てたのはよかった  14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

©10X, Inc. All Rights Reserved. チームが社内にある重要性  ● セキュリティチームが社内にあることでStailerの大小さまざまなセキュリティIssueが1箇所に集約される  ● 1箇所に集約し、Ownershipを持つことで「Stailerのセキュリティなんとなくやばそう」を整理、言語化することができる  ● 実際にIssueを集めて何が顕在化しているIssueなのかや、明らかにできていないIssue(Known Unknowns)を知ることができた  ● 新しいIssueはSlack上で @team_security へのメンションで把握している  16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©10X, Inc. All Rights Reserved. 10Xセキュリティチームの体制  ● 立て付けとしてはDevelopment Platformチーム配下のSubTeam   ○ Development Platformチーム＝基盤チーム的なところ(SRE, QA, Security)  ● 2022/01に組成  ● Mission: Stailerで扱う全ての情報、システムが安全であることを目指す     18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

©10X, Inc. All Rights Reserved. 10Xセキュリティチームの特徴  ● リソースが少ない(よくある)  ● Corp ITチームとふんわり責任境界を決めて協調してる   ○ Product Security, Corporate Securityと言う言葉でふんわり分業してる  ○ いずれ明確な線引きの整理が必要だが双方ともスモールチームなのでいつかやれたらいい、くらいの温度感  ● セキュリティの専門家が不在  20

Slide 21

Slide 21 text

Slide 22

Slide 22 text

©10X, Inc. All Rights Reserved. SWEの立場でもできることはたくさんある  ● セキュリティチームが不在、もしくは専門家が不在の組織はセキュリティIssueが基本的に積まれ続けている  ● その状況下であればSWEができることは多い   ○ 普段の開発で考える「セキュリティ的に気をつけなきゃいけないこと」に100％Focusして取り組むイメージ  ● セキュリティIssueの解決を計画と実行に分けた時、実行の際にはSWEの知識が役に立つことが多い  ○ 例) Cloud Securityの治安を維持するための自動化をどうすればいいのか  ○ 例) 仕様上、どうなってるかを追うためにソースコードを精読する  22

Slide 23

Slide 23 text

©10X, Inc. All Rights Reserved. 専門家がいないと難しいこと(=10Xの残課題)  ● 理想の未来像を描いた上での戦略策定   ○ 3~5年単位で目指すべき場所の定義  ○ 事業計画から逆算した上での戦略策定やリソース配分の決定、プロダクトのブレーキをいつかけるべきなのか  ● 現状の体系的な整理  ○ Product SecurityとCorprate Securityの境界も1つのトピック  ○ 「サービスのセキュリティ品質が担保されている」の具体的な構成要素をbreak downする必要がある  23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

©10X, Inc. All Rights Reserved. 現状の整理 - Issueの棚卸し  ● 当時時点で存在したGitHub Issuesの中からセキュリティにまつわるIssueにラベリング   ● 現在はGitHub上で把握できている全てのセキュリティIssueが集約されている状態   ● Slack上でフロー情報として流れてくるIssueはSlack reaction -> Notion DBに溜め込む仕組みを作って必要であればIssueとして管理する   26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

©10X, Inc. All Rights Reserved. 取り組みの中で見えてきたこと  ● (再掲)SWEの立場でも解決できる問題は多い   ○ 権限整理であれば現状把握からひたすら整理していったり、監査ログを有効にする  ○ 個人情報の整理は入口から出口までを洗い出してある程度機械的に保守できる仕組みを考える  ● 早ければ早いほど安い  ○ 例えば「サービスの個人情報って社内のどこにあるの？」という問いに答えるためには究極、全情報のチェックが必要  ○ これに取り組むのは早ければ早いほどいい、なぜならスコープが小さく済むから  ○ この3ヶ月間でチームのSWEには数百存在するBigQueryのdatasetを1つ1つチェックしてもらいました、頭が上がりません  32

Slide 33

Slide 33 text

©10X, Inc. All Rights Reserved. 取り組みの中で見えてきたこと  ● 採用活動は中長期で考える必要がある   ○ SWEと比べると市場にそもそもパイが無い  ○ その中からさらにハイレベルなメンバー(Product Securityのロードマップを描けるような人材)となるとさらに厳しい  ○ なるべく早く、継続的な活動を始める必要がある  ● 案外、取り組みをスモールにスタートする方法はある   ○ 10XのようにSWEでまずは取り組み始めるのも手だし、調べるとSecurity系のソリューションはかなり多い  ○ ただ、どんなサービスも入れたら終わりではなく入れてからの運用や文化づくりが本丸なのでそこにリソースを一定貼る必要がある  ○ Dependabot, Renobate導入 → 誰もmergeせず放置、みたいなのってあるあるデスヨネ  33

Slide 34

Slide 34 text