My progress
Menu

Level 6 · Cloud Computing, DevOps and Cybersecurity · Course 6.4 Cybersecurity

Module 80: Security Assessment

Goal: bring the whole level together: model the threats to your CRM, review it for vulnerabilities, understand how authorised testing works, respond to security incidents, and recover fully. Then complete the Level 6 final project.

You'll need: everything from Modules 63 to 79: your deployed CRM, its pipeline and operations guide, and your Project D notes (risk register, access review, web and network review, secrets inventory, privacy notes).

Lessons

  1. 1Threat modelling15–25 minutes✓
  2. 2Vulnerability review15–25 minutes✓
  3. 3Authorised testing15–25 minutes✓
  4. 4Security incidents15–25 minutes✓
  5. 5Recovery15–25 minutes✓

🛠️Module practice: Project D, an application security review

Bring parts 1 to 7 together into one Application Security Review for your CRM:

  1. The threat model (data-flow diagram, STRIDE table) and updated risk register.
  2. security-review.md: every finding with severity, fix and re-test status; no open critical or high findings.
  3. A scope and rules-of-engagement document, your own grey-box test results, and a published security.txt.
  4. A security incident checklist and a tabletop exercise write-up.
  5. A timed recovery drill.

🛠️Level 6 final project: Deploy a Production-Ready Application

You now have everything you need for the Level 6 project (15 to 25 hours). Put your Level 5 CRM on a server, with:

  1. SSH keys and users: key-only SSH, no root login, a named admin user and a deploy user (Module 64).
  2. A firewall: default-deny host and cloud firewalls; only SSH, HTTP and HTTPS open, checked from outside (Modules 66, 76).
  3. Containers and storage: the API in a slim, non-root container; data in volumes or managed services; uploads in private storage (Modules 68, 69).
  4. A reverse proxy and HTTPS: Nginx in front, Let's Encrypt with automatic renewal, HSTS, security headers (Modules 66, 75).
  5. Secrets: none in Git or images; env files with tight permissions or a secrets manager; a secret inventory (Module 77).
  6. CI/CD with tests: every pull request built and tested with a real database; branch protection; images tagged by commit (Module 71).
  7. A staging release: deployed to staging and smoke-tested before an approved production release (Modules 70, 71).
  8. Logs and alerts: structured logs without secrets, uptime monitoring, and tested alerts with runbooks (Module 72).
  9. Access controls: roles and object-level checks proven by tests; MFA for admins (Module 74).
  10. An OWASP review: your security review with no open critical or high findings (Modules 75, 80).
  11. Data-protection notes: data inventory, notice and consent, retention and rights (Module 79).
  12. Backup and restore: automated, encrypted, off-site backups and a timed restore (Module 72).
  13. A rollback test: a deliberate bad deploy rolled back with your workflow, timed (Modules 70, 71).
  14. An operations guide: how to deploy, roll back, restore, rotate secrets, add and remove users, and where everything is.
  15. An incident checklist: for outages and security incidents, including reporting duties (Modules 72, 80).

How it's assessed: Linux 15%, cloud and containers 20%, CI/CD and monitoring 15%, security and privacy 25%, and this project 25%. To pass you need 70%, and you must show working HTTPS, access controls that refuse what they should, a successful deployment check and a restore. A critical security failure must be fixed whatever the score. Passing shows you can deploy and operate an application carefully; it doesn't certify that any real application is secure. Keep reviewing.

✅Module check

Explain in a few sentences, in your own words:

How do you assess an application's security and recover from a security incident?

Show a good answer

A good answer mentions: threat modelling with a data-flow diagram, trust boundaries and STRIDE, feeding a risk register; planned vulnerability reviews across configuration, code, access, dependencies, secrets, privacy and operations, with severities, fixes, re-tests and regression tests; testing only with written permission, scope and rules of engagement, and responsible disclosure; an incident process that contains, preserves evidence, eradicates and reports (CERT-In within six hours, the Data Protection Board and affected people for personal data breaches); and recovery by rebuilding from known-good sources, rotating every exposed secret, restoring clean data, patching the cause and learning from the review, proven by drills.

📝Module quiz

10 questions · 10 marks each · 100 marks in all · pass mark 70% · retry as often as you like ·

1. What does the S in STRIDE stand for?

