Network Security Foundations and Security Models

Introduction

Network security is the disciplined protection of information, computing systems, communication networks, applications, and services against unauthorized access, misuse, disruption, alteration, and destruction. It is not limited to firewalls or encryption. Contemporary network security combines technical controls, secure architecture, identity management, operational processes, governance, risk analysis, and human judgment.

The subject is especially important because modern organizations operate interconnected and partly outsourced environments. Cloud platforms, mobile devices, industrial systems, software supply chains, remote work, application programming interfaces, and artificial intelligence systems have expanded both capability and exposure. A security failure may affect confidentiality, operational continuity, legal compliance, public safety, and organizational reputation simultaneously.

This chapter establishes the conceptual foundation for later study of cryptography, secure protocols, intrusion detection, identity and access management, vulnerability assessment, and incident response. It introduces the principal security objectives, the structures through which attacks occur, major security design principles, security considerations across networking models, and formal models for confidentiality and integrity.

Learning Objectives

After completing this chapter, a student should be able to:

1. Define essential network-security terminology accurately.
2. Explain confidentiality, integrity, availability, authenticity, accountability, and non-repudiation.
3. Analyze attack surfaces, trust boundaries, and security dependencies.
4. Apply defense-in-depth and zero-trust principles to system design.
5. Relate security concerns to the OSI and TCP/IP models.
6. Explain the Bell–LaPadula and Biba models and their limitations.
7. Represent discretionary access control using an access-control matrix.
8. Evaluate security architecture decisions in a realistic organizational scenario.

1. Security as a Socio-Technical Discipline

Security protects assets against threats by reducing vulnerabilities and limiting the consequences of compromise. An asset is something valuable, such as data, credentials, infrastructure, software, intellectual property, or service availability. A threat is a potential cause of harm. A vulnerability is a weakness that can be exploited. An attack is an intentional or accidental attempt to exploit a vulnerability. A control or countermeasure is a safeguard that reduces likelihood, impact, or both.

Security is therefore not equivalent to secrecy. A system can preserve confidential data while remaining vulnerable to denial-of-service attacks. Conversely, a public website may have no confidentiality requirement for its published content, but its integrity and availability may be critical. Security objectives must be derived from business, legal, safety, and operational requirements.

A useful distinction is between risk and incident. Risk is the possibility that a threat will exploit a vulnerability and produce an undesirable consequence. An incident is an event that actually violates, or threatens to violate, security policy. Risk management includes identification, assessment, treatment, monitoring, and communication of risks. No practical system eliminates all risk; responsible security seeks risk that is understood and acceptable in relation to the value of the protected assets.

Important terminology

2. The Core Security Objectives

2.1 Confidentiality

Confidentiality means preventing unauthorized disclosure of information. It applies to data at rest, data in transit, and data in use. Encryption, access controls, information classification, network segmentation, and secure disposal support confidentiality.

Confidentiality is not identical to privacy. Privacy concerns the appropriate collection, use, retention, and disclosure of information about people. Confidentiality is one technical and organizational means of supporting privacy, but privacy also requires lawful purpose, transparency, minimization, and governance.

2.2 Integrity

Integrity means protecting information and systems against unauthorized or improper modification. Integrity includes correctness, completeness, consistency, and authenticity of data where relevant. Hash functions, message authentication codes, digital signatures, transaction controls, versioning, input validation, and file-integrity monitoring are common mechanisms.

Integrity has several forms. Data integrity concerns stored or transmitted information. System integrity concerns whether software, configurations, and operating behavior remain trustworthy. A system that has not disclosed confidential data may still be unsafe if an attacker changes its routing rules or executable files.

2.3 Availability

Availability means that authorized users can access systems and information when required. Availability depends on capacity, redundancy, maintainability, recovery capability, and resistance to disruption. Backups alone do not guarantee availability: backups must be protected, tested, and restorable within the required recovery time.

Availability is often discussed using recovery objectives. The recovery time objective (RTO) is the maximum acceptable time to restore a service after disruption. The recovery point objective (RPO) is the maximum acceptable period of data loss measured backward from the disruption. These are organizational requirements, not universal technical constants.

2.4 Authenticity and authentication

Authenticity is confidence that an entity, message, data source, or system is genuine. Authentication is the process of verifying an asserted identity or origin. Authentication factors commonly include something known, something possessed, and something inherent. Multi-factor authentication uses two or more independent factor categories; using two passwords is generally not multi-factor authentication.

Authentication does not by itself authorize every action. Authorization is the decision to permit or deny a requested operation after identity, attributes, policy, and context have been considered. A user may authenticate successfully but lack authorization to access a particular database record.

2.5 Accountability

Accountability is the ability to associate actions with responsible entities and to investigate those actions. It depends on reliable identity, event logging, time synchronization, protected audit records, monitoring, and appropriate retention. Accountability is weakened by shared accounts, unprotected logs, incomplete event sources, and excessive administrative privileges.

Accountability is not the same as surveillance. Audit collection must observe legal requirements, proportionality, purpose limitation, access restrictions, and retention policies. Logs should support investigation without creating an uncontrolled secondary store of sensitive personal information.

2.6 Non-repudiation

Non-repudiation provides evidence intended to prevent a party from credibly denying a previous action or communication. Digital signatures, trusted timestamps, certificate management, contractual procedures, and secure audit trails may contribute to non-repudiation.

Non-repudiation is frequently overstated. A digital signature can demonstrate that a private key produced a signature, but it does not automatically prove who controlled the key, whether the signed content was understood, or whether the transaction was legally binding. Key protection, identity proofing, certificate status, and institutional procedures are essential.

3. Attack Surfaces and Trust Boundaries

An attack surface includes network interfaces, exposed services, APIs, authentication endpoints, administrative consoles, removable media, software dependencies, cloud permissions, physical access points, and human processes. Attack-surface analysis asks what can receive input, what can issue commands, what identities are trusted, and what components have connectivity or privilege.

Attack surfaces are dynamic. A new cloud workload, software update, remote-access rule, or third-party integration may introduce exposure. Security teams therefore use asset inventories, service discovery, dependency analysis, vulnerability management, and configuration monitoring to maintain an updated view.

A trust boundary separates components that operate under different security assumptions. Examples include the boundary between the public Internet and an enterprise network, between a web application and a database, between a tenant and a cloud provider, and between a user device and a privileged administration network. Crossing a boundary should require explicit validation rather than implicit trust.

A boundary is not necessarily a physical network perimeter. A single host may contain several boundaries between ordinary users, containers, virtual machines, kernel components, and hardware. Conversely, two network segments may not represent meaningful security separation if they share administrative credentials or have unrestricted routing.

Threat modeling perspective

A practical threat-modeling process identifies assets, entry points, trust boundaries, actors, security objectives, abuse cases, and mitigations. Frameworks such as STRIDE classify common threat types as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. The value of a framework is not its label set alone; it is the disciplined process of connecting threats to concrete architecture and controls.

4. Defense-in-Depth and Zero Trust

4.1 Defense-in-depth

Defense-in-depth uses multiple complementary safeguards so that failure of one control does not expose the entire system. A layered architecture may include secure configuration, endpoint protection, identity controls, network segmentation, encryption, application validation, monitoring, backups, incident response, and physical protection.

Effective layers should be sufficiently independent. Five controls that all depend on the same administrator account do not provide five independent barriers. Defense-in-depth also requires attention to common-mode failure, in which a single cause defeats several controls simultaneously—for example, compromise of a centralized identity provider.

Defense-in-depth must not become uncontrolled complexity. Redundant or contradictory controls can cause unsafe workarounds, administrative errors, and alert fatigue. Layers should have defined purposes, owners, failure modes, and testing procedures.

4.2 Zero trust

