Pass Apprentice Exam Guide

Command-and-control is the lifecycle stage where compromised systems communicate with attacker-controlled infrastructure. This communication may deliver commands, retrieve additional malware, update configuration, report system status, or prepare for lateral movement and data theft. The phrase “passing instructions back and forth” is the defining signal for C2. Exploitation is the moment an attacker uses a weakness to compromise a system. Reconnaissance is pre-attack information gathering. Weaponization and Delivery involve preparing and transmitting the malicious payload to the target. C2 traffic is a high-value detection opportunity because it often requires outbound communication to domains, IP addresses, or protocols that differ from normal business activity. Defenders look for beaconing patterns, suspicious DNS queries, unusual destinations, and connections to known malicious infrastructure. Disrupting C2 can limit an attacker’s ability to operate even after initial compromise. Reference/topics: Cybersecurity 1.2, cyber attack lifecycle; Cybersecurity 1.3, command and control.

A false positive occurs when a security tool generates an alert for activity that is actually benign. Overly generalized traffic match criteria can cause a high number of false positives because the detection rule captures too much normal behavior. For example, a rule that flags all encrypted outbound traffic as suspicious would produce excessive alerts because encrypted web traffic is common and expected. Effective detection criteria must be specific enough to identify meaningful risk while broad enough to catch real threats. A well-defined post-breach recovery plan improves response readiness but does not directly create false positives. Strict user privileges may reduce risk and are not a normal cause of noisy alerts. A device failing to receive an IP address is an operational connectivity issue, not a typical false-positive driver. SOC teams manage false positives through tuning, baselining, enrichment, severity adjustment, and better rule logic. Reference/topics: Security Operations 6.4, false positive and false negative alerts; Security Operations 6.2, SOC performance optimization.

Software as a Service provides a complete application hosted and operated by a third-party provider and made available to customers over a network, usually through a browser or client application. The customer consumes the software without managing the underlying servers, operating system, runtime, or application infrastructure. Examples include business productivity suites, CRM platforms, collaboration tools, and many security consoles. PaaS provides a managed development or application platform, not a finished application. IaaS provides infrastructure resources such as compute and storage, leaving the customer responsible for more of the workload stack. Desktop as a Service provides hosted virtual desktops, but it is not the general model described by a provider-hosted application ready for customer use. SaaS changes the shared responsibility boundary because the provider handles more of the application delivery stack, while the customer still manages data, users, access policies, and configuration choices. Reference/topics: Cloud Security 5.2, SaaS, PaaS, IaaS, NaaS; Cloud Security 5.3, shared responsibility.

Two of the four Cs of cloud-native security are Code and Clusters. The four-Cs model is commonly used to organize cloud-native security responsibilities across layers: cloud, cluster, container, and code. Code is the application logic and dependencies that developers produce, and it must be secured through review, scanning, dependency management, and secrets control. Cluster refers to the orchestration environment that runs workloads, commonly Kubernetes, and must be secured through access control, configuration hardening, network policy, and runtime monitoring. Configurations are extremely important in cloud security, but “Configurations” is not one of the four Cs in this model. Connections are also important, especially for service communication and network policy, but they are not one of the named four Cs. The model is useful because cloud-native risk is layered: weak code, vulnerable containers, misconfigured clusters, or insecure cloud infrastructure can each become an attack path. Reference/topics: Cloud Security 5.5, CNSP; Cloud Security 5.4, container, microservice, and cloud terms.