Clarke Rodgers (00:08):
本日はご参加いただきありがとうございます。

Aman Sirohi 氏 (00:10):
こちらこそ、ありがとうございます。お招きいただき、光栄に思います。

Clarke Rodgers (00:11):
よろしければ、経歴と People.ai での仕事について教えていただけますか?

Aman Sirohi 氏 (00:16):
もちろんです。当社は収益インテリジェンス企業です。営業リーダーがデータを利用して迅速な意思決定を下せるように支援しています。当社はお客様のデータを取り込み、分析的な決定を下せるようにデータをお客様に提供しているため、セキュリティは私たち全員にとって最優先事項です。

Clarke Rodgers (00:30):
私が多くの CISO と話す際には、時間とともに CISO の役割がどのように進化するかを話題にします。 そして、長きにわたって、CISO は技術的なセキュリティエキスパートとみなされ、実際には組織内で良くないことが起きたときの火消し役としてのみ、頼りにされてきました。しかし、今日では、私たちが目にする成功した CISO の大多数は、実際にはまずビジネスリーダーであり、おそらくセキュリティの実務者としての役割はその後に来るものとなっています。この役割がどのように進化してきたのか、できればご自身の経験と合わせて、少しお話しいただけますか?

Aman Sirohi 氏 (01:05):
もちろんです。5 年、あるいは 10 年前に遡ると、CISO の役割はおっしゃるとおりであったと思います。私たちの仕事は会社を守ることでした。私たちはセキュリティのエキスパートであり、舞台裏で仕事をしています。そして、現在および今後に目を向けると、セキュリティはあらゆる業界のあらゆる人々の考えの中で極めて重要なものです。実際、セキュリティは事前に確保する必要がありますよね? そのため、私は社内で常に次のような言葉を用いていました。「セキュリティを第一に考えましょう。守勢に回らず、セキュリティについてお客様に伝えましょう。会社にとってセキュリティがいかに重要であるかをお客様に伝えましょう」。 なぜなら、そうすることで、お客様から「しっかりとした知識がある」と思っていただけるからです。 私たちが積極的であれば、お客様は話すだけで安心するのです。

Clarke Rodgers (01:43):
信頼を勝ち取るということですね。

Aman Sirohi 氏 (01:43):
そのとおりです。信頼を築いていくのです。私は、信頼が複数のレイヤーで構築されると考えています。エグゼクティブの会議に参加すると、常に話題になるのは、これらのエグゼクティブが聞いたことです。これらの取締役会のメンバー、E スタッフ、友人から聞いた話を思い出して、「あのハッキングについて聞きましたか? このことは知っていますか?」というようなことを話します。

つまり、私が実際に行っているのは、セキュリティ全般について話すということです。私たちが関係する分野で何が起こっているのでしょうか? 私たちに影響があるかどうかにかかわらず、会議でセキュリティが注目されるのは常にすばらしいことです。なぜなら、これらのエグゼクティブは頭の片隅で、「友人はこのハッキングについて話していた。まさに自分たちの環境で起こったことだ。しかし、このような理由により、私たちは影響を受けなかった」と考えるからです。

それは、ストーリーを伝え、情報を提供し、関係をより強調し、お互いの考えやアイデアを結びつけるということであり、これによってセキュリティがさらに強力になるのだと思います。

Clarke Rodgers (02:29):
興味深いですね。取締役会のレベルで対話し、このようなストーリーを話しているとき、「X 個の脆弱性があり、これだけの時間でそれらにパッチを適用することができました」というように話すのでしょうか? それともビジネスに対する損益に関するリスクの観点から話しているのですか?

Aman Sirohi 氏 (02:45):
幸運にも私はいくつかの異なる会社に所属してきましたが、どの取締役会も少しずつ異なっています。一部の取締役会は知識を求めています。 また、基本的に十分にスマートで知識があり、セキュリティの実務者ではないかもしれませんが、この分野について非常に詳しい取締役会もあります。そのため、私はまず、「私たちはこの業界で何をしているのか? 私たちの業界は何をしているのか? これらの業界にとってセキュリティとは何か?」という質問から始めます。 それから、収益につながるビジネス価値や機能について説明します。

