セキュリティオーナーシップを組織全体に拡張する

Clarke: (00:05)
Megan、今日はご参加いただきありがとうございます。

Megan: (00:07)
こちらこそ、ありがとうございます。

Clarke: (00:08)
まずは、ご自身のバックグラウンドと AWS に入社した経緯について簡単に教えていただけますか。

Megan: (00:13)
私は、病院のネットワークセキュリティスペシャリストとして、15 年を超える期間にわたってさまざまなセキュリティ業務に従事してきました。その後、シアトルを拠点とするグローバルな小売業者に入社し、さまざまなセキュリティエンジニアリングやアーキテクチャの業務に関与してきました。そして、当時私が所属していた企業は 2014 年に AWS の顧客となり、私は同社でクラウドセキュリティ戦略の設定とセキュリティコントロールの実装に携わりました。それから、Slalom に入社し、開発部門の運用チームの一員として、北米全体のお客様が同じこと、つまり、クラウドセキュリティ戦略を設定し、セキュリティコントロールを実装することをサポートしてきました。そして、パシフィックノースウエストのエンタープライズソリューションアーキテクトとして AWS に入社し、その後セキュリティスペシャリストチームの一員となりました。

Clarke: (01:02)
素晴らしいことですね。

Megan: (01:03)
ですので、ここで働き始めて約 4 年になります。

Clarke: (01:04)
素晴らしいです。

Megan: (01:04)
ありがとうございます。

Clarke: (01:05)
働き始めたときからコンピュータサイエンスのバックグラウンドを持っていましたね。セキュリティに惹かれた理由は何ですか。

Megan: (01:12)
興味深かったのです。当初は機械工学の道を歩んでいましたが、Boeing での夏季インターンシップに 3 度参加し、767-400 ラインの工作機械の技師と一緒に働きました。私は、「もし今学校に行くとしたら何を勉強しますか」とこれらの技師に尋ねました。 その答えは「コンピュータサイエンス」でした。私は「そうですか」と言ったと思います。 そして、全員がはっきりと同じように答えたのです。そこで私は、「わかりました。では、私はコンピュータセキュリティかコンピュータサイエンスのクラスを受講することにします」と言いました。 そして、私はそれを気に入りました。とても楽しかったです。パズルを解くようなものでした。

Clarke: (01:47)
なるほど。

Megan: (01:47)
受講者の半数は、自分に合っていないという理由で、途中で受講をやめました。しかし、私は受講を続けました。選択科目の 1 つはデジタルセキュリティで、それは私にとって非常に興味深いものでした。そして、私はその科目を選択し、夢中になりました。本当に面白いと思いました。解決すべきパズルは増え続けており、常に変化しています。それから、コンピュータサイエンスの学位取得のためのシニアプロジェクトとして IDS を実際に構築しました。ネットワークパケットキャプチャを分析し、悪質なネットワークの動作を判断する小さなプログラムを構築しました。本当に楽しいことです。

Clarke: (02:21)
素晴らしいことですね。それは今、素晴らしいキャリアにつながっています。

Megan: (02:23)
そうですね。

Clarke: (02:24)
AWS でのご自身の役割はシニアセキュリティソリューションアーキテクトですね。それは何を意味するのでしょうか。 また、その役割における主な責任は何ですか。

Megan: (02:33)
私は、AWS のセキュリティでお客様をサポートします。基盤の構築方法、ガードレールの設定方法、セキュリティコントロールの実装方法についてガイダンスを提供するほか、お客様が「クラウドの運用モデルとは何か」、 「それはどのようなものか」を理解できるようサポートしています。 また、イベント、構築ワークショップ、ビルダーセッション、および社内の現場に関するお客様の教育にも携わっています。そのため、セキュリティのさまざまな側面について教育するためのプログラムをいくつか用意しています。これらのプログラムでは、お客様は社内の現場に関するエッセイに取り組みます。例えば 100 (入門) レベルのセキュリティ知識を 300 (中級) レベルまで引き上げて、顧客との会話をより効果的なものにできるようにします。

