Sistemi strojnega učenja sprejemajo vse več odločitev, ki jih je v preteklosti izvajala samo deterministična programska oprema.

Modeli klasificirajo podatke, zaznavajo goljufije, identificirajo malicious activity, priporočajo actions, generirajo vsebino in prek AI agentov vse pogosteje komunicirajo z drugimi sistemi.

Zato attacker ne napada več samo aplikacije okoli modela.

Lahko poskuša vplivati na odločitev modela, zastrupiti informacije, iz katerih se model uči, pridobiti informacije o občutljivih podatkih ali legitimne generativne capabilities uporabiti za nezaželen namen.

To področje imenujemo Adversarial Machine Learning oziroma AML.

Aktualna taksonomija, na kateri temelji izvorna ShabuShabu analiza, predictive AI napade organizira predvsem okoli evasion, poisoning in privacy kategorij, pri generative AI pa dodaja še misuse.

Kaj je Adversarial Machine Learning?

Adversarial Machine Learning proučuje napade, pri katerih attacker namerno manipulira, vpliva na ali izkorišča machine-learning system.

Pri običajnem software exploitationu iščemo broken access control, memory corruption, exposed API ali druge implementation vulnerabilities.

AML napad lahko deluje drugače.

Attacker morda ne potrebuje programske napake.

Izkoristi način, kako se model uči ali sprejema odločitve.

Model prejme input, ga obdela na podlagi patternov, naučenih iz podatkov, in ustvari output.

Če attacker dovolj dobro razume to razmerje, lahko poskuša input ali learning process oblikovati tako, da model doseže drugačen rezultat.

Zakaj tradicionalna kibernetska varnost ni dovolj

Traditional cybersecurity ostaja nujna.

AI model še vedno teče na serverju.

API potrebuje authentication.

Cloud potrebuje access controls.

Aplikacija lahko vsebuje običajne vulnerabilities.

Machine learning pa doda novo plast.

Behavior ni določen samo s codeom.

Vplivajo nanj tudi training data in learned parameters.

To pomeni, da data pipeline postane del security surfacea.

Za penetration testerja se threat model razširi.

Vprašanje ni samo:

»Ali lahko kompromitiramo aplikacijo?«

Ampak tudi:

»Ali lahko namerno spremenimo odločitev modela, ne da bi kompromitirali aplikacijo okoli njega?«

AI lifecycle določa attack surface

AML napade je koristno razdeliti glede na fazo, v kateri attacker poseže v sistem.

Nekateri delujejo med inferenceom.

Drugi napadejo training ali fine-tuning.

Privacy napadi imajo drugačen cilj: ne spreminjajo nujno vedenja modela, ampak poskušajo pridobiti informacije.

Generative AI dodaja misuse, pri katerem model lahko deluje povsem pravilno, vendar ga nekdo uporablja za napačen cilj.

Faza napada vpliva tudi na remediation.

Malicious inference input lahko odstranimo in model ostane nespremenjen.

Poisoned training data pa lahko vpliva na model še dolgo po tem, ko attacker izgubi prvotni access.

Evasion attacks: manipulacija modela med inferenceom

Evasion attack poskuša vplivati na že deployed model.

Attacker spremeni input tako, da sistem sprejme napačno ali attacker-preferred odločitev, ne da bi moral spreminjati model.

Osnovna ideja je preprosta.

Model se je naučil določene decision boundary.

Attacker išče input, ki to boundary prestopi na nepričakovan način.

Input manipulation brez spremembe modela

Predstavljajmo si classifier, ki ocenjuje incoming content.

Software deluje normalno.

Model ne vrne errorja.

Vse komponente delujejo po načrtu.

Toda attacker spremeni lastnosti inputa toliko, da model sprejme napačno odločitev.

V traditional pentestu bi researcher morda poskušal bypassati authentication code.

V AML assessmentu lahko preverja, ali se model, na katerem ta security decision temelji, da namerno zavesti.

Security boundary je tokrat v model behavior.

Evasion ni samo computer-vision problem

Adversarial examples so postali znani predvsem skozi image classification.

Toda princip velja bistveno širše.

Pomemben je povsod, kjer model vpliva na security-relevant decision.

Fraud detection.

Spam filtering.

Malware classification.

Anomaly detection.

Content moderation.

Identity models.

Generative AI.

Če application avtomatsko zaupa model outputu, lahko evasion postane pot okoli širšega security controla.

Model confidence ni dokaz varnosti

