日本年金機構の情報漏洩事件のニュースを聞き、よくある添付メール攻撃なのにウィルス感染してしまったことについて、あらためて感じることがありました。
仕事の中で受け取るメールの大半は、こんな形式のものです。
これでは、発信者が偽装され、もっともらしい件名で、もっともらしい文面で、もっともらしい添付ファイル名であれば、通常の業務として開いて見てしまうのは当然のように思います。たまたま担当者にピンポイントで攻撃されれば、防ぎようがありません。ましてや、既知のウィルスならばともかく新種のウィルスであれば、過去のウイルス情報をもとに対応されるウィルス対策ソフトも役立ちません。
組織内部の情報管理の問題としてとらえたときに、この、添付ファイルに依存した文書通知の在り方に、弱点を感じます。メールによる文書通知の大半は、メールの本文に通知の中身が書いてあればすむのではないかと思います。
要するに、文書の権威付け（オーソライズ）を、添付ファイルという機能に頼っているわけです。このあたりは、文書習慣というか、文書規定というか、そのレベルで考えないといけない問題なのでしょう。
CADデータや、マクロを含む表計算のシート、あるいは写真画像などは添付ファイルによることになるとは思いますが、全体の比率から言えば、大半は普通のワープロ文書(DOCなど)かそのPDFファイルでしょうから、内容を本文に書くことで、危険性はかなり軽減されるはずです。
この議論は、パソコン通信の昔から言われていたことですが、「起こる可能性のあることは、起こる」「起こってほしくないことは、最悪の形で起こる」というマーフィーの法則を、あらためて実感することとなりました。
○
もう一つ、LAN 内で異常を発見した時に、外部と接続している基幹ケーブルを大至急で抜くことが重要なわけですが、大きな組織であるほど、外部接続を遮断することの影響は大きく、判断は難しく、抵抗も大きいでしょう。通常の稟議システムにのせていたら、間に合わないことが予想されます。危機管理の中に、情報システムのトラブル対応が位置づけられ、かつ適切に運用されるかどうかが問われます。
だいぶ以前の話ですが、Nimda ウィルスが米国に登場したニュースを読んで、何の気なしに職場のサーバを調べてみました。そうしたら、FreeBSD のウェブ・サーバは大丈夫だったものの、発見後わずか数日しか経過していない日本で、WindowsNT ファイル・サーバに Nimdaウィルスの痕跡を発見してしまいました。即刻、上司に報告してファイルサーバを遮断し、全端末について、LANケーブルの抜線の指示を出しました。それからサーバは業者に復旧を依頼し、端末は根気よく1台ずつ点検・駆除して回り、作業が終わったものから接続することで、ようやく緊急対応終了。この間、数日間は夜なべ仕事だったはず。結局、感染していた端末は3～4台だけだったと記憶しています。発見が早かったのが幸いしたようです。当時、私もまだヒラの40代、若かった。一応システム管理者とはいうものの、職掌上の位置づけはきわめて弱いものでしたが、管理職には全面的に信頼してもらい、業務に支障を来す強引な対応にも、職場の皆が文句も言わずに従ってくれたことに感謝したものでした。
このときの経験から、Windows の持つ脆弱性を感じ、それ以前にも興味は持っておりましたが、Linux に決定的に惹かれるようになったものです。今にして思えば、素早い判断が、被害を最小限にし、早い復旧ができた理由だったと思います。
仕事の中で受け取るメールの大半は、こんな形式のものです。
--
From: ○○○○(XXXXXXXX) [mailto:abcdefg@xxxxxxx～]
Sent: Tuesday,June,XX,2015 x:xx PM
To: △△△△
Subject: [件名]～
△△△△ 様
XXXXXXXX の○○○○です。
件名につきまして、～です。
つきましては、～ようにお願いします。
[メッセージ] aaaaaaaaaaaについて.DOC (xx KB)
--
これでは、発信者が偽装され、もっともらしい件名で、もっともらしい文面で、もっともらしい添付ファイル名であれば、通常の業務として開いて見てしまうのは当然のように思います。たまたま担当者にピンポイントで攻撃されれば、防ぎようがありません。ましてや、既知のウィルスならばともかく新種のウィルスであれば、過去のウイルス情報をもとに対応されるウィルス対策ソフトも役立ちません。
組織内部の情報管理の問題としてとらえたときに、この、添付ファイルに依存した文書通知の在り方に、弱点を感じます。メールによる文書通知の大半は、メールの本文に通知の中身が書いてあればすむのではないかと思います。
--
From: ○○○○(XXXXXXXX) [mailto:abcdefg@xxxxxxx～]
Sent: Tuesday,June,02,2015 3:14PM
To: △△△△
Subject: [件名]～
△△△△ 様
XXXXXXXX の○○○○です。
件名につきまして、～です。
つきましては、以下のようにお願いします。
--
（文書記号番号）
平成○○年○月○○日
各○○○○長殿
発信者(偉い人)の職・氏名
○○○○○○について（依頼）
～（文書の内容）～
以上
--
要するに、文書の権威付け（オーソライズ）を、添付ファイルという機能に頼っているわけです。このあたりは、文書習慣というか、文書規定というか、そのレベルで考えないといけない問題なのでしょう。
CADデータや、マクロを含む表計算のシート、あるいは写真画像などは添付ファイルによることになるとは思いますが、全体の比率から言えば、大半は普通のワープロ文書(DOCなど)かそのPDFファイルでしょうから、内容を本文に書くことで、危険性はかなり軽減されるはずです。
この議論は、パソコン通信の昔から言われていたことですが、「起こる可能性のあることは、起こる」「起こってほしくないことは、最悪の形で起こる」というマーフィーの法則を、あらためて実感することとなりました。
○
もう一つ、LAN 内で異常を発見した時に、外部と接続している基幹ケーブルを大至急で抜くことが重要なわけですが、大きな組織であるほど、外部接続を遮断することの影響は大きく、判断は難しく、抵抗も大きいでしょう。通常の稟議システムにのせていたら、間に合わないことが予想されます。危機管理の中に、情報システムのトラブル対応が位置づけられ、かつ適切に運用されるかどうかが問われます。
だいぶ以前の話ですが、Nimda ウィルスが米国に登場したニュースを読んで、何の気なしに職場のサーバを調べてみました。そうしたら、FreeBSD のウェブ・サーバは大丈夫だったものの、発見後わずか数日しか経過していない日本で、WindowsNT ファイル・サーバに Nimdaウィルスの痕跡を発見してしまいました。即刻、上司に報告してファイルサーバを遮断し、全端末について、LANケーブルの抜線の指示を出しました。それからサーバは業者に復旧を依頼し、端末は根気よく1台ずつ点検・駆除して回り、作業が終わったものから接続することで、ようやく緊急対応終了。この間、数日間は夜なべ仕事だったはず。結局、感染していた端末は3～4台だけだったと記憶しています。発見が早かったのが幸いしたようです。当時、私もまだヒラの40代、若かった。一応システム管理者とはいうものの、職掌上の位置づけはきわめて弱いものでしたが、管理職には全面的に信頼してもらい、業務に支障を来す強引な対応にも、職場の皆が文句も言わずに従ってくれたことに感謝したものでした。
このときの経験から、Windows の持つ脆弱性を感じ、それ以前にも興味は持っておりましたが、Linux に決定的に惹かれるようになったものです。今にして思えば、素早い判断が、被害を最小限にし、早い復旧ができた理由だったと思います。
アクセス
トータル
ランキング
つまり、どこでも、いつでも発生すべき問題なのでしょう。Wordの添付ファイル問題はいつもイライラさせられて、公文書は仕方がないのかなぁ、用件は本文にべた打ち、ケータイに転送されることを考えれば、題名のみで用件がわかるようにして下さると助かる、いつもそう思っておりました。
マイ・ナンバー制はもっと大事になりますよ、きっと。
-お写真-
まぁ、素敵なお庭、日本庭園‘つぼにわ’といった感じがします。つつじが咲いてますね、池には錦鯉でしょうか・・・？
ただ、それが権威付けと関連しているとは気がつきませんでした。
黒塗りの文箱に入った巻物を「ははーっ」と平伏して受け取り、恐れ入り奉りながら拝見させていただきます～という気分なのかも知れませんね。
マイナンバー制ね～。やれやれ(^o^;)>poripori
山形市内の、某料亭のお庭です。滅多に行けないところですので、一度写真に収めたかったのです。役得でした(^o^)/
本文と写真とは、ぜんぜん関係がありませんですよ(^o^)/
メールの時代には、発信者は詐称できますし、信頼性を担保する方策として、この「赤いハンコを押してある文書」の代わりにWORDの文書とかPDFファイルを添付してオーソライズすることとなったのだろう、と想像しています。