Cybersecurity Fundamentals

Weeks 1–2 — the human and the credential. Almost every incident begins here, which is why it is week one instead of an appendix.

1. Phishing, the door that is always open

   A phishing message asks for an action, not for information: open this, approve this, pay this. The tell is usually the consequence of doing nothing being urgent.

   The lesson

   Nearly every serious breach starts with one person clicking one link, and no firewall stops that. Phishing is a message that looks like it comes from somebody you trust — a bank, your college, your manager — and asks you to log in, open an attachment or pay an invoice. The tell is never the spelling; it is the pressure to act quickly and the fact that the request arrived at all.

   Four checks catch most of them: read the actual address, not the display name; hover a link before clicking and read the domain to the right of the last dot; treat any unexpected attachment as hostile; and when a message asks for money, a password or a code, confirm through a channel you already trust rather than the one in the message.

   The mistake is assuming you would never fall for one. Every phishing test in every company catches a third of the staff, including the security team, because the good ones arrive on a busy afternoon and look like work. Slow down on anything with an urgent request in it — that pause is the control.

   Plain textCopy

   Red flags:
     urgency ("act within 24 hours")
     a lookalike sender domain
     a link whose visible text and real target differ
     an unexpected attachment
     any request for a password, OTP or card details
   
   Verify out of band: call the person on a number YOU look up.
   Never enter credentials from a link in an email.

   Example A message claiming your salary account will be frozen in two hours works because urgency stops people checking the sender domain. Reading the domain and hovering over the link before clicking takes four seconds and defeats most of it.

   Practice Collect five real phishing examples from public awareness pages and write the tell that would have caught each one.

2. Passwords, MFA and why length beats symbols

   A long passphrase beats a short complex password, and reusing a password across sites is what turns one leaked database into ten compromised accounts.

   The lesson

   Length beats complexity. A four-word passphrase of twenty-odd characters is far harder to crack than eight characters with a symbol and a capital — and it is easier to remember. Attackers do not guess; they try billions of combinations per second against stolen databases, and every extra character multiplies the work.

   Never reuse a password between important accounts: one breach anywhere reveals that password, and attackers try it everywhere. Use a password manager so you only remember one, and turn on multi-factor authentication — the code on your phone after the password — on your mail and GitHub first. Mail is the skeleton key: password resets for everything else arrive there.

   The mistakes are a system everybody in a household knows, a password written in plain text on the desk, and MFA codes read out on a call to somebody who asked for them. A support agent will never ask for your one-time code; whoever does is attacking you.

   Plain textCopy

   Length beats symbols:  "purple-tiger-battery-lamp-7"  >  "P@ssw0rd!"
   Use a password manager. Never reuse a password across sites.
   Turn on MFA - an app or a hardware key, not SMS if you can avoid it.
   Breached site? Change the password AND everywhere it was reused.

   Example Credential stuffing — trying leaked username and password pairs on other sites — works entirely because of reuse. Multi-factor authentication breaks it, which is why enabling it everywhere is the highest-value hour a beginner can spend.

   Practice Turn on MFA on your own email and two other accounts, and install a password manager. Use a long passphrase for the master.

3. Attack surface: what you can see, you can defend

   Every service listening on a port is something an attacker can talk to. Shrinking that list is the most effective defensive work there is, and it is less glamorous than it sounds.

   The lesson

   Attack surface is everything an attacker can reach: open ports, web forms, old test pages, an admin panel, a Git repository with a key in it, an unattended laptop on a public network. You cannot defend what you have not listed, so the first exercise in any audit is making the list.

   Do it on your own project this week. Which endpoints are public? Which database is reachable from the internet? Which repository has ever contained a password or a key? Which accounts have admin rights and do all of them need them? Every answer that surprises you is a finding, and finding them yourself is the job.

   The mistake is a development server left running with a default password, months after the project it belonged to. Remove, close or protect — and write down what you removed, because the list is what you show in an interview.

   TerminalCopy

   # Run only on your OWN machine.
   ip=$(curl -s ifconfig.me)
   nmap -F "$ip"                       # common ports
   ss -tulpn                           # local listening services
   systemctl list-units --type=service --state=running
   
   Close what you do not need. Remove default accounts.
   Enable a firewall. Fewer open doors, smaller attack surface.

   Example A development server left running on port 8080 with no password is a breach waiting for a scanner. Scanners are automated and constant; nothing has to be targeted at you personally for this to be found.

   Practice List every service on your own machine that opens a port, and mark which ones you actually need.

