COMP 6660 · Enterprise Cybersecurity Security Frameworks and Models

00 Introduction

Lessons 1.1 to 1.4 established what enterprise cybersecurity is, what it protects, what objectives it pursues, and who threatens it. This lesson addresses the structure of the security programme itself.

Enterprises do not approach security as a blank canvas. They inherit expectations, obligations, and practices — some from regulators, some from customers and partners, some from industry norms, and some from the frameworks and standards that have become the common language of the field. Frameworks such as the NIST Cybersecurity Framework, the NIST Risk Management Framework, and ISO/IEC 27001 are not merely documents; they are the shared reference points through which enterprises, auditors, regulators, and customers communicate about security.

This lesson examines those frameworks and one architectural model — defence-in-depth — in detail. It explains what each is for, what each contains, and where each is strongest and weakest. It then compares them across the dimensions that matter for selection: scope, purpose, structure, assurance, cost, and regulatory recognition. It closes with the practical question of selection — how an enterprise chooses among frameworks, and how it combines them when no single framework fits.

The lesson is deliberately comparative. A common failure mode in enterprise security is framework capture: treating one framework as the answer to every question, rather than as one instrument among several. Frameworks are tools. The purpose of this lesson is to give you the judgement to use them well.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 1 outcomes U1.4 (frameworks and models) and U1.5 (posture assessment), and to Module 1 outcomes M1.4 and M1.5. See the Unit 1 learning outcomes page for the full mapping.

02 Why frameworks exist

Before examining specific frameworks, it is worth asking why the discipline has produced them. A security framework is not a control catalogue, nor a technology reference architecture. It is a structured way of organising and reasoning about security activity — a scaffolding that helps enterprises address a problem too large and too interconnected to manage ad hoc.

Four problems frameworks address

What frameworks are not

Frameworks have limits, and confusing frameworks with the discipline they support produces real harm. Frameworks are not:

• Guarantees of security. An enterprise can be fully aligned to a framework and still be breached. Frameworks provide structure; they do not provide outcomes.
• Substitutes for risk judgement. Frameworks structure activity, but they cannot decide which risks matter. That remains a human judgement, informed by context.
• Complete. No framework covers everything. Each has strengths and blind spots. Frameworks are written for a particular context and are best used with awareness of what they leave out.
• Interchangeable. Frameworks differ in scope, purpose, and structure. Choosing the wrong one for a given purpose — using a risk framework for assurance, or an assurance framework for risk — is a common and expensive mistake.

03 NIST Cybersecurity Framework (CSF)

Origin

The CSF was first published in 2014 in response to a US Executive Order directing NIST to develop a voluntary framework for reducing cyber risk to critical infrastructure. Its scope was subsequently broadened, and it is now used by organisations of all sizes and sectors — not only critical infrastructure. It has been revised periodically, with the most recent revision expanding its treatment of supply chain risk, governance, and emerging technologies.

Structure: five functions

The CSF is organised around five functions that describe the lifecycle of security activity:

Beneath the five functions, the CSF defines categories and subcategories, and (in its most recent revision) references specific controls and practices from other frameworks. This layering allows organisations to begin with the high-level functions and progressively add detail.

Structure: implementation tiers and profiles

Two additional constructs give the CSF its distinctive character:

• Implementation tiers. Four tiers — Partial, Risk Informed, Repeatable, and Adaptive — describe the rigour with which an organisation manages cyber risk. Tiers are not maturity levels; they describe the extent to which an organisation's approach is informed by risk, integrated with business strategy, and adaptive to change.
• Profiles. A Current Profile describes the organisation's present alignment with the framework; a Target Profile describes the desired state. The gap between the two drives prioritisation and investment.

The profile concept is one of the CSF's most useful contributions. It frames security improvement as a managed transition from a current state to a desired state, rather than as a binary question of compliance.

Strengths and limitations

04 NIST Risk Management Framework (RMF)

Origin and relationship to CSF

The RMF predates the CSF and originated in US federal information security law. It is a more prescriptive and procedural framework than the CSF, and it is designed to support system-level risk decisions rather than enterprise-level programme structure. The two are complementary: CSF provides the enterprise-level view; RMF provides the system-level process.

Structure: seven steps

The RMF defines a seven-step process. Each step produces artefacts that feed the next.

The RMF's companion publication — NIST SP 800-53 — contains the detailed control catalogue that enterprises select from during the "Select" step. This catalogue is extensive and organised into families (access control, awareness and training, audit and accountability, and so on).

Distinctive features

• System-level focus. The RMF operates on individual systems rather than the enterprise as a whole. It answers "how do we decide whether this system is safe to operate?", not "how do we structure the enterprise programme?".
• Categorisation drives control selection. The impact of compromise determines the rigour of controls. A system that handles low-impact information does not require the same controls as one that handles high-impact information.
• Formal authorisation. The authorisation step places personal accountability on a named official. This is one of the RMF's most distinctive features and its most demanding.
• Continuous monitoring. The framework assumes that security is not a one-time certification but an ongoing process. Controls decay; risk changes; the process continues.
• Prescriptive process. The seven steps are defined, with expected inputs and outputs. This produces consistency but also imposes effort.

Strengths and limitations

05 ISO/IEC 27001

The ISMS concept

The distinctive feature of ISO/IEC 27001 is that it does not prescribe specific security controls. Instead, it requires the organisation to establish, operate, monitor, review, and improve an Information Security Management System — a managed system for security, analogous to a quality management system under ISO 9001 or an environmental management system under ISO 14001.

The ISMS is a "plan-do-check-act" cycle applied to security. The organisation must define its scope, establish a security policy, assess risks, select controls, implement them, monitor them, and continuously improve. The standard specifies requirements for this system, not for the controls themselves.

Structure

ISO/IEC 27001 is organised into clauses that define requirements for the ISMS, and an annex that lists a set of controls the organisation may select from. The relationship between the two is important: the clauses define what the ISMS must include; the annex controls are a menu, not a mandate. The organisation selects the controls appropriate to its risk assessment and documents its selection.

Annex A controls

Annex A of ISO/IEC 27001 lists a set of control objectives and controls organised into categories such as information security policies, organisation of information security, human resource security, asset management, access control, cryptography, physical security, operations security, communications security, system acquisition, supplier relationships, incident management, business continuity, and compliance.

The list is not exhaustive. Organisations may select additional controls beyond those listed if their risk assessment justifies them, and they may justify not applying listed controls where those controls are not applicable to their risk profile. This flexibility is a key feature but also a source of variability in certification outcomes.

Certification

ISO/IEC 27001 is certifiable. Certification involves an independent audit by an accredited certification body, and it is maintained through periodic surveillance audits. The certificate is a statement that the organisation has established and operates an ISMS meeting the requirements of the standard. It is not a guarantee that the organisation is secure; it is a statement that the organisation has a managed system for security.

Certification is widely recognised in commercial relationships. Organisations frequently require ISO/IEC 27001 certification of suppliers, particularly in sectors where information security is a material concern. This recognition is one of the standard's principal commercial benefits.

Strengths and limitations

06 Defence-in-depth

Origin and motivation

Defence-in-depth is borrowed from military doctrine, where it refers to the practice of arranging defences in layers so that an attacker who penetrates one layer faces further resistance. Applied to information security, the principle assumes that any single control will eventually fail — through misconfiguration, vulnerability, or adversary capability — and designs so that a single failure does not produce compromise.

The principle is directly relevant to the "assume breach" posture introduced in Lesson 1.4. If the enterprise accepts that prevention will sometimes fail, layered controls become essential: they ensure that failure at one layer is detected and contained by another.

Layers in defence-in-depth

The layers vary by architecture, but a common model includes:

Two interpretations of defence-in-depth

Defence-in-depth is sometimes interpreted in two different ways, and the distinction matters:

• Breadth. Multiple layers, each addressing different attack vectors. The objective is coverage across the range of ways an adversary might attempt to reach the asset.
• Redundancy. Multiple controls at each layer, so that the failure of one control does not leave the layer undefended. The objective is depth within each layer.

Effective defence-in-depth combines both. Breadth without redundancy can be defeated by a single successful attack at any layer; redundancy without breadth leaves entire attack vectors unaddressed.

Failure modes of defence-in-depth

Defence-in-depth is more often invoked than implemented well. Common failure modes include:

