韓国旅客船セウォル号沈没事件からの示唆

https://www.google.co.jp/search?q=%E3%82%BB%E3%82%A6%E3%82%A9%E3%83%AB%E5%8F%B7&client=firefox-a&hs=AJn&rls=org.mozilla:ja:official&hl=ja&source=lnms&tbm=isch&sa=X&ei=KNtVU8rCKILz8QXX34KQBw&ved=0CAkQ_AUoAg&biw=998&bih=658#imgdii=_

韓国旅客船セウォル号沈没事件からの示唆

事故ですが敢えて事件としました。船が沈没に行ったことも多分に人災であり、事故の避難・救済の不手際も殆どが役割責任放棄、ある意味では不正を原因とすると見られるからです。

過積載は日常的、重量検査をやらない、全く出鱈目な管理下で船舶運行が続けられていたことには驚くばかりです。それでも船は今までは役割を果たしていた。ぼろぼろの管理システムでも仕事は出来た訳だ。

ISMSへの示唆

ISMSの観点で見ると、いくつも示唆となるポイントがありますが、最も重要なものは正に「弱点の報告」に関するものです。

管理の仕組みは完璧なものはありません。どれだけ用意周到に準備していても、内部的・外部的変化を免れることはできません。

最後は現場の力。水際の対応力。ここがしっかりしていれば、多くの問題は小事で収まるはずです。

「ビジネスシーンでいつもと違う景色が見えたら要注意」。弱点の報告に関するルールを思い出すべきだ。今回の沈没事件では、弱点の報告は十分可能だった。

(1)朝の8時台の時点で、他所の船からセウォル号を見ていた人が既に変な形に傾いていることを知っていた。船同士のすれ違いで適当な交信があれば気付き情報を入手できたかもしれない。
(2) 同様に、朝の8時台の時点で、乗組員が傾いて歩き難い状況を検知している。恐らく全ての人が傾きを感じていただろうが、客は初めてだからいつもと同じなんだろうと思えば異常には気付かない。しかし乗組員はその違いを分かっていた。沈没して休出されてから漸く報告しているが襲いどころの話ではない。

最初の気付きで点検確認などしていれば、もう少しまともな避難ができただろう。ただ、この無責任な船長とクルーでは結果は同じだったかもしれない。どんな仕組みも行動も、結局はトップの能力が最後は成否をきめてしまう。

弱点の報告を受けても処理する頭がなければ、報告はされなくなる。結局、船長(社長)次第なのだ。

.*.

(認証書発行が仕事と勘違いしている馬鹿な審査機関を利用するとわが身を滅ぼすよ)

.*.

見えない攻撃ハートブリードの衝撃?緊急対策は社会的責任です!

https://www.google.co.jp/search?q=%E3%83%8F%E3%83%BC%E3%83%88%E3%83%96%E3%83%AA%E3%83%BC%E3%83%89&client=firefox-a&hs=GWJ&rls=org.mozilla:ja:official&hl=ja&source=lnms&tbm=isch&sa=X&ei=LVJVU-oCiJSSBbSKgMgM&ved=0CAgQ_AUoAQ&biw=998&bih=658#imgdii=_

被害額の見えないハートブリード

ハートブリード
Heartbreed
心臓出血

ブラウザ利用時のOpenSSLは安全なやり取りを保障する通信方式だったが、SSLサーバーの初期プロセスのハートビート処理(チャレンジレスポンス習性?)を利用したバッファ情報の抜き取りを行なうのがハートブリードの手口。個人情報や鍵情報まで抜き取られる。

ハートビート処理中にデータの送り込みをサーバーが受けると、サーバーは送り返すデータがないためにバッファー上のデータを送り返す欠陥がある。多くの企業は既に脆弱性対策を実施済みだと思われる。

問題は、果たして自分の企業あるいは顧客は被害を受けたかどうかがまるで分からないことだ。

悪意の人が十分時間を置いてから本に成りすましたりすれば、犯罪が行なわれても原因を特定しにくくなる。

今、簡単に出来る対策は、犯人がIDパスワードを使う前に、パスワードを別のもっと安全なものに変更してしまうことだ。

(1)全くニューのパスワードにすること。(過去のパスワードは使わない)
(2)サイト毎に返ること。 (同じパスワードを使わない)
(3)覚えのないID利用がないか、メール通知、SNS記事、ポイント残高、クレカ利用などをチェックする。

.*.

ISMS施策

<運用者として直ぐやること>
  1. 運用しているオープンSSL利用サーバーを至急更新する。
  2. ログデータの確保。ログの保管期間が短く設定している企業ではログ廃棄を一旦停止する。ミニマム2年間、できれば10年保管。
  3. 利用者への注意喚起。特に、不正利用の有無についての注意、及び気付いたことの報告。問い合わせメニューに追加する。
  4. 外部の被害状況に対する情報収集体制の見直し。
 <運用者として1週間~1ヶ月以内にやること>
  • オープンSSLの脆弱性の報告が最初にされてから、実際に管理しているサーバーに対策が実施されるまでに掛かった時間の妥当性レビュー。脆弱性検知と対応力を定量的定性的に評価する。
<利用者としてすぐやること>=殆ど全ての企業組織が対象
  • 真っ先にやるのはパスワード変更。⇒業務上アクセスしている先は必須。ISMS事務局はパスワード変更済みの確認フォローまで実施すること。
  • ID変更も可能なら、IDも変更する。
  • 不正アクセスの疑い事例についてのチェックと報告。
  • 不正アクセスの疑い事例についての監視要請。
<社員・従業員とビジネスパートナーへの手当て>
  • 社員のプライバシーが晒されると企業までも悪影響を受けるのはよくあることだ。あんな馬鹿な社員が勤める企業の商品は買いたくないとなる。プライベートであれ、注意喚起は当然。
  • ビジネスパートナーが脆弱では事業継続性に問題を残す。注意喚起と可能なら結果のフォローまで実施すること。
.*.

この問題は既にニュースその他で広く知られていることだ。その意味することは、出遅れたハッカーグループもハッキング技術検証のためにハートブリード攻撃を始めるということです。今まで以上に飛躍的に多くの攻撃が開始されます。

対策が遅れているサイトはひとたまりもありません。

対策が遅れていたら社会的責任は免れません。サーバーに対策が一晩で出来ないならサーバーを止めることです。対策しないで運用を続けたら、目隠しして街中を全速力で運転しているのと同じことです。 事故が起きて当然。サーバーを運用する企業側が犯罪者になります。

.*.

<必ずお読みください>

◆コメントについて

内容見直しの機会としてコメント可能としています。但し、採否・削除は勝手に行いますので予めご了解ください。

◆注意事項

当ブログは独断と偏見を排除しない私用目的のものです。不適切な内容を含む可能性がありますので注意してください。

組織・個人・商品・サービス等について固有名詞が引用されますが、関連考察は誹謗中傷を意図したものでは有りません。また内容の真否は一切確認しておりません。鵜呑みにしないでください。

記事は同じような内容が繰り返し記載されたり、矛盾することが記載されたりします。事実誤認もあります。これらの修正は必ずしも行うものではありません。

◆禁止事項

ブログ訪問者は直接閲覧すること以外の行為は遠慮してください。ブログ内容の一部または全部に関わらず、印刷、コピー、ダウンロード、保管、編集、利用、及び他の人への紹介・情報提供等を禁じます。

2004/04/01

人気の投稿:月間

人気の投稿:年間

人気の投稿