自社のセキュリティ体制を説明するためのデータを常に用意しておく必要があります。例えば、前月にフィッシングの試みが 10 倍になり、トラフィックの急増があったとします。取締役会に出席して、「当社のフィッシングキャンペーンはどうでしたか?」と聞かれ、「確認してから後ほどお答えします」などと言うわけにはいきません。 回答として不適切です。

準備を整えて、データを用意しておく必要があります。例えば、「スライド 54 には、今回と前回の違いが示されていて…」と述べることができます。結局のところ、取締役会のメンバーから質問があれば、簡単にわかるようにしておくべきであると私はいつも考えています。

Clarke Rodgers (03:42):
そうですね。

Aman Sirohi 氏 (03:42):
簡単にしておきます。取締役会のメンバーが情報を理解しやすいようにしておくのです。そうすることで、仕事は楽になり、全員が同じ認識を持つようになります。

Clarke Rodgers (03:49):
取締役会にとって理解しやすくするということはわかりました。一方、社内に目を向けると、製品チームと開発チームが正しく安全な方法で作業を簡単に行うことができる環境も必要ですよね。これを可能にするために設けたメカニズムのいくつかを簡単に教えていただけますか?

Aman Sirohi 氏 (04:07):
シンプル過ぎるかもしれませんが、会話をすることです。会話をしてコミュニケーションをとり、CTO、Chief Engineer、Chief Architect と座って話をすると、多くの人が「シフトレフト」について話します。 過去に私が所属していた組織では、「この脆弱性を解決する必要があるので、スプリントを変更してください」と言われたことがあります。 ほとんどの製品デベロッパーは、「この機能をプッシュする必要がある」というふうに考えます。 機能が収益につながるのですから、これらの人々は機能のプッシュに向けて作業を進めますよね?

したがって、会話をしていて、「スピードを落とす必要があります。このスプリントではなく、次のスプリントかもしれません。安全なコードを確実にプッシュするために、 NIST SSDF モデルに基づいて、これらのセキュリティゲートを設ける必要があります」と伝える場面を想定してください。私は次のように述べました。「お客様のところに行って、『X 様、安全なソフトウェアを構築するために追加で 1 週間いただけませんか?』とたずねれば、 お客様は『はい』と答えるでしょう」。そのように答えないお客様はいないでしょう? したがって、私は常に、オープンであること、コミュニケーションを取りやすくすることという基本に立ち返っています。

私たちは、「監視役が見ている」とよく言われます。つまり、警察のように思われているのです。しかし、実際はそうではありません。別の方法で取り組むことにしたときには、「よし、これはこのスプリントではなく、次のスプリントにしよう。うまくいきそうだ」というような声が上がります。 そのように進めて問題ないことを確認するには Chief Product Officer の承認が必要かもしれませんが、少なくともコミュニティが構築され、そのように対応すべき理由が理解されています。「セキュリティ部門に強制されたから」という理由ではありません。

Clarke Rodgers (05:23):
すばらしいです。CISO として、あなたは組織を保護し、可能な限りビジネスを安全に遂行するためにさまざまなセキュリティプログラムやメカニズムを導入する責任を負っています。しかし、同時に会社のイノベーションを実現する責任も負っていますよね? この 2 つのバランスをどのように取っていますか?

Aman Sirohi 氏 (05:43):
それはとても繊細です。スタートアップである以上、速度がすべてであり、スケーラビリティがすべてです。お客様の要求も同様です。製品があり、機能があり、X というお客様はこれを望み、Y というお客様はあれを望んでいる、というように。 そこで、製品ロードマップの出番です。CISO として、あるいはあらゆる種類のセキュリティ体制について、製品ロードマップについて話し合う場に参加する必要があります。

その場に E スタッフを参加させて、次の四半期がどうなるのか、来年がどうなるのかについて話し、その会話に参加しているときにこそ、イノベーションを実現できると考えています。また、少しだけ話を戻すと、CISO として、セキュリティ面で必要な変更を学ぶことがあるかもしれません。なぜなら、ある製品についてイノベーションを起こそうとしている中で、それをより簡単にする必要があるからです。 それで、当然誰かが「そうだ、MFA を廃止しよう」と述べるでしょう。 私は「いいえ。これは譲れません」と述べます。 それは絶対に必要です。そうですよね? しかし、私たちはセキュリティの実務担当として、デベロッパーが仕事を成し遂げるために大変な苦労をしなくてもよいように、デベロッパーのために作業を簡単にすることができるはずです。

Clarke Rodgers (06:48):
それは非常にすばらしいことです。多くの CISO は、極めて困難な立場にあるとは言いませんが、組織内のセキュリティスタッフの数が限られており、組織のセキュリティ以外の部分に対するセキュリティチームのパフォーマンスを改善し、影響力を強める方法を常に模索しています。セキュリティ以外の部分というのは、デベロッパー、サービスチーム、あるいは経理、財務、人事などのことです。これについては、どのようにお考えですか? また、セキュリティが全員の仕事であるようにするために、組織内にセキュリティ文化をどのように位置付けますか?

Aman Sirohi 氏 (07:27):
それは難しいことです。簡単ではありません。マーケティング部門には異なる目的があり、財務の目的も異なるからです。さまざまな国や州に出張する営業担当者は、ビジネスのしやすさを求めています。

特に今日のような経済情勢においては、人員、資金、予算が減らされていますが、私たちの責任は変わっていません。私たちの責任が変わらないのであれば、これを実現するための創造的な方法を見つける必要があります。前の会社や今の会社で本当に有意義だと思う方法の 1 つは、チームメンバーが、セキュリティについて情報を伝え、コミュニケーションを取るために、事前に同僚のグループや組織とのミーティングの機会を設けていることです。私はこのミーティングには参加しません。「CSO がいる」と思ってほしくないからです。

Clarke Rodgers (08:16):
興味深いですね。

Aman Sirohi 氏 (08:16):
「リーダーがいるから、私たちはリーダーの意見に耳を傾けなければならない」と思ってほしくないのです。 私はチームメンバーにコミュニケーションを取らせ、関係を構築させ、促進させているのです。 そうすることで、参加者は同僚と話すことになるからです。その後、社内全体にデプロイし始めると、地ならしをしてデューデリジェンスを行っているため、よりシームレスに進めることができます。

Clarke Rodgers (08:37):
支持者を確保できたのですね。

Aman Sirohi 氏 (08:38):
そのとおりです。ただし、自分がそこにいなくても支持者を確保することはできます。なぜなら、セキュリティリーダーとして、またはリーダーがそこにいる場合には、トーン、進行、会話がまったく異なってしまうからです。「上司がここにいるから、これについて話さなければならない。聞かなければならない」というようになります。 しかし、他のチームメンバーも同じことができるようにする必要があると思います。本当に難しいことですが、そのエコシステムを構築し、個々のチームメンバーがそのバトンを担って、全員にとってのセキュリティ担当者になれるようにする必要があると思います。

Clarke Rodgers (09:08):
すばらしいです。さて、セキュリティチームに限ると、セキュリティチームで人を採用する際、どのようなスキル、特性、経歴を求めていますか?

Aman Sirohi 氏 (09:20):
最も大切なのは好奇心です。好奇心は教えることができません。

Clarke Rodgers (09:25):
興味深いですね。

Aman Sirohi 氏 (09:25):
セキュリティを教えることはできます。X、Y、Z のトレーニングを実施することもできます。大学のカリキュラムも教えることはできます。しかし、好奇心は教えることができないのです。そして、セキュリティは、誰もが同意するように、日々変わりゆくものです。今日から明日に向かう中で刻々と変化しています。好奇心があれば、さまざまな反応に適応できます。ある日、X という脆弱性が発生したとして、翌日には同じ脆弱性が X ではなく、Y になります。好奇心が十分に強く、「よし、詳しく確認して、このボタンをクリックしてみよう」と考え、それができるのなら、私にとってはそれが最も重要な採用の理由となります。

そのため、私は人を採用する際に、非常に興味深いテストを用います。「ハングリー」「謙虚」「スマート」という 3 つの単語を示し、そのうちどれを最優先するか、ランク付けしてもらうのです。そして、その人がチームにどのようなダイナミクスをもたらすかを必ず私が理解します。私のチームは全員が「スマート」な人で、その全員が同じ部屋にいるとすると、誰もが隣の人よりも自分が「スマート」だと思っているので、物事が進みませんよね? 「謙虚」なメンバーのみのチームでは、セキュリティが軽視されるでしょう。なぜなら、気を悪くしないでほしいのですが、「そうですね。今日ではないですか? では、明日やりましょう。明日でもないですか? では、後で対応しましょう」ということになるからです。 また、メンバー全員の最大の特性が「ハングリーファースト」である場合、毎回全員を昇進させることはできません。

