Controls, plans, and change versus configuration management

What a control is

A control — the words safeguard and countermeasure mean the same thing — is any measure that lowers risk, in one of exactly three ways: by eliminating or preventing a violation, by limiting the harm a violation can do, or by detecting and reporting it so that correction is possible. Hold on to the three verbs; the classification below is built on them.

Two axes, not one

Controls are classified on two independent axes, and the single commonest mistake is collapsing them into one list of six.

Classes say who implements it:

• Management — policies, planning, guidelines and the risk process itself. These drive the other two: a technical control nobody was told to deploy does not exist.
• Operational — controls implemented primarily by people rather than by systems. Note that the name misleads. Operational does not mean at runtime; it means a human being carries it out. Background screening, media handling procedures, awareness training and incident handling are all operational.
• Technical — hardware and software capabilities: authentication mechanisms, access control lists, encryption, audit logging.

Categories say what function it performs, and any category can appear in any class:

• Supportive — pervasive underlying capabilities the other controls depend on. Identification is the archetype: without it, nothing can be authorised or audited.
• Preventive — stops the violation happening.
• Detection and recovery — notices that it happened and restores the state.

Three classes by three categories is a nine-cell grid, and an exam question that asks you to classify a control wants both coordinates. Incident response is operational and detection-and-recovery. Cryptographic key management is technical and supportive. The security policy itself is management and supportive.

The three levers, and residual risk

This is the cleanest causal account of what a control actually does, and it is what makes a register defensible. A control lowers risk by:

1. reducing the vulnerability — patching, input validation, hardening;
2. reducing the threat source's capability or motivation — deterrence, prosecution, making the target visibly expensive;
3. reducing the magnitude of the adverse impact — backup, replication, compartmentation, insurance.

The first two lower likelihood. The third lowers consequence. For every control in your register, say which lever it pulls — that one habit turns a list of good ideas into an argument.

Whatever remains after the control is applied is residual risk. It is never zero, and management formally accepts it. An answer that describes a control as eliminating a risk has said something no security professional would say.

The four-way selection rule

For each candidate control, document its feasibility — technical compatibility, operational impact, whether users will actually accept it — and its effectiveness, meaning the risk reduction weighed against the cost. Then decide by four cases:

• reduces risk more than required ⇒ look for a cheaper alternative;
• costs more than the reduction is worth ⇒ look for an alternative;
• reduction is insufficient ⇒ add further controls;
• sufficient and most cost-effective ⇒ select it.

The honest caveat belongs with the rule: the cost of implementing a control is far more tangible than the cost of not implementing it. One is a quotation; the other is a probability multiplied by an estimate. So the final selection is a management judgement over ill-defined numbers, and pretending otherwise is what produces security programmes that cannot defend their own budgets.

Baseline controls also need adjusting rather than adopting: for the technology actually in use, for organisation-wide common controls that several systems inherit at once, for public-access systems (whose public interface is outside the scope of personnel and authentication controls, though administrative access to it is emphatically not), and for scalability.

The IT security plan

The plan is the bridge from assessment to action, and it has eight contents: the risks; the recommended controls; the action priority for each risk; the controls actually selected; the resources required; the personnel responsible; the target start and end dates; and the maintenance requirements.

During implementation the security officer checks three things: that costs stay within the bounds the plan set; that controls are implemented exactly as specified, because a control installed differently achieves a different risk reduction from the one that was planned; and that they are operated and administered thereafter. On completion, management authorises the system for operational use. The pair to learn here: certification is the technical evaluation of the system; accreditation is management's formal authorisation to operate it.

The commonest gap between a plan and a working control is that even technical controls need associated operational procedures — who reviews the alerts, who rotates the keys, who acts on the report — and management has to encourage and monitor their use.

Change management and configuration management

This pair is close to guaranteed on an exam paper, and the distinction is one sentence.

Change management is a process: proposed modifications are reviewed for their security implications, approved or refused, scheduled, and reviewed afterwards. It controls whether and when a change happens.

Configuration management is a record: what is actually deployed right now, what changed and when, and the ability to return the system to a known state. It records what the system now is.

You need both, and the reason is practical rather than definitional: a change process with no configuration record cannot tell you what to roll back to, and a configuration record with no change process documents a system nobody is controlling. Configuration management is also what answers which of our hosts needs this patch, which is a question you will be asked in the first hour of an incident.

The teachable tension sitting on top of both is the patch-testing dilemma: test a patch first and stay exposed for longer, or deploy immediately and risk breaking production. It is framed explicitly as management deciding whether availability or security has priority for this system — not as a technical question with a right answer.

Worked example — classifying Coldstream's controls

Take the controls the previous two lessons produced for the worm threat and place each one on the grid, with its lever.

• Fortnightly patching of the records servers — technical, preventive; reduces the vulnerability, so it lowers likelihood.
• Attachment sandboxing at the mail gateway — technical, preventive; reduces the vulnerability, lowers likelihood.
• The macro-execution policy, and the awareness campaign that explains it — the policy is management and preventive; the campaign is operational and preventive. Both lower likelihood by removing capability from the threat source.
• Nightly offline backups with quarterly tested restores — the backup mechanism is technical and detection-and-recovery; the quarterly test is operational. Reduces impact, so it lowers consequence.
• Segregating records from payroll — technical, preventive in effect but working on impact: it stops one corruption reaching both systems, so it lowers consequence, not likelihood. This is the entry that shows why the lever matters more than the label.
• The incident response plan — management and operational, detection-and-recovery.

Now apply the selection rule to one of them. Coldstream priced continuous data protection with fifteen-minute recovery points for the records service: technically feasible, but it costs eleven times the nightly-backup arrangement and the risk it removes is the difference between losing a day's transactions and losing fifteen minutes' worth — during an event that occurs less than once a decade. That is reduces risk more than required, so the cheaper alternative is selected and the reasoning is written into the plan. Residual risk — up to one day of records changes lost in a successful corruption event — is stated explicitly and signed off by the registrar, who owns the asset.