• Uniform controls. Deploying the same control at every layer — five different firewalls, for example — rather than controls that address different failure modes. This is breadth in name only.
• Control interdependence. Layers that depend on each other, so that failure of one layer disables others. This defeats the purpose of layering.
• Neglected layers. Focus on network and host controls while neglecting identity, data, or human layers — where modern attacks are increasingly concentrated.
• Perimeter thinking. Treating defence-in-depth as a justification for a "hard outside, soft inside" architecture. Modern attacks assume the perimeter has already been crossed.
• Complexity without visibility. Many controls, poorly integrated, producing operational burden without corresponding risk reduction.

07 Comparing frameworks

The three frameworks and the defence-in-depth model differ in purpose, scope, and use. The table below compares them across the dimensions that matter most for selection.

They are not alternatives

A common misconception is that an enterprise must choose between these frameworks. In practice they serve different purposes and are often used together:

• CSF as the enterprise structure. The five functions provide the organisation for a security programme, and the profile concept supports managed improvement.
• RMF for high-assurance systems. Where formal risk acceptance is required — for systems processing sensitive data, or for regulated environments — RMF provides the process.
• ISO/IEC 27001 where assurance is needed. Where customers, partners, or regulators require certification, the ISMS framework provides the structure for achieving and maintaining it.
• Defence-in-depth as the architectural principle. Whatever framework is used, defence-in-depth shapes how controls are layered and placed.

In practice, most mature enterprises reference multiple frameworks. A service provider might hold ISO/IEC 27001 certification, structure its programme around NIST CSF, and apply RMF principles to its most sensitive systems. The frameworks reinforce rather than compete.

08 Selecting frameworks for organisational needs

Framework selection is a decision, and like every decision in enterprise security it should be made deliberately, in light of the enterprise's context, obligations, and priorities.

The selection questions

Illustrative selection scenarios

Combining frameworks

When multiple frameworks are used, they should be combined coherently rather than run as parallel programmes. Useful practices include:

• Choose one framework as primary. The others are mapped to it, so that reporting is coherent and control coverage can be evidenced across frameworks.
• Use a control mapping. Most frameworks publish mappings to each other, allowing the enterprise to demonstrate that a control satisfying one framework also satisfies another.
• Avoid duplicate documentation. One control can satisfy multiple frameworks; the evidence should be recorded once and referenced many times.
• Align review cycles. Reviews and audits should be coordinated to reduce operational burden and to produce a single coherent view.
• Maintain enterprise risk as the organising principle. The frameworks are instruments; the enterprise's risk picture is the object they serve.

09 Using frameworks in practice

Frameworks are easy to adopt and difficult to use well. The following practices distinguish enterprises that use frameworks to improve security from those that accumulate documentation.

Common implementation pitfalls

• Compliance-driven adoption. Adopting a framework solely to satisfy an external requirement, without using it to improve the programme. The result is documentation without change.
• Framework-only thinking. Measuring success by framework alignment rather than by security outcomes. A programme can be 100% aligned and still fail.
• Under-resourced implementation. Adopting a framework without the resources to sustain it. The framework is implemented once and then decays.
• Weak risk assessment. Selecting controls from a framework without a credible risk assessment to inform the selection. The result is controls that do not address the enterprise's actual risk.
• Loss of business context. Implementing the framework as a technical exercise, disconnected from the business processes it is meant to support.
• Over-documentation. Producing documentation that no one reads, because the framework's requirements have been interpreted as requiring comprehensive textual coverage.

Practices that work

• Start from risk, not from the framework. Use the enterprise's risk picture to identify priorities, then use the framework to structure the response.
• Adapt the framework to the enterprise. Frameworks are written for broad use; enterprises must tailor them to their context, size, sector, and culture.
• Measure outcomes, not alignment. Track incident rates, dwell time, recovery time, and control effectiveness — not only framework percentage completion.
• Use frameworks as common language, not as the conversation. Frameworks help communicate with customers, partners, and regulators; they should not replace the enterprise's own risk discussions.
• Sustain the programme. Framework adoption is a multi-year commitment. Resourcing must match ambition.
• Review and adapt. The threat landscape, regulatory environment, and enterprise itself change. Frameworks and their application must evolve accordingly.

10 Key concepts

The terms below are used throughout the course. Capture them in your own words as you work through the lesson.

Security framework

A structured set of practices, controls, or outcomes used to organise and assess an enterprise security programme. Frameworks provide completeness, common language, governance, and (where certifiable) external assurance.

NIST Cybersecurity Framework (CSF)

