GIAC GDSA — Data-Centric Security & Governance

Reverse Proxy Security Benefits:

• Backend servers not directly exposed to internet — their IPs are hidden behind the reverse proxy's IP
• SSL/TLS termination: crypto offloaded to proxy, backend can use HTTP internally (or separate TLS segment)
• Single point for TLS certificate management, rate limiting, DDoS mitigation, caching
• Access logging for all incoming requests — forensic record
• Products: nginx, HAProxy, Traefik, AWS ALB, Azure Application Gateway, F5 BIG-IP

WAF vs Traditional Firewall:

• Traditional firewall: operates at Layers 3-4. Allows or blocks based on IP, port, protocol. Cannot inspect HTTP request content.
• WAF: operates at Layer 7 (HTTP/HTTPS). Inspects request headers, parameters, cookies, body. Understands web application semantics. Detects SQL injection, XSS, CSRF, command injection, path traversal.

WAF Deployment Modes:

• Inline (reverse proxy mode): All traffic passes through WAF. Full inspection and blocking capability. Adds latency. Fail-open (bypass) or fail-closed (block all) configuration.
• Out-of-band (passive): WAF receives a copy of traffic (SPAN port). Monitoring only — cannot block. Useful for initial baseline before enforcement.
• Cloud-based: Cloudflare, AWS WAF, Akamai. Traffic routed through provider's WAF infrastructure. No on-premises hardware.

WAF Rule Types:

• Signature-based: Matches known attack patterns (SQLi, XSS payloads). OWASP Core Rule Set (CRS) provides signature library for ModSecurity and compatible WAFs.
• Positive security model (whitelist): Only allow valid inputs matching defined patterns. Reject everything else. Lower FP rate but high maintenance — must define all valid inputs.
• Anomaly scoring: Multiple rule matches accumulate a score. Block when threshold exceeded. Reduces false positives vs blocking on individual rule match.

WAF Bypass Techniques (Know for Exam):

• HTTP parameter pollution: duplicate parameter names confuse WAF vs application parsing
• Encoding variations: URL encoding, double encoding, hex encoding of attack characters
• Chunked transfer encoding: HTTP chunked encoding fragments payload across chunks
• Case variation: SQL keywords: SeLeCt instead of SELECT
• Defenders must understand bypass techniques to tune WAF rules to cover them

False Positive Management: Learning mode (observe baseline for 2-4 weeks) → tuning (create exceptions for legitimate traffic triggering rules) → enforcement (switch to blocking). Business justification workflows for security exceptions.

Database Firewall Architecture: Sits inline between application servers and database servers. Inspects SQL traffic at the protocol level — parses actual SQL statements, not just HTTP.

What Database Firewalls Block:

• DROP TABLE, TRUNCATE — schema destruction commands
• EXEC xp_cmdshell — SQL Server OS command execution
• UNION SELECT-based SQL injection patterns
• Unauthorized stored procedure calls
• Queries not matching the approved whitelist of query patterns

Why DB Firewall + WAF Are Complementary:

• WAF protects the HTTP tier — inspects incoming HTTP requests for SQLi patterns
• DB Firewall protects the database tier — inspects actual SQL at the database protocol level
• Second-order SQL injection: attacker stores payload via normal (WAF-passing) input. Later, application reads that data and constructs a query — the stored payload executes. WAF saw clean input; DB Firewall sees the resulting malicious SQL query.
• Blind SQLi: may not contain obvious SQL keywords in HTTP request; manifests as unusual query patterns at DB level

Supported Database Protocols: MySQL (3306), Microsoft SQL Server (1433), Oracle (1521), PostgreSQL (5432), MongoDB wire protocol. Protocol parsing is deep — understands database-specific extensions.

Products: Imperva SecureSphere, GreenSQL, Oracle Audit Vault and Database Firewall (AVDF), IBM Guardium.

Query Whitelisting: Learn normal application query patterns over baseline period. Block any query not matching approved patterns. Extremely effective but operationally complex — application code changes require whitelist updates.

DAM Architecture Options:

• Network-based: Sniffs database traffic via SPAN port or network tap. No impact on database performance. Cannot see encrypted database connections or localhost connections.
• Agent-based: Lightweight agent installed on database server. Captures all activity including local connections (DBA from localhost, stored procedures). Higher coverage but agent maintenance required.

What DAM Captures (Per Query):

• Full SQL statement text
• User account that executed it (database user + OS user + hostname)
• Source IP address and application name
• Timestamp and database name/schema
• Result: rows returned, rows affected
• Execution duration

Key Detection Scenarios (Exam-Tested):

• Off-hours DBA access: DBA connecting at 2 AM from personal workstation
• Bulk data extraction: SELECT * FROM customers returns 500,000 rows — exfiltration indicator
• Schema changes: DROP TABLE, ALTER TABLE outside change window
• Failed authentication attempts: brute force against database accounts
• Privilege escalation: regular user suddenly using DBA-level commands
• SQL injection reaching database: suspicious UNION SELECT, comment injection patterns in query text

