ペネトレーションしのべくん

さようなら、すべてのセキュリティエンジニア

docker-composeしようとしたら「ERROR [internal] load metadata」というエラーが発生する

docker-composeRubyコンテナを使ってビルドしようとしたら、以下のようなエラーで失敗しました。

$ docker-compose run web rails new . --force 
--no-deps --database=postgresql --skip-bundle
[+] Running 1/0
 ⠿ Container ugiene-db-1  Created                                                       0.0s 
[+] Running 1/1
 ⠿ Container ugiene-db-1  Started                                                       1.1s
[+] Building 0.8s (3/3) FINISHED
 => [internal] load build definition from Dockerfile                                    0.1s 
 => => transferring dockerfile: 32B                                                     0.1s 
 => [internal] load .dockerignore                                                       0.1s 
 => => transferring context: 2B                                                         0.0s 
 => ERROR [internal] load metadata for docker.io/library/ruby:3.1.3                     0.6s 
------
 > [internal] load metadata for docker.io/library/ruby:3.1.3:
------
failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to create LLB definition: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: ``

以下を順番に実施した結果、解決しました。もしかしたら最後だけでもよかったのかも。

  • (WSLでなく)Windowsdocker login し直す
  • Docker Desktopの設定ファイルから {"features": {"buildkit": true}} を削除する
  • Docker Desktopをリスタートする
  • docker pull ruby:3.1.3 する
  • docker-compose run する

Virtualboxのウインドウが動かせない時はホストキーを押す

Kali LinuxやParrot OS上で、VirtualboxVMを起動している最中、VMのウインドウを動かせないという事象をしばらく放置していました。

調べてみたら以下の記事が出てきて、書かれている通り、ホストキーを押してみたら動かせるようになりました。

askubuntu.com

I find the same thing when imwheel is running, the utility that allows change to the mouse wheel. Holding down the Right-Control dows allow VirtualBox windows to be moved around.

ちょっと触ったら肩や腰の痛みが一瞬で治る整体の動画を観ている気分でした。

『CSIRT人材の育成 Ver 1.0』の内容と思ったことメモ(コンセプト、役割グループ、基礎教育)

はじめに

日本コンピュータセキュリティインシデント対応チーム協議会(日本シーサート協議会、NCAなどとも)が『CSIRT人材の育成 Ver 1.0』を公開しました。

www.nca.gr.jp

インシデントが起きると様々な役割の人達が入り乱れて、時に統制され、時に混沌としたまま収束へ向かうわけですが、役割の分類については『CSIRT 人材の定義と確保 Ver.2.1』で取り組まれています。『人材の育成』は、『人材の定義と確保』で定義した各役割を育成するにあたって、どういった教育が必要かをまとめたものです。

また、この資料はあくまでNCA人材育成WGで収集・編纂したベストプラクティスであって、組織によってCSIRTの業務内容や人材構成大きく異なることを前提に、「それぞれの組織に合わせて柔軟に考えてほしい」とも書いてあります。

自分自身のキャリアパスやラーニングパスの整理のためにも、通しで読んでエッセンスをまとめておきたいと思います。

育成STEPの定義

『人材の育成 Ver 1.0』では、育成のSTEPを以下のように定義しています。育成カリキュラムや評価制度を自分たちで作ろうとした時、レベル分けというアイデアは容易に思いつきますが、「どう分けるか」って結構難しいですよね。

このガイドラインでは0から5のSTEPを定義していて、そのうち担当役割における一人前になるまでのSTEP3までについて、資料内で言及があるみたいです。

STEP 対象者 内容 目標
0 新規配属者 自社のセキュリティ業務を行うために必要な基礎知識を身に着ける。 基礎教育修了者
1 基礎教育終了者 組織における自分の役割、立ち位置を理解する。 担当役割の初心者
2 担当役割の初心者 担当する役割のより深い知識を、OJTを通して身に着ける。上位職が支援すれば業務をこなせるようになる。 担当役割の見習い
3 担当役割の見習い 実践、訓練を通じて知識経験を慣熟させる。独り立ち。 担当役割の一人前
4 担当役割の一人前(トレーナー) 各役割における想定外事象に対応できるスキルを身に着ける。 担当役割の熟練技術者
5 - -

役割グループの定義

『人材の定義と役割』では、インシデントにかかわる人々の役割を細分化しています。それぞれについて求められる専門性はあるものの、基礎的な教育については共通化していい組み合わせがあるだろう、というのが『人材の育成』での考え方のようで、7つのグループに分かれています。『人材の育成』には『人材の定義と役割』における機能分類を基準とした表が載っていますが、この記事では兼任グループを基準にした表を作ってみました。

