NRI セキュアテクノロジーズでは、毎年、企業におけるセキュリティの実態を調査し、統計した「企業における情報セキュリティ実態調査」を発行しています。その中で、サイバー攻撃に関しては、「標的型メール攻撃」「ランサムウェア」「マルウェア感染」といったマルウェアによるものが突出して多いという結果でした。
マルウェア感染が原因で不正アクセスのインシデントを引き起こし、結果として情報の漏えいや改ざん、システム停止などの被害を受けた企業もあります。
Webシステムの脆弱性を突いた攻撃についても、インシデントが発生した企業は一定数存在します。ミドルウエア、OSの脆弱性を突いた攻撃もあれば、Webアプリケーションの脆弱性を突いた攻撃（専門的にはバッファオーバーフロー、SQLインジェクション、ディレクトリートラバーサル、クロスサイトスクリプティングなど）もあります。こうした脆弱性を突いた攻撃のインシデントは、情報の漏えいや改ざん、システム停止など、深刻な被害に至っている事例が多いのが特徴です。
本記事では、頻発する「標的型メール攻撃」「ランサムウェア」、深刻な被害をもたらす「システム基盤や Web アプリケーションの脆弱性を突いた攻撃」について、インシデントが発生した場合の影響と、上流工程でのセキュリティ設計の重要性について、実際のインシデント事例を基に解説します。
インシデント事例① 『標的型メール攻撃』
【発端】
標的型メール攻撃を受けて従業員が添付ファイルを開いた。
【事象】
攻撃者が顧客管理データベースに不正アクセス。顧客情報が漏洩する被害が発生した。
攻撃者が特定の企業をターゲットに、あらゆる手段を使って攻撃を仕掛けてくる時代になりました。標的型メール攻撃は複数の攻撃のうちの一つです。
その実際の手口は次のようなものでした。
図. サイバー攻撃の流れ（標的型攻撃、ランサムウェア）
攻撃者はまず、業務メールを装った攻撃メールを企業の関係者に送信しました。従業員の数人がその攻撃メールの添付ファイルを開き、その従業員の PC がマルウェアに感染しました。
PC に感染したマルウェアは、攻撃者と不正な通信を開始しました。これにより、攻撃者はマルウェアに感染した PC の遠隔操作が可能になりました。攻撃者はその後、数カ月かけて社内システムを探索。サーバーやほかの従業員の PC にアクセスして、最も機密情報が含まれる顧客管理データベースに狙いを定めました。
攻撃者は顧客管理データベースのOSの管理者権限にはアクセスできませんでしたが、サーバーの認証を集約管理している認証サーバーにアクセスして、顧客管理データベースで利用している高権限のアカウントとパスワードを入手しました。それを利用してデータベースに直接アクセスし、顧客情報を取得。マルウェアに感染しているPC経由で攻撃者宛てに顧客情報を送信して、情報を盗み出しました。
この企業は顧客情報を集約して管理して、様々なシステムと連携するようなシステム構成にしていました。顧客情報を集約しておけばデータ管理の効率性が高まりますし、他システムからの連携時にデータの最新性を確保できます。機能面から見ると、正しいシステムの姿です。
しかし、セキュリティ面では二つの要素が不足していました。一つは認証サーバーとデータベースサーバーのセキュリティ強化、二つめは不正アクセスの監視です。認証サーバーとデータベースサーバーのアクセス制御（必要なアカウント、プロトコル、アクセス元のアクセスのみ許可）ができておらず、アカウントの厳密な管理もできていなかったため、それぞれのサーバーへ容易にアクセスすることができました。
また、不正アクセスの監視が行き届いていなかったため、通常アクセスしない方法でアクセスされても、その挙動を検知することができなかったのです。データの特性や重要度、漏洩時のインパクトを考慮すると、もっと厳密に管理するセキュリティの設計が必要でした。
上流工程で正しく設計できていれば、認証サーバーや顧客管理データベースなど、重要サーバーの「要塞化」の必要性に早期に気付けたでしょう。要塞化とは、不要な機能やアカウントの停止、アクセス制限などで攻撃される可能性のある穴を減らす手法です。
さらに、昨今のセキュリティ対策で重要なのは複数の防御の “ 層 ” を作り、一つの層が破られても別の層で守るという「多層防御」の考え方です。この考え方に基づくと、重要サーバーにアクセスする際の適切なアクセスルートの特定、重要データの暗号化やアクセス制御などの設計、重要データが持ち出されることを想定した監視設計なども必要でした。
標的型メール攻撃への対策というと、マルウェアに感染させないウイルス対策、攻撃メールを受信させないメールセキュリティ、不正な通信を止めるネットワークセキュリティ、攻撃メールに気付く社員教育などを思い浮かべがちです。しかし、ここで挙げた事例では、根本的な問題は顧客管理システムの設計にこそあったのです。顧客管理システムを開発する上流工程で脅威を想定した対策を行っていれば、インシデントは防げたはずでした。
インシデント事例② 『ランサムウェア』
【発端】
従業員が不正な Web サイトにアクセスした。【事象】
攻撃者に基幹システムの全データを暗号化された。
従業員が不正な Web サイトにアクセスして、PC がマルウェアに感染したのがきっかけでした。その後の攻撃の流れは標的型メール攻撃に似ています。攻撃者に社内システムを探索されました。標的型メール攻撃との違いは攻撃の最後の部分です。重要な情報を盗み出すのではなく、基幹システムの全ファイルを暗号化して使用不能にするという手口を使ってきました。
暗号化されたファイルは “ 人質 ” です。暗号化された翌日、攻撃を受けた企業に攻撃者から金銭の支払いを要求するメールが届きました。「ファイルを元通りにしたければ金を払え」ということです。
この企業は身代金の支払いを拒否しました。バックアップからの復旧を試みましたが、復旧までに多大な時間がかかりました。
復旧に時間がかかったのは、バックアップ / リストア設計とその運用が不十分だったのが大きな要因でした。データベース内の重要なデータは定期的にバックアップしていたものの、一部の設定データなどは変更管理の仕組みなどで集約管理されていませんでした。データベースの復旧試験は実施していましたが、OSからのフルリストアのテストや定期的な手順の確認を実施していませんでした。
そのため、復旧手順が一部しかないことに気付かずにいました。さらに、マルウェアにいつから感染していたのか分からず、どの時点のデータを復旧すべきか判断に迷いました。こうした要因により、リストアに多くの時間を要したのです。
基幹システムの要件定義や設計時に、すべてのファイルにアクセスできなくなるようなセキュリティインシデントへの想定がなかったのでしょう。本来ならば、代表的なセキュリティの脅威（標的型攻撃、不正アクセス、内部不正など）を想定した設計を行ったうえで、試験や手順作成を実施すべきでした。
そうしたセキュリティ設計では、取り扱うデータの機密性だけでなく、システム全体の完全性や可用性も考慮するのが原則です。様々な脅威を想定して設計していれば、上流工程でバックアップ / リストアの設計を実施でき、復旧時間の短縮化や一部データの欠損を防ぐことができたでしょう。
インシデント事例③ 『Webサイトへの不正アクセス』
【発端】
企業が提供する Web サービスで顧客データの改ざん、不審なメールの送付など顧客情報の不正使用が相次いだ。【事象】
Web サイトの脆弱性を突かれ、攻撃者に Web サービスの情報を盗み出されていた。
攻撃者はまず、企業のWebサービスのフロントにあるWebサーバーに対して、利用しているOSやミドルウエアなどの種類とバージョンの調査を行いました。そして攻撃者は取得したミドルウエア（Web アプリケーションフレームワーク）の脆弱性情報を利用して、Web サーバーに対して攻撃を試みました。
図. サイバー攻撃の流れ（Webサイトへの不正アクセス）
攻撃者は、WebサーバーからデータベースサーバーにOSのコマンドを実行する攻撃が可能であることを突き止めました。これを悪用して、データベースの中の顧客情報を盗み出したのです。
このインシデントは、Web サーバーで利用しているミドルウエアにパッチを適用していないことで発生しました。ただし、数日前に緊急パッチが出たばかりであり、いわゆる「ゼロデイ攻撃」に近い状態で起こったものでした。データベースサーバーに対する外部からの直接的なアクセスは許可していませんでしたが、Web サーバーを掌握されてしまったため、攻撃者に容易にアクセスされてしまいました。さらに、攻撃の発生を監視システムで検知できていませんでした。
上流工程でパッチマネジメントの運用設計、データベースサーバーのアクセス設計、重要データへのアクセスに対する監視の設計をきちんとできていれば、防げたインシデントでした。
パッチマネジメントは実施していなかったわけではありません。ただ、それが不十分でした。定期的に脆弱性情報を収集して、パッチを適用するという運用設計でした。問題は情報収集がソフトウエアベンダー頼みだったうえ、緊急パッチの適用基準や方針が決まっていなかったことです。緊急対応を想定した運用設計になっていませんでした。
Web サーバーからデータベースサーバーへのアクセスについては、データベースに接続可能な専用の API を使ったものだけを許可すべきでしたが、そうした設定になっていませんでした。本来ならば要件定義や設計時にデータへのアクセスルートを特定・整理し、そのアクセス制限（いつ、どのアカウントで、どの目的で、どうアクセスさせるか）を決めて設定する必要がありました。
重要データへのアクセスの監視については、データベースで利用するプロトコルと実行するコマンドを監視するように設計する必要がありました。この企業では、通常利用するアカウントからの通信だけを監視していました。その結果、不正アクセスを見逃してしまいました。こうした「特殊だが重要な例外」の監視要件は、後工程の設計では簡単に追加できません。
おわりに
このように、セキュリティインシデントの多くは要件定義や設計といった『上流工程での不備』が原因になっているケースが多いです。
「標的型攻撃」、「ランサムウェア」、「Webサイトへの不正アクセス」など実際に発生しているインシデントを見てみても、上流工程で万全の対策を取っておけば防げたものが多いということ分かります。システムを開発する上で、一貫した「プロセス」と「観点」を持つことで、システムのセキュリティを適切に考慮して設計できるようになります。
こうした観点を持ってセキュリティを考慮したシステム設計をしていくことが、企業全体のセキュリティレベルの向上につながり、企業の競争優位性を保つことに繋がるのです。
※本記事は、以下書籍の内容を元に再構成したものです。
「上流工程でシステムの脅威を排除する セキュリティ設計実践ノウハウ」
編著：山口 雅史
発行元：日経BP社
https://tech.nikkeibp.co.jp/atcl/nxt/books/18/00010/111300196/
