تحصين الأجهزة الطرفية، تم التحقق منه.

نقطة البداية.

عملت على قيود التحكم في التطبيقات لأجهزة Windows الطرفية، بما في ذلك واجهات سطر الأوامر وPowerShell. لم يكن التحدي العملي مجرد إظهار السياسة في Intune، بل التحقق من مسارات التنفيذ المسموح بها أو المحظورة فعليًا، مع الحفاظ على أعمال الإدارة المشروعة.

ما قمت به.

1. اختبرت تنفيذ الأوامر في سياقات مستخدمين مختلفة، وتحققت من السلوك الفعلي بدلًا من الاعتماد على حالة التعيين وحدها.
2. استخدمت PowerShell لمراجعة أحداث AppLocker الخاصة بملفات EXE وDLL، والبحث عن نشاط يشمل cmd.exe وpowershell.exe وpwsh.exe.
3. فصلت بين سلوك السياسة وتوفّر التطبيق. فغياب الملف التنفيذي لـ PowerShell 7، على سبيل المثال، ليس دليلًا على أن AppLocker قد حظره.

القرارات والمفاضلات.

قراءة أحداث واجهات الأوامر في AppLocker.

مثال يقتصر على القراءة، أُعيد بناؤه لدراسة الحالة هذه. يفحص سجل «EXE and DLL» دون تغيير السياسة.

$filter = @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8002,8003,8004
    StartTime = (Get-Date).AddHours(-24)
}
try {
    $events = @(Get-WinEvent -FilterHashtable $filter -ErrorAction Stop)
} catch {
    if ($_.FullyQualifiedErrorId -like 'NoMatchingEventsFound*') {
        $events = @()
    } else { throw }
}

$events |
    Where-Object {
        $_.Message -match '(?i)cmd\.exe|powershell\.exe|pwsh\.exe'
    } |
    Select-Object TimeCreated,Id,Message

اقرأ النص البرمجي قبل تشغيله. على Windows: powershell -ExecutionPolicy Bypass -File .\read-applocker-events.ps1 (ينطبق ذلك على تلك العملية فقط).

ما تحققت منه.

جمعت الفحوصات بين التنفيذ الفعلي للأوامر وسجلات الأحداث المحلية. ومكّنني ذلك من التمييز بين إجراء مسموح به، وحدث في وضع التدقيق يفيد بأن الإجراء كان سيُحظر، وحظر تم فرضه. كما تحققت من وجود الملف التنفيذي قيد الاختبار في المسار المتوقع.