LESSON 3.1: Foundations of Security Architecture – Principles, Frameworks, and Design Patterns for Financial Institutions

Introduction: The Blueprint for Defense

In Modules 1 and 2, we established the foundational concepts of cybersecurity for financial institutions and developed a comprehensive understanding of the cyber threat landscape. We explored the regulatory landscape including GLBA, SOX, GDPR, and NYDFS, developed threat intelligence capabilities, conducted cyber risk assessments, and examined security frameworks and controls. We categorized threat actors, analyzed their Tactics, Techniques, and Procedures (TTPs), examined Advanced Persistent Threats, and assessed the full spectrum of attacks targeting financial institutions—from phishing and ransomware to insider threats, supply chain attacks, and DDoS attacks.

However, understanding threats and risks is only half the battle. Financial institutions must also design and implement robust security architectures that protect their assets, detect threats, and respond to incidents. A security architecture is the blueprint for defense—a comprehensive framework that defines how security controls are organized, integrated, and managed to protect the organization’s information assets. Without a well-designed security architecture, security controls are deployed in an ad hoc, disconnected manner, creating gaps that adversaries can exploit.

Security Architecture is the set of structures, processes, and controls that protect an organization’s information assets. It encompasses the design of networks, systems, applications, and data protection mechanisms, as well as the policies, procedures, and governance structures that support them. A well-designed security architecture provides:

Defense-in-Depth: Multiple layers of protection that ensure no single point of failure compromises the entire system. Each layer provides independent protection, and an attacker must breach multiple layers to achieve their objective.
Least Privilege: Restricting access to only what is necessary for each user, system, or process. This minimizes the potential damage from compromised accounts and limits the blast radius of attacks.
Segregation of Duties: Ensuring that no single individual has complete control over a critical function. This prevents fraud and errors by requiring multiple individuals to collude to compromise a critical function.
Security by Design: Embedding security into the design of systems and applications from the beginning, rather than adding it as an afterthought. This is significantly more cost-effective and produces more secure systems.

This lesson provides the complete mathematical and conceptual foundation for security architecture. We begin by examining the Core Principles of Security Architecture: Defense-in-Depth, Least Privilege, Segregation of Duties, and Security by Design. We formalize these principles and derive their mathematical formulations, providing rigorous definitions that can be used to assess and measure the implementation of these principles.

We then examine the Security Architecture Frameworks used in financial institutions: the SABSA Framework (Sherwood Applied Business Security Architecture), which provides a business-driven approach to security architecture; the TOGAF Framework (The Open Group Architecture Framework), which provides a comprehensive enterprise architecture framework with security as a cross-cutting concern; and the NIST Cybersecurity Framework (CSF) , which provides a risk-based approach to managing cybersecurity. We compare these frameworks and derive the Security Architecture Maturity Model: $M_{S A} = α \cdot A_{w a re n ess} + β \cdot D_{es i g n} + γ \cdot I_{m pl e m e n t a t i o n} + δ \cdot O_{p er a t i o n}$ , which quantifies the maturity of a security architecture.

We also introduce the Security Design Patterns for financial institutions: Network Segmentation, which divides the network into isolated segments to contain threats; Demilitarized Zone (DMZ) , which provides a buffer zone between the internet and internal networks; Zero-Trust Architecture (ZTA) , which eliminates implicit trust and continuously verifies all access requests; and Micro-Segmentation, which provides granular segmentation at the workload level. We derive the Zero-Trust Model: $Z_{T} = {Verify Explicitly, Use Least Privilege, Assume Breach}$ , and we analyze the mathematical foundations of each design pattern.

By the end, you will have a complete understanding of the foundations of security architecture and be able to design secure architectures for financial institutions.

Learning Objectives

Upon completion of this lesson, you will be able to:

