キザイア・プラットナー & カディア・マシャール【CODE BLUE SPEAKER インタビュー】
[Speaker interview, English follows]
SisyphusとCVEフィード:大規模な脆弱性管理について
これまで続けてきたCODE BLUE 2022 スピーカーのインタビューも今回が最後になります。
トリを飾るのは「SisyphusとCVEフィード:大規模な脆弱性管理について」の講演を予定されているキザイア・プラットナー(Keziah Plattner 写真左)氏とカディア・マシャール(Kadia Mashal 写真右)のお二人です。
https://codeblue.jp/2022/talks/?content=talks_8
講演のテーマはズバリ「組織における脆弱性の管理手法」。お二人が所属するAirbnbの事例が紹介される予定です。多くの組織が直面している課題でもあり、とても興味深いと言えます。
―― 発表されるテーマを始めたきっかけは何ですか?
マーシャル氏:防御的なセキュリティ・エンジニアとして、私は脆弱性の一元化と追跡に関して多くの課題に直面しました。デフォルトのCVEレーティングでは、リスクの優先順位付けに十分な内部コンテキストがなく、複数のベンダーのDBに分散した脆弱性データでは、リスクを総合的に評価するという私の仕事が難しくなっていました。そこで私は、ベンダーの制約に左右されることなく、脆弱性データを管理し、総合的なリスク評価と防御の方法を確立することを決意しました。そして、このデータを一元化し、脆弱性のライフサイクルを自動化できるプラットフォームを構築することをビジョンとしました。
プラットナー氏:私の経歴と学歴は伝統的なソフトウェア工学ですが、この業界にフルタイムで入ってからは、常にセキュリティ組織の下で働いています。私は、両分野が交わることで生まれるチャレンジが好きで、脆弱性管理の拡張という問題は、この分野の中で大きなチャンスとなります。
―― 研究の過程でどのような点で苦労しましたか?
多くの「ベストプラクティス」アドバイスは一般的なもので、既存のレガシーコードや独自の社内事情を持つ大規模な組織で実際に導入するのは難しい場合があります。例えば、「自動化」についてのアドバイスは、スキャンツールのデフォルトの自動チケット作成機能を示唆しているだけで、私たちのニーズには十分に柔軟でないことがよくあります。
あるいは、提供されたデフォルトのスコアで十分であるという前提がありますが、実際には、ノイズの多いアラートをすべて選別するのは、自明ではない量の作業です。
さらに、従来の脆弱性管理手法の多くは人間の介入に依存しており、私たちは特にこれを避けたいと考えていました。大規模なインフラを持つ企業が、どのように私たちの問題に対処しているのか、より実践的な例を探すのは簡単ではありませんでした。
―― この講演に参加しようと思っている人たちに一言お願いします。
セキュリティのトレードオフやスケーリング問題を管理するための日々の課題や現実的なアプローチについて、システム構築の立場やブルーチーム・メンバーの視点に興味がある方にお勧めします。
“Sisyphus and the CVE Feed: Vulnerability Management at Scale”
https://codeblue.jp/2022/en/talks/?content=talks_8
―― How did you get started in the topic that you are presenting?
Kadia Mashal:As a defensive security engineer, I encountered a lot of challenges around centralizing and tracking vulnerabilities. Default CVE ratings didn’t have enough internal context to help prioritize risk, and having vulnerability data staggered in multiple vendor DBs made it difficult to do my job of evaluating risk holistically. I decided to be in charge of our vulnerability data and not let vendor limitations affect our holistic risk assessment and defense methods. The vision was to build a platform that allowed us to centralize this data and automate the vulnerability lifecycle.
Keziah Plattner:My background and educational experience is in traditional software engineering, but I have always worked under Security organizations since joining the industry full time. I love the challenge that comes in the intersection of both fields and the problem of scaling vulnerability management is a great opportunity within that space.
―― What were some of the obstacles in doing this research?
A lot of "best practice" advice feels generic, and can be difficult to implement in practice in a large scale organization with existing legacy code or unique internal context. For example, advice about "automation" can just suggest default auto-ticket creation features from scanning tools, which are often not flexible enough for our needs. Or the assumption is that the default scores provided should be sufficient, when in fact sorting through all the noisy alerts is a nontrivial amount of work.
In addition, much of the traditional vulnerability management approach relies a lot on human intervention, which was something we specifically wanted to avoid. Searching for more practical examples on how an established company with a large infrastructure handled our problems was not easy!
―― What would you say to the people thinking of attending this talk?
I would recommend this to anyone who is interested in the perspective of builders and blue teamers on the day-to-day challenges and pragmatic approaches of managing security tradeoffs and scaling problems.
世界トップクラスの専門家による情報セキュリティ国際会議「CODE BLUE(コードブルー)」