ANHANG

Lösungen zu den Übungen

Dies sind die Antworten zu den Übungen am Ende jedes Kapitels.

Kapitel 1

  1. A, C und D. Das Erzwingen einer Multifaktor-Authentifizierung ist auch eine gute Idee, aber es geht hier um ein Beispiel für das Prinzip der Defense in Depth, nicht für das des Least Privilege.
  2. A und D. Strikte Firewall-Regeln können helfen, aber sie stehen nicht für eine Defense in Depth, sofern sie nicht mit anderen Schutzmaßnahmen kombiniert werden. Trust Boundaries sind auch wichtig und können genutzt werden, um Schutzmaßnahmen zu definieren, aber es handelt sich ebenfalls nicht um eine Maßnahme für Defense in Depth.
  3. A, B, C und D. Threat Actors wollen eventuell all das tun, auch wenn historisch gesehen Geld der bei Weitem größte Motivator ist. Zudem sind manche Threat Actors einfach durch die Herausforderung motiviert, einzubrechen oder ihre Reputation in Hacker-Kreisen zu verbessern.
  4. A. Abhängig vom Service-Delivery-Modell können Netzwerksicherheit und Betriebssystemsicherheit in der Verantwortung des Cloud-Providers liegen – müssen es aber nicht. Die Sicherheit des Datenzugriffs – wer Zugriff erhält – liegt so gut wie immer in der Verantwortung des Kunden.
  5. A und B. Die meisten Risk Assessment Systems ermitteln auf verschiedene Weise Wahrscheinlichkeit und Auswirkungen, um das Gesamtrisiko zu berechnen. Das Übertragen eines Risikos bestimmt nicht dessen Schweregrad, kann aber eine Möglichkeit sein, mit dem Risiko umzugehen. Ihre Risikoschwere wird auch nicht direkt davon beeinflusst, ob die Aktivitäten der angreifenden Person legal sind oder nicht, wenngleich illegale Aktivitäten die Gefahr einer Gefängnisstrafe für den Angreifer erhöhen.

Kapitel 2

  1. A. Sie brauchen vielleicht mehr als drei Klassifikationsstufen, aber 30 sind für so gut wie alle Organisationen deutlich zu viel, und 300 steht da nur, um zu prüfen, ob Sie die Frage überhaupt gelesen haben, bevor Sie eine Antwort auswählen.
  2. A, B, C und D. Die IP-Adressen selbst sind zwar öffentliche Informationen, aber verknüpft mit Kunden-Requests an Ihre Systeme, werden sie in vielen Rechtskreisen als persönliche Informationen angesehen und müssen dementsprechend geschützt werden.
  3. A, B und C. Daten können zwar kryptografisch gelöscht werden, um sie unlesbar zu machen, dazu gehört aber nicht das Verschlüsseln von Daten beim Löschen. Beim kryptografischen Löschen werden die kryptografischen Schlüssel gelöscht, sodass die schon verschlüsselten Daten nicht mehr länger entschlüsselt werden können.
  4. C. Hardware Security Modules haben den Vorteil, dass sie physisch manipulationssicher sind, was für manche Bereiche oder Compliance-Vorgaben mit hohen Sicherheitsanforderungen erforderlich sein kann, aber Sie können auch ohne sie ein ordentliches Schlüsselmanagement umsetzen. Das Speichern verschlüsselter (oder »verpackter«) Schlüssel zusammen mit den Daten ist übliche und akzeptable Praxis, solange der Key Encryption Key (KEK) woanders abgelegt ist, aber das Speichern ungeschützter Schlüssel zusammen mit den Daten ist nutzlos.
  5. C. Bei einem Angriff auf die Anwendung oder die Datenbank werden die Daten abgefragt, und der Festplattencontroller wird sie entschlüsseln und bereitstellen. Das ist für die normale Funktionalität der Systeme erforderlich.

