Purpose

This crosswalk translates SWIFT's Customer Security Controls Framework (CSCF) — the control set I assess tier-1 banking clients against day to day — into NIST CSF 2.0, the framework most commonly used to communicate cyber risk posture to non-SWIFT audiences (boards, regulators, cross-industry GRC and AI-risk teams). The goal is practical: showing that control-framework literacy transfers, and that assessment methodology built on one standard is the same discipline underneath any framework.

CSCF v2027 (published 10 July 2026, effective for the July–December 2027 attestation window) defines 32 controls across three objectives and seven principles; 26 are mandatory and 6 are advisory. NIST CSF 2.0 organizes its outcomes across six functions: Govern, Identify, Protect, Detect, Respond, and Recover.

Revision note: this replaces an earlier draft built from third-party summaries of CSCF v2026. Verified directly against the official SWIFT CSCF v2027 PDF — two anchor controls were corrected (segmentation is Control 1.1, not 1.2; vulnerability scanning is 2.7, not 7.1) and a seventh anchor control was added to properly cover the Respond/Recover mapping.

Methodology

The mapping works at two levels. First, a structural pass maps each of CSCF's seven principles to its primary NIST CSF function(s) — the level useful for a risk register or a control-inventory conversation with a non-SWIFT team. Second, a control-level pass takes seven representative controls, sourced directly from the official CSCF v2027 control definitions, and maps them to specific NIST CSF categories, showing what "equivalent evidence" looks like across the two frameworks.

Structural Mapping — Principles to Functions

No structural-mapping rows match "".

Control-Level Deep Dive — Seven Anchor Controls

Control text below is paraphrased directly from the official CSCF v2027 control definitions (control objective and control statement), not third-party summaries.

No control-level rows match "".

Observations

• SWIFT's v2027 update to Control 2.2 (Security Updates) now explicitly names AI-driven cyber threats and frontier AI systems as part of the risk the control addresses — a concrete, current example of a mature financial-services cyber framework folding AI risk into an existing control rather than spinning up a separate track.
• v2027 introduces the "Secrets and Keys Vault" (SKV) as a formal, technology-agnostic in-scope component spanning up to thirteen other controls — a good illustration of how a single infrastructure change can ripple across a large fraction of a control framework, equally true in NIST CSF or ISO 27001 environments.
• Control 7.1 (Cyber-Incident Response Planning) is CSCF's strongest link to NIST CSF's RECOVER function, via its mandatory backup/recovery plan requirement — worth citing directly rather than treating CSCF as purely reactive.
• Objective 3 (Detect and Respond) still maps most cleanly to NIST CSF's DETECT and RESPOND functions — the area where SIEM/monitoring experience (Wazuh, in my case) transfers most directly regardless of which framework a client uses.
• The most common CSCF assessment failure is a control that is implemented but not evidenced — the same failure mode NIST CSF, SOC 2, and ISO 27001 all penalize. Framework fluency is less about memorizing control numbers and more about recognizing this one failure pattern everywhere it shows up.

Purpose

Most AI governance material is written by people who have never built the system they're assessing. This document applies NIST's AI Risk Management Framework (AI RMF 1.0, GOVERN / MAP / MEASURE / MANAGE) and its Generative AI Profile (NIST AI 600-1, 12 risk categories specific to generative AI) to a system I designed and am actively building myself — an Azure-hosted retrieval-augmented generation (RAG) pipeline. The goal is to show what a governance assessment looks like from the builder's seat: honest about what's actually been tested versus what's planned, rather than a theoretical best-practice writeup.

System under assessment: a six-phase Azure RAG build — Entra ID identity and Azure Storage (Phase 1, complete), Azure AI Search indexing (Phase 2, in progress), followed by retrieval validation, Flask-based deployment, a dedicated red-team phase, and KQL-based production monitoring (Phases 3–6, planned).

This is a mid-build assessment, not a post-deployment audit — several MEASURE and MANAGE items below are stated as plans rather than completed controls. That distinction is deliberate: NIST AI RMF is meant to be applied across the full lifecycle, including before a system is finished, not only at launch.

GOVERN

GOVERN is the cross-cutting function — it's meant to sit above the other three and make them repeatable, not skipped for being "just a personal project."

MAP

MAP scopes the system and its risk. Applying all 12 NIST AI 600-1 generative-AI risk categories — including the ones rated N/A — is itself the point: it shows every category was reviewed and screened out deliberately, not simply omitted.

MEASURE

NIST AI RMF expects measurement to be tied to the system's actual maturity, not applied uniformly regardless of build stage.

MANAGE — Case Study

MANAGE is where a framework meets production reality, and the clearest example I can offer isn't the RAG pipeline itself — it's a related, already-built system: a Python agent that polls Wazuh SIEM alerts, enriches them via VirusTotal and AbuseIPDB, and routes them to an LLM API for triage reasoning, delivering results via Teams Adaptive Cards and Sprints tickets.

• Triage reasoning is treated as a recommendation, not an automated action — every output requires human review before an alert is closed or escalated, specifically because a confident-but-wrong output on a security alert is a worse failure mode than a slower human-only process.
• Flagged internally as needing a formal compliance review before production, given ECS Fin's SWIFT-certified posture — a human-in-the-loop design is only a real control if it's documented and consistently enforced, not just true in practice.
• No incident database yet for tracking triage errors or near-misses — NIST AI RMF's MANAGE function expects exactly this kind of tracking, and it's the clearest concrete gap between this system and full RMF alignment.

Observations

• Applying MAP before Phase 2 is complete — rather than after the system is built — surfaced access-control and value-chain risks early enough to influence Phase 2 indexing decisions.
• The single clearest gap across both systems assessed here is MANAGE-function tracking — no formal error/near-miss log exists for either. Building one is the next concrete step, ahead of any further feature work.
• Screening all 12 risk categories rather than only the obviously relevant ones caught two I would have otherwise skipped by assumption — Environmental Impacts and Value Chain & Component Integration — a skipped category reads as an oversight, not a deliberate scope decision.

Overview

Most SIEM deployments stop at detection — an analyst still has to notice the alert, open a ticket, and notify the right channel by hand. This project closes that loop: Wazuh detects, Tines orchestrates the response, and Clawdbot — a Slack bot I deployed and configured for this pipeline — delivers a formatted, human-readable alert card to the SOC channel in seconds instead of hours.

Architecture

Wazuh's rule engine evaluates incoming log data and fires a JSON alert payload on match. That payload is forwarded via webhook to a Tines "story" — Tines's term for a no-code automation workflow — which parses the relevant fields (rule ID, severity, agent, rule description, MITRE ATT&CK tag when present) and branches based on severity.

From there, three things can happen depending on the branch: a host-isolation API call for high-confidence, high-severity matches; a ticket created automatically in the tracking system; and, in every case, a Slack notification. That last step routes through Clawdbot, which takes the raw Tines JSON output and renders it as a color-coded alert card — red for high severity, amber for medium, green for informational — so an analyst scanning the channel can triage by glancing at color before reading a word.

Design Decision — Human-in-the-Loop Containment

The pipeline is deliberately not fully autonomous. Notification is automatic; containment is not. Host isolation only fires for a narrow set of high-confidence rule matches, and even then it's the exception rather than the default — most branches end in a formatted Slack card and a ticket, waiting on human judgment before anything gets touched. That's the same principle I apply to the newer Wazuh-to-LLM triage agent documented elsewhere on this site: automation should compress the time-to-notice, not remove the human from the decision that matters.

Detection Tuning

The pipeline is only as useful as the signal feeding it. Early iterations forwarded every Wazuh alert to Tines regardless of confidence, which produced exactly the alert fatigue this project was supposed to solve. Tuning happened at the source — refining Wazuh rule thresholds and decoder logic so only alerts worth a human's attention reach the Slack channel at all, rather than trying to filter noise downstream in Tines.

Outcome

Mean time to notification dropped from a manual, hours-scale process (an analyst noticing an alert in the Wazuh dashboard, then manually posting to Slack) to a low-single-digit-seconds automated pipeline. The bigger win was consistency — every alert that crosses the severity threshold gets the same formatted treatment, every time, instead of depending on whoever happens to be watching the dashboard.

Next step: formalize an error/near-miss log for this pipeline — the same MANAGE-function gap I flagged in the NIST AI RMF self-assessment of my Wazuh-to-LLM triage agent applies here too. Automation that silently misfires is worse than automation that doesn't exist.

Overview

Every other project on this site runs on top of this one. Before any Kerberoasting exercise, Wazuh rule tuning, or SOAR pipeline could exist, there had to be a network to run it on — segmented realistically enough that offense and defense actually mean something, instead of every VM sitting flat on the same subnet.

Architecture

pfSense sits at the center as both firewall and VLAN gateway, running IDS/IPS on traffic crossing segment boundaries. Wazuh has its own VLAN and receives log forwarding from every other host in the lab, giving it visibility across segments rather than being confined to watching its own traffic. The Kali attack box lives on a deliberately isolated VLAN — any traffic it sends toward a target has to traverse pfSense, which means that traffic is inspectable and rule-matchable, the same way a real attacker pivoting from a compromised host would have to cross a monitored boundary.

Why Segmentation Matters Here

A flat lab network makes every exercise easier than it should be — an attack box with unrestricted access to every target teaches bad muscle memory. Firewall rules on pfSense restrict the attack VLAN to specific target VMs only, and Wazuh's cross-VLAN visibility means detection exercises are testing against the same boundary an attacker would actually have to cross, not an artificial shortcut.

Proxmox's snapshot capability is what makes repeated offense/defense cycles practical — a domain controller can be compromised, rebuilt from snapshot in minutes, and re-attacked with a different technique, without a multi-hour reinstall between each exercise.

Origin & Iteration

This started in 2023 as a single Kali Linux VM, following tutorials and breaking things with no real network design behind it. The current four-node architecture is the result of iterative expansion — adding pfSense for segmentation once flat-network limitations became obvious, then Wazuh once detection engineering became the actual point of the lab rather than an afterthought.

Overview

Full-scope web application penetration test covering reconnaissance, automated scanning, manual verification, and exploitation, resulting in 12 documented vulnerabilities across the OWASP Top 10, each scored with CVSS 3.1 and paired with remediation guidance. Assessment was conducted running Burp Suite from a Windows tablet — a deliberate constraint to confirm the methodology holds up outside a dedicated pentest workstation.

Methodology

• Reconnaissance — subdomain enumeration, technology fingerprinting, and endpoint mapping to establish the application's attack surface before any active testing began.
• Automated triage — Burp Suite's active and passive scanners run first to surface low-hanging findings and establish a baseline, treated as a starting point rather than a deliverable.
• Manual verification — every automated finding manually re-tested to eliminate false positives, then manual testing extended into categories automated scanners routinely miss: business logic flaws, authorization boundaries, and multi-step workflow abuse.
• Exploitation & PoC — working proof-of-concept built for each confirmed finding, demonstrating real impact rather than a theoretical description.
• Scoring & reporting — each finding scored under CVSS 3.1, with remediation guidance mapped to the relevant OWASP ASVS control.

Representative Finding Categories

The IDOR finding was the highest-priority item in the report — the kind of finding that's trivial to exploit once found (no tooling required beyond changing a number in the URL) but easy for automated scanners to miss entirely, since it requires understanding what the application is supposed to enforce, not just what it returns.

Deliverable

Final report structured for two audiences at once: an executive summary with risk-ranked findings for stakeholders who need the headline, and full technical detail — reproduction steps, PoC, CVSS breakdown, and remediation guidance — for the engineering team that has to fix each issue.

Overview

Built and validated a complete Active Directory Domain Services implementation in an isolated lab environment, translating a formal 11-section AD implementation plan into a working, tested deployment — starting from a single blank server and ending with two domain controllers that together handle authentication, DNS, and policy enforcement for an entire simulated network, with no single point of failure.

This lab is the direct precursor to the AD Implementation Plan I authored for ECS Fin's production data center — the OU structure, GPO layering, and hardening decisions below were tested here first, before being proposed for a SWIFT-regulated environment.

Architecture & Access Control

Promoted a blank Windows Server into the forest root domain controller for a new domain, ecslab1.local, with a static IP so it could always be resolved reliably. From there, built a team-based OU structure — Operations-Maintenance, Development, Deployment, and Finance — so accounts could be grouped and governed by team rather than sitting in one flat bucket.

Group Policy was layered rather than flat: a domain-wide baseline (password complexity, account lockout threshold) applied at the top so it flows down to every OU automatically, plus an additional policy scoped only to Operations-Maintenance for extra audit logging. This proved GPO inheritance actually stacks as designed — a user in Operations-Maintenance inherits both the domain-wide baseline and their team's extra policy, while every other team only gets the baseline.

Troubleshooting Under Real Conditions

Validating the policy — not just configuring it — surfaced a real bug: a second, older default policy was silently overriding the intended password baseline. Windows resolves conflicting GPOs by link order, and the new policy wasn't winning. Diagnosed the root cause, corrected the link-order precedence, and confirmed the fix using Group Policy Modeling rather than trusting the configuration screen at face value.

Security Hardening

Layered a third, CIS-aligned hardening policy on top of the baseline and team-specific policies: logon success/failure auditing, enforced password expiration, and disabling the legacy SMBv1 protocol — the same attack surface WannaCry exploited. Each control was verified as actually active on the running system, not just defined in policy, which matters because a setting that's configured but never enforced is worthless.

Live Validation, Not Just Configuration

Rather than assuming the audit policy worked because it was configured, triggered real test events — an account modification and a simulated lockout — and confirmed the correct Security event IDs (4738, 4740) generated correctly. This directly validates the SIEM monitoring integration point in the original implementation plan: a logging policy is only as good as the events it actually produces when something real happens.

Multi-Master Replication

Provisioned and promoted a second domain controller — not a passive backup, but an equally active twin capable of independently handling authentication, DNS, and policy enforcement at the same time as the first. If the first DC disappeared, the second could keep the environment running for nearly everything.

Immediately after promotion, DC2 couldn't reliably sync with DC1 — a DNS resolution issue where DC2 was effectively querying itself for name resolution before it had fully learned the domain. Fixed by pointing DC2's DNS client at DC1 first, itself second — the standard correct configuration for any second domain controller, not a one-off patch.

Proved true multi-master replication by querying an object created on DC1 directly against DC2, and getting back a correct, matching answer — not a status message claiming replication succeeded, but an actual live answer confirming it.

Why This Matters

The technical build is the easy part to demonstrate. The harder part — the one that actually maps to GRC and stakeholder-facing work — is catching and fixing two genuine bugs along the way (the GPO link-order conflict and the DNS resolution issue) rather than following a checklist and assuming success. Both fixes came from validating outcomes directly instead of trusting configuration screens, which is the same standard I apply to SWIFT CSCF assessment evidence: a control isn't proven by being configured, it's proven by generating the right evidence when tested.

Overview

A closed-loop exercise: attack a simulated Active Directory environment using real adversary techniques, then flip sides and build the detections that would have caught each one. The point isn't the offensive technique itself — Kerberoasting and Pass-the-Hash are both well documented — it's understanding each attack well enough to know exactly what evidence it leaves behind, which is what makes the resulting Splunk detections precise instead of noisy.

Offense

• Kerberoasting — enumerated service principal names (SPNs) across the domain, requested TGS tickets for the associated service accounts, and took them offline for cracking against weak service-account passwords.
• Pass-the-Hash — harvested NTLM hashes from a compromised host and replayed them to authenticate laterally without ever needing the plaintext password.
• BloodHound path discovery — collected AD relationship data (active sessions, ACLs, group memberships, delegation rights) and computed the shortest graph path from an initial low-privilege foothold to Domain Admin.

Defense

Each offensive technique got translated into a corresponding Splunk detection, built from the specific event signature that technique leaves behind rather than a generic rule:

• Kerberoasting detection — abnormal volume of TGS requests (Windows Event ID 4769) using RC4 encryption from a single source within a short time window, since legitimate service authentication rarely produces that pattern.
• Pass-the-Hash detection — anomalous logon type 3/9 activity paired with NTLM authentication originating from hosts that don't normally authenticate that way, flagging lateral movement that skips normal interactive logon patterns.
• GPO hardening — disabled unconstrained delegation where not explicitly required, enforced AES-only Kerberos encryption to eliminate the RC4 downgrade path Kerberoasting depends on, and restricted local admin group nesting to cut down BloodHound-discoverable attack paths.

Why This Matters Beyond the Lab

This exercise is where I first got comfortable with Event ID 4769 and the broader audit-event vocabulary that shows up constantly in production AD monitoring — including Event ID 4719 (audit policy tampering), which I now investigate directly in a regulated, SWIFT-certified environment at ECS Fin. The GPO hardening decisions tested here — encryption enforcement, delegation restrictions, admin group discipline — are the same categories of control that later became part of a formal 11-section Active Directory Implementation Plan I authored for ECS Fin's production data center.

Summary

Cybersecurity analyst with hands-on SOC operations and SWIFT Customer Security Controls Framework (CSCF) assessment experience for tier-1 banking clients in a regulated financial-services environment. Combines detection engineering (SIEM/XDR, SOAR automation) with a business analytics foundation and a growing GRC and AI-risk assessment skillset. Pursuing an M.S. in Cybersecurity at Georgia Tech alongside active work toward SWIFT CSP Assessor certification.

Core Competencies

SOC Monitoring & Alert Triage · SWIFT CSCF Assessments · Detection Engineering · SIEM/XDR (Wazuh, CrowdStrike Falcon) · SOAR Automation · Risk & Controls Assessment · Incident Response · Active Directory Security · Python / Bash Scripting · AI Risk Governance (NIST AI RMF)

Professional Experience

SWIFT-Certified Independent Assessment Provider & Cyber Security Service Provider · Somerville / New York, NJ

• Conduct SWIFT Customer Security Controls Framework (CSCF) assessments for tier-1 banking clients, evaluating architecture types A1–B against the framework's mandatory and advisory controls, and contributing to KYC-SA attestation readiness.
• Monitor and triage security alerts across Wazuh SIEM and CrowdStrike Falcon EDR/Falcon Fusion SOAR in a production, regulated environment, investigating brute-force attempts, SWIFT SAA outages, audit-policy tampering (Windows Event ID 4719), firewall rule failures, and agent buffer-flood events.
• Built a Python-based alert triage agent that enriches Wazuh alerts via VirusTotal and AbuseIPDB, applies LLM-assisted reasoning, and delivers human-reviewed recommendations via Teams Adaptive Cards and Zoho Sprints tickets — flagged for formal compliance review ahead of any production rollout given the environment's SWIFT-certified posture.
• Authored an 11-section Active Directory Implementation Plan for ECS Fin's data center covering OU structure, GPO strategy, CIS benchmark hardening, multi-master domain controller redundancy, Wazuh monitoring integration, and a hybrid identity future-state roadmap, delivered for senior stakeholder review.
• Built and validated a physical Windows Server Active Directory lab (ADDC-Test) to test implementation decisions before rollout, including static IP and scope configuration ahead of stakeholder sign-off.
• Built Power BI dashboards from Wazuh log exports surfacing RDP session anomalies and unauthorized account creation, identifying a cross-dataset compromise pattern spanning RDP activity, software installs, and new account creation on a single host.
• Developed Python webhook integrations for SWIFT-related MQ and SAA infrastructure monitoring via Wazuh, and built a Wazuh-to-Teams Adaptive Card alert delivery pipeline used across the SOC.
• Contributed to CIS benchmark validation and audit readiness, and researched MISP threat-intelligence integration and CrowdStrike Falcon SIEM Connector deployment to close detection-tooling gaps.

• Built structured dashboards and analytical reports in Excel and SQL, and automated recurring reporting workflows — strengthening data analysis and systematic problem-solving skills directly applicable to security operations.

• Operate an independent e-commerce resale business since 2013, managing inventory, logistics, and fraud/risk exposure; designed and built Aperture, a Node.js order-tracking dashboard with AES-256-GCM encrypted credential storage, IMAP-based email ingestion, and live carrier tracking integrations.

Technical Projects

• Azure RAG Pipeline (in progress) — six-phase build combining Entra ID identity, Azure AI Search indexing, Flask deployment, adversarial red-teaming, and KQL-based production monitoring; governed against the NIST AI Risk Management Framework and NIST AI 600-1 Generative AI Profile.
• SWIFT CSCF → NIST CSF 2.0 Crosswalk — mapped all 32 SWIFT CSCF v2027 controls against NIST CSF 2.0's six functions, verified directly against the official framework text, to support cross-framework GRC translation work.
• Home Lab — Ubuntu 24.04 environment running Wazuh and Velociraptor for independent detection engineering research and SWIFT CSP Assessor exam preparation.

Education

M.S. Cybersecurity, Information Security — Georgia Institute of Technology (OMS)

B.S. Business Analytics & Information Technology — Rutgers Business School

Certifications

SWIFT CSP Assessor (In Progress) · Security+ & CCNA-level fundamentals (self-studied)