A voluntary framework for understanding, managing, and reducing cybersecurity risk. Organised around five functions — Identify, Protect, Detect, Respond, Recover — with implementation tiers and profiles.

CSF function

One of the five high-level categories of activity in the NIST CSF: Identify, Protect, Detect, Respond, Recover. Together they describe the lifecycle of security activity.

CSF profile

A structured description of an organisation's current (Current Profile) or desired (Target Profile) alignment with the framework. The gap between the two drives prioritisation and investment.

CSF implementation tier

One of four levels — Partial, Risk Informed, Repeatable, Adaptive — describing the rigour with which an organisation manages cyber risk. Distinct from a maturity model.

NIST Risk Management Framework (RMF)

A structured process for integrating security and risk management into the system development lifecycle. Seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Mandatory for US federal information systems.

NIST SP 800-53

The companion control catalogue to the RMF, organised into control families. Provides the detailed controls selected during the RMF's Select step.

System authorisation

The RMF step in which a senior official formally accepts the residual risk of operating a system, on the basis of the assessment. Places personal accountability on a named individual.

ISO/IEC 27001

An international standard specifying requirements for an information security management system. Certifiable by independent audit. Emphasises management system processes (plan-do-check-act) rather than specific controls.

Information Security Management System (ISMS)

A managed system for information security — scope, policy, risk assessment, control selection, operation, monitoring, and improvement — required by ISO/IEC 27001.

Annex A controls

The list of control objectives and controls in ISO/IEC 27001. A menu from which organisations select based on their risk assessment, not a mandatory checklist.

Defence-in-depth

An architectural model that places multiple, overlapping controls at different layers so that the failure of any single control does not compromise the enterprise. Combines breadth (different layers) and redundancy (multiple controls within layers).

Control interdependence

A weakness in defence-in-depth where controls depend on each other, so that failure of one disables others. Defeats the purpose of layering.

Framework capture

The tendency to treat one framework as the answer to every question, designing the security programme around the framework's categories rather than the enterprise's actual risk. Produces internally consistent but poorly aligned programmes.

Control mapping

The cross-referencing of controls between frameworks, allowing the enterprise to demonstrate that one control satisfies requirements in multiple frameworks and to avoid duplicated documentation.

Residual risk

The risk that remains after controls have been applied. In the RMF, residual risk is formally accepted at the authorisation step; in ISO/IEC 27001, it is the basis for ongoing management review.

11 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 1. They are not graded, but completing them will improve the quality of your forum contribution.

12 Self-check

Answer the questions below before moving to Lesson 1.6. If you cannot answer a question confidently, revisit the corresponding section.

13 Summary

This lesson has examined the frameworks and models that structure enterprise security programmes. The essential points are:

• Frameworks address four problems. Completeness (so security activity covers the whole problem), common language (so enterprises, auditors, regulators, and customers can communicate), governance and accountability (so security can be directed from the top), and external assurance (so the programme can be independently confirmed).
• NIST CSF provides enterprise-level structure. Five functions — Identify, Protect, Detect, Respond, Recover — with implementation tiers and profiles. Voluntary, flexible, widely recognised. Not certifiable.
• NIST RMF provides system-level risk management. Seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Rigorous and prescriptive. Places personal accountability on a named official at authorisation.
• ISO/IEC 27001 provides an ISMS and independent assurance. The standard specifies requirements for a managed security system, not specific controls (which are selected from Annex A based on risk). It is certifiable, internationally recognised, and used in commercial relationships.
• Defence-in-depth is an architectural model, not a framework. It places multiple, overlapping controls at different layers so that failure of any single control does not compromise the enterprise. Combines breadth (different layers) with redundancy (multiple controls within layers). Common failure modes include uniform controls, control interdependence, and neglected layers.
• Frameworks are not alternatives. They serve different purposes and are commonly combined. The enterprise's risk picture remains the organising principle; frameworks are instruments that serve it.
• Framework capture is a real risk. Treating one framework as the answer to every question produces internally consistent programmes that are poorly aligned to the enterprise's actual risk. The antidote is to keep the enterprise's risk picture in view.

These ideas are developed throughout the course. Lesson 1.6 applies everything in Unit 1 — assets, objectives, threats, frameworks — to documented enterprise breaches. Unit 2 turns to the technologies that enforce security policy. Module 2 examines architecture and detection in depth. Module 3 addresses governance, compliance, and resilience.