Zero trust is an architectural approach that avoids implicit trust based solely on network location. It requires continuous evaluation of identity, device posture, requested resource, application, session context, and policy. Its central idea is often summarized as “never trust, always verify,” although verification is not a single event and cannot guarantee that a verified subject remains safe.

Zero trust commonly involves strong identity, device management, fine-grained authorization, application-level segmentation, least privilege, telemetry, policy enforcement points, and rapid revocation. It is particularly useful where users, workloads, and devices operate across cloud, on-premises, and remote environments.

Zero trust does not mean denying all access, replacing every firewall, or inspecting every packet indefinitely. It is a strategy for reducing implicit assumptions. Legacy systems, unavailable telemetry, operational technology constraints, and emergency access may limit implementation. Migration should be risk-based and should preserve safety and availability.

5. Security Design Principles

The following principles provide reusable guidance for architecture and implementation:

• Least privilege: grant only the permissions necessary for an authorized task and for the required duration.
• Separation of duties: divide critical responsibilities so one person or process cannot complete an abuse-prone operation alone.
• Fail-safe defaults: deny access unless a policy explicitly permits it. Exceptions must be deliberate and auditable.
• Complete mediation: check authorization whenever access is requested, while using safe caching where performance requires it.
• Economy of mechanism: keep security mechanisms simple enough to analyze and maintain.
• Open design: security should not depend on secrecy of design; secrets such as keys must remain protected.
• Least common mechanism: minimize shared mechanisms because shared resources can create unintended information flows.
• Psychological acceptability: controls should be usable; otherwise users may bypass them.
• Defense in depth: combine controls with different failure modes.
• Secure by design and by default: security requirements should be built into architecture and initial configuration rather than added after deployment.
• Fail securely: errors should not disclose secrets or grant unintended privileges.
• Complete and trustworthy logging: record relevant events with protected integrity and controlled access.
• Assume breach: design detection, containment, recovery, and blast-radius limits rather than relying on perfect prevention.

These principles can conflict. Complete mediation may affect performance; separation of duties may reduce convenience; detailed logging may increase privacy risk. Professional design makes such trade-offs explicit and governed.

6. Security Across the OSI and TCP/IP Models

Layered models help locate controls, but attacks frequently cross layers. A vulnerability at one layer may be exploited through another, and secure operation requires coordination across the stack.

The OSI model is a conceptual reference and does not perfectly describe every modern protocol. The TCP/IP model groups functions differently, and many protocols do not fit neatly into one layer. Security controls should therefore be selected according to actual assets, flows, and threats rather than by mechanically assigning one control to one layer.

At the application layer, authorization flaws are often more damaging than perimeter flaws. At the transport and network layers, encryption may protect content while metadata such as endpoints, timing, and volume remains visible. At the physical layer, an attacker with direct hardware access may bypass software assumptions. These observations demonstrate why layered security must be combined with end-to-end reasoning.

7. Formal Security Models

Formal models simplify security reasoning by defining subjects, objects, states, and permitted transitions. They are valuable for policy analysis, but they do not represent every organizational, economic, or human factor.

7.1 Bell–LaPadula model: confidentiality

The Bell–LaPadula model addresses information-flow confidentiality in systems with ordered security levels, such as Unclassified, Confidential, Secret, and Top Secret. A subject and an object each have a security level. The model is based principally on two rules:

• Simple security property (“no read up”): a subject cannot read an object at a higher classification level.
• *-property (“no write down”): a subject cannot write information to a lower classification level.

The second rule prevents a subject from reading highly classified information and then copying it into a lower-level object. The model may permit a subject to read lower-level information and write to a higher-level object, subject to the model’s assumptions.

Bell–LaPadula focuses on confidentiality, not integrity, availability, usability, or covert channels. It also assumes that classifications and trusted subjects are correctly defined. A system may satisfy its rules while still suffering from malicious software, inference, poor administration, or denial of service.

7.2 Biba model: integrity

The Biba model addresses integrity using ordered integrity levels. Its classic rules are:

• Simple integrity property (“no read down”): a subject should not read data from a lower-integrity level, because doing so may contaminate its decisions.
• Integrity *-property (“no write up”): a subject should not write to a higher-integrity object, because untrusted information could contaminate it.
• Invocation property: a subject should not invoke a process at a higher integrity level.

Biba is conceptually opposite to Bell–LaPadula in its read/write direction. It is not a complete integrity theory: integrity also involves accuracy, origin, processing correctness, and timely recovery. Real systems often use domain-specific integrity constraints rather than a single total ordering.

7.3 Comparing Bell–LaPadula and Biba

The models illustrate an important design insight: confidentiality and integrity are distinct properties and may impose different access directions. A control designed for one objective should not automatically be assumed to enforce the other.

8. Access-Control Matrices and Practical Authorization

An access-control matrix represents subjects as rows, objects as columns, and permitted operations as cell entries. Operations may include read, write, execute, delete, approve, or administer.

The matrix is a conceptual model; large systems implement it through access-control lists, capability lists, role-based access control, attribute-based access control, policy engines, and database privileges.

An access-control list (ACL) stores permissions associated with an object. A capability list stores the objects and operations a subject is allowed to use. Role-based access control (RBAC) assigns permissions to roles and users to roles. Attribute-based access control (ABAC) evaluates attributes such as department, device posture, location, resource sensitivity, time, and purpose.

A matrix can reveal excessive privilege, toxic combinations of duties, missing audit permissions, and dangerous inheritance. It does not by itself prove that data flows are safe. Indirect access, inference, side channels, delegated authority, emergency access, and compromised applications require additional analysis.

9. Applied Case: Securing a University Research Cloud

The following is an illustrative case.

Background

A university research group stores sensitive health-related research data in a hybrid cloud. Researchers connect from campus and remote locations. A web portal, analysis notebooks, object storage, a relational database, and an external collaboration service exchange data.

Problem

An assessment identifies a flat virtual network, shared administrator credentials, long-lived API keys, unrestricted researcher access to production data, incomplete logging, and backups accessible from the same administrative domain. The organization has strong perimeter firewalls but cannot confidently determine which user or service accessed a particular dataset.

Analysis

The principal attack surfaces are the portal, notebook environment, APIs, identity provider, cloud management plane, collaboration integration, and backup interfaces. Important trust boundaries exist between the public Internet and the portal, the portal and data services, researchers and production data, and the university and the external collaboration provider.

The risks are not limited to external attackers. A stolen researcher credential could expose sensitive data; a compromised notebook could use service permissions to reach the database; a malicious insider could alter results; and ransomware could affect both production data and backups. The security objectives are confidentiality and integrity of research data, availability of analysis services, accountability for access, and compliance with data-governance obligations.

Approach and solution

The university adopts a staged architecture:

1. Federated identity and phishing-resistant multi-factor authentication replace shared accounts.
2. Administrative duties are separated, with time-limited privileged access and approval for sensitive operations.
3. Researchers receive role- and attribute-based access to approved datasets rather than unrestricted production access.
4. The portal, notebooks, databases, and management interfaces are segmented by application function and trust level.
5. Service identities use short-lived credentials with narrowly scoped permissions and automated rotation.
6. Encryption protects data in transit and at rest, while key-management responsibilities are separated from application administration.
7. Centralized, tamper-evident logs record authentication, authorization, data export, configuration change, and administrative events.
8. Backups are isolated from ordinary administrative paths, tested regularly, and governed by defined recovery objectives.
9. Detection rules identify unusual downloads, impossible travel, privilege escalation, and access from unmanaged devices.
10. A documented incident process supports containment, evidence preservation, notification, and recovery.

Outcome

The architecture does not eliminate risk, but it reduces implicit trust and limits blast radius. A compromised notebook cannot automatically access every dataset. A stolen credential is less useful without the required authentication factor and device posture. Investigators can associate significant actions with accountable identities, and isolated backups improve recovery from destructive attacks.

