wakatonoの戯れメモ このページをアンテナに追加 RSSフィード

たわいもないこと(日々の妄想とも言う)をつらつらと書いてます。断じて壊れメモではありません。ましてや「穢れメモ」でも爛れメモでもありません(涙)。
が、時により一つのことを掘り下げる傾向が見られるので、article数は少ないカモ。
ちなみにSlashdot Japanの日記もあります。個人的な連絡がある方はwakatono@todo.gr.jpまで("@"は2バイト文字になってるんで、てけとうに書き直してください)。GnuPG公開鍵はこちら

他のあたり:PFSEC - Systems Platform and Securityアマゾンのレビュー

強いWindowsの基本 WebDAVシステム構築ガイド(萌えバナーその1)
WebDAVシステム構築ガイドの方のバナーの絵柄は、内容とは何の関係もありません(汗)
アクセス探偵IHARA

おとなり日記はこちら

2017-07-17 セキュリティ以外のことも書くのですよw

[]GPD Pocketが届きました。 GPD Pocketが届きました。を含むブックマーク GPD Pocketが届きました。のブックマークコメント

実は、Indiegogo経由して、GPD Pocketに出資しており、つい先日到着したばかりです。

この数日使ってみて感じたことは以下のような風。

[]GPD Pocketを使ってみての所感(総評) GPD Pocketを使ってみての所感(総評)を含むブックマーク GPD Pocketを使ってみての所感(総評)のブックマークコメント

GPD Pocketを数日使って出した結論は以下のとおり。

  • 少し手のかかるじゃじゃ馬マシン

まったく手を入れずに吊るしのまま使うのはなかなか厳しいです。が、「小さい」ことはやっぱり大きな価値なわけで、手のかかる部分も楽しんで使える人だったらよいものではないかな、と思いました。普通のPCでもかかる手間はしょうがないんですが、キーボードまわりは普通のPC以上の手間がかかります(いや、マジで)。

[]GPD Pocketを使ってみての所感(サイズ編) GPD Pocketを使ってみての所感(サイズ編)を含むブックマーク GPD Pocketを使ってみての所感(サイズ編)のブックマークコメント

わりかしありがちな所感だとは思うけど、以下のような感じで。

  • 7インチUMPCということで、本当に小さい。ユニクロのビンテージチノの後ろポケットには入る(入れないけど)
  • ACアダプタインタフェースUSB-C、ケーブルもUSB-C - USB-Cということで、USBで完結させることが可能だけど、サイズはそんなに小さいとは思わない。PD 2.0に対応しているので、ANKERのPD 3.0に対応しているUSB電源とかをかわりに調達して使うのがいいのかも。

[]GPD Pocketを使ってみての所感(操作性編) GPD Pocketを使ってみての所感(操作性編)を含むブックマーク GPD Pocketを使ってみての所感(操作性編)のブックマークコメント

まとめると、画面はまだしもキーボードは長時間作業にはつらい風。なので、長時間これで作業することを想定するならば(特に作文やプログラミング)、外付けキーボードは必要と判断してたりします(あくまで個人の感想ですw)。

  • 本体だけだと、インタラクションや作文、プログラミングをはじめとして、長時間の作業には(まったく)向かない。キーボード等は外付けするなど工夫の余地ありだけど、本体だけでも作業が可能なのは、(最終手段的には)アリ
  • スペースが限られる飛行機の中や電車の中(含む新幹線の中)では、それなりに快適に作業可能。とはいえ、キーボードがウルトラ小ぶりなので、作業効率はたぶん落ちる
  • ディスプレイは、7インチでFHDならば、たぶんギリギリ使い物になるレベル。拡大率は150%でちょうどいい感じ。100%はちょっと使うには厳しい(個人の感想)。125%はありかもしれないけど、150%のほうがいいかな(これも個人の感想)。オレ自身は別メーカのGOLE1も持ってるけど、こちらは5インチ。GOLE1は本体だけだとインタフェースがタッチしかないので、指がでかいオレとかはもう苦行にしかならなかったw。ということで、ほとんどネタデバイス扱いにしかならなかったw。

[]GPD Pocketを使ってみての所感(電源まわり編) GPD Pocketを使ってみての所感(電源まわり編)を含むブックマーク GPD Pocketを使ってみての所感(電源まわり編)のブックマークコメント

まとめると、「ハイバネーション設定必須」だけど、個人の責任でよろしくという感じで。

ハイバネーションを有効にすると、問答無用でストレージ上の8GBの領域を食うので、これを惜しいと思う人は有効にしないほうがいい(けど、スリープでバッテリごんごん減るよw)。

  • スリープ時の消費電力が半端なくでかい(閉じた状態で半日放っておいて触ったら「熱い」って意味わからねえw)。ハイバネーション必須
  • まだ試してないけど、先人によると、モバイルバッテリ経由での給電もできそうな風

[]GPD Pocketを使ってみての所感(お値段編) GPD Pocketを使ってみての所感(お値段編)を含むブックマーク GPD Pocketを使ってみての所感(お値段編)のブックマークコメント

オレの場合は、約400ドル程度の出資でGPD Pocketを入手できたわけですが、出せるのはいくらまでか?と言われると、この使い勝手ならば、たぶん6万円が限度だと思います(500ドルはまぁアリ。600ドルとか言われると、"No, thank you"となりそう)。

[]GPD Pocketを使ってみての所感(その他編) GPD Pocketを使ってみての所感(その他編)を含むブックマーク GPD Pocketを使ってみての所感(その他編)のブックマークコメント

わりとどうでもいいようなよくないような点をまとめてみた。

  • 性能は意外に悪くない。WinSATの結果は、メインで使ってるマシンの1台であるThinkPad Helix(1st Gen、Core i5 3rd Gen)よりちょっと悪いくらい(気が向いたら結果載せます)
  • 筐体の加工精度はものすごく高い。閉めたらぴったり閉まる。すげえ気持ちいい。物欲満たされた感になる(個人的には重要)
  • 内蔵オーディオ(というかスピーカー)はモノラルだけど、別に気にならない(というか気にする気もない)
  • Webカメラは内蔵してないけど、別に不便でもなんでもないのでOK。どうしても必要ならば、これこそUSBカメラつければOKな世界
  • USB-CのHUB兼カードリーダーがついたモデルが届いたけど、正直いらなかったかなと感じてる。給電して充電可能なHUBを調達するほうがよっぽどいいかなと思った

2017-05-04 GMO-PGさんに対する不正アクセスの調査報告書を読んで…

2ヶ月前にGMO-PGさんが受けた不正アクセス調査報告書が出てたので、読んでみた。

…所感だけ。

[]再発防止委員会の構成 再発防止委員会の構成を含むブックマーク 再発防止委員会の構成のブックマークコメント

専門家アドバイザーが少し偏り気味でないかい?と思ってたり。

実は結論が少々偏ってたりするなぁ(間違ってるわけではないけど、方向性が偏ってるという意味)…と思っていたのだけど、再発防止委員会の構成を見て納得。

[]インシデント発覚から公表までの期間の短さはGood インシデント発覚から公表までの期間の短さはGoodを含むブックマーク インシデント発覚から公表までの期間の短さはGoodのブックマークコメント

3/10 2:15にインシデントが発覚し、公表が同日18:22に行われている。

関係各所の調整も含めて16時間で公表というのは、個人的な所感では超高速だと感じる。

[]ヤバい事象の認識から対応に移るまでの時間の短さはGood ヤバい事象の認識から対応に移るまでの時間の短さはGoodを含むブックマーク ヤバい事象の認識から対応に移るまでの時間の短さはGoodのブックマークコメント

3/9 18:00にヤバさを認識し、同日21:56にWAFによるブロックを開始したのはGood。

[]ヤバさを認識するまでが遅いのがBad ヤバさを認識するまでが遅いのがBadを含むブックマーク ヤバさを認識するまでが遅いのがBadのブックマークコメント

ヤバさを知覚してから対応に入るまでの速度が高速なのはいいのだけど、脆弱性が公開された時刻からGMO-PG側で脆弱性情報を確認し、ヤバさを知覚するまでの時刻に開きがありすぎというのがヤバい。

簡単に脆弱性公開からGMO-PGさん対応までの話を図に起こしてみた。図の上部がGMO-PGさんの対応、図の下部が(攻撃者も含めた)外部の動き。絵心なくてすんません…。

f:id:wakatono:20170509000300p:image

[]よくわからない点:脱Struts宣言を出したものの、リスク含みの既存システムへの対応が不十分なあたり よくわからない点:脱Struts宣言を出したものの、リスク含みの既存システムへの対応が不十分なあたりを含むブックマーク よくわからない点:脱Struts宣言を出したものの、リスク含みの既存システムへの対応が不十分なあたりのブックマークコメント