Weeks 3–4 — ports, logs and the unglamorous controls. This is the actual day job of most security staff.

1. Networks, ports and what a firewall rule means

   An IP address identifies a machine and a port identifies a service on it. A firewall rule allows or denies traffic between addresses and ports, and reading one is a core skill.

   The lesson

   A network moves packets between addresses. An address identifies a machine; a port identifies a service on it — 22 for SSH, 80 and 443 for the web, 3306 and 5432 for databases. A service listening on a port is a door, and whether the door is reachable from the internet is the whole question.

   A firewall rule is one line of permission: allow, from an address range, to a port. Read them as sentences and they stop being scary. The rule you want is almost always "allow 443 from anywhere; allow 22 only from the office", and the one you do not want is "allow all to all", which is what a default cloud security group often gives you.

   The mistake is opening a database port "temporarily" to test locally and forgetting it. Databases belong behind the application server, never exposed; that single rule is behind a large share of breached small systems.

   TerminalCopy

   # Allow SSH, HTTP, HTTPS - drop everything else.
   sudo ufw default deny incoming
   sudo ufw allow 22/tcp
   sudo ufw allow 80,443/tcp
   sudo ufw enable
   sudo ufw status verbose
   
   # 22 SSH . 80 HTTP . 443 HTTPS . 3306 MySQL (NEVER expose to the internet)

   Example "Allow 443 from anywhere, deny everything else" is a rule you can explain. "Allow all" with a note saying review later is how test environments become production incidents.

   Practice Write the allow-and-deny list for a small office that needs web, mail and remote access — and nothing else.

2. Logs: reading the story of an incident

   A log is a timeline. Five hundred failed logins from one address followed by one success is a story; the same five hundred spread across a week and never succeeding is noise.

   The lesson

   Logs are the timeline of what happened, and an incident is normally reconstructed from three sources: the web server's access log, which shows every request, the application log, which shows what the code did, and the authentication log, which shows who signed in from where and how often they failed. Reading them in time order is the whole technique.

   Start from the thing you know — the time a customer reported the problem, an alert, a strange filename — and move outwards. Look for repetition (one address, hundreds of requests), for success after a run of failures (a password guessed), or for a request from a country nobody visits you from. grep, sort and uniq -c turn ten thousand lines into a shortlist.

   The mistake is trusting a dashboard summary and never opening the raw lines. Summaries are written by whoever configured them and rarely answer the question in front of you. The second mistake is deleting a log after an incident because the disk was full — export it first, then rotate.

   TerminalCopy

   # Failing logins, and where they come from:
   sudo grep "Failed password" /var/log/auth.log   | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
   
   sudo last -f /var/log/wtmp | head          # recent logins
   sudo journalctl -u ssh --since "1 hour ago"
   
   # Timeline: the first event, what changed, what was touched.

   Example Logs are shown in UTC, and reading a timestamp without converting it is the most common reason an investigation goes in the wrong direction for an hour.

   Practice Take a sample authentication log, find the burst, convert the timestamp, and write three sentences on what happened.

