Information Security and Privacy | Semester 6 Complete Core Notes
Semester 6 - Page 4: Information Security and Privacy. 25 numbered topics, highlighted rules, worked defensive cases, answered exam questions, diagrams, comparison tables and three complete Python demos. General common-core guide, not an official syllabus or legal advice. Practice only within explicit permission.
Topic map
- CIA and security objectives
- Assets, threats, vulnerabilities and risk
- Threat modeling and trust boundaries
- Authentication, MFA and account recovery
- Authorization and least privilege
- Access-control models and accountability
- Sessions, cookies and browser boundaries
- Symmetric/asymmetric cryptography and keys
- Hashes, integrity and trusted expected values
- MACs, HMAC and digital signatures
- Password storage and secret handling
- TLS, certificates and secure channels
- Input validation and SQL injection prevention
- Output encoding, XSS and context
- CSRF, CORS and request origin
- Networks, firewalls and segmentation
- Malware, phishing and human workflows
- Backups, availability and recovery tests
- Incident response and evidence
- Security testing and responsible disclosure
- Privacy purpose and data minimization
- Pseudonymization, anonymization and reidentification
- Retention, sharing and legal scope
- Defense in depth and secure lifecycle
- Exam and defensive checklist
1. CIA and security objectives
Confidentiality restricts reading, integrity protects against unauthorized change and availability enables authorized use. Security manages risk rather than promising perfect safety.
Answer: No. Confidentiality and integrity can still fail.
2. Assets, threats, vulnerabilities and risk
Assets are what needs protection; threats can cause harm; vulnerabilities enable scenarios; controls reduce likelihood/impact. Risk estimates and residual risk need stated assumptions.
Answer: No. It is a modeling aid with uncertain inputs.
3. Threat modeling and trust boundaries
Identify data flows, entry points, assets, actors and boundaries before choosing controls. External/client input remains untrusted even when it looks familiar.
Answer: No. Authority must come from the trusted control boundary.
Untrusted client request -> authenticated identity boundary -> object/action authorization -> validated query/data boundary -> permitted result only
4. Authentication, MFA and account recovery
Authentication verifies a claimed identity. MFA uses distinct factors; recovery and session setup need comparable care because weak recovery can defeat strong sign-in.
Answer: No. Authentication and authorization are different checks.
5. Authorization and least privilege
Authorization decides permitted actions/resources. Deny by default, check every protected operation and keep privileges limited to actual needs.
Answer: No. Attackers can send requests without that interface.
6. Access-control models and accountability
Discretionary, mandatory, role-based and attribute-based models organize permissions differently. Audit records support accountability with privacy/retention controls.
Answer: No. Least privilege and object/context restrictions still apply.
7. Sessions, cookies and browser boundaries
Sessions bind ongoing requests to authenticated state; tokens/cookies need suitable scope, lifecycle and protection. Cookie and browser policies do not replace application authorization.
Answer: No. It limits script access to a cookie, not every authenticated request effect.
8. Symmetric/asymmetric cryptography and keys
Symmetric schemes share a secret; asymmetric schemes use public/private key roles. Use reviewed authenticated constructions and libraries rather than custom encryption.
Answer: No. Secret key control is part of the threat model.
9. Hashes, integrity and trusted expected values
A cryptographic digest is not reversible encryption. A matching digest authenticates content only as well as the trusted expected value/source; hashes are not password storage by default.
Answer: No. It can supply its own matching value.
Synthetic SHA-256 digest comparison, not password storage
import hashlib
for message in [b"notes", b"Notes"]:
print(message.decode(), hashlib.sha256(message).hexdigest())
print("A matching digest needs a trusted expected value; it does not identify a sender.")
Checked output:
notes ab5aa97074c454a0632057e704220d9a6678fbf773a0a5806fc09b8173b07309 Notes 8a7525b1492fb84833f5c4a69b30f4bfbb134f9b666b61a2c1872d63d234c085 A matching digest needs a trusted expected value; it does not identify a sender.
10. MACs, HMAC and digital signatures
A MAC uses a shared secret for message authentication; a signature uses a private signing key and public verification. Neither automatically prevents replay or establishes an unrelated person's identity.
Answer: Not uniquely by itself. Both holders can compute valid MACs.
HMAC verification of exact synthetic bytes
import hashlib, hmac
key = b"DISPOSABLE-TEACHING-KEY-DO-NOT-REUSE"
message = b"task=42;action=complete"
tag = hmac.new(key, message, hashlib.sha256).digest()
def verify(received):
actual = hmac.new(key, received, hashlib.sha256).digest()
return hmac.compare_digest(tag, actual)
print("unchanged:", verify(message))
print("altered:", verify(b"task=43;action=complete"))
print("The hardcoded disposable key is only for this local demo, never real use.")
print("No replay prevention, key distribution or real identity system is provided.")
Checked output:
unchanged: True altered: False The hardcoded disposable key is only for this local demo, never real use. No replay prevention, key distribution or real identity system is provided.
11. Password storage and secret handling
Passwords need dedicated salted password-hashing schemes with current reviewed settings, not plain fast hashes or reversible storage. Never embed real secrets in source, URLs or logs.
Answer: No. Password guessing resistance requires an appropriate dedicated scheme and cost.
12. TLS, certificates and secure channels
TLS protects a properly authenticated transit channel. Certificate/name validation matters; channel security does not secure compromised endpoints or replace object permissions.
Answer: No. It protects a connection under its trust model, not every claim.
13. Input validation and SQL injection prevention
Validation constrains shape/meaning; parameterized queries separate values from query structure. They do not automatically enforce caller access or business rules.
Answer: No. Include a trusted authorization predicate/check separately.
Bound query data plus ownership predicate on synthetic SQLite
import sqlite3
connection = sqlite3.connect(":memory:")
try:
connection.execute("CREATE TABLE tasks(id INTEGER PRIMARY KEY, owner TEXT, title TEXT)")
connection.execute("INSERT INTO tasks VALUES (?, ?, ?)", (42, "Asha", "Revise TLS"))
def read(user, key):
# Real apps derive user from their trusted authenticated identity boundary.
return connection.execute("SELECT title FROM tasks WHERE id = ? AND owner = ?", (key, user)).fetchone()
print("owner:", read("Asha", 42))
print("other user:", read("Ravi", 42))
print("unexpected key text:", read("Asha", "not-an-integer-key"))
print("rows:", connection.execute("SELECT COUNT(*) FROM tasks").fetchone()[0])
finally:
connection.close()
print("Local synthetic query demo; no real authentication or persistent database.")
Checked output:
owner: ('Revise TLS',)
other user: None
unexpected key text: None
rows: 1
Local synthetic query demo; no real authentication or persistent database.
14. Output encoding, XSS and context
Encode output for its actual context; HTML text, attributes, JS and URLs need different handling. Validation alone does not make arbitrary output safe.
Answer: No. Context determines the proper defense.
15. CSRF, CORS and request origin
CSRF concerns unwanted authenticated effects; CORS controls browser cross-origin response access. Apply suitable token/origin/cookie controls to actual threat paths.
Answer: No. They address different mechanisms.
16. Networks, firewalls and segmentation
Network controls restrict paths and exposure but do not fix all application flaws. Segmentation and least-exposed services reduce impact under a threat model.
Answer: No. Address translation serves a different purpose.
17. Malware, phishing and human workflows
Deceptive messages, malicious software and unsafe approvals can defeat purely technical assumptions. Verify requests through trusted channels and keep systems/dependencies maintained.
Answer: No. Source binding and trusted confirmation matter.
18. Backups, availability and recovery tests
Backups need protection, restore testing and stated recovery objectives. Redundancy alone is not backup; retention and access restrictions matter.
Answer: No. Test actual recovery of the needed version/data.
19. Incident response and evidence
Prepare roles and contacts, detect/assess, contain, preserve evidence, remove cause, recover and learn. Steps can overlap; exact notification duties depend on current applicable rules.
Answer: No. Protect evidence and use authorized reporting channels.
Prepare -> detect/assess -> contain -> preserve + investigate evidence -> remove cause -> recover/test -> review and improve
20. Security testing and responsible disclosure
Test only systems within permission and scope. Document defensive findings, impact and reproducible evidence without unnecessary exploitation/disclosure.
Answer: No. Scope and authorization are separate.
21. Privacy purpose and data minimization
Privacy asks whether collection/use/sharing/retention is appropriate, not only whether data is encrypted. Define purpose and collect the minimum justified fields.
Answer: Yes. Unnecessary collection or retention can be inappropriate.
Purpose -> minimum needed fields -> limited access/use/sharing -> retention review -> safe deletion
22. Pseudonymization, anonymization and reidentification
Pseudonyms replace direct identifiers but linked/contextual data may still identify people. Anonymization claims need careful evaluation; hashing a name is not a universal guarantee.
Answer: No. Linkability and auxiliary information remain.
23. Retention, sharing and legal scope
Limit retention/access/sharing to stated purposes and verified obligations. Current laws, institutional rules and contracts depend on jurisdiction/context; these notes are not legal advice.
Answer: No. Consult applicable current sources and qualified advice where needed.
24. Defense in depth and secure lifecycle
Combine preventive, detective and recovery controls with threat-informed design, dependency updates, review and monitoring. One control's failure should not imply unlimited access.
Answer: No. Coverage, configuration, failure behavior and testing matter.
25. Exam and defensive checklist
Distinguish threat/vulnerability/control, authn/authz, hash/encryption/MAC/signature and security/privacy. Explain scope and limits with one concrete defensive example.
Answer: Correct objective, threat model, control, worked check and residual limits.
Security objective and control
| Objective | Example control | Limit |
|---|---|---|
| Confidentiality | Access rules + suitable encryption | Compromised endpoint/key remains a threat |
| Integrity | Permission + authenticated changes | Untrusted expected hashes do not prove origin |
| Availability | Protected backups + recovery | Backup success is not restore proof |
| Privacy | Purpose/minimization/retention | Encrypted unnecessary collection can still be wrong |
Cryptographic distinctions
| Mechanism | Purpose | Important limit |
|---|---|---|
| Encryption | Recover plaintext with authorized key | Does not replace permissions |
| Digest | One-way content fingerprint | Trusted expected value needed |
| MAC/HMAC | Shared-key message authentication | Both key holders can create tags; replay separate |
| Digital signature | Private signing/public verification | Identity depends on trusted key binding |
| Password hashing | Resist password guessing with dedicated scheme | Plain fast digest is unsuitable |
Application boundary defenses
| Mechanism | Addresses | Does not replace |
|---|---|---|
| Authentication | Claimed identity | Object authorization |
| Parameterized SQL | Values separate from syntax | Business permissions |
| Contextual output encoding | Data not executable markup/code | Every context with one generic escape |
| CORS | Browser cross-origin response access | CSRF/authentication |
| TLS | Authenticated transit channel | Trust in all content or endpoint hygiene |
Revision and defensive checklist
State assets, threat scenario, permission scope and residual risk. Distinguish identity from allowed action and data protection from justified use. Verify restore, actual access checks and expected failure behavior. Do not adopt teaching keys/digests as production credential systems.
Resources and sources
Current defensive guidance supports application controls, password handling and privacy concepts. Historical OWASP links from the original page are preserved as historical references, not the current ranking. No fixed legal deadline is inferred here.
Comments
Post a Comment