
■はじめに
本記事ではCrowdsrike Falcon for IT機能に追加された"パッチ管理機能"のご紹介を掲載しています。
※現状はパッチ管理機能についてはBeta版という扱いです。
正式リリースの折には仕様の変更などもあり得るためご注意ください。
機能の使い方や用途などがわからないといったお悩みをお持ちの方はぜひご覧ください。
=============================
もくじ
■パッチ管理機能?
■有効化手順
■使ってみた
■使用感など
■最後に
=============================
■パッチ管理機能?
CrowdstrikeはFalcon for ITで複数端末の状態を可視化したり操作する手段をひとつ増やしました。
今回ご紹介するパッチ管理機能は、その技術を利用してWindowsの複数端末にパッチを展開する機能です。
![]()
今までExposure Managementで脆弱性の可視化はかなり簡単にできたものの、
パッチの一括適用にはもう一つ効率的な手段が欲しかった。という部分がありました。
今回のアップデートでそれが実現した!ということですね。
では、利用の要件から見ていきましょう。
===================
要件
・サブスクリプション:Falcon for IT
・センサーのサポート:サポートされているすべてのセンサーバージョン
・対象ホストシステムの要件:サポートされているすべての64ビットオペレーティングシステム
また、RTRポリシーとIT自動化ポリシーの設定が必要です。
※以下手順内に記載
最低要件:
・PowerShell 5.1
・メモリ(空き容量)1GB
・ディスク容量 32GB
・CPU 2コア
・.NET Framework 4.5.2
・インターネット速度(ダウンロード):5Mbp
推奨要件:
・PowerShell 5.1
・メモリ(空き容量)2GB
・ディスク容量32GB以上
・CPU 2コア
・.NET Framework 4.8
・インターネット速度(ダウンロード):10Mbps
その他
WMF 5.1: 2012年版と2008年版のインストール
ネットワーク:WSUSを使用する場合:ポート8530~8531(デフォルトポート)
マイクロソフト:80/443
※2026/7月現在
===================
一般的な社用PCの基準でいえば、厳しいものはないですが
強いて言うのであれば空きメモリとディスクは利用状況にもよるのでここだけ少し気を付けたいですね。
とはいえ実質Windows10や11では特に気にすることなく使えそうです。
■有効化手順
まず、Falcon for ITのポリシー(ITの自動化ポリシー)でパッチ管理の項目でチェックを付けて、デバイスグループにポリシーを割り当てましょう。![]()
Falcon for IT利用の前提であるレスポンスポリシー(RTR)の設定も必要です。
管理コンソールからエンドポイントにクエリを投げたりファイルをプッシュするには事前に関連したコマンドの実行許可です。![]()
■使ってみた
スキャンの実行
まずこちらがまだ環境のスキャンを行っていない画面です。
ポリシーを適用すると、1日1回適用可能なパッチを判定するスキャンが走るようになります。
初回含むスキャンは1日1回実行されるようですが、時間などの調整や確認は現状不可?のようです。
(履歴も日付単位)
弊社の環境では朝の10時前後にパッチ適用状況が更新されておりました。
ただ、後述しますがスキャンの負荷は結構低いようです。
リソースをモニタリングして検証しましたが、スキャン結果が更新される前後の時間で見ても
スポット的なリソース高騰は見られず。という結果でした。
こういったスキャンは通常かなり負荷があるので、上記が基本的な仕様ならうれしい限りですね。![]()
スキャンが終了すると、パッチ/ホストの画面にスキャン結果に応じた内容が反映されます。
パッチの画面ではデフォルトで「適用可能なパッチ」と「置き換えられたパッチ」がフィルタされ、
簡単に判断できるようになっています。
※置き換え=脆弱性(KB)に対してパッチが出されますが、後発的にリリースされたパッチが
前のパッチの効果を包含している場合があります。それを置き換えとしています。
つまり無駄なパッチまで適用しなくて済むような配慮ですね。
↓パッチ画面

↓ホスト画面

