雑文です🖊
同僚の SRE がイネーブルメント活動のうち、専門知識の伝導やオーナーシップの移譲を進めることを「民主化」と呼んだりしている。自分もそれを気に入って「セキュリティの民主化」をやることがある。
その民主化活動を他社の人に共有したところ、興味を持ってくれたのでブログにも書いておこうと思う。
セキュリティの民主化とは
やっていることはチームトポロジーにおけるイネーブリングチームの活動に該当する。セキュリティに関する知識を開発者に伝導したりサポートすることで、セキュリティ文化の情勢や知識・技術力のボトムアップを図る。
「民主化」は政治用語なので、本来の意味とは厳密には違うかもしれないが、「全員がセキュリティに関心があり、それについて意思決定ができる状態」ぐらいの意味だと思ってほしい。
事例: 脆弱性の影響調査
ここで “民主化” の事例として、「Dependabot によって検出された脆弱性の影響調査」を紹介しようと思う。
Dependabot によるアプリケーションライブラリの脆弱性の影響調査をセキュリティチームのみが行うのは大変な作業だと思っている。「ライブラリをどう使っているか」「その機能はどういう使われ方をしているのか」を良く知っているのはドメイン知識を持つサービス開発者である。なので、脆弱性の影響調査もサービス開発者が行えば正確にできると思う。
一方で、「その脆弱性について、そもそも知らない」「攻撃の実現可能性が判断できない」などのセキュリティエンジニアの知識・経験による判断が求められることもあり、完全に任せることは難しいと思う。
CVSS 値による Severity は一種の判断基準としてあるが、当然ながらそのまま信用するわけにはいかない。
そこで、社内向けの脆弱性リスクアセスメントフレームワークを作り、それを浸透させるために、あるチームで「Dependabot アラートを倒す会」を実施した。 この会は、週1で30分ほど「セキュリティチーム + チームメンバー」で Dependabot によって検出された脆弱性を調査・対応する会。
リスクアセスメントフレームワークによる評価と"肌感"での深刻度の差分を縮めて成熟させ、活用を浸透させることが目的だったが、セキュリティチームと実施することで「脆弱性の調べ方や Advisory の読み方のコツが掴めた」「攻撃手法やそのリスクを知ることができた」といった声をもらった。
この活動は2,3ヶ月ほど経過したあたりで、チームメンバーだけで脆弱性評価ができるようになったので、そのチームに開催のオーナーを移譲した。その後も継続して実施されている。たまに様子を見に行くが、積極的にライブラリを更新したり、Dependabot の検出結果が0になったりと良い効果が出ていると思う。
特別知識がなくても扱えるリスクアセスメントフレームワーク自体も大切だが、こういったコラボレーションによるイネーブルメント / 民主化が、組織としての技術力や文化の醸成に繋がると改めて思った事例だった。
他の民主化活動
これはまだ実践できていないが、セキュリティアラートへの対応も同じことができるんじゃないかと考えている。例えば GuardDuty とか Datadog のセキュリティアラートも、セキュリティエンジニアだけが確認していては、開発者は気にもしなくなると思う。
「これはどういうアラートで、なぜ発生したのか、False Positive と言える根拠は何か」などを開発者と一緒に確認していくことで、開発者主導でのアラートの調整・追加にも繋がるのではないかと思う。
もちろん、全てを開発者に任せるというつもりは無くて、セキュリティチームと開発チームの境界を曖昧にしていくことが大切だと思う。セキュリティチームもサービスの改善にエンジニアリングで貢献するし、開発チームもセキュリティを気にする、そういった関係性を作っていけると良いと思う。Security Champion のような制度も同時に採用することで、強いのりしろにもなるだろう。
……ということを考えつつ、文化醸成のためにより良い Enabling をするには何をしていくか… というのが最近の個人的なテーマでした。
こういった「セキュリティ x 組織」な話って、他社事例をそんなに聞かないので、イベントテーマにして開催するといいのかなー。