Splitting one default profile across three business groups
An 800-endpoint estate is managed by EMS 7.4: Finance 200 desktops, Engineering 250 desktops, Field Sales 350 laptops. Today a single Default profile applies to everyone. Since go-live, Engineering has raised repeated tickets because a build tool is quarantined on write and a USB licence dongle is blocked by the removable-media policy. Finance wants evidence that users cannot disable real-time scanning or the web filter. Field Sales report CPU saturation during the 09:00 scheduled full scan and frequent signature update failures when on hotel Wi-Fi. The security team also wants to know automatically when an endpoint stops running antivirus, rather than discovering it at audit time. Locked settings, profile assignment, and antivirus exclusions are all available in your EMS build, and the Windows endpoints are all in AD groups that already match the three business units.
1. Design the profile structure and assignment model, and state which settings you would lock in each profile and why.
Read the worked answer
Split Default into three profiles mapped one-to-one to the existing AD groups: Fin-Strict, Eng-Balanced, Sales-Light. One profile for 800 endpoints guarantees that the most permissive requirement wins for everyone.
- Fin-Strict: real-time scanning blocking on write, scheduled full scan nightly when idle, web filter with blocked categories, removable media blocked or read-only. Lock real-time scanning, the web filter, the EMS server address and client uninstall protection.
- Eng-Balanced: the same antivirus baseline plus narrowly scoped exclusions and a dongle exception (below). Lock the baseline features so exceptions stay inside the profile, not in user hands.
- Sales-Light: full protection with a scan schedule outside working hours and update behaviour tuned for constrained links. Lock the same security core; leave cosmetic and notification settings unlocked.
Locking matters for two reasons. First, a locked setting is greyed out in the FortiClient console, which answers Finance's request with configuration evidence rather than a verbal assurance. Second, pairing the lock with a reporting control (below) proves the state continuously, not just at deployment.
Assignment itself is the risk: verify after rollout that no endpoint sits ungrouped in a default bucket, and re-check whenever AD groups change, because a user moved between departments will silently inherit a different security posture.
2. How would you resolve the Engineering exceptions without weakening protection for the whole group?
Read the worked answer
Scope the exception to the mechanism that causes the conflict, and compensate for the residual risk.
Build tool (antivirus conflict). The tool writes to a working folder that on-access scanning inspects. Add an exclusion for that specific path, for that specific detection behaviour only, and keep scheduled and on-access scanning active everywhere else. Do not switch the group to monitor-only, and do not disable the antivirus feature - that is scoping by convenience.
Compensating controls: confirm the excluded folder is writable only by the build service account through NTFS permissions; restrict the toolset to signed binaries using application control or application firewall rules; keep the exclusion in change control with an owner and a quarterly review; and monitor for detections in sibling paths so a new dropper location is noticed.
USB licence dongle. Prefer a device-specific allowance (allow that device, keep all other removable media blocked or read-only) over opening removable media for the whole Engineering group. If your build only supports group-level rules, use read-only as the fallback, which permits the licence check in most cases while blocking writes to removable storage.
Documentation. Record the exception, the business justification and the review date in the profile notes. Exceptions that are not written down become permanent, and the next auditor will ask why 250 endpoints can write to an unscanned folder. If a future FortiClient release fixes the conflict, remove the exclusion rather than keeping it out of habit.
3. Address the Field Sales performance complaints and design the automatic control that flags endpoints without antivirus protection.
Read the worked answer
Performance. A 09:00 full scan is a scheduling error: it runs when the laptop is busy, often on battery and on a shared hotel network. Move the full scan to a weekly idle-triggered schedule outside business hours, keep real-time scanning blocking on write, and check that the scan is not configured to traverse removable media or network drives. Signature update failures on slow links are usually timeouts or blocked egress rather than a product fault: confirm the update path (FortiGuard directly, or updates distributed through EMS), avoid forcing updates during working hours, and allow retry on the next connection. Validate the change on a handful of sales laptops before pushing it to 350.
Flagging missing protection. Configure a zero trust tag rule that evaluates endpoint state - antivirus not running, or signature older than your stated threshold - and tags the endpoint accordingly. The tag appears in the endpoint inventory and can drive alerts and reports for the security team, and, if a FortiGate is integrated, it can be referenced in policy. This is stronger than a locked setting: the lock prevents a deliberate change, while the tag catches the machine that lost protection through a failed service, a botched uninstall or a malware attempt. Test the rule by stopping the antivirus service on a lab endpoint and confirming the tag appears within your expected detection window.