兼任グループ 役割 機能分類 役割
兼任グループ1「連絡・全体統括」
  • 連絡窓口として、主に関係者、経営者に対する説明をする。
  • 専門家などの協力のもと、フェーズ毎の対応戦略を策定する。
  • インシデントマネージャーへ対応を指示する。
情報共有 社外PoC:自組織外連絡担当
社内PoC:自組織内連絡担当
リーガルアドバイザー:リーガルアドバイス担当
ノーティフィケーション担当:自組織内調整・情報発信担当、IT部門調整担当
インシデント対応 コマンダー:CSIRT全体統括担当
インベスティゲーター:調査・操作担当
トリアージ担当:優先順位選定担当
兼任グループ2「インシデント対応」
  • 全体統括の戦略に基づいて作業を実⾏する(実施にあたっては、⾃社インフラ部⾨やシステム部⾨と協⼒)。
  • SOCから上がってくるアラートを受け、該当システム部⾨と調整、調査する。
  • インテリジェンスを含めた脆弱性情報の対応要否やリスク判断を SOC とともに⾏い、関係者に対して連絡、調整、対応依頼する。
インシデント対応 インシデントマネージャー:インシデント管理担当
インシデントハンドラー:インシデント処理担当
兼任グループ3「情報収集/情報分析(SOC/監視)」
  • SOC/監視システムと業務を設計/構築/導入/運用/維持する(注:設計/構築/導入は熟練技術者レベル以上の業務)。
  • セキュリティ機器から通知されたアラートを分析して、正検知/誤検知を判定する。
  • 検知したアラートから監視対象システムへの影響の有無を推測する。
  • 監視対象システムへ影響するおそれのあるアラートの情報をまとめて、インシデント対応部⾨へ連絡する。
  • インシデント対応部⾨からの調査依頼に対応して、セキュリティ機器の情報を調査、分析する。
  • 定期的にアラートを統計的に分析して、レポートを作成する。
  • メーカー提供の新しい検知ルール、定期レポートの結果、独⾃に収集した攻撃情報、インシデント対応部⾨のフィードバックなどを使って、セキュリティ機器の検知精度を維持、向上する。
  • 定期的に作業記録を振り返って、業務の維持、改善を行う。
情報収集・分析 リサーチャー:情報収集担当
キュレーター:情報分析担当
兼任グループ4「脆弱性管理/診断」
  • 社内の各種システム/ソフトウェア(開発製造時、運⽤時)の脆弱性管理ルールの作成と施⾏
    • 社内の各種システム/ソフトウェアのリリース前/維持運⽤中の脆弱性診断ルール/合格基準を作成し、ルールを施⾏する。
    • パッチ/脆弱性情報の収集と社内配信、注意喚起、パッチ適⽤を指示する。
    • 社内の各種システム/ソフトウェアのインベントリ情報、パッチ/脆弱性情報を管理する。
    • 社内の各種システム/ソフトウェアのインベントリ、パッチ適⽤状況を管理する。
    • 社外/第三者からの脆弱性情報の連絡窓⼝を設置し、維持運営する。
  • 脆弱性診断の請負業務
    • 各種脆弱スキャナを使った社内の各種システム/ソフトウェアの脆弱性診断を実施する。
  • ⾃社製品/サービスの脆弱性対応業務
    • ⾃社が維持運⽤/販売しているシステム/ソフトウェア/サービスの脆弱性対応業務全般
    • ⾃社で開発したソフトウェア製品に関連する脆弱性情報を収集する。
    • ⾃社で開発したソフトウェア製品で発⾒された脆弱性情報の脆弱性をハンドリングする。
    • バグバウンティプログラムを実施する。
情報収集・分析 脆弱性診断士:脆弱性の診断・評価担当
兼任グループ5「フォレンジック
  • 解析/抽出/examination
    • 削除データ復元
    • 分析対象データ/ファイル/ログの抽出(Acquisition、パケット解析)
    • 各種正規化(タイムスタンプ時刻、⽂字コード変換)
    • タイムライン作成
  • 報告/reporting
    • 原因分析
    • 侵害経路分析
    • 被害分析(侵害有無、漏えい有無、被害範囲)
    • 対策検討
    • 報告書作成
