OpenCyber Academy
Engineering · Chapter 20 · English
Course code: OCA-121Chapter 20: OCA-121-C020

Chapter 20 — Human factors and cyber policy: engineering context

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

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Defining the field"]
  N2["20.2 Policy and engineering"]
  N3["20.3 Stakeholders"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Defining the field"]
  N2["20.2 Policy and engineering"]
  N3["20.3 Stakeholders"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Defining the field]
    |
    v
[20.2 Policy and engineering]
    |
    v
[20.3 Stakeholders]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) define the field of human factors and cyber policy; (2) relate policy to engineering decisions; (3) identify stakeholders at Greyford.

20.1 Defining the field

Aiko begins the specialist part of her course. Human factors and cyber policy studies how people interact with security, and how rules, programmes and laws shape that interaction. It covers usability of security tools, awareness and training, organisational culture, social engineering and policy design. Sasse, Brostoff and Weirich (2001) argued for an approach that treats users as partners and designs security around them. Aiko notes the field is engineering as much as psychology, because it produces requirements, designs and measurements. She writes a one-paragraph definition for her notebook.

20.2 Policy and engineering

Policies set requirements engineers must meet. Greyford's information security policy requires annual awareness training, strong authentication for remote access and reporting of incidents. NIST SP 800-50 Rev. 1 frames awareness and training as a learning programme with needs assessment, design, delivery and evaluation. Aiko sees that engineering choices determine whether policy is workable: a reporting requirement means little without an easy report button. She resolves to read policy as a set of design constraints and goals. She marks each policy clause with the design feature that makes it achievable, and finds two clauses with no supporting feature at all.

20.3 Stakeholders

Aiko lists stakeholders: operators, field engineers, office staff, managers, the security team, human resources, staff representatives, the regulator for water services and the public who depend on safe water. Each has interests. Operators want minimal interruption; human resources wants fair treatment; the regulator wants evidence of good practice; the public wants safe, reliable water. She records these in a stakeholder table. Prof. Kerr notes that human factors work fails when it serves one stakeholder, usually management, and ignores the rest. She adds contractors after a reminder.

Worked example

Aiko defines the field, reads policy as design constraints and maps nine stakeholder groups with their interests.

Synthetic case. Greyford's policy is synthetic; Sasse et al. (2001) and SP 800-50 Rev. 1 are real.

Errors and limits

Stakeholder lists can omit quiet groups such as contractors. Policy summaries simplify legal duties.

Exercises

Synthesis

Human factors and cyber policy is an engineering field that turns policy and stakeholder needs into workable designs.

Continue studying — chapter 20 of 50

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →

Worked answers

EX058. Usability of security tools, awareness and training, and organisational culture, among others.

EX059. As a set of design constraints and goals for engineering.

EX060. When it serves one stakeholder, usually management, and ignores the rest.