CCSP: AI and Machine Learning in Cloud Security, SOAR and AI Regulation

Machine learning (ML) detects cloud threats by learning patterns from security telemetry (management-plane logs, identity sign-ins, network flows, endpoint events) and scoring new events against what it learned. The approach you choose depends on whether you have labelled examples and whether the threat is known or novel.

• Supervised learning trains on events that people have already labelled (malicious or benign, phishing or legitimate). It reproduces those known classes and can be measured against the labels, which makes it the fit when you have a large, trustworthy labelled history and want the same decision made faster.
• Unsupervised learning needs no labels. It clusters activity or models what normal looks like and scores outliers, which makes it the fit for spotting behaviour never seen before when no labelled attacks exist. Its output is "unusual", not "malicious", so analysts still decide.
• Rule-based correlation (the classic SIEM approach) is not ML: it finds exactly what a rule describes, such as a published attacker technique, and nothing else.
• Reinforcement learning learns from rewards for the actions it takes. It suits sequential decision problems, but it is a poor fit for detection whenever the reward is only a proxy for accuracy, because the system learns to maximise the proxy.

In practice these are layered: ML models catch what rules cannot describe, and rules catch what a single model can be fooled into missing. A cloud security professional's job is to choose the approach that matches the data available and the question asked, and to remember that ML output is evidence for an analyst, not a verdict.

User and entity behaviour analytics (UEBA) decides what is unusual by first learning a baseline of how each user and entity (account, workload, service identity, device) normally behaves, then scoring later activity by how far it deviates. Without the baseline there is nothing to deviate from, so UEBA needs a learning period before it can alert.

A baseline typically captures sign-in times and locations, the resources an identity touches, data volumes moved, API calls made and peer-group behaviour (what similar accounts do). A finance user suddenly listing every storage bucket, or a service identity calling an API it has never called, scores high.

Baseline contamination

The baseline is only as clean as the period it learned from. To the model, whatever happened during the learning window is normal, including misuse that was already under way, so that behaviour becomes part of normal and can carry on without ever scoring as a deviation. Nothing is broken: the feeds and thresholds work as designed on a contaminated picture of normal. The controls are to learn from a period believed to be clean, to review and rebuild baselines when an incident shows an account was compromised, and to keep non-baseline detections (rules, threat intelligence) alongside UEBA.

When normal itself changes

An acquisition that merges two directories, a move to remote working or a new collaboration suite changes what normal looks like for many identities at once. A baseline learned before the change then flags ordinary work, and alert volume jumps. Because the out-of-date picture of normal is the cause, the fix is to rebuild the baseline from activity recorded after the change. Any adjustment that only suppresses alerts treats the symptom and leaves the model judging today's work against yesterday's environment.

A detection model is measured by how well it handles the rare class (attacks), not by overall accuracy. Most models produce a score, and an alert threshold turns the score into a yes/no decision. Moving the threshold changes the balance between the two kinds of error without changing the model itself.

• A false positive is a benign event that alerts (wasted analyst time, alert fatigue).
• A false negative is an attack that does not alert (a missed compromise).

Why accuracy misleads on security data

Attacks are rare. If one event in a thousand is malicious, a model that never alerts is right 999 times in 1,000, and its specificity is perfect. Both metrics are dominated by the benign majority, so a vendor's headline accuracy says almost nothing about detection. Ask for precision and recall on the malicious class, measured on data like yours.

Choosing the threshold and the metric

Lowering the threshold lets more events cross it: recall rises (more attacks caught) and precision falls (more false positives). Raising it does the opposite. Which error matters more is a business decision, and the costlier error picks the metric: if a missed attack is the worse outcome, recall should decide between models; if each false alarm is expensive (for example because every alert triggers a disruptive response), precision leads. Many teams track both, or a combined score, but the stated cost of each error sets the priority.

Detection models degrade because the data they see in production stops resembling the data they learned from. Three near-twin causes produce poor results, and telling them apart decides the fix.

A model validated on held-out samples of the same data it trained on can score very well and still fail in production: the test only proved it works on data like its training set. A model trained and tested on one region's Windows endpoint events, for instance, says little about Linux containers elsewhere, where event types, identities and behaviour all differ.

Pre-trained and provider-supplied models

When a provider offers a model pre-trained on its other customers' telemetry, its benchmark describes those customers, not you. Under shared responsibility the provider runs the model, but the customer remains accountable for deciding whether its alerts can be relied on, and the evidence for that decision is measurement on data like yours: validate it against a labelled sample of your own telemetry before relying on it or tuning it. Assurance about how the provider operates its service answers a different question from whether the model fits your environment.

Detecting degradation early

Drift is caught by monitoring it directly rather than waiting for missed incidents:

• Compare the distribution of live inputs with the training baseline (new event types, shifted volumes, new sources).
• Compare the model's outputs with analyst verdicts on the alerts they triage, tracking precision and, where possible, recall over time.

The principle is that drift lives in live data, so the detector has to watch live inputs and live outcomes; anything measured on data that never changes cannot reveal it.

Machine learning systems are attacked through their training data, their inputs at run time and their query interface. NIST's adversarial machine learning taxonomy (NIST AI 100-2) groups these as poisoning, evasion and privacy attacks. Each needs a different control, so naming the attack correctly matters.

Some distinctions are tested closely:

• Poisoning versus evasion: poisoning acts before or during training and lands when the model retrains; evasion attacks a model that is already deployed and leaves it unchanged.
• Extraction versus evasion: both involve many queries. Extraction aims to copy the model; evasion aims to get one input past it.
• Inversion versus membership inference: inversion recovers data the attacker lacks; membership inference tests a record the attacker already has.

Matching the control to the attack

Query attacks work through legitimate, authorised responses. Controls that protect who the caller is, the transport, the stored data or the model artefact are worth having, but they do not change what an entitled caller learns from the answers. The controls that work act on the query interface (how much and how fast a client may ask, how much detail each answer reveals) or on the model itself. Throttling the interface helps most against attacks that need a large number of queries; attacks that need only a little information have to be addressed in the model, by making it leak less: differential privacy adds calibrated noise during training so that any single record can change the model's outputs only by a strictly bounded amount (set by the privacy budget, epsilon), while scores stay useful.

Evasion exploits a specific blind spot, and that blind spot persists until the model is shown examples of the manipulation. The durable answer is adversarial training, which teaches the model what manipulated inputs look like, combined with defence in depth: independent detection layers that do not share the model's blind spot. Fresher data of the ordinary kind does not close a blind spot the data never contained. Generative AI adds its own input attacks, such as prompt injection against assistants that can call tools, which follow the same principle: untrusted input must not be able to change what the system is permitted to do.

Data source validation and verification means proving that the data feeding a model or detection pipeline is authentic (it came from who it claims), intact (unchanged since publication), complete (nothing silently missing) and fit for use (correct, consistent and representative). Every downstream decision inherits the quality of its inputs, so these checks come before training and run continuously during ingestion.

Authenticity and integrity of external datasets

• Compare the file's cryptographic hash (for example SHA-256) with a checksum signed by the dataset's originator. That proves the file is exactly what was released.
• The trust must trace back to the originator. A file and a checksum fetched from the same location prove only that the location is self-consistent: whoever can alter one can alter both. Verify the publisher's digital signature with a key obtained from the publisher directly, so the check rests on something an intermediary cannot replace.
• Checks on what the data contains or whether you are allowed to use it are separate questions. Only a cryptographic comparison against something the publisher vouches for shows that the bytes you hold are the bytes that were released.

Provenance and lineage

Provenance records where data came from; lineage records what happened to it on the way: which source datasets and versions, which transformations, which training run, which model version. Lineage is what lets you answer an auditor's question "what produced the model in production?" with evidence, and it is what lets you find every model affected when a source is found to be poisoned. Keeping copies or version numbers of individual pieces is not lineage; its value is the recorded link between each data version, each processing step and the model that resulted.

Telemetry quality for detection

Schema mapping and time normalisation are near-twins: both are needed, but only time normalisation fixes ordering. Integrity hashing proves what arrived is unchanged; it says nothing about what never arrived, which is what gap monitoring catches.

Multi-tenant and contributed data

When a shared model learns from data that many parties contribute (for example a community feed of reported phishing URLs), any contributor can try to skew it. The risk enters with the data, so the control belongs at the point of entry: checks at ingestion that confirm who sent each contribution and whether it looks like the rest, with suspicious contributions held back from the next training run. Protecting the stored data or the deployed model does not help, because the skewed data arrives through a legitimate channel.

Security Orchestration, Automation and Response (SOAR) adds the ability to act: it takes alerts and runs playbooks that work through connected security tools to enrich, contain and track an incident. A SIEM collects, correlates, retains and displays events and raises alerts; SOAR picks up where the SIEM's alert ends. Many platforms now combine both, but the functions remain distinct.

Event collection, correlation, retention and dashboards are SIEM capabilities. A SOAR playbook might: receive an alert of a suspicious sign-in, look up the account's recent activity and threat intelligence on the source address, open a case, revoke the active sessions, ask an analyst whether to disable the account, and record each step. In the cloud this speed matters because a stolen credential can be used against the management plane within minutes. ML increasingly sits inside SOAR as well, for example to score alerts for triage or suggest the next step, which brings every data-quality and model-risk concern above into the response process.

You design SOAR playbooks safely by deciding which steps run automatically and which wait for an analyst, by limiting what the platform itself can do, and by testing before anything runs in production. Automation acts at machine speed, so a wrong action also spreads at machine speed.

Automatic versus approved steps

The deciding factors are impact if the alert is a false positive and reversibility. Enrichment has no downside on a false positive, so it is the safest step to automate fully. Where speed and safety pull in opposite directions, split the playbook rather than choosing one extreme: automate every step that is safe and reversible on a false positive, and put the approval gate only in front of the steps whose mistakes would be costly or hard to undo.

