セキュアメッセージングサービスのThreemaは、大規模なDDoS攻撃によってホスティング型プラットフォームへのアクセスが妨害され、約4時間にわたって停止した。
サービスの問題は水曜日の朝に再発したが、その日の後半には通常運用に戻った。攻撃者は攻撃の間、トラフィックパターンを変え続けたため、通常であれば目立った障害を起こさずにプロバイダーが対処している日常的なDDoS活動よりも、事態の収束が難しくなった。
影響の大きさは、顧客がサービスをどのように導入していたかによって異なった。
OnPrem環境はオンライン状態を維持
ホスティング型サービスのユーザーには障害が発生したが、自社管理のOnPremインストール環境は顧客のインフラ上で稼働を続けた。
Threema Workを利用する法人顧客には、水曜日の朝に不安定な状態についてのメール通知が届き、アカウントマネージャーが個別の問い合わせに対応した。自社管理型の環境は障害中も利用可能な状態を維持していたと、同社のインシデント報告書によると。
攻撃者がシステムやユーザーデータにアクセスしたことを示す証拠はなかった。攻撃によってサービスの可用性は損なわれたものの、暗号化は維持された。
防御に応じて攻撃パターンが変化し続けた
DDoS攻撃の再発はThreemaにとって珍しくなく、その大半は目立った障害をほとんど、あるいはまったく引き起こさない。8月の攻撃は、攻撃が長時間続き、トラフィックパターンが繰り返し変化したため、収束させるのがより難しかった。
サービスは火曜日の夜に完全に停止し、攻撃は水曜日の朝に再開した。短時間の中断が発生したが、正午ごろには通常運用に戻った。
別の技術的な問題により、ステータスページの更新が一時的にできなくなり、同社は障害情報の発信にソーシャルメディアを使わざるを得なかった。
サービスが安定した後、同社は悪意のあるトラフィックをインフラに到達する前に上流でフィルタリングする追加の防御策を有効にした。これらの制御は、大量のトラフィックがネットワーク容量を消費するのを防ぐのに役立ち、DDoSの防止・緩和策の一環として一般的に用いられる。計画には、ステータスページへのインシデント履歴とRSSフィードの追加も含まれている。
障害後も攻撃者は特定されず
この攻撃の責任者は依然として不明だ。ThreemaのコロケーションプロバイダーであるNineも標的となったため、Threemaが主な標的だったのか、それとも複数の標的の1つだったのかは、なお明らかになっていない。
組織のサイバーインシデント対応に暗号化メッセージングが含まれている場合は、同じプロバイダーやインフラの外部に第2の通信手段を維持しておこう。代替手段をインシデント対応計画に追加し、障害が発生してスタッフがその場しのぎの対応を迫られる前に切り替えをテストしておくべきだ。
プロバイダーのレビューでは、暗号化の制御だけでなく、DDoS防御と障害時のコミュニケーションも確認すべきだ。フィルタリングがどこで行われるのか、主要なステータスシステムが停止した場合に管理者がどのようにアラートを受け取るのかを確認しておこう。
OnPremのサービスが中断しなかったからといって、自社ホスティングのほうが常に安全というわけではない。しかし、プロバイダーの障害時に、導入アーキテクチャによって影響の受けやすさが変わり得ることは示している。
関連ニュース：およそ4万人のSafePal顧客の情報が流出したことで、詐欺師が標的型攻撃に使える、より説得力のある材料を得る可能性がある。