WEEK 01 · LESSON 01 · 45–60 MINUTES · ESSENTIAL + PROFESSIONAL CHALLENGE
← Back to the 12-week roadmap · Leia em português
Security engineering is not about memorizing tools or trying to hack everything. It is about making systems safer by design, deciding which risks matter, implementing controls, and proving that those controls work. Today you will act as the security engineer for a fictional small SaaS product.
Your deliverable: a one-page security review containing a system diagram, three risks, three controls, and a way to verify each control. Keep it: it is the first artifact in your learning portfolio.
1. What will you be able to do?
- Explain the difference between an asset, threat, vulnerability, risk, and security control.
- Describe what a security engineer actually delivers to a business.
- Turn a vague concern into a testable technical requirement.
- Prioritize a few practical improvements instead of making an endless tool checklist.
2. A security engineer’s mindset
Ask four questions in order: What matters? What could go wrong? What can reduce the risk? How will we know it works?
Asset: something valuable, such as customer information or service availability. Threat: a possible cause of harm. Vulnerability: a weakness that can be exploited or trigger failure. Risk: the combination of a harmful scenario, its likelihood, and its impact. Control: a measure designed to reduce that risk, such as access checks, MFA, monitoring, or tested backups.
The NIST Cybersecurity Framework 2.0 organizes cybersecurity work into six complementary functions:
- Govern: decide ownership, objectives, and acceptable risk.
- Identify: inventory important systems, data, and dependencies.
- Protect: use safeguards such as least privilege and encryption.
- Detect: observe suspicious or unexpected activity.
- Respond: contain and investigate incidents.
- Recover: restore services and learn from failures.
One job title does not have to own every function. Security engineers often collaborate with developers, cloud engineers, infrastructure teams, and incident responders. A good deliverable is a working protection with evidence—not merely a recommendation slide.
3. Your fictional company: OrderDesk
OrderDesk helps small businesses collect customer orders. It has a website, a backend API, a PostgreSQL database, and object storage for attachments. Each merchant signs in to see only their own orders. Administrators manage the service. Customer records include names, phone numbers, and delivery details.
During an initial review you hear three worrying statements:
- “Order IDs are sequential, and I am not sure the API checks which merchant owns each order.”
- “Admins use passwords, but we have not enabled MFA or reviewed failed-login alerts.”
- “The database is backed up nightly. Nobody remembers the last restoration test.”
These are hypotheses to investigate, not confirmed incidents. A security engineer turns each into a concrete check, a decision, and an improvement.
4. Hands-on lab — create a one-page security review (30 minutes)
Step A — Draw the system (5 minutes)
On paper or in a diagram tool, draw: Customer browser → Web app/API → PostgreSQL, plus API → object storage. Mark the boundary between a merchant’s account and another merchant’s data. Mark where administrators sign in. No accounts or paid tools are required.
Step B — Fill your risk register (10 minutes)
Use this table as a starting point. Copy it to a note and improve it in your own words:
| Asset | What could go wrong? | Control | Proof it works |
|---|---|---|---|
| Merchant orders | Merchant A reads merchant B’s records | Server-side authorization on every order request | With synthetic test accounts, A cannot access B’s order (403/404) |
| Admin accounts | Stolen password grants privileged access | MFA, least privilege, login monitoring | Test admin MFA and alerting with test accounts |
| Orders database | Deletion or outage causes prolonged data loss | Protected backups and a recovery plan | Restore into an isolated environment and check records |
Step C — Choose priorities (10 minutes)
For each risk, record impact (low/medium/high), likelihood (low/medium/high), and what you still do not know. Choose your top three actions. Explain why each deserves attention before selecting a product or vendor. These are qualitative judgments, not a precise risk formula.
Step D — Write acceptance criteria (5 minutes)
Transform your highest-priority risk into a testable task. Example: “When merchant A is authenticated, requesting an order belonging to merchant B must never disclose B’s order data; the API must enforce authorization regardless of UI behavior.” Define how you would verify it on accounts and data you control.
5. Test your decisions
Try the questions below before revealing their answers. Getting one wrong is useful: explain what assumption you made.
Question 1 — Merchant A can read merchant B’s order. Is hiding B’s order link in the UI enough?
No. Browser UI restrictions are not authorization. The API must check the authenticated merchant against the owner of every requested order. Verify with two synthetic accounts and a negative test.
Question 2 — Nightly backups are running. Does that prove OrderDesk can recover from data loss?
No. A successful backup job is only one piece of evidence. Restore a copy into an isolated test environment, verify data integrity and measure how long recovery takes.
Question 3 — Which is a stronger deliverable: “Enable MFA” or “Admin MFA is enforced and verified”?
The second. A verified control has an owner, a test, and evidence. “Enable MFA” alone could remain an unimplemented recommendation. Security engineering is about measurable outcomes.
6. Professional challenge (optional, 20 minutes)
If you develop software, implement one small automated negative authorization test in a local project you own: create two synthetic merchants and an order for merchant B; authenticate as A; request B’s order; assert that no sensitive data is returned and the response is 403 or 404. Also test the list and update endpoints where relevant. Never test other people’s applications without authorization.
If you are not coding yet, write the three test cases in plain language. A well-designed test is still valuable engineering work.
7. Check your deliverable
- ☐ I drew the components and at least one trust boundary.
- ☐ I identified three valuable assets and plausible failure scenarios.
- ☐ I chose controls with clear owners and priorities.
- ☐ Every control has a way to verify its effectiveness.
- ☐ I can explain my most important decision in two sentences.
Self-assessment: 5/5 means you completed the lesson; fewer than 5 means revise the missing items. Save your diagram and risk register as lesson-01-security-review in your notes or portfolio. Do not publish production data, credentials, or internal architecture details.
8. Learn the culture
Read the introduction to OWASP Top 10:2025 — Broken Access Control and the NIST NICE Framework. Notice the difference between knowing a vulnerability name and being responsible for a measurable security improvement.
Reflection: What would you protect first in OrderDesk, and what evidence would convince you that your change worked? Write a three-sentence answer. Next: Lesson 02 — Confidentiality, Integrity, and Availability in Real Systems.