「ISMS」を含む日記 RSS

はてなキーワード: ISMSとは

2019-09-15

障害パーティーに参加してきた

10人くらいでやる障害パーティーに行ってきた

場所あんまりいうとバレるから関東近郊のDCを借りて、酒と食べ物買って飲み食いしながら夜はめちゃくちゃに障害復旧するっていう催し。

ういういわゆる障パを主催している幹事に誘われて初めて参加した。

インシデントバーインシデントばっかり発生する)とか少しだけ行ったことあって、技術好奇心があったから参加した。

時間夕方〜泊まり

参加している男らは意外と普通人達で、ちょっとホッとした。

リビング適当に酒飲んだりご飯食べてたら、いきなりKubernetesオンプレに展開したいとか唐突に言い出して、障害パーティースタートした。

適当に近くの運用担当ペアになってどんどん運用部屋(ISMS規定されている)に吸い込まれていく。

1回1時間弱くらいで手順を確認して、コンソールからコマンド打って、復旧確認して休憩して、また近くのダブルチェック担当障害復旧しに行く。

部屋中に溢れる指さし確認の声がうるさくて眠たくならない。

人の運用体制を笑ったことはなかったけど

他人コマンド実行の仕方って千差万別なんですね。

これまで、無理に安全側に倒す方ではなかったけど、転職イベントとかで口説かれたりして転職するかしないかという駆け引きコミュニケーションばかりしていた。

この回転寿司のように障害復旧を繰り返す姿はスポーツのような動物園に来たような気がした。

正直、全然酒に酔えなくて全く楽しめなかった。全然技術的達成感を感じなかった

幹事には楽しかたからまた誘ってとか社交辞令を言ったけど、多分もう障害パーティーはいかないだろうな。

ISUCONみたいな絡みが好きみたいな感じで、ああい作業だけしてる場はある意味人間動物的な本質なのかもしれないが理解できなかった。

社会勉強になったよ。

朝、参加者見てみたらやっぱり陰キャの集まりみたいだった。

金払ってまで障害復旧はしたくはねーな。

https://anond.hatelabo.jp/20190914193945

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2019-07-04

7payだけど

最初は腹抱えて笑ってたけど、ふと周りを見たら笑えなくなった。

多分、分かってる技術者もいっぱい居たと思うんだけど、複数企業とか絡んでて仕様変更出来なかったんじゃないかと思う。

上司、自部門、自社トップ、他社、セブンシステム子会社セブン本体・・・俺だったら絶対何もしない。中途半端対策案とか出してこのカオスに何回も相手に合わせた説明資料作ってとかできない。

これで間に合わなかったら分かってて対策案出さなかったとかで責められるのが目に見えてるからだ。

セキュリティって簡単に見つかったりするくせに直そうとするととんでもなく苦労する。仕様変更からリグレッションテストとか発生する。その工数誰が出すんだ。保守費でよろしく。いや、想定外に高くなります。そんなの仕様が書いたおたくが悪いんでしょ・・・

日本じゃ金出した奴が偉いんだ。お客様は神様ですフランチャイズだけは金を取ってる方が偉いけどな。

はっきり言うと、ちゃんとしたベンダーじゃない限りIDを使ったサービスなんて自前でしない方が良い。個人情報を扱うならなおさらだ

どうしろと?firebase使えよ。

関係ないけどセブンってPマークとかISMSとかとってんだっけ?

2019-04-20

anond:20190420072401

思ったよりも反響があって驚いています

コメント読んで、単価、フリーソフト中抜きピンハネについてのみ言及ときます

単価が安すぎるのではないか

経験入社したというのと、客先は3つ経験したのですが、これは2つ目の客先の単価だからです。

だいたい入社してから5ヶ月経った時の単価で、ある程度の予想が含まれます

この時は仲介業者(大手SIer)の営業さんに「安ければ安いほどいいので業務経験がなくても大丈夫です」などと言われて入った客先なので、安く買い叩かれてて当然だと思います

あと転職前の会社営業が弱かったので、それもあります

フリーソフトダウンロードし放題って大丈夫

それは私が一番思っています大丈夫なの?

ときちんと現職の担当者には不安であることを伝えています

たぶんISMS規約かにフリーソフトは個々でダウンロードせず、一括でダウンロードしたインストーラーをプロジェクト参加者で共有すべきである」とか追加されると、変わるのではないか、と思います

結構ショッキングだったので、感想として書いてしまいました。

中抜きピンハネについて

利益の2/3ほどを会社運営費にしないと会社がうまく回らないというのは知っています

