2011-05-15

http://anond.hatelabo.jp/20110514170542

システム管理から言わせてもらうと、これだけの情報ではシステム停止対応した是非は判定できないが、

おそらくは、事前通知なしのシステム緊急停止は行きすぎた対応はないかと思う。

それに、この派遣社員は、テスターとしては合格だが、技術者としては微妙ビジネスマンとしてはアウトだ。

このケースは、「SQLインジェクション」といって、攻撃により情報漏えいが起きる可能性であり、

システムセキュリティ上の致命的な欠陥が潜在的に存在すると分かっただけで、事前通知なしの緊急停止という対応普通はしない。

逆に、具体的な攻撃が観測された場合、または通常の操作情報漏えいが発生する欠陥が見つかった場合などは、迷いなく事前通知なしの緊急停止に踏み切るべきだ。

プライベート趣味サイトであれば即停止でもよいだろうが、ビジネスで使っているシステムである以上、セキュリティだけでなく、事業継続性や説明責任や止めた場合の影響も考慮すべき。

緊急度や対応方法もいろいろなバリエーションがあるし、インシデント発生対応時のマニュアルを参照しつつ、状況を照らして迅速に判断することになる。

なお、判断するのは、あくまで正社員責任者(内容によっては経営者が)であって、派遣社員はない。

ただ会社側の体制に問題があると思う。

派遣社員暴走?も、会社側がこういう場合対応について考えるきっかけを与えることになっただろうから、それはそれで意義はあったのではないかと思う。

システムのことさっぱりわからない経営者マネジメント側の人間ができることは、

(1)派遣社員には、システム運用稼働中に本番サーバを触らせないように権限を決めておく。

(2)その代わり、システム管理者として、スキルと判断力と責任感を兼ね備えた人材(正社員)を配置しておく。

(3)インシデント発生対応時のマニュアルを整備しておく。

ことだろう。

プライバシーマークISMSを取得すれば、こういうことが体系的にできる。

私がもしこのテスター(派遣社員)から運用中のシステム脆弱性を指摘されたらどうするか考えてみた。

(そもそもこんな品質レベルシステムは導入する時に却下するだろうが。)

(1)テスターから第一報をうける。時刻を記録

 ここからインシデント対応マニュアルを参照しつつ対応する。

(2)上司に口頭で「XXシステムで、セキュリティ上の問題発生、これより対応開始します」と報告。時刻を記録

(3)状況を確認する。

 (「SQLインジェクション脆弱性存在することがわかった。

  アクセスログなどから攻撃や情報漏えい痕跡はとりあえず見当たらない。

  ただし、攻撃は比較的容易で、個人情報流出する可能性があることが分かった。)

(4)対応方法を判断する。

 緊急性、停止方法、影響、修正、暫定復旧のめどを見積もる。

 (1時間以内に顧客通知を完了した上で、システムを停止して調査するとする。)

(5)上司対応概要説明。同意を得る。

(6)顧客通知開始。時刻を記録

(7)システム停止。時刻を記録

(8)ここからは調査、復旧作業など、具体的な対応に入る。

トラブル対応は手がいるので助っ人を頼む。顧客への連絡などは、営業担当者でも手伝ってもらえるはずだ。

システム停止後は、攻撃や情報漏えいが起きたか起きなかったかの調査が先になるだろう。

もちろん致命的なバグを仕込んだ開発者は呼びつけて調査に加わらせる。

都度、時刻を記録するのは、後で顧客に提出する報告書を書くためだ。

また、システム停止前に利用者に事前通知するかどうかは重要ポイントで、

データ更新処理を行うデータベース連携システムであれば、

更新処理中にシステムを停止すると、データの内容に不整合が生じる可能性もある。

事前通知なしでシステム止めた場合責任上これが問題となってくるし、データ整合が発生したら、その分復旧も遅れだろう。これひとつとっても、やみくもにシステム停止すればよいわけでは決してない。

備えあれば憂いなし。

記事への反応 -
  • Togetter - 「巫女テスター(17歳)、システムの致命的な欠陥を発見しサーバーごとシステムをシャットダウンした一部始終」 http://togetter.com/li/135043 Togetter - 「巫女テスター(17歳)、欠陥シ...

    • システム管理者から言わせてもらうと、これだけの情報ではシステム停止対応をした是非は判定できないが、 おそらくは、事前通知なしのシステム緊急停止は行きすぎた対応ではないか...

      • プライバシーマークやISMSを取得すれば、こういうことが体系的にできる。 馬鹿? PDCAのサイクルで、セキュリティ強度はPlan次第。

        • プライバシーマークやISMSを取得すれば、こういうことが体系的にできる。っていうのは、その上の(1)~(3)の体制を整える話で、セキュリティ強度の話はしていない。 あまりに貧弱なPlan...

          • 審査するおっちゃん次第で、余裕で認可されると思うよ。

          • 少なくともPマークだけでは絶対に守れないよ。 派遣社員に運用ルールの講習さえ行えば個人情報に触らせることができるから。 ツッコミ入れてる奴はPマークの取得に関わったことが...

      • あまりに初歩的なSQLインジェクション、つまりフォームに「'; (任意のSQL文); --」と入力するだけでアウトになるようなケースは、公開するとかなり早期に機械的な絨毯爆撃を受けるので...

    • jspだとかなんだとか用語が入ってることから推察するに、要はサーブレットとかを動かなくすればいいだけの話なんだから、適当な静的ファイルだけを残しておいてWEB-INF書き換えた後に...

記事への反応(ブックマークコメント)

ログイン ユーザー登録
ようこそ ゲスト さん