Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος Εξάμηνο: Δ’

Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος 2012-2013 Εξάμηνο: Δ’
Ασφάλεια Υπολογιστών και Προστασία Δεδομένων Ενότητα Δ: Μοντέλα Εξουσιοδότησης (Authorization) Εμμανουήλ Μάγκος

Syllabus Μοντέλα και Πολιτικές Ελέγχου Πρόσβασης (Εξουσιοδότησης)
Έλεγχος ροής κυκλοφορίας (information flow control) Πολιτικές MAC, DAC, RBA Έλεγχος Πρόσβασης Συστήματος και Ασφάλεια Λ.Σ Το μοντέλο Ασφάλειας των Windows Άλλα Θέματα στον Έλεγχο Πρόσβασης Επίπεδα Προστασίας Κριτήρια για την Πρόσβαση Διαχείριση Ελέγχου Πρόσβασης Άλλα θέματα Καταγραφή & Παρακολούθηση, Ανίχνευση Logging and Monitoring Intrusion Detection & Intrusion Prevention

Information Flow Control
1. Authorization & Information Flow Control

Έλεγχος Λογικής Πρόσβασης & Εξουσιοδότηση (Authorization)

Έλεγχος Λογικής Πρόσβασης & Εξουσιοδότηση (Authorization)
π.χ. πόροι που χρειάζονται προστασία (μνήμη, αρχεία, φάκελοι, υπηρεσίες, συσκευές,.) Αντικείμενα (objects) Υποκείμενα (Subjects) Τύπος Πρόσβασης π.χ. Εφαρμογές που ζητούν πρόσβαση σε πόρους, εν’ ονόματι μιας οντότητας (χρήστες, Ομάδες, Η/Υ..) Εξουσιοδότηση (Authorization). Στην ενότητα Γ (ταυτοποίηση) είδαμε πώς οι μηχανισμοί ταυτοποίησης, στα πλαίσια του Ελέγχου Πρόσβασης (Ε.Π.), μας επιτρέπουν να απαντήσουμε σε ερωτήσεις όπως «ποιος είναι αυτός που προσπαθεί να αποκτήσει πρόσβαση στο σύστημα;». Τι γίνεται όπως όταν το υποκείμενο Α, του οποίου την ταυτότητα διασταυρώσαμε, αποκτήσει πρόσβαση στο σύστημα; Τι μπορεί να κάνει το υποκείμενο Α στο σύστημα, και συγκεκριμένα ποια είναι τα δικαιώματα που έχει στους πόρους του συστήματος; Το υποσύστημα του ελέγχου λογικής πρόσβασης που ασχολείται με τον καθορισμό των δικαιωμάτων που παρέχονται σε ένα υποκείμενο, ονομάζεται και ως υποσύστημα Εξουσιοδότησης (Authorization) του συστήματος. Σημείωση: Στην βιβλιογραφία, ή εξουσιοδότηση αναφέρεται και συχνά και ως έλεγχος προσπέλασης. Οι έννοιες είναι αλληλένδετες. Συχνά επίσης αναφέρεται και ως έλεγχος πρόσβασης. Αντικείμενα, Υποκείμενα. Ο Ε.Π., στα πλαίσια της πολιτικής ασφάλειας του συστήματος, καθορίζει εκτός των άλλων τα δικαιώματα που έχουν οι χρήστες, καθώς και τα προγράμματα που εκτελούνται εξ ‘ ονόματος των. Οι χρήστες, τα προγράμματα, καθώς και τα ονόματα διευθύνσεων Η/Υ που προσπαθούν να ανταλλάξουν δεδομένα μέσω δικτύου, θεωρούμε ότι ανήκουν στην κατηγορία Υποκείμενα. Αντίστοιχα, οι πόροι του συστήματος, ή αλλιώς τα Αντικείμενα στα οποία προσπαθεί να αποκτήσει πρόσβαση ένα υποκείμενο, είναι οι περιοχές της μνήμης, οι φάκελοι και τα αρχεία, οι υπηρεσίες (services) που εκτελούνται στο παρασκήνιο, τα προγράμματα, οι βάσεις δεδομένων, τα υποσυστήματα hardware του Η/Υ κ.λ.π. Δικαιώματα. Tα δικαιώματα που παρέχονται σε ένα υποκείμενο και τα οποία επιτρέπουν την πρόσβαση σε έναν πληροφοριακό πόρο (αντικείμενο). Όταν ένας χρήστης ταυτοποιηθεί, το επίπεδο εξουσιοδότησης καθορίζει τα δικαιώματα πρόσβασης που μπορεί να έχει. Τα δικαιώματα συνήθως τυποποιούνται ως εξής: Ανάγνωση (διάβασμα), Εγγραφή (τροποποίηση), εκτέλεση κ.λ.π. Στη συνέχεια της ενότητας θα δούμε περισσότερο αναλυτικά τα δικαιώματα επί των αντικειμένων Σημείωση: Ένα υποκείμενο σε μια περίσταση, μπορεί να μετατραπεί σε αντικείμενο σε κάποια άλλη περίσταση (π.χ. ένα πρόγραμμα τροποποιείται από κάποιο άλλο πρόγραμμα). Πολιτική Εξουσιοδότησης: Κανόνες οι οποίοι καθορίζουν Ποια υποκείμενα έχουν τι είδους πρόσβαση σε ποια αντικείμενα Σημείωση: Ανάλογα με την περίσταση, ένας χρήστης μπορεί να συνδέεται στο σύστημα με ένα ή περισσότερα ονόματα (userid). π.χ. Ανάγνωση, Εγγραφή, Εκτέλεση.. Πολιτική Εξουσιοδότησης: Κανόνες που καθορίζουν ποια υποκείμενα έχουν τι είδους πρόσβαση σε ποια αντικείμενα

Έλεγχος Λογικής Πρόσβασης Συστατικά Στοιχεία
op on o op s Reference monitor s o Ταυτοποίηση Καταγραφή Εξουσιοδότηση Ποιος είναι ο s; Τι op μπορεί να κάνει ο s στο o; Τι έκανε (ή προσπάθησε να κάνει ο s;)

Έλεγχος Λογικής Πρόσβασης Συστατικά Στοιχεία
Τεχνολογίες Αυθεντικοποίησης Αυθεντικοποίηση Οντότητας (π.χ. Passwords, Challenge-Response,…) Πολιτική Εξουσιοδότησης Ένα μοντέλο καθορισμού των εξουσιοδοτημένων προσβάσεων Πολιτικές DAC, MAC, RBAC,… Σύνολο κανόνων που καθορίζει τι είδους πρόσβαση έχουν τα υποκείμενα σε άλλα υποκείμενα/αντικείμενα Reference monitor Επιβλέπει την υλοποίηση των πολιτικών εξουσιοδότησης Αποτελεί κομμάτι του πυρήνα (kernel) του Λ.Σ Καταγραφή και Παρακολούθηση Ασφάλεια Αρχείων Καταγραφής και Πολιτικές Παρακολούθησης Ανίχνευση και Αποτροπή Εισβολών (IDS, IPS) Πολιτικές Εξουσιοδότησης. Η πολιτική Εξουσιοδότησης αποτελεί τμήμα της Πολιτικής Ασφαλείας της Επιχείρησης/Οργανισμού. Θέτει τους κανόνες ελέγχου των δικαιωμάτων πρόσβασης των χρηστών. Οι κανόνες αυτοί είναι αρκετά γενικοί ώστε να επιτρέπουν την υλοποίηση τους με περισσότερους από έναν μηχανισμούς/μοντέλα εξουσιοδότησης. Σε κάθε πληροφοριακό και δικτυακό σύστημα, κατά τις διαδικασίες ανάπτυξης και συντήρησης του, θα πρέπει να πραγματοποιείται αποτίμηση κινδύνου (Risk Assessment) (π.χ Ενότητα Α: Ποιος μας απειλεί; Τι επιθέσεις μπορεί να εξαπολύσει;) με σκοπό την επιλογή μηχανισμών που θα μειώνουν τους κινδύνους σε αποδεκτά για την επιχείρηση / οργανισμό επίπεδα. Τα μοντέλα εξουσιοδότησης θα πρέπει να επιλέγονται βάσει των αποτελεσμάτων της προαναφερθείσας διαδικασίας αποτίμησης κινδύνου. Μοντέλα Εξουσιοδότησης. Στη συνέχεια αυτής της ενότητας θα αναφερθούμε στα μοντέλα εξουσιοδότησης MAC, DAC, RBAC Μηχανισμός Εξουσιοδότησης (Reference Monitor). Αποτελεί τμήμα του κώδικα προγράμματος του Λ.Σ. ενός Η/Υ (συγκεκριμένα του πυρήνα – kernel), το οποίο ελέγχει την πρόσβαση στα δεδομένα, προγράμματα, τη μνήμη και το υλικό του Η/Υ. Κάθε φορά που υποβάλλεται μια αίτηση πρόσβασης από ένα υποκείμενο για ένα αντικείμενο, ο μηχανισμός εξουσιοδότησης ελέγχει τα δικαιώματα πρόσβασης που έχουν προ-εκχωρηθεί στο υποκείμενο για το εν λόγω αντικείμενο, και εξουσιοδοτεί ή όχι την πρόσβαση.

Βασικές Έννοιες Δικαιώματα Πρόσβασης (Permissions)
write read append execute observe X alter Gollmann p Δικαιώματα Πρόσβασης στο μοντέλο ασφάλειας των Bell-LaPadula

Δικαιώματα Πρόσβασης Περίπτωση: Unix
: Τύπος αρχείου. 2 – 4 : Τα δικαιώματα του ιδιοκτήτη (owner). 5 – 7 : Τα δικαιώματα της ομάδας (group). 8 – 10 : Ta δικαιώματα των υπολοίπων (world). Δικαιώματα Σημασία - rwx rwx rwx Αρχείο. Όλοι δικαιούνται Ανάγνωση, Εγγραφή και Εκτέλεση - rwx r-x r-x Αρχείο. Όλοι δικαιούνται Ανάγνωση και Εκτέλεση αλλά μόνο ο ιδιοκτήτης δικαιούται εγγραφή. d rwx Φάκελος. Ο ιδιοκτήτης δικαιούται Ανάγνωση, Εγγραφή, Εκτέλεση Δικαιώματα Πρόσβασης (τύπου Unix). Κάθε αρχείο η φάκελος σε ένα σύστημα αρχείων UNIX ανήκει σε κάποιον χρήστη. Σε συστήματα αρχείων Unix, τα αρχεία/φάκελοι προστατεύονται επίσης από Λ.Ε.Π (ACLs). Σε κάθε αρχείο ή φάκελο κατά τη στιγμή της δημιουργίας του ορίζονται και τα δικαιώματα πρόσβασης (permissions) που θα έχει ένας χρήστης (ιδιοκτήτης), η ομάδα στην οποία ο χρήστης ανήκει (group), ή οι υπόλοιποι χρήστες του συστήματος (world). Για κάθε υποκείμενο του συστήματος, η λίστα των δικαιωμάτων εμφανίζεται ως μια συμβολοσειρά μήκους 10 χαρακτήρων. Ο πρώτος χαρακτήρας περιγράφει τον τύπο του αντικειμένου (αν είναι «-» τότε είναι ένα απλό αρχείο, ενώ αν είναι «d» τότε είναι φάκελος). Επίσης, η λίστα των δικαιωμάτων συμπληρώνεται με 3 ομάδες των 3 χαρακτήρων για την απεικόνιση των δικαιωμάτων του Ιδιοκτήτη, της Ομάδας του Ιδιοκτήτη, και των Υπολοίπων. Κάθε χαρακτήρας συμβολίζει την ύπαρξη ή απουσία (-) ενός εκ των βασικών δικαιωμάτων της ανάγνωσης (r), της εγγραφής (w) και της εκτέλεσης (x). Ανάγνωση – Read (αρχείο): δικαίωμα ανάγνωσης των περιεχομένων του αρχείου Εγγραφή – Write (αρχείο): δικαίωμα αλλαγής (τροποποίηση & διαγραφή) στο αρχείο Εκτέλεση – eXecute (αρχείο): δικαίωμα εκτέλεσης του αρχείου (εφόσον περιέχει εκτελέσιμο κώδικα) 9

Δικαιώματα Πρόσβασης Περίπτωση: Unix
Σε φάκελο: read: λίστα περιεχομένων write: δημιουργία, διαγραφή ή μετονομασία αρχείων του φακέλου execute: Πρόσβαση στον φάκελο (enter, open files,..) Σε αρχείο: read: Ανάγνωση του αρχείου write: Εγγραφή στο αρχείο execute: Εκτέλεση του αρχείου Gollman p. 115 Τα δικαιώματα πρόσβασης έχουν ελαφρώς διαφορετικό νόημα στους φακέλους (directories). Ανάγνωση – Read (φάκελος): Δικαίωμα ανάγνωσης των περιεχομένων του φακέλου (π.χ. λήψη της λίστας των περιεχομένων με την εντολή ls) Εγγραφή – Write (φάκελος): Δικαίωμα αλλαγής των περιεχομένων του φακέλου( π.χ. δημιουργία, μετακίνηση ή διαγραφή αρχείων στον φάκελο) - Σημείωση: ένας χρήστης μπορεί να σβήσει το αρχείο ενός φακέλου στον οποίο έχει δικαίωμα Εγγραφής, ακόμα και αν δεν έχει δικαίωμα Εγγραφής στο αρχείο αυτό. Ωστόσο, για να τροποποιήσει το περιεχόμενο του αρχείου, θα πρέπει να έχει δικαίωμα εγγραφής στο αρχείο. Εκτέλεση - eXecute (φάκελος): Δικαίωμα πρόσβασης στα περιεχόμενα του φακέλου (δικαίωμα να κάνουμε έναν φάκελο τον τρέχοντα φάκελο, να ανοίξουμε ένα αρχείο) Σημείωση (παράδειγμα): Εάν ο χρήστης έχει δικαίωμα Ανάγνωσης αλλά όχι Εκτέλεσης για έναν φάκελο, τότε το μόνο δικαίωμα που έχει στον φάκελο είναι η ανάγνωση της λίστας με τα περιεχόμενα του φακέλου. Δηλαδή, μπορεί να δει τη λίστα με τα περιεχόμενα του Α χρησιμοποιώντας π.χ. την εντολή ls, αλλά όχι να μεταβεί στον φάκελο Α (με την εντολή cd) ή να κάνει οποιαδήποτε άλλη ενέργεια στα περιεχόμενα του φακέλου. Αν ο χρήστης έχει δικαίωμα Εκτέλεσης αλλά όχι Ανάγνωσης για τον φάκελο Α, αυτό σημαίνει ότι μπορεί να μεταβεί στον φάκελο Α (με την εντολή cd) και να διαχειριστεί τα περιεχόμενα του (π.χ. να σβήσει ένα αρχείο του φακέλου για το οποίο έχει δικαίωμα εγγραφής), αλλά δεν μπορεί να δει τη λίστα με τα περιεχόμενα του (άρα, για να σβήσει το αρχείο, θα πρέπει να γνωρίζει από πριν το όνομα του). Η διαφορά είναι «λεπτή», για το λόγο αυτό συνήθως σε έναν φάκελο είτε εκχωρούνται δικαιώματα Ανάγνωσης & Εκτέλεσης (r-x) , είτε δεν εκχωρούνται καθόλου δικαιώματα). 10

Βασικές Έννοιες Πίνακας Ελέγχου Πρόσβασης (Access Control Matrix)
* Αφηρημένη έννοια: Ένας πίνακας με υποκείμενα, αντικείμενα, & τις ενέργειες (δικαιώματα) των υποκειμένων στα αντικείμενα Ζητήματα Πλήθος υποκειμένων/ αντικειμένων (scalability) Ένα υποκείμενο μπορεί να γίνει αντικείμενο σε κάποιο context Gollmann, p. 71 You can either specify What a principal is allowed to do What may be done with an object In general, sub jects are viewed as a subset of the ob jects. The cell for row s and column o is denoted by [s; o], and contains a set of access rights specifying the authorization of sub ject s to perform operations on ob ject o. For example, read 2 [s; o] authorizes s to read o. Only those operations which are authorized by the access matrix can be executed. For purpose of the access matrix, every user is also regarded as a sub ject in its own right. This sub ject retains the access rights of the user, even when the user is not engaged in any activity in the system. The access matrix is usually sparse and is stored in a system using access control lists, capabilities, relations, or some other data structure suitable for ecient storage of a sparse matrix. The access matrix is a dynamic entity. The individual cells in the access matrix can be modied by sub jects. For example, if sub ject s is the owner of ob ject o (i.e., own 2 [s; o]) then s typically can modify the contents of all cells in the column corresponding to o. In this case the owner of an ob ject has complete discretion regarding access by other sub jects to the owned ob ject. Such access controls are said to be discretionary. The access matrix also changes due to addition and deletion of sub jects and ob jects. (The typical access control on les and directories, provided by popular multi-user operating systems, on the basis of protection bits, is an example of discretionary access control. Similarly, the access control on relations and parts of relations provided by popular relational database management systems, is also an example of discretionary access control.) Security practitioners have developed a number of abstractions over the years in dealing with access control. Perhaps the most fundamental of these is the realization that all resources controlled by a computer system can be represented by data stored in objects (e.g., files). Therefore protection of objects is the crucial requirement, which in turn facilitates protection of other resources controlled via the computer system. (Of course, these resources must also be physically protected so they cannot be manipulated directly bypassing the access controls of the computer system.) Activity in the system is initiated by entities known as subjects. Subjects are typically users or programs executing on behalf of users. A user may sign on to the system as different subjects on different occasions, depending on the privileges the users wishes to exercise in a given session. For example, a user working on two different projects may sign on for purpose of working on one project or the other. We then have two subjects corresponding to this user, depending on the project the user is currently working on. A subtle point that is often overlooked is that subjects can themselves be objects. A subject can create additional subjects in order to accomplish its task. The children subjects may be executing οn various computers in a network. The parent subject will usually be able to suspend or terminate its children as appropriate. The fact that subjects can be objects corresponds to the observation that the initiator of one operation can be the target of another. (In network parlance subjects are sometimes called initiators, and objects called targets.) The subject-object distinction is basic to access control. Subjects initiate actions or operations on objects. These actions are permitted or denied in accord with the authorizations established in the system. Authorization is expressed in terms of access rights or access modes. The meaning of access rights depends upon the object in question. For files the typical access rights are Read, Write, Execute and Own. The meaning of the first three of these is self evident. Ownership is concerned with controlling who can change the access permissions for the file. An object such as a bank account may have access rights Inquiry, Credit and Debit corresponding to the basic operations that can be performed on an account. These operations would be implemented by application programs, whereas for a file the operations would typically be provided by the Operating System. The access matrix is a conceptual model which specifies the rights that each subject possesses for each object. There is a row in this matrix for each subject, and a column for each object. Each cell of the matrix specifies the access authorized for the subject in the row to the object in the column. The task of access control is to ensure that only those operations authorized by the access matrix actually get executed. This is achieved by means of a reference monitor, which is responsible for mediating all attempted operations by subjects on objects. Note that the access matrix model clearly separates the problem of authentication from that of authorization. An example of an access matrix is shown in figure 2, where the rights R and W denote read and write respectively, and the other rights are as discussed above. The subjects shown here are John, Alice and Bob. There are four files and two accounts. This matrix specifies that, for example, John is the owner of File 3 and can read and write that file, but John has no access to File 2 or File 4. The precise meaning of ownership varies from one system to another. Usually the owner of a file is authorized to grant other users access to the file, as well as revoke access. Since John owns File 1, he can give Alice the R right and Bob the R and W rights as shown in figure 2. John can later revoke one or more of these rights at his discretion. The access rights for the accounts illustrate how access can be controlled in terms of abstract operations implemented by application programs. The Inquiry operation is similar to read in that it retrieves information but does not change it. Both the Credit and Debit operations will involve reading the previous account balance, adjusting it as appropriate and writing it back. The programs which implement these operations require read and write access to the account data. Users, however, are not allowed to read and write the account object directly. They can manipulate account objects only indirectly via application programs which implement the Debit and Credit operations. Also note that there is no Own right for accounts. Objects such as bank accounts do not really have an owner who can determine the access of other subjects to the account. Clearly the user who establishes the account at the bank should not be the one to decide who can access the account. Within the bank different officials can access the account on basis of their job functions in the organization. Για μεγαλύτερη ευελιξία, ο καθορισμός των δικαιωμάτων μπορεί να είναι προσανατολισμένος: Στα Αντικείμενα Λίστες Ελέγχου Πρόσβασης Στa υποκείμενα (principals) Λίστες Δυνατοτήτων

Βασικές Έννοιες Λίστες Ελέγχου Πρόσβασης
Βασικές Έννοιες Λίστες Ελέγχου Πρόσβασης Ποια δικαιώματα έχουν ποια υποκείμενα επάνω σε ένα αντικείμενο; Ουσιαστικά αποτελεί θεώρηση ενός Πίνακα Ελέγχου Πρόσβασης ανά στήλες Χρησιμοποιούνται ευρέως σε: Λ.Σ., Β.Δ.,… Εφαρμογές Πολιτικές πρόσβασης σε δικτυακές συσκευές …

Βασικές Έννοιες Λίστες Ελέγχου Πρόσβασης (Access Control Lists)
* 4 3.1 Access Control Lists A popular approach to implementing the access matrix is by means of Access Control Lists (ACLs). Each object is associated with an ACL, indicating for each subject in the system the accesses the subject is authorized to execute on the object. This approach corresponds to storing the matrix by columns. ACLs corresponding to the access matrix of figure 2 are shown in figure 3. Essentially the access matrix column for File 1 is stored in association with File 1, and so on. By looking at an object's ACL it is easy to determine which modes of access subjects are currently authorized for that object. In other words ACLs provide for convenient access review with respect to an object. It is also easy to revoke all access to an object by replacing the existing ACL with an empty one. On the other hand determining all the accesses that a subject has is difficult in an ACL-based system. It is necessary to examine the ACL of every object in the system to do access review with respect to a subject. Similarly if all accesses of a subject need to be revoked all ACLs must be visited one by one. (In practice revocation of all accesses of a subject is often done by deleting the user account corresponding to that subject. This is acceptable if a user is leaving an organization. However, if a user is reassigned within the organization it would be more convenient to retain the account and change its privileges to reflect the changed assignment of the user.) Many systems allow group names to occur in ACLs. For example, an entry such as (ISSE, R) can authorize all members of the ISSE group to read a file. Several popular Operating Systems, such as Unix and VMS, implement an abbreviated form of ACLs in which a small number, often only one or two, group names can occur in the ACL. Individual subject names are not allowed. With this approach the ACL has a small fixed size so it can be stored using a few bits associated with the file. At the other extreme there are a number of access control packages which allow complicated rules in ACLs to limit when and how the access can be invoked. These rules can be applied to individual users or to all users who match a pattern defined in terms of user names or other user attributes.

Βασικές Έννοιες Λίστες Ελέγχου Πρόσβασης (Access Control Lists)
Μοντέλο DAC. Tη στιγμή που δημιουργείται ο λογαριασμός ενός χρήστη στο σύστημα, ο χρήστης είναι ιδιοκτήτης - κάτοχος (owner) συγκεκριμένης ποσότητας πληροφοριακών πόρων. Το πλήθος και το είδος των πόρων που κατέχει ο χρήστης καθορίζεται από την πολιτική εξουσιοδότησης. Στη διάρκεια της «ζωής» του στο σύστημα, ο χρήστης μπορεί να δημιουργήσει καινούριους πόρους (π.χ. αρχεία, φάκελοι, προγράμματα). Οι πληροφοριακοί πόροι που δημιουργούνται από ένα χρήστη θεωρούνται επίσης ότι βρίσκονται στην κατοχή του χρήστη. Tο μοντέλο DAC αφήνει στη διακριτική ευχέρεια του χρήστη τον καθορισμό (δημιουργία, μεταβίβαση, ανάκληση) των δικαιωμάτων πρόσβασης στους πληροφοριακούς πόρους που έχει υπό τον έλεγχο του. Windows grants or denies access and privileges to resources based on access control lists (ACLs), which use SIDs to uniquely identify users and their group memberships. When a user logs into a computer, an access token is generated that contains user and group SIDs and user privilege level. When a user requests access to a resource, the access token is checked against the ACL to permit or deny particular action on a particular object. (Tanenbaum & Van Steen, 2007).

Βασικές Έννοιες Λίστες Ικανοτήτων (Capability Lists)
* 3.2 Capabilities Capabilities are a dual approach to ACLs. Each subject is associated with a list, called the capability list, indicating for each object in the system, the accesses the subject is authorized to execute on the object. This approach corresponds to storing the access matrix by rows. Figure 4 shows capability lists for the files in figure 2. In a capability list approach it is easy to review all accesses that a subject is authorized to perform, by simply examining the subject's capability list. However, determination of all subjects who can access a particular object requires examination of each and every subject's capability list. A number of capability-based computer systems were developed in the 1970s, but did not prove to be commercially successful. Modern operating systems typically take the ACL-based approach. It is possible to combine ACLs and capabilities. Possession of a capability is sufficient for a subject to obtain access authorized by that capability. In a distributed system this approach has the advantage that repeated authentication of the subject is not required. This allows a subject to be authenticated once, obtain its capabilities and then present these capabilities to obtain services from various servers in the system. Each server may further use ACLs to provide finer-grained access control.

Ποια δικαιώματα έχει ένα υποκείμενο επάνω σε ποια αντικείμενα; Ουσιαστικά αποτελεί θεώρηση ενός Πίνακα Ελέγχου Πρόσβασης ανά γραμμές Το σύστημα επιτρέπει στο υποκείμενο την πρόσβαση σε ένα αντικείμενο, σύμφωνα με τη λίστα δυνατοτήτων Παραδείγματα ~ Προνόμια χρηστών (Windows) ~Πιστοποιητικά ιδιοτήτων (attribute certificates),…

(Tanenbaum & Van Steen, 2007).

Λίστες Ικανοτήτων Case: Attribute Certificates

