表題は大風呂敷です
なんかこういきなりビジネスパーソンへのアピールがクリティカルヒットするビッグなタイトルをスローアウェイしてみたかった。反省はしていない。
一応言っておきますが、伺かはゼロトラストセキュリティの真逆を爆走するやつです。そのへんに転がってるDLL(SHIORIとかSAORIとか)を読める時点でセキュリティ何それ食えるのってやつですけど、そういう指摘はしてはだめです。
ゼロトラストセキュリティの基礎知識
ググれば本来の意味をちゃんと調べられると思いますが、ざっくり言うとファイアウォールとかだと限界があるので、そもそも会社のLANに特定条件の端末以外は接続できなくしようとか、いやもっと常時端末状態を監視すべきだとか、そういうハードなやり方でネットワークへ接続してくる端末を一切信用しない性悪説ベースの考え方のことですが…
いきなりユーザーを一切信用するなと言っている時点でデスクトップマスコットとしては駄目です。はい次。
ゼロトラストの構成要素について
ゼロトラストを実現するための構成要素ってなんでしょう。まあぶっちゃけ敵を知り己を知れば百戦殆うからずというやつで、ちゃんと端末の状態を常時監視し、外からヘンなものを拾ってこないようにしましょうというやつです。そんな身も蓋もない言い方で片付けられてしまうと世のIT屋さんが確実にキレるとは思いますけど。
そんな雑説明はさておき、構成要素を提供できるかもしれないな～というSSPの機能について紹介します。
1.脅威検出機能
SSPはゴーストのネットワーク更新の際に、更新対象をファイルとして保存する前のネットワークからデータが流れてくる段階で、マルウェア対策ソフトにデータを渡して確認してもらう仕組みを整えています。
先に説明した通りそもそも任意のDLLを読める時点で駄目だろうという話ではありますが、その懸念をだいぶ軽減してくれます。
…ぶっちゃけ誤検出だらけなのでウンザリするんですけど。
2.デバイス状態検知機能
SSPは相当偏執狂めいたレベルでOSの状態を確認し通知する機能が充実しています。省電力モードでディスプレイが消えたとか、バッテリーが足りないかもしれないとか、ロック画面のまま放置プレイされてるっぽいとか、WiFiに接続したっぽいとか、そういうのSAORIでやれよって思うレベルですが反省していません。
その中でもなんかこうゼロトラストっぽいのはなんかないかなーということで、USBメモリをPCに挿したら検知するのを紹介します。イベントサンプルは下記の通りです。
GET SHIORI/3.0
Charset: UTF-8
Sender: SSP
SenderType: internal
SecurityLevel: local
ID: OnDeviceArrival
BaseID: OnDeviceChange
Reference0: USBUSB 大容量記憶装置互換性のある USB 記憶装置/Device/USBPDO-636fc9e60-c465-11cf-8056-444553540000
Reference1: VolumeボリュームMicrosoft/Device/HarddiskVolume371a27cdd-812a-11d0-bec7-08002be2092f
Reference2: LogicalVolumeG:G:00000000-0000-0000-0000-000000000000
挿し込んだ瞬間、OnDeviceArrivalというイベント通知が来ます。Reference0以降は挿し込まれたデバイスの詳細情報がバイト値1区切りで格納されています。
SSP内部では、挿し込んだ瞬間から少し待って、内部で情報を溜め込んでからイベント通知するので、USBメモリの場合はだいたいが上のように3行セットで来る感じになると思います。
USBメモリ特有のものだと、USBPDO-ではじまるデバイスファイルが検出されているとか、直後にVolume、LogicalVolumeが来てドライブ名が割り当てられてるとか、そのへんを拾えば判定できると思います。今回はGドライブが割り当てられたようですね。
…まあ検知できるだけで、使えなくできるとかそんな高度な機能はないんですけど。そういうのはグループポリシーかなんかで設定できたはずなのでぐぐってね。
3.OS更新検知機能
そろそろ正気を疑うレベルになってきましたが、SSPではOSの更新状態の検知もできます。だいたいの人はWindows上で実行していると思うので、Windows Updateの更新状況がゴースト側で把握できるということです。
NOTIFY SHIORI/3.0
Charset: UTF-8
Sender: SSP
SenderType: internal
SecurityLevel: local
ID: OnOSUpdateInfo
Reference0: 2021,12,25,15,36,12
Reference1: 2021,12,25,13,44,42
Reference2: success000000002021,12,25,13,44,42Microsoft Defender Antivirus のセキュリティ インテリジェンス更新プログラム - KB2267602 (バージョン 1.355.820.0)
Reference3: fail802400342021,12,18,16,17,13Advanced Micro Devices, Inc. - Display - 30.0.13023.1012
Reference4: success000000002021,12,18,16,4,11Advanced Micro Devices, Inc. - Display - 30.0.13023.1012
Reference5: success000000002021,12,15,7,57,262021-12 x64 ベース システム用 Windows 11 の累積更新プログラム (KB5008215)
Reference6: success000000002021,12,15,7,52,42悪意のあるソフトウェアの削除ツール x64 - v5.96 (KB890830)
Reference7: success000000002021,12,15,7,46,112021-12 .NET 5.0.13 Security Update for x64 Client (KB5009194)
Reference8: success000000002021,12,15,7,44,472021-12 .NET Core 3.1.22 Security Update for x64 Client (KB5009193)
上記は12/25時点での私のPCで通知された情報です。
イベント名はOnOSUpdateInfoで、ゴースト起動直後にNOTIFY、その後OSの更新処理が入るとGETで来ます。イベント通知が来た時点でいったん情報を取っておいて、喋れる時に別途しゃべるという感じの処理になると思います。
いろいろ解析するのがめんどくさいという場合でも、最新チェック日時がReference0、最終更新処理日時がReference1に入っています。この日付がやたらと古いかどうかをチェックするだけでも、OSの更新をちゃんと行っているかが確認できると思います。
Reference2以降は詳細情報で、こちらはバイト値1区切りです。最初の要素がsuccessかどうかだけ確認して、それ以外があったら何か更新でトラブルが起きてるよと通知してもいいかもしれません。
…あ、このサンプルでもReference3にfailがありますね。AMDのディスプレイドライバの自動更新に失敗した、失敗理由はダウンロード失敗だそうです。でもReference4で同じものが成功判定なのは解せぬ…
とまあこんな感じで、割と失敗ログは頻繁に残るっぽい感じなので、これを検知してあまりうるさく言うのはアレかもしれません。
まとめ
本記事では、SSPが提供するゼロトラスト構成要素と言い張るマニアックな状態検出機能をまとめました。これらを活用すると、なんかこうめっちゃお高いアレとかソレとかのクライアントPC管理用ソフトと似たようなことが、ただのデスクトップマスコットソフトでできてしまいます。マジかよ！今すぐ全社に導入だ！
今後もDX化の流れ、働き方改革の流れは継続すると考えられ、このような管理機能は重宝するとは思いますが、正直デスクトップマスコットとしてはDX？デラックス？なにそれ食えるの？とか、働き方改革するなら年中デスクトップに立たなきゃならない我々のブラック環境を改善しろとか、そういう指摘のほうが先にくるんじゃないかと思います。だいたい会社でゴースト立たせんやろ。*1
2021年の歴史は、あと数ページ
今回で2021年のアドベントカレンダー記事は最終回になります。特に私は頻繁に駄文をばらまきまくってましたがよく耐えてくれました。はなまるをあげましょう。
みんなアドベントしたかい？
初出：2021/12/25に12/19用として後付しました
*1:私は立たせてますよ？