Clarke: (03:20)
わかりました。ところで、AWS には非常に強力なセキュリティ文化があり、その文化を強化するための仕組みがたくさん用意されています。特にお気に入りの仕組みはありますか。

Megan: (03:29)
もちろんあります。用意されているプロセスの 1 つに sev two の申立てがあります。社内の誰であっても、セキュリティ上の問題があると考える場合、チケットを提出するというプロセスを経ることになります。これは sev two と呼ばれます。そして、セキュリティエンジニアがそのチケットを受領し、それが問題かどうかを評価して対応を進めます。セキュリティ上の問題でなければ、問題はありません。これは素晴らしい仕組みです。しかも誰からも非難されることはありません。セキュリティ上の問題があると考えることで、心配したり、恐れたりする従業員がいないようにしたいのです。私たちは問題について知りたいと考えています。良い意味で、前向きに、問題に対応したいと考えています。そして、これはリーダーシップレベルでサポートされているのです。本当に素晴らしいことです。セキュリティトレーニングや、自分のリーダーと話す機会がある場合、誰もが前向きに考えていることが多いように思います。これまでどこにも見られなかった、セキュリティに関する透明性やオープンな態度を持つという文化が育まれていると感じます。これは非常に好ましいことであると考えています。

Clarke: (04:44)
わかりました。ところで、お客様の組織全体について幅広いレベルでやり取りしているとき、さまざまなお客様と話をする中で、独自のセキュリティ文化の構築を奨励する特定の分野はありますか。 誰からも非難されないセキュリティ文化などでしょうか。

Megan: (05:01)
そのとおりです。そして、これはいくつかの分野で見られます。私は、セキュリティチームを運営することは、ビジネスをサポートし、デベロッパーをサポートするようなものだと考えるようにお客様に勧めています。セキュリティの観点から、簡単に物事を行ったり、適切に物事を行ったりできるようにサポートすることは、道を舗装していくようなものなのです。適切なモデル内で運用され、それらのセキュリティ要件に関する透明性が確保されている場合、業務を加速することができます。そして、多くの障害に突き当たることもなくなるのです。こうしたことから、セキュリティと開発の間のこの適切なバランスが生み出され、両者の協力が実現されていると考えています。お客様の組織でこの仕組みが機能しているのを目にすると、本当に嬉しくなります。このことは、いくつかのお客様の事例で確かに実現されてきました。私からすれば、これは、セキュリティ側と開発側が連携して、互いにサポートし合うための適切な方法を提供しているだけなのです。

Clarke: (06:00)
ということは、セキュリティは「いいえ」と言う部門ではなく、実際に他部門をサポートして成功するのを支えているということですね。

Megan: (06:05)
そのとおりです。

Clarke: (06:07)
お客様のリーダーシップの観点からお聞きします。当社がお客様との関係で構築しようとしているセキュリティの文化を促進するために、企業のトップのシニアリーダーは何ができるでしょうか。

Megan: (06:20)
現状を見てみると、これまでの時代と比べてかなり変化していますよね。 セキュリティに責任を負うのはセキュリティチームだけではありません。それは不可能なのです。デベロッパーがその多くを所有する必要があります。私は「AWS とお客様の間には責任共有モデルがあります」とお客様に説明しますが、お客様ご自身で、クラウドのさまざまなセキュリティコントロールと、セキュリティの側面のすべてについての責任共有モデルを、組織の残りの部分にまで広げて、自らが何を所有しているかを従業員全員にとって透過的にする必要があるのです。

Clarke: (06:53)
なるほど。

Megan: (06:53)
そして、それらのことを簡単に実行し、簡単に正しく行えるようにサポートします。自らの組織内で責任共有モデルを広げることは、誰にとっても具体的なことであり、非常に効果的な方法だと思っています。

Clarke: (07:05)
素晴らしいことですね。ところで、多くのお客様が擁するセキュリティエキスパートの数は、自社の希望にはるかに満たない数ではないかと思います。お客様のセキュリティチームは、自らの業務の結果や影響力を他部門全体に及ぼすために、どのようなことを実行してきたでしょうか。

