脆弱性管理とインシデント対応を考え直す

あらゆる企業がDXに取り組む現在、データを活用して新たな価値をユーザーに提供していくケースが増えています。その手法は主にアプリやWebサービスですが、リリースを急ぐあまりセキュリティがおろそかになってしまい、大きなインシデントが発生してしまうこともあります。この連載では、開発にセキュリティを組み込むための考え方や手法について、GitLabのブログを再構成してお届けします。今回は、脆弱性管理、そしてインシデントレスポンスの自動化について紹介します。

脆弱性管理はDevSecOpsの導入から始める

従来の脆弱性管理のアプローチには、動的アプリケーションセキュリティテスト（DAST）や静的アプリケーションセキュリティテスト（SAST）がありますが、それで十分でしょうか？　クラウド・ネイティブ・アプリケーションの増加により、多数の開発者用ツールが生み出され、セキュリティがシフトレフトされ、SASTやDASTツールが使用される前に開発者自身が脆弱性を特定し修正することが可能となりました。

また、脆弱性報奨金制度が人気を集めており、従来のアプリセキュリティプログラムの補完として使用されることが多くなっています。しかし、万能なアプローチはなく、どのソリューションが組織にとって最適を知るのは困難です。

脆弱性管理とは、脆弱性を特定、分類、処理、軽減、および報告する反復的なプロセスです。このプロセスは単独で行われるのではなく、ソフトウェア開発ライフサイクル全体を通じて行われるべきものです。これにより、本番リリース前に脆弱性を特定する機会が増え、開発やテストの後期段階での修正の必要性を減らし、違反や侵害の可能性を減らすことができます。

脆弱性管理はシフトレフトされ始めており、DevSecOpsの概念が技術系企業の常識になることが期待されています。事実、GitLabの調査「2020 Global DevSecOps Survey」での回答者の多くは、すでに自分の役割に複数の変化を経験していると回答しています。

回答者の28％は、「⁠セキュリティに焦点を当てた部門横断的なチームに参加することが多くなった」と回答し、27％は「日々の開発活動に関わることが多くなった」と回答、23％は「コンプライアンスに焦点を当てることが多くなった」と回答しています。「⁠自分の役割は変わっておらず、今後も変わらない」と答えたのは、わずか20％でした。

スコープを定義し、定期的に実施する

脆弱性管理プロセスを成功させるために最も重要なステップは、そのプロセスがカバーする範囲を定義することです。GitLabでは、セキュリティチームとインフラチームが協力して、デプロイされている全ての重要な環境とシステムがカバーされるように範囲を定義しました（現在GitLab.comの本番環境で対象になっている環境は、こちらで確認できます⁠）⁠。

環境のスコープを設定した後、脆弱性スキャナーを導入し、脆弱性管理のプロセスを開始します。脆弱性管理は、継続的なフィードバックループです。脆弱性スキャナーは、脆弱性を修正するために、データを取り込み、分析します。このプロセスからのフィードバックは、環境をより安全にするために予防的に利用されます。

脆弱性管理は、「⁠脆弱性スキャン」「⁠レポート/分析」「⁠取り込み」「⁠バリデーション」「⁠改善」「⁠フィードバック」のステップに分けられます。そして、脆弱性スキャンを定期的に実施します。これにより、脆弱性が顕在化してから対処するのではなく、脆弱性の発見と軽減のために積極的に行動できます。

このプロセスを支援するスキャナーの例としては、次のようなものがあり、それぞれ焦点が異なります。

SAST
DAST
依存関係スキャン
コンテナスキャン
シークレット検出
ファズテスト

自動化によってインシデント対応を改善する

インシデント対応チームは、企業や顧客を危険にさらすインシデントやイベントへの対応に追われる日々を送っています。ログの相関関係を利用して有害な活動を特定し、軽減することは、多くの時間を消費します。しかし、インシデント対応の完全自動化により、この作業をより効率的かつ効果的に行うことができます。

コロナ禍によって従業員が分散し、ネットワークにセキュリティホールを残す可能性が出てきました。2020年には、米国の全従業員の半数以上がリモートワークをしており、現在も33％がリモートワークを続けています。また、2020年には1,845件以上のデータ漏えいが発生し、3億人以上が影響を受けています。このため、貴重な資産を保護し、ITチームが効率的かつ効果的に外部の脅威に対応できることが重視されるようになりました。

情報漏えいを特定し、封じ込めるまでの平均時間（情報漏えいライフサイクル）は、2020年には280日となっています。私たちは、自分自身や会社のためだけでなく、顧客やサービス利用者のためにも、より良い方法を取らなければなりません。自動化されたインシデント対応は、24時間体制の安全な防御システムを提供します。セキュリティチームやITチームは、脅威が継続的に検出され、リアルタイムで対応されていることを知り、安心して眠れるようになります。

インシデントレスポンスの自動化、何から着手すべきか

自動化は、従業員がより大規模かつ高度な脅威に集中できるようになるため、短期的には時間とリソースが節約され、長期的には大幅なコスト削減が実現します。調査によると、情報漏えいを30日以内に抑止することで、企業は100万ドル以上のコスト削減が可能であり、一方で情報漏えいの平均コストは400万ドル以上と言われています。

自動化は、情報漏えいの報告にも役立ちます。情報漏えいの報告に時間がかかりすぎると多額の罰金が発生し、顧客や従業員からの信頼を大きく失うことになります。また、1件のハッキングについて顧客に通知するコストは、米国では平均約74万ドルとなっています。インシデント対応を自動化することで、時間とコストを削減し、最終的には企業の安全性をより高めることができます。

そうはいっても、ほとんどの企業は、インシデント対応を自動化することに圧倒され、どこから着手すべきか分からないのが普通でしょう。DevOpsサイクルのできるだけ早い段階に、しっかりとしたプロセスが確立されていればコード開発の段階でも、脆弱性検出の自動化に取り組むべきです。

効果的な手順の1つは、情報漏えいやマルウェアの兆候を含む、エンドポイントとインフラストラクチャのインシデントのアラートシステムの自動化です。で、侵害の指標やマルウェアを含めて、効果的な対策を講じることができます。もう1つの重要な対策は、オンコールアラートおよびエスカレーションシステムを自動化することです。これにより、インシデントの特定から軽減までの時間が大幅に短縮されます。

自動化を制御の喪失と考えるのではなく、悪い状況を制御するためのより良い方法と考えましょう。自動化を正しく行えば、会社の安全確保に役立つと信頼できます。自動化されたSIEMがヒューマンエラーを回避することは、何度も証明されていることも忘れないでください。