IT security management — three questions, four approaches, five stages

◈ 7 cards

The six properties security management preserves, the three questions that scaffold any risk answer, the four ISO 13335 risk-assessment approaches with the trade-off that decides between them, and the five stages of a detailed analysis.

Appropriate security, not maximum security

IT security management is the formal process of establishing and maintaining appropriate security for an organisation's assets. The adjective is doing real work. No organisation can afford maximum security, and one that tried would spend more defending an asset than the asset is worth. The job is to make the spend proportionate to what is at stake, and to be able to show the reasoning afterwards.

The properties it preserves are six, not three: confidentiality, integrity and availability — the triad you already have — plus accountability, authenticity and reliability. This is a favourite trap. A question that opens state the security objectives an organisation's management process preserves is not asking for the CIA triad, and an answer that stops at three has named half the list. Note that reliability appears here and essentially nowhere else in the course.

The process is cyclic, not a project with a completion date. It runs: determine objectives, strategies and policies → assess risk → select cost-effective controls → write plans and procedures → implement, including awareness and training → monitor and maintain → detect and react to incidents → and back to the top, because an incident is evidence that the risk profile has changed, not merely evidence of bad luck. The whole loop is conventionally wrapped in the Plan-Do-Check-Act cycle borrowed from quality management, which is where ISO's family of standards puts it.

One precondition sits above all of this: senior management buy-in. Without it the process has no budget, no authority to impose controls on people who did not ask for them, and no one to accept residual risk. Management commitment is also itself evidence of due diligence when the organisation later has to defend its choices. An answer that omits it has omitted the reason any of the rest happens.

The three questions

Stripped to its spine, security management asks three questions, and they are a better scaffold for a ten-mark answer than any taxonomy you could memorise:

What assets do we have, and what are they worth?
How are those assets threatened — by which threat sources, through which vulnerabilities?
What can we do to counter those threats, at a cost the organisation will actually bear?

They map onto asset identification, threat and vulnerability identification, and risk treatment. Every artefact in the next five lessons is an answer to one of them.

The standards landscape, in one paragraph

ISO/IEC 27001 states the requirements for establishing and operating a documented information security management system — it is the certifiable one, the standard an organisation is audited against. ISO/IEC 27002 is a code of practice: the control catalogue and guidance, formerly numbered ISO 17799, which is why older material cites a number you will not find on the current standard. ISO/IEC 27005 covers information security risk management. ISO 13335 is the source of the four risk-assessment approaches below. The pair to drill is 27001 against 27002: what you must do against what you might do.

The four risk-assessment approaches

Every organisation has to decide how much analysis to buy before it starts analysing. There are four answers.

Baseline. Implement a general level of controls taken from a code of practice, with no per-asset analysis at all. It costs nothing to assess and it establishes a floor. Its weakness is that it is blind to variation in actual exposure: the same control set is applied to the payroll database and the notice-board server, so it is simultaneously too strong somewhere and too weak somewhere else. Suits small organisations without the resources to do more.

Informal. A pragmatic analysis by internal experts or outside consultants, using judgement rather than a defined method. Fast and cheap, and much better than baseline at catching the organisation's genuinely unusual exposures. Its weaknesses are structural: risks can simply be missed, the results are skewed by whichever prejudices the analysts brought, the spend is weakly justified when someone asks why, and the conclusions drift out of date with no mechanism for noticing. Suits small-to-medium organisations where IT is not business-critical.

Detailed risk analysis. A formal, structured process — the five stages below — applied asset by asset. The most thorough, and the only one that produces a justification strong enough to survive a regulator or a court. Its cost is the objection, and the cost is not only money: the delay is itself an exposure, because systems stay unprotected while the analysis runs. Legally mandated for many government bodies and for critical infrastructure.

