本「
IT談話館」一般公開記事は、10年以上の実務経験を持つ上級Windowsエンジニアを想定しています。
本館は、Windowsカーネル深層を解析し、クラッシュ原因をはじめとするシステム内の「異様な動き」を検出・分析する
超高度な技術と実績を保有しています。
Windows OSとセキュリティー
本「IT談話館」の「一般公開記事」は、「Active Memory Dump とカーネルメモリダンプ」の解析結果を基に起草されています。「本館」主筆の「豊田孝」はDKOM(Direct Kernel Object Manipulation)ベースの解析手法の第一人者であり、Windowsカーネル空間の解析分野では世界の先頭を走っています。
現在、セキュリティー問題を無視することはできません。Microsoft社側の負担だけではなく、同社製品の利用者側の負担も増しています。困ったことではありますが、当面避けられません。セキュリティーの視点から「Windows10ソフトウェアセンサー」を見た場合、本「IT談話館」の確認範囲では、「カーネル層保護ロジック」に加え、次のような保護メカニズム階層が考案・実装されています。下記リンクはすべて本館記事を指しています。
- Silo/Server Silo
- Job
- Session
- Protected Process
- Mandatory Integrity Control(MIC)
- Windows API(+CPU)
- CPU
現在のWindowsセキュリティーメカニズムは次のような概念間の連携で構成されています。
データ収集<->分析＋Alert<->特徴＋モデル<->予測
このメカニズムは、データを収集し、それを分析する過程でAlertを出力しながら、最終的に「将来の脅威を予測」する、という流れを示しています。また、流れを構成する各概念は「<->」記号で結ばれ、それぞれの成果物の品質が相互フィードバックにより常に変更されることを示しています。Alertや予測などは外れることがあるため、常に、批判的に解釈する技術力が必要になります。False Alertに引きずられた場合、貴重な時間が浪費され、直面している問題の本質に迫ることはできません。
以上の流れは、次のように書き直すことができます。
Client<->Cloud<->File Upload<->Expert Analyst
データ収集と分析作業はClient ML側で行われ、脅威の性質に応じてCloud側（Cloud ML+DL+AI)がトリガーされ、詳細な分析が行われます。米Microsoft社の資料は、Client上では500を超える攻撃パターンをモニターしており、攻撃の97%はClient上で阻止できる、と主張しています。ML、DL、AIといった用語を使用すれば、次のような流れが出来上がります。
Sensors<->ML<->DL<->Neural Network<->Human
データ収集にはSensorが必要になります。この場合のSensorとは、Windows 10に組み込まれている機能を指しますが、Windows 10/11は短周期で内部更新を繰り返している関係上、その機能実態を把握するには高度な技術力が必要とされます。本「IT談話館」は、独自解析コードでWindows 10/11センサー内部に直接アクセスし、そのユーザー空間とカーネル空間の詳細な解析を通して、最新のセンサー機能を把握する高度な技術力を保有しています。
Windows 10/11環境で採取した「Active Memory Dump」を本「IT談話館」独自の解析コードで解析すると、次のようなWindows 10/11保護プロセスに関する内部情報を取得することができます。
この表は、ダンプ採取時点で動作中のプロセスの性質を示しています。性質には保護プロセス特性に加え、次のような情報が含まれています。
- 起動番号
- 所属セッション番号
- Windowsの動作に不可欠な重要プロセス
- セッションを超えて動作するプロセス
- サブシステムプロセス
保護プロセスメカニズムは分かりやすいものですが、この表内の結果には、より抽象度の高いレベルで基本的な不可解さが残されています。表内の「System」欄を見ると、すべてのプロセスは「0」という値を持ち、システムプロセスが存在しない、と報告されています。カーネル構造体には次のようなビットが用意されています。
0: kd> dt nt!_eprocess system*
+0x6fc SystemProcess : Pos 12, 1 Bit
今回の調査では、このビットが立っていません。しかし、次のビットは立っています。
0: kd> dt nt!_eprocess subsystem*
+0x6fc SubsystemProcess : Pos 6, 1 Bit
「SystemProcess」は存在しないが、「SubsystemProcess」は存在する。この論理はどう考えても成立しません。ちなみに、Windows 10の前身であるWindows 8.1では「SubsystemProcess」ビット自体が用意されていません。この論理的な矛盾は今後どのように解消されるのか注視したいと思います。
なお、表内の「CrossSession」欄は、オブジェクト名前空間内にEventオブジェクト、Keyオブジェクト、あるいはFileオブジェクトなどを作成し、セッション分離を超える機能を実装しているプロセスを示しています。オブジェクト名前空間へのアクセスは通常はシステム内部のハンドルテーブルを経由することになりますが、この面での改善試みは複数のWindowsバージョンを跨ぎながら、長期的かつ継続的に行われています。ハンドルテーブルとKeyオブジェクトについては、本館の次のような記事がそれぞれ参考になるでしょう。