Securing the SOAR platform

A SOAR platform holds privileged credentials to the CSP's management API, the identity provider and network devices, which makes it a high-value target. If it is compromised, the attacker acts with its credentials, so the blast radius is set by what those credentials allow. The primary control is least privilege: give its service identity only the actions its playbooks perform, scoped to the resources they touch. Controls that protect the credentials from being stolen are worth having too, but once an attacker controls the platform itself, only the scope of its permissions limits the damage. Log every action the platform takes so its own activity can be audited.

Testing playbooks

A new automated playbook is tested first against simulated incidents outside production, because only running it shows what it will really do when it fires. Playbooks are then change-controlled like code, because a small edit can change what is isolated or disabled.

The ethical concerns for AI are whether its outcomes are fair, whether people can understand it (transparency and explainability), who is accountable for its decisions, whether humans keep meaningful oversight, and whether it respects privacy. Hosting a model on a cloud AI platform does not move these concerns to the provider: the organisation that decides to use the model for a purpose owns its effects.

Bias and fairness

A model trained on past human decisions learns whatever those decisions contained. If years of past insurance-claim approvals were harsher on one region's customers, a model trained on them reproduces that disparity: this is historical bias in the labels, and it appears as unequal outcomes for otherwise equivalent people. Nothing malfunctioned; the model faithfully learned a pattern in its labels.

Removing the protected attribute (for example nationality) rarely fixes it, because other features act as proxies: postcode, school, employment gaps or purchasing patterns can encode the same information. The fix is fairness testing: measure outcomes per group, identify proxy features, then adjust the data, the features or the model, and keep measuring. Because the bias lives in the data rather than in any single field, only measuring outcomes shows whether a change worked.

Transparency versus explainability

When people must be told the reasons for a specific decision, information about the model as a whole does not meet the requirement: global measures describe average behaviour, not why one person got one outcome. A per-decision duty is met by an inherently interpretable model or by a local (per-decision) explanation method added to a complex one, and a gain in accuracy does not remove the duty.

Human oversight and privacy

Human oversight means a person can understand, intervene in and override the system where its decisions matter, which is also what data protection and AI law require for significant decisions. Privacy concerns include training on personal data without a lawful basis, models that leak training records (see membership inference) and profiling that people would not expect.

AI in the cloud is governed by data protection law wherever personal data is processed (in the EU, the GDPR), by AI-specific law such as the EU AI Act, and by voluntary AI risk frameworks and management standards such as the NIST AI RMF and ISO/IEC 42001. As with other cloud regulation, the obligations attach to the organisation's role (controller, provider, deployer), not to where the model is hosted.

GDPR: automated decisions and DPIAs

• Article 22 gives data subjects the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. The trigger is the effect of the decision, not the data type or the mere use of profiling.
• The exceptions are that the decision is necessary for entering into or performing a contract, is authorised by EU or member state law with safeguards, or is based on the person's explicit consent. These are alternatives: any one of them is a sufficient basis on its own.
• Under the contract and consent exceptions, Article 22(3) still requires safeguards, at least the right to obtain human intervention, express a point of view and contest the decision. Automated decisions on special category data are allowed only with explicit consent or substantial public interest, plus safeguards.
• Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in high risk; systematic and extensive evaluation of people through automated processing, including profiling, on which decisions about them are based is a listed case, for example automated scoring of customers that decides who is offered a service. Article 36 prior consultation with the supervisory authority follows only when a DPIA shows high residual risk. Because the DPIA decides whether and how the processing may go ahead and which safeguards it needs, it comes before the other compliance steps, not after them.

The EU AI Act: risk-based categories

The EU AI Act (Regulation (EU) 2024/1689) entered into force in August 2024 and applies in stages; its prohibitions have applied since February 2025. It sorts AI systems by risk, and the use case, not the technology, decides the category.

Emotion recognition shows why the use decides: in general it carries transparency duties and can be high-risk, but in the workplace or in education it is prohibited unless the purpose is medical or safety, so the same technique can be lawful with transparency in one setting and banned in an office or classroom. The Act also places separate obligations on providers of general-purpose AI models. Its timetable for some high-risk obligations has been subject to proposed amendment, so check the current dates rather than relying on memory.

AI risk frameworks and management standards

The NIST AI RMF's Govern function is cross-cutting: it sets the policies, accountability and risk culture and is infused throughout the other three. Map frames a specific system's context: its purpose, users, deployment setting and the people its outputs could affect. Measure chooses metrics and tests the risks identified, and Manage prioritises and treats them. NIST also publishes a Generative AI Profile (NIST AI 600-1) that applies the framework to generative systems. When the assurance needed is about AI governance and must be certifiable, ISO/IEC 42001 is the standard that provides it; ISO/IEC 27001 addresses information security whatever its scope boundaries.