Clarke Rodgers:
非常に興味深いですね。あなたは AWS でセキュリティプログラムを立ち上げたので、AWS のセキュリティ、それに対する脅威、リスク選好など、AWS のあらゆる側面を熟知されています。CSO に就任されたことで、amazon.com、社内ではストアと呼んでいるもの、Whole Foods、Prime Video、MGM、Twitch など、さまざまな組織について学ぶことになりましたね。
まず、それぞれの事業のセキュリティプロファイルとリスクアペタイトをどのように把握し、どのようにそれらを統合したのでしょうか? いわゆる「single pane of glass」(1 枚のガラス) で、「Whole Foods のリスクプロファイルは適切だ」、「AWS のリスクプロファイルも AWS にとって適切だ」と言えるようにするために、どのように取り組んだのでしょうか?
Steve Schmidt:
まず、私の仕事で気に入っていることの 1 つは、事業の多様性です。周りからはよく次のように言われます。「あなたは 16 年間も今の仕事をしていますよね。セキュリティ業界では異例のことです。何故ですか? 」。この会社の仕事の多様性がその答えです。この仕事は学び続ける機会そのものであり、それが私にとって大きな魅力となっています。
私はそれほど若くはありません。人々は次のように言います。「いつまで働くのですか?」、 「引退するのですか?」など。 私は次のように答えます。「楽しんでいるんだ。引退なんてしたくないよ。本当に楽しい仕事だからね」。なぜなら、世界最大級のクラウドプロバイダーの構築から、宇宙への衛星の打ち上げ、食料品店の経営まで、幅広い業務に携わることができるからです。この仕事の多様性は、ビジネスの観点から見ると非常に大きな挑戦ですが、同時に、会社の規模を活かして運営コストを削減できるという、興味深い機会でもあります。
セキュリティ組織の運営について言えば、それらにはある程度のコストがかかります。しかし、Amazon のような大規模な企業全体でスケールできれば、単価を下げることができるのです。
Clarke Rodgers:
なるほど。
Steve Schmidt:
つまり、あらゆる事業が他の事業の規模から恩恵を受けるということです。したがって、食料品店が衛星事業と同じセキュリティを活用できる方法を見つけることが重要です。実際、これは多くの領域で可能なのです。例えば、脆弱性管理やコンピュータシステムに対するパッチの適用などは、衛星の構築と食料品店の運営で根本的に変わりません。
そのため、当社は単体の事業では到底実現できないレベルのセキュリティを実現し、あらゆる人々のために水準を高めることができます。そして、それがここでの私の仕事の一部なのです。すなわち、脆弱性管理、インシデント対応、一般的なセキュリティ組織を構成する他の要素などについて、会社全体で標準化された水準を確立するということです。
それから、それぞれの事業の固有の状況に応じて、どのようなカスタム要素を導入する必要があるのかを検討します。これにより、画一的な対策をあらゆる場面で適用しようとするようなことを避けることができます。そんなことをすれば、コストが急増してしまうからです。例えば、食料品店のビジネスであれば、1 店舗を失っても比較的小さな損失で済みますが、衛星を 1 基失うような場合はまったく逆で、大きな損失となります。
Clarke Rodgers:
なるほど。
Steve Schmidt:
ですから、個々の要素に合わせてセキュリティの状況を調整する必要があるのです。
Clarke Rodgers:
どのように...言い直しますね。各事業のセキュリティプログラムを運用する Chief Information Security Officer がいますよね。これらの Chief Information Security Officer にセキュリティ事業の運営責任をどのように負わせているのでしょうか?
Steve Schmidt:
Amazon が全社的に重視していることの 1 つに、シングルスレッドオーナーという考え方があります。これは、ある特定の要素にのみ注力する役割を担う人物を意味します。セキュリティにおいて、各事業に CISO を配置しているのは、2 つの理由からです。
1 つは、デバイスと Kuiper を担当する Amy Herzog であれ、AWS を担当する Chris Betz であれ、日々そのことに集中的に対応する人物を私が必要としているからです。しかし、同時に、私はそれらすべてに共通の指標を用いています。例えば、私は、全社を対象とする脆弱性管理に関する月次ビジネスレビューをチェックしています。そこでは、同じ数値、同じ手法、同じプレゼンテーション方法などが用いられています。
これにより、すべての事業で一貫した共通の視点を持つことができます。そして、それによって 2 つのことが可能になります。1 つ目は、当社が求める水準を満たしていることを確認すること、そして 2 つ目は、ビジネスの隅々まで、必要な可視性が確実に得られるようにすることです。なぜなら、よくある問題として、人々は「これは重要ではない。些細な部分だ」などと考えてしまうからです。
そして、そこから悪意のある人物が侵入し、当社全体が被害に遭うのです。したがって、あらゆるものを 10,000 フィートの高さから監視することで、会社のあらゆる部分で必要な対策を確実に講じることができるようにしています。
Clarke Rodgers:
そして、Amazon Security (AMSEC) のもとで、誰もが活用できる一元的なシステムを設けていますね。
Steve Schmidt:
当社のすべての事業にわたって、多くのことが基本的に同じです。特定の種類のデータの収集方法、そのデータの分析方法、そのレポート方法はその一例です。そのため、個々の事業ごとに同じことを何度も繰り返すのではなく、それらを 1 か所に集約することにしたのです。これにより、デベロッパーの時間などを節約できます。
大規模な運用を考えた場合、脆弱性管理の話に戻ると、収集エンジンにはオンコールのエンジニアが不可欠です。あなたもオンコール対応組織を運営したことがあるのでおわかりかと思いますが、休暇やその他諸々を考慮して、オンコールを 1 人確保するとしても、効果的に運用するには約 7 人必要です。
Clarke Rodgers:
当社は従業員に休暇を取ってもらいたいと考えていますからね。
Steve Schmidt:
そうです。これを複数の事業に一元的に展開することで、より効果的なツールを一元的に、より低コストで利用できるため、より効果的に運用できるようになるのです。
Clarke Rodgers:
これらの多様な事業全体のセキュリティの状況を Amazon の取締役会に報告するために、どのような方法を開発または実践していますか?
Steve Schmidt:
まず、Amazon の取締役会は本当に興味深いですね。Amazon の取締役会ほど、全メンバーが技術的な見識を備えている取締役会はほとんどないでしょう。さらに、Amazon は数年前にセキュリティ小委員会を設置することを決定しました。そのため、例えばセキュリティ部門が監査委員会に報告する多くの企業とは異なり、Amazon の取締役会にはセキュリティのみを専門に扱うグループが存在します。
それはすばらしいことです。そしてそれは、その過程で私たちの活動が厳しく精査されることも意味します。そのため、私たちは報告メカニズムを構築する必要がありました。これは時間の経過とともに進化してきました。それには 2 つの理由があります。1 つは、私たちがより良いかたちで報告業務を行えるように改善しているからです。もう 1 つは、取締役会が時間が経過する中でより情報に精通するようになるからです。取締役会のメンバーは、より鋭い質問をし、事業のニッチな領域についてより具体的な詳細を知りたがるようになっています。私たちは一般的に、取締役会に報告する際には必ず、事業の具体的な部分について報告することが重要だと考えています。「特定の分野でセキュリティの水準を満たしているか?」ということです。
さらに、取締役会のメンバーは非常に関心のある事柄を持っており、「事業のこの特定の部分について教えてほしい」、あるいは「当社が取り組んでいるこの事業には多くのリスクがあると考えているので、概要を説明してほしい」など、さまざまな要望が出されます。そのため、私たちは、定型的な部分と、取締役会の関心に応じた部分の両方を報告しています。
また、報告の最後には「時事問題」という項目を設けることにしています。この項目では、ニュースで取り上げられたすべての情報を、当社にとって特に教訓となる点やポイントに絞り込み、取締役会に有益な情報として提示しています。「業界ではこのようなことが起こりました。当社はこのような理由で影響を受けませんでした。
この投資により、影響を受けずに済みました」というようなことを報告するのです。これは取締役会にとって非常に大きな価値があると考えています。第一に、取締役会は当社に問題がないことを理解してくれますし、第二に、将来の投資判断の材料にもなります。例えば、私たちが報告の中で、8 年前、あるいは 10 年前に多要素認証に投資したことにより、他のある大企業に侵入したこの特定の脅威アクターが、当社に影響を及ぼすことを防ぐことができたと言うことで、取締役会は、「なるほど。すばらしい。では、10 年経っても問題を回避し続けるために、今計画しておくべき他の投資は何だろうか」と聞いてくれるのです。
Clarke Rodgers:
当社の CISO のお客様の多くは、取締役会を重視しています。中には、取締役会に直接参加して話す機会があまりない人もいます。また、既におっしゃっていたように、当社の取締役会はセキュリティに精通しているという点で他に類を見ない存在です。意見を効果的に伝えたり、取締役会の言語で話したりすることについて、取締役会に報告する CISO や CSO にどのようにアドバイスしますか?
Steve Schmidt:
私たちのやり方を好ましく思う理由として、取締役会のメンバーから最もよく聞くのは、専門用語の使用を極力避けているということです。CISO の役職に就く人の多くは技術畑出身で、報告する際にはつい...
Clarke Rodgers:
技術的に細かくなってしまいますよね。
Steve Schmidt:
まさにそのとおりです。自らの考え方を反映してしまうのです。しかし、ここでは取締役会がお客様であることを忘れてはなりません。取締役会にプレゼンテーションを行う際には、取締役会の言葉で話し、その取締役会にとって理解しやすい文脈で説明する方法を見つける必要があります。
第一に、毎回報告方法を変えるのではなく、一貫した報告方法を確立することです。毎回変更すると、基本的には理解が難しくなりますから。第二に、毎回必ず伝えたい、本当に重要な 2 つか 3 つのメトリクスを明確にすることです。
メトリクスの海で取締役を溺れさせないでください。例えば、私たちは脆弱性管理について毎回報告しています。これは、当社が運用している、そしてあらゆる企業が運用しているであろう、最も重要かつ基本的なセキュリティコントロールです。そして、投資すべき項目を見極めるのに役立つ、最後に追加すべき他の興味深い項目は何かを検討します。そして、報告プロセスの構成要素を意図的に分離する必要があります。
Clarke Rodgers:
そして、ここに投資すれば、ここでリスクが軽減される、というようなことも含めるのですね?
Steve Schmidt:
はい。これは現在のリスク軽減と将来を見据えたリスク軽減の両方を組み合わせたものです。そして、将来を見据えた対応は、セキュリティプロフェッショナルとしての私たちの仕事の中で最も難しい部分かもしれません。前例がありませんからね。多くの人がそれを見て、「それは本当に必要ですか?」、
「今すぐ実行する必要がありますか?」、 「それほど大規模に実行する必要があるのでしょうか?」、 「もう少し小規模に実行できませんか?」とたずねます。 これらは私たち全員で議論すべきことであり、時間をかけて取締役会でナレッジベースのようなものを構築していく必要があります。そして、「これらは現実世界での悪用事例です。これくらいの時間で当社にも影響が生じるでしょう。そのため、今すぐ、2～3 年のうちになど、ある時期に行動を起こさなければなりません」と言う必要があります。
Clarke Rodgers:
よくわかりました。Amazon は、イノベーション、Working Backwards、お客様の声に耳を傾ける、などで知られています。セキュリティリーダーであるあなたには、あなたに報告する CISO の意見にもよるのかもしれませんが、どのツールを購入し、どのツールを自社で構築するかについて、多くの選択肢がありますね。多くの場合、スケールについて考慮する必要があります。
つまり、市販のソフトウェアが Amazon のスケールに対応できるかどうか、自社で構築する必要があるのかを検討する必要があります。昨年、私たちは、MadPot、Mithra、Sonaris などのツールについて公に議論してきました。CSO として、これらのツール、そしておそらくまだ議論していない他の多くのツールの背後にエンジニアリングリソースを割り当てる資金を確保するために、どのように提案すればよいでしょうか?「これは投資に見合う価値があり、これらのツールからはこのような価値を得ることができます」と説得するにはどうすればよいでしょうか?
Steve Schmidt:
はい。まず、購入するツールと自社で構築するツールを区別しましょう。これは重要な出発点だと思います。私たちは、コモディティ化しているツールは購入します。例えば、エンドポイント検出機能は、自社で構築するのではなく、購入しています。なぜですか? 当社が使用している Mac、Windows、Linux のノートパソコンは、他の多くの人が使用しているものと同じだからです。
インストールされているソフトウェアは多少異なるかもしれませんが、それが当社のビジネスの差別化要因になるわけではありません。一方、MadPot などの非常に大規模なシステムを構築できるのは当社だけです。当社は構築できるが、他社は構築できないものに、当社は投資する傾向があります。
当社の投資プロセスは、当社が行う他の多くのことと似ています。プロトタイプを作成し、試用して、何がうまくいくかを確認します。最初からうまくいくとは限りません。そのため、再構築したり、少し変更したりするなどする必要があります。現在、MadPot は驚異的な成功を収めていますが、一夜にして生まれたわけではありません。長年にわたる投資の成果なのです。それは、「このアイデアは本当にいいな。何か面白いものが生まれるか試してみよう」と言ったあるエンジニアから始まりました。
そして、極めて適時の脅威インテリジェンスデータを取得し、それを抽出および処理して、すべてのお客様がアクセスできるセキュリティツールにフィードすることを可能にするこのエンジンが生まれたのです。私は、これが最も重要な部分だと考えています。例えば、多くのお客様から「生の脅威インテリジェンスフィードが欲しい」という声が寄せられます。
しかし、実際にはそうではありません。そのようなお客様が本当に必要としているのは、現在の業務のコンテキストで関連性のある情報なのです。それ以外の情報は単なるノイズで、現在その量は膨大であるため、当社のような規模の企業でない限り、すべてを理解しようとするのは無意味です。
そのため、当社の多くのお客様は、脅威インテリジェンスのようなものをマネージドサービスの一部として利用することに非常に満足しています。また、これにより、膨大なデータの山をふるいにかけるために時間を費やす必要がなくなりますし、複数の顧客にわたってコンテキストが適用されていないためにそのコンテキストが欠けてしまうという事態も避けられます。
コンテキストが重要なのです。コモディティ化とカスタムビルドという最初の議論に立ち返れば、まさにその点で、当社だけが持つ一元的な可視性が真のメリットをもたらしてくれるのです。
Clarke Rodgers:
これが適切な言葉かはわかりませんが、社内向けプレゼンでは、「これは AWS/Amazon 全体のセキュリティ強化に役立つし、お客様にも恩恵があります」と伝えるのでしょうね。「したがって、これは成功につながります」と。
Steve Schmidt:
はい。Amazon の言葉で言えば、お客様を第一に考え、「これはすべてのお客様のセキュリティ強化に役立ちます」ということです。同時に、私たちのビジネスにも役立ちます。なぜなら、私たちのビジネスのほとんどは Amazon/AWS のお客様だからです。つまり、あらゆる面で恩恵があるということです。