【ITニュース解説】Can I have a new password, please? The $400M question.

大手消費財メーカーであるClorox社が経験したサイバー攻撃の事例は、システムエンジニアを目指す皆さんにとって、現代のITセキュリティが抱える課題と、その対策の重要性を浮き彫りにする、非常に示唆に富んだ出来事だった。この事件で、Clorox社はなんと3億8000万ドル（日本円で約400億円）もの甚大な損害を被った。しかし、この攻撃は、映画に出てくるような高度なゼロデイ攻撃や、未知の脆弱性を突いたものではなかった。攻撃者は、驚くほど単純だが巧妙な手口、すなわち「ソーシャルエンジニアリング」を使い、企業の内部へと侵入したのだ。

攻撃グループ「Scattered Spider」は、Clorox社のヘルプデスクに電話をかけた。彼らは、Clorox社の正規の従業員であるかのように装い、自身のパスワードをリセットしてほしい、多要素認証（MFA）もリセットしてほしいと要求した。多要素認証とは、パスワードだけでなく、スマートフォンに送られるワンタイムパスワードや生体認証など、複数の要素を組み合わせて本人確認を行うことで、セキュリティを強化する仕組みだ。通常、パスワードが漏洩しても、MFAがあれば不正ログインを防げるため、非常に強力なセキュリティ対策とされている。しかし、今回の事件では、そのMFA自体を攻撃者がリセットさせてしまった。

なぜ、このようなことが起きてしまったのだろうか。問題は、ヘルプデスクでの「本人確認」が不十分だったことにある。ヘルプデスクは、従業員がパスワードを忘れたり、システムにログインできなくなったりした際に、サポートを提供する重要な役割を担っている。しかし、そのサポートを提供する際、本当に本人からの依頼なのかを厳格に確認しなければ、今回のClorox社の事例のように、攻撃者に悪用されるリスクがある。攻撃者は、事前にターゲットとなる従業員の情報を何らかの方法で入手していた可能性が高い。名前や部署、時には役職といった断片的な情報を巧みに利用し、ヘルプデスク担当者を騙すことに成功したのだ。ヘルプデスク担当者は、目の前の電話口の相手が本当に従業員本人であると信じ込み、パスワードとMFAのリセットに応じてしまった。

この結果、Scattered Spiderは、正規の従業員になりすましてClorox社のシステムにアクセスする権限を手に入れた。一度内部に侵入を許してしまうと、攻撃者は企業の機密情報にアクセスしたり、システム設定を変更したり、さらには他のシステムへと横展開して被害を拡大させたりすることが可能になる。Clorox社の3億8000万ドルという巨額の損害は、この不正アクセスによって、ビジネス運営が停止したり、データの漏洩が発生したり、復旧作業に膨大なコストがかかったりした結果として生じたものと考えられる。

この事件が私たちに教えてくれる最も重要な教訓の一つは、「発信者の本人確認（caller verification）」がいかに重要かということだ。システムやネットワークの堅牢な設計はもちろん大切だが、それ以上に、システムを利用する「人」が関わるプロセスにおけるセキュリティ対策の徹底が不可欠である。ヘルプデスクは、システムと人間の接点となる部分であり、ここが脆弱だと、どんなに強固な技術的セキュリティ対策を施していても、容易に突破されてしまう可能性がある。本人確認は、単に「お名前は？」と聞くだけでなく、事前に登録された秘密の質問、部署コード、社員番号と連動した情報など、複数の要素を組み合わせて厳格に行う必要がある。そして、疑わしい点があれば、一度電話を切って登録されている正規の連絡先に折り返す、といった慎重な対応も求められる。

もう一つの重要な教訓は、「監査証跡（audit trails）」の必要性だ。監査証跡とは、システム上で行われた操作の記録、例えば、いつ、誰が、どのシステムにアクセスし、どのような変更を加えたか、といった情報を時系列で記録しておくことである。今回の事件で言えば、ヘルプデスクがパスワードやMFAをリセットした日時、その依頼元、対応した担当者などが詳細に記録されていれば、異常なリセット要求があった場合に早期に検知できたり、万が一不正アクセスが発生した場合でも、その経路や被害範囲を特定するのに役立ったりする。監査証跡は、インシデント発生時の原因究明や、再発防止策の検討に不可欠な情報源となる。また、定期的な監査を行うことで、システムのセキュリティポリシーが正しく運用されているかを確認する上でも重要な役割を果たす。

システムエンジニアを目指す皆さんにとって、このClorox社の事件は、セキュリティが単にファイアウォールやアンチウイルスソフトを導入することだけではないことを教えてくれる。システム開発や運用に携わる際、私たちは常に「人がどのようにシステムを利用するか」「人がどのように管理するか」という視点を持つ必要がある。特に、ヘルプデスクのような人とシステムが密接に関わる部分は、攻撃者にとって格好の標的となるため、設計段階から厳格な本人確認プロセスを組み込み、その運用ルールを徹底させることが求められる。また、ログの設計と管理もSEの重要な仕事の一部だ。どんな情報が、どのような形式で記録され、どれくらいの期間保存されるべきか。これらの設計が適切でなければ、事件が発生した際に原因究明に手間取ったり、そもそも何が起きたのかさえ把握できなかったりする可能性がある。

今回の事件は、いかに優れた技術的セキュリティ対策を導入していても、それを運用する「人」と「プロセス」に脆弱性があれば、多大な被害につながることを明確に示している。システムエンジニアは、単にコードを書くだけでなく、セキュリティを考慮したシステムの全体設計、そしてそれを運用する人々のための安全なプロセスの構築までを視野に入れる必要がある。セキュリティは、技術的な側面だけでなく、組織文化や従業員への教育、そして厳格な運用ルールと監視体制が一体となって初めて機能するものなのだ。この事件から学び、未来のシステムをより安全に設計・運用できるシステムエンジニアを目指してほしい。