1

SOA vs. Microservices — Loose Coupling & Independence

The old way of building systems was monolithic — tightly coupled, everything built together, everything breaks together. Modern architecture separates systems into loosely coupled services so each piece can be built, tested, deployed, and scaled independently.

SOA (with ESB) vs. Microservices Architecture — The Key Distinction
SOA — Service-Oriented Architecture
Order Service
↕ connects via ESB
Enterprise Service Bus (ESB)
Facilitates service-to-service communication
↕ connects via ESB
Payment Service
↕ connects via ESB
Inventory Service
↕ connects via ESB
Notification Service
✓ Services share some interdependencies
✓ ESB coordinates communication
✓ Reuse across business processes
⚠ Changing one service may affect others
Microservices — Fully Independent
Order µService
↕ isolated — no shared dependencies
Payment µService
↕ isolated — no shared dependencies
Inventory µService
↕ isolated — no shared dependencies
Notification µService
✓ Each developed, tested, deployed alone
✓ Scale only what you need
✓ No ESB required
✓ Change one without affecting others
SOA
Services with interdependencies
Software architecture where services are loosely coupled but maintain some connections through the Enterprise Service Bus (ESB). Services communicate across platforms and languages. Good for mapping business workflows to IT systems. Allows reuse of components. Components can have dependencies that mean changing one affects others.
Microservices
Fully independent services
Each service performs exactly one function with clearly defined inputs and outputs — a "black box." Developed, tested, and deployed completely independently. Scale only the specific service that needs it rather than the entire application. No shared interdependencies. Backbone of modern cloud architectures (Netflix, Amazon).
ESB — Enterprise Service Bus
SOA communication layer
A common component of SOA architectures that facilitates service-to-service communication when services are loosely but not fully decoupled. Acts as a message broker between services. Not needed in true microservices architectures where services are fully independent.
The key differentiator: SOA has interdependencies between services (connected via ESB). Microservices are fully independent — each can be developed, tested, and deployed alone. If a question describes services with connections and dependencies = SOA. If it describes completely independent single-function services = Microservices.
2

SOAP — XML Protocol & Security Vulnerabilities

SOAP (Simple Object Access Protocol) is an XML-based web service protocol that provides a common language-agnostic format for services written in Java, Python, JavaScript, Ruby, or any other language to communicate with each other. It supports authentication, transport security, asynchronous messaging, and built-in error handling.

