Identity, Access and Network Security

Introduction

Identity and access management (IAM) and network security are central to cybersecurity because most attacks seek either to impersonate a legitimate user, obtain excessive privileges, or move through a network after an initial compromise. Cryptography supports these controls by protecting passwords, credentials, sessions, and communications, but cryptography alone does not decide who should be trusted or what that person may do.

A secure environment therefore combines four related functions: identifying an entity, authenticating its claimed identity, authorising permitted actions, and recording activity for accountability. These functions operate across users, administrators, applications, devices, services, and automated processes. Network controls such as firewalls, segmentation, virtual private networks (VPNs), Transport Layer Security (TLS), and wireless security mechanisms then restrict and protect communication between those entities.

Learning Objectives

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

• distinguish identification, authentication, authorisation, and accounting;
• explain passwords, multifactor authentication, federation, and single sign-on;
• apply role-based access control and principles of least privilege;
• describe privileged access management and secure administration;
• explain firewall operation, network segmentation, VPNs, TLS, and wireless security;
• analyse an access-control and network-security problem and recommend proportionate controls;
• recognise governance, privacy, usability, and ethical issues in identity and access decisions.

1. The Identity and Access Security Model

1.1 Identification, authentication, authorisation, and accounting

These terms describe different stages of an access decision:

1. Identification is the presentation of an identity claim, such as a username, email address, device identity, or service name.
2. Authentication tests whether the claimant controls evidence associated with that identity.
3. Authorisation determines which resources and operations the authenticated entity may use.
4. Accounting—often called auditing or accountability—records relevant events so that activity can be reviewed.

A useful model is: “Who are you?”, “Can you prove it?”, “What may you do?”, and “What did you do?” Confusing these stages creates weaknesses. A username identifies but does not authenticate a user. Authentication does not automatically grant permission to read every database. Logging an event does not prevent the event.

Authentication factors are commonly classified as:

Multifactor authentication (MFA) requires evidence from at least two independent factor categories. Entering a password and answering a second password question is generally not strong MFA because both are knowledge factors. A password combined with a cryptographic security key is stronger.

1.2 The access-control decision

An access decision can be represented conceptually as:

Here, User may be a human or service, Resource is the protected object, Action is an operation such as read or delete, and Context may include time, device health, location, and risk. The policy function returns Permit or Deny. This is a conceptual model rather than a numerical equation; its quality depends on correctly defined policies and trustworthy input data.

A sound policy applies least privilege: an entity receives only the access necessary for an authorised task, for only as long as necessary. Need to know limits access to information required for a particular duty. Separation of duties distributes sensitive activities among different people or roles so that one person cannot complete an inappropriate transaction alone.

1.3 Identity life-cycle management

Identity security begins before account creation and continues through change, suspension, and removal. A typical life cycle includes:

• identity proofing and approval;
• account creation and assignment of attributes;
• credential enrolment;
• periodic access review;
• changes caused by transfer or promotion;
• suspension after risk indicators or inactivity;
• immediate deprovisioning when employment or a contract ends.

The joiner–mover–leaver problem is especially important. A mover may retain permissions from a previous role, producing privilege accumulation. A leaver whose account remains active can provide an attacker with a valid route into the organisation. Automated provisioning connected to authoritative human-resources or student-record systems reduces delay, but automation must be monitored because incorrect source data can propagate excessive access.

2. Authentication Technologies and Practices

2.1 Passwords and credential storage

Passwords remain common but are vulnerable to phishing, reuse, credential stuffing, guessing, malware, and database theft. Organisations should encourage long, unique passwords and use password managers where appropriate. Security controls should avoid unnecessary forced periodic changes that cause predictable patterns, while requiring a change when compromise is suspected.

A server should not store a password in plaintext. It should store a password-derived verifier produced by a password-hashing function with a unique salt. A salt is not secret; its purpose is to ensure that identical passwords produce different stored values and to frustrate precomputed tables. Password-hashing algorithms should be deliberately expensive in computation or memory, such as Argon2id, scrypt, or an appropriately configured bcrypt implementation. Ordinary fast hashes designed for data integrity are unsuitable for password storage because attackers can test guesses rapidly.

2.2 Cryptographic authentication

