ViacomCBSのPhil Guimond氏と語る、セキュア開発における可視性、スケーラビリティ、関係構築

先日、ViacomCBSのプリンシパル・クラウドセキュリティアーキテクトであるPhil Guimond氏と話す機会がありました。彼は自分の役割を、「あらゆること」に関わるのが好きなことを、少し格好よく言ったものだと説明しています。これには、クラウドセキュリティとアーキテクチャ、アプリケーションセキュリティ、ペネトレーションテスト、デジタルフォレンジックとインシデント対応に加え、ときにはベンダー評価やリスク管理も含まれます。彼は非常に部門横断的なチームで働いています。

とても有意義な話ができたので、皆さんにも共有したいと思います。セキュリティプラクティスや現代のセキュア開発への取り組み方などについて話しました。私と同じように楽しんでいただければ幸いです。

まず、Philにセキュリティに対する基本的な考え方と、情報セキュリティプログラムを構築するうえで最も重視すべきことを尋ねました。

Guimond: 私の情報セキュリティへの取り組み方の軸は、可視性、スケーラビリティ、そして関係構築です。これまで一緒に働いてきた多くの素晴らしい人たちのおかげで、年月をかけて培ってきた考え方です。なかでも、優れたメンターであるストリーミング部門のCISO、Jonathan Keithには感謝しています。コンサルタントとしてインシデント対応に携わっていたここ数年、情報が多く欠けていることに気づきました。ログも何もない……。ほぼ常に手探りで、問題の特定には標準的なCLIツールだけに頼らざるを得ませんでした。インシデントのたびに真っ先に勧めていたのは、可視性を確保するための適切なロギングシステムを構築することです。何を守るべきか、侵害された場合に何が起きたのかを把握できなければ、セキュリティツールにどれだけ投資しても意味がありません。何が起きたか見えないのに、何を守るべきか分かるでしょうか。

可視性は、組織全体のリスクやインサイトに優先順位をつけるための重要な指標としてよく使われます。Philが日々の業務で可視性データをどう活用しているのか、ぜひ聞いてみたいと思いました。

Guimond: 可視性があれば、古い脅威、新しい脅威、出現しつつある脅威など、どこで発生した問題にも迅速に対応できます。可視性を活用してできることは実に多く、ときには驚くほどです。新たな事象に遭遇したとき、可視化ツールが何が起きたかを正確に示してくれるのは、間違いなくエキサイティングです。可視性は、インシデント対応、ペネトレーションテスト、アプリケーションセキュリティ、クラウドセキュリティ、リスク管理、脆弱性管理など、ほぼあらゆる業務を大きく改善します。

侵害されたオープンソースライブラリを使ったサプライチェーン攻撃や、オープンソースライブラリの脆弱性が発生した場合、どのアプリケーションがそのライブラリを使用しているかを把握し、プロジェクトからすばやく削除したり、アップグレードしたり、自分たちで修正したりできます。クラウドやネットワークのインフラが侵害された場合は、攻撃の発生源や攻撃者が標的のリソースで何をしたのかをすばやく特定できます。そして何より、どのような不適切なプラクティスが侵害につながったのかを把握できます。その後、インフラから該当するリソースを簡単に隔離し、不正な操作を一度にすべて排除できます。従業員のノートPCが侵害された場合も、攻撃者が認証情報を使って何をしたのか、どのリソースにアクセスしようとしたのかを確認できます。

大規模な情報セキュリティプログラムを構築する際には、できる限り多くのことを可視化することが重要です。どのテクノロジーを使っているか、プロジェクト内にどのオープンソースライブラリがあるか、IAMポリシー、バケット、コンテナ、Infrastructure as Codeなどを含むクラウドインフラ全体を把握する必要があります。

問題のすべて、あるいは大部分を把握できることは非常に大きな意味を持ちます。優れたプラクティスによってより良い成果を上げているチームと、そうでないチームを見分けられます。ベストプラクティスを実践していないチームを見つけたら、連絡して支援する絶好の機会です。エンジニアがベストプラクティスを取り入れると、脆弱性の大半はみるみる減っていきます。さらに、エンジニアに実践的なトレーニングを提供できるという利点もあります。もちろん、可視性だけでは十分ではありません。大規模に問題を修正できなければ、いつまでも火消しに追われることになります。