Define the core principles of security architecture: Defense-in-Depth, Least Privilege, Segregation of Duties, and Security by Design.
Derive the mathematical formulations of each core principle: $P (Success) = \prod_{i = 1 N} P (Bypass Layer_{i})$ , $P_{g r an t e d} \subseteq P_{re q u i re d}$ , $\forall i \in Individuals, Controls (i) \neq = F$ , and $Cost \propto e^{β \cdot Stage}$ .
Analyze the Security Architecture Frameworks: SABSA, TOGAF, and NIST CSF.
Derive the Security Architecture Maturity Model: $M_{S A} = α \cdot A_{w a re n ess} + β \cdot D_{es i g n} + γ \cdot I_{m pl e m e n t a t i o n} + δ \cdot O_{p er a t i o n}$ .
Apply the Security Design Patterns: Network Segmentation, DMZ, Zero-Trust Architecture, and Micro-Segmentation.
Derive the Zero-Trust Model: $Z_{T} = {Verify Explicitly, Use Least Privilege, Assume Breach}$ .
Design a security architecture for a financial institution.

Part 1: Core Principles of Security Architecture

1.1 The Principles Framework

The core principles of security architecture provide the foundation for all security design decisions:

$Security Principles = {Defense-in-Depth, Least Privilege, Segregation of Duties, Security by Design}$

These principles are interdependent and mutually reinforcing. A well-designed security architecture implements all four principles in an integrated manner. The failure to implement any one principle creates a significant vulnerability that adversaries can exploit.

1.2 Defense-in-Depth

Definition: Defense-in-Depth is the strategy of layering multiple security controls to provide redundancy and ensure that no single point of failure compromises the entire system.

Mathematical Formulation: The probability of a successful attack is the product of the probabilities of bypassing each layer:

$P (Success) = i = 1 \prod N P (Bypass Layer^{i})$

Derivation: For an attack to be successful, it must bypass every layer of defense. Assuming the layers are independent, the probability of bypassing all layers is the product of the individual probabilities. This is a fundamental property of defense-in-depth: multiple layers provide multiplicative protection.

Interpretation: If each layer has a 90% chance of stopping an attack ( $P (Stop) = 0.90$ ), then the probability of stopping the attack across all layers is:

$P (Stop) = 1 - i = 1 \prod N (1 - 0.90) = 1 - (0.10)^{N}$

For $N = 5$ layers, $P (Stop) = 1 - (0.10)^{5} = 0.99999$ . This demonstrates the power of defense-in-depth: five layers of 90% effectiveness provide 99.999% protection.

Layers of Defense:

Layer	Description	Examples
Physical Security	Protecting physical assets	Guards, fences, locks, CCTV
Network Security	Protecting the network perimeter	Firewalls, IDS/IPS, VPNs
Endpoint Security	Protecting devices	Antivirus, EDR, application control
Application Security	Protecting applications	Secure coding, WAF, vulnerability scanning
Data Security	Protecting data	Encryption, DLP, access controls
User Security	Protecting users	MFA, awareness training, PAM
Monitoring	Detecting threats	SIEM, SOC, threat hunting
Incident Response	Responding to incidents	IR plan, forensics, communication
Business Continuity	Maintaining operations	BCP, DR, redundancy

1.3 Least Privilege

Definition: The principle of Least Privilege states that every user, system, and process should be granted only the minimum privileges necessary to perform its function.

Mathematical Formulation: Let $P_{re q u i re d}$ be the set of privileges required to perform a function, and $P_{g r an t e d}$ be the set of privileges granted. The principle requires:

$P^{g r an t e d} \subseteq P^{re q u i re d}$

Derivation: Any privilege not required is a potential vulnerability. By limiting privileges to only those required, we minimize the attack surface and limit the damage of compromised accounts.

Interpretation: Users should not have more access than they need. This reduces the attack surface and limits the damage of compromised accounts. The principle applies to all entities: users, systems, processes, and applications.

Implementation:

Practice	Description	Mathematical Model
Role-Based Access Control (RBAC)	Granting access based on job roles	$P_{g r an t e d} = ⋃_{r \in R u ser} P_{r}$
Just-In-Time Access	Granting access only when needed	$P_{g r an t e d} (t) \neq = \emptyset ⟺ t \in T_{n ee d}$
Privileged Access Management (PAM)	Managing and monitoring privileged accounts	$\forall u \in U_{p r i v i l e g e d}, Monitor (u) = True$
Regular Access Reviews	Periodically reviewing and removing unnecessary access	$\forall u \in U, P_{g r an t e d} (u) \leftarrow Review (P_{g r an t e d} (u))$

1.4 Segregation of Duties

Definition: The principle of Segregation of Duties states that no single individual should have complete control over a critical function.

Mathematical Formulation: Let $F$ be a critical function with $N$ sub-functions. The principle requires that no single individual controls all $N$ sub-functions:

$\forall i \in Individuals, Controls (i) \neq = F$

Derivation: If one individual controls all sub-functions of a critical function, they can commit fraud or cause significant damage without detection. By requiring multiple individuals to complete a critical function, we reduce the risk of fraud and errors.

Interpretation: Separation of duties prevents fraud and errors by requiring multiple individuals to collude to compromise a critical function. This is particularly important in financial systems where the potential for fraud is high.

Implementation:

Practice	Description	Mathematical Model
Dual Control	Requiring two individuals to perform a critical action	$\forall a \in A_{cr i t i c a l}, Execute (a) ⟹ \exists u_{1}, u_{2} \in U, u_{1} \neq = u_{2}$
Split Knowledge	Splitting critical information across multiple individuals	$\forall k \in K_{cr i t i c a l}, \exists u_{1}, \dots, u_{n} \in U, ⋃_{i = 1 n} Knowledge (u_{i}) = k$
Rotation of Duties	Periodically rotating job responsibilities	$\forall t \in T, R (u, t) \neq = R (u, t + 1)$
Mandatory Vacations	Requiring employees to take vacations to detect fraud	$\forall u \in U, \exists t \in T, Vacation (u, t) = True$

1.5 Security by Design

Definition: Security by Design is the practice of embedding security into the design of systems and applications from the beginning, rather than adding it as an afterthought.

Mathematical Formulation: The cost of fixing a security issue increases exponentially with the stage of the development lifecycle:

$Cost \propto e^{β \cdot Stage}$

Where $β > 0$ is a constant representing the cost multiplier per stage, and Stage is the stage of the development lifecycle (1 = Design, 2 = Development, 3 = Testing, 4 = Production).

Derivation: Security issues found early in the lifecycle are cheaper to fix because there is less code to change, fewer dependencies to consider, and less impact on existing systems. Issues found late in the lifecycle require significant rework, testing, and potential downtime.

Interpretation: Fixing a security issue during design costs significantly less than fixing it during production. A study by the National Institute of Standards and Technology (NIST) found that the cost to fix a security issue increases by a factor of 10 at each stage of the lifecycle.

Implementation:

Practice	Description	Benefit
Threat Modeling	Identifying threats during design	Early detection of vulnerabilities
Secure Coding Standards	Following secure coding practices	Prevention of common vulnerabilities
Security Testing	Testing for vulnerabilities during development	Early detection of vulnerabilities
Security Reviews	Reviewing designs and code for security issues	Prevention of vulnerabilities
DevSecOps	Integrating security into DevOps	Continuous security throughout development

