Future Tech Blog
フューチャー技術ブログ
Securityカテゴリ

初めてのセキュリティ情報収集（mjckeck4）

こんにちは。Cyber Security Innovation Group（CSIG）の井上です。

部門名の通り、サイバーセキュリティに関する部署で、セキュリティコンサルティングやFutureVuls（ https://vuls.biz）という脆弱性対策サービスのコンサルティングやサポートをしています。

初めに

春の入門祭り2023 という事で、初めて脆弱性対応をする方に向けた記事を書いてみようと思います。
この時期になると、部門移動等で情報システム部に移動し「何をやっていいのか分からない…」という話も時々聞きます。

今回は、IPAの「mjcheck4」（ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html）というツールを使った、**セキュリティ情報の収集**についてお話しようと思います。

セキュリティ情報収集とは

世の中にはセキュリティ情報はいろいろあります。
例えば、雑に説明すると以下のようなものがあります。

  • 攻撃手法、攻撃者の動向に関する情報
  • IoC（Indicator of Compromise：侵害指標）の情報
    • マルウェアのファイル名や攻撃者の通信先IPアドレスなど、攻撃時に残された痕跡情報を示します。
    • 例えば、「特定のIPがIoCとして公開されたので ProxyやFirewallのブロック対象に追加する」「ネットワーク機器のログに該当のIPが存在すれば、攻撃を受けている可能性がある」、のような使い方をします
  • 脆弱性に関する情報
    • ソフトウェア等の脆弱性に関する、発見やPoC/Exploit（検証や悪用ができる実証コード）、更新プログラムの提供や回避策などの情報を示します。
    • 一般的に、脆弱性情報はNIST（National Insitute of Standards and Technology：米国立標準技術研究所）のNVD（National Vulnerability Database：脆弱性情報データベース）に登録され、日本国内で主に使われる製品はJVN（Japan Vulnerability Notes）に登録されていきます。
    • これらを、「いろいろなソースを集約」して「自分が利用している製品に絞って閲覧」するためには、何らかのツールや製品が必要になります。
      • 今回紹介する mjcheck4 もそのツールのうちの一つです
  • インシデントに関する情報
    • 実際に発生した被害の状況や傾向に関する情報です。
    • 一般的には、セキュリティ系のネットニュースなどを参考にすることが多いと思います。
  • etc

今回は、「初めてのセキュリティ情報収集」という事で、一番身近で活用しやすい「脆弱性情報の収集」について書いていきます。

IPA（独立行政法人 情報処理推進機構）とJPCERT/CC（JPCERTコーディネーションセンター）が共同運営している脆弱性対策情報 JVN iPedia（ https://jvndb.jvn.jp/apis/myjvn/）のデータを基に使う、脆弱性対策情報収集ツール mjcheck4 を見ていきます。

mjcheck4とは

ツールのページ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html を確認すると、「MyJVN脆弱性対策情報フィルタリング収集ツール（check）の4番目」の略称と思われます。
日本国内向け製品の脆弱性情報も含まれる「JVN iPedia」の情報を簡単に利用するためのツールです

  • 脆弱性対策情報収集対象製品を、、
    • グラフィカルに選択可能
    • SBOMでの入力も可能
  • 収集した脆弱性情報を、、
    • 画面上で閲覧可能
    • メール、SBOM、での出力が可能

今回はこのツールを使い、自組織が利用している製品の脆弱性を自動的に収集してみましょう。

使い方

導入自体は MyJVNのページ（ https://jvndb.jvn.jp/apis/myjvn/mjcheck4.html#mjcheck4_install）通りですので、省略します。

  • 利用規約について同意する
  • 対象のファイルをダウンロードし、setup.exeを用いてインストールする
  • 収集対象製品を選定し、データのダウンロード
  • 収集した脆弱性情報を閲覧

Windowsアプリケーションとして実装されているので、特に難しい事は無いと思います。
利用している製品を登録することで、JVN iPediaに脆弱性が登録されていれば通知がされる仕組みになっています。

  • バージョン番号は使わず、特定日以降の日付で発見されたもの、というチェック方法です。
    • そのため、まずは該当製品の過去の脆弱性を全件抽出し、現状を把握する必要があります。「収集起点日（最終更新日）」で指定ができます。
    • 一度チェックが終われば、あとは「新しく報告された脆弱性」を確認するだけになります。

設定

収集状況概要

脆弱性情報詳細

本ツールももそうですが、脆弱性検出の為にはソフトウェアの一意の特定が必要で、PCEという表記を利用しています。今回はこれについても説明します。

CPEとは

CPEは「Common Platform Enumeration：共通プラットフォーム一覧」と呼ばれる、ソフトウェアやファームウェアを一意で識別するための仕組みです。詳細はIPAの https://www.ipa.go.jp/security/vuln/
scap/cpe.html で解説がされています。

  • cpe:2.3:{種別}:{ベンダ名}:{製品名}:{バージョン}:{アップデート}:{エディション}:{言語}の構造です
  • 脆弱性管理製品にCPEを登録することで、OSベンダーパッケージ提供以外の製品の脆弱性を検知することを想定しています
    • CPE登録 -> 脆弱性情報で「影響を受ける製品」として登録されるCPEとマッチング -> 該当すれば、その脆弱性が内包されると判断します

