00:00
こんばんは、Replay.fm第39回です。
こんばんは。
はい。
はい。お疲れですか?
首が痛いです。
首が痛い?
首が痛い。
なんで?
全身痛い。昨日…
全身痛い?
うん。追い込んだ。
昨日、パンクバンドのライブに行ってきまして。
うん。あ、そっちか。
あ、そうだったね、そういえばね。
6月10日、ロットンの日っていうね、ロットングラフィティっていう神バンドのライブなんですけど。
あー、なるほどね。
そう、京都のバンドで、毎年6月10日は京都の箱でめちゃくちゃなライブをする。
めちゃくちゃなライブっていうか。
えー。
そう、めちゃくちゃに、なんか、なんかね、そう。
まあ、ロットンはめちゃくちゃだもんね、そもそもね。
そう、基本めちゃくちゃだから。
うん。
あの、その…
えー。
毎年この日のライブはやっぱ気合の入り方というか、まあ特別感があるから。
なるほどね。えー。
めちゃくちゃ楽しかった。
京都のバンドなんだね。
うん、京都のバンド。
京都のバンド2つ目だな、これで知ってるの。
ヤバティも京都。
厳密には。
うーん、京都、まあ、いや、でも、なんか一応レペゼン京都。
2人、2人京都、1人大阪みたいな感じじゃなかった?ヤバティって。
まあ地元で言うとバラバラなんだけど、大学サークルで多分京都だったんじゃないかなって。
えー。
わからん、私の中では京都のバンドと言えばなんかヤバい、あー、夜の本気ダンスなんだけど。
あー、そっちか、そっちなんだ。
天秤だ。
天秤も京都なんだ。
そうです、天秤も京都。
多分天秤が一番もう走りじゃないかな、京都バンド。
あー。
レペゼン京都、で、ロットン、そうだね、夜の本気ダンス。
岡崎体育とかも京都だね。
えー、おもろいな。
うん。
いやー、夜ダンはもうなんかさ、もう毎回京都のバンドってなんか残っとるやん。
そうだね、うんうん。
うん。
いいよねー、最近の。
えー、大阪芸大なんだね、小山。
ヤバティ。
あー、大阪か。
うん。
えっと、えっと、宇治か、宇治出身。
うん。で、別になんかサークル、まあいいや。
あー、クルリ京都だ。
あ、マジで?
うん。
クルリ京都なんだ。
確かに、京都で毎年フェスやってるわ、そういうの。
えー、京都感ないよな、クルリって。
そうね、クルリ全然詳しくないけど、でも京都感ないのは分かる。
なんかすごく関東っぽい感じがするよ、クルリ。
おしゃれてる。
何がって感じ。
ねえ。
あともう一個なんか、最近新しめのバンドでレペゼン京都知るバンドがあったけど忘れた。
いいや。
ほうほうほう。
ちょっとバンドの話しちゃうと趣旨がブレてるんで。
いやー、バンドの話が聞きたい人は何か、はい、こっそり教えてください。
全然、突撃するわ。
うん。
ぜひ、ぜひ話しましょうって感じですけど。
じゃあ、上から順に行きますか。
やりましょう。
暗号化とMACの理解
はい、一つ目、暗号化してからMACがなぜ重要か。
セキュリティの基本原則を理解するっていう記事でございますが、どう説明していくのがいいのかな。
なんか、MACってメッセージオーセンティケーションコードなんだけど、
ちょっと待ってね。
なんか、ある技術ブログを見ていたら暗号理論に引いてよ。
これは学べば学ぶほど退屈な代物だ。
ただ、HMACしてから暗号化と、暗号化してからHMACの違いがわからないようでは、
到底エースセキュリティエンジニアとは言えないっていう自分が、
自分じゃないよな。
三分あるよな。
こんな一文を見かけましたっていうところから始まる記事なんですが、
違いがすぐに出てこなかったので簡単にまとめた記事ですよっていう記事でございます。
で、そのままなんだけど、
暗号化したものにMACを付けるのか、
MACを付けたもの、MACを付けたメッセージを暗号化するのかっていうのに
大きな違いがあるよっていう話。
引いたことで言うと、暗号化ってそれなりに重め、
いろんな意味で重めの処理なので、暗号文に対してMACを付けるっていうのが
ベターなケースが多いんじゃないのっていう話ですね。
これね、頑張って読んだんだけど、分かんなくて聞こうと思ってたんだけど、今理解したわ。
複合処理をすること自体がリスクがあるんだ。
っていうのもあるし、そもそも複合処理って計算コストもMACの検証よりも高いし。
ドス攻撃にもなるのか。
まともなあれだったらほぼないと思うけど、
例えばね、いろんな意味でも重いっていうのはそういう意味で。
パディングオラクル攻撃、聞いたことあるけど多分全く覚えてないな。
プードルとか呼ばれてたやつとかが有名なやつかな。
プードルそうだっけ?プードルって書いててね、これね。
プードル、懐かしいな。
違うな、プードルってパディングオラクルだっけ?
そうだよね、パディングオラクルだよね。
プードルのPOがパディングオラクルだからね。
平文ね。
3回に1回ぐらいあるな、これ。
誰もが通る道だから。
ありがとうございます。
俺平文知ってるはずなのに平文って読んじゃった。
引数を因数とかね、誰もが通る道だから。
あるかも。首タイトでやりがち。
首のせいにしないと欲しいけどね、まりな。
これ2つ目がね、まだ分かんない。
エンクルベット&マックで平文のマック値と暗号化した文章別々で独立しておくって、暗号文を複合して平文のマック値。
要はMACは平文に対してのものなんだけど、
暗号文とMACを独立して送るっていうか、一緒に送るんだけど、
要はMACと暗号文には直接の関わりがない状態で送るっていう話だね。
だから複合しないとMACの検証ができない。
そうだね。じゃあ複合するステップが必須なのが問題なのか。
いずれにせよね。
このプログラムだと攻撃者暗号文の一部を別の値に変更してもMACの検証は成功してしまう可能性があります。
これではMCAの役割を十分に果たせませんっていうのが理解できてない。
どういうパターンで成功してしまう可能性があるんだろうっていうのが分かってない。
うーんと、そうだな。
例えばなんだけど、
ハッシュのレンクスエクステンションアタックっていうのがあって、
草のCTFとかでやんなかった?これ。
覚えてねー。何年前の草のCTFさえいいんだろう。
あるのよ、こういうのが。
で、割とお手軽に異なるメッセージから同じハッシュ値を生成するみたいな、そういう攻撃だったはずなんだけど。
なんかあの、一回やったSH-1かなんかの衝突とはまた別の話?
SH-1の衝突とは基本的には別の話なんだけど、
でも遠からずなのかな。
なので、要は同じそのMACが生成できる暗号群っていうのを作り得るよねっていうのがここで言ってることで、
ただあんまりこれに関してはそこまで個人的には現実味ないなと思っていて、
複合できて、かつメッセージオーセンティケーションコードとして成立する、
メッセージオーセンティケーションコードの方も成立するみたいなのはかなり難易度高いと思うので、
理論上はあり得るよねとは思うし。
どっちかっていうと複合必須の部分は方式1と共通の問題点としてあるし、
これも原理上はあるけど、現実のユースケースでどれくらい刺さるかは可能性は高くなさそうって解釈。
あとはHMACが冒頭で言及されてるのに引っ張られすぎて、
ハッシュを前提に今話しちゃったけど、別にMACってハッシュ、HMACだけじゃないので、
MACの方式によってはそういうのが起こりやすいものとかもなくはないのかもしれないね。
ちょっと私も言うほどこの暗号理論に非出ているわけではないので、
ちょっと拙い説明で申し訳ないんだけど、
でも言いたいことはめっちゃ分かるというか、基礎にあるものだし、
なんて言ったらいいんだろうな、
割とベースにあるというか、
何だろうな、論理学的な安全性みたいな、
そういうところの話なんだと思うんだよね。
この大元の記事で言いたいこと、多分そういうことなんじゃないかなと思っていて。
なるほど。
こっちの記事読んでなかったな。
そっちの記事俺も読んでないや。
すごいハートの数や。
ちょっと前に形式手法の基地とかもこれでこのPodcastで紹介したかどうか忘れちゃったけど、
あれとかも割とそういう話なのかなと思っていて。
形式手法。
これもだから数学的にシステム設計の動作を担保できるようにしようよみたいなやり方。
なるほどね。
2回勉強になりましたね。
なるほど。
これは全然知らなかったんで、到底セキュリティエンジニアがなかった状態から。
別に知らなくてよくて、知らなくていいっていうか、むしろ暗記ものじゃないのでこういうのって。
なるほどね、そういうことか。
だから、なんて言ったらいいんだろう。
この両者のうちどっちが処理として望ましいですかって聞かれたときに、
これはこういう理由でこっちのほうがいいですねって答えられるかどうかを問われてると思った方が良くて。
なるほど。
なるほどね。
知ってる知らないの話では正直。
MSEが何ぞやみたいな話とか、そういうところからになっちゃうとちょっとしんどいんだけど。
こういうのスルスルっと頭に入って。
いや俺もね正直別にスルスルって出ないよこれ。
出ないよ。
そうか、なるほど。ちょっと元気で。
パッティングオラクルの話出て、確かになって思ったぐらいだし正直。
スッと即答できるかというとちょっと難しいなって思うよ。
なるほどね。
こうして読んで説明ができるし、別にちゃんと考えれば同じようなあれが出てくるとは思うんだけど、何とも言えないです。
了解です。
とりあえずなんでこれピックしたかっていうと地味だけどこういうのちゃんと規定に言語化してそのような、なるほどねなんかそういうのが大事なんだで、
特に意味のない腹落ちの仕方をせずにこうしてちゃんと言語化して記事にしてっていうのは偉いなと思って、いい記事だなと思って持ってきました。
間違いない、それは同意だわ。なんかこういう取り組みの積み重ねてなんか大事だよね、個人目線。成長していきたいってなった時に。
こういうの目にすればさ、我々も思い出すじゃん。その読んだ人がさ思い出すじゃんね。
そうだね。ありがとうございます。
そんな感じです。またこんな記事見つけたら持ってきます。
ぜひ。
セキュアAIプログラミング
次がセキュアAIバイブコーディングwithルールファイルwithブログの記事ですね。
これちょっとごめん実は読んでないんだけどサマリしか読んでなくて、サマリだけで十分なんか中々想像できたから読んでないんだけど、
人が読めてLLMもちゃんと解釈できてみたいなガイドライン整備ができるといいなみたいなことを読んで思いました。
なんかあれか、その前に記事のサマリだけでもさらっと読むと、AI支援のプログラミングにおけるセキュリティリスクとそれに対処するためのルールファイルの重要性について紹介してる記事ですよっていう話。
で、LLMの生成するコードはデフォルトで安全ではないので、バイブコーディングにおいては開発者が生成コードの詳細から離れることでリスクが増加する。
ちょっとなんか固い日本語だな。まあいいけど。
ルールファイルはAIコーディングアシスタントへの標準的なガイダンスを提供する新しいパターンですよ。
ルールファイルを使用することで生成コードの脆弱性を検証させることができるよ。
セキュリティに特化したルールファイルのオープンソース提供が行われてるよっていう話らしいです。
なんか遥か昔にほっといたらAPIトークンハードコードしちゃうみたいな。
あなたはセキュリティのプロフェッショナルとして絶対にシークレットをハードコードするコードを進めることはありませんって。
そうだね。
プロンプトに入れとくみたいな話があったね。
とりあえずそれをちゃんとやろうって話かなって。
結構これ系の記事たくさんあるけど、単純にこのOSSになってるやつありがたいってシンプルにめちゃくちゃ思いました。
全部見てないんだけど、多分汎用的なやつじゃなくて割と言語ごとに提供してくれてて。
僕とかあとNode.jsのやつがあったんで、なんか読んでみたんだけど。
めっちゃ読める分量なんで、ぜひ読んでみて欲しいというか、
セキュリティルールの重要性
真似できるとか真似した方がいいんじゃないかなというか、僕はした仕事で真似しようと思ったのと、
実際に読んでみておもろかったのは、ルールから逆にこういうことをするんだっていうのを知ったんだけど、
セキュアアンスコプレフィックスをつけてセキュアってことにしないでみたいなルールが書いてあって、
そんなことをするんだみたいなとこだっけな。
フォーカスオンメイキングエプリメーションインファレントリーセイクラザーズ
リメイニングメソッドウィズセキュアプレフィックスみたいなのがあったりとか、
それはちょっとおもろいって感じだけど、前取り上げたタイプスカッティングみたいなやつも結構丁寧な指示が書いてあって、
パッケージ参照するときは本当に存在するものかどうかっていうのを慎重に検討した上で、
コード生成してみたいなのとか、またマイク生成するとベースクリエインジェクションとかCSRFみたいなもんとかはCWEのやつで引っ張ってきて、
一緒に細かい指示も渡してみたいなことを書いてあってて、かなり参考になるなみたいな。
しかもこれクライム向けとウィンドサーフと多分一通りクロードとみたいなのが書いてあって、
今見て気づいたけど、フォーマットは書いてある内容は流石に、でもちょっと微妙に違うな。
クロードとかはセキュリティベストプラクティスを最初の方にやってCWEの話は後半にしてるけど、
クライムルールとかは逆の順序にしたり、あとエレメントとしてのインタラクションをちょっと変えたりしてるから、
おもしろいね。
これ何でだろうね。
エージェント、これの理由知りてえな。記事には多分書いてなかったと思うから。
多分最適化した結果なんだけど、ぜひ真似してくださいって思いました。
僕は真似しようかなと思ってます。
これって何で食わせるのが最適化になるんだろうね。
何で食わせるっていうのは。
フラインルールとかで置いておくのがいいのかな。
使ってるツール依存だと思うね。
クラインだったらクラインルールズは、
この辺多分ちょっと議論の間違って社内でも話したことあるんだけど、
今は標準化されてないからもうケースバイケースなんですよ。
クラインはクラインルールズを読むっていう挙動があるから、
クラインしか使わない人はクラインルールズを置くし、
マックロードはクロードって無理なのかな。
ウィンドサーフとか知らないけど、ドットウィンドサーフルールズみたいなのがあって。
何らかのマークダウンにリダイレクトするようなやつを、
それぞれのツールの分だけ置いておくみたいなやつで、
やつも紹介されてたりするよね。
気になったのは、この程度の分量だったらいいけど、
例えばCWE全部カバーしましょうみたいなことをやりだすと、
トークンの消費量えぐいことになりそうだなと思って。
内製MCPサーバーのメリット
だからプロンプトとしては当たるようなものを、
でもプロンプトとしては当たらない。
でも最終的には何がプロンプトとして当たるのか。
1タスク、多分タスクごとに1回壊せることになるから、
だからよほど膨大じゃなければどうだろう。
現実、その辺のトピックあんま聞いたことないから、
許容できるオーバーヘッドになるんじゃないかなって気はするな。
どうなんだろうね。
でもこの人が読んでパッと読みやすいぐらいの量のものを壊せるんだと、
あんま意味がない。
足りなくない?
どこまで何を担保したいか次第なのかな。
その辺はなんていうか、
個人的には手を動かして模索しなきゃいけないんだろうなって気はする。
何もしなかった時に、もう1から100まで危険な行動を吐き出すわけでは多分ないから、
だからありがちなやつとかをカバーしてくれてるのかな。
そうだね。で、来週の記事かな。
フラットさんの記事で、ちょっと記事のタイトル忘れたけど、
デビンかな、デビンかなんかのやつで。
あれ、今週入れなかったんだけど、今週の記事だっけ。
今週じゃないの。
今週の記事だ。
後で話すのに書いてあるんだけど、
その時に話すけど、
多分ね、あるあるのやらかしみたいなのがあるような気がするんだよね。
こういう実装させるとこういうことしちゃうみたいなのがあって、
そういうのをあるあるをある程度最大公約数取ってルールにしたみたいなのが、
いずれの場合はこれでいいんじゃないっていう1つのケースな気がする。
なるほどね。
だから多分大事なのは、基地の外からインプットできるようなやつはこういうルールでまず走ってみて、
その過程でこんなの吐き出そうみたいなのを見つけたら、
ルールを育てていくみたいなのが必要なんじゃないかなって気はする。
それがどこまで膨らむかはちょっとやってみないと分からないけど、どうなんでしょうね。
どうなんですかね。
人間が認知できないレベルのルールも認知できるっていうのは生成側の強みな気がするから、
そこはセキュリティ、セキュアコーディングの観点ではもしかしたら優位性があるのかな、人間がやるよりも。
あとはソフトエンジニアごとによる知識のグラデーションみたいなのもある程度は生まれるとかもあったりするのかもしれない。
いやー。
もしくは書くとき、生成するときはありがちなやつだけ抑えて、レビューをさせる生成側のルールをめちゃくちゃ分厚くするっていうアプローチももしかしたらあるかも。
どこまでいけんのかちょっと分かるんで、動かしてみると分からんなって思うけど。
そうねー。
いやー、うーん、はい。
なんか、うーん、まあ別に全知全能の何かをこう生み出してるわけじゃないから。
そうだね。
まあそんなもんだよねっていう割り切りは一定必要なんだろうけど。
うーん、割り切りも必要だし、あとは1,2年ぐらいは進化を見守るのはどこまでいけんのかみたいなところ。
うーん、はい。
はい。じゃあ次いきますか。
はい。えー、カーソルを導入だけじゃなく活用まで、メルカリ2000人展開のリアル。
なんかカーソルミートアップ東京ですね、カーソルミートアップ東京でやってた発表のスライドでございます。
うん。
なんかざっと見てただけなんだけど、まあ直近2ヶ月とかの動きだと思うんだけど、多分なんかもうちょっとかかりそうだなーって思いながら辞めてったから。
うーん。
多分ほぼ直近2ヶ月の動きのような気がしていて、そこでからエグいなと思ってビビってるっていうのがまず1つ。
そうだね。内容としてはカーソルデビンの導入と、そのための多分社内のレールとか準備とかをババーっと迫速でやりつつ、
MCPサーバーもリスクを抑えるために耐性いっぱいしてとか、なんだっけこれだっけな、その強制、あ、コーディング禁止令か。
あ、そうそうそう。
これなんかブログも書いてたよね、メルカリ。
あった、あった気がする。メルペイかな?
うん。
某社のCTOのやつを参考にって言って。
うん。
その某社のCTO実は僕の、僕は昔メンターしたことあるんですけど。
僕も大変お世話になってましたけど。
あ、そうなんだ、そうなんだ。いいね。
え、そうなの?知らなかった。
え、だって普通に被ってるでしょ。
被ってはいると思う。
うん。
なんかいろいろなんか直してもらった記憶があるよ。
あ、そうなんだ、いい話。
ウェブ2のあれをいろいろ。
あ、じゃあ絡み合うのか、確かに確かに。
そう、名前捨てる必要ないですよ、カズタカ君に。
なんか別に、そうそうそう、なんか別に触れちゃいけないみたいになって。
いや、なんか、それ記事の扱いかな、ちょっと触れちゃいけない人みたいな。
そうそうそう。
名前出したらいいのに、なんか。
そうそうそう。
特に理由ないと思うんだけど。
理由ないと思いたいんだけど、まあまあそれはいいんですけど。
そうね、あの、禁止引きをやったよみたいな話もありつつって感じですね。
えー、なんかね、すごいね。
うん。
このセキュリティチームが確認済みのMCPサーバーリストみたいな。
これちょっと、もうちょっと詳しく聞きたいなと思って。
内製MCPサーバーは、これはこの下に並んでるのが全部そうってことなのかな。
そうだと思う。
まあ今となってはFigmaとかは公式ができてるし。
Google系はね、たぶん内製中か、あんま公式はなさそうな気がするから。
あー、Slackとかも作ってるな。
いやー、Slackとかね、そんだよな。
オース認証、まあまあまあ、なんかそう。
なんかちょっと僕作ったことないんで、間違ってたらすまんやけど、
社内の人と話した感じ曰く、別に作ろうと思えばそんな難しいもんじゃないから、
仕様自体めっちゃ薄いから。
MCPのその仕様自体薄いのはそれは分かるんだけどさ、
なんかSlackとか、そもそもAPIが割としんどいじゃん。
あー、そうかな。
そんなことないかな。
今ね、僕Slack API大臣を名乗ってるんでちょっと。
あ、そうなんだ。じゃあしんどくないんだね。
API大臣のバイアスがかかる。
よく整ってるほうな気はする。
あー、Notionよりは。
ん?
Notionよりは。
まあNotionよりはそうだね。
NotionはなんかAPIがつらいっていうか、Notionの仕様が。
まあAPIじゃないんだよね。
ブロックがね。
まあでもなんかその、たぶん内製MCPサーバー作るときはその、
有利というかいいポイントはその、
自分たちが必要な機能だけ込み込めばいいから、
そういう意味では楽な気はするんだよね。
うんうん。
普通にミニマムで作って出して、
なんか後からちょっとずつアップデートしていくとかね、
全然いいわけだしね。
で、むしろなんか公式のやつで、
その全APIカバレッジ高いものとかを使うってなっちゃうと、
その権限、なんか手足を奪いたいときにたぶん、
ひもづくSlackAppとかの手足を縛るしかないとか、
オース認証だったらそもそもたぶんそれができなくなっちゃうから、
うんうんうん。
そういう意味でもそこには、
内製の有利性はもしかしたらあるのかもしんない。
うんうん。
なるほどね。
いやー、洋をやるなあ。
いや洋をやってるよ。
これなんか、これしっかり、
なんかフリーさんの記事とかしっかり読んで思うけど、
なんか生成I型、なんていうか、
なんか、ぼやきとかじゃないんですけど、
そのでかい会社は有利だなって、
今の時点で。
逆に?逆に?
うん、逆に。
いやなんかこういうのに投資する体力があるかどうかって結構大事な気がしていて、
あー。
まぁわかんないけど、
そのー、
まぁ弊社しかりその中小スタートアップというか、
なんかまずサバイブしなきゃいけないみたいな会社って全然いっぱいあると思うんだけど、
うんうん。
うちは50人ぐらいかな、今だけど、
20人ぐらいの会社とか10人。
まぁでもそこまでちっちゃかったら逆にいいのかな。
わかんないけど、
なんかその、なんだろうな、
生成AIの利用と企業戦略
だから生成I周りを活用することにめちゃくちゃでかいリターンがあるから、
じゃあ明日から一人、あなたは生成I研究してって言って、
その分開発が遅くなるのはOKみたいな意思決定ができる動画って結構、
なんか事業的な余力もそうだし、
でかければでかいほどその意思決定はしやすいんじゃないかなって、
ちょっとぼんやり思ってるっていう感じかな。
うーん。
あとなんかでかいと、なんだろうな、
投資対リターン、なんかリターンが結構見えすいてるはいいすいかもしれないけど、
なんか期待値がでかい気がするんだよな。
2000人でしょ、2000人の生産性1対1倍になるってなったら、
まぁ全然バチッと張り付けていいよねみたいな意思決定できそうな気がするし。
うーん。
でも一方、2000人分投資しないといけないっていう。
まぁ確かに。
金銭的な話とかってことだよね。
うーん。
まぁまぁそれ、まぁそうね、それは確かに。
うーん。
まぁそれで、だからそれで言うとそれ含め結構大胆な意思決定であるよな、なんか。
そう、だからそう思ったの。
100人で試して2000人にしましたとかじゃなくて、
正確な解答の重要性
まぁもしかしたら内部的にはそういうステップがあったのかもしれんが、
なるほどね、まぁ確かに確かに。
それはそうだね。
そうなんです。
うーん。
そうなんです。
もうちょっとかかるかなって思ってたのが、ほんと率直な感想。
いやー、資本は、資本は大事やな。
うーん。
うん。
まぁまぁまぁ。
このなー、もうちょっと色々成熟してきたら、
なんか、まぁでも色々レール整えるの頑張らなきゃいけないのかなー。
うーん。
NCPサーバーとかちょっとしん、権限周りとかなんかもうちょっとサービス側で、
おっといい感じになってって思っちゃうんだけど、
まぁでも、その、セキュリティ観点で言うと、その、なんていうか、当然EDRとかも入ってるし。
あーなるほどね。
うーん。
あー、装置が整ってるみたいな話もありそうだな。
うーん。
それは多分あって。
うんうんうん。
確かに。
確かにねー。
確かに。
うーん。
一体その何かが起きても、まぁまぁ何とか見つけられそうだよねっていう前提はあるんじゃないかなと。
確かに、その観点で言ってた。
うーん。
まぁあとはなんかその、なんか事業特性とか当然あると思っていて。
うーん。
そうね。
そうね。
事業特性も当然あるし、あとは、そのね、まぁ下地の話で言うと、なんか、まぁメルカリって基本、本番環境触れないので普通は。
うんうんうん。
うーん。
どこまで言っても本番までは行かないように見たら前提でやれるって話だよね。
そうそうそうそう。
だからなんか散々いろんなところで、なんかこのポッドキャストでも話してるけど、
基礎的な部分がやっぱ言われてるか言われてないかで、なんか変わってくるんだろうね。
うんうん。
価値ができるかどうかが。
それでいくと、まぁ下地が整ってたっていうのは一定あると思うなぁ。
うーん。
だからこそこの動きができたんだろうし。
確かに。
うーん。
確かにザムライ。
いやぁ見習っていきたいなぁ。
うーん。
うーん。
まぁでもそれで言うと確かにその、ちょっとこの話が長くなっちゃうけど、
その大きいところの方がなんか有利だよねっていうのは一定あるかもね。
うーん。
その小さいところって、なんか結構その基礎的な部分が、まぁ大きいところに対して、
まぁ多少有力やってる部分って、まぁなんていうかありがちというか。
うーん。
要は今までのそのそこ、そういう分野への投資のその積み重ねがあったからこそできてるっていう部分はあって、
じゃあ今から小さいところがそこに追いつこうと思ったときに、その基礎的な部分への投資、もうセットでついてくるっていう形になるから。
うーん。
それはでかいよねっていう感じになる。
確かに。
でかいね。
そうするとだから、そうあのなんていうかROIがどうなのっていう話は当然出てきちゃうし。
うーん。
だから多分発想の転換が必要で、なんていうか。
まぁ遅から早かれ、そのLLMとか生成AI関係ない部分でも、その遅から早かれ通る部分っていうのがあるから、
そこはなんか、その生成AIの活用みたいなところからは切り離して、その投資に対しての効果っていうのを測らないといけないんだよみたいな。
そうね。
なんか発想の転換が本当は必要なのかもね。
まぁちょっと、そればっかりが原因とも思わないんだけど、いろいろその組織によって理由は様々あると思うから。
うん。
なんか、そうだね、それはマジで同意だし。
だからなんかいじるとしたら優先度かなっていうのは結構思ってる。
うんうんうんうん。
その。
まぁね、ただただその、うーん。
なんか本来やったら数年かけて積み上げていく分を、そのじゃあ、なんていうか早くこういうの活用したいから、なんか。
あーまぁ。
その、1年でやってよみたいな。
話になった時に、その、やれるかいっていうのをちょっとシンプルに思うし。
数年単位の成果とかだとそうだね。
うーん。
まぁでもそこはなんか、ケースはいケースというか、結構いろんなパターンがありそうだな。
なんかど、今時点でどれぐらい荒れてるかとかもあると思うし。
うんうんうんうん。
で、だからそこでその、まぁそういうの一旦置いといてもいいから、とりあえずこっちに舵を切ろうよっていうのがやれるかどうかは、その。
うーん。
事業の属性とかが上がってくる部分だと思う。
リスクをどれぐらいのめるかは、会社主で話してやる。
うーん。
会社というか事業というか。
まぁお金たち、まぁいろんな変数を加味した上で。
うーん。
そうだねー。
そう。
はい。
はい。
そうですか。
そんな感じでございます。
次。
ほい。
えーと、あー次全然軽い記事だね。
TLSインスペクショナルマイクロソフトインターネットアクセスっていう、マイクロソフトコミュニティハブの記事です。
うーん。
えーと、ラベルで言うとネットワークかつ、エンドポイントみたいなラベルだったっけ?
あ、エンドポイントセキュリティっていうラベルあるね。
あ、それかな、じゃあ。
うんうん。
うん。
えーと、マイクロソフトのエッジを通して通信させることでTLSを解いてみることができるよっていう、まぁ製品っていうかなんか。
おー。
なんだろう、オプションなんかな、わからんけど。
うんうんうん。
機能って言えばいいのかな、きっとね。
うんうん。
の話ですね。
エントライヒートかなんか、クロームプレミアム的なやつがあんのかもね。
うーん。
わかんない。
エッジってあれだよね、あ、エッジってそっちか、ごめん。
あ、ごめん、うんうん。
そういうことか。
ネットワークのエッジ。
あー、理解してました。
で、えーと、アプローチ自体は、まあ要はこのTLSを解いて中に見ないとなんもわからんよねみたいな。
このアプローチ自体は、まあ特に新しいものじゃないかなと思うんだけど。
このMSがインターネットからアクセスできるエッジを提供してくれるのちょっと面白いなと思って持ってきた感じ。
で、他社でもこういうのがあんのかどうかちょっとわからないんだけど、なんかどうなんだろうね。
うーん、全然わからんな。
ね。
解くのは、まあそれにいろいろ、まあ読み取っていろいろしたいって話だよね。
いろいろ、ちょっと解像度過ぎていろいろって言ってた。
ああいうほうが、だから暗号化されてると中身なんもわからんから、なんか悪意のある通信かどうかもわからんよねみたいな話。
うーん、まあさすがにオプトインだと思うけど。
エントラ、エントラ、エントラ、エントラって製品なのかな、ちょっとイメージわかってない。
エントラIDとエントラは違うのかな。
エントラIDとエントラインターネットアクセスっていうのがあるんだよね。
ああ、エントラIDとインターネット、そうだね、それが二つをエントラって隠れるんだ。
なんかわかんないけど、キャスビーみたいな感じなんじゃないかな。
まあマイクロソフトエントラっていう製品ページがあるわ。
はいはいはいはいはい。
エントラIDとエントラスイートっていう。
へー、なるほどね、いろいろあるな。
はい、本当はマイクロソフトエントラインターネットアクセス。
じゃあこの辺のあれかもね、プライベートアクセス。
はー、勉強になるわ。
なるほど。
ちょっとわからんね。何ができるのか全部はよくわかんないんだけど、まあそんな記事でした。
コープレートIT目線としては何、コープレートITっていうか、まあ個別的っていうか。
何が嬉しいのかしら、変なサイトと。
あー、なるほどね。
というかなんか別に常にVPNを通さなくてもいいっていうのが一つじゃない。
要はVPNは通せばさ、なんか別に、TLSの集団を通らないと出らんないようにするとかで。
別にポートとかも制約入れちゃってさ。
ポートとかプロトコルの制約入れちゃって。
リスク管理の進化
で、HDBSしか通信できません、TLSは解いてますみたいな。
まあ比較的簡単にできると思うんだけど。
なるほどね。
VPNなしでもMSの提供してる経路で、実質VPNだと思うんだけどこれ多分、とはいえ。
その辺の複雑な構成をせんでも、勝手にそこで解いて中身を見ることができるようになるよっていうのが多分一つ嬉しいポイントなんじゃないかな。
なるほどね。で、その上で、空き時中だとDLPを使いたいとかウェブフィルタリングしたりとか、マークにある通信をブロックしたりとか。
なるほどね。確かに確かに。理解しました。
例えばマルウェアをダウンロードしてくる経路がTLSで暗号化されてたときに、通信そのものをブロックすることができない。
要はローカルにファイルが置かれた段階で初めて検知するみたいな形になっちゃうけど、通信そのものをブロックできるようになるケースもあるよね。
一番最初の一文が根拠というか、87%のマークにある通信はもう暗号化されちゃってるから、解かないとわからないよねっていう。
まあ確かにね。理解しました。
なんなら悪意のあるサイトとかじゃなくても、ドロップボックス系のサイトとかだったら全然わからないもんね。見るしかないもんね。
そうだね。
ありがとうございます。
今日は序盤いっぱい読んでもらって。
いやいや、そうそうそうそう。全然それはやって。
お願いします。
次がRSA Conference 2025注目セッション。CISOのリーダーシップ戦略とGRCを徹底解説。
NRAセキュアのブログです。
なんかさらっとしか読んでないんだけど、考え方のトレンドをさらっと把握するには良い感じかなっていう感じで。
なんか別に、これすげえみたいなものがあったわけじゃない。
わかるということになりつつ。
メモで書いてるところとかで言うと。
その上で気になったところで言うと、これどこの話だったっけな。
中書中書。
それはね、そっちは別にどうでもいいや。
こっちね。
エクスポージャー管理、新たなサイバーリスク法というしかない。
そうそうそうそう。
攻撃対象領域がめっちゃ増えてて、従来の脆弱性管理が厳しいよねっていう話があり。
一般的な組織の場合、平均83種のセキュリティツールを用いて、6から8つのチームが断片的にリスクを把握しているため、統合的なリスクの把握が困難なケースが多くあるよっていう話。
現代はAIの登場によりリスクの因果関係や優先度をリアルタイムに判断する時代なので、統合予測自律の3軸でリスク管理を最適化する戦略的アプローチとしてエクスポージャーマネジメントが紹介されたよっていう話。
ちょうちん記事っぽくなってるんだけど、最終的にエージェンティックAIによってリスクの把握から対応までを充実的に実行可能とする構想が提示された。ちょうちんじゃないか。特定製品の話じゃないよね。
セキュリティツールの課題
発表自体はちょうちんじゃないですか。
というところで、このセキュリティツールを用いて、83種のセキュリティツールを用いて、6から8つのチームが断片的にリスクを把握しているためっていうのは、これ結構サービス特性にもよると思うんだけど、
セキュリティ以外の領域も合わせるとさらに広がるよなと思っていて、そうなんですよみたいなことを考えていて。行き着く先ってエンタープライズリスクマネジメントなんだなーみたいなことは。
これ書いてあることは同意できるんだけど、それができないから困ってるじゃんって気持ちになっちゃうんだよな。AIでどうにか。
まあ未来の話だからね。
まあまあまあ確かに。めちゃくちゃさすに考えてるんだけどさ、コーパイティのタスクをやってるとしみじみ思うんだけど、
SaaS時代でありつつ、SaaS間のインテグレーションは基本めちゃくちゃ弱いというか。
うん、そうだね。
強いことが競争価値になるぐらいデフォルトの価値ではないみたいな部分がある中で、いろいろ悩みは多い技術ではあるんだけど、
MCPがのきなみどこも対応してくれれば、ここに書いてあるようなやつもわりと有名物答え以上なくなるのかなとかは思わんこともない。
API提供してくれるのが前提だけど、別にプレイライトMCPとかでさ、ブラウザーを操作するみたいな感じになるのかな、そうすると。
ヘッドレスブラウザーってパスキー持てんのかな。
持てんのかな。
MCPサーバーとアイデンティティ管理
あらゆるものがさ、APIないならブラウザでやればいいじゃないって。でもなんかによその印象は必須ねみたいな話になったときにさ。
あらゆるものが邪魔だなって思っちゃうんだよね。
もしくは行くところまで行くと、MCPサーバーを提供してないところが切られる世界とかもなくはない。
それはあると思う。最終的にはそうなると思ってて。
でも今パスキーの話聞いて思ったけど、そうなると多分アイデンティティ管理が結構次の悩みの種になるだろうね。
まあでもノンヒューマンアイデンティティの話はさ、ちょうど盛り上がってきてるわけで。
盛り上がってるけど、別にこうすればいいみたいなんてあんまりないよね。僕は認識してないなと。
MCP向けにはOIDCベースの認証をこうしようよみたいなアイディアがどっかで上がってて。
ああそうなんだ。
OIDCだとオースとか忘れたけど。
そこの対応でまたグラデーションデストでやだな。
ただ結局クレデンシャルをどう扱うの問題とかはやっぱあるんだって言って。
そうだね、そうなんだよ。
だからそのアカウントはさ、さっさとアカウントを狙われてる守りましょうみたいな話って草のほど記事で見るけど、
仮にパスキーバーって広まってってなった時にある程度、インフォスティーダーとか入ってなかったら大丈夫だよねとか、
あとあれか、ソーシャルエンジニアリングされなければ大丈夫だよねってなっても、
なんかそのMCPサーバー側とかにAPIトークン通信とか残るんであれば結局そっち側が穴として残るというか、
プロンプトインジェクションのリスク
狙われるトレンドが映るのかなみたいなことを思ったり。
なんならもう今も別にAPIトークンとか狙うみたいなのは上等手段なんだろうけど、
いやだなって気持ちになったって感じですかね。
あとこの統合予測自律みたいなのか、
言ってることずっと変わんない気もすんだよな。
永遠に実現してない気がする。
AI、エージェンティックAIによってそこが埋まるか埋まらんかみたいな。
この因果関係や優先度をリアルタイムに判断するみたいなさ、別に新しい時代じゃないよな。
ずっとそうじゃん。
そうだね。
この因果関係みたいなのさ、ずっとみんなが欲しがってるし、
それを売りにしてるものとかもなかなかなかったと思うんだよな。
なんて言ったらいいんだろう、リネージ?
どうしようにかくわ。
リネージ。
この系統というか、時系列で並べたときにこれが起きて次これがこうなっていって。
別にセキュリティ要項じゃない。
なるほど。
そういうのが把握できたらいいよねみたいな。
割とあらゆるものであると思ってて。
データマネジメントとかがよく一番ありがちなの。
いやー、そうね。
この辺本当にAIがやってくれるならとうとう仕事なくなるか気がするけどな。
いやー、でもさ、もうさ、でもさ。
プロンプトインジェクションの可能性をゼロに上げてるからさ。
そうだ。
そこは預けられんの?って思っちゃうんだけど。
そうだね。いや、間違いない。
多分、ネクストジェネレーションLLMが多分遠からず出てくると思うんだよ。
うーん、そうだね。
なんて言ったらいいんだろう。
あのー、こう、難しいな。
その、えーっと、いやー、むずいな。
ちょっと俺の頭ではなんとも言えないけど、
その、まあ端的に言えばプロンプトとペイロードを分けるっていうのが
何らかの形で実現できるモデルが出てくると思うんだよね。
なんかすごく雑な予言というか予測なんだけど、
LLMでいろんなものを解決したり盛り上がってきてバーってシェアが、
まあ、もう今爆発的に広がってるけど、
まあでも今年ももう後半ですか。
後半、今年後半か来年前半ぐらいにそれを狙ってバカすかにやられて、
で後追いで、まあ今ヤギ足蹴ったようなアプローチなのか別のアプローチなのかわかんないけど、
セキュリティー面も担保したものが出るみたいな流れになるんじゃないかみたいな。
勝手に。
たまに妄想したりしてるわ。
うーん。
まあやられるまでは多分このまま突っ走る気がするんだよな。
うーん。
あとはなんか結構、ことプロンプトインジェクションに関しては、
意外と刺さるプロンプト見つけるの難しいと思っていて、
特にこの、何て言ったらいいんだろうな、
フィードバックが得られる環境だと、
まあ繰り返し繰り返し打ち込んで、
刺さったかな刺さってないかなっていうのを確認していくことができると思うんだけど、
内部で使っているセキュリティーツールに対して、
外から何らかの経路でプロンプトインジェクションを成立させますみたいなのってかなり難しい。
それを少ない試行回数で成功させるって、
まあほぼ無理だと思っていて、
だから可能性ゼロにはできないけど、
まあ思ったより心配するほどでもないのかなとはちょっと思っていたりして。
でもなんか個人的に今はそうなんだけど、
半年後同じかは結構怪しい気がしてて、
今って分かんないけどフェーズ的には、
CCI単体で見た時に使えるじゃんっていうチャットUIから、
まあエージェントって形組み込んじゃえばエージェントか、
なんか価格、サービスもどう組み込むかを模索している中で、
意識せずに動いている場合があるっていうのがあって、
それがどんどん繋がっていくみたいな話もあって、
エージェントプロストコルの話とかもあった時に、
それこそ何て言ったらいいんだろう、
何ホップか減った上でプロンプトに入りますみたいな状況において、
汎用的に刺さるプロンプトインジェクションのペイロードって多分作れないと思うんだよね。
まあそうですね。
分からんよ、どっかでもしかしたら発見されるかもしれない。
キラー、プロンプトインジェクションペイロードみたいなのが
作って生み出されるかもしれんけど、多分無理だと思ってて。
ヘルプデスク詐欺の手法
そうかな、そうか。
だって結構難しいと思うよ。
SQLインジェクションも成立するし、XSSも成立するし、OSコマンドインジェクションも成立するし、
たとえば私?
みたいなバイト列を作ってくださいみたいな。
なんかそういう話じゃん。
まあね、確かにサービス上とかだとそうなのかな。
難しいな。何の経路でもいいけど、
とりあえずNCPサーバーまでたどり着けばC2は確立できそうな気がするんだけど。
まあでもちょっと。
コネクションの維持が結構難しいんじゃないかな、たどり着いたとて。
あー。
まあでも、今時代のNCPの話をするんならば、
普通にローカルに何か落として立ち上げるとかまでいけないのかな。
どうなんだろうね、権限次第だろうね。
オートアップループとかやったら、
まあカールとかは叩けるだろうから、
コマンドは叩けるようになればもうできるんじゃないかな。
ただ、クラインとかやったら、
セーフコマンドだけにするかみたいなコマンドがあるから、
それがどこまで緩くなってるか次第で、
実現性はゼロじゃない気がする。
でもそれをやろうとした時にさ、
定期実行させようと思うと、
今時だと何がいいんだろう。
定期実行ってのは。
常時走ってるプログラムか、
定期実行されるプログラムじゃないと、
C2とのコネクションがさ、
C&Cサーバーとのコネクションが確立できなくない。
命令取りにいけないじゃん。
毎回NCPまでたどり着いて、
ローカルに何か落として何か実行させるのか、
ってなると結構大変じゃない。
毎回何らかインジェクション。
一回プロセス立ち上げて永続化しちゃえば。
一回プロセス立ち上げて永続化って。
僕の開発動画がガバガバの。
再起動したら消えるじゃん。
そうね。
Macのスタートアップ項目に入れようとすると、
たぶん流石に、
ローカルのエージェントの権限上できないと思うんだよな。
インフォスティーラーみたいなやつとか、
どういう原理で動いてるんだ?
その辺が全然わかんないんだよな。
一回インストールされて、集め続けて動き続けてるわけじゃん。
ああいう奴らと同じようなイメージを持ってたんだけど。
ああいう奴らはどうしてんだろうね。
入る経路は最近だと様々あるじゃん。
そうだね。
TikTokとかでクリックフィックスみたいな。
そう、クリックフィックスみたいな。
ああいうのはたぶん管理者権限まで取り入ってるよね。
管理者権限で動かさせてるよね、きっとね。
それとこの前話したカーソルのランアーズルートがちょっと。
ランアーズノードだね。
ランアーズノードか。
あれもだからさ、
ルートで動かすかSUZUで動かすかしないとダメで。
あとは権限昇格の脆弱性を作るとかはワンチャンなくはないと思うけど。
それぐらいじゃない?
たぶん一発で
永続プロセスとして動かそうみたいなことをやろうとすると。
なるほどね。
じゃあ今思いつく範囲では意外と
すごい旅に出てすごい場所にたどり着いた感があるが。
どうなんでしょうね。
はい。
以上です。
ありがとうございます。
でもこれも本当楽しいな。
どうなんでしょうね。
じゃあ次いきますか。
お願いします。
スカッターズスパイダー。
スカッターズスパイダーだと思う。
多分ね脅威グループの名前っぽいんだけど。
スカッターズスパイダー。
Understanding Helpdesk Scams and How to Defend Your Organization
っていうハッカーニュースの記事ですね。
ラベラーと付けよう。
何の記事かというと
スカッターズスパイダーっていう犯罪グループ、脅威グループがいて
何をしてる奴らかというと
ヘルプデスク詐欺業をやってる人達なんだけど
そのグループの
具体的な方法と
防御策について解説してる記事ですね。
一応先年記事で最後には
何のサービスか読んでないんですけど
内容は結構勉強になって
直近先週とか先々週読んだ記事で
ヘルプデスクのやつとかあったけど
誰をどう狙って成立したんだろうねみたいな話とかの
具体的な部分が解説されてたんで
引っ張ってきたっていう感じです。
長いんでいくつか買いつくまんで
いろんなところだけ話すと
例えばヘルプデスクを攻撃するみたいな話
そもそもヘルプデスクを何を指すかが
僕多分正しく理解できてなかったんだけど
イメージ的には社内のヘルプデスクを指しに行ってる話っぽくて
コーポレートITとかに
アカウント発行してとか
アカウント入れなくなったからどうにかしてみたいな
そういう人たちを狙ってるっていう話で
その前提であるあるの攻撃ステップみたいなのは
機種変したから
昔のスマホのMFAを削除して新しいMFA登録し直してほしい
みたいなのが割とあるあるだったりとか
そっから入ったりして
いろいろとリスクの中で信頼を得て
実は別の番号もあるんでこっちもひも付けてとか
リカバリーURL送ってみたいなのを送らせる
みたいなのが割と上等したっぽくて
なるほどなと思ったのは
結構大半のヘルプデスクはリカバリーをお願いされたアカウントが
管理者であろうと一般アカウントであろうと
基本同じプロセスで対応することが多いっていうのがあって
なので攻撃者としては
そこに強度の差がないんで
管理者を把握した上で当然狙っているっていうのがあって
かつ直近ニュースが目立っているけど
新しいトレンドでは全然ないよって話も書いてあって
2022年にはこの攻撃が普通に成立してるし
ツールキットみたいなのもどうやらあるらしいっていうのが
分かってるという話ですね
あと何でヘルプデスク狙われるのか
みたいな話は結構
どうなんだろうなと思ったけど
ヘルプデスク自体は
自分が公開店の仕事やってるから分かるなっていう部分はあるんだけど
安全にやるっていうのももちろん多分大事なんだけど
どっちかっていうと早く裁くとか
早く問題を解決して収束させるっていう部分が
結構第一目標になりがちだし
ヘルプデスクのチケットクローズとかの
正解を導出することの重要性
SLAを設けてるとかも多分でかいところであればあるほど
ちゃんとやってるはず
そうなると早く動かすことにインセンティブが働く
早く動かすことにインセンティブが働くから
わりと攻撃者としては狙い目だし
守る目線だとセキュリティに固めて狙い目っていう部分があって
結構狙いがちだって話も書いてあって
これはちょっとありそうだなと思う
肝心の対策の部分はいくつか書いてあって
管理者レベルのアカウントとかは
別のフローちゃんと用意しようとか
エスカレーションするとか用意しましょうとか
リポントで手続きできないとかは
対面確認必須にしましょうとか
また怪しい挙動があったら
例えばURL渡したら
セルフでアカウントリカバーできるような例があるんだったら
まず安全側に倒して止めましょうみたいな
有効そうなんだが
実現できるのかみたいな
対策としては書いてあったりとか
ならないよってやつが2つあって
電話で問い合わせ来た時に
名乗った従業員に対して
例えば従業員の電話番号を別で調べて書き直す
みたいなのとかはシームスワップの例とかがあるから
完璧じゃないよって話とか
ウェブカメラ繋いで本人であることを確認するとかは
今だってディープフェイクで騙されちゃうから
安全じゃないよみたいな話があって
なるほどなというか
ちょっと解像度が上がったんで
紹介しました
思ったことをメモに書いたんだけど
結構自分ごととして考えた時に
例えば端末紛失した時とかって
多分大半の会社は
このメアドに送ってとか
この電話番号に緊急で電話かけてすぐにワイプしてもらいましょう
みたいな運用とかってあると思うんだけど
その電話番号みたいなのを狙って
騙すみたいな 基本ワイプでしか使わないから
アカウントリカバリしてとかはないかもしれないけど
なんか相手が人間である以上は
攻略の余地はありそうな気はしていて
結構かかってきた人が本当に本人なのかみたいな
公衆電話でかけてきてみたいな
焦った声でやられた時にちゃんと対応できるのかとか
結構ちゃんと思いはせてもいいかもなとか
あとは自分の仕事に近いところで言うと
例えばパスワードマネージャーのアカウント
ワンパスワードとかは管理者から復旧する仕組みがあったり
Googleアクセスベースも復旧する仕組みがあるんだけど
この依頼が来た時に
例えば何でしょうね
機種変したとかスマホ壊れちゃったみたいな時に
ワンパス無くなっちゃって ワンパス無くなっちゃったから
それもログインできないしストラクトもログインできなくて
どうしようもないのでとりあえずワンパス復旧してもらえませんか
みたいなのが知らない新しい電話からですって言って
電話された時にミスんないかみたいなのを
結構普通にちゃんと思いはせないと
いざその場面になった時に騙されるのかなとか
ちょっと思ってて
結構あんま他人事じゃないなって
今の立場とか業務を考えると
なんかスパイ映画みたいに
認証コードみたいなの喋ってもらう
そういうこと?おもろいな
認証コードをどうぞ
それ以外何も喋らない認証コード言うまで
認証コードをどうぞ
社内サービスって観点で考えると最悪の体験ではあるけどね
いやーでも
これ
人間狙ってくるのがやっぱ
ソーシャルエンジニアリングもそうだけど
むずいよな
ヤモティさんの声とかでディープフェイク使ってさ
わかんないけどなんか事前情報つかまれてて
すごい大事な商談の日とかに
あと30分で商談なんだけど
パソコンとスマホを新幹線に置いてきちゃって
大急ぎで電話してバーってマックス立てられて
とかなんかありそうだなとかも
でもさ冷静に考えてさ
もう30分じゃ間に合わないよ
手ぶらで言ってください
そのケースはそうだ
何もできない
一旦手ぶらで言ってくれ
セーロンだわ
どちらより小さい規模だとあれなのかな
大きい規模になってある程度も
ヘルプテスカ機械的に回すような
体制とかになってるところが
危なかったりするのかな
相手が別に
どこの誰だかわからん人であることが
普通くらいの規模になると当然
刺さりうるだろうね
社員の顔全員わからんみたいになると
確かにな
そんな感じで終わりです
GitHubセキュアコードゲームの紹介
じゃあ次
これはまださらっとでいいかな
これちょっと気になってそう
GitHubブログでハックザモデル
GitHubセキュアコードゲームという記事ですね
まずGitHubセキュアコードゲームというのが
何かという話をすると
ボリューム2を全部はやれてないんだけど
やりかけたことあるんですけど
GitHubが出してるパブリックのリポジトリで
課題みたいなのがあって
ボリューム2とかだと
Pythonか何かのアプリケーションが渡されて
こういう脆弱性があるから直してみたいな
テスト走らせて通ったら直ったっていうことで
チェックしてくれるみたいなのがあって
コードスペースポチっと押すと
その場合立ち上がって動作までするから
すぐに脆弱性の勉強ができるみたいなやつがあって
ワンツーっていうのがあるんですけど
今回それのボリューム3で
AIにフォーカスしたものが出たよっていう記事ですね
詳しいとか見てくださいって感じで
そんなに長い記事じゃなかった
ぼちぼち長いか でも読める量の記事だと思うんですけど
6個ぐらいテーマが問題かなが設定されてるみたいで
例えばよくここでも話す
プロンプトリンジェクションに対して
防ぐようなアプリを作り変えてねとか
アウトプットバリエーション インプットフィルタリングとかも書いてありますね
そういういろいろなアプリケーション由来の
脆弱性に対して
脆弱性をテーマにしたものになってるんで
っていう感じです
よく言えばやってきましたって言えたらよかったんだけど
やられてないんでちょっとやってみますねっていう
気持ちではいるんですけど
ぜひ気になる方はやってみるといいんじゃないかなと思ってます
AIに関する考察
っていう感じです
何分ぐらいでできると
ボリューム2やった感じは結構
山盛りではある気がする
コードまで直していく感じだとね確かに
セキュアコード
シーズン3同じリポジトリだよ
自分で手元にクローンして立ち上げたらすぐ動くって感じですね
今クローンしようとしたら僕昔
ボリューム2やったんでクローン済みでやってくれちゃった
ちょっと問題見てみるか
レベルごとにディレクトリが起きられてて
ヒントもあるですね
答えもあるんだ
コードスペース使ったことね
ブラウザでVSコードが立ち上がるだけだと思う
パブリックリプレッシャーだったら
そんな気にせず使っていいんじゃないかな
いいっすね
分量もめっちゃ小さいからすぐ読める感じだな
これやろう
レベル1とか典型的なシークレットを吐き出させる
プロンプトインジェクションの問題っぽいね
ライトやプロンプトヒア
コード書き換えて動かして突破できるかどうか
これ裏は分かんないけどもしかしたら
GitHubのAPI通してモデル叩いてるのかもな
おそらくそうだな
いいねギターをモデル叩いてる
やりすぎると問題解けなすぎて叩きまくってると
多分レートリンって引っかかるな
コードスペース
ちゃんとシナリオみたいなのもリードミーに書いてあるんだよね
あなたこういうので
働いてこういう場面に乗ってよみたいな
シーズン2も確かそんな感じだったんだよな
おすすめです
かなり手軽にできる良質コンテンツなんじゃないかな
こんなとこにコードスペースってのがある
あんま流行ってないよね
使ってる人は使ってるのかな
初めてだな
クラウドIDみたいな概念
今はクラインとか出ちゃったからな
手っ取り早くパイロットを使うなら
ここみたいな感じになったりするのかな
そういうのもあるかもね
でもね永遠に
無事取りの中身が出てこない
重いのかな
初めてだからかもしれない
面白い
CMのオフサイトとかで
アイスブレイクがてら
やれる量だったらやってもいいなと思ったんだけど
全部終わらせられなくても時間内でできる範囲で
やってもいいかもね
10分くらいでできるかどうか
10分は無理なんだ
1個触ってみようとりあえず
AI多いね
ちょっと食商気味なんだよな
AIじゃない話が欲しい
これの次が最後だけど
これの次は
これの次はAIじゃないんで楽しみにしつつ
1個頑張って食べましょう
でもちょっとAIって入ってる まあいいや
フラッシュ責任さんの記事で
さっき話したやつですね
これはAIかっこできました
人間かっこ本当に大丈夫か
デビンと探るコードセキュリティトラノマキ
内容はめちゃくちゃボリュームあって
でも読み応えあるんでぜひ読んでください
この人の文章好きだわ僕
AIが書いてないと思う 書いてたら騙された感じ
すごい読み応えがあるんで
読んでほしいなって感じなんですけど
さっきもチラッと頭出しちゃったけど
デビンに実際にシナリオを設定して
コードを書かせてみて
確か6個ぐらい基準内容としては
まず簡単なアプリケーションからスタートして
そこに機能を6個ぐらい追加していって
できた実装に脆弱性があったかないか
みたいなのを評価してみたみたいな
それを考察してどうしたら防げるかみたいな
ところをセットでやってるっていう感じ
例えば何かそうだね
何のアプリを作るシナリオだったっけな
どこに書いてあったっけな
TUDOアプリかTUDOアプリ作って
マルチテナントでロールの概念があって
MySQLとNextstation使ってみたいなとこに作らせて
そこにリッチテキストでユーザープロフィールを作れるとか
TUDOの共有リンク生成をさせるみたいな
1個1個やってみたいな
プロンプトも全部書いてるからね
すごいいいなって感じなんですけど
なんか面白いなと思ったのは
TUDO共有リンク生成機能とかは
プロンプト投げたらこれだったかな
別ネスだったかな
レスポンスにIDパスワード含めてるみたいなやつがあって
URLパラメータにIDとパスワード含む実装回してきて
バリバリ脆弱性含んでるねみたいな話
とかが書いてあって
結構面白いって感じです
TUDP入力画面の先進
URL
なかなかね
面白すげーなおもろ
これはすごいな
ギリ人間がやりそうなラインを攻めてるの面白いな
なんかね
このポッドキャストで話したかわかんないけど
人間ならまずやらかさんけど
生成Iはわけわからんから
やらかす脆弱性みたいな
普通に書いたらそうならんやろみたいなものが出てくるんじゃないかなって
かねたより思ってて
結構それに近いいい線いってるね
追加させてる機能とプロンプトもかなり絶妙で
非現実的すぎない
仕事で合いそうなんだけど
確かに作り込んじゃいそうなやつを狙ってやってて
CSVエクスポートとかね
ファイル添付とかで
ちゃんとプロンプトも脆弱性出るような
悪意のあるやつじゃなくて
普通のやつなんだけどちゃんと脆弱性出るっていうライン
何回か試してここにたどり着いたのか
一発で出たのかわからない
CSVのフォーミュラインジェクション対策はしてくれるのに
これはこうなっちゃう
マジ興味深い
暗記と導出の重要性
補足かつこの記事のめっちゃいいところだなと思ったのは
中立的なトーンで終始まとめていて
今回の実験とかは
既存のゼロから実装してるから
ある種参考にする実装がないからできたっていう可能性もあって
実際にアプリケーション手に入れるってなったら
他のやつのとこ真似するみたいな部分もあるから
同じようにならない可能性もあるはずみたいな
とはいえこの条件だとこういう結果になったよみたいな
感じでやってくれてるって感じですね
いやーおもろ
誰かなと思ったらかなるんさんなんだね
かなるんさんはブラクラクラの主催の人です
面白かった
ここに至るまでのキャリアも
独特の感じで
面白かった
機会があったらぜひやってみてください
面白かった
さっきのルールと照らし合わせてもいいかもなと思った
セキュリティの課題
これ読んで多分ルール作れるなって思ったりはしたな
逆にルール
どういうルール変えたらこうならないのかを調べてみた
いやーでもさ
いやーその
TOTPの利用画面に
センスのIDパスワード引き回すの面白すぎるな
だからさ
何ていうかギリ想像できるんだけど
ギリ想像できないラインでもあるんだよな
ちょっと斜め上ではあるよね
現物を見せられたときに
何がしたかったのかはめっちゃ理解できるんだけど
ギリ想像できないラインなんだよな
いやー面白い
それを想定したルールを作れるかっていうとさ
別に日々情報をURLで
引き回しちゃダメだよみたいなルールを作ればいいんだね
また今回は再現性は
たぶん生成アイディアから切り替えるときにないけど
ルール作ってもう一回やったときにどうなるかみたいな
もしかしたら思ったけど
ルールが本当に成熟するまでは
オートアプローブしないのは当然だけど
書かせておかしかったらその場で
ルール書いて同じプロンプト投げ直してみたいな
やるみたいなのを少なくとも僕とかやった方がいいんだよな
いやー
PDCA回すじゃないけどルールの
別にでもおかしいって気づければいいけどさ
そこはどっかでは気づくべきだと思うな
今のフェーズだと
気づけないってことはコードレビューできてないってことだから
別にIDパスワードを引き回しちゃいけないっていうのが
頭の中になかったらさ
例えばだけどどうしてもそのTLTPの話が
頭から今離れなくってそればっかり
引き合いに出しちゃうんだけど
それがさ
そもそも頭になかったらさ
それで言うと
自分のセキュアレビュー力に依存する話であるから
そこはもう頑張るしかない
いやー俺やだよだってDevinでさ
生成したコードでさセキュリティレビューお願いしますってさ
そのIDパスワード引き回してTLTPの入力画面に
遷移してるの見せられるのすげーやだよ
なんかもうどんな顔してそれレビューすればいいのかわからないし
その何て言ったらいいんだろうな
そのさこのさ
セキュリティレビューするときもさそれなりの覚悟があるわけですよ
その覚悟のレベルというかその
気合の入れ方というかさ
困っちゃうよ
いやーまあまあまあ
困っちゃうよーやだよー
今時点のセキュリティレビュー向き合い方はよく言われてるけども
そのジュニアエンジニアをどうって名付けるかっていう
視点に立つしかないと思う
なんかセキュリティに限らないと思う
セキュリティでもやらかすし普通の実装面でもやらかすデザインも多いというか
やっぱそれがまあ
現在地点なんじゃないかって気がする
いやーでも
これはねぜひ読んでほしい面白かった
はいじゃあ最後いきますか
AI職が弱い
まあ単語入ってるけどそんなあれです
だし軽めの記事なんですけど
Our latest scam survey sees changing online security habits
っていう
セキュリティのカンパニーニュースの
セーフティー&セキュリティカテゴリーのブログな記事ですかね
はい記事です
長くなかったはず
長くなったかな
内容としてはオンライン詐欺に関して
調査結果
リサーチをした調査結果の共有なんだけど
一応周り読むと
アメリカの話ですねアメリカのスコープなんだけど
60%以上のアメリカ人が
詐欺が増加したっていうのを
実感してるよって話と事実増加してますって話
数字は忘れたけど
別の記事で取り上げた気がするけど
多分100億ドルとかそういうレベルで被害が出ていますよとか
特にテキストメッセージとかメールを通じての
詐欺が多いですよっていう話
個人的にちょっと興味深かったのは
ただ世代間で
詐欺とどう絡むかちょっと忘れてたけど
世代間でセキュリティ意識みたいなところに差がある
っていうのがレポートに書いてあって
いわゆるZ世代みたいなところは
パスワードとか従来のパスワードとか
パスワードプラス2FAよりもパスキーを好む傾向があって
シェアがかなり大きいっていうところとか
またアカウント数が少ない
管理したいアカウント数が少なくて
っていうのもソーシャルログインをかなり活用してるから
Z世代は確か10個程度
平均か中央値か忘れたが10個程度しか管理してない
っていうのがZ世代に傾向としてあるんだけど
それに対してZ世代より上の
僕らの世代とかその上の世代みたいな
ところは従来のパスワードだけとか
パスワードプラス2FAみたいなところが
まだまだ多くてパスキーの利用っていうのは少ない
っていうのが書いてあったっていう感じですね
最後はGoogle頑張ってるよみたいな話で
締めくくれてるんですけど
AIが何とかするよとか
その辺はもう散々触れてるので活躍として
結構個人的におもろいなと思ったのは
Z世代のパスキー利用
Z世代がすごいとかっていうよりかは
わかんないけどパスキーに適応できてる世代がいるってことは
Z世代じゃないと適応できないのかどうかは
このブログの記事だけからは分からんけど
別に他の世代も適応できる可能性がゼロじゃないような
っていう気はしていて
暴論かもしれんが
パスキーの普及みたいなところの未来は暗くないんじゃないかな
っていう気持ちもありつつ
もしかしたらZ世代の
一つ上のレイヤーがパソコン使わなくなるまで
時が経つまでは普及しないかもしれないし
ちょっと神の目指してるって感じなんですけど
へーと思ったって感じですね
雑に締めちゃったけど
うーん
なんかでもこの辺って
なんて言ったらいいんだろう
なんか
人間の研究の中で多分ありそうだよね
何か新しいものに対する
適応能力は年齢に応じて
ぬんかんぬんみたいな研究って絶対あるはずで
ちょっとまあ実際それで
どれくらいその
信頼に足るデータが出てるのかとか
どういうデータが出てるのかとか全然分かんないけど
個人差はあるけどなんかおおむね
若い方がっていう傾向は感覚的にはある
と思うし
確かにね確かにありそう
元レポートも読んどきゃよかったな
読むしかなかったな
そもそもそのジェンチ向けのサービスが
信仰サービスが多かったりするんじゃない
そもそもパスキー使ってるサービスが多い
みたいなのあったりしないのかな
でもGoogleの
検証とか調査の内容もちょっと
ちゃんと読まないと何も言えない
Googleだからちゃんとその変化見した上で
やってそうな気がするんでもないけど
レポートがPDFだったんで
ノートエピックエデンスクラスで
おもむらに予約をさせてるんだが
ちょっとリンク貼っとくか
Z世代USコンシューマー50パー
ユージングストロークユニークパスワード
パスキー40パー
書き留めるか記憶する
パスワードの管理方法についても
勉強があるんだね記事でも触れられてる
書き留める人とか記憶する人が26パー
パスワードマネージャー13パー
メモリストへの保存10パー
プラザの保存9パー
複数のアカウントでパスワードを
使い回してるのは7パー
傾向があるみたいな表現に留めてるから
あくまで傾向ではあるんだよね
そんな感じのAI要素は
見もたれせずに済んだかわかんない
そんな感じの記事でした
ありがとうございます
面白かったね
あれだな
さすがに今回のタイトルは
IDパスワードURLに含めてはいけない回だな
任せるよ
何言うの
聞いててあんま通じてない人もいるかもしれないから
全部説明するけど
TOTPを入力する画面って
だいたい別の画面になって
IDパスワードを入力した後の画面になってる
多いよねっていうのが前提としてあって
なのでまず画面
IDパスワードの入力画面とTOTPの入力画面を分けましょう
プロンプトとかでそういうのが示唆されてるのかもしれない
わからんけど
そういう前提があります
ただそうすると
TOTPを入力する画面からだと
ログインのエンドポイントなり
パスなりが
1個しかないから
結局
TOTPを入力する画面から
リクエストを飛ばそうと思った時に
IDとパスワードが分からないから
ログインのエンドポイント呼べないじゃんみたいな
思考が入って
セア入力画面から引き回してこようみたいな
ギリ人間がやりそうなんだけど
ギリ想像がつかないという
ギリ僕ら視点想像がつかない
斜め上のやり方っていう
なんて言ったらいいんだろうな
ギリギリ見たことあるかもみたいなラインを攻めるのが
すごい絶妙なんだよ
世界中探すの絶対あるよね
そうそう
やられWebアプリとかだったらやってそうみたいな
そういうかなり絶妙なラインを攻めていて
個人的には大ヒットなの
それってIDパスワードを単純に
引き回しちゃいけないみたいな単純な話じゃなくて
あまりにも何とも言えないラインを攻めた
その思考回路そのものが大ヒット
なるほど 理解しました
結論はそんな感じになっちゃったら別に
IDパスワードTOTPっていうフォームを1個増やす
アイテムを1個フォームアイテムを1個増やすって話でしかなくって
別に
それがやったら別にそういう実装もなくはないよね
そうだね
いやーいい
いやー面白いなこれ
本当に好き
別のもぜひ読んでくれ
めちゃくちゃヒットしてる
めっちゃ好きだな
なんか今回の記事のやつ面白いかな
群を抜いてこの絶妙なラインを攻めている
脆弱性が一番面白いな
今年の上半期
なんかベストかもしれない
めちゃくちゃヒットしてる
めっちゃ好きだな
めっちゃ好きだな
何よりよ
俺だけなのかな
結構面白いけどな
俺好きな人多そうだけどな
なんだっけ
あれとかもやりそうだな
なんだっけ
あれかパスワード変更の時に
パスワードの確認を
元のパス
何だっけな
元のパスワード確認のAPIと
新しいパスワードの更新のAPIが分かれていった
実装
だと直接叩けば新しいパスワードを
元のパスワード入れずに変えられるみたいなやつがあって
あるあるですよ
セッション管理とセキュリティの議論
フリーの人との対談かな
俺ら見たことないよ
あるあるじゃないのかな
結構よくありますよね
間違ってたらごめんなさい
題材としては特等のいい題材になりそうだね
タイムオブジェクトタイムオブユーズの
サーバーサイド側で
ちゃんとやれっていう話
サーバーサイド側でっていうか
やり方は様々あると思うけど
セッションのステータスで持てるんだったら
いやでもな
無理だよ
パスワード変更の話
セッションのステータスで持つのも
悪用はちょっと難しくなるけど
なんか違うよなって感じするしな
しかもなんかさ
パスワードの変更機能って
基本アンティセーサーRFトークンとかつけないからさ
全部ついちゃうっていうパターン
フレームワークとかで全部ついちゃうとかだったらついてると思うけど
ついてないケースもあったりするから
そうすると例えばバックエンドでセッション変数として
こいつは
いつ何時
現在のパスワードのチェックを通しましたみたいなステータスを持ってたとすると
その状態だとCSRFに対して
CSRFでパスワードの変更ができちゃうから
やっぱダメで
あまりにも仮定の話が多すぎて
何も言えんけど
普通に全部まとめて受け取れっていう話にしかならんな
エピソードのまとめと次回予告
あんま刺さんない例を出して
これを胸に秘めて今日は
薬飲みを
面白いな
声に出して読みたい
今年度末のベスト記事
ちょっとノミネートかもな
ヤギ足を選定
ノミネート説
俺が一番受けた記事
いいね
そんな感じですか
そんな感じですね
今日も楽しかったですね
また来週も
来週もお願いしますというか
収録自体は明日もあるからね
特別編があるとかないとかいう話があるので
ちょっとだけお楽しみにしつつ
僕ら入りにならないこと
大丈夫でしょう
楽しみにしながら
みなさんぐっすり眠ってください
おやすみなさい
