新しいドラマの告知
今日はちょっとね、最近ちょっとずいてるかもしれないなと思うんですけど、
お告知させてくれー。
何でしょうか。
ちょうどタイミングいいんですけど、3月18日、たぶんこれ皆さんが聞くときの次の週だと思うんですけど、
サイバーの日じゃん。
あ、ほんまや。
なんか昔ね、我が国のガースがいらっしゃったときのおやつですよね、確かにね。
そうそうそうですね。そんな語呂合わせがありましたね。
それ忘れてたけど、3月18日の火曜日夜10時にですね、NHK総合でNHKスペシャル作られた真実、ディープフェイクの時代っていうドラマが流れるんですよ。
ドラマ?
ドラマフェーズとドキュメンタリーパートみたいなのがあったりという番組なんですけど、
これのですね、ドラマパートの方の脚本の監修というかチェックをさせていただいてまして、非常に面白いんですね。
いろんなディープフェイクによる人を騙すテクニックとかあるじゃないですか。
本当多いよね、今ね。
このドラマの世界では、コンピューター上で亡くなった人を再現するみたいな、人を癒すためのフェイクは許されるのかみたいなこととか。
そういうディープフェイクを使って人を騙して、盗んじゃうみたいな話もちらほら見えるような脚本になっていて、それをチェックしたんで。
最後のエンドロールみたいなところには、残念ながら今回私の名前は出ないので。
そうなんだ。
会社の名前か個人の名前かどっちかって言われたので、じゃあ会社の名前でって言ったんで、やってるんで。
映像は僕も見てないんですけど、脚本はすごく面白かったんで、見ていただければなと思ってちょっと告知をさせていただいたということでございます。
リスナーからのお便り
はい、楽しみですね。NHKスペシャルとか珍しいね。
そうですね。またまたスマホを落としただけなのに監修僕やってたでしょう。
その脚本家の人がこの脚本書いてて。
あ、そうなんだ。なるほど、そういう繋がりか。
そう、ちょっとチェックしてもらえませんかっていう風に製作会社の人に言ってくださったみたいで、それで製作会社経由で僕のところに連絡が来てチェックしたっていう感じなんですよね。
僕も録画してみようかなと思ってます。
見てください、皆さんよかったら。
今日は早速お便りに入っていこうかなと思ってるんですけれども。
はい、お願いします。
長めのお便りをいただきまして、ちょっと読ませていただきますね。
私は病院でシステム管理部門の責任者をしています。
昨年秋の情報処理安全確保支援士試験に2年がかりで合格したアラカンです。
看護さんファンでたまたま1月にアレを発見しアレデイに加えていただきましたという看護さんファンから富士山に連絡が来ています。
看護さんが第253回の岡山県精神科医療センターの話で構造的な問題があるのかというふうな疑問を挙げてらっしゃったので、
この人が感じる構造的な問題2つをお答えしようかと思いますというDMをいただきまして。
ありがたい。
現場の声だ。
1つ目。
1つは、例えばユーザーが調達仕様書にいくらダメだと記載しても、ベンダーは未だ管理者権限同一パスワードで構築を進めます。
これは氷山の一角で報告書に書かれている通り、あくまで自社製品の正常稼働を妨げないような独自のポリシーを適用し、
納品運用がなされていることということです。
日本を代表するような大手のベンダーも、こういったことが当たり前のように行われてしまっているのが現状です。
というのが1つ目ですね。
2つ目。
職員は単なる事務員という形で雇われていることが多く、IPAの資格を取得しても、給与面のインセンティブはもちろん、資格更新費用が出ない病院がほとんどなんです。
なので、能力のあるスキルの高い人はもっと良い職場に移ってしまう傾向があって、加えて病院の収入は国による診療報酬で決められているので、今年度の改定で診療力管理体制加算で、
オフラインバックアップやサイバー対策の事業継続計画などを対応すると加算がつくんですが、500床規模の病院でもその金額は500万円にも満たないんですって。
なので、この金額を考えるとセキュリティ人材などは雇えないのが現状です。加えて自治体病院などでは職員がローテーションするので、少なくともこの人の感覚だと思うんですが、5年以上は同じ状況が続くでしょうという、かなり長いしっかりしたお便りをいただきました。
なるほど。いろいろやりたくてもできない制約が結構あるよって話だね。この方はどういうモチベーションでその資格を取られたんだろうね。2年間も頑張ってさ。
そうですよね。やっぱりしっかり、使命感とかのある方なのかもしれないですけどね。これぐらいしっかりされるってことは。
そうなり別にインセンティブがあるわけでもないしみたいなことをおっしゃってたけどさ、えらい立派だよね。そういう方がやっぱりいるっていうのは心強いけど、なかなか現場は厳しいというご意見ですね。
そうですよね。こういう方がいるのはありがたいしすごくいいことだと思う一方で、やっぱり報われる仕組みがなかったら誰も彼もこういうふうに意識高く心折れず続けられるとは限らないので、やっぱり構造的な問題というのは非常に大きいなというふうに見てて思いましたね。
そうだね。現場任せるのはやっぱり支援がないと、ちょっとその状況を変えるにはなかなか至らないという感じがするよね。
そうですね。500万の増収だと、高が知れてますよね。たぶん人を雇うとなったら新卒すら怪しい金額でしょ、一人これやったら。そういう現状を教えていただいたということでございます。
なるほど。ありがとうございます。厳しい。ありがとうございます。
あとですね、通勤中に聞いてるという方なんですが、通勤中に聞いてるけどセキュリティの話になる前についちゃう。そして次の回を聞くの繰り返して、この人冒頭の雑談だばっかりを最新回で聞いた反応かな。
イヴァンチの脆弱性解説
雑談しか聞いてない説ある。
雑談飛ばして聞けばいいじゃん。
一応チャプター振っていただいてますからね。
この聞き方新しいなと思って。
面白い。
新しいのが出たらもう次の聞かなあかんねやっていう。
そうか。
そんな言うほど腐る話でもないと思うから、一旦全部聞くっていうのをやってほしいかな。
そうね。でもそうか。一週間、何日通勤されるかわからないけど、いつかあれば1回くらい聞けないもんかね。
そうですね。通勤中って言うたかって、僕も経験ありますけど、自分の家の玄関から自分の会社の席まで800歩っていうので働いたことがあるんで、もしかしたら電車とか乗ってはらへん可能性もありますよね。
すごい近いことあるよね。
そういう人はもう家で聞いてほしい。
そうね。
確かにね。
ちょっと雑談だけで終わっちゃうのはなんかもったいない。
雑談が面白いんだったらいいんですけど、今日みたいに告知だけで終わるとかなってしまうかもしれないので、ぜひ飛ばして本編聞くっていうのをやってもらってもいいんちゃうかなっていう。
1回ちょっと本編も聞いてほしいね。
一応ね、根岸編集長によるチャプターンもきちんと切られているんでですね。
そうですね。
それを聞いていただければなと思います。
僕がちょっと前にお勧めした小峠英二さんのなんてビラに関して、サイバーセキュリティはアートかみたいな話があって、それに対してですね、アートかどうかを答えてくださっている方がいらっしゃいました。
攻防自体も、攻撃と防御ですね、攻防自体も複雑さ巧妙さがアートと言えなくもないけど、被害者のことを考えるとちょっと言いづらい側面もある気はする。
けど、セキュリティについて誰かに伝えるという活動が表現力に関わるという点で間違いなくアートです。
もちろんセキュリティのあれもアートですねっていう。
これね、たぶんこれね、見て晴らしだと思うわこれ。
そうなんだ、なるほど。
そういう感じの言い回しなわけ?
そう、中谷さんがこういう言い方するんですよ。
こうこねくり回して結局アートですみたいな。
なるほど。結論はアートなわけね。
見てるか見始めた人ちゃうかなこれ。
もう絶妙ですもん、中谷さんぽい。
だから我々もアートです。
これもアートなんだね。
そうそう、てことはもう僕もねんぎすさんもかんごさんもアーティストってことです。
セキュリティーアーティスト名乗っていい。
あれ、新しいじゃんじゃないそれ。
それいいね、新しいね。我々これからセキュリティーアーティスト名乗ろうか。
いいですね、いいですね。
僕もセキュリティーファンタジスタって自分で言ってたんですけど。
言ってたね。
ファンタジスタ時代あった。
ちなみに自分の所属会社の社長にセキュリティーファンタジスタって肩書きに名刺してもいいですかって言ったらそれだけはあかんって言われてましたね。
意外と厳しいね。
髪の毛の色とか服装とか短版とかサンダル許してくれるのにセキュリティーファンタジスタはあかんかったです。
ファンタジスタだめか。
まあ会社のルールだからね、肩書きは。
セキュリティーアーティストはいけるんじゃないの?
たしかに。
いけそうな気がしますね。
まあいいかもね、アートですということでお詰め付きいただいちゃいました。
やったー。
最後のお便りなんですけども、
上司から勧めていただき知ったセキュリティーのアレ。
現在育休中ですがスムースに復帰。
5月予定。
できるように繰り返し聞いています。
ちなみにアレのおかげで出産前に受けた去年秋試験で支援師合格しましたということで合格おめでとうございます。
おめでとうございます。
上司からも推奨されるポッドキャスト。
すごいですね。誰かから聞いてお勧めされてるって結構聞きますよ最近。
ね、多いね。
口コミでね。
あと前回か前々回のお便りでもありましたけども、
出産前に妊娠されてる方が退協にって聞いてる方いらっしゃいましたよね。
いやー産休育休のお供にポッドキャスト。
ありがたいなと思いつつも、ただ一つ言っておきたいのは責任は取れないんでですね。
それだけはご了承いただきたいなという。
いやいやもう間違いなくいい子に育ちますよ。
ありがとうございます。
お便りを紹介した方にはセキュリティのあれのステッカー印刷コードを差し上げます。
5種類あるんで5種類揃ったら僕に揃えましたよという写真を添えてDMいただきましたらシークレットの印刷コードを差し上げますんでどしどしよろしくお願いします。
はいお待ちしてます。
はいじゃあそろそろセキュリティのお話を今日もしていこうかなと思うんですけども今日はそうですねじゃあ僕からいきましょうかね。
はいお願いします。
僕が今日紹介するのはですねあのイヴァンチのコネクトセキュアの脆弱性CVE-2025-0282という脆弱性を使ってその後感染をしてくるスポーンキメラというマルウェアのお話をしようかなと思うんですけど。
このイヴァンチコネクトセキュアの脆弱性の先ほど言ったCVE-2025-0282というふうな脆弱性は今年の1月に公開された脆弱性でこれ人にと読み方違うと思うんですけどSTRNコピー関数というものの不適切な利用があってですねそれでオーバーフローが発生して認証不要で任意のコードが実行できるというふうな脆弱性で。
やばいやつだね。
これゼロでだったんですよ。
マンディアンによると去年の12月中旬から悪用が確認されているというふうなリリースが出されていて日本のJPサートによると同じく12月の下旬には日本国内でも悪用被害を複数確認しているというふうなものが書かれてありました。
この脆弱性自体はUNC-5221、シルクタイフーンですね。旧ハフニウムかな。によって2025-0283という脆弱性とセットで利用された実績もあるというふうなレポートも上がっていると。
UNC-5221って過去にもイヴァンチの認証バイパスとコマンドインジェクションを組み合わせて攻撃するっていうのもしてたグループですね。
これを使ってその後マルウェアを設置してくる。そのマルウェアがスポーンキメラというものなんですけども、キメラって合成獣なんですが、合成獣のことキメラ、いろんなものをくっつけた生き物みたいなね。
いうふうなものなんで、中身はバラバラのスポーンシリーズが全部入っているみたいな感じのやつなんですよね。全部入りみたいなものをキメラというふうに呼んでいるんですね。
スポーンシリーズの脆弱性
スポーンなんちゃらっていうスポーンシリーズっていうのは、スポーンモール、モグラ、スポーンスネイル、カタツムリ、スポーンアント、アリ、スポーンスロースで生き物ってこの4つがあるんですけども、これも以前に観測されたものと比べると若干バージョンアップしてたりもすると。
まずスポーンモールっていうのは受信した攻撃者のトラフィックを特定のところに転送するっていうやつだったんですよね。
これもともとはこの後紹介するスポーンスネイルっていうバックドアの役割をしているやつのローカルポートに転送してたらしいんですよ、受けたものを。
でも今はプロセス間通信に切り替わっていて、ネットスタートとかの結果には出力されないようになっているというふうなバージョンアップがされているものですね。
さっき言ったバックドアになっているスポーンスネイルっていうようなものは、SSHサーバーとして動作するのはバックドア的な動きをするもの。
あとはスポーンアントはこの2つのイントラで、スポーンスロースはログ消しのやつ。
こういうツールキットみたいなものがスポーンキメラというふうに呼ばれているというようなものです。
このスポーンキメラの今言ったようなやつとかだと、普通そういうツールもあるわなという話なんですけども、こういったものに加えてちょっとこれめっちゃ嫌やなっていう機能がついてて。
これスポーンキメラを入れると、さっき言ったその脆弱性の20250282の脆弱性を仮想的に修正するという機能がついてるんですよ。
何するかというと、さっき言ったSTRnコピーが原因なんですけども、この関数自体をフックして、
これはコピーするサイズが制限されてないからオーバーフロー起きちゃうという問題なんですけど、このコピーするサイズを制限してオーバーフローしないような形にして戻すというようなことをするんですよね。
なのでこれ何のためにやっているかというと、これをすることによってこの脆弱性を使って他の自分たち以外の攻撃者が入ってこないようにするというふうなことをしているんじゃないかなと。
これ結構Botnetとかでもこういうのありますよね。
そうね。IoT系のBotnetでは割とこういうの多くて、自分が感染するとテルネットのポートを閉じちゃうとか、自分だけが占有するための機能っていうのはあるね。
そういうのがないと、たまに見るけど同じ一つのマシンに複数のマルウェアが同時に感染してるなんてこともあるんで、そうならないようにってことだろうね。
主導でやってる攻撃とかも以前だいぶ前に紹介したけど、攻撃者が入っててその後ランサムが来たっていう事案の時に一番初めに入ってきたやつがリモートデスクトップで入ってきて、
リモートデスクトップ用のファイアウォールみたいなソフトを入れてたみたいなものを以前に紹介したと思うんですけど。
なんかあったね。
そういう4ヶ月後ぐらいに攻撃が来たみたいなやつですね。ランサムが来たみたいな話を以前に紹介しましたけど、こういうのは結構行われてるんですけど、久しぶりに見たなと思って。
そうだね。あと手が混んでるよね。関数わざとフックしてコピー制限するなんてね。
そうなんですよね。パッチを当てるわけでもなく、脆弱性は残ってるんですよね。フックしてるだけなんで。ただこれ他の攻撃者が入ってこないようにするっていうようなことと同時に、これ脆弱性スキャンでも見つからないようになると思うんですよ。
なのでネットワーク的な、ネットワーク経由のチェックも回避されるので、中からとか資産管理的な部分でパッチが当たってる当たってないというふうなものをチェックをしないと、自分たちが、しかもこれゼロで使われてるからその後にスキャンしても見つからへんっていう、脆弱性の存在を認知できなくなってしまう可能性ははらんでるんじゃないかなっていうふうにちょっと思ったんですよね。
ゼロデイ攻撃の影響
そうだね。なんか外からだからこの手のASM的なとか脆弱性スキャン的なやつの限界をちょっと示す感じがするよね。
そうそうそうなんですよね。
自分はさ、管理してる自分たちはさ、パッチを当ててないとか当然わかってるわけだからあれ変だなってわかると思うけど、第三者からは見分けがつかないもんね。
そうですね。それかもそういうスキャンとかを外にお願いしてるとレポートにはたぶん載ってこないですよね。
わかんないよね。
我々よく脆弱性の対応っていうのは脆弱性がすでに悪用されていないかどうかっていうのを疑問を持って考慮しないといけないよねって話をよくしてるじゃないですか。
そうだね。最近特にね、その脆弱性の情報が出て修正するまでの間にやられちゃう的なやつとかも結構見かけるからね。
今でも見られるような事例で言うと、脆弱性を利用してあらかじめ抜いておいた認証情報がそのまま使われる、もしくは売られたりとかするっていうので、後から来るっていうパターンっていうのはまあまあ見られるじゃないですか。
もしそれで認証情報変えてないとってことだよね。
今回紹介したのはそのパターンとはちょっと違って、バックドアが設置されていて、そいつが悪さしているパターンもあるなっていうふうに、ちょっとこの辺も考慮しなあかんなっていうふうなのは思ったというふうなことと、
さっき言ったみたいに仮想的に修正しているので外から見つけられないっていうようなことで言うと、
この間我々ITメディアのパネルでASMの論点と盲点を整理するみたいなことをしましたけど、
これもまさにさっきネギさんがおっしゃったみたいに盲点になり得るから気をつけないといけないなというふうなことで紹介させていただきました。
そうだね。しかもこれ別にこのマルウェアが仮想的に見せてるだけだから、こいつらがいなくなったらまあ脆弱なままなわけだからね。
また別の恋人が来るかもしれないしね。
ますます脆弱性対応っていうのの幅広さを痛感する事例でしたね。
あとこれなんだろうね、ちょっとわかんないけどさ、ゼロデイだから大規模な攻撃ではなかったはずだけど、
どんなような観点で攻撃者側が攻撃をしたのかわかんないけど、日本も含めて被害があるっていうJPサードの報告なんかも見てもいつも以上に一言ではないというかさ。
いや、ほんまそう。
なんかそういう感じがしますね。
こういう事例があるのを知ってるか知ってへんかでやっぱり明暗化れることもあるかもしれへんなって思いましたね。
厄介だよね、こういうのは。
まあどうしようもない。ゼロデイの場合は事前に対処するのはちょっと難しいから見つけた時にきっちり調べて、さっきの話じゃないけどね、侵害前提でちゃんと対応するっていうことをやる。
もしくは、やられるかもしれない前提というところで変な通信してないかっていうのはこれまで通り見ておく、そこでなんとかキャッチアップするしかない。
以上に気づく術ですよね、それしか。
なかなかハードル高いけどね。
どこもの組織ができるわけではないかなとは思いますね。
確かに。
でも今回の例に限らずイヴァンティのコレクトツイッキはもうそうだし、珍しくなくなってきたじゃん、こういう事例がさ。
そうですね。
外部との境界に設置するいわゆるエッジのデバイス、VPN機器とかファイアウォールとか、そういうセキュリティ製品、これもセキュリティデバイスじゃない。
こういうやつが攻撃の起点になるっていうケースがちょっと目立つので、しかもゼロデイが珍しくもない。
ゼロデイの場合にはある程度標的を絞ってだと思うけど、大規模には来ないと思うけど。
ただこういった事例があった後、脆弱性の情報が公開されて、エクスプレートコードが公開されて、その後大規模に来るみたいな。
標的型攻撃が第一波だとすると、その後第二波がすごい大規模に来るみたいな事例も。
犯罪系が利用してくるとかもよくあるパターンですよね。
ランサムとかが利用してくるとか、いろいろあるから、こういう機器の運用が前よりもだいぶしんどくなってるなって感じはするよね。
だからよほどスピード感をもっと対応できる体制とかにして、最新の情報をキャッチアップするようにしておかないとちょっと厳しいよね。
そういうキャッチアップをするってことは、キャッチアップするボールを投げる人たちがいると思うんですね。
看護さんもよく言ってますけど、いろんなリリースを出してる中で、なんで製品名出せへんねんって看護さんたまに言ってはるじゃないですか。
たまにとかもめっちゃ言ってますね。
よくめっちゃ言ってますよね。多分僕、世の中の人が聞いてるのの3倍ぐらいは僕ら聞いてると思うんですけど、近いからさ。
機器名を出さないことによってやっぱりピンとこんのですよね。
なるほど。自分に関係であることなのかどうかみたいなのがわかりにくいかもね。
だってみんなエスパーじゃないですからね。
そうそう。どれぐらいの機器がどれぐらいの数やられてんのかみたいなものがやっぱりヤバいって感じる一つの指標ではあると思うんですよ。
それをVPN機器みたいな感じで、エッジデバイスみたいな感じで一括りにしてしまうとぼやけると思うんですよね、ヤバさが。
まあそうかもね。
そこはさ、もうちょっと能動的に行こうぜって思ったりもするわけですよ。
それ言いたいだけでしょ、それ。
なんだ?
ちょっと意味変わってるけど。
それ言いたいだけだよね、それ。
言いたいだけだけど、でもいやほんまに表にちゃんと出していこうぜっていうことだね。
ちょっと意味は変わってるけど、確かにその自分からそういうのをね、自ら見つけに行くとか取りに行くとか先手先手を打ちに行くっていう姿勢は必要かもね。
いいですね。思いついちゃった今。
何を?
自発的サイバー防御ってどうかな。
ちょっとなんか。
パクリか。
なんかあんまりちょっとインパクトかな。
2番戦時感半端ないもんね。
そうね、まだ能動的とかまだなんかちょっといいな。
じゃあ能動的に行こうぜって言っていこうと思います。
戻ってきた。
そんな感じです。ありがとうございます。
ありがとうございます。
じゃあ次はねぎすさん行きましょう。
はい。じゃあ私はですね、ちょっと超久しぶりにラストパスの話をしたいなと思って。
ほんと?あれラストパス辞めたんじゃなかったでしたっけ?
そうなんですよ。
あれ?ラストラストパスになってましたよね?
そうそう。このポートキャストは多分2年前ぐらいに喋ったのが多分最後で。
そんな前になりますか。
そうなんですよ。その時にいろいろ事件が起きてもさすがにちょっと私もワンパスアウトに移行しますっていう。
ちょうど年末に移行したんだよね。
あ、そうですか。
で移行しましたっていうのを確かここで報告してそれっきりだと思うんだけど。
ちょっと久しぶりにおっていうのがあったんで取り上げたいなと思うけど。
はいはいはいはい。
何かというとですね、今週アメリカの司法省が公開した、これ正式な名称わからないけど財産とかの差し押さえの例状が公開されたんだけど。
そこに書いてあった事案が面白くて。
何を差し押さえたかっていうと、複数の暗号資産の取引上で暗号資産を差し押さえた。
これ盗難されたものだったっていうことが追跡してわかったので押さえましたってことなんだけど。
トータルで2300万ドル相当だから日本円だと35億円ぐらい。
結構な金額なんだけども。
これでも全体の一部で、この盗難っていうのは何の事件かっていうと、
去年の1月、2024年の1月にある被害者の方から被害の届けがあった暗号資産の盗まれたものの一部。
これでも一部で、全体では盗まれたのは1.5億ドル相当の暗号資産。
1.5億ドル?
200何十億くらいだよね。
もう分からない。
日本円で200億円以上のとんでもない金額。
当時のレートで、当時のレートの金額の全体の今回の差し押さえ分が15%ぐらい。
だから大半はまだ戻ってきてないんだよね。
この1.5億ドルってとんでもない金額だけども、何の暗号資産かっていうと、実はリップルっていう暗号資産で。
今ちょっとリップル相当値上がりしてるんで。
僕が大好きな仮想通貨というか。
リップル大好き?
それはどうでもいいんだけど。
リップルの当時のレートで2.8億リップルぐらいが盗まれたと。
今だったらもっと高いけど、当時のレートで1.5億ドル相当ですと。
当然、司法書の資料の中には被害者の名前は書いてなくて、ヴィクティム・バントしか書いてないんだけど。
クリス・ラーセンのウォレット盗難
ちょっとあまりにも金額が大きすぎるのと。
去年の1月にリップルの共同創業者のクリス・ラーセンさんという有名な方がいて、
この人が自分が個人的に持っているリップルが全部盗まれたっていうことをTwitterで報告してて。
それがまさにこの2.86億リップルなんだよね。
完全に一致してるんで、時期も金額も一致してるから、匿名で書いてあるけど、おそらくこの人のことでしょうと。
その資料の中に、じゃあなんでこの人のウォレットから盗まれたのかっていう原因も書いてあって。
これがちょっとおって感じなんだけど、この人は自分のリップルのウォレットの秘密鍵、
暗号資産を取引するのに必要な秘密鍵ね。
これをオンラインのパスワードマネージャーに保存していましたと。
いわゆるパスワード以外もいろいろ書けるセキュアノートっていう機能があるけども。
これに鍵の情報を書いてました。他にはその鍵の情報は一切保管してなかったそうなのね。
このオンラインのパスワードマネージャーの、これももちろん匿名で名前は書いてないんだけど、
この事業者は2022年に不正アクセスを受けて、
ユーザーの暗号化されたパスワードとかの情報が一部、行為者に取られましたということを公表していますと。
FBIの調査によると、この被害を受けた人のデータを保存している自分のスマホとか端末とか、
そういうのが侵害されたとかバルウェアに関連されたという痕跡も全く見られないし、
他に原因が考えられないので、
おそらくこの2022年に侵害されたオンラインのパスワードマネージャーから盗まれたデータが
解読されて、犯人、攻撃者に解読をされて、
その中に保存されていたこのリップルと秘密鍵が使われたのではないかと思われますと。
多分犯人はこのラストバスに侵入した、ラストバスで言っちゃったけど、
オンラインパスワードマネージャーのサービスに侵入した犯人と、
今回の暗号者を盗んだ犯人は同一人物だろうということまでが書いてあるのね。
今ちょっとぽろっとついつい言っちゃったけど、
この資料には匿名で書いてないんだけど、
明らかにこの2022年に大規模な侵害をして漏洩しちゃったというパスワードマネージャーはラストバスなんだよね。
なのでこれはラストバスから盗まれたものを多分パスワードをクラックされたんでしょうねと。
2022年に2回あったんでしたっけ?
そう2回あって、最初は大したことないです的なことを言ってたのが、
実はって言って、さらに3回目の2回8月11月ってあって、それは多分Podcastでも取り上げてるんだけど、
3回目に12月の年末くらいに、実はユーザーのデータも漏れてましたってことをそこで言ったんだよね。
僕もそれでちょっと監任袋動画切れまして、
これはもうダメだと思って見限ってその年末にすぐ乗り換えたんだけど、
それがどうも原因っぽいねということが書いてあって、
実はこのラストバスが原因じゃないかっていう事例は今回が実は初めてではなくて、
僕が乗り換えたって言った2013年の初めぐらいから色んな人たちが暗号資産が盗まれたっていう事例を報告していて、
それも原因ははっきりしないんだけど共通点はみんなラストバスを使ってたっていうのは共通点なので、
おそらくラストバスから漏れたんではないかとみんな言ってたんだよね。
ラストパスの脆弱性
それを今回今この金額の大きいリップルの事例でFBIがそれを認めたっていうか、
FBIの捜査でもそれしか考えられないって言ってるので、どうもそうだろうねと。
これはでも一応暗号化を解読してみたいなことが言われてましたけど、
マスターパスワードを当てたってことなのかな?
そう、だからこの時もラストパスの話をした時に、僕にちょっと言ったかもしれないんだけども、
僕自身はマスターパスワードが非常に強いから、
仮に漏れてもパスワードを変えなければいけない必要性は感じませんと、
僕はリスクとしてはそこまで感じませんということを言ったんだけども、
多分今回のクリスラーセンさんも含めて、
2年ぐらい前から暗号試算盗まれたって言ってる事例が多発したって言ってる人たちは、
多分2つ理由があって、
1つはマスターパスワードがそもそもちょっと弱い。
パスワードが短いとかね。
実はこの事件の後、ラストパスワードはマスターパスワードの要件を厳しくして、
最低12文字以上とか難しくしたんだけど、
それまでは短いパスワードもOKだったのよ。
だからもしかしたらこのやられた人たちはパスワードが弱かった可能性があるということと、
もう1個の要因は、
ラストパスって他のワンパスワードとかも大体そんな感じだけども、
ユーザーのマスターパスワードから、
pbkdf2っていうキーデリベーションファンクションを使って暗号の鍵を生成してるんだけど、
その鍵の生成の計算の回数、イタレーションっていう繰り返しの回数だよね。
何回にするかっていうのを結構時代とともに変えてて、
それは計算能力が高くなるからだんだん数を増やさないとまずいよねっていうことで。
ラストパスも一番最初、だいぶ前に最初サービスが始まった時はこれが1回だったんだけど、
だから発症1回計算しただけで鍵を作ってたんだけど、
それじゃまずいってことで、1が100になり500になり5000になり、
この事件を起こした当時は10万回になってたんだよね、デフォルトが。
ドラゴンボールの戦闘力のことが上がってる。
本当だね、そうだね。もうスカウターじゃ測れないぐらいだけども。
測れないですね。
だけどその10万回にしたのはデフォルトでそうなってますって話で、
その時に新しくユーザーがアカウントを作れば10万回になるんだけども、
昔から過去からずっと使ってた人は自分でその設定値を変える必要があって、
既存だとそうなっちゃう。前の方が引き継がれてるってことか。
そう。僕もだからラストパスを使ってた時はどうしたかっていうと、
そのデフォルトの設定値を変えましたよってラストパスが報告を出す度に、
俺のも変えなきゃって言って自分で変えてたんだよね。
だけど面倒くさがってたとかそういうのを知らずにやってなかった人はひょっとしたら下手したら1とかさ、
弱いままだったってことか。
そう。弱いままだった可能性があって、
そうすると下手したら1と10万ではそれこそ本当に10万倍差が出るわけで、計算能力に。
それだともしかしたらやられてたかもしれないなっていう。
被害にあったらその辺も明らかにしてほしいですよね。
そうなんだよね。それはちょっとはっきりしないっていう人が、
被害者へのインタビューとかが結構ブライアン・クレブスとかが記事を返したりするんだけど、
でももしかしたら弱かった可能性があるってうちの人で言ってたりするんで、
その可能性が非常に高いんじゃないかということで。
この事件を受けてというか、ラストパス側は一応さらに回数を引き上げて、
事件後に60万回にしたらいいのかな。
今実はいろんなガイドライン、OWASPのガイドラインとかいろんなガイドラインで
だいたい60万回は最低必要だよねっていうのが今ベストプラクティスになってるんで、
ワンパスワードは65万回になってるし、だいたいこれぐらいなんだよねみんなどこも標準的に。
60万回に引き上げて、プラス、既存のユーザーを強制的にアップグレードするようにラストパスは変えて、
設定をユーザーがいじらなくても勝手に保護される。
ログオンすると勝手に変えられるっていうかね。
これはパスワードを入力したタイミングでしか変えられないからさ。
ユーザー側のパスワードをラストパス側は知らないから。
新たに入力したタイミングで鍵を生成し直さないといけないんで、
そういうタイミングに強制するっていうアップグレードするってことをやってるらしいんだけど、
おそらくこの漏洩したタイミングでは人によっては非常に設定が弱かったのではないかと思われるということで、
セキュリティの重要性
僕が長いこと愛用してたラストパスの話でもあるし、
パスワードマネージャーを使っているぐらいだから、
この人たちって多分セキュリティ的に多少普通の人よりも意識が高いっていう言い方がいいかわからないけど、
感度が高いというかね。
そういう人じゃない?ラストパスとかワンパスワードとかを使ってるってこと自体がさ。
わざわざお金払ってね。
そうそう。にもかかわらず、ちょっとそういうのを過信してたのかなっていうか、
設定の見直しをやってなかったとか、
弱いパスワード、弱いと本人たちは思ってなかったかもしれないけども、
でもこういうクラックというか攻撃のリスクがあるよっていうことをそこまで認識せずに使ってたのかもしれないなって思うと、
本当にこういう重要な情報とかを安全に守るってやっぱり難しいなと改めて思ってさ。
確かにね。
なんかでもその暗号資産のこのカギ、秘密カギって、
超要ってか、いっちゃん大事なものなわけじゃないですか。
財産を守る。
だってカギ無くしたらさ、もう使えなくなっちゃうし、
時々あるじゃん。ハードリスクで保存しようとゴミとして吸い合ったとかさ。
はいはいはい。聞きますよね、それね。
こういうのはそういうデジタルで保存するだけやったらあかんのちゃうかな。
紙の方がええと思うよな、これぐらいヤバいやつは。
実際こういうのって、ワンパスワードもそうだけど、
あれもワンパスワードも作るときにさ、
シークレットキーとパスワードを紙に書いて保存しとけって推奨されるんだよね。
言われる。
だから暗号カギも、暗号資産のカギも、
印刷してどっかに大事に保存しとくの方がもしかしたら安全かもしれないとかってやっぱり思っちゃうよね。
そっちのね、管理の仕方っていうのもあるかもしれない。
少なくともオンラインに狙われることはなくなるわけですから。
そうね、でもね、貸し銀行に入れてたら取られちゃうかもしれないけどね。
なんか怖い話です。聞いたことあんな、その怖い話。
最近、なんかあちこちでそういう話聞くよね。
結局、なんか人のバックドアがいっちゃう怖いみたいなね、話というか。
ね、怖いよね。
もちろんね、だからみんな考えた上でさ、こういう、
僕らもね、パスワードマネージャーとか扱ってるから全く一言じゃないけど、
そういうとこに保存してて、本当に安全かとか思っちゃうもんね。
大丈夫かなとか考えちゃうよね。
結構常々不安ですけどね。
いや、本当だよね。
俺もさ、口では結構ラストパス漏れても、
マスターパスワードめちゃくちゃ長いから絶対無理って思ってるけど、
本当に大丈夫かなとか思っちゃうよね。
いや、そうですよね。ちょっと疑ってる自分は常々いるかなって。
いる、いる。
でも多分そういう姿勢が大事なのかもしれないね。
うん、使うたびに結構思うもんな。
そうそうそう、疑心暗鬼。
僕あの、昔なんかのインタビューで答えたことがあるんだけど、
セキュリティの仕事に一番向いてる人はどういう人だと思いますかって言われて。
あー、コードキャストで言ってましたね。
うん、疑り深い人が一番向いてるんじゃないかって言ったことがあるんだけど、
なんちゃら病的に疑り深いのはダメかもしれないけど、
例えばそのベンダーが大丈夫ですって言ったことを疑ってみるとか。
本当に大丈夫なのか、どういう意味で大丈夫なのか、どの範囲で大丈夫なのかってね。
そうそう、疑いを持って自分で例えばそれを手元で検証してみるなり、
いろいろ調べてみるなり、
そういう姿勢がいろんな研究者とかエンジニアとか色んな職種あるけど、
セキュリティに関わる人にはそれは必須なんじゃないですかねって言った記憶があったよ。
それ今も俺思ってるんだけど、
なんかやっぱりそういうのを改めて思わされたというか、
こういうオンラインのパスワードマネージャーだったりとかで、
暗号士さんの鍵を管理してる人がどれくらいいるかわかんないけど、
用心するに越したことはないですよっていう。
そうですね、仮想通貨の秘密鍵だけじゃなくても、
ほんまにこれが漏れたらものすごいダメージやでっていうふうなものは、
入れるか入れないかっていうのを考えておくことは大事かもしれないですね。
その保存している場所がどこであれ、
それが盗まれたり危険にさらされるリスクってのはどういう方法があり得るのかとか、
それがどのくらい確率的で高いものなのかとか、
それを防ぐ方策はないのかとかね、
そういうのは常々考えておかなきゃダメなのかなっていうふうに思いましたね。
何事も過信すると足救われるなっていう。
そうだね。まさかってところからこういうのってくるからね。
そこまで行き届かへんからこそやっぱりやられるのが後立たないでしょうけど。
そうか、こういうことが起きるんだなっていうのをちょっと思いました。
身に染みてというか、気をつけようって思いましたね。
そうですね。そういったものを見直すきっかけになればね、いいかなと思います。
はい、ありがとうございます。
ラストパス愛をまだ感じられたお話になりました。
そうなんだよ。ついつい取り上げずにはいられないというか、
なんたらやっぱ愛なのかな、これは。
これは愛ですね。僕のランサムウォッチとかアノニマスウォッチと似たような感じが。
なんかニュースでラストパスっていう言葉を見るとさ、
元気にやってるかなみたいな、そういう気持ちになるんだよね。
ラストパスが元気にしてるってどういう状況?
わかる?そういう、あいつ元気にやってるかなみたいな。
昔逮捕されたアノニマスとか今何してんのかなとか思うときあるもん。
似てるかな、そういう感じ。
コマンダーX元気にしてるかなとか、元気に生きてるかなとか結構年配の方だったんでね。
懐かしいね。
そういうのがあったりしますね。
ありがとうございました。
最後は寛吾さんです。お願いします。
不正アクセスの重要性
今日は私は不正アクセスのインシデント公表について取り上げたいんですけども、
3月の4日に石倉っていう会社がですね、ランサムウェアに感染したということで調査を。
不正アクセス自体は去年の5月に発生したものではあるんですけども、
その後も調査を続けておられていて、
最終報告になるのかな、そういった形で調査がまとまったのでその結果を報告するという形で
4日に報告がされたと。
石倉っていう会社そもそもご存知ですかね。私全然知らなかったんですけども。
いや僕はこの件で初めて知りました。
ただちょっとウェブサイト見ると会社は卒業アルバムとか商業印刷とかをメインの授業としてやられている会社なんですが、
卒業アルバムめちゃめちゃ作られていて、年間に約25万人の卒業生の方に卒業アルバムをお届けされてますっていう形で。
加工数でいうと2100項って書いてあるので。
すごいいい数じゃない?
ですよね。なので多分その手の業界というか分野ではかなり。
老舗なんですね、じゃあね。
めちゃめちゃ老舗で87年って書いてあるんで。
やっぱり有名、卒あるって言ったらここみたいな感じで名前が上がる会社なんだろうなと。
我々もお世話になったかもしれないですね。
かもしれないですね。っていうところではあるんですけども、そちらの企業が運用されておられるウェブレーダーっていう名前をつけておられるシステムで、
卒業アルバムのレイアウトとかを写真とかアップロードをして、自分たちでレイアウトとかをすることができるっていうそういうサービスを提供しておられていて、
石倉自身もそういったサービスシステムを通じて、入稿って表現されてましたけども、データの重量とかをやってらっしゃるそうなんですが、
そのまさにこのウェブレーダーっていうレイアウトサービスが動いているサーバーがFSEアクセスを受けたと。
で、今回私ちょっとびっくりしたのが、ちょっとこの好評の形態がなかなか見たことないなっていうのがあってですね。
石倉社のサービスと問題点
そこか。まずね。
リリース多分ご覧になった方であればおって思うんですけども、各項目がPDFになってるっていう表現でちょっとうまく伝わるかわかんないんですけど、
PDFのリンクが貼られていてですね。リンクをクリックするとその石倉さんのボックスのストレージにつながってそのPDFがそれぞれ格納されていると。
項目すると結構あってですね、多分8個か9個ぐらいあるんですけども、それぞれにPDFファイルがURLついていてですね、見ることができるというようなそういう構成なんですが、
見ていただくとわかるんですけども、結構しっかり書かれていてですね、内容は。
実際どういう形で被害に遭われたのかとかっていうのは概要図で表現されていたりとか、
あと原因となったところについてのその点末っていうんですかね、その部分に関してもそこそこ詳しく説明はされておられていて、
どんなことが起きたっていうのが、ちょっとPDF見るのは多少大変ではあるんですけども、読むとざっくり中身っていうのが把握できるようなぐらいの情報量っていうのを公開されておられてですね、
情報通信系の専業の会社とかっていう感じでもないんですけども、情報の公開具合っていうのはしっかりやられておられるなっていう。
そうですよね、なんか被害の説明を図示するとかっていうのはまあちょこちょこありますけど、そもそもこういう仕組みでやってますも書いてましたもんね、最初の。
そうなんですよね、なかなかなので、さっきも言った通りね、この会社どんな会社なのとか、どんなサービスなのっていうところとかも、
初めて私とかも含めてではあるんですけども、読んだ人がわかるっていう形で説明されておられていてですね、
それは結構参考というか勉強になるなと。
攻撃を受けた原因というところについては、先ほども説明した通り概要は書かれていまして、
発端としてはこのサービスの保守管理ですかね、保守管理を委託しているシステムの会社が外部機器の交換を修理の業者に依頼したと。
委託っていうんですかね、そういったところがあってですね、実際にその修理をされた業者、
修理業者までは石倉さんからシステム会社に委託されて、実際そこから再委託みたいな感じになるんですかね、石倉から見ると。
修理業者の方が外部機器の交換をされたということが発端であったというところで、
交換をされた後にセキュリティの設定として行うべきところ、閉鎖設定と書かれていたんですけど、
おそらくはポートとか不要なサービスとかアクセス制御とかその辺だろうなと思うんですけども、
そういった設定というのが行われていなくて脆弱性となったと。
加えてそれ自身は侵入されたというところの初期侵入の入り口というところではあるんですけども、
情報が今回漏れた可能性というのは否定できないと。そこに関しては卒業アルバムなので、
言ってしまえば期間を絞ってデータを保持しておくだけで業務というのは遂行できるというのは、
それは言わずもがなので、実際内部ルールとしても保存期間1年としていたそうなんですが、
実際のところとしては期限を過ぎたデータというところも削除というのが徹底をされていなかったというところがあってですね、
件数でいくと74,238件の画像のデータを中心に、あとは名前とかを入れたりとかっていうケースもあるので、
情報公開と対策
名前というのが漏れている可能性というのが、残念ながら否定はできない状況と。
実際今のところ情報流出っていうのを、よくある表現の一つあるんですけども、確認はできていないと。
漏れてないっていうような言い切るっていう状況にはなっていないというところなどは書かれていてですね、
これはよくあるなとか、何ですかね、去年だとちょっと名前出しちゃってあれですけども、
伊勢島とかの治安とかでも消されているはずがみたいな話もあったりして、
被害がより深刻化したっていうケースもありはしたので、これは本当あるあるなんだなっていう感じでは読んでいて思ったところと。
あともう一点としては、タイムラインっていうんですかね、時系列などの情報も整理はされておられているんですが、
交換対応っていうのが入られたのが、5月の10日だったそうなんですね。
2020年の5月の10日に修理として危機交換を行った。
その時点で設定などが適切ではなかったので、侵入される状態になっていたというところではあったんですが、
攻撃を受けたのが5月の18日、ランサメアの攻撃を受けたということで異常検知ということは、
実際ランサメアを展開されて発火した状態っていうんですかね、そういった状況になったというところではあって、
これ期間で言うと8日間。
侵入されるっていうタイミングなどを踏まえると、もっと多分期間としては短いんじゃないかなっていうふうには思いますので、
このスピード感っていうのもやっぱり怖いなっていうのは、
さっきツイスターもおっしゃられてたITメディアのセミナーでご紹介させたあれは、
高野総合会計事務所ですかね。
あれも似たような感じのタイムスパンというか、結構短い期間で。
アクセス制御の不備が発生してから10日足らずぐらいですね。
ですよね、やっぱそれぐらいでしたよね。
それぐらいのスパンだなっていうところっていうのは、
今回結構細かくというか、概要が分かる形で情報公開をしていただいたというところもあってですね、
結構分かるというところもあり、
こういったタイムスパンで対応とか対策っていうところを考えていかないといけないなというふうには、
改めてこれを読んで思ったと。
あとちょっと見るの大変っていうのはあったんですが、
分割されてますからね。
内容自体は情報量としては、
どんなことが起きた、どういうふうなことが原因で起きたっていうところ、
あとここまで書く必要あるかなと思うんですけども、
対応対策報告っていうところについては、
具体的にどういうところに報告をして、
受理番号こんなんだったみたいなのが書かれていたりはするので、
ちょっとそこまで書くかっていうのはあるんですけども、
かなり具体的な話っていうのも書かれてはいるので、
被害組織に第三者が批判的な立場、
偉そうに情報を出せっていうのはなかなか言いづらいところではあるというのは、
これは大前提ではあるんですけども、
やっぱり上場企業であるとか、
重要インフラであるとか、
説明責任っていうですかね、
そういう充積を特に担っておられる組織とか企業においては、
別に今回の内容ってすごい技術的かっていうと、
本当にやられたことを淡々と整理されて、
それを公開されているっていうところに
収支されているかなっていう感じではあるので、
これぐらいのレベルっていうのは公開はしてほしいなっていうのは、
個人的にはやっぱりこういうのを見るとですね、
ちょっと改めて思ったというところがあってですね、
やっぱりこういうのが出てこないと、
対応対策考えようっていうふうに機運というか、
考えが向きづらいかなっていうのもあってですね、
なのでやっぱりこれぐらいの情報、
もちろんこの情報を出すために、
なんていうか今ないリソースをなんか必死こいて、
それこそ無理してやれっていう話ではないんですけども、
すでにこれぐらいの情報が集まっていて、
公開できるというか、
そういう情報が手元にあるという状況であれば、
公開できないかなっていうふうに、
考え方をちょっと柔軟に持っていただいて、
対応していただいてもいいかなっていうような形で、
ちょっと今回ご紹介をさせていただいたというところです。
なんか公開の形のこの謎の文革はともかくとして、
内容は多分誰が読んでも理解しやすい形にはなっているなとは思ったんですよね。
技術的なところをそんなこと細かに書きたくないのか、
わざと書かなかったのか分からないですけど、
読みやすいは読みやすいかなっていうふうに、
最低限のところも抑えたりとかして、
分かりやすいなとは思ったんですけど、
修理業者が外部機器を交換したときに、
この閉鎖設定がされず、
これなんか交換したから全部内容がなくなったのかな。
これを再設定したときに漏れがあったとかね、
そういうところがちょっとそこの経緯がもっと気になるというか、
bad knowみたいなものがあるかなと思うので、
この辺をちょっとなんかフォーカスしてほしかったなっていうのと、
脆弱性の原因と責任
あと閉鎖設定がされずに脆弱性が生じたっていうのが、
具体的にどういう状況なのかがちょっと分からないんですよね。
例えば仮にアクセス制御がされてたけど、
any any 許可みたいな感じになってしまって、
その先のサーバーで動いてたリモートアクセスのものが触れるようになった。
それもきちんと認証してたら通ったとしても破れないじゃないですか、
こんな簡単には。
そうですね。
経路の話としてこういう経路ができてしまいましたっていうのは、
もちろんそれも抗議には脆弱性だと思うんですけど、
もうちょっと根本的な理由ってあるはずなんじゃないかなと思ってて、
パスワードが甘かったですなのか、
脆弱性をパッチ当てずに放置しているサービスが動いてて、
それが外から見えたんですなのか、
ポートが空いただけだとちょっと気持ち悪いまま終わるんですよね、僕。
なるほど、確かに。
そうですね。
そこに触れてほしいっていうか、
自分たちの歌詞もあったんじゃないのかなみたいな。
そうね。
せっかく内容が結構詳しいだけに惜しいというかね、
そこまで書いてくれればみたいなね。
外も悪かったけど、
自分たちのここもちょっと良くなかったなという教訓ですみたいなものがあると、
なんかもうパーフェクトとまでは言わないにしてもかなりいいんじゃないかなっていう。
そうね、今の話で言うとさ、
僕もちょっと細かいけど気になったのは、
これは多分石倉さん側は把握するのが難しい気がするけど、
システム会社と修理業者のどっちの責任なんだろうね、これは。
どうなんだろう、設定をするのはシステム会社なのかなという気はしますけどね。
システム会社の指示が適切ではなかったんではないですかね。
そういうことなのかな。
対策についてっていうところでも、
特にその修理業者云々って話じゃなくて、
システム会社での再発防止策っていう形で書かれてはいるので、
もちろん最終責任というのは発注元が追うというのは当然あると思うんですけども、
システム会社もそういう意味では責任は追っているのかなっていう形の書きぶりになっているかなっていう。
なるほどね。
でも対策に直接そこまで書かないかもしれないけど、
修理業者に委託した後の最低限の設定の確認みたいなことを何でやってなかったのかなとか、
割と単純な確認で済むような。
だってタイムラインにも事件が起きた後、
システム会社が確認して設定が不明だったことを確認しましたみたいな書きぶりがあるじゃない。
だったらそれで修理した直後にやれよっていう。
やってなかったのかもしれないですね。
やってなかったんだろうね。
やってなかったからわからなかったと思うんだけど、
それが仮にシステム会社の責任でやるべきなんだったら、
その部分が気になるというか。
そうですね。
もうちょっと想像してみて、
システム会社の肩をちょっと持つなら、
修理業者が修理した時にそれが初期かなりなんなりして、
それが設定が変わっちゃうってことをシステム会社がその時に知ってたかどうかだと思うんですよね。
さっきのどっちの責任だろうっていうのはちょっとその辺も含まれていて、
お互いにやる内容をちゃんと理解してたのかなっていう。
そうですね。
どっちかの責任って言いたいわけじゃないんだけど、
多分両方に見過ごしというか誤解とかわからないけど、
なんかちょっと行き違いがあったりとかした可能性があるかなっていうかね。
再発防止策の重要性
その辺が細かい話だけど、
どの会社のどんな委託とかの契約でもありそうな話だなと思って、
こんな細かい危機交換でどんなことが起きるかってちゃんと把握せずに、
全部任せたつもりになってて、
自分の確認を怠ったみたいなことってよく起きそうじゃん。
あとさっきの辻さんがセミナーで紹介した事案もそうだけど、
この手の交換時の設定の不備とかメンテナンス時の不備っていうのが意外と多くてさ。
いや、よく出てきますよね、最近ね。
そうですね。
こんなの普通に当たり前にチェックしそうなもんだけどなっていう風に、
片付けられない理由がそこにはありそうだなっていう。
そうですね、意外と。
思ったよりもこういうの多いんだなっていうのがちょっとね。
そうですね。さっきの辻さんがおっしゃったみたいなこういう流れの問題なのか、
その委託内容の金銭的な問題っていう可能性もあるじゃないですか。
そうそう、いろいろありそうだなっていうね。
そこも確かに知りたい部分ではありますよね。
なんでこうなったんや、攻めるとかではなくて、
どこでやったら止められたんやろうかみたいなことを考えてみたい事例だなと、
こういうのを見るたびに思いますね。
あとごめんなさい、最後に。
この内容はまあいいんだけどさ、この公表の仕方はもう本当にやめてほしい。
バラバラに、衝打手ごとにファイルがバラバラ?
なんか参考にするような事案というか、なかったというか初めて見たんで、こういう形は。
このパターン初めてですね。
そうですね。
どう考えたんだろうな、これは。
なんか理由があるんだと思うんだけど、何かしら?
ただこの、どうせだったらこの内容を一個のまとめてPDFで公開してほしいし、
なんか一個一個項目をPDFで分けて、しかもボックスで簡単に見えないし。
そうなんですよね。
しかもこれ画像なのかどうか分からないけど、これピンピンポンできないしさ。
そう、そうなんですよ。
こういうのはね、なんかちょっと悪いノウハウですよ、これは。
ほんまにそうなんですよね。
理由あるにせよ、知らないで勝手なことを言わせてもらうと、
これはほんとやめた方がいいね、こういう公表の仕方は。
いやー、ほんまにそうだと思う。
何も何かいいことない。
共有しようとか何か言う気にならないもん、これだって。
ここ見てくださいって、だって言えないじゃん。
いちいち項目見るためにPDFをクリックして見るとかさ、ありえないでしょ、こんなの。
内容の良さがこれ全く消えちゃうよ、こんな公表の仕方したら。
すげーもったいないよ、これ。
そうそう。
公表自体は4回目なんですけど、
この特殊な公表方法は今回だけなんですよね。
何でだろうかな、ちょっとそこは不思議。
こういう風にした理由を聞きたい、俺は。
いや、ほんまに。
しかも何かさっき言ったみたいに、色んなPDFで見受けられますけど、
このコピーできひんとかね。
あとウェブにあったら何か謎に右クリック禁止とかしてるのもあるじゃないですか、リリースの中には。
あと画像ですよね。
そんなことをする人には、もうほんとにね、今のChromeには
Googleレンズって付いてるって知ってた?って教えてあげたいなって。
すぐに文字起こしできちゃうからね、そんなのね。
確かに確かに。PDFもさ、編集禁止にしてる系のやつ?
あれはビューワー依存だから、全く無意味なんだよね、あれね。
うん、ビューワーが守るか守らないかだけですからね、そこね。
だからああいう無駄な制限はほんとやめてほしいみたいな。
だからそれはほんまに印象悪くするだけって誰か教えてあげた方がいいと思うんですよね。
意味がある制限だったら別に全然否定しないけど、無意味だからね、あれね。
そうですね、残念だから。
残念だから。
そういう形もね、在り方もやっぱり良い例が出て増えてほしいけどね、
これはあんまりちょっと正直お勧めできないなって思いましたね。
確かに確かにそれは思いました。せっかく内容いいのにねっていう。
そうなんだよね。
内容がね、ほんとに。
壮大な台無しを見てしまった気持ちになってしまいましたね。
ありがとうございます。
はい。
はい、ということで今日もセキュリティのお話を3つ送りしてきたんですけれども、最後にお勧めのあれなんですが。
はい。
早くもう2人からツッコミがきそうなお勧めのあれなんで、ちょっともうすでに恐縮しておるんですが。
はい、なんでしょう。
情報セキュリティワークショップin越後湯沢2024車座経営市長とあれ参加レポートっていうのが公開されたぞということで。
知ってますよ。
正直ね、いろんなところで僕ら話させてもらうじゃないですか。
そうですね、ありがたいことに呼んでいただいて。
3人3様にその時の出来栄えみたいなの、感想がやっぱり妙の見事に違う時もあって。
そうだね。
今回はね、なんかこうちょっとあんまりうまく踊られへんかったかなっていう風に思ってたとこが実はあったんです、僕当日。
その車座で?
喋っている最中。
なんかあんま跳ねてへんかもなって。
そうなの?
そういうのがあってね。
2人はそうでもないっておっしゃってたんですけど。
ほんでね、改めて文章におこつしたものを見たらまあおもろいんですよ。
おもろいかどうかはともかく、僕も今回レビューしながら改めて読んでさ。
ほら、当時の内容ってやる前はすっごい準備してやるけどさ。
やったら割と忘れちゃうから。
わかるわかる、確かに。
改めて読んでみて結構いいこと言ってんなと思ったよ、俺も。
一言で言うと、何かというとためになるな。
そうね。
あとさ、水産の会社の候補の方が頑張ってくれて、記事もすごい詳しくまとめられて、非常に内容を詳しく読みやすくまとまってるんで。
これは大作ですよ、3部作。非常に読みごたえありますよ。
我々3人だけではなくて、今回警視庁の方が2名参加していただいてね。
あれもよかったよ。聞いていただいた方はどういう感想を持ったかわかんないけど、改めて読んでみて、やっぱり普段聞けない人の現場の声っていうかさ。
法執行機関としていろいろ相談を受ける、被害の相談を受けたり、調査をするっていう立場の方から見て、こういう見方があるんだなとか。
公表方法の問題点
そうですね。
なんか違いもわかるし、我々と同じような課題も持ってんだなとかっていうのもわかるし。
すごいやってて、僕らの側がすごい勉強になったしね。
確かにそうですね。自分たちがこういうの大事でやってることも、実は犯人をとっちめるためにはそんなに役立たへんかったりすることもあるとかね。
なるほどね。
その辺は結構、僕もアドバイザーやらせてもらってますけど、目から鱗な話もあったんで。
あれはよかったよね、結構ね。
あんまりそういうエンジニア系だとエンジニア系とか、セキュリティーだとセキュリティー系、集まって人材の話とか課題の共有とかすることはあるけど、
こういうのってあんまりそんなに多くないかなと思ってて、こういう立て付けが。
そういうのも新しいというほどではないかもしれないですけど、あんまりないものができたっていうふうな意味で、もう振り返ってよかったなって思ったんですよね。
そうですよね。これがおすすめなわけね。
感想を喋ってる。
なんやと思って聞いて貼ったんですか、これ。
いやいやいや、これはもう絶対おすすめですよ。
これはもう本当に、ネギさんもそう思うでしょ。
思います、思います。
ぜひリスナーの方にもね、読んでいただきたいなっていうのと、組織に役立つような話もありましてね、内部不正の話とか、特にそうやと思うんですよ。
結構ね、よかったよね。
ということで、これをおすすめのあれとしたいなということでございますが、よろしかったでしょうか?
よろしかったですよ。
ぜひ読んでください。ということで、今回はここまでです。また次回のお楽しみにです。バイバイ。
バイバイ。
