Lernkontrollfragen

Rolle des Security Champions: Er fungiert als Sicherheitsexperte innerhalb des Teams, der als Multiplikator für Sicherheitswissen dient und die Brücke zwischen dem Team und der Sicherheitsabteilung schlägt. Er ist ein Sparringspartner für das Team, der Argumente für Sicherheitsmaßnahmen liefert und selbst Teil des Entwicklungsteams bleibt.

Wichtigkeit von Security: Unternehmen sind zunehmend durch Gesetze (z. B. NIS 2, Cyber Resilience Act) und Standards verpflichtet, ihre Produkte zu schützen. Zudem nehmen die Häufigkeit von Angriffen und die Fähigkeiten der Angreifer stetig zu.

Anzahl der Vulnerability steigt immer

Konsequenzen bei Missachtung: Es können finanzielle Schäden bis hin zur Insolvenz, rechtliche Konsequenzen (Gefängnisstrafen), Reputationsschäden sowie Schäden für Kunden und Dritte entstehen.

Unzulänglichkeit von Penetrationstests: Tests können nur die Existenz von Fehlern aufzeigen, nicht deren Abwesenheit. Viele Sicherheitsprobleme liegen „unter der Haube“ (Designfehler) und sind von außen durch reine Tests schwer zu finden.

Tests beweisen keine Fehlerfreiheit: Ein Penetrationstest findet zwar Schwachstellen, aber wenn er nichts findet, bedeutet das nicht, dass das System sicher ist. Er kann nur die Existenz von Fehlern aufzeigen, niemals deren Abwesenheit

Probleme „unter der Haube“: Penetrationstests betrachten das System meist von außen (Black Box). Viele kritische Probleme sind jedoch Designfehler, die tief in der Architektur vergraben liegen und von außen kaum sichtbar sind

Später Zeitpunkt: Penetrationstests finden meist erst am Ende des Entwicklungszyklus statt. Sicherheit sollte jedoch von Anfang an („Security by Design“) in jede Phase einfließen, von der Planung bis zum Betrieb

Die 50%-Regel: Schätzungen zeigen, dass Designfehler für etwa 50 % aller Sicherheitsprobleme verantwortlich sind. Solche Mängel lassen sich oft nicht durch reines Testen des fertigen Codes finden, sondern erfordern ein tieferes Verständnis des Systementwurfs

Stell dir das wie bei einem Haus vor: Ein Tester kann prüfen, ob die Tür verschlossen ist, aber er sieht von außen nicht, ob das Fundament morsch ist.

Verhältnis der Begriffe: Ein Adversary (Angreifer) führt einen Attack/Exploit über einen Attack Vector aus, um eine Vulnerability (Schwachstelle) eines Assets (Wertes) auszunutzen, was eine Threat (Bedrohung) darstellt. Countermeasures (Gegenmaßnahmen) dienen dazu, die Wahrscheinlichkeit oder Auswirkung dieser Bedrohung zu minimieren.

CIA-Triade: Dies steht für die drei Schutzziele der Informationssicherheit: Confidentiality (Vertraulichkeit – Schutz vor unbefugter Preisgabe), Integrity (Integrität – Schutz vor unbefugter Änderung) und Availability (Verfügbarkeit – Gewährleistung der Nutzung bei Bedarf).

AAA-Prinzip: Es umfasst Authentication (Authentifizierung – Identität prüfen), Authorization (Autorisierung – Rechte prüfen) und Accountability (Zurechenbarkeit – Nachvollziehbarkeit von Aktionen).

Zeitpunkte im Entwicklungsprozess: Sicherheit muss über den gesamten Lebenszyklus („Security by Design“) betrachtet werden: von der Planung und Anforderungsanalyse über Design und Implementierung bis hin zu Deployment, Betrieb und Wartung.

Typen von Hackern: Black Hats agieren mit böswilliger/illegaler Absicht für persönlichen Gewinn. White Hats sind ethische Hacker, die legal im Auftrag handeln. Grey Hats testen Systeme oft ohne Zustimmung, informieren aber danach die Besitzer; ihr Handeln ist dennoch illegal.

