cicd-sensorの概要と導入背景
今回はゲストとして、 rung さんをお呼びしました。 rung さん、よろしくお願いします。
よろしくお願いします。cicd-sensorを作っています、 rung です。
はい、よろしくお願いします。ありがとうございます。
まあ、そういうことなんで、今回はですね、 rung さんをお呼びして、
cicd-sensorについてちょっと聞いていけたらなと思っているんですけど、
まずですね、ざっくり cicd-sensorがどんなものかっていうのを rung さん、
ちょっとだけ説明していただいてもよろしいですかね?
cicd-sensorは、今年の6月ぐらいにリリースした オープンソースのソフトウェアなんですけども、
GitHub Actions とか、GitLab の CICD のジョブ上で、
実際にどういったプロセスが動いたりとか、 ネットワークのコネクションがあったりとか、
ファイルアクセスがあったりとかというのを監視したり、
もしくは、最近よくサプライチェーン攻撃みたいなワードを聞くと思うんですけども、
そういったことが発生したときに、 それを検知できたりするオープンソースとして作りました。
すごいなんか、ざっと聞く限り、 すごい便利そうだツールだなというようなことを思うんですけど、
これ実際片杉さん使ってるんでしたっけ? cicd-sensor。
そうですね、個人でも会社でも使ってるんですけど、
そもそも使い始めたいなと思ったきっかけとして、 実際会社で起こったこととして、
NPM のサプライチェーンアタックって 最近結構話題になってると思うんですけど、
実際会社でも、リノベート経由で侵害されたバージョンへの 更新のプレリクエストって来てたんですよ。
なんですけど、たまたまコスト削減のため、 セキュリティのためじゃなくてコスト削減のために、
依存更新時のギターバックションずつ たまたま止めてたんですよ。
それで本当にたまたま更新、 たまたまCIで実行されなかったんですけど、
なんかこれ完全に偶然で防いじゃったんで、 これってまずいよねって話をずっとしてたんですよね。
それで cicd-sensor を入れると、何かあった時にログが残るので、
その時に調査の手がかりになるっていうので 導入したっていう形ですね。
すごい。じゃあ実際に共務でも個人でも使われていて、
しかもそもそももしかしたら侵害があった可能性すらあったっていうか、
ユースケースとしてバッチリタイミングがあったってことなんですね。
そうですね。
環境では。
cicd-sensor開発の動機と現状
ちなみにこれランクさん、最初作り始めたきっかけ的な cicd-sensor の作り始めたきっかけ的なところとしては、
今片井さんが言ってくれたようなユースケースが もうまさにドンズバみたいな感じなんですかね。
そうですね。まさにという感じで。
サプライチェーン攻撃は今年の3月ぐらいからどんどん起こっているんですけども、
もともとは4、5年前からずっとそういった攻撃って続いていて、
ちょうど去年の末ぐらいに1回そういうのを検知するツール、
どうしても市場にあまり良いオープンソースがなかったりとか、
もしくは有償商品としてはあるんですけども、
プライベートレポジトリで使えなかったりであるとか、
そういう問題があったりとかしたので、
そういうちゃんと検知できてかつ記録できるようなソフトウェアを
オープンソースで誰でもが使える形で作ってみたいなと思ったのが去年末で、
そこから設計をして作り始めて、
実際に3月からいろいろインシデントが起きていると思うんですけども、
まさにそういうのを検知するために作ったという感じです。
本当にどんどん中立井さんがユーザーというような形ですよね。
そうですね。
ちなみに今年の6月に作られたというような話なんですけども、
もう2ヶ月ぐらいですかね。
もうすでにGitHubの方の下かなりついているのかなと思うんですけど、
どんなような感じですかね、この2ヶ月リリースしてから。
一応まだ公にはプレリリースという扱いにしていて、
これから本リリースですよというような感じの段階ではあるんですけども、
とはいえ今までそういうオープンソースでCICD向けに
ジョブ上のアクティビティを監視するというツールが
ちゃんとなかったというのもあって、
結構実は会社内で使ってますみたいな声をいただいたりとかしているという段階ですね。
すごいですね。
じゃあもう業務でも、さっきも片杉さんの例でもありましたけど、
業務でも使われているようなツールになっているんですね。
プレリリースというような形ですけど。
そうですね。
すごいですね。
攻撃検知の仕組みと通知方法
ちなみに僕の理解なんですけど、
このCICDセンサーで防げるところとしては、
GitHub Actionsとかで実行しているジョブの中に
不正なアクションが仕込まれていた場合に
スラックの通知が来るだったりとか、
何らかのアクションを起こせるみたいな理解であってますかね。
基本的にその理解であっています。
よくあるのが、不正なアクションが呼ばれて、
そのアクションがCICDジョブ上にあるクレデンシャル、認証情報を読み取って、
それを攻撃者のサーバにアップロードするみたいなケースがよくあるんですけども、
まさにそういうケースを検知できるようにという形で作っています。
ちなみに一番よくあるというか、
Rangさんが想定するようなアクションの攻撃手法と通知パターンみたいなのってあったりするんですかね。
ちょっと気になるなと思ってて。
結構いろんな種類があるんですけども、
結構シンプルな攻撃も多くて、
よくあるのがさっき言った通り、宝探しって自分はよく言っているんですけども、
ジョブ上にあるサーバ上にあるクレデンシャルをどんどんアクセスしていって、
例えばSSHキーとかクラウドのアクセスキーであるとか、
あとはたまにクリプトですね、仮想通貨系の認証キーみたいなものを取りに行って、
取れたらそれを固めてあげるっていうのがよくあるパターンですね。
ですね。
攻撃手法としては円部系を取っていくみたいな。
そうですね、そういうのが多いです。
環境変数を。
環境変数にアクセスしただったりとか、
ドット円部をリードしたとかそういうところを取ってるみたいな。
そうですね。
なので基本的には環境変数とかあとはファイルアクセスですかね。
そういうところに取りに行ってっていうのが多いです。
AWSのクレデンシャルファイルというところですかね。
それを検知した後にどうやってユーザーというか、
開発チームに知らせるみたいなところはどんな形になってるんですかね。
主に2つ方法があって、
1つ目は検知結果をアクションを回した後に載せるっていうような方法を取っていて、
アクションを実行した後ってジョブのサマリーみたいなものが載ると思うんですけども、
そこでもし検知があったら、検知がありましたよというのを載せると。
たまにこれは止められるってものがあれば、
ジョブ自体を途中で止めるってこともします。
それが1つの方法で。
もう1つがマネージャーっていうようなコンポーネントを置くことができるようにしていて、
それ何かというとログの受け取り場所ですかね。
いっぱいある会社内でたくさんCICDって回ってると思うんですけども、
その各CICDのジョブからログを集約して、
それをS3バケットであったりとか、
どこかのストレージに送っていいようなことができる、
そのマネージャーっていうのを置いてコンポーネントがあって、
それ経由でログを送って、ログを監視することで検知すると。
そういう2つ目のルートもあるという感じです。
なるほど。
ジョブのリザルトに載せる、もしくはジョブを止めてしまうっていうようなルールというか、
そういうジョブの設定をかけるみたいなイメージですかね、前者に。
そうですね、前者はそういう感じです。
それに引っかかったら、このジョブ自体をフェイルさせるみたいなことも、
実装というか設定ができるという。
結構強いやり方にしたら、
例えばここではAWSのクレデンシャルなんて絶対呼ばないから、
クレデンシャルファイルにアクセスしたらもう絶対に
ジョブをフェイルさせるみたいないうこともかけるってことですよね、具体的に。
そうですね。
すごい、かなり便利だなと思うんですけど。
なんかCICD環境において、
基本的にはそういうクレデンシャルは置かない、
必要ないクレデンシャルとかエンブとかは置かないっていうのは、
基本パターンというか、推奨すべきパターンじゃないですか。
その環境において、
そういうエンブとかをダッシュしてくるみたいなのって、
どっちかというとあれなんですかね、
GitHubのセルフホステッドとか、
そういうパターンに多いんですかね。
でもセルフホステッドにも関わらず、
結構実は、今でも認証情報を送るっていう人たちっていうのは、
たくさんユースケースとしてはあったりいたりとかして、
それを狙っているっていうような認識ですね。
例えば、AIのサービスのトークンを渡して、
環境変数とかで渡してますとかもあるだろうし、
例えばAWSとか、クラウドサービスを操作するテラフォームを
立ててますとかもあるだろうし、
あとソースコードの中にそういった環境変数、
そういったトークン情報とか入ってますっていうケースもあるだろうし、
本当にいろいろあると思いますね、その辺は。
なるほど、じゃあ精錬潔白なレポジトリは現実的ではあんましないというか、
不要なエンブも入ってしまってるパターンも絶対あるよねっていうような環境において、
エンブをダッシュしてくるっていうのが攻撃者のパターンなんですね。
そうですね。
なるほど、理解できます。
実装詳細：eBPFとルーティング
ちょっとCICDセンサーに関しては概要はざっくり把握できたかなと思うんですけど、
ここからは実装周り、OSSとして実装してきたところの話聞けたらなと思うんですけど、
なんか面白い話として片手さんなんかここから聞いていくといいみたいなのあったりしますかね。
そうですね、なんかそもそもどうやってるのかって、
多分ほとんどの人想像もついてないんじゃないかなっていう気がしているので、
例えばLinux KernelのEBPFっていう機能を使っていろいろとってきてると思うんですけど、
まずそもそもどういうことやってるのかってところから聞きたいかなと思います。
はい、結構説明が難しいんですけども、
基本的にLinux上のイベントを取得するために、さっきおっしゃられたようなEBPFというものを使っています。
このEBPFっていうのを使うと、例えばファイルアクセスとかネットワークのコネクションとか、
そういうイベントが取れるんですね。
それを取得して、ある種ルーティングをして、各CICDのジョブに紐付けてあげます。
その後、CICDのジョブに紐付いたルールっていうのを回してあげます。
このルールっていうのは検知ルールで、自分でも定義できますし、
もしくはベースラインルールっていうのがあって、私が書いて配布したルールっていうのがあるので、
それを読み込んでるっていうパターンもあるんですけども、そのルールを回します。
これはエバリュレーションのフェーズなんですけども、
それがもしヒットしたら、ディテクションがありましたよっていう風にマネージャーに飛ばしたりとか、
もしくはリザルトに書いたりとか、そういうのをしますというループを回してまして、
というような感じのアクティビティを吸い上げる、ルーティングする、ルールを評価するっていうのを何度も何度もやってるっていうのが
基本的なやっていることになるかと思います。
そもそもEBPFっていうのが、ご自身ちょっと分かってないんですけど、
これはすごいざっくり言うとLinuxのシステムコールが全部来るイベントストリームみたいな感じですか?
すごく説明の難しい部分ではあるんですけども、
カーネルの中にいくつかフックみたいな感じで、
イベントの取得するためのフックを差し込むポイントっていうのがあるんですね。
そこのポイントを見てあげることで、例えばプロセスが生成されましたよとか、
ファイルアクセスしようとしてますよとか、ネットワークのコネクションしようとしてますよっていうのを観測することができると。
それで最近よく使われているのがこのEBPFという機能で、
以前は例えばカーネルだと自分でカーネルモジュールみたいなものを開発して、
それで差し込むみたいな方法しかなかったんですけども、
最近だとこのEBPFっていうのが使われていて、それによって監視をすると。
例えば最近だとファルコっていうようなOSSとかテトラガンみたいな、
Kubernetesみたいな領域で使われている教育圏地のソフトウェアとかもこのEBPFっていうのを使って実装されていたりします。
なるほど。EBPFという仕組みというかLinuxの機能に対してフック関数みたいなのを設定できるってことですね。
そうですね。まさにそうです。
そのフック関数に送られてくるアクションが全部渡ってくるからそこを監視しましょうねというような
基本的なアーキテクチャとしてはざっくり言うとそんな感じになっていると。
さっき言ってたルーティングが意図するところってどういうところなんですか?
ルーティングって何なんですか?
確かにちょっと説明が足りなかった部分ですね。
このCICDセンサーなんですけども、
例えばホスティットの普通にGitHubを使っててそのまま使うGitHubアクションだと
一つのVM上で一つのジョブしか回らないと思うんですね。
なんですけどもこのCICDセンサーは例えばKubernetes上でセルフホスティットで使うユーザーに対しても
このCICDセンサーっていうのを使うことができますと。
そうなった場合ってCICDセンサーは一つのプロセスがその一つのVM上に立っていますと。
そのVM上でいろんなジョブがKubernetesの場合はPodって形でいろんなジョブが上で走りますと。
なってくると一つのところで監視するけども
このイベントはこのジョブに紐づくものですよ。
このイベントはジョブBに紐づくものですよっていう風に裏で仕分けしてあげないといけないんですね。
というところでこのルーティングっていう処理が入ってくるという感じですね。
なのでホスティットの場合はほとんど全部一緒のジョブに紐づくんですけども
一つのVM上でたくさんジョブが流れている場合はそのルーティングが入ってくるという感じです。
なるほど。さっきの話のEBPFで流れてくるフックに設定した関数の中には
複数ジョブのイベントが入ってくる可能性があるってことですね。
そうですね。このイベントはこのジョブ、このイベントはこのジョブっていう風に結構
イベントごとにジョブが異なってくる可能性があるという感じです。
それを仕分けしているっていうのがルーティングと呼ばれる処理ってことですね。
ちなみにこの仕分けっていうかルーティングどうやってしてるんですか?
そのプロセスごとに分かったりするんですかね?
実装詳細：Cグループとルール評価
さらに複雑な話に入っていくんですけども
Cグループっていうのを使って仕分けっていうのをしてるんですね。
このCグループに紐づくジョブはこれだ、このCグループに紐づくジョブはこれだっていう風な形で
Cグループごとにジョブの割り当てみたいなものを裏でマップとして持っていて
特定のイベントが例えばネットワークアクセスが発生しましたってなったときに
そのネットワークアクセスが発生したプロセスのCグループを見て
そのCグループに紐づくジョブを特定して
そのジョブのイベントとして処理するというようなことをしています。
なるほど。一つのジョブに対してテストの実行に限らないと思うんですけど
ジョブの実行に関して、一個Aというジョブが実行されたら
AというCグループの孫プロセスとかが何らかのネットワークのアクセスだったりとか
そういったことをするはずだから
親をたどっていってこのジョブだというような
たどりで解決をするみたいなことをしてるんですね、内部で。
だいたいイメージとしてはそんな感じですね。
Cグループ自体は一つのCグループの中にいろんなプロセスを持てるのでたくさん
なので特定のプロセスの情報を取ったら
どのCグループかがもうひも付いてくるという感じになります。
そういった形でたどれるような形になってきてるんですね。
このポッドキャストでもCグループはシステムD界で紹介をしているかなと思いますね。
システムDのプロセスも全部Cグループ別々になるんですけど
そういうプロセスをグルーピングしてある程度アイソレートしたいみたいなときは
基本的にはCグループを使うかなと思うので
そこをうまく活用してるんだなと知れました。
そういった意味でもやっぱCグループ便利だなと今思っちゃったんですけど
かなり便利な仕組み。
この仕組みがなかったらどのジョブかって特定できないですよね。
そうですね。
結構そのCグループっていろんなプロセスを束ねてくれる
プロセスのグループを作ってくれるんで
こういうこのプロセスはここだみたいなことを決めたいときに
結構便利だなっていうのを改めて今回作ってて思いましたね。
すごいですね。
そういった形でルーティングしてあげて
結果的にルールにのっとって評価していくっていうような形なんですかね。
最終的には評価のベースのルール集みたいなものがあるっていうような話だったんですけど
なんか理解としてあれですかね。
リントのリントみたいな形でルールが設定できるみたいな
そんな理解であってますかね。
そうですね。
ルール自体はセルっていう式言語で書かれてるんですけども
中のそのルール自体は例えばプロセス名にこれが含まれていて
かつ例えば何でしょうね。
ネットワークアクセスがこういうネットワークアクセスがあったら検知するみたいな
複数条件でさっき取ってきたアクティビティとかをベースにして
複数条件でルールを書けるみたいなことを実装しています。
ここは独自の独自実装の式とかではないですね。
セルというような既にあるような既存の原稿を使ってっていうような形なんですかね。
そうですね。既存のものを流用して作っているという感じです。
ちなみにここランクさんがデフォルトで用意しているルール集って言うんですかね。
それをとりあえず使っておけばいいみたいなそんな感じなんですかね。
どういうようなところなんですかね。
やっぱカスタムして各社自社用にやった方がいいんですかね。
そうですね。なんか自分の経験として
例えばこのルール集ってうちのOSSだけじゃなくて
例えばファルコとかだったらファルコも裏で配ってたりとかするんですけども
やっぱりその自分でルールを書くって
かなりアドバンスドなユーザーだけの話かなと思っていて
なので基本的にはこのベースラインを使っていたら
ある程度安心できるっていうのを目指していきたいなと思っている形ですね。
基本的にはランクさんが作って配布しているやつ
公式のものを使うのが一番いいよねっていうような形にしていきたいという。
していきたいという感じです。
ちなみに片栗さんここどうしてます。ルールの設計。
ルール本当難しいなと思っていて
例えば何かその否得情報のファイルにアクセスしたら即ダメかっていうと
実際それが必要なジョブとかもあると思うんですよね。
だからやっぱりその1個これやったからOK
絶対ダメみたいな感じじゃなくて
複数個例えば否得情報何か必要なさそうなのに
否得情報をアクセスしたりとか
何か必要なさそうなのに全然関係ない
IPアドレスに通信しようとしたりとか
何かそういう複数組み合わせて
それで初めて発動するみたいな形にしないと
結構ご判定が多くなっちゃいそうだなと思いますし
あとなんかすごいセル使ったのすごい面白いなと思っていて
この手の仕組みって
例えば何か何て言うんですかね
例えばネットワークアクセスしたら困るじゃないですか
この手のやつってただ計算式だけを書いて欲しくて
何かそれ以上のことをして欲しくないって思うんですけど
セルってそもそも言語でいいのかな
その言語使用として何かそういうネットワークとかそういうのなくて
計算式しか基本的には書けないようになってるんですよね
なのでそのあたりがすごいマッチしてて
すごいいいなと思いつつ
じゃあ実際それを自分で今回の条件として書けるかっていうと
やっぱ考えることが多すぎて
ちょっと自分では書けないなって思ってしまってるのが現状ですね
なるほどセルの式自体が高いっていうようなことなんですね
書くまでの式が若干高いっていうのと
なんだけども言語特性
セルの言語特性上
CICDセンサーにはかなりマッチしてるなというような感じなんですね
ちなみにラングさんこのルール
セルでデフォルトなもの配ってるもの書いてるかなと思うんですけど
これ自分で手で書いてたりするんですかね
それともAI使ってますか
かつ裏で自分の手元ではスキルみたいなものを作って書いてますね
やっぱそうですよね
そのぐらいセルの書き方というのが結構難しかったりするんですかね
僕セルのどういう基本なのかちょっとわかんないんですけど
そうですね
なんか自分書いてる身としては
そこまで難しい言語じゃないっていう実感があるんですけども
どうしても独自言語というか
一般的に同じように書くツールOSSがあるわけではないので
やっぱりCICDセンサーのために覚えないといけないことがあるというところが
難しいポイントかなと思っています
だからこそデフォルトで配ってるものっていうのが
一番品質よくっていうのがまさにその通りっていう感じですよね
カスタムするっていうのはなかなか難しいと思うので
そうですね
一個補足すると
自分は仕事でもディテクション関係のことをやってるんですけども
結構読むのが難しい言語っていうのがあるんですね
例えばレゴ言語みたいなものがあったりして
これはよくKubernetesとかそういうクラウドネイティブみたいな界隈で
よく使われる言語だったりするんですけども
初学者からすると書く以前に読むのも結構最初は難しいみたいな言語だったりするんです
最初は自分がどの言語を使うかとか
もしくは自分の独自実践にするかっていうのを考えていた時に
セルだと書くのは多分大変だけど
読むまでは割といけるだろうという判断があって
読むまでいけるならある程度書くのもAIを使えば
他の人もできるんじゃないかっていう判断もあり
セルを採用したっていうのがありました
なるほどそういう背景があるんですね
書くのは難しいが読むのは実直に言って普通に読めばいけるんじゃないか
そうですね何をやっているかぐらいは分かるっていう感じですかね
実際片地さんどうです読んで何となく分かりますか
完全に個人の感想なんですけど
セル自体は記号とかは普通のプログラミング言語っぽくて
普通に読めるんですよね
ただやっぱCACDセンサーだとアクセスしたい要素とかがすごく多岐に渡るので
セル自体の難しさというよりもそっちじゃないかなとは思ってますね
なるほどちょっと柔軟性が高いものというか
ルールをこう書く術というか
ルール自体が難しいって感じですね
セル自体はちゃんとそれを表現できる言語なので
それはすごい言語だと思いますね
じゃあ言語の問題ではないというところが
ある意味マルウェア検知自体の難しさみたいなところですかね
なるほどちょっとここからはOSSで開発していく中で
この2ヶ月ぐらいの中でどういう技術的な選択してきたのかな
さっきのセルだったりとかも結構あったのかなと思うんですけど
技術的選択：ルールの言語とパフォーマンス
ちょっとそこを聞けたらなと思うんですが
さっきのセルの話から行こうかなと思うんですけど
他に考えていた言語とかあったりするんですかこのルールの
そうですねさっきも言及したんですけども
レゴ言語は最初に検討しました
もう一つはエクスパーというような語言語で
使うために作られた言語があって
それも似たものなのでそれも検討しました
もう一つ独自でルールの形式を作ろうかなというのも思って
それも実際にやってみてやめたという感じでしたね
すごいじゃあ独自言語を実際にちょっと作ってはみたんですか
そうですね作ってはみたんですけども
ちょっと作る内容自体がコンパイラーの再実装とか
パーサーの再実装みたいにちょっと近くなっちゃうので
危ないしあんまり自分でやらないで済むならやるべきじゃない領域だなと思って
セルに倒したという背景があります
なるほどさっきの話だと読むまでは行けるんじゃないかなというところで
セルを採用したって話だったんですけど
他に利点というかこれがあったからセル選んだみたいなのあったりするんですか
他だとやっぱり速度ですかね
レゴも試したんですけどもレゴでやるよりセルでやった方が
10倍以上ですかね早いっていうのがあったので
そういうのもあってセルにしましたね
なので速度もやっぱり大きいです
その評価の速度ですかね
評価の速度ですね
ランタイムで走る時の検知する時の速度が10倍差があったということなんですね
CICDセンサーってEBPFとかでイベント取ってくるレイヤーも面白いんですけども
もう一つ大量に来るイベントをどう処理するかとか
どう検知するかみたいな
かつ検知もすぐに検知の評価を回さないと
次のイベントがすぐにやってくるので
そこの処理をどうやるかっていう楽しさもあるというようなツールですね
確かに今聞いて気づいたんですけど
ジョブってGitHub Actionsとかで回してる
僕も会社とかでGitHub Actions使ってるんですけど
基本的にはテストで回してるわけなんですが
そのテスト普通に回すと5分とかかかるわけなんですけど
CICDセンサーを入れたことによって10分になりましたとなっちゃったら困っちゃいますよね
そうですね
しかもその中でちゃんとご検知とかもされてほしくないですし
ちゃんと検知はしてほしいんですけど
2倍になっちゃったとかは困りますけど
そこら辺の速度の考え方というか
毎回処理をストップさせるわけにはいかないけど
ちゃんと検知をしないといけないという中で
でもジョブは止まるタイミングもあったりするわけじゃないですか
そこら辺どうやってるんですか
基本EBPFっていう仕組みの話になってくるんですけども
リングバッファーっていうのを使うんですね
このリングバッファーっていうのを簡単に言うと
サイズ付きの球みたいなものだと思っていただければいいと思うんですけども
要は後段の処理で重い処理がやってくると
そのリングバッファーが詰まってしまって
イベントを取りこぼすみたいなことが発生したりするんです
なので遅くなるっていうので済むならもしかしたらいいんですけども
そうじゃなくて発生したイベントが全く乗ってこないみたいなことになりかねない
みたいなのがそのEBPFでやっているところの難しさですね
完全性ではないんですね
できる限り詰め込むよというような形なんですねアーキテクチャ的に
スルーされる情報もあるかもしれないよという
スルーされないレベルまでバッファーを取っておくとか
そういうことで対策するというところになります
すごい実装というか気にすべきところめちゃくちゃありそうな
あります
CPUなんて絶対MAXで使えないんですもんねこんなところで
そうなんです
そこら辺の最適化というか工夫ポイントあったりしますか実装する上で
実装する上でも毎回毎回ちょっと変更するたびに
実際にパフォーマンスを確認しながら作るみたいな感じにする必要があったんですけども
一番詰まるポイントとしてはセルの評価がやっぱり詰まる
たくさんルールがあってそれをルールを回していかないといけないので
例えば3個重いルールがあったらそれだけ速度が遅くなるということがあり得てしまうので
そこのルール評価みたいなところをいかに軽くするかが今回キーポイントでした
なるほどそのルールもいっぱいあればいいって話ではないということになってきました
そうですなので1万個例えばあれば詰まっちゃうしっていうので
見足としては1000ルール持ててると嬉しいなぐらいのイメージで作っています
なるほどそういうパフォーマンスチューニングというか
1000個ぐらいでいい感じに動くというところを目指しつつというところなんですね
ただもちろんあれですよねルールごとにコストありますよね
そうなんです
そこをどう評価するかということですね
なのでメモリーアロケーションを減らしたりとか
あとはシングルスレッドじゃなくてマルチスレッドで動かしたらどうなるかとか
そういうのを一個一個検証しながら実装していたという感じですね
かなり検証時間かかるんじゃないかなと思うんですけど
この辺も全部CICDセンサー自体のギタバーアクションとかCIとかでやってる感じなんですかね
自動で回してるような感じなんですかね
これに関しては実装するときにまず個人のOSSなんですけども
後ろで裏でデザインドッグを書きながら進めていて
そのデザインドッグを書く段階で書く検証をして判断していたという感じですね
なので毎回回してるんじゃなくて最初実装判断したときに実験しました
なるほどじゃあ一番最初こういうルール
ルールの追加とかの段階とかですかね具体的には
そうですね最初そのCICDセンサーを実装したタイミングですかね
一番最初ですね
その後から結構機能の追加とかされてるのかなと思うんですけど
その検証みたいなところはどうなんですかね
それでいうとセルのエバリエーション部分の大きい変更っていうのはまだないので
なので今のところは初期実装のままという感じですね
なるほどじゃあそこの部分に手を入れるときにはもう一回再検証をしないといけないというものがあるんですね
なかなかギターアクションズってそんなにCPUコア数が潤沢にあるわけじゃないんで
並行にあったから速くなるかっていうとなかなか厳しいですよね
そうなんですそれはめちゃくちゃ面白いポイントだなと自分も思っていて
一般的に考えて並列にしたら語言語で書かれてるんで
複数の語流値を使ったら速くなるんじゃないかと思いたいんですけども
実際には並列で動かすためにメモリアロケーションが増えてしまったりとか
一つのCPUをお互い食い合うみたいなことが発生して結構遅くなっちゃったんですね
なので今は一つのジョブに対して一つのスレッド語ルーチンという形で動かしています
そうなりますよねそれがいい気がします
かなりやっぱ工夫ポイントがここには詰まってそうですね
速度と使ってるマシン違いますもんね各社
それもあります
本当にすごい弱いようなものをセルフォーステッドで使ってるような環境ももちろんありますもんね
ちなみにこのルールの各社さんもすでにプロダクションというか企業で使われてるっていう話もチラホラ聞くっていうところなんですけど
OSS開発におけるセキュリティ対策
ここら辺のパフォーマンスの部分の話とかって何か触れられたりとかあったりしたんですかねフィードバック
そうですねフィードバックとしてはもらってないんですけども
一度自分で検証かなり負荷検証みたいなものをしたときにやっぱり取りこぼしが発生するということがあって
その時にいろいろまたチューニングしたいっていうのは一部初期の段階ですけどありましたね
取りこぼしあるとすごい怖いですね
取りこぼしの検知みたいないうのも必要ですよねきっと
そうですねなので序文の終了時にサマリーログという感じで全体のログを出すようにしてるんですけども
そのログの中にセルの評価でもしこぼれた部分みたいなそこの段階ではみ出した部分についてはそのログに載せるっていう風にしています
フォールバックのシステムみたいなものが入ってるっていうところなんですね
ちなみにCICDセンサーそれ自体も脅威にさらされる対象かなと思うんですよ
CICDセンサーのディポジトリ自体も
そこら辺の対策というかCICDセンサー自体でCICDセンサーを使ってるのかどうかとかどうでしょうか
そうですねもちろんCICDセンサー上でもCICDセンサーを使っていますというのと
やっぱり誰が気をつけててもサプライチェーン攻撃みたいなものって起こり得ると思っていて
ただCICDセンサーっていうCICDを守るためのツールが侵害されたらもうともこもないと思ってるので
かなり個人的には気を使っていて
なので例えば依存をかなり減らしていたりとか
あとはリリースのためのステップをかなり増やしていたりとか
そういうことは個人的には気をつけながらやっているというものはありますね
依存関係かなり減らしてるっていうのは意識的にやられてるんですよね
そうですね
最近すごく思うのが本当に依存が少なければ少ないほどもしかしていいんじゃないかって
それはちょっと思ってきてるんですけど個人的には
そこら辺Rangさん的にどうです
理想の世界ではないなと思っていて
ただ現実的に今それが推奨されるというか
ある程度信頼できるOSSを使っていこうっていうような流れになってきちゃってるなというのは思っています
ただいい世界とは思ってなくて
本当は好きなツールを使って
かつその好きなツールを使っても安全だっていうふうに言えるような仕組みであるとか
そういうエコシステムみたいなものが本当はあるべきだよなと思いながらやってますね
その一個となるのがCI-CDセンサということですよね
となれば嬉しいなとは思うんですけど
作るための
CI-CDセンサでセキュリティ上一番気にしてるところとしてはどういったところなんですかね
やっぱCI-CDセンサを使ってるっていうところなんですかね
他にあったりしますかね依存関係減らす以外
一般的な依存関係のリスクを減らす対策っていうのはしていて
例えばクールダウンを設けるっていう話であるとか
でもそれが一番最近多いのはクールダウン期間を設けて
リリースされた直後のものを使わないとか
そういうのはもちろんやってるという感じですね
さっきの話だとリリースサイクルリリースフローをかなり複雑にしてるって話だったんですけど
ここら辺どうなってるんですかね
その辺に関しては個人のOSSなんで最悪自分個人でリリースはできちゃうんですけども
ただちゃんとその承認フローを通さないとリリースできませんっていう話であるとか
あとは結構OSSってメンテナーをどんどん増やしたいっていうのがあると思うんですけども
今のところいろいろコントリビューションしてくださる方もいるんですけども
一旦まずは自分だけがリリースできるようにするという状況でやってるというようなことで対策していたりします
コミット権は与えないというようなことですよね
コントリビュータープルリクエストは受け入れるけどもという
あと今後もしライト権限持つ人が現れてもリリースまではできないみたいになってたりしますね
なるほどリリース権限はRangさんのみで作業をして
現状はそうやって人を減らすことでリスク対策してるというところで
今後変わっていくかもしれないエリアではあるんですけども現状はそういうふうになっています
ちなみにリリース自体あれですかね手動でやられたりしています?CIとか使って自動化するんではなくて
それは全部CIを使って自動化してますね
そこ自体は自動化されてますね
そうですねその上でCI上でも例えばビルドした後にそのビルドの署名をつけたりとか
あとはどこでビルドされたかとかそういうのも実は確認できるようにっていうので
裏でそういうのをつけたりとかはしています
ここら辺のこのOSS今話してたのって割とOSSプロジェクトの運営というか
どうやってやっていくのか最近の事情みたいな話だったんですけど
片津さんからここら辺あったりします?
いや自分も全然できてないですねこの辺はなんか署名結構めんどくさいっていうのもあって大変だし
あとCICDセンサーの文脈で言うとEBPFってGoのレイヤーだと扱えないんですよね
確か何かLinuxカーネル上にVMみたいなのを立てないといけなくて
基本Goで直接触れるレイヤーじゃないんですよ
なのでなかなか標準パッケージだとできないので
やっぱりライブラリーを使わないとなかなか実装難しかったりするところなんですよねEBPFって
なのでたぶん依存ゼロっていうのはCICDセンサーだとかなり難しいだろうなと思っているので
そこどう捉えるかという気はしていますね
そうですねそのレイヤーは今はCiliumのEBPFの
たぶん一番有名なやつですね
はい有名なやつですね
PureGoで作れるっていうEBPFを触れるっていうのでそれを使っていますね
やっぱりそういう既存の実装には乗っからざらえないっていうところが
あれを再実装は現実的に無理だっていうくらいのものかなと思いますね
難しいところは絶対にあるという
そうですね
ちなみにラグさん自身がセキュリティエンジニアとしてかなり活動されているのかなと思うんですけど
セキュリティ知見とルール作成
その中で得た知見とかをルールに起こしていたりとか
そういうこともされているんですかね
そうですねもちろんそういうところもやっていて
基本的にルールって2個の観点で作っていて
一つ目の観点が一般的な検知というので
さっき言ったような宝探しみたいなものを検知する
例えば一つのジョブの上でAzureとGoogle CloudとAWS
3つともにクレデンスアクセスがあったらおかしいよねみたいな検知するみたいな
そういう一般的な一般論の検知のレイヤーと
もう一つがIOCってセキュリティの業界で呼ばれるんですけども
インディケーターオブコンプロマイズっていう
特定のマルウェアがどういう動きをしたかみたいな
各マルウェアごとの動きを検知するっていうものですね
2つ目の観点はそれも検知できるようにというので
新しいマルウェアみたいなものが現れたら
可能な限りそれの挙動みたいなものを確認したりとか
もしくはレポートを読んでそれを検知できるようにというような
そういうセキュリティ系の知見というか知識って
かなり集合値に頼らざるを得ないかなって個人的に思っているんですよ
個人で頑張っているからといって
なかなかいたちごっこなところもあると思うので
攻撃者からのそういったところもあるかなと思うので
個人では結構難しいかなと思うんですけど
そういうルールだったりとか
こういう検知パターンも必要だねみたいないうのが
プロリクエストで挙げられてきた時に
どう対応しようかなみたいなのってあったりしますか?
そうですね 現状ルールはまだPDRでもらっていない段階で
ちょっとこれくらいになってくると思うんですけども
すごくそれは今悩んでいる難しい例の話で
ルールを作る時に一番怖いのがご検知なんですよね
もちろんちゃんと検知はしたいんですけども
やっぱりご検知 簡単にルールだけ
例えばさっき言った特定のクレデンションにアクセスするっていうものを
検知ルールとして書いちゃうと
あらゆるところで検知が発生してしまうと
ってなってしまうと
使っている側からするとちょっと信頼性がやっぱり落ちちゃう
自分の使っているいろんな情報で検知が全部上がってきたよってなると
落ちちゃうって話になってくるので
そこはちょっと難しいなと思って
今ちょうど思っているところで
悩んでいるところっていう感じですね
一つ案として最近話しているのが
CICDセンサーのマネージャーの部分を
GMO Flat Securityさんというような
実際のベンダーが
マネージャーの機能を提供するという話がちょっと裏で上がってまして
そこからある程度匿名化されたデータをもらうことで
もしご検知が大量に発生したら
すぐに改善するみたいなプロセスを回せるようにできないかみたいな
ことはちょっと裏で進めている最中になったりします
すごいですね
GMO Flat Securityさんの匿名化とかですかね
あれの匿名化ランナーっていうような
同じようなことをしているツールがあるんですけども
そこにCICDセンサーからのイベントも取れるようにっていうので
組み込んでもらおうとしているところですね
単純にCICDセンサーから見たときに
扱えるデータ量が増えるということですね
ユーザーから見ると
マネージャーの運用を全部Flat Securityさんに任せて
CICDセンサーから見ると各イベントを
自分たちで運用したマネージャーにあげるんじゃなくて
Flat Securityさんにあげて
Flat Securityさんに検知とか
後追いの検知とか
いろんなものを任せられるようになるみたいなことが
起こる予定です
なるほど マネージャー部分の実装というか
そこのコンポーネントをまるっと
GMO Flat Securityさんの方にお任せして
その部分のリクエストに関しては
ネットワークで通信して
GMO Flat Securityさんのサーバー上で
処理が回るみたいな
マネージドサーズ版みたいな感じだと思うんですけども
CICDセンサー自体は完全にOSSで
僕個人のものなんですけども
オープンソースなんでどう使ってもいいですよというところで
GMO Flat Securityさんの方で
そういうものも今作っているというふうに聞いています
すごいですね
単純に実現したら夢があるなと思うんですけど
やっぱりOSSの問題点として
ユーザーのデータを集めるのが非常に難しいというのがあって
やっぱりここはOSSだと限界があるなと思っている部分ですね
やっぱりソフトウェア自体はOSSで
入れるってなるとソースコード見れないと怖いと思うので
そこはOSSでありつつ
やっぱりログの解析とかは
やっぱりセキュリティ会社にちゃんと見てほしい
ってなるとそういう構成になるかなと
個人的にも思ってますね
かなり利点があるなと思いつつも
HTTPリクエスト監視機能の実装
どう今後なっていくんだろうな
なんとなく思うところで
基本的にマネージャー部分に関しては
匠ランナーとか
そういったところのサービスを使うといいよ
みたいな感じになっていくんですかね
一応マネージャー自体は
基本的には私のスタンスとしては
OSSのものを使っても大丈夫ですよとしつつ
やっぱりOSSの限界ってさっき片杉さんも言われたんですけど
いろいろあるんですね
データを取れないっていうのもありますし
あとは後追い検知みたいなものが難しい
例えば後から検知ルールを追加しても
前までに流れてしまったジョブの検知は
後追いでできない
だけどデータを持っているセキュリティ会社だと
それができるみたいな話もあったりするので
そういうところでやっぱりOSSっていろんな限界があると
なので基本的には
自分たちでお金も払わずに
いろいろできますよっていうふうなことにしつつも
もしそういった本当にセキュリティ会社の
サポートを受けていろいろやりたいっていう人たちに対しては
そういうGMO Flat Securityさんのような
マネージャーバージョンをぜひ使ってくださいね
っていうような案内になるのかなとは思っています
そういった形で
マネージャーのコンポーネントを
まるっと外部の
セキュリティ会社の方にお願いできる
っていうふうにすると
そもそもマネージャー以外の部分の
コンポーネントに関しても
セキュリティ会社のところから
フィードバック受けられるみたいな利点も
もちろんあるっていうような形で
CICセンサーの開発者としては
そういう利点が出てくるなと思って期待しています
すごいいいなと思いつつ
ちょっと話戻って
内部実装の話になるのかなと思うんですけど
HTTPリクエストの話を
具体的なところとして聞きたいなと思うんですけど
片杉さんお願いしてもいいですかね
そうですねやっぱり実際使ってて
一番気になるのって
例えばソースコードとか内部の取得情報を
外部に送信されるとか
あと外部から変なバイナリー取って来られて
実行されるとか
やっぱりそこが一番怖いなと思っていて
やっぱりどういうリクエストを
飛ばしているのかっていうのが一番
気になるところだと思うんですよね
CICセンサー実際動かすと
DNSでこういうドメイン解決しましたよとか
こういうところにリクエスト飛ばしましたよ
みたいなのが見えるようになっているので
その辺の実装どうなっているのかとか
そういうのを聞きたいなと思っています
はい 今まさに
実装中のところも入ってくるんですけども
さっきおっしゃられたように
ドメインの名前解決自体は
ドメインっていうような
ドメインの名前解決のイベントで
上がってくるっていう風に今なっていますと
今実装中なのが
HTTPリクエストっていうようなイベントを
実装中ですと
これに関しては何で実装しているかというと
ここ最近の
さっき言った宝探しをして
クレデンシャルを
攻撃者のサーバーに上げる
みたいな話をしたと思うんですけども
その上げる先が
例えばGitHubだったり
そういうことがあるんですね
ってなってくると
イベントとしては
ドメインの名前解決としては
Github.comしか残っていないと
で そのなんか怪しいプロセスがあるけど
そこの通信先が
Github.comしかないってなった時に
その先の
例えばパスを見るとか
いうところまでできた方がいい
っていうような話が出てきたりするんです
っていうので今
HTTPリクエストっていうようなイベントを
実装していて
そのパス部分とかも含めて
もう少し
実際に今発生しているマルウェア
サプライチャイン攻撃の検知に使える
ようなイベントを
実装中の段階です
どうですかね
そういった機能が
実装中ということなんですけど
そうですね いやなんかすごい期待だな
と思っていてやっぱりなんか
GithubだとグラフQL
だったりするんで
ポストだったら全部危ないかっていうと
グラフQLだと全部ポストだよね
とかもあるので結構この
辺り難しいんですよね
そうなんですよね
その辺りは本当に難しくて
どこまで取れるようにするかっていう
ような話もあって
結構悩んでる
まだ現在進行形で悩んでる部分もある
ポイントではありますね
ちなみにさっきGithubであれば
ホスト名で
ブロックできないというような話だったんですけど
有名な
危ないドメインは
全てブラックリストとして
管理してる
みたいなのってあったりするんですかね
そうですね ここ最近起きた
サプライチャイン系の大きいイベントの
通信先みたいなものは
ルールに今も入っている状態ではあるんですけども
やっぱりGithubのIPアドレスとか
Githubのドメインはブロックできないので
そこはもう穴として残っているというのが
現状の段階ですね
難しいですね そこら辺に関して
そうですね もう少しやっぱり
情報が取れるとマルウェア特有の
動きをさっき言った
汎用的なところは難しくても
特別なこのマルウェアは
ここに通信するかそれを検知する
ぐらいのところまでは行けるんじゃないかというところで
実装していきたいな
と思っているところですね
うん
さっき話でもあった
GraphQLのボディの部分
どうやって解決するのかみたいな
すごい難しそうなんですけど
普通に聞いていて
どうやる予定なんですかね
ここに関しては
そうですね まだ検討中のところも
あるので
これから変わる可能性もあるんですけども
今リクエストをどう
まず読み取るか
という話があって
今例えば
HTTPSの通信で多くの通信が
行われていると思うんですけども
その通信って暗号化されているので
EBPFで普通にネットワークの
レイヤーを見ても何も
見えないんですね
見えるとしてもギリギリSNI
というようなサーバーのネームインディケーター
みたいなところで
ドメイン名のレイヤーまでしかやっぱり取れない
というような話になってきますと
なのでカーネインの
レイヤーじゃなくて
YouProveというユーザーランドの
レイヤーをフックする機能というのが
EBPFにはありまして
それを使って
例えばOpenSSLに
渡る関数に
フックをかけて
その関数上
関数に渡るその引数
の情報を見て
どうにか検知につなげる情報を取れないか
例えばパス情報とか
あとはメソッドとか
あとはどこまでやるかなんですけど
リクエスト情報を検知まではできるようにするとか
ログとしては残さなくても
検知まではできるようにするみたいな
そういったことが今後必要になってくるかな
と思っているところですね
なるほど暗号化前の情報を
取るみたいなことですね
そうですね
確かにそれができたらいいなとは思いつつも
やっぱここら辺はあれですね
別のセキュリティとの
兼ね合いも
なんとなくありそうだなと思いますね
まさにそうですね
セキュリティの話もありますし
あと複雑性とか
あとは互換性の話とかで
一番ちょっと
バグを生みやすいエリアですね
ここら辺も
タクミランナーとかとの
協調とかができると
より
すごい強硬の形になってく
っていうところも若干あったりするんですかね
そうですねやっぱり
プライバシーに配慮は必要なんですけども
その上で送れるイベントは可能な限り
送った方がディテクションの観点では
いいっていうのがやっぱりあるので
そこの観点でタクミランナーと
協調できたらなと思っているところです
ありがとうございます
結構お話
今後の展望と正式リリース
いい話聞けたかなと思うんですけど
片杉さん
他にあったりしますかね
そうですね結構
いろいろ聞けたんじゃないかなと
思ってますが
ラングさん的にどうですか
そうですねいろいろ聞いていただいて
ありがとうございます
他
ラングさん的に
今後こういうこと
さっきのお話の中でも
いろいろあったかなと思うんですけど
今後の展望というか
今年中には
ここまで行きたいなみたいなのあったりしますか
そうですね結構実は今の段階で
flatさん
gmoflatsecurityさんとの
協業みたいなものが発生
したのはすでに結構
嬉しいなと思っていて
やっぱりいろんな会社と一緒に
今やれそうなので
そこは嬉しいなと思っている
上で
実際に今まだプレリリース
という風に見えるという段階なので
ちゃんとしたリリースに持っていきたいというのを
今月か
来月までにはしたいなと思っているのと
それに伴って
なるべくいろんな会社で
実際に使われるものになってほしいなと
いうのがあります
と
来月
9月か
遅くとも10月くらいには
正式リリースがされていると
期待しますね
なるほど
正式リリースはバージョン1.0.0
とかになる?
そこはちょっと悩んでいるんですけども
今は
プレリリースですよというのを
Readmeに書いている段階なので
実際にリリースしましたよという風に書き換えるのが
一番メインかなとは
思っています
ユーザーの観点で
自分から言うとすでに
ログを取りたいだけだったら
すでに十分機能としては揃っているので
とりあえず入れて
何か起こった時に
今だと何も分からないので
シャシリセンサー入れておくと
どこと通信したのとかどこのファイル見に行ったのとか
そういうのは見れるので
現時点でも入れたら
すごい便利だよとは思っています
やっぱり検知までしてほしい
ってなると
まだまだいろいろ機能足りてないな
って思う部分もあるので
その辺は今後になると思うんですけど
現時点でもログだけは
全然普通にできているので
みんなも入れたらいいんじゃないかなと
思っています
じゃあぜひこれを
お聞きの皆様は
シアシリセンサー入れていただけたらな
と思うんですけど
その上で
何か実際に
気づいたところとかあったら
GitHubの一周とかで報告
とかすればいいような形なんですかね
GitHubの一周で報告していただければと思います
ありがとうございます
番組紹介とエンディング
では今回はここら辺にして
いけたらなと思うんですけど
ランクさん改めましてありがとうございました
ありがとうございました
ということで今回はここまでにしたいな
と思います
ヤウヨロズのOSSでは毎回一つのOSSを
取り上げてそれについて片付いた辺とかで
技術的なところも深掘りしながら
話をしていく番組です
今回みたいな形でですねランクさんをお呼びして
いろんなゲストさんを
お呼びしてOSSについて
お話しできればなと思ってますので
もし私も自分も
出たいよというような方がいましたら
コメントとかいただけると非常に嬉しいので
よろしくお願いします番組についての感想なども
お待ちしていますのでよろしくお願いします
Xなどでつぶやく際には
ハッシュタグヤウヨロズのOSSをつけていただけると
見つけやすくなるのでよろしくお願いします
それでは今回も
ありがとうございました
ありがとうございました