私にとって重要なのは、最後の2点です。1つ目は、目標は問題を見つけることだけでなく、発見した問題に対処することだと認識すること。2つ目は、スケールできる体制を整えることです。組織全体のデータを活用すれば、各プロダクトチームの状況やカバレッジを把握し、そのデータをリスク評価に役立てられます。準備が整わないままチーム間で拡大すれば、ベストプラクティスではなく、苦労を共有することになりかねません。Philにとってスケーラビリティとは何かを尋ねました。

Guimond: 私にとってスケーラビリティとは、一度の対応であらゆる問題を解決できることです。たとえば、複数のプロジェクトチームが同じ特定の機能を必要としているとします。同じことを行うコードベースが十数個あり、それぞれに固有の脆弱性や課題を抱えているなら、問題を解決する最も簡単な方法は、共通のプロジェクトを1つ開発し、各チームに使ってもらうことです。できるだけ少ない手順とプロジェクトで、できるだけ多くのチームに対応できるソリューションを目指すのです。その一環として、ベストプラクティスを活用し、より良い成果を生み出すことも大切です。

また、可視性なしに真のスケーラビリティは実現できないと強く信じています。何を守るべきか見えないのに、どうやって守るのでしょうか。そもそも、それが存在することを把握しているでしょうか。長年その会社で働いて得られる豊富な内部知識がない限り、ほとんどの場合、把握できないでしょう。その知識を持つ人が退職したり、突然いなくなったりしたらどうなるでしょうか。すべての情報が一気に失われます。それでも、プロジェクトに潜む脆弱性について十分な知見は得られません。このやり方では、まったくスケールしません。

スケーラビリティが不足すると、セキュリティチームも、協力するエンジニアもすぐに手いっぱいになります。あなたにも開発者にも、このやり方に割く時間はありません。現在のペネトレーションテストの進め方も、スケーラビリティに関する大きな課題を抱えています。攻撃者は、テストの対象範囲や、検査したわずかな領域など気にしません。ペネトレーションテストを否定しているわけではありません。絶対に必要だと思います。しかし、標準的なペンテストは高額で、まったくスケールしません。クラウドファーストの今日の環境では、インフラ全体を対象とするペンテストが不可欠です。そして、継続的に実施しなければなりません。 

Philが話したように、準備が整わないまま急速に拡大したり、まったく拡大できなかったりすると、特にプロセスやドキュメントなどがスケールに対応できていない場合、セキュリティチームは手いっぱいになります。そこで、Philがどのようにしてスケールを実現したのかを尋ねました。

Guimond: 可視性を最優先するアプローチと、ツールを統合した単一の管理画面によって実現しました。ありきたりに聞こえるかもしれませんが、本当に効果があります。エンジニアの仕事を難しくするのではなく、楽にすることが大切です。プロジェクトを守るために25種類ものセキュリティツールを使わせるのは、ばかげたやり方です。そうすれば、絶え間ない反発やスケーラビリティと可視性の欠如につながり、事業部門がセキュリティチームと協力する意欲も大きく損なわれます。

最小限のツールでできるだけ多くの問題に対応し、しかもスケールできる方法でエンジニアの仕事を楽にできれば、より良い成果を上げられます。それも、はるかに良い成果です。それは可視性の向上につながり、ひいては大規模な脆弱性管理を可能にします。従来の脆弱性管理はスケールしません。クラウドコンピューティングの時代には、もはや通用しないのです。ベストプラクティスを実践すれば、ほとんどの問題を解消できます。残る問題については、大幅なアーキテクチャの再設計をせずに修正できない場合に備えて、代替となるコントロールを構築することが重要です。

組織の可視性を高めるために、どのようなベストプラクティスを実践すべきか、Philに尋ねました。

Guimond: ツールの統合と削減です。不適切なプラクティスを明らかにするだけでなく、できるだけ少ない手順と製品で修正できるツールが必要です。セキュリティチームや開発者に実質的な価値をもたらさないツールもなくす必要があります。1つのツール、あるいは一連のツールだけを担当する人を採用すると、サイロ化につながり、スケールしないセキュリティアプローチを招くことがあります。

チームはできるだけ部門横断的にしましょう。担当業務に加えて、メンバーが力を発揮し、さまざまな分野に取り組めるようにします。個々のメンバーが一日中会議に出ていては、何も進みません。自社のダッシュボードと同じ情報を提供できる、堅牢なAPIを備えた製品を提供するベンダーと協力しましょう。