Why each option is right or wrong

  • “Security” (Incorrect): Security is the overall goal; STRIDE's S names a specific threat, spoofing.
  • “SQL injection” (Incorrect): SQL injection is a real threat, but it fits under tampering and disclosure, not the S.
  • “Session hijacking” (Incorrect): Hijacking a session is one way to spoof someone, but the S stands for spoofing itself.
  • “Spoofing” is correct.

    STRIDE is a checklist of six threat types: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privilege. Spoofing means pretending to be someone or something else, such as signing in with stolen credentials or faking an email sender.

    • Defence: strong authentication, such as passwords plus a second factor.
    • Use STRIDE: go through each letter for each part of your data flow.

📖 Revise: Lesson 1: Threat modelling

Question ID module-80-q1 · Report a mistake in this question
2. When is threat modelling most useful?

Why each option is right or wrong

  • “Only after a breach, to work out what went wrong” (Incorrect): That's incident review. Threat modelling aims to prevent the breach.
  • “Once, at the very end, just before the app launches” (Incorrect): By then designs are fixed and expensive to change; earlier is better.
  • “Only for large companies with a dedicated security team” (Incorrect): Small teams benefit too; a short session on a diagram is enough.
  • “During design, and again for significant changes” is correct.

    Threat modelling helps most before decisions are fixed in code, when changing the plan is cheap. It's worth repeating whenever something significant changes, such as adding payments, a new integration, or file uploads.

    • Keep it light: an hour with a diagram and STRIDE is a good start.
    • Store it: with the project, so it can be updated.

📖 Revise: Lesson 1: Threat modelling

Question ID module-80-q2 · Report a mistake in this question
3. What should happen to a critical finding?

Why each option is right or wrong

  • “Add it to the backlog and fix it in the next quarterly release” (Incorrect): Waiting months leaves a serious weakness open to attackers.
  • “Hide it from the team until a fix is ready to avoid panic” (Incorrect): The people who need to fix it must know; secrecy delays the fix.
  • “Mark it as accepted risk so that the release can go ahead” (Incorrect): Accepting a critical risk needs a strong reason and an owner's sign-off, not a default.
  • “Fix it before other work, re-test it and add a test” is correct.

    A critical finding is a serious, exploitable weakness. It jumps the queue: fix it, confirm the fix works by re-testing, and add an automated test so the same mistake is caught if it ever comes back.

    • Track it: record what was found, fixed and when.
    • Check siblings: the same mistake may exist elsewhere in the code.

📖 Revise: Lesson 2: Vulnerability review

Question ID module-80-q3 · Report a mistake in this question
4. Why add a test for each fixed vulnerability?

Why each option is right or wrong

  • “Tests make the fix run faster in production” (Incorrect): Tests check behaviour; they don't change production speed.
  • “Security scanners need a test before they'll scan the code” (Incorrect): Scanners don't depend on your tests; tests are for catching regressions.
  • “A test is legally required to close each vulnerability report” (Incorrect): It's good practice, not a general legal rule.
  • “So it can't return unnoticed later” is correct.

    Code changes all the time, and a later edit, merge or AI rewrite can quietly undo a fix. A test that tries the old attack fails straight away if the weakness returns, so you find out in CI rather than from an attacker.

    • Example: a test that user A can't read user B's enquiry.
    • Name it clearly: so others know why it exists.

📖 Revise: Lesson 2: Vulnerability review

Question ID module-80-q4 · Report a mistake in this question
5. What must be in place before any penetration test?

Why each option is right or wrong

  • “A verbal okay from any developer who works on the site” (Incorrect): A developer may not have authority, and verbal agreements are hard to prove.
  • “A full backup, so permission isn't needed if nothing breaks” (Incorrect): Backups don't replace permission; testing without it can be illegal.
  • “A public announcement so users know a test is happening” (Incorrect): Testers need the owner's permission and scope, not a public notice.
  • “Written permission from the owner, with scope and rules” is correct.

    A penetration test is a simulated attack. Without the owner's written permission, it can be unauthorised access under laws like India's IT Act. The agreement sets the scope (what may be tested), timing, methods allowed, and who to call if something breaks.

    • Scope: list the exact domains and systems.
    • Safety: agree an emergency contact and stop rule.

📖 Revise: Lesson 3: Authorised testing

Question ID module-80-q5 · Report a mistake in this question
6. You notice a website exposes other people's data by chance. What do you do?

