c2b_default

Security (HW/SW) Questions

Questions about security, cryptography, protocols and standards.

Questions about security, cryptography, protocols and standards.

12
0.0 (0)
Subhan Waizi
Lernen
Subhan Waizi
Diese Lernkarten bieten einen umfassenden Überblick über Sicherheitsfragen in Hardware und Software, insbesondere für Studierende an Universitäten. Sie behandeln Themen wie strukturierte Bedrohungsanalysen, Sicherheitsstandards wie die IEC 62443, Fuzz-Testing und Methoden zur Identifizierung von Sicherheitslücken und Bedrohungen. Die Karteikarten sind besonders nützlich für IT-Sicherheitsfachleute, Entwickler und Studenten, die sich mit der Analyse und Bewertung von Sicherheitsrisiken befassen.
Karten
12
Lernende
1
Sprache
Deutsch
Kategorie
Informatik
Stufe
Universität
Erstellt / Aktualisiert
09.01.2021 / 02.02.2021
  • 1  / 12

Lernkarten

Top 10 Web Application Security Risks (1-5)

    1. Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
    2. Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
    3. Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
    4. XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
    5. Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

    Top 10 Web Application Security Risks (6-10)

     

      1. Security Misconfiguration. the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
      2. Cross-Site Scripting (XSS). flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
      3. Insecure Deserialization. often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
      4. Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover.
      5. Insufficient Logging & Monitoring. coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

      How can risks be assessed? What is a common model?

      DREAD is part of a system for risk-assessing computer security threats previously used at Microsoft and although currently used by OpenStack and other corporations it was abandoned by its creators. It provides a mnemonic for risk rating security threats using five categories.

      The categories are:

      • Damage – how bad would an attack be?
      • Reproducibility – how easy is it to reproduce the attack?
      • Exploitability – how much work is it to launch the attack?
      • Affected users – how many people will be impacted?
      • Discoverability – how easy is it to discover the threat?

      How can security threats be identified? What is a common approach for this?

      STRIDE is a model of threats developed by Praerit Garg and Loren Kohnfelder at Microsoft for identifying computer security threats. It provides a mnemonic for security threats in six categories.

      The threats are:

      How can vulnerabilities be assessed?

      A vulnerability assessment is a systematic review of security weaknesses in an information system. It evaluates if the system is susceptible to any known vulnerabilities, assigns severity levels to those vulnerabilities, and recommends remediation or mitigation, if and whenever needed.

      • Threat analysis (e.g. Stride)
      • Risk Assessment (e.g. Dread)
      • Remediation / Mitigation Actions and Control Mechanisms

      What is Fuzz-Testing?

      Other Names: Fuzzing, or Robustness Testing, Fuzzy Testing, negative Testing

      • Willkürliche und zufällige Daten werden in das System eingespeist und das Verhalten des Systems beobachtet
      • Black-Box Testing, v.a. sehr gut geeignet um Sicherheitslücken aufzuspüren
      • Als Folge von Abstürzen durch Fuzzing Tests kann man das Problem dann im Rahmen von White-Box Testing näher untersuchen
      • Greybox-Testing als Verfahren bei dem der Quellcode mit herangezogen wird und man dadurch gerade die Anfangsabfragen umgehen kann um tiefer in den Code hineinzugelangen und damit eine höere Coverage zu haben

      Tools Beispiele (aktuell eingesetzte Tools):

      • American Fuzzy Lop (afl) von Michal Zalewski (Greybox-Testing --> höhere Coverage und kein so schnelles Abbrechen)
      • Clusterfuzz (Google) als skalierbare Fuzzing-Infrastruktur
        • 16000 Fehler in Google Chrome gefunden von 2012-2019

      Was ist die IEC 62443?

      IEC 62443 ist eine internationale Normenreihe über "Industrielle Kommunikationsnetze - IT-Sicherheit für Netze und Systeme". Die Norm ist in verschiedene Abschnitte unterteilt und beschreibt sowohl technische als auch prozessorale Aspekte der Industriellen Cybersecurity. 

      Dabei unterteilt die Norm die einzelnen Kapitel (insgesamt 4) für verschiedene Stakeholder:

      • Betreiber von Anlagen, Integratoren (Wartung / Integration von Anlagen), Hersteller (Komponenten / Produkte) 

      Wie sind die einzelnen Teile der IEC 62443 untergliedert?

      Melde dich an, um Bilder anzusehen.

      s. Bild

      Was definiert die IEC 62443 4-1?

      Anforderungen an einen sicheren Entwicklungsprozess für Produkte - einen sog. SSDLC (Secure Product Developemnt Lifecycle).

      Das Unterkapitel 4-1 gliedert die Anforderungen an den sicheren Produktentwicklungsprozess in sog. Practices, wovon die 4-1 aktuell 8 verschiedene definiert:

      1. Security Management (SM)
        1. SM-1 - Development Process
        2. SM-2 - Identification of Responsibilities
        3. SM-3 - Identification of applicability
        4. SM-4 - Security Expertise
        5. SM-5 - Process Scoping
        6. SM-6 - File Integrity
        7. SM-7 - Development Environment Security
        8. SM-8 - Controls for private keys
        9. SM-9 - SR for externally provided products
        10. SM-10 - Custom-developed components from 3rd party suppliers
        11. SM-11 - Assessing and addressing security related issues
        12. SM-12 - Process Verification
        13. SM-13 - Continious Improvement
      2. Specification of Security Requirements (SR)
        1. SR-1: Product Security Context
        2. SR-2: Threat model
        3. ...
        4. SR-5: Security Requirements Review
      3. Secure by Design (SD)
      4. Secure Implementation (SI)
      5. Security Verification and Validation Testing (SVV)
      6. Management of security-related issues (DM)
      7. Security Update Management (SUM)
      8. Security Guidelines (SG)

      Was definiert die IEC 62443 4-2

      Detaillierte technische Security Anforderungen sichere Produkte, untergliedert in sieben Foundational Requirements.

      1. FR 1 - Identification and authentication control
      2. FR 2 - Use control
      3. FR 3 - System Integrity
      4. FR 4 - Data confidentiality
      5. FR 5 - Restricted data flow 
      6. FR 6 - Timely response to events
      7. FR 7 - Resource availability

      Weiterhin:

      1. Software Application Requiirements
      2. Embedded Device Requirements
      3. Host Device Requirements
      4. Network Device Requirements  

      Wie kann man strukturiert eine Bedrohungsanalyse betreiben? Punkte 1 - 5

      Es gibt detailierte SW, mit der man Vulnerability / Threat Analysis betreiben kann. Bis jetzt haben wir das in einfachen Templates gemacht, ohne Verwendung von SW. 

      1. Use Scenarios enthält eine kurze Beschreibung, für welchen Nutzen das System gedacht ist. Nutzen des Systems für das Syste, nicht gedacht ist könnte die Security des Systems beeinträcthtigen.
      2. Externe Abhängigkeiten beschreiben Abhängigkeit zu weiteren (nicht im Scope befindlichen) Systemen, welche Schwachstellen im zu analysierend. System führen könnten.
      3. Implementierungsannahmen beschreiben Annahmen die über externe Komponenten oder das System gemacht  wurden während der Spezifikation. Es wird generell erwartet, dass diese nicht verletzt werden. Z.B. Drittsystem, welches aber bereits einer Bedorhungsanalyse untergangen ist. Sobald das System analysieirt wurde im Hinblick auf Bedrohungen, können diese Annahmen noch einmal verifiziert werden.
      4. External Security Notes nkludiert Bedrohungen oder Informationen welche der Benutzer eines Systems wissen und befolgen sollte, damit Security Schwachstellen verhindert werden. Diese Tabelle kan z.B. Features enthalten, die bei inkorrekter Nutzung Sicherheitsprobleme bei der Systembenutzung hervorrufen könnten.
      5. Internal Security notes inludieren Sicherheitsinformationen, die nur relvant und zugänglich sein sollten für jem. der die Bedrohungsanalyse liest. Sie soll helfen spätere Designentscheidungen / Maßnahmen nachvollziehen zu können.

      Wie kann man strukturiert eine Bedrohungsanalyse durchführen (Punkte 6-10).

      1. Trust Levels beschreiben Auth / Authpunkte im System und die Rechte, die man dadurch erlangen kann.
      2. Interfaces sind Schnittstellen durch welche externe Eiheiten Daten mit dem System austauschen können. Diese sollten alle Inputs, welce zum System / vom System gesendet werden beinhalten.
      3. Assets beschreiben die Daten und Funktinalitäten die im System beschützt werden müssen um Breaches zu vermeiden (Schlüssel, Code, Parameter, etc.).
      4. Datenflussdiagramme zeigen die Kommunikation zw. verschieden Komponenten innerhalb Systems und die Kommunkation zu externen Systemen die in der "External Dependencies" und "Interfaces" Sektionen beschrieben sein sollten. 
      5. Letzendlich die Bedrohungen besteht aus einer Tabelle welche Bedrohungen beschreibt und zu Interfaces, Assets in GEfahr, STRIDE Klassifikation, den Use Case Scenarios, etc. in Verbindung bringt. Weiterhin sollt beschrieben sein, welche Maßnahmen implmentiert sind, welche implementiert werden müssten um die Bedrohung einzudämmen (inwieweit liegt im Augen bzw. in der Erfahrung, derjenigen die die Analyse durchführen) und eine Art Einschätzung inwieweit die Bedrohung bereits abgeschwächt wurde (none, partially, mitigated, prevented).

      Lernen