Ziele von Angreifern: Finanzieller Profit, Sabotage oder Verursachung von Schaden, Diebstahl geheimer Informationen oder schlicht die Herausforderung („das Spiel“).

Evil User Stories: Sie beschreiben Angriffe aus der Sicht eines Angreifers im Format einer User Story („Als Angreifer möchte ich..., um...“). Sie helfen dabei, die Angreiferperspektive bereits bei der Planung von Anforderungen einzunehmen.

Risikoanalyse: Sie ist notwendig, um die erwartete Eintrittswahrscheinlichkeit und die Konsequenzen von Angriffen auf Assets zu bewerten.

Schritte nach BSI 200-3: 1. Gefährdungen identifizieren (Elementar- und Zusatzgefährdungen), 2. Risiken klassifizieren (bewerten und einschätzen), 3. Risiken behandeln.

Schadensausmaß und Eintrittshäufigkeit: Das Schadensausmaß (Impact) beschreibt die negativen Folgen eines Vorfalls (finanziell, Reputation). Die Eintrittshäufigkeit bewertet, wie oft ein Angriff wahrscheinlich erfolgreich ist, basierend auf den Fähigkeiten des Angreifers und der Attraktivität des Assets. Beide Werte zusammen ergeben das Gesamtrisiko.

Threat Modeling: Eine Methode zur systematischen Identifikation von Bedrohungen durch die Analyse von Systemdarstellungen (z. B. Datenflussdiagramme). Es dient dazu, frühzeitig Designfehler zu finden.

STRIDE:

    ◦ Spoofing: Vortäuschen einer fremden Identität.

    ◦ Tampering: Unbefugtes Manipulieren von Daten.

    ◦ Repudiation: Abstreiten einer durchgeführten Aktion.

    ◦ Information Disclosure: Unbefugte Offenlegung von Informationen.

    ◦ Denial of Service: Dienstverweigerung durch Überlastung des Systems.

    ◦ Elevation of Privilege: Unbefugtes Ausweiten von Berechtigungen.

Risiken können durch:

• Vermeidung (Funktion entfernen),

• Reduktion (Maßnahmen ergreifen),

• Teilung/Transfer (z. B. Versicherung) oder

• Akzeptanz (bewusstes Inkaufnehmen) behandelt werden.

Protection Poker: Vorteile sind die Zugänglichkeit der Risikoanalyse für das Team und die Förderung gemeinsamer Diskussionen über Bedrohungen. Ein wesentliches Merkmal ist, dass sowohl das Schadensausmaß als auch die Eintrittshäufigkeit getrennt bewertet werden.

Secure design principles provide guidance!

Secure Design Prinzipien sind bewährte Methoden und Strategien, die einen Prozess unterstützen, bei dem Sicherheit in jeder einzelnen Designentscheidung berücksichtigt wird. Das Ziel ist es, die Möglichkeiten zur Ausnutzung des Systems zu reduzieren und die Auswirkungen eines erfolgreichen Angriffs zu minimieren.

Least Privilege: Jeder Benutzer oder jedes Modul erhält nur die minimal notwendigen Berechtigungen.

    ◦ Defense in Depth: Man verlässt sich nicht auf eine einzelne Sicherheitsmaßnahme, sondern implementiert mehrere Ebenen (ähnlich einer mittelalterlichen Burg).

    ◦ Fail Securely: Bei einem Systemfehler (z. B. Exceptions) muss das System in einen sicheren Zustand übergehen, ohne Informationen preiszugeben.

    ◦ No Security by Obscurity: Die Sicherheit darf nicht von der Geheimhaltung des Designs abhängen; das System sollte auch dann sicher sein, wenn ein Angreifer das Design vollständig kennt.

    ◦ Detect and Record: Ungewöhnliche Ereignisse müssen erkannt und protokolliert werden, um Angriffe bemerken und im Nachhinein analysieren zu können.

    ◦ Don’t Trust / Keep it Simple: Gehe davon aus, dass alles und jeder dem System schaden will (Eingaben validieren) und halte das System so einfach wie möglich, da Komplexität das Verständnis und damit die Sicherheit erschwert

