3月11日を迎えました。
あの日は新宿の高層ビルの18階で働いていました。
地震の揺れはもちろん激しかったのですが、わたしは激しさよりも、ぐらぐらと揺れる長さを覚えています。
大きな窓からは別な高層ビルが見えたのですが、高いビルが横にぐらぐらと揺れる光景を初めて見ました。
揺れを感じながら、次第に吐き気を感じました。
窓から目に入る建物の大きな揺れと、自分の身体のなかにある平衡感覚が不一致になったんだと思います。その不一致感が脳を混乱させ、めまいや吐き気になったと思います。
東日本大震災は「長周期地震動」と言われます。
長周期振動は通常の地震よりも揺れの周期が長い地震です。揺れがゆっくりとしたリズムで地表を移動するように感じるようです。地震に於いて周期が2秒以上を「長周期」と呼び、そのような地震は、高層ビルを横にゆらゆらと大きく揺らす特徴があるようです。
地震の翌日から、大きな社会問題になったのが、津波による福島原発の事故です。
原発の事故で放射性物質の漏えいが明らかとなりました。
放射性物質は、事故から長くても3日後には東京にも届きました。
福島原発事故が発生した2011年3月、新宿MP（モニタリングポスト）は15日から16日にかけて、複数回にわたり空間線量率の急上昇をとらえており、一時間あたりの最大値で0.089 µGy/hを記録した。
～「東京都における福島第一原子力発電所事故後の空間線量率の推移と変動要因」（小西 浩之 、冨 士 栄 聡 子、生嶋 清美、鈴木 俊也、保坂 三継 、栗 田 雅 行）
福島第一原発から新宿区東京都庁までは直線距離で 226km です。わたしは港北ニュータウンに住んでいるのですが、GoogleMAPで調べるとそこまでの距離は 245kmでした。ですので、放射性物質が新宿に到達したのと、大差のないタイミングでわたしの住む街にも放射性物質が来ているはずです。
ただ、わたしを含めて首都圏に住む多くの方があのとき困ったのは、放射性物質より計画停電による生活や通勤の不便さでした。計画停電に伴い、朝の最寄り駅は通勤客で長打の列をなしました。わたしの勤務先は出社時刻を任意にする措置がとられました。
でも、もしあのとき大量の放射能が街に届いたら、通勤なんかより、まずはそこから一刻も早く逃げるべきでしょう。福島原発の事故が発生したとき、事故による放射能汚染の被害がどこまで拡大するかの予測は、誰も出来ていませんでした。
しかし、港北ニュータウンに住む皆が、西へ西へと逃げる選択をとったら、東名高速や国道246は、大量の車が殺到し、全く動くことが出来なくなります。日本は地形的に中央を大きな山脈がつらなり、逃げる道は限られてます。狭い平野部に人口が集中しているので、大勢が迅速に遠くへ遠くへと避難するには、あまりにも難しい構造です。
津波であれば、足を使って急いで高台に避難することでも可能です。でも、原発事故で風で運ばれてくる放射能から、車を飛ばして逃げるのは、事実上無理です。
混乱を防ぐ為、国としても緊急対策としての避難指示は、出来るだけ控えめにしようと考えるのは当然かもしれません。
- 緊急対策をしなければならない
- 混乱はできるだけ避けたい
１は理論で、２は感情です。よく、「安全」と「安心」は違うと言います。この場合、安全が理論であり、安心は感情です。人間は情理が備わっています。理論と感情はジレンマの如く絡みます。シンプルな問題でも解決を難しくすることがあります。
原発事故から話が変わりますが、情報セキュリティでは、インシデントという言葉をよく使います。
情報セキュリティのインシデントは、組織の管理するシステムにおいて、機密性、完全性、可用性に代表される情報セキュリティの原則（この３つをとって情報セキュリティのCIAといいます）が侵害される出来事を指します。
たとえば、悪意を持ったハッカーにより脆弱性のある情報システムに侵入され、機密データへの不正アクセスがされ、機密情報が外部に漏えいする事故です。
もしインシデントが発生した際は、対応フロー（下図）にのっとって行うことが大切です。この対応フローは組織により適宜策定されますが、「初期対応」➡️「暫定対応」➡️「恒久対応」の順序を抑えることが大切とされます。
しかし、情報セキュリティインシデントに於いて、いちばん難しいのは、インシデント対応フローにのっとることではありません。
難しいのは、組織が情報セキュリティの事故を事故として認めることだと思います。
もし、組織が管理している情報が外部に漏れている事実を社員の誰かが確認したら、その人は上司や情報システム部門に報告すると思います。これを「情報セキュリティ事象」と呼びます。「情報セキュリティ事象」は「情報セキュリティインシデント」の疑いがありながらも、まだインシデントと認めているわけではありません。
もし、組織が情報セキュリティインシデントを認めたら、組織内部で完結して対応することは困難です。政府や企業から独立した中立的な立場で、情報セキュリティに関する助言を行っている「JPCERT/CC（JPCERTコーディネーションセンター）」に報告し、支援を仰ぐ必要があります。また、個人情報の漏えいであれば、個人情報保護委員会に報告する必要があるでしょう。組織の内部不正であれば警察への相談が必要です。また、企業が ISMS（ISO27001など） を取得していたなら、審査機関に対しても報告が必要になるでしょう。
情報セキュリティに関わる関係各所に迅速に報告することで、適切な対策を行うことにつながります。
インシデントを報告することで、被害の拡大を防ぐことが期待できます。
ですので、理屈としては、組織は情報セキュリティインシデントを認め、一刻も早く公表することが最善の行動だと思います。
しかし、経営者はもう一方の頭で、セキュリティ事故を公にすることを嫌がります。事故が公になることで、顧客が離れたり、組織の運営に混乱が生じたり、事業を監督する立場としての責任の取り方を心配するからです。
そういうマイナスの感情が、組織として社員が報告した「情報セキュリティ事象」を「情報セキュリティインシデント」としての認定を遅らせる要因になります。
ですので、公表される情報セキュリティの事故は、発生してからすでに時が経過したものが多いのが現実です。
もう、被害はとんでもなく拡大しています。
原子力発電所の稼働にしても、情報システムの稼働にしても、多くのリスクが取り巻いてます。
リスクが顕在化したとき、人間のあたまにある「情」と「理」をうまく制御するのは、とても難しい命題なんだなと思いました。