Model je lahko zelo samozavesten in še vedno napačen.

Confidence je del njegovega prediction procesa.

Ne dokazuje legitimnosti inputa.

Če classifier vpliva na sensitive operation, mora arhitektura predvideti tudi možnost napačnega classa.

Varnost ne sme propasti samo zato, ker se je ena detection komponenta enkrat odločila napačno.

To je klasičen defense-in-depth princip.

Poisoning attacks: manipulacija tega, kar se model nauči

Poisoning ne cilja samo ene inference odločitve.

Napade podatke ali learning process, iz katerih model oblikuje prihodnje behavior.

Cilj je lahko vplivati na model še dolgo po prvotni attacker interakciji.

Training data je security asset

Organizations veliko pozornosti namenijo final modelu.

Data pipeline pa pogosto obravnavajo predvsem kot engineering problem.

To je nevarno.

Če attacker vpliva na training, fine-tuning ali drug learning input, lahko vpliva tudi na behavior produkcijskega modela.

Data pipeline je zato podoben software supply chainu.

Security team mora vedeti:

od kod data prihajajo,

kdo jih lahko spreminja,

kateri source je authoritative,

kakšen review se izvede pred model updateom.

Poisoning je lahko širok ali zelo ciljan

Preprost poisoning attack lahko poslabša splošno performance.

Bolj subtilen attacker pa želi, da se model obnaša napačno samo pod določenimi pogoji.

Pri običajni evaluation model še vedno izgleda zdrav.

Average accuracy ostane visoka.

Problem se pokaže samo pri attacker-controlled trigger condition.

Zato standardni benchmark ni dovolj za security validation.

Potrebujemo threat scenarios.

RAG knowledge poisoning

Retrieval-Augmented Generation uvaja soroden integrity risk.

Attackerju ni treba spreminjati foundation modela.

Če lahko v knowledge source doda malicious ali misleading content, lahko vpliva na informacije, ki se kasneje znajdejo v model contextu.

Z vidika usera AI samo uporablja external knowledge.

Z vidika security pa je knowledge base del decision pipelinea.

RAG content je zato treba obravnavati kot del AI information supply chaina.

Data provenance postaja ključen control

Poisoning risk močno zmanjša razumevanje provenance.

Kateri dataset je authoritative?

Katere external sources uporabljamo?

Kdo sme spreminjati internal training data?

Se user feedback avtomatsko uporablja pri learningu?

Kdo lahko dodaja RAG dokumente?

Različni sources imajo različne trust levels.

Architecture mora te razlike ohraniti.

Ne sme vsega razpoložljivega contenta avtomatsko obravnavati kot equally trusted.

Privacy attacks: kaj model lahko razkrije

Vsi AML napadi ne poskušajo povzročiti napačne odločitve.

Privacy attacker išče informacije.

Vprašanje postane:

»Kaj lahko iz interactiona z modelom izvemo o podatkih ali sistemu v ozadju?«

To je pomembno, kadar so modeli trained, fine-tuned ali runtime povezani z občutljivimi informacijami.

Model lahko postane information side channel

User morda nima direct accessa do training dataset-a.

To ne pomeni avtomatsko, da iz model behaviora ni mogoče pridobiti nobenega signala o podatkih.

Attacker lahko interagira z modelom in analizira njegove responses.

Feasibility močno zavisi od architecture, modela in attacker accessa.

Privacy problemov zato ne smemo predpostaviti niti zanikati brez threat modela.

Training-data privacy in runtime leakage nista isti problem

AI security pogosto vse označi kot »data leakage«.

Toda root cause je lahko zelo različen.

Training privacy problem je povezan s podatki, uporabljenimi pri učenju.

Runtime leakage je lahko povezan s prompti, RAG, tools ali broken authorization.

Če LLM assistant pridobi records drugega customerja, je lahko pravi root cause tenant isolation, ne sofisticiran AML privacy exploit.

To razlikovanje neposredno vpliva na remediation.

Privacy testing mora biti sorazmeren

Ker privacy assessment vključuje sensitive information, mora biti scope nadzorovan.

Če controlled test record pokaže broken confidentiality boundary, ni razloga za množično pridobivanje real customer data.

Cilj je dokazati odpoved security property.

Ne maksimalno izpostaviti podatkov.

Misuse attacks: ko generativna AI deluje pravilno za napačen cilj

Misuse je posebej pomembna kategorija pri generative AI.

Model ni nujno broken.