Diese Aussage ist falsch. Ein offenes Design (Open Design) ist vorzuziehen, da Geheimhaltung oft scheitert (z. B. durch Insider oder Raten). Sicherheit sollte auf dem Schutz der Schlüssel basieren, nicht auf der Verheimlichung der Algorithmen (Kerckhoffs’ Prinzip)

Das System wird in separate Prozesse (nicht Threads, da diese Speicher teilen) mit jeweils eigenen, minimalen Berechtigungen zerlegt. Implementiert werden dabei die Prinzipien Least Privilege, Defense in Depth und Don’t Trust. Die Prozesse kommunizieren über Interprozesskommunikation (IPC) wie Files, Sockets oder REST-APIs und misstrauen einander grundsätzlich.

Es bedeutet vorausschauendes Programmieren unter der Annahme, dass Aufrufer einer Methode das System angreifen wollen. Es setzt das sichere Design und die Risikoanalyse auf Code-Ebene um, indem es interne Schwachstellen vermeidet und Code als das oft „schwächste Glied“ absichert.

Know your APIs: Nutze Bibliotheken nur in ihrem korrekten Kontext und verstehe sie vollständig, bevor du sie einsetzt (z. B. XML-Parser-Konfiguration).

Minimize Attack Surface: Füge keine Eingabefelder oder Funktionen hinzu, die nicht zwingend erforderlich sind, um die Angriffsfläche klein zu halten.

Diese Strategien helfen dir, Code von Anfang an robuster gegen Angriffe zu machen:

Know your APIs: Du solltest APIs und Bibliotheken nur in ihrem vorgesehenen Kontext nutzen und ihre Dokumentation genau kennen, da du nichts absichern kannst, was du nicht verstehst

Attack Surface (Angriffsfläche minimieren): Reduziere die Anzahl der Eingabepunkte (Formularfelder, Uploads etc.) auf das absolute Minimum, um Angreifern weniger Gelegenheiten zu bieten

Complexity (Komplexität reduzieren): Da Komplexität der Feind der Sicherheit ist, solltest du strukturelle und kognitive Komplexität aktiv verringern, um Fehlerquellen zu vermeiden

Input Validation (Eingabevalidierung): Schreibe niemals eigene Sanitzer oder Validierer, sondern nutze spezialisierte Bibliotheken, um jeden potenziellen Einstiegspunkt zu prüfen

Character Conversion: Verwende durchgehend standardisierte Kodierungen wie UTF-8 oder UTF-16 und führe keine Normalisierungen nach einer Validierung durch

Concurrency Awareness: Behandle parallele Prozesse mit Misstrauen, um Race Conditions (DoS) oder den Zugriff auf gemeinsam genutzten Speicher (Information Disclosure) zu verhindern

Unencrypted Storage: Alle Daten, die auf Festplatten geschrieben werden, sollten verschlüsselt und authentifiziert werden, da Root-Exploits sonst Zugriff auf den gesamten Speicher gewähren

Immutability (Unveränderlichkeit): Nutze unveränderliche Attribute und Schlüsselwörter wie final (in Java), damit bösartige Unterklassen keine sensiblen Methoden überschreiben können

Config & Install: Überprüfe Konfigurationsdateien (z. B. auf zu kleine Log-Größen oder hartkodierte Credentials) und vermeide veraltete Abhängigkeiten bei der Installation

HTTP-GET: Verwende HTTP-Methoden nur für ihren vorgesehenen Zweck (z. B. GET nur zum Abrufen, nicht zum Senden sensibler Daten)

SQL-Injection: Angreifer schleusen bösartigen Code über Eingabefelder ein, um Datenbankabfragen zu manipulieren.

Hardcoded Credentials: Passwörter oder Schlüssel werden direkt im Quelltext gespeichert, was sie für jeden auslesbar macht, der Zugriff auf die Binärdatei oder den Code hat

Diese Fehler treten in der Praxis immer wieder auf und sollten gezielt vermieden werden:

Hardcoded Credentials: Passwörter oder Schlüssel werden direkt im Quellcode gespeichert und sind so in Binärdateien auslesbar

Hashing without Salt: Das Speichern von Hashes ohne Salt macht Passwörter anfällig für Wörterbuch- oder Brute-Force-Angriffe