Core Security Principles (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Defense-in-Depth                                               ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Multiple layers of protection                                   ║  |
|  ║  P(Success) = ∏ P(Bypass Layer_i)                               ║  |
|  ║  Example: 5 layers at 90% effectiveness = 99.999% protection   ║  |
|  ║  Layers: Physical → Network → Endpoint → Application → Data    ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Least Privilege                                                ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Grant only minimum necessary privileges                         ║  |
|  ║  P_granted ⊆ P_required                                         ║  |
|  ║  Implementation: RBAC, JIT Access, PAM, Regular Reviews        ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Segregation of Duties                                          ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  No single individual controls a critical function              ║  |
|  ║  Controls(i) ≠ F                                                ║  |
|  ║  Implementation: Dual control, split knowledge, rotation       ║  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  ╔═══════════════════════════════════════════════════════════════════╗  |
|  ║  Security by Design                                             ║  |
|  ╠═══════════════════════════════════════════════════════════════════╣  |
|  ║  Embed security from the beginning                               ║  |
|  ║  Cost ∝ e^(β × Stage)                                           ║  |
|  ║  Implementation: Threat modeling, secure coding, security testing│  |
|  ╚═══════════════════════════════════════════════════════════════════╝  |
|                                                                         |
|  Interdependencies:                                                  │
|  ┌─────────────────────────────────────────────────────────────────┐  |
|  │  • Defense-in-Depth requires Security by Design                │  |
|  │  • Least Privilege supports Defense-in-Depth                   │  |
|  │  • Segregation of Duties reinforces Least Privilege            │  |
|  │  • All principles work together in a well-designed architecture│  |
|  └─────────────────────────────────────────────────────────────────┘  |
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Part 2: Security Architecture Frameworks

2.1 The SABSA Framework

Overview: The Sherwood Applied Business Security Architecture (SABSA) is a framework for developing business-driven security architectures. SABSA is unique in that it starts with business requirements and derives security requirements from them, ensuring that security is aligned with business objectives.

The SABSA Matrix:

Layer	Business View	Architect’s View	Designer’s View	Builder’s View	Manager’s View
Contextual	Business requirements	Strategic security	Security policies	Security standards	Security metrics
Conceptual	Business processes	Security concepts	Security architecture	Security design	Security operations
Logical	Business functions	Security models	Security components	Security implementation	Security management
Physical	Business operations	Security infrastructure	Security controls	Security deployment	Security monitoring
Component	Business components	Security modules	Security components	Security building blocks	Security testing

The SABSA Framework Equation:

$SABSA = {Business Requirements, Security Requirements, Security Architecture, Security Implementation}$

Implementation Approach:

Phase	Description	Key Activities
1. Requirements	Understand business requirements	Stakeholder interviews, business process mapping
2. Security Requirements	Derive security requirements	Risk assessment, threat modeling
3. Architecture Design	Design the security architecture	Security models, component design
4. Implementation	Implement the architecture	Technology selection, deployment
5. Management	Manage the architecture	Operations, monitoring, continuous improvement

2.2 The TOGAF Framework

Overview: The Open Group Architecture Framework (TOGAF) is a framework for enterprise architecture that includes security as a cross-cutting concern. TOGAF provides a comprehensive methodology for developing enterprise architectures that integrate security throughout.

The TOGAF Architecture Development Method (ADM):

Phase	Description	Security Focus
Preliminary	Framework and principles	Security principles
A. Architecture Vision	High-level vision	Security vision and objectives
B. Business Architecture	Business processes	Security requirements
C. Information Systems	Data and applications	Security controls
D. Technology Architecture	Infrastructure	Security infrastructure
E. Opportunities	Implementation planning	Security implementation
F. Migration Planning	Migration to target	Security migration
G. Implementation Governance	Implementation oversight	Security governance
H. Architecture Change Management	Change management	Security change management

The TOGAF Security Integration Model:

$TOGAF Security = {Security Principles, Security Requirements, Security Architecture, Security Governance}$

2.3 The NIST Cybersecurity Framework (CSF)

Overview: The NIST Cybersecurity Framework provides a risk-based approach to managing cybersecurity. It is widely adopted in the financial sector due to its practical, risk-based approach.

The NIST CSF Core Functions:

$NIST CSF = {Identify, Protect, Detect, Respond, Recover}$

Function	Description	Key Activities
Identify	Understand the organization’s cybersecurity risk	Asset management, risk assessment, governance
Protect	Develop and implement safeguards	Access control, awareness training, data security
Detect	Identify cyber events	Anomalies detection, continuous monitoring
Respond	Contain a cyber incident	Response planning, communications, analysis
Recover	Restore capabilities	Recovery planning, improvements, communications

Implementation Levels:

Level	Description	Characteristics
Level 1: Partial	Ad hoc, reactive	No formal processes, limited awareness
Level 2: Risk-Informed	Some formal processes	Risk-aware, some documentation
Level 3: Repeatable	Consistent processes	Formal documentation, consistent execution
Level 4: Adaptive	Continuous improvement	Proactive security, adaptive to threats

Security Architecture Frameworks Comparison (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  SABSA Framework                                                       │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Business-driven security architecture                        │  │
|  │  5 Layers: Contextual → Conceptual → Logical → Physical →    │  │
|  │            Component                                           │  │
|  │  5 Views: Business → Architect → Designer → Builder → Manager │  │
|  │  Strength: Business alignment                                  │  │
|  │  Weakness: Complex, requires significant expertise            │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  TOGAF Framework                                                       │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Enterprise architecture framework                            │  │
|  │  ADM: 10 phases                                                │  │
|  │  Security integrated across all phases                        │  │
|  │  Strength: Comprehensive enterprise view                      │  │
|  │  Weakness: Overly complex for security-only focus             │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  NIST CSF Framework                                                   │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Risk-based cybersecurity framework                           │  │
|  │  5 Core Functions: Identify → Protect → Detect → Respond →   │  │
|  │                    Recover                                      │  │
|  │  4 Implementation Levels                                       │  │
|  │  Strength: Practical, widely adopted in finance               │  │
|  │  Weakness: Less prescriptive than other frameworks            │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Best Practice: Combine SABSA (business alignment) with NIST CSF    │
|  (practical cybersecurity) for financial institutions.               │
└─────────────────────────────────────────────────────────────────────────┘

2.4 The Security Architecture Maturity Model

The Security Architecture Maturity Model quantifies the maturity of a security architecture:

$M^{S A} = α \cdot A^{w a re n ess} + β \cdot D^{es i g n} + γ \cdot I^{m pl e m e n t a t i o n} + δ \cdot O^{p er a t i o n}$

Where:

$A_{w a re n ess}$ is the Awareness Score (0-1)
$D_{es i g n}$ is the Design Score (0-1)
$I_{m pl e m e n t a t i o n}$ is the Implementation Score (0-1)
$O_{p er a t i o n}$ is the Operation Score (0-1)
$α, β, γ, δ$ are weights (typically $α = 0.2, β = 0.3, γ = 0.3, δ = 0.2$ )

Component	Description	Scoring Factors
Awareness (A)	Awareness of security architecture	Executive support, stakeholder engagement, security culture
Design (D)	Quality of security architecture design	Architecture completeness, adherence to principles, documentation
Implementation (I)	Effectiveness of implementation	Control deployment, policy enforcement, integration
Operation (O)	Effectiveness of operations	Monitoring, incident response, continuous improvement

Interpretation of Maturity Scores:

Maturity Score	Level	Interpretation
$M_{S A} \geq 0.90$	Level 5 (Optimizing)	World-class security architecture
$0.80 \leq M_{S A} < 0.90$	Level 4 (Managed)	Strong security architecture
$0.60 \leq M_{S A} < 0.80$	Level 3 (Defined)	Good foundation, room for improvement
$0.40 \leq M_{S A} < 0.60$	Level 2 (Repeatable)	Basic security, significant gaps
$M_{S A} < 0.40$	Level 1 (Initial)	Ad hoc, high risk

Part 3: Security Design Patterns

3.1 Network Segmentation

Definition: Network segmentation divides a network into smaller, isolated segments to contain threats and limit lateral movement.

$Segmentation = {Segments, Controls, Traffic}$

Benefits:

Benefit	Description
Threat Containment	Contains threats to a single segment
Lateral Movement Prevention	Prevents attackers from moving between segments
Granular Security Policies	Enables different policies per segment
Performance Optimization	Reduces broadcast traffic

Types:

Type	Description	Example
Physical Segmentation	Physically separate networks	Different switches and routers
Logical Segmentation	Virtually separate networks	VLANs, subnets
Micro-Segmentation	Granular segmentation at the workload level	Software-defined networking

3.2 Demilitarized Zone (DMZ)

Definition: A DMZ is a network segment that exposes services to the internet while isolating internal networks.

$DMZ = {External Interface, Internal Interface, Services}$

Architecture:

Component	Description	Security Controls
External Firewall	Protects the DMZ from the internet	ACLs, NAT, IPS
DMZ Network	Contains public-facing services	Segmentation, monitoring
Internal Firewall	Protects the internal network from the DMZ	ACLs, inspection, IDS/IPS
Internal Network	Contains sensitive systems	Strict access controls

3.3 Zero-Trust Architecture (ZTA)

Definition: Zero-Trust Architecture is a security model that assumes no trust and requires continuous verification of all access requests.

$Zero-Trust = {Verify Explicitly, Use Least Privilege, Assume Breach}$

Core Principles:

Principle	Description	Implementation
Verify Explicitly	Always authenticate and authorize based on all available data	MFA, continuous authentication
Use Least Privilege	Grant minimum access necessary	RBAC, JIT access, PAM
Assume Breach	Design as if the network is already compromised	Micro-segmentation, monitoring, encryption

Zero-Trust Architecture Components:

Component	Description
Identity and Access Management (IAM)	Verifying identity and access
Network Segmentation	Dividing the network into smaller segments
Micro-Segmentation	Granular segmentation at the workload level
Encryption	Encrypting data at rest and in transit
Monitoring	Continuous monitoring and threat detection
Policy Enforcement	Enforcing access policies

3.4 Micro-Segmentation

Definition: Micro-segmentation is a fine-grained approach to network segmentation that isolates workloads at the application level.

$Micro-Segmentation = {Workloads, Policies, Enforcement}$

Benefits:

Benefit	Description
Granular Control	Control at the workload level
Lateral Movement Prevention	Prevents movement between workloads
Zero-Trust Enablement	Enables zero-trust architecture
Agility	Supports cloud and container environments

Security Design Patterns (Visual):
┌─────────────────────────────────────────────────────────────────────────┐
|                                                                         |
|  Network Segmentation                                                 │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Physical Segmentation: Separate switches/routers              │  │
|  │  Logical Segmentation: VLANs, subnets                         │  │
|  │  Micro-Segmentation: Workload-level isolation                 │  │
|  │  Benefit: Threat containment, lateral movement prevention      │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  DMZ Architecture                                                     │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Internet → External Firewall → DMZ → Internal Firewall →     │  │
|  │  Internal Network                                              │  │
|  │  Benefit: Exposes services while protecting internal network   │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Zero-Trust Architecture (ZTA)                                       │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Verify Explicitly: MFA, continuous authentication           │  │
|  │  Use Least Privilege: RBAC, JIT access, PAM                  │  │
|  │  Assume Breach: Micro-segmentation, encryption, monitoring    │  │
|  │  Benefit: Eliminates implicit trust                           │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
|  Micro-Segmentation                                                  │
|  ┌─────────────────────────────────────────────────────────────────┐  │
|  │  Granular segmentation at workload level                      │  │
|  │  Software-defined networking                                  │  │
|  │  Benefit: Zero-trust enablement, lateral movement prevention  │  │
|  └─────────────────────────────────────────────────────────────────┘  │
|                                                                         |
└─────────────────────────────────────────────────────────────────────────┘

Summary and Bridge to Lesson 3.2

We have now completed the foundations of security architecture. You have learned:

Core Principles: Defense-in-Depth, Least Privilege, Segregation of Duties, and Security by Design.
Mathematical Formulations: $P (Success) = \prod P (Bypass Layer_{i})$ , $P_{g r an t e d} \subseteq P_{re q u i re d}$ , $Controls (i) \neq = F$ , and $Cost \propto e^{β \cdot Stage}$ .
Security Architecture Frameworks: SABSA, TOGAF, and NIST CSF.
Security Architecture Maturity Model: $M_{S A} = α \cdot A_{w a re n ess} + β \cdot D_{es i g n} + γ \cdot I_{m pl e m e n t a t i o n} + δ \cdot O_{p er a t i o n}$ .
Security Design Patterns: Network Segmentation, DMZ, Zero-Trust Architecture, and Micro-Segmentation.
Zero-Trust Model: $Z_{T} = {Verify Explicitly, Use Least Privilege, Assume Breach}$ .

Certificate in Cybersecurity for Financial Institutions LESSON 3.1: Foundations of Security Architecture – Principles, Frameworks, and Design Patterns for Financial Institutions

Certificate in Cybersecurity for Financial Institutions

LESSON 3.1: Foundations of Security Architecture – Principles, Frameworks, and Design Patterns for Financial Institutions

Introduction: The Blueprint for Defense

Learning Objectives

Part 1: Core Principles of Security Architecture

1.1 The Principles Framework

1.2 Defense-in-Depth

1.3 Least Privilege

1.4 Segregation of Duties

1.5 Security by Design

Part 2: Security Architecture Frameworks

2.1 The SABSA Framework

2.2 The TOGAF Framework

2.3 The NIST Cybersecurity Framework (CSF)

2.4 The Security Architecture Maturity Model

Part 3: Security Design Patterns

3.1 Network Segmentation

3.2 Demilitarized Zone (DMZ)

3.3 Zero-Trust Architecture (ZTA)

3.4 Micro-Segmentation

Summary and Bridge to Lesson 3.2