新規開発でStrutsを使わない宣言を出したのは評価出来るけど、既存システムへの対応がない(ように見える)のが不可解。

報告書では「既存のStruts 2使用システムの再構築には至らなかった」とあるが、これは正直「システム運用の現場」を理解していない(理解していたとしても、現場の努力に報いない)文言とも取れる。Struts 2で構築されたシステムを別フレームワークを使って再構築ってのは、ほぼゼロからシステム構築するのに等しい。再構築に至らないまでも、「既存システムの監視強化」なり「保有リスクと認識し、セキュリティ強化」となるのが(個人的には)正しいと考えてたり。

[]「全社的リスク管理の課題」は本当に真の課題か? 「全社的リスク管理の課題」は本当に真の課題か?を含むブックマーク 「全社的リスク管理の課題」は本当に真の課題か?のブックマークコメント

現場に寄り添うべき立場の者として、この課題(の記述)は少し腹立たしい。

報告書中、以下のような記述がある。

本件事故の原因とも言える「大規模の脆弱性発覚」のリスクは、本来、看過できない重大なリスクであったと考えられるものであるが、経営管理の上流での検討が十分になされないまま、現場サイドの判断によって重大リスクから漏れてしまっていた。

これは少し、現場サイドに責任を押し付けているようにも読める。

現場サイドはこれまで脆弱性対応を(現場で)大変な目にあいながらも致命的な事故が発生する前に迅速に行なえてきたのではないか、と感じる。そして、そういった現場の話とは別に、外部での攻撃発生や被害発生について、経営管理上のリスクを検討するインプットになっていなかったのではないか、とも感じる。

[]再発防止策が偏ってるなぁ…と感じるのはオレだけか? 再発防止策が偏ってるなぁ…と感じるのはオレだけか?を含むブックマーク 再発防止策が偏ってるなぁ…と感じるのはオレだけか?のブックマークコメント

再発防止はどれも「まぁそうだね」と思えるものが並んでるけど、「2 情報セキュリティマネジメントに関する防止策」中、「(3)ア 脆弱性情報の早期入手」と「(3)イ 脆弱性情報等に関する情報のエスカレーションプロセスの策定」だけでいいのか?というように感じる。

[]再発防止には「入手した脆弱性情報の適切な評価」をプロセスに含めることも対策に含めるべきではないか 再発防止には「入手した脆弱性情報の適切な評価」をプロセスに含めることも対策に含めるべきではないかを含むブックマーク 再発防止には「入手した脆弱性情報の適切な評価」をプロセスに含めることも対策に含めるべきではないかのブックマークコメント

脆弱性情報は、早期に入手すればするほど「危険性の評価」が難しくなる傾向にある。これは、公開情報などを契機に「早期に」入手できた情報には「PoCなどが伴わない」ことが多いからだ。この場合、おおざっぱには当該情報をもとに「対処する」「PoCなどの公開がされないか経過観察する」「対処しない」という三択になる。

[]再発防止は「再発防止策が機能したら、発生したインシデントは発生しなかったか」がカギ 再発防止は「再発防止策が機能したら、発生したインシデントは発生しなかったか」がカギを含むブックマーク 再発防止は「再発防止策が機能したら、発生したインシデントは発生しなかったか」がカギのブックマークコメント

これは私見だが、再発防止策を考えるときには、考えた策を適用することで「発生したインシデントが発生しなかったか」の検証が必須と考える。

そして、「今やってること」「今やってないこと」「やるべきこと」「今やるべきこと」「今後やるべきこと」の層別が必要になってくる。

[]結び:現場の営みをうまく拾ってエスカレーションを行えるしくみの構築と運用が必要 結び:現場の営みをうまく拾ってエスカレーションを行えるしくみの構築と運用が必要を含むブックマーク 結び:現場の営みをうまく拾ってエスカレーションを行えるしくみの構築と運用が必要のブックマークコメント

脆弱性は、「早期発見&即対処」を行えればベストだが、これはシステムの規模や影響を考えるとかなりの無理筋とも感じる。

となると、脆弱性マネジメントの見地では「早期発見」「適切な評価」「迅速な対処」をいかにスムーズに行うか?がカギになる。

早期発見は「ある程度」現場でカバーできるかもしれないが、きちんとした営みとするためには全体で行うのがベストだし、適切な評価は集中的に識者陣で行うのが必要と考えている。迅速な対応は、局所的な対応だけではなく組織や企業が保有するシステム全体に対して行うとなると、やはり何らかのしくみが必要になってくる。

[]追記:マネジメント側で出来る最大の対処 追記:マネジメント側で出来る最大の対処を含むブックマーク 追記:マネジメント側で出来る最大の対処のブックマークコメント

「(3)イ 脆弱性情報等に関する情報のエスカレーションプロセスの策定」の後にも考えるべきことが2つあった。

それは、「深刻な脆弱性保有するシステムに対する『システム停止を含む緊急対応』の事前策定と関係者間の合意」と「策定したプロセスが機能することの確認」。

脆弱性」が発見され、「即インシデントに発展する危険性の高い脆弱性である」ことがわかった場合に、システムに対する措置を遅滞なく行うことが必要なわけだが、この話を「都度協議の上で行う」とした場合、まず間違いなく「意思決定通達→対処」というプロセスを踏むことになる。

しかし、このプロセスにかかる時間すらも惜しい(何もしないで攻撃される危険性が高くなる)場合には、緊急避難的な対処を行うことになる。

このような対処を行う基準を策定し、関係者間で合意を取るのが、マネジメント側が行える(というかマネジメント側が行わなければならない)最大の対処の1つであろうと考える。

あとは、「策定したプロセスがきちんと機能するかどうか?」の確認が必要である。このために机上検証が必要であることはもちろんのこと、関係者が参加しての「訓練」が有効である。

2016-10-21 久々にセキュリティ・キャンプのこと〜「これまでの応募用紙を見る」

セキュリティ・キャンプに興味がある人に対して、「これまでの応募用紙を見てみたら?」という返事をすることが多いのですが、真意が曲がって伝わっていないか心配なので、すこし補っておくことに。

[]セキュリティ・キャンプの応募で一番困ったことの1つ セキュリティ・キャンプの応募で一番困ったことの1つを含むブックマーク セキュリティ・キャンプの応募で一番困ったことの1つのブックマークコメント

個人的には、「やる気はあります」とだけ書かれていて、こちらからの設問にほとんど答えていない応募が一番困りました。

これは、「やる気」を見るための応募用紙に単に「やる気はある」と書かれても、どこでそれを測ればいいのかわかりようがないためです。

[]セキュリティ・キャンプの応募用紙が問うこと セキュリティ・キャンプの応募用紙が問うことを含むブックマーク セキュリティ・キャンプの応募用紙が問うことのブックマークコメント

セキュリティ・キャンプの応募用紙は、「やる気や熱意、興味の見える化」をするためのものであり、全部正答すれば参加できるというものではありません。

[]オレが期待している「過去のセキュリティ・キャンプの応募用紙を見ることの効能」 オレが期待している「過去のセキュリティ・キャンプの応募用紙を見ることの効能」を含むブックマーク オレが期待している「過去のセキュリティ・キャンプの応募用紙を見ることの効能」のブックマークコメント

過去の応募用紙を見ることで、当然ですが「何を問うてきたか」を見ることはできます。

でも、それに対して自分が答えられないということは、少なくともその応募用紙と格闘して参加した人と比べると、前提知識ややる気、熱意(興味といってもいいかもしれないです)の面で劣る部分がある、ということに等しいです。

セキュリティに限りませんが、何らかの強烈な興味を抱いている人は、その後爆発的な成長を遂げる可能性が高まります。

単なる興味が強烈な興味にクラスチェンジするトリガは、オレにもよくわかりませんが、育成なり発掘なりする際には、何らかの分野に目を向けて取り組んでもらうことが大事というのはなんとなくわかっています。

ある人が応募用紙を見て「自分にとって未知の領域がある」&「これに興味をもって取り組んだ人がいる」事実と「その興味を講師陣に認めてもらえた人がいる」という事実、そして「自分にはまだ理解できるだけの力がない」というのをわかった時点で、どのようなアクションを取るか?てのは大きく2つ3つ考えられます。

  1. 無理と思ってスルーする
  2. なんとかして問題を解くようにがんばる
  3. わからないことに対する興味を抱く

多分、最初が一番多くて、次がわりとありがちなパターンですが、最後の「(自分が)わからないことに対して興味を抱く」というように行ってくれればいいのかなと考えてます。

参加するために頑張るんじゃなくって、興味を持ったことを突き詰めて調べて試してまとめて、ということをひたすらやっていたら、キャンプの参加をするに足るようになっていた、というのが、(あくまでオレの私見ではありますが)理想かなと考えてたりします。

2016-08-04 超久々にブックレビュー〜「実践CSIRT 現場で使えるセキュリティ事

この数日で買った数冊のうち一冊を早速読んでみた(でないとまた積読になりそうで)。

最初に読んだ本が、思いのほか良いと感じたので、さっそく(?)レビューしてみることに。

これはオレの主観が多分に交じってますが、あまり外してはいないと思いますw

[] 実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(1)  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(1)を含むブックマーク  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(1)のブックマークコメント

インシデント対応関連の和書は珍しく、著者に知った方々がちらほらいらしたので、ゲットの上読んでみた。

良い書籍だけど、やっぱり難点も出てくる。

[] 実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(2)〜まずは良い点  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(2)〜まずは良い点を含むブックマーク  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(2)〜まずは良い点のブックマークコメント

事故を類型化し、具体的にどうするか?が、かなりわかりやすく書いてあるのは非常に良い。

本書は「セキュリティ事故現場での対応」にフォーカスを当てたものであり、著者陣の安定感もあって、非常に安心して読める内容である。

生々しい(よもすると読み解きづらい)事故の事実そのものではなく、事故をある程度定型化した上で、どのような対処が望ましいか(もしくはどのような対応が必須か)を説いている。

具体的には、2章〜4章で、発生してしまったインシデントに応じて、「マルウエアから組織を守る対応術」「狙われ続けるWebサイトを守る対応術」「内部不正の対応術」というようにインシデント対応あるある的な対応の類型が書かれており、さらに5章「平時に進める脆弱性対策」で脆弱性対応の重要性を説いており、(すべてではないにしても)真面目に取り組めば成果が出る(そして定時に帰れるかもしれないくらいのインパクトが出るかも)という感じになる。

この書籍をもとにして、演習や訓練を実施するというのもよいと考える。

[] 実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜たぶんスコープ外だけど、期待しちゃいけない点  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜たぶんスコープ外だけど、期待しちゃいけない点を含むブックマーク  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜たぶんスコープ外だけど、期待しちゃいけない点のブックマークコメント

本書に、チームビルディングやチームマネジメント、ケイパビリティ、チーム成熟度などの話を期待してはいけない。

1章「事故対応の司令塔「CSIRT」とは」で、「何よりまずは CSIRT を立ち上げる」とあるが、正直なところ、このとおりのアクションを取れる企業/組織は、現時点では(たぶん)あまりない。もちろん、考え方などで参考になるところも多いのだが、企業ごとにチームを結成するためのハードルが違ってくるので、(あたりまえのことと言われるかもしれないが)こういうやり方もある、ということで参考にとどめるべきであろう。

で…本書は「現場対応」に力点を置いて書いているということもあるが、対応するチームをどう切り回していくか?を知りたい方々にはあまり参考にならない。

そもそも「どう対応するか」というプロセスと、プロセスで使われるツール、そして留意点が書かれている書籍なので、対応する前にどう(ゼロから)チームを組み立て、運営していくかについては(1章に部分的に書かれてはいるものの)参考にはできないと思ったほうがよい。

むしろCSIRTをどうやって立ち上げるか?などの話は、現時点で最も参考になると思われる文書類は、日本シーサート協議会がリリースしているCSIRTスタータキットJPCERT/CCがリリースしているCSIRTマテリアルなどがある。

また、CSIRTの窓口を作る際には、手前味噌であるが「世の中CSIRTという文字列が…」が多少の参考になると考える。

[] 実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜まとめ  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜まとめを含むブックマーク  実践CSIRT 現場で使えるセキュリティ事故対応を読んでみた(3)〜まとめのブックマークコメント

ネガティブなことも書いたが、どちらかというと「買ったはいいけど期待外れ」というのを防ぎたいと思ったので、オレなりに著者陣の主張を読み解いたまでのことである。

で…本書で述べている内容は掛け値なしに貴重なものであり、これまであちこちで局所的/散発的に公開されてたり、暗黙知になっていたものを、パワーをかけてまとめ、世に送り出してくれたことに拍手を贈りたい。

内容自体は(実地で対応したことある人ならばわかると思うが)非常に具体的かつ平易に書かれているので、インシデント対応を行う役割についたんだけど、それどうやるの?的な人がいたら、その人にまず読ませてみるというのがよいだろう。

そして、この書籍を参考に演習を組み立ててみるなどのことも、かなり有用だ。

