Kiteworksの顧客には、週末に本番システムをオフラインにするよう求められた。この停止中に、同社は重大な脆弱性を発見して修正した。
同社が9月28日に発表したところでは、停止中の調査でこれまで知られていなかった重大な脆弱性が明らかになった。同社によると、影響を受ける機能を有効にしている顧客は1%未満で、脆弱性が悪用された兆候はなく、顧客は通常の運用に戻すことができる。
セキュリティチームにとって、今回の出来事は実務的な疑問を投げかける。機密データ基盤をオフラインにして業務ワークフローを中断する必要がある場合、信頼できる警告を受けてどれだけ迅速に行動できるだろうか。
停止中に何が起きたのか？
9月25日、 Kiteworksは顧客に、一部の環境が脅威アクターの標的になる可能性があるとの情報を受け、9時間の停止時間を設けてシステムを停止するよう助言した。オンプレミス、AWS、またはAzureでシステムを管理している顧客には、自ら停止を実施するよう伝えられ、Kiteworksは自社がホスティングする環境を停止した。この勧告は予防措置であり、同社は当時、侵害の兆候はないとしていた。
停止中、Kiteworksは重大な欠陥を特定し、修正を開発・展開するとともに、各環境に追加の保護レイヤーを適用した。同社は9月28日の声明で、脆弱性の仕組みを公には説明していない。一方、Kiteworksが更新した再起動ガイダンスでは、セルフホスト型のAdvanced Formsを利用する顧客に対し、支援を受けるためサポートに連絡するよう求めている。
Kiteworksは9月27日、停止の勧告を解除した。同社によると、継続的な監視により脅威の発生期間中に異常な活動は確認されず、悪用や侵害の兆候もなかった。Kiteworksがホスティングする顧客システムはすべてオンラインに復旧したという。
この警告が防御側にとって重要な理由
ファイル共有・転送システムは、機密性の高い業務データのすぐ近くに置かれることがある。以前に報じた MOVEit Transferの脆弱性は、こうしたプラットフォームの欠陥に迅速な対応が求められる理由を示している。Kiteworksのケースでは、信頼できる警告を受けてシステムを停止し、オフラインになっている間に調査によって重大な欠陥が明らかになった。
「今回のインシデントは、脅威インテリジェンスを運用に組み込む必要性も浮き彫りにしている。レポートやダッシュボードに置かれているだけのインテリジェンスは、何も守ってくれない」と、Suzu Labsのシニアコンサルタント兼エバンジェリスト、Phil Wylie氏は述べた。
そのインテリジェンスを実際の対応に生かすには、緊急停止を誰が承認できるのか、どのシステムがサービスに依存しているのか、顧客やスタッフにどう通知するのか、アクセスを復旧する前にチームがどのような証拠を必要とするのかを定めた対応計画が必要になる。同様の対応上の課題は、チームが 積極的に悪用されているGitLabの脆弱性を優先するか、 ファイル転送の脆弱性の悪用を調査しなければならない場合にも生じる。
Kiteworksの顧客が今すべきこと
管理者は、Kiteworksが更新したガイダンスに従ってシステムをオンラインに戻すことができる。同社が明確に指示しているとおり、セルフホスト型のAdvanced Formsを利用するチームは、支援を受けるためKiteworksのサポートに連絡すべきだ。また、導入環境に必要な修正が適用されていることをKiteworksに確認し、自社の監視記録を調べて異常な活動がないか確認するとともに、停止が重要な転送に与えた影響を記録しておく必要がある。
Kiteworksは、悪用や侵害の兆候はないとしている。それでも顧客は、自社の構成と復旧状況を確認する必要がある。特にAdvanced Formsを利用している場合はなおさらだ。
詳しく読む：「 ShareFile Storage Zone Controllerに関する警告」は、ファイル共有プロバイダーが信頼できる脅威を理由にシステムをオフラインにするよう勧告した際、セキュリティチームが直面する判断の別の例を示している。