Data Structures and Algorithms using C

1. Information security protects hardware, software, and data—the full system “assets” spectrum.
2. Information assurance emphasizes ensuring reliable, timely access to trustworthy information (assurance

focus beyond pure protection).

3. CIA triad is foundational: Confidentiality, Integrity, Availability—every control maps to one or more.
4. Confidentiality prevents unauthorized disclosure; breaches include eavesdropping, data leakage.
5. Integrity prevents unauthorized or accidental modification; checksums, MACs, signatures support it.
6. Availability ensures timely, reliable access for authorized users; DoS and outages target this pillar.
7. Data often exceeds hardware in value because it is unique and costly/impossible to recreate.
8. Asset = anything of value to the organization (data, systems, people, reputation, IP).
9. Threat = potential cause of unwanted incident; can be natural, accidental, or malicious.
10. Vulnerability = weakness that can be exploited to harm an asset.
11. Attack = attempt to exploit a vulnerability against an asset.
12. Exploit = specific method/technique to take advantage of a vulnerability.
13. Control/Countermeasure = measure that reduces vulnerability, threat likelihood, or impact.
14. Core relationship: a Threat exploits a Vulnerability to attack an Asset; Controls reduce the Vulnerability.
15. Interception (confidentiality breach) = unauthorized viewing/sniffing of data in transit or at rest.
16. Modification (integrity breach) = unauthorized changes (e.g., altering records/transactions).
17. Interruption (availability breach) = preventing access (e.g., DoS, power outage, link failure).
18. Fabrication = creation/injection of counterfeit objects or data (e.g., bogus log entries).
19. Impact categorization informs where to invest: high-impact assets deserve stronger controls.
20. FIPS 199 standardizes categorization of information/system impact levels: Low, Moderate, High.
21. FIPS 199 applies impact per CIA dimension independently (C-I-A can have different levels).
22. Organizational mission, legal obligations, and user safety drive impact ratings.
23. Example workflow: identify information types → rate C, I, A impacts → derive overall system category.
24. Smart-home case study (module): personal data, device states, control commands—categorize each by

CIA.

25. Threat actors include cybercriminals, hacktivists, state-sponsored/APTs, insiders, and hobbyists.

26. Cybercriminals are financially motivated (credential theft, ransomware, fraud).

27. Hacktivists pursue ideological goals (defacements, leaks, DDoS for awareness).

28. State-sponsored groups conduct espionage/sabotage with persistence and resources (APTs).

29. Insiders may be malicious or negligent; they bypass perimeter and know internal processes.

30. Hobbyists/script kiddies leverage toolkits; capability varies but volume creates risk.

31. Social engineering exploits human trust; technologies can’t fully prevent it.

32. Phishing/vishing/smishing are common social-engineering modalities.

33. Malware classes: virus, worm, trojan, rootkit, spyware, ransomware, adware.

34. Rootkits aim for stealth and privilege (kernel/firmware/boot-level persistence).

35. Attack surface expands with complexity, interconnections, and unknown perimeters.

36. Security posture depends on layered defenses across physical, personnel, operations, network,

information.

37. Defense-in-depth = multiple, complementary controls so one failure doesn’t cause compromise.
38. Reference monitor properties for security enforcement components: always invoked, tamperproof,

small/verifiable.

39. Least privilege: give subjects only the access necessary to perform tasks, no more.

40. Separation of duties: split critical tasks so one person cannot commit undetected fraud.

41. Need-to-know: restrict access to data strictly to those requiring it for duties.

42. Fail-safe defaults: deny by default; permit only explicitly authorized actions.

43. Open design: rely on secrecy of keys not algorithms (Kerckhoffs’ principle).

44. Complete mediation: every access must be checked; no caching of authorization that can be bypassed.

45. Auditability: log security-relevant events; necessary for accountability and forensics.

46. Security vs usability trade-offs must be explicit; excessive friction leads to insecure workarounds.

47. Policy → standards → procedures → guidelines: governance hierarchy for coherent security practice.

48. Asset inventory is prerequisite to protection—“you can’t protect what you don’t know.”

49. Data classification schemes must be comprehensive and mutually exclusive.

50. Owners classify data; custodians enforce controls; users comply with handling rules.

51. Handling rules cover storage, distribution, portability, and destruction for each classification.

52. Risk thinking starts in Module 1: total risk combines likelihood and impact; later quantified in Module

