システムが動いていても安全とは限らない

 

ここにサイバー攻撃の難しさがある。ランサムウェアならファイルが暗号化され、システムが止まるため、被害そのものはわかりやすい。しかし情報を盗むことが目的なら、攻撃者にとって侵入を知られない方が都合がよい。システムを正常に動かしたまま内部を探索し、権限を奪い、必要な情報を探すこともできる。利用者から見れば何も起きていない。サービスも利用できる。企業側でも目立った障害がない。それでも内部で異常が進行している可能性はある。だから「システムが正常に動いている」ことと、「システムが安全である」ことは同じではない。

 

さくらインターネットの事案で注目すべきなのも、136万という数字だけではない。8月9日の異常をきっかけに詳しく調べたことで、それ以前には把握されていなかった事象が次々と明らかになったことである。

 

小さな異常を「その程度」で終わらせない

 

そこで必要になるのが、以前のコラムで「サイバー攻撃の棚卸し」と呼んだ作業である。企業では日常的に小さなシステムトラブルが起きる。端末の動作が突然遅くなった、見慣れない通信が発生した、認証に失敗した、サーバーが一時的に不安定になった、設定がいつの間にか変わっていた。結果として業務に大きな影響がなければ、「復旧したから問題ない」と処理されることもあるだろう。しかし、その小さな異常が攻撃の兆候ではなかったと確認できているだろうか。

 

製造業や医療の安全管理では、大事故には至らなかった「ヒヤリ・ハット」を集め、その原因を分析する。情報システムでも同じ発想が必要だ。小さな障害や不自然な挙動があれば、直して終わりにするのではなく、「なぜ起きたのか」を確認する。原因がわからなければ、正常に戻ったように見えても、それで調査を終わらせない。セキュリティ部門だけでなく、現場で経験したヒヤリ・ハットを共有し、似た事象が別の部署やサーバーで起きていないかを確認する。「復旧した」ではなく、「原因までわかった」ことを正常性確認の区切りにするのである。

 

何も起きていない時に調べる

 

もう一つ必要なのは、異常が起きていない時にも調べることである。見覚えのないアカウントはないか。必要以上の管理者権限が残っていないか。不審な外部通信はないか。サーバーに未知のプログラムやファイルが置かれていないか。認証記録や操作記録に通常とは違う動きがないか。設定が意図せず変更されていないか。こうした点を定期的に確認する。会計や倉庫では、帳簿上の数字だけを信用せず、実際の資産や在庫を確認するために棚卸しを行う。情報システムについても、「対策を導入しているから大丈夫」と考えるのではなく、現在のシステムが本当に想定した状態にあるのかを実物で確かめる必要がある。さくらインターネットも第三報で、管理者権限・アクセス権限の総点検、監視対象と検知機能の拡充、ログの取得範囲・保管期間・分析体制の見直し、定期的な外部監査や第三者評価などを再発防止策として挙げている。

 

「事件が起きていない」は安全の証明ではない

 

セキュリティ対策では、侵入を防ぐことに目が向きやすい。ファイアウォール、EDR、多要素認証、OSの更新はいずれも必要である。しかし、どれほど対策を重ねても侵入の可能性をゼロにはできない。そこで発想を変える必要がある。「侵入されないようにする」だけでなく、「すでに侵入されていないかを定期的に確かめる」のである。そして、日常の小さな異常を記録する。ヒヤリ・ハットを組織で共有する。原因不明のトラブルを放置しない。ログ、アカウント、権限、通信、プログラム、設定を定期的に調べる。これが「サイバー攻撃の棚卸し」である。

 

サイバー攻撃で怖いのは、発見した攻撃だけではない。まだ発見できていない攻撃が、自分たちのシステムの中に存在する可能性である。何も起きていないように見える時こそ、本当に何も起きていないのかを確かめる。その習慣が、長期間発見されない攻撃を少しでも早く見つけるための出発点になる。