Chapter 2 — Service and stakeholder context | Professional Authorized offensive security and red team

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 2 — Service and stakeholder context

Lesson map

Lesson 02 published. Map, example, EX006.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Services that matter"]
  N2["2.2 Why core banking is excluded"]
  N3["2.3 Stakeholders"]
  N4["2.4 Context in the plan"]
  N5["2.5 Third parties"]
  N6["2.6 Examiner expectations"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX006"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Services that matter"]
  N2["2.2 Why core banking is excluded"]
  N3["2.3 Stakeholders"]
  N4["2.4 Context in the plan"]
  N5["2.5 Third parties"]
  N6["2.6 Examiner expectations"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]

[Learning outcomes]
    |
    v
[2.1 Services that matter]
    |
    v
[2.2 Why core banking is excluded]
    |
    v
[2.3 Stakeholders]
    |
    v
[2.4 Context in the plan]
    |
    v
[2.5 Third parties]
    |
    v
[2.6 Examiner expectations]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX006]

Learning outcomes

You will (1) identify HCU services and who owns them; (2) explain why core banking is often out of scope; (3) map stakeholders for an engagement; (4) write a context paragraph for a test plan.

2.1 Services that matter

HCU runs online banking, a staff VPN, email, a member-facing website and a core banking system on an AS/400. Online banking and the VPN are internet-reachable and change often; they are common first targets for authorized review, so Leo's next authorized review starts with them. The staff VPN ranks high because a shared admin password there would reach internal systems, as the later ENG-440 finding showed. Email and the public website matter too, but they change less often and are lower on the current plan. The AS/400 is listed so everyone knows it exists and is deliberately left alone. Each service on the list carries its owner's name, so Leo knows whom to ask before any check touches it.

2.2 Why core banking is excluded

The AS/400 holds the system of record for balances. An accidental outage would stop branches. Unless a specialised, heavily controlled engagement is funded, it stays out of scope and is protected by compensating controls. Those controls — network isolation, tightly limited admin paths and monitoring — are what make exclusion defensible to examiners. Leo's plan names them, and the owner of each, rather than pretending the system is invisible, so examiners can put questions to the network team directly. A specialised engagement would need its own funding, ROE and operators trained on that platform; until one is funded, the AS/400 appears in the report only as an exclusion with its controls listed.

2.3 Stakeholders

The CISO authorises; the online-banking product owner accepts risk; the network team opens temporary rules; the SOC watches for test traffic; legal reviews the contract. Leo's job is to know who decides what, so before kickoff he can name each person and what they must approve. If the product owner has not accepted residual risk, or the SOC has not been told the window, he does not start. He keeps a dated one-line approval record for each stakeholder in the ENG-440 ticket; the network team's temporary firewall rule, for instance, must be live by 08:00 Saturday or the window slips. Knowing who decides what prevents a test that is authorized on paper but blocked in practice.

2.4 Context in the plan

A good plan states business purpose (protect members, meet examiner expectations), services in and out of scope, and peak times to avoid (for example Friday payday). Leo's draft for HCU states the purpose (member data and the annual exam), lists online banking and the VPN in scope, excludes the AS/400, ATM network and card processor, and avoids the Saturday morning batch window. The Saturday window and payday avoidance sit next to the host list so a reviewer sees timing judgment, not only addresses. Reviewers can also check timing against the SOC rota, since the analysts on duty that Saturday morning must expect the test traffic.

2.5 Third parties

Card processors and cloud email are separate organisations. Testing them needs their authorization, not only HCU's. Leo's plan lists the card processor and cloud email as out of scope for that reason, so a keen tester does not invent permission that was never granted. If HCU wants them tested, the CISO must obtain written authorization from each provider and attach it to the ROE. HCU's signature alone never covers another organisation's systems, however convenient it would be to probe the card processor from the same Saturday window.

2.6 Examiner expectations

Credit unions face safety-and-soundness exams that ask how systems are tested. Leo's context paragraph is also evidence for examiners: it shows HCU chooses scope deliberately, excludes fragile systems and schedules around operations rather than testing "everything that answers a ping." The paragraph is filed with the ROE, so examiners read the same scope reasoning that the CISO signed and should see that HCU tested what it meant to test. Naming the AS/400 exclusion and the batch-window avoidance is as useful as listing what was in scope, because it shows judgment rather than a checklist of every reachable host.

Worked example (synthetic HCU)

Leo drafts: "Purpose: reduce risk to member data and authenticate online banking ahead of the annual exam. In scope: online banking web tier and staff VPN. Out of scope: AS/400 core, ATM network, third-party card processor. Avoid: Saturday morning batch window."

Synthetic case — Harborline Credit Union (HCU). The credit union, Leo Okonkwo and all figures are invented for teaching.

Errors and limits

Local policies and laws differ; follow HCU's authorization and your jurisdiction. This book never authorizes testing of real systems.

Exercises

EX006 — Five services. List five HCU services from the chapter. Rubric: 3 = five correct; 2 = four; 1 = two; 0 = none.
EX007 — AS/400 exclusion reason. Why is the AS/400 usually out of scope? Rubric: 3 = system of record; outage stops branches; needs specialised controls; 2 = partial; 1 = "old"; 0 = none.
EX008 — Who authorises. Who at HCU authorises the engagement? Rubric: 3 = CISO (with product owner acceptance); 2 = CISO; 1 = Leo; 0 = none.
EX009 — SOC role. What does the SOC need to know before testing starts? Rubric: 3 = window, source IPs, expected noisy methods; so they do not treat test as real attack blindly; 2 = partial; 1 = vague; 0 = none.
EX010 — Third party. May HCU's ROE alone authorize testing the card processor? Rubric: 3 = no; processor's own authorization required; 2 = no; 1 = yes; 0 = none.

Synthesis

Services, owners, exclusions and third parties belong in the plan before any method is chosen.

Continue studying — chapter 02 of 12

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →