Foundations of Cybersecurity
The vocabulary, networking concepts, and threat-model thinking that every later module assumes you already have. If you can already explain the CIA triad, OSI model, and symmetric vs. asymmetric encryption in your sleep, skim this and jump to Part 2.
CIA Triad & Core Concepts
Every control you will ever audit exists to protect one or more of three properties. When you write a finding later (Part 8), you should be able to say which of these it threatens — it sharpens both your analysis and your recommendation.
Confidentiality
Information is disclosed only to those authorised to see it. Breached by data leaks, weak access control, unencrypted data, shoulder-surfing.
Integrity
Information and systems are accurate and unaltered except by authorised action. Breached by tampering, unauthorised edits, malware, faulty interfaces between systems.
Availability
Authorised users can access information and systems when needed. Breached by DDoS, ransomware, hardware failure, poor capacity planning, absent DR.
Two more concepts you'll use constantly alongside CIA:
| Concept | Definition | Audit-relevant example |
|---|---|---|
| Authentication | Proving you are who you claim to be | Is MFA enforced for admin logins to the e-governance portal? |
| Authorisation | Being permitted to do a specific action once authenticated | Does a data-entry clerk's account have database admin rights it doesn't need? |
| Non-repudiation | An action cannot be credibly denied after the fact | Are financial transaction approvals logged with a verifiable user identity and timestamp? |
| Accountability | Actions can be traced to the responsible individual or system | Are audit logs for privileged access retained and protected from tampering? |
Threats, Vulnerabilities & Risk
These three words get used loosely in conversation. In an audit finding, precision matters — auditees will push back if you conflate them.
Threat
A potential cause of an unwanted incident — an actor or event that could cause harm. Example: a ransomware gang targeting healthcare.
Vulnerability
A weakness that a threat can exploit. Example: an unpatched, internet-facing server.
Risk
The likelihood of a threat exploiting a vulnerability, combined with the impact if it does. Risk ≈ Likelihood × Impact, moderated by existing controls.
Threat actor categories
| Actor | Typical motive | Typical capability |
|---|---|---|
| Nation-state / APT groups | Espionage, sabotage, strategic disruption | Very high — custom malware, zero-days, long dwell times |
| Cybercriminal groups | Financial gain (ransomware, fraud) | High — ransomware-as-a-service, banking trojans |
| Hacktivists | Ideological — defacement, disruption, leaks | Moderate — DDoS, website defacement, doxxing |
| Malicious insiders | Grievance, financial gain, coercion | Variable, but high access by default |
| Script kiddies / opportunists | Curiosity, low-level disruption | Low — automated scanners, public exploit kits |
Most real-world breaches in organisations exploit basic failures — default passwords, unpatched systems, missing MFA — not nation-state zero-days. Weight your audit programme accordingly.
Networking Fundamentals for Auditors
You don't need to configure a router, but you do need to read a network diagram and understand what an auditee means when they say "it's behind the firewall."
The OSI model (simplified for audit purposes)
| Layer | Name | What lives here | Audit relevance |
|---|---|---|---|
| 7 | Application | HTTP, DNS, the actual software | Application security audit (Part 4.5) |
| 4 | Transport | TCP, UDP, ports | Which ports are open — firewall rule review |
| 3 | Network | IP addressing, routing | Network segmentation, VLANs (Part 4.2) |
| 2 | Data Link | MAC addresses, switches | Physical/logical access to network gear |
| 1 | Physical | Cabling, Wi-Fi signal | Physical security audit (Part 4.10) |
Layers 5–6 (Session, Presentation) are omitted here as they rarely come up directly in audit conversation.
Ports & protocols you'll see constantly
| Port | Protocol | Use | Auditor's question |
|---|---|---|---|
| 22 | SSH | Encrypted remote admin (Linux) | Is it exposed to the internet? Key-based or password auth? |
| 80 / 443 | HTTP / HTTPS | Web traffic | Is port 80 still open when 443 (encrypted) should be enforced? |
| 3389 | RDP | Windows remote desktop | Internet-exposed RDP is one of the most common ransomware entry points — flag immediately |
| 21 | FTP | File transfer (unencrypted) | Is sensitive data transferred over plaintext FTP? |
| 445 | SMB | Windows file sharing | Is SMBv1 still enabled? (Known ransomware vector — EternalBlue) |
| 53 | DNS | Name resolution | Is DNS traffic monitored/filtered for malicious domains? |
| 502 | Modbus | OT/ICS protocol | Unauthenticated by design — never expose beyond the OT network (see Part 5) |
If the entity can't produce an up-to-date network diagram, that is itself a finding — it usually means no one has full visibility of the attack surface.
Operating Systems & Architecture Basics
Most organisation IT environments run a mix of Windows Server (Active Directory, file/print, line-of-business apps) and Linux (web servers, databases, increasingly cloud workloads). You need enough familiarity to ask informed questions, not to administer either.
Active Directory (AD) is the backbone of most organisation Windows networks — it centralises user accounts, group policy, and authentication. Key audit questions: How many Domain Admin accounts exist, and are they used for daily work (they shouldn't be)? Is Group Policy enforcing password complexity and screen-lock? Are service accounts using least-privilege?
Linux underpins most public-facing web servers and an increasing share of cloud workloads. Key audit questions: Is root login over SSH disabled? Are packages patched via a managed process, or ad hoc? Is sudo access logged and limited to named individuals (not a shared root password)?
Most applications you'll audit follow a 3-tier architecture: a presentation tier (web server), a logic tier (application server), and a data tier (database server) — see the diagram above. Each tier is a separate attack surface and should be on a separate network segment with its own access controls.
Cryptography Basics
You will repeatedly ask "is this encrypted, and how?" Know enough to evaluate the answer.
Symmetric Encryption
One key encrypts and decrypts. Fast — used for bulk data (e.g. AES-256 encrypting a database at rest). The hard problem is securely sharing/storing that one key.
Asymmetric Encryption
A public key encrypts, a private key decrypts (or vice versa for signing). Slower — used to establish trust and exchange symmetric keys (e.g. RSA, TLS handshakes).
Hashing
One-way transformation producing a fixed-length fingerprint. Used to store passwords (never store plaintext passwords) and verify file integrity. SHA-256 is the modern standard; MD5 and SHA-1 are broken — flag their use.
Digital Certificates & PKI
A Certificate Authority vouches that a public key belongs to a named entity. This is what makes the padlock in a browser meaningful. Audit: are certificates from a trusted CA, current (not expired/self-signed in production), and using modern TLS versions (1.2+)?
# Check what TLS version and cipher a organisation web portal is serving $ openssl s_client -connect example.gov.in:443 -tls1_2 < /dev/null # Look for: Protocol version (avoid TLS 1.0/1.1), and a valid, non-expired certificate chain
Organisation Threat Landscape
Three documented applicable incidents illustrate why this manual treats organisation systems as high-value targets, not low-priority ones:
On 23 November 2022, ransomware disrupted AIIMS Delhi's digital operations; roughly 5 of 100 physical servers were breached. Patient registration, admission, billing, and discharge had to revert to manual processes for about a week, with full e-Hospital restoration taking around two weeks. Attackers reportedly demanded approximately ₹200 crore in cryptocurrency, and data on an estimated 3–4 crore patients — including VIPs — was feared compromised. Delhi Police filed cases citing cyber-terrorism and extortion.
Audit lesson: Segmentation and backup integrity (Part 4.9) would have limited both the spread and the recovery time. Critical public services should never depend entirely on a digital system with no manual fallback procedure.
Malware (later identified as DTrack, linked to the Lazarus Group) was found on an internet-connected administrative network PC at Kudankulam. NPCIL confirmed the infection but stated the plant's critical control systems were isolated from this administrative network and unaffected. official incident-response service had flagged the issue on 4 September 2019; it was publicly confirmed by NPCIL in late October.
Audit lesson: This is the textbook argument for OT/IT network segmentation (Part 5.5) — the isolation NPCIL described is exactly what you must verify, not assume, in every OT audit.
Attackers (suspected Lazarus Group) compromised Cosmos Bank's ATM switch server and proxy SWIFT system, withdrawing roughly ₹78 crore via ATMs in 28 countries plus ₹2.5 crore domestically on 11 August, and fraudulently transferring ₹13.92 crore via SWIFT on 13 August — about ₹94 crore in total. Only a fraction was later recovered.
Audit lesson: Payment switch and SWIFT-adjacent systems need their own hardened, monitored, and tightly segmented environment — a recurring theme across this manual's IT audit domains.
None of these required a brand-new zero-day to start. Each involved a system that was more exposed, less segmented, or less monitored than its sensitivity warranted. That is precisely what an audit programme exists to catch before an attacker does.
Knowledge Check
Eight questions. You need 80%+ to be considered ready for Part 2, but you can retake this as many times as you like.