Integer Overflow: Fehlende Plausibilitätsprüfungen bei Zahlenwerten können dazu führen, dass Werte „umkippen“ (z. B. negative Kontostände)

Buffer Overflow: Wenn ohne Bereichsprüfung über Puffergrenzen hinaus geschrieben wird, kann dies das Programm korrumpieren

Format String Corruption: Benutzereingaben werden direkt als Format-String (z. B. in printf) verwendet, was Speicherzugriffe ermöglicht

Log Neutralization: Fehlende Bereinigung von Eingaben vor dem Loggen erlaubt es Angreifern, Log-Einträge zu fälschen

Log Overflow: Ein Angreifer flutet das System mit Log-Daten, um Beweise zu überschreiben oder einen Absturz zu provozieren

Open Redirect: Nutzer werden über URL-Parameter unkontrolliert auf externe Phishing-Seiten weitergeleitet

Path Traversal: Durch Sequenzen wie ../ greifen Angreifer auf Dateien außerhalb des vorgesehenen Verzeichnisses zu

Insecure PRNGs: Die Nutzung nicht-kryptographischer Zufallszahlengeneratoren für Sicherheitszwecke macht kryptographische Werte vorhersagbar

Reflection Abuse: Über die Java-Reflection-API können private oder finale Variablen unbefugt geändert werden

SQL Injection: Schadcode in Eingabefeldern manipuliert Datenbankabfragen

XML Embedded DTD (XXE): Durch Dokumenttyp-Definitionen können lokale Dateien referenziert oder das System angegriffen werden

NoSQL Injection: Ähnlich wie bei SQL werden hier NoSQL-Abfragen (z. B. MongoDB) durch präparierte Eingaben manipuliert

Cross-Site Scripting (XSS): Bösartige Skripte werden in Webseiten eingeschleust und im Browser anderer Nutzer ausgeführt

Komplexität erschwert das Verständnis des Systems. Was man nicht versteht, kann man nicht effektiv absichern. Fehler in komplexem Code oder komplexen Architekturen führen unweigerlich zu Sicherheitslücken.

Jede Eingabe ist ein potenzieller Einstiegspunkt für Angreifer. Die Validierung stellt sicher, dass nur korrekt formatierte Daten verarbeitet werden. Man sollte niemals eigene Validierer schreiben, sondern etablierte Bibliotheken nutzen.

◦ Vertraulichkeit (Confidentiality): Nur beabsichtigte Parteien können den Inhalt lesen.

◦ Integrität (Integrity): Jede Modifikation des Inhalts wird erkannt.

◦ Authentizität (Authenticity): Die Urheberschaft einer Nachricht kann verifiziert werden.

◦ Verbindlichkeit (Accountability): Der Autor kann seine Urheberschaft im Nachhinein nicht leugnen.

Ein kryptographisches System muss auch dann sicher sein, wenn alle Details (außer den Schlüsseln) öffentlich bekannt sind. Es ist nützlich, weil es Peer-Reviews der Algorithmen ermöglicht und "Security by Obscurity" vermeidet.

CSPRNG steht für Cryptographically Secure Pseudo Random Number Generator. Für Sicherheitszwecke (wie Schlüsselgenerierung) muss immer ein CSPRNG verwendet werden, da dieser Hardware-Entropie (z. B. thermisches Rauschen) nutzt, um Vorhersagbarkeit zu verhindern. In Java ist dies beispielsweise java.security.SecureRandom, während das einfache java.util.Random nicht sicher ist

CTR (Counter Mode): Dieser Modus verwandelt eine Blockchiffre in eine Stromchiffre, indem ein Zähler verschlüsselt und mit dem Klartext XOR-verknüpft wird. Er ermöglicht es, Datenzeichen sofort zu verarbeiten

GCM (Galois/Counter Mode): GCM wird als gängiges Beispiel für einen modernen, strombasierte Verschlüsselungsmodus aufgeführt, der oft für AES verwendet wird. Er kombiniert Verschlüsselung mit Authentifizierung (AEAD)

Kryptographisch sichere Zufallswerte (CSPRNG) müssen so beschaffen sein, dass sie von echtem Zufall nicht unterscheidbar sind und Angreifer sie nicht mit vertretbarem Aufwand erraten können.

