Security Architecture and Preventive Controls

Introduction

Banking institutions operate in an environment in which confidentiality, integrity, availability, accountability and resilience are inseparable from business performance. A payment platform may process millions of transactions daily, while mobile banking, open-banking APIs, card networks, cloud services, branch systems and third-party processors expand the attack surface. Preventive controls therefore cannot be limited to firewalls or antivirus software. They must form a coherent security architecture that reduces the probability and impact of unauthorised activity.

This chapter examines defence-in-depth and zero-trust design through identity and access management (IAM), privileged access management (PAM), cryptography, tokenisation, network segmentation, endpoint protection, secure configuration, data loss prevention (DLP) and key management. The focus is not merely on technologies, but on control objectives, design trade-offs, governance and implementation in banking environments.

Learning Objectives

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

1. Explain defence-in-depth and zero-trust security architectures.
2. Design IAM and PAM controls according to risk and business need.
3. Distinguish encryption, hashing, digital signatures and tokenisation.
4. Apply segmentation, endpoint, configuration and DLP controls.
5. Explain the lifecycle and governance of cryptographic keys.
6. Evaluate preventive controls in a banking case and identify residual risk.

1. Security Architecture as a Control System

Security architecture is the structured arrangement of policies, processes, technologies, people and trust relationships that protects information assets. It translates business requirements into enforceable controls. A useful architecture begins with assets and business processes, identifies threats and trust boundaries, specifies control objectives, and defines monitoring and recovery dependencies.

The classical CIA triad comprises:

• Confidentiality: information is disclosed only to authorised parties.
• Integrity: information and transactions are accurate, complete and protected from unauthorised alteration.
• Availability: systems and information are accessible when required.

Banking architecture must also address authenticity, non-repudiation, privacy, accountability and resilience. For example, a transaction may be confidential but still unacceptable if its authorisation cannot be demonstrated or if it can be altered in transit.

Defence-in-depth

Defence-in-depth uses multiple, partly independent layers. Typical layers include governance, physical security, identity, application security, network controls, endpoint protection, data security, monitoring and recovery. If one control fails, another should prevent, detect or limit the compromise.

Layering is not equivalent to buying multiple products. Controls must be independent enough to avoid common-mode failure. For example, requiring a password and a security question provides less independence than combining a password with phishing-resistant hardware authentication. Similarly, two network appliances managed through the same compromised administrator account may represent one effective control rather than two.

Zero trust

Zero trust is an architectural approach in which no user, device, application or network location receives implicit trust. Access is continuously evaluated using identity, device posture, resource sensitivity, transaction context and policy. “Never trust, always verify” is a useful slogan, but zero trust does not mean verifying every request in an identical way. It means applying risk-appropriate, explicit and continually reassessed decisions.

A zero-trust policy can be represented conceptually as:

Here, Decision is permit, deny or require additional controls; identity identifies the subject; authentication represents assurance; device describes security posture; resource captures sensitivity; context includes time, location and transaction risk; and policy expresses organisational rules. This is a policy model rather than a universal numerical equation.

Figure: A layered zero-trust architecture in which governance informs identity and policy enforcement around protected services and data.

2. Identity and Access Management

IAM manages the digital identities of customers, employees, contractors, service accounts and applications. Its lifecycle includes enrolment, proofing, authentication, authorisation, review, suspension and deprovisioning.

Authentication and assurance

Authentication establishes confidence that a claimant controls an identity. Factors are commonly classified as:

• knowledge, such as a password;
• possession, such as a hardware security key;
• inherence, such as a biometric characteristic.

Two different passwords are still one factor. Stronger assurance combines independent factors and protects the authentication channel against phishing, replay and credential stuffing. Risk-based authentication may require step-up verification for a new device, unusual geography, high-value transfer or beneficiary change.

Passwords should be individually salted and processed with a slow, memory-hard password-hashing function. Passwords should not be stored using reversible encryption or unsalted fast hashes. Where practical, phishing-resistant public-key authentication is preferable to one-time codes delivered through easily intercepted channels.

Authorisation models

Role-based access control (RBAC) assigns permissions to job roles. It is administratively clear but can create excessive privilege when roles become broad. Attribute-based access control (ABAC) evaluates attributes such as department, transaction value, device assurance and location. ABAC provides finer control but requires reliable attributes and policy governance. Least privilege grants only the permissions necessary for an approved task, for the required duration.

Segregation of duties prevents one person from controlling incompatible stages, such as creating a beneficiary, approving a payment and releasing funds. IAM should support joiner–mover–leaver processes, periodic access certification, dormant-account detection and auditable approval records.

Service and machine identities

Service accounts, API clients, certificates and workload identities can possess extensive access while receiving less scrutiny than human users. They require ownership, purpose, expiration, secret rotation, scoped permissions and monitoring. Shared accounts undermine accountability and should be eliminated or tightly controlled.

3. Privileged Access Management

PAM protects accounts capable of changing security controls, databases, operating systems, payment configurations or production code. Its controls include a separate administrator identity, approval workflows, just-in-time elevation, credential vaulting, session recording, command restrictions, time limits and emergency-access procedures.

A mature PAM design does not merely place administrator passwords in a vault. It reduces standing privilege, validates the administrator and device, restricts the target and records the activity. Break-glass access should be rare, independently reviewed and automatically alerted. PAM logs should be protected from alteration and correlated with change-management records.

A practical control sequence is:

1. identify the requested administrative task;
2. authenticate the administrator with strong assurance;
3. validate ticket, approval, device posture and target;
4. issue narrowly scoped, time-limited access;
5. monitor commands and session behaviour;
6. revoke access and review the outcome.

4. Cryptography and Tokenisation

Cryptography protects data and establishes trust, but it cannot compensate for poor key management or compromised endpoints.

Core cryptographic functions

• Encryption transforms plaintext into ciphertext using a key and is intended to provide confidentiality.
• Hashing maps input to a fixed-length digest. A secure hash is designed to resist finding an input that produces a specified digest and to make collisions computationally difficult. Hashing is not encryption and cannot be reversed by decrypting.
• Message authentication codes (MACs) provide integrity and authenticity to parties sharing a secret key.
• Digital signatures use asymmetric cryptography to support integrity, origin authentication and, subject to legal and operational conditions, non-repudiation.
• Authenticated encryption provides confidentiality and integrity together. Systems should verify authentication before accepting decrypted data.

Symmetric encryption is generally efficient for bulk data. Asymmetric cryptography supports key agreement, signatures and identity binding but is computationally more expensive. Algorithms and parameters must be selected according to current standards, data lifetime and regulatory requirements; obsolete algorithms should be retired through a managed cryptographic inventory.

Encryption in banking

Data should be protected in transit using authenticated, modern transport protocols and at rest using centrally governed encryption. Database, disk and field-level encryption address different threats. Disk encryption may not protect data from an authorised database administrator, whereas field-level encryption or tokenisation can reduce exposure in applications and test environments.

Tokenisation

Tokenisation replaces a sensitive value with a surrogate token. A token may be random and non-reversible, with the mapping held in a protected tokenisation service. It is distinct from encryption: encrypted data can be decrypted with a key, while a properly designed non-reversible token cannot be converted back without access to the mapping service. Tokenisation reduces the number of systems handling primary account numbers, but the token vault and token-management interfaces become critical assets.

Tokenisation is not automatically anonymisation. If an organisation can link a token to an individual, privacy obligations may remain. Format-preserving tokens may assist legacy integration but require careful analysis because preserving structure can expose information or reduce the token space.

5. Key Management

The security of encrypted information depends on the lifecycle of cryptographic keys. Key management includes generation, registration, activation, distribution, storage, backup, rotation, suspension, revocation, destruction and audit.

Keys should be generated using approved random-number sources, stored in hardware security modules or comparably protected services where risk warrants, and separated from the data they protect. Access should follow dual control and separation of duties. Key-encryption keys and data-encryption keys should have distinct purposes and lifecycles.

Rotation reduces the quantity of data protected by one key and limits exposure after suspected compromise. Rotation does not by itself remediate a stolen plaintext copy or a compromised application. Re-encryption, key versioning and historical decryption requirements must be planned. Backups of keys require equivalent protection; losing a key can make legitimate data permanently unavailable.

A key-management policy should specify algorithm standards, ownership, custodianship, cryptoperiods, emergency revocation, compromise response, evidence retention and recovery testing. Cloud key-management services require clear allocation of responsibility between provider and bank.

6. Network Segmentation and Secure Connectivity

Segmentation limits lateral movement and narrows the blast radius of compromise. Banking environments commonly separate internet-facing services, user networks, application tiers, databases, payment zones, administrative networks, development environments and third-party connections.