SOAP security best practices
Always use least privilege between services. Apply deny-by-default policy. Use WS-Security (Web Service Security) extensions to enforce integrity and confidentiality over SOAP communications. Never pass SQL statements directly over SOAP into a database — always process them first and then validate before pushing to the database.
WS-Security
Extensions to SOAP that enforce integrity and confidentiality. Adds digital signatures to SOAP messages (integrity — proves they weren't modified). Adds encryption (confidentiality — prevents eavesdropping). Provides a security framework for SOAP-based web services similar to what TLS provides for HTTP.

Five SOAP attack vectors

Probing
Reconnaissance attack against the web service. Attacker sends requests to the SOAP API and analyses responses to fingerprint and enumerate the service — discovering its structure, parameters, and behaviour. Preliminary step before a targeted attack. SOAP exposes the service interface making it a viable recon target.
Coercive Parsing
Maliciously crafted XML triggers harmful parsing behaviour. Attacker modifies the SOAP request to cause the XML parser to process data in a harmful way — triggering an exploit payload embedded in the XML, or causing a denial of service by making the parser consume excessive resources (similar to an XML bomb attack).
External References
SOAP calls reference malicious external third-party resources. Similar to Remote File Inclusion — a poorly configured SOAP service loads external libraries or files from attacker-controlled locations. The external reference can deliver malicious code directly into the service processing pipeline.
Malware in XML
Malware embedded inside XML message payload. Malicious code inserted into the body of a SOAP XML message. When the service parses the message, the malware is processed and executed. Prevention: validate and sanitise all XML input before parsing, not after.
SQL Injection via SOAP
SQL statements passed through SOAP directly into database. SOAP has no native SQL filtering. If a service passes SOAP content directly to a database query, attackers can inject malicious SQL. Fix: receive the data, process it, validate it, then use parameterised queries to push it to the database — never pass raw SOAP data directly to SQL.
3

SAML — Federated Identity & SSO Flow

SAML (Security Assertions Markup Language) is an XML-based data format used to exchange authentication and authorisation information between an identity provider and a service provider. Enables Single Sign-On (SSO) — users authenticate once with their identity provider (Google, Microsoft) and access multiple service providers without re-authenticating.

Three SAML roles

Identity Provider (IdP)
The entity that authenticates the user and issues SAML assertions. Examples: Google, Microsoft, Okta. Contains the authoritative source of user identity. The user's actual credentials are entered here — not at the service provider.
Service Provider (SP)
The website or application the user wants to access. Trusts assertions made by the identity provider without requiring the user to authenticate directly with the SP. Example: a website that offers "Login with Google."
User Agent (browser)
The user's web browser. Acts as the intermediary between the service provider and the identity provider. The SAML request/response flows through the browser — the SP and IdP never communicate directly.

SAML SSO flow — 8 steps

1
User requests resource — visits the service provider (e.g. diontraining.com) and clicks Login.
2
SP discovers IdP — service provider identifies the identity provider (e.g. "use Google login"). Redirects browser to SSO service.
3
Browser requests SAML from IdP — browser sends the SAML authentication request (encoded in URL) to Google's identity service.
4
IdP authenticates user — Google verifies username and password, collects user attributes.
5
IdP responds with assertion — Google returns an XHTML form to the browser containing a signed SAML assertion (who the user is, what permissions they have).
6
Browser forwards assertion to SP — browser sends the SAML assertion to the service provider's consumer service endpoint.
7
SP verifies and creates session — SP validates the digital signature on the assertion, creates an authenticated session for the user.
8
Ongoing resource access — user receives requested resources. Further requests use the established session without re-authentication.
SAML assertion structure: Contains the user subject (who), conditions (validity window + timestamp to prevent replay attacks), attributes (name, email, role), and a digital signature (ds:Signature for non-repudiation). Requests are encoded and sent as HTTP 302 redirects in the URL. SAML runs over SOAP/HTTP.
4

REST, OAuth2, OpenID Connect & JWT

REST (Representational State Transfer) is a loosely specified architectural framework for web APIs. More flexible than SOAP — accepts HTTP, XML, CSV, or JSON messages rather than requiring strict XML formatting. RESTful APIs are the backbone of modern web services.

REST vs. SOAP
SOAP = tightly specified XML-only protocol with a strict envelope format. REST = flexible framework supporting multiple formats (HTTP/XML/CSV/JSON). REST is generally simpler and faster to develop with. HTTP GET = retrieve data. HTTP POST = send/create data. RESTful APIs are built using standard HTTP methods.
OAuth 2.0
Open Authorization protocol for RESTful APIs. Enables apps to obtain limited access (scopes) to a user's data without the password. Serves four parties: Client (the app), Resource Owner (end user), Resource Server (target service), Authorization Server (IdP). Used for single sign-on via token exchange.
⚠ OAuth = AUTHORISATION, not authentication. OAuth proves what you can do, not who you are.
⚡ Vulnerable to CSRF attacks and open redirects. Attacker tricks browser into performing OAuth actions as the user.
OpenID Connect (OIDC)
Authentication protocol built on top of OAuth 2.0 flows. Adds precisely defined token fields to OAuth to enable identity verification. Pairs with OAuth: OAuth handles what the user can do (authorisation), OIDC handles who the user is (authentication). Together they form a complete auth system.
🔑 Authentication = "who are you?" OIDC verifies identity. Authorisation = "what can you do?" OAuth grants access scopes.
JWT — JSON Web Token
Token format containing a header (algorithm + token type), payload (subject ID, name, email, attributes), and signature (SHA-256 hash for integrity). Pronounced "Jot." Carries authorisation claims — assertions about what the user is allowed to do. Assumes the user is already authenticated. Encoded as Base64 and passed in the URL or HTTP header.
📋 JWT structure: {"alg":"HS256","typ":"JWT"} + {"sub":"id","name":"Jason"} + signature
Auth/AuthZ summary you must know: Authentication = verifying identity (who are you? → username + password → OIDC/SAML). Authorisation = granting access rights (what can you do? → OAuth2/JWT/scopes). You need both. OAuth2 alone can authorise but cannot authenticate — pair with OpenID Connect for authentication.
5

APIs, Webhooks & Plugins

API — Application Programming Interface
Client pulls data. Set of protocols and routines for building and interacting with software applications. Intermediary between systems enabling data exchange. Built using REST or SOAP. The client asks for data and the server responds. Example: polling the Udemy API every 4 hours to check for new student questions. Testing tool: curl --data "firstname=test" https://api.example.com.
Webhook
Server pushes data. Event-driven — server sends data to the client automatically when an event occurs. No polling required. Lower latency than periodic API calls. Example: credit card processor sends a webhook to the voucher system the moment payment is confirmed — instant voucher issuance (minutes vs. hours). More efficient for real-time notifications.
Plugins (connectors / add-ons)
Extend software capabilities. SIEMs use plugins to integrate firewall logs, IDS alerts, and endpoint security. Vulnerability scanners use plugins to support specific OS types (Windows/Linux/mobile) and compliance checks (PCI DSS). Can be vendor-built or third-party. Risk: every plugin added = increased attack surface + potential new vulnerabilities. Only use from trusted sources.
6

Scripting & Cloud Automation

Cloud automation is the completion of cloud-related administrative tasks without human intervention. Without scripting, rapid elasticity — the ability to automatically spin up or down hundreds of instances — is impossible. Scripting is the foundation of orchestration.

What scripting enables
Provision and deprovision resources automatically. Add accounts, assign permissions. Take snapshots of thousands of instances simultaneously without manual work. Handle backup, recovery, and auto-scaling. A 50-line Python script can snapshot all production cloud instances in a region on schedule, saving hundreds of person-hours per year.
Script components
Parameters (inputs the script accepts), logic statements (if/then/else/while control flow), validation (checking inputs before processing), error handling (graceful failure on bad inputs), unit testing (test the script before running it against thousands of instances — a bad script at scale causes massive damage).
Scripting languages
Python (recommended — easy to learn, widely used in cloud automation, cybersecurity, and pen testing), JavaScript, Ruby, Go. For CySA+ exam: you don't need to write scripts. For PenTest+: know Python, Ruby, PowerShell, and Bash — must be able to read them and understand what they do.
7

Workflow Orchestration — Types & Tools

Orchestration = the automation of automations. Taking individual automated steps and chaining them together into a complete workflow. Rapid cloud elasticity — automatically spinning up/down servers based on demand — is driven by orchestration. Three orchestration types:

Resource orchestration
Provisioning and allocating compute resources within a cloud environment. Starting up a new EC2 instance (VM) in AWS is resource orchestration. Manages the underlying infrastructure components — servers, storage, networking.
Workload orchestration
Managing applications and cloud workloads — what runs on the resources. Coordinates multiple services working together to produce a product. Focuses on the components and their interactions rather than the raw infrastructure.
Service orchestration
Deploying services into cloud environments. Higher-level than workload — concerned with the services themselves, their configurations, and their deployments. Used for deploying microservices to production environments.

Orchestration tools (know these for the exam)

Chef
Automates configuration and app management using Ruby-based "cookbooks" and "recipes." Works with VMs, physical machines, containers, and cloud instances.
Puppet
Similar to Chef but requires a master server and client agents on each node. Less code-heavy — suited to ops teams without deep Ruby knowledge. Older generation tool.
Ansible
No user agents needed. Uses YAML "playbooks" for configuration. Master connects to clients over SSH. Simpler to set up than Chef or Puppet. Very popular for modern infrastructure.
Docker
Open platform for developing, shipping, and deploying applications using container-based virtualisation. Each container is an isolated, portable, lightweight environment.
Kubernetes
Abstraction layer for managing containers at scale. If Docker creates containers, Kubernetes orchestrates them — scheduling, scaling, load balancing, and managing their lifecycle automatically.
GitHub
Code sharing and version control platform. Before building an orchestration solution, check GitHub — someone may have already built and shared the code. Use as a starting point and modify for your use case.
8

FaaS & Serverless — AWS Lambda, Netflix & Analyst Role

FaaS (Function as a Service) is a cloud service model that supports serverless architecture by provisioning runtime containers in which code executes without the developer managing any underlying server infrastructure. Serverless = functions run in virtualised runtime containers in the cloud rather than on dedicated server instances.

Key FaaS benefits
No server patching — no server to patch. No administration — no server to manage. No file system monitoring — no server to monitor. Only pay while code is executing (not for idle time). Can cost less than a dollar per month for low-frequency automations. Provider manages all underlying infrastructure, security, and redundancy.
AWS Lambda
Amazon's serverless FaaS platform. Netflix uses it to deliver 10 billion hours of video to 125 million customers per quarter. Netflix writes code in Python (or other languages), Lambda runs it on Amazon's infrastructure. Netflix never touches the underlying servers — Amazon handles everything below the code.
FaaS risks
Emerging technology — no established long-term best practices. Full dependency on the cloud provider's security and reliability. You can't see, touch, or control the underlying servers. Provider must be trusted for security, redundancy, and availability. Decisions made at CIO/CSO level — analysts implement within those decisions.

Analyst role in Serverless environments

Shift from infrastructure to code
In a serverless world, there's no infrastructure to patch, harden, or scan. The analyst's role shifts toward ensuring the code being deployed is secure — secure coding practices, code review, authentication/authorisation design.
Protect developer workstations
The developer's workstation and credentials are the new attack surface. If a developer's account is compromised, the attacker can deploy malicious code that runs on serverless infrastructure. Secure the developer, not the server.
Orchestration is the backbone
Serverless depends completely on automation and orchestration to spin resources up and down quickly. Analysts must understand these orchestration workflows to monitor for anomalies and ensure the orchestration logic itself is secure.
Exam

Quick Reference Cheat Sheet

SOA vs. Microservices
SOA = loosely coupled services with some interdependencies, connected via Enterprise Service Bus (ESB). Microservices = fully independent services, each performs one function (black box), developed/tested/deployed independently, no shared dependencies, more scalable (scale only what you need). Key difference: SOA has interdependencies. Microservices don't. Both use defined inputs and defined outputs. Monolithic = old way, tightly coupled, everything breaks together.
SOAP & its 5 vulnerabilities
SOAP = Simple Object Access Protocol. XML-based. Enables services in different languages to communicate. WS-Security adds integrity + confidentiality. 5 vulnerabilities: 1 Probing (recon/enumeration), 2 Coercive Parsing (crafted XML triggers harmful parser behaviour), 3 External References (remote file inclusion via XML), 4 Malware in XML messages, 5 SQL Injection via SOAP. Best practice: least privilege, deny-by-default, never pass SQL directly over SOAP — process and validate first.
SAML & SSO flow
SAML = Security Assertions Markup Language. XML-based. Used for SSO and federated identity management. 3 roles: Identity Provider (IdP = Google/Microsoft — authenticates the user), Service Provider (SP = your website — trusts IdP's assertions), User Agent (browser — mediates between IdP and SP). Flow: user → SP → browser → IdP → authenticate → SAML assertion → SP → session created. Assertion contains: subject, conditions, attributes, digital signature (ds:Signature). Sent as HTTP 302 redirect encoded in URL.
REST / OAuth2 / OIDC / JWT
REST = flexible API framework (HTTP/XML/CSV/JSON — more flexible than SOAP). OAuth2 = Open AUTHORIZATION 2 (NOT authentication). Serves: Client (app), Resource Owner (user), Resource Server (target), Authorization Server (IdP). Vulnerable to CSRF + open redirects. OpenID Connect (OIDC) = authentication layer on top of OAuth2. Together: OIDC authenticates (who are you?) + OAuth authorises (what can you do?). JWT (Jot) = JSON Web Token. Header+payload+signature. Contains user attributes/claims. Encoded as Base64 in URL. For authorisation, not authentication.
APIs vs. webhooks vs. plugins
API = client pulls data from server on request (polling). Test with: curl --data "key=value" url. Webhook = server pushes data to client when event occurs (event-driven, real-time, lower latency). Analogy: API = you call the restaurant to check if your order is ready. Webhook = restaurant calls you when it's ready. Plugins = extend software functionality. SIEM plugins integrate firewall/IDS/endpoint logs. Scanner plugins add OS/compliance support. Risk: each plugin increases attack surface — use only trusted sources.
Orchestration types & tools
Orchestration = automation of automations. 3 types: Resource (provision VMs/instances), Workload (manage running applications), Service (deploy services). Tools: Chef (Ruby cookbooks/recipes, multi-environment), Puppet (master server + client agents, less code-heavy, YAML-like), Ansible (YAML playbooks, agentless, uses SSH), Docker (container-based virtualisation), Kubernetes (orchestrates Docker containers at scale), GitHub (shared code — check before building from scratch). Third-party platforms prevent vendor lock-in by working across multiple cloud providers.
FaaS & Serverless
FaaS = Function as a Service. Serverless = code runs in virtualised runtime containers without dedicated servers. AWS Lambda = Amazon's FaaS (Netflix example). Benefits: no patching, no admin, no file system monitoring, pay-per-execution only. Risks: new technology, no long-term best practices, full dependency on provider, can't see/touch underlying infrastructure. Analyst role: shifts from infrastructure hardening to code security + securing developer workstations/credentials (developer = new attack surface). Serverless depends on orchestration for rapid elasticity.