3. Patching, backups and the boring controls that work

   Unpatched software and untested backups cause more real damage than clever attacks. Both are boring, and both are what separates a defended system from a hopeful one.

   The lesson

   The unglamorous controls stop the attacks that actually happen: automatic updates on, backups that are tested by restoring one, least privilege so nobody has more access than the task needs, and disk or database encryption. None of them make an interesting demonstration, and all of them are in the list of top breaches every year.

   A backup is not a backup until you have restored from it and checked the data is usable. Automate it, keep one copy somewhere the main system cannot reach — because ransomware encrypts attached drives too — and put a date in your calendar to restore one for real.

   The mistake is a backup job that has been failing for months while the log line says it ran. Check the exit status and the file size, and restore once a quarter. Security is mostly maintenance, and maintenance is mostly noticing.

   TerminalCopy

   sudo apt update && sudo apt list --upgradable
   sudo apt upgrade -y
   
   # Backups: 3 copies, 2 media, 1 off-site  (3-2-1)
   # Test a RESTORE, not just a backup - an untested backup is only a hope.
   
   # The controls that actually stop incidents: patch, backup, MFA,
   # least privilege. Boring, and they work.

   Example A backup that has never been restored is not a backup. Restoring one file from last week, on purpose, once, is the only way to know.

   Practice Take a backup of something you care about, restore one file from it, and write down how long it took and what you would lose today.

Weeks 5–6 — legal practice, honest certificates and a write-up that gets you interviewed.

1. Labs and legal practice ranges

   Practising on a system you do not own is a criminal offence in India under the IT Act and equivalent laws everywhere else — no exceptions for curiosity or for a course. Deliberately built practice ranges exist precisely so you never need to.

   The lesson

   Practise where you are allowed to. Legally safe environments to learn on: TryHackMe and Hack The Box (guided and legal), OWASP Juice Shop and DVWA running on your own machine, and your own virtual machines. Read the rules of a capture-the-flag event before you start; they say exactly what is in scope.

   Never test a website you do not own or have written permission to test, even with a harmless automated scanner — that is a criminal offence in most countries regardless of intent, and in India it is a serious one. Universities and employers do give written permission for specific ranges and times; get it in writing, and stay inside it.

   The mistake is running a vulnerability scanner against a college portal, a friend's site or a company that has not asked you to. Curiosity is not a defence, and a fresher with a police complaint has no career to protect.

   Plain textCopy

   Practice only where you are ALLOWED to:
     TryHackMe . Hack The Box . PortSwigger Web Security Academy
     OWASP Juice Shop (run it locally) . your own VMs
   
   Never test a site you do not own or have written permission to test.
   Keep a lab notebook - that notebook becomes your portfolio.

   Example Free and low-cost ranges give you vulnerable machines to attack with permission, with scoreboards and community support. Every skill in this course can be practised on them, and none of it requires touching somebody else's system.

   Practice Create an account on one practice range, complete an introductory machine and save the walkthrough you wrote.

2. Two free certificates worth doing first

   Entry-level security certificates are useful for one reason: they force you through a syllabus in order and give a recruiter something to verify. They are not a substitute for the practice range work.

   The lesson

   Start with Google's free cybersecurity course for vocabulary and how companies actually work, and Cisco's Introduction to Cybersecurity for the networking basics. Both are free, both can be finished in a few weekends, and both give a certificate you can put on your resume honestly as foundational training.

   Then pick a direction rather than collecting badges: security operations (reading logs and alerts — the SOC analyst route, and the biggest fresher market), or application security (finding and fixing bugs in web applications). For either, add practice from a legal lab and one written-up finding of your own; that combination is what gets a fresher shortlisted.

   The mistake is buying an expensive course before reading a single job ad. Read ten fresher security postings this week, note what they name — Splunk, Wireshark, Burp Suite, the SOC, Excel — and let the requirements choose your next month of study.

   Plain textCopy

   Both free to start:
     1. Cisco "Introduction to Cybersecurity" (skillsforall) - fundamentals.
     2. TryHackMe "Pre Security" path - hands-on basics.
   
   Then pick a direction: blue team (SOC), GRC, or offensive security.
   Add ONE small home-lab write-up - certificates alone do not get interviews.

   Example Pick one foundational certificate covering network and security basics, and check the current syllabus against what this course covers before paying for anything at all.

   Practice Download the syllabus of one entry-level certificate and mark every objective you can already explain out loud.

