Systems and Application Security

7.1 Identify and analyze malicious code and activity

Core idea: malicious activity analysis.

Scenario: Endpoint alerts show script execution, credential dumping behavior, and outbound beaconing from one host.

Practitioner response: Isolate the host, preserve evidence, analyze behavior, scope lateral movement, and apply containment and hardening.

Concepts to Understand

• malware types: malware types is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• rootkits, spyware, scareware, ransomware, trojans, viruses, worms, trapdoors, backdoors, fileless malware, OS and mobile code vulnerabilities: rootkits, spyware, scareware, ransomware, trojans, viruses, worms, trapdoors, backdoors, fileless malware, OS and mobile code vulnerabilities is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• malware countermeasures: malware countermeasures is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• insider threat: insider threat is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• data theft: data theft is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• DDoS: DDoS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• botnets: botnets is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• zero-day exploits: zero-day exploits is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• web attacks: web attacks is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• advanced persistent threat: advanced persistent threat is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• social engineering: social engineering is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• behavior analytics, machine learning, AI, and data analytics: behavior analytics, machine learning, AI, and data analytics is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

7.2 Implement and operate endpoint device security

Core idea: endpoint security.

Scenario: A laptop with sensitive data is lost and the user reports it was powered off.

Practitioner response: Verify full disk encryption and recovery-key controls, revoke sessions, monitor access, and follow incident reporting procedures.

Concepts to Understand

• HIPS: HIPS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• HIDS: HIDS is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• host firewalls: host firewalls is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• application allowlisting: application allowlisting is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• full disk encryption: full disk encryption is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• TPM: TPM is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• secure browsing and certificates: secure browsing and certificates is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• EDR: EDR is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

7.3 Administer and manage mobile devices

Core idea: mobile device management.

Scenario: Executives want personal phones to access corporate email and documents.

Practitioner response: Use MDM or MAM policies, encryption, containerization, conditional access, remote wipe rules, and privacy-aware BYOD agreements.

Concepts to Understand

• COPE: COPE is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• BYOD: BYOD is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• MDM: MDM is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• containerization: containerization is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• encryption: encryption is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• mobile application management: mobile application management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

7.4 Understand and configure cloud security

Core idea: cloud security administration.

Scenario: A SaaS product is approved because it encrypts data, but contract terms omit deletion, audit, data ownership, and breach-notice commitments.

Practitioner response: Evaluate shared responsibility, data handling, SLA, audit, portability, deletion, and legal terms before approval.

Concepts to Understand

• public, private, hybrid, and community deployment models: public, private, hybrid, and community deployment models is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• IaaS, PaaS, and SaaS service models: IaaS, PaaS, and SaaS service models is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• virtualization and VPC: virtualization and VPC is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• privacy, surveillance, data ownership, jurisdiction, eDiscovery, and shadow IT: privacy, surveillance, data ownership, jurisdiction, eDiscovery, and shadow IT is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• storage, processing, transmission, archiving, backup, recovery, and resilience: storage, processing, transmission, archiving, backup, recovery, and resilience is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• third-party outsourcing, SLA, portability, privacy, destruction, and auditing: third-party outsourcing, SLA, portability, privacy, destruction, and auditing is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• shared responsibility model: Cloud does not remove customer responsibility for identity, data, configuration, legal requirements, and monitoring.

7.5 Operate and maintain secure virtual environments

Core idea: virtual environment security.

Scenario: Container workloads share a host with broad runtime privileges and unscanned images from public registries.

Practitioner response: Harden runtime privileges, validate images, segment workloads, monitor behavior, and maintain resilient container/host operations.

Concepts to Understand

• Type 1 and Type 2 hypervisors: Type 1 and Type 2 hypervisors is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• virtual appliances: virtual appliances is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• containers: containers is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• continuity and resilience: continuity and resilience is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• storage management: storage management is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• brute-force attacks: brute-force attacks is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• virtual machine escape: virtual machine escape is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.
• threat hunting: threat hunting is testable because a practitioner must know what control it supports, who owns it, what evidence proves it worked, and what failure looks like.

HIDS vs HIPS

This comparison is covered through the domain objectives above and the SSCP review sheet.

EDR vs antivirus

This comparison is covered through the domain objectives above and the SSCP review sheet.

BYOD vs COPE

This comparison is covered through the domain objectives above and the SSCP review sheet.

IaaS vs PaaS vs SaaS

This comparison is covered through the domain objectives above and the SSCP review sheet.

Type 1 vs Type 2 hypervisor

This comparison is covered through the domain objectives above and the SSCP review sheet.

container vs virtual machine

This comparison is covered through the domain objectives above and the SSCP review sheet.