一元化されたセキュリテイツールへの移行を実現するための4つのステップ

先日 Fastly が公開した、ESG Research との共同調査に基づくレポート「転換期を迎えた Web アプリと API のセキュリティ」を読む中で、いくつかの事実が矛盾していることに気づきました。調査対象企業は、平均11種類の Web アプリや API のセキュリティツールを使用しているにもかかわらず、回答者の93%がセキュリティツールの統合ソリューションに興味がある、もしくは採用予定であると答えています。多様なツールが使用されているにもかかわらず、これほど多くの人が統合されたソリューションを求めているという事実は、セキュリティツールにおいて現実と理想との深い隔たりが存在することを表しています。

もっとも、11種類のツールを使用しながら、技術的負債を減らし、セキュリティスタックやプラクティスを改善することは非常に大変なことです。しかし、大規模なセキュリティ侵害によるダメージからの回復はさらに困難です。

でもだからと言って、一度にプロセス全体を徹底的に見直す必要はありません。セキュリティツールの見直しにおいて私がおすすめするのは、実証的アプローチです。このアプローチでは、組織全体に Okta を導入するなど、一つの小規模なプロジェクトから始め、導入初期にスピードが落ちる可能性はあるものの、誤ったソリューションを使い続けることでいつまでもスピードが落ちたままである上、問題が発生するリスクが高まるということを証明します。そうして組織の納得を得て、CEO や CFO と CISO の間に信頼を築き、このプロセスを繰り返します。

今回は、セキュリティ上の技術的負債を減らし、アプリや API の安全性を高め、統合されたセキュリティツールの導入を実現するための反復可能な4つのステップをご紹介します。

導入初期にスピードが落ちる可能性はあるものの、誤ったソリューションを使い続けることで、いつまでもスピードが落ちたままである上、問題が発生するリスクが高まります。

1. ワークフローの棚卸し

可視化されていないものは、保護することはできません。シャドー IT とは、IT 部門によって承認されていないテクノロジーを使用することを意味します。Statista の調査によると、参加者の42%がそのような未承認のテクノロジーを利用しているそうです。開発者は常にスピーディな開発を心がけているため、いちいち新しい API や AWS インスタンスを IT チームに報告しない場合があります。しかし、どんなに優れたセキュリティツールでも、開発者によってローンチされた API が未承認である場合、その API を保護することはできません。

組織内のサイロ化が、この問題の要因の一つです。問題をいち早く解決したいと思うことは本能的な反応ですが、開発者が使っているツール全てがセキュリティ組織によって開発および承認されているわけではありません。まずは、組織内のソフトウェアのデリバリーワークフローの棚卸しを行い、理解することから始めると良いでしょう。その中で、テクノロジーやプロセスに共通している要素、中心的な役割を果たしているコンポーネント、または IT フットプリント全体へのアクセスが必要なコンポーネントなどを特定します。そうすることで、絶え間なく増え続ける特定のツールやベンダーでモグラ叩きのように脅威に対処するのではなく、効率的にリスクを管理する方法をエンジニアリングチームのリーダーと共に再考することができます。

2. リスク評価と優先順位

ワークフローにおいて保護すべき肝心なコンポーネントがリストアップできたら、各項目にリスク評価を与えます。まずは、ソフトウェアデリバリーの成功に欠かせないサービスやツールを把握することが重要です。その中で、ユーザーに対して本番サービスの高い可用性を確保するのに必要な要素、機密データを保管・処理するコンポーネント、または他のツールやコンポーネントにフックする特権を持つツールなどを把握します。要するに、収益の創出やユーザーへの配信において、障害や被害を及ぼす可能性が最も高い、ソフトウェアシステム内の要素を特定します。

次に、その中でも最も攻撃者に狙われやすいと思われる箇所を特定し、重要なリソースを保護するための対策を考えます。その際、OWASP Top 10 リストなどを参考にすることをおすすめします。2021年の脅威トップ3は、インジェクション攻撃、認証プロセスの不備、機密データの露出です。これら3つの脅威リスクにさらされる可能性のあるもの全てを、ワークフローの見直しにおいて優先すると良いでしょう。 

リスク評価と優先順位の割り当てができたら、少しずつ見直しを進めていきましょう。一度に全部やろうとしてはいけません。一つの要素の改善が完了してから、次に取り掛かるように、一つずつ順番に進めていきましょう。

3. DevSecOps を並行して導入

セキュリティツールやセキュリティプラクティスの統合に向けて少しずつ前進する中、プロセスを見直すことも忘れてはいけません。1日に何度もデプロイを行う開発チームは、新しいインスタンスについて毎回セキュリティチームに確認を取ることはできません。DevSecOps は、プロダクトの開発にセキュリティツールを取り入れる手法のことです。このプロセスでは、プロダクトを開発しながら、開発の効率やスピードを妨げることなく、セキュリティテストを行うことができます。

新たな API を作成する際、セキュリティポリシーを適用するなど、開発チームとセキュリティチームが協力し合う必要があります。そうすることで、新たな脅威や脆弱性が見つかった際、セキュリティチームはポリシー管理を行い、API 全体に適用することができます。

しかし、協力が必要なのはチーム間だけではありません。多層防御の重要性については一般的によく理解されていますが、それを実行に移すことは容易ではありません。特定の脅威に対して効果的なツールが複数あったとしても、これらのツールを統合することができなければ、意味がありません。攻撃者は悪用可能な機能や脆弱性を見つけるべく、常にさまざまな手口を駆使しているため、幅広い範囲の脅威に対する可視性が欠かせません。セキュリティと開発プロセス全体にわたって脅威とトラフィックのエンドツーエンドの可視性を得ることは、DevSecOps にとって非常に重要です。

4. プロセスを繰り返す

新たなツールやプラクティスが整ったら、テストを行いましょう。そして、本番環境でもテストを続けることが重要です。導入が完了したからと言って、安心することはできません。忘れ去られたりほったらかしにされたツールを使った攻撃は検出されにくいため、攻撃者によって悪用される (または継続的な攻撃に利用される) 可能性があります。ビジネスにとって優先的な順序に従い、各ソリューションにおいて実証可能な信頼性を継続的に築いていくことがこのプロセスの目的です。これを繰り返すことで投資収益率を最大化できるほか、開発チームは使いやすく、信頼性の高いツールをワークフローに取り入れてプロダクトを強化できます。

より統合されたセキュリティソリューションを導入するためにスタックを一新するのは大変な作業かもしれませんが、盲点の排除や誤検知の削減、よりシンプルなシステム、コスト節約など、得られるメリットは計り知れません。実証的なアプローチを採用することで、統合されたソリューションを手に入れることが可能になります。

現在転換期にあるセキュリティツールについて詳しくは、ぜひレポートをダウンロードしてください。