◇ OpenCyber Academy
Professional · Chapter 3 · English

Chapter 3 — Authorized practice and evidence handling

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 3 — Authorized practice and evidence handling

Lesson map

Lesson 03 published. Map, example, EX011.

flowchart TD
  N0["Learning outcomes"]
  N1["3.1 Authorization"]
  N2["3.2 Minimum necessary evidence"]
  N3["3.3 Storage and labelling"]
  N4["3.4 Sensitive findings"]
  N5["3.5 Supplier information"]
  N6["3.7 Practice task"]
  N7["3.9 Retention and deletion"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX011"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["3.1 Authorization"]
  N2["3.2 Minimum necessary evidence"]
  N3["3.3 Storage and labelling"]
  N4["3.4 Sensitive findings"]
  N5["3.5 Supplier information"]
  N6["3.7 Practice task"]
  N7["3.9 Retention and deletion"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 Authorization]
    |
    v
[3.2 Minimum necessary evidence]
    |
    v
[3.3 Storage and labelling]
    |
    v
[3.4 Sensitive findings]
    |
    v
[3.5 Supplier information]
    |
    v
[3.7 Practice task]
    |
    v
[3.9 Retention and deletion]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) obtain and respect written authorization; (2) collect only necessary evidence; (3) store and label evidence properly; (4) handle sensitive findings; and (5) work with suppliers' confidential information.

3.1 Authorization

Even "harmless" activities — reading configurations, running an inventory tool, asking for logs — need written authorization from the system owner stating systems, methods, time window, data handling and contacts. Active tests that alter negotiation are done only in isolated labs by technical staff.

At MTI the SEC-118 ticket is the model: it names the servers, the read-only method, the dates, the repository and a contact. Keep a copy of every authorization with the evidence it produced, and stop work when the window closes, even if the task is unfinished.

3.2 Minimum necessary evidence

Collect what answers the question: algorithm names, versions, certificate details, dates. Do not collect message contents or customer data. Prefer configuration exports and summaries over raw captures.

For the reinsurer SFTP servers, this means an export of OpenSSH version and key-exchange settings, not samples of transferred files. If a team offers more than you need, decline politely and record that you did. Less evidence is easier to protect and simpler to delete when the programme ends. Write down what you chose not to collect.

3.3 Storage and labelling

Store evidence in the agreed repository with labels: source, date, collector, system, classification. Restrict access; inventories of weaknesses are sensitive. Keep a log of who accessed what.

Use the same label fields for every item so that searches work across sources: an export, a questionnaire and a log summary should all show who collected them and when. Review the access log monthly, and remove people who no longer need access. Evidence that cannot be traced to a source and date should be graded U until it can.

3.4 Sensitive findings

If you find something serious — an exposed private key, an unpatched system with a known vulnerability — report it immediately through the security process; do not investigate further on your own.

Record what you saw, when and where, and pass it to the incident contact named in your authorization. Do not copy a discovered key or test whether it works; that would be outside your authorization and could damage evidence. Afterwards, note in the tracker that the item is waiting on the security process.

3.5 Supplier information

Suppliers may share roadmaps under confidentiality. Record them as supplier statements, respect the agreement, and do not forward them outside the people who need them.

Store them with restricted access, as MTI did with the NDA roadmap, and grade the claims they contain as D until observed. When summarising for executives, refer to a roadmap by its date and status without quoting confidential details. If a supplier asks for its roadmap to be deleted, follow the agreement and note the deletion in the evidence log.

3.6 Worked example

MTI's coordinator requests configuration exports for the reinsurer SFTP servers (inventory name insurer-sftp). The authorization (ticket SEC-118) covers read-only export, 1–15 October, results stored in the security evidence repository, contact the infrastructure lead. The export shows OpenSSH version and key-exchange settings; no file contents are touched. A supplier's roadmap received under NDA is stored with restricted access and labelled "supplier statement, confidential".

Note what made this work: the scope was narrow, the method was read-only, the window had an end date, and the contact was named in advance. The roadmap was useful but stayed confidential. Both items can be traced later through their labels.

3.7 Practice task

Write an authorization request and an evidence label for one inventory activity.

Choose a real kind of activity, such as a certificate export from MTI's internal CA. The request should name systems, method, time window, storage, data handling and a contact, like SEC-118. The label should give source, date, collector, system and classification. Ask a peer whether a system owner could approve your request without asking a single follow-up question. Then revise the request once and keep both versions to show what you improved.

3.8 Common errors and limits

Each error has a cost. Excess data enlarges what must be protected and later deleted. Unlabelled evidence cannot support a grade or be traced in an audit, so the work must be repeated. A roadmap shared beyond the agreement can breach an NDA and damage the supplier relationship on which several MTI tracker items depend. Check each piece of evidence against all three before filing it. Correct them before filing.

3.9 Retention and deletion

Evidence has its own lifetime. Agree how long inventory exports, questionnaires and logs are kept — typically for the duration of the programme plus an audit period — and delete them securely afterwards, keeping only aggregate results and decision records. Record deletions in the evidence log. Keeping raw exports forever increases the damage if the repository is ever compromised, because a complete map of an organization's cryptographic weaknesses is valuable to attackers.

When staff leave the workflow, remove their access to the evidence repository promptly and review what they could see; access reviews are part of evidence handling, not an afterthought.

Exercises

Synthesis

Authorized, minimal, well-labelled evidence handling protects the organization, its customers and its suppliers, and keeps the workflow trustworthy.

Continue studying — chapter 03 of 12

← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →