Security Principles, Threats and Risk

Introduction and Context

Network, internet and cloud security is concerned with protecting information, services, devices, identities and business processes that communicate across interconnected systems. Modern organisations rarely operate a single isolated network. Employees use cloud applications, customers access internet-facing services, suppliers connect through application programming interfaces (APIs), and workloads may move between on-premises data centres and public-cloud platforms. This connectivity creates business value, but it also creates opportunities for misuse, disruption and loss.

Security work begins with a disciplined vocabulary and a set of principles. A security professional must be able to distinguish a threat from a vulnerability, an exploit from an attack, and an incident from a risk. These distinctions support sound decisions about controls, priorities and accountability.

This chapter introduces the foundational principles of confidentiality, integrity, availability, authentication, authorization, accountability, least privilege and defense-in-depth. It then examines threat actors, attack surfaces, vulnerabilities, exploits and risk, followed by a practical risk-assessment method and an applied case.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the confidentiality, integrity and availability objectives of information security.
2. Distinguish authentication, authorization and accountability.
3. Apply least privilege and defense-in-depth to network, internet and cloud environments.
4. Identify common threat actors, attack surfaces, vulnerabilities and exploits.
5. Explain how risk is assessed and treated.
6. Perform a basic qualitative and quantitative risk analysis.
7. Recommend proportionate controls while considering ethics, governance and compliance.

1. The Core Security Objectives

1.1 Confidentiality

Confidentiality means preventing information from being disclosed to unauthorised people, systems or processes. Examples include protecting customer records from unauthorised viewing, encrypting traffic across an untrusted network and restricting cloud-storage access to approved identities.

Confidentiality controls include access control, encryption, data classification, secure authentication, network segmentation and privacy-preserving procedures. Confidentiality is not identical to secrecy: an organisation may legitimately share information with authorised parties while still maintaining confidentiality.

1.2 Integrity

Integrity means preserving the accuracy, completeness and trustworthiness of information and systems. An attacker who changes a bank-account number in an invoice has violated integrity even if the data remains confidential. Integrity controls include cryptographic hashes, digital signatures, authenticated database transactions, change management, backups and file permissions.

Integrity has two related dimensions. Data integrity concerns whether information has been altered improperly. System integrity concerns whether software, configurations and operating systems remain in an authorised and trustworthy state.

1.3 Availability

Availability means that authorised users can access systems and information when required. Distributed denial-of-service attacks, ransomware, hardware failures, misconfigured cloud resources and power interruptions can all reduce availability.

Availability is supported by redundancy, resilient architecture, capacity planning, backups, disaster recovery, monitoring and tested incident-response procedures. Availability is not simply a technical property. A system available for only a few seconds each day is not operationally available, and a system that is online but unusably slow may fail its service objective.

1.4 The CIA Triad and Its Limits

Confidentiality, integrity and availability are commonly called the CIA triad. They provide a useful starting point, but they do not describe every security requirement. Privacy, authenticity, non-repudiation, safety and resilience may also be important. For example, a digitally signed message can support integrity and authenticity, while audit records support accountability.

Security objectives can conflict. Strong encryption may increase processing overhead; extensive availability may require additional access paths; and collecting detailed logs may assist accountability while creating privacy obligations. Professional security design therefore balances objectives in relation to business context and legal requirements.

2. Identity, Access and Accountability

2.1 Authentication

Authentication is the process of establishing that a user, device or service is the entity it claims to be. Common authentication factors are:

• Knowledge: something the subject knows, such as a password or PIN.
• Possession: something the subject has, such as a hardware token or authenticator application.
• Inherence: something the subject is, such as a fingerprint.
• Location or behaviour: contextual evidence such as a trusted network or normal sign-in pattern.

Multi-factor authentication (MFA) uses two or more independent factor categories. Using a password and a second password is not true MFA because both are knowledge factors. MFA reduces the effect of stolen passwords, although phishing-resistant methods such as security keys are generally stronger than one-time codes entered into a fraudulent website.

Authentication also applies to machines. Cloud workloads, APIs and network devices require service identities, certificates, tokens or other credentials. Shared accounts weaken authentication because actions cannot be reliably linked to an individual.

2.2 Authorization

Authorization determines what an authenticated entity is permitted to do. It should be based on a defined policy and evaluated for every protected resource or action. Common models include:

• Discretionary access control (DAC): resource owners can grant access.
• Mandatory access control (MAC): centrally enforced labels and clearance rules determine access.
• Role-based access control (RBAC): permissions are assigned to job roles.
• Attribute-based access control (ABAC): decisions use attributes such as department, device health, location, resource sensitivity and time.