Public-key authentication uses a private key retained by the user or device and a corresponding public key registered with a service. During authentication, the claimant proves possession of the private key, commonly by signing a challenge. The private key is not transmitted to the service. Hardware security keys can resist many forms of phishing because authentication is bound to the legitimate website origin.

Certificates bind a public key to an identity through a trusted certificate authority. In enterprise environments, certificate-based authentication may identify devices, users, or services. Certificate revocation, expiry, key protection, and trust-store management remain operational responsibilities.

2.3 Federation and single sign-on

Federated identity allows one identity provider to authenticate a user for a relying service. Single sign-on (SSO) improves usability by reducing repeated credential entry and centralising controls such as MFA. It also creates concentration risk: compromise of the identity provider may affect many services. Federation therefore requires strong protection of the identity provider, careful trust configuration, secure token validation, and rapid response to account compromise.

2.4 Adaptive and risk-based authentication

Modern systems may adjust authentication requirements according to risk signals such as an unfamiliar device, impossible travel, malware indicators, or unusual access patterns. Risk-based controls can improve usability, but signals are probabilistic and may be wrong. They should complement—not replace—strong authentication, clear user communication, and human review for high-impact decisions.

3. Authorisation Models

3.1 Access-control lists and capabilities

An access-control list (ACL) attaches permissions to a resource. For example, a document may specify that a finance group can read and edit, while an audit group can read only. ACLs are intuitive for small systems but can become difficult to manage when many users and resources exist.

A capability model gives a subject an unforgeable token or capability representing authority over an object. Capabilities can support delegation, but their distribution, revocation, and protection require careful design.

3.2 Role-based access control

Role-based access control (RBAC) assigns permissions to roles and assigns users to roles. A nurse, lecturer, help-desk analyst, or database administrator may each have a defined permission set. RBAC reduces direct user-permission administration and supports separation of duties.

An effective RBAC design should:

• define roles according to genuine job functions;
• avoid roles that are too broad;
• document role owners and approval authority;
• review role membership regularly;
• support temporary or time-limited assignments;
• test for conflicting roles.

Role explosion occurs when too many narrowly tailored roles are created. Conversely, overly broad roles create excessive privilege. Role engineering is therefore a balance between administrative simplicity and precise control.

3.3 Attribute- and policy-based access control

Attribute-based access control (ABAC) evaluates attributes of the subject, object, action, and environment. For example, a policy might permit a lecturer to access assessment records only for assigned courses, during an approved period, from a managed device. ABAC supports context-sensitive decisions but demands reliable attributes, understandable policies, and effective testing.

In practice, RBAC and ABAC can coexist: a role establishes baseline permissions while attributes refine the decision.

4. Privileged Access Management

Privileged accounts can alter configurations, create users, disable controls, or access sensitive data. Examples include domain administrators, cloud-root accounts, database administrators, and emergency accounts. Because compromise of such an account can produce extensive damage, privileged access management (PAM) should include:

• separate administrative and ordinary user accounts;
• MFA for privileged activity;
• approval and justification for elevated access;
• just-in-time and time-limited privileges;
• secure storage and rotation of secrets;
• session recording or command logging where lawful and proportionate;
• alerting on unusual administrative actions;
• tested break-glass procedures;
• removal of unused and shared privileged accounts.

Administrators should not browse email or the web using a highly privileged session. Workstations used for administration should be hardened, patched, monitored, and separated from ordinary user activity. Shared administrator accounts weaken accountability and should be avoided; if technically unavoidable, compensating controls such as individual check-out, vault logging, and session monitoring are needed.

5. Network Security Architecture

5.1 Firewalls

A firewall enforces traffic policy between network interfaces or security zones. It may filter by addresses and ports, track connection state, inspect applications, or use threat-intelligence information. A stateful firewall understands whether traffic belongs to an established connection; a stateless filter evaluates each packet independently.

A good rule base follows least privilege. It should specify source, destination, service, direction, action, owner, and review date. Rules should be ordered and tested carefully because some devices apply the first matching rule. A final deny rule, meaningful logging, secure management, and regular rule review are important. Logging every packet indiscriminately may create excessive noise; logging denied high-risk traffic and significant permitted actions is usually more useful.

A firewall is not a complete security strategy. It cannot reliably stop malicious activity that is permitted through an authorised channel, prevent compromised endpoints from misusing valid credentials, or replace patching and endpoint protection.