Combined. Baseline everywhere first, then a high-level pass to identify which systems are high-risk, then informal assessment of those, then ordered detailed analyses of the ones that warrant it. This is the standard's own recommendation for most organisations in most circumstances, and it is a named, examinable verdict rather than a matter of taste. Its residual risk is that if the initial high-level pass misjudges a system, that system stays under-assessed for a while — mitigated by the baseline floor sitting underneath it. Note what combined does not mean: it is not a middling level of rigour applied uniformly. It is two different levels of rigour applied to two different sets of systems.

The five stages of a detailed risk analysis

Establish the context and characterise the system. Where does this organisation sit on the risk spectrum? What legal and regulatory constraints bind it? What is senior management's risk appetite? What are the assessment's boundaries — which systems are in scope and which are explicitly not? Who are the stakeholders, and what criteria will be used to judge a risk acceptable? Then identify the assets, by interviewing the people in the business areas, because the security analysts do not know the business and cannot list its assets from outside.
Identify threats, risks and vulnerabilities against each asset.
Analyse the risks: record the existing controls, then rate likelihood, then rate consequence, then derive the risk level, and record all of it in the risk register.
Evaluate the risks against the acceptable level established in stage 1.
Treat the risks that fail that test.

Who supplies which judgement is easy to get backwards, and it is directly examinable. Likelihood is rated by the risk analyst — it is a technical judgement about threat sources and vulnerabilities. Consequence is determined by the asset owners and management — it is a business judgement about what harm the organisation would suffer. Asset identification and valuation come from the business-area staff who were interviewed. An analyst who sets consequence has exceeded their remit, and an executive who sets likelihood is guessing.

Worked example — Coldstream University chooses an approach

Coldstream is a mid-sized university: about 14,000 students, a residence network, a records service holding admissions files, transcripts, fee accounts and staff payroll, and a research computing cluster with two funded projects under data-sharing agreements. The asset we will carry through this whole module is the integrity of Coldstream's personal and financial records, and the threat is an imported e-mail worm that corrupts them.

Ask the three questions. What assets? Records first, but also the payroll pipeline, the two research datasets bound by agreements, the network itself, and — a category learners drop — the people who operate and maintain the systems, who are assets requiring protection in their own right. How threatened? By an imported worm, but also by a burst pipe above the basement records room, by an administrator's mistyped command, by a supplier's compromised update channel. What can we do? That is the rest of this module.

Now choose an approach. Baseline alone is indefensible here — Coldstream holds regulated personal data and is bound by research data-sharing agreements, and a uniform control set cannot show a regulator that the payroll pipeline was assessed. Detailed everywhere is unaffordable — Coldstream has hundreds of systems, most of them a departmental web server or a booking tool whose compromise would embarrass rather than harm. So Coldstream picks combined: a baseline drawn from ISO 27002 applied across every system; a high-level pass that flags the records service, the payroll pipeline and the two research datasets as high-risk; informal assessment of those four; and full detailed analysis of the records service and the payroll pipeline, in that order, because the register will rank them.

Write down why, not just which. The mark is not for the word combined. It is for the sentence that says a uniform baseline cannot justify itself to a regulator, and a detailed analysis of the departmental notice-board server would spend a week to protect nothing.

The loop is the point. Detecting and reacting to an incident is not the end of the process — an incident is evidence that the risk profile changed, so it feeds the next Plan.

Read the last row first: combined is the standard’s own recommendation for most organisations, and it is baseline everywhere PLUS detailed analysis where the high-level pass says it is needed — not a middling rigour applied uniformly.

These four words are used with their exact meanings from the start of this course, and this module reuses them rather than redefining them. An asset is a system resource or capability of value that requires protection — tangible or intangible, and including the people who manage and maintain the systems. A threat is the possibility that a threat source exploits a vulnerability. A vulnerability is a defect or weak point in how an asset is designed, implemented, operated or managed. Risk combines how likely a threat is to exploit a vulnerability with how large the resulting harm would be. Two consequences worth holding: a vulnerability on its own causes no harm — risk exists only where a threat source can actually reach it, which is what stops a risk register from degenerating into a vulnerability list; and one asset faces many threats while one threat targets many assets, so the register is not a list of systems.