Lahko deluje točno tako, kot je bil zasnovan.

Problem je namen uporabe.

Legitimen capability se uporabi za nezaželen ali škodljiv cilj.

Misuse je problem capability governance

Traditional cybersecurity veliko govori o unauthorized accessu.

Pri misuse ima user lahko popolnoma legitimen access.

Zato se security vprašanja spremenijo.

Kdo lahko uporablja model?

Katere capabilities dobi?

Do katerih data lahko pride?

Katere tools lahko agent uporablja?

Kakšen monitoring obstaja?

Kdaj usage postane abnormalen?

Nekateri AI riski obstajajo zato, ker je powerful capability na voljo, ne zato, ker ima implementation klasičen bug.

Misuse in excessive agency

Misuse je še pomembnejši pri agentic systems.

Text-only model večinoma generira informacije.

Agent pa lahko izvaja actions.

Impact je zato povezan tako z model capability kot z application authority.

Agent z unnecessary tools in broad privileges spremeni misuse v veliko večji security problem.

Security teams morajo ločeno vprašati:

Ali lahko user model zlorabi?

In:

Kaj mu surrounding architecture omogoča doseči?

AML in prompt injection nista sinonima

Prompt injection je pomemben.

Ni pa celoten adversarial AI landscape.

Prompt injection vpliva na LLM runtime instructions.

Evasion je širši inference-time concept.

Poisoning napada learning ali knowledge sources.

Privacy napada protected information.

Misuse pa zlorablja legitimne generative capabilities.

Pravilna classification pomaga najti pravi remediation control.

AML proti traditional vulnerability exploitation

Traditional API vulnerability je pogosto deterministic.

Če je authorization broken, isti request vedno vrne unauthorized object.

AML behavior je lahko probabilistic.

Rezultat je lahko odvisen od:

model version,

input variation,

system state,

sampling behavior.

Zato security researcher ne sme preveč vezati findinga na en exact input.

Bolje je definirati underlying security property.

Če attacker z realističnim accessom zanesljivo povzroči security-sensitive failure, je finding bistveno močnejši od enkratnega anomalnega model outputa.

Attacker knowledge spreminja threat model

Različni attackers imajo različne informacije.

Internal researcher pozna architecture.

External user vidi samo API.

Nekdo pozna training process.

Drug attacker lahko behavior le inferira skozi queries.

Level knowledge vpliva na feasibility in design napada.

Assessment mora modelirati attackerja, ki ga organization realno pričakuje.

Attacker capability je enako pomemben

Ali attacker lahko pošlje en input ali milijon?

Lahko spremeni training data?

Lahko objavi RAG document?

Ima authenticated access?

Vidi confidence ali samo končni decision?

Lahko vpliva na feedback loop?

Unrealistic attacker capability vodi do nerealističnih findings.

Prenizek assumption pa lahko spregleda realen risk.

AML je disciplina threat modelinga

Dober assessment se začne z architecture.

Kateri model uporabljamo?

Od kod dobiva data?

Kdo vpliva na training?

Kateri decisions so security-sensitive?

Kaj lahko model razkrije?

Je povezan s tools?

Kaj se zgodi, ko se zmoti?

Cilj ni dokazati, da machine learning lahko faila.

To že vemo.

Cilj je pokazati, ali lahko attacker namerno povzroči failure z varnostnim impactom.

Kako testirati evasion

Najprej identificirajte decisions, ki so pomembne.

Cosmetic classifier nima iste severity kot fraud detector ali access-related model.

Nato v authorized environmentu preverite, ali attacker-controlled inputs lahko sistematično vplivajo na decision.

Merite practical impact.

Je rezultat ponovljiv?

Kakšen access je potreben?

Ali downstream controls napad ustavijo?

Ali monitoring vidi anomalijo?

Cilj ni čim bolj zmediti model.

Cilj je izmeriti security robustness.

Kako oceniti poisoning risk

Preglejte zgodnejše lifecycle faze.

Kdo dodaja training information?

Kateri datasets so external?

So model updates automatic?

Lahko feedback spremeni prihodnji behavior?

Lahko low-trust identity spreminja knowledge repository?

Če organization teh odgovorov nima, ne pozna dobro svojega AI supply chaina.

Kako testirati privacy

Najprej ločite:

training information,

runtime context,

RAG data,

tool outputs.

Nato preverite, kaj lahko unauthorized identity inferira ali pridobi.

Pri enterprise LLM systems je klasičen access control pogosto zelo pomembna privacy defense.

