Κυριακή 23 Φεβρουαρίου 2014

Secure Systems Design - Part I

I. Understanding Threats

a. Defacement

 - Online Vandalism, επιθέσεις με σκοπό να αντικαταστήσουν νόμιμες ιστοσελίδες με παράτυπο περιεχόμενο.

 - Συνήθεις στόχοι, ιστοσελίδες πολιτικού περιεχομένου.

b. Infiltration
 - Μη πιστοποιημένα άτομα, λαμβάνουν πρόσβαση σε πόρους υπολογιστικών συστημάτων (CPU, Disk Drives, Network Bandwidth).
 - Πρόσβαση σε read/write access το back-end βάση δεδομένων.
 - Οι επιθέσεις πρέπει να εντοπίζονται.
 - Διαφορετικές προϋποθέσεις σε θέματα ασφάλειας, ανάλογα με τον οργανισμό.

c. Phishing

 - Δημιουργία spoofed ιστοσελίδων που ομοιάζουν με πραγματικές

<a href=http://www.evil-site.com>
Legitimate Site
</a>

d. Pharming

 - Προτροπή στον χρήστη να εισάγει ευαίσθητα δεδομένα σε μία spoofed ιστοσελίδα.
 - DNS Cache Poisoning, o hacker κατορθώνει να δρομολογήσει ένα legitimate URL σε μία spoofed ιστοσελίδα.
 - O DNS μεταφράζει ένα URL σε μία, προσδιοριζόμενη από τον hacker, IP.

e. Insider Threats

 - Επιθέσεις με τη συνεργασία εκ των έσω.
 - Διαφοροποίηση των Privileges ανάμεσα στους χρήστες, μη εξουσιοδότηση πρόσβασης σε δεδομένα και πόρους αν δεν συντρέχει λόγος.

f. Click Fraud

 - Pay per click διαφημίσεις.
 - Ο hacker κλικάρει διαφημίσεις αντιπάλου, ώστε να εξαντλήσει το ad budget τους.
 - Αυτόματο κλικ με botnets.

g. Denial of Service (DoS)

 - O hacker κατακλύζει το server με traffic, ώστε να αναγκάσει το server να απορρίψει legitimate packets.
 - Συνήθεις στόχοι, οικονομικοί και e-commerce vendors.
 - Μπορεί να αυτοματοποιηθεί μέσω botnets.

h. Data Theft and Data Loss

 - BofA: απώλεια backup data tapes κατά τη μεταφορά.
 - Fraudsters εκτελούν queries σε βάση δεδομένων με ευαίσθητα δεδομένα.
 - Χρήστης με προσωπικές πληροφορίες στον υπολογιστή του, πέφτει θύμα διάρρηξης.


II. Threat Modeling

STRIDE:

  • Spoofing Identity
  • Tampering (unauthorized modification)
  • Repudiation
  • Information Disclosure (unauthorized read)
  • Denial of Service
  • Escalation of privilege

III. Designing in Security

a. Σχεδίαση των features λαμβάνοντας υπόψιν την ασφάλεια
 - Όχι σαν afterthought.
 - Δύσκολα η ασφάλεια μπορεί να ενσωματωθεί αργότερα σαν add – on.

b. Σχεδίαση concrete, measurable security goals.
 - Πόσοι χρήστες θα μπορούν να εκτελέσουν την ενέργεια Χ.
 - Ποιο output του feature Y, θα πρέπει να είναι encrypted.
 - To feature Z θα πρέπει να είναι διαθέσιμο 99.9% του χρόνου.

c. Παράδειγμα κακής σχεδίασης: Windows 98
 - Diagnostic mode, πατώντας το πλήκτρο F8 κατά την εκκίνηση.
 - Ήταν δυνατή η προσπέλαση του κωδικού προστασίας, δίνοντας πλήρη πρόσβαση στο σκληρό δίσκο και στα δεδομένα.
 - Η ασφάλεια Username/Password προστέθηκε αργότερα.
 - Θα έπρεπε να είχε ενσωματωθεί από την αρχή, ώστε να απαιτείτε για την είσοδο σε Diagnostic Mode.

d. Παράδειγμα κακής σχεδίασης: Internet
 - Όλοι οι κόμβοι αρχικά, ανήκαν σε πανεπιστήμια ή στρατιωτικές βάσεις.
 - Κατά το commercialization, πολλοί νέοι hosts μπορούσαν να συνδεθούν με τους υπάρχοντες hosts, ανεξάρτητα να ήταν άξιοι εμπιστοσύνης.
 - Ανάγκη για Firewalls.
 - Loopholes, χρήση ελεύθερων ports.

e. IP Whitelisting & Spoofing

 - IP Whitelisting: αποδοχή επικοινωνίας μόνο από hosts συγκεκριμένων IP.
 - IP Spoofing: mislabeling την source address, ώστε το πακετο να διαπεράσει το Firewall.

f. IP Spoofing & Nonces

 - Nonce: one – time ψευδοτυχαίος αριθμός.
 - Η επισύναψη ενός Nonce, για απάντηση και request να επιστραφεί πίσω, είναι προστασία έναντι στο IP Spoofing.
 - O hacker δεν γνωρίζει τι να αλλοιώσει στην απάντηση.
 - Spoofing είναι ευκολότερο σε non-connection-oriented πρωτόκολλα, όπως UDP.
 - TCP sequence #s πρέπει να είναι τυχαία, αλλιώς ο hacker μπορεί να προβλέψει που θα κάνει τα δικά του πακέτα inject, κατά την επικοινωνία.

g. Turtle Shell Architectures
 - Ένα inherently μη ασφαλές σύστημα, προστατεύεται από ένα άλλο σύστημα, όπως Firewall.
 - Ένα εξωτερικό shell δεν είναι επαρκής ασφάλεια.

h. Convenience και Security
 - Κάποιες φορές, αντιστρόφως ανάλογα μεγέθη.

i. Security in Software Requirements
 - Robust consistent error handling.
 - Share requests with QA team.
 - Handle internal errors securely.
 - Use defensive programming.
 - Validation and Fraud Checks
 - “Security or Bust” Policy

Δεν υπάρχουν σχόλια:

Δημοσίευση σχολίου