Effective segmentation is based on business flows and trust requirements, not merely VLAN labels. Firewalls, software-defined controls, service meshes and API gateways can enforce explicit allow rules. A default-deny posture is preferable where operationally feasible. Rules should identify source, destination, service, identity and business purpose, and should be reviewed for necessity and shadowed or redundant entries.

Microsegmentation applies policy closer to workloads and can limit east–west traffic. Its limitations include operational complexity, incomplete asset inventories, misconfigured dependencies and the risk that excessive segmentation disrupts critical services. Segmentation should therefore be validated through traffic analysis and controlled testing.

Remote and third-party access should use strong authentication, device assessment, narrowly scoped routes, contractual security requirements and continuous monitoring. Direct exposure of administrative interfaces to the public internet should be avoided.

7. Endpoint Protection and Secure Configuration

Endpoints include employee laptops, servers, mobile devices, ATMs, point-of-sale terminals and specialised operational technology. Controls include supported operating systems, rapid security updates, endpoint detection and response, application control, host firewalls, disk encryption, secure boot, device management and removal of unnecessary services.

Secure configuration establishes a hardened baseline. Typical measures include disabling default accounts and insecure protocols, enforcing logging, restricting administrator rights, applying configuration-as-code where appropriate, and continuously detecting drift. A baseline must be version-controlled, tested and adapted to operational constraints. Excessive hardening without compatibility testing can impair availability.

Patch prioritisation should consider exploitability, exposure, asset criticality and compensating controls rather than age alone. Internet-facing vulnerabilities and actively exploited weaknesses generally receive urgent treatment. Exceptions require documented risk acceptance, expiry dates and compensating measures.

8. Data Loss Prevention

DLP seeks to prevent unauthorised disclosure through email, web uploads, removable media, endpoints, cloud applications, print channels and collaboration platforms. It combines data classification, content inspection, contextual policy and response.

Classification should distinguish, for example, public, internal, confidential and highly restricted information. Policies may detect payment-card patterns, national identifiers, account records or confidential documents. Context matters: an authorised payment processor may legitimately receive account data, whereas the same transfer to a personal email address should be blocked or escalated.

DLP actions include allow, warn, quarantine, encrypt, block and create an incident record. False positives can cause users to circumvent controls; excessive blocking can interrupt customer service. DLP should therefore use graduated enforcement, exception governance, privacy safeguards and periodic tuning. It is not a substitute for access control, encryption or secure application design.

9. Control Integration and Assurance

Preventive controls are strongest when integrated. IAM supplies identity signals to segmentation and DLP; endpoint posture influences access decisions; PAM protects configuration changes; key-management logs support audit; and tokenisation reduces the data available to endpoints and test systems.

Control assurance should assess both design and operating effectiveness. Useful evidence includes access reviews, authentication events, privileged sessions, firewall-rule recertification, configuration-compliance results, key-lifecycle records, DLP incidents and recovery exercises. Metrics should measure risk reduction rather than activity alone. Examples include the proportion of privileged accounts without standing access, percentage of critical assets covered by managed endpoint protection, time to revoke leavers, and percentage of high-risk data stores using approved keys.

A control can be represented through a simplified risk relationship:

This expression is a conceptual model, not a universally measurable law. Inherent risk is the exposure before controls, and control effectiveness is expressed as a proportion from 0 to 1 under defined assumptions. Real risk assessment must also consider threat likelihood, impact, dependencies and uncertainty; controls may fail together, so effectiveness cannot simply be added across layers.

Applied Case: Illustrative Regional Bank

Background

Riverland Bank operates mobile banking, a card-processing platform and a payment-operations network. It uses contractors for application support and stores transaction data in a hybrid cloud environment.

Problem

An attacker obtained a contractor’s password through phishing. The account had broad VPN access and a persistent administrator privilege. The attacker reached a payment-support server, copied customer records and attempted to alter beneficiary controls. The bank detected unusual activity only after a customer complaint.

Analysis

The incident exposed several architectural weaknesses: single-factor authentication, excessive network reachability, standing privilege, weak service-account governance, inadequate DLP coverage and insufficient correlation between VPN, endpoint and database events. Encryption at rest limited some exposure, but the compromised application could access plaintext during processing.

Approach and solution

The bank implemented phishing-resistant MFA for staff and contractors, device-compliance checks and risk-based step-up authentication. Contractors received separate identities with time-bound access. PAM introduced approval, vaulting, session recording and just-in-time elevation. The VPN was replaced by application-specific access policies, while payment, user, development and administration zones were segmented.