3. Writing up a finding like a professional

   A finding has five parts: what the issue is, how it can be exploited, what the impact would be, how to fix it, and how urgent it is. The fix and the urgency are what the reader acts on.

   The lesson

   A security report is written for two people at once: the engineer who must fix it, and the manager who must decide how urgent it is. Structure it as title, summary, impact in business words, reproduction steps, evidence, and the fix. Write the impact in terms of what data or access is lost, not in jargon.

   Include the exact request and response, the version of the software, and the minimum steps to reproduce. Then calibrate the severity honestly — critical for remote code execution or data exposure, medium for something needing an authenticated user and unusual conditions — because a report that calls everything critical gets read as noise.

   The mistake is a screenshot with no steps, which cannot be reproduced or fixed, and the second is a fix without a re-test. Say what you checked after the fix, and you become the junior whose reports are trusted, which is how the interesting work starts coming to you.

   Plain textCopy

   Title:    Session cookie missing the Secure flag
   Risk:     Medium - the cookie can cross plain HTTP on a hostile network
   Evidence: the response headers, and the request showing http://
   Impact:   session theft on public Wi-Fi
   Fix:      set Secure; HttpOnly; SameSite=Lax
   Retest:   confirmed set after the change
   
   Risk + evidence + impact + fix + retest. No names, no drama.

   Example A report that says "SQL injection found" gets ignored. A report that names the parameter, the impact on customer data and the two-line code fix gets scheduled this sprint.

   Practice Write up one issue from a practice machine in that five-part format, with a screenshot, and publish it as a portfolio write-up.

Harden a server, recognise the common web flaws, and handle secrets and keys like a professional.

1. Hardening a Linux server

   Most breaches use a door somebody left open: a default password, an exposed database, an old package. Hardening is closing the obvious doors first, and it is measurable.

   The lesson

   Disable root login over SSH as well, and keep the SSH port and firewall on an allow list - the goal is fewer ways in, not a longer password.

   Write the changes down as a checklist. A hardening step you cannot repeat on the next server is a one-off, not a control.

   TerminalCopy

   # key-only SSH
   sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' \
     /etc/ssh/sshd_config
   sudo systemctl restart ssh
   
   # updates + firewall
   sudo apt update && sudo apt upgrade -y
   sudo ufw default deny incoming
   sudo ufw allow 22/tcp && sudo ufw allow 80,443/tcp
   sudo ufw enable
   
   # remove default accounts nobody uses
   sudo deluser --remove-home pi 2>/dev/null || true

   Example Disabling password login for SSH and allowing only keys removes the single most attacked door on the internet.

   Practice Harden one VM: key-only SSH, update packages, and enable the firewall - then list what you changed.

2. The OWASP Top 10, in plain words

   The Top 10 is a list of the mistakes that keep happening: broken access control, injection, weak authentication, misconfiguration, and more. Knowing the five that hit web apps covers most real findings.

   The lesson

   Injection is still alive in any query built by string-joining user input; parameterised queries and escaping are the fix, and reviewers look for them first.

   Misconfiguration - debug mode on, directory listing on, default credentials kept - is unglamorous and extremely common. Check the settings before hunting exotic bugs.

   Plain textCopy

   Checklist - the five that matter most:
   
   1. Broken access control  can you change an id in the URL and see others' data?
   2. Injection               is input concatenated into SQL or a shell command?
   3. Authentication          is there rate limiting on login? MFA? session timeouts?
   4. Misconfiguration        debug on? directory listing? default creds left?
   5. Sensitive data          secrets in the repo? stack traces shown to users?
   
   Fix order: 1 and 2 first - they are exploited the most.

   Example A page that shows /invoice/1042 and lets you open /invoice/1043 by changing the number is broken access control - the most common serious flaw.

   Practice Take one web app and check three things: can you change an ID and see someone else data, is input reflected into the page, are errors leaking stack traces.