54. Natural threats: fire, flood, earthquake; require DR/BC planning and insurance.

55. Human benign threats: error, misconfiguration; training and change control mitigate.

56. Human malicious threats: theft, sabotage, extortion; need technical and administrative controls.

57. Passive attacks (sniffing) observe; active attacks (DoS, injection) alter state or availability.

58. 1969 ARPANET origins: early needs included user identification and connection traceability.

59. 1988 Morris Worm catalyzed formal incident response; CERT/CC established.

60. Security incidents increased with internet scale; attacker motives shifted from curiosity to profit.

61. Zero-day market: researchers, governments, and criminals trade exploits; raises ethical/policy questions.

62. CVE growth trends illustrate expanding vulnerability landscape (need for patch/vuln management).

63. Security categorization (FIPS 199) informs control selection and certification/accreditation scope.

High.

66. Example: public website may be Low confidentiality, Moderate integrity, High availability.
67. Example: smart-home locks—High integrity/availability of control commands; Moderate confidentiality

of config.

68. Administrative controls: policies, training, background checks, sanctions.

69. Technical controls: access control, encryption, network filtering, EDR, logging.

70. Physical controls: locks, guards, cameras, cages, power/UPS, environmental sensors.

71. Preventive controls aim to stop incidents (e.g., firewall default-deny).

72. Detective controls discover incidents (e.g., IDS alerts, SIEM correlation).

73. Corrective controls restore normal operations (e.g., backups, patches, DR).

74. Deterrent controls discourage attempts (e.g., warnings, visible cameras).

75. Compensating controls provide alternative measures when primary controls aren’t feasible.

76. Security architecture aligns controls to data flows and trust boundaries.

77. Trust boundary violations (e.g., direct DB exposure to internet) are architectural vulnerabilities.

78. Attack trees help reason about attacker goals and required sub-steps.

79. Threat modeling (STRIDE, etc.) systematically enumerates threats by component.

80. Asset criticality depends on confidentiality needs, integrity sensitivity, and availability demands.

81. Security testing spectrum: vulnerability scanning, penetration testing, red teaming, purple teaming.

82. Patch management cadence must balance risk of exploitation vs operational impact of change.

83. Configuration management (baselines, hardening guides) reduces misconfigurations.

84. Principle of minimal attack surface: remove unused services, close ports, uninstall defaults.

85. Data lifecycle: create, store, use, share, archive, destroy—controls at each phase differ.

86. Secure destruction (crypto-erase/shredding) is essential for decommissioned media.

87. Logging scope should include auth events, admin actions, security alerts, and data access.

88. Time synchronization (NTP) supports coherent logs and forensic timelines.

89. Incident response basics: detect, analyze, contain, eradicate, recover, lessons learned.

90. Business continuity focuses on continued operations; disaster recovery on restoring IT services.

91. Legal/regulatory drivers (privacy laws, contractual duties) influence controls selection.

92. Third-party risk: vendors/partners add attack paths; require assessments and controls.

threats, vulnerabilities, and controls succinctly.

Module 2 – Risk Analysis (100 Key Points for Exam-Level Understanding)

1. Core Definitions
2. Risk is the potential for loss or harm when a threat exploits a vulnerability.
3. Risk = Threat × Vulnerability × Impact.
4. Asset is anything valuable to an organization—data, systems, people, reputation.
5. Threat is any event or actor with potential to cause harm.
6. Vulnerability is a weakness that allows a threat to succeed.
7. Impact is the consequence or damage resulting from a successful attack.
8. Risk analysis is the process of identifying, estimating, and prioritizing risks.
9. Risk management is selecting and applying controls to reduce risks to acceptable levels.
10. Inherent risk is the natural level of risk without any controls applied.
11. Residual risk is the risk remaining after controls are implemented.
12. Risk Analysis Steps
13. Step 1: Identify assets.
14. Step 2: Identify threats to those assets.
15. Step 3: Identify vulnerabilities.
16. Step 4: Determine impact if threat exploits vulnerability.
17. Step 5: Determine likelihood of occurrence.
18. Step 6: Calculate overall risk.
19. Step 7: Identify and evaluate risk controls.
20. Step 8: Select appropriate response (mitigate, transfer, accept, avoid).
21. Step 9: Document and communicate risk.
22. Step 10: Continuously monitor and re-evaluate.
23. Asset Identification
24. Assets include data, hardware, software, personnel, physical infrastructure.
25. Data is usually the most critical asset.
26. Each asset must have an owner responsible for its protection.
27. Asset value can be financial, operational, legal, or reputational.
28. Critical assets must be prioritized over low-impact assets.
29. Threat Identification
30. Threats can be natural (earthquake), accidental (misconfiguration), or intentional (hacker).
31. Identify both internal and external threats.
32. Threat sources include employees, competitors, nation states, criminals.
33. Threat events are specific actions like DDoS, phishing, fire.
34. Threat likelihood must be measured (High, Medium, Low or numerical).
35. Vulnerability Assessment
36. Vulnerabilities can be technical (unpatched systems), physical (unlocked doors), or administrative (no

policies).

