滋賀県の寒波と雪合戦
こんばんは、Replay.fm 第72回です。
こんばんは、72回。
こんばんは、72回です。
いやー、クソ寒い。
クソ寒いだね、ちょっと慣れたよ、でもなんか。
ほんと?
うん。
なんか、こっちは、こっち括弧、滋賀県は、滋賀県南部は。
うん。あれでしょ、琵琶湖凍ったんでしょ。
琵琶湖凍ったの?
でも、琵琶湖凍ったかもね、まーちゃん。
いや、嘘で、嘘で凍ったね。
あのー、でも、いや凍ってもおかしくないぐらいの寒波が来てて。
あ、そうなんだ。
あのー、その、滋賀県ってその、北と、僕も住んでから知ったんですけど、北と南で結構、その、雪の感じが全然違うというか、北は基本もうずっと多分この時期は寒い。
あー、日本海側の気候と、なんかその、若干太平洋側の気候のなんか、中間地点っぽい感じなのかな。
そうそうそうそう。
うん。
あとなんか地味に縦に長いから、北ってもうほぼ福井県とかだから。
うんうんうん。
そう、なんか割と、車走らせるともう、雪山吹雪みたいなの珍しくないんだけど。
でも、直近1週間ぐらいはね、珍しく2日3日ぐらい、その、僕が住んでる南部の方でも雪が降りまして。
うん。
お、雪じゃーんと思ったけど、積もらずに終わりました。残念。
残念。雪合戦できなかったね。
雪合戦できなかったねー。
あー、TENX雪合戦部の、なんか久々の活動になるかと思ったけど。
うそ100パチ、うそ800?なんだっけ忘れたけど、もううそも、ダイナミック詐欺すぎるというか、雪合戦部もねーしねー。
ちなみにコースタラックは。
ちなみにコースタラックは。
レベル違うわなんか。
美若子じゃないですかね。
角違いすぎて。
美若子凍るのかなもう、なんか水分量的にきつそうだよな凍るの。
なんか、表面だっけこれ。
あー、どうなんだろうね。なんか、そんな、なんかこんなそうだけどね、なんか。
うん。
分かんないっすね。
なんか百歩ゆずってさ、雪合戦部があったとしてさ、滋賀まで来てくれるのやばいよね、なんか。
相当僕に寄せてくれてるというか。
一人でやるんですよ、だから。
え?マジで?
え?
ソロ雪合戦。
うーん。
エクストリームスポーツがすぎるなー。
うーん。
一人で投げて一人で受ける。
うーん。
まあ、悪くないかもしんない。
うーん。
じゃあ、頑張ります。はい。
Z、雪合戦。
明日作るか。
美若子。
雪が降らないと活動できない。
カールのバグバンティープログラム
余計なタネを増やしてさ、交配店の仕事増やすのやめようぜ。
半年後に棚降ろしされる未来が見える。
あれ今、自動クローズになってないんだっけ、あれ。まあいいや。
自動にはなってないんじゃないかな。
あの、あれですよ。
半年とか1年間投稿がないチャンネルは、そのチャンネルに一番クラスの人にメンションが飛んできて、
これ使ってます?アーカイブしていいですか?って来るから。
従来のようなね。
どうにかして誰か人のアカウントでチャンネルを作る方法を考えなきゃいけない。
悪いなあ。
Botに会話させるか。
LLM同士会話させとくか。
うーん。
はい、まあそんな感じで、
えーっと、今日もやっていきたいんですけど、
えー、見てないな。直近見てないんですけど、
まあ本日もお便りは来てませんが、引き続きGoogleホームにお待ちしてますという、
お決まり文句を元に記事を読んでいければなと思っております。
うーん。
ちょっとさ、なんか、今日風呂入りながら思ったんだけど、
あの、僕編集、音源編集するときに全部聞き直してるんで、
聞き直してるというか、実質聞き直しなんだけど、流し切りしながら編集してるんだけど、
たまに自分が喋ったことで訂正したいことあるんですよ。
あ、これ近いわみたいな。
はいはいはい。
3社、第3社の目線で聞いて、あ、これこの観点抜け落ちてたみたいになって、
それ気づいたときに、なんか次からお便り投稿しようってセルフでやろうかなと思ったんで、
次回はキリンからのお便りが来るかもしれないですっていう。
そういうこと?
そう、マッチポンプ。
マッチポンプというか。
うんうんうん。
メモ代わりに使い始める前に誰かお手伝いくださいって感じですね。
僕が。
僕がメモ代わりに使う前にって感じ。
じゃあ1個目からいきますかね。
あ、はい。
僕読もうかな。
カールエンディングバグバンティープログラムアフターフラットオベアイスロップリポーツっていう
ブリーピングコンピューターの記事ですね。
はい。
まあ、さらっと紹介できたって感じですけど、
前、多分2回ぐらいここでも取り上げましたけど、
カールのバグバンティープログラムが
ハッカーワンかハッカーワンで運営されていて、
お金がもらえるんですよね。
バグバンティー有効なレポートとして認められると、
報酬金がもらえるっていうものがあったんですけど、
1年、2年前ぐらいからAIによる質の低いレポートが大量に発生して、
その取り味でチームが疲弊してるよって話と、
チームもある種一定ボランタリーでやっているので、
プロジェクトの持続可能性を考えたときに、
この質の低いバグ報告を減らすために
リターンとしてお金を渡すっていうのはやめますっていうのを前々から言っていて、
それがついに1月31日をもってかな、
あと収録日今27日んで4日ぐらいですか。
で、おしまいになりますっていうやつですね。
それ以上でもそれ以下でもないんですけど、
本当に終わっちゃったねっていうところと、
一つの仕様目というか、
デカめの誰もがお世話になってる、
リラックスコマンド、リラックスに限らずコマンドだと思うので、
応援したいなという気持ちご紹介です。
そういう感じだね。
そうだね。
合わせて読みたいでエゲシ張ってくれたやつもいいね。
ついになる感じがするね。
このカールのやつは結構あんまり、
LLMの普及のちょっと負の側面が悪い形で出てたよね。
負の側面じゃないか、発展が悪い形で影響してるねってパターンだけど。
そもそも制度設計として崩壊してるっていうのは多分あると思ってて、
ほうほう。
なんて言ったらいいんだろう。
別にさ、もともとあるわけですよ、こういうのって。
例えば静的解析ツール回して出てきたやつをとりあえず投げるみたいなのって、
多分昔からあったはずで、
それらしさが多分増したっていう意味で、きっと問題だったのかなと思っていて。
量も増えたけど、とりあえずのコストもかかるってこと?
うん、きっとそうなんじゃないかなとはなんとなく思うな。
確かにね。
あとなんか、今週分か先週分か忘れたけど、紹介ピックアップはしなかったけど、
Node.jsがバグバンティープログラムで同じHackerOneでやってたんだけど、
レポーターのレピテーションのバーを上げたみたいなのがあって。
今週かな。
見た記憶があるな。
それをカールは打っててこうだったのかとかちょっと気になるかもな。
そうだね、今週合わせたよみたいだな。
なんたらスコア1.0みたいな。
シグナルスコアだね。
シグナルスコア。
僕HackerOneは全然なんていうか、あれしてないんで、よくわかってないんだけど。
あれしてないとね、わかんないよね。
あーって感じですけど。
でもカール以外こういう話を聞かないけど、どうなんでしょうね、起きてるのか。
なんでカールだけこんな、ブチギレてるから話題になってるって感じなのかな、もしかしたら。
そうなんじゃないかな。
思うんだけど、とりあえずにAI使えばいいんだよね。
もうそこでバチバチやらしちゃきゃいいんじゃないかなって。
それもそうね。
でもそうすると本当のその善意の報告者が全然なんていうか取り味されなくて、やんじゃうっていうのがたまるし。
そうだね、あとなんか意外とその、エージェントブラウザーとかもそうだけどさ、その仕組みいざ作ろうと思うと意外となんか実装コストもメンテコストもかかるというかさ。
ハッカー1にAPあるのかわかんないけどね。
AIによるコントリビューションの質向上
素朴に組めなかったときに、なんでお前らのためにそこまでやんなきゃいけないんだよみたいなところは、ボランタインでやってたら思っても不思議じゃない気もする。
てかなんかハッカー1がさ、あれひどいよな。
あー、確かにね。
だからハッカー1ってさ、結局さ、なんかハッカー1もさ損するわけじゃん。撤退されると。
そうだね、確かに確かに。
なんかそのうちハッカー1がなんとかすんじゃないかなと思うけどな。
うーん。
まあでもそれこそそのノードのこれとかもなんかハッカー1を使ったそのソリューションの一つとして、なんかこういうこともできるねっていう例ではあるんだろうね、きっとね。
そうだね、なんかヤフオクみ、昔のヤフオクみを感じるな、評価もらえないと購入だけ出品だけできないみたいな。
そうだね、今もあるんじゃないかな、昨日としては。
今もあるんだ。
わかんない、わかんない。
全然使ったことないんで。
なんか評価ない人はお断りみたいな設定はなんか、出品側にね回ったことないけど、俺もわかんないんだけど、なんかあった気がする。
なるほどね、そのこう出品者側が設定できるのか。
まあ確かに。
じゃあ完全に一緒だね。
はい。
じゃあそんな感じで次になるやつ紹介しますか。
次になるやつは、AIで一歩踏み込んだOSSコントリビューションですね。
しゅんすけ鈴木さんの記事でございます。
えーと、ちょっとサマリオ何にも書いてないな。
なんかちゃんと読んだんだけど、何にも書いてないわ。
えーと、何の話かというと、記事に書いてあるのをそのまま読み上げちゃうと、
先日自分のOSSにissueが作られました。
自分で再現確認した後にクロードコードにissueのURLを投げました。
クロードコードは調査して原因を特定し修正案を出しました。
妥当そうなので高サインを出すとPRの作成までやってくれました。
修正にも特に問題がなさそうだったので、特に手直しすることなくマージして終わりました。
なんか結構なんか、おー未来だなーってちょっと思ったんだけど、どうでした?
あー、でもこれはそうだね、未来だけど。
全然できるよね。
うん。
でもこれ以上のことをしたって話じゃなかったっけな。
これ以上のことっていうよりは、えーと、なんかどっちかっていうとその、
AIで、うーんと、まあなんかこういう楽になってる側面も。
あ、コントリビューション、ごめん、これ僕が読んだ記事、ごめん、別の記事だ、僕が読んだ記事。
別の記事でしたか、はい。
なんかとりあえず自動化したみたいな記事があった気がするんだよな。
あー。
あれ違うか。
それはじゃあビューストに拾っておいていただいて。
はい、あーそうね。これはでもいいね。
はい。
まあなんかディープウィキ使うといいよみたいな話とか。
で、なんか結構その、なんていうか、AIを使って質の悪いコントリビューションを量産するっていうのもできちゃうよね。
みたいな話があって、まさにそのカールの話が言及されていて。
うんうん。
なのでまあむしろAIを使ってコントリビューションの質を上げようぜっていうことを書いてくれてる。
うんうんうん。
なんか自分でできるだけ調べて、なんかバグを再現するようなコードとかも作らせればいいと思うしっていう話ですね。
うんうんうん。
うん。
なるほどねー。
いやー確かにこれ面白い、この発想はいいね。
ちなみに僕も仕事で結構、基本コパイロット対応してるんですけど、
そのコパイロットがそのプッシュの制約とかで動かないケースで、
クロードコードに全く同じことやってて、
その一周のURL投げて、これ実装してプリクターってやってて。
うんうんうん。
まあだいぶ良しのように動くから、結構再現性はあるよねみたいな気はするね。
この記事読み逃してたな。
へー。
たぶんね。
ほんほんほんほん。
コントリビューションの質を上げましょう。
はいはいはいはい。
そうねー。
確かに一周、一周、まあでもなんか結構人間と一緒ではあるんだよな、話としては。
結局その、AIを前提としてその一周、まあリポーティングの質を上げましょうもちろんそうなんだけど、
なんか相手が人間になってもリポーティングの質が低いとやっぱOSSメンテナーってめちゃくちゃ困るというか、
うんうんうん。
AIによるリポートの質
まあよくなんか、その何周も何周もぐるぐるなんか炎上してるイメージがあるんだけどその、
うん。
なんだろうな。
その、よくわからん質の低いリポートだけするのが最悪で、
まあ質の高いリポートはするけど修正しないのが次に嫌で、
でその次に修正投げてくれるんだけど修正の質が低いのが嫌で、
最後はなんかリポーティングの質も高くてちゃんと修正をしてくれるのが一番いいみたいな、
なんかそういう4段階みたいな。
でもなんかそれはそのAIに代わっても一緒だよねっていう部分と、
またそのAIの不確実性、まあ確率論的な部分を考えると、
まあより大事になるよねみたいなところはあるよねみたいな話なのかなっていう気が、
ちょっとさっと記事を読んだ感じはしたなあ。
で、またそのリポーティング質をAIに上げさせるは確かに、
なんかあんまやんない意味はないからやってやると良さそうな気がするね。
いやOSSをメンテしてる目線のこの記事は面白いですね。
うん。
いやAIね、AIに関するコントリビーションがあるのも確かに大事だよなあ。
うん。
この記事中に書いてある、なんかAを使ってる場合はそう分かるようにすると良いでしょうみたいなの結構、
なんか地味大事ポイントな気がするね。
うん。
多分かなりバイアスもかかってるけど、何か質の低いものとか違和感があるものが来たときに、
AIだと決めつけて、それ以上インプットをやめるみたいなのってなんか全然ある気がしていて、
それがなんかある種のなんだろうなあ、
でも本当は人間がやってて見逃していけないものみたいなパターンはある気がするから、
そこにAIラベルみたいにつけてくると助かるなあっていうのはある気がするね。
特にOSSにやり取りとかだと、基本世界中の知らない人とやり取りするわけだから、
そういうマナーはあってしかるべきかもしれない。
うん。
そうね。
なんかあのGitのコースアドバイとかは、あれはなんか昔からあったやつなのかなあ、ちょっとふと思ったんだけど。
コースアドバイって、
クロードコードとかがつけてくれてるやつ、勝手に。
複数、アイディアの自分とクロードコードをつけて。
そうそうそうそう。
これはどうなんだろうね。
まあでも、昔からありそうだけどなあ、
別にAI出てくる前からなんかでは見たことあるかなあ。
コミットサジェストンとかをマージすると共同コミットになったりとか。
マージコミットは違うか。
なんかGitの仕様はなんだろうね。
なんかGitの仕様なのかGitHubの仕様なのかはちょっとわかんないけど、
なんかGitトレーラーっていうやつらしくて。
へえ。
複数の作者を持つGitミントを作成する。
うんうん、それそれ。
うんうん。
コースアドバイ、はいはいはい。
これね、これありがたいよね。
うん。
あともう、なんか僕が知ってるのはコパイロットとクロードとデビングレーなんですけど、
それは全部、まあコパイロットはそもそも自分がコミットしないっていうか、
手元で動かないから、まあコパイロットシールドライだったらもしかしたらそうなのかもしれないけど、
クロードコードとデビングレーはこれ使ってAIのコミットであることは地味にわかるようになってるよね。
うん。
なんか読んだ気になってたなあ、これじゃないなあ、僕読んだ。
どこに行ってしまったんだ。
どこに行ってしまったんだ。
まあ、思い出したら書いておきます。
思い出したら見つけられたら書いておきます。
じゃあ、少し先頭に戻って。
へえ。
読めますか。
リアクトツーシル攻撃で顕在化したリクエストボディの先頭しか検査しないWAFを回避する攻撃。
えーと、スキュータム技術ブログですね。
はい、かなとこさんの記事でございます。
うーんと、なんか、なんだろう、書いてある通りなんだけど、そのWAFの製品の、多分割とね、大体そうなんじゃないかなと思うんだけど、
うん。
なんかボディの先頭何倍とだけ検査するみたいな仕様のやつが多くて、
うん。
リアクトツーシルの場合はなんかもう割と初期からこの方法で攻撃が来てたよっていう話ですね。
はい。
まあ、ただそれだけなんだけど。
うん。
面白いですね。
面白い。これ全然知らなかったです。勉強になりました。
このクラウドフレアが慌ててサイズでかくして障害、大障害を起こしたのは記憶に新しいですね。
うん。
あとこのスクータムがこれをやらないって宣言してるのかっこいいね。
うん。
結構言うはやすしいだよね、その。
そうだね。なんかWAF自体がなんか、WAF自体でなんかドスが刺さるみたいなの起こりそうだもんね、こういうのやると。
うん。結構うまくやらないと。
うん。
画像とかね、いろいろ考えると一概に聞けないっていうね。
うん。
あとなんかその、長くなっちゃうと語源値が増えるっていうのは結構面白いなと思ったな。
うん。
確かにっていう。読むと、なるほどなって感じなんだけど。
うん。
いやー、めっちゃ勉強になりました。
うん。
まあ、基本もう、いやでもこれ回避されちゃってるとこを見るとどうなんだろう、その既存のオフベンダーはなんだろうな、これいつかはもうこの仕様に向き合わなきゃいけないのかな。あんまその攻撃のトレンドが。
でも向き合わない前提なんじゃないの。やっぱりそのこれ以上のここが検査しない、WAFが検査しない以上のそのWAFが検査するサイズより大きいリクエストは全部落としてねっていう。
なるほどね。
まあ話だよねーって書いてるよね、記事の中ではね。
でもその画像とかだと容易に超えるから、マソコンのチューニングとかも自前でやるしかないって感じなのかな。結構、まあやりゃいいんだけどだるいよな、正直ね。
でも現実問題なんかパフォーマンスめっちゃ落ちるから、なんか結構きついと思うけどね。
まあ素朴にやればいいのかな。
グラフQLみたいな自由度の高いAPIじゃない限りは結構その、このエンドポイントにこのサイズは来ないだろうみたいなのを見込むことはできそうだから。
まあこのエンドポイント、このエンドポイントを除くエンドポイントはもうWAFで見てくれるサイズ以上のリクエストはこう、何だろう、四丸いうんだろう返すみたいな。
まあなんか、どうだろうな。
なんかベンダーが求めてるのでそういうことなのかなと思ったんだけど。
うーん、なんか、いやー、うーん、ちょっとうまく言語化できないんだけど。
なんか、うーん、あんま、いや、汎用的にこれで動くでしょうっていうパターンは多分ないと思うんだよな。
むしろ多分その一定期間モニタリングで動かしておいて、その、なんていうか、評価期間に来たリクエストに基づいて、
おおむねこのサイズに収まるだろうっていうので、アナマリーディテクション的なその考え方をセットで入れるとかの方が現実味あるかなって思うし。
ああ、まあ確かに。
うーん。
それはそうか。
ここはグラフQLだからとかまでいくんだったら、そもそも見るシグネチャーをそのグラフQLに特化したものに絞るとか多分できるし、
そういうやり方もありなのかなとは思うけど、結構大変な気がするな。
じゃあ新しくエンドポイント増えたらどうするのみたいな話とかさ。
そうね。
またメンテだよね。
一定期間モニタリングしましょうみたいなので、アナマリーディテクション的に変なサイズのが来たらそれがわかるみたいな状態を作ってとって、
そのやっぱり新しいエンドポイント増えたらどうするのとかは課題としては引きずることになるし。
なるほどね。
うーん、なんか全体的に結構難しい気がするなあ、なんか。
まあそう思うと多層防御のうちの1枚として認識して、
あくまでね。
前回言った把握も含め。
まあだからWAFがバイパスされるよっていう前提でなんかやんなきゃいけなくて、
でも結構リアクトツーシェルは、そういう意味で言うとなんかその、
多分今までは一定その、なんていうか、WAFがあったらそれはバイパスするっていうその発想とか能力がないとその、
要はなんていうか、もう手当たり次第適当にそのエクスプロイトラーゲットだけみたいなところはだいたいWAFで防げるよねみたいな
前提があったところにこのリアクトツーシェルは割と初期からなんかWAFの回避がされていて、
っていうのが多分特徴的なんじゃないかなと思っていて、
なんかその多層防御の1つとしてもちょっとあんまり頼れないものになりつつあるよねっていう話なのかなっていうふうに理解しました。
なるほどですね。
今回多分早期に悪用してたのはその脅威アクターだったっていう話があった気がするから、
なんていうか、スキル面というかそういう意味でも、
本当に防ぎたいものはWAFでは防げないぐらいの前提で、
WAFを最初防衛ラインにしないって考え方で向き合わればいいんだろうなと。
なるほど、勉強になりました。
WAFの課題
ありがとうございます。
じゃあ次。
次、https://2685-434919とhttps://160.16.124.39はsameoriginかっていう、
フラノさんのですね、朝の風プログのフラノさんの記事ですね。
答えが聞いたに書いてるんだけど。
すごい2年ぶりに聞いたに記号してる。
これ知ってた?
知らなかったです。
知らなかったのか、そうか。
前回意外とSSRFとかAI弱いよねって話をしたと思うんだけど、
まさにこの辺が知識として抜けてて、
URLのチェックみたいなのをする。
URLとかホスト名のチェックをするときにこの辺が抜けたりするんだよね。
これは受信表記してくれてるけど、
発信表記もね、
発信表記、16信表記もあったんじゃないか。
これ面白いな。
ノーションの方に貼るんだけど、
フィッシング対策協議会のURLのIPアドレス表記を用いたフィッシングの報告を受けてますよっていうので、
発信数、17信数、16信数等のIPアドレス表記っていうので出してくれてて、
このサイトのURL欄が具体的な例として出てるんだけど。
貼ってるノーションページが違うかも。
本当だ、違いました、失礼しました。
全然大丈夫です、今引っ越し。
すげえいろいろ表記の方法があって。
面白い。
面白いね、ウェブって感じだね。
これ何に載ってたのかな、めんどくさいウェブセキュリティに載ってた気がするんだけどな、読んでないんだっけ。
読んでないな、つんどくやな、読まなきゃ。
難しいね、今更読むのか感は若干あるんだけど。
どこに載ってたんだっけな。
普通に本に載ってるぐらい有名な話であるんだけど、こんな感じなんで。
こういう知識こそAIに飲み込んでおいてほしい感もあるけどな。
そうなんだよね、なんか抜けてんだよね。
こういうの、責任人間という立場で言ってはいけないのかもしれないけど、割とキリがないというか、無限にある気がするから。
こういうの全部理解したまに、こういうのあるよってちょっと言ってほしい感はありつつ。
新たな攻撃手法
なるほどね。
勉強になりますかいだな、個人的には。
しっかりこれしっかり。
これで言うと、あれ?
ま、いっか。
出てこねぇな。
はい、なんでもないっす。
あれ、どこだっけな。
メモ取っといたんだけどな。
これか。
そうそう、これが面白かったんですよ、というのがあるんだけど。
全部知ってるまになるのは難しいっていう話で。
デイリーアルパカハックっていう、多分日替わりになるかな。
自分でやってないから全然分かんないんだけど、日替わりで割とサイズの小さいCTFの問題を出してくれてるサイトがあって、
そこのライトアップで、たまたま流れてきた、たまたま見たんだけど結構面白かったやつがあって、
バッシュのジェイルをバイパスして、シェルを取るみたいな問題なんだけど、
おお、なるほどね、みたいな。
ここにあれ書いてあるから、シェルとして実行するとこれが通るんだな、みたいなのが順を追って書かれてて結構面白かった。
こういうのも知ってる知らないではあるんだけど、結構全部知ってるまになれないみたいな話でちょっと思い出したので、貼っておきます。
なるほどね、ありがとうございます。
読んでみよう。いいっすね。深いね、奥が。
こういうの見ると、たびたび言ってるけど、ソフトウェアエンジニアとは発想の方向が全然違うから、難しいなって思うな。
知らんがな、なんて話じゃん。
ソフトウェアのセキュリティの重要性
IPアドレスって実は受信表記、16審表記もできて、知らんがなって。
ソフトウェアエンジニアの思考は目的を達成するときに、もちろん幅が広い方がいいんだけど、
いらないやつはいらないというか、だから知る機会もないし、
ある種僕がこのIPアドレスの話を知らなかったのは、いいソフトウェアを作るのに多分必要のない知識として、
界隈はそういう評価をしてるってことだと思うんだよね。
でもこれ知らなかったらSSRF作り込むかもしれなくて、SSRFのあるソフトウェアっていいソフトウェアなんですかって話になると、
途端にうんってなっちゃうじゃん、みんな。
それはそうね。
厳しい話をすると。
品質にセキュリティを含めるのはそうなるね。
攻撃側の視線はちょっと違うじゃないですか。
使えるもん全部使うというかさ。
そうそうそうそう。
じっとくナイフをいかに分厚くするかのゲームの側面があるのかなって気がしていて、
やっぱちょっとゲームが違うよなっていう。
結構その表裏一体ではあるんだけど、やっぱ厳しいよなと。
ただなんかその、なんて言ったらいいんだろうな。
これの話で言えば入力地検証をどこまで厳密にやりますかみたいな話とかにも通ずると思っていて、
なんて言ったらいいんだろうな。難しいな。
セキュリティバイデザインとかセキュリティバイデフォルトみたいな考え方がベースにあれば、
そもそもある程度はそれだけで防げるんじゃないのみたいな話でもあると思っていて、
それは分からないこと知らないことに対して立ち向かう術としてそういうのがあるんじゃないのかなとは思うけどね。
そうかもね。
それってまだ機械的に動向できるような領域ではないと思っていて、
結構人間がやらないといけないというか、
人が考えて人がレビューしてっていうのがまだまだ必要な領域だと思うので。
そうね。
でも気持ち的にはAIにレビューさせたい気持ちもあるけどね。
それができるレベルのソフトエンジニアって結構なハイレベルだと思っていて、
それを事業を大きくして前に進めたいってなった時に、
そういう人たちをたくさん集めるって結構、少なくとも今の日本だと結構厳しいから、
実装者に、AIに実装させる時に期待はできずとも、
人間かAIが実装したものに対して、
そういう観点でなるべくいい問いを投げかける、レビューでもいいんだけど、
みたいなのはチャレンジしたいなって気がしたな。
なんかでも結構PDM的な思考の方が相性いいんじゃないかなと思ってて、
プロダクトマネージャーとエンジニアの役割
わかんないけどね、俺PDMやってないから知らないけど、
聞いてるPDMの皆さん本当ごめんなさいって感じなんだけど、
その、なんて言ったらいいんだろう、
実装の触れ幅が少なくなるような要件を書くっていうのは多分、
どっちかというとPDMの方が得意なんじゃないかなって思うんだよな、
なんかわからんけど。
いやー、でもね、PDMが得意な領域とソフトエンジニアが得意な領域は分かれてると思う。
なぜかというと、これも前回か前々回話したばっかのクリーンアーキテクチャって本に書いてあって、
僕はめっちゃ腹落ちしてる理論っていうかモデリングあるんだけど、
いわゆるみんながドメイン知識っていうものは、
現実世界に存在するもの。
例えばお金だったら、0円って状態は1万円も札を持ってないと、
1,000円は1,000冊1万円持ってる。そこに1,000円足したら2,000円になるよねみたいな。
で、それを1,000円を誰かに渡すっていう。
まあじゃあそれは送金っていう扱いにしましょうみたいな。
そういう形でいろいろ整理をしていくわけじゃん。
それをソフトウェアに落とそうってなったときに、
ソフトウェアの世界だと現実で絶対に起きないことが起きるわけじゃん。
例えばお金がマイナスになるみたいな。
これって現実だと起きないはずなんだけど、ソフトウェアの世界だと起きるみたいな。
そこの現実をうまくきちんとモデリングするっていう部分は、
会社によると思いますけど、プロダクトマネージャーとか、
もしくはプロダクトマネージャー&ソフトウェアエンジニアの責務になると思うし、一般的にはね。
で、それをソフトウェアの世界に持ち込んだときに、
そこで初めて発生し得る例外とか異常系みたいなのは、
ソフトウェアエンジニアが見つけるというか、考えるべきところなのかなって気はする。
実装と仕様の関係
だからそういう意味で、ここまではPDEM、ここからはソフトウェアエンジニアみたいな分け方できる気はするな。
だからこの、なんだろうな。
オリジンの表現みたいなのをソフトウェアの世界にしか、
まあ難しいな、境界を通るしかしないんだけど。
ある種システム要件というか、ドメインの世界ではないというか。
ケースバイケースな気がするね。
もちろんそこで、
そこでソフトウェアの世界に造形が深いプロダクトマネージャーとかがいると、
僕らの仕事は結構楽だよね。
そこもある程度見越して、こっちに染み出してくれて、とかは全然あると思うし。
そうだな、URLみたいな概念で言うとさ、
例えばその繊維先を受け取ってなんかするみたいな要件があったときに、
繊維先を受け取ってなんかするみたいな、
ふわっとした要件までしか定義しないのか、
なんて言ったらいいんだろうな、
事前に定義されたこれとこれとこれのリストのうち、
繊維先を外から指定できるようにするみたいな形で書くのかでさ、
だいぶ実装の触れ幅が違うよなと思ってて、
そういう話をしたかった。
なるほどね、まあまあまあ。
言いたいことは分かった気がする。
向いてる世界と向いてない世界があるっていうのは確かにその通りだなって思うから、
現実の世界のモデリングっていう観点において、
得意としている部分が全然違うよっていうのはその通りかなとは思うな。
あとはきっとグラデーションがあるね、
多分一番左にユーザーストーリーがあって一番右に実装があるっていうのは、
今のURL繊維とかってどの辺か分かんないけど、
こういうことをお客さんができてほしい、こういうことができてほしい、
それを画面に表現したらこうで、
機能はこの繊維にあるみたいな感じ。
ソフトウェアに実装者と要件を決める人がどこまでお互い右と左に侵食できるか。
そうだね、そういう意味で言うとPDMの技術への改造度みたいなのは確かにめちゃくちゃ変数としてはでかいところな気がするね。
動いてりゃいいっていう考え方だったらそれは緩い実装になるだろうし、
そうだね、そうだね。
いやー、おもろいよな、プロダクト作りおもろいよな。
こと安全なプロダクトを作りましょうっていう話になったときに、
なんか割と根性論っていうかなんか結構、
なんて言ったらいいんだろうね、なんか人間の部分に向き合わないといけないのが結構難しくて面白いなって。
うーん、そうだね。
あとはその、現実でやっぱさ、上手くいく事業とかプロダクトって基本的には独自性とかさ、先行性とか、
あとはその、解いてるissueがすごく難しいっていうのが往々にしてあるじゃないですか。
だからこそ上手くいってる。
他者の参入を許さないとか、
そういうのがあるわけで、なんかそうなるとなんかAIが理解できないほど、
なんか一般論では語れないエッチケースとかなんか難解さが出てきて、
まあ人間がまだまだ頑張んなきゃいけないみたいなのがあるだろうなってちょっと思ったわ。
なんか掲示板作るならAIレビューいけると思うんだよ、その今言った話とかって。
でもなんかその、そこに複雑な要件がボンボンボンボン盛り込まれたりしたら、
無理なんだろうなっていうのをちょっと今腹落ちしたわ。
僕らの仕事はまだなくなりません、多分。
難しい、なんか多い。そうなんだよな。
だから面白いんだろうけど。
仕様がな、昔働いてた、結構尊敬してたソフトエンジニアの方が言ってて、
僕は結構好きなフレーズがあって、
何かの行動を僕が実装して、ペアプロとかなんか、ペアプロじゃないか、
僕が実装した行動で、ここ悩んでてめっちゃイマイチになっちゃったんですよねみたいな話をしたときに、
これはもう仕様が壊れてるから行動も壊れるよねみたいなこと言ってて。
なんかだからその、壊れた仕様をまずどうにかしないとみたいなこと言ってて、
なるほどねーってすごい思ったというか。
なんかね、その地続きだよなーって気はするよね。
そうねー。
はい。
はい。
ありがとうございます。
オリジンの話か。
全然ちょっと待って、セイモー・オリジンから一切しなかったんで失礼しました。
すみません。
結論セイモー・オリジン。
結論、はい、セイモー・オリジンですという話ですね。
これは面白いよね。
でもそう考えるとさ、これどうやって内部的に判定してんだろうね。
その、一段なんか挟んでるはずで、その、何て言ってるんだろう。
あの、同じ、同じスペースで、
その、その、その、何て言ってんだろう。
解決先がどこなのかっていうのを、こう、あの何て言ったらいいんだろうな、
なんか、あのー、えーっとちょっと出てこない、
解決先がどこなのかっていうのを解決するって、
ちょっと主人は何とか公文みたいになっちゃうんだけど、
その、解決するレイヤーが一番多いのがこの、
この、この解決先なんですよね。
はい。
はい。
がどこなのかっていうのを解決 するって ちょっと趣旨がなんとか
公文みたいになっちゃうんだけど 解決するレイヤーが一覧挟まってる
わけだよね 間に 面白いなと思って でも そういうレイヤーが一覧
挟まってるにもかかわらず ドメイン 名の場合は IPアドレスでなくドメイン
で判定するみたいなのができてる わけだよね 結構 実装が面白い
なと思って きっと多分パブリック サフィックスリストでマッチング
して そのドメイン名か何かを 先に見てるとかなのかなとか 裏
の実装が気になっちゃいますね こういう のは IPアドレスのとき
だけ解決してるんだね きっと ブラウザーのコード読めば読め
そうなんだけどね
しばやん これ ちなみに 結構 いや できるよね できたぞ なんだけど
カールとかでも解決すると思うん だよな これ 普通に
おだしょー なるほどね いいね これでまたツールによって解釈が
違ってたとか 夢が広がるね っていう ことが
そうそうできるできる カールでも 解決できるから 結構 TGP IPのスタック
の深いところに目指してる仕様 なんだよね これ ブラウザーだから
とかじゃないんだよ 面白いね
面白いね
こっちに使用RFCがあるんだろう ね RFCじゃないか アドレスワーキング
グループか
いや ワットワージンのだって あれ だと 多分 これWebだけだから カール
がうまくいくとか
そうかそうか
違うんだ URLのスペックの話だから 入ってくるのかな きっとね 本当
かな ちょっと待ってね では これが トレースルートだったら どうなん
でしょうか もう忘れちゃったな でもトレースルートでも解決する
から やっぱり結構 TGP IPのスタック として深いところで多分定義されてる
仕様だな きっと ようわからんけど なんか ワットワージンのURLが
うんうんとかではない気がするね
おもろいな アゾマス いや 無限 だな じゃあ 気になる方実装読んで
レポーティングしてください 次いきますか 私はもうかな ネクスト
はですね Azure AI Supercharges Phishing Scams 1% Introduces Built-in Protection 1% リリース
の記事ですね 昨日リリースの記事 で 何かっていうと ちょっとサッ
と読んでるんですけど どういう 昨日リリースしたかで言うと 1%
しっかり 多分他のパスワードマネージャー も一緒だと思うんですけど パスワード
マネージャーの仕組みって このURL のIDパスワードはこれですっていう
形で認証情報を保存しておいて 大体ブラウザー拡張が用意されて
いて 一致するURL 1パスとかの場合 は設定次第ですけど もしくはURL
のサブドメインのURLとかにアクセス すると 登録した認証情報で保管
が効くっていうような感じで使える サービスになっているんですけど
そこに対してフィッシング攻撃 っていうのは 正規のサイトには
なり過ごせないんで 別のそっくり の別のURLのサイトを用意して ID
フィッシングとパスワード管理
パスワードを入力させようっていう のをやってくるわけで そこに対して
パスワードマネージャーを使ってる と さっき言ったドメインの位置
がしないんで サブドメインテイク オーバーとかじゃなければ なんで
認証情報の保管が効かずに あれ おかしいぞって気づけるよみたいな
文が よく言われるパスワードマネージャー のいいポイントなんだけど 現実
じゃあどうかっていうと ハバイビン ポンドの管理者のセキュリティ
めっちゃ多分強い人とか専門家 の人とかがめっちゃ疲れてるとき
とかにフィッシングに引っかか ちゃいました さっき言った保管
されないっていうところで気づける はずだったのに めっちゃ疲れて
おかしいなってなってコピペして 入力しちゃって引っかかっちゃ
いましたみたいな
あと ハバイビンポンド の人だったっけ あれって
おだしょー うん ハバイビンポンド の人だと思う
そうだっけ そうか 覚えて ないな
おだしょー ハバイビンポンドの 人が自分が運営してるメルマガ
のサービスでフィッシングに引っかか っちゃって
そう メルマガのサービス だけ覚えてたから ハバイビン
ポンドが全然ひもついてなかったん だ
おだしょー そうか あれ そういう キスだったのか
覚え方としては それで 移動営したメルマガの人たちの
メアドを全部ハバイビンポンド にまるっと登録するっていう ちゃん
と自分でポイントするっていう 場合があって エピソードとセット
で覚えると覚えやすい
おだしょー なるほどね
そう そう ちゃんと反省 いるんですけど それは一例なんです
けど そういうことが起きちゃう よっていうとこに対して 今回リリース
された機能は そのID パスワード をコピペしようとしたときに ワンパス
に登録してないURLだった場合は 警告が表示してくれるっていう
機能がリリースされましたっていう 話ですね なんで 今言ったハバイビン
ポンドみたいなケースにおいて は もう一段ウェーブのコンファーメーション
が出て 気づけるのか気づけない のかもその人次第ですけどっていう
新しい警告機能の検討
形で少し安全にしましたよっていう リリースがされましたって感じ
ですね これ まだ手元で試してないん ですよね どういうロジックで判定
したのかあんま分かんなくて コピペ しようとしてる文字列がなんか
あれなのかな ワンパスに入った やつと完全一致したら警告して
くるのか ワンパスの拡張機能から コピペしたものを コピペしたって
ことを記憶しといてやってるのか ちょっと定かないんですけど 今
試してる いや ちょっとなんか動く条件が分かんないな
ね そうなんすよね 分かんないな
ちなみに手元でFacebookのログイン ページで全然別のサービスをコピペ
してみたけど なんか何も起こられ なかった バージョンが古いのか
一応 動作の動画とかもあるんですけど なんか似てるURLとかだと起こる
のかな いや 分からんな ちょっと
サイトをオン オン オン これなんか中ではコピーアンド
ペーストって名言されてるの 要は ワンパスワードの機能を使って
入所交換をしようとすると警告 が出るは分かるっていうかな それ
はもともとあったような気がするん だよな
そのウェブサイトに手動でコピー アンドペーストしようと 起こそう
かね ユーザーが認証書を貼り付け ようとすると警告を出すって言ってる
んだよね だからこの貼り付ける っていうのがどうなのかっていう
部分なんすよね
ペーストってコピーアンドペースト って書いてあるから コピーアンドペースト
なんだろう 分からんね
デモサイト欲しいな
確かにね デモサイト作って パスワード集める人とか出てき
そうだね クソ邪悪な考え方だけど
何かその動作 見てみたみたいな やってみたみたいな記事
もう この虹 虹上二次天才のやつしか 出てこなくてあれなんですけど
はい まあまあまあそんな感じです なんでワンパスユーザー喜んで
くださいなのか ちょっと条件が謎ですけど
脅威モデリングの類似手法
これちょっと頑張って動作確認 してお便り出そうか
それ普通にブログ記事書いて ここに持ってくればいいじゃん
書いお便りを挟むシステム 何なの
記事書くのだるいけど ちょっと 2行ぐらいとか言って
せめて何々が何々じゃないか検証 してくださいみたいなお便りに
してさ検証してきました大川さん まだいない
なるほどね 確かにマッチポンプね 確かにそうするか
じゃあちょっとこんなお便り 聞いてたんでこんな記事書いて
きましたっていう手にするか
そのほうがいいよ 知らんけどきっと
そうするか あとなんかこれ気になったけど
これあっても何かダメな時はダメ なんじゃないかって思ったけど
どうなんでしょうってぐらいかな
それはちょっとわからんけど
ダメな時はダメっていうのはそりゃ そうでしょ
ダメな時はダメだよ だいたいの物事はダメな時はダメだから
そうね なんかそのホワイトピン ポランドの例とか
あと直近でポッドキャストで引っかかっちゃいましたっていうのを
紹介してくれてる方がいて 別に伏せる必要ないんですけど
その話 生々しい話とかを聞いてると
そもそもコピペしてわざわざ保管されない サイトにわざわざコピペして
入力しちゃう時って結構ちゃんとした 理由があるというか
ハワイビーポンドの場合はめちゃくちゃ 疲れてたパターンだし
僕が今言った公社の場合は疲れてたプラス
めっちゃ久々にログインするサイトで 言われる変わったのかなみたいな感じで
何万回かにしてやっちゃったみたいな感じ 新しくて
それらのケースは多分1回結構 重まっても
でも意図通りですみたいな感じで やっちゃいそうだよなみたいな
思ったっていう ただそう
分かる 社内のドキュメントでちょうど パスワードマネージャーフレンドリーな
作りにしようねっていうのを書いてたんだけど
めっちゃあるよなと思ってて
同じアカウントでログインする口が複数あって
複数ドメインを1個のアカウント情報に紐づける
各ドメインに同じアカウント情報を保存しとく みたいなことをしないといけないとか
結構アンチパターンだよねみたいな話とかあるし
それがURL変わったのかなみたいなのが
当たり前に起こりうるんだけど
そこはもう制約としてしょうがない部分はあるんだけど
それが普通に想定されるような状況っていうのが
そもそももう負けな気がしてきて
しんどいなって思っちゃうね
人間の注意力に対応らずに進む側になるべく寄せてあげたほうが
そうするとやっぱパスキーだよねってなっちゃうと思うんだよな
オリジンの紐づけもできるわけだからあれだったら
間違いない
フィッシングだろうと移行先言われるだろうとログインしたくても絶対にログインできない
バグってなければ
バグってなければそうだね
散々言ってるけどパスキー入れない未来が正直ない
よなっていうのは間違いなくその通りだと思っていて
まだその時期が来てないだけだよ
あと何年ぐらいでしょう
波は確実に来てるからな
先週紹介したSBA証券系とかでもSNBCの記事も流れてきたし
クレーカーセキュリティガイドラインとかにどっかで入るんじゃないきっと
確かに入るかもね
確かにそれで思うと5年後ぐらいには
重要なものとかには入ってる世界になるかもね
入ってる世界になると思うんだよねきっと
サービス提供事業者として守ってあげられる手段が
それしかないんだもんそれが別に完璧とは言わないけど
技術的なサポートを恩恵を受けられるっていうのは
技術的には今それしかないわけだから
パスキーの使用そのものが全部死ぬとかじゃない限り
それはもう規定路線な気がするね
ありがとうございます
ありがたいリリースである一方
そこの認識はそうだよねっていうのが確認できてよかったです
最後の記事いきますか
私ですねこれ
ハードウェア設計に
読んだけどあんま読めてないんでお願いします
おける脅威モデリングとの類似的手法
長谷川さんのスライドですね脅威モデリングナイトの
発表らしいんだけど
どれぐらいの時間枠で喋ったのかな結構面白くて
長谷川さんってもともと
書いてくれてるんだけど電子回路系の人だったんだよね
そこからセキュリティに来て特に
webのアプリのセキュリティに来て
わりと興味深いキャリアを辿っている人
世代で言うとちょっとわからん俺の中の大雑把な分類で言うと
セキュリティの人のわりと初期の
世代というか別にセキュリティを専門で
やってきたわけじゃないんだけどいろんな経緯でセキュリティをやるようになって
セキュリティを専門とするようになった人みたいな
そうだけど世代で言うとそういう世代っていうか
僕が多分それよりもさらに下でどっちかというとセキュリティを専門にして
ずっとやってきててっていうタイプなんだけど
なんとなく世代が分かれてて長谷川さんはそういう世代
っていう風に僕は認識してる感じそういう世代ってジェネレーションというか
時代が分かれてるのよ俺の中で
説明できないんだけど
そういう方ですよと
脅威モデリングナイトなんで脅威モデリングの話をしてるんだけど
最近哲学とか倫理学に興味関心があるよっていうのを
スライドの中で触れていて脅威モデリングとは脅威をモデル化すること
モデル化とは一般化抽象化することだよと
哲学倫理学っていうのは現実を抽象化し普遍的な原則を見出す学問だよと
なんで哲学的な考え方ができるっていうのは
脅威モデリングにも寄与するということを
言ってるんですね
なかなか面白いなっていう感じなんですけど
そこからさらに振り返って産業用計測機器の電子回路設計を
やってた経験の中で産業用計測機器の回路設計においても
脅威モデリングに通じる技法があるんで今日はそれを紹介するよ
っていう趣旨のスライドでした
いくつか端折るんだけど
故障モード影響解析っていうのがあるらしくて
スライドで言うと10ページですね
FMEA フェイルワーモードアンドエフェクトアナリシス
故障モード影響解析ってやつがあるらしくて個別要素ごとに
例えば短絡不祥とか断線とか摩耗とかが発生したときに
製品あるいはシステムにどのような影響が発生するかを分析する手法らしくて
なかなか面白い
FMEAが故障モード影響解析っていうのを
どういうふうにやるんですかっていうのをその例を説明してくれていて
例えばMINIONCの場合だと
幹電池2本でモーターを駆動する玩具で底面にスイッチがあるよと
この図が何を意味するのかは
ちょっとわからないんだけど電池配線スイッチモーターギア
モーターギアシャフトタイヤっていうふうに順に繋がってるよと
これはなんだろうなーなんかこの矢印が
パスなんじゃないなんかその
電池が動力としてタイヤが動くまでの過程
と思ったけど
この矢印をどう一般化して捉えればいいのかちょっと俺の中では
若干あれなんだけど
ある種のリレーションというか関係性があるよっていう話なのかな
そういうふうになってますよと
故障っていうのは様々な不具合
例えばギアの摩耗とかコネクターが
ずらくするよとか様々なものがあって故障モードっていうのは
発生しうる典型的な不具合を抽象化分類して整理したものだよと
故障モードの例で言うと例えば電気回路だったら
短絡断線コンデンサーの容量低下とか
機械部品だったら摩耗欠損強度低下とか
ストライドでの脅威分類に似てるんだけれどもストライドのようなプリセットのリストは存在しないよ
っていう感じらしい
14ページから先が具体的にこういう表ができていくんだよみたいなやつ
になってるんですけど
例えば部品とか要素あとは故障モードと原因みたいな
分類を作っていって部品要素が電池で故障モードが
発熱だったら原因は粗悪な電池の使用だよね
なので影響は人体とか火災に影響する損害を与えうるよねとか
の評価していって
最終的に故障モードの重要度を影響の大きさ
発生度検出度の3軸で検討するよと
最終的にその3軸によって点数付けされて
その評価が出るよっていう感じらしい
対策の検討っていうのを
評価結果に応じてやるよと
セキュリティリスクの評価
評価に応じて対策するしないみたいな部分を
考えるっていう話なのかなきっと
割と本数字が22ページ以降なんだけど
このFMEAと共有モデリングの比較っていうのが
ここの辺で触れられてるところで
共有モデリングではシステムへの影響を検討するプロセスがないよっていう
話に触れていてここの差分って何によって
出てるのどういう意味があるのっていうのが
この発表の趣旨っていうか
一番大きい学びなのかなと思っていて
共有モデリングでは
個別要素ごとに脅威と脆弱性を検討し
それをもとにリスク評価するよと例えば要素をデータベースに脅威情報漏洩
脆弱性スケルインジェクションと仮定したときに発生する可能性と
発生したときの影響からリスクを評価するよと
個別要素に着目したミクロな視点から
発生時の影響を推定することが難しいんじゃないかと
だからシステムに与える影響の検討がないんじゃないっていう風に言っていて
個別要素の脅威からシステム全体の影響を検討するっていうのが
結構一足飛びに個別要素を見て脅威を検討して
じゃあシステム全体に何が起きますかみたいな
影響の大きさを導こうとするっていう結構飛躍した考え方をしてるよねっていう指摘をしていて
これってセキュリティに慣れてる人であれば
暗黙的にそれができるよねっていう例えばSKインジェクションが一箇所でも存在すれば
全体として致命的だよねっていう話とか
結構ここが割と
個人的には
ソフトウェアエンジニアにとっての
セキュリティの難しさの言語化みたいなところに若干近いんじゃないかなって思って
興味深かったんだけど
それでさっきの話も結構面白かったし
今日はそういう話が多いなって思ってるんだけど
結構難しさの一因なのかなって思いながら読んでました
確かにね
それと言うと年数を数えたら多分3年ぐらいで
セキュリティ転向してやって思ったのは
飛躍感みたいなのがだいぶ分かるようになったかもしれない気がする
結構一つリスクとか
脆弱性とかがあったときに
言語化が難しい感覚なんだけど
そこから紐が伸びていくというか
影響の線が伸びていって動いてるシステムはここで
クレデンシャルにまつわるリスクがあったらそのクレデンシャルは何のクレデンシャル
ここに置いてあってそこに対してこの矢印が伸びていって
じゃあこれぐらい芋連れで広がっちゃうよねって
ものまではまあまあこんぐらいで収まるでしょみたいな
そういう話なのかなってすごい解釈しながら
なるほどねっていう気持ちがある
結構ここが飛躍してるっていうのを受け止めた上で
名刺的に
この脅威と脆弱性から
システム全体にどういう影響が起こりそうかっていうのを検討してもいいのかもね
っていうのが一番最後に書かれてること
面白いなという感じでした
モデリングと実務の関連
あと結構面白いなと思ったのは
どこだっけな14ページ
14ページちょっとドクセルさ
ページがさ割と下に常に表示されてて欲しいんだよな
下のこの矢印を
クリックしたほうがいいのかな俺も今気づいたけど
クリックするときにマウスオーバーでそれが出る範囲が微妙に狭くて
すごい今イラついてた
なるほどね
製品システムを構成する要素を列挙するっていうページなんだけど
入念に検証したい要素ほど細かく分割して列挙するっていう話と
外部から購入する部品など分解に難しいものも
そのまま扱うその前段として実績のある部品などは
ある程度機能単位でまとめるサブシステムとして扱うかつ外部から
購入する部品など分解に難しいものもそのまま扱う要はそれ以上
モノリスからマイクロサービス
移行するときに割と厚く残ったモノリスを1個のでかいマイクロサービス
として扱うみたいな話なんだけど考え方としては
1個のでかいサブシステムとして扱ってそれ以上細かい要素には分解しない
っていうベースの考え方があってこの考え方自体は
セキュリティの脅威モデリングにも持ち込めるんじゃないかなって思って
面白かった
持ち込めそうな一方で
持ち込めるか
ソフトウェアでちょっと違いそうなものは物によるかなケースバイケースかな
ハードウェアもしかしたらそうなのかもしんないけど
入れ子になることあるかなって気はするな
難しいけどこのレイヤーの共有モデリングでは
これはこんぐらいの抽象度にとどめましょうこれはこれで個別に盛り下げましょう
とかそういうケースはありそう
ハードウェアもあるんだろうけど
今日ちょうど仕事で話してた話で言えば
外部のOSSのGitHubアクション
の安全性ってぶっちゃけわからんよね
リポジトリの設定どうなってるかわからんしさ
こっちで一定リスク緩和できる部分はあってそれを厳密にやるしかないけど
いちいち全部
いってこっちからもチェックしに行かないとその辺はタップできなくて
それいちいち全部チェックするのってすごく手間だよねみたいな話とか
現実的にそこが判断が難しいできない
リソースがないっていう話であればそれはいって
1個の大きな塊として扱ってしまって何らかの形でこれが
何らか侵害されるとする
その発生可能性は大雑把にこれぐらいと見積もっておきましょう
世の中でこれぐらい起きてるしみたいな大雑把な
手が扱いをするとかは全然ありかなと思ったし
スコープを分けるとか
入れ子になるみたいな話とかは確かにその通りだと思ってて
飛躍してるっていう話がある一方で実務的には
別に全部オモーラ的に
見る必要がそもそもなくて教員モデリングというものの
捉え方次第かなとは思うんだけど実務にどう活かしてるかっていうのは
会社とか組織によって様々あると思うので
一例としてTENXの場合はどうしてますかっていう話で言うと
実務上はスコープを細分化するとかで
結構対応できてるというか
飛躍が少なくなるようにスコープを切っている
ところはあると思っていて
なぜかというと有限のリソースで早期に目的を満たしたいっていうのが
まず大前提としてあるので
それこそ飛躍だと思うんだけど結構暗黙的にスコープを切っている
っていう側面もあると思っていて
大体ここまで見ればいいでしょうっていうスコープを結構暗黙的に切っていて
それが暗黙的な共通認識になってる
っていうのがそもそもあると思っていて
教員モデリングって面白いなっていう話なんだけど
そうだね 肌感というか
まあこんなもんでいいでしょみたいなラインはあるよね
それを擦り合わせるときもあれば
一致するときも多いかもしれない
事前準備も含めてやろうと思えばいくらでも時間はかけられる
わけだけれども
1時間で洗い出したいんです 大雑把に一旦洗い出したいんです 今何をするべきか
一旦知りたいんですみたいなときに
事前準備にそんなに時間かけてらんないし
図とかもその場でサクサク書きながらやっちゃった方が楽だし
そうすると暗黙的にスコープを切って
有限の時間で何とかしましょう 有限のリソース一時間で何とかしましょうっていう話になるわけだから
実務的にはやっぱりスコープを切る必要がある
かなとは思うんだよね
立ち向かい方はそこの飛躍っていうところに対しての立ち向かい方は多分
様々あると思っていて
立ち向かった結果別の飛躍にぶち当たるっていう可能性もあるから
難しいとこではあるんだけど
間違いないね
トピックは違うかも OSSの話聞いて思ったのは
ハードウェアとちょっと違うのは
ソフトウェアは文字通り柔らかいというか
それが多分めちゃくちゃハードウェアに対する
違いとかある種の優位性というか柔軟性みたいな
変化がめちゃくちゃ早くてどんどん適応できるみたいな
特性があると思うんだけど それ故にやっぱ
柔らかいまま扱わなきゃいけないみたいなことが多いんじゃないか
良い面悪い面あるよね あとからそこに脆弱性が
入り込みうるっていうのも多分柔らかいからこそだと思うし
ハードウェアの側は基本的にはないじゃん 一回組んだものが
あとからそれが脆弱になるって
暗号系はまた別なのかな 新たな仕様が出ましたとか
特定の暗号アルゴリズムが期待化しましたみたいな状況になるとまたちょっと
話が変わってくると思うけど 基本的にハードウェアそのものが
っていうのはあんまないから そうだね 私なんかあっても多分
困るというか部品を組み込む側目線としては
リリースして半年で脆弱性発生して
回収して直してみたいなね やってられんって話だから
そう だからやっぱそれを踏まえたいろんな
仕組みが多分成熟してるじゃん
モーター一つにしてもこういう基準があって これクリアしてるものしか買わないとか
それを売る側もきちんとちゃんとやんなきゃ売れないから
やるみたいな形であるけど それっては
OSSとかってそういうの全然ないと思うし
人によったら便利だったらシュッと入れて
手軽さがいい面であり でも何の保証も実はされてないから
自分たちできちんとアセスメントしなきゃいけないがゆえに
ブレイクダウンしなきゃいけない ディープダイプしていかなきゃいけない
結構 違いだよなっていうのをしみじみ思った
いい部分ってあり 面白いんだよな
面白いんだけど セキュリティ観点だとちょっと悩ましいことも
ハードウェアの挑戦
多々ありつつ なんかハードウェアセキュリティ
やってる人とかと話してみたいわ
全然また違いそうだよな
だいぶ初期の頃に
ハードウェアレベルの暗号化周りの話があったよな
忘れちゃったけど
何の話だっけな ちょっと忘れちゃったけど
一個記事を紹介してる気がする これやってる人たちすごいねって
指キーかなんかに
込め込まれたチップスに 出着性があったみたいなやつは
たぶんそれ きっとそれ系だったはず
それかどうかがないけどそれ系だったと思う
大変中華すごいよね なんかいかつい機械で
パスワード認証通してる瞬間をキャプチャーすると
サイドチャレンジ攻撃で削減できちゃう
たぶんそれ 懐かしい
すごいよな ハックする側もすぎるけど
これをやられて大丈夫な
行動をかけと言われて やれるかって言われて
うーんってなっちゃうよねって話をしてた
厳しいよね
セキスペとか基本情報
技術試験におけるサイドチャレンジ攻撃
はなんか定義は理解してるし
説明もできるけど 現実で例えば
向き合えって言われたらなんか 発狂しちゃうよね
電流でバレるって何みたいな 俺電流のこと考えなきゃいけないの
みたいになっちゃうよね
頭が上がらんすわ 広いな 世界は広いよ
面白いよね ハードウェアどんだけ頑張ってもさ
コードのせいで 上で動くソフトウェアのせいで
結局サイドチャレンジ成立するとか普通にありそうだし
あるんだろうね あるんでしょうね
そうすると低レイヤーからどんどん上がっていかないといけないんだよね きっとね
また品質保証というか そこどうするのかとか
ある種のレッドチーミング的なものとかめっちゃ
物によっては頑張んなきゃいけなかったですよね そうだね
いやー大変っすわ マジで
はい ありがとうございます とてもいいスライドでしたね
うん めちゃくちゃ良かった
今日は以上かな
いやー面白かったなぁ いいですね なんか久々に
久々にとか言っちゃったんだけど結構いい回だったね
なんか話すことが多かった いい意味でね
いやー全部良かったなぁ
セームオリジンとかマジですよ もうどこまで話し飛んだんだって感じ
最後の最後でね あれセームオリジンの話してないじゃんって
びっくりした いやーありがとうございます
じゃあこんなところですか まだまだ寒いですけど
まあ寒さに負けずやっていきましょうというところと
まあ引き続きお便りもお待ちしておりますんで 僕がマッチポンプしだす前に
気軽にご応募ください
ご応募 ご質問してください まああと2回ぐらい
来なかったらもう中止でいいんじゃないですか
マジでメンタル弱えな頑張ろうぜ 俺半年やるよ
マジですごいね なんか
いやーそうだよ みんなそのみんなこっから
リスナーとの対話の重要性
それで売れてくんだよ知らないけど あーそういうこと 売れてくって
毎日お便りが来すぎて困っちゃう状態になるってこと こっから
うーんまあそれはちょっとだいぶ先に行きやすいけど
まあまあまあ
意外と大事な気はしてて マジでゼロ圏でもいいんだけど
あれじゃん
ふとさ自分も聞いたときにたまにあるんだけど
これに関してどう思ってんだろうと思ったときにさ
まあ行動力ある人だったら
もう本人にメンションして聞くとかすればいいけどさ
そこまでじゃないとかそれはちょっとなっていう人が
いたときになんかフォームがあるならじゃあ特命でもいけるし
シュッと聞いてみようかなってなるわけじゃないですか
口を用意して そういう意味では全然 そうかもしれない
なんかスポーティファイのweb版とかだとコメント残したりとか
ツイッターのハッシュタグも見てるんでそれでも全然構わないんですけど
大ピラに宣言しとくことは意外と価値があると思ってるんで
頑張ろうぜメイズに
まあまあちょこちょこ
やっていきましょう
じゃあそんな感じで皆さん来週もお楽しみにしててください
おやすみなさい
