セキュリティ統合が最も進んだ組織の29%が、連携時の摩擦に直面
2020年1月28日
0 分で読めます組織における従来型のセキュリティ活動には、セキュリティチーム、運用・IT部門、そして中核となるR&Dエンジニアリング部門の間に大きな緊張があるという特徴があります。これらのチームがそれぞれ孤立して活動し、全体的な目標も一致していないと、緊張や摩擦が生じ、セキュリティ活動が効果を発揮しない状態につながります。
一方、SDLC全体にセキュリティプラクティスを組み込むと、組織全体のセキュリティプラクティスに対する信頼度が高まります。さらに、Puppetのレポートによると、SDLCのごく初期段階でセキュリティ活動を実施すると、より大きな効果が得られます。
深く摩擦のないセキュリティ統合が、セキュリティ態勢とコラボレーションを向上
具体的には、脅威モデリングは、組織全体のセキュリティ態勢と信頼度に最も大きな影響を与えるセキュリティ活動として挙げられました。脅威モデリングは、セキュリティ、開発、運用といったすべてのビジネス関係者を結び付け、「何を構築するのか」「何が問題になり得るのか」といった基本的な問いへの答えを導き出すことを目指します。この活動は、開発・セキュリティ・運用に携わるすべての関係者が協力し、率直に話し合い、コミュニケーションを図るための環境と土台を生み出します。
先日、DevOpsとDevSecOpsの導入状況に関する調査を実施しました。主な調査結果の一つは、セキュリティ統合が最も進んだ組織の29%が、セキュリティチームとデリバリーチームの連携に依然として大きな摩擦があると感じていることです。
DevSecOps Insights 2020のPDFをダウンロード
Puppetによると、組織のセキュリティ態勢の向上に特に大きな影響を与えるプラクティスには、次のようなものがあります。
継続的インテグレーションパイプラインで使用するセキュリティツールは、エンジニアが既知のセキュリティ問題をコードベースに持ち込んでいないという確信を持つのに役立ちます。こうした自動化されたセキュリティツールは、多くの場合すばやく動作し、迅速なフィードバックループによって開発者に優れた体験を提供します。そのため、開発者は作業を妨げられることなく、スムーズに開発を進められます。また、開発者のワークフローに密接に統合され、実行可能な修正案を提示するツールもあります。これにより開発者は、自身が開発するアプリケーションのセキュリティに責任を持てるようになります。
インフラ関連のセキュリティポリシーは、デプロイ前にレビューします。Infrastructure as Code（IaC）は多くのDevOpsツールに不可欠な要素となっており、クラウドネイティブなサービスのプロビジョニングや、HashiCorp Terraformなどのツールの普及とともに急速に広がっています。IaCのもう一つの例は、Kubernetesなどのコンテナオーケストレーションソフトウェアをプロビジョニングするために、テキストベースの設定を使用することです。しかし、よくあるセキュリティ上のミスは、安全でない設定を誤ってプロビジョニングしてしまうことで、組織に大きな影響を及ぼす可能性があります。たとえば、あるケースでは、安全でないクラウドストレージの設定によって、権限のないユーザーが不適切にアクセスできる状態になり、複数のデータ漏えいが発生しました。この点については、本レポートの前半でも取り上げました。
とはいえ、セキュリティ統合が最も進んだ組織の29%は、セキュリティチームとデリバリーチームの連携に依然として大きな摩擦があると感じています。それでも、セキュリティ統合が中程度の段階にある組織では47%が同じように感じており、状況は改善しています。特に注目すべき点として、セキュリティ統合が行われていない場合、チーム間の連携はまったくありません。
Puppetのレポートから得られるもう一つの注目すべき結果は、セキュリティを深く統合している組織ほど、一般的な機能の提供よりもセキュリティ上の問題を優先し、迅速に対処できていたことです。これは重要な示唆です。組織全体でセキュリティを共有責任と捉えれば、ビジネスに対するセキュリティリスクの最小化が最優先事項になります。
DevSecOps Insights 2020のPDFをダウンロード
DevSecOps Insights 2020の調査結果を引き続きご覧ください：