Megan: (07:22)
いくつかあります。第一に、実績のある適切な求職者を常に見つけることができるとは限りません。そのため、場合によっては、視野を少し広げて、「必ずしもクラウドに精通しているわけではないが、クラウドに興味を持っているセキュリティ担当者がいるなら、これらの担当者がクラウドに精通できるようになるための道を用意しよう」と考える必要があります。 また、セキュリティに関心はあるが、必ずしもバックグラウンドを持っていないデベロッパーや DevOps 担当者がいる場合は、これらの担当者がセキュリティに精通できるようになるための道を用意するのです。そのためのトレーニングを提供しましょう。また、これを実現するためのツールはたくさんあると思います。私のお気に入りの方法の 1 つは、過去の re:Invent の動画、re:Inforce、を視聴して、セキュリティの基本的なベストプラクティスに関する 30 分間または 45 分間のセッションを開催することです。特にお客様が登場する多くの動画は、お客様の実際の対応を示す非常に良い例であり、枠にとらわれずに考えることができるため、本当に役立つと思います。さらに、AWS ソリューションアーキテクトアソシエイトまたはプロフェッショナル認定は、これらの基本的な概念を習得するためのとても良い方法です。そしてもちろん、セキュリティスペシャリスト認定は非常に優れています。

Clarke: (08:39)
これまでの約 18 か月間は、誰にとっても困難な時期でした。パンデミックが発生し、在宅で勤務する人が増えました。パンデミックはクラウド採用の増加につながったのでしょうか。または減少につながったのでしょうか。 お客様はどのような状況にあるでしょうか。

Megan: (08:54)
本当に大変な時期でしたね。私が見てきた何社かの大企業のお客様は、大きく変化した状況に対処するために、クラウドの採用を増やす必要がありました。実店舗が閉鎖を余儀なくされたため、オンライン小売事業は躍進しました。そのような状況の中で、興味深いパターンがいくつか見られました。当初の基本的なセキュリティとマルチアカウント戦略に依拠している他のお客様のために、そこからいくつかの教訓を得ました。オートメーションを活用できた場合、物事は非常に円滑に進みました。より多くのアカウントを構築してオートメーションを実装できるからです。お客様は既に、これらのセキュリティ基盤を構築するためのオートメーションと、そのコントロールを備えていました。他方、自動化されていない場合は、当社がオートメーションなしで構築し、可能な限り早急に事業を強化するのをサポートすることも当然ありました。しかし、これらを手動で行うのは大変なことであり、時間もかかります。すべてが整っているようにしなければなりません。すべてのガードレール、マルチアカウントが自動化されていることは、非常に重要なのです。これは、現実世界によって、どのように物事が半強制的に進められたかを示す非常に良い例です。私が AWS の顧客として働き始めたとき、稼働している開発チームは 2 つであったことを記憶しています。6 か月後、開発チームは 20 になり、システムは本番稼働しており、他の全員がプラットフォームにオンボーディングしたいと考えていました。そのため、私は早い段階でその教訓を得ましたし、多くのお客様も同じだと思います。

Clarke: (10:31)
必要なセキュリティの水準を満たすために、見直しをしなければならなかったからですね。

Megan: (10:35)
そのとおりです。

Clarke: (10:37)
同じようなことは、セキュリティチームや、お客様アカウント内のセキュリティチームにも言えます。セキュリティは、お客様がクラウドの利用を推進するための要因となり得るでしょうか。

Megan: (10:50)
私は、セキュリティを最後に考慮する多くのお客様を見てきました。しかし、必ずしもそうである必要はないのです。オンプレミスで採用したセキュリティフレームワークやコントロールをクラウド用に更新し、マッピングを行い、本質的にそれらのガードレールを前もって備えることができれば、作業ははるかに簡単になると思います。これにより、デプロイの準備が整います。作業を急かされないほうがいいですね。メトリクスも定義できます。「早く仕事を始めましょう」と誰かが声をかけるのを待つことなく、オートメーションを設定できるのです。 また、このことは、セキュリティチームとして、セキュリティ要件について透明性を保ち、デベロッパーがどのように構築する必要があるか、セキュリティチームがどのような仕様を期待しているかを理解する機会をもたらしてくれるでしょう。繰り返しになりますが、これはデベロッパーとセキュリティの関係を改善することにもなります。より効果的かつ効率的な関係であり、デベロッパーが行おうとしているビジネス機能を実装するのに役立ちます。