Authentication answers “Who are you?” Authorization answers “What may you do?” Confusing these functions can produce serious weaknesses. A valid employee account should not automatically be able to read every database or administer every cloud subscription.

2.3 Accountability and Non-Repudiation

Accountability means that actions can be attributed to responsible identities and reviewed. It depends on unique accounts, reliable time sources, audit logs, monitoring, retention policies and appropriate protection against log alteration. Non-repudiation is a stronger concept, often supported by digital signatures and legal or procedural controls, intended to make it difficult for a party to deny an action.

Logs should record relevant events such as successful and failed authentication, privilege changes, administrative commands, sensitive-data access and security-alert decisions. Logging everything without a purpose can create excessive cost, privacy risk and unmanageable volumes. Logs must also be protected because attackers commonly attempt to delete or modify evidence.

2.4 Least Privilege

Least privilege means granting only the permissions necessary for an identity, process or device to perform an authorised task, for only as long as necessary. It applies to people, applications, containers, virtual machines, service accounts and network services.

Practical measures include separate standard and administrative accounts, just-in-time elevation, time-limited credentials, narrowly scoped cloud policies, removal of dormant accounts and periodic access reviews. Least privilege limits the damage caused by stolen credentials or compromised software. It is not the same as denying all access; excessive restriction can encourage unsafe workarounds and prevent legitimate operations.

2.5 Separation of Duties

Separation of duties divides sensitive activities among more than one person or role. For example, one employee may create a supplier record while another approves payment. In cloud operations, a developer may deploy code to a test environment while a controlled release process authorises production deployment. Separation of duties reduces fraud and error, but it must be designed carefully so that emergency operations remain possible and auditable.

3. Defense-in-Depth

Defense-in-depth uses multiple, partially independent safeguards so that failure of one control does not expose the entire system. A layered design may include:

1. Governance: policies, risk ownership, training and legal requirements.
2. Physical protection: controlled facilities, power resilience and hardware security.
3. Network controls: segmentation, firewalls, secure routing, intrusion detection and egress filtering.
4. Identity controls: MFA, privileged-access management and conditional access.
5. Host and workload controls: patching, endpoint detection, secure configuration and application allow-listing.
6. Data controls: encryption, classification, backups, key management and data-loss prevention.
7. Monitoring and response: centralised logs, alert triage, containment and recovery.

Layers should be meaningfully different. Deploying several identical firewalls may provide less diversity than combining network segmentation, identity controls, secure coding and monitoring. Defense-in-depth does not guarantee security: poorly configured layers can create false confidence, and controls may share a common failure such as a compromised identity provider or stolen administrative key.

Zero Trust is a contemporary architectural approach that complements defense-in-depth. It assumes that network location alone does not establish trust. Access decisions should consider identity, device state, resource sensitivity, requested action and relevant context, with continuous verification where appropriate. Zero Trust is not a single product and does not mean that trust can literally be eliminated.

4. Threats, Actors, Vulnerabilities and Exploits

4.1 Threat and Threat Actor

A threat is a potential cause of harm to an asset. A threat actor is the person, group or process that may intentionally or accidentally create that harm. Common actors include:

• cybercriminals seeking financial gain;
• nation-state or state-sponsored groups pursuing intelligence or disruption;
• hacktivists motivated by ideology or publicity;
• insiders, including malicious, negligent or compromised employees;
• competitors or contractors with inappropriate access; and
• automated malware, bots and scanning systems.

Motivation, capability, opportunity and resources vary. A technically sophisticated actor may use custom tools, while a less sophisticated actor may rely on publicly available malware or stolen credentials.

4.2 Asset and Attack Surface

An asset is something valuable that requires protection, including data, systems, credentials, services, reputation and safety. An attack surface is the collection of points through which an attacker may attempt access or influence. It includes internet-facing ports, APIs, remote-access services, identities, endpoints, cloud-management interfaces, software dependencies, third-party connections and human processes.

Cloud environments can expand the attack surface through exposed storage, overly broad identity policies, insecure APIs, unmanaged workloads and inherited service configurations. The attack surface is dynamic: a new application, supplier connection or temporary test resource may create a new exposure.

4.3 Vulnerability

A vulnerability is a weakness that can be exploited. It may be technical, such as an unpatched flaw or insecure default configuration, or non-technical, such as inadequate approval procedures or insufficient staff training. Vulnerability severity depends on context. A flaw in an isolated laboratory system may be less dangerous than the same flaw in an internet-facing system containing sensitive data.

Vulnerabilities may arise from design, implementation, deployment, operation or retirement. Secure development, asset inventories, vulnerability scanning, penetration testing, patch management and configuration review help identify them. Scanning does not prove that no vulnerabilities exist; it is limited by coverage, tool quality and the tester’s assumptions.

4.4 Exploit, Attack and Incident

An exploit is a method, code, technique or sequence of actions that takes advantage of a vulnerability. An attack is an attempt to compromise confidentiality, integrity or availability. An incident is a security event or series of events that may compromise operations, information or policy compliance and requires investigation or response.

These terms describe different stages. A vulnerability may exist without being exploited. An exploit may be attempted but blocked. A successful attack may or may not become a reportable incident, depending on impact and organisational policy. Accurate terminology improves triage and reporting.

4.5 Common Attack Patterns

Examples include phishing and business-email compromise, credential stuffing, brute-force attacks, malware delivery, ransomware, exploitation of unpatched services, injection attacks, insecure direct object references, denial-of-service, supply-chain compromise and cloud misconfiguration. A useful analysis asks what precondition the attack requires and which control can interrupt the sequence.

The Cyber Kill Chain and MITRE ATT&CK are examples of frameworks used to describe adversary behaviour. They support detection and defensive planning, but no framework captures every attack and none should replace local evidence and risk analysis.

5. Risk and Risk Assessment

Risk is the possibility that a threat will exploit a vulnerability and cause harm to an asset. In a basic qualitative model:

Likelihood expresses how probable or plausible the harmful event is within a defined period; impact expresses the magnitude of consequences. In qualitative assessment, values such as Low, Medium and High are categories rather than precise numerical probabilities. A risk matrix can help prioritise work, but its ratings are not measurements unless supported by a defined scale and evidence.

A more explicit probability-based model is:

Here, P(Event) is the probability of the specified event during a stated period, and Loss(Event) is the monetary or other measurable loss if it occurs. The model assumes that the event definition, time period and loss measure are clear. It is useful for comparing alternatives, but probability estimates may be uncertain and some impacts—such as safety or reputational damage—are difficult to express in money.

For recurring loss scenarios, organisations may use:

where ALE is annualised loss expectancy, SLE is single-loss expectancy and ARO is annual rate of occurrence. SLE is the estimated loss from one occurrence, and ARO is the expected number of occurrences per year. This is an estimation model, not a prediction; it assumes that the estimates are meaningful and that repeated events can reasonably be represented by an average annual rate.

A Practical Risk-Assessment Process

1. Establish scope and context. Identify systems, owners, business processes, legal obligations and assessment period.
2. Identify assets and dependencies. Include data, identities, suppliers, cloud services and recovery requirements.
3. Identify threats and vulnerabilities. Use incident history, threat intelligence, architecture review, scanning and interviews.
4. Estimate likelihood and impact. Consider exposure, actor capability, existing controls and plausible consequences.
5. Record and prioritise risks. State the asset, threat, vulnerability, consequence, owner and evidence.
6. Select treatment. Avoid, reduce, transfer or accept the risk.
7. Monitor and review. Reassess after major changes, incidents, new vulnerabilities or changes in business purpose.

Risk treatment does not always mean purchasing a security product. Risk may be reduced by redesigning a service, removing unnecessary exposure, improving identity governance, changing a process or accepting a residual risk with documented approval. Risk transfer, such as insurance or contractual allocation, does not eliminate the underlying technical risk.

Worked Example: Qualitative and Quantitative Reasoning

An organisation exposes a remote administration service to the internet. It estimates a medium likelihood of credential compromise and a high impact because successful access could disrupt critical operations. The resulting qualitative rating is high under its approved matrix, so management prioritises MFA, removal of direct internet exposure, privileged-access controls and monitoring.

Suppose a separate estimate assigns a 0.20 annual probability to a defined ransomware event and estimates the resulting loss at £50,000. The expected annual loss is:

This does not mean that exactly £10,000 will be lost each year. It is an expected value used for comparison. If a control costs £4,000 per year and reduces the probability to 0.05, the revised expected loss is £2,500, producing an estimated reduction of £7,500 before considering implementation effects and other benefits. A decision must also consider uncertainty, downtime, legal duties and safety—not only the arithmetic.

6. Applied Case: Northbridge Medical Supplies

The following is an illustrative case.

Background

Northbridge Medical Supplies is a regional distributor using a public-cloud customer portal, an enterprise resource-planning system and a warehouse network. Staff work remotely, and a logistics supplier connects through an API. The organisation stores customer contact details, purchase histories and limited regulated information.