そのため単価60〜70万が20ほどに減るのは一般論的には変なことではないのも知っています

単価が目に見えるのがかなりの悪であることと、普通派遣会社を経由した時給でのお仕事であれば同じような仕事をしているのに2/3も削られないため、ピンハネされていると考えてしまうのだと思います

2018-12-20

人類ZIPパスワードを直後のメールで送る理由

IPAが公開している電子メール利用時の危険対策のしおりの影響

https://www.ipa.go.jp/security/antivirus/documents/07_mail.pdf

電子メール安全に送受信するために、メールの本文や添付ファイル暗号化することができます。‘

普通会社は安く手軽なセキュリティを好む、暗号化簡単問題暗号の解除だ

そこでこんなサービスが登場する「パスワードは別メール送信元に自動で同時送信」と言うものだググれば腐るほど出てくる

システムさえ入れればお手軽なセキュリティしてますアピールが出来て漏洩したとしても言い訳がしやす

コストも安いとなると多くの企業が飛びついたのだろう、次!


PマークISMSを取得するために必要から

JIS改正に伴うプライバシーマーク審査基準改正について

https://www.jisa.or.jp/service/privacy/tabid/831/Default.aspx?itemid=31

‘【第23条】個人情報を含む添付ファイルを取扱う際に、セキュリティ対策データ暗号化パスワード設定など)の措置を講じることを新たに追加した。‘

ISMS認証にも似たような審査基準記載されている、気になるなら自分文章探すんだな

お客様に「うちはセキュリティ対策に社全体で取り組んでいますアピール安心感を持たせるためには必要PマークISMS認証のためなんや

労働者無駄とか不便とかどうでもいいんや、そんなのに答えたらPマーク認証外されちゃうから

上記の再送システムも付ければ最高のセキュリティ対策になるとお上の方々は思ってるんやで


21世紀人類ZIPパスワードを直後のメールで送るのは、なぜデスか?」ってタイトル@IT記事大元itmediaPマークを持っているわけだが

どうやって客や取引先にファイルを送っているのか教えて欲しい、パスワード付きzipを叩くぐらいだ画期的セキュリティ対策をしているのだろう

https://corp.itmedia.co.jp/corp/privacy/

2018-09-14

日本IT企業生産性低い理由分かったわ

PマークとかISMSとかISOなんちゃらとか今すぐやめろ。

それが結論

2018-02-23

セキュリティ資格なんていらねぇよ

PマークISMSも、会社社員の足かせでしかなく、

あん資格の教本通り運用したって

流出なんて防げないし、なんの役にも立たない。

あれをとることで会社社会的信用があがる??

あがらないだろあんなの。

セキュリティ意識たかまる?

まらないよ、あんなので。

開発用のソフトインストールするのにも申請申請って

本当に馬鹿かと。いい加減にしろよ。

天下り先のためにつくった化石のような資格にしがみついたって、

どうにもなんねーんだよ。

2016-02-20

IPAセキュリティスペシャリスト資格持ってるけれど手取り20万円のままなんですが

ISMS資格でもとれば収入あがるのかな

2014-11-09

http://anond.hatelabo.jp/20141109190907

すこし物事が崩れただけで色々出来なくなっちゃうの、頭良いというよりお勉強はよく出来るタイプなんだろうな。

過去のしがらみを元にしか仕事できないのであれば、それがない仕事任せればいいんじゃない

ISMS 導入したい会社だったら ISMS資格勉強させて、資料をまとめさせるだけ(それを対応するかは他に任せる)とか、

開発なら新しい技術導入部分だけ勉強させて、資料にまとめさせるだけとか。

足かせになるぐらいなら、他と折衝するような仕事任せられないっていうこと言ってしまえばいいんじゃね

2012-04-12

http://anond.hatelabo.jp/20120412003907

日本に名だたる大企業のA社もB社もみんなIE6使ってるぜ。

ISMS認証を受け、PC管理ソフトソフトウェアを一元管理しているにも関わらずな。

マジ情シスって糞だね。仕事しろや。

2011-05-15

http://anond.hatelabo.jp/20110515032934

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

あまりに貧弱なPlanだったら認定が下りないし、少なくとも派遣社員勝手運用中の本番サーバ落とす事態にはならないと思うが。

http://anond.hatelabo.jp/20110515025034

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

馬鹿

PDCAのサイクルで、セキュリティ強度はPlan次第。

http://anond.hatelabo.jp/20110514170542

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ことだろう。

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

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

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

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

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

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

(3)状況を確認する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

備えあれば憂いなし。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん