1

CI/CD — Continuous Integration, Delivery & Deployment

Traditional software deployment was slow, linear, and siloed — developers, testers, integration teams, and operations teams each worked in sequence, handing off to the next group. A new feature could take 9–12 months from development to production. CI/CD compresses this dramatically.

Old Waterfall vs. CI/CD Pipeline — From Months to Hours
❌ Old Waterfall — Sequential, Siloed
Dev
→
Test
→
Integrate
→
Stage
→
Production
⏱ 9–12 months per feature · Different teams per stage · High conflict between handoffs
✅ CI/CD — Automated Loop, Hours to Days
Code
→
CI Server
(build+test)
→
CI
validated
→
CD
(delivery)
→
CD
(deploy)
→
Production
in hours
⚡ CI: build & test on commit → CD (Delivery): validated & ready → CD (Deployment): auto-pushed to staging/production
CI = Continuous Integration: commit → build → test → merge (detect conflicts early) Delivery = tested & validated, ready but not yet released Deployment = automatically released to staging then production
Continuous Integration (CI)
All developers commit to a shared code repository frequently (multiple times daily). Each commit triggers automatic build and test. Detects conflicts between developers' changes early rather than discovering them weeks later when 50 people's changes all diverge. Prerequisite for CD.
Continuous Delivery (CD1)
Code is automatically tested, validated for compliance, and made ready to release — but it isn't automatically released. A human decides when to push to staging or production. Requires CI as a foundation. Focused on readiness, not release.
Continuous Deployment (CD2)
The next step beyond delivery — validated code is automatically deployed to staging and then production at regular intervals with no manual intervention. Security fixes can go from development to production in hours instead of months. Requires both CI and Continuous Delivery.
CI/CD dependency chain: CD (Delivery) requires CI. CD (Deployment) requires both CI and Delivery. But CI does NOT imply Delivery, and Delivery does NOT imply Deployment. Think of it as: if you have Deployment (the furthest right), you must be doing all three. If you only have CI, you're not doing Delivery or Deployment.
2

DevSecOps — Shift-Left & Integrated Security

DevOps combined Development and Operations into a single cross-functional team — software built and supported by the same people, deployed faster and more reliably. But security was still an afterthought. DevSecOps adds Security into that integrated team from day one.

The shift-left mindset
In old SDLC, security and testing happened at steps 5–8. Shift-left means moving security to step 1 — into the development phase before any code is written. Security considerations, compliance requirements, and threat modelling happen alongside design and coding, not after delivery. Earlier = cheaper and faster to fix.
Three DevSecOps benefits
1. Integrate security from day one (cheaper to build in than bolt on). 2. Test security during and after every development cycle, not just at the end. 3. Automate compliance checks — run code against HIPAA, PCI DSS, or SOX checks automatically every commit. Security issues caught before production, not after.
DevOps → DevSecOps evolution: Old = Dev team throws code over the wall to Ops. DevOps = Dev + Ops in one team. DevSecOps = Dev + Sec + Ops in one team. The shift-left mindset = moving security earlier in the SDLC. Key phrase on the exam: "integrating security into the development process from the beginning" = DevSecOps.
3

Infrastructure as Code (IaC) — Idempotence & Snowflakes

Infrastructure as Code (IaC) is a provisioning architecture where deployment of resources is performed by scripted automation and orchestration rather than manual configuration. Scripts don't make mistakes — a tested, verified script produces the same correct output every time.