Problem

A review found that several administrators shared a cloud account, MFA was optional for remote access, a test storage bucket had been publicly readable, and the supplier API accepted broad permissions. Logs were retained for only seven days. No confirmed breach had occurred, but the attack surface and potential impact were significant.

Analysis

The shared account weakened authentication and accountability. Optional MFA increased the likelihood that stolen passwords could be used. Public storage threatened confidentiality. Broad API permissions violated least privilege and could allow a compromised supplier account to modify orders. Short log retention would hinder investigation. The principal risks were unauthorised disclosure, fraudulent order changes and operational disruption.

Approach and Solution

Northbridge created unique accounts and separate administrative roles, enforced phishing-resistant MFA for privileged users, and placed routine administration behind a controlled access gateway. The storage bucket was made private, with encryption and automated configuration checks. The API was redesigned with narrowly scoped service identities, request validation, rate limits and monitoring. Network segmentation separated warehouse devices from administrative systems. Logs were centralised, protected from ordinary administrators and retained according to business and legal requirements. A tested backup and recovery procedure was added.

Outcome

The controls reduced exposure and improved the organisation’s ability to detect and investigate misuse. Residual risks remained, including supplier compromise and social engineering. Management documented ownership, review dates and acceptance criteria rather than claiming that the environment was risk-free.

Learning Points

The case demonstrates that security is a system of interacting controls. MFA alone would not have corrected excessive API permissions; encryption alone would not have prevented fraudulent changes; and logging without unique identities would have limited accountability. Effective security combines principles, architecture, operations and governance.

7. Governance, Ethics and Professional Practice

Security professionals have authority that can affect privacy, employment, access to essential services and organisational reputation. Monitoring should have a legitimate purpose, be proportionate, use the minimum necessary data and follow applicable law and policy. Penetration testing requires written authorisation, defined scope, safety limits and responsible handling of discovered information.

Organisations should assign risk owners, maintain asset and data inventories, document exceptions, test controls and report material incidents according to applicable requirements. Privacy and security are related but distinct: security protects information and systems, while privacy concerns the appropriate collection, use, disclosure and retention of information about people.

Responsible vulnerability disclosure gives affected parties an opportunity to remediate before public release, while avoiding unnecessary harm. Professionals should not access systems merely because they are technically exposed. Capability does not constitute permission.

8. Contemporary Developments and Best Practices

Cloud shared-responsibility models require the provider and customer to understand their respective duties. Providers may secure underlying facilities and managed services, while customers remain responsible for identities, data, configurations and workloads according to the service model. The exact boundary differs between infrastructure, platform and software services.

Artificial intelligence can assist detection, log analysis, code review and vulnerability prioritisation. It can also produce inaccurate conclusions, expose sensitive data through unsafe prompts, generate insecure code or enable more convincing phishing. AI outputs require human review, data governance and testing. Automation should be used to improve consistency without removing accountability.

Sound foundational practice includes maintaining accurate inventories, applying secure defaults, patching according to risk, enforcing MFA, minimising privileges, segmenting critical systems, encrypting sensitive data, testing backups, centralising useful logs, rehearsing incident response and reviewing third-party access. Controls should be measured by outcomes and tested in operation, not merely documented.

Chapter Summary

Security objectives are commonly expressed through confidentiality, integrity and availability, supported by authentication, authorization and accountability. Authentication establishes identity; authorization determines permitted actions; accountability enables actions to be attributed and reviewed. Least privilege limits permissions to what is necessary, while defense-in-depth combines independent layers so that one failure does not expose the whole environment.

Threat actors exploit weaknesses across an organisation’s attack surface. A vulnerability is a weakness, an exploit is a method for taking advantage of it, and risk describes the potential for harm. Risk assessment requires defined scope, asset and dependency identification, threat and vulnerability analysis, likelihood and impact estimation, treatment decisions and continuing review. Quantitative models such as expected loss and ALE can support decisions, but their results depend on assumptions and uncertain estimates.

Professional practice requires proportionate controls, ethical authorization, privacy awareness, governance, clear ownership and honest communication of residual risk. In network, internet and cloud environments, secure outcomes arise from the combined use of identity protection, least privilege, segmentation, secure configuration, monitoring, recovery and informed human judgment.

Key Terms

Accountability: The ability to attribute actions to responsible identities and review them.

Asset: Something valuable that requires protection, such as data, systems, services or reputation.

Attack surface: The set of points through which an attacker may attempt access or influence.

Authentication: Establishing that an entity is who or what it claims to be.

