00:05
こんばんは、Replay.fm 第2回です。
こんばんは。 お願いします。
1週間ごとって言ったんですけど、前回。
あの、さっそく2週間開けるっていう。
あれでも1.5週間だよね。
1.5週間か。
じゃあ、まあほぼ1週間。
先週分プラス0.5週間分を今日読むっていう形にしてるから、
そう、1.5週間分で、今週の分を来週読むっていう形になるから、
そう、大丈夫だと思います。
なんか、任せたわ。
脳内でその辺の整理ってことね、実は追いついてないから。
次回以降はちょうど1週間ずつぐらいで多分出せるようになるはずで、
用文・記事も1週間ずつ区切っていけるようになるはずだから、
はいはいはい。
OKでございます。
今回はちょっと長めになるかもしんないけど。
うんうん。
じゃあ、さっそくですけど、読んでいきますか。
はい。
例のごとく、ノーションに溜め込んでるんで、一番上から読んでいこうかなって感じですけど、
Bleeping Computerの記事ですかね。
マルウェアロックスブラウザーin kioskモードto steal google credentialsっていうタイトルの記事です。
はい。
いくつかね、なんか気になるフレーズというか、まずkioskモードって何やねんっていう話があったりするのと、
うん。
具体どうやってんのみたいな話があったりするんだけど、
kioskモードっていうのはなんかいわゆる、なんて言ったらいいんだろう。
すごくわかりやすい例というと、なんか居酒屋の注文端末のAndroidがアプリのあれに固定されてるとか、
あとなんだっけ、iOSのアクセスガイドかとか、なんかああいうやつが多分Chromeにもあるらしくて、
それをkioskモードっていう風に呼んでるらしいですと。
みんながよく居酒屋とかでポチポチやって、そこをいかに抜け出すかを遊んでるやつ。
ですね。
これを使って、悪用して、例えばフィッシングサイトみたいなのを開かせて、
抜け出せなくして、クレデンシャルを盗む手口があるよっていう記事ですかね。
フィッシングじゃなくて、正規のGoogleのサイトを開いてるんだけど、別のマルウェアがいて、そいつがそこに入力したクレデンシャルを持っていくっていうシナリオみたいですね。
なるほど。
めっちゃ勘違いしてた。
どっちかと言うと、だからもうそのkioskモードから抜け出せないストレスをかけて、訳わからなくさせて入力させるっていう。
03:08
じゃあもうこれ、このGoogleのログイン画面がkioskモードで開かれてる時点で、もうマルウェアに感染しているっていう。
そうそう。
わざわざ入力させるのは、Googleのログイン情報はローカルにないだろうから、入力させて取らなきゃいけないって感じでやってるのかな。
なるほどね。早速勘違いしてた。良かった、この回やってて。
これなんかChrome以外とかでも似たような手口あるんだろうな。
Chrome以外ってかGoogle以外ってこと?
っていうかは。
Chrome以外でもkioskモードみたいなのがあればあるかもしれないけど、
ただShareを見た時に多分Chromeが一番狙いやすいんじゃないかな。
確かに。そうかそうか。
なるほどね。
Exiting the kiosk mode。
で、これにはkioskモード。
あれだよね、開かせた時に本来だったら抜け出すためのホットキーがいくつかあるんだけど、
潰されてる。
凍化するような処理が入っちゃってるから、
それされてもこのキー組み合わせれば抜け出せるよっていうのが記事には書いてあるっていう。
抜け出せないからセーフモードで起動し直せって書いてなかったっけ?
なるほど。
Those may help bring the desktop on.
あーなるほどね。
まぁでも一応抜け出せるかもとは言ってるんだな。
タスクマネージャーでブラウザを閉じればなんとかなるかもっていうことは言ってるんだね。
その画面、Chromeの画面しか表示されてないっていう画面からは抜け出せるはずだから、
それで全部ダメだったら、
ハードリセットして、電源ボタン押してハードリセットして、
セーフモードで起動してねっていうことを言ってる。
あーなるほどね。
まぁでもこの記事にたどり着けないともうやられちゃったな。
だからこそなんか先に読んどくと、こうなった時に焦らずに済むっていう話なんでしょうね。
そうだね。
いや、ちょっとちゃんと読まなきゃいかんな。
おもろ。まあKioskモードを個人的には知らなかったんで結構へーって感じの気持ちでしたね。
ありがとうございます。次行きますか。
はい。
えーっと、これもブリーピングコンピューターの記事で、
FBI tells public to ignore false claims of hacked portal dataっていうところで、
内容としては、FBI、アメリカのFBI、皆さんご存じのFBIが、
06:06
たぶん大統領選の選挙に関して虚偽の情報っていうのが蔓延してるので、
先導されないというか、惑わされないようにしてくださいっていうのを民間に対して警告してるよっていう話かなっていう理解をしてます。
全て嘘だよっていうのを言ってる。
そういう事実はないよっていうこと言ってる。
そうだね。なんか個人的にはピックした、両方ピックしてるけど、僕はなんか割と、なんか前回の大統領選も、
たぶんなんかロシアの介入があったなかったみたいな話を、ちゃんとリサーチはしてないが、まあいろいろ耳に入ってきてはいて、
なんか結構ちゃんと実生活に影響するなっていうのが普通にディストピアだなーって、しみじみ改めて思ったっていう感じですね。
なんかある種のサイバー戦争みたいな部分の延長っていうかその一環なのかなと思う一方で、
世の中、世間一般で見たときの情報通信技術そのもののなんかよくわからなさみたいなのに気にするものなんじゃないかなみたいなのをこれ読んで思って、
なんか一言で言っちゃうと、すごい壮大なワンクリック詐欺というか、こんなことが起きてますよってわーって騒ぐとなんかみんながなぜか不安になってくるみたいな。
ハッキング、いやよくわかんないし、実際そういうふうにされてるのかもしんないしみたいな、そういうその不安を煽られる、なんていうかそういう話なのかなとちょっと思っていて。
なるほどねー。
なんかそういう人たちがなんも考えなくても安全にこう暮らせる世界が多分理想なんだけど、でもなんか一定のリテラシーがないとこういうことは起こるし、
この辺のなんかバランス感みたいなのがすごく難しいなとはちょっと読んで思いましたね。
でもなんか聞いてて思ったのは、なんか実は本質的にはインターネット、まあインターネットはなんかハウの話で、
ああそうそうそれはそうだと思いますね。
メディアで多分似たようなことがされてきて、ただそのハードルが低いのと国境を容易に超えられてしまうし、まあそこにテスルの抑止力も多分現状ないから、まあやられたい。
今も多分そうで、そのなんていうか、昔は例えば極端な話、ビラを配ってそのなんていうかそういう風説をルーフするみたいな出来たかもしんないけど、
それらがこう、それらの信憑性を確かめる手段に多分乏しかったんじゃないかなと思ってて。
で、今はどっちかっていうと、今この記事で話題にされてるような話はどっちかっていうと、
そもそも人々がえっとなんていうか、漠然と怖いと思ってるものみたいなのを根拠にしてそういうことを語っているから、
09:03
なんかこう、みんな確かめようがないっていうか、漠然と不安になりたいな。
なんか確かに類型としては全く一緒だと思っていて、昔からあるようなものと。
ハードルがなぁ、LLMで嘘記事量産してるみたいなやつもなんか別のポッドキャストで聞いたんですけど、
いやー、あーこれ対策する立場になったらめちゃくちゃ頭痛いだろうなぁ。
どうすんねんって感じだよなぁ。
教育、義務教育で、いやでもなんか見抜こう、見抜かなきゃいけない状況になってる時点で負けな気もするんだよなぁ。
見抜けないじゃないですか、多分。
結構むずいよなぁ。
特に希望のない話をしてしまったが。
次。
これ僕が最初に追加したのかな。
JMO Cyber Security by Ieraeさんのブログ記事で、
見落としがちなサーバーサイドPDF生成における脆弱性、SSRFやLFIによるシステムの侵害という記事ですね。
で、これ、僕なんかシンプルに、恥ずかしながらというかシンプルに、この手法というか抗議経路を知らなくて、
言われてみれば、
どっちの?SSRFなりLFIなりの話をしている?
PDF生成経由でのインジェクションが成立し得るよっていうところなんですよね。
ですかね。
なるほどね。
なんか、なんだろうな、っていうのもなんかその自分の業務、今の職種の機能とかで、
そのPDF生成をするような機能は実は普通にあったりするんで、
なんかその機能があるっていう事実を受け止めたときに、
なんかこの攻撃があり得るっていう発想に至らなかったなってちょっとなんか純粋に思ったというか、
確かにその任意の値を受け取って、
まぁ受け取んないパターンもあるけど、
まぁそのどっかしらから値を受け取って、
そのPDFを動的に生成してるっていうロジックは、
なんていうか現実の世界で結構あるはずなんだけど、
まぁある割に、なんかちゃんと知れてなかったなっていうのを結構シンプルに内省したというか、
私、まぁでもなんかちょっと頭使えばなんか分かる話でもあったなっていう気はしてて、
なんか本質的にはなんかXSSとか、
まぁその辺のインジェクション系と一緒というか、
まぁ入力する値を信用すんなよとか、
まぁ出力するときにちゃんと処理しろよっていうところの話に通ずるところかなと思いつつっていう、
まぁ割とそれぐらいの浅さで、浅さというかそれぐらいの解像度での感想を抱いたって感じですね。
12:08
なるほどね。
なんか、なんて言ったらいいんだろうな、
PDF生成っていうのがちょっと目につくかもしれないけれども、
本質的にはやっぱりSSRFとかLFIの話であって、
結局向こう側で取ってきた、
向こう側ってすごいあれだけど、
自分がクライアントサイドにいたとしてバックエンド側で取ってきた、
取りに行かせた情報をどうやって、
要はクライアント側に何らかの形で持ってこないと、
SSRFとか、
SSRFはちょっと難しいな、
持ってこなくても成立するケースがあるので何とも言えないんだけど、
LFIとかも場合によって成立するケースがあるのかもしれないけど、
ただ何らか結果を持ってきたいっていうシナリオがそれらの攻撃手法の中にあって、
その持ち出してくるときの一つのやり方として、
PDF生成っていうのが握用されているだけっていう話なので、
別にPDF生成がっていう話では多分ない。
なるほどね。
なるほど、理解。
確かに。
PDFじゃなくて画像生成だったとしても一緒で、これは。
うんうん。
なるほどね、言われてみれば確かに。
この辺の嗅覚を養っていきたいな、
嗅覚というか考え方というか、なるほどですね。
なので突き詰めていくと、
ユーザー入力を信用してはいけないよっていう話に行き着くんだけれども、
信用しない、信頼しない結果じゃあ何をするのっていう部分がコンテキストによって変わるから、
例えばこのPDF生成処理とかでこういうことが起きちゃうよみたいな話だと思っていて、
うんうん。
まあまあまあ、そうっすね。
理解しました。
こういうのこそその辺で出回ってるやつはデフォルトでちょっと固めのCSPとかが効いててくれたら、
多少マシになったりしないのかなと思うんだけど、
よくわからん人はちょっと固めのポリシーのCSPのもとでしか使えないような形にするとか、
なんかできたりしないのかなとは思うんだけど、
まあちょっとなんとも言えないっすね、その辺は。
これCSPで防ぐ術あるのか?あんまり分かってない。
HTMLを、HTMLとして描画したものをPDFにしているっていう都合上、
そもそもiフレームとかでロードさせなければ。
あーなるほどね。
表示はされないから。
まあそれ確かに。
いやー確かにね。
まあでもそこまで開発のときに思いつけないだろうな。難しいな。
だからこそOSSとかでそういう形になってたら、
15:06
なお良いんじゃないかなっていうのは思うところかな。
確かに。
まああるいは結構難しいかもしれないけど、
HTTPでアクセスされ得るLFIとかSSRFでターゲットにされるような場所の方で、
そっちでiフレーム経由だったらそっち側でxフレームオプションで返してあげれば、
iフレームで読み込めなくなったりするのかな。今回のケースでいうと。
まあでもあんまり本質的じゃない気がするから、やっぱり難しいですね。
気を付けなくてもうまいことできるようになってて欲しいなとは思いますね。
これかしらか。
まあ見落としがちなっていうプレフィックスが記事に付く理由がすごい。
納得感がある。
納得感ある。
ひとつ賢くなりましたって感じですね。
次いきましょうか。
RS Conference 2024セッション解説1 総評セキュリティトレンド編。
これはエナライセキュアさんのブログ記事ですね。
事前メモ、ヨヨさんが釣り替えてくれてる。
この記事自体は、RS Conferenceどこのイベントなんだっけ?
アメリカ、大体アメリカかな。
アメリカの記事のレポーティングって感じですかね。
カンファレンスに、たぶん毎年何人か行ってるんじゃないかなと思うんだけど。
いくつかの、たぶんセッションのサマリーとかを書いてくれてるってところで。
事前メモで書いてくれてるところが。
紹介をされてるんだけれども、特に気になったところでいくと、
ガートナーのトッププレディクションスフォーサイバーセキュリティの2023から2024年っていう、
セキュリティのトレンド解説みたいなのをやってる講演の一つで上がってたのが、
ちょっと僕は面白いなと思って事前のメモで残していて。
2027年ぐらいまででセキュリティ周りのトレンドがこうなるよっていうのを、
ガートナー社の人が予測として紹介していて、
18:02
2024年までにプライバシーの保護に関する規制が進む一方、
プライバシーの保護を売りにできる企業は10%にも満たない。
2025年までにおおよそ半数のCISOたちは職を変えてしまい、
そのうち25%はストレスが原因で全く異なる役割の職に就く。
50%のCISOは経営判断に活用するためにサイバーリスクの低量化を試みるものの失敗に終わる。
2026年までに10%の企業がゼロトラストを成熟させる。
脅威検知調査対応に関する機能の60%以上が検証や優先順位付けにエクスポージョンマネジメントデータを活用する。
70%の企業は取締役会にセキュリティの専門家を1名含む。
2027年までに75%の従業員がシャドウITを利用する。
大企業の50%が人的リスクを念頭に置いたセキュリティ対策を行う。
みたいな予測を紹介していて、
なんか気になったのは僕は3つぐらいポイントとしてはあって、
1つ目はプライバシーの保護に関する規制が進む一方で、
それの保護を売りにできる企業は10%にも満たないっていうのは、
これは肌感としてすごくわかるなと思っていて、
そういう流れに世の中なっていくんだろうなとは、
なんとなく思ってた部分がすごくあって、
規制はめっちゃ厳しくなっていくけれども、
一方でそれを売りにしているっていう企業は実際まだまだ多くないし、
それが2024年までに、
2024年って今でも今年か、
今年のうちにワッと増えるかというと絶対増えないはずで、
この辺はだから売りにできるっていうのが価値になるのか、
そもそも市場がそこに価値を見出さないのか、
どっちなのかちょっと講演の中でどう言及されるかわからないけれども、
肌感としてはなんかまさにそういう部分は思っていて。
なんかその求められるベースラインがそもそも、
強制的に上がってるというか、
日本だったら個人情報保護法が、
個人情報のとりあえず使い回りがどんどん厳しくなっているよとか、
この業界、この界隈に入って間もないんで間違っていたら教えてほしいけど、
なんていうかそのISMSとかBマークの取得とかをしてますっていうのがなんか割と、
なんだろうな、してるからいいねじゃなくて、
してないんですかみたいな世界だなって肌感はめちゃくちゃあって、
なんかそういう認識を持つ企業とか、
いわゆるその顧客側が何かを選定するときに、
そこはもう足切りラインでしょっていう認識になってる感じはしていて、
なんでそれで言うと、まあ僕も経験短いながらわかる。
その足切りラインプラスアルファの部分に、
そのプライバシーの保護を売りにするっていう領域があるはずで、
21:05
要は別に極端な話、違法じゃなければ何やってもいいみたいな、
その世界なわけですよ、まだまだ。
で、別に適法にやってることだけれども、
人によってはすごく気持ち悪いと思う、
事象が起きていたりするっていうのは事実としてあると思っていて、
そういう中でプライバシーの保護をユーザーに提供できる価値として見出して、
それを売りにしていく企業っていうのが出てくるのか出てこないのかで言うと、
まだまだそれを売りにするよりも、
ある程度その法律は守り続け放題やってる方が儲かるという状態なのかなと思っていて、
それこそスタートパーティークッキーの話とか。
そうですね、確かにあれは分かりやすいな。
なるほど、確かに。
まだまだその辺の論争っていうのは続いていくんだろうなとは思ってる。
確かにな。
もう1個気になったのが、経営判断に活用するためにサイバーリスクの低量化を試みるっていう部分の話ですね。
このリスクの低量化っていうのは永遠のテーマだと思っていて、
ありとあらゆるリスク管理と名のつくもの全てでこのリスクの低量化っていうのは、
みんながやりたいと思っている。
これを見るに、なかなかみんなうまくいってないんだろうなっていうのは、
なんとなく察することができるので、今後どうなっていくのかなっていう。
むしろ失敗するの50%で済むなら良くねというか、
50%成功してる。
これ公演見ないとダメだな、公演見てみようかな。
でも自分も身に覚えしかないんで、とても身にしみるな。
あとはごめんなさい、これ2つしかなかったな。
このまとめて気になったやつ。
もう1個3つ多分僕が書いたやつかな。
そういうことか。
そうそう、多分記憶ないんじゃないかと思うんだけど。
ごめんね、ありがとう。
これは別のセッションのサマリーですね。
そうですね、SANSのメンバー5名が登壇し、
現在取り沙汰されているセキュリティ上の懸念や、
新たな脅威攻撃手法について紹介するっていうようなもの。
で、サマリーのところで技術的不採っていうのが1つトピックとしてあって、
その場しのぎのコーディングやレガシーコードが蓄積された結果、
コードのメンテナンスが十分に実施できなかったり、
それらの内容を理解できる人材が残っていなかったりするために、
脆弱性が取り残されやすくなっているっていうのが書いてあって、
それなボタンを連打したって感じですね。
24:02
それなっていう。
いやー、そうなんですよね。
でもなんかこれ、割と当たり前体操案件ではあって。
じゃあどうだったらいいの?っていうのがすごく難しい。
なんか、この講演のサマリーのところでもセキュリティデザインって言葉が出てますけど、
いやー難しいな。
セキュリティ云々ではなく、
そもそも品質をきちんと担保していきましょうっていうところからアプローチするのが現実的には、
まあいいよねっていう気はしていて、
というのもなんというか、
コードが汚くなったら脆弱性生まれやすくなるんで、
コードきれいにしましょうって言っても、
どこが具体的にっていうのを想像できるソフトエンジニアってそんなには多くないはずで、
すみつかない。
割と狭い職じゃないと。
そうそうそうそう。
ちょっとホップしなきゃいけない。
だけど、じゃあコード汚いままだとリリースの時にバグりやすかったり、
洗剤バグめっちゃ出ますよね。
じゃあきれいにしましょうよって言ったら、
みんなわかってくれると思うんですよ。
なので、
そういうアプローチで、
そもそもコードの品質が下がっていく、
下がりうる状態とか、
低くなってしまっている状態に対して、
成功法でアプローチをするのが、
現実界としてはやるべきことかなと思うし、
それが結果的にここで指摘されている脆弱性が取り残されやすくなっているみたいな部分に対しても、
ある程度は効いてくるはずかなと思っていて、
ただ、
自分的にどうだろうなと思っているのは、
その先でじゃあ脆弱性がゼロになるかっていうと、
それはまたそういうわけではないんで、
別の取り組みを、
いろんな多角的な取り組みをしていかねばならんよなっていう。
なんかすごいちょっと予算臭いコンサルみたいな毛皿になっちゃってるけど。
ほんまやな。
でも技術的不細は多分スタートラインに立ててない状態だと思うから、
まずスタートラインに立とうぜっていう気がするな。
言うはやすしなんですけどね。
本当それなんですよね。
うん。
脆弱性が。
いやー、でもね、
なんか、
会社目線で言うのは事業リスクですよっていうのを、
ちゃんと会社が認識して、
こうならないために、
こうなる前にきちんと投資をするとか、
こうなってしまったんだったら、
返済のために投資するっていう。
動きが取れるか取れないかで結構会社の名誉は変わるかもしれないな。
なんかそうなってしまっているのをどう見つけるかみたいなのが個人的には気になってて、
27:00
何を持ってそうなっていると判断するのかっていうのが結構難しいのかなって。
例えば開発のその生産性というか、
スクラムとかやってればベロシティがどうなのとかを見ることができるかもしれないけど、
でも、
なんかそんなの人によるし、
なんかやってるテーマによるかもしれないし、
すごくなんかブレが起きそうだなとも思うから。
なんかあるあるというか、
バザードを使うみたいでちょっと嫌なんですけど、
その4 keysを計測しましょうとか、
まあ一つの回答にはなるんじゃないかなって気はしたりとか、
あと弊社とかだと、
なんか実際にやってるのはその、
やっぱなんかこの、
技術的不採が生まれるときって、
なんか徐々に生まれるじゃないですか。
徐々になっていくじゃないですか。
ある日突然不採になるわけじゃなくて、
たぶん気づいたらあれ不採じゃねってなってる。
で、なんか徐々に変わっていくから、
気づけないっていうのが結構難しいところなんで、
その前提に立つとやっぱ定点観測っていうのは間違いなくしたほうがよくて、
で、うちもなんかその障害なんか増えてねみたいな、
あの空気が漂った時期があったんだけど、
その単純に障害件数だけ見えても、
まああんま意味のある定点観測にならないというか、
その障害レベル自体に、
障害それぞれに重さがあってグラデーションがあるよねとか、
その障害が起きてる領域が結構バラバラだけど、
なんかどの領域で起きてるのかとかが、
今のフォーマットだと計測しづらいみたいな話をしてて、
じゃあなんかこの領域で、
なんかリリース回数に対して、
なんかこのレベル以上の障害が何件起きてるかっていうのをちょっと追ってみましょうみたいな、
取り組みとかをしてくれてる開発チームとかがいて、
まあそういうのは割と一つベンチマークにはなるのかなって気はしたりしますね。
なるほどね。
例えばですけど、
そうですね、この貼り付けてくれたfor useというのは、
今の話は変更失敗率のところかな。
デプロイあたりに何回障害起こしてるんだっけっていう。
だからなんかその、
障害の数が少ないイコール、
ダメじゃないってパターンでもないっていうのが結構多分むずくて、
なんか障害起きてないのはリリースしてないからみたいなオチもあるから、
なるほどね。
だからデプロイの頻度とかがCEOとして入ってくると。
そうそうそうそうそう。
その辺ね、バリッドな、バリッドなっていうか、
意味のある定量的な定点観測ができるといいし、
またそれに対してその理想系としては、
まあ経営までいかなくてもいいけど、
そのある程度その、
まあ社内のステークホルダーとかが見たときに、
わかりやすくなってると、
まあ合意も得られやすいんじゃないかなって気はしますね。
確かになんか感覚としても、
そのデプロイの失敗とか失敗からの復元までの時間とかで、
その複雑性みたいなのは測れそうな気がしますね。
どんだけこんがらがっちゃってるのかみたいなのは、
なんとなくそれでわかるというか。
30:01
そうですね。
ここいじったらこっち壊れるの、
えーみたいなのはなんか確かにそういうのでわかりそう。
あとは多分行動以外の問題も炙り出せる気はしていて、
まあなんかこの記事に書いてあった、
それらの内容を理解できる人生が残っていなかったりするみたいなところがあると、
多分この復元までの時間とかが伸びがちだと思うんですよね。
どこをどう直せばいいかわかんないみたいなので、
死ぬみたいな。
そうなると、じゃあそもそもなんかこの領域、
雰囲気で触っちゃってるよねみたいな。
理論からじゃあそこの理解を深めるとか、
綺麗にしていこうみたいな方向になっていくと、
教科書的にはいいよねっていう。
まあこの計測も大変だし、
それを運用するっていうのがやっぱ難しさではあるんで。
うん。
まあでもなんかそうっすね。
だからセキュリティー、
そうね。
なんか感覚としてはセキュリティー的に技術的不採がまずいっていうよりかは、
技術的不採は確かにセキュリティーの問題につながるなっていうのは、
改めて思ったというか、
そうだねって気持ちになる感じですね。
なるほど。
うん。
いやでもこれ、
ちょっと、
カンファレンスの動画とかあるのかな?
あとで。
ある。
YouTubeに上がってて、
全部の講演がそうかわからないけど、
上がってて。
うん。
なるほど。
後日か後で見てみようかなとは思ってるんだけど。
うんうんうん。
これ1があるんで2もあるんですよね。
2は来週多分読むことになると。
確かにね。
読みましょう。
じゃあ次いきますか。
SBOM。
SBOMね。
GDNETの記事ですね。
ソフトウェア脆弱性管理やSBOM対応における国内外の動向っていう記事ですね。
これ僕がメモを書いてるのか。
そうです。
記事の内容思い出せないな。
記事の内容思い出せないけど、メモは。
でもなんかSBOMなんで必要なのっていう話を書いてくれてるのと、
結構貴重だなって思ったのは、ヨーロッパ圏とか米国とか海外での動きとして、
こういうレギュレーションでSBOMが必須になってきてるよみたいなトレンドを紹介してくれてるっていうのが結構いいまとめかなっていう感じですね。
確かに。
結構丁寧にまとめてくれてる記事ですよね。
SBOM分からんって人は、なんかこれ読めば雰囲気分かるかもよって言えるかもしれない。
なんでこれが今流行ってるのっていうのが多分すごく分かる。
僕がなんかピックしたのは、記事中の一文でSBOMを利用することで複雑になりすぎたソフトウェア製品やITサービス内部のコンポーネントを正確に把握し、
33:00
リスク管理を行えるようになると期待されてますって書いてあって、
僕はこの複雑になりすぎたソフトウェア製品っていうのが結構しみじみ感じるところというか、
現代のセキュリティ対応を明らかに難しくしてる要素の一つだなって感覚があって、
なんでしょうね、分かんない、多分把握できないんですよね、本当にガチで。
GKEにアプリケーションデプロイしますってなったときに、
GKEが動いてるコンピュートエンジンのマネージドのOSがあって、そこに何が入ってるのかとか、
GKEのバージョンによって、じゃあそれ何に依存してんのとか、
デプロイされるDockerイメージのベースイメージに何がプリインストールされてるのかとか、
そのDockerイメージファイルの中で何を自分たちでアプトゲットしてるのかとか、
その上にアプリケーションが乗っかってて、アプリケーションがNPMなりバンドラーなり、
GoModですか、なんかその辺で山のようにインストールしていて、
その依存ツリーが人間の脳内には到底乗らないやつになってるみたいな、
これで脆弱性管理しろみたいなのとか、リスク対応しろみたいなのは本当に多分きつくて、
そういう意味では、このSBOMっていうフォーマットに全てを集約して、
そこで何か管理しましょうっていうのは、実現できるんであればいいのかっていう。
本当に実現できんのかな。
ある程度はいけるんじゃないですか、ツールが。
複雑さは別に変わらないよなと思ってて。
複雑なとき、例えば、実際に業務で回った例としては、
とあるOSSに結構クリティカルな脆弱性が出て、
それがどこで動いてるのか、動いてるなら影響のある動き方なのかを把握しなきゃいけませんってなったときに、
困るんですよ。わからん、どこに何が入ってるかっていう。
でもそれが、なんて言ったらいいんだろうな、どうなんだろう、
どこに何が入ってるか、それでわかるか、SBOMでわかるかもしれないけど、
でも、それが影響のある動き方をしてるのかとかは、SBOMでは多分表現できないと思うし。
そうですね。そこら辺は運用で回るのかっていうのは、
一つのチャレンジだよねっていう気はしますね。
SBOMって現物を自分で見てないからなんとも言えないんだけど、
何の上で何が動いてるみたいなのも表現可能なんですかね。
僕も勉強薄くなかったです。
極論だって、脆弱性対応の中において、ハードウェアレベルまで見に行かないといけない場合があると思っていて。
36:05
でもね、多分あんまりね、
いや、少なくとも、
いや、アムちょっと勉強してから言うよ。まさか言い飛んできそう。
いや、少なくとも、一個例としてあるのは、
GitHubのディペンダボットアラートとかあると思うんですけど、
ディペンデンシーを全部、ある程度メジャーなパッケージ管理ライブラリに関しては、
リストでUIって見れるようになってるんですけど、
あれをSBOM形式でもダウンロードできるんですよね、ポチッと押したら。
ダウンロードしてみたんだが、あんまり気の利いたフォーマットではなかったですね。
それはGitHubがそうしなかったのか、SBOMの限界なのかは、
持ち帰って勉強しますって感じなんですけど、
そのどのディレクトリで動いてる何性のライブラリでこのバージョンが入ってるっていうのは表現してくれないので、
単一のリポジトリだったらいいけど、
モノレポとかだと結局コード見に行かないとわからんってなるし、
その辺のギャップは自分たち埋める必要があるのか、
SBOMを生成するライブラリの質に左右されるのかは、
ちょっと見ないといけない。
もしかしたらギャップがあるから、
ギャップがあるからSBOM生成できるぞっていうSaaSたちが
群遊滑挙というか、売り込んでるのかもしれないし、
勉強しますって感じですね。
ディレクトリのことをちょっとしゃべれないかも。
そうですね、運用。
課題設定とそれに対してこうしたいっていうところは、
分かるようになったなって気持ちは個人的にはある感じですね。
SBOMが銀の段階になるかは、
ちょっと手を動かしてみてって感じかな。
ちなみにバックリンクのとこに1個、
SBOMを研究している他の記事を入れてるんですけど、
じゃあそっちも読みましょうか。
後ででも、記事のリスト作るときに順番が大変だなってちょっと思ってて。
まあいいか。
いいですよ。
ラスベガス開催の2大セキュリティイベント、
Black Hat USA 2024 & DEFCON 32現地レポート。
これはまたNRAセキュアのレポートですね。
これ僕まだ読んでないな。どんな感じですか?
これはですね、どんな感じだったっけな。
さっきのRSA Conferenceと同じようにセッションの紹介等がある感じなんですね。
ていうかRSA Conferenceの2位は今週分に入ってたわ。
だからまた後で出てくるね。
一緒に連続で読めばよかった。
ちょっと今の記事に戻りまして、
構成としてはRSA Conferenceの紹介と同じような感じで、
39:02
セッションをいくつかカイツマンで紹介してくれてるっていう感じなんですか。
気になったのはLLMのセキュリティとかなのかな。
Practical LLM Security Takeaways from Maya in the Trenchesっていうセッションのメモがありますね。
NVIDIAの事件を元に解説をしてくれてるみたいな話。
結構なるほどなーって一番思ったのはガードレール経由での情報流出ってやつかな。
LLM入力を事前に検査するガードレール、
ブラックリスト等の存在自体が情報漏洩につながる可能性っていうのを書いてくれてて、
例えば通常の応答とブラックリストに拒否された際の応答の逆ら推測可能みたいな。
ブラックリストの中身が推測できるから、
この機器をこんなんブラックリストに入れとるぜっていうのが外から分かっちゃうケースがあるんじゃないかっていう話。
これはおもろいな。
でもなんか原理はさ、もうそのLLMが生まれる世界、前の世界でもうあった概念ではあるけど。
なるほど。
まあラグね、ラグはそうだね。
あとは、サプライチェーンの話か。
どこだっけ。
Uncovering supply chain attack with code genome framework。
ジェノム遺伝子ですか。
うん。
これは書いてある通りなんだけど、
プログラムの計算セマンティックスをもとにプログラムの遺伝子情報を生成することで、
メタデータに依存しないプログラム検証を可能にするフレームワークに関するセッションです。
背景としてあるのが、サプライチェーンリスクの対策の限界の話が挙げられていて、
SBOMが注目されているけれども、SBOMはソフトウェアコンポーネントやそれらの依存関係を機械処理可能な形で一覧化したもので、
解決策の一つとして普及施設あるねみたいな話が上がっていて、
ただプログラムに付与するメタデータを用いてプログラムを管理検証する方法は、
メタデータと実際のプログラムの挙動に乖離が生じた際に破綻してしまいますっていうのを書いてくれていて、
SBOMにも限界があるよねっていうのを書いてる。
特定のサプライヤーが悪性コンポーネントを仕込み偽装されたSBOMを作成した場合、
上流のソフトウェア作成会社や利用者において悪性コンポーネントの有無を特定することは非常に困難ですよっていうのを書いてるっていう。
中身はだから解析すれば、何が起きてるかとか何が入ってるかとか分からなくはないけれども、
42:06
全部解析するので全然現実的じゃないよねっていうのを書いてくれていて、
なので実際の振る舞い、多分振る舞いを見て意味ないよって書いてくれてるから、
振る舞いじゃないんだけど、どういう動きをしてるかどういう動きをするプログラムなのかを見て、
なんて言ったらいいんだろうな、あるコードとあるコードが同じだよねっていうのを多分類似してるよねみたいなのを遺伝子情報的な形で表現できるようにするっていう話じゃないかなって思うんだけど。
なるほどですね。
多分でもこのやり方というかこのアプローチ自体は、多分現流にマルウェア解析があるんじゃないかなと思っていて、
マルウェア解析って要はこれとこれが可計図的に親子関係にあるよねみたいなのをやるんですよ。
なのでなんか多分現流はその辺なんじゃないかなと思うんだけど、結構興味深いアプローチだなというふうに思いました。
なんか理屈はふんわりわかったが、頭良すぎるな。
おもろいね、なるほどね。
いやー確かになー、SBOOM、いやーこれはそうだなー。
破綻、なるほどね。
SBOOMの信頼性ってどこにあんのみたいな、誰が担当するのみたいなのは確かに解決されてないと思っていて。
間違いないですね、今は。
原理上保証できないんじゃないかなー。
だからその、動作してる環境から抽出するしかなくて、でもそんな方法ないよねっていう。
あるいはだから自己ファイルの署名と、SBOOMの署名の位置を確認するみたいな話になるのかな。
性的な、分かんないな、なんか領域ごとに違いそうだな。
ただ自己ファイルに一個にまとめられるんだったらそれでいいけど、でも。
実際は多分そうじゃないというか、分かんないけど。
可動してるOS上の。
OS側のlibc使ってますとかだったらだって、そんなの常に変わるし。
そうですね。なるほどね。
だから自己ファイル1個のその中に含まれてるのは、これだよっていうのは多分都度作るしかないんだろうな。
えー、おもろいなー。
なるほどです。
おもろお記事ですね。
いや、これ僕一人で読んでたら完全に理解したって顔をして閉じてただろうな。
そんなことないっしょ。大丈夫。
そんなことないか。ちゃんと読めばわかるか。
はい。
ありがとうございます。
えーと、じゃあ次。これね、収録始まる前に見つけて追加したんで読んでないんですけど、
45:04
読むというか読み合わせるぐらいでいいかなと追加したんですけど、何かっていうと。
これ来週でいいんじゃない?
あ、来週にするか。
今日の記事だから。
あれ、ちょっと待ってて。今日のこれで入れて、今日のとこに入ってくるのはなぜ?
おかしいですか?
おかしい、おかしいです。
あー、違う。これはフィルターのせいですね。
フィルターのせいか。フィルターのだからグループ倍が効いてないのかな今。
あー、そういうことか。
意図的に消してて。
そうそう、だから今日見なきゃいけないのは、先週いつ収録したっけ、木曜だよね。
木曜ですね。
木曜か、だから先週の木曜からこの間の日曜までだから、15日までだね。
なるほど。
増えたよ。
増えた?
増えてないよ。増えてない増えてない。増えてないけど、うん、大丈夫。
じゃあ、来週。
だから、RSA Conferenceの2がここに入ってるのもやっぱおかしくて、良かった良かった良かった。
来週だったよなって思ったんだけど。
なるほどね。
ちょっと後でノートにずいに書こう。
はい、じゃあ次行きましょうか。
もしかしたら来週読もうと思ってたのが、もう読んじゃったかもしれないね。
まあ、いいんじゃない?
あの、まだ2回目なんで。
ちょっとね、ガタガタしとるけどしょうがないね。
専念していきましょう。
これは、あ、Google、なんかUIが崩れてる。
いや、崩れてるか、崩れてるなこれ。崩れてるよ、そんなもんじゃない?
これ、僕読んでないっけな、これ読んだと思うんだけど。
あ、M1っていうのが書いちゃってる。
ああ、なるほどね。
URLのそこ消せば。
ああ、モバイル、はいはいはい。
モバイルのなんか多分あれだね。
うん、うん、うん、理解です。
えっと、New Pass for Hibern on the WebっていうGoogleセキュリティブログの記事ですね。
これ、僕読んだ気がするけど、あんまりわかんねえなと思った。
いや、私、僕もそれで完全に理解したっていう顔をして閉じた系の記事なんですけど。
そもそもなんかポスト漁師暗号について何も知らねえなっていうのはちょっと思って、
さすがにちょっと追いかけないとまずいなという気がしてきたんですけど。
何の話かっていうと、カイバーっていう鍵交換のアルゴリズムじゃないんだよな、鍵交換のプロトコルって言えばいいのかな。
はい、その新しいメカニズムがChromeに入りましたよっていう記事です。
今使われている鍵交換方式がやっぱり数学的混乱性に依存する、
48:02
例えば素因数分解とか楕円曲線暗号とかへの依存度がすごく高いので、
鍵交換でも普通の要は暗号アルゴリズムだけじゃなくて、鍵交換においてもポスト漁師暗号時代のことが考えられてるっていうのは前提としてあって、
カイバーっていうのは格子暗号ベースのキーエンカプセラーションメカニズムらしいです。
そもそも格子暗号知らないなみたいなのはちょっと思っていて、
時代はもう、そういう時代はすぐそこまで来てるなっていうのがこういうのでよく分かるなと思うんで。
そうですね。
これなんか、対漁師、漁師コンピューターに対して耐性なるアルゴリズムを入れるっていうアップデート自体は結構前にあった気がしてて。
ちょこちょこね、やってるよね。
即例が、そのアルゴリズム、方式がアップデートされたって話なのかな?
ちょっとね、よく分かんないね。その辺の経緯はね、全部把握してないんだけど。
うんうん。
まあでも、エクスペリメンタルなものを100%Chromeディスクトップでは。
っていう話なのかね。
じゃあ、もともとトレアルしてたものを本当にしたような。
そういうことですね。
一回なんか突っ込んで何か壊れて。
取り下げた?取り下げてないのかな?
まあでもなんかドタバタしてたから。
その辺ちょっとやってますよっていう進捗の一つではあるのかな。
で、ちょうど5月に暗号の理論と技術っていう漁師時代のセキュリティ理解のためにっていう本が出てて。
これを読めばこの辺の話が全部分かるのかもしれないんだけど。
なるほど。
いや、暗号系の本はね、しんどいんだよね、読むのが。
すごい暗号入門みたいな本読んですごい満足しちゃいました。
いやー。
数学分からないもんだからなんか結構しんどくて。
そうそうそうそう。
あるライン越えるとなんか。
そうなんだよね。
大学通い直したいなみたいな気持ちが。
なんなら高校からやり直したい、この辺の話の関しては。
間違いない。
いやー。
はい、という話でした。
ありがとうございます。
このGoogleセキュリティブログはちょっと守備範囲外だったんで、サブスクリプションしておきました。
ありがとうございます。
次は。
次。
働きたくない人の脳内。
直接セキュリティは関係ない話なんですけど。
ちょっとぜひこれを題材に話してみたいなと思ったんで入れてます。
この人PDMなのかな、プロダクトマネージャーなのかなと思うんですけど、
プロダクトマネジメントをする中で新規プロダクト開発のなんかゲートキーパーみたいな役割を一時期果たしてましたよっていう話で、
51:09
こういう問いかけを経て、やるかやらないかの判断をするよっていうのを紹介してくれていて、
いくつかなんか問いがあるんですけど、それが5つの問いがあるのかな。
オペレーションで大体可能か、市場にあるプロダクトで大体可能か、プロダクトが競争優位性につながるか、
SLA定義に成功した保守が可能か、RYが当てるかみたいな。
あとは今やるべき理由が明確かっていう全部で2,4,6個が質問があって、
ここまでの全てのゲートを取り抜けた場合、念のためもう一周してみて、それでも同じ結果だったらやるっていう。
できるだけ開発をやらずに済むんだったらその方がいいよねっていう話だったり、
何を話したかったかっていうと、このマインドセットのプロダクトマネージャーと一緒にプロダクトセキュリティに取り組むっていうのを考えたときに、
どうしたらいいんだろうなっていうのをちょっと思った。
なるほどね。
特にきついなって思ったのが、RYの話とプロダクトが競争優位性につながるかっていう話と、
思っていると今やるべき理由が明確かっていうとこもそうなのかな。
なんか、こういうPDMに限らず、なんていうか、あくまでN1の声なんですけど、僕というN1の声なんですけど、
プロダクトセキュリティをやっていく中で考え、プロダクトセキュリティを開発プロセス、開発チームと一緒に開発案件としてやるという前提に立つ、
立ってる時点で結構負け戦になりがちだなっていうのを正直思っていて、
なぜかっていうとなんかちょっと性質が違うというか、
例えばリファクタリング、リファクタリングはまだロジックこじつけられるんだけど、
セキュリティってなんかどう足掻いても、事業上のリターンをこういうところで得ましょうとか、
なんでしょうね。
事業上のリターンには繋がんないんだけど、例えば開発メンバーの生産性なのか、社内の、なんかここの部分に実は効いてきて、
で、それって回り回って事業に効くよねみたいなロジックを立てようと思った時に、なんかどうしても繋げられない気が、
54:05
繋げられないことが多いし、繋げられたとしてもなんか距離がありすぎて、
なんていうか、他の普通の開発タスクとか、そうじゃない、機能要件のタスクと並べた時に、
優先のレースで絶対負けるんですよね。負けやすいと思っていて、
で、なんで、なんかその、普通の開発プロセスで、そのプロダクツセキュリティに文脈での改善をやりましょうっていうのとは、
なんか別の切り口が必要なんじゃないかっていうのが、個人的には思っていること。
で、じゃあそれどうやるのかっていう部分は結構、個人的には模索中です。
なんか一つ、まあ組織の規模感とかにもよるんですけど、
今個人というか、うちの会社とかでやろうと思ってるのは、
まあ二つやり口があって、一つはなんかその、
ベースラインであるべき取り組みに、ちょっとずつインストールしていくっていうのがまず一つで、
例えば、何でしょうね、コードを書く時にテストを書きましょうって、
企業とか組織とかチームの風土によっては、インストールしなきゃいけない場所があるのも十分承知なんですけど、
ある程度成熟した開発チームとか、その開発組織であれば、
なんか、めっちゃ頑張って説得することじゃないと思うんですよね、文化が根強いとか。
まあやみこみにかけていたわけじゃないけど、その単体テストっていうものにこういう価値があって、
中長期で見た時に、リリースまでの速度が多少遅くなったとしても、
いられるリターンでかいですよみたいな、ある程度の共通認識があって、
じゃあまあなんか何も言わなくてもやりましょうというか、
なんかルールとかで別に強制されるまでもなくみんなやってくれるっていうところになってると思うんですけど、
プロダクトセキュリティの一定運用とか、これは守ってほしいみたいなところも、
そういうものと似たような類似した取り組みとして、
インストールできるものはインストールしたいっていうのがまず一つ。
具体的に言うと、うちとかだとなんか、何でしょうね、リネベートポチポチいい感じの設定にして、
自分が見てるプロダクトに関しては、リリースノート読んでポチポチ押して、最新にしようねみたいな。
それはなんかセキュリティ以外の旨味もあるから、結構インストールしやすかったっていうのもあるんですけど、
例えば一例としてはそういうものとかはやりやすいっていうのと、
あともう一つは、デカ玉とか、中粒大粒はトップダウンでやるしかないかなって気はしていて、
57:00
なんかその、ごめんなさい、先聞きたいな。
先話すと、なぜトップダウンかって言うと、トップダウンって言葉ちょっとなんか、
興味反応出る人いたら申し訳ないんですけど、しょうがないと思ってて、なぜなら、
自分が現場の開発エンジニアだったことがあるんで、すごくよく分かるんですけど、
別になんかそのプロダクトセキュリティの文脈でやるべきことを、
ある程度優秀なソフトエンジニアとかPDMであれば、別に理解できないわけでは絶対ないと思うんですよ。
それでセキュリティ的に大事だよねとか、なぜやるのかもう説明したら全部分かってくれるはず。
なんだけど、でも彼らにはその事業上求めなきゃいけない、KPIなのかOKRなのか、
訂正的な目的なのか、リリース期限なのか、何か分かんないけど、
常に何かを目指してるし、前に言ったら何かに追われてるっていう状況の中で、
そこに直接相関しえない、大事なんだけどっていうものを、
自分たちの意思で自分たちのチームにねじ込む。で、そのねじ込むために、もしかしたら他のそのチームが関わるステークホルダーに対して、
説明をしなきゃいけないっていうところにコスト払えるかっていうと、結構しんどいことの方が多数。
で、それを、たまたま得点のチームがそれできたとしても、
他のチームも等しく同じように、セキュリティチームが横串でこれやってほしいっていうオーナーシップを持つチームに投げていったとして、
毎回毎回うまくいくかっていうと、うまくいかないよねっていうのを持ってて、
そうなるんだったら、トップダウンで、トップっていうのはCTOとかっていうよりかは事業責任者と握りにいって、
事業でこういう部分が大事なのはわかるけど、このタイミングでこれでこういうこと、まずいことが起きるとか、こういうリスクがありますっていうのを理解してもらった上で、
どっかにねじ込むっていう、ステージじゃないけど、っていう風にやらないと、やらないといけないというか、そういうのが一つ手なんじゃないかなっていう。
結構そうなるよなと思っていて、最終的にはどう統制を効かせるかっていう、ベースラインにどう組み込むかっていう話と、
いかに組織の目標としてそれをねじ込んでいくかって話になっちゃうんだけど、ちょっと残念だなって思うのと、
なんか、ディスアグリアンドコミットってやってくれるんだったらいいけど、なんかすごい懸悪な関係になりそうだなと。
もっと言うと、1PDMがそうですよって話と、組織のトップがそうですよって話だと、全然レベル感が変わってくると思っていて。
そうだね、そうだね。
組織のトップがそうですよってなったら、もうなす術ないじゃないですか。
なす術ないです。
そう。
ないと思います。
じゃあ何もやれないのかって言ったら、なんかうーんってなるし。
いやー、それで言うと、個人的に結構、理想を追いかけるマンかもしれないが思ってるのは、やっぱその、一番トップがやっぱ、
1:00:05
プロダクト、セキュリティ領域にちゃんと重要性を認識してるかとか、関心を払ってくれてるかはマジで大事だと思ってて、
なんか最終的に何をやるかっていう、その優先順位でどうしてもコースつけがたいってなった時に、
意思決定者のツリーを上っていくと、どの会社も絶対経営層にはたどり着くわけで、
でもその経営層が、最終的にじゃあ、極端な話ですけど、揉めに揉めて経営会議に持ち込まれましたとなった時に、
経営メンバーがセキュリティに対してそんなに解像度がないとか、なんかその自社の状況わかってなかったら、
多分、じゃあ事業所の方まずやりましょうか、セキュリティはいつかやりましょうってなるじゃないですか。
うん。
だからトップを握る、握り続けるっていうのはめちゃくちゃ重要だし、理想は、なんか元々そういうところに関心を持ってくれてるとか、
あとはそのセキュリティに詳しい人が経営メンバーにいるとかが理想ではあって、ただ理想通りの会社なんて多分ほぼないんで、
僕が1メンバーとしてできることは、正しい温度感で、ここはちゃんと見てくれってアピールをしたり、
あとそのあまり距離を遠くならないような組織体制を維持するとか、そういうのはなんか中長期でじわじわ効くよなーって信じてはいる。
いいですかね。
じゃあその分野でさらにややこしい話をぶっこぶと、さっきのそのプライバシー保護を売りにできる企業は10%に満たないっていう話がありましたけど、
じゃあ例えばプライバシー保護に関わる機能をこのPDMのマインドセットでやるっていう判断に至るまでって多分相当強力な環境要因なり開発が必要だと思っていて、
今までここまで話してきたのって割とミニマムをどう実現するかっていう話だと思っていて、
プラスアルファの世界に踏み込もうと思ったときに、それを売りにしたいっていうところまで持っていきたいときに、じゃあどうやってそれを組み込むのっていうのはすごく思った。
例えばメッセージングアプリでエンドツーエンクリプションの必要性をどう認知してもらうか。
それがなぜ売りになるのか、なぜ必要なのか。そんないらないじゃんって言われたら、
そうかもしれないですねってなっちゃうんだけど。
でもここまで来たら結構、セキュリティに携わる身としては身も蓋もないこと言うと腕の見せどころなんじゃないですか。
これで今、話したい内容のスタートラインとか持ってきて。
その文脈で、じゃあどうやってこういうマインドセットの人たちと共生をしていくのか。
プロダクトセキュリティに携わる人間として一緒にやっていくのかっていう。
1:03:02
なんかすごい胃が痛くなるなって思った。
なるほどね。
いやーでも難しいなー。
なんかすごい、本筋からずれてたら言ってほしいんですけど、
まず、言ってしまうとなんか結構ケースバイケースで話したくなっちゃうから、
あえてちょっと抽象化するんですけど、
別にセキュリティだからとか限らず、
そもそもベースにないと個人的に厳しいなって思うのは、
双方向のリスペクトはまず絶対にないと無理だなって思って、
だから向こうに、会社においてセキュリティに取り組む人に対して、
一定のリスペクトとか重要性を理解してほしいっていうウォントもあるし、
逆にこっち側としては、
事業にフォーカスして取り組んでくれているPDMとかソフトエンジニアに対して、
彼らにはミッションがきちんとあって追っかけているものがあるっていうのを、
きちんと理解すべきっていうのが、
まずスタートラインとしてはあるべきだと思っていて、
その上で、その前提に立てるなら、
あとは、どれだけいいプロレスができるかとか、
どれだけいいつま弾きができるかなのかなって、
個人的には感覚としては思っていて、
それを言語化していくとどう…難しいな。
まあでも、肌感覚としては個人としてはそう思っていて、
そのプロレスをやるときに、
さっき言った遊びも蓋もないこと言うと、
腕の見せ床っていうのはあるよなと思っていて、
こっちはこっちで、
なるべく何かをやって欲しいと思っているときって、
僕らの立場としては、
何かのリスクを低減したりとか、
場合によっては何かの価値をお客さんに届けたいっていう、
ワットがあるはずで、
そのワットをより正しい解像度で理解してもらうために、
必要な情報をきちんと丁寧に揃えていきましょうっていうところは、
やらなきゃいけないし、
そのときに情報のフォーマットとか、
持ってこれる情報みたいなのとか、
自分のスキルとか経験に依存してくるから、
それがいわゆるセキュリティエンジニアとしての、
セキュリティエンジニアってスコープ広すぎですけど、
僕みたいな立場のセキュリティエンジニアの実力に、
アバウトイコールになってくるのかなっていうところとか、
あとは逆に、
自分たちが必要な情報を揃えるっていうのも必要だし、
向こうから、
リスペクト、事業上やってる人に対してリスペクトを持つ以上は、
1:06:00
その人たちがどういう景色を見てるのかっていうのを正しく理解するために、
必要な情報をきちんと引き出していくっていうのも、
平たく言ったらコミュニケーション能力になってしまうんだが、
でも大事な要素だよねっていう気がします、個人的には。
どうですか?
全然違和感はないというか、そうだよなって思うんですけど、
相互のリスペクトっていうので、
僕の愛すべき新卒で入った会社である、
NRIの2015年の入社式の祝辞で、
ミューチュアルリスペクトっていうのが言われてて、
それを思い出してたんですけど、
結構大事だなって思ったのと、
あとは個人でそこに相対するって結構しんどいよなって思って、
組織で解決できるのがないのっていうので、
ちょうど全然別の記事で流れてきて、
面白いなって思ったのが、
サイロカとお豆腐屋からの回答ってやつで、
気になるワードだね。
中坂ミヤっていう豆腐屋さんが、
数値目標を設定しないっていうのをやってるらしくて、
すべて社長が数字の責任を取りますよっていう形を取ってるらしい。
さっきまでの話の文脈で言うんだったら、
PDMを数字のしがらみから解き放ってあげることで、
じゃあプロダクトがどうあるべきなんだっけっていうところに、
フォーカスできるようになるんじゃないかなみたいなことをちょっと思ったりした。
なるほどね。
そうするとだからプラスアルファの部分っていう、
さっき話したところに踏み込みたいですって話になったときに、
プロダクトとしてじゃあそれって本当にそうあるべきなんだっけ、
それがユーザーのためになるんだっけ、
顧客のためになるんだっけみたいな話が初めて議論できるのかなって思って。
なるほどね。
確かにな、構造から、確かに。
それで言うとちょっと思ったのは、
もはや組織デザインとか事業デザイン、
もしくは事業に対しての組織デザインの話になるかもしれないけど、
PDMがこうならずに済むような構造を作るっていうアプローチは一つありな気はしていて、
カルチャーだよな。
カルチャーもらしい事業モデルもあると思う、個人的には。
例えば、別に言っても大丈夫だと思うんですけど、
僕もともとメルカリで働いてましたけど、
僕が働いてた頃のメルカリの事業モデルって、
シンプルではないんだけど、厳密にはシンプルではないんだけど、
シンプルに考えられるように、シンプルに考えやすくて、
1:09:03
それが社内の構造にも生きてて、
結果として結構埋まらずに済んだしがらみがすごくあったなと思ってて、
具体的には、
メルカリの当時の、当時じゃないですよ、
僕がいた頃の話をしてるんで現在は知りませんけど、
手数料モデルなんで、取引が増えれば増えるほど儲かりますっていう、
もうただそれだけです。
そうなった時に、取引が増えるためには出品がまずないとダメなんで、
出品たくさん増やしましょうね。
出品だけあっても買う人がいなかったらダメだから、
買う人たくさん産みましょうね。
それだけ以上みたいな感じ。
ここに多分、細かいROIとかの余地が入りづらいというか、
究極的には出品を買う人増やすっていうのも、
買いやすくすれば増えるじゃんっていう話。
あえて柔らかく解釈するのは落ち着くはずで、
その前提に立つと結構、
その前提に立ってかつ、
そこに対して細かい市場を出さないっていう状態になると、
割とチームごとが、
それぞれのチームが自分の持つ責務に対してめちゃくちゃ真摯に、
それこそ遊びを持つじゃないけど、
向き合ってくれるし、
チーム間の、
何でしょうね、衝突も起きづらいというか、
なぜなら、最終的な目標は一緒だから。
っていうのが結構個人的には、
何だろうな、
事業モデルがああだったから、
働き方がああできたっていう感覚があって、
逆に、
働いてた別の会社の話を、
こっちは名前を出さないんかいって感じなんですけど、
出すと、
事業構造上、どうしても社内、
利害関係が生まれてしまうパターンって。
ちょっとイビルな方に走らざるを得ないっていうパターンだったんですね。
そうですね。
B2B2Cとかだとあり得るのかなって気がしてて、
今の会社の話じゃないんですけど、
2Cに立つ人は2Cのことを考えたいけど、
2Bに立つ人は2Bのことを考えたい。
利益がどっちから上がってるかっていうと、
単純な計算では語れないから結構複雑な、
本当にちゃんと構造化しようと思ったら複雑なことをしなきゃいけない
みたいな状態になった時に、
その末端のメンバー全員がそれを理解して動けるわけがないので、
2C側と2B側で何か機能のバッティングが起きた時に、
平行線を辿ってしまうというか、
共通の目的をデザインしづらいから、
じゃあ都度都度調整するのか、
それが何か行き過ぎると多分、
この記事のロジックが悪いとは僕は全くわかんないけど、
この記事みたいな悪いというか、
あんま本質的じゃないワークフローみたいなのを組むメンバーとかが出てきても
おかしくないかなって気がしてて、
実際過去に何かおもろかった、
1:12:01
なるほどってなったのは、
あのエンジニアに頼むと見積もりを3倍にしてくるみたいなことを言われてる人とかいて、
それは何かその人が悪いんじゃなくて、
多分なんていうか、
何らかの力学によってそうなっちゃってるっていうか、
そう、歪んでしまったというか、
それが何か個人の責任かっていうよりかは、
組織とか、組織のデザインとか、
事業がこういう風な構図になってるんだったら、
じゃあ組織をこういう風にデザインすれば、
うまく回るよねみたいなところ、
言うは優しいなんですけど、
そういうとこに目を向けるっていうのは確かにいいな、
いいかもなっていうのは思いました。
なんかね、主張としては別にマットだからさ、
そのすごく燃えるというか、
この元の記事の方の主張もそうだけど、
そうだね、マットだね。
まあ、という話でした。
いや、おもろいこれ。
うん。
これはおもろいですね。
でも、何かどんな組織で働きたいか、どんな組織であるべきか、
プロダクトセキュリティに関わるものとして、
どういう心構えであるべきかみたいなところに、
向き合ういい材料なのかなと思ったんで、
ちょっと紹介しましたが。
ありがとうございます。
熱くなっちゃったぜ。
じゃあ、次行きますか。
次は。
次はマクニカさんのフィッシングサイトに発表されるドメイン名の、
過去と現在っていうレポートですね。
近年のフィッシングサイトのURLにおけるドメイン悪用の、
ドメイン悪用の傾向について解説してくれている記事ですね。
なんで英語で表示されてるの、それ。
僕の多分ブラウザの。
ああ、そういうのか。
日本語版もあるので、ぜひ日本語。
てか元が、ベースが日本語版なんじゃないかなと思った。
画像日本語だもんね。
サマリーとしてはいくつかあるんですけど、
そんなに長いけどそんなに長くないんで、
元のレポートもぜひ読んでほしいなと思うんですけど、
URLの利用の仕方、
ドメインの利用の仕方に変化が見られてるよっていう話で、
ブラウザ名を模倣したURLはちょっと時代遅れになってきていて、
ブラウザ名を含まないフィッシングURLが主流になってきてるよっていう話とか、
フィッシングURLではドメインを悪用せずにサブドメインを悪用する手法が主流で、
要はサブドメイン部分で何か、
まあいいや、何でもない。
ちょっと待って、今言ったこととちょっと矛盾しないって話になっちゃうんだけど、
サブドメイン部分にそのブラウザ名とかを仕込むよみたいな話とかが書いてあったりとか、
DDNSのサービスとか、
短縮URLのサービスを悪用する手法が増加してるよっていう話とかをまとめて書いてくれてます。
なるほどね。
それだと検知がしづらいとか、なるほどなるほど。
1:15:03
なるほどですね。
まあいろいろ書いてはくれてるんですけど、
まあ個人的に教員深かったのが年次推移の部分で、
ここに上がってるのって観測された数でしかないので、
必ずしも被害件数とは一致しないんだけれども、
2022年にわーって燃えたところとか、
いやそれじゃなくてね、レポートを開いてもらった方がいいんだよな。
ごめんなさい、なんかすごい聞いてるだけの人には全然わかんないと思うんだけど、
その辺からの話ですね。
6ページあたりからの話で、
2022年にわーっと燃えたところ、
2023年にわーっと燃えたところとか、
そんな感じで各サービスごとに波があるんですよね。
それは最低限言えるなと思っていて、
ただ波自体に特定の周期があるようには見えないので、
日和み的に狙いやすいところとか、
旨みのあるところを狙ってるのかなーみたいなのはちょっと気になったこと。
なるほどね、確かに。
すごいちゃんと説明できたりするけど、面白いですね。
結構ね、件数の集計をして傾向をまとめてくれてるのがすごく面白いなと思って、
このレポート自体はすごく貴重なものだなと思いました。
あとはURLそのものの開く用の傾向がちょっと変わってきてるよっていう話が面白かったんだけど、
サブドメインを開くよって話がそっか。
サブドメインを開くよっていう話はサマリーだけ見るとわけがわからないんだけど、
これメモに残してたわ。
なんて言ったらいいんだろう。
単に正規サービスのサブドメインに乗ってくるっていう話でしたね、これは。
さっきのDTNSのサービスとかのサブドメインに乗っかってくるっていう話がまさにそこで、
DuckDNSっていうDNSのサービスがよく使われてるよって話で、
そこは特定のDuckDNSのサブドメインに多分ユーザースペシフィックなものを指定できるっていうサービスだったはずで、
そんな感じでそこを利用してるよって。
サブドメインを開くよって書いてるからサブドメインに全部開くもないだろうって思って、
すごいなんかもやるんだけど。
なるほどね。
ちょっと書きっぷりが技術的にはちょっともやる書きっぷりだったりしてるから、
ちょっとあれなんですけど、
話を戻すと検索の集計をして傾向をまとめているのは面白くて、
このURLの開くよの傾向が変わってきてるのが、
背景っていうところまでは正直このレポートからはパッと読み取れなくて、
あんまり人は意外とURL見てないから、実はコストかける意味がないっていう話なのか、
正規URLを模したものは早期にテイクダウンされがちなのかどっちなんだろうと思ったら、
書いてあったこれもう。
もうだめだ。若干記憶から飛んでるんだけど。
1:18:00
全体的にちょこちょこ矛盾を感じるんで、ちょっともやる感じがするんだけど、
混乱するんだけど読んでて。
ホモグラフアタック的なのは多かったらしいんで、
たぶん正規URLを模したものは早期にテイクダウンされがちだから、
たぶんそういう形に倒してるっていう感じっぽい。
なるほどね。板値ごっこっすね。
ちょっとなんかね、サマリーの仕方がぐちぐちになってたけど、
面白いレポートだったので、ぜひ見てくださいっていう話でした。
ありがとうございます。意外とURL見てないとかはありそうだけど、
そういうの検証した人とかいない?検証した会社とかないのかな?
どうなんすかね。
さすがにそれ引っかからんやろみたいなURLっていろいろ来たりもするから、
実はみんな読んでないのかもしんないし、見てないのかもしんないし、わかんないけど。
なんか今手元でスマホ開いとるけど、
Androidとかだとなんか開いてスクロールしちゃうとURLバーって隠れたりするから、
いやでもわかんねえな。なんか意識的に見てるか見てないか自覚的じゃない?
いやなんか見ない瞬間もある気がすんだよな。
なるほど。ありがとうございます。
ちょっと読んでおこうか。
いや、今週重いな。
あと、
7個、8個。
7個。
うん。
サクサクペース上げていきますか。
はい。
次は、
でもね、次も重いんだよ。
なるほど。
パスキーは問題があるが、パスキーはもっとある。
っていうDHHさんの記事でございますね。
かなり有名な。
記事自体はそんなに長くないんだけど、
Windows Helloのパスキーで入ったユーザーが、
iPhoneで同じサービスを使おうとすると、
詰むっていう。別に詰みはしないんだけど、厳密には。
よくわかんなくなって困っちゃうねっていう話。
そうですね。
なので、そのなんていうか、
そのよくわかんなくなっちゃった状態から救済するために、
いろいろユーザーに教えるぐらいだったら、
パスワードマネージャーを使うように教えたほうが早いんじゃない?
っていうことを書いてくれて、自重してる。
エンジニアの立場だったらそれはそうって感じだが、
一般人に使ってもらうっていうのはどうなんだろうな。
プラットフォーム間の同期、時間の問題なんじゃないかって勝手に思ってるけど、どうなんですかね。
そこをやんないと、なんていうか、
結局、達成したいところに行けないし、
1:21:04
双方で連携することにインデミリティあるのかな。
どっちがプラットフォームをまたいで鍵の同期がされる。
そういう未来が来るのか、
それともそもそもプラットフォームに依存、
今例えばマイクロソフトとかアップルとかグーグルとか、
そういうところに依存しないパスキープロバイダーをみんなが使うようになる未来が来るのか、
どっちなのかはちょっとわからない。
それは正直わからない。
わからないけど、もっと言うと、
鍵を追加するっていう手順がみんなにまだ浸透してないっていう話でもあると思っていて、
そこがなんとなくクリアされてくれば、みんながそこを分かるようになってくれば、
別にプラットフォーム化をまたいでわざわざ鍵を共有する必要はなくなるとも思うし。
確かに。
なるほどね。
いやー、悩ましさしかないですね。
なんかこの、なんていうか、これは僕はツイッターで、
テッペイエスさんっていうサイボーズの開発者の方がこれをツイートしてるのを見て、
ツイートじゃないんだけども今、ポストしてるのを見て、僕が見つけたんですけど、
テッペイエスさんはパスワードマネージャーを使わせるって、
どうやったらできるのっていう、現実的にそれって無理じゃないっていうことを言っていて、
僕もそこが完全に同意で、
なんていうか、結局は使う側のリテラシーの問題なのかなとは思うんですよね。
感覚的にパスワードマネージャーをみんなに使ってもらうっていう試みが全然うまくいかなそうだなって思う一方で、
パスキーを可能な限り積極的に使うっていうのは、
サービス提供者としてはできる選択肢の一つとして絶対入るわけじゃないですか。
できることをせずにユーザーに責任を転化するっていうのが、
果たしてあるべき姿なのかっていうのはちょっと悩ましいところだと思っていて、結構モヤモヤする。
スタックするポイントが多いっていうのもまさにその通りだと思うんで、
その辺のバランスがすごく難しいのは分かるんだけれども、
もはやこの時代にパスキーに倒さないっていう選択肢があるのかというとないんじゃないかと思うし、
なんかいい感じになってくていいなっていうすごいふわっとした結論なんだけど。
なんかシンプルに今、勝っときですよねって気はするんですけどね。
1:24:05
言わんとすることは全て分かる。
DHHさんが言わんとすることも分かるし、
分かるけど、そうなんですよね。
じゃあイタチごっこするんですかっていうパスキー使わずにユーザー守れるんですかっていうところに対しての回答がないになれば。
ただパスワードマネージャー使ってくれるんだったら、
その実質パスキーと保護のレベルは強度は違うけれども、
実質パスキーとそんなに変わらないというか、
そのドメインのチェックとかをしてくれるわけだし、パスワードマネージャーも。
そうですね。
そんなパスワードマネージャーって、
GoogleのパスワードマネージャーとかをAppleで使うとかできるのかな?
それも問題で、今みんなが使いやすいパスワードマネージャーが何かっていうと、
iCloudのキーチェーンとか、Chromeのパスワードマネージャーとかだと思ってて。
そうっすよね。
プラトンをまたごとしようとすると、
ワンパスワードを自分で使って全部の端末に入れとくとか、
ビットワーデンを自分で使って全部の端末に入れとくとかをしないといけないわけで、
その辺をだから、
それをだからユーザーに責任を転嫁してるっていうふうに僕はさっき言ったんだけど、
仮にできたとしてもあんまり、
なんていうか、パスキーと同じぐらいスタックポイントはあるんじゃないって気がする。
どうなんだろうな。
そこをだから、
なんていうか、iCloudのキーチェーンはプラトンをまたげないからみたいなのを気をつけられる人って別に、
最悪別にスタックしないと思っていて、
ごく普通の大多数の人がそれを解決できるかっていうと多分できないと思っていて、
サービス提供者としてはそこは知りませんっていうんだったら、
それはなんかちょっとスタンスとしてどうなのって思うし。
なるほどね。
いやー、
なんか、
すごいこの記事流れてきたときの個人的なファーストインプレッションは、
一緒に頑張ろうよっていう。
DHHがそういう感じじゃないのはなんか噂は聞いてましたけど、
一緒に頑張らんっていう。
まぁでもなんかそのソフトエンジニアだから、
そのパスキーの意義とか対義を理解してくれてるって思わない方がいいっていうのは普通にあるだろうな。
自分はなんか今の立場になるから、なってるから、
1:27:00
価値となんか意義がわかるけど。
なるほどね。
この記事1年後ぐらいに振り返りたいな。
1年経てばね、いくつかの回答は出てるんじゃないかな。
1年経ったら総集編みたいな感じで、1年間読んだ記事で印象深かったものを拾って、
確かに。
読み返す回をやればいいんじゃない?
確かに。やりましょう。
やりましょう。
予定された企画がちょっとずつ増えていく。
うん。
ありがとうございます。
これはスキップでいいや。
ちょっと読んでないんで。
あと内容詞のほうもいいんで。
しかも8月だしね、出たの。
確かにね。
次がGDNETさんの記事ですと、
セキュリティ強化のためにLinux初心者が知っておくべきコマンド6000。
クソ軽いやつ。
別に記事がダメとかそういう話じゃなくて、
ライトに紹介できるやつ。
これめっちゃスルーしちゃった、この記事。
面白いコマンドだったんですか?
単純に僕使ったことないやつで、
setfaclっていうのが、
知らない、使ったことないと思って。
知らない。
ファイルのACLを設定できるよっていうコマンドらしくて、
要はパーミッションではなく、
パーミッションとは独立して、
特定のファイルへの、
特定のユーザーに特定のファイルへのアクセス許可を与えるっていうことができるらしい。
知らなかった。
便利だと思って。
便利だってことなんだけどさ、
Linuxとか自分でもはやサーバーとかメンテセンスしなっていうのはちょっと思って。
はいはいはい。
これなんか、最近森多子さんの書いたコンテナセキュリティ本を読んでるんですけど、
それになんか、
Linuxのセキュリティ機構ってめちゃくちゃ、
なんか5種類ぐらいの本で紹介されてて、
なんかどれかの、
どれかの裏側で、
各種ACで載ってるかもしれないですね、確かに。
このコマンド自体は出てきてないんだけど、
裏側そうなのかなとかちょっと思ったりしたな。
うん。
あ、でも違うか、seccompか、
LSMか、
いやーでもなんか、
そうっすね、そうなんだよな、
生で触んないから、
まあでも知識としては面白いですね。
うん。
そう、というだけの、
あれでした。
ありがとうございます。
あー。
昔からあったのかな。
どうだろう、
Linux拡張、
聞いたに、
なんか、
基本ACL、拡張ACL知らなくて怒られた件っていう、
記事がある。
いやーほんとごめんなさい、
インフラやー。
僕も知らなかったです、ごめんなさいって感じなんだけど。
1:30:00
インフラの人とかはさ、あるのかもなー。
うん。
あーそう、共生や節制業ね。
2018年にはすでにあるなー。
うん。
いつからあったんだろう。
CLDAC、
今度はセキュリティ本で紹介されてるな、
このACLのうち、
まあMAC、共生アクセス制御みたいなのは。
うんうん。
紹介されてますね。
うん。
あー、だから任意アクセス制御の種類のACLだから、
セキュリティ本、この本に出てきてないけど、
まあセキュリティ機構って感じか。
うん。
うん、ありがとうございます。
いやー、
ちゃんとするせずに、
目閉じた方がよかったな。
拾ってくれてありがとうございます。
地味地味記事だけど、そう。
へへへ。
よかった。
うん。
よっしゃー、
次。
GitHub Actions Veritable Type Squatting Exposing Developer to Hidden Malicious Cause。
ハッカーニュースの記事ですか。
はい。
これは、
まあよくある、
そのノードのパッケージ名とかでタイプをスクワッティングをやってるやつの、
GitHub Actions版を紹介している記事ですね。
あー。
いつから出てるのか知らんけど、
あー確かに出てきそうだなっていうのは、
これ読んで思った。
はいはいはい。
うん。
これ、
やだなー地味に。
いやっすねー。
なんかGitHub側で何か対策してくれんかなーとは思わんでもないけど。
うんうんうん。
うん。
なんか個人的にちょっと気になったのは、
このタイプスクワッティングっていう手法自体は、
もう昔からあるけど、
これってなんか人類にはもうどうにもできないのかなっていうのがちょっと。
うーん。
気になった。
うーん。
うーん。
なんか、
どうにもできないそうな気がしますよね。
正直。
どうだったらどうにかできるのかなー。
なんか入力インターフェースの問題じゃないじゃないですか、
多分これって。
うーん。
例えばだけど、
その思考をそのままインプットする入力インターフェースがあったとしても、
その綴りを間違えて覚えてたらタイプスクワッティングって多分成立するわけで。
うーん。
うーん。
なんか、
まあそりゃそうだろうって感じだけど、
いろんな場所でちょっとずつ防御策を立てて、
そうよく地道に頑張るしかないんじゃないかなーという。
うーん。
なんか一番根っこはやっぱもう、
これもなんか人間じゃないですか、タイプスクワッティングって。
人間の脆弱性でもう多分それはもうどうにもなんないから、
その前提に立たなきゃいけなくて。
うーん。
なっす。
それで言うと、
アクションズのケースだったら、
いやー。
いやー。
難しいな。
いや、アクションズは難しいな。
いや、例えばですけど、
Node.jsとかだったら、
その、
Node.jsの場合はサプライチェーン攻撃ですけど、
1:33:00
サプライチェーン攻撃においてタイプスクワッティングを狙ってるパッケージって、
無限にあるし定期的に上がってきて、
で、
まあ、
今のところNode.jsとNPMの世界にいる限りは有効の差がないんですけど、
バンされるのを待つしかないとか、
それぐらいなんだけど、
そのNodeのランタイムで、
Denoっていうランタイムが、
めちゃくちゃ有名なタイプスクワッティングのランタイムがあるんですけど、
Denoとかは、
セキュリティ面で、
その、
プロセスを実行するときに、
そのプロセスに渡す権限を制御できるんですよ。
だからデフォルトだと全然渡さないようになっていて、
例えばIoの権、
あるいはIoの権限とか、
Denoはあんま普段使わないんであんま詳しくないんですけど、
そういうところを制限するようになっていて、
なんで、
まあ、それだと防げないけど、
なんかそういう何個かを、
その、
デフォルトで占めるっていうのがあって、
どっかのタイミングで、
なんか変なこと要求してきてるぞみたいなことに気づけるようにするとか、
なんか、
地道だけど、
そういうの頑張るしかないのかなとか、
なんか構造上、
その、
なんかこれってタイプスクワッティングじゃなくても、
まともなパッケージの革をかぶった、
マリシアスのコートとか、
もうなんか、
なんていうか、
まあ本質は違うのかな、本質は違うかもしんないけど、
でもその入れちゃったらおしまいっていうのが、
なんかあまりにつらいというか、
入れちゃっても、
まあなんか、
2つぐらいボタン押さないと、
本当に危ないとこまではたどり着けないとか、
本当に大事な経験は渡さないとか、
まあでもそれが頻発したらみんなポシポシ押すようになっちゃうしな。
まあ、そうっすね。
それはそう。
それもそうだね。
やだやましいなあ。
まあアクションズの場合は、
まあこの、
これやってるコードみんなに聞かないとわかんないけど、
1つあんのは、
ベリファイドされたアクションズって概念があるから、
それだけに制限するとかは、
オルグとかがあったらオルグの設定で強制できたりするから、
それは1つ対策にはなるかも。
ああ、なるほどね。
ただベリファイも、
ドメイン所有してたら、
一応誰でもできるかな。
できるから、
あんまり意味ないな。
そう、向こうがそこまでやってたら防げないけど、
まあなんか、
そこまで作り込んでないマリシアスなやつとかは防げるかもしれない。
あと一応、
確かに。
使えるアクションズをホワイトリスト形式で管理することもできるから、
それもそうだけど、
結構つらいっす。
ちょっとね、コストがね、高そうだよね。
って感じっすね。
まあちょっとなんか、
このすごく原始的な手法がまだまだ刺さりそうっていうのが面白いなと思って。
1:36:04
スペルチェックとかできるんだから、
タイポスクワッティングじゃないこれ、みたいなサジェスチョンを出せそうな気がするんだよな。
でもなんか、
フォークされたプロジェクトとかですごい紛らわしい名前のやつとか普通にありそうな気がするし、
あとなんか、造語とかだと、
確かにね。
今タイポスクワッティングっていうのがそもそもだって赤アンダーラインついてるもんね。
そうだね。
その辺は限界あるよな。
ありがとうございます。
はい。
えーと、
これなー。
これは、
はい、クエスト初心って感じですけど、
意思決定に基づく初のオペレーションを追跡し、監査を効率化する話。
レイアエックスエンジニアブログの鈴木健吾さんの記事ですね。
はい。
これもセキュリティに直結っていう感じじゃないんですけど、
割と近しい領域の話だなと思って紹介してます。
大雑把に言うとなんか、決済をしましたみたいな、
証人の記録を、
なんだか意思決定を多分してるので、
決済をしたことと、
実際に例えば支払いが発生したこと、
そういうものを、
なんていうか、機械的に追跡できるようにして監査を効率化しましょうみたいな、
大雑把にそういうことを書いてると思います、多分。
いやー、
これだから監査しないといけないって前提があって、
そこに対してソフトウェアエンジニアリングでアプローチしてるって話なのか。
なるほどね。
ちょっとディテクションエンジニアリングっぽくなってきたねって話を書いてくれてて、
なるほど面白いなっていう記事でした。
なるほどですね。
ちょっと予習してきます。
ディテクションエンジニアリングは分かんないんだよなあんまり。
分かってないんだよな。
でもなんか、
僕も理解できないながら一通り記事は読んだんですけど、
なんか愚直で、
読みました結構。
課題に向き合ってるんだなあ。
はい、皆さんも読んでみてください。
はい。
これは、
僕が追加したのかな。
New Fastly Threads Research、
ちょっと長いんで走りますけど、
Fastlyから出てるイベント、
レポーティングですかね。
特にレポート自体は読んでみてくださいって感じなんですけど、
気になったことがあって、
それをメモしてなかったんだが、
サイバーアタックの観測をしましたよっていうやつで、
トラフィックのうち、
結構な割合が攻撃のトラフィックだったっていう記述が確かどっかにあって、
1:39:04
辛いなって思ったっていう記事ですね。
英語読むのすんげえ。
トラフィックの36%はBotから発生し、
残り36%は自動化ツールから生成されたリクエストになっています。
36%か。
36%は自動化ツールから生成されたリクエストになっていて、
通人されると、なるほどなって気持ちになったって感じですね。
あとワードプレイスが狙われがちっていうのも、
それはそうだよねっていうのとか、
IPアドレスも結構、
有効期限が短いやつをガンガン大量に使われてるから、
これどう対応すればいいねっていうのか、
僕はちょっとあんまり解像度がないところですけど、
対策考えなきゃねっていうところって感じですかね。
でもスキャンされてるものを叩き落としましょうみたいなのが本質じゃないような気はしていて、
うんうんうん。
これか。
そうですね。
登録しないと落とせないやつですね。
はい。そんな感じのやつです。
はい。
だいぶ座席になってきちゃった。
でもちょっとあんまりちゃんと読んでないんですよね。
ちゃんと読んでいきます。
ちゃんと読みましょう。僕全部読んできましたよ。
ありがとうございます。
この直前に追加されたのとか読んでないけど。
なるほどね。
僕がね、ちょっと今回触っちゃった。
これはね、もう5分、40秒ぐらいでいいんですけど、スキャンネットセキュリティの記事で、
業務委託コンサルタント経由でマルウェア感染しちゃって、
インシデントに繋がっちゃったっていう、
まあよくあるニュース記事で、
まあなんかその、なんていうか普通に思ったのは、
やっぱ業務委託の管理って大事だよねっていうのを改めてシンプルに思ったし、
まあその、半面教師にしたいなってシンプルに思った感じですね。
その実際にこのインシデント詳細は出てないんで、
その業務委託の人のPCもちゃんと端末管理をして、
ウィルススキャンソフトも入れてたのにやられましたなのか、
業務委託の人が勝手に使用PCをやりました。
使用PCを使ってやられましたなのかは、
ちょっと詳細わかんないんですけど、
まあ、個人用か。個人用っていうのはわかってるのか。
個人用でやられちゃいましたってところですね。
なんで、まあその辺の管理はやっぱなんか基礎であり、
1:42:02
まあ耳見たこでみんな言ってることであり、
まあでも大事だし、
まあ難しい領域でもあるよなっていうのを改めて思ったところですね。
べき論で言えばなんか社員相当のアクセス権を持ってるんだったら、
同じ、そのだけの措置を講じないといけないわけで、
実際それどれだけの会社がやってるのかっていうのは結構難しいところだと思うけど。
結構なんか、そうですね。
なんか赤いキャラ仕事する前は割と僕、
この辺のグラデーション付け方というか、
あんまり危機感なかったんですけど、
仕事するようになって、
まあ冷静にやっぱ、
まあそうですね、おっしゃる通りですね。
何を渡してんのか、
その人が何をできるのかに合わせて、
ちゃんとハンドリングがしなきゃいけないよねっていうのが
しみしみ思った感じですね。
はい。
で、あとはこれも僕かな。
これ最後すかね。
なんか最後これでいいのかって感じなんですけど。
メモちょっとちゃんと書いてないんで、
まあ読みますけど。
インプレスウォッチの記事で、
何で見つけたんだっけな。
多分なんか流れてきたんですけど、
オンライン詐欺の最新手口17種と、
その対策をまとめてチェックした記事で、
記事自体は僕らみたいに沿っているから、
多分一般の向け人の向け記事って感じなんで、
まあなんか技術的に新しいこととかあるわけじゃないんですけど、
まあ割とこんな詐欺あるんだって気持ちで読めたんで、
ちょっと話したかったなって感じに思ってきてて、
まあ例えば、
そうですね、
選挙詐欺とかは、
へーって感じだったんですけど、
まあなんか日本だと馴染みがないんだが、
アメリカとかだとなんか政治キャンペーン代表者を装い、
メールやSNSで寄付金を要求してくることがありますとか、
選挙調査と訴訟してフィッシング詐欺を仕掛けてくることがありますみたいなのがあって、
ああこんなのあるんだとかは結構思ったりとか、
マットを、
まあよく注意喚起とかもされてますけど、
当事詐欺とかはやっぱ取り上げられるよねとか、
またオンラインチケット詐欺とかも、
僕はなんかライブによく行くんで、
なんかすごい自分ごとに思っちゃったんですけど、
イベントのチケット転売詐欺みたいなところで、
まあ日本は転売が法的に一応縛られて、
チケットがめっちゃ対策してるんですけど、
それでもTwitter調べると、
まあ割と一部ではまだ横行していて、
でもあれってもう、
多分口約束でやるしかないんで、
このチケット売ります買いますって、
お金払うのが先か渡すのが先かみたいな話になるはずで、
その時にそれが詐欺かどうかって、
もう見分けらんないはずだから、
いやーみたいな。
現地で手渡しぐらいじゃないと、
なんか全然安心できないよなとは思うけど。
そうですね。
なんかテイラーセフトのツアーチケット詐欺では、
少なくとも3000人が被害に遭ってますって書いてあって、
1:45:00
いやーなんか切ないな。
厳しい。
そう、厳しいなっていう。
なのでちょっと紹介したかった感じですね。
なんか個人的には、
セキュリティーから遠い人に、
とかなんか家族とかに呼んでほしいなってすごい思いました。
なるほど。
なんか頭に入ってるだけで、
それかもって思えるかどうかってある気はしていて。
なんか我々にも関係しそうなとこでいくと、
シムスワッピングとかが紹介されてるのはいいですね。
13番かな。
そうっすね、確かに確かに。
偽の住宅賃貸詐欺、アンケートクイズ詐欺。
この辺は偽の就職面接とトレーニング詐欺とかもね、
マジかって感じっすよね。
これもでもなんかすごい、
いにしえからあるあれじゃないの。
なんかアイドルになりませんかみたいなそういう感じじゃないの。
生成AIとかすごいキャッチーなワードが入ってるだけで、
なんか別に。
確かに。
あとヘッドハンティングを装ってとかなのかな。
シムスワッピングって。
写真動画のディープフェイクとか最近っぽいかな。
確かに。
それかなんか3ヶ月前ぐらいにアメリカかどっかで、
結構派手にやられた事件があって、
使えることが証明されてしまった感があるから、
ちゃんと対応しなきゃなって感じな気がしますね。
ありがとうございます。
読みたいものは一通り読めましたかね。
他になんか読んでおきたいのあります?
大丈夫だね。
ありがとうございます。
いっぱい読んだな。2週間も読んだんで、
結局2時間ぐらい話しちゃいましたが。
でもあれだな、どれだっけ、
PDM話はちょっと面白かったな。
働きたくない人の脳内の記事ですね。
リスペクト大事にしていきたいな、個人的には。
何の仕事するにしても。
追い続けるのか、ガチガチに統制を聞かせる方向に倒すべきなのか、
どっちがいい姿なのかは分からないけど。
個人的に、
ケースバイケースかな。
授業とかでも変わりますよね。
変わる。
守んなきゃいけない、統制を敷きたいラインが
1:48:01
本当に失守しないと事業上まずいのか、
95点でも許容し得るのかとか、
何か守らせたいものがあったときに、
そこに対する手段として統制を取るのか、
文化作りを頑張るのかとか、
その辺はやっぱケースバイケースだから、
難しいですね。
当たり前のことしか言わないですけど。
ありがとうございます。
じゃあまたこんな感じで、
次はまた来週ですかね。
次火曜日かな。
うん、火曜日にやりましょう、1週間分。
はい。
次はいっぱいちゃんと読んできます。
はい、よろしくお願いします。
はい、じゃあ皆さん、
今週もありがとうございます。
ありがとうございます。
おやすみなさい。
おやすみなさい。