Independence from Native Database Audit Logs (Critical Exam Point): DBAs can: disable database auditing, truncate audit logs, grant themselves AUDIT privileges to hide their own actions. DAM is deployed independently — DBAs cannot modify or delete DAM records. Provides immutable audit trail. This independence is why DAM satisfies compliance requirements (PCI DSS Requirement 10.2, SOX, HIPAA).

UEBA Integration: Baseline each DBA's normal query patterns (hours, database objects accessed, query types). Alert when behavior deviates — same DBA accessing HR tables they've never queried before is anomalous even if technically authorized.

Real-time Blocking: Some DAM products can block queries in real-time (effectively acting as a DB firewall). Adds latency — only enable for high-risk queries. Products: Imperva, IBM Guardium with blocking enabled.

Data Discovery (Must Come First):

• Scan structured (databases, spreadsheets), unstructured (file servers, SharePoint, email archives, cloud storage), and semi-structured (JSON, XML, log files) data stores for sensitive content
• Content inspection: regex patterns for SSN (XXX-XX-XXXX), credit card numbers (Luhn algorithm validation), passport numbers, IBAN, SWIFT codes, medical record identifiers
• Document fingerprinting: exact-match known sensitive documents even if renamed or partially modified
• ML-based classification: Microsoft Purview, Google Cloud DLP, Varonis — classify documents by content context, not just pattern matching
• Data flow mapping: where does sensitive data travel? Which applications, services, and users touch it?
• GDPR Article 30 Record of Processing Activities (RoPA) — requires documenting all processing of personal data

DLP Deployment Modes:

• Network DLP: Deployed at email gateway and web proxy. Inspects outbound traffic for sensitive data patterns. Example policy: block email with credit card numbers to external recipients. Requires SSL inspection for HTTPS. Cannot stop USB exfiltration.
• Endpoint DLP: Agent on workstation monitors: clipboard operations (copying sensitive data), USB drive writes, printing (optical character recognition), local application actions, cloud sync client uploads. Stops USB-based exfiltration that never traverses the network. Cannot inspect traffic from devices without the agent.
• Cloud DLP: Microsoft Purview, Google Cloud DLP API, Netskope, Zscaler. Native integration with cloud storage (OneDrive, SharePoint, Google Drive, Box). No agent required for cloud-native inspection.
• CASB (Cloud Access Security Broker): Visibility and control over all SaaS application usage. Detects shadow IT (Dropbox, personal Gmail, etc.). Enforces DLP policies in cloud apps. Modes: API-based (native integration with sanctioned apps) or proxy-based (intercepts all SaaS traffic). Products: Netskope, McAfee MVISION Cloud, Microsoft Defender for Cloud Apps.

DLP Policy Components: (1) Content identifier — what to detect (credit card pattern, specific document, keyword). (2) Conditions — where/who/when (email to external, USB write, specific user group). (3) Action — block, alert, encrypt, quarantine, require business justification.

The Luhn Algorithm: Mathematical checksum formula for validating credit card numbers. DLP uses Luhn validation to reduce false positives — a random 16-digit number usually fails Luhn check; a real credit card number passes. Dramatically reduces FP rate in DLP credit card detection.

Database Account Types and Least Privilege:

• Application accounts: Only SELECT/INSERT/UPDATE/DELETE on specific tables required by the application. No DDL (CREATE/ALTER/DROP) permissions. No access to audit tables. Connection from application server IPs only.
• Read-only reporting accounts: SELECT only on reporting views/tables. Used by BI tools, reports. No data modification.
• DBA accounts: Full access — carefully controlled. Should not be used for routine operations. JIT access. MFA required. All actions logged by DAM.
• Quarterly review of all database accounts — disable unused accounts (dormant accounts are backdoors).

Separation of Duties (Critical Exam Point):

• DBA has full access to database — can read all data, modify records, delete audit logs
• DBAs cannot self-audit: they have incentive and ability to cover unauthorized actions in their own logs
• DAM provides independent monitoring that DBAs cannot modify — satisfies separation of duties requirement
• Principle: no single person should both perform a sensitive action AND control the audit of that action

Sensitive Data in Non-Production Environments:

• Data masking: Replace real sensitive values with realistic fake values. "John Smith SSN 123-45-6789" → "Jane Doe SSN 987-65-4321". Preserves data format and referential integrity. Test applications work correctly with masked data. Static masking (at copy time) vs dynamic masking (real-time for specific users).
• Anonymization: Irreversibly transform data so individuals cannot be re-identified. Stronger than masking for regulatory purposes. Cannot reconstruct original data. GDPR: properly anonymized data no longer subject to GDPR requirements.
• Never use production PII/PHI/PCI data in development/test environments without masking — compliance violation in most frameworks.

