<a id="ch-01"></a>

## Chapter 1 — Mathematical reasoning

<!-- open-cyber-academy:lesson-figures:start ch-01 -->
### Lesson map

Lesson 01 published. Map, example, EX001.

```mermaid
flowchart TD
  N0["Learning outcomes"]
  N1["1.1 The opening case"]
  N2["1.2 Precise claims"]
  N3["1.3 Necessary and sufficient"]
  N4["1.4 Counterexamples"]
  N5["1.5 Quantities and units"]
  N6["1.6 Logical structure"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]
```

### Logical drawing

```mermaid
flowchart LR
  N0["Learning outcomes"]
  N1["1.1 The opening case"]
  N2["1.2 Precise claims"]
  N3["1.3 Necessary and sufficient"]
  N4["1.4 Counterexamples"]
  N5["1.5 Quantities and units"]
  N6["1.6 Logical structure"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
```

```text
[Learning outcomes]
    |
    v
[1.1 The opening case]
    |
    v
[1.2 Precise claims]
    |
    v
[1.3 Necessary and sufficient]
    |
    v
[1.4 Counterexamples]
    |
    v
[1.5 Quantities and units]
    |
    v
[1.6 Logical structure]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX001]
```
<!-- open-cyber-academy:lesson-figures:end ch-01 -->


### Learning outcomes

You will (1) use precise reasoning to state and check claims about cloud systems; (2) distinguish necessary and sufficient conditions; (3) use counterexamples; (4) set up the course case.

### 1.1 The opening case

Samuel Osei is a bachelor's student at the fictional Westmere University. His final-year project is with the university's own cloud team, led by Tom Becker, and supervised by Dr Clara Jensen from the computing department. Westmere runs StudyHub, its student services platform, as containers on a managed Kubernetes service. Last term an internal review found that the container registry allowed anonymous pulls of two repositories. One image, records-api, contained a connection string for the student records test database. The test database held synthetic records only, and no unusual access was logged, but nobody could say how long the registry had been open, because audit logging was off in one account.

The case returns throughout the course: each chapter adds a tool or idea that helps answer one of its open questions.

### 1.2 Precise claims

"StudyHub is secure" cannot be checked. "No registry repository allows anonymous pull" can be checked by listing repositories and their settings. The course trains Samuel to turn vague worries into precise, checkable statements, because only checkable statements lead to fixes and evidence.

The precise version also says what evidence would prove it wrong: a single repository with anonymous pull enabled. Samuel's first task is to write such statements for each worry raised in the review, including the missing logs, so that each becomes a check that someone can run and repeat next term.

### 1.3 Necessary and sufficient

Turning off anonymous pull is necessary to stop outsiders downloading images, but not sufficient to protect secrets: anyone with internal access could still read a secret baked into an image. Removing secrets from images and using a secret manager is also needed. Mixing up necessary and sufficient conditions leads to fixes that feel complete but are not.

Samuel lists both conditions in his findings and marks which fixes are done. Closing the registry was finished within a day; removing the connection string from records-api needed a rebuilt image, a new secret in the secret manager and a rotated database password, because the old one had been readable for an unknown period.

### 1.4 Counterexamples

One counterexample disproves a universal claim. The claim "all our images are private" was disproved by a single anonymous pull test on records-api. Engineers look for counterexamples deliberately rather than waiting for them to appear in an incident.

Samuel's test was simple: from a machine with no Westmere credentials, request the image list for each repository. Two requests succeeded where all should have failed. He now runs the same test after every registry change, because a single successful anonymous request is enough to show the claim is false again.

### 1.5 Quantities and units

Exposure is measured in days and resources; costs in money and engineer-hours. Keeping units explicit avoids comparing unlike things.

In the opening case, the exposure involved two repositories and an unknown number of days, while the fix cost about three engineer-days. Writing "two repositories, unknown days" rather than "a small exposure" makes clear what is known and what is missing. Samuel records units beside every figure in his notes, so a later reader never has to guess whether a number means hours, days or resources.

### 1.6 Logical structure

Claims are combined with and, or and not; access policies, later in the course, follow the same logic.

For example, a rule might allow a pull if the caller is in the build group and the request comes from the private network, and not if the repository is marked restricted. Writing such conditions carefully now makes later policies easier to read. Samuel practises by rewriting the registry's intended rule as a single logical statement and checking each repository against it.

### Worked example

Samuel writes the review's findings as four precise statements: two repositories allowed anonymous pull; one image contained a database connection string; audit logging was off in one account; therefore the duration of exposure is unknown. Tom notes that the last statement follows logically from the third, and that fixing logging is necessary before any future exposure can be measured.

> **Synthetic case.** Westmere University, StudyHub, people and events are synthetic.

### Errors and limits

Precise statements can still rest on wrong data; check the data source too.

### Exercises

- **EX001 — Checkable claim.** Rewrite "StudyHub is secure" as a checkable claim. *Rubric:* 3 = e.g. no repo allows anonymous pull; 2 = partial; 1 = vague; 0 = none.
- **EX002 — Not sufficient.** Why is disabling anonymous pull not sufficient? *Rubric:* 3 = internal users could still read baked-in secret; 2 = partial; 1 = vague; 0 = none.
- **EX003 — Unknown duration.** Why was exposure duration unknown? *Rubric:* 3 = audit logging off; 2 = partial; 1 = vague; 0 = none.

### Synthesis

Precise, checkable statements turn worries into work.

### Continue studying — chapter 01 of 40

[← Course home](../../README.md) · [Course chapter index](../SUBJECTS.md) · [Chapter 02 (draft) →](#ch-02)

## Worked answers

<a id="answer-ex001"></a>
**EX001.** For example, "no registry repository allows anonymous pull".

<a id="answer-ex002"></a>
**EX002.** Internal users could still read a secret baked into an image.

<a id="answer-ex003"></a>
**EX003.** Audit logging was off in one account.
