8/11に富士通ProjectWebへの不正アクセス事件での続報が出ていました。
www.nikkei.com
富士通の情報共有ツールに第三者からの不正アクセスがあり、複数の顧客情報が外部に流出した問題で、同社は11日、社内調査の結果、129の中央省庁や企業などから情報が漏れていたと発表した。外部の有識者による検証委員会を設置し、さらに対応や原因について検証する。
社内調査を進めたところ、不正アクセスによって情報システムの機器情報やプロジェクトの体制図、個人情報などが流出していたことが分かった。第三者が同ツールの脆弱性を悪用し、正規利用者のIDとパスワードを取得してログインしたとしている。富士通によると、これまでに悪用被害は確認していない。
公式発表
・プロジェクト情報共有ツールへの不正アクセスについて（第二報）
・プロジェクト情報共有ツールへの不正アクセスについて（第三報）
※9/28追記：第三報を受けてか当ブログの記事がアクセスが増えていたので、少し補記します。
キタきつねの所感
ProjectWebは富士通が社内のナレッジマネージメント（プロジェクト管理）ツールとして1998年に導入したもので、その後、富士通社内だけでなく顧客企業にも提供される様になりました。
今回の第2報で侵害を受けた原因部分について富士通は、他のサービス等で漏えいした認証情報（≒パスワードの使い回し）に起因するものではなく、0ディ攻撃だった可能性を示唆しています。
本事案は、第三者が正規のIDとパスワードを使用し、正常認証および正常通信により、本ツールに対して外部から不正アクセスを行ったものであることが判明しております。正規のIDとパスワードを使用し正常認証および正常通信によりログインできた原因は、本ツールの何らかの脆弱性を悪用したものである可能性が高いと考えております。
（公式発表より引用）
当然の事ながらセキュリティ対策を含めたバージョンアップはされてきたと思いますが、その基本設計が1990年代であった（であろう）事を考えると、20年以上も運用しているサービスに、未知の脆弱性があった理由の１つは「長く引っ張り過ぎた」事にあるのかも知れません。
※ProjectWebのリリースノートを確認できていない（見つけられなかった）ので、実は名前が変わってないだけで最新のセキュリティ対策がされたサービスにメジャーバージョンアップされていた（上記記載が間違いである）可能性もあります。
Windowsの世界に例えると、2000年頃（約20年前）と言えば、Windows98やWindowsMEが丁度この頃にリリース（WindowsXPのリリースが2001年）されていますので、セキュリティ面でも大幅な機能改訂がされてなかったとすれば、年々脅威を増すサイバー攻撃には耐えられなかったという事は十分考えられそうです。
（以下想像が過分に入ります）
被害組織は、詳細に公開されている訳ではありませんが、第2報では129の中央省庁や企業と公表されており、その中にはNISCや外務省、国土交通省など、保有していた情報資産価値が、一般企業と比べて高い組織も含まれています。
この事から、攻撃側は、公官庁にProjectWebが「導入されていた」事を知っていて、そのユーザ企業（≒公官庁や自治体）のデータを狙って攻撃を仕掛けてきた気がします。
漏えいした情報に関して、第2報では以下の様に書かれています。
影響範囲および原因の調査・分析は、セキュリティに関する専門知識を有する当社技術者を集結させ、社長直轄の全社を挙げた体制を構築し対応に努めてまいりました。その結果、129のお客様に関して、本ツールに保存されていた情報の一部が不正に閲覧またはダウンロードされたことが判明しております。閲覧またはダウンロードされた情報は、お客様のシステムに関する情報（システムを構成する機器類に関する情報等）、プロジェクト運営に関する資料（体制図、打合せメモ、作業項目一覧、進捗管理表、社内事務手続きに関する資料等）、その他公開情報等であり、その一部にはお客様および関係者の氏名・メールアドレス等の個人情報が含まれていたことも確認されております。
ProjectWebは、当然の事ではありますがプロジェクト管理ツールなので、ToDoListやスケジュール等の機能があり、そこからも上記の情報が漏えいした可能性があるのかと思いますが、漏えいの影響が最も懸念されるのはファイル共有機能（ライブラリ）ではないでしょうか。
※富士通の資料（少し古い気もしますが）ではシステム開発時のツール利用を以下の様に説明しています。
※フィッシングや別なサイバー攻撃への転用という面では個人情報（氏名・メールアドレス等）も被害を受けた組織が組織だけに懸念されます。
今の所、悪用は確認されていない旨、富士通は第2報に書いていますが、気になる情報をDarkWeb上に確認しています。
この記載が事実かどうかは、サンプルデータ（見せしめ）が公開されていないので分かりませんが、近い内に第3報を富士通が出す必要性が出てくる事が懸念されます。
※9/28追記：掲載サンプルは某大手繊維メーカー（1社だけ）のものが公開されており、富士通も「富士通側は証拠はなく関連ないものと考えている」と否定した様ですが、富士通名が明記されている事を考えると、販売されているデータやそれ以外の流出データも存在する可能性は残留していると思います。
海外ではSolarWinds、Accellion FTA、Kaseya等、サードパーティが攻撃を受け多くのエンドユーザーが影響を受けるサイバー攻撃事例がいくつも出てきています。
国内でも宅ファイル便やソリトン等が以前侵害を発表しましたが、富士通もこうした過去のインシデントをヒヤリ・ハットとして、自社サービスのセキュリティを見直すきっかけにしていれば、もしかすると侵害の影響を抑えられたのではないでしょうか。
余談となりますが、Kaseyaの件で攻撃を実行したREvilがマスター復号鍵をハッカーフォーラムにリークした件が話題となっていますが、関連記事に面白い記載を見つけました。
dzone.com
最も明白な問題の中には、古いコードに支えられたソフトウェア、Kaseyaの製品とサーバーでの弱い暗号化とパスワードの使用、定期的なソフトウェアのパッチ適用などの基本的なサイバーセキュリティ慣行の遵守の失敗、他の優先事項を犠牲にして販売に焦点を当てることがありました。従業員は言った。
元従業員の1人は、2019年の初めに、セキュリティ上の懸念を詳述した40ページのメモを会社のリーダーに送り、約2週間後に解雇されたと述べました。これは、問題を報告するための彼の繰り返しの努力に関連していると考えました。
別の従業員は、Kaseyaがサードパーティのプラットフォームでソフトウェアやサーバーにパッチを適用したり、顧客のパスワードをクリアテキストで保存したりすることはめったにないと述べました。
同社の一部のエンジニアや開発者は、問題の修正よりも新機能や新製品が優先されていることへの不満を従業員がやめたと述べています。他の人は2018年に解雇され、カセヤはベラルーシのミンスクに仕事を移し始めました。そこでは、以前に米国で行われていたソフトウェア開発作業を行うために40人以上を採用しました。 。元労働者のうち4人は、ベラルーシがロシア政府と緊密な政治的忠誠を持っていることを考えると、ベラルーシへの仕事のアウトソーシングを潜在的な安全保障問題と見なしていると述べた。
日本のIT（DX）をリードする富士通のサービスに、こうしたKaseyaの様な「脆弱点」は無かったと思いますが、今後出てくるであろう外部有識者の検証委員会による最終レポート（の発表）で、攻撃を受けた原因部分を公開して頂けると、他の組織・企業にも参考になるかと思います。
更に余談です。PPAPの有力な代替策がファイル共有サービスの利用かと思いますが、ProjectWebや宅ファイル便の様に、ファイル共有サービス自体のセキュリティに問題があった場合、メール（PPAP）より影響範囲が大きくなる可能性もあります。
その事を考えると、復号パスワードの2経路送信なども代替策の候補に入れる（もっと注目される）べきだと思います。
※【P】assword（パスワード）zipファイル添付メール送信
【P】asswordのメール送信
⇒例：プロジェクト固定Password事前取り決めor2経路（例えばSMS）送信
【A】ん号化 （暗号化）
【P】rotocol（プロトコル）
※9/28追記：富士通の第三報は第二報から約1か月経過して9/24に出されていますが、追加の原因部分や影響範囲はほぼ書かれておらず、体制強化や再発防止策などが書かれているだけで、被害を受けた顧客に”個別報告”で終わらそうとしている様にも思えます。
例えば上記のMarketoでサンプルデータを漏えいされている某繊維企業が”ProjectWeb”利用ユーザかどうかを伺わせる様な記載もありません（否定されていません）。
そうした詳細は今後「検証委員会」の検証作業結果として出てくるのかも知れませんが、第三報でそれを伺わせる否定表現が含まれていない事を考えると、影響を受けた公官庁を始めとする被害組織の手前、あまりオープンに出来ない情報が多々あるのかも知れません。
※とは言え「検証委員会」の検証結果が一般に公開されるとも明言されてはいないので、無いとは思いますが、（機微な部分を隠した上でも）”公開されない”可能性も考えられます。
当社では、本事案を重く受け止め、関係当局へのご相談を進めるとともに、早期の信頼回復を目指し、引き続きお客様対応に全力で努めてまいります。また、本事案の原因および当社の対応について、外部有識者による「検証委員会※」を設置し客観的な視点での検証作業を進め、これらの結果を踏まえ、実効的な再発防止策を講じてまいります。
（第2報から引用）
※”これらの結果”（検証結果）は、”再発防止策”にかかっている（≒公開しない）様にも読み取れます。
第3報を読んでいて、もう1点気になったのがCISO任命の部分です。富士通たる大企業でCISOを設置してなかったのか？・・・と思ったのですが、
専任のCISOおよびCISO補佐の任命について
本年10月1日付で理事 太田 雅浩をCISO、理事 花山 亨をCISO補佐に任命。
情報セキュリティリスク対応の専門性・特殊性に加え、現場の実態も踏まえた施策を実行。
2019年4月の執行役員および理事人事についてでは、CISOが副社長兼務となっていましたので、CISOは従来から設置されていた事が分かります。
海外が主担当に見える副社長が兼務？と思わなくもありませんが、技術的知見も含め、当時は適任人事と判断されたのだろうと推察します。
今回の第三報での発表では、「専任のCISO」及びCISO補佐を任命と書かれており、ProjectWebへの攻撃を受けて、情報セキュリティ管理・運用に関して、兼務の弊害が確認されたという事なのかと推察します。
企業規模、担当内容などによっても違いがありますし、情報セキュリティ分野での知見も加味されるものなので一概には言えませんが、富士通ほどの大企業で兼務CISOは無理があったのかなと思います。
因みに、第三報では以下の様に「新たな情報セキュリティ管理・運用体制」について書かれています。
2. 新たな情報セキュリティ管理・運用体制について
・情報管理のあり方に関してCISOによる社内関連部門の統率を強化し、全体をマネジメントする体制を再構築。
・情報セキュリティに関して各部門を統率するリソースをCISO直轄の組織に再配置。
CISOを中心とした経営幹部、対応要員の緊急招集スキームを改善し、大規模セキュリティインシデントにおける初動の迅速性を向上。
・関係機関との連携も含めて、社内セキュリティ体制を一元的に管理するCISO体制の強化。
通常こうした改善策の内容は、改善の反対内容が「脆弱点」であったと推察されますので、
①CISOは全体マネジメントできる状態にはなかった
②緊急招集スキームに問題があり、初動が遅かった
③社内セキュリティ体制は関係機関とは連携されず、一元的に管理されてなかった
と裏読みする事が出来ます。
この想像が合っているかは分かりませんが、想像通りだとすれば、従来のCISO（CSIRT）は、組織の問題を把握できていなかった事に他ならず、大きなインシデントが発生しない事を前提とした平時のCISOだったと考えられ、片手間でCISOの責を負うには、やはり不適任だったのかと思います。
※今後の富士通の情報公開、検証委員会の検証結果等がありましたら追記、あるいは新たに記事を書くかも知れません。
本日もご来訪ありがとうございました。
Thank you for your visit. Let me know your thoughts in the comments.
更新履歴