3. Secrets, keys and password managers

   A secret in a Git repository is a secret that is already public. Keys, tokens and passwords belong in a manager or the environment, never in the code, and a committed key must be rotated, not deleted.

   The lesson

   A password manager is how a person keeps a different long password for every site; a secrets manager does the same for code. Reuse is the thing that turns one breach into ten.

   Add a scanner to the pipeline so a secret never lands in the first place, and treat the removal of one as an incident with a rotation, not a quiet edit.

   TerminalCopy

   # look for secrets before they ship
   grep -rniE 'aws_secret|api[_-]?key|password *=' --include='*.py' --include='*.js' .
   
   # if a key WAS committed:
   #   1. revoke it in the provider   (deleting the commit is not enough)
   #   2. issue a new one
   #   3. load it from the environment:  export API_KEY=...
   #   4. add a scanner (gitleaks / trufflehog) to CI

   Example An AWS key pasted into a repo is found by scanners within minutes; deleting the commit does not help because the history keeps it - the key must be revoked and replaced.

   Practice Search your own repositories for a key-like string and move anything found into an environment variable.

What to do during an incident, and how to turn the fundamentals into a first security job.

1. Incident response basics

   An incident is handled in a known order: prepare, detect, contain, eradicate, recover, learn. Skipping contain to go straight to the fix is how an attacker gets a second chance.

   The lesson

   A checklist written in calm times is what keeps a 2am response ordered; the goal in the first hour is to stop the spread and preserve evidence, not to fully understand the cause.

   The lesson comes at the end and changes something real - a rule, a training, a monitor. An incident review that produces no change is a story, not a response.

   Plain textCopy

   IR order:  Prepare -> Detect -> Contain -> Eradicate -> Recover -> Learn
   
   Suspected phished account - first hour:
     1. Contain   reset the password, revoke sessions, enable MFA
     2. Preserve  export the mailbox rules and the login log
     3. Eradicate check for forwarding rules and new OAuth apps
     4. Recover   restore access, watch logins for a week
     5. Learn     add an alert for new mailbox rules

   Example On a suspected compromise, isolate the machine from the network first - contain - then investigate, rather than pulling the power and losing the evidence in memory.

   Practice Write a one-page incident checklist for a suspected phished account: who to call, what to isolate, what to preserve.

2. Writing a finding like a professional

   A security finding a client will pay for has five parts: title, risk, evidence, impact and fix - in that order, in plain language, with the retest. No drama, no blame.

   The lesson

   Write for a busy non-security reader: the fix and the impact first, the technical detail in an appendix. A finding nobody acts on has protected nothing.

   Always include a retest step - "verify by loading /admin in a private window" - so the client can confirm the fix themselves, which is what closes the ticket.

   Plain textCopy

   Title:    Admin page reachable without authentication
   Risk:     High
   Evidence: GET /admin returns 200 and user data with no session cookie
   Impact:   Anyone can read every user record
   Fix:      enforce the role check on the server for the route, not the menu
   Retest:   load /admin in a private window -> expect 403
   
   Detail (appendix): the request, the response headers, the timestamp.

   Example Title: "Admin page reachable without login". Risk: High. Evidence: the request and response. Impact: full data access. Fix: enforce the role check server-side.

   Practice Turn one issue you found in a lab into a one-page finding in the five-part format.

3. The SOC analyst path and the interview

   The common first security job is a SOC analyst: watch alerts, triage, escalate. Get there with fundamentals, two certificates, a home lab and a clear story about one investigation.

   The lesson

   Know the day of a tier-1 analyst: alerts, false positives, escalation criteria, and clear notes on every ticket. The tools are learnable; the discipline is what they screen for.

   Be honest about what you have not done. Saying "I have done labs, not production incidents" is respected; pretending otherwise falls apart on the second question.

   Plain textCopy

   Tier-1 SOC day:
     - triage the alert queue against playbooks
     - close false positives with a reason
     - escalate real ones with evidence and a timeline
   
   Your interview story:
     "I saw 200 failed logins from one IP in the lab logs,
      confirmed it was brute force, blocked the IP, and wrote it up."
   
   Ask them: "what does a good escalation look like to you?"

   Example In an interview, "I saw repeated failed logins from one IP, isolated the source and blocked it" beats a list of tools you have read about.

   Practice Prepare one investigation story in the five-part shape and one question to ask the SOC team.