Kapitel 3

  1. A und B. Viele Organisationen haben kein einzelnes Team, das für das Deployen von Cloud Assets zuständig ist, aber selbst wenn es solch ein einzelnes Team gäbe, wäre das Dokumentieren von Assets auch nicht fehleranfälliger. Cloud-APIs machen das Dokumentieren nicht schwerer – im Gegenteil: Sie ermöglichen Ihnen, das Dokumentieren von Cloud Assets zu vereinfachen.
  2. A, B und C. Das Verschlüsseln dient dem Schutz gespeicherter Daten, ihrer Übertragung auf dem Transportweg und beim Einsatz, aber es ist kein eigener Asset-Typ. Eine Key-Management-Instanz zum Verwalten von Schlüsseln für Ihre Daten kann aber ein Cloud Asset sein.
  3. Falsch. Container haben standardmäßig eine größere Angriffsoberfläche als virtuelle Maschinen und sollten nicht genutzt werden, um ohne weitere Schutzmaßnahmen nicht vertrauenswürdigen Code auszuführen, aber sie sind nicht inhärent unsicher.
  4. A, B und C. Es ist ein gutes Ziel, nur bekannte Risiken in akzeptabler Menge und Schwere zu haben, aber es ist kein Problem an sich.
  5. A, B, C und D. Das sind alles sinnvolle Tags für Assets. Sie können Ihnen dabei helfen, Assets zu dokumentieren und Sicherheitsrichtlinien zu erstellen.

Kapitel 4

  1. A, B, C und D. Alle sind übliche Aktivitäten im Lebenszyklus des Zugriffsmanagements.
  2. A. Durch Authentifikation, auf die eine Autorisierung folgt, können Sie auf eine Anwendung zugreifen, auch wenn manche Applikationen den Zugriff für alle authentifizierten User erlauben. API-Schlüssel sind keine Multifaktor-Authentifizierung, aber sie sind eine stärkere Einzel-Authentifizierungsmethode als einfache Passwörter und werden oft von Automationstools genutzt, die keine Multifaktor-Authentifizierung durchführen können. Die letzte Aussage ist ebenfalls falsch, weil auch für eine interne Kommunikation Authentifikation und Autorisierung erforderlich sind, wenn man den Zero-Trust-Prinzipien folgt.
  3. A, B und C. Alle drei Aussagen stimmen. Eine zentrale Autorisierung besitzt Vorteile und findet immer mehr Verbreitung, aber eine dezentrale Autorisierung kann weiterhin sehr effektiv sein.
  4. A, B und D. Cloud-IAM-Systeme besitzen oft Methoden zum Authentifizieren und Autorisieren von Usern und anderen Entitäten, aber im Allgemeinen werden andere Cloud-Services wie Secrets Management Services oder Encryption Key Management Services zum Speichern von Secrets und Schlüsseln genutzt.
  5. B und C. A ist falsch, weil es sich bei Federation um das Konzept und bei Single Sign-On um eine Technologie handelt, die es Usern erlaubt, Federated Identities zu verwenden. D ist falsch, weil Single Sign-On im Allgemeinen sicherer ist, da weniger Anwendungen das Passwort des Users sehen.

Kapitel 5

  1. B, C und D. Physische Sicherheitsmaßnahmen sind zwar sehr wichtig, aber sie liegen so gut wie immer in der Verantwortung des IaaS-Cloud-Providers und sind kein signifikanter Faktor bei bekannten Einbrüchen. Beim Einsatz von IaaS-Services sind Sie für alles andere selbst zuständig.
  2. A und B. Dynamic Application Scanner und Static Application Scanner sind nützlich, um Sicherheitsprobleme in von Ihnen gewartetem Code zu finden, aber sie werden keine fehlenden Betriebssystempatches finden.
  3. C und D. Agentenlose Scanner und Configuration Management Tools konzentrieren sich im Allgemeinen auf das Betriebssystem und die Middleware, aber nicht auf die Anwendungsschicht. Containerscanner finden typischerweise angreifbare Konfigurationen und fehlende Patches in Container-Images oder in laufenden Containern, aber meist keine Probleme auf Anwendungsebene, sofern sie nicht mit einer anderen Art von Tool kombiniert werden.
  4. Falsch. Ein Network Vulnerability Scan wird im Allgemeinen nur Probleme beim Betriebssystem oder in der Middleware finden, aber keine Schwachstellen in der Anwendung, sofern das Tool nicht Möglichkeiten von Dynamic Application Scanner besitzt und Sie es so konfiguriert haben, dass die Webanwendung getestet wird.
  5. Falsch. Penetration Tester werden im Allgemeinen nur einen oder wenige Wege, aber nicht alle möglichen Wege in ein angreifbares System finden. Wenn der Umfang Ihres Pentests die ganze Anwendung ist und Sie nur kleinere Probleme aufgezeigt bekommen, können Sie recht zuversichtlich sein. Lässt der Pentest wichtige Teile der Umgebung aus oder werden größere Probleme gefunden, müssen Sie nach dem Beheben dieser Probleme in einem größeren Umfang erneut testen.
  6. Falsch. Nachdem Sie sich die Wahrscheinlichkeit und die Auswirkungen des Ausnutzens einer Schwachstelle angeschaut haben, können Sie sich dazu entscheiden, das Risiko zu akzeptieren – entweder so, wie es ist, oder nach dem Aufsetzen zusätzlicher Sicherheitsmaßnahmen oder Wege zum Abmildern des Problems. Es ist wichtig, insgesamt nicht zu viele Risiken zu akzeptieren (wenn Sie 100 Risiken mit jeweils einprozentiger Wahrscheinlichkeit haben, wird eines von denen wahrscheinlich eintreten), aber Sie müssen im Allgemeinen eine gewisse Menge in Kauf nehmen, damit Ihre Umgebung auch genutzt werden kann.