情報収集・分析 フォレンジック担当
兼任グループ6「セキュリティマネジメント」
  • 情報資産の管理や管理ルールの維持、改善を実施する。
  • リスクアセスメントを計画実⾏し、⼿法の問題点の改善を実施する。
  • リスク対策を維持し、既存対策の問題点の改善を実施する。
  • セキュリティインシデント管理(報告フローなどのインシデント管理システムを指す)を維持し、改善を実施する。
  • 情報セキュリティマネジメントシステムISMS)を維持し、改善を実施する。
  • 従業員に対して情報セキュリティ教育を実施し、改善を実施する。
  • 情報セキュリティガバナンスの取組みを維持する。
  • コンプライアンスを維持し、強化を実施する。
  • 事業継続計画(BCP)の定期的な⾒直しや訓練を実施する。
  • 災害対策(DR)の定期的な⾒直しや訓練を実施する。
情報収集・分析 セルフアセスメント担当
自社組織内教育 教育担当:教育・啓発担当
兼任グループ7「開発/開発支援」
  • ⾃社で開発するシステムのセキュリティ要件定義とセキュリティ基本設計を⾏う。
  • ⾃社で開発するアプリケーションがセキュリティ要件を満たし、適切なログが出⼒されるように開発者を⽀援する。
  • ⾃社で導⼊を検討しているパッケージ製品やクラウドサービスがセキュリティ要件を満たし、適切なログを出⼒できるかを確認する。
  • ⾃社システムのサーバーOS が要塞化要件を満たし、適切なログが出⼒されるようにインフラ設計者を⽀援する。
  • ⾃社システムのネットワークにおいてネットワークアクセス権が最⼩になるように、また適切なログが出⼒されるようにネットワークエンジニアを⽀援する。
  • ⾃社システム環境に境界防御を⾏っている部分がある場合、侵⼊検知/侵⼊防御などの製品を導⼊し維持管理を⾏う。
  • ⾃社システムの利⽤する DB のアクセス権が最⼩になるように、また適切なログが出⼒されるように DB 設計者を⽀援する。
  • 統合ログシステムにすべてのログを集約し、適切な検知アラートや適切なレポートが SOC に出⼒されるように構築する。
  • マルウェア検知/除去/検疫などの基盤を整え、検知された場合は SOC に対してアラートが発報されるようにする。
  • 継続的脆弱性管理のシステムやサービス、改ざん/変更検知のシステム、DB Firewall や WAF など他のセキュリティソリューションについても正しく機能するように維持管理を⾏う。
  • ⾃社システムの脆弱性の診断が定期的に⾏われるように計画し、調整し、実⾏する。脆弱性があった場合はアプリケーション開発やインフラの担当者が修正できるように⽀援する。
  • ⾃社システムが世の中のセキュリティ基準と⽐較して妥当な注意が払われている状態を維持するように、公的機関や他のセキュリティ団体などが発表しているガイドラインを満たした⾃社のガイドラインを作成し、維持する。
情報収集・分析 ソリューションアナリスト:セキュリティ戦略担当

兼任グループを基準に見てみると、フォレンジック脆弱性診断などに比べて、グループ1「連絡・全体統括」でカバーする役割が多めですね。これらの役割は専門的な知識よりもコミュ力や組織理解、ビジネス理解が重要な点で共通するということだと思います。

参考までに、日本セキュリティオペレーション事業者協議会(ISOGJ)が公開している『セキュリティ対応組織成熟度セルフチェックシート』(ISOMM)では、グループ1のような役割は「自組織で実施すべき領域」ないし「自組織を中心に連携すべき領域」として位置づけられています。アウトソーシングしづらい領域こそ教育が重要なわけで、優先的に対応すべきなのかもしれません。

isog-j.org

基礎教育

『人材の育成』では、基礎教育を「CSIRT もしくはセキュリティ部⾨に配属された要員が、これから⾃社のセキュリティに関する業務を⾏うために必要な基礎知識を⾝につけるための教育である」としています。『人材の育成』でのグルーピングがあんまりしっくりこなかったので、私なりに「自社に関する理解」「CSIRTに関する理解」「セキュリティに関する理解」「関連法令に関する理解」の4つに分けてみました。

見るに、基礎教育にはプログラミングやTCP/IPなど、IT一般に関する知識は含まれていません。以降の担当別教育の内容を見てもITに関する基礎知識は含まれていないようなので、どうやら事前学習(入社時研修など)に含まれている前提のようです。兼任グループ1に分類されているようなマネジメント系の役割についても最低限身に着けているべき技術知識というのはあると思うので、ここをカバーする方法は別途考える必要があります。

また、法令に関しても、以下のように事前教育を前提とした部分がある旨の言及がありました。

契約不履⾏、損害賠償請求に関する⺠法、善管注意義務に関する会社法、個⼈情報保護法、マイナンバー法に関しては、特に CSIRT 業務に限らずとも理解しておくべき法令のため、全社教育で実施されているものとする。

