I85PREP
⌘ K
NISP Level 2 study materials
NISP Level 2 study resources

NISP Level 2: Host and System Security

NISP Level 2 · Work through your exam, one topic at a time.

All guide sections

Host and System Security

Host and System Security covers the operating system and its accounts, services, files and baselines. NISP Level 2 asks you to harden a server, detect privilege escalation, and judge whether a proposed configuration change weakens the host.

Hardening baseline

  • Minimise attack surface: remove or disable unused services, close unused ports, uninstall sample applications, delete or rename default accounts.
  • Patch management: firmware, OS, middleware and third-party applications, with a defined test-then-deploy cycle and an emergency path for critical CVEs.
  • Account hygiene: unique accounts (no shared logins), least privilege, password complexity and lockout thresholds, MFA for administrative access, prompt revocation at staff departure.
  • Mandatory access control: SELinux or AppArmor constrain a compromised process even after it gains root-like rights; disabling it "to make the application work" removes a real layer.
  • Logging and integrity: enable auditd or the Windows security log, forward logs off-host, and use file-integrity monitoring on system binaries and configuration.
  • Trust anchors: TPM-backed measured boot and Secure Boot resist bootkits and offline tampering.

Windows and virtualisation

Active Directory centralises authentication and authorisation; Group Policy is the enforcement mechanism for baselines across hosts. Domain controllers are tier-0 assets - compromise of one effectively compromises the estate. On virtual platforms, keep hypervisors patched, restrict management-plane access, and remember snapshots are not backups.

Worked example

A Linux web server allows PermitRootLogin yes and password authentication, and a developer has run chmod 777 /var/www/uploads. Reasoning: root SSH login exposes the highest-value account to brute force; password auth enables credential guessing; world-writable upload directories let an attacker drop and execute a payload. The fix is key-only authentication, PermitRootLogin no, per-user sudo rules, and ownership www-data with mode 755/640 - plus a host firewall that exposes only 443.

Traps

  • Treating antivirus as a complete host control.
  • Applying chmod 777 to "fix permissions"; it removes the access-control boundary.
  • Disabling SELinux or the host firewall instead of writing a correct policy.
  • Patching the OS but not the application stack and container images.
  • Assuming sudo always equals full root; sudoers rules can and should be scoped.