サイバー攻撃者と被害者　実は第三の関係者がいた

ランサムウェア攻撃が増え、被害は拡大している。攻撃者をブロックし、企業が防御を固めるだけでは事態は解決しないというのが政府の考えだ。では誰が何をすればよいのだろうか。

公開 2024年06月12日 07時06分

著者

Matt Kapko

[Cybersecurity Dive]

印刷する連載新着通知を受け取る

　政府はランサムウェア攻撃に対する支援策を次々と打ち出している。特に米国政府はさまざまなプログラムを実行しており、一定の効果がある。だが、複数の国家が共同で攻撃者を取り押さえ、企業が対策を打つだけではまだ足りない。

第三の関係者は何をしているのか

　サイバー攻撃者が企業を攻撃する際、「第三の関係者がいる」というのが政府の見立てだ。第三の関係者とは誰だろうか。

　サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のジェン・イースタリー氏（ディレクター）は、2024年4月24日に開催された「Institute for Security and Technology」の年次ランサムウェアタスクフォースイベントで、「ランサムウェアは周期的かつ持続的な脅威だ。そのため、これまでのセキュリティ対策とは異なる考え方が必要だ。防御者や関係者は、ソフトウェアやハードウェアのベンダーに目を向ける必要がある」と語った。もう一人の関係者とはソフトウェアのベンダーだ。

　「サイバー攻撃者についても、その被害者についても多くが語られる。しかし、ベンダーについて語られる機会は少ない。攻撃件数やその結果、損害を被った件数を減らすためには、（ソフトウェアチェーンの）川上に目を向けて、企業が導入しようとしている技術の安全性を優先することが重要だ。ソフトウェアの機能ではなく、市場投入までのスピードでもなく、コスト削減でもなく、そのソフトウェアが安全だということが重要だ。これこそが、私たちがこの問題に取り組んでいる理由だ」（イースタリー氏）

　後述するように「セキュア・バイ・デザイン」は（注1）、技術が核となる製品やサービスに関するセキュリティの責任をメーカーやベンダーに移そうとする集団的な働きかけだ。この取り組みは広く語られているものの、今のところ、ガイドラインに沿うことを強制する仕組みは存在しない（注2）。

　政府関係者は、川下でまだやるべきことがあると認識しており、肯定的な結果を得るには何年もかかる可能性があるという。

政府はランサムウェア対策を打ってきた　ベンダーは？

　イースタリー氏は「過去3年間にわたり、米国政府とそのパートナーがランサムウェアの増加を抑制してきた。stopransomware.govやジョイントランサムウェアタスクフォース、事前にランサムウェアを通知する取り組み（注3）、ランサムウェアの脆弱（ぜいじゃく）性警告パイロット（注4）、既知の脆弱性カタログなどの取り組みは、魔法の解決策ではないが、これらがなければランサムウェア攻撃の数ははるかに多かっただろう」と述べた。

　同氏によると、CISAの「事前にランサムウェアを通知する取り組み」と「ランサムウェアの脆弱性警告パイロット」は、2022年末の開始後、それぞれ約2000件を通知した。これらの取り組みにより、幾つかの攻撃の発生を防いだり、大災害に発展することを防いだりできたが、ランサムウェアは依然として巨大な問題だ。

　「被害者や攻撃が発生した理由に焦点を当てるのではなく、関係者はベンダーが一般的な脆弱性を残したまま製品を提供していることに対処する必要がある」（イースタリー氏）

　同氏によると、ファイル転送サービスMOVEitのSQLインジェクションの脆弱性は非常に初歩的なものであり、20年前の手法で解決できたものだ。それにもかかわらず、MOVEitの脆弱性に関連したランサムウェア攻撃は、約2300の組織に影響を与え（注5）、9300万件以上の個人情報が流出した。

セキュア・バイ・デザインとは

　セキュア・バイ・デザインとは、ソフトウェア開発においてセキュリティを重視する考え方だ。ソフトウェアの設計段階からセキュリティを考慮することで、ソフトウェアをより安全にすることを目指す。

　セキュア・バイ・デザインのアプローチでは、ソフトウェアが完成した後にセキュリティを追加するのではない。ソフトウェアの設計の根本的な部分としてセキュリティを扱う。ソフトウェアの開発ライフサイクルの初期段階からセキュリティを統合することで、潜在的な脆弱性を軽減し、より強固なセキュリティ対策を実現することが目的だ。

　セキュア・バイ・デザインを実践するには幾つかの重要な原則と手法がある。

（1）セキュリティ要件の定義
　ソフトウェア開発プロジェクトの開始前に、セキュリティ目標と要件を明確に定義する。これには、機密性や整合性、可用性などのセキュリティの軸を考慮する他、ソフトウェアの処理や保存、送信するデータの機密性とプライバシーを保護するメカニズムが含まれる。

（2）脅威モデリング
　ソフトウェアの設計を分析して、潜在的な脅威や脆弱性、攻撃経路を特定する。これには、システムの攻撃対象領域をマッピングし、悪意のある攻撃者や偶発的な脅威が利用する可能性のある脆弱性を特定することが含まれる。この情報は適切なセキュリティ対策を実装する際に役立つ。

（3）セキュリティ対策の統合
　設計プロセス全体を通してセキュリティ対策を実装する。これには、安全な認証と認可メカニズム、暗号化、データの検証とサニタイズ、アクセス制御、監査とログ記録などの実装が含まれる。これらの対策は、ソフトウェアのアーキテクチャに組み込まれ、セキュリティが設計の一部となるようにする。

（4）入力と出力の検証　全てのユーザー入力とシステム間のインタフェースを徹底的に検証し、サニタイズして、インジェクション攻撃（SQLインジェクションやクロスサイトスクリプティングなど）を防止する。同様に、出力が適切にエンコードされ、意図した通りに解釈されるようにする。

（5）最小権限の原則
　各コンポーネントやモジュール、さらにユーザーにも、タスクを実行する際に必要な最小限の権限のみを付与する。これにより、侵害や悪用が発生した場合の潜在的な影響を軽減できる。

（6）防御的プログラミング
　開発者はソフトウェアが予期せぬ入力やエラー状態に遭遇した場合でも安全に動作するように、防御的プログラミング手法を採用する必要がある。これには、エラー処理や例外処理、フォールトトレランスの適切な実装が含まれる。

（7）セキュリティテストと監査　開発ライフサイクルの全体を通して、事前の計画に沿ってセキュリティテストと監査を実行する。これにはコードレビューやペネトレーションテスト、脆弱性スキャン、セキュリティ監査などが含まれる。こうして、設計や実装の潜在的な脆弱性が特定され、対処される。

（8）セキュリティ更新プログラムの管理　ソフトウェアのリリース後も、セキュリティは継続的なプロセスでなければならない。開発者はセキュリティ更新プログラムとパッチを定期的に監視および展開して、新たに発見された脆弱性からソフトウェアを保護する必要がある。これには開発したソフトウェアが利用している外部のコンポーネントも含まれる（キーマンズネット編集部）

出典：CISA director pushes for vendor accountability and less emphasis on victims’ errors（Cybersecurity Dive）
注1：Explore the core tactics of secure by design and default（Cybersecurity Dive）
注2：How will the government enforce the national cyber strategy?（Cybersecurity Dive）
注3：CISA’s 1,200 pre-ransomware alerts saved organizations millions in damages（Cybersecurity Dive）
注4：CISA launches ransomware warning pilot for critical infrastructure providers（Cybersecurity Dive）
注5：Progress Software’s MOVEit meltdown: uncovering the fallout（Cybersecurity Dive）