以降、各役割については、必要に応じて個別に記事を作ろうと思います。

Go言語でMySQLのSQLインジェクション検証環境を作った

SQLインジェクションの検証環境が欲しくて、ついでにGo言語とGoのWebアプリケーションフレームワークEchoも触っておくかということで↓を作りました。ぜんぜん大したものじゃないんですが、日記として。

github.com

今はシンプルにJSONを返すだけですが、Reactでも学んでフロントもちゃんと作ろうかなと思います。Echoの機能も初歩の初歩しかやってないので、がんばります。

Echoを使うにあたっては、ISUCON12予選のコードを参考にしました。

github.com

以下、Go言語ではじめて何か作ったメモとか感想:

  • Go言語のパッケージやモジュールの概念について
    • とりあえず最初に go mod init github.com/shinobe179/repo_name する
    • 以降は、パッケージが必要になったら go get すれば勝手に足されていく
    • 今開発しているものをimportする場合、基本的にはGitHubにアップロードしてgo getしなければならないの?
      • そんなわけないよな
    • go mod tidyって使わなかったけどいいんだろうか
    • パッケージってどういう風に分けるのがいいんだろう?
    • ディレクトリってどういう風に分けるのがいいんだろう?

あとずっとPythonしか書いてこなかったので、型との付き合い方みたいなものに慣れていないと感じました。やることはあんまり変わらない(使いたい関数の引数と戻り値、そしてそれぞれの型を確認して使う)はずなんですが。

Docker Desktop for Windowsが「WSL_E_DISTRO_NOT_FOUND」というエラーを出していつまでも起動しない

はじめに

Docker Desktop for Windowsが動かなくて嫌な思いをしたのでメモです。

結論

ログファイルを見たら、 WSL_E_DISTRO_NOT_FOUND というエラーが出ていた。ググったら以下の記事が出ていて、これの内容に従った。

github.com

こうなってたところを、

PS C:\WINDOWS\system32> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2
  docker-desktop-data    Stopped         2
  docker-desktop         Uninstalling    2
PS C:\WINDOWS\system32>

こうして、

PS C:\WINDOWS\system32> wsl --unregister docker-desktop
登録解除。
この操作を正しく終了しました。
PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32>
PS C:\WINDOWS\system32> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2
  docker-desktop-data    Stopped         2
PS C:\WINDOWS\system32>

Docker Desktop for Windowsを再起動したら直りました。

PS C:\WINDOWS\system32> wsl -l -v
  NAME                   STATE           VERSION
* Ubuntu-22.04           Running         2
  docker-desktop         Running         2
  docker-desktop-data    Running         2
PS C:\WINDOWS\system32>

なんだったん?マジで。

OSVについて調べてみた

はじめに

Googleがosv-scannerというリポジトリを公開しています。どうやら脆弱性スキャナのようです。

github.com

これを使ってみる前に、OSVとかSBOMとか、知らなかった概念について先に掘り下げて置こうと思います。この記事ではOSVについて見ていきます。

OSV

トップページ曰く「A distributed vulnerability database for Open Source」とのこと。

osv.dev

Aboutでは、OSVは以下のものから構成されると説明しています。

  • OSV Schemaという脆弱性を記述するためのデータフォーマット
  • OSV Schemaで記述された脆弱性情報を集約、参照するためのインフラストラクチャー
    • サイトそのもの
    • API
    • ツール(osv-scannerもここに含まれる?)

OSV Schema

OSV Schemaがどんな感じか見てみることにします。

ossf.github.io

Aboutによると、OSV Schema策定にあたっての課題意識のひとつとして、各エコシステムでのパッケージの命名およびバージョニングとCPEを照合するのって難しいよね、というのがあるようです。

Enforces version specification that precisely matches naming and versioning schemes used in actual open source package ecosystems. For instance, matching a vulnerability such as a CVE to a package name and set of versions in a package manager is difficult to do in an automated way using existing mechanisms such as CPEs.

CPEという仕組み自体が結構きついよね、という話を以前フォロワーさんとした記憶があって、掘り返してみたらやっぱり嘆いてました。もっとも、今見返すと無意識的にプロプライエタリな製品について言及していたと思うので、このOSVのスコープ外ですかね。なんてったって「Open Source Vulnerabilities」だし。

OSV Schemaは、以下のような情報を含んでいます。

  • 脆弱性情報の公開日や更新日
  • 要約と詳細
  • 影響を受けるパッケージ
  • 参考URL
  • 重大度

severity

重大度を示す severity[]type というフィールドを持ち、これは執筆時点で CVSS_V2 もしくは CVSS_V3 の値をとることが想定されています。