Learning points

The case demonstrates that security is an architectural property rather than a single product. Zero trust, defense-in-depth, least privilege, separation of duties, and accountability reinforce one another. It also demonstrates the need to balance security with research usability: excessively restrictive controls may encourage researchers to create unsanctioned copies or services.

10. Limitations, Governance, and Contemporary Developments

Security models are abstractions. Bell–LaPadula and Biba do not fully address privacy, availability, safety, economic incentives, machine learning risks, social engineering, or complex distributed applications. Formal access rules can also produce a false sense of assurance if identity proofing, configuration, logging, and operational discipline are weak.

Governance determines who may define policy, approve exceptions, investigate events, retain evidence, and accept residual risk. Organizations should align security architecture with applicable privacy, records-management, sectoral, contractual, and critical-infrastructure requirements. Legal compliance is a baseline, not proof of effective security.

Artificial intelligence introduces both defensive and offensive implications. AI can assist with anomaly detection, code analysis, alert triage, and threat intelligence, but models may produce false positives, leak sensitive prompts, inherit biased data, or be manipulated through adversarial inputs. AI systems require conventional controls: strong identity, least privilege, protected data, monitoring, human oversight, and tested failure handling. A model’s output should not automatically authorize high-impact actions without appropriate controls.

Contemporary best practice emphasizes secure development lifecycles, software supply-chain provenance, dependency management, identity-centric architecture, continuous configuration assessment, resilience engineering, and tested recovery. Organizations should measure meaningful outcomes such as reduction of exploitable exposure, time to detect and contain incidents, restoration performance, privileged-access review quality, and coverage of critical assets. Counting tools or alerts alone is not a reliable measure of security.

Chapter Summary

Network security protects assets against unauthorized disclosure, alteration, misuse, and disruption. Its foundational objectives are confidentiality, integrity, and availability, supplemented by authenticity, accountability, and non-repudiation. Authentication verifies identity or origin, while authorization determines permitted action; neither should be confused with the other.

Attack-surface analysis identifies reachable entry points, and trust-boundary analysis identifies changes in authority or security assumptions. Defense-in-depth uses complementary layers, whereas zero trust minimizes implicit trust and evaluates access using identity, resource, device, context, and policy. Secure design principles—including least privilege, separation of duties, fail-safe defaults, complete mediation, economy of mechanism, secure defaults, and assume-breach thinking—guide practical architecture.

Security concerns exist across physical, data-link, network, transport, application, and governance domains. The OSI and TCP/IP models assist analysis but do not eliminate cross-layer dependencies. Bell–LaPadula formalizes confidentiality through no-read-up and no-write-down rules. Biba formalizes integrity through no-read-down and no-write-up rules. Access-control matrices provide a structured representation of subjects, objects, and operations, which can be implemented through ACLs, capabilities, RBAC, and ABAC.

Finally, security models are aids to reasoning rather than complete descriptions of reality. Effective security requires governance, usable controls, reliable operations, continuous assessment, resilience, privacy protection, and informed management of residual risk.

Key Terms

Confidentiality: Protection against unauthorized disclosure of information.

Integrity: Protection against unauthorized or improper modification.

Availability: Accessibility of systems and information when authorized users require them.

Authenticity: Confidence that an entity, message, or source is genuine.

Authentication: Verification of an asserted identity or origin.

Authorization: Decision to permit or deny a requested operation.

Accountability: Ability to associate actions with responsible entities.

Non-repudiation: Evidence intended to prevent credible denial of an action or communication.

Asset: A valuable resource requiring protection.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited.

Attack surface: The collection of reachable points through which attacks may occur.

Trust boundary: A boundary across which security assumptions or authority change.

Defense-in-depth: Use of multiple complementary security layers.

Zero trust: Architecture that avoids implicit trust based on network location.

Least privilege: Granting only the access necessary for an authorized task.

Bell–LaPadula model: Formal model primarily concerned with confidentiality.