32. Vulnerabilities are discovered through scanning, auditing, or testing.

33. Zero-day vulnerabilities are unknown to vendors and have no patches.

34. CVSS (Common Vulnerability Scoring System) is used to rank vulnerabilities.

35. The higher the vulnerability severity, the higher the risk.

36. Impact (Loss) Assessment

37. Impact is measured in terms of financial loss, legal consequences, reputational damage, safety risks.

38. Impact = Asset Value × Exposure Factor.

39. Exposure Factor = percentage of asset lost in a single incident.

40. Single Loss Expectancy (SLE) = Asset Value × Exposure Factor.

41. Impact can be tangible (money) or intangible (public trust).

42. Likelihood & Probability

43. Likelihood = how often a threat is expected to occur.

44. Annual Rate of Occurrence (ARO) = estimated number of times per year a threat occurs.

45. ARO can be based on historical data or expert judgment.

46. Likelihood may be qualitative (High/Medium/Low) or quantitative (0.1, 1, 10).

47. The more exposed a system is, the higher the likelihood.

48. Risk Calculation

49. Annualized Loss Expectancy (ALE) = SLE × ARO.

50. ALE estimates expected yearly financial loss due to a risk.

51. If ARO = 0, ALE = 0 (risk is negligible).

52. Total risk accumulates for all identified threats.

53. Risks are ranked from highest to lowest to prioritize mitigation.

54. Risk Treatment Strategies

55. Mitigate (reduce risk using security controls).

56. Transfer (shift risk to third party, e.g., insurance).

57. Avoid (stop performing risky activity).

58. Accept (acknowledge and tolerate risk if low or unavoidable).

59. Different risks may require different strategies.

60. Types of Controls

61. Preventive controls stop incidents before they happen (firewalls, encryption).

62. Detective controls identify incidents after they happen (IDS, logs).

63. Corrective controls recover systems after incidents (backups, incident response).

Module 3 – Cryptography 100 Key Points (High-Difficulty, Exam-Focused, No Repetition, No Explanations Added unless needed for precision) No citations, as you requested.

1. Foundations of Cryptography

2. Cryptography is the science of securing information through mathematical techniques.

3. Cryptanalysis is the study of breaking cryptographic systems.

4. Cryptology = Cryptography + Cryptanalysis.

5. Purpose of cryptography: confidentiality, integrity, authentication, non-repudiation.

6. Kerckhoffs's Principle: security must depend only on secrecy of the key, not the algorithm.

7. Plaintext = original readable message.

8. Ciphertext = scrambled form of plaintext.

9. Encryption transforms plaintext into ciphertext using a key.

10. Decryption transforms ciphertext back to plaintext.

11. Keyspace is the total number of possible keys.

12. Symmetric Key Cryptography

13. Symmetric encryption uses the same key for encryption and decryption.

14. Major issue: secure key distribution.

15. Key count in symmetric systems = n(n-1)/2 for n users.

16. Block ciphers process fixed-size blocks of data.

17. Stream ciphers process data bit-by-bit or byte-by-byte.

18. DES: 64-bit block size, 56-bit key, 16 rounds, Feistel structure.

19. 3DES = Encrypt-Decrypt-Encrypt using DES, key sizes 112 or 168 bits.

20. AES: block size 128 bits, key sizes 128/192/256 bits.

21. AES rounds: 10 for 128-bit, 12 for 192-bit, 14 for 256-bit keys.

22. AES steps: SubBytes, ShiftRows, MixColumns, AddRoundKey.

23. Block Cipher Modes