Sie verarbeiten Daten in Blöcken fester Größe (z. B. 128 Bit). Der Betriebsmodus (z. B. CTR, GCM) bestimmt, wie die Blöcke miteinander verknüpft werden.

Symmetrische Verfahren nutzen denselben geheimen Schlüssel für Ver- und Entschlüsselung.

Asymmetrische Verfahren (Public-Key) nutzen ein Schlüsselpaar: einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten zum Entschlüsseln.

Assymetric

Bei symmetrischen Verfahren müssen die Partner den Schlüssel vorab über einen sicheren Kanal austauschen.

Bei n Teilnehmern werden n(n−1)/2 Schlüssel benötigt, was die Skalierung erschwert.

Die eigentliche Nachricht wird effizient mit einem symmetrischen Schlüssel verschlüsselt. Dieser symmetrische Schlüssel wird dann asymmetrisch verschlüsselt und mit der Nachricht übertragen.

Hashing ist eine Einwegfunktion, die Daten beliebiger Größe in einen festen Hashwert umwandelt.

    ◦ Integrität: Änderungen am Original führen zu einem anderen Hashwert.

    ◦ Vertraulichkeit: Es ermöglicht den Beweis eines Geheimnisses (z. B. Passwort), ohne das Geheimnis selbst preiszugeben.

Der Absender berechnet eine Signatur basierend auf der Nachricht und seinem privaten Schlüssel. Jeder kann die Signatur mit dem öffentlichen Schlüssel des Absenders verifizieren, um Authentizität und Integrität sicherzustellen.

Penetrationstests: Sie bieten einen realistischen Black-Box-Angriff durch Experten. Nachteile sind die hohen Kosten und die seltene Durchführung (meist nur einmal jährlich).

Statische Analyse (SAST): Diese Methode ist hochgradig skalierbar und findet gängige Fehler wie SQL-Injection direkt im Quellcode. Ein Nachteil ist die hohe Rate an Falsch-Positiven und die Unfähigkeit, Laufzeitprobleme zu finden.

Manuelles Code-Review: Es ist sehr effektiv beim Finden von Logik- und Designfehlern, die Tools übersehen. Der größte Nachteil ist, dass es nicht automatisch abläuft und zeitintensiv ist.

Automatisierte Tests (wie Unit-Tests oder SAST) sind schnell, in die CI/CD-Pipeline integrierbar und skalierbar für den gesamten Code.

Sie finden jedoch keine komplexen semantischen Designfehler. Manuelle Reviews können genau diese Design- und Logikfehler identifizieren, sind aber subjektiv, langsamer und hängen stark von der Erfahrung des Reviewers ab.

Vorteile:

• Sie skaliert gut über große Codebasen,

• bietet präzises Feedback zur exakten Codezeile und

• findet viele Standard-Schwachstellen früh im Lebenszyklus.

Nachteile:

• Sie erzeugt oft viele Falsch-Positive,

• kann keine Konfigurationsfehler in der Umgebung erkennen und

• findet keine dynamischen Probleme wie fehlerhafte Authentifizierungsabläufe

Vorteile:

• Sie findet komplexe semantische Fehler (z. B. im Authentifizierungsfluss),

• berücksichtigt Fehlkonfigurationen der Umgebung und

• benötigt keinen Zugriff auf den Quellcode.

Nachteile:

• Sie erfordert eine voll funktionsfähige,

• laufende Anwendung, ist sehr ressourcenintensiv und

• deckt meist nur Web-Schnittstellen ab.

Sicherheitswerkzeuge sollten in der Pipeline genutzt werden, um sofortiges Feedback an Entwickler zu geben, die Kosten für Fehlerbehebungen durch Früherkennung zu minimieren und eine hohe Durchlaufrate bei gleichzeitig geprüfter Sicherheit zu garantieren

1. Sicherheitskritische Aktionen detailliert geloggt und für ausreichende Zeit gespeichert werden.

2. Die Log-Datenbank so konfiguriert werden, dass Löschen oder Ändern unmöglich ist (WORM-Prinzip).

3. Professionelle Log-Management-Lösungen zur automatischen Erkennung verdächtiger Aktivitäten eingesetzt werden.

