UNIT 5: INFORMATION SECURITY - EXAM-FOCUSED SHORT NOTES

1.0 FOUNDATIONAL SECURITY CONCEPTS

1.1 Core Terminology & Characteristics

• Threat: Potential violation of security. A circumstance/event with potential to cause harm (e.g., a hacker, a flood).

• Attack: Active assault on system integrity, availability, or confidentiality. An intentional act (e.g., phishing, DoS).

• Vulnerability: Weakness in system that can be exploited by a threat (e.g., unpatched software, weak password).

• Risk: Likelihood of a threat exploiting a vulnerability and the impact. Risk = Threat × Vulnerability × Impact.

Critical Characteristics of Information (Pillars of Security):

Fabrication, Interception, Modification, Repudiation (FIMR):

• Fabrication: Creating false data/events (e.g., fake log entries).

• Interception: Eavesdropping on data in transit (confidentiality breach).

• Modification: Altering data (integrity breach).

• Repudiation: Denial of an action (e.g., "I didn't send that").

[!TIP] Exam Focus: Be ready to define each term and give a real-world example. Questions often ask to "list and define categories of security attacks" – FIMR is a key framework.

1.2 Security Fundamentals

• Security vs. Protection: Protection is a subset of security. Security is a broader, strategic process (policy, risk mgmt). Protection is tactical implementation (firewalls, encryption).

• Security Policy: Formal document stating management's intent, rules, and procedures. Key Components: Purpose, Scope, Responsibilities, Enforcement, Compliance.

• Security Life Cycle (Continuous Cycle):

  1. Identify & Assess: Identify assets, threats, vulnerabilities. Risk assessment.

  2. Develop & Implement: Design & deploy controls (policy, tech).

  3. Monitor & Detect: Continuous monitoring, IDS, audits.

  4. Respond & Recover: Incident response, disaster recovery.

  5. Review & Update: Lessons learned, policy updates.

• Trust & Assumptions: No system is 100% secure. Security is based on assumptions (e.g., "kernel is trusted"). Trust is placed in specific components (hardware, software, admin). Breach of trust compromises the whole system.

• Principle of Least Privilege: Grant only the minimum access/resources needed for a task. Applied to users, processes, and information flow (prevents unauthorized data leakage).

[!TIP] Common Pitfall: Don't confuse Security Policy with Security Procedures. Policy is the "what" and "why"; procedures are the "how".

2.0 CRYPTOGRAPHIC TECHNIQUES & ALGORITHMS

2.1 Classical & Basic Cryptography

• Steganography vs. Encryption:

  | Feature | Steganography | Encryption | | :--- | :--- | :--- | | Goal | Hide existence of message. | Hide meaning of message. | | Output | Ciphertext looks like something else (image, text). | Ciphertext is random-looking data. | | Example | Hiding text in image pixels. | AES, DES. |

• Substitution Cipher (Caesar):

  • Shift each letter by fixed key k.

  • Encryption: C = (P + k) mod 26

  • Decryption: P = (C - k) mod 26

  • Example (key=3): A→D, B→E, ..., Z→C.

  • Weakness: Only 25 keys; frequency analysis breaks it.

• Playfair Cipher:

  • Digraph substitution (pairs of letters).

  • Uses 5x5 matrix (I/J merged) with a keyword.

  • Rules: Same row → shift right; same column → shift down; rectangle → swap corners.

  • Example: Plaintext "HELLO" → pairs "HE LX LO" (add X if odd). Encrypt using matrix rules.

2.2 Symmetric Cryptography

• Block Cipher: Encrypts fixed-size blocks (e.g., 64-bit DES, 128-bit AES).

• Design Principles:

  1. Confusion: Make relationship between key & ciphertext complex (S-Boxes).

  2. Diffusion: Spread plaintext influence over many ciphertext bits (P-Boxes, permutations).

• Data Encryption Standard (DES):

  • Block Size: 64 bits. Key Size: 56 bits (plus 8 parity bits).

  • S-Boxes (Substitution Boxes): 8 non-linear S-Boxes. Core source of confusion. They take 6-bit input, output 4-bit. Closely guarded design to resist differential cryptanalysis.

  • Avalanche Effect: Small change in plaintext/key → ~50% change in ciphertext bits. DES exhibits this.

