Offensive work, defensive work, and CTFs

02Classify the action

An alert is a notification that something may need attention. A failed login means a sign-in attempt was not accepted. It could result from a typing mistake or something else; it does not by itself establish an attack.

In the example, trying the permitted weakness is testing. Reviewing the alert and deciding how to protect the system is defensive work. Classify the action described rather than the person's job title: the same person may do both kinds of work at different times.

Authorized means permitted by someone with the right to allow the activity. Scope is the boundary of that permission, including the target and allowed action. A reachable page does not supply permission. You will practice reading these boundaries before running security tools.

03What a CTF leaves out

A puzzle often concentrates on one idea and leaves out much of a real organization's complexity. Its flag shows that a submission matches the event's expected outcome. It does not show how safely someone worked or whether they can explain the effect of a problem and recommend a correction.

A real security test also needs planning, careful evidence handling and reporting. Defensive work includes keeping systems useful over time. Puzzle practice can develop parts of these skills, but a score alone does not establish all of them.

04Sort role cards

Read the fresh cases below and classify the action in each. These are written scenarios; you will not sign in, restore files or join an event.

FICTIONAL ROLE CARDS

CARD 1
A permitted tester checks one named weakness in an isolated toy login.

CARD 2
A maintainer restores a broken club timetable from a tested copy.

CARD 3
A learner solves an event's supplied file puzzle and submits its flag.

For each card, record:
Action / intended outcome / permission or rules to check

1. For each card, choose the best description: authorized testing, defensive recovery or CTF practice. Explain which action supports your choice before comparing the cases.
2. Record the outcome each person wants. Separate discovering a weakness, restoring useful information and reaching a puzzle's expected result.
3. For the test, identify the stated target and action limit. For the puzzle, identify whose rules would govern the supplied material and flag submission.
4. Review your explanations. A classification should follow the activity, not the person's title. None of the cards gives permission to act on unrelated systems. Stop with your written decisions.

05Work together

A permitted test can give defenders evidence about a weakness. Defenders can help a tester plan a suitable activity and interpret its results. After a correction, another controlled check can help establish whether the particular weakness remains.

Useful work leaves an explanation of what happened and what should improve. You can practice that habit now with clear notes and permission decisions. The next lesson shows how those habits apply when reading a CTF challenge board.

06Optional challenge

Allow about 5 extra minutes. For the toy-login example, propose one protective improvement and the evidence you would want when checking it. Keep the proposed evidence separate from an observed result; you are writing a plan, not performing a login test.

07Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Mira, whose job title is defender, checks one permitted weakness in the named isolated upload lab. Jo, whose title is tester, restores a damaged schedule from a tested copy. Ren solves a provider’s supplied file puzzle and submits its flag under the event rules.

An authorized lab test shows that a reader can change a practice entry. The maintainer plans to restrict changes to editors. No correction or retest has happened yet. The test grant excludes the real club website.

08Explain the evidence exchange

Optional written self-check: Describe a weakness report, a proposed control and a controlled retest. Mark plans as plans and results as results. Check that your target stays inside its permission and that a puzzle score is not used as proof of every security responsibility.