CompTIA SecurityX — Übungsfragen und Probeprüfung

Im AWS Shared Responsibility Model verantwortet AWS die Sicherheit „der“ Cloud (physische Infrastruktur, Hypervisor, globales Netzwerk), während Kunden die Sicherheit „in“ der Cloud verantworten (AWS Shared Responsibility Model, aws.amazon.com/compliance/shared-responsibility-model). Security Groups (stateful, auf Instanzebene) und NACLs (stateless, auf Subnetzebene) sind unabhängig vom Servicemodell immer vom Kunden konfigurierte Netzwerkkontrollen. Warum nicht die anderen? Die physische Rechenzentrumssicherheit ist eine Kernpflicht von AWS. Die globale Netzwerkinfrastruktur wird von AWS verwaltet. Das Patchen des Hypervisors liegt gemäß der IaaS-Grenze bei AWS. Die Grenze verschiebt sich je nach Servicemodell: EC2 (IaaS) bringt mehr Kundenverantwortung mit sich, Lambda (serverless) weniger. Laut AWS Well-Architected Security Pillar liegt jede Konfigurationsentscheidung zu Kunden-Workloads beim Kunden. Ref: AWS Shared Responsibility Model; AWS Well-Architected Security Pillar; NIST SP 800-145.

Klassifiziere nach dem Zustellmechanismus, nicht nach der Geschichte, die darum herum gebaut ist. Ein Angreifer, der Nachrichten verschickt, um Zugriff auf die Systeme der Opfer zu erlangen, betreibt Phishing, und die Klasse deckt bösartige Anhänge und Links ausdrücklich ebenso ab wie das Auftreten als vertrauenswürdige Quelle. Sich als Lieferant auszugeben, ist eine Verfeinerung der Zielansprache, die die Nachricht überzeugender macht, aber sie ändert nichts daran, um welche Technik es sich handelt.

Die Distraktoren gehören zu späteren Phasen oder zu anderen Zielen. Der Missbrauch bestehender Anmeldedaten beschreibt einen Angreifer, der bereits gültigen Kontozugriff besitzt; so setzt sich ein Einbruch fort, nicht so kommt dieser hier an. Command-Traffic in gewöhnliche Protokolle der Anwendungsschicht einzubetten, ist ein Command-and-Control-Verhalten, das erst dann relevant wird, wenn ein Standbein existiert. Code innerhalb eines anderen Prozesses auszuführen, ist eine Technik zur Ausführung und Umgehung auf einem bereits kompromittierten Host.

Prüfungstipp: Die richtige Klassifizierung ist wichtig, weil sich die Gegenmaßnahmen unterscheiden. Der Zustellung begegnest du mit Nachrichtenauthentifizierung, Detonation von Anhängen und einem Meldeweg für Nutzer, während Missbrauch von Anmeldedaten und Code-Ausführung völlig andere Kontrollen brauchen, eine falsche Einordnung schickt dich also zur falschen Abwehr.

Shadow IT ist die Nutzung von IT-Systemen, Geräten, Software oder Cloud-Diensten ohne ausdrückliche Freigabe der Organisation; dadurch entstehen unverwaltete Risiken und blinde Flecken in der Governance. Hier hat die IT-Abteilung nicht freigegebenen Cloud-Speicher genutzt — die Definition aus dem Lehrbuch. Warum nicht die anderen? Das Restrisiko ist das Risiko, das nach dem Einsatz von Kontrollen übrig bleibt, und setzt voraus, dass Kontrollen existieren. Das inhärente Risiko ist das Ausgangsrisiko vor jeglichen Kontrollen und hat nichts mit unbefugter Nutzung zu tun. Beim übertragenen Risiko wird das Risiko über eine Versicherung oder Outsourcing an einen Dritten weitergegeben. Shadow IT untergräbt Asset-Inventar, Compliance, Incident Response und Datenschutz, weil Security-Teams nichts absichern können, von dessen Existenz sie nichts wissen. Es reißt Lücken in Risikobewertungen, Policy-Durchsetzung und regulatorische Compliance. Ref: NIST CSRC Glossary (shadow_it); NIST SP 800-53 Rev 5 CM-8 (System Component Inventory); NIST CSF Identify function.

Certificate Pinning bindet ein bestimmtes Zertifikat oder einen bestimmten öffentlichen Schlüssel an den erwarteten Server einer Anwendung und ergänzt damit die übliche TLS-Kettenprüfung. Standard-TLS vertraut jeder CA im Zertifikatsspeicher des Geräts; eine kompromittierte oder betrügerische CA kann gefälschte Zertifikate ausstellen und so das Abfangen per MITM ermöglichen. Pinning verhindert das, indem geprüft wird, ob das Zertifikat des Servers einem vorab eingebetteten Hash entspricht. Ansätze: Leaf-Pinning (streng), Pinning der Intermediate-CA (flexibel) oder Public-Key-Pinning (übersteht die Zertifikatserneuerung). Warum nicht die anderen? DoS-Angriffe zielen auf die Verfügbarkeit, nicht auf die Authentifizierung. XSS nutzt das Browser-DOM aus und hat mit Transportsicherheit nichts zu tun. SQL-Injection zielt auf das Parsen von Abfragen, nicht auf TLS. Zu den Risiken des Pinnings gehört der betriebliche Aufwand bei der Zertifikatsrotation; Backup-Pins sind unverzichtbar, um eine Aussperrung zu verhindern. Ref: OWASP Mobile Security Testing Guide (MSTG); OWASP Mobile Top 10 M3; RFC 7469 (HTTP Public Key Pinning).