Chapter 10 — Research reading and critique
Lesson map
Lesson 10 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Choosing papers"]
N2["10.2 Burns 2016"]
N3["10.3 Shu 2017"]
N4["10.4 Rahman 2019"]
N5["10.5 Standards"]
N6["10.6 Critique"]
N7["A structured critique template"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Choosing papers"]
N2["10.2 Burns 2016"]
N3["10.3 Shu 2017"]
N4["10.4 Rahman 2019"]
N5["10.5 Standards"]
N6["10.6 Critique"]
N7["A structured critique template"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[10.1 Choosing papers]
|
v
[10.2 Burns 2016]
|
v
[10.3 Shu 2017]
|
v
[10.4 Rahman 2019]
|
v
[10.5 Standards]
|
v
[10.6 Critique]
|
v
[A structured critique template]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) read research on cloud security critically; (2) judge relevance to Beacon; (3) summarise limitations.
10.1 Choosing papers
Inês reads Burns et al. (2016) on Borg, Omega and Kubernetes, Shu et al. (2017) on Docker Hub image vulnerabilities and Rahman et al. (2019) on security smells in infrastructure as code. Each paper covers a different part of Inês's work: Burns et al. explain why Kubernetes is designed the way it is, Shu et al. measure risks in public images that Beacon's registry rules address, and Rahman et al. describe mistakes in infrastructure code like Beacon's GitOps repository. She reads each for method and limits, not just conclusions.
10.2 Burns 2016
Explains the design history of cluster managers. Useful context for why namespaces and admission exist; not a security evaluation. The paper helps Inês explain to the risk committee why admission control exists and why namespaces are the unit Pod Security works on. She does not cite it as evidence that any control works, because it describes design, not security outcomes. Her notes record what the paper supports and what it does not, so she cites it only for design history in the final report.
10.3 Shu 2017
Measured vulnerabilities in public images. Supports Beacon's registry rules; the data is several years old, so figures should not be quoted as current. Shu et al.'s findings support the policy engine's rule that images must come from Beacon's private registry. Because public images change constantly, Inês does not repeat the paper's percentages as current figures. When a colleague quoted them in a slide as today's numbers, she suggested citing them as historical and adding Beacon's own scan data instead.
10.4 Rahman 2019
Identified recurring security smells such as hard-coded secrets in scripts. Supports scanning Beacon's GitOps repository. Hard-coded secrets in Beacon's GitOps repository could expose credentials to anyone who can read it. Rahman et al.'s categories give Inês a checklist for scanning the repository. The paper studied scripts from open-source projects, so Inês checks whether its smells appear in Beacon's own code before relying on it. She records which smells the scan found, if any, with the date. Inês asks the platform team to add a secrets scan to the GitOps pipeline, so new commits are checked automatically.
10.5 Standards
NIST SP 800-190 and SP 800-207 give frameworks; they are guidance, not evidence of effectiveness. Inês uses the standards to organise the baseline and to explain it to auditors, but she does not claim that following them proves Beacon is secure. Evidence that controls work comes from Beacon's own behaviour tests and the policy evaluation. Her final report keeps the two kinds of source apart, citing standards for structure and her own measurements for results. Prof. Rao asks her to keep this distinction in her viva answers, since examiners may challenge claims that standards prove effectiveness.
10.6 Critique
For each, Inês notes method, data age, and whether results transfer to a managed service. Method shows how much weight a result can bear, data age shows whether it still applies, and transfer shows whether it fits Beacon's managed Kubernetes service. A study of self-managed clusters may not apply where the provider runs the control plane. Inês records her notes for each paper in a short table, which appears in the final report's literature chapter. Prof. Rao checks the table against the papers themselves and queries one data-age entry.
A structured critique template
Inês uses a short template for each source: the question it asks, the method, the data and its date, the main finding, the limits stated by the authors, and the relevance to Beacon. For Ristenpart et al. (2009), on information leakage between co-located virtual machines, she records that the work shows why providers isolate tenants carefully, that providers have since changed their platforms, and that Beacon relies on the provider's isolation under the shared responsibility model rather than testing it. For Mell and Grance (2011), the NIST definition of cloud computing, she notes it is a definition, useful for shared vocabulary in board reports, not a security control.
The template makes reviews comparable and keeps her from treating a well-known paper as stronger evidence than its method supports.
Worked example
A colleague quotes Shu's percentages in a slide as today's figures. Inês suggests citing them as historical and adding Beacon's own scan data.
Synthetic case. Summaries are paraphrased.
Errors and limits
Old data can mislead when quoted as current.
Exercises
- EX046 — Burns relevance. How is Burns 2016 relevant? Rubric: 3 = design context, not security evaluation; 2 = partial; 1 = vague; 0 = none.
- EX047 — Shu caution. What caution applies to Shu 2017? Rubric: 3 = data age; 2 = partial; 1 = vague; 0 = none.
- EX048 — Rahman. What does Rahman 2019 support? Rubric: 3 = scanning GitOps repo for smells; 2 = partial; 1 = vague; 0 = none.
- EX049 — Standards. How should standards be treated? Rubric: 3 = guidance, not evidence of effectiveness; 2 = partial; 1 = vague; 0 = none.
- EX050 — Slide. How was the slide corrected? Rubric: 3 = cite as historical, add own data; 2 = partial; 1 = vague; 0 = none.
Synthesis
Read research for method, age and transfer.
Continue studying — chapter 10 of 12
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →