DEV Community: Charles Givre

How to Brief a Board on AI Security: A CISO's Structure

Charles Givre — Wed, 29 Jul 2026 14:06:43 +0000

The EU AI Act's high-risk obligations arrive in August 2026, and a lot of security leaders are about to give their first serious AI briefing to a board that has started asking pointed questions. Most of those briefings will go badly, for a predictable reason: they will describe AI risk in general terms when the board wants to know about this company.

A board does not need an education in transformer architectures. It needs to know whether the organization is exposed, who owns the problem, and what decision is being asked of it.

What the board is actually deciding

Boards do not manage risk. They allocate authority and money, and they establish whether management has the situation in hand. Every AI security briefing should therefore end in a specific ask: fund an inventory, authorize an approval gate with teeth, accept a documented risk, or approve headcount.

If you reach the end of your slot without asking for something, you have delivered a status report. Boards tolerate those and forget them.

Bring four numbers you can defend

The difference between a credible briefing and a nervous one is whether the speaker can say where each number came from. Four are worth the slot.

How many AI systems are deployed, and how many have a named owner. The owner count matters more than the total. Pull the list from procurement records, your CMDB, and the OAuth application grants in your identity provider (Entra ID or Okta will show you which third-party AI tools employees have already connected to corporate accounts, which is usually the number that surprises people).

What data classes are reaching external model providers. Source this from DLP and egress tooling (Microsoft Purview, Netskope, Zscaler) rather than from policy. Policy tells the board what is permitted. The board is asking what is happening.

How many AI systems can take an action, not merely produce text. A summarizer and an agent with write access to a ticketing system belong in different risk tiers. This number is your blast radius, and it is the one that most cleanly separates AI risk from ordinary vendor risk.

What fraction of AI vendor contracts carry data retention and training-use terms. Legal usually has this and has never been asked to count it.

Four numbers, each traceable to a system of record. That is a defensible briefing. A maturity score you cannot reconstruct under questioning is not.

The three questions you will get

Are we exposed? Answer with the inventory and egress numbers, then name the single largest concentration of risk rather than listing everything. Boards remember one thing.

Are we behind our peers? Resist the benchmark you cannot substantiate. What you can say honestly is which practices are becoming standard: an AI asset inventory, a documented approval gate, and contract terms covering retention and training use. Position against those, not against an invented industry percentile.

What will this cost? This is where briefings collapse, because the honest answer depends on a scope decision the board has not made. Present two or three scoped options with costs attached and let the board choose. Inventing a single number to sound decisive is how CISOs end up defending a figure they never believed.

What to leave out

Framework recitation. Naming NIST AI RMF, ISO/IEC 42001, and the EU AI Act is fine as one line establishing that a structure exists. Walking a board through the four functions of the NIST framework is not a board conversation, and it reads as filling time.

Threat theater, too. Deepfake fraud is real and directors will ask about it, but if it consumes more of your slot than your own deployment posture, the agenda came from the news rather than from your risk register. The same applies to technical attack detail: prompt injection is worth one clear sentence about why an AI assistant connected to internal documents is an exploitable path (OWASP LLM01, MITRE ATLAS AML.T0051), and not worth a diagram.

Where this structure does not apply

It assumes you have an inventory. If you cannot say what AI is running in your environment, do not build a four-number deck on estimates. The correct briefing in that situation is short: state the gap, explain that everything else depends on closing it, and ask for a window and a budget. That version is uncomfortable to deliver and considerably more survivable than a dashboard that falls apart on the second question.

It also assumes the board is engaged enough to decide something. A board that wants reassurance rather than decisions is a different problem, and a governance problem rather than a briefing problem.

The judgment to hold this conversation is what the executive AI course we teach for security leaders is built around. For the underlying material, the posts on AI governance for security executives and the AI risk blind spots CISOs miss go deeper. The one-day executive course works through it with other security leaders in the room, and if the board date is sooner than that, we also brief leadership teams directly.

How to Tell if an AI Security Tool Actually Uses Real AI

Charles Givre — Mon, 27 Jul 2026 17:11:00 +0000

Ask a vendor whether their product uses machine learning and you will get a yes. Ask for the model architecture and you will get a slide. Neither answer tells you what is running in the detection path.

You do not need the vendor's cooperation to find out. Four tests, run from outside the box on data you control, will tell you whether the thing scoring your events has learned parameters or is a weighted condition list with an AI label on the box. None of them require the vendor to open the model.

A Rule Engine Is Not the Problem

If a product scores an event by summing weights across 30 conditions, that can be a good detection engine. Rules are readable, predictable, and tunable by an analyst at 3 a.m. Plenty of detection problems should be solved that way.

The problem is paying for a model and receiving rules. You get neither the generalization to unseen variants that a trained model buys you nor the transparency that makes a rule pack cheap to operate. So the question worth answering is narrow: does the scoring function have parameters that were fit to data, or thresholds that a person typed in?

Test 1: Count the Unique Scores

You should already be insisting on raw per-detection output rather than dashboard counts as part of POC discipline. That raw stream answers this question in one line of pandas.

import pandas as pd

scores = pd.read_json('vendor_detections.jsonl', lines=True)['risk_score']
print(scores.nunique(), 'unique values across', len(scores), 'events')
print(scores.value_counts().head(10))

A model with fit parameters produces a near-continuous distribution: hundreds or thousands of distinct values, most of them ugly decimals. A weighted rule engine produces a short repeating list, because every score is a sum over the same fixed condition set. Twelve unique values across 8,000 events is a rubric, not a model. Scores piling up on 25, 50, 75, and 90 point the same direction.

The honest caveat: a vendor can bucket a real model's output before it reaches the API, which makes a genuine model look like a rubric. So treat low cardinality as a prompt to ask whether the pre-bucketing score is exposed, then run the next test, which bucketing cannot hide.

Test 2: Sweep One Feature and Watch the Boundary

This is the test that settles it. Take an event the product flags, vary a single field in small increments, resubmit each variant, and record the score.

import numpy as np

rows = []
for length in range(8, 40):
    for entropy in np.arange(2.0, 4.6, 0.1):
        domain = synth_domain(length, entropy)          # your generator
        rows.append({'length': length,
                     'entropy': round(entropy, 1),
                     'score': vendor_api.score(domain)})

grid = pd.DataFrame(rows).pivot(index='length', columns='entropy', values='score')
print(grid)

Read the surface. If the score is flat and then jumps in a vertical line at a round entropy value, identical for every domain length, a threshold fired. If the score rises gradually and the entropy at which it rises depends on the length, the scoring function learned an interaction between two features, which is something no analyst hand-codes.

We teach this same procedure as the model-extraction lab on day four of the Applied Data Science and AI for Cybersecurity course: query a black-box classifier through its API until the decision boundary becomes visible. The technique comes from the 2016 USENIX Security paper Stealing Machine Learning Models via Prediction APIs, and MITRE ATLAS catalogs the offensive version as Extract AI Model (AML.T0024.002). That matters procedurally: get written authorization and a rate limit agreed in advance, because a vendor's abuse detection will read a high-volume sweep exactly the way ATLAS describes it.

Test 3: Ask for the Version String, Not the Architecture

Architecture answers cost a vendor nothing. Versioning is expensive to fake, because it only exists if someone built a pipeline. Ask for three artifacts:

A model version in every detection payload. model_version: "url-clf-2026.06.3" on the detection itself, not the product release number in the footer.
A retraining changelog. Dates, and the held-out evaluation metrics for each version. Redaction is fine. Absence is the answer.
The drift monitor. What input distribution it watches, what threshold trips it, and what the team did the last time it tripped.

NIST's AI Risk Management Framework (AI 100-1) puts exactly this under its MEASURE and MANAGE functions, so a vendor selling into regulated buyers has no excuse for being surprised by the request. The artifact to ask for by name is a model card, from Model Cards for Model Reporting (Mitchell et al., 2019): intended use, training data, evaluation results, known failure modes. Teams running real models usually have something like it internally. A product that has "used ML since 2019" and cannot produce a single retraining date is not maintaining a model.

Test 4: Read What Actually Ships

If any component runs in your environment, the inference stack is sitting on your disk. This is the fastest of the four and the hardest to spin.

List the bundled runtime's dependencies for an inference library: onnxruntime, xgboost, lightgbm, torch, scikit-learn.
Look for serialized weights: find /opt/vendor -name '*.onnx' -o -name '*.pt' -o -name '*.pkl' -o -name '*.joblib'.
Run strings and ldd against native binaries for ONNX Runtime or libtorch symbols.
Check egress. If the product claims local inference but the agent opens a connection to a scoring endpoint before every verdict, the model is not local, whatever the datasheet says.

The ratio is the finding. A 400 KB gradient-boosting model next to a 40,000-line YAML rule pack tells you which component does the work.

What These Tests Do Not Tell You

None of this measures whether the product is any good. It measures whether one specific claim is true. A tuned rule pack from a vendor with deep threat-intel coverage will outperform a poorly trained model on your traffic, and for some vendors the rule pack is the genuinely valuable asset. Establish what the engine is so you can price it, then judge it on detection lift and false positive cost against your current stack.

These four tests also do not transfer to LLM-wrapper products. When the "AI" is a hosted model behind a prompt, there is no decision boundary to sweep and score cardinality means nothing. The questions there are which model, what grounding, what happens to the output at temperature above zero, and whether the prompt is a trust boundary.

Reading a score distribution and probing a decision boundary are ordinary data science skills, which is the point: the technical literacy to test a vendor claim is the same literacy that lets your team build detections. The executive AI course covers the decision side of this for security leaders, and the applied course is where analysts write the probe scripts themselves. Both sit inside GTK Cyber's AI cybersecurity training track. For the questions to open the conversation with, start with our vendor evaluation checklist.

How to Use Python and scikit-learn for Security Log Analysis

Charles Givre — Wed, 22 Jul 2026 21:07:21 +0000

scikit-learn shows up in most security ML tutorials as one thing: an anomaly detector. IsolationForest, a contamination parameter, done. That is a fraction of what the library does for log data. Two other jobs matter more day to day in a SOC: grouping tens of thousands of near-identical log lines so an analyst reviews ten clusters instead of ten thousand events, and classifying events so known-benign noise stops paging anyone.

This post covers those two workflows. It assumes you can already load a log into a DataFrame. If not, start with Pandas for security data analysis and come back.

From log lines to a feature matrix

scikit-learn models take a numeric matrix, not raw log text. Building that matrix is most of the work. Two encoders cover the majority of log fields:

Structured fields (port, bytes, status code, hour of day) go in as numbers, scaled with StandardScaler so no single large-magnitude column dominates.
Free-text fields (URLs, process command lines, user agents, syslog messages) go through TfidfVectorizer, which turns text into weighted token vectors.

For a proxy log, that looks like this:

from sklearn.feature_extraction.text import TfidfVectorizer

# df['url'] is the requested URL per row
vec = TfidfVectorizer(analyzer='char_wb', ngram_range=(3, 5), min_df=5)
X = vec.fit_transform(df['url'])

Character n-grams (char_wb, 3 to 5 characters) work better than word tokens on URLs and command lines, where the signal lives in substrings like /wp-admin or a base64 chunk, not in whitespace-separated words.

Workflow 1: cluster to triage volume

A single web server can emit tens of thousands of near-identical log lines an hour. Clustering collapses them. MiniBatchKMeans scales to large logs and groups the TF-IDF vectors:

from sklearn.cluster import MiniBatchKMeans

km = MiniBatchKMeans(n_clusters=50, random_state=42)
df['cluster'] = km.fit_predict(X)

# Rare shapes hide in the smallest clusters
sizes = df['cluster'].value_counts()

The move that pays off is sorting clusters by size and reviewing the smallest ones first. The giant clusters are your normal traffic. The cluster of 12 requests that resembles none of the other 49 clusters is the one worth an analyst's time. DBSCAN is an alternative when you do not want to pick n_clusters up front, at the cost of tuning eps.

This is triage, not detection. Clustering tells you what is unusual in shape, not what is malicious. An analyst still reads the small clusters and makes the call.

Workflow 2: classify known event types

Once you have labels (from past investigations, a SIEM's verdicts, or a public corpus), a supervised classifier can carry the repetitive decision. A RandomForestClassifier is a strong default on the mixed numeric-and-text features above:

from sklearn.ensemble import RandomForestClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

X_train, X_test, y_train, y_test = train_test_split(
    X, df['label'], test_size=0.2, stratify=df['label'], random_state=42)

clf = RandomForestClassifier(n_estimators=300, class_weight='balanced', n_jobs=-1)
clf.fit(X_train, y_train)
print(classification_report(y_test, clf.predict(X_test)))

Two arguments earn their place. class_weight='balanced' stops the model from predicting "benign" for everything when 99.9% of your logs are benign. stratify=df['label'] keeps the rare class present in both the train and test splits.

The public Loghub collection from the LogPAI group is a good place to practice. It has labeled system logs (HDFS, BGL, and others) with anomaly labels, so you can build and test a classifier without waiting for your own labeled incidents to pile up.

Read the right metric

Accuracy lies on security data. A classifier that calls everything benign scores 99.9% accuracy on a log where 1 in 1,000 events is malicious, and it catches nothing. Read precision and recall per class from classification_report, and pick the tradeoff deliberately: a SOC drowning in alerts wants precision, a hunt for a known-bad pattern wants recall. For scoring outliers rather than known classes, that is the anomaly detection job, which uses a different family of models.

The mistake we see most often when we teach this is students optimizing accuracy and declaring victory. On imbalanced security data that number is meaningless. We spend real lab time in the Applied Data Science and AI for Cybersecurity course on reading a confusion matrix and choosing the metric that matches the mission, because it is the difference between a model that ships and one that quietly misses everything.

Where scikit-learn stops

scikit-learn is a batch library. It fits and predicts on data held in memory; it is not a streaming engine. For real-time scoring at SOC scale, you train in scikit-learn and then serve the fitted model behind your pipeline (a Kafka consumer, a Spark job, or a detection rule that calls the serialized model). Every model here also decays as traffic shifts: a classifier trained on last quarter's URLs slowly goes stale. Plan to retrain, and track precision and recall over time so you notice the drift before your analysts do.

If you want reps on this with real security datasets, and an instructor who can tell you why a model did something surprising, that is what the Applied Data Science course at Black Hat USA 2026 is built for.

A CISO's One Day at Black Hat: Inside the Executive AI Course

Charles Givre — Tue, 21 Jul 2026 21:31:03 +0000

The one-day executive AI course at Black Hat USA 2026 walks a security leader through four blocks in a single day: what AI really does for security, the governance frameworks that land on a CISO's desk, the AI-powered threats worth planning for, and how to evaluate the vendors selling into all of it. You leave able to interrogate a vendor, gate a deployment, and answer a board with specifics. No code, no labs.

Black Hat USA 2026 runs August 1 to 4 at Mandalay Bay in Las Vegas. A Cyber Executive's Guide for Artificial Intelligence is the one-day option on August 3. Here is what that day actually looks like from the seat.

Morning: what AI can and cannot do for security

The day opens by separating the real from the sold. Every vendor deck claims AI. Most security leaders cannot yet tell a genuine capability from a demo built to survive a sales call. So the first block draws that line: where machine learning and large language models actually move the needle in detection, triage, and analysis, and where they quietly fail or add risk.

This is not an AI theory lecture. It is the grounding a leader needs to walk into the next vendor meeting and ask a question the salesperson did not rehearse. By mid-morning you can hear a capability claim and know whether it is plausible, and just as important, you can tell your own team which AI ideas are worth piloting and which are hype dressed up in a roadmap.

Late morning: governance frameworks that reach your desk

The second block is the one CISOs ask for by name: governance. It covers the NIST AI Risk Management Framework as the operational backbone, the EU AI Act as the compliance overlay that applies to any organization with EU customers or operations, and how to map both onto the security and risk program you already run.

The emphasis is practical, not a framework recital. Which controls map to which obligations. Where the gaps usually sit. What auditable evidence actually looks like when a regulator or a board asks. You leave this block able to tier AI risk in an inventory and gate new AI systems through an approval process, instead of signing policy you cannot enforce.

If you want the deeper version of this material before you go, the post on AI governance training for security executives covers the framework stack in detail.

Early afternoon: AI-powered threats, from the defender's chair

After lunch the course turns to offense: how AI changes the threat model. Deepfakes in social engineering and fraud. Adversarial AI against the models you might deploy. AI-enabled attacks that scale what used to take a human. Prompt injection and RAG poisoning against the LLM assistants moving into enterprises now.

The framing stays at the altitude a leader operates from: not how to write the exploit, but what the attack means for your risk register, your controls, and the questions you should be asking your own engineers. The companion read on AI risk blind spots CISOs miss covers several of these in more depth.

Late afternoon: vendor evaluation and organizational readiness

The final working block is where the day pays for itself. Vendor evaluation: how to question AI capability claims, what training-data and evaluation-methodology questions to ask, and how to design a proof of concept that produces evidence instead of a polished narrative. This is the skill that kills a bad six-figure contract before the renewal locks in.

It closes on organizational readiness: what an AI-ready security program looks like, where the gaps usually are, and how to sequence the build. You leave with a picture of your own program's next three moves, not a generic maturity model.

Two things make the room work. First, the material comes from working practitioners who have sat across the table from AI vendors and stood up governance inside real security programs, not from full-time trainers reading a deck. Executives can tell the difference, and the vendor-evaluation block in particular lands because it is drawn from decisions the instructors have actually made. Second, the peers in the seats next to you are other CISOs and senior security leaders wrestling with the same AI decisions, which is its own reason to be there. The hallway conversations at an executive course are frequently worth the trip on their own.

What you walk out able to do

By the end of the day the deliverable is judgment, not a binder. A CISO who took the course can:

Interrogate an AI vendor's claims and recognize a non-answer.
Map an AI deployment to NIST AI RMF and the EU AI Act.
Tier AI risk in an inventory and gate deployments through an approval process.
Speak to AI risk in a board conversation with specifics instead of hand-waving.

That is a full day at executive altitude, and it is the reason the format is one focused day rather than a week. If you are deciding whether to send a member of your leadership team, the companion post on sending your security leaders works the budget and ROI side. For how the course fits with GTK's consulting and the CISO Brief, see the for-executives hub.

Full details and registration are on the executive course page and the Black Hat 2026 training page. For a custom on-site version tailored to your regulatory environment and AI roadmap, contact us. The seat is one day; the decisions it improves run for years.

Should You Send Your Security Leaders to an Executive AI Course?

Charles Givre — Tue, 21 Jul 2026 21:30:49 +0000

If a member of your security leadership signs off on AI purchases or AI deployment risk, one day at Black Hat USA 2026 is worth the seat. A Cyber Executive's Guide for Artificial Intelligence runs August 3 in Las Vegas, and it pays for itself the first time a CISO kills a weak AI vendor deal or governs a deployment correctly instead of approving it blind.

Most AI training aimed at executives is generic: business applications across industries, a tour of what large language models can do, a few slides on ethics. That is not what a security leader needs. A CISO needs to reason about AI-powered threats, govern AI deployed inside a security program, and answer for it when a regulator or a board asks. This course is built for that person specifically.

The decision this course actually improves

The expensive AI mistakes at the executive level are not technical. They are decisions made without enough literacy to ask the right questions.

A vendor demos an AI-powered detection tool. It looks impressive. Nobody in the room knows to ask what the model was trained on, how it was evaluated, or what the false positive rate looks like on data that resembles your environment. The contract gets signed. Six months later the tool is generating noise and the renewal is already locked in.

Or: a team wants to deploy an internal LLM assistant with access to ticketing and email. It ships. Nobody scoped prompt injection through retrieved content, agent tool permissions, or data provenance. The blind spot becomes an incident.

The course targets exactly these moments. Not by making executives into engineers, but by giving them enough technical judgment to interrogate a vendor claim, recognize a non-answer, and gate a deployment on real evidence. That is the skill that carries budget authority.

What one day covers

The day is organized around the decisions a security executive makes, not around AI theory:

What AI can and cannot do for security. The real capabilities and the real limits, so you can tell a genuine use case from a demo.
Risk and governance frameworks. NIST AI Risk Management Framework, the EU AI Act and its high-risk system obligations, and how to map both onto the security and compliance program you already run.
AI-powered threats. Deepfakes, adversarial AI, and AI-enabled attacks, framed from a defender's perspective.
Vendor evaluation. How to question AI capability claims, what training-data and evaluation-methodology questions to ask, and how to design a proof of concept that produces evidence instead of a sales narrative.
Organizational readiness. What an AI-ready security organization looks like, and where the gaps usually are.

It is decision-grade content with no technical prerequisites. The goal is that an executive leaves able to ask specific questions and act on the answers.

Why the one-day format works

A common objection: can a single day cover enough to matter? For executive decision-making, yes, because the target is judgment, not implementation. An engineer needs weeks of lab time to build and test models. A leader needs enough grounding to govern the people who do, evaluate the vendors who sell to them, and defend the decisions to a board.

One focused day at that altitude is the right dose. It also fits an executive calendar in a way a four-day technical course never will, which is part of why it is the format that actually gets attended.

The instructors matter here too. GTK Cyber courses are taught by working practitioners, not full-time trainers, so the vendor-evaluation and governance material comes from people who have actually sat across the table from AI vendors and stood up governance inside real security programs. Executives can tell the difference between a slide deck and someone describing a decision they have made. That credibility is what makes an executive room engage instead of tune out.

The math on sending someone

Price the course against your training budget. Price the decisions it improves against your risk register. Those are different orders of magnitude.

One AI vendor contract questioned hard enough to walk away from a bad fit. One deployment governed correctly the first time. One board conversation where your CISO can speak to AI risk with specifics instead of hand-waving. Any one of those outcomes returns the cost of a seat and the travel around it.

If you have several leaders who should hear this, the math shifts again. GTK Cyber delivers the same material as a custom on-site program tailored to your regulatory environment and AI roadmap. For a leadership team or a board, an on-site engagement is usually more cost-effective than sending each person to Las Vegas, and it can be scheduled around your calendar instead of Black Hat's. Contact us to scope one.

How it fits the rest of the program

Black Hat USA 2026 is August 1-4 at Mandalay Bay. The executive course is one day on August 3, which leaves room to pair it with the conference itself or to send technical staff to one of GTK Cyber's hands-on courses running the same week.

If you are weighing which course fits which person on your team, the course decision guide matches each of the three GTK Cyber Black Hat courses to role and time budget. For the executive path specifically, the for-executives hub lays out how the course, consulting, and the CISO Brief fit together. Full course details and registration are on the executive course page and the Black Hat 2026 training page.

The security leaders who govern AI well over the next two years will be the ones who built the judgment early. One day in Las Vegas is a cheap place to start.

What You Build in the 4-Day AI Cyber Bootcamp at Black Hat

Charles Givre — Tue, 21 Jul 2026 14:16:36 +0000

Four days in the AI Cyber Bootcamp at Black Hat USA 2026 produce a folder of working notebooks: trained detection models, an anomaly-hunting pipeline, an LLM triage workflow, and an AI agent that automates a SOC task. You write the code in labs on real security data, and it runs in your own environment after you leave. The point is not to watch a demo. It is to build the thing.

Black Hat USA 2026 runs August 1 to 4 at Mandalay Bay in Las Vegas. The bootcamp is the four-day AI Cyber Bootcamp and takes all four training days. Here is what each stretch of the course actually puts in your hands.

Foundations: data science on real security data

You start with the unglamorous part that everything else depends on: getting security data into a shape a model can use. Pandas and Python against real datasets (PCAP-derived features, EDR telemetry, phishing corpora, malware metadata), not toy CSVs. You do the preprocessing, feature engineering, and exploratory analysis that decide whether a model works or wastes a week.

By the end of the first stretch you have a clean feature pipeline you built yourself, and you understand why a model failed when the features were wrong. That skill transfers to every detection problem you will ever touch.

Classical ML for detection you can defend

Next you train supervised models on problems analysts actually see: malware family classification, phishing detection, intrusion classification, SOC alert triage. You work through Random Forest, Naive Bayes, KNN, and SVM, and more importantly you learn when to reach for which one and how to read the evaluation honestly.

This is where the FAQ question everyone asks gets answered in code: Random Forest handles mixed features, non-linear interactions, and gives you feature importance, which makes it a strong default for malware and intrusion work. Naive Bayes trains fast on sparse text features for spam. You do not take that on faith. You train both, compare the confusion matrices, and see it.

The output is a set of trained, evaluated classifiers with metrics you can explain to a skeptical senior analyst. That is the difference between a model you deploy and a model you hope works.

Unsupervised learning for threat hunting

Detection assumes you know what you are looking for. Hunting does not. So the course moves into unsupervised methods: KMeans and hierarchical clustering to group similar users, hosts, and processes; DBSCAN and IsolationForest for anomaly detection; PCA and t-SNE to explore high-dimensional data you cannot eyeball.

The labs run these against authentication logs, network flow, and EDR telemetry, so what you build is a hunting pipeline that surfaces the odd account, the anomalous host, the process that does not fit. You leave with a notebook that turns a pile of logs into a ranked list of things worth investigating.

Generative AI and agents that do real work

The back half turns to LLMs and agents. You use a language model for the tasks it is genuinely good at: summarizing threat intel, drafting log analysis, triaging alerts. You practice prompt engineering as an evaluated skill, not a party trick, measuring whether a prompt actually improves the output on a security task.

Then you build an AI agent that automates a SOC workflow end to end. This is the piece students most often tell us changed how they think about their job: an agent that reads, decides, and calls tools, doing the repetitive analysis a human was burning hours on. You walk out with the agent code and a clear sense of where agents help and where they quietly go wrong.

Adversarial AI: attack the models you just built

The course does not let you deploy AI without understanding how it breaks. The final labs are red and blue team exercises against ML and LLM systems: model evasion, data poisoning, prompt injection, and RAG poisoning, the attack that matters most now that nearly every enterprise LLM deployment grounds answers in a retrieval corpus.

You attack models like the ones you trained earlier in the week, then defend them. That loop is the whole reason to learn AI and security together instead of separately. You leave able to reason about the attack surface of an AI system, not just its accuracy.

What you take home

Add it up and the four days produce a working portfolio, not a certificate to frame: trained classifiers with honest evaluation, a clustering and anomaly-detection hunting pipeline, an LLM triage workflow, a SOC-automation agent, and a set of adversarial exercises you have run from both sides. All of it lab-built on the Centaur VM and real security data, all of it runnable in your own environment on the flight home. Most students are using at least one of those notebooks in production within a month. That is the test of training that worked: code you keep and use, not notes you never open again.

Who should take it, and who should not

The bootcamp is built for security professionals who can read code and want to apply AI, ML, and data science to operations. Analysts, detection engineers, and threat hunters are the sweet spot. If you have never written a script, the pace will hurt.

If you are a security leader who needs to govern AI rather than build it, the four-day technical course is the wrong seat. The one-day executive course covers risk, governance, and vendor evaluation for that audience instead. Not sure which fits your team? The course decision guide matches each GTK Black Hat course to role and time. For a group or a custom on-site version, contact us.

Full details and registration are on the Black Hat 2026 training page. The seats that matter fill early; the folder of working code is worth booking one.

Hands-On vs Lecture-Based Cybersecurity Training: Which Builds Skills

Charles Givre — Fri, 17 Jul 2026 14:02:41 +0000

If you are buying training for a security team, the format matters more than the syllabus. Two courses can cover the same MITRE ATT&CK techniques, the same detection methods, the same tools, and produce completely different results depending on whether your people spent the week watching or doing.

The marketing does not help. Nearly every vendor now calls their training "hands-on." Some of it is. A lot of it is a lecture with a screen share.

What the Research Actually Says

Skip the "learning pyramid" you have seen on a hundred slides, the one claiming people remember 10% of what they read and 90% of what they do. Those numbers have no empirical source. They were fabricated and repeated until they looked like fact.

The real evidence is better and more specific. A 2014 meta-analysis of 225 studies across STEM education (Freeman et al., PNAS) found that active learning cut exam failure rates from 33.8% under traditional lecturing to 21.8%, and improved exam scores by roughly 0.47 standard deviations. The authors noted that if these had been drug trials, the results would have justified stopping the study early to switch everyone to the better treatment.

Retention is the other half. The Ebbinghaus forgetting curve describes how quickly memory of new material decays without retrieval practice. A lecture is pure exposure. A lab forces retrieval and application, which is why the skills stick.

Security Skills Are Procedural, Not Declarative

Here is the part specific to our field. Most of what a security professional needs to learn is procedural knowledge: how to do something, not what something is.

You can memorize the definition of an isolation forest from a slide. That does not mean you can pick features from an auth log, set contamination sensibly, read the raw anomaly scores, and decide which flagged events are worth an analyst's time. You can watch someone explain prompt injection. That does not mean you can craft a payload that bypasses a system prompt. You can hear about C2 beaconing. Detecting it in your own Zeek conn.log is a different skill entirely, as our walkthrough on hunting C2 beaconing with Python shows.

Procedural skills are acquired through reps. There is no shortcut, and watching an expert do it is not a rep.

What Lab-Based Training Looks Like

Real hands-on security training puts the student in a live environment against realistic data and asks them to produce something. A few concrete examples:

Detection engineering. Write a Sigma rule, then test it against emulated adversary behavior from Atomic Red Team or MITRE Caldera. A rule that fires on T1059.001 PowerShell execution is easy to write and easy to get wrong:

  detection:
    selection:
      Image|endswith: '\powershell.exe'
      CommandLine|contains:
        - '-enc'
        - 'FromBase64String'
    condition: selection

You only learn where that rule produces false positives by running it against real telemetry.

Applied ML for detection. Load logs into a pandas DataFrame in Jupyter, engineer features, fit a model from scikit-learn, and evaluate it on held-out data. The evaluation step, precision versus recall on your own data, is where the learning happens.
AI red-teaming. Run prompt injection and jailbreak payloads against a local model with Ollama, then scan it systematically with garak. Our prompt injection lab works exactly this way.

In every case the student walks away with an artifact: a working notebook, a tested rule, a documented finding. That is the tell. If the deliverable is a completed slide deck, it was a lecture.

Where Lectures Still Earn Their Place

Format should match the goal. Lectures are the right tool when the objective is understanding rather than muscle memory. An executive AI risk briefing, a governance framework walkthrough, a threat modeling discussion, an introduction to an unfamiliar domain: these are conceptual, and structured lecture plus discussion works well. Our executive AI training is deliberately built this way, because a CISO needs to make good decisions, not tune a classifier.

The failure mode is using lecture format to teach a skill. No amount of watching someone build a detection pipeline builds one in your team's hands.

How to Vet a Vendor's "Hands-On" Claim

Since most vendors claim hands-on, make them prove it. Ask:

What percentage of class time is students in a lab versus watching the instructor?
What environment do the labs run on, and do students keep access after the course?
Can you see a sample exercise, and what artifact does the student produce?
Does every student get their own environment, or does the instructor drive while everyone watches?

A vendor running genuine labs answers these easily. One that dodges them is selling a presentation.

GTK Cyber's courses run on a proprietary lab platform where every student works in their own environment against real security data, taught by practitioners who do this work. The Applied Data Science and AI for Cybersecurity course and the AI Cyber Bootcamp are built around exercises, not slides. If you are evaluating training for your team, ask us to show you a lab.

AI Governance Training for Security Executives: What to Learn

Charles Givre — Thu, 16 Jul 2026 13:40:14 +0000

Most AI governance training for executives teaches people to recite framework names. NIST AI RMF, the EU AI Act, ISO 42001. That is not governance. Governance is the operational capability to decide which AI systems your organization deploys, on what data, and with what controls, and to enforce that decision. Training that does not build that capability produces executives who can sign a policy but cannot tell whether the deployment in front of them is safe.

Here is what AI governance training for security leaders should actually cover.

What AI Governance Means for a Security Leader

Strip away the framework vocabulary and governance comes down to three decisions, made repeatedly, for every AI system in the environment:

What gets deployed. A marketing chatbot, a code assistant with repository access, and an autonomous agent with write permissions carry very different risk. Governance decides which ones proceed and under what conditions.
On what data. The single biggest AI exposure most organizations have is sensitive data flowing into systems with unclear retention and training policies. Governance sets what data classes are allowed into which systems.
With what controls. Logging, human-in-the-loop review, permission scoping, and monitoring. Governance defines the minimum bar before a system goes live.

None of this is new to a security leader. It is the same asset inventory, risk tiering, and approval-gate discipline you already apply to software and vendors. The difference is that AI systems fail in ways traditional software does not, and the controls have to account for that.

The Framework Stack Worth Knowing

Executives do not need to memorize these. They need to know what each one does and where it fits.

NIST AI RMF (document AI 100-1) is the operational backbone for most US organizations. It structures AI risk work into four functions: Govern, Map, Measure, and Manage. The companion Generative AI Profile (NIST-AI-600-1, published July 2024) adds specific guidance for LLM and generative systems. It is voluntary and gives you a vocabulary and process, not a compliance checklist.

ISO/IEC 42001:2023 is the AI management system standard. Think of it as ISO 27001 for AI: it is certifiable and auditable, which matters when a customer or regulator wants evidence that your AI governance is a system, not a slide deck. ISO/IEC 23894:2023 is the companion AI risk management guidance.

The EU AI Act (Regulation (EU) 2024/1689) is the regulatory obligation. It sorts AI systems into risk tiers: prohibited, high-risk, limited-risk, and minimal-risk. Timelines matter: it entered into force in August 2024, prohibited practices applied from February 2025, general-purpose AI model obligations from August 2025, and most high-risk obligations from August 2026. It applies extraterritorially, so a US company with EU customers is in scope.

OWASP Top 10 for LLM Applications and MITRE ATLAS cover the technical control side. OWASP LLM01 is prompt injection; the list maps the concrete failure modes of deployed LLM systems. ATLAS catalogs adversarial techniques against ML systems, including LLM prompt injection (AML.T0051) and training-data poisoning (AML.T0020). These are what turn a governance policy into specific controls a security team can test.

The mistake to avoid is treating these as interchangeable. NIST AI RMF is the operational process. ISO 42001 is the auditable system. The EU AI Act is the law. OWASP and ATLAS are the threat and control vocabulary. Governance training should teach the relationship, not the list.

What a Governance Program Actually Produces

A governance function that works produces artifacts, not intentions:

An AI asset inventory. Every AI system in the environment, including embedded vendor features and developer tooling (GitHub Copilot, Cursor, internal OpenAI or Anthropic API keys). Most organizations cannot produce this today, and it is the prerequisite for everything else.
A model risk tiering scheme. A rubric that sorts systems by data sensitivity, autonomy, and blast radius so a low-risk summarizer and a high-risk agent get proportionate review.
An acceptable-use policy with technical enforcement. Not an awareness memo. A data-classification-backed rule that DLP tooling (Microsoft Purview, Netskope, Zscaler) can enforce.
An approval gate. A cross-functional review with actual authority to stop a deployment, so a business unit cannot ship an AI feature on live customer data without security sign-off.
Third-party AI contract terms. Clauses covering data retention, training use, prompt-injection resilience, and inference-time isolation.

If a governance program is not producing these, it is producing paperwork.

The Technical Literacy the Role Requires

This is where most executive AI training falls short. Governance without technical literacy becomes rubber-stamping. An executive who cannot reason about how prompt injection exfiltrates data through an agent's tool calls, or why a model trained on unvetted data is a supply chain risk, will approve systems on the strength of a vendor's reassurance.

The bar is not a data science degree. It is enough understanding to:

Ask an AI vendor specific questions and recognize a non-answer. Our AI security vendor evaluation checklist covers the technical questions worth asking.
Understand why an agent with broad tool permissions is a larger attack surface than a read-only assistant, and insist on least privilege.
Read an evaluation result and know whether the reported accuracy means anything for your environment.
Recognize which AI risks are already in the building versus which are speculative.

That literacy is what separates governing AI from signing off on policies your team wrote.

Where to Get the Training

GTK Cyber's executive course, A Cyber Executive's Guide for Artificial Intelligence, is built for exactly this: security leaders who need to govern AI deployments and understand the frameworks well enough to make defensible decisions. It covers the risk and governance stack above, the regulatory environment, and how to build an AI-ready security organization, without turning executives into data scientists. It runs at Black Hat USA 2026 and as a custom on-site program. Executives who want the strategic and governance context for their whole leadership team can also look at our AI training for CISOs.

Using LLMs for Log Analysis: Parsing, Clustering, and Queries

Charles Givre — Mon, 13 Jul 2026 14:05:02 +0000

An LLM will not read your logs for you. It cannot, at least not the way vendors imply: a single busy host emits millions of lines a day, and no model context window or API budget survives that volume. The teams getting value from large language models in log analysis are the ones who reduce the data with deterministic tooling first, then point the model at the language-heavy remainder.

Here is the split that works, the tools to use, and where it breaks.

Reduce Before You Reason

The first mistake is treating the model as the parser. It is the last step, not the first. Before an LLM sees anything, collapse the raw stream into a small set of representatives.

For high-volume structured-ish logs (auth, web, firewall), mine templates with Drain3. It groups lines by their fixed skeleton and treats the variable parts as parameters, with no training required. Millions of lines become a few hundred templates.

from drain3 import TemplateMiner

miner = TemplateMiner()
with open("/var/log/auth.log") as f:
    for line in f:
        miner.add_log_message(line.strip())

# A few hundred templates instead of millions of raw lines
for cluster in sorted(miner.drain.clusters, key=lambda c: c.size, reverse=True):
    print(cluster.size, cluster.get_template())

Now you have something a model can actually work with: send the templates, their counts, and a few example lines, and ask the model to label each cluster, flag which ones are security-relevant, and group them by activity. You are spending tokens on a few hundred patterns, not tens of millions of events.

Force Structured Output on the Messy Tail

Drain3 and Grok patterns handle the regular logs cheaply. The long tail is where the model earns its keep: free-text error messages, vendor appliance logs with no schema, application exceptions that never look the same twice.

Do not ask for prose back. Force a schema, the same way you would for any other enrichment callout. On the Anthropic Messages API, tool use doubles as a structured-output contract:

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

extract_tool = {
    "name": "extract_log_fields",
    "description": "Extract normalized fields from a single unstructured log line.",
    "input_schema": {
        "type": "object",
        "properties": {
            "event_type": {"type": "string"},
            "src_ip": {"type": "string"},
            "username": {"type": "string"},
            "outcome": {"type": "string", "enum": ["success", "failure", "unknown"]},
            "severity": {"type": "string", "enum": ["info", "low", "medium", "high"]},
        },
        "required": ["event_type", "outcome"],
    },
}

resp = client.messages.create(
    model="claude-haiku-4-5-20251001",   # cheap model for high-volume work
    max_tokens=512,
    tools=[extract_tool],
    tool_choice={"type": "tool", "name": "extract_log_fields"},
    system="Extract only fields present in the line. Do not invent values.",
    messages=[{"role": "user", "content": raw_line}],
)

fields = next(b.input for b in resp.content if b.type == "tool_use")

The enum constraints stop the model from inventing a new severity, and you validate every returned src_ip against an IPv4/IPv6 format before it enters your store. Route this high-volume extraction to a cheap model like Claude Haiku 4.5 (claude-haiku-4-5-20251001); save the expensive models for the investigations a human already cares about. The same routing-by-severity logic applies here as in a full SOC integration.

Cluster With Embeddings, Not Prompts

Two log lines can describe the same event with completely different wording. Embeddings catch that where string matching does not. Embed each message with a small local sentence-transformer, then cluster the vectors.

from sentence_transformers import SentenceTransformer
from sklearn.cluster import DBSCAN

model = SentenceTransformer("all-MiniLM-L6-v2")   # runs locally, no data leaves
vectors = model.encode(log_messages, normalize_embeddings=True)

labels = DBSCAN(eps=0.25, min_samples=5, metric="cosine").fit_predict(vectors)
# label == -1 marks the outliers worth an analyst's attention

Run the embedding model locally with sentence-transformers so you are not paying per token or exporting logs to analyze them. Store the vectors in pgvector and you get "show me logs similar to this one" during an investigation. The -1 outliers from DBSCAN are the rare events; hand only those to the LLM for explanation. This is the same feature-then-model discipline covered in feature engineering for security data.

Draft Queries, Do Not Run Them

Turning an analyst's plain-English intent into first-draft Splunk SPL, KQL, or a Sigma rule is a real win. Generating a query and running it unattended is not. Models invent field names that do not exist in your schema, botch time-window boundaries, and write queries that look correct while matching the wrong events.

Give the model your actual field list so it stops guessing, and treat the output like generated code: review it, run it against a bounded time range, and sanity-check the hit count before it becomes a scheduled detection. A generated query that returns zero results or ten million both mean the same thing: read it before you trust it. This is the reverse of the SIEM-to-Jupyter workflow, where the analyst writes the logic and the notebook keeps it reproducible.

Where It Breaks

Plan for these from the first prototype:

Aggregation belongs in SQL. Counting failed logins per user across a week is a GROUP BY, not a prompt. Models cannot count reliably at scale and will confidently give you a wrong total.
Log fields are attacker-controlled. A User-Agent, a filename, an HTTP path can carry an indirect prompt injection (OWASP LLM01, MITRE ATLAS AML.T0054). Keep the model read-only and gate everything it returns.
Hallucinated fields reach your store. A model may return a plausible src_ip that was never in the line. Validate format and cross-check against the raw event before writing anything.
Non-determinism defeats detection. The same line can parse two ways on two runs. Anything feeding a detection rule needs a deterministic path or a validation gate, not a raw model output.
Cost scales with volume. Send representatives, not raw streams. If your token bill scales linearly with log volume, the architecture is wrong.

Where to Learn This

The hard part is not prompting. It is knowing which step is deterministic (templating, aggregation, format validation) and which is a language task (labeling clusters, explaining an anomaly, drafting a query), then wiring them so the model never sits where a wrong answer causes damage. Teams that get value here already understood their log schemas and detection logic; the model amplifies that engineering, it does not supply it.

GTK Cyber's Applied Data Science and AI for Cybersecurity course is built for security practitioners who want to connect these pieces on real data, with the judgment to keep the model where it helps. The generative AI in security operations post covers the same split for the broader SOC.

How to Apply Machine Learning to Threat Hunting

Charles Givre — Fri, 10 Jul 2026 15:39:01 +0000

Machine learning in threat hunting is oversold in one specific way: vendors imply the model finds the threat. It does not. A hunt still starts with a hypothesis and a human who knows the environment. What machine learning does well is one narrow, valuable job: it shrinks the candidate set. Instead of an analyst scrolling through 40,000 outbound sessions, ML hands them 40 that do not look like the rest.

That reframing decides where ML belongs in a hunt and where it wastes your time. Here is how to apply it without pretending it replaces judgment.

Start With Whether You Have Labels

The first decision is not which algorithm to use. It is whether you have labeled examples of the thing you are hunting.

You have labels. For well-studied problems, curated datasets exist: DGA domains, phishing URLs, known malware families. Here supervised classification works. Extract features and train a classifier. See detecting DGA domains in Python for a worked example using lexical features and a gradient-boosted model.
You do not have labels. This is most hunting. You are looking for something you cannot name yet, so there is nothing to train a classifier against. This is where unsupervised methods earn their place: clustering to group events, and distance-based scoring to rank them.

If you are unsure which camp a hunt falls into, it is almost always the second one. For the difference in practice, see supervised vs. unsupervised learning for security.

Clustering to Collapse Candidate Sets

The most useful unsupervised technique in hunting is not anomaly scoring. It is clustering, used to reduce volume. Group thousands of similar events into a handful of clusters, then hunt the small and the odd ones.

Command-line execution (MITRE ATT&CK T1059) is a good target. Sysmon Event ID 1 and Windows Event ID 4688 give you the full command line. Most command lines in an environment are near-duplicates of each other: the same scheduled tasks, the same management scripts, the same installer strings. The rare ones are what you want.

Vectorize the command lines with a character n-gram TF-IDF, then let DBSCAN from scikit-learn label the outliers:

import pandas as pd
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.cluster import DBSCAN

# df: one row per process creation, with a 'command_line' column
vec = TfidfVectorizer(analyzer='char_wb', ngram_range=(3, 5), min_df=2)
X = vec.fit_transform(df['command_line'].fillna(''))

db = DBSCAN(eps=0.5, min_samples=5, metric='cosine').fit(X)
df['cluster'] = db.labels_

# cluster == -1 is DBSCAN's noise label: command lines that resemble
# nothing else in the dataset. Rare by construction, worth hunting.
rare = df[df['cluster'] == -1].sort_values('command_line')

char_wb n-grams handle the obfuscation you see in real command lines: base64 blobs, mixed casing, inserted characters. A PowerShell -enc payload will not cluster with anything legitimate and drops straight into the noise group. The same pattern works on outbound HTTP sessions, DNS query strings, and user-agent values. You are not asking the model "is this malicious." You are asking "is this like everything else," which is a question ML answers reliably.

Peer-Group Anomaly for Account Behavior

Single-user baselining has a known failure mode: if an account is compromised early, or you only have a short history for it, its baseline is either poisoned or too thin to be useful. Peer-group comparison sidesteps this. Compare each account to the accounts most like it, not only to its own past.

Build a feature vector per account (distinct hosts reached, off-hours logon ratio, privileged operations, distinct source IPs), group accounts by role or organizational unit, and measure how far each account sits from its peers:

import numpy as np

# features: DataFrame indexed by account, grouped by 'role'
def peer_distance(group):
    numeric = group.drop(columns='role')
    centroid = numeric.mean()
    std = numeric.std().replace(0, 1)
    z = (numeric - centroid) / std
    return np.sqrt((z ** 2).sum(axis=1))   # distance from peer centroid

features['peer_score'] = (
    features.groupby('role', group_keys=False).apply(peer_distance)
)
suspects = features.sort_values('peer_score', ascending=False).head(25)

A service account that suddenly behaves like an interactive admin, or a helpdesk user reaching servers no one else in helpdesk touches, surfaces here even when their own history looks unremarkable. This is the useful core of what vendors sell as UEBA, and it maps cleanly to lateral movement (MITRE ATT&CK T1021) and account manipulation hunts.

The Work Is Feature Engineering, Not the Model

Every example above spends more effort turning raw logs into features than on the algorithm. That is not incidental. The choice between DBSCAN and KMeans, or between a random forest and gradient boosting, rarely decides whether a hunt succeeds. The features do. A byte-ratio, an inter-arrival coefficient of variation, an entropy score on a domain string: these are what carry signal. Spend your time there. See feature engineering for security machine learning for the patterns that hold up.

Where Machine Learning Stops

Be honest about the limits, because the failures are predictable:

It will not generate hypotheses. ML ranks and groups what you point it at. Deciding to hunt command-line execution, or peer-group deviation, or beaconing, is your call. The model has no idea what an attacker looks like.
The base-rate problem is unforgiving. Malicious activity is a tiny fraction of all activity, so a small false positive rate still buries the real findings. Use ML to prioritize, then filter with cheap rules (known-good ASNs, expected admins) before an analyst sees anything.
It is blind to living-off-the-land. If attackers use the same tools your admins use, statistically unusual is not the same as malicious. This is the same limit that constrains anomaly detection in security operations: map your MITRE ATT&CK threat model explicitly against what the model can and cannot see.
Findings need validation before they become detections. A cluster or a high peer-score is a lead, not a verdict. Confirm it, then translate reliable logic into a production detection rather than rerunning a notebook forever.

Applied well, machine learning is a force multiplier for a hunter who already knows what questions to ask. GTK Cyber's applied data science training covers exactly this: building and calibrating these models against realistic security datasets, with hands-on labs on the feature engineering, clustering, and peer-group techniques described here.

AI Security Training for Healthcare Security Teams

Charles Givre — Wed, 08 Jul 2026 15:00:53 +0000

Healthcare organizations are wiring LLMs and machine learning into clinical work: ambient documentation that drafts notes from a visit, chatbots that answer patient questions, retrieval over the EHR, and predictive models for sepsis, readmission, and imaging triage. Each of these is a new attack surface, and most healthcare security teams were trained for networks and endpoints, not models and training data.

The skills gap is specific. Here is what healthcare cybersecurity professionals actually need to train on.

Keeping PHI Out of the Model Pipeline

The first problem is data exposure, and it does not look like a normal data breach. Protected health information ends up in places a network review never checks: inside LLM prompts, in the retrieval context a RAG pipeline pulls from the EHR, in application and model-provider logs, and in every call to an external inference API.

HIPAA's Safe Harbor method requires removing 18 identifiers (names, geographic subdivisions, dates, medical record numbers, and more) before data counts as de-identified. Security teams need to know where PHI enters a pipeline and strip it before it does. Microsoft Presidio is a practical starting point for detecting and redacting identifiers:

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Patient John Doe, MRN 00219384, seen on 2026-06-14 for chest pain."
results = analyzer.analyze(text=text, entities=["PERSON", "DATE_TIME"], language="en")
clean = anonymizer.anonymize(text=text, analyzer_results=results)
print(clean.text)  # -> "Patient <PERSON>, MRN 00219384, seen on <DATE_TIME> for chest pain."

The lesson to teach alongside the tool: de-identification is imperfect. Named-entity recognition misses custom identifiers like that MRN unless you add a recognizer, and even Safe Harbor data carries re-identification risk. De-identify before data reaches the model, log what you send, and treat the model provider as a data flow, not a black box.

Red-Teaming Clinical LLM Features

A patient-facing chatbot or a clinician copilot is an application that takes untrusted input and acts on it. That makes it a target for prompt injection. Direct injection overrides the system prompt through user input. Indirect injection hides instructions in a document the model retrieves, which matters most in healthcare because RAG pipelines routinely ingest clinical notes, uploaded records, and patient messages that an attacker can influence (OWASP LLM01, MITRE ATLAS AML.T0051).

Security teams should train to test these features the way they test a web app: send adversarial input, try to override instructions, attempt to exfiltrate the system prompt or connected data, and write findings mapped to OWASP and ATLAS. We cover the mechanics in how to red team an LLM-powered application and RAG poisoning and jailbreaking.

Testing Diagnostic Models Under Attack

The models that carry the highest stakes are the ones influencing clinical decisions. These can be fooled. Finlayson et al. showed in Science (2019) that small, human-imperceptible perturbations flip the output of dermatology and radiology classifiers. This is a model-evasion attack (MITRE ATLAS AML.T0015), and it applies to any ML model tied to a clinical or billing outcome.

Vendor accuracy numbers are measured on clean data. Healthcare security teams need to evaluate robustness under adversarial pressure, not accept the marketing figure. The methodology is the same one we teach for any security-relevant model, covered in how to evaluate ML model robustness for security use cases.

The Constraints That Change the Threat Model

The attack techniques are not healthcare-specific. The constraints are. PHI exposure is a regulatory event under HIPAA. Model evasion against a diagnostic tool is a patient-safety event. And the FDA governs AI/ML-based Software as a Medical Device, including how a deployed model can be updated, so change management on a model is not a purely internal decision. Training that ignores these stakes teaches the mechanics but misses the point.

None of this requires a data science degree. Security practitioners already have the adversarial mindset; what they need is the AI-specific layer and time in a lab against real targets. GTK Cyber teaches that layer in hands-on courses like AI Red-Teaming and Applied Data Science and AI, and delivers custom, on-site training for security teams that need it mapped to their own environment.

How to Integrate ChatGPT or Claude Into a SOC

Charles Givre — Mon, 06 Jul 2026 15:27:55 +0000

The useful question is not whether to put a large language model in your SOC. It is where the model plugs in. Answer that wrong and you either get a chatbot nobody uses or an agent with enough privilege to become your next incident. Answer it right and you remove real toil from tier-1 without adding a new attack surface.

The short version: the model sits beside your SIEM and SOAR as an enrichment and drafting service, called from your existing pipeline, and it never sits in the critical decision path. This post is about the wiring. For the broader question of what generative AI is and is not good at in security work, see how to use generative AI in security operations.

The Reference Architecture

Do not point analysts at a chat window. Build an event-driven service:

Your SIEM or SOAR fires a webhook when an alert crosses a threshold.
An enrichment service you control assembles the fields the model needs (the alert, recent auth history, relevant threat intel), redacting what it should not see.
The service calls the model API with a fixed output schema.
It validates the response and writes a draft verdict, confidence, and rationale back to the case.
A human still decides. State-changing actions stay with the human or with a deterministic SOAR playbook.

The model is a callout in your pipeline, no different in principle from a VirusTotal or GreyNoise lookup. It produces text; your systems remain the source of truth.

Use the API, and Force Structured Output

The consumer ChatGPT and Claude apps give you no retention control, no output contract, and no audit log. For anything touching production alerts, use the API: the OpenAI Chat Completions or Responses API or the Anthropic Messages API.

The important move is to stop parsing prose. Force the model to return a schema that drops straight into case management. On Anthropic, tool use doubles as a structured-output mechanism: define a tool, force the call, get validated JSON. OpenAI's structured outputs and function calling do the same.

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY

triage_tool = {
    "name": "record_triage",
    "description": "Record the triage verdict for a single security alert.",
    "input_schema": {
        "type": "object",
        "properties": {
            "verdict": {"type": "string", "enum": ["benign", "suspicious", "malicious"]},
            "confidence": {"type": "number", "minimum": 0, "maximum": 1},
            "mitre_techniques": {"type": "array", "items": {"type": "string"}},
            "rationale": {"type": "string"},
        },
        "required": ["verdict", "confidence", "rationale"],
    },
}

resp = client.messages.create(
    model="claude-haiku-4-5-20251001",   # cheap model for high-volume queue work
    max_tokens=1024,
    tools=[triage_tool],
    tool_choice={"type": "tool", "name": "record_triage"},
    system=(
        "You are a SOC tier-1 triage assistant. Classify the alert using only the "
        "fields present in the input. Do not invent indicators not in the data."
    ),
    messages=[{"role": "user", "content": alert_json}],
)

verdict = next(b.input for b in resp.content if b.type == "tool_use")

The enum stops the model from inventing a new category. Log the confidence and route anything low-confidence to a human instead of auto-closing it.

Give the Model Tools With MCP, Read-Only First

Static triage on a single alert is worth something. An investigation that pulls related context is worth more, and that means letting the model call your tools. The clean way to standardize this is the Model Context Protocol (MCP), an open standard for exposing tools and data to models. Both the Anthropic API and a growing set of OpenAI clients speak it, so one MCP server serves multiple models.

Start with read-only tools: search_siem, lookup_ip_reputation, get_user_auth_history. A minimal MCP server that wraps a SIEM query looks like this:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("soc-tools")

@mcp.tool()
def get_user_auth_history(username: str, hours: int = 24) -> list[dict]:
    """Return this user's authentication events (read-only)."""
    return siem.query(
        f'index=auth user="{username}" earliest=-{hours}h | fields _time, src_ip, action'
    )

The rule that keeps this safe: every input the model reads is potentially attacker-controlled. The body of a phishing email, a hostname in a log, a field in a retrieved document; an attacker who can write to any of those can attempt prompt injection. OWASP ranks prompt injection as LLM01 in its Top 10 for LLM Applications, and MITRE ATLAS tracks it as AML.T0054. Constrain the agent the way you constrain a service account:

Read-only by default. Query, enrich, and summarize tools are safe to grant. isolate_host and disable_user require human confirmation or a deterministic playbook, never an unattended model.
Least privilege per tool. The auth-history tool does not need write access to anything.
Bound the blast radius. Rate-limit tool calls, cap agent turns, and log every invocation as a privileged action.

Route by Severity to Control Cost

A SOC processing tens of thousands of alerts a day cannot send all of them to a frontier model. Route by severity. Tier-1 queue triage goes to a fast, cheap model like Claude Haiku 4.5 (claude-haiku-4-5-20251001). Escalations that a human already cares about (correlating artifacts, drafting an incident timeline) go to Sonnet 5 (claude-sonnet-5) or Opus 4.8 (claude-opus-4-8), or the OpenAI equivalent. Cheap model for volume, capable model for the cases that earn it.

Keep Sensitive Data Out of the Call

The integration is only as safe as its data handling. Send the model the fields the task needs, not raw logs carrying credentials, PII, or full payloads. Redact or hash identifiers before the API call. Use an enterprise tier with a zero-retention, no-training agreement and keep that contract for your auditors. For regulated data, run retrieval locally with pgvector and a self-hosted embedding model and pass only the snippet, or deploy the model inside your own tenant via Amazon Bedrock or Google Vertex. The pattern is the same discipline you already enforce on every other third-party callout.

Roll Out in Shadow Mode

Do not flip this on live. Run it in shadow mode first: the model produces a verdict, a human still decides, and you compare. Track two numbers, agreement rate against your analysts and cost per alert. Promote a task from shadow to assisted only when the agreement rate earns it, and keep a human on every irreversible action indefinitely.

The teams that get value from wiring ChatGPT or Claude into a SOC are the ones who already understood their detection logic and data flows. The model amplifies the pipeline you have; it does not replace the engineering. GTK Cyber's Applied Data Science and AI for Cybersecurity course is built for exactly that: security practitioners who want to connect LLMs to real workflows, with the judgment to know where the model belongs and where it does not.