CompTIA SecAI+ — Übungsfragen und Probeprüfung

Zerlege die Anforderungen und schau dir an, welche Technologie jede einzelne erfüllt. Ein Ticket zu erstellen, die relevanten Logs zu sammeln und ein Playbook vorzuschlagen sind drei Aktionen über drei verschiedene Systeme hinweg, also Orchestrierung. Sie automatisch auszuführen, sobald ein Alert mit hohem Schweregrad ausgelöst wird, ist KI-gesteuerte Automatisierung. Die endgültige Entscheidung beim Analysten zu belassen, ist Human-in-the-Loop-Validierung. Eine SOAR-Plattform — security orchestration, automation and response — ist genau die Kategorie, die für diese Kombination gebaut ist: vorkonfigurierte Sätze von Remediation-Aktionen, die automatisch laufen, wenn ein Alert oder Incident auf eine Regel passt, oder die ein Analyst während einer Untersuchung manuell auslöst.

Bei den Alternativen fällt jeweils eine Anforderung weg. Statische Korrelationsregeln erkennen und alarmieren, handeln aber nicht, also wird kein Ticket eröffnet und kein Log eingesammelt. Ein Chatbot ohne Integrationen kann über einen Incident sprechen, erreicht aber weder das Ticketsystem noch den Log-Speicher, sodass nichts von dem, was er vorschlägt, ausgeführt werden kann. Ein manuelles Runbook, das von geplanten Jobs angestoßen wird, ist weder ereignisgesteuert noch adaptiv, denn es läuft nach Zeitplan, unabhängig davon, was passiert ist, und ein Mensch führt weiterhin jeden Schritt aus.

Prüfungstipp: Lies die Verben im Aufgabentext. Erkennen deutet auf Monitoring, orchestrieren und beheben deuten auf Response-Werkzeuge, und ein ausdrücklicher menschlicher Entscheidungspunkt sagt dir, dass die gesuchte Antwort den Analysten in der Schleife hält, statt ihn zu entfernen.

Der EU AI Act ist eine wegweisende Gesetzgebung, die ein risikobasiertes regulatorisches Framework für künstliche Intelligenz etabliert. Er kategorisiert AI-Systeme in vier Risikostufen: inakzeptables Risiko (vollständig verboten, z. B. Social-Scoring-Systeme), hohes Risiko (unterliegt strengen Anforderungen einschließlich Konformitätsbewertungen, z. B. AI im Recruiting oder in der Strafverfolgung), begrenztes Risiko (Transparenzpflichten, z. B. Chatbots, die offenlegen müssen, dass sie AI sind) und minimales Risiko (keine spezifischen Anforderungen, z. B. Spam-Filter). Organisationen, die AI in der EU einsetzen oder Daten von EU-Bürgern verarbeiten, müssen die Anforderungen der jeweiligen Stufe erfüllen. Der Act enthält außerdem Bestimmungen für General-Purpose-AI-Modelle wie Large Language Models. Das Verständnis der Risikoklassifizierung des EU AI Act ist für die SecAI+-Prüfung entscheidend, weil sie den weltweit umfassendsten regulatorischen Ansatz für AI Governance darstellt. Prüfungstipp: Der EU AI Act hat vier Risikostufen — merke dir die Hierarchie von inakzeptabel bis minimal.

Lernziel 1.2 listet die Datenverarbeitungskonzepte auf, die für die Sicherheit von KI-Daten wesentlich sind: Data Cleansing, Verifikation, Lineage, Integrität, Provenance, Augmentation und Balancing. Data Provenance hält Herkunft und Eigentümerschaft der Daten fest, während Data Lineage ihre Bewegung und ihre Transformationen durch die Pipeline nachverfolgt; zusammen begründen sie Vertrauenswürdigkeit und unterstützen Audits sowie die Untersuchung von Vorfällen. Für die Sicherheit ist das wichtig, weil vergiftete oder manipulierte Daten deutlich leichter zu erkennen sind, wenn Herkunft und Historie dokumentiert und überprüfbar sind. Verwechsle Provenance/Lineage nicht mit Augmentation (Erzeugen synthetischer Daten), Balancing (Ausgleichen einer Klassenschieflage) oder Watermarking (Einbetten von Eigentumsmarkierungen oder Erkennen KI-generierter Inhalte). Prüfungstipp: 'Woher stammen die Daten und wie wurden sie transformiert' bedeutet Provenance und Lineage.

Zwei Anforderungen müssen von einer einzigen Kontrolle erfüllt werden, und das grenzt das Feld schnell ein. Kostenzuordnung braucht eine Abrechnung pro Consumer; faire Isolation braucht eine Obergrenze pro Consumer. Eine Token-Limit-Policy am Gateway liefert beides, denn sie erzwingt Limits pro API-Consumer auf Basis des Token-Verbrauchs und lässt dich eine Tokens-pro-Minute-Rate zusammen mit einem Kontingent über einen längeren Zeitraum festlegen, gebunden an etwas, das den Aufrufer identifiziert, etwa einen Subscription-Key.

Tokens sind die richtige Einheit. Sowohl die Kosten als auch die Backend-Kapazität eines Sprachmodells skalieren mit Tokens und nicht mit der Anzahl der Requests, deshalb ist ein einfaches Requests-pro-Minute-Limit ein schlechter Näherungswert: Ein einziger sehr langer Prompt kann mehr Kapazität verbrauchen als tausend kurze und trotzdem eine Prüfung der Request-Rate bestehen. Den Zähler pro Consumer zu führen, macht aus einem globalen Sicherheitsventil erst eine Isolation, denn ein Team, das seine Obergrenze erreicht, wird gedrosselt, ohne den Spielraum eines anderen anzutasten.

Die Distraktoren lösen andere Probleme. Ein Filter für gesperrte Themen ist eine Content-Safety-Kontrolle und misst gar nichts. Semantisches Caching reduziert Backend-Aufrufe bei wiederholten Prompts, was den durchschnittlichen Kosten hilft, aber nichts über Fairness oder Zuordnung garantiert. Ein größeres Kontextfenster erhöht, wie viel ein einzelner Request verbrauchen darf, und macht das Risiko des Aushungerns damit größer statt kleiner.

Prüfungstipp: Wenn eine Gateway-Frage Kosten mit Kapazität kombiniert, such nach der Kontrolle, deren Einheit Tokens sind und deren Geltungsbereich der Consumer-Key ist.