Sensitive customer identifiers were tokenised for analytics and test environments. Production keys were placed under central lifecycle management with dual control. EDR was deployed to servers and workstations, critical baselines were enforced, and DLP policies covered email, web upload and removable media. Detection rules correlated identity, endpoint, network and database events.

Outcome

A later simulated phishing attempt produced no reusable password, and a compromised test account could not reach the payment database. A legitimate emergency change was recorded through PAM and independently reviewed. The bank still retained residual risks, including software supply-chain exposure and availability risks from incorrect policy changes; these became subjects of ongoing assurance and recovery testing.

Learning points

1. A strong control in one layer cannot compensate for weak architecture elsewhere.
2. Least privilege must include network reachability and time, not only application permissions.
3. Tokenisation reduces exposure but does not eliminate the need for access control.
4. Preventive controls require monitoring, testing and governance.
5. Availability and operational resilience must be considered when enforcing security policy.

Challenges, Ethics and Governance

Security controls process personal and employee information. Monitoring privileged sessions, collecting device telemetry and analysing behavioural signals must be proportionate, transparent and legally supported. Biometric authentication requires particular attention to consent, retention and breach consequences because biometric traits cannot be replaced like passwords.

Governance should assign control owners, approve risk tolerances, document exceptions and ensure independent assurance. Regulatory obligations may address payment-card data, privacy, operational resilience, outsourcing, incident reporting and record retention; the applicable requirements depend on jurisdiction and service. Compliance is a baseline, not proof of security.

Artificial intelligence can assist anomaly detection, configuration analysis and DLP classification, but models may produce false positives, encode bias or expose sensitive data. Human review, model governance, explainability appropriate to the use case and adversarial testing are necessary. AI should not silently make high-impact access decisions without accountability and a safe appeal or escalation process.

Contemporary Developments and Best Practices

Current practice is moving toward passwordless authentication, continuous device and workload identity, policy-as-code, confidential computing, software supply-chain assurance and cryptographic agility in preparation for post-quantum migration. These developments should be adopted according to threat, maturity and interoperability rather than novelty.

A practical implementation sequence is to inventory assets and data, map trust boundaries, establish identity ownership, remove standing privilege, segment critical services, standardise secure configurations, protect keys, reduce sensitive-data copies, integrate telemetry and test failure scenarios. Architecture review should ask whether a control is preventive, detective or corrective; whether it fails safely; who can bypass it; and how its effectiveness will be demonstrated.

Chapter Summary

Security architecture in banking is a system of layered, governed controls rather than a collection of products. Defence-in-depth reduces dependence on any single safeguard, while zero trust removes implicit trust and evaluates access using identity, device, resource and context. IAM establishes identity and authorisation; PAM constrains high-impact administration. Cryptography provides confidentiality, integrity and authenticity when algorithms and keys are properly managed. Tokenisation reduces the systems exposed to sensitive values but creates critical token-vault dependencies.

Segmentation limits lateral movement, endpoint protection and secure configuration reduce exploitable weaknesses, and DLP limits unauthorised data movement. Key management covers the full lifecycle from generation to destruction. Effective programmes integrate these controls, measure operating effectiveness, respect privacy and resilience, and continuously test assumptions. The Riverland Bank case illustrates that layered controls are most valuable when they are connected through policy, telemetry, governance and accountable operations.

Key Terms

Authentication: Verification of a claimant’s identity.

Authorisation: Determination of what an authenticated subject may do.

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

Zero trust: Architecture that grants no implicit trust and continuously evaluates access.

Least privilege: Granting only necessary permissions for an approved purpose and period.

IAM: Governance and technical management of identities and access.

PAM: Controls for protecting and governing privileged accounts.

RBAC: Access control based primarily on organisational roles.

ABAC: Access control based on attributes and policy conditions.

Encryption: Transformation of plaintext into protected ciphertext using a key.

Hash: Fixed-length digest produced by a one-way cryptographic function.

Digital signature: Asymmetric cryptographic evidence of integrity and signing identity.

Tokenisation: Replacement of sensitive data with a controlled surrogate value.

Key management: Governance of cryptographic keys throughout their lifecycle.

Network segmentation: Division of networks or workloads into controlled trust zones.

Endpoint detection and response: Monitoring and response capability on endpoint devices.

Secure configuration: Hardened, tested and monitored system settings.

Data loss prevention: Controls designed to detect and prevent unauthorised data disclosure.