24. ECB (Electronic Codebook): same plaintext = same ciphertext.

25. CBC (Cipher Block Chaining): each block depends on previous block.

26. CFB (Cipher Feedback): converts block cipher into a stream cipher.

27. OFB (Output Feedback): similar to CFB but more error-resistant.

28. CTR (Counter Mode): transforms block cipher into parallelizable stream cipher.

29. IV (Initialization Vector): required for CBC, CFB, OFB, CTR.

30. IV must be unique and unpredictable.

31. ECB must never be used for sensitive data.

32. Padding schemes like PKCS#7 handle non-exact block-size plaintext.

Module 4 – Authentication, Passwords, Access Control 100 Advanced, Exam-Level Points (No repetitions, no filler, no sources attached)

1. Foundations of Authentication & Identity

2. Authentication = verifying identity of a user or system.

3. Identification = claiming an identity (e.g., entering a username).

4. Authorization = deciding what an authenticated user is allowed to do.

5. Accounting (AAA model) = logging actions performed after authentication.

6. Authentication factors: something you know, have, are.

7. Strong authentication uses at least two different factors.

8. Re-authentication is required for critical actions (bank transfers, sudo in Linux).

9. Session tokens/cookies maintain authentication state in web applications.

10. Kerberos uses tickets for mutual authentication over untrusted networks.

11. Mutual authentication verifies both client and server (seen in Kerberos, TLS).

12. Types of Authentication Factors

13. Something you know: password, PIN, answer to security question.

14. Something you have: smart card, token, phone OTP, hardware key (YubiKey).

15. Something you are: biometrics (fingerprint, face, iris).

16. Multi-factor authentication succeeds only when factors come from different categories.

17. Two passwords do not count as multi-factor authentication.

18. Password-Based Authentication

19. Passwords are the most widely used authentication method.

20. Good password policies enforce minimum length + complexity + history.

21. Password aging forces periodic change (e.g., chage command).

22. Linux stores hashed passwords in /etc/shadow, not /etc/passwd.

23. /etc/passwd retains username, UID, GID, home directory, shell.

24. Password hashing uses one-way functions.

25. Salt is added to prevent identical hashes for identical passwords.

26. Pepper is a site-wide secret added to all passwords before hashing.

27. Shadow file access is restricted to root.

28. Never store plaintext passwords.

29. Password Hashing Algorithms

30. MD5 and SHA-1 are insecure for password hashing.

31. bcrypt adds salt and uses multiple rounds.

Module 6 – Network Security (100 Hard-Level Points)

1. Basics of Network Security

2. Network security is the protection of data during transmission and the protection of networked systems.

3. Security goals in networking still map to CIA: confidentiality, integrity, availability.

4. Data-in-transit refers to data moving across communication channels.

5. Data-at-rest refers to stored data on physical or cloud systems.

6. Attack surface increases as network complexity, devices, and exposure increase.

7. Network Attacker Capabilities

8. An attacker on the same LAN can sniff unencrypted traffic using tools like Wireshark/tcpdump.

9. ARP spoofing enables an attacker to redirect network traffic to their system (MITM).

10. DNS spoofing poisons DNS cache to redirect users to malicious websites.

11. Port scanning (e.g. nmap) identifies open ports/services on target hosts.

12. Banner grabbing retrieves service versions to identify possible exploits.

13. Ping sweeps identify live hosts using ICMP echo requests.

14. DoS (Denial of Service) makes services unavailable by exhausting resources.

15. DDoS uses distributed systems or botnets to flood target with traffic.

16. SYN flood attack sends many SYN packets but never completes TCP handshake.

17. Man-in-the-Middle attack intercepts communication between two systems silently.

18. Firewalls and Packet Filtering

19. Firewalls enforce network traffic rules at network boundaries.

20. Stateless packet filters inspect only headers of each packet.

21. Stateless firewalls cannot track TCP session states.

22. Stateful firewalls track connection states (NEW, ESTABLISHED, RELATED).

23. Default firewall rule principle: deny all, allow specific.

24. In iptables, INPUT chain handles traffic to local system.

25. OUTPUT chain handles traffic leaving local system.

26. FORWARD chain handles traffic routed through the system (used in proxy/gateway).

27. NAT table is responsible for address translation (source NAT/destination NAT).

28. iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE hides internal IPs.

29. Secure Proxy Lab Concepts