Web Security, Firewalls, Email Security & Identity Management
This lesson covers the practical application of security controls to protect web communications, email, and user identities — the three most critical communication channels in modern organizations. These topics bridge the theoretical cryptography from Lessons 9–11 with real-world deployment.
---
HTTP Security — From HTTP to HTTPS
HTTP (HyperText Transfer Protocol) is inherently insecure — all data is transmitted in plaintext, readable by any network observer. HTTPS adds TLS (Transport Layer Security) encryption over HTTP.
TLS Handshake Process (TLS 1.3 — simplified):
- ClientHello: Browser sends supported TLS versions, cipher suites, key share (ECDHE)
- ServerHello: Server selects cipher suite, responds with key share + certificate
- Certificate Verification: Browser verifies server certificate against trusted CA store
- Key Derivation: Both sides independently derive same session keys from ECDHE exchange
- Finished: Encrypted communication begins
| HTTP Security Feature | What It Does | Header / Mechanism | Protects Against |
|---|---|---|---|
| HTTPS / TLS 1.3 | Encrypts all HTTP traffic | TLS handshake + certificate | Eavesdropping, MitM |
| HSTS | Forces HTTPS, prevents downgrade | Strict-Transport-Security header | SSL stripping attacks |
| CSP | Controls which resources browser loads | Content-Security-Policy header | XSS, clickjacking |
| X-Frame-Options | Prevents embedding in iframes | X-Frame-Options: DENY/SAMEORIGIN | Clickjacking |
| Certificate Pinning | Hardcodes expected certificate | In app/browser | MitM with rogue CA |
| CORS | Controls cross-origin requests | Access-Control-Allow-Origin header | Cross-origin data theft |
| SameSite Cookies | Prevents cross-site cookie sending | Cookie SameSite attribute | CSRF attacks |
---
Firewalls — Types and Operation
A firewall is a network security device (hardware or software) that monitors and controls incoming/outgoing network traffic based on predetermined security rules. It establishes a barrier between trusted internal networks and untrusted external networks.
Types of Firewalls:
| Firewall Type | OSI Layer | How It Filters | Speed | State Awareness | Modern Use |
|---|---|---|---|---|---|
| Packet Filtering | Layer 3–4 | Source/dest IP, port, protocol | Very Fast | Stateless | Router ACLs, basic perimeter |
| Stateful Inspection | Layer 3–4 | Tracks TCP connection state | Fast | Stateful | Most enterprise firewalls |
| Application Layer (Proxy) | Layer 7 | Inspects application content | Slower | Full | Zscaler, Blue Coat proxies |
| Next-Gen Firewall (NGFW) | Layer 3–7 | Deep packet inspection + IPS + App ID | Medium | Full | Palo Alto, Fortinet, Check Point |
| Web Application Firewall (WAF) | Layer 7 (HTTP) | HTTP request analysis, OWASP rule sets | Medium | Full | ModSecurity, AWS WAF, Cloudflare |
| Host-based Firewall | Layer 3–7 (on host) | Per-host rules | Fast | Varies | Windows Defender Firewall, iptables |
DMZ (Demilitarized Zone) Architecture: A DMZ places publicly accessible servers (web, email, DNS) between two firewalls:
- Outer Firewall: Separates internet from DMZ — allows only specific ports
- Inner Firewall: Separates DMZ from internal network — strict rules
- If a DMZ server is compromised, the attacker still cannot easily access internal systems
---
Email Security — SPF, DKIM, DMARC
Email was designed without security and is trivially forged. Modern email security uses three complementary DNS-based authentication mechanisms:
| Mechanism | Full Name | How It Works | What It Prevents | DNS Record Type |
|---|---|---|---|---|
| SPF | Sender Policy Framework | Lists IP addresses authorized to send email for a domain | Email spoofing (unauthorized senders) | TXT record |
| DKIM | DomainKeys Identified Mail | Cryptographic signature on email headers/body | Content tampering, forgery | TXT record (public key) |
| DMARC | Domain-based Message Authentication, Reporting & Conformance | Policy that combines SPF + DKIM; specifies what to do with failures | Phishing, spoofing | TXT record |
| S/MIME | Secure/Multipurpose Internet Mail Extensions | End-to-end encryption + digital signature using X.509 certificates | Eavesdropping, forgery, non-repudiation | Client-side configuration |
| PGP/GPG | Pretty Good Privacy | End-to-end encryption using web-of-trust key model | Eavesdropping, forgery | Client-side key exchange |
DMARC Policy Options:
p=none— Monitor only, take no actionp=quarantine— Send suspicious emails to spam/junkp=reject— Reject emails failing DMARC checks (strongest protection)
---
Backup Strategies
Backups are a primary control against ransomware and data loss:
| Backup Type | What It Backs Up | Time | Storage Needed | Recovery Time | Best Practice |
|---|---|---|---|---|---|
| Full Backup | All data, every backup | Long | Large | Fast | Weekly |
| Incremental | Only changes since last backup | Short | Small | Slow (chain) | Daily |
| Differential | Changes since last full backup | Medium | Medium | Medium | Daily |
| Mirror Backup | Exact real-time copy | Continuous | Same as source | Instant | For critical systems |
3-2-1 Backup Rule: 3 copies of data, on 2 different media types, with 1 offsite (or cloud).
Exam Tip: Know the three email authentication mechanisms: SPF (who can send), DKIM (message signature), DMARC (policy for failures). Together they significantly reduce email phishing. Also remember: HSTS prevents SSL stripping attacks; CSP prevents XSS attacks via browser policy.
---
Identity Management and Authorization
Identity Management (IdM) is the discipline of managing digital identities (who users are) and their access to resources (what they can do).
Key Concepts:
| Concept | Definition | Technology | Example |
|---|---|---|---|
| Identity | Digital representation of a person/system | LDAP, Active Directory | Username johndoe@company.com |
| Authentication | Proving you are who you claim | Password, MFA, biometrics | Google login with 2FA |
| Authorization | Granting access to resources based on identity | RBAC, ABAC, ACL | Admin can delete, user can read |
| SSO | Single Sign-On — one login for multiple services | SAML 2.0, OAuth 2.0, OIDC | Login with Google button |
| IAM | Identity and Access Management system | AWS IAM, Azure AD | Managing cloud permissions |
| PAM | Privileged Access Management | CyberArk, BeyondTrust | Controlling admin account access |
| Federation | Trusting identities across organizations | SAML, WS-Federation | University accessing journal via SAML |
Authorization Patterns:
| Pattern | Full Name | How It Works | Best For | Limitation |
|---|---|---|---|---|
| DAC | Discretionary Access Control | Resource owner grants permissions to others | Personal file systems | Owner can accidentally grant too much |
| MAC | Mandatory Access Control | System enforces classification levels (Confidential, Secret) | Military, government | Rigid, complex to manage |
| RBAC | Role-Based Access Control | Permissions assigned to roles; users assigned to roles | Enterprise systems | Role explosion problem |
| ABAC | Attribute-Based Access Control | Permissions based on attributes of user, resource, environment | Fine-grained cloud IAM | Complex policies |
| PBAC | Policy-Based Access Control | Centralized policies combining RBAC + ABAC | Large enterprises | Requires sophisticated policy engine |
---
Study Deep: Web and Email Security
- HTTPS is not the same as safe: A green padlock (HTTPS) only means the connection is encrypted — it does NOT mean the website itself is legitimate or trustworthy. Phishing sites routinely use HTTPS certificates (Let's Encrypt provides free certificates to anyone). Users must check the actual domain name, not just the padlock icon.
- DMARC adoption is accelerating: Following high-profile BEC (Business Email Compromise) fraud, CISA issued a directive mandating DMARC for US federal agencies. As of 2023, only ~50% of Fortune 500 companies have DMARC at enforcement level (p=reject). Domains without DMARC can be trivially spoofed for phishing attacks.
- Zero Trust Identity (ZTI) replaces perimeter security: Traditional IAM assumed internal network users were trusted. Zero Trust Identity requires continuous re-authentication based on context: device posture, location, time, behavior risk score. Microsoft Conditional Access and Google BeyondCorp Enterprise implement ZTI — even internal requests go through the same security evaluation.
- OAuth 2.0 authorization code injection attacks: OAuth 2.0 enables "Login with Google/Facebook." Misconfigured OAuth implementations are vulnerable to authorization code injection, where an attacker substitutes a stolen authorization code for their own. PKCE (Proof Key for Code Exchange) mitigates this by binding the authorization request to the token exchange.
- Just-in-Time (JIT) privileged access: Rather than permanently assigning admin roles (standing privileges), JIT access grants elevated privileges only when needed, for a limited time, with approval workflow. CyberArk, BeyondTrust, and Azure AD PIM implement JIT. This dramatically reduces the risk from compromised admin accounts.