デプロイメントの作成(パッチの適用)
せっかくなので複数のパッチを複数端末に適用してみます。
パッチを指定して、[デプロイメントの作成]をクリックします。
ターゲット/対象パッチの編集と確認をして次へ
※ちなみにスキャンができていないと、対象端末は当然リストされません。
ちなみにこの時点でいくつかの端末に仕掛けを施しました。
・別経路でアップデートをかけてわざと失敗するようにした端末が1台(失敗の理由が出るのか試したい)
・オフラインにしていた端末が1台(オフラインの処理はどうなるのか)
・リモート端末(何かしら結果に差分が出るか確認)![]()
スケジュールの設定(1回のみ)
オフライン端末の処理について、おそらくこの設定値の中の"期間"の範囲内でオンラインになった場合は
そのタイミングで適用が試行されます。後述しますが2時間後にオンラインにした結果無事適用されました。![]()
スケジュールの設定(繰り返し)![]()
通知と再起動の設定
各々チェックを入れる通知と再起動が実行されるようになり、詳細な設定欄が表示されます。![]()
↓チェックを入れた画面![]()
↑この画面で適用を開始できます。
では作成されたデプロイメントの状況を確認してみましょう。>詳細ページを表示![]()
デプロイメント作成直後の概要ページです。
適用の状況はしっかりとリアルタイムに追いかけられるようになっています。
また、思惑通り適用に失敗したホストが1件出ています。
インストールが開始済みとなっている筐体が2台、
まだ実行中のものが2台あります。![]()
ステータスページでデバイスごとに適用状態が確認できます。
ちなみにInstalation Durationは、字面通りに受け取るとインストール処理にかかった時間です。
無い役をご説明すると。。。
・1番上の筐体...これはデプロイメント直前に筐体側にログインしアップデートを行いました。
そのため、有効なアップデートが無いと判断されアップデート自体は失敗しています。
ある意味で正しく失敗したという事になり、その場合はこの表示になるという参考です。
・2番目の筐体...2件適用し、1件失敗(上記同様適用済みにした)の場合どうなるか試行しました。
2枚目の画像を見ると、パッチごとに失敗理由が見れるようですね。
・3番目の筐体...これはリモート環境にある筐体です。
基本的に格安で貧弱な回線を使っている環境なので、その影響か若干時間がかかったようです。
実運用では影響のないレベルですね。
・4番目の筐体...これはデプロイメント直前にオフラインにした筐体です。2時間後に電源を入れました。
具体的な結果は後述します。
・5番目の筐体...こちらは検証環境で正常な状態でデプロイを実施した筐体です。
エラーもなく、デプロイ直後に適用成功しています。![]()
そしてデプロイ実行直前に電源を落とした筐体はどうなるかの確認結果です。
大体2時間後(22時10分ごろ)に電源を入れると...。
10分ほど経過後に無事適用されました。
おそらくポーリングなど何かしらのステータス検出機構で、オフラインの端末も設定した期間内であれば
適用がトリガーされるようですね。オフライン対策もばっちりです!![]()
■使用感など
非常に簡単にパッチ適用ができました。
これまでCrowdstrikeの課題であった複数端末への一括のパッチ適用や、他の製品で課題となるオフライン端末への対処を同時にクリアしてくれたことにも感動です。
また、CrowdstrikeのUI自体、1本道で使いやすいことも運用のテンプレート化を考えると大事な要素ですね。
他の製品との差別化をするとすればこういった簡易性や今後脆弱性関連の機能(Exposure Management)をいかにシームレスに取り入れて活用するかというところではないでしょうか。
脆弱性とパッチの画面のシナジーは高い方が良いですからね。
しかしながら、現状でもパッチ適用したいだけであればもう十分なのでは?
と思えるクオリティの新機能でした。
■最後に
Mythos関連のトピックもあり、脆弱性対応には確実な手段を持っておきたい昨今です。
それら機器選定のお役に立てましたら幸いです。
以上、Falcon for ITのパッチ管理機能のご紹介でした。
ご一読いただきありがとうございました。
※本ブログの内容は投稿時点での情報となります。今後アップデートが重なるにつれ
正確性、最新性、完全性は保証できませんのでご了承ください。
他のオススメ記事はこちら
著者紹介
SB C&S株式会社
技術本部 技術統括部 第4技術部 1課
宮澤 建人