Database Encryption:

• TDE (Transparent Data Encryption): Encrypts database files (.mdf, .ldf), backups, and temp files at the OS level. Transparent to applications — no code changes. Protects against: storage theft, unencrypted backup exposure, decommissioned disk theft. Does NOT protect against: authorized user query access, SQL injection (data is decrypted for authorized queries).
• Column-level encryption: Encrypt specific high-sensitivity columns (SSN, credit card, health data). Application-level — application decrypts for authorized users only. Protects even against DBA access. Higher performance overhead.
• Key management: Use HSM (Hardware Security Module) for master key storage. AWS KMS, Azure Key Vault, Thales HSM. Separate key management from data management (DBAs shouldn't hold encryption keys).

MDM vs MAM (Critical Exam Distinction):

• MDM (Mobile Device Management): Manages the entire device. Policies: screen lock timeout, passcode complexity, full disk encryption enforcement, remote wipe, device compliance (jailbreak/root detection), certificate deployment, VPN configuration, app management (whitelist/blacklist). Requires full enrollment — user privacy concern on personal devices.
• MAM (Mobile Application Management): Manages only corporate applications — no visibility into personal apps or data. Creates a secure container on the device for corporate apps (email, calendar, Teams). Personal apps outside the container are unaffected. Corporate data stays within managed container. Ideal for BYOD — employee privacy maintained. Products: Microsoft Intune MAM, VMware Workspace ONE, MobileIron.

BYOD Security Challenges and Solutions:

• Employee resistance to MDM on personal devices: use MAM instead. "I don't want my employer to wipe my personal iPhone" — MAM solves this by only wiping corporate apps/data container, not personal data.
• Samsung Knox: hardware-level containerization on Samsung devices. Separate work profile with encrypted storage, isolated from personal apps.
• iOS Managed Open In: iOS policy that restricts data sharing between managed (corporate) and unmanaged (personal) apps. Corporate email attachments cannot be opened in personal apps.

MDM Capabilities (Memorize):

• Enforce disk encryption (FileVault, BitLocker, iOS/Android native encryption)
• Enforce screen lock and passcode complexity
• Remote wipe — selective (corporate data only) or full device wipe for lost/stolen devices
• Certificate deployment — push client certificates for 802.1X Wi-Fi authentication
• VPN profile deployment — enforce corporate VPN on device
• Application catalog — required/optional/prohibited apps
• Jailbreak/root detection — detect compromised device state

Conditional Access (Identity + Device): Intune + Azure AD / Entra ID: deny access to corporate resources from non-enrolled or non-compliant devices. Policy: "User must be authenticated AND device must be enrolled in MDM AND device must be compliant (patch level, encryption, no jailbreak) to access Exchange Online." Single control that enforces both identity and device health requirements.

Enterprise App Store: Internal app distribution — apps undergo security review before deployment. Users install approved apps from enterprise catalog. Prevents sideloading of unauthorized apps on corporate devices.

CASB Architecture:

• Sits between users and cloud services — visibility and control over SaaS/IaaS/PaaS usage
• API mode: Direct API integration with sanctioned SaaS apps (M365, Salesforce, Box). Retrospective scanning of stored data. Cannot inspect traffic in real time but no proxy latency. Best for data-at-rest discovery.
• Proxy mode (forward/reverse): Inline inspection of traffic. Real-time blocking. Forward proxy intercepts user requests to cloud. Reverse proxy intercepts cloud app requests to users.
• Four pillars: Visibility (shadow IT discovery), Compliance (DLP policies in cloud), Data Security (encryption, rights management), Threat Protection (malware in cloud storage).

Shadow IT Discovery: CASB analyzes firewall/proxy logs to identify all cloud services in use — not just sanctioned ones. Common finding: hundreds of cloud services employees use without IT approval. Risk assessment per service (compliance certifications, data residency, breach history). Block high-risk services, allow low-risk with monitoring.

Data Governance Frameworks:

• GDPR: EU regulation. Legal basis for processing, right to erasure, data minimization, 72-hour breach notification. RoPA (Record of Processing Activities). Data Protection Impact Assessment (DPIA) for high-risk processing.
• HIPAA: US healthcare. PHI (Protected Health Information). Technical safeguards: encryption, audit controls, automatic logoff, unique user ID. Administrative safeguards: risk assessment, workforce training, access authorization.
• PCI DSS: Payment card industry. 12 requirements. Cardholder Data Environment (CDE) scope reduction. Requirement 10: audit logging. Requirement 6: WAF required for internet-facing applications or code review. Tokenization reduces scope.

Data Retention and Disposal: Retention schedules based on legal/regulatory requirements (GDPR: not longer than necessary; SOX: 7 years for financial records). Secure disposal: NIST 800-88 media sanitization — overwrite (software), degaussing (magnetic), physical destruction (shredding). Certificates of destruction for audit.