Merge remote-tracking branch 'origin/dev' into feat/377-smb-closure

This commit is contained in:
Shirofune-Security committed 2026-09-23 08:58:47 +09:00
commit 3a5481ea9b
8 files changed
+44 -4

No files matched your search

+4
View File
@@ -1,5 +1,9 @@
# Native AppLocker readiness
### Issue 381 coverage
AppLocker readiness observes the effective policy, AppIDSvc, and native channels before any optional import. Only an operator-supplied audit-only policy may be imported; existing enforcement policies are preserved, and policy state is kept separate from event generation and Sigma eligibility.
`applocker-readiness` reports local and GP effective policy XML, each of the five rule collections, enforcement modes, rule counts, Application Identity (`AppIDSvc`) state/start mode and relevant AppLocker channel observations. A host with enabled channels but no rules reports `MissingGpPolicy`. Stopped/disabled services, missing channels, unavailable cmdlets and read errors remain explicit. `NotConfigured` with rules is treated as potential enforcement, never as disabled.
```powershell
+4
View File
@@ -1,5 +1,9 @@
# Event-log sizes and retention modes
### Issue 379 coverage
Event-log sizing and retention changes are explicit per-channel controls with typed before/after evidence, mode preservation, and guarded recovery. Buffer size does not establish a retention duration, archive capacity, forwarding health, or absence of event loss.
`audit-filesize` and ordinary `configure` now use the same
`config/eventlog_profiles.json` definitions. `-Profile` continues to select
**advanced audit policy only**. Use the separate `-LogProfile` option with
+4
View File
@@ -1,5 +1,9 @@
# Native public OneSettings configuration acceptance
### Issue 378 coverage
OneSettings auditing and Security warning thresholds are configured only through explicit, version-aware workflows. Unsupported builds and absent controls are refused or reported, sibling values are preserved, and successful policy writes do not claim warning-event generation or telemetry collection.
The disposable acceptance fixture invokes the actual `WELA.ps1 audit-notifications` command under Windows PowerShell 5.1 and PowerShell 7. It verifies local configuration and the explicit Privacy channel dependency. It does not generate a OneSettings event or claim effective producer behavior, policy persistence, forwarding or Sigma readiness. Sysmon is excluded.
```powershell
+4
View File
@@ -1,5 +1,9 @@
# Native Security 4703 audit attribution
### Issue 380 coverage
Token-right attribution pins the canonical Security 4703 GUID and retains the competing historical mappings as conditional candidates. Native event XML, audit masks, token context, and cleanup evidence are required before attribution; a catalog match alone does not claim universal Windows coverage.
The disposable `Native Security 4703 audit attribution` workflow tests the two historical audit-subcategory candidates for event 4703 on standalone Windows Server 2022/2025 under Windows PowerShell 5.1 and PowerShell 7. It does not add a production probe, change WELA policy recommendations, remove historical mapping candidates or grant Sigma readiness.
Microsoft's [Token Right Adjusted guidance](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/audit-token-right-adjusted) and [advanced audit-policy reference](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/advanced-audit-policy-configuration) associate 4703 with token adjustment. The older [4703 event reference](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4703) names Authorization Policy Change. [WELA's mapping review](audit-catalog-mappings.md) retains both historical candidates as conditional. Native evidence below is specific to the recorded Windows build/UBR, provider manifest, engine and fixed operation.