CCES (Harmony Endpoint Specialist) study materials
CCES (Harmony Endpoint Specialist) study resources

CCES (Harmony Endpoint Specialist) cheat sheet

CCES (Harmony Endpoint Specialist) · Keep the key ideas within reach.

Quick reference

Deployment and Architecture

  • Management server components: the Endpoint Security Management Server hosts policy, database, and the web management interface; the Endpoint Security Management (secondary/failover) server provides redundancy; SmartConsole or the web console is the operator interface.

  • Endpoint client components: the endpoint agent (Endpoint Security Client) includes the anti-malware engine, the Threat Prevention/behavioral engine, the firewall/network protection driver, and the compliance/forensics agent; all are installed and updated as one package.

  • Deployment methods: manual installation, remote push from the management server, and software deployment packages distributed through the management console; large rollouts use deployment rules that target groups rather than individual machines.

  • The management server needs outbound connectivity to endpoints on the agent communication port (default 443/CPDA) and endpoints must reach the server; NAT and proxy traversal must be planned before rollout.

  • High availability options: a standby management server with database replication, plus multi-server (distributed) deployments where a management server manages endpoints in remote sites to reduce WAN traffic.

  • Site topology: endpoints are organized in organizational units/groups that mirror AD structure; deployment and policy assignment are group-based, so AD hygiene directly affects policy accuracy.

  • Licensing is per-endpoint and tied to the management server's license; unlicensed endpoints can still be managed but protection blades may be disabled until a license is applied.

  • Endpoint client versions should be kept at or near the management server version; version skew beyond the supported matrix blocks new blade features on older agents.

  • Upgrade path: upgrade the management server first, then push client upgrades in waves; client upgrades are reversible only by reinstall, so pilot groups are used before broad rollout.

Quick reference

Endpoint Security Policy Management

  • Policy structure: a policy is a set of rules evaluated top-down per blade; each rule has a source (endpoint group/user), destination, service, action, and tracking; the first matching rule wins.

  • Blade enablement: each protection blade (Anti-Malware, Threat Prevention/Behavioral, Firewall, Application Control, Data Protection, Compliance, Forensics) is enabled per policy and per rule, so a rule can apply one blade without others.

  • Rule actions: Accept/Allow, Block/Drop, Ask user, and blade-specific actions such as Quarantine or Remediate; the action available depends on the blade in the rule.

  • Exceptions: exceptions can be defined at the policy level (global exceptions), the rule level, or per-endpoint; precedence is endpoint-level over rule-level over global, so the most specific exception wins.

  • Policy installation: policy changes take effect only after Install Policy; the console shows installation status per endpoint, and failed installs leave the endpoint on its previous policy.

  • User/group-based rules rely on identity from AD or the endpoint's logged-in user; machines without identity resolution fall back to machine-based rules.

  • Compliance rules define required settings (e.g., disk encryption, AV signature age) and produce a compliance status; non-compliant endpoints can be blocked from network access by a compliance action.

  • Policy versioning and audit: every install creates an auditable policy version; reverting requires reinstalling a prior version, and the audit log records who changed and installed what.

  • Default policy behavior: traffic and files not matched by any explicit rule fall to the blade default (typically block for malware, allow for firewall depending on configuration), so defaults must be reviewed before go-live.

Quick reference

Threat Prevention and Anti-Malware Configuration

  • Anti-Malware scanning modes: on-access (real-time) scanning intercepts file open/execute/write; on-demand scanning runs scheduled or manual full scans; both use the same signature and heuristic engines.

  • Signature updates: the management server distributes signature updates to endpoints; update interval and fallback to vendor update servers are configurable, and signature age is a compliance metric.

  • Heuristic/behavioral detection: the Threat Prevention engine watches process behavior (e.g., credential dumping, ransomware-like mass encryption, script-based attacks) and can block or terminate the process independent of signatures.

  • Quarantine: detected files can be quarantined (moved to a protected store) and optionally restored; quarantine actions are logged and reversible by an administrator.

  • Exclusions: path, file-hash, and process exclusions reduce false positives but create blind spots; hash-based exclusions are safer than path-based because they cannot be abused by a renamed file.

  • Forensic and remediation actions per threat: the blade can block, quarantine, terminate process, or delete; choosing delete removes evidence, so quarantine is preferred when forensics is required.

  • Ransomware protections include behavioral detection of mass file modification and protected folders that only trusted processes may write to.

  • Scan performance tuning: exclude known-good high-I/O directories and trusted application caches from on-access scanning to reduce endpoint CPU impact; measure before and after.

  • Threat emulation/sandboxing: suspicious files can be detonated in a sandbox; verdicts feed back to endpoints as new signatures, so sandbox latency must be accounted for in detection SLAs.

Quick reference

Forensics, Incident Response, and Remediation

  • Forensic evidence sources: the endpoint agent records process creation, file writes, network connections, registry changes, and user activity; the management server aggregates these into the threat and audit logs.

  • Incident workflow: detect (alert) → triage (confirm malicious) → contain (isolate endpoint from network) → eradicate (remove artifact) → recover (restore) → lessons learned; each step should be logged in the incident record.

  • Endpoint isolation: the console can cut an endpoint off from the network while keeping the management channel open; this is the primary containment action for a suspected compromised host.

  • Forensic capture: a memory or disk image can be collected from the endpoint through the console; capture before remediation because cleanup destroys volatile evidence.

  • Threat hunting queries use the endpoint telemetry store to search for indicators (hash, process name, command line, network destination) across the estate.

  • Remediation actions: quarantine/delete the file, kill the process, revert registry/file changes, and reinstall the agent if it is tampered with; verify remediation by rescanning.

  • Chain of custody: record who collected evidence, timestamps, hashes of collected images, and storage location; unhashed or undocumented evidence is not defensible.

  • Root cause analysis: correlate the initial infection vector (phishing, exploit, USB) with the endpoint telemetry timeline; the vector determines whether a policy change is needed.

  • Post-incident: update exclusions, signatures, and policy rules; add the IOC to threat hunting; document the timeline in the incident report.

Quick reference

Monitoring, Reporting, and Troubleshooting

  • Log types: threat logs (detections and actions), audit logs (admin and policy changes), and system/health logs; each has its own retention and query interface.

  • Dashboards show estate-wide status: endpoints online/offline, signature age distribution, threats by severity, and compliance posture; a spike in offline endpoints often precedes a coverage gap.

  • Reports are scheduled or ad hoc; common reports include threat summary, top infected endpoints, policy compliance, and license usage.

  • Troubleshooting order: check endpoint online status → check last policy install result → check agent version and signature age → check local agent logs → check management server logs.

  • Common failure: endpoint offline because the agent cannot reach the server (firewall, proxy, certificate); verify connectivity on the agent communication port and check the agent's server address setting.

  • Common failure: policy not applied because the endpoint is in a group not covered by the rule or the rule is shadowed by an earlier rule; use the policy hit-count and rule order to diagnose.

  • Common failure: false positive after a signature update; confirm by hash, add a scoped exclusion, and report the false positive to the vendor.

  • Agent health: the console shows agent service status and last communication time; a tampered or stopped agent service is a security event, not just an operational one.

  • Escalation evidence: collect the endpoint's agent logs, the relevant threat/audit log entries, timestamps, and the policy version before opening a vendor case.