1. Logs oft unzureichende Details enthalten.

2. Alarme nicht die richtigen Personen erreichen oder ignoriert werden.

3. Angreifer Beweise durch gezielte Log-Overflows löschen können.

4. Rice's Theorem besagt, dass das Verhalten von nicht-trivialem Code nicht sicher vorhergesagt werden kann.

5. Falsch-Negative in Tools dazu führen, dass Schwachstellen unentdeckt bleiben.

CVE ist ein System zur eindeutigen Identifizierung und Dokumentation konkret gefundener Schwachstellen in Softwareprodukten.

Ihr Zweck ist die Standardisierung, damit Teams die Kritikalität für ihre eigenen Produkte besser bewerten und priorisieren können.

CWE ist eine Liste von Schwachstellentypen (z. B. Pufferüberlauf oder SQL-Injection).

Sie hilft bei der Entwicklung sicherer Software, indem sie Entwicklern ermöglicht, aus Fehlern der Vergangenheit zu lernen und systematische Schwachstellenmuster im eigenen Code zu vermeiden.

Das Common Vulnerability Scoring System berechnet einen Score von 0.0 bis 10.0. Es besteht aus drei Teilen: dem Base Score (Angreifbarkeit und Auswirkung), dem Temporal Score (Verfügbarkeit von Exploits/Fixes) und dem Environmental Score (individuelle Kritikalität im eigenen Produkt).

Ein Product Security Incident Response Team verwaltet die Identifizierung, Bewertung, Behebung und Offenlegung von Sicherheitsvorfällen. Es dient als zentrale Kontaktstelle für interne und externe Meldungen und koordiniert die gesamte Kommunikation mit allen Beteiligten.

Zu den relevanten Stakeholdern gehören:

• das Top-Management,

• der Product Owner (PO),

• das Entwicklungsteam,

• die Sicherheitsabteilung (Security Department),

• die Rechtsabteilung (Legal Department) sowie

• externe Kunden und Softwarelieferanten.

1. Verständliche Sprache: Wähle eine einfache Sprache, die an den Wissensstand des Gegenübers angepasst ist. Beispiel: Erkläre einem Product Owner die Auswirkung einer Sicherheitslücke in geschäftlichen Begriffen (Risiko) statt in technischem Code.

2. Kurze Sätze: Nutze kurze Sätze statt langer Schachtelsätze und packe nicht zu viele Informationen in einen Satz. Beispiel: Präsentiere eine Bedrohung im Team-Meeting prägnant in zwei Sätzen.

3. Visualisierungen: Nutze Grafiken, da diese leichter zu verstehen sind als reiner Text. Beispiel: Zeige dem Team ein Datenflussdiagramm (DFD), um Vertrauensgrenzen zu veranschaulichen.

4. Konzentration auf den Partner: Schenke deinem Gegenüber volle Aufmerksamkeit und eliminiere Ablenkungen. Beispiel: Schalte bei einem Gespräch über die Sprint-Priorisierung dein Handy aus.

5. Fragen stellen: Nutze Fragen, um das Gegenüber zu aktivieren und sicherzustellen, dass Informationen korrekt angekommen sind. Beispiel: Frage nach einer Erklärung zu STRIDE: „Wie könnten wir Spoofing in dieser Funktion verhindern?“

Gutes Feedback zeichnet sich dadurch aus, dass es die Sache und nicht die Person bewertet, konkret beschrieben ist und zeitnah erfolgt.

Feedback-Geber: Sollten fragen, ob Feedback erwünscht ist, mit Positivem beginnen, Ich-Botschaften verwenden und vorerst keine fertigen Lösungen diktieren. Ein bewährtes Modell ist die Drei-Schritt-Methode: Verhaltensbeschreibung, Auswirkungen benennen und einen Wunsch/eine Bitte formulieren

Feedback-Nehmer: Sollten mit Dankbarkeit und Lernbereitschaft zuhören, sich nicht sofort rechtfertigen oder verteidigen und Verständnisfragen stellen. Am Ende entscheidet der Nehmer selbst, welche Punkte er annimmt.