5.2 Segmentation and zero-trust principles

Segmentation divides a network into zones with controlled communication. Typical zones include user devices, servers, management systems, guest wireless, development environments, and critical operational systems. Segmentation limits lateral movement and reduces the blast radius of compromise.

A virtual local area network (VLAN) can separate broadcast domains, but a VLAN alone is not a security boundary if routing between VLANs is unrestricted. Inter-zone traffic should pass through an enforcement point with explicit policy. Microsegmentation applies controls closer to workloads or identities.

Zero trust is an architectural approach based on continuous verification rather than automatic trust based on network location. It does not mean “trust nobody” in a literal operational sense; it means that access is explicitly authorised, least-privileged, monitored, and reevaluated.

5.3 Network address translation and related limits

Network address translation (NAT) changes address information as traffic crosses a device and can conserve IPv4 addresses. It may make unsolicited inbound connections more difficult, but NAT is not equivalent to authentication or a firewall. Security depends on explicit filtering and service configuration.

6. VPNs and Secure Remote Access

A VPN creates a protected tunnel across an untrusted network. It may provide confidentiality, integrity, peer authentication, and controlled access to internal resources. Common designs include remote-access VPNs for individual users and site-to-site VPNs connecting networks.

VPN security depends on strong authentication, modern protocols, secure key exchange, current software, restricted routes, and monitoring. Full-tunnel mode sends all client traffic through the organisation, improving central inspection but increasing bandwidth and privacy responsibilities. Split tunnelling sends only selected traffic through the VPN, improving performance but potentially allowing uninspected paths to sensitive services.

A VPN does not make an infected endpoint trustworthy. Devices should be managed, patched, encrypted, and assessed for health before sensitive access is granted. Remote users should also understand that a VPN protects the tunnel between endpoints; it does not automatically protect data after it reaches an internal application.

7. TLS and Secure Application Communication

Transport Layer Security (TLS) protects application communication by providing confidentiality, integrity, and authentication, normally of the server. During a handshake, the parties negotiate supported parameters, authenticate a server certificate, establish shared session keys, and then protect application data with authenticated encryption or an equivalent secure construction.

TLS does not guarantee that the application itself is safe, that the authenticated server is honest, or that the endpoint is malware-free. Certificate validation must include trust-chain verification, hostname matching, validity checking, and appropriate algorithm and protocol choices. Systems should disable obsolete protocol versions and weak cipher suites, protect private keys, and renew certificates before expiry.

Applications should use TLS consistently, including for administrative interfaces and internal services where sensitive information or credentials are transmitted. Developers must also prevent downgrade attacks, validate tokens correctly, and avoid placing secrets in URLs or logs.

8. Wireless Security

Wireless networks extend the attack surface beyond physically cabled premises. A secure deployment should use current enterprise-grade protection, strong authentication, protected management frames where supported, and separate guest access from internal systems. Enterprise wireless commonly uses 802.1X with an authentication server, allowing individual credentials or certificates rather than one shared password.

Shared wireless passwords are difficult to revoke selectively and may spread beyond authorised users. If a pre-shared key must be used, it should be long, unique, changed when exposure is suspected, and combined with network segmentation.

Wireless risks include rogue access points, evil-twin networks, weak encryption, credential phishing, misconfigured guest isolation, and insecure IoT devices. Users should verify network names carefully and avoid entering sensitive credentials into unexpected captive portals. Organisations should monitor for unauthorised access points and maintain secure default configurations.

9. Applied Case: Protecting a College Network

Background

This illustrative case concerns Northbridge College, which provides student laboratories, staff systems, online learning, finance applications, and remote access. It previously used shared administrator passwords, a flat internal network, a single wireless password, and broad VPN access.

Problem

A phishing attack captured a staff password. The attacker connected through the VPN, reached a file server, and used an unpatched workstation to access shared administrative folders. Investigation was difficult because VPN and administrator activities were incompletely logged.

Analysis

The incident involved several control failures rather than one defective product:

• authentication relied too heavily on a password;
• VPN access did not require MFA or device health checks;
• network segmentation did not restrict lateral movement;
• privileges were broader than job requirements;
• shared administrative credentials weakened accountability;
• logging was incomplete and retention was unclear.

