Ακριβώς όπως και το ιδιόκτητο λογισμικό, το Open Source έχει άφθονα συν και πλην. Οι επικριτές του λογισμικού ανοικτού κώδικα συχνά αναφέρουν ότι η ευρεία βάση ανάπτυξης της και ο ανοικτός πηγαίος κώδικας είναι επικίνδυνα για την ασφάλεια. Όμως αυτή η αξιολόγηση δεν είναι δίκαιη, σύμφωνα με τον Dr Ian Levy, τεχνικός διευθυντής της CESG, ένα τμήμα του οργανισμού πληροφοριών GCHQ του Ηνωμένου Βασιλείου, που συμβουλεύει την κυβέρνηση της Βρετανίας για την IT ασφάλεια.
Το Open source δεν είναι χειρότερο ή καλύτερο από το ιδιόκτητο λογισμικό, όταν πρόκειται για την ασφάλεια, σύμφωνα με τον Levy, ο οποίος απέρριψε ορισμένους μύθους για την ασφάλεια του ανοιχτού κώδικα και μίλησε λεπτομερώς για τις πραγματικές προκλήσεις ασφαλείας στο συνέδριο Open Source, Open Standards που πραγματοποιήθηκε παλαιότερα στο Λονδίνο.
Χθες αναφέραμε τους μύθους για το Open Source.
Σήμερα θα μιλήσουμε για τις προκλήσεις:
Η διανομή λογισμικού
Οι online μέθοδοι διανομής που χρησιμοποιούνται από πολλά projects ανοικτού κώδικα είναι ευάλωτα καθώς γνήσια εκτελέσιμα αρχεία αντικαθίσταται με προϊόντα απομίμησης που περιέχουν κακόβουλο κώδικα, ανέφερε ο Dr Ian Levy στο ίδιο συνέδριο.
“Πώς θα έχω επιβεβαίωση για την online διανομή, επειδή ένα SHA-1 hash και ένα κλειδί PGP υπάρχει στον ίδιο διακομιστή, και η ίδια η διανομή δεν το κάνει για μένα. Έχουν ήδη σημειωθεί επιθέσεις εναντίον διακομιστών διανομής. Κανείς δεν άγγιξε τον πηγαίο κώδικα, αλλά άγγιξαν το δυαδικό (binary), το MD5, το SHA-1 και τον PGP κώδικα.
“Έχετε κατεβάσει τον έλεγχο του hash, αλλά έχετε το hash από την ίδια θέση που πήρατε το binary. Πού είναι η εμπιστοσύνη;”
Patching ή επιδιορθώσεις
Η ίδια ερώτηση που ισχύει για την προέλευση του κώδικα ισχύει και για τις ενημερώσεις του λογισμικού ανοικτού κώδικα.
«Αν χρησιμοποιήσω το Windows Update, ξέρω ότι είναι signed από μια διαδικασία που λειτουργεί στο εσωτερικό της Microsoft. Τι μπορώ να γνωρίζω για τις ενημερώσεις του Mint;
“Τι μπορώ να γνωρίζω για το λογισμικό που έρχεται από έναν “ασφαλή” HTTP Server;”
Exploit visibility ή Ορατά Exploits
“Για τα Open source patches θα πρέπει να κυκλοφορήσετε τον πηγαίο κώδικα. Έτσι κακόβουλοι χρήστες μπορούν εγγενώς να αποκαλύψουν το βασικό πρόβλημα. Ένα binary patch που κυκλοφόρησε να να επιδιορθώσει μια ευπάθεια ασφαλείας σε ένα προϊόν μπορεί να χρησιμοποιηθεί για να αναστρέψει και τη λειτουργία του. Στο open source, υπάρχει διαθέσιμος ο πηγαίος κώδικας του patch και δείχνει στον εισβολέα που ακριβώς είναι το πρόβλημα.
“Αυτό δεν είναι απαραίτητα κακό, με την λογική της συνεχούς επιδιόρθωσης. Συνεχείς επιδιορθώσεις μειώνουν τον χρόνο λειτουργίας των exploits.”
Έτσι projects ανοικτού κώδικα (Open Source) έχουν άτομα και ομάδες που παρακολουθούν τα ενεργά σφάλματα στον κώδικα, γεγονός που καθιστά αυτά τα δυνητικά unpatched σφάλματα ακόμα πιο ορατά.
“Εφόσον είναι ανοιχτά σε όλους μπορείτε να έχετε το zero day exploits γιατί δεν υπάρχει patch.”
Έλεγχος της αλυσίδας εφοδιασμού του κώδικα
“Πώς μπορώ να ξέρω ποιος έχει γράψει τον κώδικα που χρησιμοποιώ, πως μπορώ να ξέρω τι έχει γράψει, και πώς μπορώ να ξέρω τι άλλα υπάρχουν εκεί;” ανέφερε ο Levy.
Τα εμπορικά software modules, μπορούν να ελεγχθούν από κάποια νομική ομάδα για να διαπιστωθεί ότι συμμορφώνονται με την άδεια χρήσης.
“Πώς μπορώ να έχω την ίδια αξιοπιστία με το ελεύθερο λογισμικό; Τι μπορώ να πω για τη νομιμότητα του; Πώς μπορώ να ξέρω ότι κάποιος έχει εξετάσει τις άδειες αυτών των software modules;
“Δεν λέω ότι δεν μπορείτε να το κάνετε, εγώ λέω πώς να το κάνουμε; Είναι ένα διαφορετικό σύνολο προκλήσεων.”
Διάσπαση της Ομάδας
“Η αλλαγή της προσωπικότητας μπορεί να έχει πολύ μεγαλύτερη επίδραση σε ένα προϊόν ανοικτού κώδικα από ό, τι μπορεί να έχει σε ένα εμπορικό προϊόν. Ένα εμπορικό προϊόν έχει ένα brand value, ενώ ένα προϊόν ανοικτού κώδικα οδηγείται από μια ομάδα ανθρώπων. Θα ήθελα να ελπίζω ότι είναι όλοι ευθυγραμμισμένοι σε ορισμένες γενικές γραμμές αλλά έχουν υπάρξει και υπάρχουν γκέτο σε projects ανοικτού κώδικα, που αλλάζουν ριζικά την κατεύθυνση. ”
Σχέσεις των Developers
Για να είσαι σε θέση να αξιολογήσεις την ασφάλεια του λογισμικού εξαρτάται σε μεγάλο βαθμό από το πόσο γνωρίζεις τους προγραμματιστές και αν έχεις κάποια στοιχεία για τα μελλοντικά τους σχέδια για το λογισμικό, σύμφωνα με το Levy.
«Η αξιολόγηση της ασφάλειας είναι πιο πολύ στην σχέση που έχουν οι developers και όχι στον πηγαίο κώδικα», είπε.
“Όποιος νομίζει ότι αξιολόγηση ασφαλείας προϋποθέτει τον έλεγχο κάθε γραμμή κώδικα για την αναζήτηση τρωτών σημείων είναι απολύτως λάθος. Η εξέλιξη στο επίπεδο που μιλάμε είναι να γνωρίζει ο κύριος του έργου τι κάνουν οι υπόλοιποι, να υπάρχει ένα μακροπρόθεσμο σχέδιο για τη διατήρηση της ασφάλειας και να υπάρχει ένα σχέδιο διαχείρισης περιστατικών.
“Ο σχεδιασμός της αρχιτεκτονικής του προϊόντος από τον κώδικα είναι απίστευτα δύσκολος. Αν δεν έχεις κάποια σχέση με τον κύριο του έργου να ρωτήσεις: Γιατί το σχεδιάζετε έτσι; ” Η συνέχεια της ανάπτυξης είναι πραγματικά δύσκολη και συχνά χρειάζεται τρίτους.”
Οι ταυτότητες των Developer είναι γενικά ανύπαρκτες
«Για ορισμένα projects η ταυτότητα του developer είναι μια διεύθυνση Gmail. Ποιος θέλει να στοιχηματίσετε την ασφάλειά του στον λογαριασμού κάποιου Gmail; Υπάρχουν και άλλοι τρόποι για τον έλεγχο ταυτότητας των developers, αλλά είναι πράγματα που πρέπει να σκεφτούμε.”
Η έλλειψη ανάπτυξης τυποποιημένων και κοινών υποδομών ασφάλειας
“Μπορώ να ελέγξω μια εταιρεία και να πω: “Έχετε αυτά τα πρότυπα και τα εφαρμόζετε και ναι έχετε περιστατικά, αλλά τα διαχειρίζεστε καλά;”
Πώς μπορούμε να το κάνουμε αυτό για ένα διαφορετικό σύνολο προγραμματιστών στο δικό τους hardware;
