-
Kartei Details
| Karten | 15 |
|---|---|
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 29.07.2020 / 26.08.2020 |
| Weblink |
https://card2brain.ch/box/20200729_infsi_15_punkte
|
| Einbinden |
<iframe src="https://card2brain.ch/box/20200729_infsi_15_punkte/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
1 - Establish Security Requirements
Definition von Sicherheitsanforderungen an das Projekt.
- verhindert unnötige Verzögerungen
- Sicherheit kann frühzeitig integriert werden
2 - Quality Gates/Bug Bars
Bestimmt die minimalen Akzeptanzkriterien im Bereich Sicherheit & Datenschutz an das Projekt.
- Quality Gates: Anforderungen an Codequalität
- Bug Bars: Schwelle für Sicherheitslücken (z.b. keine "Kritisch", oder "Warnung")
3 - Security and Privacy Risk Assessment
Es werden diejenigen funktionalen Aspekte der Software identifiziert, die ein
vertieftes Review benötigen.
Privacy Impact Rating festlegen.
4 - Establish Design Requirements
Designspezifikationen und Implementation von Sicherheitsfunktionen festlegen.
(z.B. Login)
5 - Analyze Attack Surface
Mögliche Angriffszenarien suchen/ definieren.
Stark verbunden mit Thread Modeling.
6 - Thread Modeling
Mögliche Bedrohungen dokumentieren und diskutieren.
7 - Use Approved Tools
Teamweite Tools definieren, welche zur Qualität und Sicherheit des Codes beitragen.
8 - Deprecate Unsafe Functions
Im Team festlegen welche Funktionen und APIs nicht verwendet werden sollen.
9 - Static Analysis
Code soll automatisch mit einem Tool geprüft werden.
Sicherstellen der Coding Policies.
Soll Bugs eliminieren.
10 - Dynamic Analysis
Verifikation während der Laufzeit.
Tools definieren, welche Fehlverhalten protokolliert.
11 - Fuzz Testing
Dynamische Analyse um Programm durch diverse Inputs auf Fehler hin zu überprüfen.
(Schwachstelle finden, die ausgenutzt werden kann)
13 - Incident Response Plan
Vor dem Release festlegen, welches Team bei einem Security Notfall kontaktiert werden muss.
Eine Ansprechsperson muss 24/7 verfügbar sein.
12 - Attack Surface Review ( & Thread Model)
Abweichungen der Anwendung zur ursprünglich geplanten Anwendung festellen
Sicherstellen, dass alles berücksichtigt wurde.
14 - Final Security Review
Letzte Kontrolle vor dem Release (Durch Security Spezialist)
15 - Release Archive
Alle erstellten Dokumente archivieren
Software freigegeben
