Case study: review a Windows service boundary

NightlyReport creates a daily inventory summary. You are reviewing a proposed permission cleanup before the service owner accepts it. All names and records in this exercise are fictional. Read the supplied packet and produce a decision; no computer changes are needed.

A permission boundary is a point where an action on a particular resource requires authority. Here, managing the service, reading its configuration file, and writing its output cross different boundaries. The fact that all three relate to NightlyReport does not make their permissions interchangeable.

P1: the owner’s approved duties

The application owner approves four duties. Support may view service status. Operations may start and stop the service during an agreed maintenance window. Release administrators maintain service configuration and the configuration file. The dedicated ReportWriter runtime identity reads input records and configuration, then creates reports in the output area. It does not need to alter its configuration.

These are this application’s requirements, not universal Windows defaults. The owner confirms that NightlyReport does not write settings back to its configuration file and does not require an administrator runtime identity. Changing those facts would require reviewing the proposal again.

E1-E4: the supplied permission snapshot

The review team supplies effective decisions for the named ordinary identities. The records already account for applicable group membership and file inheritance. Assume fresh access checks, no previously opened handles, no impersonation, and no privileged override or additional policy that changes these decisions. Do not infer other objects’ permissions from this small packet.

Release administrators’ approved maintenance access is separately verified and must remain available. The packet supplies no action logs and no full review of other services.

Windows names the status-query right SERVICE_QUERY_STATUS and the service-configuration right SERVICE_CHANGE_CONFIG. File content access uses the file’s security controls. The process token supplies runtime identity and other security context; an operator’s management grant does not transfer that operator’s identity to the running service.

Make the first decision

PredictWhich two records show unnecessary authority, and which fact would you avoid claiming?

E1 exceeds Support’s status-only duty in P1. E3 permits the runtime identity to change a configuration file that P1 says it only reads. These are two supported policy deviations. Neither record proves that somebody exercised the permission, modified a report, or compromised the host. The finding should state possible unauthorized configuration changes as an impact, with actual use unresolved.

Notice why E4 is different. Creating output is useful work explicitly required by P1. Removing all write access from ReportWriter would mix an unnecessary configuration-file permission with a necessary output permission. A smaller proposal is easier to justify and verify.

Propose a change with an owner

The Windows platform owner should review removing Support’s service-configuration grant while preserving status queries. The application owner and release administrator should review removing ReportWriter’s configuration-file write access while preserving its read and output workflow. Separate the two changes in the review record even if one maintenance window implements both.

Before approval, ask which exact policy entries provide the effective grants, whether a shared group or inherited file rule affects other applications, and whether the recorded identity matches the deployed service. Effective-access evidence identifies the deviation; it does not alone tell you the smallest configuration edit. An unreviewed broad denial can interfere with required maintenance.

Define acceptance before checking it

Acceptance evidence connects observed results to agreed requirements. Request a new permission snapshot plus ordinary workflow results under the stated identities. Support’s status query should succeed and its service-configuration request should be denied. ReportWriter should read its configuration, fail an ordinary request to write that file, and still produce the expected report. Operations and release administrators should retain their approved tasks.

This describes expected results for the owner’s controlled validation, not instructions for interacting with a live service. Record identity, object, requested action, conditions, time, and result. A screenshot saying “running” does not cover those requirements. Nor does a successful administrator-run report establish what ReportWriter can do.

A model review and its limits

“P1 requires status-only Support access and read-only runtime access to configuration. E1 and E3 show excess grants, creating a possibility of unapproved configuration changes. Platform and application owners should approve narrow corrections and supply both denial and retained-workflow evidence. The findings remain open until that evidence covers both boundaries. No unauthorized action is established by this packet.”

If a controlled rollout fails and the previous snapshot is restored, document the recovered service separately from the unresolved permissions. Restoring availability does not meet the original acceptance criteria. Preserve the observations, revise the proposal, and assign the next review. This conclusion remains limited to NightlyReport and the supplied identities; it is not assurance about every Windows service.