いつの日かセキュキャンのtweetが流れてきて軽く眺めてみたらとあるクラスが自分に刺さりまして...調べていくとかなり面白そうだということがわかってきました。

[専門B]Webセキュリティークラス

面白そうだなあ...応募...

運よくいけることになりました。同じくもう一人のチューターが知り合いでびっくりしました。

どんなコンセプトや世界観で専門Bが作られているのでしょう？
これは2023年度のB1ともつながるところです。気になるのはこの部分ですが、去年も@lmt_swallow さんがプロデューサーだったということで2022年の履歴を見てみました。

現代の (Web) プロダクトセキュリティの世界の地図を内面化してもらう

Web プロダクトのセキュリティを守っていくというミッションにゼロから向き合うにあたって持っていたいベースの知識・体験を獲得するための始めの一歩が不足しているとのことです。それに関しては僕自身も思うところがあって、「現在のwebないしwebセキュリティーは複雑化・広範化しすぎている」ということです。それゆえに、webプロダクトのセキュリティーやその周辺に携わりたいと考えている人がどのように前に進んでいけばいいのか分かりにくい、というのは1年前の自分がまさに直面していた問題でもあったので深い共感がありました。

近年は事業会社においてはplatform engineeringの考えが台頭し民主化していっているといったダイナミックな動きがあったりしてそれによってとるべき行動は変わってきてるのだけれども”学生”はその渦中にいないのでゼロから向き合うにあたって持っていたいベースの知識・体験を獲得するための始めの一歩の場としては最高だったのではないのかなと思いました。僕自身も勉強になることばかりでした。

今の"webセキュリティ"が昔とはだいぶ変わっていてxssだとかssrfのような個別の脆弱性対応という世界観では収まらなくなってきているんですよね。今ってプロダクトを開発する人がクラウドも触るし、DevOpsに介入していくといったこともするし、1人の専門領域が広くなっているんですよね。...中略...セキュリティー業界においてもベンダーで働いている人は多いけれども、キャリアの選択肢として「事業会社の中でセキュリティーのチームとして働く」とか「SREの人と一緒に(appliation)のplatformを作っていく」とかセキュリティーの会社に行くことだけが(webプロダクトに携わる)セキュリティーの仕事ではなくなってきている背景があるんですよね。そしてそういった人って事業ドメインのことに対する深い理解があって意思決定をして技術的にどう実現していくのかということを考えている人たちでこれまでのキャンプにはなかったような面白さがあるなと思っています...中略...またそういった講師の話を聞くことで学生に1つロールモデルを見せることができればと思っています。

専門Bはかなり広範な技術領域を横断して取り扱っていますが、その理由に直結する本質が語られている気がしました。出典

それを踏まえてのB1はどのmatrixでwebプロダクトセキュリティーを考えるのかという思考スキームに関する話がありました。具体的に何を考えたのかは受講生のブログを参照してください。

B2, B3, B4, B6に関してです。かなり広範に技術をとりあつかっていることもあり、分野によってはチューター２人よりも受講生の方が手が動くものもありました。そんな時でも受講生同士で助け合いながら前に進んでいっており非常にたくましかったです。

B2はコーポレートセキュリティーにおける横断的侵害で、レッドチームの思考と攻撃の展開手法とそれを踏まえた防御側のプラクティス(発見的統制と予防的統制)についてまででした。サプライチェーンにおける問題がしばしば目立つ昨今で現代版の思考スキームから実際の事例を知ることができたのは非常に良かったです。
格言："攻撃者と防御側の本質的な思考は変わらない！"

B3のcloudnativeな環境でインフラのセキュリティーをどう考えていくのかというのはwebクラスの中ではかなり低いレイヤーになるものと思いますがこういったセキュリティーが考慮されたインフラ開発の戦略を立てて実践していくことはプロダクトの生産性にダイレクトに直結しそうだなと思いながら聞いていました。

B4に関しては認証・認可ということでサイバーサイドやフロントエンドを実際に書きながら最新のAuthz/Authnに関して理論も聞きました。認証や認可はflowが分かりにくくこれまでわからないところはフレームワークに丸投げし目を背けていたところもありましたが今回を機に色々深く掘ってみようと決意しました。複雑だけれどもちゃんと理解すると結構面白いとなりました。