Biba model: Formal model primarily concerned with integrity.

Access-control matrix: Representation of subjects, objects, and permitted operations.

Separation of duties: Division of critical responsibilities among different entities.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.
2. What is the difference between an attack surface and a trust boundary?
3. State the confidentiality and integrity objectives of the CIA triad.
4. What does the Bell–LaPadula “no write down” rule prevent?
5. Why are shared administrator accounts harmful to accountability?

Long Answer Questions

1. Explain the CIA triad and discuss how encryption, access control, monitoring, backups, and incident response contribute to its objectives.
2. Compare defense-in-depth with zero trust. Explain how they can be combined in a cloud-based organization.
3. Explain the Bell–LaPadula and Biba models, including their rules, purposes, and limitations.
4. Describe how an access-control matrix can be transformed into RBAC or ABAC for a large enterprise.
5. Discuss the major security considerations across the OSI or TCP/IP layers and explain why layer-by-layer controls are insufficient by themselves.

Analytical / Application Questions

1. A hospital allows clinicians to access patient records from unmanaged personal devices using passwords alone. Identify the assets, attack surfaces, trust boundaries, and security principles that should guide redesign.
2. A financial analyst can approve a payment, modify the beneficiary account, and delete audit records. Model the problem using an access-control matrix and recommend controls based on least privilege and separation of duties.
3. A research service must read public data and write validated results into a high-integrity repository. Explain how Biba-style integrity rules, application validation, service identities, and audit controls could be combined without creating an unusable workflow.

Multiple Choice Questions with Answers

Question 1

Which security objective primarily concerns preventing unauthorized disclosure of information?

A. Availability

B. Confidentiality

C. Accountability

D. Non-repudiation

Correct Answer: B. Confidentiality

Question 2

Which statement best distinguishes authentication from authorization?

A. Authentication grants every permission, while authorization encrypts data.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication records events, while authorization restores services.

D. Authentication provides availability, while authorization provides physical security.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 3

Which situation most directly represents a trust boundary?

A. Two identical files stored in one directory

B. A boundary between a public web portal and an internal database service

C. A user changing the color of an interface

D. A backup being compressed before storage

Correct Answer: B. A boundary between a public web portal and an internal database service

Question 4

Which principle requires access to be denied unless explicitly permitted by policy?

A. Fail-safe defaults

B. Open design

C. Psychological acceptability

D. Least common mechanism

Correct Answer: A. Fail-safe defaults

Question 5

Under the classic Bell–LaPadula model, which action is prohibited?

A. Reading a lower-level object

B. Writing information to a higher-level object

C. Reading an object at the subject’s level

D. Writing information to an object at the subject’s level

Correct Answer: B. Writing information to a higher-level object

Question 6

Which rule is associated with the classic Biba integrity model?

A. No read up

B. No write down

C. No read down

D. No authentication required

Correct Answer: C. No read down

Question 7

What is the principal purpose of an access-control matrix?

A. To calculate network bandwidth

B. To represent subjects, objects, and permitted operations

C. To replace all audit logging

D. To determine physical cable lengths

Correct Answer: B. To represent subjects, objects, and permitted operations

Question 8

Which statement best describes zero trust?

A. All internal network traffic is automatically trusted.

B. Access is evaluated using identity, context, resource, and policy rather than location alone.

C. Only external users require authentication.

D. Perimeter firewalls are prohibited.

Correct Answer: B. Access is evaluated using identity, context, resource, and policy rather than location alone.

Question 9

Which control most directly improves accountability?

A. Shared administrator credentials

B. Protected logs linked to individual identities

C. Disabling time synchronization

D. Removing authorization records

Correct Answer: B. Protected logs linked to individual identities

Question 10

A service identity has permission to read every database and administer the operating system, although it only needs one table. Which principle is most clearly violated?

A. Least privilege

B. Open design

C. Psychological acceptability

D. Availability

Correct Answer: A. Least privilege