Clarke: (12:10)
なるほど。セキュリティチームがデベロッパーよりも先にクラウドに関与するのを一度でも見れば、ある程度の確信と信頼が築かれるのでしょうね。デベロッパーやプロダクトオーナーは、「セキュリティチームが既に関与しているのであれば、私はもう言い訳をすることはできません」というようなことを言うのでしょう。

Megan: (12:25)
そのとおりです。お客様がセキュリティ要件を提示し、例を挙げる場合、物事は非常にうまく機能していると思います。「安全な ID とアクセスポリシーとは何か」、「安全なセキュリティグループとそうでないセキュリティグループとはどのようなものか」といった社内 Wiki などです。そして具体的な例を挙げるのです。これにより、本当にうまくいきます。そして、これがまさに私たちが話していることです。アクセスポリシーに関して、実行者とリソース管理者の対立はありません。もう 1 つは、セキュリティチームに相談できるようにすること...つまり、何らかの理由で開発チームで業務が進まなくなった場合...例えば、お客様が特定のセキュリティ要件に苦労している場合に、セキュリティチームが週に 1 回のオフィスアワーや Slack チャネルを通じてサポート可能な体制にあるとき、デベロッパーにとってプロセス全体が本当に簡単になります。何かあったときに頼れるチームです。多くの場合、以心伝心になっているので、必ずしもそこに座って、24 時間付きっきりになる必要はありません。簡単なやり取りですみます。例えば、「文書が複雑すぎる」、「何かを指定する必要がある」といったようなフィードバックが考えられます。あるいは、ホスト上でセキュリティエージェントをブートストラップするように依頼している場合は、「スクリプトを記述して、そのスクリプトをコードリポジトリで利用できるようにしてはどうですか」というフィードバックになるかもしれません。

Clarke: (14:02)
これまでに共有してくださったすべてのことに加えて、平均的なセキュリティチームは備えていないかもしれないいくつかのスキルについてもお聞きしたいと思います。従来型のセキュリティチームを見ると、どのような場合であっても、IDS やさまざまなネットワークサービスを運用し、システムにパッチを適用しているように思います。お聞きしたいのは次のようなことですが、間違っていたら訂正してください。現在のセキュリティチームは、開発サイクルがどのように機能するか、さらには自らコーディングする方法まで理解する必要があるのではないでしょうか。

Megan: (14:33)
まったくそのとおりです。おそらく...セキュリティ担当者のバックグラウンドによっては、デベロッパーのバックグラウンドや CS の学位を持っていないこともあるでしょうし、それは必須ではありませんが、わずかでも Python プログラミングを知っていることは有益ですし、CloudFormation は非常に簡単に習得できると思います。Ansible は単なる YAML 設定ファイルです。そして、バックログとともにアジャイルプラクティスを使用して、開発チームと同様に稼働することは、セキュリティの観点から優先事項を管理しているプロダクトオーナーにとって有益であると私は確信しています。デベロッパーがどのように作業するかを理解できるだけでなく、実際には常に効率的な作業方法でもあります。私が現場でセキュリティ業務に携わっていたとき、私たちはそのように作業していました。それは、特にセキュリティの観点から、物事は急速に変化し、ビジネス要件も急速に変化していたからです。何の前触れもなくスケールアップしなければならず、運用方法を変更する必要が生じました。したがって、定期的な頻度で効率的に優先順位を設定し直すのに役立ちます。

Clarke: (15:39)
つまり、組織内で「サービスとしてのセキュリティ」を提供しているのに近いということですね。

Megan: (15:44)
そのとおりです。

Clarke: (15:46)
素晴らしいです。では、少し話題を変えて、最近のニュースについてお話を聞かせてください。ランサムウェアについては、詳しく述べる必要もないでしょう。この類の話は次から次へと出てきますからね。ランサムウェアについて、お客様はどのように対応しており、そのリスク低減手法に関してお客様にどのようなアドバイスをしていますか。

