「（３）イ 脆弱性情報等に関する情報のエスカレーションプロセスの策定」の後にも考えるべきことが2つあった。 それは、「深刻な脆弱性を保有するシステムに対する『システム停止を含む緊急対応』の事前策定と関係者間の合意」と「策定したプロセスが機能す…

脆弱性は、「早期発見＆即対処」を行えればベストだが、これはシステムの規模や影響を考えるとかなりの無理筋とも感じる。 となると、脆弱性マネジメントの見地では「早期発見」「適切な評価」「迅速な対処」をいかにスムーズに行うか？がカギになる。早期発…

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

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

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

現場に寄り添うべき立場の者として、この課題（の記述）は少し腹立たしい。 報告書中、以下のような記述がある。 本件事故の原因とも言える「大規模の脆弱性発覚」のリスクは、本来、看過できない重大なリスクであったと考えられるものであるが、経営管理の…

新規開発でStrutsを使わない宣言を出したのは評価出来るけど、既存システムへの対応がない（ように見える）のが不可解。 報告書では「既存のStruts 2使用システムの再構築には至らなかった」とあるが、これは正直「システム運用の現場」を理解していない（理…

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

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

3/10 2:15にインシデントが発覚し、公表が同日18:22に行われている。 関係各所の調整も含めて16時間で公表というのは、個人的な所感では超高速だと感じる。

専門家アドバイザーが少し偏り気味でないかい？と思ってたり。 実は結論が少々偏ってたりするなぁ（間違ってるわけではないけど、方向性が偏ってるという意味）…と思っていたのだけど、再発防止委員会の構成を見て納得。

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