そこで、面接では実際に座って、最初に「皆さんのハングリーさ、謙虚さ、スマートさを示してください」と応募者に言い、同席している人たちに「これらの人々の最も強い特性は何だと思いますか?」とたずねます。 そして、チームの正しいバランスを保ちます。チームの適切なバランスを取り、金融、小売、SaaS、暗号通貨などのエコシステムに応じて、特定の属性をより高くする必要がある場合があります。業界によっては、特定の属性をわずかに低くする必要がある場合もあります。これが、私がセキュリティ組織内でチームを構築したり、チームメンバーを採用したりする際の考え方です。

Clarke Rodgers (11:18):
つまり、ここで重要な要素はチームの多様性だということですね?

Aman Sirohi 氏 (11:23):
まさにそのとおりです。私のチームは、カナダや東海岸だけでなく、世界中にいます。メンバー全員にベイエリアにいてほしいですか? 同じオフィスにいてほしいですか? 答えは「はい」ですが、ご存知のとおり、それは現実的ではありません。そのことは COVID を通じて理解できたと思います。多様性、経験、好奇心は、異なる考えを持つ人々と出会ったときにのみ意味があるのだと思います。

Clarke Rodgers (11:45):
すばらしいお話です。最近、生成系 AI ツールがニュースで頻繁に取り上げられています。ますます多くの人々、そしておそらく多くの企業がこれらのツールを利用するようになっていますが、セキュリティの観点からはどうお考えですか?

Aman Sirohi 氏 (12:04):
これは、私たちの想定を超えるイノベーションになると思います。イノベーションが次々に起き、ツールが高速で革新されリリースされるため、多くのセキュリティ対応が必要になるでしょう。

私たちは、規模の拡大やオープンソースツールの活用などいろいろ試していますが、すぐに AI のリスクに直面することになるでしょう。会社やお客様にとって、このリスクはどのようなものでしょうか?

私が知っているどの契約でも、サードパーティーのデータが使用環境を離れてサードパーティーのソースに移動することはできないと規定されています。他方、使用する AI モデルにかかわらず、そのデータは今では使用環境を離れてサードパーティーのソースに移動し、そこから返されて何らかの回答を提供しています。したがって、法的な観点や、お客様や企業がリスクをどのように考えるのかについて、多くの変化が生じるだろうと思います。この分野では多くのイノベーションが起こると思います。

Clarke Rodgers (13:08):
そのリスクとは、これらのサービスの「ブラックボックス」に関するものですか? 具体的にはどのようなリスクが懸念されますか?

Aman Sirohi 氏 (13:17):
両方です。つまり、何がわからないのかがわからないのでブラックボックスだと考えています。

Clarke Rodgers (13:22):
そうですね。

Aman Sirohi 氏 (13:23):
興味深い点の 1 つとしておそらく同意してもらえると思いますが、一度何かを教えたら、翻意して「削除しろ」とは言えないということです。そうですよね? 翻意してモデルからそれを取り出すのは非常にコストがかかります。これが今後直面する落とし穴です。なぜなら誤った情報が提供されることでモデルのバランスが崩れ、これに対処すべきことになるのは確実だからです。

企業はこの AI ツールにどのようなデータを提供するかを慎重に考えなければならず、この点でリスクが生じると考えています。さて、その AI ツールは公開されているのでしょうか? 私たちは皆、自宅の中に AI を導入するつもりなのでしょうか? すべてを整理する必要があると思います。

物事は、私たちが想定していないスピードで進んでいます。企業の観点から、それにはどのようなリスクがあるのでしょうか? 一つ言えるのは、規制に関しては、私には何の見当もつかないということです。これに関しては、規制機関が必須のガードレールを設ける方法を見つけるために、どのようにこれを理解していくかさえ、想像がつきません。規制がなければ、無法地帯となってしまいます。

Clarke Rodgers (14:27):
基本的に、リーダーは、ビジネスの一環としてこれらのツールを使用することに同意する場合、引き受けることになるリスクを理解する必要があるということですね。

Aman Sirohi 氏 (14:35):
そのとおりです。また、別の部門にいる人がこれらのツールのいずれかをダウンロードして情報をフィードし始めた場合、どのように制御するのでしょうか? その情報はどこに行くのでしょうか? 現在、誰かがこの AI モデルにこの情報をフィードし、それがポリシーに違反していると警告するツールはありますか?

Clarke Rodgers (14:55):
つまり、それらの場面でセキュリティが必要となるということでしょうか?

Aman Sirohi 氏 (14:58):
はい。セキュリティを強化すべきさまざまな機会が存在すると思います。環境にとっても良いことだと思います。

Clarke Rodgers (15:05):
同じトピックについて、今から 5 年後にこの会話をするとしたら、私たちの会話の内容はどのようになるでしょうか?

Aman Sirohi 氏 (15:13):
私たちの苦労や普段の仕事のすべてが、どのように私たちのために処理されているのかについて話していると思います。最近読んだ記事では、これらのツールの 1 つにアクセスした人が、こう話しかけます。「ワインの産地への旅行を計画しています。子ども連れで楽しめる必要があります。予算はこのくらいで、X、Y、Z が必要です」。 そのツールはすべてのタスクを実行し、ボッチャを楽しめる場所を見つけて、E メールを送信して予約し、カレンダーにその情報を入力しました。

以前は、さまざまなワイナリーに電話をかけ、Google でさまざまなワイナリーを検索し、あるいは何らかの検索エンジンを使用して何かを調べる人が必要でしたが、それらはすべてツールによって処理されることになるでしょう。したがって、5 年後に私たちが何にフォーカスしているかを知るのは、とても興味深いことだと思います。このデータを解釈するのは人間だと思うので、単に自動化されて、何の規制もなく利用できる、というわけにはいかないでしょう。誤った道に進まないように、重要なステップごとに人間の介入が必要になると思います。

Clarke Rodgers (16:19):
では、そのトピックについて、取締役会とはどのように会話することになるでしょうか? どのような内容になるでしょうか?

Aman Sirohi 氏 (16:24):
私たちは、既に社内で対話を始めています。私たちにはポリシーがあります。私たちには原則があります。これは簡単なことではありません。しばらく時間がかかるでしょう。正直に言うと、ご質問に対する良い答えは持ち合わせていませんが、この点についてはさらなる会話が必要であると考えています。私たちは CISO の考え方を持つべきなのです。CISO の考え方とは、「これにどのように取り組んでいますか? これをどのように規制するつもりですか?」というものです。 なぜなら、私たちがより多く話し合うほど、お互いを守り、敵を寄せ付けないことが容易になると思うからです。敵対者もこのツールを利用するでしょうから。

Clarke Rodgers (16:57):
あらゆる人がこの機会を活用できるのですね。

Aman Sirohi 氏 (16:58):
そのとおりです。

Clarke Rodgers (17:00):
それでは、締めくくりとして、他の CISO へのアドバイスはありますか?

Aman Sirohi 氏 (17:03):
むしろ、他の CISO からアドバイスをもらいたいですね。私からお伝えするとすれば、ビジネスにより近づくということです。これは、私が自分自身で、そして同僚グループからも学んだことの 1 つです。CFO、CRO、Chief Product Officer、Chief Strategy Officer との会話に参加する必要があります。これらの役職の人々に近づくことが、何が利益を生み出しており、何が会社を守っているのかを理解するのに役立つからです。

そして、その会話に参加し、自らの能力を活用して、これらの人々の目標達成をサポートできれば、より多くのお客様を獲得できるでしょう。この次に予算を求める際に、人々は理由を理解してくれるはずです。したがって、私のアドバイスは、それらの人々のグループにより近づき、ビジネスやビジネスドライバーを理解するということです。これにより、CISO は仕事をより円滑に進められるでしょう。

Clarke Rodgers (17:55):
すばらしいアドバイスですね。

Aman Sirohi 氏 (17:57):
私も努力しているところです。まぁ、成功する日もあれば、そうでない日もありますよね。結果を待ちましょう。

Clarke Rodgers (18:03):
すばらしいです。Sirohi さん、本日はお時間をいただき、ありがとうございました。

Aman Sirohi 氏 (18:05):
こちらこそ。どうもありがとうございました。