Approach and solution

Northbridge first established an identity inventory and connected account status to its authoritative staff and student records. It introduced MFA, prioritising administrators, finance users, and remote access. Administrative accounts were separated from ordinary accounts, stored in a privileged-access vault, and granted only for approved periods.

The network was divided into staff, student, server, management, guest, and laboratory zones. Firewall rules permitted only documented flows. The VPN was restricted to necessary applications and required managed-device checks. Wireless guest traffic was isolated from internal systems, while staff wireless used individual enterprise authentication.

Critical applications were placed behind TLS, certificates were monitored, and central logging collected authentication, VPN, firewall, and privileged-session events. The college conducted access reviews each term and tested incident response through a simulated compromised account.

Outcome

The changes did not eliminate phishing or compromise risk, but they reduced the likelihood that a stolen password alone would provide access and limited the attacker’s ability to move laterally. Better logs improved investigation speed and accountability. The college also recognised that controls must be reviewed as systems, regulations, and threats change.

Learning points

Security is layered. Strong authentication, least privilege, segmentation, secure protocols, monitoring, and rehearsed response reinforce one another. A control should be evaluated not only by whether it exists, but by whether it is correctly configured, usable, monitored, and maintained.

10. Governance, Ethics, and Limitations

Identity systems process personal and sometimes sensitive information. Organisations should collect only necessary data, define retention periods, restrict administrative access, and explain monitoring practices. Biometric systems require particular care because a fingerprint or facial characteristic cannot be replaced like a password. Biometric matching also carries risks of error and discriminatory impact; it should not be treated as infallible.

Access decisions should be reviewable and contestable, especially in education, employment, health, and public services. Excessive surveillance can damage trust and may conflict with privacy and labour obligations. Security monitoring must therefore be proportionate, access-controlled, and governed by policy and applicable law.

Technical limitations also matter. MFA can be bypassed through social engineering, session theft, or malicious consent flows. Firewalls can be misconfigured. TLS cannot repair insecure endpoints. RBAC can become stale. Zero-trust architectures may increase complexity and operational cost. Effective cybersecurity combines technical controls with training, governance, procurement discipline, vulnerability management, and incident response.

11. Contemporary Developments and Best Practice

Passkeys and WebAuthn-style authentication are increasingly important because they use public-key credentials and can reduce phishing and password reuse. Cloud identity platforms provide scalable federation and conditional access but create dependency on provider availability, configuration correctness, and supply-chain trust. Service accounts, APIs, containers, and machine identities now require life-cycle management comparable to human accounts.

Practical best practice includes:

1. maintain an accurate inventory of identities, devices, applications, and privileged accounts;
2. require MFA for privileged, remote, and high-impact access;
3. use phishing-resistant authentication where feasible;
4. apply least privilege, separation of duties, and time-limited elevation;
5. automate joiner–mover–leaver processes with review and exception handling;
6. segment networks and explicitly control inter-zone traffic;
7. use current TLS and secure wireless protocols;
8. centralise meaningful logs and protect their integrity;
9. test access rules, backup administration, and incident response;
10. review controls for usability, privacy, accessibility, and legal compliance.

Chapter Summary

Identity and access security separates identification, authentication, authorisation, and accounting. Strong practice combines unique identities, robust authentication—preferably MFA and phishing-resistant methods—with least privilege, need to know, separation of duties, RBAC, ABAC where appropriate, and disciplined identity life-cycle management. Privileged accounts require additional controls such as separate credentials, approval, just-in-time access, vaulting, and monitoring.

Network security is layered. Firewalls enforce traffic policy, segmentation limits lateral movement, VPNs protect selected remote connections, TLS secures application communication, and enterprise wireless security protects radio-based access. None of these controls is sufficient alone. Effective protection depends on correct configuration, monitoring, patching, governance, privacy safeguards, and tested response processes.

Key Terms

Identification: Presentation of an identity claim.

Authentication: Verification of a claimed identity.

Authorisation: Decision about permitted actions or resources.

Accounting: Recording and reviewing security-relevant activity.

Multifactor authentication: Authentication using independent factor categories.

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

Need to know: Limiting information access to what a person requires.

Separation of duties: Dividing sensitive responsibilities among actors.