B6はcodeqlのクエリを書きソースとシンクを特定していくことでソースコードの脆弱性を発見していくということをしました。今回は実際にクエリを書きましたがgithubが買収済みのためgithubのプロジェクト側から使うこともできると知って将来的には使いこなせるように実践していくことでしょう。log4jを発展的な題材としましたが組織で使っている3rd partyのフレームワークなどに脆弱性がないのかという調査は、事業会社においてかなり重要なトピックであり過去に僕自身も行ったことがあります。そういった時にflowを追っていき、怪しいところがないかを試す手法の1つとして有効であると心得ました。

さてここまではプロダクトセキュリティーサイドで出てくる代表的な技術的トピックの深掘りでしたが、ここからレイヤーがガラッと変わります。

B7:Policy as Code入門

監査というビジネス文脈、特に「システム監査」に着目してそれをソフトウェアの力で自動化する手法の一つとしてPolicy as Codeの考え方を学びハンズオンを通して実践しました。

確かに、現在のIT監査はエクセルで書かれたチェックシートが送られてきてチェックしてくださいという古典的なやり方が横行しているところが多いはずであり、それが自動化されることで監査が透明化され、監査人もまた監査を受ける企業にとっても双方にとって多くの手間が「継続的に」省けて非常に優れます。

行った演習についてはスライドを参照してもらうことにします。僕は事業会社でセキュリティや広義のIT監査に携わることに興味があったので積極的に演習をやって完走しました。Githubに演習の記録を置いておきました。これからPolicy as Codeの技術がさまざまなところで活かされていくと確信していますが、それを見守りつつも自分でも何ができそうかを考えていこうと思います。

cncfがサポートしているのは大きなことです。OPAのgithubを見るとkubernetes向けのOSSなどが散見されます。宣言的な構造化データでリソースを定義して表現できることの背景には、いくつものステップの抽象化の過程があります。PCサーバーがありOSがあり、言語があってドメイン固有言語に整備された環境の上に構造化データは成り立ち、下のレイヤーを信頼することで成り立っています。その分「自由度」や「制約の厳しさ」という観点では一番の制約を受けるものとなっています。極度に抽象化されておりさらに制約が厳しい環境で、プロダクトが安定して動くためのリソースを構築するというのはなかなかに大変なことです。それに加えて、ビジネス的な側面も介入してくると、セキュリティや効率化などのほかの軸のことも考慮することが求められます。

そこで、パブリッククラウド向けのCSPM製品や、yamlで記述されたmanifestに対してルールを当てていくセキュリティ管理が理にかなっていることがわかります。宣言的構造化データは計算機の抽象化の恩恵を受けており下のレイヤーの信頼のもとに成立しているからだともいえると思います。よって抽象が高いところに同じ目線で検知ルールを当ててやることでそれらのあるべき振る舞いについて考えることができるわけですね。

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

技術経営というハイレイヤーの視点から変わりゆく環境の中でステークホルダーを把握しプロダクト、その先にある事業の継続を抽象的に考え、さらに具体化として環境の変化に従って個人はどのように振る舞い変化に適応していくべきなのか...ということを「深化」と「探索」で考える非常に密度の濃い2時間でした。

大枠の内容は資料に任せることとして、僕が感じたことを書いていきます。まず、事業会社でプロダウトやコーポレートサイドまでを含めたセキュリティについて考えることは「総合格闘技」であるということです。受講生の感想の中にはCISOの目線で話を聞いてもなかなか想像ができないしどう活かすことができるのか...という声もありました。たしかに聞いていた話は受講生と講師の間でギャップがありすぎるところもあるのはよくわかります。そこで少しギャップを埋めることを目的に僕が受講生だったらどう考える(それこそ１年前くらいに本気で考えていたこと)について書いておきます。

１つは、自分が将来活躍したいフィールドではどのようなトピックがあって、それにはどんな技術、もしくは知識や経験が必要なのかということを知ることなのかなと思います。

事業会社に行くんだったら、セキュリティをやりたいのか、開発をやりたいのかで大きく変わってきます。どんな規模の開発をやりたいのか、どんな領域の開発をやりたいのか（サーバーサイドの開発をやりたいのか、はたまたインフラ開発をやりたいのか）などいろいろありすぎます。