Megan: (16:11)
ランサムウェアについては、過去 2 か月間だけでも、おそらく 20 回以上お客様と直接話し合ったと思います。お客様は「当社は AWS のメッセージがどのようなものであるのかを理解したいと考えています」と仰るため、私はこのような対話を楽しんでいます。 これは、お客様が当社をパートナーと考えていることを示唆しています。これは素晴らしいことです。ランサムウェアには特効薬がないため、通常、私は上位 10 位までのベストプラクティスを用意しています。強力なセキュリティプログラムと強力なセキュリティコントロールを備え、それらが効率的に運用されていることを確認する必要があります。ただし、カバーすべき重要な領域がいくつかあるため、マルチアカウント戦略、最小特権アクセスについて説明します。私が何度も繰り返し確認することの 1 つに、長期にわたって有効に存続している静的 IM 認証情報をどこかに持っているかということがあります。 持っている場合、それを慎重に見直して、まだ必要であるかを確認してもらいます。 再設計できるかもしれません。 そして、それらが本当に必要な場合 (場合によってはハイブリッドアクセスで必要になるため)、その認証情報に関連付けられたアクセス権を最小化し、環境内でわずかなことしか実行できないようにして、それがいつ使用されるかをモニタリングし、それをリスクとして認識するようにします。リスクレジスターに入れるのです。失念しないようにします。そして、将来的に機会があれば、それを取り除きます。これは私たちが目にする最大のリスクの 1 つだと思います。私たちは、お客様が、いわばピンチに陥らないよう、事前予防的にサポートしたいと考えています。

Clarke: (17:44)
ランサムウェアのリスク低減は、セキュリティの基本を非常に忠実に実行することに尽きると私は理解しています。これは公正な評価でしょうか。

Megan: (17:52)
はい。パッチ適用は新しい概念ではありません。実際、AWS ではさまざまな方法でこれを行うことができます。Auto Scaling グループを使用してまるごと入れ替えたり、CI/CD パイプラインからシステムを再起動したりできます。Systems Manager を使用することもできます。現時点では、Systems Manager の半分はオペレーション、半分はセキュリティツールのようなものです。Systems Manager では素晴らしいことを実行できます。つまり、多くのオプションがあるのです。そして、私たちはそれらについても話します。お客様から尋ねられるもう 1 つの質問があり、よい対話のきっかけにもなります。それは、「当社では以前、オンプレミスでエアギャップバックアップを行っていました。文字どおりテープバックアップを備えており、超安全な輸送トラックで運び、誰もそれらのバックアップに触れることはできません。AWS ではこれをどのように行いますか」と言うものです。 すべてが API なので接続されていますが、AWS アカウントとしてのセキュリティ境界については、別のアカウントを作成し、バックアップをそのアカウントに送信することができます。プッシュプルタイプのメカニズムを使用してオートメーションを実行できるため、バックアップ用のランディングアカウントを持つことができます。その後、既知の優れたソースからプルする別のアカウントを作成します。また、S3 オブジェクトブロックなどを使用できます。これはその S3 バケットにおける書き込みが 1 回だけの WORM です。そして、いくつかの非常に強力なセキュリティとコントロールにより、アカウントの少数の管理者へのアクセスを最小化します。また、2 週間前、あるいはつい最近だと思いますが、AWS Backup で AWS Backup Vault Lock が発表されました。これは、同じように書き込みは 1 回で複数回の読み取りを可能にし、そのボールトに適用されます。したがって、基本的に、バックアップが完了した後にそれらのバックアップに変更を加えることはできません。何も削除できないということです。そのため、AWS Backup Vault Lock を使用すると、アクセスポリシーを設定して、それを変更できないようにすることができます。データがそこに保存され、一定期間にわたってアクセスできないという点で、S3 オブジェクトブロックと本質的に似ています。