いずれにしても、(読まないより読んだほうがいいけど)読んだだけではなく、その内容を(実地というよりは)訓練を通じて実施できるようにしておき、いざ本番となったらある程度動けるようにしておくと、よりよいのではないか?と考える。

2016-07-14 世の中CSIRTという文字列が…

いろんなところで見られるように。

でも、どこまでやればいいの?とか何やればいいの?という話はあちこちで…。

[] 前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっている  前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっているを含むブックマーク  前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっているのブックマークコメント

CSIRT設置するにあたって、「コンスティチュエンシー」や「サービス範囲」をはじめとすることは、すでに決まっているものとして以下の話を書いてたりします。

[]CSIRTとは、外部との情報交換のための信頼の枠組み CSIRTとは、外部との情報交換のための信頼の枠組みを含むブックマーク CSIRTとは、外部との情報交換のための信頼の枠組みのブックマークコメント

CSIRTに関して一番本質的なところをついてるものの1つが、こちらの山賀さんの講演で触れられているところと考える。

作ったから云々でもなく、外部から情報を得るのみでもなく、適切な情報も出していくという営みは必要だ。

[]外部との情報交換を行うインタフェース=CSIRTならば… 外部との情報交換を行うインタフェース=CSIRTならば…を含むブックマーク 外部との情報交換を行うインタフェース=CSIRTならば…のブックマークコメント

「情報交換を行うインタフェースがあればCSIRTを設置したといえる」のか?と言われると、これはYesともNoともいえる。

とある人wは、「最低限外向けの窓口(PoC)を設置してくれればCSIRT作ったといえるのでは」と述べているが、これは窓口対応を正しく理解していて、本当に必要な機能は何なのか?というのをわかっている人向けの説明といえる。

そこすら理解していない人が、「あ、それでいいんだ。んじゃとりあえず外部に対して窓口のメールアドレス公開するか」と安易に動くと、たいてい痛い目を見る。

[]窓口すらない場合 窓口すらない場合を含むブックマーク 窓口すらない場合のブックマークコメント

f:id:wakatono:20160714004933p:image

窓口すらない場合は、そもそも何か起こったかを外から送ってもらう統一的な枠組みを用意していないといえる(図では「Webサーバおかしい」ということを言おうとしている報告者が「どこに送るのさ?」と不安になってる様を描いている)。

昨今の状況でこれは考えづらいともいえるが、後で述べる例との対比のために、あえて出している。

[]窓口「だけ」ある場合 窓口「だけ」ある場合を含むブックマーク 窓口「だけ」ある場合のブックマークコメント

f:id:wakatono:20160714004931p:image

窓口「だけ」あるという場合は、窓口がない場合よりもひどいことになりうる。

報告者から報告を受け取った後、窓口から先どこに持って行っていいのかわからず、苦労することになる。

窓口を設置した企業なり団体なりの所帯が小さければ、まだなんとかなるかもしれない。しかし、企業規模なり団体規模なりが大きくなってくると、「整理されたエスカレーション先」なり「場合によって送る聞き先」なりを事前に把握しておかないと、確実に死ねる。

[]窓口+エスカレーション先がある場合 窓口+エスカレーション先がある場合を含むブックマーク 窓口+エスカレーション先がある場合のブックマークコメント

f:id:wakatono:20160714004929p:image

窓口を設定する意義の1つは、コミュニケーションや情報交換/コーディネーションを円滑にするところにある。

中と外のコーディネーションもそうだし、中のコーディネーションもそう。中→外の情報伝達も、外→中の情報伝達も、最終的にはPoCチームもしくはPoCチームから近いところでハンドリングされることになる。

窓口を設置するからには、「窓口がエスカレーションなりする体制を整える」ことが必須と言っているわけだ。

[]結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を! 結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を!を含むブックマーク 結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を!のブックマークコメント

窓口(PoC)が何をやるのか?というのを、自分なりの整理も兼ねて書いてみた。

兼任/専任というスタイルもさることながら、「窓口」という機能に着目して考えると、こういう見方もあるとご理解いただければ幸いである。

0000 | 00 | 01 |
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 04 | 05 | 06 | 07 | 08 |
2011 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 12 |
2012 | 01 |
2013 | 05 | 06 | 07 | 08 | 09 | 12 |
2014 | 03 | 06 | 08 |
2015 | 02 | 04 | 08 | 10 |
2016 | 02 | 03 | 04 | 07 | 08 | 10 |
2017 | 05 | 07 |
hacker emblem
ページビュー
1793636