00:00
2週間ぶりの収録になるんですかね、これ。 その間に何かタコパーあったけど。そうですよ、ちゃんと公約通り。公約だったんですね。タコパーをやったわけですけど。もう何喋ったか覚えてないけど。そうですね、結構喋りましたね。
うん、なんだかんだ真面目な話したみたいな記憶はうっすらあるんですけど、なんか60人ぐらい。パッと見た時に60何人みたいになってましたけど。あれ平日でしたよね。平日だったね。平日の夕方?
3時、4時とか。すごい時間にやってましたね。そんなこんなで聞いていただいて良かったなっていうことなんですけど。ありがとうございます。なんかあの前回靴下の穴開くわけへんみたいなしょうもない話僕あったじゃないですか。収録でね。
したね。ああいう話題こそ結構お便りというか反響があるというか。しょうもないな。どういう反響なんですか?
いくつかあったんですけど基本的に皆さん穴開いてるそうです。そうなんだ。中には営業職みたいな方も5つ、いや普通にデスクワークですって人もいたんですけど、まあまあやっぱ大人になっても開くときは開くんだなっていう。
まあそうかもね。まあ確かに気づかなかったら聞いたときに開いてたっていうのはあってもおかしくはないけど。まあ結構開くんやなっていう。やっぱり人に聞いてわかることっていっぱいあるなって思いましたよ。
思い込まずに大人になったら自分だけ観測範囲みたいな。お前の環境だけやろみたいな感じのものっていっぱいあるんやなっていうのは改めて思いましたけど。今回はねお便りが多いんですよ。多め多めちょっと多め。
ECKでニオンソ認証を登録したらポイント付与みたいなのは見たことがない。見たことないですねと。銀行でスマホのアプリ認証を有効にしないと会員ランクが上がらない過去優遇が受けられないやつはありました。
そういうキャンペーンでもやったらええんちゃうみたいな。そうやったら一気に増えるんちゃうんかみたいな。そういうのあるんだ銀行とかで。優遇が受けられる。確かに銀行からしたらセキュリティのレベルが上がるから自分たちを守ることでもあるからやりやすいのかな。
でも結構大手の銀行とかだと必須になっているところとか。銀行じゃなくても金融機関とか金融系はやって当たり前的になりつつあるかなって気はするけどね。
あとこれもちょっと文章から読み取ってやから本当はどうかわからないですけどもしかしたら物理的なああいうトークンからスマホのアプリに変えるとコスト下がるじゃないですか。だからこういう切り替えをしてくださいキャンペーンやったのかもしれない。もうすでに二要素になっててみたいな。確かに確かに。
03:00
大手の金融機関とかで昔あったそのワンタインパスワードのカードみたいなやつ。はいはい未だにありますけどね。デバイスあれなんかもうなくなっちゃったやつとかあるよね確かねアプリに全部移行しちゃったみたいなね確か。ありますね金融機関結構そういうの多いですね。銀行のアプリに統合しちゃいましたみたいなね。
その二要素認証を残しつつもスマホやったらの指紋とかで開くとかフェイスなんとかとかで開くとかでもありますけどね両方いけるみたいなのがあったりしますね。最近だったらねパスキーサポートしてるからあれを使えるようにするとかっていうのもあると思うけどな。そうそうそうそう。なかなか難しいのかな。銀行はちょっと特殊かなって思ってます僕は。
なんか被害があったら結局補填するのは金額上限あるけど銀行が補填するじゃないですか。クレジットカード会社だったりとか。なんでね自分たちを守ることにつながるからこういうことやりやすいっちゃやりやすいかもしれないなと。
あとはネギスさんへの反応というかネギスさんと言えばっていうのはなってるんやなと思うお便り来てまして。今週のあれを聞いてネギスさん一押しのパスワードデーが今日だと知り、会社で定期的にセキュリティの小ネタを書いて発信している資料のネタにさせていただきました。
毎回ネタに困っていたので大助かりのあれ。これ配信もタイミングよく聞けて楽しかったですというお便りがきております。
もはやほとんど言われてないけど5月の第1木曜日かな。先週の5月の連休中ちょうど連休中だよね。日本はそうですね。パスワードデーで。
そのタイミングで結構いろんなところがGoogleとかマイクロソフトとかパスキーに関する投稿をしてたりとか。あの辺はワールドパスワードデーにかけて投稿してるんだよね。
だからそういうタイミングで色々そういうきっかけになったのであれば嬉しいですけどね。
これは会社で定期的にセキュリティの小ネタを書いて発信っていう。どういう部署にいてどういう立場でされているかちょっとわかんないですけど。
確かにこういうことを昔自分もやってたなーって何年もやってないなって気がしますね。
言われてみれば俺も昔やってたのはそういうのな。メーリングリストみたいなね。そうそうニュースレター的なやつでコラムみたいな書いたりとかしたな。
今はやったらダメなんですか?
長らくやってないとね、どこに投げていいかもまずわからんっていうのもある。
メールみたいなんでそういう社内発信みたいなしてる人もいればチームズのグループとかでやってるとかっていうのがあったりとかして。
本当はみんなが知った方がいいのに細分化されて余計見えへんようになってるっていうのもあるのかなって思ったりもしますけど。
06:01
普通に僕らの場合だったらあれ聞いてくださいって言えばいいんじゃないですか。
ちょっとタイムリーじゃないのもあるかもしれないですけどね。
確かに定期的に発信してますからね。
ありがとうございます。
でですね、またご新規さんがいらっしゃいまして。
最近セキュリティのあれ聞き始めた。
最新回から遡っていると徐々にお三方のパーソナリティが明かされていく感じでセキュリティの話と合わせて二重に楽しめる。
ゲームやスニーカーが好きだったりアップルが好きだったりインコ買ってたりという。
確かにね。
逆に古いところに戻していくパターンなんやな。
でもあれではね、前も言ったけどさ、ご新規さんで段々段々遡って聞いてるっていう人とかさ、
最近の聞き始めて、時間になるときに最初の回から聞き始めましたとかさ、いろいろパターンあるんじゃないかね。
1時間ちょいぐらいやからね。週の前半に聞いちゃうと後半聞くのないみたいになってしまうかもしれない。
それでちょっとつまんで聞くとかいう人もいるみたいですけどね。
嬉しいですね。ありがとうございます。
ありがとうございます。これからも聞き続けていただければと思います。
先週文を聞いて思ったこと。
通勤のお供に聞いているのですが、最初の雑談&お便り紹介が終わるあたりで最寄駅に到着することがあるのですが、
それで今週文を聞き終わったと勘違いしてしまうことがあります。
それを週末に気づいて慌てて本編を。という風に書いててですね。
なるほど。
すごいですね。これ要は僕らでいう控室で話が盛り上がったみたいなもんと一緒ってことでしょ?
そうだね。
すごいですね。それただの雑談ラジオみたいなのを聞いただけっていう。
かといってさ、ほら一応僕チャプターつけてるからさ、本編から聞こうと思えば聞けるんだけど。
でも雑談聞いてほしいですよね。
そう、雑談というより飛ばされちゃうとそれはそれで悲しいよね。
結構雑談好きですからね。
そこで終わっちゃって聞いた気になってもらうのも困っちゃうけど。
そうですよ。
面白いな。
いろんなパターンがあるんですね。バイバイを最初に聞きたいとか。
寝落ちするからってね。
聞いた気になって週末に思い出すやらいろいろあって面白いですね。
いろんな聞き方ありますね。
でですね、あとは最後のお便りなんですけども、これは情報提供ですかね。
いつの間にかプロトンパスのMacアプリがリリースされてた。
このセキュリティのあれで紹介されてからプロトンパスユーザーになったけどというふうなことで。
地道に改善されてていいですねという。
だいぶ前だっけ俺が紹介したのかな確か。
多分プロトンとつけばネギスさんじゃないですか。
多分ね。僕は今メインでワンパスワード使ってるんでプロトンパスは検証用に入れてるだけでメインでは使ってないんだけど。
09:02
ただねあれ前紹介したときも言ったと思うけどあれってプロトンのメールのサービスとひも付いてるからさ
ID登録用のだけのメールアドレスをランダムなやつを勝手に作れるんだよね。
それがだから結構便利で。
そういう用途が必要な人は結構プロトンパスいいかもしれないよね。
というふうにお便りいただいたんで今読み上げた方にはステッカーの印刷コードを差し上げます。
5つ集めたらシークレットもらえます。
はいじゃあセキュリティの話を入る前にですね。
告知がある。
今日収録している日からちょうど1週間ということで。
1ヶ月だ1ヶ月ってことで。
今回も今年もやりますよあれを。
何を?
情報セキュリティ自己対応アワード。
はいはいはいはいきましたね。
確かにちょうど1ヶ月後か。
6月11日に大月のね11日の夕方17時から18時半ですね。
やるぞっていうことをねちゃんと今年も9回目ですよ。
そう9回目なんですね。
今回あれだよねオフラインというか現地で。
現地もあるんでしたっけ。
あれ違ったオンラインだっけあれ。
確かに一応申し込みサイトはできてるんですけど。
あれ完全オンラインだったっけ今回。
定員なしって書いてるのに多分これオンラインじゃないかな。
オンラインかごめんごめん最近ごちゃごちゃになってる。
いろいろやるから。
いろいろやるとねそうなんですよね。
そっかそっかすいませんオンラインでした今回は。
多分オンラインだと思いますね。
長らくオフラインではやってない。
そうだねなんか懐かしいよね。
僕が会場で多くの方に来ていただいてましたからね。
そうですね今年もどんなところが表彰されるのかみたいな。
今いろんな調整中というふうなことなんで。
もしよかったら今のうちに申し込んでいただければなと思います。
ぜひぜひそうですね。
じゃあ今日もセキュリティの話をしていこうかなと思うんですけれども。
じゃあ今日僕から行きますかね。
はいお願いします。
ニュース記事を読んでておってちょっと気になったことが書かれてあったんでそれを紹介しようかなと。
それとそれを基に知っているレポートを参照しているレポートを紹介しようかなと思うんですけど。
記事自体は脆弱性スキャナーが一台では不十分な場合はみたいな感じのタイトルの記事だったんですけれども。
先に言っちゃうとこれ後半宣伝やったんでその辺は触れずにですね。
内容でつまんで気になったところを紹介していこうかな。
もし気になった人は読めばいいかなと思うぐらいあるんですけども。
脆弱性の数とかって看護さんとかも前このポッドキャストで何年の脆弱性CV何件あったと思いますみたいな質問をされてた回があったような気がするんですけれども。
今はほらもう年間3万超えてくる感じ。
そうだね多分今年は超えるだろうね。
12:00
結構長引きそうですよね。
去年が確か3万件弱とかあった気がするけど。
それで見ると1日に約80件ぐらい登録されるぐらいの計算になるんですよねこの3万ぐらいって。
CVEの数がってことね。
ちなみにCVEで発行された数ねその年に。
23年だったとしても22の番号がつかれてでも発行したのは23ってカウントしたとして。
見るともう今2024年でさっき見たら14484件あります。
なんか2024年に入ってからだいぶブーストかかったっていうか。
数が増えてるよねちょっとね。
だからほらあの前に看護さんが言ってたみたいにさNVDの情報が追いついてないみたいな。
大変なことになってます。
大変なことになってますよね。
2013年から計算すると10年2023年までで確定してるやつまでで6.8倍の脆弱性の件数になってるということで。
これが増えれば増えるほど脆弱性スキャナーっていうふうなもので見つけるのが困難な状況にどんどんなってくるんじゃないかと。
登録する側がね遅れてしまってるわけですから。
スキャナーの方になってきたらもっと大変ちゃうのみたいなところである2つの脆弱性スキャナーを比較してるんですね。
比較してるのがイントルーダーという会社の分析で比較してる脆弱性スキャナーはNESASとオープンバスっていう。
オープンバス自体はNESASから派生したオープンなスキャナーとして使われていることが結構多いですけれども。
それぞれのカバー範囲とかっていうようなものをどんどん比較していってるんで、レポートは結構長いんですけれども、それをいくつかつまむと。
NESASはですね、今までの脆弱性のカバー率っていうところで言うと49572件のCVEをカバーしてて、
オープンバスは44306件ということで、それぞれ比較すると10%ぐらい件数が違う。
オープンバスの方が少ないってことなんですよね。
2010年以降に発行されたCVEの件数っていうのが118528件なので、これをそれぞれがどれぐらいカバーしてるかというと、
NESASは41.82%、オープンバスは37.38%ということで、両方とも半分はカバーできてないと。
ただ古いものって別にカバーしておく必要あんのかとかっていうふうなスキャンの速度に影響したりするので、
こういうのは全部カバーしてりゃいいってもんじゃないというふうに僕も思ってるんですけども、
現状としてそれぐらいのカバー率だということになっています。
それぞれのNESASとオープンバスの2つがそれぞれどれだけ重複している脆弱性を見れているのかとか、
あとは各々で見れているやつは何なのかっていうのも比較していて、
重複しているのは37557件で67%ぐらいは重複していると。
15:06
一緒にあっても両方とも見つけてくるやつってことですよね。
で固有になっているのがNESASの方は12015件でオープンバスの方は6749件。
ここは重複なしでそれぞれでしか見れない部分というところなんですけども、
パーセンテージで見るとNESASに軍配という感じがすると思うんですが、
これをリスクのカテゴリーで、ロー、ビリアム、ハイ、クリティカルみたいなやつありますけども、
それで全てにおいてNESASが勝っているんですけれども、
脆弱性のカバー率がどんどん危ない脆弱性になるにつれて、
差が少なくなっていっているってことなんですね。
やばいやつほどそんなに件数の差がなく、
オープンバスもきちんとカバーしているっていう風なものになっていましたね。
でもあれだね、ちょっと意外意外というか意外でもないのかな。
NESASの方はね、さっき言ってたけど商用のテナブルという会社が優勝でサポートしている今はね。
もともとNESASから発信しているけど、オープンバスの方はオープンソースでアップデートとかがされているから、
カバーしている範囲が違うとはいえ、もっと結構重複しているかなと思ったけど、
意外のそれぞれでしかチェックしないやつって結構多いんだね。
知らなかったな。
あとさっきのさ、クリティカルになればなるほど重複率が高くなるっていうか、
それは何となくわかるっていうかね。
やっぱ対応書関とみたいなね。
重要なものはさすがにどっちも対応するよねみたいなね。
今のCVEの件数でこの案件見ていくとみたいな話しましたけど、
これっていうのはローカルの脆弱性とかも含まれているんですね。
なるほど。
例えばログインして、クレデンシャルスキャンとかって言ったりしますけど、
情報を与えて中見ていくっていうスキャニングもできると思うんですけども、
それをリモートのみに絞った比較っていうのをこのレポートはやっていて、
これだけで見ると全体で見たら、
リスクカテゴリはロー、ミディアム、ハイはオープンバスの方が件数多かったんですよ。
きちんと見れてる。
で、クリティカルのみネサスが勝ってるっていう風な、
それも結構近差っちゃ近差なんですけど、
こういう差もありましたよという風なことが書かれてありましたね。
なるほど。
で、今ちょっと触れたローカルで見るとっていう認証チェックとか、
クレデンシャルスキャンとかいろんな呼び方ありますけども、
これを比較したときにネサスの方は、
エージェントをインストールしてチェックするっていう機能もあるんですよ。
ただオープンバスにはなくて、
SSHとかSMBとか認証情報を与えて中身に行かせるっていうスキャン、
認証スキャンっていう風なものは両方にあるっていう違いがちょっとあるんですけど、
ただね、これも結構僕、確かにそうなのかって思った。
ハッとしたことがレポートに書かれてたんですけど、
どっちのスキャナーもですね、
18:00
リモートでその脆弱性をチェックするっていう風なリリースの前に、
ローカルチェックの方が先にリリースする頻度が高いんですよね。
ああ、そうなんだ。
当たり前っちゃ当たり前かもしれないですね。
レジストリ見りゃすぐ分かるとかっていう風なものとかって。
ただ脆弱性スキャナーって僕らが、
僕が昔から触れてたから、
外からスキャンするっていう風なとこに重きを置いたツールと思い込んでたんですけど、
今はそうじゃないのかもしれへんなという。
あれだよね、さっきのエージェント機能もそうだけどさ、
Nexusもそうだし他の製品もそうだけど、
今は単なるスキャナーっていうよりも脆弱性管理のトータルな製品として
発展するっていうものが多いというか、Nexusもそうだよね確かね。
そういうのの自然な流れかもしれないね。
その外からスキャンするっていう風な手軽さっていう風なものを重要視したい場合もあるかもしれないですけど、
最新の脆弱性を早く常にチェックしたいっていう風なことを考えてるんだったら、
エージェントベースか、もしくは認証スキャンっていうハードルを超えられるんだったら、
こっちを選択するのが正しいアプローチなのかなということですね。
よく脆弱性の悪用までの期間みたいな話ちょいちょい出てきたりしますけど、
その期間内に見つけ出さないと早く、それで対処しないとってなると、
ちょっとでも早く見つけるためにはこっちを使うことを検討した方がいいのかなっていう傾向的に。
なるほど。
そうなんですよね。そんなことが書かれてあって。
そうですね。見てて思ったのは、この記事自体は両方使わない、見られへん部分があるから、
うちの製品そんなことできませんみたいなことが書かれてあったんですけど、
そのカバレッジっていう風なことももちろん大事かなと思うんですが、
運用しやすさとかレポートとかも大事かなっていうのも忘れたらあかんしなっていうのもありつつ。
あとはさっき最後の方に触れましたけど、
特徴とエージェントを優先させるっていう風なことを考えると、
なくなりはしないんだけど、脆弱性を外からスキャンしていくっていうアプローチ自体が
もうちょっと考え直さなあかん時期に来てるんかなって思いましたね。
なんか不確か、手軽なんですけど不確か。サービスとして提供はしやすいと思うんですよね。
サービス提供する側としては。コンサルするとかだったらいいかもしれないけど、
確実に見つけてきてってことを考えたら、やっぱり今のご時世考えるとローカルにインストールするか、
認証スキャンをするかみたいなことをしっかり考えないといけないかなっていう風なことを
ちょっと僕も考え始めましたね、これを見て。
なるほどね。ただあれだよね、一方でさ、最近のさまざまな脆弱性の侵害なんかも含めてだけど、
いわゆるアタックサーフェスマネージメント的なものっていうのが、
新たにさ、それやってること自体は前からやってる外部からの、言ってみれば脆弱性のスキャンと同じといえば同じだと思うんだけど、
21:03
それが見直されてるっていうかさ、外から見た自組織の状況っていうのを的確にちゃんと把握して管理しましょうっていう。
そうですね。
そういう観点は今言ったような話で言うと、リモートのスキャンに該当するのかなっていう感じもするんで、
使い方次第っていうかね、ローカルでの脆弱性の管理と、外から見たリモートでのスキャンのうまく活用の仕方なんじゃないのかな。
そうですね。
どっちかが優れていて、どっちかがダメとかっていうわけでもないかなと。
場合によったら外からのスキャンは本当にポートスキャンとバナーチェックぐらいに留めて、
あとは中から自分たち見る仕組みがあるんでっていう風に、そういうバランスの取り方もありかなと思うんですよね。
あとはさっき言った製品の違いというのも考えると、その中で管理する、チェックする製品と外からチェックする製品を別々にするとかね。
それもありかもしれないですね。
そういうことでカバーする範囲全体をカバーできるようにしましょうみたいな考え方はあるかもしれないよね。
あとはこのシステム群はリモートからのチェック、このシステム群はローカルっていう、そういうシステムごとに進み分けてもいいかもしれないですよね。
まあまあ確かにね、外部に露出していないものとかもあるだろうしね。
まあそのあたりうまく組織ごとに工夫して取り組む必要があるかなっていうのは感じるよね。
あとは予算的なところかなっていう、エージェント入れると結構高くなったりするケースもあったりするんで、
その辺を考えてどういう組み合わせにするかっていうのがセキュリティ対策する側の腕の見せ所になってくるポイントかなっていう風に感じました、これを見てて。
まあでもこれはあれだよね、今回たまたま2つの製品を比較してるけどさ、
まあ世の中同じような脆弱性のスキャンとか管理とか、あるいは今言ったようなASMだったり、
まあいろんな観点でこういう製品とかソリューションあるけど、
多分ちゃんとその比較評価してみないと、ここら辺の違いっていうのはあんまり見えてこないっていうかさ、
それぞれの製品とかサービスの強み弱みみたいなのって、
スペックだけ見ててもちょっとわかんないよね、きっとね。
これこんなに差があるとはちょっと意外だったなっていうか。
まあ確かにそうですね、使い勝手というかね、さっき僕が言ったみたいな運用のしやすさとか見やすさとかね、
あと通知機能があるかとかそういう細かいところも見ていかないとダメですもんね、運用するとなると。
いや結構ね意外でした。
知ってるようで知らんかったなっていうのがこうわかった。
そうだね、確かに。
はい、そんな感じでございます。
ありがとうございます。
じゃあ次はですね、ねぎしさんいきますかね。
じゃあ私はですね、ちょっと前のレポートなんだけど、
5月の1日かな、BitSiteっていうところがKEVのカタログに載っている脆弱性に関する調査レポートっていうのを出してて、
これちょっと面白かったんでこれ紹介したいんだけど、
最近そのKEVも結構運用し始めてからもう何年か経っているんで、
24:02
KEVに載っている脆弱性がどういうものかみたいな調査レポートってのはちょいちょい見かけるんだけど、
今回のやつがちょっと変わっているというかユニークなのは何が違うかというと、
BitSiteってランマ使っている人もしかしたら国内にはいないかもしれないけど、
結構セキュリティサービスいろいろ提供していて、今もちょうど話出てきたけど、ASAのサービスなんかを提供している会社なんだよね。
ここはその定常的にインターネット全体を常にスキャンしていて、脆弱性の有無とか、
あるいはその対応状況だったりっていうのは調査している。
そのデータを基にしてその中にKEVに含まれる脆弱性があるのかないのかとか、
あるいは途中でその脆弱性が対応されてチェックからなくなるとかさ、
そういう状況っていうのは調べられるんだよね。
それをまとめてみました。2023年1年間分ちょっとまとめて調べてみました。
そういうレポートになっていて、ざっくり全世界の140万組織っていうからかなりの組織数だけど、
の対応状況をまとめてみました。こういうレポートになっています。
全体のレポートは結構ボリュームが多いので、要点だけかいつまんで紹介したいなと思うんですけど、
まずですね、KEV自体は1000件超えていて結構数は多くなっているんだけど、
全部について調べたわけじゃなくて、このビットサイトがスキャンできるものとか一部に限られるので、
KEV全体のうち、おおよそ20%くらいの脆弱性が対象になっています。
その20%の脆弱性に対して、どれくらい2023年の検出があったかとか、
それがどういうふうに対応されたかっていうのを調べました。
このデータによると、全体の100何万という組織のうち、
おおよそ35%、大体3分の1くらいかなが、2023年に1つ以上のKEVに該当しています。
数がもっと多くなると、例えば66%、おおよそ3分の2くらいは2つ以上。
10%くらいの組織は10個以上って言っていて、確かにそれは組織によっては規模が大きければ、
年から年中KEVの対応しているところっていっぱいあるから、それは増えるでしょう。
でも少なくとも1つ以上というところが35%あります。
ただこれは全体で見て、KEVの脆弱性を該当するものが出て、
すぐになくなっちゃうわけじゃなくて、対応するものはずっと対応しなきゃいけないわけなので、
時間軸でもちょっと見てみましょう。
そうすると時間軸で見たときに、1週間あたり1つ以上KEVを既に対応しているというところがどれくらいあるかというと、
おおよそ全体の60%くらいの組織が平均すると1週間に1個KEVに対応していると。
結構多いよね。だからずっと対応し続けない方はずっとKEVを該当しますというふうにスキャン上は出るわけなので。
27:00
毎週対応している。
毎週新しいものが出るわけではないんだけど、毎週毎週チェックに引っかかるというところがおよそ60%組織であります。
残ってるってことですね。
これが数が多くなってくるとどれくらいかというと、毎週平均して10個くらいKEVの脆弱性が見つかるという組織が2%くらいあると言っているので、
数は少ないけども多分これは大手の会社だろうね。
そういうところは平均すると年から年中毎週10個くらいのKEVで格闘しているというとんでもないことになっていると。
そういうような感じで結構KEVに乗っている脆弱性っていうのがインターネット上のスキャンではかなり見つかっているという状況が見えていると。
しかもここのビットサイト当然KEVに乗っているもの以外も含めて脆弱性のチェックはしているわけなんだけど、
KEVに乗っていない脆弱性の平均と比較すると、KEVに乗っている脆弱性の方が大体2.6倍くらい多く組織で見つかりますと。
特にその中でもKEVってさ、なんかちょっと前からランサムウェアのアクターに使われてるか使われてないかってフラグが。
ノーンかアンノーンか、そんなやつでしたっけ?
そうそう、そんなのがあるよね。で、あれで見るとなんかランサムウェアのアクターに使われてますっていう方がさらに多いというのがわかっていて。
だから逆に言うとさ、これそのKEVに乗っているから多いわけではなくて、使われているものが多いやつがより狙われているっていうことだと思うんだよね。
逆にインク関係から見ると逆だと思うんで、それだけたくさんの組織で使われていて、利用しやすいものがより悪用されるし、よりランサムウェアのアクターにも利用されているっていう、おそらくそういうことだと思う。
結果それがKEVに乗っている方が、そうでないものに比べてだいぶ多い、数倍多いってことなんで。
なるほどね、それは確かにKEVがそこに注目するっていうのは結構効果があるなっていうのはこの辺からもわかると。
じゃあ実際にスキャンしてみて、どのくらいの時間で脱脱性が対応されるかと。
スキャンしていれば当然対応されれば脱脱性も対応済みっていうふうに分かるわけなんで、その期間も調べてみましたって。
これが結構面白いんだけど、KEVに乗っているやつは全体平均するとおおよそ174日で修正されてますと。
長いと見るかどう見るかわからないけど。
ちょっと長い感じはするけどね。
半年くらい平均するとね、全体平均すると。
でクリティカルなものだけに限っても137日って言ってるんで、思ったよりも結構長いかなという感じがある。
ただそのKEVに乗っていない、それ以外の脱脱性はどうかというと、全体平均すると621日って書いてあるんで。
平均すると1年半くらい。
30:01
1年半以上ですねこれね。
ただちょっと難しいのは平均値なんでかなりばらつきが大きいみたいなのね。
だからちょっと単純にこれだけでずいぶん期間が長いなとは言い切れないんだけど、全体平均だとこれくらい。
全体ならしてみるとKEVに乗ってないものに比べてやっぱりKEVの方が対象のスピードは速いということは言えると。
数倍速いよね。
それくらいの感じになってると。
特にCV施設のスコアのクリティカルとかスコアが高いものの方がもちろん短い時間で対応はされると。
とはいえ結構思ったよりもちょっと長いなという気が。
そうですね。ちょっとえって思っちゃいますね反射的にこの数字は。
KEVって僕らからするとすぐに対応しなければいけないような感覚のものだけど、
インターネット全体で見ると例えば規模の小さいところとか、そもそも自分たちが贅沢性に該当してるってことにすら気づいてないところとかね、そういうのも全部含まれてるから。
これ直さなかった理由はもちろんこんな数も数だからヒアリングしてるわけじゃないですもんね。
いや単にこれスキャンしてるだけだからね。
スキャンしただけですもんね。
全然わからないので。
だからそういうものも含まれると考えるとそれぐらいになっちゃうのかなって感じだね。
加えて最後に出てくる数字としてCISAがKEVに乗っけるときには連邦政府機関向けに1週間でやらなさいとか2週間でやらなさいとか。
期限が設定されてますよね。
クリティカル度によって多長期限がばらけるけども1週間2週間3週間みたいなレッドラインが設けられますよねと。
じゃあそれどれぐらい頑張られてんのっていうのも調べてみましたと。
そうするとこれもざっくりだけど全体でおおよそ4割未満しか守れていなくて。
逆には6割は守れてないと。
そう6割以上の組織は守れてないと。
特にこれはその期限が1週間っていう特にクリティカルなものに限ってこの数字でこれが2週間3週間ってレッドラインが伸びていくとどんどんどんどんこの割合が下がっていくと。
30%20%ってどんどん下がっていっちゃって。
だから余裕があるほどまだ大丈夫だよねってなるのかどうかわからないけど理由はわからないけど期間が長いものほど守られない傾向にありますと。
ダイエットは明日からみたいなもんやな。
その例えがどうかよくわからないけどそういうことですね。
先送りすると失敗しやすいってことですよね。
あと1週間って出てるっていうものは当然既に悪用されているものでも非常に多分影響度が大きいものに関してCICが設定しているわけなので。
おそらくだけど世間的な注目も大きかったりとか。
目立つ贅沢性が多いから比較的取り組みが早いのかなとか。
いろいろ理由は考えられるけど。
でも掃除で見ると下半数が守れてないと。
33:01
でも中でも一応このCISAのデッドラインというのは元々連邦政府機関向けに出しているものなので。
政府機関はちゃんとやらなきゃいけないってなってるんだけど。
じゃあその政府機関は守られてるんですかというと。
民間のそれ以外の組織に比べると1.5倍ぐらい守ってる組織はどうも多いらしいんだけど。
それでも全体の半分ぐらい。
期限1週間のものでも半分ぐらいで。
2週間3週間で伸びるとやっぱり下がっていくというのはそれはやっぱり同じ傾向なので。
それで大丈夫っていう気が若干するんだけど。
確かにね。
その連邦政府機関といっても外からのスキャンでこれは政府機関だなって分かるものっていうのを多分調べてると思うんだけど。
そういうものに限ってもどうもちょっと思ったよりは守られてないなというか。
ちょっとそういう状況が分かってきていて。
他にも例えば業種別にどうだとか国別とかね。
いろいろそういった比較とかもあるんだけど。
その辺はちょっと今回割愛するけど。
思ったよりももうちょっと守られてるというかもうちょっと対応スピードの差があるような気がしたんだけど。
意外にそうでもないなというのと。
でも一方でやっぱりKEV乗ってるものはそれだけ危険度が特に高いしもう既に悪用もされてるし。
特にそのKEVっていうのがここ1,2年、2022年に始まってから注目もされてきてるんで。
ここに乗ったものの対応スピードが他のものよりもかなり速いっていうのはそれはもちろん予想されてた通りだけども。
そういう効果は実際あるなというのは分かるけど。
やっぱりこれかなりばらつきが大きいというのは見て取れるので。
自分たちの組織にとってどういう対応基準でどれくらいのスピード感でやるかっていうのはちゃんともう一回見直す必要があるのかなというか。
全体でこの数字ってことは実態は思ったよりも厳しいなっていうのが直直な印象でしたね。
思ってたより良くはないって感じかな。
もうちょっといいような気がなんとなくしてたんだけどそうでもなかったなと。
そうでもない?どんなふうに思った?
もうちょっと良い結果が出そうな気はしてた。
そうですね。
実際CISAでしたっけ?1000件超えたみたいなタイミングで。
カンゴさんが紹介したよね。
あれはもっと数字良かったような気がしたね。
そうだよね。俺もそう思ったんだよね。
あれ聞いてた話とちょっと違うなと思って。
実際もっと幅広く民間まで広げてみるとこういう状況なんだなっていうのは。
あれはCISAが内部で政府機関向けに調査してるものだから。
そうですね。
外部からスキャンするのとだいぶ元のデータが違うとはいえ、
ちょっと意外とやっぱりまだまだかっていう感じはするというかね。
確かにそうなんですよね。
あとこれって地域というか場所とかで差はあったりするんですかね?国。
36:00
国ごとの違いとかもだいぶあったみたいね。
そうなんですね。
その辺の差が出る理由とかっていうのも今回あれですもんね。
外部でスキャンした結果を分析された結果なので、
数字として見えているその具体的な背景というか何でこうなのかっていうところまではちょっとわからないっていう感じですかね。
あと業種によっても例えば教育機関がどうとかテクノロジー関連の業種がどうとかって結構そのばらつきが業種ごとにもあったり、
地域ごとにもあったりとか結構データとしては興味深いんだけども、
何でこうなっているのかなっていうのが若干わかりにくいというか。
これKEVはきっと使っているだろうなっていうことではあるんですよね。
どうだろうね。
見てるって言うんですかね。
どうだろうね。
でもそのKEVで明らかにその有意な差があるのは確かなので、
さすがにKEVを見ているからこうなっているんだと思うけどね。
少なくとも連邦政府機関は間違いなく見ているだろうけど、
民間企業とか組織がどのくらいKEVのことをちゃんと認識しているからこうなっているかっていうのはちょっとわかりにくいかもね。
というのは例えばさっきの話でKEVに載っていてもKEVに載っていなくても、
CVSのスコアが高い方がやっぱり数値はいいんだよね。
修正される速さがね。
対応時間も短いし対応している組織の数とかも全然多いんで、
ひょっとしたらそういう方が数字の違いに与えている影響というのは大きいのかもしれないというのはちょっとあるんで。
果たしてこれが本当にKEVに載っているから注目度が高まった効果なのかというと、
その辺の因果関係は読み取れないんだよね。
測れないですね。
結果的に確かに優位な差はあるねっていうことは言えるけど、
だから効果があるねと言えるかというとちょっとよくわからないっていうことはあるね。
ただ割とこういう実際のスキャンに基づくデータっていうかレポートっていうのはちょっと珍しかったので、
日本まであんまりなかった気がするんで。
こういうのは多分今回一回きりじゃなくて、
継続してやっていてその数値がどう改善したかとか。
確かに。
あとこれを補強するのは他のさっきも看護さんが言ってくれたみたいな、
因果関係が伺えるような別のデータとの補強とかがあるとだいぶ説得力が違うかなという気がするんだけど。
もう少しスキャン対象の国別とかっていう流度ではなくて、
従業員規模とか。
一応組織の規模的なやつもあるにはあるけど。
あるんですよね。
従業員とかとあと予算規模みたいな。
どれぐらいの売上高の会社かとかそういう意味が。
なるほど。
なかなか厳しいね。
それがもしかしたらどっかの境界で対策がめっちゃ遅れてる遅れてないのを、
境界線がどっかで引けるんじゃないかなってちょっと思った。
39:02
なるほどね。
確かにそういう考察は結構大事かもしれないね。
一応その組織の規模で言うと、
規模の大きいところの方が当然そのKEVに該当する
自宅線の検出率が高いなっていうのは、それはそうだよねっていうような。
ただ一応そういうのが確認できましたっていうのはデータが出てたりとか。
一応あるはあるけど、今言ったような観点っていうのはちょっとないかもな。
なるほどね確かに。
そこちょっと気になったなっていう。
今後はこういうのを見ている間に、
一個一個の個々の自分たちの組織にとってもそうだし、
例えば業界全体とかもうちょっと全体で対応が進むためには何が足りてないんだろうかっていう
そういう考察が必要ってことだよね。
そうだね。思ったよりも対応が進んでないようなというか、
思ったよりも期間が長いなって感じてるっていうことは、
その辺の意識のギャップがあるってことだから。
なんでそれがそんなに進んでないんだろうかっていう。
さっきのCISAの言ってるのとちょっと少しギャップがあるなって感じるっていうと、
実体との差はどこから生まれてるんだろうかっていうのは気になるところですよね。
ちょっと言うのは簡単ですけどね。
まあそうですね。
結構調べるのとか分けるのとかそんな大変やろうなと思うんですけど、
問題の解決には必要かなっていう。
そうだね。そういうののベースになるデータとしては非常に興味深いなと思いました。
ぜひこれはちょっと結構、
今日は時間なくてそんなに細かく説明できてなかったんで、
ぜひ読んでほしいですね。
はい。分かりました。ありがとうございます。
はい。じゃあ最後はカゴさんです。
はい。私も脆弱性の話してよろしいでしょうか。
なんかちょっと脆弱性の回ですね。
なんなんですかね。
たまたまだね。たまたま。
たまたまですかね。
仲いいからな。
そうね。
今日はですね、以前の回で、
私NISTのNational Vulnerability Databaseで起きている問題というかトラブルというか、
バックログがめっちゃ出てるよっていう話をしたと思うんですが、
あれの後日談というかその後の動きというか、
今こういう状況ですというところで、
CISAがですね、
Vulnerability Enrichmentっていうのを、
これ2日前なのかな。
ついこの間ですよね。
これなんか唐突感が若干あるんですけど、
始めましたっていう。
急にって感じがするよね。
急にで、なんやそれって話。
について少し触れたいなとは思うんですが、
まずNVDの状況なんですけども、
以前なんかコンソーシアムを立ち上げて云々みたいな話があったかと思うんですが、
あの話ですね、コンソーシアム実際立ち上げますよって話はNIST自身しているんですけども、
現状まだまだちょっと具体的な話が出ておらずというところで、
実際あのNVDのページ見ると、
4月の25日に更新はされていて、
42:00
コンソーシアムをステークホルダーの中で立ち上げて、
長期的な課題解決に取り組んでいきますよっていうのは追及はされたんですけど、
やっぱりそのぐらいというところがありつつ、
実際ですね、大丈夫かなというのはその数字を見るとですね、
実はバックログというか、
寸読対応がないですよね、
寸勢弱性なのか分からないですけども、
1万件超えちゃったんですよ。
さっきの話じゃないけど、
今年に入ってからもう1万数千件ってなってるからね。
本当に今年分析されたというか、
NISTで処理された件数というのが、
120件ちょっとで、
今、アウェイティングアナリシスもバックログになっちゃってるものが、
1万200件というところで、
なかなか深刻な状況、
これなんかあんまり日本でもまだまだ話題になってない感じがするんですけど、
実際のJVNですね、
日本のJVNにおいても、
これ実際ここのJVNのデータベース、
ipediaに載るものっていうのは、
NVDで分析が終わっているものっていうのが取り扱われるというところがあり、
実際ここに登録される情報に変動するという形で、
影響が出ているというアナウンスが、
JVN IPediaのページにも、
4月24日付けで掲載をされていたりというところも、
じわじわじゃないんですけども、
やっぱりこの辺の問題っていうのが、
広く影響が出ているというところがあり、
ただとはいえ具体的な解決っていうのが、
あまり見えてきておらず、
4月の中旬なんかに、
海外のセキュリティの専門家の方々が、
アメリカの議会に対して、
なんとかならないかという形で、
支援要請みたいなのも出してはいつつも、
すぐにはこの辺解決されていない状況という、
そういった状況の中、
さっき唐突に始まったって話したんですが、
CSAが、
NVDに似たような情報を、
端的にGitHubにJSONの形で公開をし始めたっていう、
すごいざっくりと今言ってしまったんですけども、
非常に分かりやすい。
CVEのデータに対して、
エンディッチメントっていう形で、
データを補強して公開をすると、
パブリックデータベースとして公開をすると。
で、既に1300ぐらいですかね、
そういったCVEの情報が、
GitHub上に公開をされているというものではありまして、
特徴としては、
NVDに公開されていたような、
CPEであるとか、
ああいった情報が書かれているだけでなくて、
特徴的なことは、
SSVCのディシジョンツリーに使える情報っていうんですかね、
損に必要な情報も、
合わせて必要と判断されたものについては書かれているというところがあるので、
45:02
そういう意味ではちょっとNVDとは、
少し書かれている情報が異なりはしつつ、
ただ内容的には、
NVDの内容に近いというか、
だいぶ似てはいるので、
この取り組みに対して現状を見ている感じでは結構ポジティブというか、
よくやった、やってくれみたいな形の反応っていうのは結構多くて、
私自身も現状のNVDの状況などを見るに、
やっぱり誰かが他にやらなきゃいけないのかなっていうのは、
そうは思いはしつつ、
ただ同じアメリカの国の中の組織で、
NVDがこういう現状なので、
もうちょっとうまくやれないのかなっていうのは、
なんとなく見ていてもんもんというか。
なんか畳から見ると、
連携してるんだかしてないんだかわからないような動きだよね。
そうそう、そこがやっぱり実際ですね、
CPEにぶられる情報なんかも、
これちゃんと成語が取れるのかっていうところは結構指摘というか、
実際大文字小文字とかも含めて、
この辺確かにNISTが結構独占的にやっていたところだったので、
ここはちゃんと連携をされて、
既存のこれまでの通りのCPEの枠組みの中で、
今回このバルーンリッチメントっていうCSAが始めた取り組みっていうのが、
そのまま機能するのかとか、
そもそもそういったところを含めて、
さっき唐突感があるって話はしたんですけども、
運用に乗せられるものなのかなっていうのが、
まだちょっと現状わかり、読みづらいなというところがありまして、
CSA自身もGitHubのReadMeのページ上では、
まだまだ変わるよという感じで書かれていてですね。
なので現状は、乗っかってるもの、
それそのままをすぐどう使おうっていう話を考えるというよりかは、
しばらくはちょっとこの辺の動きというか、
取り組みの様子なんかを見て、
必要に応じてNVDの代わりとなるのかとか、
あるいはそれ以外の手段に採用できるのかとか、
っていうところを見ていく必要があるのかなと。
今後数週間で急速に進化すると予想される、
結構ドキドキする内容がGitHubのReadMeに書かれていたりするので、
なので下手するとデータフォーマットがガラッと変わる可能性も。
そんなん困りますよね。
そうそう、やっぱりあり得るので。
現状こういう取り組みが始まるのは困っている人が多くいらっしゃるので、
それは一時的なものとしては良いと思うんですけども、
やっぱり長期的な部分で見ていくと、
根本的なNISTがはまった問題って、
そもそも資金不足、人不足っていうリソース面の課題に直面して、
48:02
やっぱりこういう現状が起きたというふうに私は思っているので、
根本的なところで言うと多分これ解決されてない状態を、
CISAがそのまま引き取るっていうのが解決に至るのかなっていう、
なんとなしの疑問っていうところもやっぱりあって、
また件数が爆増していくと、
このプロジェクトをまたちょっとバックログが束るみたいな感じになってしまうと、
それはそれでよろしくないのかなと思うので、
ちょっとその辺は脆弱性分析って全体の流れの中でもう少し、
長期的な枠組みというか取り組みのやり方っていうのが、
議論されていくといいなっていうのは見ていて、今回ちょっと思いました。
なんかでもあれだよね、これいいなと思ったっていうかさ、
おそらくその基本的なアプローチがちょっとNVDのほうの、NISTのほうと違うのは、
CISAのほうはあくまでこれSSVCがベースになっていて、
もともとそのKVを出したときにも、
CISAはSSVCの連邦政府機関向けにカスタマイズしたガイドラインを合わせて出していて、
これに従ってちゃんと対処しなさいねみたいなアナウンスを出してるけど、
でも結局そのSSVCのツリーの決める項目っていうのを、
どう扱うかっていう部分については、なんかちょっとよくわかってなくて、
それを参照してやろうとしている民間も、結局その部分は自分たちでやらなきゃいけないっていう、
そういうちょっとチグハグな感じだったんだけど、
多分だけどさ、これってそのSSVCを今既に運用している政府機関とかに対して、
今これも既にKVに乗っててアクティブでエクスプロイテーションがあるよとか、
何らかしたら今回のエンディチメントで増えたのは、
例えばまだポックが出ている状況ですとか、そういうそのKVに乗る手前の段階でも乗ることになるんで、
そういうのも含めてなんかそのSSVCの運用が多分しやすくなるようなことを目指していて、
でおそらくだけど、SSVCでそのエクスプロイテーションありになるとか、
そのここの今READMEに書いてある状況に該当するものって、
全体の脆弱性からするとおそらく1%とか2%とかすごい少ないはずなんで、
その辺がさっきのリソースの問題を多少解消しているというか、
NVDのように全部が全部ってわけじゃないけど、
それにしてもバックログが1万件溜まるというような状況にはおそらくならないはずなので、
多少そういう意図は感じられるというか違いという点では、
そのままだからNVDのあれを置き換えるというものじゃないのかもしれないよね。
ちょっとその辺の関係がよくわかんないけどね。
ただ、方向性としては非常にいいなというか、
SSVCってなんか良さげだけど、結局でも判断する部分を自分でやらなきゃダメなんだし、
51:01
解決してないじゃんって。
それが一番大変ですもんね。
そうそう、いろいろそれが根本的な課題だよねってあちこちで言ってたけど、
それを一つ解決する道としてはいい気はするけどね。
そうですね。なので、事業継続への影響ですかね。
あの部分を多分自分たちでやれば、
この今のバルーンリーチメントで公開されているデータと合わせて、
その脆弱性の取り味っていうのができるようになるのかなっていうふうには思いますね。
そうですね。なんかちょっと贅沢言うと、
このJSONの形式で公開するだけはやめてほしいと思いましたけどね。
なんで?
だってこれちゃんと分析する仕組みをちゃんと作れる人しかきちんと読み解けないですよね。
こんなのいっぱい出されても。
まあでもこれ多分おそらくだけど、自動化することを最初から考えられてるから
こういう形式なんじゃないの?APIで叩いてJSONを引っ張ってきてみたいなことなんでしょきっと。
まあそうなんですけど、もうちょっと優しいインターフェースがあってもいいんじゃないかな。
どういうのがあればいいの?
例えば何月から何日までっていう範囲を指定してね。
それで例えば能動的な悪用が行われてるとか、
いうふうなものだけペロペロって出してくれるとかさ。
なるほど。
それは自分で作れって話はわかりますよ。もちろんおっしゃる通りですよ。
それは仕組みとしてやろうと思ったらできることだと思うんですけど、
もっと広く多くの人に見れるようにしてほしいなっていう。
自分では一般の人がこれを見るということは想定してないんだろうねきっとね。
多分専門家が使うとか情報システムのIT部門の方とか、
これを加工できる人が使うとかっていう前提なんだとは思いますけど。
ないしはこれを扱ってSSVCとかを統合している脆弱性管理のソリューションが使うことを
多分想定してるんじゃないのかな。
そうですね。
だと思うんですけどね。もうちょっとユーザーフレンドリーというか。
なんていうんですかね。
なるほどね。それはだからトレードオフはあるよね。
マシンフレンドリーの方が多分取り扱いはしやすいので。
しやすいしやすい。
今は多分そっちに一旦フォーカスして、
人が見るようなインターフェースは用意してないし、
とりあえず一旦置いておくっていうのは、
どうなんだろう。リソース面とか優先順位の問題でそうしてるんじゃないの。
多分そうだと思います。
余力があったらもしかしたらそういうインターフェース作ってくれるかもしれないし。
その辺は今後に期待したいな。
そうだね。だからこれがそのまま、さっきの看護さんの話じゃないけど、
ちゃんとその継続してくれないと意味がないので。
やめまーすってなるかもしれないですもんね。
安定してリアルタイムに。
KEVもあれも本当に悪用があって1日2日とかの結構なスピード感でやってくれてるから価値が高いわけで。
1週間も2週間も経ってもう散々悪用されてから乗っかっても何の意味もないわけじゃん。
54:04
これもそういう意味でタイムリーにSSVCのレシジョンの判断ができるようなタイミングで出てこないと意味がないので。
そういうような価値のある取り組みとして続けられればいいけど、
ちょっとこの辺の唐突に出てきたからやってる体制がどうなってるか全然わかんない。
確かに。しかも出しましたでいうのがなぜかリンクトインが。
公式のアナウンスにないからそういう意味ではまだ補助的な位置づけっていうかパイロットなのかな。
そんな感じはしなくもないですね。
GitHubではとりあえず先に公開だけしてっていう感じでも見えなくもない。
ファブリックベータじゃないですけど。
いろいろフィードバックを受けてこれから変えていくってことなのかな。
そんなようにも見えますね。
でもすごく注目すべき取り組みの一つではあるよね。
また新しい動きが始まったなと。
ちょっと継続していぼっち案件ですね。
そうですね。
ありがとうございます。
ということで今日もセキュリティのお話を3つしてきたんですけれども、
最後におすすめのあれなんですが、
今日おすすめするのはですね、僕もめぎさんもカンゴさんも食べたことのあるものを紹介しようと思ってます。
何だろう。
以前におたふくだのブルドックだのを言ってソースの紹介したと思うんです。
1回か2回そんなの、このあれでも紹介したような気がしますね。
そうなんですよね。
この間お二人に僕の小屋に来ていただいて。
タコパで。
そう、タコパで来ていただいたじゃないですか。
僕ね、たぶんここで紹介してなかったと思うんですけど、
たこ焼きに一番かけておいしいものって辛そうで辛くないラー油だと思ってて。
あれおいしかったよね。
おいしかったでしょ、たこ焼きにのせるの。
初めて食べたけど。
そう、だから僕ね、家でたこ焼きするときとかは、
基本的にはそのラー油、辛そうで辛くない桃屋の有名なやつありますけれども、
それをかけるのが好きすぎてソースを使わないっていう。
あーなるほど。
そればっかりで食べてまうっていうようなことをしてたんですけど、
この間二人来たときに新しく買ってきた、
これもタフクのソースなんですけど、
だしと醤油のたこ焼きソースっていうやつを新しく買って使ってみたら、
そのラー油じゃなくてほとんど僕これで食べちゃったんですよね。
あのソースめちゃくちゃうまかったよね。
俺も初めて食べたけど。
いいですよね、このだしと醤油のたこ焼きソースって。
何の液体やねんみたいな名前してません?
なんかだしと醤油とソースみたいな感じもちょっとするじゃないですか。
わかんない。
今の歌は何の歌かわからんかった?
全然わかんなかった。
うるせえな、ヘアとワイシャツと私じゃないですか。
わかんねえ。
ほんまですか?
なんか滑舌は悪いし歌も下手みたいなキャラになってきたぞこれ。
57:04
これかつおだしと昆布だしと焼きあごだしの三つのだしと醤油が入っているという。
味自体はすごいコクのあるというか。
食べやすいソースでしたよね。
俺初めて食べたけどめちゃくちゃおいしかったこれ。
これちょっと二人の反応もよかったし、
僕自身も普段これが一番やと思った食べ方を上回ってきた感じの衝撃があったんで、
ちょっと紹介をさせていただいたということでございますね。
ぜひぜひ。
たこ焼きにはこれ。
これでもたこ焼き以外にもあったりするのかな?
どうですかね。
お好み焼きには少なくとも合うんじゃない?
あーお好み焼きね。
そういう他の使い道も開拓してよ。
僕が?
僕がですか?
この間のソースまだあるでしょ?
確かに確かに。
とんぺい焼きとかもいいと思いますよ。
だってあれたこ焼きだけで使うの?
焼きそばとかにも使うかもしれない。
焼きそばも合うかもしれないな。
だからそういう他の使い道を開拓する余地がありそうじゃない?
オタフクのサイトでたこ焼きスタジアムっていうレシピとか
食べ方みたいなのを紹介してるサイトがあるんですよ。
そこにはいろんなたこ焼きを卵焼き機で作ってみようとか。
それはたこ焼きのバリエーションってことか。
そうですね。
ソースのバリエーションはないわけ?
使い道のソースのバリエーション。
使い道のバリエーションは
ただ名前がたこ焼きソースって言うても出るからな。
そうだけどさ。
自己否定みたいになっちゃうからやらないのちゃうんかな。
そうかそうか、なるほどな。
ソースかけて美味しい食べ物って何やろう。
たこ焼きと焼きそばとお好み焼き。
でも人によったら目玉焼きか。
目玉焼きにソースかけた人いますよね。
そうね。
だって俺も醤油派だけどさ。
これだって出汁と醤油で醤油も入ってるんだよ。
確かに確かに。
どっちもカバー。
色々やってみて。
そうですね。
確かに。
それでもしこれええんちゃうかみたいなものがあったら。
でも今日そのチャンスの日やったわ。
何か食べた?
今日焼きそばやって。
使えなかったのに。
ソース使ってくださいよ。
でも暑いやん最近ちょっと。
ちょっとね。
だから塩焼きそばにしてもうた。
なるほど。
そっかそっか塩焼きそばね。
ちょっとね。
ソースって家で一回買うとゼロにならへんので。
思い出したら見かけたら買っていただくぐらいでいいかなと思うんですけども。
もしよかったら試していただければなと思います。
はい。
ということで今回は以上です。
また次回のお楽しみです。
バイバイ。
バイバイ。