• Advanced Encryption Standard (AES):

  • Block Size: 128 bits. Key Sizes: 128, 192, 256 bits.

  • Detailed Steps (per round for 128-bit key, 10 rounds):

    1. SubBytes: Non-linear substitution using S-Box.

    2. ShiftRows: Cyclic shift of rows for diffusion.

    3. MixColumns: Mix columns using polynomial multiplication.

    4. AddRoundKey: XOR with round key.

    • Final round omits MixColumns.

  • Key Expansion: Original key → 44/52/60 32-bit words (for 128/192/256-bit keys). Uses RotWord, SubWord, Rcon (round constant).

• Modes of Operation (for block ciphers on long messages):

  | Mode | IV Needed? | How it Works | Main Use / Drawback | | :--- | :--- | :--- | :--- | | ECB | No | Each block encrypted independently. | Rarely used. Identical plaintext blocks → identical ciphertext blocks. Leaks data patterns (e.g., penguin image). | | CBC | Yes | C_i = E_K(P_i ⊕ C_{i-1}), C_0 = IV. | Chaining hides patterns. Needs padding. | | CFB | Yes | C_i = P_i ⊕ E_K(C_{i-1}). | Stream cipher mode. No padding. | | OFB | Yes | O_i = E_K(O_{i-1}), C_i = P_i ⊕ O_i. | Independent of plaintext. Error doesn't propagate. | | CTR | Yes (nonce) | C_i = P_i ⊕ E_K(Nonce || Counter). | Parallelizable, random access. |

[!TIP] Exam Trap: "Why is ECB rarely used?" → Because it's deterministic and reveals patterns in plaintext. Always use CBC or CTR for sensitive data.

2.3 Asymmetric (Public-Key) Cryptography

• Comparison:

  | Feature | Symmetric (Private) | Asymmetric (Public) | | :--- | :--- | :--- | | Keys | Single shared secret key. | Key pair: Public (distribute) & Private (secret). | | Speed | Fast (hardware). | Slow (math-intensive). | | Use Case | Bulk data encryption. | Key exchange, digital signatures, small data. | | Algorithms | AES, DES, 3DES, Blowfish. | RSA, ECC, Diffie-Hellman, ElGamal. |

• RSA Algorithm:

  • Key Generation:

    1. Choose primes p, q. Compute n = p × q.

    2. Compute Euler's Totient: φ(n) = (p-1)(q-1).

    3. Choose e (public) such that 1 < e < φ(n), gcd(e, φ(n)) = 1.

    4. Compute d (private) such that d × e ≡ 1 mod φ(n) (using Extended Euclidean Algorithm).

  • Encryption: C = M^e mod n

  • Decryption: M = C^d mod n

  • Attacks on RSA:

    • Factoring Problem: Factoring n to get p,q → compute d. Most fundamental.

    • Chosen Ciphertext Attack (CCA): Attacker decrypts chosen ciphertexts (e.g., Bleichenbacher's attack on PKCS#1 v1.5).

    • Low Exponent Attack: If e small & M^e < n, M = ∛C (no mod).

    • Timing Attack: Measures decryption time to deduce d.

• Diffie-Hellman (DH) Key Exchange:

  • Goal: Establish shared secret over insecure channel.

  • Primitive Root (α) modulo q: Number whose powers generate all numbers 1..q-1. α^k mod q for k=1..q-1 gives all residues.

  • Algorithm Steps:

    1. Agree on public prime q and primitive root α.

    2. User A: Private X_A (random < q), Public Y_A = α^{X_A} mod q.

    3. User B: Private X_B, Public Y_B = α^{X_B} mod q.

    4. Exchange public keys.

    5. Shared Secret: A computes K = Y_B^{X_A} mod q; B computes K = Y_A^{X_B} mod q.

  • Vulnerability: Man-in-the-Middle (MitM). Attacker intercepts Y_A, Y_B, establishes separate keys with each.

  • Numerical Example (q=11, α=7, X_A=3, X_B=6):

    • Y_A = 7^3 mod 11 = 343 mod 11 = 2

    • Y_B = 7^6 mod 11 = 117649 mod 11 = 4

    • Shared K_A = 4^3 mod 11 = 64 mod 11 = 9

    • Shared K_B = 2^6 mod 11 = 64 mod 11 = 9

[!TIP] Exam Must-Know: Euler's Totient φ(n) for RSA. How to find primitive root for small primes (test all powers). Always show DH shared secret calculation.

2.4 Hash Functions & Message Authentication

• Hashing:

  • Definition: One-way function mapping any length input → fixed-length output (hash/digest).

  • Purpose: Data integrity verification, password storage, digital signatures.

  • Benefits: Fixed size, deterministic, fast computation, pre-image resistant, collision resistant.

• Why Hashing Alone Does NOT Ensure Integrity in Network Communication:

  • Attacker can modify both message and its hash in transit.

  • Example: Hash(M) sent with M. Attacker changes M to M', computes Hash(M'), sends (M', Hash(M')). Receiver has no way to know M' is tampered.

  • Solution: Use Message Authentication Code (MAC) or digital signature. MAC uses a shared secret key to generate/verify tag, preventing attacker from forging valid tag.