Če unauthorized data sploh ne pridejo v userjev model context, se veliko disclosure pathways odstrani že na architecture ravni.

Kako oceniti misuse risk

Začnite s capability analysis.

Kaj lahko sistem naredi?

Kdo dobi access?

Ali imajo različni user segments različne privileges?

Kateri external systems so povezani?

Kakšen usage je visible security ekipi?

Mitigation ni vedno samo model-level guardrail.

Uporabni so lahko:

access controls,

rate limits,

tool restrictions,

user verification,

anomaly monitoring,

environment isolation.

To je širši security principle:

probabilistični model ne sme biti edini nosilec security architecture.

Ena obramba ne reši celotnega AML

Ni universal mitigation.

Evasion-hardening ne reši poisoning problema.

Data governance ne reši avtomatsko runtime privacy leakage.

Prompt filtering ne reši overprivileged tool.

AML zato potrebuje defense in depth.

Vsaka attack surface potrebuje ustrezen control.

Testirajte impact, ne tehnične zanimivosti

Adversarial ML lahko proizvede zelo zanimive model failures.

Security assessment mora vprašati:

Ali to vpliva na real produkt?

Unusual text output je lahko low severity.

Reliable bypass security-sensitive classifierja je nekaj drugega.

Manipulated agent, ki uporablja privileged tool, je spet nekaj drugega.

Priority naj določajo:

realistic exploitability,

attacker capability,

business consequence.

Retesting AML findings

Fix ne sme blokirati samo enega znanega samplea.

Če je bil evasion problem, retestirajte robustness proti reasonable variations.

Če je poisoned knowledge problem, samo odstranitev enega dokumenta ne popravi weak publishing modela.

Če broad RAG authorization povzroči data leakage, prompt change ne reši root cause.

Strong retest preveri, ali originalna attacker capability še vedno lahko doseže isti security outcome.

AML in penetration testing se združujeta

AI je vedno bolj običajen component production softwarea.

Penetration tester lahko ugotovi, da classifier upravlja pomemben workflow.

AML researcher lahko manipulira model, vendar potrebuje API in authorization expertise za oceno impacta.

LLM red team lahko spremeni agent behavior, vendar mora AppSec researcher preveriti, ali je tool call res unauthorized.

Modern attack path prečka discipline.

Najmočnejši AI security assessment zato kombinira:

model-aware adversarial testing + traditional application-security reasoning.

Prihodnost AML je širša od model robustness

Pri AI sistemih bo treba analizirati celotno architecture.

Data integrity.

Model behavior.

Retrieval.

Privacy.

Tools.

Permissions.

Autonomy.

Ključno vprašanje prihodnosti ni samo:

»Je model robusten?«

Ampak:

»Ali AI-enabled application ostane varna, ko attacker namerno manipulira eno od komponent learning sistema?«

To je praktični pomen Adversarial Machine Learning za cybersecurity.

Pogosta vprašanja o Adversarial Machine Learning

Kaj je Adversarial Machine Learning?

To je področje varnosti, ki proučuje namerno manipulacijo modelov, learning procesov, podatkov in information boundaries v machine-learning sistemih.

Katere so glavne vrste AML napadov?

Za predictive AI so pomembni evasion, poisoning in privacy. Pri generative AI je pomemben tudi misuse.

Kaj je evasion attack?

Inference-time napad, pri katerem attacker manipulira input, da deployed model sprejme napačen ali attacker-preferred decision.

Kaj je poisoning attack?

Napad na informacije, uporabljene pri trainingu, fine-tuningu, feedbacku ali drugih trusted knowledge sources, z namenom vplivati na prihodnji model behavior.

Kaj je AI privacy attack?

Poskus pridobivanja ali inferiranja informacij o sensitive data, training information ali AI systemu skozi model interactions.

Kaj pomeni generative AI misuse?

Namerna uporaba legitimnih AI capabilities za nezaželen ali škodljiv cilj, ne nujno z izkoriščanjem klasične software vulnerability.

Ali je prompt injection AML?

Je del širšega adversarial AI landscapea, vendar AML vključuje tudi evasion, poisoning, privacy in misuse.

Kako se AML razlikuje od penetration testinga?

Traditional pentesting išče exploitable weaknesses v softwareu, infrastrukturi in business logic. AML dodatno preverja, ali lahko attacker namerno vpliva na model behavior, learning process ali information exposure. Pri modernih AI produktih se obe področji vse bolj prekrivata