Authorization: Determining which actions an authenticated entity may perform.

Availability: Ensuring authorised access to systems and information when required.

CIA triad: Confidentiality, integrity and availability as foundational security objectives.

Defense-in-depth: The use of multiple, complementary security layers.

Exploit: A method, technique or code that takes advantage of a vulnerability.

Integrity: The accuracy, completeness and trustworthiness of data and systems.

Least privilege: Granting only the permissions necessary for an authorised task.

Likelihood: An estimate of how probable or plausible a harmful event is in a defined context.

Multi-factor authentication: Authentication using at least two independent factor categories.

Risk: The possibility that a threat will exploit a vulnerability and cause harm.

Risk treatment: A decision to avoid, reduce, transfer or accept a risk.

Threat: A potential cause of harm to an asset.

Threat actor: A person, group or process capable of causing a threat.

Vulnerability: A weakness that can be exploited.

Review Questions

Short Answer Questions

1. Define confidentiality, integrity and availability.
2. What is the difference between authentication and authorization?
3. Explain the principle of least privilege.
4. Distinguish a vulnerability from an exploit.
5. Why are unique user accounts important for accountability?

Long Answer Questions

1. Explain how defense-in-depth can be applied to a cloud-hosted business application.
2. Compare RBAC and ABAC, including a situation in which each may be appropriate.
3. Describe a complete risk-assessment process from scoping through review.
4. Discuss the relationship between MFA, least privilege and accountability.
5. Explain why security and privacy should be considered together but not treated as identical concepts.

Analytical / Application Questions

1. A company discovers that a public API uses a shared administrator credential and connects directly to a production database. Identify the assets, threats, vulnerabilities and immediate control priorities.
2. A proposed control costs £6,000 annually and is estimated to reduce expected annual loss from £18,000 to £5,000. Analyse the financial comparison and identify non-financial factors that should affect the decision.
3. Design a layered security approach for a remote workforce accessing cloud applications and warehouse systems. Justify the controls using confidentiality, integrity, availability, authentication, authorization, accountability, least privilege and defense-in-depth.

Multiple Choice Questions with Answers

Question 1

Which security objective is primarily concerned with preventing unauthorised disclosure of information?

A. Availability

B. Confidentiality

C. Integrity

D. Accountability

Correct Answer: B. Confidentiality

Question 2

Which statement best describes authorization?

A. Proving the identity of a user

B. Recording a user’s actions

C. Determining what an authenticated entity may do

D. Encrypting information in transit

Correct Answer: C. Determining what an authenticated entity may do

Question 3

Which example provides true multi-factor authentication?

A. A password and a PIN

B. Two different passwords

C. A password and a hardware security key

D. A username and an email address

Correct Answer: C. A password and a hardware security key

Question 4

What is the main purpose of least privilege?

A. To give every employee administrator access

B. To limit permissions to those necessary for an authorised task

C. To eliminate the need for authentication

D. To make all systems publicly accessible

Correct Answer: B. To limit permissions to those necessary for an authorised task

Question 5

Which item is an attack surface?

A. A documented security policy only

B. An internet-facing API

C. A completed incident report

D. A backup stored offline

Correct Answer: B. An internet-facing API

Question 6

Which statement correctly distinguishes a vulnerability from an exploit?

A. A vulnerability is a weakness; an exploit takes advantage of it

B. A vulnerability is always an attack; an exploit is always a policy

C. A vulnerability is a security control; an exploit is a backup

D. They are identical terms

Correct Answer: A. A vulnerability is a weakness; an exploit takes advantage of it

Question 7

In the basic model Risk = Likelihood × Impact, what does impact represent?

A. The number of passwords in a system

B. The magnitude of consequences if the event occurs

C. The age of the software

D. The number of security controls deployed

Correct Answer: B. The magnitude of consequences if the event occurs

Question 8

If the probability of an event is 0.10 and its estimated loss is £40,000, what is the expected loss?

A. £400

B. £4,000

C. £40,000

D. £400,000

Correct Answer: B. £4,000

Question 9

Which practice most directly improves accountability?

A. Using one shared administrator account

B. Deleting logs after every shift

C. Using unique accounts and protected audit logs

D. Disabling time synchronization

Correct Answer: C. Using unique accounts and protected audit logs

Question 10

What is a central idea of defense-in-depth?

A. Relying on one highly advanced control

B. Using multiple complementary layers so one failure is less damaging

C. Removing all network segmentation

D. Allowing trust based only on network location

Correct Answer: B. Using multiple complementary layers so one failure is less damaging