RBAC: Access control based on assigned organisational roles.

ABAC: Access control based on subject, object, action, and context attributes.

Privileged access management: Controls for high-authority accounts and sessions.

Firewall: A device or service enforcing network traffic policy.

Segmentation: Division of a network into controlled security zones.

Zero trust: Continuous, explicit, least-privileged access verification.

VPN: A protected logical tunnel across an untrusted network.

TLS: A protocol providing protected application communication.

Certificate: A digitally signed binding between an identity and a public key.

VLAN: A logical separation of a switched network broadcast domain.

Phishing-resistant authentication: Authentication designed to resist fraudulent website capture.

Identity life cycle: Creation, maintenance, review, suspension, and removal of identities.

Review Questions

Short Answer Questions

1. Distinguish identification from authentication.
2. What is the purpose of a salt in password storage?
3. State two benefits of network segmentation.
4. Why should privileged accounts be separated from ordinary user accounts?
5. What security properties does TLS commonly provide?

Long Answer Questions

1. Explain the identity life cycle and analyse the risks created by poor mover and leaver processes.
2. Compare RBAC and ABAC, including an example in which each is appropriate.
3. Describe how a firewall should be designed, documented, reviewed, and monitored.
4. Explain how MFA, VPN controls, device health, and least privilege should work together for remote access.
5. Discuss the privacy, ethical, and operational limitations of biometric and behavioural authentication.

Analytical / Application Questions

1. A contractor retains access to a finance system after changing projects. Identify the control failures and propose a remediation plan.
2. Design security zones and firewall policy principles for a college containing guest wireless, student laboratories, administrative servers, and management systems.
3. An employee’s password is stolen, but the attacker is stopped by a hardware security key and cannot reach internal servers from the guest network. Identify the layered controls involved and explain how each reduced risk.

Multiple Choice Questions with Answers

Question 1

Which activity determines what an authenticated user is allowed to do?

A. Identification

B. Authentication

C. Authorisation

D. Accounting

Correct Answer: C. Authorisation

Question 2

Which combination is strongest as multifactor authentication?

A. Password and PIN

B. Password and security key

C. Two security questions

D. Username and password

Correct Answer: B. Password and security key

Question 3

What is the primary purpose of a unique password salt?

A. To encrypt network traffic

B. To make identical passwords produce different stored values

C. To replace multifactor authentication

D. To provide a firewall rule

Correct Answer: B. To make identical passwords produce different stored values

Question 4

Which principle grants only the permissions necessary for a task?

A. Least privilege

B. Open access

C. Default allow

D. Single sign-on

Correct Answer: A. Least privilege

Question 5

What is a major purpose of network segmentation?

A. To eliminate the need for patching

B. To increase lateral movement

C. To limit the spread of a compromise

D. To authenticate passwords

Correct Answer: C. To limit the spread of a compromise

Question 6

Which statement about NAT is correct?

A. NAT is equivalent to multifactor authentication

B. NAT automatically encrypts all traffic

C. NAT changes address information and is not itself a complete security control

D. NAT replaces TLS certificates

Correct Answer: C. NAT changes address information and is not itself a complete security control

Question 7

What does TLS primarily protect during application communication?

A. Confidentiality and integrity, with authenticated peers where configured

B. Physical building access

C. Employee role assignment

D. Database backup scheduling

Correct Answer: A. Confidentiality and integrity, with authenticated peers where configured

Question 8

Which practice best supports privileged access management?

A. Using one shared administrator password

B. Granting permanent administrator rights to all staff

C. Using time-limited elevation with logging and approval

D. Disabling all administrative logs

Correct Answer: C. Using time-limited elevation with logging and approval

Question 9

Why is a VLAN alone not necessarily a complete security boundary?

A. VLANs cannot separate broadcast domains

B. Routing between VLANs may be unrestricted

C. VLANs always disable encryption

D. VLANs cannot support wireless networks

Correct Answer: B. Routing between VLANs may be unrestricted

Question 10

Which wireless design is most appropriate for enterprise staff access?

A. One unchanging shared password for every user

B. Open wireless with no segmentation

C. Individual enterprise authentication with internal network controls

D. A hidden network name as the only protection

Correct Answer: C. Individual enterprise authentication with internal network controls