• Message Authentication Code (MAC):

  • Definition: Short tag generated from message + secret key. Provides authentication (sender knows key) and integrity (tag changes if message altered).

  • How it Achieves Confidentiality? It doesn't directly. But MAC can be used in Encrypt-then-MAC scheme: Encrypt(message), then MAC(ciphertext). This provides both.

  • Types of Attacks Addressed: Content modification, masquerade (source authentication), replay (if nonce/timestamp used).

• Secure Hash Algorithm (SHA) Family: SHA-1 (160-bit, broken), SHA-2 (SHA-256, SHA-512), SHA-3 (Keccak).

[!TIP] Key Distinction: Hash (no key) ≠ MAC (with key). Hash ensures integrity only if receiver already knows correct hash via separate secure channel. MAC does not require separate channel.

3.0 AUTHENTICATION & ACCESS CONTROL

3.1 Authentication Systems

• Authentication: Verifying identity of user/entity.

• Types (Factors):

  1. Something you know: Password, PIN.

  2. Something you have: Smart card, token, phone.

  3. Something you are: Biometrics (fingerprint, retina).

• Password Management:

  • Best Practices: Long (12+ chars), complex (mix types), unique per site, regular change (controversial), use password manager.

  • Storage: Never store plaintext. Store salted hash (e.g., hash(salt + password)). Salt prevents rainbow table attacks.

  • Attacks: Brute-force, dictionary, rainbow tables, phishing, keylogging.

3.2 Access Control Models

• Principle of Least Privilege in AC: Grant only permissions needed for current role/task. Reduces attack surface.

3.3 Supporting Frameworks

• Confinement Problem: How to prevent a process (e.g., a program from an untrusted source) from leaking data it's allowed to read to an unauthorized destination.

  • Mitigation Methods: Capabilities (tokens granting access), Sandboxing (restricted environment), Virtualization, Secure Kernels (reference monitors).

• Six Components of PKI:

  1. Certificate Authority (CA): Issues/revokes digital certificates.

  2. Registration Authority (RA): Verifies identity before CA issues cert.

  3. Certificate Repository: Database of certificates.

  4. Certificate Revocation List (CRL): List of revoked certificates.

  5. Policy: Rules governing PKI operation.

  6. Key Management: Generation, storage, backup, recovery of keys.

[!TIP] Exam Focus: Differentiate DAC/MAC/RBAC/TBAC with clear examples. Know PKI components by name and function.

4.0 SECURITY PROTOCOLS & SYSTEMS

4.1 Authentication Protocols