そのほかにもセキュリティベンダーに行ってレッドチーミングを極めるとか、クラウドベンダーのようなところでインターネット作るぞとか、研究者や学者になるとかコンサルティングのほうに行くとか監査など多様な道がありすぎると思います。これらすべての選択肢が素晴らしい選択です。

こっから下は、私自身が事業会社の中の人であるという個人的な事情で「事業会社に行くなら」という話で推し進めていきます。あくまで個人の勝手ないち意見であり鵜吞みにしないでください。

上のような図があったと思いますが、実際これらはすべて重要なことと思います。PSIRTやIAMのようなプロダクトセキュリティと直結するトピックが当然ある一方で、予算管理やガバナンス、規制やコンプラのようなビジネスドメイン固有の問題が散見されます。また、リスク管理や脅威分析のようなWebセキュリティクラスから越境した技術領域（主に専門C:脅威解析クラス）のトピックも見えます。

ここからわかることとして、１つは自分の興味のあるビジネスドメインを見つけるということが重要であるととらえることができると思います。いわゆるsomething+Tech(例：Fintech)です。確かに金融事業とエネルギー事業は置かれている環境があまりにも違います。僕が見てきたエンジニアは開発もPlatformやセキュリティに従事している人もある程度以上の自分たちのビジネスドメインに対する知識や解像度がある人ばかりです。それありきで仕事が成立する以上、重要なことであると考えています。

２つ目としては、そのほかの隣接する技術領域に興味をもったり手を動かしてみるということです。Webプロダクトの会社とは言えど、端末管理や回収してきたログの分析などレイヤーが低い領域に対しても自ら責任を担って行っていかなければならないところが一定あります。そういった本体とは別の領域に対して「Webプロダクトを軸に展開している立場」の目線ではどのように取り組んでいるのかを知り、実際にそれを支えている要素技術を手を動かして学んでみるということは重要と考えています。当然ですが余力ができたときの話です。

１つ目と前図にかかわるところでいうとコミュニケーションの能力もそれに入るのかなと思います。他の分野の人と会話するということが往々にしてあるでしょうしそんな時に自分の世界観でばかり話してしまうと全く伝わらなくなってしまいます。また、人に伝える・伝わるというところが前図でいうところの「分化形成」とか「教育」とかにもつながってくるのだと考えています。

いろいろ必要だということが分かったところですが、一気にできることでもないので講義でもあったように「積層化させる」ことが大切だというところにつなげてこの辺で終わりにしておきます。

謝辞とまとめ
Bクラスというのは足りないと言われているセキュリティー人材の中でも一番ボリュームが多い層(実際にも必要とされている層)だと思われ、第3者目線ではかなり注目されているクラスなのではないかと思います。それに従って、受講生は応募時に相当な倍率を勝ち抜いて参加する権利を勝ち取ったのではないかと思います。そんな近しい技術領域に強い興味関心がある皆様に囲まれて過ごす5日間はチューターとしても特別な体験となりました。

また、当クラスの講師の皆様におかれましては、現場の第一線で活躍、また講義をされた当該技術の第一人者ばかりで非常に良い刺激を受けました。これから私自身も深化と探索と続けていくことによって広い視点で、長期的にwebプロダクトのセキュリティーに携わっていくための1つの布石とすることができました。私自身、学士取得予定後の2024年の4月からは、このクラスでプロデューサーが見せたい1つのロールである「事業会社の中でwebプロダクトのセキュリティーに開発者と一緒に携わっていく」様な人になっていると思います。もう1人のチューターも同じ様な立場になるらしく、事業会社の中でそういったactionを起こしていく流れに昨今の学生が乗っていくことは普遍的になってきていると実感します。

また、協賛企業の見学の皆様の中で当クラスに見学に来てくださった方々にも感謝しています。私の知り合いの方が何人かきてくださいましたし、はじめましての方ともたくさんお話しすることができました。同様に事業会社の中でwebプロダクトのセキュリティーに携わりご尽力なさっている方と直に話をすることができたのは非常に良い経験でした。今後ともよろしくお願いいたします。

来年のWebセキュリティクラス、またセキュリティ・キャンプ自体もより良いものとなることを祈念して結びの言葉とします。お疲れさまでした。

付録：受講生の参加記

https://www.palsha.jp/sec-camp-record/

Discussion