Residual risk: Risk remaining after controls are applied.

Review Questions

Short Answer Questions

1. What are the principal differences between defence-in-depth and zero trust?
2. Why is a shared administrator account a weakness in accountability?
3. Distinguish encryption, hashing and tokenisation.
4. What functions are included in the cryptographic key lifecycle?
5. Why should network segmentation be based on business flows rather than labels alone?

Long Answer Questions

1. Explain how IAM, PAM and segregation of duties can be combined to protect payment operations.
2. Evaluate the benefits and limitations of tokenisation compared with encryption for customer data.
3. Describe a zero-trust design for a hybrid-cloud banking application.
4. Discuss how secure configuration, endpoint protection and patch governance interact.
5. Explain the ethical and governance issues associated with DLP, employee monitoring and AI-assisted security.

Analytical / Application Questions

1. A contractor needs access to a production payment service for four hours. Design an access workflow using zero-trust, PAM, segmentation and monitoring principles.
2. A bank has encrypted databases but permits broad administrator access and unrestricted exports to test environments. Analyse the residual risks and propose prioritised controls.
3. A DLP system blocks legitimate payment-processing files and users begin using personal messaging applications. Design a graduated policy, exception process and assurance plan that reduces both leakage and circumvention.

Multiple Choice Questions with Answers

Question 1

Which statement best describes zero-trust architecture?

A. All internal network users are trusted after connecting through the corporate VPN.

B. Access is explicitly evaluated using identity, device, resource and context.

C. Only external users require authentication.

D. Security is achieved primarily by installing multiple perimeter firewalls.

Correct Answer: B. Access is explicitly evaluated using identity, device, resource and context.

Question 2

Which control most directly reduces standing administrative privilege?

A. Just-in-time elevation through PAM

B. Longer administrator passwords

C. A larger network address range

D. Annual antivirus replacement

Correct Answer: A. Just-in-time elevation through PAM

Question 3

What is the principal function of a cryptographic hash?

A. Reversible protection of bulk data

B. Fixed-length representation designed to support integrity checking

C. Replacement of a value with a token vault reference

D. Creation of a network firewall rule

Correct Answer: B. Fixed-length representation designed to support integrity checking

Question 4

Which statement correctly distinguishes tokenisation from encryption?

A. Tokenisation always provides stronger confidentiality than every encryption method.

B. Encryption cannot be reversed, while tokenisation can always be decrypted.

C. Tokenisation uses a surrogate value and may depend on a protected mapping service.

D. Tokenisation eliminates all privacy obligations.

Correct Answer: C. Tokenisation uses a surrogate value and may depend on a protected mapping service.

Question 5

Which practice is most appropriate for cryptographic key governance?

A. Store keys in the same database as the protected plaintext.

B. Permit one administrator to generate, approve and recover every key.

C. Define key generation, rotation, revocation, backup and destruction procedures.

D. Rotate keys without maintaining any version or recovery information.

Correct Answer: C. Define key generation, rotation, revocation, backup and destruction procedures.

Question 6

What is the principal security purpose of network segmentation?

A. To guarantee that no system can ever be compromised

B. To limit lateral movement and reduce the blast radius of compromise

C. To replace identity and access management

D. To remove the need for endpoint protection

Correct Answer: B. To limit lateral movement and reduce the blast radius of compromise

Question 7

Which authentication arrangement provides two distinct factor categories?

A. Password and security question

B. Two different passwords

C. Password and hardware security key

D. Username and account number

Correct Answer: C. Password and hardware security key

Question 8

Why is disk encryption alone insufficient against a compromised database administrator account?

A. Disk encryption cannot protect data at rest.

B. An authorised application or administrator may access plaintext during processing.

C. Disk encryption prevents all system recovery.

D. Disk encryption works only on mobile devices.

Correct Answer: B. An authorised application or administrator may access plaintext during processing.

Question 9

Which DLP practice best reduces harmful false positives?

A. Block every outbound file without exception.

B. Use graduated actions, contextual policies and governed exceptions.

C. Disable monitoring for senior employees.

D. Allow all transfers and investigate only after complaints.

Correct Answer: B. Use graduated actions, contextual policies and governed exceptions.

Question 10

Under the conceptual model Residual risk = Inherent risk × (1 − control effectiveness), what is residual risk when inherent risk is 80 units and control effectiveness is 0.75?

A. 20 units

B. 40 units

C. 60 units

D. 140 units

Correct Answer: A. 20 units