0x00 背景
転職しました。これを機にここ数年セキュリティエンジニアやってきた感想を書こうかなと思います。
私は副業を含め、主にWeb系事業会社のインハウスセキュリティに従事してきました（ベンチャー、上場企業、メガ企業の子会社など）。経歴はかなり限定的ですが、この文章のターゲットを従業員数50人から3000人程度のWeb系企業だと想定して書いています。
0x01 転職理由
前職のD社で本当に楽しく働かせていただきました。もともとリバースエンジニアリング系の仕事が好きで、偶然にもモバイルゲームのセキュリティに関する需要があり、さまざまな面白い仕事に携わることができました。
D社には、本当に優秀なセキュリティエンジニアがたくさんいます。みんなは攻撃手法に精通しているだけでなく、開発スキルも優れています。この強みを生かし、D社ではさまざまなセキュリティツールが内製で開発されました。
内製はエンジニアにとっては非常に楽しい仕事で、技術力の向上にも繋がり、とてもいい選択肢だと思っています。しかし、内製をしすぎるといくつかのデメリットもあるかなと思います。
- まず、内製ツールの開発ノーハウは属人化しやすく、コーディング能力が高いエンジニアが作ったものは簡単に引き継げない。製品の品質も開発メンバーのスキルによってぶれます。もちろんこれは開発のプロセスを最適化にすることよって解決できるかもしれませんが、そうすると次の問題が発生します。開発という行為をしているので、仕様設計、アプリ開発、インフラ構築、SRE、QA、メンテナンス等々、開発ライフサイクルにある全ての手順はセキュリティエンジニアが自らカバーしないといけなく、セキュリティエンジニアをやりながら、これらの仕事を遂行するには非常に強い精神力が必要です。開発している中で、段々セキュリティエンジニアの本職からズレていくこともあり得ます。
- 二点目は、内製が成功しているということは、商業セキュリティ製品を触ることが少なくなるという反面があります。最新の商業製品にさわれないと、業界最近の動向もわかりにくく、最新のセキュリティ技術への感度も低くなります。まあ本音をいってしまえば、他の会社みんなが使ってる技術、製品が多少わからないと、転職時には不利になりかねません。私はたまに思いますが、D社でとても楽しく楽にセキュリティエンジニアをやってますが、それは本当に優秀な同僚のおかげで、次の会社で同僚が開発してた内製ツールがないと自分はやっていけるかな？と（笑）。
- 最も重要なデメリットはやはり人材の確保です。セキュリティ人材自体が少ない時代に、事業会社はセキュリティベンダーと人材を競合することが多いです。しかも、事業会社が求めるセキュリティ人材はさらに限られており、攻撃手法の知識だけでなく、プログラミングや自社の要件に合わせたシステムのカスタマイズ能力や関心も持っている人でなければなりません。D社のようにこんなにも優秀なセキュリティ人材を揃えられる会社はそうそうありません。
簡単にいうと、D社のセキュリティ体制は優秀ですが、他社での再現性はむずかしいかなと思っています。
もちろん、内製を反対しているわけではなく、インハウスセキュリティチームは商業製品いっぱい買って入れれば万々歳というわけではありません。あくまで内製と商業製品両方のバランスの取れた運用にしたいと思っています。
具体的に、事業会社では、EDR、AV、SAST、DAST、CSPM、WAF等のセキュリティ製品の本体を作るべきではない、作るべきなのはこれらの製品により検出された脆弱性やアラート等のイベントを整形、管理、自動化するプロセス（ETLというかな）のみだと思っています。
というわけで、自分はどんな事業会社にも簡単に適用できそうセキュリティ体制（ポータビリティの高い体制）を作って行きたいと思い、転職しました。（ちなみに、現職のCISOもみんなにポータビリティの高いスキルを身につけてほしいという考えらしいです。）
0x02 プロダクトセキュリティ
次に、もう少し具体的な話をしたいと思います。特に今はお流行りのプロダクトセキュリティについて個人的な見解を述べたいです。
これまでは、EDR、WAF、SIEM、IDS/IPSなどのセキュリティ製品が事業会社において主要な役割を果たしてきました。このような製品の扱い方は、基本的には上がったアラートをセキュリティチームが一元的に監視し、アラートが発生した場合にはインフラチームや該当事業部と連携してハンドリングするという方法が一般的です。
しかし、モダンなセキュリティ環境では、前述の製品だけを使用してSOCの体制だけで対応することは十分ではありません。シフトレフトやプロダクトセキュリティの観点では、コンテナーセキュリティ、ソースコードセキュリティ、サプライチェーンセキュリティ、クレデンシャル管理、クラウドセキュリティ（CSPM）など、様々な面倒を見る必要があります。これらの要素は、セキュリティチームによる一元的な管理方法では現実的ではありません。
中小企業なら、AWSアカウント数個、プロダクト一個ならとりあえずセキュリティチームが一通り検知ツールを設定してあげれば、なんとか運用が回ります。しかし少し企業規模が大きくなると、複数の事業を立ち上げ、Githubのレポジトリ、AWSアカウントやGCPプロジェクト数百、数千個にのぼり、それらのソースコードやクラウド設定で検出されたアラートをセキュリティチームで集中的に管理するのは無理でしょう。それに、SOCならセキュリティチームの方が検出されたアラートに詳しいのに対し、プロダクトで検出された脆弱性はそもそも仕様なのかむしろ開発側の人間の方じゃないとわかりません。そこで、自分は一番作りたいのはこの課題を解決するための集中&分散管理ができる仕組みです。
具体的にいうと、ソースコード(SAST)やクラウド設定(CSPM)で検出された脆弱性をセキュリティチームが集中的に把握しながら、各プロダクトに自主的に対応してもらえる責任分担の仕組みが大事だと思います。開発段階で大量に検出した脆弱性はセキュリティチームが対応すべきではない(できない)ものの、イネーブルメントとか言って完全に開発側に任せるのも違うので、うまくからくりを作らないといけません。
実際は今の会社ではこのような仕組みを作っている最中で、まだ詳しい話はできませんが、そのうち公開したいと思います。
0x03 最後に
正直セキュリティ職種に関してはD社の給料は全然悪くなく、いい方だと思います。商業製品にはあんまり投資しない分、従業員の給料に還元しています。どっちにお金を突っ込むべきか難しい判断だと思いますので、私にも正解はわかりません。
そして、プロダクトセキュリティに関しては、すごく進んでいる有名な事業会社も見たりしていますが、一つや二つのプロダクトだけを強化するのではなく、会社全体にわたって共通の仕組みを作りたいという僕の着眼点は少し違うかなと思っています。同じ感想を持つ方々とぜひ関わりたいと思います。
いっぱい偉そうに言ってしまいましたが、一緒に頑張りましょう。