Why each option is right or wrong

  • “Download a sample of the data as proof before reporting it” (Incorrect): Taking data harms the people in it and can be illegal; describe the issue instead.
  • “Post about it on social media so the company has to act” (Incorrect): Public posts expose the victims' data to attackers before it's fixed.
  • “Keep exploring to find out how much data is exposed” (Incorrect): Further access goes beyond chance discovery and can be treated as intrusion.
  • “Stop, access nothing more, and report it privately” is correct.

    Looking further, downloading or sharing the data can harm the people involved and put you at legal risk. Stop, note only what you need to describe the problem, and tell the site's owner privately, through a security contact or security.txt if they have one.

    • Don't: post it publicly or keep copies.
    • If unsure who to tell: CERT-In accepts vulnerability reports.

📖 Revise: Lesson 3: Authorised testing

Question ID module-80-q6 · Report a mistake in this question
7. Why preserve evidence before rebuilding a compromised server?

Why each option is right or wrong

  • “So the same server can be put back online straight away” (Incorrect): The compromised server shouldn't be trusted again; evidence is for learning and reporting.
  • “Because rebuilding is slower if the old files are deleted first” (Incorrect): Rebuild speed isn't the reason; understanding the attack is.
  • “So the attacker's files can be reused on the new server” (Incorrect): Attacker files should be studied, not reused.
  • “To learn what happened and for reporting” is correct.

    Logs, disk snapshots and timestamps show how the attacker got in, what they touched and what data was affected. Without them, you can't fix the real cause, tell affected people accurately, or report properly to authorities.

    • Quick step: take a snapshot of the disk before wiping.
    • Copy logs: to a safe place the attacker can't reach.

📖 Revise: Lesson 4: Security incidents

Question ID module-80-q7 · Report a mistake in this question
8. How quickly must many cyber incidents be reported to CERT-In?

Why each option is right or wrong

  • “Within 72 hours, as in Europe's GDPR rules” (Incorrect): 72 hours is GDPR's deadline for some breach notices; CERT-In's is six hours.
  • “Within 30 days, once a full investigation is complete” (Incorrect): The first report is expected quickly, before the investigation finishes.
  • “Only if customers complain about the incident” (Incorrect): Reporting depends on the type of incident, not on complaints.
  • “Within six hours of noticing them” is correct.

    CERT-In's 2022 directions require many types of cyber incident, such as data breaches and compromised systems, to be reported within six hours of noticing them. Early details can be filled in later; the point is a fast first report.

    • Prepare: know who reports, and how, before anything happens.
    • Check: the current list of reportable incidents on the CERT-In website.

📖 Revise: Lesson 4: Security incidents

Question ID module-80-q8 · Report a mistake in this question
9. Why rebuild a compromised server instead of cleaning it?

Why each option is right or wrong

  • “Rebuilding is quicker than cleaning in every case” (Incorrect): It's often quicker, but the reason is trust: you can't be sure a cleaned server is clean.
  • “A cleaned server costs more to host than a new one” (Incorrect): Hosting cost doesn't depend on whether it was cleaned.
  • “Antivirus can't run on servers that have been attacked” (Incorrect): Scanners can run, but they can miss changes an attacker made.
  • “You can't be sure you found everything the attacker changed” is correct.

    Attackers often leave hidden ways back in: extra accounts, changed programs, scheduled tasks. Cleaning can miss one. Rebuilding from a known-good image, then restoring data from a clean backup, removes that doubt.

    • Before restoring: check backups weren't tampered with.
    • Also fix: the weakness they used to get in.

📖 Revise: Lesson 5: Recovery

Question ID module-80-q9 · Report a mistake in this question
10. Which secrets should be rotated after a breach?

Why each option is right or wrong

  • “Only the password that was used to break in” (Incorrect): The attacker may have copied other secrets once inside.
  • “Only secrets that show signs of being used by the attacker” (Incorrect): Absence of evidence isn't proof; any reachable secret should be treated as leaked.
  • “None, if the server has been rebuilt from a clean image” (Incorrect): Rebuilding doesn't change keys the attacker already copied.
  • “Every secret the attacker could have seen or used” is correct.

    If an attacker could reach a file, environment, or database, assume they copied any password, API key, token or certificate it held. Rotate all of them, not just the one you know leaked, because one missed key can let them straight back in.

    • Include: database passwords, API keys, SSH keys, signing secrets and session secrets.
    • Also: sign users out, by invalidating sessions.

📖 Revise: Lesson 5: Recovery

Question ID module-80-q10 · Report a mistake in this question

ProLearners Assist