• Kerberos:

  • Purpose: Network authentication in client-server model using tickets. Trusted third party (KDC).

  • Requirements: Secure against eavesdropping/replay; scalable; interoperable.

  • Need for Double Encryption:

    1. Client → KDC (AS): E_{Kc}(TGT, SKc,tgs) (encrypted with client's key).

    2. Client → TGS: E_{SKc,tgs}(Authenticator, TGT) & E_{Ktgs}(ServiceTicket).

    • First encryption proves client to KDC. Second (on service ticket) protects it from client modification. TGS decrypts inner ticket, verifies outer authenticator.

  • v4 vs v5: v5 fixes v4 weaknesses: supports multiple realms, forwardable/renewable tickets, pre-authentication, better encryption handling.

• PGP (Pretty Good Privacy):

  • Components & Block Diagram:

    
    [Message] → [Compress] → [Session Key Encrypt (Sym)] → [Public Key Encrypt (Asym)] → [Base64] → [Email]
    
    

    • Uses hybrid encryption: Symmetric key (e.g., IDEA) for message speed. Asymmetric (RSA/ElGamal) to encrypt session key.

    • Digital Signature: Hash message → encrypt hash with sender's private key.

  • Confidentiality & Authentication:

    • Confidentiality: Message encrypted with session key; session key encrypted with receiver's public key.

    • Authentication & Integrity: Sender signs message with private key; receiver verifies with sender's public key.

4.2 Network Security Protocols

• IPsec (IP Security):

  • Basics: Suite of protocols for securing IP-layer traffic (VPNs).

  • Components:

    • AH (Authentication Header): Provides integrity, authentication, anti-replay (no encryption).

    • ESP (Encapsulating Security Payload): Provides confidentiality (encryption), integrity, authentication, anti-replay.

  • Modes: Transport (payload only) & Tunnel (entire IP packet).

• SSL/TLS:

  • Purpose: Secure communication over application layer (HTTPS, SMTP).

  • Brief Operation:

    1. Handshake: Negotiate cipher suite, authenticate server (and optionally client) via certificates, generate session keys (using RSA/DH).

    2. Record Protocol: Fragments, compresses, encrypts application data using symmetric session keys.

• Secure Electronic Transaction (SET):

  • How Achieved: Uses dual signatures. Customer signs order info & payment info separately, then combines. Merchant sees order, bank sees payment, neither sees both. Uses X.509 certificates for all parties (cardholder, merchant, bank).

4.3 Enterprise & System Security

• Enterprise Security Specifications: Formal documents defining security requirements, standards, procedures for an organization (e.g., password policy, network segmentation, incident response plan).

• Linux Security Architecture:

  • Discretionary Access Control (DAC): Traditional Unix permissions (user/group/other).

  • Mandatory Access Control (MAC): SELinux (Security-Enhanced Linux) or AppArmor. Enforces type enforcement, role-based access, multi-level security.

  • Other Features: Capabilities, namespaces, seccomp-bpf.

• Windows OS Security Features:

  • Access Tokens: User's privileges & group SIDs.

  • Security Reference Monitor (SRM): Kernel component enforcing security policy, object access checks.

  • User Account Control (UAC): Privilege separation.

  • BitLocker: Full disk encryption.

• Database Auditing:

  • Purpose: Track & log database activities (who accessed what, when, what operation).

  • Role in Security: Detect unauthorized access, investigate breaches, ensure compliance (GDPR, HIPAA), monitor privilege use.

[!TIP] Diagram Required: Be ready to sketch Kerberos flow (AS, TGS exchanges) and PGP block diagram. Know SELinux as Linux's MAC implementation.

5.0 NETWORK SECURITY DEVICES & MECHANISMS

5.1 Firewalls

• Definition: Network security device/system that monitors & controls incoming/outgoing traffic based on predetermined security rules.

• How it Works: Sits at network boundary (perimeter). Inspects packets against rule set (ACL). Permits, denies, or proxies.

• Three Common Types:

  1. Packet Filtering Firewall (Network Layer):

     • Inspects packet headers (IP, port, protocol).

     • Stateless. Fast but limited context.

     • Diagram: Simple router with ACL rules.

  2. Stateful Inspection Firewall (Transport Layer):

     • Tracks state of connections (TCP handshake). Knows if packet belongs to established session.

     • More secure than stateless. Can detect spoofing.

     • Diagram: State table mapping connections.

  3. Application-Level Gateway (Proxy Firewall) (Application Layer):

     • Intercepts traffic, acts as intermediary (proxy). Deep packet inspection (DPI).

     • Understands protocols (HTTP, FTP). Can filter content.

     • Diagram: Client → Firewall (proxy) → Server. Firewall terminates connections.

5.2 Intrusion Detection Systems (IDS)

• Intrusion Detection: Monitoring network/system for malicious activity/policy violations.

• Role of IDS: Detect (not prevent). Alerts administrators. Provides evidence for forensics.

• Three Benefits:

  1. Detect attacks that bypass firewalls.

  2. Document security incidents for compliance/forensics.

  3. Deter attackers (if known to be present).

• Types:

  • By Location: NIDS (network traffic), HIDS (host logs/processes).

  • By Detection Method:

    • Misuse/ Signature-based: Looks for known attack patterns (signatures). Low false positives, can't detect zero-day.

    • Anomaly-based: Establishes baseline "normal" behavior, flags deviations. Can detect zero-day but high false positives.

5.3 Tunneling & Encryption

• Encrypted Tunnel:

  • Concept: Encapsulating original packet within a new packet, with payload encrypted. Hides original packet's content & often source/destination.

  • Use: VPNs (IPsec, SSL/TLS), SSH tunneling, Tor. Provides confidentiality & integrity across untrusted networks (like the internet).

[!TIP] Diagram Required: Draw three firewall types showing packet flow. Know NIDS vs HIDS placement and signature vs anomaly trade-offs.

6.0 MALWARE, THREATS & VULNERABILITIES

6.1 Malicious Software

• Virus vs. Worm:

  | Feature | Virus | Worm | | :--- | :--- | :--- | | Propagation | Needs user action (run infected file). | Self-replicating, spreads automatically via network. | | Payload | Often destructive (delete files). | Often payload-less (just consume bandwidth) or drop backdoor. | | Example | File infector, macro virus. | SQL Slammer, WannaCry (also ransomware). |

• Virus-Related Threats & Countermeasures:

  • Threats: Data corruption, theft, system crash, botnet recruitment.

  • Countermeasures: Antivirus (signature + heuristic), patching, user education, least privilege, email filtering, backups.

• Types of Viruses:

  • File Infector: Attaches to executable (.exe).

  • Macro: Infects Office documents (Word, Excel).

  • Boot Sector: Infects MBR/boot sector.

  • Polymorphic: Changes signature each infection (encrypts body).

  • Metamorphic: Rewrites own code.

  • Multipartite: Infects multiple locations (file + boot).

• Malicious Logic: Code intentionally designed to cause harm (virus, worm, trojan, logic bomb). Impact: Data loss, service disruption, financial loss, reputation damage.

6.2 Network & Application Attacks

• DoS & DDoS:

  • DoS: Single source floods target (e.g., SYN flood, Ping of Death).

  • DDoS: Multiple compromised systems (botnet) attack target. Harder to block.

  • Goal: Exhaust resources (bandwidth, CPU, memory).

• Web Application Vulnerabilities:

  • SQL Injection (SQLi):

    • Definition: Injecting malicious SQL code into input fields to manipulate database queries.

    • Prevention: Input validation (whitelist), parameterized queries/prepared statements, least privilege DB accounts, WAF.

  • Cross-Site Scripting (XSS):

    • How it Works: Inject malicious scripts (usually JavaScript) into web pages viewed by others.

    • Types: Stored (saved on server, e.g., comment), Reflected (in URL, reflected), DOM-based.

    • Impact: Steal session cookies, perform actions as user.

    • Prevention: Input validation, output encoding (escape HTML), Content Security Policy (CSP).

• Cookies:

  • Role: State management, session tracking, personalization.

  • Security Considerations: Set Secure (HTTPS only), HttpOnly (no JS access), SameSite (prevent CSRF), short expiry, avoid storing sensitive data.

6.3 Analysis & Forensics

• Vulnerability Analysis:

  • Importance in Auditing: Proactive identification of weaknesses before attackers exploit them. Essential for risk assessment, compliance (PCI-DSS, ISO 27001).

  • Methods: Automated scanning (Nessus, OpenVAS), manual penetration testing, code review.

• Forensic Analysis on Compromised Server:

  1. Containment: Isolate server (network disconnect).

  2. Preservation: Create bit-for-bit disk image (forensic copy). Document scene.

  3. Identification: Analyze logs (syslog, auth.log), processes, network connections, file integrity (Tripwire), malware.

  4. Analysis: Determine attack vector, scope, tools used, data exfiltrated.

  5. Eradication & Recovery: Remove malware, patch vulnerabilities, restore from clean backup.

  6. Lessons Learned: Update policies, improve detection.

[!TIP] Exam Focus: Contrast virus/worm clearly. For SQLi/XSS, state one specific prevention technique. Forensic steps must follow order: Preserve before analyze.

7.0 WEB TECHNOLOGIES & SECURITY

7.1 Core Web Concepts

• URL vs. URI:

  • URI (Uniform Resource Identifier): Generic identifier for a resource. scheme:[//authority]path[?query][#fragment]. Example: mailto:[email protected].

  • URL (Uniform Resource Locator): Subset of URI that specifies location and access protocol. Example: https://example.com:443/path?query=1.

  • Key Difference: All URLs are URIs, but not all URIs are URLs (e.g., urn:isbn:0451450523 is a URN, not locator).

7.2 Web Security Practices

• Secure Cookie Handling:

  • Use Secure flag (HTTPS only).

  • Use HttpOnly flag (prevent XSS theft).

  • Use SameSite=Strict/Lax (prevent CSRF).

  • Set appropriate Expires/Max-Age.

  • Never store passwords/plaintext sensitive data.

• Input Validation:

  • Whitelist (Allow-list): Define what is allowed (e.g., only alphanumeric). More secure.

  • Blacklist (Deny-list): Define what is blocked (e.g., <script>). Easily bypassed.

  • Contextual: Validate based on context (HTML context, SQL context, OS command context).

  • Prevents: SQLi (parameterized queries are better), XSS (output encoding is primary defense).

8.0 SPECIAL TOPICS & SYNTHESIS

8.1 Trusted Systems

• Definition: System that enforces security policy correctly and can be verified to do so. Built on trusted computing base (TCB) – hardware, software, firmware responsible for enforcing policy.

• Role: Provides high-assurance security (e.g., military, government). Uses formal verification, secure design principles (least privilege, isolation). Example: SELinux in enforcing mode, Trusted Platform Module (TPM).

8.2 Security in Practice (Repeated Topics)

• Secure Electronic Transaction (SET) - Detailed:

  • Participants: Cardholder, Merchant, Issuing Bank, Acquiring Bank, CA.

  • How Achieved:

    1. Cardholder gets dual certificate (for ordering & payment).

    2. Dual Signature: Sign(OrderInfo) & Sign(PaymentInfo) → combined. Merchant verifies order signature, bank verifies payment signature. Neither sees both.

    3. All messages encrypted (symmetric session key, encrypted with recipient's public key).

    4. End-to-end confidentiality for payment info.

• Enterprise Security Specifications - Detailed:

  • Comprehensive document covering:

    • Acceptable Use Policy (AUP)

    • Access Control Policy (models, password rules)

    • Incident Response Plan

    • Network Security (firewall rules, VPN use)

    • Physical Security

    • Compliance (audit requirements)

    • Roles & Responsibilities

  • Purpose: Set standards, assign accountability, ensure consistency, meet legal/regulatory needs.

[!TIP] Synthesis: SET uses public key crypto for key exchange & signatures, symmetric crypto for bulk data, and dual signatures for privacy. Enterprise specs are management-level, not technical configs.

END OF UNIT 5 NOTES
Aligned with RGPV past papers (Jun 2025, Dec 2024, May 2024, May 2023). Focus on definitions, comparisons, algorithm steps, and diagrams.