警報メールは約430人に届いた。直す担当者は、正式には決まっていなかった

おはようございます。昨日は、繊維事業を持つ国内の上場会社グループの子会社で、与信限度額に近づいたときの照会が、取引を回していた本人の説明で閉じられていた事案でした。

今日の「警告は出ていた」は、社内の配信リストで約430人に送られた警報メールです。米国の大手信用情報会社で、重大な脆弱性の警報が届いたあと、何が起きなかったかを読みます。

2018年12月、米国下院の監視・政府改革委員会の多数派スタッフは、米国の大手信用情報会社の情報流出についての報告書を公表した。証言の記録と、会社が委員会に出した社内文書をもとにしたもので、当局の処分や裁判所の認定ではない。以下の事実と評価は、この報告書の記載である。

会社は2017年9月7日、1億4,300万人の消費者に影響する事故を公表した。人数はのちに1億4,800万人に増えた。報告書によれば、米国の人口のほぼ半分にあたる。

入口は、ウェブのアプリを動かすソフトの部品(Apache Struts)の重大な脆弱性だった。2017年3月7日に公表され、翌8日、国土安全保障省の緊急対応チーム(US-CERT)が会社に通知した。3月9日、社内の脅威・脆弱性管理チームが、この通知を社内の配信リストで流した。

約430人と複数の配布リストが、このメールを受け取った。メールは、この部品を導入している担当者に、特定の版へ更新するよう指示していた。(拙訳) メールにはこう書かれていた。この脆弱性には攻撃の手段が出回っており、現に悪用されているため、重大なリスクと評価され、セキュリティ方針により48時間以内のパッチ適用を要する。(拙訳)

セキュリティ部門は、脆弱な版を使うシステムを探すスキャンも行った。結果は「該当なし」だった。事故後の暫定の最高セキュリティ責任者は、こう説明している。スキャンは最上位のフォルダで実行され、この部品があった下位のフォルダを見ていなかったため、脆弱性を見落とした。(拙訳) 3月15日には別の道具で、外部に面した958のIPアドレスを2回スキャンしたが、やはり見つからなかった。翌16日の月例会議でもこの脆弱性が取り上げられ、資料は配信リストの430人全員に改めて送られた。

消費者が自分の信用情報の誤りに異議を申し立てるシステム(1970年代に作られたもの。以下、異議申立てシステム)は、脆弱な版を使ったままだった。5月13日、攻撃者はこの脆弱性から侵入した。暗号化されていない認証情報を見つけ、無関係な48のデータベースに入り、約9,000回の照会のうち265回で個人情報を探し当てて、外へ持ち出した。攻撃は76日間続いた。

気づかなかった理由も、報告書は書く。異議申立てシステムの暗号化された通信は、検査する装置を通ってから中へ入る仕組みだった。この領域を監視する装置に入っていた証明書は、2016年1月31日に期限が切れていた。その結果、会社は19か月にわたり、このシステムの環境の通信を見ることができなかった。(拙訳) 装置は初期設定のまま、証明書が切れても通信を通し続けていた。報告書によれば、会社は300を超える証明書を期限切れのままにしており、うち79は事業上重要な領域の監視用だった。

2017年7月29日、会社は期限切れの証明書を更新し、直後に不審なウェブの通信に気づいた。(拙訳)

ここが今日の分岐点である。警報は、期限つきで、430人に届いていた。では、異議申立てシステムを直すのは誰だったのか。

会社には2016年版のパッチ管理方針があった。事業の持ち主がシステムを止める時間を承認し、システムの持ち主がパッチを当て、アプリの持ち主が正しく当たったことを確かめる。警報メールは、こうした持ち主たちに届く前提だった。報告書はこう書く。委員会への証言によれば、方針で役割と責任は定められていたが、その役割に正式に指名された人はいなかった。(拙訳)

委員会は、異議申立てシステムの環境を管理していた上級副社長(グローバル企業プラットフォーム担当の最高情報責任者)に、このシステムの持ち主を役割ごとに挙げるよう求めた。答えはこうだった。だから、アプリの持ち主の明示的な指名は無かったと思います。(拙訳) 彼は、聞かれれば自分ならこの人たちだと思う、という形で名前を挙げた。システムの持ち主についても指名されていなかったと述べ、推測で答えた。

届いたかを確かめる手段もなかった。当時の最高セキュリティ責任者と最高情報責任者はいずれも、パッチが必要だと正しい人に伝わったことを確かめる二重の仕組みは、パッチの手順の中に無かったと証言した。(拙訳) 最高情報責任者は、約400人へのメールのほかに持ち主たちへ知らせる方法を知っていたかと問われ、知らないと答えている。報告書が引く2015年の社内監査は、パッチの適用の確認が担当者の自己申告に頼っていて、期限内に直らない重大な脆弱性を上へ上げる仕組みが無い、とすでに指摘していた。

事故のあと、会社は責任を問うた。最高情報責任者と最高セキュリティ責任者は公表の8日後に早期退職し、CEOも9月26日に会社を去った。10月2日、会社は、脆弱性についてのメールを転送しなかったとして、先の上級副社長を解雇した。翌3日、すでに退任していた元CEOが議会で証言した。人のミスとは、組織の中でパッチを当てるよう伝える責任を負った個人が、それをしなかったことです。(拙訳)

報告書は、別の事実を並べる。この上級副社長は、脆弱性の警報メールを送られた430人の従業員の1人にすぎなかった。(拙訳) 本人は、メールは情報として写しを受けただけで、方針の上で自分はシステムの持ち主でもアプリの持ち主でもなかったと証言した。誰かから転送を指示されたこともなかった。本人の言葉はこうである。

組織の上級副社長が、すべての警報について、脆弱性の警報を……組織の3階層か4階層下の人たちに転送しているべきだと主張するのは、筋が通らないし、意味をなさない。それが会社の頼らなければならない手順なのだとしたら、それは問題です。(拙訳)

報告書(多数派スタッフ)は、この解雇を、広報を動機とした措置で、事実全体に照らせばいわれのないものに見える、と評価している。

報告書によれば、2016年版のパッチ管理方針が定める「システムの持ち主」「アプリの持ち主」は、異議申立てシステムについてどうなっていたか。

正解: 1

解説: 委員会への証言によれば、役割と責任は方針に書かれていたが、正式な指名はなかった。システムの環境を管理していた上級副社長も、持ち主の名前は推測でしか挙げられなかった。本便では、警報は役割に宛てて出ていたが、その役割に名前が入っていなかったと読んだ。

誤答の罠: 2を選びたくなる。メールが届かなかったことを原因と考えると分かりやすい。この事例では、メールは約430人に届き、資料も再送されていた。届くべき人が、そもそも決まっていなかった。

報告書によれば、攻撃者が76日間にわたって情報を持ち出していた間、会社が気づかなかったのはなぜか。

正解: 2

解説: 侵入を検知・防止する装置は、通信を検査する装置の後ろにあった。証明書が切れると暗号化された通信はそのまま通り、検査されない。報告書によれば、この状態が19か月続き、2017年7月29日に証明書を更新した直後に不審な通信が見つかった。本便では、警報を出すはずの装置そのものが、黙ったまま動き続けていたと読んだ。

誤答の罠: 4を選びたくなる。気づかなかったのなら装置が無かったのだろう、と考えやすい。装置はあり、初期設定のまま通信を通し続けていた。

(仮想の場面)重大な脆弱性の警報が来た。セキュリティ部門は、関係しそうな約400人に「48時間以内に直してください」とメールを送った。あなたはIT部門の責任者である。次にすることとして、本便が勧めるのはどれか。

正解: 2

解説: この事例では、方針の役割に正式な指名がなく、警報が正しい人に届いたかを確かめる二重の仕組みも無かった。スキャンは最上位のフォルダしか見ずに「該当なし」を返した。システムごとに名前を1人書き、期限に一人ずつ確かめる、という手順は、報告書の提言でなく、本便の提案である。

誤答の罠: 3は、会社が事後に「すべきだった」とした行動に近い。ただ、解雇された上級副社長は、すべての警報を3〜4階層下へ転送するという前提そのものが筋が通らないと証言している。転送する人が増えても、直す人の名前は決まらない。1と4は仮想の選択肢である。この事例で実際に起きたのは、メールの配信、会議での再度の周知、2つの道具によるスキャンが行われ、それでも異議申立てシステムが直っていないことを誰もつかめなかった、という経過だった。

この事例を選んだのは、警報が、期限つきで、繰り返し出ていたからです。政府からの通知は翌日に社内へ流れ、重大度と48時間という期限が書かれ、宛先は400人を超え、1週間後の会議でもう一度取り上げられていました。

それでも、報告書によれば、異議申立てシステムを直す役割には、方針の上で正式に指名された人がいませんでした。上級副社長は委員会に聞かれて候補の名前を挙げましたが、それは推測でした。方針には役割の名前が並び、メールはその役割に宛てて出ていました。役割に正式に人が入っていなければ、430人に届いた警報は、430人の誰のものでもなくなります。

私は、警報の仕組みを見るとき、宛先の広さより先に、システムごとに直す人の名前が1人書かれているかと、直ったことを誰が確かめるかを見るべきだと考えています。事故のあと、会社はメールを転送しなかった1人を解雇しました。仕組みの空白を、1人の行動の問題にすり替えると、次の警報の宛先にも名前は入らないと私は考えています。

今日、自社で直近に出た重大な脆弱性の警報(または広い範囲への一斉の通知)を1つ選び、対象のシステムごとに「直す人」の名前が1人ずつ書かれた一覧があるかを、情報システムの担当者に聞いて確かめる。無ければ、その警報で、直ったことを誰がどう確かめたかを聞く。

このシリーズ「朝3分の分岐点」は平日毎朝、実際の事件から「判断の型」をひとつお届けします。

PS(いつでも・何度でも): 最近、「このルール何のためだっけ」と思った瞬間はありましたか。
一行で返信いただければ、必ず私が読んで、私が返します。