モンドーの共同創設者 Dom Richter – インタビュー シリーズ

Dom Richter, モンドーの共同創設者は、モダンなソフトウェア開発、プロダクトデザイン、チームリーダーシップにわたる幅広い分野で豊富な経験を持つシーズンドプロダクトリーダーです。バックエンド、フロントエンド、自動化テクノロジーを含む幅広い背景を持つ彼は、信頼、実験、目的志向のイノベーションを重視する文化を持つ高パフォーマンスのエンジニアチームを率いてきました。彼の仕事は、AI、サイバーセキュリティ、DevOpsの分野で交差し、コラボレーション、継続的な学習、エンドユーザーへの有意義な価値の提供を重視しています。

モンドーは、クラウド、オンプレミス、ハイブリッド環境を横断してインフラストラクチャを継続的に評価、監視、保護できるセキュリティおよびコンプライアンスの自動化プラットフォームです。ポリシー・アズ・コードとマシンラーニングによって駆動される洞察を活用して、モンドーはチームが脆弱性を特定し、コンプライアンス基準を施行し、セキュリティ態勢を強化することを支援しながら、イノベーションを遅らせることなくセキュリティ態勢を強化することを支援します。プラットフォームは、継続的なコンプライアンスを実現可能な現実として、モダンなDevOpsワークフローにシームレスに統合されます。

モンドーの共同創設者になったきっかけと、ハッカーおよびプロダクトリーダーとしての経歴、Google (GOOGL ) 、Chef、 以前のスタートアップでの経験が、会社の使命をどのように形作ったかについてお話しください。

私は、ペネトレーションテスターとしての仕事の中で、簡単に防ぐことができる弱点を見つけることが多かったです。同時に、セキュリティはユーザーにアラートを送りすぎて、重要なことを見失うことがありました。当時私は「これらの問題を解決するための簡単なボタンを押すことができたら」と考えていました。

その後、私は攻撃側から防御側に切り替え、システムを適切に運用する方法を学びました。自動化とコードを使用して大規模なシステムを運用する方法を学びました。これは、小規模なホームネットワークを運用する場合でも、大規模なテクノロジー会社を運用する場合でも同じです。最終的に、セキュリティとプラットフォームエンジニアリングの組み合わせが、モンドーの共同創設者になったきっかけとなりました。私は、もう一つのスキャナーを追加するのではなく、セキュリティの現状を変えることを目指しました。モンドーを使用することで、数年間困難に陥っていた顧客がポストを迅速に改善できるのを見て、非常に励みになります。何人かの顧客は、モンドーによってオープンな脆弱性が60%減少したと報告しています。これは素晴らしい結果です。私たちは、エージェントベースの脆弱性管理によって100%に近づけることを目指しています。

修復 — 脆弱性が発見された後に実際にそれらを修復するプロセス — は、ミスと考えられます。なぜ業界は、修復を行うチームが苦労するように、スキャニングと報告に多大な投資を続けているのでしょうか。

これは、特に大規模な組織において、セキュリティチームとプラットフォームチームが設定される方法の結果です。長い間、これらのチームを別個のエンティティとして扱い、各チームに独自の目標、ツール、優先事項がありました。しかし、コンウェイの法則は、組織図を解決策ではなく出荷することを証明しています。両方のチームが、しばしば妥当な理由で、相手チームを指責するのを見てきました。

業界では、ついに変化が起こっています。会社は、セキュリティからより多くのものを求めているのです。ビジネスを妨げるものではなく、推進するものにしたいのです。進歩的なリーダーが、境界を押し広げるために現れ始めたので、ついに業界とソリューションに変化が起こってきました。

セキュリティチームとDevOpsチームの間の文化的な隔たりをどのようにして克服し、修復と回復力を向上させることができますか。

DevSecOpsは良いスタートです。開発者とセキュリティチームを近づける必要があります。SecOpsエンジニアやセキュリティバックグラウンドを持つプラットフォームエキスパートなどのクロスファンクショナルロールを採用することで、ギャップを埋めることができます。また、チームを物理的に近づけることも重要です。リーダーシップがこのプロセスを促進し、参加することが不可欠です。共有目標とメトリクスを設定し、追跡する必要があります。

チームをサポートするために、ツールとテクノロジーを統合する必要があります。セキュリティチケットをチケットシステムにダンプするのではなく、両方のチームが必要なものを提供する共有モデルを確立する必要があります。たとえば、プラットフォームチームに十分なコンテキストと適用する必要のある具体的な修正を提供することで、脆弱性の修復を自動化することができます。自動化システム（TerraformやAnsibleなど）で変更リクエストを作成することで、実行がより迅速になります。また、プラットフォームチームが異議を唱えたり、例外を取得したり、システム的な問題を報告したりすることが容易になるように、コミュニケーションパスを確立する必要があります。すべてこれらはコラボレーションを促進し、ギャップを埋めます。

リーダーシップが、セキュリティの問題を修復するための責任とコラボレーションを創造する役割についてはどう考えていますか。