NVDであればSearchCommonPlatformEnumerationsというページで検索ができるのですが、例えば以下のようになります。

  • FortiOS（ForinetのFortigate製品のOS）
    • cpe:2.3:o:fortinet:fortios:7.2.4:*:*:*:*:*:*:*で表現されます
    • 後半の*は、エディションや言語などが想定され、通常は*のままで利用されています
  • Fortigate 1000e（ハードウェア）
    • cpe:2.3:h:fortinet:fortigate-1100e:-:*:*:*:*:*:*:*で表現されます

mjcheck4はバージョン2.2の表記方法を使っているようで、アップデート以降の表記が上記と異なっていますが、意図としては同じものです。
以下にFortiOSの例を示します。

  • version 2.2
    • cpe:/o:fortinet:fortios:7.2.4
    • シンプルに、バージョンまでを表現しています
    • mjcheck4のCPEはこのタイプです
  • version 2.3
    • cpe:2.3:o:fortinet:fortios:7.2.4:*:*:*:*:*:*:*
    • CPEのバージョンを示す:2.3:部分が追加されています
    • 製品バージョン以降に、詳細な分類をするための項目（:{アップデート}:{エディション}:{言語}）が用意されています
      • 用意されていますが…、あまり使われていない印象です。しかしながら、項目として用意されていること、が重要です。

OS標準パッケージ以外の製品（ソフトウェアだけではなく、ハードウェアも含めて）の脆弱性管理をする場合、このCPEというものをよく使うので、おおよそのフォーマットは覚えておいた方が良いです。

脆弱性情報収集後の対応

検出後の対応については本ツールの範囲外ですが、概要を書いておきます。

一般的には下図のようなフローを随時回していくことになります（状況により諸説あります）。

簡略化すると以下のようになり、本ツールは「脆弱性情報の収集」部分となります。

  • 対象のソフトウェアを設定する部分が「対象の把握」に該当します
  • ツールによるチェックが「脆弱性情報の取集」に該当します

収集した脆弱性情報を確認し、適用要否を判断し、実際に適用/回避策の適用 を行います。

  • クライアントな端末の場合、多くは判断不要でアップデートができると思います。
    • 例：Windows自身のアップデートや、Google Chromeなどのアプリケーションのアップデート
  • サービス提供をしているネットワーク機器やサーバの場合、適用要否を検討して対応を決めます。
    • アップデートによる挙動変化が無い、若しくは許容できることを確認するために、検証が必要です。
    • アップデートを行わないことにより発生する損害リスクを考慮し、許容できる場合は対応保留とする場合もあります。
    • これらの判断の為に、「脆弱性対策情報」の詳細項目を確認します。
      • CVSSの情報などを基に、システムが置かれている環境などを考慮して決定します。

本ツール mjcheck4 は、脆弱性対策情報の内容が少し分かりづらいかもしれませんが、「脆弱性対策のはじめの一歩」としては有効だと思われます。

  • Pros
    • 無償で、JVN iPediaの情報を収集/選別できる
      • きちんと設定できれば、一旦は問題ない範囲を対象と出来る
    • メールでの通知機能がある
    • 対象製品登録が、GUI的に比較的楽
  • Cons
    • 脆弱性対策情報が少ない
      • JVN iPediaの情報のみで、CVSSでしか判断できない（慣れてくると、物足りない）
    • 自動運行が難しい
      • アプリ起動時にチェックが走る為、例えば毎日起動しなおす必要がある
    • ソースがJVN iPediaである
      • NVDやベンダーの脆弱性情報が全てあるわけではない
        • これにより、例えば UbuntuやRed HatなどのLinuxサーバの脆弱性を確認するのは難しい
    • バージョン比較はできない
      • mjcheck4のUIでは、対象製品のバージョンまでは登録できない
        • 例えば、cpe:/a:oracle:java_seのような記載となり、java SEのバージョンまでは記載しない
      • 特定バージョンのみ影響を受けるような脆弱性の場合、バージョンを考慮していないので手動で影響対象かを判別する必要がある

まだ脆弱性情報収集と対策を本格的に実施していない組織においては、以下のステップを踏んだ方がよさそうです。

  • まずはmjcheck4でを使う
    • mjcheck4 で、主要なクライアント／サーバ/ネットワーク機器 などを登録して、現状を把握する
      • 登録するために、現状を確認するというアクションが行える
  • 一部に於いて、脆弱性対応を始めてみる
    • 前述の対応フローを参考に、脆弱性情報を読みながら、できるところから対応をしてみる
    • 一部ずつ始め、できる範囲を増やし、対応に関する知見を得る
  • 商用製品の脆弱性管理ツールを検討する
    • 商用製品であれば、mjcheck4で不足していると感じる部分が提供されていることが多いので、乗り換える
      • 対応のタスク管理機能、バージョンによる脆弱性の有無判断、対応優先度決め、多数の環境への対応、等

まとめ

mjcheck4は、比較的簡易にセキュリティ情報収集を始められることが確認できました。

脆弱性情報を収集した後の「脆弱性対応」をするには少し物足りないものですが、「まずはやってみる」という点では良いのではないかと思います。

こういうツールでまずはセキュリティ情報収集/脆弱性対応の必要性を感じつつ、大規模且つ重要なシステムは FutureVuls などの脆弱性管理サービスを使うのが良いかと思います。

もし、脆弱性対応についてお困りのことがあれば、井上までご相談ください。
製品ありきではなく、何らかの知見を共有できるかもしれません。

以上です。

次は市川さんのCloud Data Fusionで始めるETL入門です。