Kapitel 6

  1. A, B und C. Ein paar wenige Cloud-Provider erlauben Ihnen zwar, physische Netzwerk-Appliances zu mieten, aber bei den meisten müssen Sie auf Sicherheitsgruppen und Network Access Control Lists sowie gelegentlich auf Virtual-Firewall-Appliances setzen.
  2. A. In den meisten Fällen besitzen VPC-Angebote keinen dedizierten Storage, auch wenn Sie typischerweise durch Verschlüsselung isoliert sind. VPCs bieten meist auch keine dedizierten CPUs oder Bare-Metal-Systeme, wenngleich das in vielen Fällen eine zusätzlich bestellbare Option ist. Der Einsatz von VPCs beeinflusst keine kryptografischen Schlüssel.
  3. A, B und C. Eine Firewall wird Netzwerkverbindungen blockieren, TLS hingegen nicht.
  4. Falsch. Auch wenn ein Perimeter nicht immer möglich sein wird und eventuell mehr Zugriff als bei klassischen Umgebungen erforderlich ist, können viele Anwendungen trotzdem davon profitieren, solange es sich bei ihm nicht um die einzige Verteidigungslinie handelt.
  5. A, B und D. Sicherheitsgruppen sind ebenfalls nützlich, aber sie sind wie »Host-Firewalls« und agieren unabhängig vom Erstellen von Subnets.
  6. Falsch. Anti-DDoS-Appliances können Denial-of-Service-Angriffe zwar abmildern, wenn dabei Traffic geschickt wird, der sich nur schwer bedienen lässt, aber eine einzelne Appliance (oder deren Netzwerkverbindung) wird im Allgemeinen durch einen großvolumigen Angriff überlastet werden.
  7. A, B und D. Egress-Filter sind im Allgemeinen nicht sehr effektiv, wenn sie IP-basierte Schutzvorkehrungen nutzen, weil Sie normalerweise die gleichen Ports öffnen müssen (wie zum Beispiel tcp/443), die auch bei Angriffen oder durch Malware genutzt werden. Zudem ist Egress-Filtering weder in klassischen noch in Cloud-Umgebungen eine einfach zu implementierende Schutzmaßnahme, weil Sie oft keinen guten Überblick über alle ausgehenden Verbindungen haben, die Ihre Anwendung und deren Abhängigkeiten durchführen müssen.

Kapitel 7

  1. A und B. Metriken beziehen sich auf jegliches Zählen von Aktivität über die Zeit, wie zum Beispiel auf Web-Requests. Zudem müssen die meisten Logs keine kritischen oder persönlich zuzuordnenden Informationen enthalten, auch wenn sich das in einigen wenigen Situationen nicht verhindern lässt.
  2. A, B, C und D. Alles sind gute Quellen für sicherheitsrelevante Logs und Metriken.
  3. Falsch. Sie können ein kombiniertes Tool zum Aggregieren und Analysieren von Logs nutzen, oder Sie entscheiden sich dazu, die Logs mit einem Tool zu aggregieren und die sicherheitsrelevanten Logs zur Analyse an ein anderes Tool zu übermitteln. Beide Funktionen sind sehr wichtig, müssen aber nicht mit dem gleichen Tool ausgeführt werden.
  4. A, B und C. Aktuell gibt es neben dem erneuten Aufsetzen keine zuverlässige Möglichkeit, betroffene Systeme automatisch zu säubern.
  5. A, B und C. Angreifer sind oft recht unüberlegt und probieren alle diese Dinge aus.
  6. B und C. Antivirensoftware und andere Tools können im Allgemeinen nicht jegliche persistente Malware mit großer Sicherheit von einem System entfernen, daher ist das erneute Aufsetzen von Systemen, die durch Angreifer kontrolliert werden, die weitaus sicherere Vorgehensweise.