リーダーとして、私たちのチームが実行する能力に寄与する2つの主要な要素があります。1つは、私たちがコミュニケーションを行う方法であり、もう1つは、私たちが測定する方法です。如果リーダーが、発見の収集と他のチームへのボトルネックを指摘することだけに焦点を当てている場合、チームは同じように扱うでしょう。如果リーダーがセキュリティ問題の数とその質、取られた措置を測定しない場合、チームはそれに最適化します。

私たちは、境界を超えた他のリーダーと協力し、共有された性質を認識し、シロ化されたメトリクスではなく、共有された成果に焦点を当てることで、適切な条件を作ります。リーダーが共有された問題に取り組むと、個々のチームとビジネスにとって、より多くのことを達成します。なぜなら、重要な成果を推進するからです。

リスクスコアは広く使用されていますが、しばしばコンテキストが欠けているため、アラート疲労が多くのチームを圧倒しています。組織は、正しい問題が修復されるように優先順位を再考する必要があります。

効果的な優先順位付けのために、ビジネスコンテキストとテクニカルコンテキストが必要です。ビジネスコンテキストには、会社の活動を維持するために保護する必要があるデジタルアセットを含むものがあります。たとえば、ユーザーのプライベート画像を含むデータベースや、すべてのWebトラフィックを処理するゲートウェイは、インターネットに接続されていないテストシステムよりも優先順位が高いです。セキュリティの発見を調べる際には、ビジネスコンテキストを理解する必要があります。如果「クリティカル」と表示されるが、発見が低優先順位の場合、チームはそれを真剣に受け止めません。如果問題が真正にクリティカルである場合、理由を明確に示す必要があります。

次に、テクニカルコンテキストが必要です。これには、システム、構成、ロケーション、タグ、애플리케이션、パッケージ、ユーザーを理解することが含まれます。しかし、それだけではありません。より高いレベルで理解する必要があります。クリティカルなシステムがどのように公開されるか、どのように接続および統合されるかを理解する必要があります。単に1つまたは2つの個別のシステムを調べるのではなく、クラスターとして調べる必要があります。また、これらのシステムがどのように自動化され、どのように構築されているかを理解することで、迅速に問題の根本原因を特定し、修復する方法を示すことができます。

攻撃者がAIを兵器化するようになっているため、ディフェンダーはAIを責任を持って使用して、リスクを生み出すことなく先んじて対応するためにどのようにすることができますか。

AIを使用すると、脆弱性を修復する能力が大幅に増加し、機械のスピードで実行できます。しかし、AIシステムがセキュアでない場合、新しいリスクを環境に導入する可能性があります。AIを搭載したシステムを展開する場合、セキュアで透明なアーキテクチャを使用し、包括的なログ記録とイベント監視を可能にすることが重要です。エージェントの権限を、割り当てられたタスクを完了するために必要なものだけに制限することで、リスクを最小限に抑えることができます。さらに、ユーザーがエージェントを中断または停止できるようにする、必要に応じてエージェントとそのアクションを監査するなどのガードレールも必要です。

生産環境で修復を自動化するために、エージェントに権限を与える場合に、どのようなガードレールが不可欠であると考えていますか。

自動化が実行できるすべてのアクションに対して、予想されるスコープ内で動作することを保証するガードレールが必要です。如果エージェントに全インフラストラクチャへのフリーローミングアクセスを与えると、最終的には何かを壊します。

幸いにも、プラットフォーム自動化の過去20年間の努力により、ガードレールを理解することができます。モダンな自動化システムには、自動化が実行できるアクションを制御する制限があります。モンドーでは、AI駆動の修復と対立するポリシーフレームワークを組み合わせて、修復のアクションを確認します。修復はコードで作成され、テスト、検証、および必要に応じて制限できます。

次の5年間で、人間主導と機械主導の修復のバランスがどのように進化すると思いますか。

自動運転車と同様に、チームは徐々に機械主導の自動化を採用するでしょう。まず、セキュリティのスコープのサブセット、たとえば優先順位の低いシステムに焦点を当て、そこにエージェントベースの自動化を導入し、メトリクスを作成し、目標を追跡し、段階的に展開します。自動化が完了すると、他の領域に拡大します。

最終的に、自動化の焦点は、規模が大きく類似点が多い領域に置かれるべきです。自動化によってもたらされる一貫性から最も利益を得る領域です。5年以内に、すべての主要な修復アクションが機械主導になることを信じています。セキュリティとプラットフォーム運用が緊密に統合されたシステムになるでしょう。

脆弱性管理が今後10年でどのように見えるべきかについての長期的なビジョンを教えてください。

10年末までに、脆弱性管理は自動化と修復に重点を置くことになります。セキュリティの専門家としての私たちの役割は、プラットフォームチームと協力して進化するIT環境をセキュアにすることに重点を置くことになります。これらのシステムは、プラットフォームの自動化とエージェントベースのAIを使用して、大規模なアクションを取り、安全で予測可能なものになります。

リソースが限られている小規模なセキュリティチームにとって、修復と回復力を向上させるための実用的な最初のステップは何ですか。

パッチの自動化から始めましょう。特にリソースが限られている場合、自動化を早期に導入し、セキュリティを最初から統合しましょう。これは、攻撃者が使用する自動スキャンへの露出を大幅に減らす最も簡単なステップです。

素晴らしいインタビュー、詳しく知りたい読者はモンドーを訪問してください。