サーバーの脆弱性通知メールの一次切り分けを自動化した話

この記事は、 NTT Communications Advent Calendar 2024 24日目の記事です。

システムを運用していると日々のアラートメールへの対応の手間を減らしたいと感じることはありませんか？ 例えばセキュリティアラートに日々対応している運用者の方は、アラートの中に含まれる誤検知・過検知への対応に負担を感じている方も多くいらっしゃると思います。 この記事では、そのような誤検知・過検知対応の負担を削減するためにサーバーの脆弱性通知メールの一次切り分けを、マイクロソフト社が提供しているローコードツールであるPower Automateを使って自動化した話を紹介します。

はじめに

こんにちは。ソリューションサービス部の牧です。 普段はセキュリティソリューションの開発やプリセールスの業務を行っています。 この記事では、私が所属しているチームで管理しているLinuxサーバーの脆弱性通知メールの一次切り分けを、マイクロソフト社が提供しているローコードツールであるPower Automateを使って自動化した話を紹介します。

脆弱性通知メールの一次切り分けを自動化したいと思った背景

私が所属しているチームでは、検証用にLinuxサーバーを運用しています。社内の規定に従って、ソフトウェアなどで発見された脆弱性の対策状況を管理するシステムにサーバーのOSなどの情報を登録しており、ほぼ毎日2通～5通ほどの新規の脆弱性の通知メールを受信しています。 新規の脆弱性が発見された場合、脆弱性の深刻度に応じて対策完了までの期限が定められているため、その期限までに対策を完了させる必要があります。 そのため定期的に脆弱性通知メールの内容を確認し、サーバーにログインして脆弱性の発見されたソフトウェアがインストールされているかどうかを確認して、必要であればパッチ適用を実施しています。 脆弱性通知メールの中にはサーバーにインストールしていないソフトウェアのものも多く含まれており、毎回サーバーにログインして切り分けをするのは大変なので、Power Automateを活用することでこの確認作業の手間を減らしたいと考えました。

作成したPower Automateのフロー

作成したPower Automateのフローの処理の流れは以下の通りです。

1. 脆弱性通知メールを読み取る
2. メール本文からCVE-IDを抜き出す
3. CVE-IDが含まれない場合、「CVD-IDなし」フォルダにメールを振り分ける
4. Canonical社が公開しているUbuntu Security APIからCVE-IDを使って脆弱性のあるパッケージ名とバージョンを取得する
5. 予め保存しておいたインストール済みのパッケージ一覧に脆弱性のあるパッケージがあるか突合する
6. パッケージ名とバージョンがどちらも一致した場合、「パッチ適用が必要」フォルダにメールを振り分ける
7. パッケージ名のみ一致した場合、 「パッチ適用済み」フォルダにメールを振り分ける
8. パッケージ名とバージョンがどちらも一致しない場合、「該当なし」フォルダにメールを振り分ける

実際に作成したPower Automateのフローは以下の通りです。

フロー作成において大変だった点

フローの作成において大変だった点は以下の2点です。

NVDのAPIが採用しているCPE（ソフトウェア名やバージョンの識別子）を利用した脆弱性の突合が難しい

当初は脆弱性のあるパッケージの突合にCanonical社が公開しているUbuntu Security APIではなく、NVD(National Vulnerability Database)という最も広く利用されている脆弱性情報データベースのAPIを利用しようとしていました。 NVDでは、脆弱性情報データベース内の脆弱性識別子CVEと結びつけられたCPEという識別子がソフトウェアと脆弱性を突合させるために利用されています。 例えば、Microsoft社のInternet Explorer 8.0.6001 BetaをCPEで表現すると、

cpe:/a:microsoft:internet_explorer:8.0.6001:beta

となります。 しかし、一般的に全てのソフトウェアに対して普遍的な識別子は存在せず、ソフトウェアを一意に特定することは難しいと言われています。 OSSのTrivyも、CPEを使わず各ベンダーが出している脆弱性情報を使いマッチングを行っています(参考)。 そのため、今回は複雑なスクリプト実行ができないこともあり、CPEではなくaptコマンドで取得できるソフトウェアの名前とバージョンと同じ形式で脆弱性のあるソフトウェアの名前とバージョンを取得できるCanonical社が公開しているUbuntu Security APIを利用することにしました。

フローのアクションの実行回数に制限がある

クラウド版の場合のフローの開発は、主に「①フロー作成画面で一連のアクションを設定する」→「②フローを実行してテストする」→「③実行結果を確認してエラーを修正する」→①に戻るという流れで進めると思いますが、開発が進んでアクションの数が増えるに従ってフローのアクションの実行回数をたくさん消費してしまっていたようで、実行回数の制限の80%に到達したところで警告メールが送られてきました(参考)。 制限を超えるとアクションの実行が制限されたり、遅くなったりする可能性があるそうなので、制限を超えないように気を付ける必要がありました。

フローを作成した結果

フローを作成した結果、下記の画像のように脆弱性の突合結果に応じて自動でメールのフォルダが振り分けられるようになり、毎回サーバーにログインしたり脆弱性のあるソフトウェアがインストールされているかどうかを確認する必要がなくなりました。

パッチを適用する際にはサーバーにログインする必要はあるのですが、特に誤検知・過検知への対応の手間を減らすことができました。

まとめ

今回はサーバーの脆弱性通知メールの一次切り分けをマイクロソフト社が提供しているローコードツールであるPower Automateを使って自動化した話を紹介しました。 最後までご覧頂き、ありがとうございました！明日の記事もお楽しみに。