Three IaC components
Scripts (automation code that provisions infrastructure), Security templates (pre-approved secure configurations for all resource types), and Policies (governance rules that all scripts must comply with). Together these ensure every deployment meets security requirements without human error.
Idempotence
A property of IaC where automation always produces the same result regardless of the component's previous state. Run the script once or a hundred times — the output is identical. Eliminates "drift" where manual changes cause servers to deviate from their intended configuration over time.
Snowflake systems
Any system that deviates from the standard configuration template — a "special one-off." Created when someone thinks their situation requires a unique setup. Problems: security gaps (your hardening scripts don't apply to it), support nightmares (different from everything else), compliance risks. Default policy: no snowflakes. Exceptions require high-level approval.
The snowflake anti-pattern: In a cloud environment with 10,000 VMs, if 9,999 are standardised and 1 is a snowflake, every support call starts with "is it the snowflake?" Security patches apply to 9,999 but not the 1 — which becomes your attack surface. Enforce standardisation ruthlessly. The efficiency and security benefits of IaC are destroyed by every snowflake exception.
4

AI, Machine Learning & Deep Learning

The hierarchy

Artificial Intelligence (AI)
The science of creating machines with the ability to develop problem-solving and analysis strategies without significant human direction. Encompasses all sub-fields including ML and deep learning. Original AI = rule-based expert systems (if-then-else). Modern AI = machines that can learn.
↓ Machine Learning is a component of AI
Machine Learning (ML)
Enables machines to develop strategies for solving a task given a labelled dataset with features manually identified. Humans train the model: "This is malware. This is not." The system builds an artificial neural network (ANN — input/hidden/output layers) from that training data and then makes its own classifications. Adjusts neural networks over time to reduce errors. Only as good as the training dataset.
↓ Deep Learning is a refinement of Machine Learning
Deep Learning
ML without the need for explicit human labelling instructions. Feed it the dataset and it discovers its own patterns and builds its own complex knowledge hierarchy. Uses classes of knowledge defined in relation to simpler classes. Example: network traffic analysed for anomalies without a human labelling each flow as "malicious" or "benign." Still needs initial direction but trains itself far more independently. More powerful but requires more data.
Training data bias — a real danger: Machine learning is only as good as the dataset used to train it. A biased dataset produces a biased model. Example: if a model is trained on images of "parties" that only include white people, it learns that white people = parties. In cybersecurity: if your training malware dataset misclassifies anything, the model inherits that mistake at scale across every detection it makes. Always audit training datasets for quality and representativeness.
5

Data Enrichment & Malware Signatures

Data enrichment is the process of incorporating new updates and information from external sources into an organisation's existing database to improve its accuracy and usefulness. In cybersecurity, this means combining your SIEM data with threat intelligence feeds, partner data, and open-source intelligence to give analysts more context.

Data enrichment in practice
Your SIEM sees your network traffic. But without threat intelligence from third-party feeds, you might not know that an IP address connecting to your server is a known C2 server. By enriching your SIEM data with external threat feeds, you surface that context automatically, dramatically improving alert quality and reducing analyst investigation time.
Reducing false positives
AI-based systems can combine indicators from multiple threat feeds to reduce both false positives (alert on benign events) and false negatives (miss real threats). More data sources = more confident classification. The goal is to surface the most important alerts to analysts while suppressing noise — making human time more valuable.
Malware signatures & AI
Traditional signature-based detection: reverse engineer malware → extract byte sequence signature → write rule. Problem: change one byte = new signature = detection evaded. AI solution: give the model the known signature and train it to also flag similar variants. ML can identify modified versions that would bypass exact-match signatures. Humans provide the seed; AI extends the coverage.
AI limitations: admin actions
AI struggles with administrative actions that are identical whether malicious or legitimate. Creating a new admin account, changing a policy, moving files — all normal operations that can also be attack steps. The distinguishing factor is intent, which AI cannot determine from the action alone. Humans remain essential for these ambiguous, context-dependent decisions.
6

SOAR — Playbooks, Runbooks & SIEM 2.0

SOAR (Security Orchestration, Automation and Response) is a class of security tools that facilitates incident response, threat hunting, and security configuration by orchestrating and automating runbooks and delivering data enrichment. Think of it as SIEM 2.0.

SIEM (Generation 1)
Collects logs and events from across the environment. Correlates them using rules. Generates alerts. Shows analysts what happened. Requires human intervention to investigate and respond to every alert. High analyst workload from alert volume.
SOAR = SIEM + Automation (Generation 2)
Everything SIEM does PLUS: enriches data automatically using ML and threat feeds. Automates repetitive investigation steps via runbooks. Takes automated response actions (isolate a machine, create a ticket, disable an account). Leaves only complex decisions for human analysts. Dramatically reduces alert fatigue.

Playbook vs. Runbook

📋 Playbook
A checklist of actions to detect and respond to a specific incident type. Manual steps written out in sequence. Example: "If phishing link clicked — 1. Go to machine. 2. Isolate from network. 3. Run virus scan. 4. Back up user data. 5. Reformat. 6. Reinstall." Human-driven, step-by-step guide. The foundation for automation.
⚡ Runbook
An automated version of a playbook with clearly defined human interaction points. The SOAR executes the steps automatically, pauses at decision points ("re-image this machine?"), sends to an analyst for approval, then continues execution based on the human's decision. Reduces analyst workload to only the decisions that require human judgement.
What SOAR can automate
Provision new cloud resources. Create or disable user accounts. Isolate infected VMs from the network. Delete and recreate VDI sessions. Enrich alert data with threat intelligence. Generate incident tickets. Trigger vulnerability scans. All without human intervention — freeing analysts for threat hunting and complex IR decisions.
Primary SOAR use case
Incident response is the primary use case. Threat hunting is secondary. The objective: automate the routine, repeatable steps so analysts focus only on decisions that require human judgement. Cybersecurity talent is scarce — every minute an analyst spends on automatable tasks is wasted capacity.
7

Standardised Processes — Six Sigma, Lean & CSI

Standardisation = consistent, repeatable guidelines, procedures and best practices for security operations (SOPs, documentation, IR playbooks). Process improvement = systematically identifying and eliminating waste and inefficiencies. Three benefits of standardisation: improved efficiency, increased visibility, enhanced collaboration.

Six Sigma
Data-driven quality improvement methodology. Key steps: Define → Measure → Analyze → Improve → Control (DMAIC). Iterative. Reduces defects and errors. Applied to security ops: improve IR times, reduce errors in detection, streamline SOC workflows.
Lean
Focuses on minimising waste and maximising value. Eliminate unnecessary steps, streamline information flow between teams. Applied to security ops: remove redundant manual processes, reduce handoff delays, improve signal-to-noise in the SOC.
CSI
Continual Service Improvement — ongoing monitoring of security metrics, identifying improvement areas, implementing changes iteratively. Not a one-time project but a permanent continuous feedback loop embedded into SOC operations.
8

Single Pane of Glass

A Single Pane of Glass is a central management console that provides a unified view of all security-related information, tools, and systems — logs, alerts, reports, incident tracking, and threat data — from multiple sources in one interface. Eliminates the need to log into multiple systems to see the security picture.

Key benefits
Simplifies security management — one unified view replaces dozens of separate consoles. Automates collection and analysis of log data, freeing analysts for higher-value work. Improves collaboration — all team members see the same data and can coordinate responses. Easier regulatory compliance — generates required logs and reports from a single location.
How it integrates data
Uses APIs, webhooks, plugins, and connectors to collect data from log servers, IDS/IPS, SIEM, SOAR, vulnerability scanners, endpoint security, and other sources. Data is correlated and normalised into a unified format so disparate data sources can be analysed together. Implementation is almost always software-based for flexibility.

Five implementation steps

1
Define requirements — identify which data types (logs, alerts, reports), tools (IDS, IR platforms), and information the security team needs to do their job.
2
Identify and integrate data sources — find all data sources (log servers, IDS, SIEM, endpoints) and connect them using APIs/webhooks/plugins. Normalise data formats so everything correlates correctly.
3
Customise the interface — design panels and views that surface the right information for the team. Clear, organised layout enabling fast decision-making during incidents.
4
Develop SOPs and documentation — write standard operating procedures so every analyst knows how to use the console and what the processes are. Ensures consistency and repeatability.
5
Continuously monitor and maintain — regularly review data quality, adjust configurations as the environment changes, and ensure the console itself is secured against unauthorised access (it holds all your critical security data).
Exam

Quick Reference Cheat Sheet

CI/CD pipeline
CI (Continuous Integration) = commit → build → test → merge to shared repo. Detects dev conflicts early (multiple commits per day). CD (Delivery) = CI + automated testing validates code is ready for release — NOT released automatically. CD (Deployment) = CI + Delivery + auto-release to staging and production. Dependency: Deployment requires Delivery requires CI. Old waterfall = 9–12 months per feature. CI/CD = hours to days. Exam: these are rarely tested in depth.
DevSecOps & IaC
DevOps = Dev + Ops in one team (faster delivery). DevSecOps = Dev + Sec + Ops (faster AND more secure). Shift-left = move security testing earlier in SDLC (cheaper and faster to fix early). IaC = provision infrastructure via scripts, not manual config. 3 components: scripts + security templates + policies. Idempotence = same input always produces same output. Snowflake = a one-off system that deviates from standard template — creates security gaps, support complexity. Default answer: no snowflakes.
AI / ML / Deep Learning
AI = machines that develop problem-solving strategies. ML = AI component where humans train the model with labelled data → builds artificial neural network (ANN). Deep Learning = refinement of ML where machine learns patterns without explicit human labelling — more autonomous. Critical warning: ML is only as good as the training dataset. Bad training data = biased/incorrect model. AI struggles with administrative actions where intent determines maliciousness. Humans essential for ambiguous context-dependent decisions.
Data enrichment
Adding external context (threat feeds, partner data, OSINT) to SIEM events to improve detection accuracy. Reduces false positives AND false negatives. Malware signatures: traditional = exact byte match → one changed byte = evasion. AI-enhanced = feed known signature + train to detect variants. ML can flag modified versions that bypass signature detection. Limitation: AI can't determine intent behind admin actions (creating accounts/moving files = normal or malicious?). Data quality = detection quality.
SOAR — SIEM 2.0
SOAR = Security Orchestration, Automation and Response. Think of as next-gen SIEM. SIEM = collects + correlates + alerts. SOAR = SIEM + enrichment + automation + automated response. Primary use: incident response. Secondary: threat hunting. Playbook = manual checklist of IR steps for a specific incident type. Runbook = automated playbook with defined human approval points. Automates: isolating machines, disabling accounts, re-imaging VDI, creating tickets. Goal: human analysts handle only decisions requiring judgement.
Standardised processes & Single Pane of Glass
Standardisation benefits: improved efficiency, increased visibility, enhanced collaboration. Process improvement types: Six Sigma (DMAIC: Define/Measure/Analyze/Improve/Control — quality and defect reduction), Lean (minimise waste, maximise value), CSI (Continual Service Improvement — ongoing feedback loop). Single Pane of Glass = unified security console aggregating all tools, logs, alerts, reports. 5 implementation steps: Define requirements → Integrate data sources → Customise interface → Develop SOPs → Continuously monitor. Software-based (most flexible). Secure the console itself — it holds all critical data.