Sachkonflikt: Entsteht durch unterschiedliches Vorwissen oder Erfahrungen. Beispiel: Ein Security Champion und ein erfahrener Entwickler sind uneinig darüber, ob eine bestimmte Bibliothek tatsächlich eine kritische Schwachstelle für ihr spezifisches Produkt darstellt.

Zielkonflikt: Resultiert aus unterschiedlichen Prioritäten oder gegensätzlichen Zielen. Beispiel: Der Product Owner will ein neues Feature so schnell wie möglich releasen, während der Security Champion darauf besteht, zuerst eine Risikoanalyse durchzuführen.

Rollenkonflikt: Tritt auf, wenn Erwartungen an eine Rolle nicht erfüllt werden. Beispiel: Das Team erwartet vom Security Champion, dass er alle Sicherheitslücken selbst fixiert, während dieser sich eher als Multiplikator sieht, der das Team befähigen möchte, selbst sicher zu programmieren.

Java: Hier sind SpotBugs und das spezialisierte Plugin FindSecBugs führend, um Fehler wie SQL-Injection oder unsichere Deserialisierung zu finden

Python: Häufig genutzt werden Bandit (speziell für Sicherheitsmuster), PyLint (für logische Fehler und Standards) sowie PyFlakes und MyPy

TypeScript: Hier ist ESLint das Standardwerkzeug zur Identifizierung von Fehlern

C: Entwickler nutzen Compiler-Warnungen (z. B. Clang mit -Wall und -Wextra) oder Werkzeuge wie clang-tidy zur Fehlererkennung

Allgemein: SonarLint und Checkstyle unterstützen bei der Einhaltung von Codierungsstandards und der Reduzierung von Komplexität

Diese Tools testen die laufende Anwendung („Black Box“), um Laufzeitfehler und semantische Probleme wie fehlerhafte Authentifizierungsabläufe zu finden.

DAST: Bekannte Beispiele sind der OWASP Attack Proxy (ZAP), die Burp Suite, Arachni oder Qualys.

IAST: Werkzeuge wie Contrast Security nutzen Instrumentierung innerhalb der laufenden Applikation, um Datenflüsse noch genauer zu überwachen.

Goal: Protecting the information assets of an organization

• What are we working on?

• What can go wrong?

• What are we going to do about it?

• Did we do a good job?

• Identity theft

• Malware

• Denial of Service

• Sabotage

• Social Engineering

• Loss of integrity of sensitive information

Secure Design Principles sind allgemeine, bewährte Strategien und Leitlinien, die bei jeder Entwurfsentscheidung als übergreifende Ziele dienen. Beispiele hierfür sind „Least Privilege“ oder „Defense in Depth“.

Secure Patterns hingegen sind spezifische Architekturvorlagen oder konkrete Gegenmaßnahmen, um Sicherheitsziele wie Authentifizierung oder Datenflusskontrolle praktisch umzusetzen. Während Prinzipien also die theoretische Richtung vorgeben (das „Wie“ im Sinne einer Strategie), stellen Patterns die strukturelle Lösung für ein konkretes Problem bereit (das „Was“ im Sinne einer Architektur)

setuid (Set User ID) und setgid (Set Group ID) sind Mechanismen, die festlegen, mit welchen Berechtigungen ein Programm während seiner Ausführung läuft

Decompose the system into separate processes with separate permissions

• i.e., fork(), but NOT threads. Why?

• Threads still have shared memory!

Communicate via inter-process communication (IPC)

Processes distrust each other

• i.e., validate input from other processes

• i.e., recheck credentials and integrity mechanisms

Simplify the root-level subsystems to an extreme extent

• Files

• Streams / Named Pipes: Define a “virtual file” that one process writes to and another process reads from

• REST: Usually relays on HTTP, JSON and other common protocols / HTTP methods POST, GET, … are often used in restful APIs / Is an architectural style not a protocol itself (unlike SOAP)

• Socket: Write to a traditional networked socket via the OS network interface

• Signals: Simple messaging, sometimes data can be appended (e.g., Android) / Pre-defined by the OS (Unix has ~30 signals)

• Clipbord: Can set and get clipboard programmatically

forward-thinking, look ahead, always think about possible attacks

Assume that callers of your method want to attack your system!