内閣サイバーセキュリティセンターで情報漏えい　未知の脆弱性が原因

オクレ

でつくってるからな

おそらくだけど、メールサーバが受け取る前に
eメールセキュリティ関連のアプライアンス製品
をかましてて、それがゼロデイ攻撃の対象になっ
てた懸念が高いて話なのでしょ。

それだから、漏れたメアド(NISC内部分)に関連した追加の攻撃の可能性を排除するために、一旦
バックエンド側のシステムを再起動したとか
だと思うけどね。(ログの確認をして、不正アクセスの証跡の有無を見て、不審な更新個所やら
見つかればバックアップやらから元の構成に
戻して再起動かけるとか)

大企業や官公庁研究機関やらでメールが殺到
する様なトコだと、スパムや添付ファイルによる
攻撃やら排除する為に、本番のメールサーバの
前段にセキュリティアプライアンス噛ませるて
のは割とあるからね？

コレなら、バックエンド側は再稼働かけて、同時並行で当該機器の対策済み製品への交換とか
で一応の対応は済んでるて話だろうしね。

NISCの側も恐らくは、漏れたメアドの中に含ま
れる後援や協力企業の担当者が含まれるなら、
個別に周知して対策のあり方とか模索してるの
では？(具体的にNISC側が現時点で法的責務を
負うワケじゃないだろうけどね)

出ていないのであれば、NISCが今公表する意味がわからん
意味のない公表をするのはよくない

JPCERTやらが対応できるのは、そう言う
事前にある程度予見し得る脆弱性なんでしょ
うし。

じゃあ、オープンソースベースのアプライアンス
やらで十分やん！とは世の中ならないワケ
だしね？(規格やそれベースに定まるシステム構成のある意味で、際(きわ)の部分を実装して
付加価値を売りにするて製品群なのでしょうし)

現実問題として、オープンなインターネットに
晒された環境でシステムを運用する限り、
攻撃を受ける前提で運用可能性を担保するしか
ないワケで。(この部分のシステム担当者やら
の苦悩を埋める製品として、こうしたアプライ
アンスはあるのだろうから)

起こるべくして起こったとは言わんけど、
どこまで避けられるかを最大限追求すると
しか開発元のベンダーやらも言えない(コミット
しようもない)のでは？

まぁ、ある種のアプライアンス固有の障害事案
だったて前提で書いてるけどね。

個人ユーザが想像するより、企業法人向けの
システムてのは複雑で、按分すべき課題だらけ
の中で何を制約条件として運用するかて
判断に迫られてるのでは？

その一つの事例として、たまたま攻撃事案を
招いてしまったて話な気がするけど？

ベンダー固有のコードだとコレが無いから、
最悪ゼロデイ攻撃は避けられない。

とだけ？