ツールを統合する方法としては、インフラの大部分を1つの製品で保護するベンダーと協力するのがよいでしょう。たとえば、オープンソースライブラリ、コンテナ、SAST [static application security testing]、Infrastructure as Code、クラウドインベントリなどです。そして、こうしたデータをすべてダッシュボードに集約し、単一の画面、または可能な限り少ない画面で表示します。アプリケーション、ネットワーク、インフラ、プロジェクトなどのカテゴリ別に、問題を掘り下げて確認できることが重要です。

支援やルールの徹底を担う人、あるいは実際に作業をして物事を進められる人たちから賛同を得ることが重要です。組織全体の可視性を高める取り組みを始める前に、誰から協力を得るべきか迷っている人に向けて、Philならどのようなアドバイスをするか尋ねました。

Guimond: 協力的な情報セキュリティチームをつくるなら、まず支援対象のチームや事業部門と関係を築く必要があります。連絡を取り、ミーティングを設定し、Slackでメッセージを送るなど、自分に合った方法で話をして、相手が抱えている課題を把握しましょう。課題が分かれば、どう支援できるかも見えてきます。特定のチームが過去にセキュリティ上の問題を抱えていたなら、その問題を解決できる方法を考えることが大切です。そうすれば、開発者は耳を傾けてくれます。

チームのディレクター、マネージャー、開発者、エンジニアの話を聞き、相手の視点を理解することが非常に重要です。特に、自分とは異なることの多い視点を理解する必要があります。他の視点を受け入れず、すべてを「自分のやり方に従うか、さもなくば去れ」という姿勢で臨めば、誰も協力したがらず、情報セキュリティプログラムの成果も悪くなります。しかし、関係を築ければ、必要な賛同を得るのは難しくありません。相手は、あなたが気軽に相談できる存在で、過度に干渉しないことを知っているからです。そのうえで、ベストプラクティスとツールセットを取り入れてもらいます。

最後に、自分の組織でセキュリティチームとプログラムを立ち上げようとしている人に、どのような一般的なアドバイスをするか、Philに尋ねました。

Guimond： 多様なバックグラウンドを持つ、部門横断的なチームを採用しましょう。自分とは異なる経験を持つ人は、物事を違った視点から見るものです。さまざまな視点を理解することで、全員が専門性を高め、チームのイノベーションを維持できます。たとえば、まったく同じニーズを解決するプロジェクトを20個抱えていたチームと話したことがあります。各チームがそれぞれ独自のコードベースを使い、どのコードベースにも脆弱性がありました。そのため、問題を一つずつ修正しようとしていたのです。そこで私は、このプロジェクトに共通する脆弱性をどのように修正するかを具体的に示しました。すると、意外な答えが返ってきました。共通のニーズに対応する単一のプロジェクトを作り、各チームがそれを使えるようにしたというのです。これにより、複数のコードベースを行き来して対応する必要がなくなり、20個のプロジェクトをそれぞれペネトレーションテストする必要もなくなりました。今では、テストするのは1つだけです。聞き覚えがありますか？先ほど紹介した例です！

ですから、柔軟な姿勢を保ち、ほかの人のやり方に耳を傾け、どの会社でも同じことを繰り返せばよいと思い込まないことが大切です。会社もチームも、それぞれ独自のものです。

部門横断的なチームが重要な理由については、支払うだけの価値がなくなったツールをいくつか廃止したらどうなるか、考えてみてください。それまでそのツールを担当していたチームは、別の役割を担う必要があるかもしれません。ほかのスキルもすでに身につけていれば、変化にもずっと迅速に対応できます。情報セキュリティの分野は常に変化しています。こうすることで、別の職場に移ることなくキャリアを伸ばし続けられ、セキュリティチームの適応力も高まります。

もちろん、全員が何でもこなせる人になるべきだと言っているわけではありません。ただ、複数のチームメンバーが、主な専門分野を持ちながら、複数の役割を担えると大いに役立ちます。これは、チームの新たなスキル習得を後押しし、研修の機会を設ける絶好のチャンスです。ほかの分野を学び、専門性を高められるチームであれば、より多様な人材を惹きつけることにもつながります。

チームに一つのことだけをずっと担当させてはいけません。そうすると、メンバーの専門性を損ない、情報セキュリティプログラムの成長も妨げます。マネージャーとしてそれを許してしまえば、メンバーと会社の期待を裏切ることになります。役割を固定化してキャリアの選択肢を狭めた結果、情報セキュリティプログラムも自ら定めた限界に縛られてしまいます。そして時間が経つにつれ、技術的負債によって死角が増え、拡張性が低下し、脆弱性もさらに増えていきます。