Human factors, awareness and training, and incident response

Three things that are not the same

Awareness, training and education are three different interventions with different audiences, methods and time horizons, and a question that asks you to place a programme on the continuum is asking whether you can tell them apart.

Security awareness focuses attention on an issue. Its object is what — what the policy says, what a phishing message looks like, what to do when a laptop is stolen. It is required of all employees, including those with no IT access at all, it is delivered through media rather than instruction, it is short and frequent, and it is tested by recognition: true/false and multiple choice.

Training builds a skill. Its object is how — how to configure the firewall rule, how to handle classified media, how to write code that validates its input. It is role-specific, delivered by practical instruction, and tested by application: give the learner a problem and see whether they can solve it.

Education builds understanding and insight. Its object is why — why this control class exists, why the trade-off falls where it does. It is career-length, delivered by theoretical instruction, and tested by interpretation: an essay, or a design a person has to defend.

A phishing simulation sent to every member of staff is awareness. A secure-coding course for the development team is training. This module is education. The learning continuum runs security awareness → cybersecurity basics and literacy (everyone involved with IT, including contractors) → role-based training → education and certification.

The programme's value is partly legal, and it is worth writing that down: it supports a claim that a standard of due care was exercised, and employees cannot be held accountable for policies they were never made aware of. An organisation that disciplines someone under a policy it never communicated will lose.

Personnel security through the employment lifecycle

The empirical claim that justifies this whole chapter: a large majority of the perpetrators of significant computer crime have legitimate access now, or had it recently. Perimeter thinking cannot address that.

Hiring. Establish that candidates understand their responsibilities and are suitable for them. Background checking is harder than it sounds, because former employers increasingly disclose only dates of employment and job title to avoid liability. Negligent hiring can make an employer liable for harm an employee later causes, so the check is not optional. Extra scrutiny applies to anyone in a position of trust — including maintenance and cleaning staff, who have unsupervised physical access to everything.

During employment. Least privilege, logical and physical — the reason matters: if everyone can reach everything, all users are equivalent in their level of threat, and the organisation has no way to reason about any of them. Separation of duties, arranged so that the people who check for inappropriate use are not the people who could commit it and then erase the audit trail. Limited reliance on key employees, so that no single person's departure or absence stops a critical process. Dual operator and two-person control for the most sensitive actions. And the counterintuitive one: mandatory vacations of at least five consecutive working days for staff in positions of fiscal trust, because a fraud that requires daily maintenance is exposed by a week of somebody else doing the job. An acceptable use policy should be signed as a condition of employment, and it earns its keep through a four-part conditional: if data is exposed, and the cause was an employee's action, and that action violated the AUP, and the AUP is clear and consistently enforced, then the organisation's liability may be mitigated.

Termination. Remove all access — logical and physical — before or as notice is given, not afterwards. Verify that no rogue administrator accounts were created. Inform the guards. Change locks, door codes and shared credentials that the person knew. Recover all assets, which should have been documented when they were issued, because you cannot recover a list you never wrote.

Incidents: the vocabulary the policy is written in

An incident is a violation or an imminent threat of violation of a security policy, an acceptable use policy, or standard practice. The imminent threat half is what lets you act before the damage.

Four management activities: detect · triage · respond · document. Triage is the single point of contact through which all information about incidents reaches the service, regardless of how it arrived — phone, ticket, alert, a passer-by. Triage either requests more information, or notifies the constituency of a known vulnerability, or passes the incident to response in priority order. Its value is precisely that it is single: an organisation with three ways to report an incident has no idea how many incidents it has.

Detection tools report either a precursor — an observation suggesting an incident may occur later — or an indication — evidence that one has occurred or is occurring. Five incident categories: denial of service · malicious code · unauthorised access · inappropriate usage · multiple-component incidents, the last being the forgotten member and the one that describes most real events.

External reporting must be decided in advance. Three reasons. Gathering and presenting evidence is a liability the organisation takes on voluntarily. Law mandates reporting in some circumstances — notably breaches of personal information. And it risks media coverage the organisation cannot control. And if evidence may later be used legally, its collection, storage and transfer must be documented following procedures that vary by country, or it will be inadmissible when it matters.

Worked example — the three-in-the-morning decision at Coldstream

At 03:10 the mail gateway's outbound queue depth alarms. A mass-mailing worm is spreading through Coldstream: it arrived as an attachment, harvests address books, and sends itself onward. The duty operator has the alert, a runbook, and a phone.

The question the policy has to have pre-answered is whether to disconnect the university from the Internet. Notice first why it must be pre-answered: the people who detect the incident at three in the morning are not the people with the authority to make that call, and finding someone who is, at that hour, with no procedure, is how organisations lose the first four hours of an incident.

The defensible default is not a blanket disconnection. A university's operations are its network: teaching platforms, research computing with running jobs, library services, student welfare and safety contact routes, placement and clinical arrangements, and the mail system itself, which is the channel through which the incident would be communicated. Severing all of it is a self-inflicted availability incident of a size comparable to the one being contained, and it destroys the organisation's ability to coordinate the response. So the default is graduated containment: block the worm's outbound SMTP at the gateway (which stops propagation to the outside world without stopping the institution), quarantine the subnets where infected hosts have been identified, rate-limit outbound mail generally, push the signature or the blocking rule to managed endpoints, and keep everything else running.

Full disconnection is retained as an explicitly authorised escalation — available, named in the policy, triggered by stated conditions (evidence of destructive payload behaviour, or of propagation the gateway controls have failed to stop), and authorised by a named role — the CISO or, in their absence, the duty director — who is reachable by a documented out-of-hours route. The policy also says how it is reversed, because an emergency measure with no stated exit becomes permanent.

Reporting to a CERT: yes, by default. The evidentiary burden is low, the university both benefits from and contributes to the shared picture, and early sector-wide warning is the main mechanism by which a mass-mailing worm is stopped anywhere. There is no good reason to make this a case-by-case decision, so the policy pre-commits to it.

Reporting to law enforcement: a judgement call, and the policy names who makes it rather than pre-committing. It becomes mandatory where a statutory obligation applies — most obviously a breach of personal information, which the records service means is live here — and it is warranted where there is material financial loss, evidence of a targeted rather than an indiscriminate attack, or a realistic prospect of prosecution or recovery. Otherwise it costs investigator time, exposes the institution to disclosure and media coverage, and rarely returns anything. Note the structural reason this decision is hard: cybercrime is under-reported because victims lack confidence in law enforcement, fear reputational damage, and fear civil liability — and under-reporting starves law enforcement of exactly the cases and intelligence that would build the capability the victims say is missing. Reporting is a small contribution to breaking that cycle, and the policy should say so honestly rather than pretending the decision is obvious.

Finally: communication to users. Tell people what has happened, what they must do (do not open the attachment; report if you did), what the university is doing, and when the next update will come. Silence during an incident is filled by rumour, and by users routing around the controls you just deployed.