Μοντέλα Εξουσιοδότησης
«Κατά Διάκριση» (DAC – Discretionary Access Control): Προσανατολισμένο στην ταυτότητα του υποκειμένου Διακριτικό: Ένα υποκείμενο μεταβιβάζει (ανακαλεί) δικαιώματα σε (από) άλλα υποκείμενα για αντικείμενα που «κατέχει» «Κατ’ απαίτηση» (MAC-Mandatory Access Control): Προσανατολισμένο στη διαβάθμιση αντικειμένων & υποκειμένων Ετικέτες ασφαλείας (classification labels) στα υποκείμενα και τα αντικείμενα του συστήματος Υποχρεωτικό: Ένα υποκείμενο δεν μπορεί να μεταβιβάσει δικαιώματα «Βασισμένη σε Ρόλους» (RBAC – Role based Access Control): Προσανατολισμένο στον ρόλο (ή ρόλους) που έχει ένα υποκείμενο Ρόλος: σύνολο από ενέργειες-ευθύνες TCSEC (DOD, 1985) We will now discuss three different policies which commonly occur in computer systems as follows: classical discretionary policies, classical mandatory policies, and the emerging role-based policies. We have added the qualifier "classical" to the first two of these to reflect the fact that these have been recognized by security researchers and practitioners for a long time. However, in recent years there is increasing consensus that there are legitimate policies which have aspects of both of these. Role-based policies are an example of this fact. It should be noted that access control policies are not necessarily exclusive. Different policies can be combined to provide a more suitable protection system. This is indicated in figure 6. Each of the three inner circles represents a policy which allows a subset of all possible accesses. When the policies are combined only the intersection of their accesses is allowed. Such combination of policies is relatively straightforward so long as there are no conflicts where one policy asserts that a particular access must be allowed while another one prohibits it. Such conflicts between policies need to be reconciled by negotiations at an appropriate level of management. (NIST Standard, 2001) 19

Εξουσιοδότηση «Κατά Διάκριση» Discretionary Access Control (DAC)
Κάθε αντικείμενο (πόρος) έχει έναν ιδιοκτήτη (υποκείμενο) Ο ιδιοκτήτης διαχειρίζεται (μεταβίβαση/ανάκληση) δικαιώματα πρόσβασης για αντικείμενα που του ανήκουν, ή αντικείμενα που δημιουργεί …καθορίζει το είδος πρόσβασης π.χ. ανάγνωση, εγγραφή, εκτέλεση ...βάσει ταυτότητας υποκειμένου που αιτείται πρόσβαση: Όνομα (π.χ. SID), Group Windows grants or denies access and privileges to resources based on access control lists (ACLs), which use SIDs to uniquely identify users and their group memberships. When a user logs into a computer, an access token is generated that contains user and group SIDs and user privilege level. When a user requests access to a resource, the access token is checked against the ACL to permit or deny particular action on a particular object. 4.1 Classical Discretionary Policies Discretionary protection policies govern the access of users to the information on the basis of the user's identity and authorizations (or rules) that specify, for each user (or group of users) and each object in the system, the access modes (e.g., read, write, or execute) the user is allowed on the object. Each request of a user to access an object is checked against the specified authorizations. If there exists an authorization stating that the user can access the object in the specific mode, the access is granted, otherwise it is denied. The flexibility of discretionary policies makes them suitable for a variety of systems and applications. For these reasons, they have been widely used in a variety of implementations, especially in the commercial and industrial environments. However, discretionary access control policies have the drawback that they do not provide real assurance on the flow of information in a system. It is easy to bypass the access restrictions stated through the authorizations. For example, a user who is able to read data can pass it to other users not authorized to read it without the cognizance of the owner. The reason is that discretionary policies do not impose any restriction on the usage of information by a user once the user has got it, i.e., dissemination of information is not controlled. By contrast dissemination of information is controlled in mandatory systems by preventing information stored in high-level objects to flow into low-level objects. Discretionary access control policies based on explicitly specified authorization are said to be closed, in that the default decision of the reference monitor is denial. Similar policies, called open policies, could also be applied by specifying denials instead of permissions. In this case, for each user and each object of the system, the access modes the user is forbidden on the object are specified. Each access request by a user is checked against the specified (negative) authorizations and granted only if no authorizations denying the access exist. The use of positive and negative authorizations can be combined, allowing the specification of both the accesses to be authorized as well as the accesses to be denied to the users. The interaction of positive and negative authorizations can become extremely complicated [BSJ93]. Παράδειγμα: O ιδιοκτήτης επιτρέπει την ανάγνωση του αρχείου από τον Bob, και από μέλη της ομάδας Λογιστικής (Accounting)

Windows: Ενδιάμεσοι Έλεγχοι Ομάδες (Groups)
ACL: Διαχείριση δικαιωμάτων ανά υποκείμενο: δύσκολη Λύση: Ομάδες (Groups) – Απλοποιούν την εξουσιοδότηση Χρήστες με «παρεμφερή» δικαιώματα πρόσβασης, θα καταχωρηθούν σε μια ομάδα Στη συνέχεια, εφαρμόζεται η πολιτική εξουσιοδότησης στην ομάδα Gollmann o. 74 Δικαιώματα Πρόσβασης (Windows) -σύστημα αρχείων NTFS. Σε Λ.Σ. με Windows (με σύστημα αρχείων NTFS) κάθε αρχείο ή φάκελος αποθηκεύεται στο δίσκο ή στην κατάτμηση (partition) του συστήματος, μαζί με μια Λ.Ε.Π (ACL) που απαριθμεί τους χρήστες ή τις ομάδες χρηστών (user groups) του συστήματος (ή/και του τοπικού δικτύου) που έχουν πρόσβαση στο αρχείο/φάκελο, καθώς και το είδος των δικαιωμάτων πρόσβασης. Συχνά αναφέρονται και ως «δικαιώματα NTFS» (NTFS permissions) διότι προκειμένου να εφαρμοστεί η πολιτική εξουσιοδότησης στους πόρους ενός δίσκου ή κατάτμησης (partition), θα πρέπει ο δίσκος αυτός (ή η κατάτμηση) να έχει διαμορφωθεί (format) με βάση το σύστημα αρχείων NTFS. Στη συνέχεια αναφέρονται ενδεικτικά τα βασικότερα δικαιώματα πρόσβασης σε αρχεία ενός συστήματος NTFS: Ανάγνωση (Read): Ανάγνωση των περιεχομένων, του ιδιοκτήτη και των δικαιωμάτων του αρχείου Εγγραφή (Write): Εγγραφή ή προσθήκη στα περιεχόμενα του αρχείου Ανάγνωση & Εκτέλεση (Read and Execute): Ανάγνωση των περιεχομένων, του ιδιοκτήτη και των δικαιωμάτων του αρχείου, και εκτέλεση του αρχείου (αν το αρχείο είναι πρόγραμμα) Τροποποίηση (Modify): Ανάγνωση, Εγγραφή, Διαγραφή, Εκτέλεση Πλήρης Έλεγχος (Full Control) – Ανάγνωση, Εγγραφή, Τροποποίηση, Εκτέλεση, Αλλαγή δικαιωμάτων, Αλλαγή Ιδιοκτήτη (owner)

Ομάδες χρηστών (Groups)
Υποκείμενα Ομάδες Αντικείμενα DAC και ομάδες. Ο καθορισμός των δικαιωμάτων πρόσβασης σε αντικείμενα βασίζεται είτε στην ταυτότητα (identity) των υποκειμένων είτε στην ομάδα (user group) στην οποία ανήκουν: Χρήστες με παρεμφερείς αρμοδιότητες-δικαιώματα μπορούν να κατηγοριοποιηθούν σε μια ομάδα (π.χ ομάδα Guest, ομάδα Administrators, κ.λ.π) και στη συνέχεια να εφαρμοστεί η πολιτική εξουσιοδότησης στην ομάδα, χωρίς να χρειάζεται να καθοριστούν τα δικαιώματα πρόσβασης για κάθε χρήστη της ομάδας ξεχωριστά. Κάθε χρήστης «κληρονομεί» τα δικαιώματα της ομάδας στην οποία ανήκει.

Windows: Ενδιάμεσοι Έλεγχοι Προνόμια (Privileges)
Μια πολιτική ελέγχου πρόσβασης μπορεί να αναφέρεται στις λειτουργίες (operations) που μπορεί να αποτελέσει ένας χρήστης π.χ. Backup, shutdown, change time.. Ta προνόμια μπορούν να θεωρηθούν ως ενδιάμεσο στρώμα (layer) μεταξύ υποκειμένων & λειτουργιών Gollmann p. 75

Ομάδες και Άρνηση Δικαιώματος (Negative permissions - Deny)
(Gollmann, 2010) Gollmann p. 74 Άρνηση πρόσβασης στο χρήστη s1 για το αντικείμενο ο1 παρότι η πρόσβαση επιτρέπεται στην ομάδα g1. Policy conflict

Άρνηση Δικαιώματος (Negative permissions -Deny)

Εξουσιοδότηση DAC Συμπεράσματα
Πλεονεκτήματα Ευέλικτο μοντέλο Εύκολο στην υλοποίηση Μειονεκτήματα Οι χρήστες είναι υπεύθυνοι για την επιβολή της πολιτικής ασφαλείας Δύσκολη διαχείριση Πλεονεκτήματα και Μειονεκτήματα του μοντέλου DAC. Το μοντέλο εξουσιοδότησης DAC είναι σχετικά εύκολο στην υλοποίηση, χρησιμοποιείται ευρέως σε Web-based εφαρμογές και προσφέρει υψηλό βαθμό ευελιξίας, καθώς οι χρήστες του συστήματος μπορούν να ελέγξουν οι ίδιοι την πρόσβαση στους πληροφοριακούς πόρους των οποίων έχουν την ευθύνη. Στον αντίποδα, τα μοντέλα DAC δεν προσφέρουν επαρκείς τρόπους διασφάλισης της ροής των πληροφοριών, αφού στην πραγματικότητα καθιστούν τους χρήστες υπεύθυνους για την επιβολή της πολιτικής ασφάλειας (βλέπε Μελέτη Περίπτωσης, στη συνέχεια). Ως εκ τούτου η διαχείριση των μηχανισμών υλοποίησης της πολιτικής εξουσιοδότησης, αλλά και η επίβλεψη των αποτελεσμάτων τους καθίσταται δύσκολη. Σε μεγάλα και πολύπλοκα συστήματα, όπου συνήθως απαιτείται η κεντρική διαχείριση της ασφάλειας των συστημάτων, ή υπάρχει η ανάγκη για πολλαπλά επίπεδα ασφαλείας, ίσως το μοντέλο DAC δεν βρίσκει το ιδανικό πεδίο για την εφαρμογή του.

(Sandhu, 1993) Εξουσιοδότηση DAC - Μελέτη Περίπτωσης Επίθεση Δούρειου Ίππου (Trojan horse attack) Robert: read, write Classified Robert The active entities in a system are usually processes executing programs on behalf of users. Therefore, information flow between objects, and thereby between security classes, is carried out by processes. Information can potentially flow from every object that a process reads to every object that it writes. In the absence of knowledge about what a given program does, we must assume the worst case and say that wherever there is a potential for information flow, the flow actually occurs. Said another way, we must be conservative and ensure that programs simply do not have the ability to cause information flows contrary to the given policy. Before showing how the Bell-LaPadula model' addresses this objective. I introduce some basic abstractions for access control models. To understand access control and computer security, we must first understand the distinction between users and subjects. This distinction is fundamental but often is treated imprecisely, leading to undue confusion about the objectives of computer security. We understand that a user is a human being. And we assume that each human TS-AKLQWXYZFigure 3. Smith's lattice. being known to the system is recognized as a unique user. Stated another way, the unique human named Jane Doe cannot have more than one user identity in the system. If Jane Doe is not an authorized user of the system, she has no user identity. Conversely, if she is an authorized user, she is known by exactly one user identity, say, J Doe. Clearly this assumption can he enforced only by adequate administrative controls, which we assume are in place. This assumption is not required for some of the policies considered in this article. At the same time, it is crucial for policies such as Lipncr's integrity lattice and Chinese Walls, which are discussed later. This assumption is often violated in current systems. (It is worth observing that the converse requirement, that each user identifier in the system be associated with exactly one human being, is critical to maintaining strict accountability. The use of shared user-identifiers to facilitate sharing is usually applied only because the system lacks convenient facilities for such sharing. In a properly designed system, there should be no need for this artifice.) We understand a subject to be a process in the system; that is, a subject is a program in execution. Each subject is associated with a single user, with the subject executing on the user's behalf. In general, a user can have many subjects concurrently running in the system. Every time a user logs in to the system, the user does so as a particular subject. (Note that access control models assume that identification and authentication of users takes place in a secure and correct manner, and are concerned with what happens afterward.) Different subjects associated with the same user can obtain different sets of access rights. Suppose that top-secret user John logs in at the secret level. In user-subject terminology, we interpret this as follows: First, there is a unique user, John, cleared to top secret; second. John can have subjects executing on his behalf at every level dominated by top secret. For now, assume that each subject runs at a fixed security level. (Below, we see that the security level of subjects can be changed in some models.) The access rights of subjects to objects in a system are conceptually represented by an access matrix.' This matrix has a row for every subject and a column for every object. A subject can also be an object in the system; for example, one process can execute suspend and resume operations on another process. In general, all subjects arc also objects, but not all objects are subjects. The cell for row a and column o is denoted by [a, o] and contains a set of access rights specifying the authorization of subject a to perform operations on object o. For example, read E IS, o] authorizes a to read o. Operations authorized by the access matrix are the only ones that can be executed. In the access matrix, all users are also regarded as subjects in their own right. A subject retains the access rights of the user, even when the user is not engaged in any activity in the system. The access matrix is usually sparse and is stored in a system using access control lists, capabilities, relations, or another data structure suitable for efficient sparse-matrix storage. The access matrix is a dynamic entity, and its individual cells can be modified by subjects. For example, if subjects is the owner of object o (that is, own E [a, o]), then a typically can modify the contents of all cells in the column corre sponding to o. In this case, the owner of an object has complete discretion regarding access to the owned object by other subjects. Such access controls are said to be discretionary.November 1993 The access matrix also changes with the addition and deletion of subjects and objects. (The typical access control on files and directories, provided by popular multiuser operating systems on the basis of protection bits, is an example of discretionary access control. Another example of discretionary access control is the access control on relations and parts of relations provided by popular relational database management systems Ivan: read, write REJECTED! Black is not allowed To access Classified Non Classified Read Classified Ivan

Εξουσιοδότηση DAC - Μελέτη Περίπτωσης Επίθεση Δούρειου Ίππου (Trojan horse attack)
Robert: read, write TH Reads Classified Address Book Manager Robert’s Classified Robert Uses shared program By themselves, discretionary access controls are inadequate for enforcing information flow policies. Their basic problem is that they provide no constraint on copying information from one object to another. (There are also other, more subtle problems with discretionary access controls, notably concerning the so-called safety problem' for propagation of access rights.) Suppose that Tom, Dick, and Harry are users and that Tom has a confidential file Private that he wants Dick to read but doesn't want Harry to read. Tom can authorize Dick to read the file by entering read in [Dick, Private]. (Assume that Dick does not thereby have the authority to grant the read right for Private to other users, such as Harry.) Dick can easily subvert Tom's intention by creating a new file called Copy-ofPrivate and copying the contents of Private into it. As the creator of Copy-ofPrivate, Dick has the authority to grant read access for it to any user, including Harry; that is, Dick can enter read in [Harry, Copy-of-Private]. Then, for all practical purposes, Harry can read Private as long as Dick keeps Copy-ofPrivate reasonably up to date with respect to Private. This situation is actually worse than the above scenario indicates. So far, I have portrayed Dick as a cooperative participant in this process. Now suppose Dick is Tom's trusted confidant and would not deliberately subvert Tom's intentions regarding the Private file. However, Dick uses an ingenious text editor that Harry gave to him. This editor provides all the editing services that Dick needs. In addition, Harry has also programmed the editor to create the Copy-of-Private file and to grant Harry the right to read Copy-of-Private. This kind of Trojan horse software performs normal functions expected by its user, but also engages in surreptitious activities to subvert security. A similar Trojan horse that Harry created and Tom executed could actually grant Harry the privilege to directly read Private. We can require that all software run on the system be free of Trojan horses, but this is hardly practical, particularly if we wish to guarantee this freedom with a high degree of assurance. The solution is to impose mandatory controls that cannot be bypassed, even by Trojan horses. Ivan, Robert: read, write TH Copies Classified To Ivan’s Directory Robert’s Classified Inserts Trojan Horse Into shared program Ivan

Έλεγχος Ροής Πληροφορίας Information Flow Control
(Sandhu, 1993) Ροή πληροφορίας σε ένα σύστημα: Yποκείμενα απoκτούν πρόσβαση σε αντικείμενα, π.χ. : Διεργασίες  αρχεία/κατάλογοι Διεργασίες  Διεργασίες Διεργασίες  Εγγραφές ΒΔ … Έλεγχός ροής Αντιστοίχιση σε υποκείμενα & αντικείμενα, ετικετών ασφάλειας (Security Labels) Κανόνες στη ροή πληροφορίας μεταξύ οντοτήτων με διαφορετικές ετικέτες Information flow policies are concerned with the flow of information from one security class to another. In a system. information actually flows from one object to another. The models I discuss treat "object" as an undefined primitive concept. An object can be informally defined as a container of information. Typical examples of objects are files and directories in an operating system, and relations and tuples in a database. Information flow is usually controlled by assigning every object a security class, also called a security label. Whenever information flows from object x to object y, there is an accompanying information flow from the security class of x to the security class of y. Henceforth, when I talk about information flowing from security class A to security class B, visualize information flowing from an object labeled A to an object labeled B. Bad subject Object Other read write Higher level Lower level

Information Flow Policies
(Sandhu, 1993) Ιnformation flow policy Α triple <SC, →, ⊕> where SC is a set of security classes → ⊆ SC x SC is a binary can-flow relation on SC, and ⊕ : SC x SC →SC is a binary join operator Examples A → B (info can flow from A to B) A ↛ B (info cannot flow from A to B) A ⊕ B = C (label objects that contain info from A and B, with sec. label C) (Denning, 1976)

(Sandhu, 1993)

(Sandhu, 1993) : An information flow policy forms a finite lattice (Denning, 1976) (Figure 1 (b))

Orders and lattice partial order of a set: binary relation that is
transitive: a ≥ b and b ≥ c then a ≥ c reflexive: a ≥ a anti-symmetric/acyclic: a ≥ b and b ≥ a then a = b total order: like a chain (either a ≥ b or b ≥ a) lattice: every pair of elements have a least upper bound, and a greatest lower bound Hasse diagrams depict a partial order (Sandhu, 1993) (DTM course - Daniel Trivellato, 2008)

(Sandhu, 1993) A totally ordered lattice TS ≥ S ≥ C ≥ U There are no incomparable classes A ⊕ B = max(A,B)

(Sandhu, 1993) The two lattices (the totally ordered and the subset lattice) are often combined (military and government)

The Product Lattice Levels: TS, S and TS > S
(DTM course - Daniel Trivellato, 2008) The Product Lattice Levels: TS, S and TS > S Compartments: Nuclear, Chemical TS, {Nuclear, Chemical} TS, {Nuclear} TS, {Chemical} S, {Nuclear, Chemical} TS, {} S, {} S, {Nuclear} S, {Chemical} the partial order dominates: (L1,C1) ≥ (L2,C2) iff L1 ≥ L2 and C2 C C1 lub((TS, {Nuclear}), (S, {Nuclear, Chemical})) = glb((TS, {Nuclear}), (S, {Nuclear, Chemical})) = (TS, {Nuclear, Chemical}) (S, {Nuclear})

Εξουσιοδότηση «Κατ’ Απαίτηση» Mandatory Access Control (MAC)
(Sandhu, 1993) Eυθύνη πολιτικής εξουσιοδότησης: Aπό το χρήστη στο σύστημα Η πρόσβαση καθορίζεται, ελέγχοντας ετικέτες ασφάλειας (security labels) Ετικέτες αποδίδονται σε υποκείμενα (security classifications), Και σε αντικείμενα (security clearance) Έμφαση: Eμπιστευτικότητα (Bell-Lapadula) Ακεραιοτητα (Biba) 4.2 Classical Mandatory Policies Mandatory policies govern access on the basis of classification of subjects and objects in the system. Each user and each object in the system is assigned a security level. The security level associated with an object reflects the sensitivity of the information contained in the object, i.e, the potential damage which could result from unauthorized disclosure of the information. The security level associated with a user, also called clearance, reflects the user's trustworthiness not to disclose sensitive information to users not cleared to see it. In the simplest case, the security level is an element of a hierarchical ordered set. In the military and civilian government arenas, the hierarchical set generally consists of Top Secret (TS), Secret (S), Confidential (C), and Unclassified (U), where TS > S > C > U. Each security level is said to dominate itself and all others below it in this hierarchy. Access to an object by a subject is granted only if some relationship (depending on the type of access) is satisfied between the security levels associated with the two. In particular, the following two principles are required to hold. Read down A subject's clearance must dominate the security level of the object being read. Write up A subject's clearance must be dominated by the security level of the object being written. Satisfaction of these principles prevents information in high level objects (i.e., more sensitive) to flow to objects at lower levels. The effect of these rules is illustrated in figure 7. In such a system information can only flow upwards or within the same security class. It is important to understand the relationship between users and subjects in this context. Let us say that the human user Jane is cleared to S, and assume she always signs on to the system as an S subject (i.e., a subject with clearance S). Jane's subjects are prevented from reading TS objects by the read-down rule. The write-up rule, however, has two aspects that seem at first sight contrary to expectation. Firstly, Jane's S subjects can write a TS object (even though they cannot read it). In particular, they can overwrite existing TS data and therefore destroy it. Due to this integrity concern, many systems for mandatory access control do not allow write up; but limit writing to the same level as the subject. At the same time write up does allow Jane's S subjects to send electronic mail to TS subjects, and can have its benefits. Secondly, Jane's S subjects cannot write C or U data. This means, for example, that Jane can never send electronic mail to C or U users. This is contrary to what happens in the 7 paper world, where S users can write memos to C and U users. This seeming contradiction is easily eliminated by allowing Jane to sign to the system as a C, or U, subject as appropriate. During these sessions she can send electronic mail to C or, U and C, subjects respectively. In other words a user can sign on to the system as a subject at any level dominated by the user's clearance. Why then bother to impose the write-up rule? The main reason is to prevent malicious software from leaking secrets downward from S to U. Users are trusted not to leak such information, but the programs they execute do not merit the same degree of trust. For example, when Jane signs onto the system at the level her subjects cannot read S objects, and thereby cannot leak data from S to U. The write-up rule also prevents users from inadvertently leaking information from high to low. In additional to hierarchical security levels, categories (e.g., Crypto, NATO, Nuclear) can also be associated with objects and subjects. In this case the classification labels associated with each subject and each object consists of a pair composed of a security level and a set of categories. The set of categories associated with a user reflect the specific areas in which the user operates. The set of categories associated with an object reflect the area to which information contained in objects are referred. The consideration of categories provides a finer grained security classification. In military parlance categories enforce restriction on the basis of the need-to-know principle, i.e., a subject should be only given those accesses which required to carry out the subject's responsibilities. Mandatory access control can as well be applied for the protection of information integrity. For example, the integrity levels could be Crucial (C), Important (I), and Unknown (U). The integrity level associated with an object reflects the degree of trust that can be placed in the information stored in the object, and the potential damage that could result from unauthorized modification of the information. The integrity level associated with a user reflects the user's trustworthiness for inserting, modifying or deleting data and programs at that level. Principles similar to those stated for secrecy are required to hold, as follows. Read up A subject's integrity level must be dominated by the integrity level of the object being read. Write down A subject's integrity level must dominate the integrity level of the object being written. Satisfaction of these principles safeguard integrity by preventing information stored in low objects (and therefore less reliable) to flow to high objects. This is illustrated in figure 8. Controlling information flow in this manner is but one aspect of achieving integrity. Integrity in general requires additional mechanisms, as discussed in [CFMS94, San94]. Note that the only difference between figures 7 and 8 is the direction of information flow, being bottom to top in the former case and top to bottom in the latter. In other words both cases are concerned with one-directional information flow. The essence of classical mandatory controls is one-directional information flow in a lattice of security labels. For further discussion on this topic see [San93].

Εξουσιοδότηση MAC Το Μοντέλο Bell-LaPadula

(Sandhu, 1993) Το μοντέλο Bell-LaPadula Έμφαση στην εμπιστευτικότητα (confidentiality) No read up: Κανένα υποκείμενο δε μπορεί να διαβάσει δεδομένα ενός υψηλότερου επιπέδου (simple security property) No write down: Κανένα υποκείμενο δε μπορεί να γράψει δεδομένα σε ένα χαμηλότερο επίπεδο (*-property) (Bell and LaPadula, 1973) Bell and LaPadulas formalized the concept of mandatory access controls. defining a model commonly bearing their names. Numerous variations of the model have since been published. Consequently, the exact meaning of the BellLaPadula model is not clear. In this article, I take a minimalist approach and define a model, called BLP, that is generally the smallest model capturing the essential access control properties I want to illustrate. The notation and precise formulation of the rules of BLP are substantially different from those of the original Bell-LaPaduIa model. BLP is more in line with the formulations authors of more recent literature have used. The key idea in BLP is to augment discretionary access controls with mandatory access controls to enforce information flow policies. BLP takes a two-step approach to access control. First is a discretionary access matrix D, whose contents can be modified by subjects (in a way we don't need to specify here). However, authorization in D is not sufficient for an operation to he carried out. Second, the operation must be authorized by the mandatory access control policy. over which users have no control. Mandatory access control policy is expressed in terms of security labels attached to subjects and objects. A label on an object is called a security classification, while a label on a user is called a security clearance. A user labeled secret can run the same program, such as a text editor, as a subject labeled secret or as a subject labeled unclassified. Even though both subjects run the same program on behalf of the same user, they obtain different privileges due to their security labels. It is usually assumed that once assigned, the security labels on subjects and objects cannot be changed (except by the security officer). This assumption, known as tranquility, can be relaxed in a secure manner (see below). With X. signifying the security label of the indicated subject or object, the specific mandatory access BLP rules are as follows: Simple-security property: Subject s can read object o only if k(s) k(o). *-property (read as star-property): Subject s can write object o only if X(s) 5 X(o).14 COMPUTER Read access implies a flow from object to subject, hence the requirement that k(s) z k(o) or equivalently X(o) X(s) (that is, 2.(o) can flow to 2(s)). Write access conversely implies a flow from subject to object, hence the requirement that k(s) X(o) or equivalently k(s) — X(o) (that is. k(s) can flow to k(o)). Write access is interpreted here as write only. In some models, write access is interpreted to mean read and write, with append access provided for write only. These properties are stated in terms of read and write operations. In a real system, additional operations will exist (for example, create and destroy objects). Considering read and write suffices to illustrate the main points. For example, create and destroy are also constrained by the *-property because they modify the state of the object in question. Mandatory controls are formulated as "only if" conditions; that is, they are necessary but not sufficient for the indicated access. In operational terms, we can visualize the mandatory controls as kicking in only after the checks embodied in the discretionary access matrix D have been satisfied. If D does not authorize the operation. we do not need to check the mandatory controls, since the operation will be rejected anyway. Equivalently. the mandatory controls can be checked first, followed by a check of the discretionary controls. The simple-security requirement applies to humans and programs equally, and the need for it is self-evident. On the other hand, the *-property is not applied to human users, but rather to programs. Human users are trusted not to leak information. A secret user can write an unclassified document because we assume that he or she will put only unclassified in formation in it. Programs, on the other hand, are not trusted because they can have embedded Trojan horses. The *-property prohibits a program running at the secret level from writing to unclassified objects, even it it is permitted to do so by discretionary access controls. A user labeled secret who wishes to write an unclassified object must log in as an unclassified subject. A curious aspect of the *-property is that an unclassified subject can write a secret file. This means that secret data can be destroyed or damaged, perhaps accidentally, by unclassified subjects. To prevent this integrity problem, a modified *-property is sometimes used that requires X(s) = X(o); that is, subjects can write at their own level but cannot "write up." Here's how these properties impact the previous Tom, Dick, and Harry Trojan horse example. Suppose Tom and Dick are secret users and Harry is an unclassified user. Tom and Dick can have secret and unclassified subjects, while Harry can have only unclassified subjects. Now, let Tom create the secret file Private via a secret subject. The simple-security property will prevent Harry's subjects from being able to directly read the file Private. The simple-security and *-properties will ensure that Harry's subjects cannot surreptitiously read Copy-of-Private because Copy-of-Private will either be labeled secret (or above) or will not contain any information from Private. Specifically, if Dick's Trojan horse-infected secret subject creates Copy-of-Private, it will be a secret (or above) file and Harry's unclassified subjects will not be able to read it. On the other hand, Dick's unclassified subject running the Trojan horse cannot read Private and copy it to Copy-of-Private. BLP mandatory access controls only prevent information flow between security classes. Thus, if Harry was a secret user like Tom and Dick, these controls would not solve the problem. Above 1 noted that the tranquility assumption requires that security labels of subjects and objects not change. This assumption can be relaxed in several different ways, some securely and others insecurely (that is, they introduce information flow contrary to the given lattice). Suppose we allow a subject s to change the security label of object o from X(o) to A.'(o), with the stipulation that 7v(s) = 7.(o), and T.' (o) > X(o): for example, an unclassified subject upgrades the label of a file from unclassified to secret. Such a change is secure, because it causes no information flow from secret to unclassified. Now suppose we allow a secret subject to perform the same change; that is, we replace the stipulation that X(s) = X(o) with "it(s)>X(o). This latter case is insecure, because upgrading an unclassified file to secret by a secret subject will make this file disappear from the view of unclassified subjects, thereby opening a means for communicating information from secret to unclassified; this could be exploited by Trojan horses. A secret user can securely upgrade an unclassified file to secret by logging in as an unclassified subject. A flow from object to subject A flow from subject to object

Εξουσιοδότηση MAC Το Μοντέλο Biba
Στόχος: Προστασία «καθαρών» υποκειμένων/αντικειμένων από «βρώμικη» πληροφορία

(Sandhu, 1993) Το μοντέλο Biba Έμφαση στην ακεραιότητα (integrity) No read-down: Κανένα υποκείμενο δε μπορεί να διαβάσει δεδομένα από ένα χαμηλότερο επίπεδο (Single Integrity property) No write-up: Κανένα υποκείμενο δε μπορεί να γράψει δεδομένα σε ένα υψηλότερο επίπεδο (Integrity *-property) (Biba, 1977) Confidentiality considerations motivated the mandatory controls in the BellLaPadula model. Biba proposed that similar controls could be formulated for integrity."' The basic concept in Biba's model is that low-integrity information should not be allowed to flow to high-integrity objects, whereas the opposite is acceptable. Biba proposed several ways to use mandatory controls for integrity objectives. The best known of these is called strict integrity. In the usual formulation of the Biba model, high integrity is placed toward the top of the lattice of security labels and low integrity at the bottom. With this formulation, the permitted flow of information is from top to bottom, directly opposite that of the Bell-LaPadula model and Denning's axioms. This led Biba to propose the following mandatory controls, in analogy with the mandatory controls of the BLP model (tii denotes the integrity label of a subject or object): Simple-integrity property: Subject s can read object o only if w(s) co(o). Integrity *-property: Subject s can write object o only if co(s) co(o). These properties are said to be duals of the corresponding properties in BLP. There is nothing intrinsic about placing high integrity at the top of the lattice (or placing high confidentiality at the top, for that matter). Top and bottom are relative terms coined for convenience and have no absolute significance. But information flow in the Biba model can be brought into line with the BLP model by simply saying that low integrity is at the top of the lattice and high integrity at the bottom. This forces us to invert the dominance relation in the Biba model so that low integrity dominates high integrity. With this viewpoint, we can use the mandatory controls of the BLP model to enforce the information flows required by the Biba model. This situation is symmetrical. We could equally well invert the BLP (and Denning) lattices to put low confidentiality at the top and high confidentiality at the bottom, and employ the mandatory controls of Biba to enforce the information flows. There is no fundamental difference between the Bibs and BLP models. Both are concerned with information flow in a lattice of security classes, with information flow allowed only in one direction in the lattice. The BLP model allows information flow upward in the lattice, and the Biba model allows it downward. Since direction is relative, a system that can support one of these models can also support the other (given some straightforward re mapping of labels to invert the dominance relation as needed). It is often suggested that the BLP and Biba models could be combined in situations where both confidentiality and integrity are of concern. If a single label is used for both confidentiality and integrity, the models impose conflicting constraints. One adverse factor to combining them is that a subject can read or write only those objects that have exactly the same security label as the subject. This amounts to the trivial policy of no information flows between security classes as discussed in Example 1. Σημείωση: Ένα μοντέλο MAC μπορεί να συμπληρώνει και όχι απαραίτητα να αντικαθιστά ένα μοντέλο DAC (π.χ., O έλεγχος πρόσβασης MAC εκτελείται μετά από τον έλεγχο πρόσβασης DAC)

Biba Cannot “write up” Cannot “read down”

Μοντέλα ΜAC Σενάριο Εφαρμογής (Bell-LaPadula)
Επίπεδο Ασφάλειας Subject Object Top Secret George Personnel files Secret Joan Confidential Henry Application logs Unclassified Mark System manuals O George μπορεί να διαβάσει όλα τα αρχεία/έγγραφα Η Joan δεν μπορεί να διαβάσει τα αρχεία προσωπικού O Henry μπορεί να διαβάσει μόνον τα logs & manuals O Henry δεν μπορεί να γράψει στα manuals

(Sandhu, 1993)

Μοντέλο Biba - Επεκτάσεις Δυναμικές Πολιτικές
Αρχή “Low watermark” Περίπτωση: LOMAC, 2000 Το σύστημα υποστηρίζει δύο επίπεδα ασφάλειας High Integrity (π.χ. System files) Low Integrity (π.χ. Network) Όταν μια διεργασία High δέχεται input από το δίκτυο, υποβιβάζεται στο επίπεδο Low

Windows Vista Mandatory Integrity Control (MIC)

Επεκτάσεις MAC Compartmented security mode
Μια ετικέτα ασφάλειας (secu-rity label) μπορεί να περιέχει Επίπεδα Ασφάλειας (Classifications, Clearances) Κατηγορίες (Categories) Compartment: Σύνολο από κατηγορίες * Least privilege: Οι κατηγορίες στις ετικέτες ασφάλειας, υπηρετούν την Αρχή της Αναγκαίας Γνώσης (Need to know)

Έλεγχος Πρόσβασης(164,287,292) Μοντέλα ΜAC
(Anderson, 2008) *

Gollmann. p. 79 (Gollmann, 2010) *

Πλεονεκτήματα Το σύστημα ελέγχει την επιβολή της πολιτικής εξουσιοδότησης και όχι οι χρήστες Καλύτερος έλεγχος στη ροή της πληροφορίας από ασφαλή προς μη ασφαλή επίπεδα και αντίστροφα Αντιμετωπίζει με επιτυχία προβλήματα τύπου “επίθεση trojan horse” Μειονεκτήματα Έλλειψη ευελιξίας (στατικές πολιτικές) 5 Administration of Authorization Administrative policies determine who is authorized to modify the allowed accesses. This is one of the most important, and least understood, aspects of access controls. In mandatory access control the allowed accesses are determined entirely on basis of the security classification of subjects and objects. Security levels are assigned to users by the security administrator. Security levels of objects are determined by the system on the basis of the levels of the users creating them. The security administrator is typically the only one who can change security levels of subjects or objects. The administrative policy is therefore very simple. Discretionary access control permits a wide range of administrative policies. Some of these are described below. Centralized: A single authorizer (or group) is allowed to grant and revoke authorizations to the users. Hierarchical: A central authorizer is responsible for assigning administrative responsibilities to other administrators. The administrators can then grant and revoke access authorizations to the users of the system. Hierarchical administration can be applied, for example, according to the organization chart. Cooperative: Special authorizations on given resources cannot be granted by a single authorizer but needs cooperation of several authorizers. Ownership: A user is considered the owner of the objects he/she creates. The owner can grant and revoke access rights for other users to that object. Decentralized: In decentralized administration the owner of an object can also grant other users the privilege of administering authorizations on the object. Within each of these there are many possible variations. Role-based access control has a similar wide range of possible administrative policies. In this case roles can also be used to manage and control the administrative mechanisms. Delegation of administrative authority is an important area in which existing access control systems are deficient. In large distributed systems centralized administration of access rights is infeasible. Some existing systems allow administrative authority for a specified subset of the objects to be delegated by the central security administrator to other security administrators. For example, authority to administer objects in a particular region can be granted to the regional security administrator. This allows delegation of administrative authority in a selective piecemeal manner. However, there is a dimension of selectivity that is largely ignored in existing systems. For instance, it may be desirable that the regional security administrator be limited to granting access to these objects only to employees who work in that region. Control over the regional administrators can be centrally administered, but they can have considerable autonomy within their regions. This process of delegation can be repeated within each region to set up sub-regions and so on.

Protection Rings 1 2 3 Each subject (process) and each object is assigned a number, depending on its ‘importance’, e.g. 0 – operating system kernel 1 – operating system 2 – utilities 3 – user processes Numbers correspond to concentric protection rings, ring 0 in centre gives highest degree of protection. If a process is assigned number i, we say the process “runs in ring i”. Access control decisions are made by comparing the subject’s and object’s ring. Protection rings are mainly used for integrity protection.

Έλεγχος Πρόσβασης Multilevel & Multirateral Security
Συχνά, ο σκοπός δεν είναι να προστατέψουμε τη ροή της πληροφορίας «καθέτως» (δηλαδή, εντός ενός συστήματος), αλλά «οριζοντίως» (π.χ. μεταξύ διαφορετικών συστημάτων ή τμημάτων του ίδιου συστήματος Μοντέλα: Chinese Wall, BMA,…

Multilateral Security
Ο John συμβουλεύει την Bank A για επενδυτικά προγράμματα. H Bank B συμβουλεύει τον John για επενδυτικά προγράμματα: Σύγκρουση συμφερόντων (COI-Conflict Of Interest) Multilateral Security Μοντέλο Σινικού Τείχους (Chinese Wall)

Έλεγχος Πρόσβασης Μοντέλα ΜAC – To μοντέλο Clark-Wilson (1987)
Χαμηλής διαβάθμισης – UDI (Unconstrained Data Items) Υψηλής διαβάθμισης – CDI (Constrained Data Ιtem) Δίνει έμφαση στην ακεραιότητα Οι ταυτοποιημένοι χρήστες (Users) επιτρέπεται να τροποποιούν τα UDI Μια οντότητα (TP) τροποποιεί τα CDI εκ μέρους των χρηστών (TP–Transformation Procedures) Περίπτωση: ένα Σύστημα e-banking To profile της Kathy Οι πληροφορίες λογαριασμού της Kathy Η Kathy ενημερώνει το profile της Η TP ενημερώνει το λογαριασμό (Α) της Alice, ως συνέπεια της μεταφοράς 50$ από το λογαριασμό (Β) που η Alice διατηρεί στην τράπεζα

Έλεγχος Πρόσβασης Μοντέλα ΜAC – To μοντέλο Clark-Wilson

To μοντέλο Clark-Wilson
Η οντότητα IVP επαληθεύει την ορθότητα της συναλλαγής (well-formed transactions) τη συνέπεια των καταστάσεων (consistent states) H επαλήθευση γίνεται: Εσωτερικά Η νέα τιμή των CDI είναι ορθή Εξωτερικά Η αλλαγή στην κατάσταση του συστήματος έγινε ορθώς Η Kathy είχε 2000$ & κατέθεσε 50$, επομένως το νέο υπόλοιπο πρέπει να είναι 2050$ Η πίστωση του λογαριασμού Α της Alice με 50$, αντιστοιχεί στη χρέωση του λογαριασμού Β με 50$

To μοντέλο Clark-Wilson
Το μοντέλο επίσης υποστηρίζει: Καταγραφή συμβάντων (auditing) Διάκριση Καθηκόντων (Separation of duties) Όλες οι Συναλλαγές καταγράφονται π.χ. Αν ένας πελάτης μεταφέρει άνω των 10000$, το σύστημα απαιτεί την έγκριση από δύο οντότητες

Towards a new access model…

To Μοντέλο RBAC Role-Based Access Control
Motivation DAC is too flexible (allows wrong behaviour) Users do not “own” info for which they have access Need for centrally controlling and maintaining access rights MAC is too rigid (extremely high security) Gives emphasis on sensitivity labels of subjects & objects * Solution: RBAC Access is through roles Cases: Hospital, Bank,… Advantages Extends old access model (= users related to permissions) Roles are relatively stable, while users come and go Data abstraction: Emphasis to functions & information Reduce complexity, cost, error in assigning user permissions (Ferraiolo and Kuhn, 1992) (NIST Standard, 2001) (From In many organizations, the end users do not ``own'' the information for which they are allowed access. For these organizations, the corporation or agency is the actual ``owner'' of system objects as well as the programs that process it. Control is often based on employee functions rather than data ownership. Access control decisions are often determined by the roles individual users take on as part of an organization. This includes the specification of duties, responsibilities, and qualifications. For example, the roles an individual associated with a hospital can assume include doctor, nurse, clinician, and pharmacist. Roles in a bank include teller, loan officer, and accountant. Roles can also apply to military systems; for example, target analyst, situation analyst, and traffic analyst are common roles in tactical systems. A role based access control (RBAC) policy bases access control decisions on the functions a user is allowed to perform within an organization. The users cannot pass access permissions on to other users at their discretion. This is a fundamental difference between RBAC and DAC. Security objectives often support a higher level organizational policy, such as maintaining and enforcing the ethics associated with a judge's chambers, or the laws and respect for privacy associated with the diagnosis of ailments, treatment of disease, and the administering of medicine with a hospital. To support such policies, a capability to centrally control and maintain access rights is required. The security administrator is responsible for enforcing policy and represents the organization. The determination of membership and the allocation of transactions to a role is not so much in accordance with discretionary decisions on the part of a system administrator, but rather in compliance with organization-specific protection guidelines. These policies are derived from existing laws, ethics, regulations, or generally accepted practices. These policies are non-discretionary in the sense that they are unavoidably imposed on all users. For example, a doctor can be provided with the transaction to prescribe medicine, but does not possess the authority to pass that transaction on to a nurse. RBAC is in fact a form of mandatory access control, but it is not based on Multilevel security requirements. As defined in the TCSEC, MAC is A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. [4] Role based access control, in many applications (e.g. [9] , [10] , [11] is concerned more with access to functions and information than strictly with access to information. The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users (granting membership) and the labeling (associate operational sensitivities) of objects within the DoD. The military policy is with respect to one type of capability: who can read what information. For these systems the unauthorized flow of information from a high level to a low level is the principal concern. As such, constraints on both reads and writes are in support of that rule. Within a role- based system, the principal concern is protecting the integrity of information: ``who can perform what acts on what information.'' A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization. Transactions are allocated to roles by a system administrator. Such transactions include the ability for a doctor to enter a diagnosis, prescribe medication, and add a entry to (not simply modify) a record of treatments performed on a patient. The role of a pharmacist includes the transactions to dispense but not prescribe prescription drugs. Membership in a role is also granted and revoked by a system administrator. Roles are group oriented. For each role, a set of transactions allocated the role is maintained. A transaction can be thought of as a transformation procedure [1] (a program or portion of a program) plus a set of associated data items. In addition, each role has an associated set of individual members. As a result, RBACs provide a means of naming and describing many-to-many relationships between individuals and rights. Figure 1 depicts the relationships between individual users, roles/groups, transformation procedures, and system objects. The term transaction is used in this paper as a convenience to refer to a binding of transformation procedure and data storage access. This is not unlike conventional usage of the term in commercial systems. For example, a savings deposit transaction is a procedure that updates a savings database and transaction file. A transaction may also be quite general, e.g. ``read savings file''. Note however, that ``read'' is not a transaction in the sense used here, because the read is not bound to a particular data item, as ``read savings file'' is. The importance of control over transactions, as opposed to simple read and write access, can be seen by considering typical banking transactions. Tellers may execute a savings deposit transaction, requiring read and write access to specific fields within a savings file and a transaction log file. An accounting supervisor may be able to execute correction transactions, requiring exactly the same read and write access to the same files as the teller. The difference is the process executed and the values written to the transaction log file. The applicability of RBAC to commercial systems is apparent from its widespread use. Baldwin [9] describes a database system using roles to control access. Nash and Poland [10] discuss the application of role based access control to cryptographic authentication devices commonly used in the banking industry. Working with industry groups, the National Institute of Standards and Technology has developed a proposed standard, ``Security Requirements for Cryptographic Modules,'' (Federal Information Processing Standard 140-1) [11] that will require support for access control and administration through roles. To date, these role based systems have been developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards. Role based access controls described in this paper address security primarily for application-level systems, as opposed to general purpose operating systems. *, *, * Concern: Who owns which info * Concern: Who reads/writes which info

Role-based Access Control (RBAC)
(Rajput &Cherukuri, 1996) Athos Aramis palace uniform DAC Porthos D'Artagnan weapons Athos palace Porthos RBAC Musketeer Aramis uniform D'Artagnan weapons

To Μοντέλο RBAC Role-Based Access Control
What is a Role? A job function or job title, with associated semantics Stable: activities or functions change less frequently Motivations for building a role Competency for specific tasks Physician, Pharmacist Authority and responsibility Project supervisor Duty assignments rotated through multiple users Duty physician, shift manager … Roles vs Groups Groups: Collection of users Role: Collection of users (one side) and of permissions (other) Groups: Easier to see group members than group permissions UNIX: Traversal of filesystem tree to see Group permissions Groups: decentralized assignment of permissions (Sandhu, 1997)

The RBAC Model (Ferraiolo and Kuhn, 2009, Li et al, 2007)

Role: Doctor Role: Nurse Role: Pharmacist Functions
Enter a diagnosis Prescribe medication (=read/write access to prescription files) Add an entry to a record of treatments performed on a patient .. Members: Dr. A. V. Smith, Dr. M. Kein,… Role: Nurse Read treatments performed on a patient … Members: Ms. D. J. Hail, Mr. A. Robins,… Role: Pharmacist Dispense (not prescribe) drugs (= read access to prescription files) Members: Ms. D. V. Mapel, Mr. A. F. Johnson,…

NIST RBAC Model (NIST Standard, 2001)

NIST RBAC Model 1. Flat RBAC (also referred to as RBAC0 )
(NIST Standard, 2001) (Sandhu, 1997) User: Human Being Typically, he/she may cor-respond to one or more subjects (active user processes) Role: Job function or job title Permission: High-level privilege; always positive. Typically, translated to an operation to one or more system objects. (Sandhu, 1997) (Ferraiolo et al, 1995) *

Operations and Objects
(Ferraiolo et al, 1995) (Rajput &Cherukuri, 1996) Operation. An execution of an a program specific function that’s invocated by a user. Object. An entity that contains or receives information, or has exhaustible system resources. OS Files or Directories DB Columns, Rows, Tables, Views Printer Disk Space Lock Mechanisms Database – Update Insert Append Delete Locks – Open Close Reports – Create View Print Applications – Read Write Execute SQL

User Assignment Χρήστες Ρόλοι Ένας χρήστης μπορεί να
(Ferraiolo and Kuhn, 2009) (Rajput &Cherukuri, 1996) Ένας χρήστης μπορεί να Υποδύεται έναν ή Περισσότερους ρόλους When a new person enters the organization, admin grants him/her membership to an existent role When a person’s function changes, the user membership to roles can be updated When a person leaves the organization, all memberships to all roles are deleted Χρήστες Ρόλοι Ανάπτυξη Ένας ρόλος μπορεί να Αντιστοιχεί σε έναν ή Περισσότερους χρήστες Τεχνική Υποστήριξη

User Assignment User.DB1 User.F1 User.F2 User.F3 User.DB1 Admin.DB1
♪ (Rajput &Cherukuri, 1996) Roles set Users set Permissions User.DB1 View Update Append User.F1 User.F2 User.F3 User.DB1 Admin.DB1 object User.F1 permissions User.F1 Read Write Execute User.DB1 object permissions

User Assignment aka: Role authorization
(Ferraiolo et al, 1995) Association of a user to a role can be subject to the following Give user no more privilege than necessary to his/her job Least Privilege Principle Role is not mutually exclusive with another role he/she is member of Not exceed numerical constraints that exist for role membership … *

Permission Assignment
ROLES set A prms can be assigned to one or more roles PRMS set Create Delete Drop Admin.DB1 View Update Append A role can be assigned to one or more prms User.DB1

NIST RBAC Model 1. Flat RBAC – User Sessions
(NIST Standard, 2001) (Sandhu, 1997) Session A mapping of one user to many roles In a session, a user may choose to (simultaneously) activate subset of roles he/she is member of Session Permissions available: union of permissions from activated roles A user should be allowed to login to a system with necessary roles Least Privilege principle (Sandhu, 1997)

Sessions The set of sessions that each user invokes. USER SESSION SQL
(Rajput &Cherukuri, 1996) The set of sessions that each user invokes. USER SESSION guest user admin invokes FIN1.report1 SQL DB1.table1 APP1.desktop

Role Activation A role can be activated if:
(Ferraiolo et al, 1995) A role can be activated if: User U authorized for the role being proposed for activation Activation not mutually exclusive with any other active role(s) of U Proposed op authorized for role that is proposed for activation Proposed operation is consistent with constraints …

ANSI RBAC Standard 1. Flat RBAC - Getting Formal..
(ANSI INCITS )

NIST RBAC Model 2. Hierarchical RBAC (also referred to as RBAC1 )
(NIST Standard, 2001) (Sandhu, 1997) Motivation When operations overlap, hierarchies of roles can be established Hierarchy Role-role relationship Models structure of enterprise Simplifies administration Manager role inherits permissions of Clerk role A user assigned to Manager role can activate the clerk role (Ferraiolo et al, 1995) Manager Administrator Clerk (Rajput &Cherukuri, 1996)

Roles Hierarchy: Example
(Ferraiolo and Kuhn, 2009) Membership to Doctor, implies access to transactions defined by: Intern, Healer, Doctor Membership to Healer: access only to resources allowed under Healer

NIST RBAC Model 2. Hierarchical RBAC (also referred to as RBAC1)
(NIST Standard, 2001) (Sandhu, 1997) Dermatologist Cardiologist Jill m e b r s h i p p r i v l e g “contains” “contains” CSD Secretary Specialist Comp Security Division “contains” MEL Secretary ITL Secretary Doctor “contains” NIST Secretary Employee a-Limited Hierarchies b-General Hierarchies (Rajput &Cherukuri, 1996) (Rajput &Cherukuri, 1996)

Inverted trees do not allow aggregation of resources from more than one role
Issue: there can be no sharing of resources between project 1 and project 2 roles Senior roles (3a, 3b) aggregate too much power (what about: fraud, mistakes?)

Hierarchical RBAC Limited Inheritance
Private Role (Sandhu et al, 1996) *

Hierarchical RBAC Limited Inheritance
(Sandhu, 1997)

ANSI RBAC Standard 2. Hierarchical RBAC-Getting Formal..
(ANSI INCITS , Li et al, 2007) (Li et al, 2007) Correct: r ≥ r’ Correct: condition:

NIST RBAC Model 3. Constrained RBAC (also referred to as RBAC2)
(NIST Standard, 2001) (Sandhu, 1997) (Sandhu et al, 1996) User assignment constraints Static SOD, max number of users/role, prerequisite roles,… Permission assignment constraints max number of roles/permission Permission p is assigned to r only if r possesses q ABAC (role-centric) Session constraints Dynamic SOD, max no of activated roles Terminate session if inactive too long,… Role hierarchy constraints Max number of senior roles /role *

Constrained RBAC Separation of Duties (SOD)
(Sandhu, 1997, Ferraiolo & Kuhn, 2009, NIST Standard, 2001) Problem: Fraud & errors from collaboration between job related capabilities Conflict of Interest (COI) e.g., Initiate & authorize payment, programmer and program tester,… Solution: Separation Of Duty (SOD) Tasks partitioning among roles to prevent gathering much authority Supports least privilege principle Two flavours: Static SOD (mutually exclusive roles) Compliance determined during user-role assignment Dynamic SOD Compliance determined during roles activation in user sessions System checks role AND user ID for checking access No one who performs the initiator role could also perform the authorizer role One can take both roles but not for a payment that he/she initiated !

Constrained RBAC Separation of Duties (SOD)
(NIST Standard, 2001) Constrained RBAC Separation of Duties (SOD) Constraints are inherited within a role hierarchy

Constrained RBAC Dynamic SOD
(NIST Standard, 2001) User authorized as member of a set of roles, which: don’t constitute COI when acted in independently, .. do constitute COI when acted in simultaneously ! Dynamic SOD provides greater flexibility User can be member of 2 roles, but cannot be active to both at the same time!

ANSI RBAC Standard 3. Constrained RBAC - Getting Formal.. (1/2)
(ANSI INCITS , Li et al, 2007)

ANSI RBAC Standard 3. Constrained RBAC - Getting Formal.. (2/2)
(ANSI INCITS , Li et al, 2007)

NIST RBAC Model 4. Symmetric RBAC
(NIST Standard, 2001) Motivation: Review permissions within the enterprise. Scenarios: A user departs Revoke permissions A user changes jobs or responsibilities in enterprise Revoke and/or give new Existing permissions obsolete … Level 1 Interface for the review of user-role assignment Level 2 Interface for review of roles inherited by the assigned roles Level 4 Interface for permission-role review for a user or role Complete set of objects associated with permissions … ♪

Role Engineering and Management
(Sandhu, 1997, Coyne et al, 2011) Role Engineering Develop an RBAC structure for an organization Tasks: Design roles in large systems What the users’ jobs are? Define minimum privileges Assign Permissions to Roles Assign Users to Roles Assign roles to roles (= define Hierarchies) Define & enforce Constraints Define policies for revoking memberships, permissions Challenges Who does it? Design roles in large systems,… Future: Waiting for ISO standard * (Dridi et al, 2004)

Role Engineering and Management
(Dridi et al, 2004)

Role Engineering and Administration
(Sandhu, 1997)

The ARBAC97 model for RBAC administration
(Sandhu, 1997) User-Role Assignment Permission-Role Assignment

The ARBAC97 model for RBAC administration
(Sandhu, 1997) Role-Role Assignment

Future: Adding Attributes to RBAC
(Kuhn et al, 2010) Motivation Support of dynamic attributes (e.g. time of day, network address,…) ABAC (attribute-based AC) Goal: Add attributes & rules to make RBAC simpler and flexible Option 7 (Dynamic Roles) Attributes used to determine the subject’s role * Rule: Allow access if subject is teller working from 7.30 am to 5.00 pm Option 8 (Attribute-centric) A role is just one of many attributes Option 9 (Role-centric) Attributes are added to constrain RBAC

Some of the Vendors Offering RBAC Products
*, ♪ (Rajput &Cherukuri, 1996)

2. Άλλα Θέματα στον Έλεγχο Πρόσβασης
2. Άλλα Θέματα στον Έλεγχο Πρόσβασης

Έλεγχος Πρόσβασης –Στρώματα Προστασίας Access Control Layers
Διαχειριστικοί Έλεγχοι Πολιτικές Διαδικασίες Διαχείριση προσωπικού Εκπαίδευση & επιμόρφωση Έλεγχος (Audit) Δοκιμές … Φυσικοί Έλεγχοι Ασφάλεια περιμέτρου (Φυσική) Κατάτμηση δικτύου Ασφάλεια συσκευών Διαχωρισμός περιοχών εργασίας Αντίγραφα δεδομένων Καλωδίωση … Λογικοί Έλεγχοι Πρόσβαση στο σύστημα (Λογική) Κατάτμηση δικτύου Πρόσβαση στο δίκτυο Πρωτόκολλα ασφάλειας Δοκιμές διείσδυσης Καταγραφή και παρακολούθηση …

Άθρωποι: ο πλέον αδύναμος κρίκος στο πρόγραμμα ασφάλειας. Η σωστή και συνεχής εκπαίδευση μπορεί να μειώσει πολλούς κινδύνους Πολιτικές: η θεώρηση της ασφάλειας από τη σκοπιά τη Διοίκησης. Διαδικασίες, Πρότυπα & Οδηγίες: Υποστηρίζουν την πολιτική ασφάλειας Α. Διαχειριστικοί Έλεγχοι Πολιτικές & Διαδικασίες Διαχείριση προσωπικού Εκπαίδευση & επιμόρφωση Έλεγχος Συνεχείς δοκιμές και έλεγχος των μηχανισμών & διαδικασιών ασφάλειας (π.χ. ασκήσεις ετοιμότητας για φυσικές καταστροφές, συνεντεύξεις με υπαλλήλους,… Ενέργειες (ως προς την ασφάλεια) κατά την πρόσληψη, απόλυση, μετάθεση, προαγωγή κλπ. Επίσης, διάκριση καθηκόντων, εναλλαγή θέσεων εργασίας κλπ

Π.χ. Κλειδαριές στο κάλυμμα του Η/Υ, αφαίρεση οδηγών floppy & CD/DVD, ασφάλεια εκπομπών (emanation security),… Φρουροί ασφάλειας, κλειστό κύκλωμα TV, φράχτες, ανιχνευτές κίνησης κλπ Β. Φυσικοί Έλεγχοι Ασφάλεια περιμέτρου (Φυσική) Κατάτμηση δικτύου Ασφάλεια συσκευών Διαχωρισμός περιοχών εργασίας Αντίγραφα δεδομένων Καλωδίωση … Π.χ. οι Η/Υ με τις ΒΔ των πελατών τοποθετούνται σε συγκεκριμένη αίθουσα, με φυσική προστασία (π.χ. τοίχος, πόρτες, κλειδαριά). Οι κόμβοι, patch panels, δρομολογητές & δικτυακές συσκευές ομοίως. Ομάδες υπαλλήλων με συναφείς αρμοδιότητες, έχουν διακριτούς χώρους εργασίας. Η πρόσβαση σε κάθε χώρο προστατεύεται με μέτρα φυσικής ασφάλειας Διαδικασίες για τη λήψη, φύλαξη αντιγράφων, & ανάκτηση κρίσιμων δεδομένων μετά από ένα σφάλμα, επείγον περιστατικό, καταστροφή κλπ Είδος καλωδίων που θα επιλεγεί (π.χ. αντοχές κάθε τύπου σε παρεμβολές, θόρυβο & υποκλοπές), διαδικασίες καλωδίωσης κλπ

Τεχνικές Ταυτοποίησης (PKI, passwords, smartcards. Kerberos, Radius), & Εξουσιοδό-τησης υποκειμένου (π.χ. έλεγχος ετικέτας ασφάλειας σε MAC) Έλεγχος Πρόσβασης –Στρώματα Προστασίας Access Control Layers Γ. Λογικοί Έλεγχοι Πρόσβαση στο σύστημα (Λογική) Κατάτμηση δικτύου Πρόσβαση στο δίκτυο Πρωτόκολλα ασφάλειας Δοκιμές διείσδυσης Καταγραφή και παρακολούθηση … (Κυρίως) κρυπτογραφικά πρωτόκολλα για την προστασία της μυστικότητας, ακεραιότητας & αυθεντικότητας των επικοινωνιών & των δεδομένων Λογικός διαχωρισμός (π.χ. IP networks, subnet masks, VLANs) Penetration testing: Διενέργεια επιθέσεων (white hat) με σκοπό την διαπίστωση των ευπαθειών του προγράμματος ασφάλειας Routers, firewalls, switches, bridges,… Παρακολούθηση (π.χ. συστήματα IDS), & καταγραφή (logging) των δραστηριοτήτων και των ενεργειών στο δίκτυο και στα συστήματα

Ασφάλεια – Στρώματα Προστασίας Πρόληψη – Ανίχνευση & Αντιμετώπιση (1)

Ασφάλεια – Στρώματα Προστασίας Πρόληψη – Ανίχνευση & Αντιμετώπιση (2)

Εξουσιοδότηση (Authorization) Άλλα Κριτήρια για την Πρόσβαση (Access Criteria)
Σε ποια ομάδα (group) ανήκει το υποκείμενο; Ομάδα: λίστα υποκειμένων με παρόμοιες αρμοδιότητες Ποια η ετικέτα ασφάλειας του υποκειμένου; Ποιος ρόλος ζητεί πρόσβαση; Ρόλος: αρμοδιότητα, ή λίστα αρμοδιοτήτων στην επιχείρηση Ποια είναι η τοποθεσία (φυσική ή λογική) από όπου προέρχεται η αίτηση πρόσβασης; Ποιος είναι ο χρόνος κατά τον οποίο γίνεται η αίτηση; …

Εξουσιοδότηση (Authorization) Άλλα Κριτήρια για την Πρόσβαση (Access Criteria)
Η πρόσβαση στα αρχεία μισθοδοσίας επιτρέπεται μόνον κατά τις ώρες H εκτύπωση σε αυτόν τον εκτυπωτή επιτρέπεται μόνον στα μέλη της ομάδας «Τμήμα προμηθειών» Σε ποια ομάδα (group) ανήκει το υποκείμενο; Ομάδα: λίστα υποκειμένων με παρόμοιες αρμοδιότητες Ποια η ετικέτα ασφάλειας του υποκειμένου; Ποιος ρόλος ζητεί πρόσβαση; Ρόλος: αρμοδιότητα, ή λίστα αρμοδιοτήτων στην επιχείρηση Ποια είναι η τοποθεσία (φυσική ή λογική) από όπου προέρχεται η αίτηση πρόσβασης; Ποιος είναι ο χρόνος κατά τον οποίο γίνεται η αίτηση; … Ο ρόλος «Ελεγκτής αρχείων καταγραφής» έχει δικαιώματα ανάγνωσης (και μόνον) στα αρχεία καταγραφής Η πρόσβαση σε αυτόν τον Η/Υ επιτρέπεται μόνον με την τυπική διαδικασία εισόδου (alt-ctrl-del) – interactive log on Η πρόσβαση στη ΒΔ επιτρέπεται μόνον από διευθύνσεις της μορφής: X.X

Πολιτικές Εξουσιοδότησης Rule-Based Access Control
AN ο χρήστης συνδέεται μεταξύ Δευτέρας & Παρασκευής, KAI μεταξύ 8 Α.Μ. και 5 P.Μ, KAI το επίπεδο ασφάλειας του χρήστη είναι μεγαλύτερο ή ίσο του αντικειμένου, ΚΑΙ η κατηγορία του είναι ίδια με την κατηγορία του αντικειμένου ( “need to know”), ΤΟΤΕ H πρόσβαση επιτρέπεται Ένα σύνολο κανόνων καθορίζει τη σχέση υποκειμένων & αντικειμένων Οι κανόνες δεν είναι πάντα προσανατολισμένοι στην ταυτότητα του υποκείμενου π.χ. επηρεάζουν όλους τους χρήστες Ευρέως χρησιμοποιούμενοι σε routers, firewalls, proxies,… IF X AND/OR Z THEN Y π.χ: Μια πολιτική της επιχείρησης καθορίζει: τα συνημμένα αρχεία δεν μπορούν να έχουν μέγεθος πάνω από 5ΜΒ. Ένας κανόνας στον mail server επιβάλλει την πολιτική σε όλους τους χρήστες

Πολιτικές Εξουσιοδότησης Constrained User Interfaces (1/2)
Διαφορετικές όψεις του ίδιου πίνακα

Πολιτικές Εξουσιοδότησης Constrained User Interfaces (2/2)
Μενού Επιλογών (Menus) Κέλυφος Λ.Σ. (Shells) Όψεις ΒΔ (Database Views) Φυσικοί περιορισμοί Οι επιλογές των χρηστών περιορίζονται στις εντολές που μπορούν να εκτελέσουν Το interface του χρήστη με το Λ.Σ. Ένα περιορισμένο κέλυφος (restricted shell) περιέχει μόνον τις εντολές που καθορίζει ο Διαχειριστής π.χ. ορισμένα πεδία & εγγραφές της βάσης, δεν είναι ορατά σε συγκεκριμένους τύπους χρηστών π.χ. Σε κάθε μηχάνημα ATM, η επικοινωνία με το Λ.Σ. περιορίζεται (με φυσικό τρόπο) στις επιλογές που προσφέρει το πληκτρολόγιο

Πολιτικές Εξουσιοδότησης {Content, Context} -dependent AC
H πρόσβαση καθορίζεται από το περιεχόμενου του αντικειμένου Όψεις ΒΔ, φίλτρα spam, έλεγχος περιεχομένου Web,… Έλεγχος Πρόσβασης με βάση το Πλαίσιο (context) Η πρόσβαση καθορίζεται από πληροφορίες που σχετίζονται με την πρόσβαση π.χ. Stateful firewalls,… Η πολιτική καθορίζει: Οι διευθυντές έχουν πρόσβαση στις εγγραφές της ΒΔ για τη μισθοδοσία των υπαλλήλων τους Αν ο διευθυντής Α ζητήσει πρόσβαση στα δεδομένα του υπαλλήλου Χ, το σύστημα DBMS ελέγχει τα περιεχόμενα της εγγραφής για να διαπιστώσει αν ο Χ δουλεύει για τον Α

Διαχείριση Ελέγχου Πρόσβασης (Access Control Administration)
Πού λαμβάνονται οι αποφάσεις; Δύο προσεγγίσεις Συγκεντρωτικά συστήματα Αποκεντρωμένα συστήματα Όλες οι αιτήσεις πρόσβασης προωθούνται σε μια κεντρική οντότητα (π.χ. Kerberos) (ή, Κεντρικής διαχείρισης) Οι αποφάσεις για την έγκριση ή την απόρριψη της αίτησης πρόσβασης λαμβάνονται σε σημεία που βρίσκονται “κοντά” ως προς τα αντικείμενα

RADIUS Remote Authentication Dial In User Service

RADIUS Βήμα 1: Ο χρήστης Χ και ο AS συμφωνούν σε ένα πρωτόκολλο αυθεντικοποίησης (PAP, CHAP, EAP) Πρωτόκολλα Challenge-Response Βήμα 2: Ο χρήστης Χ υποβάλει το username & password στον AS Βήμα 3: ο AS επικοινωνεί με τον RS, με το πρωτόκολλο RADIUS Ο AS στέλνει τα διαπιστευτήρια (credentials) του Χ στον RS O RS κάνει δεκτή ή απορρίπτει την αίτηση πρόσβασης, & καθορίζει τα δικαιώματα πρόσβασης για τον Χ (εξουσιοδότηση) Βήμα4: Αν η πρόσβαση γίνει δεκτή, τότε ο RS αποστέλλει στον Χ, μέσω του AS, μια διεύθυνση IP, καθώς & άλλες παραμέτρους για τη σύνδεση.

Αρχή «Ελάχιστων Προνομίων» & Αρχή «Αναγκαίας Γνώσης»
Αρχή «Least Privilege» Οι εφαρμογές πρέπει να εκτελούνται με τα ελάχιστα δικαιώματα που απαιτούνται Αρχή «Need to Know» Ta υποκείμενα έχουν δικαίωμα πρόσβασης στην πληροφορία που είναι απολύτως απαραίτητη για τη διεκπεραίωση μιας εργασίας Περίπτωση: Το πρόγραμμα system backup έχει δικαιώματα ανάγνωσης στα αρχεία συστήματος, αλλά δεν μπορεί να τα τροποποιήσει Η Διοίκηση (ή οι Ιδιοκτήτες αγαθών) αποφασίζουν ποια είναι τα απολύτως αναγκαία δικαιώματα πρόσβασης για έναν χρήστη στα αγαθά Περίπτωση: Το πρόγραμμα system restore έχει δικαιώματα εγγραφής στα αρχεία συστήματος, αλλά δεν έχει δικαίωμα ανάγνωσης Ο Διαχειριστής Ασφάλειας επιβάλλει τους περιορισμούς αυτούς κατά την κατάρτιση των δικαιωμάτων πρόσβασης

Εξουσιοδότηση – A Fail-Secure Αpproach
Αν το σύστημα δεν μπορεί να αποφασίσει τι είδους πρόσβαση πρέπει να αποκτήσει ένα υποκείμενο, η προεπιλογή (default) πρέπει να είναι: “Η Πρόσβαση Απαγορεύεται”

3. Καταγραφή, Παρακολούθηση, Ανίχνευση (Logging, Monitoring, Intrusion Detection)

Ασφάλεια Η Έννοια της Υπευθυνότητας (Accountability)
Οι διαδικασίες παρακολούθησης (monitoring), καταγραφής (logging) & ελέγχου (audit) Καθιστούν χρήστες υπεύθυνους για τις πράξεις τους Επαληθεύουν εάν οι πολιτικές ασφάλειας εφαρμόζονται Χρησιμεύουν ως εργαλεία έρευνας (investigation tools) κατόπιν ενός συμβάντος,… Οι διαδικασίες αυτές αφορούν δραστηριότητες χρηστών, συστημάτων & εφαρμογών,.. Οι δυνατότητες μπορεί να είναι ενσωματωμένες σε Λ.Σ. ή/και σε ειδικές εφαρμογές cwwatch.files.wordpress.com

Η Έννοια της Υπευθυνότητας (Accountability) Καταγραφή (Logging)
Γεγονότα (σε επίπεδο Συστήματος) Απόδοση Συστήματος Απόπειρες εισόδου (επιτυχείς & ανεπιτυχείς) ID (username) επιτυχών συνδέσεων Συσκευές που χρησιμοποιήθηκαν Αλλαγή ρυθμίσεων συστήματος …

Γεγονότα (σε επίπεδο Εφαρμογής) Μηνύματα σφαλμάτων Λίστα αρχείων (που ανοίχτηκαν ή έκλεισαν) Τροποποίηση αρχείων Παραβιάσεις στην ασφάλεια …

Γεγονότα (σε επίπεδο Χρήστη) Απόπειρες εισόδου Λίστα αρχείων, υπηρεσιών & άλλων πόρων που αιτήθηκε Παραβιάσεις στην ασφάλεια …

Καταγραφή (Logging) Χρήση συστημάτων IDS (195)

Καταγραφή (Logging) Θέματα ασφάλειας
Τα αρχεία καταγραφής παρουσιάζουν ιδιαίτερο ενδιαφέρον από τη σκοπιά της ασφάλειας !!! Φύλαξη & αποθήκευση τους Μη εξουσιοδοτημένη πρόσβαση και τροποποίηση τους,…

Καταγραφή Θέματα ασφάλειας
Καταγραφή Θέματα ασφάλειας (Bellare & Yee, 1997) Ta log entries είναι της μορφής Χρόνος: χωρίζεται σε περιόδους, & κάθε περίοδος (epoch) i έχει το δικό της κλειδί Ki για αυθεντικοποίηση των log entries της περιόδου Στο τέλος της κάθε περιόδου Κi = hash (Ki-1) Διαγραφή του Ki Οποιαδήποτε χρονική στιγμή, το K0 (base key) χρησιμοποιείται για την επαλήθευση των log entries To K0 φυλάσσεται αλλού ! Χρήση κρυπτογραφικού MAC (Message Authentication Code) για την αυθεντικοποίηση των εγγραφών στο αρχείο καταγραφής με πρόσθια ακεραιότητα (Forward Integrity) Event Date … event1

Καταγραφή Θέματα ασφάλειας
Καταγραφή Θέματα ασφάλειας (Bellare & Yee, 1997) Event Epoch Date Footprint … event1 1 MAC(K1, event1, date1) event2 MAC(K1, event2, date2) event3 2 MAC(K2, event3, date3) Aν ο εχθρός αποκτήσει πλήρη πρόσβαση στο σύστημα, με δικαιώματα administrator, δεν θα μπορεί να «πάει πίσω» στο χρόνο και να αλλάξει τα log entries (Forward Integrity) !

Έλεγχος (Audit) Χρήση συστημάτων IDS (195)
π.χ. κατόπιν μιας επιτυχούς παραβίασης στην ασφάλεια Ειδικά εργαλεία, αναλαμβάνουν την επεξεργασία των αρχείων με σκοπό την εξαγωγή γνώσης Audit trail analysis Εναλλακτικά, ένα σύστημα IDS ελέγχει σε πραγματικό χρόνο για «ύποπτη» δραστηριότητα Ρύθμιση κατωφλίου ασφάλειας (threshold) για μείωση ψευδών αναφορών (FAR, FRR) Δυνατότητα ειδοποίησης (alarm) σε πραγματικό χρόνο

Audit Trail Analysis Tools Audit Reduction

Ανάλυση Αρχείων Καταγραφής Audit Trail Analysis
Τρεις κατηγορίες Audit reduction Φιλτράρουν τα αρχεία καταγραφής με σκοπό την ανάδειξη χρήσιμης πληροφορίας Anomaly detection (ή, Behaviour-based) Εύρεση ανωμαλιών ή ισχυρών διαφοροποιήσεων από «κανονικές συνθήκες» λειτουργίας Signature detection (ή, Knowledge-based) Αναζήτηση σε μια ΒΔ για την εύρεση γνωστών αποτυπωμάτων επίθεσης π.χ. Έστω το ωράριο του υπαλλήλου Χ είναι 8.00 – Αν καταγραφεί είσοδος στο σύστημα στις 03.00, το γεγονός αυτό ίσως σημαίνει επίθεση

Παρακολούθηση & Έλεγχος Συστήματα IDS
Αυτόνομη λειτουργία, ή επεξεργασία αρχείων καταγραφής (Η/Υ ή δικτύων) Ανίχνευση Εισβολής Ανίχνευση μη εξουσιοδοτη-μένης χρήσης, επίθεσης ή άλλων ύποπτων ενεργειών… … σε Π.Σ & δίκτυα .. με σκοπό την ενημέρωση του διαχειριστή & τη λήψη μέτρων που θα μειώσουν ή αποτρέψουν τις συνέπειες μιας επίθεσης

Αυτόνομη λειτουργία, ή επεξεργασία αρχείων καταγραφής (Η/Υ ή δικτύων) Ανίχνευση Εισβολής Ανίχνευση μη εξουσιοδοτη-μένης χρήσης, επίθεσης ή άλλων ύποπτων ενεργειών… … σε Π.Σ & δίκτυα .. με σκοπό την ενημέρωση του διαχειριστή & τη λήψη μέτρων που θα μειώσουν ή αποτρέψουν τις συνέπειες μιας επίθεσης Στο σχήμα, o όρος σύστημα μπορεί να αναφέρεται σε οποιοδήποτε από τα εξής: Σταθμός Εργασίας, Δικτ. Συσκευή, Server, Mainframe, Firewall, Web server, δίκτυο επιχείρησης κλπ

Αισθητήρες Αναλυτές Διεπαφή Διαχειριστή Συλλέγουν δεδομένα κίνησης και δραστηριότητας χρήστη (user activity) και τα αποστέλλουν σε έναν αναλυτή (Sensors) Ο αναλυτής επεξεργάζεται τα δεδομένα με σκοπό τον εντοπισμό «πιθανής» ύποπτης δραστηριότητας (Analyzers, Detectors) H κονσόλα του διαχειριστή για τον έλεγχο των αισθητήρων & του αναλυτή, καθώς και για την προσαρμογή των ρυθμίσεων αποστολής ειδοποιήσεων (Administrator interface) Τα συστήματα IDS μπορούν να κατηγοριοποιηθούν με βάση την εμβέλεια τους, καθώς και με βάση τις τεχνικές που χρησιμοποιεί ο αναλυτής

Συστήματα IDS Υπολογιστικού Συστήματος (Host-based IDS) – HIDS
Εγκαθίσταται σε μεμονωμένα συστήματα (hosts, servers) & ανιχνεύουν "ύποπτες" ενέργειες Σβήσιμο αρχείων, αλλαγή ρυθμίσεων συστήματος, κλήσεις συστήματος, κίνηση πρωτοκόλλων επιπέδου εφαρμογής κλπ

Συστήματα IDS Δικτυακά (Network-based IDS) - NIDS
Η/Υ με εξειδικευμένο λογισμικό, ή εξειδικευμένες συσκευές H δικτυακή διεπαφή (NIC) λειτουργεί «αδιακρίτως» (promiscuous mode) Μια NIC σε promiscuous mode αντιγράφει κάθε είδος δικτυακής κίνησης και το προωθεί σε ανώτερο επίπεδο της στοίβα των πρωτοκόλλων για επεξεργασία

Συστήματα IDS (202) – also look at the papers
(Debar et al, 1999)

Συστήματα IDS (Intrusion Detection) και IPS (Intrusion Prevention)

Βιβλιογραφία Μαθήματος
D. Gollman, Computer Security. 3rd Edition, 2010. R. Anderson. Security Engineering, 2nd Edition, 2008 Hacking Exposed 5th Edition, McClure, Scambray and Kurtz, 2005 Firewalls and Internet Security, 2nd Edition. Bellovin et al, 2003. D. Chaum. Secrets and Lies – Digital Security in a Networked world. 2001 Role-Based Access Control (RBAC): Features and Motivations Προβλήματα Ασφάλειας στο Ηλεκτρονικό Εμπόριο. Δρ. Χ. Κ. Γεωργιάδης. Σημειώσεις μαθήματος, Παν. Θεσσαλίας, Εισαγωγή στον Έλεγχο Πρόσβασης, Τμήμα Πληροφορικής, Α.Π.Θ, National Computer Security Center (NCSC), A guide to understanding discrentionary access control in trusted systems, 30 September 1987,

Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος Εξάμηνο: Δ’

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος Εξάμηνο: Δ’"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια

Είσοδος

Σύνδεση μέσω των κοινωνικών δικτύων:

Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος Εξάμηνο: Δ’

Παρόμοιες παρουσιάσεις

Παρουσίαση με θέμα: "Ιόνιο Πανεπιστήμιο Τμήμα Πληροφορικής Ακαδημαϊκό Έτος Εξάμηνο: Δ’"— Μεταγράφημα παρουσίασης:

Παρόμοιες παρουσιάσεις

Σχετικά με το έργο

Σχόλια