39681353
| Pregunta | Respuesta |
| Automotive Cybersecurity | IT-Sicherheit wird immer relevanter für die Automobilindustrie Risiken und möglicher Schaden sollte nicht unterschätzt werden Investieren in Sicherheit der Systeme ist für Sicherheit von Personen und Vermeidung von finanziellen Verlusten notwendig |
| Security by Design | Sicherheit von Beginn der Entwicklung von Systemen/SW bis zu deren Außerbetriebnahme |
| SPICE (Software Process Improvement and Capability Determination) | |
| Hacking | unauthorisierten Zugang zu einem Computersystem erhalten, um die Funktionsweise des Systems zu beeinflussen oder Informationen zu stehlen (Schnittstellen sind Eintrittspunkte für Attacken) Typen: White / Gray / Black Hats |
| CIA - Security goals (Sicherheitsziele) | |
| Security Definitions | |
| Risikobasierter Ansatz (risk-based approach) | keine 100% Sicherheitsgarantie um SW zu schützen müssen Risiken (finanzieller, physischer Schaden, Rufschädigung, Systemmanipulation) minimiert werden |
| Risikomanagement (risk management) | |
| 10 Attackentypen | 1. Brute-Force 2. Phishing 3. Diebstahl von Zugansdaten/Identität 4. MITM (Abhören) 5. ransom-, mal-, spyware 6. Zero Day, APT attacks 7. SQL injection, XSS 8. malicious insiders 9. social engineering 10. (D)DoS |
| Angriffsmöglichkeiten | werden steigen, da es immer mehr Angriffsflächen gibt => IT-Sicherheit in allen Phasen der SW relevant |
| Sicherheit ist ein Anliegen, kein Feature | Sicherheitsmaßnahmen müssen sich nach Sicherheitsbedenken richten |
| secure design principles | 1. Defense-in-depth 2. Principle of Least Privilege 3. Shared responsibility 4. Secure defaults 5. Fail securely 6. Separation of duties 7. Keep it simple 8. Trust but Verify 9. Zero Trust 10. Privacy by Design |
| Defense-in-depth | mehrere, geschichtete Sicherheitsmaßnahmen um Daten zu schützen |
| Principle of Least Privilege | Mindestmaß an Befugnissen - nicht mehr als für eigene Aufgabe benötigt wird dadurch geringere Angriffsfläche |
| Shared responsibility | SW wird nicht alleine entwickelt, sondern mit anderen Anbietern gemeinsam service-level agreement (SLA) definiert jeweilige Verantwortungen der Vertragsparteien |
| Secure Defaults | default-Einstellungen sollten immer auf max. Sicherheit ausgelegt sein dabei ist es wichtig die Balance zwischen Sicherheit und Benutzerfreundlichkeit zu finden |
| Fail Securely | bei einem Absturz sollte das System in einen sicheren Zustand wechseln (Vermeidung von Datenverlusten oder Sicherheitsrisiken) Backups & Shutdowns sollten eingerichtet und getestet sein um bei einem Systemausfall Datenverlust auf einem Minimum zu halten |
| Separation of Duties | ein sensibler Prozess sollte nicht in der Verantwortung einer einzigen Instanz liegen Risikominderung für unautorisierten Zugriff Verringert zwar die Prozesseffizienz, aber erhöht die Systemsicherheit |
| Keep it Simple | bekannte Sicherheitsmaßnahmen oft besser, da leichter zu verstehen sind und somit auch effektiver dadurch auch geringere Fehleranfälligkeit |
| Trust but Verify | Benutzern wird nach ihrer Authentifizierung vertraut und nur deren berechtigte Handlungen werden überprüft |
| Zero Trust | Zero Trust sagt, niemandem zu vertrauen, sowohl im Inneren als auch außerhalb des Netzwerks. Nutze Sichtbarkeit, Analytik und Automatisierung, um die Richtlinien im Auge zu behalten |
| Privacy by Design | Privatsphäre der Benutzer während des gesamten Designprozess gewährleisten |
| Privacy by Design - 7 fundamentale Prinzipien | |
| Security by Design - 3 wichtige nicht-technische Aspekte | |
| Standards vs Regulations vs Laws | Standards: nicht verpflichtend Ziel: Qualität & Effizienz Regulations: verpflichtend Instruktionen, wie man etwas richtig macht Laws: verpflichtend herausgegeben von Regierungen, Ländern, Staaten, Städten müssen befolgt werden, sonst strafbar |
| Information Gathering | regelmäßige Recherche ist wichtig um Wissen zu erweitern und auf dem neusten Stand zu bleiben Ressourcen: öffentliche Websites, Konferenzen, Projekte |
| Security - Forms of further training | |
| Weitere Sicherheitsziele | Authentizität Nicht-Abstreitbarkeit Privatsphäre Authorisierung Vertrauenswürdigkeit |
| Kryptographische Hashfunktionen | one-way, umgekehrte Hash-Funktion gibt es nicht rein kommen Daten, raus hex-codierte Bytes fester Länge kann benutzt werden um Downloads zu verifizieren (falls man Vergleichswert traut) |
| Pre-Image Resistance (Einwegfunktion) | zu gegebenen Hash-Wert y ist Urbild x mit h(x) = y nur mit unvertretbar hohem Aufwand zu berechnen Nutzung: Passwortspeicherung das Urbild sollte hierbei weder zu kurz noch vorhersagbar sein |
| Second pre-Image resistance | zu gegebenem Urbild x darf mit vertretbarem Aufwand kein von x verschiedenes Urbild x‘ zu finden sein mit h(x) = h(x‘) |
| Collision resistance (starke Kollisionsresistenz) | es ist nur mit unvertretbar hohem Aufwand möglich, zwei verschiedene Urbilder x und x‘ zu finden, mit h(x) = h(x‘) Im Unterschied zur schwachen Kollisionsresistenz dürfen hier die beiden Werte x und x‘ frei gewählt werden |
| Random Oracle Model | Der direkte Nachweis der Sicherheit eines Protokolls kann aufgrund der Kollisionsresistenzeigenschaften eine Herausforderung sein zufälliger, nicht vorhersagbarer Output gleicher Input => gleicher Output |
| Birthday Paradox | bereits bei einer Anzahl von 23 Personen gibt es eine 50%ige Chance, dass zwei am gleichen Tag Geburtstag feiern |
| Size of the Digest | die einfachste Attacke sind gegen collision resistance => zufällige Eingaben kollidieren bereits mit einer Wahrscheinlichkeit von 50% nach der Hälfte um ein Sicherheitslevel von 128 Bits zu bekommen müssen die Eingaben 256 Bits groß sein |
| Kryptographische Hash-Funktionen - SHA-2 | 4 verschiedene Versionen mit Output-Längen von 224, 256, 384 & 512 Bits |
| Kryptographische Hash-Funktionen - SHA-3 | 4 verschiedene Versionen mit Output-Längen von 224, 256, 384 & 512 Bits |
| Kryptographische Hash-Funktionen - SHAKE & cSHAKE | Output beliebiger Länge cSHAKE: Individualisierung der Hash-Funktion |
| golden crypto rule | gleiche kryptographische Grundelemente sollten mit gleichem Schlüssel nicht in verschiedenen Anwendungsfällen zum Einsatz kommen |
| Kryptographische Hash-Funktionen - Zusammenfassung | |
| Authentication-Types | Things you know Things you own Things you are Location |
| Encryption | |
| Bouncy Castle | Registrierung kryptographisches Hashing AES (advances encryption standard) Schlüsselgenerierung & Verwaltung Asymmetrische Verschlüsselung Signaturen |
¿Quieres crear tus propias Fichas gratiscon GoConqr? Más información.