◇ 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 Authorisation"]
  N2["3.2 Defensive scope"]
  N3["3.3 Evidence"]
  N4["3.4 Personal data"]
  N5["3.5 Decision records"]
  N6["3.6 Sharing findings"]
  N7["Handling credentials found"]
  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 Authorisation"]
  N2["3.2 Defensive scope"]
  N3["3.3 Evidence"]
  N4["3.4 Personal data"]
  N5["3.5 Decision records"]
  N6["3.6 Sharing findings"]
  N7["Handling credentials found"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]

[Learning outcomes]
    |
    v
[3.1 Authorisation]
    |
    v
[3.2 Defensive scope]
    |
    v
[3.3 Evidence]
    |
    v
[3.4 Personal data]
    |
    v
[3.5 Decision records]
    |
    v
[3.6 Sharing findings]
    |
    v
[Handling credentials found]
    |
    v
[Worked example] --> [Exercise EX011]

Learning outcomes

You will (1) confirm authorisation before reviewing systems; (2) handle code, logs and findings as evidence; (3) protect personal data; (4) record decisions.

3.1 Authorisation

Priya's review of build dependencies is authorised in writing by Marcus and the TrackPort lead, naming the repositories, build logs and registry settings in scope. Reviewing other teams' systems needs their owners' agreement. Written authorisation protects Priya and Harbourline: she cannot be accused of reviewing systems without permission, and owners know exactly what she can see. The scope covers TrackPort's repositories, build logs and the registry settings that affect them. If she needs to look at another team's systems, she asks the owner and records the agreement before starting. Marcus keeps a copy of each authorisation with the project records.

3.2 Defensive scope

The work reads configurations, lock files and logs; it does not publish packages to public registries or test whether a public name could be taken. Such tests could affect other organisations and are not needed to fix the configuration. The question of whether someone could take an internal name on the public registry is answered by evidence already in the logs: hl-auth was resolved publicly. Testing it again by publishing a package would add nothing and could mislead other organisations' builds. Priya's evidence shows the configuration gap, and fixing the configuration is the defensive response. The limit is written into her authorisation, so nobody at Harbourline can later ask her to prove the gap by publishing a test package.

3.3 Evidence

The build log showing hl-auth fetched from the public registry, the lock file entry with its hash and the registry configuration are saved with dates and hashes. Hashes show that saved evidence has not changed since it was collected, which matters if the finding is challenged or later reviewed. The build log shows when hl-auth was fetched publicly, the lock file shows which version and hash were used, and the registry configuration shows why. Priya stores the evidence in a restricted folder with a short register listing each item, its date and its source.

3.4 Personal data

Build logs rarely contain personal data, but application logs do; Priya uses synthetic test data in any reproduction. TrackPort's application logs include customer names, addresses and shipment details, which are not needed to understand a build problem. When Priya needs to reproduce an issue, such as how a package is resolved, she uses synthetic customers and shipments in a test environment. This keeps customer data out of her evidence and her reports. Marcus confirms the approach before she begins. Test environments used for reproductions are cleared afterwards, so not even synthetic shipment data is left behind.

3.5 Decision records

Decisions such as "the published public hl-auth was not harmful, based on comparing its contents with our internal version" are recorded with who decided and on what evidence. Recording decisions with their evidence means a later reviewer can check whether the decision was reasonable, rather than relying on memory. For hl-auth, the comparison showed the public package was an older copy of Harbourline's own code. Each decision record names who decided, the date, the evidence and any follow-up, such as Marcus's request to the registry operator.

3.6 Sharing findings

Findings are shared within the teams that need them; external reporting to the registry operator is decided by Marcus. Sharing only with teams that need findings limits the spread of information about weaknesses that are not yet fixed. Decisions about contacting outside organisations rest with Marcus, because they affect Harbourline's relationships and reputation. For hl-auth, he contacted the registry operator through its official process to ask for the name to be transferred or removed. Priya records each external report with its date and outcome.

Handling credentials found

If a review finds a real credential, Priya does not use it or test it. She reports it to the owner, who revokes and replaces it, and the finding records only where it was found.

Worked example

Comparing the public hl-auth package with the internal one, Priya finds it is an older copy of Harbourline's own code, apparently published by mistake years ago by a former contractor. Marcus asks the registry operator, through its official process, to transfer or remove the name, and records the decision.

Synthetic case. Events are synthetic.

Errors and limits

Without written authorisation, even well-meant review can cause harm or conflict.

Exercises

Synthesis

Work with written scope, careful evidence and recorded decisions.

Continue studying — chapter 03 of 12

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