ossf.github.io

そのうちEPSSとかも入ってくるんですかね?

www.first.org

また、このスキーマはありものの脆弱性情報の効率的な記述方法を提案するものであって、CVSSにとって代わるような新たな脆弱性評価手法を提案するものではないことが分かります。

affected

各パッケージへの影響範囲を示す affected[] は、以下の情報から構成されます。

  • package
  • ranges
  • versions
  • ecosystem_specific
  • database_specific

package

脆弱性の影響を受けるパッケージに関する情報です。以下の値を持ちます。

  • ecosystem: エコシステム名。 Go とか npm とか。
  • name: パッケージ名。
  • purl: purl-specという標準に則った、パッケージのURI。オプション。

purl-specというのは初耳でした。これもエコシステムによってパッケージの命名規則を統一することで参照しやすくしようというのがねらいのようです。

github.com

ranges

以下の値を持ちます。

  • type: indtoduced および fixed で使うバージョンの表現方法。
    • SEMVER: SemVer 2.0.0 に則ったバージョン表記。
    • ECOSYSTEM: 各エコシステムに則ったバージョン表記。
    • GIT: Gitのコミットハッシュ。
  • repo: パッケージのコードリポジトリのURL。affected[].ranges[].typeGIT の時は必須。
  • events[]: 脆弱性の各イベント(発生、修正など)に関する情報。
    • introduced: 脆弱性が発生したバージョン。
    • fixed: 脆弱性が修正されたバージョン。
    • limit: 上限。ってなんだ……??

versions

脆弱性があるパッケージバージョンのリストです。 affected[].ranges と役割が重複している感じがしますが、脆弱性があるバージョンを列挙してあるとぱっと見分かりやすいよねぐらいのフィールドなんだと勝手に解釈しています。

例えば、Log4Shellに該当するJSONファイルを見てみると、 affected.version がありません。

github.com

しかしosv.devで同じ脆弱性のページを見てみると、(JSONaffected.version はないのに)Affected versionsとして値がマッピングされていることが分かります。

osv.dev

後述する参考実装でも、rangesとversionsの両方を評価する実装になっているので、やはり意味合い的に重複するものみたいです。

affected[] による脆弱性評価

OSVで記述された脆弱性情報を用いて脆弱性評価をするコードの参考実装が紹介されていました。メインルーチンである IsVulnerable() だけ読んでみると、以下のようなロジックになっています。

  • 検査対象であるパッケージが affected.package と同一だったら次のチェックをする
    • 検査対象バージョンが affected.versions に含まれているか、affected.ranges に含まれていたら脆弱性あり
  • いずれにも該当しなければ脆弱性なし
func IsVulnerable(pkg, v, osv)
  for affected in osv.affected
    if affected.package == pkg
      if IncludedInVersions(v, affected.versions) ||
           IncludedInRanges(v, affected.ranges)
        return true

  return false

疑問点

参考実装では pkgosv.affected[].package を直接比較していますが、 これを成立させるために pkg をOSV形式に直すのって実は地道な努力が必要だったりしないか?と思うなどしました。それこそosv-scannerのソースを読めば解決しそうですが、それはまた次のお話ということで。

GCPの監査ツール「Forseti Security」を追う(第1回「挫折」)

先日、TrivyでAWSのセキュリティチェックができるようになりましたね(参考:クラスメソッドさんのブログ)。

dev.classmethod.jp

GCPGoogle Cloudと呼ぶ人もいるらしい)も近日対応予定!って感じみたいですが、直近さくっとチェックしたいニーズがあったので調べたところ、まずSpotifyが開発していたらしい、gcp-auditというリポジトリに辿り着きました。しかし、すでに開発が止まっている模様。

github.com

gcp-auditのREADMEから、Forseti Securityというツールに行き着きました。

forsetisecurity.org

Aboutをざっと読んだ感じ、GCPに特化したCloud Custodianという印象です。Inventoryを収集し、ScannerによってIAMやBacket ACLなどを監査、Enforcerで設定を強制し、Explaoinで可視化する。うーん、Trivyのセキュリティチェックとは、ちょっと毛色が違いそうです。

何はともあれ触ってみようということで、以下に取り組んでみます。

forsetisecurity.org

OPEN IN GOOGLE CLOUD SHELLをクリックすると、何やらチュートリアルっぽいものが始まりました。 GCPは進んでますね。

ちょっと進んだところでOrganization IDというものを要求されたのですが、なんじゃそれとなって断念。きっとAWSのArganizationと同じようなものだと思うんですが、私の体力とGCP力が足りず。また気が向いたらリベンジします。