Clarke: (20:05)
わかりました。これまでにいくつかのツールとベストプラクティスに言及していただきましたが、インシデント対応の準備についてはまだお聞きしていませんでした。これはどの程度重要で、その領域において、お客様は何をすべきでしょうか。

Megan: (20:19)
これらのランサムウェアに関する具体的な議論を行うとき、私はいつも「ランサムウェアのセキュリティイベントの机上トレーニングを実際に行ったことはありますか」とお客様に尋ねます。 なぜなら、机上トレーニングは非常に重要だからです。インシデント対応に携わったことがない場合、多くのストレスを感じることがあります。机上トレーニングを行うことで、実際のイベントの発生中に扱う必要のない多くの問題に対処する機会が得られます。実際のイベントでは、問題がない状態で、集中して調査を行いたいはずです。机上トレーニングでは、基本的に、イベントが発生したことをどのように知ることができるか、 必要な調査を行うために、すべての AWS アカウントにアクセスできるか、 イベントはどこで確認できるのか、 セキュリティオペレーションセンター経由で送信されるのか、 一貫して対応し、意思決定に必要なデータを入手できるように、実行する必要があるすべての対応を概説したガイドがあるか、 そして、適切なステークホルダーを関与させているか、といったことを学びます。 なぜなら、私たちは、セキュリティイベントが発生した場合、お客様やその顧客とのコミュニケーション方法を知っている必要があるからです。それは多くのねじれを解決するものであり、当社のプロサービスチームが関与して、お客様による解決をサポートすることもできます。私たちはこれを数回実施しましたが、練習すれば完璧になります。 ですから、特定のシナリオについて懸念があるときはいつでも「練習しましょう」ということです。 そうすれば、それほど恐ろしくはありません。何かを練習して上達するのと同じくらいシンプルなことです。

Clarke: (21:55)
他のステークホルダーへの言及がありました。ということは、これは単なるセキュリティチームのトレーニングにとどまらないということでしょうか。

Megan: (22:00)
そのとおりです。

Clarke: (22:01)
これらの机上トレーニングに参加すべき他のステークホルダーとして、どのような人々が考えられますか。

Megan: (22:06)
そうですね。通常は法務部門が確実に関与します。プライバシーチーム、セキュリティ管理チームも通常は関与します。トレーニングや対応インシデントの種類によってはヘルプデスクも関係し、何らかの緩和処置が必要かどうかを判断するためにアプリケーションチームや開発チームもかかわることがあるでしょう。これらは一例です。それが下流にどのように影響するのかを考えます。

Clarke: (22:36)
お客様の階層のすべてのレベルが関与するのですか。 つまり、CEO はこれらの机上トレーニングのいずれかに参加しますか。 あるいは、どのレベルまで関与していますか。 どこで止まりますか。

Megan: (22:50)
そうですね。参加してプロセスを理解したい人々であると思います。実際にセキュリティイベントが発生する場合、それは通常機密です。そして、コミュニケーションが計算された方法で行われるようにするため、適切な人、つまり、それについて知る必要がある人だけが機密情報を知るようにしたいはずです。しかし、トレーニングでは、参加したい人を参加させない理由はありません。そして、CEO が興味を持っているなら、ぜひ参加してもらってください。

Clarke: (23:21)
素晴らしいです。

Megan: (23:22)
誰もがそこから学ぶことができます。

Clarke: (23:24)
最近ニュースになっているもう 1 つの大きなトピックであり、お客様から常に質問が寄せられていることは、ゼロトラストの概念です。ご自身にとってゼロトラストとは何を意味しますか。

Megan: (23:34)
そうですね。従来、私たちの環境へのアクセスとセキュリティコントロールは、ネットワーク境界に大きく依存していました。現在、私たちが実現したいのは、API レイヤーで呼び出しを認証および承認することです。つまり、ユーザーが環境にアクセスする場合でも、API から API コールを実行する場合でも、私たちは、そのネットワーク通信パスの各ステップでユーザーが認証および承認されていることを確認したいはずです。

Clarke: (24:10)
Megan、今日はご参加いただきありがとうございました。

Megan: (24:12)
こちらこそありがとうございました。本当に楽しかったです。