1. Τι είναι οι Supply Chain Attacks
Οι Supply Chain Attacks, γνωστές ως επιθέσεις στην αλυσίδα εφοδιασμού, αποτελούν μια κατηγορία κυβερνοεπιθέσεων που εκμεταλλεύεται την εμπιστοσύνη μεταξύ οργανισμών, προμηθευτών, developers και λογισμικού. Αντί ένας επιτιθέμενος να προσπαθήσει να παραβιάσει απευθείας τον τελικό στόχο, μπορεί να επιδιώξει την παραβίαση ενός συστήματος ή μιας υπηρεσίας που χρησιμοποιείται ήδη από αυτόν.
Η συγκεκριμένη προσέγγιση είναι ιδιαίτερα επικίνδυνη επειδή το λογισμικό που φτάνει στον τελικό χρήστη μπορεί να προέρχεται από μια φαινομενικά νόμιμη πηγή. Μια ενημέρωση ασφαλείας, μια βιβλιοθήκη κώδικα ή μια εφαρμογή που διανέμεται από τον επίσημο ιστότοπο του κατασκευαστή μπορεί να αποτελέσει μέρος μιας επίθεσης, εάν η διαδικασία ανάπτυξης ή διανομής της έχει παραβιαστεί.
Η αλυσίδα εφοδιασμού λογισμικού περιλαμβάνει όλα τα στοιχεία που συμβάλλουν στη δημιουργία και τη διανομή μιας εφαρμογής. Σε αυτά περιλαμβάνονται ο πηγαίος κώδικας, οι εξωτερικές βιβλιοθήκες, τα εργαλεία ανάπτυξης, τα συστήματα δημιουργίας εκτελέσιμων αρχείων, τα αποθετήρια πακέτων και οι μηχανισμοί ενημέρωσης.
Ένας επιτιθέμενος που καταφέρνει να παραβιάσει ένα από αυτά τα σημεία μπορεί να αποκτήσει πρόσβαση σε μια διαδρομή που οδηγεί σε πολλούς τελικούς χρήστες ή οργανισμούς.
Αυτό είναι το βασικό σημείο που αξίζει να θυμάσαι: δεν χρειάζεται να παραβιαστεί κάθε θύμα ξεχωριστά, όταν μπορεί να παραβιαστεί το λογισμικό που εμπιστεύονται όλα τα θύματα.
2. Πώς λειτουργεί μια επίθεση στην αλυσίδα εφοδιασμού
Μια Supply Chain Attack μπορεί να πραγματοποιηθεί με διαφορετικούς τρόπους, ανάλογα με το σημείο στο οποίο αποκτά πρόσβαση ο επιτιθέμενος.
Σε ορισμένες περιπτώσεις, ο στόχος είναι ο κατασκευαστής μιας εφαρμογής. Σε άλλες, η επίθεση στρέφεται εναντίον ενός λογαριασμού developer, ενός αποθετηρίου λογισμικού ή μιας εξωτερικής βιβλιοθήκης που χρησιμοποιείται από πολλές εφαρμογές.
Μια ενδεικτική διαδικασία μπορεί να περιλαμβάνει τα παρακάτω στάδια:
1. Εντοπισμός του στόχου: Ο επιτιθέμενος αναζητά έναν προμηθευτή, ένα εργαλείο ανάπτυξης ή ένα στοιχείο λογισμικού που χρησιμοποιείται από πολλούς οργανισμούς.
2. Παραβίαση της αλυσίδας: Επιχειρεί να αποκτήσει πρόσβαση σε λογαριασμούς, συστήματα ανάπτυξης, αποθετήρια κώδικα ή υποδομές διανομής.
3. Εισαγωγή κακόβουλου κώδικα: Εφόσον αποκτήσει τις απαραίτητες δυνατότητες, μπορεί να αλλοιώσει τον πηγαίο κώδικα, μια εξάρτηση ή το τελικό πακέτο λογισμικού.
4. Διανομή: Το αλλοιωμένο λογισμικό μπορεί να διανεμηθεί μέσω μιας διαδικασίας που οι τελικοί χρήστες θεωρούν νόμιμη.
5. Εκτέλεση και περαιτέρω δραστηριότητα: Ανάλογα με την επίθεση, ο κακόβουλος κώδικας μπορεί να συλλέξει πληροφορίες, να δημιουργήσει πρόσβαση σε ένα σύστημα ή να επιτρέψει μεταγενέστερες ενέργειες.
Δεν ακολουθούν όλες οι επιθέσεις ακριβώς την ίδια διαδικασία. Ορισμένες περιορίζονται στην εκμετάλλευση μιας ευάλωτης εξάρτησης, ενώ άλλες απαιτούν μακροχρόνια και στοχευμένη παραβίαση υποδομών ανάπτυξης.
Η επικινδυνότητα αυτής της κατηγορίας επιθέσεων βρίσκεται στο γεγονός ότι η αρχική πρόσβαση μπορεί να προέρχεται από ένα στοιχείο που έχει ήδη εγκριθεί και εγκατασταθεί στο περιβάλλον του θύματος.
3. Πώς ένα νόμιμο update μπορεί να γίνει όχημα επίθεσης
Οι ενημερώσεις λογισμικού αποτελούν βασικό μέρος της κυβερνοασφάλειας. Διορθώνουν ευπάθειες, βελτιώνουν τη σταθερότητα των εφαρμογών και περιορίζουν την έκθεση σε γνωστές απειλές.
Ωστόσο, η διαδικασία ενημέρωσης μπορεί να μετατραπεί σε σημείο εκμετάλλευσης, εάν ένας επιτιθέμενος αποκτήσει πρόσβαση στην υποδομή που παράγει ή διανέμει τις ενημερώσεις.
Σε ένα τέτοιο σενάριο, ο χρήστης μπορεί να κατεβάσει ένα αρχείο από τον επίσημο μηχανισμό ενημέρωσης και να το εγκαταστήσει ακολουθώντας την κανονική διαδικασία. Η εφαρμογή μπορεί να εμφανίζεται ως γνήσιο προϊόν και η εγκατάσταση να μην παρουσιάζει κάποιο εμφανές πρόβλημα.
Αυτό δημιουργεί ένα σημαντικό ζήτημα εμπιστοσύνης. Ο χρήστης δεν αξιολογεί κάθε γραμμή κώδικα μιας ενημέρωσης πριν την εγκατάσταση. Βασίζεται στον κατασκευαστή, στη διαδικασία διανομής και στους μηχανισμούς που χρησιμοποιούνται για την επαλήθευση του λογισμικού.
Αν ένα από αυτά τα στοιχεία έχει παραβιαστεί, η εμπιστοσύνη μπορεί να αξιοποιηθεί εναντίον του ίδιου του χρήστη.
Η υπόθεση SolarWinds αποτελεί χαρακτηριστικό παράδειγμα αυτής της προσέγγισης, καθώς κακόβουλος κώδικας ενσωματώθηκε σε ενημερώσεις της πλατφόρμας Orion και διανεμήθηκε σε οργανισμούς μέσω της κανονικής διαδικασίας ενημέρωσης.
Η συγκεκριμένη περίπτωση ανέδειξε ότι ακόμη και η προσεκτική επιλογή λογισμικού δεν αρκεί όταν η υποδομή του προμηθευτή αποτελεί μέρος της επίθεσης.
4. Dependencies, libraries και package repositories
Οι σύγχρονες εφαρμογές σπάνια αναπτύσσονται αποκλειστικά από την αρχή. Οι developers χρησιμοποιούν εξωτερικές βιβλιοθήκες, frameworks και πακέτα που παρέχουν έτοιμες λειτουργίες.
Αυτά τα στοιχεία ονομάζονται dependencies και αποτελούν βασικό μέρος της ανάπτυξης λογισμικού. Μπορούν να μειώσουν τον χρόνο ανάπτυξης, να περιορίσουν την επανάληψη κώδικα και να διευκολύνουν τη συντήρηση εφαρμογών.
Παράλληλα, όμως, δημιουργούν μια επιπλέον επιφάνεια κινδύνου.
Μια εφαρμογή μπορεί να εξαρτάται από δεκάδες ή εκατοντάδες εξωτερικά πακέτα. Κάθε πακέτο μπορεί να διαθέτει δικές του εξαρτήσεις, δημιουργώντας μια αλυσίδα στοιχείων που δεν είναι πάντα εύκολο να παρακολουθηθεί.
Αν ένα από αυτά τα στοιχεία περιέχει κακόβουλο κώδικα ή παραβιαστεί ο λογαριασμός του συντηρητή του, η επίδραση μπορεί να επεκταθεί στις εφαρμογές που το χρησιμοποιούν.
4.1 Package repositories
Τα package repositories είναι αποθετήρια από τα οποία οι developers και τα εργαλεία ανάπτυξης κατεβάζουν βιβλιοθήκες και πακέτα λογισμικού.
Παραδείγματα περιλαμβάνουν το npm για το οικοσύστημα JavaScript και το PyPI για πακέτα Python.
Οι επιθέσεις σε αυτά τα οικοσυστήματα μπορούν να πάρουν διαφορετικές μορφές:
- Typosquatting: Δημοσίευση πακέτων με ονόματα που μοιάζουν με δημοφιλή πακέτα, με στόχο να εγκατασταθούν κατά λάθος.
- Account compromise: Παραβίαση λογαριασμού developer ώστε να αποκτηθεί δυνατότητα δημοσίευσης κακόβουλων εκδόσεων.
- Dependency confusion: Εκμετάλλευση του τρόπου με τον οποίο ένα σύστημα επιλέγει μεταξύ πακέτων με ίδιο ή παρόμοιο όνομα από διαφορετικές πηγές.
- Compromised package: Εισαγωγή κακόβουλου κώδικα σε ένα πακέτο που χρησιμοποιείται ήδη από άλλες εφαρμογές.
Οι συγκεκριμένες τεχνικές δεν απαιτούν όλες την παραβίαση ενός μεγάλου κατασκευαστή λογισμικού. Σε ορισμένες περιπτώσεις, η εκμετάλλευση ενός λιγότερο προστατευμένου λογαριασμού ή ενός πακέτου μπορεί να δημιουργήσει σημαντικό κίνδυνο.
4.2 Γιατί οι εξαρτήσεις χρειάζονται έλεγχο
Η εγκατάσταση μιας βιβλιοθήκης δεν σημαίνει ότι ο developer έχει ελέγξει προσωπικά όλο τον κώδικά της.
Για αυτόν τον λόγο, η διαχείριση εξαρτήσεων πρέπει να περιλαμβάνει καταγραφή των πακέτων που χρησιμοποιούνται, έλεγχο των εκδόσεών τους και αξιολόγηση της προέλευσής τους.
Η ύπαρξη μιας βιβλιοθήκης σε ένα δημοφιλές αποθετήριο δεν αποτελεί από μόνη της εγγύηση ασφάλειας. Απαιτείται αξιολόγηση του πακέτου, των αλλαγών του και της διαδικασίας με την οποία ενσωματώνεται στο λογισμικό.
5. Πραγματικό περιστατικό: Η επίθεση στη SolarWinds
Η επίθεση στη SolarWinds, η οποία έγινε δημόσια γνωστή τον Δεκέμβριο του 2020, αποτελεί ένα από τα πιο χαρακτηριστικά παραδείγματα παραβίασης της αλυσίδας εφοδιασμού λογισμικού.
Η πλατφόρμα Orion της εταιρείας χρησιμοποιούνταν για την παρακολούθηση και τη διαχείριση δικτυακών υποδομών. Επειδή τέτοιου είδους εργαλεία διαθέτουν συχνά σημαντική ορατότητα στα συστήματα ενός οργανισμού, αποτελούν ιδιαίτερα ενδιαφέροντα στόχο για έναν επιτιθέμενο.
Στη συγκεκριμένη περίπτωση, κακόβουλος κώδικας ενσωματώθηκε σε ορισμένες εκδόσεις της πλατφόρμας Orion και διανεμήθηκε μέσω ενημερώσεων λογισμικού. Η δραστηριότητα συνδέθηκε με το backdoor που έγινε γνωστό ως SUNBURST.
Σύμφωνα με τις αναφορές της αμερικανικής υπηρεσίας CISA, οι επηρεαζόμενες εκδόσεις είχαν διανεμηθεί μεταξύ Μαρτίου και Ιουνίου του 2020. Η επίθεση επέτρεψε την αρχική παραβίαση οργανισμών που χρησιμοποιούσαν τις συγκεκριμένες εκδόσεις, ενώ σε επιλεγμένους στόχους ακολούθησαν πρόσθετες ενέργειες.
Η αρχική εγκατάσταση του κακόβουλου κώδικα δεν σήμαινε ότι κάθε επηρεαζόμενος οργανισμός υπέστη ακριβώς την ίδια περαιτέρω επίθεση. Η δραστηριότητα μετά την αρχική πρόσβαση διέφερε ανάλογα με τον στόχο και τις συνθήκες του περιβάλλοντος.
Η υπόθεση απέδειξε πόσο σοβαρές μπορεί να είναι οι συνέπειες όταν παραβιάζεται μια διαδικασία ανάπτυξης και διανομής λογισμικού που εμπιστεύονται πολλοί οργανισμοί.
Η επίσημη τεχνική αναφορά της CISA είναι διαθέσιμη εδώ:
Το σημαντικό δίδαγμα είναι ότι η αξιολόγηση της ασφάλειας ενός οργανισμού πρέπει να λαμβάνει υπόψη όχι μόνο τα δικά του συστήματα, αλλά και τα κρίσιμα λογισμικά που χρησιμοποιεί.
6. Πραγματικό περιστατικό: Η επίθεση στην 3CX
Ένα ακόμη χαρακτηριστικό παράδειγμα είναι η επίθεση στην 3CX, η οποία έγινε γνωστή τον Μάρτιο του 2023.
Η 3CX αναπτύσσει λογισμικό επικοινωνίας για επιχειρήσεις, ενώ η εφαρμογή 3CXDesktopApp χρησιμοποιούνταν για λειτουργίες όπως φωνητικές κλήσεις και βιντεοεπικοινωνία.
Η υπόθεση ξεχώρισε επειδή η παραβίαση της 3CX συνδέθηκε με προηγούμενη παραβίαση της αλυσίδας εφοδιασμού λογισμικού.
Σύμφωνα με την έρευνα της Mandiant, η αρχική πρόσβαση στο περιβάλλον της 3CX συνδέθηκε με κακόβουλη έκδοση του λογισμικού X_Trader, η οποία είχε κατέβει και εκτελεστεί από εργαζόμενο. Η παραβίαση αυτή χρησιμοποιήθηκε ως σημείο εισόδου για την επόμενη επίθεση, η οποία επηρέασε το περιβάλλον ανάπτυξης και διανομής της εφαρμογής 3CX.
Στη συνέχεια, κακόβουλες εκδόσεις της νόμιμης εφαρμογής διανεμήθηκαν σε χρήστες. Η επίθεση στόχευε στην περαιτέρω διείσδυση σε επιλεγμένα συστήματα, με πρόσθετα στάδια δραστηριότητας.
Το ιδιαίτερα σημαντικό στοιχείο είναι ότι η επίθεση δεν περιορίστηκε σε μία μεμονωμένη εφαρμογή. Μια προηγούμενη παραβίαση χρησιμοποιήθηκε ως μέσο για να προετοιμαστεί μια δεύτερη επίθεση στην αλυσίδα εφοδιασμού.
Η συγκεκριμένη περίπτωση δείχνει πώς οι Supply Chain Attacks μπορούν να συνδεθούν μεταξύ τους, δημιουργώντας μια αλληλουχία παραβιάσεων που είναι δυσκολότερο να εντοπιστεί και να αντιμετωπιστεί.
Περισσότερες πληροφορίες είναι διαθέσιμες στις ακόλουθες αναφορές:
- CISA: Supply Chain Attack Against 3CXDesktopApp
- Mandiant: https://cloud.google.com/blog/topics/threat-intelligence/3cx-software-supply-chain-compromise
7. Code signing και η ψευδαίσθηση της εμπιστοσύνης
Το code signing είναι μια διαδικασία ψηφιακής υπογραφής λογισμικού που επιτρέπει την επαλήθευση της προέλευσης και της ακεραιότητάς του, σύμφωνα με τον μηχανισμό υπογραφής που χρησιμοποιείται.
Η ψηφιακή υπογραφή μπορεί να βοηθήσει το λειτουργικό σύστημα ή τον χρήστη να διαπιστώσει αν ένα αρχείο έχει τροποποιηθεί μετά την υπογραφή του και αν η υπογραφή αντιστοιχεί σε συγκεκριμένο πιστοποιητικό.
Πρόκειται για σημαντικό μηχανισμό ασφάλειας, αλλά πρέπει να κατανοούμε τα όριά του.
Αν ένας επιτιθέμενος αποκτήσει πρόσβαση στη διαδικασία δημιουργίας ή υπογραφής του λογισμικού, μπορεί να επιχειρήσει να εκμεταλλευτεί την ίδια την υποδομή που χρησιμοποιείται για τη διανομή έμπιστων αρχείων.
Ανάλογα με το περιστατικό, μπορεί επίσης να γίνει κατάχρηση έγκυρων διαπιστευτηρίων ή κλεμμένων κλειδιών υπογραφής.
Μια έγκυρη ψηφιακή υπογραφή δεν αποδεικνύει ότι κάθε λειτουργία του λογισμικού είναι ασφαλής. Επιβεβαιώνει συγκεκριμένα στοιχεία σχετικά με την υπογραφή και την ακεραιότητα του αρχείου, όχι την απουσία κακόβουλης συμπεριφοράς.
Για αυτόν τον λόγο, η υπογραφή πρέπει να συνδυάζεται με ασφαλή διαδικασία ανάπτυξης, περιορισμένη πρόσβαση στα συστήματα δημιουργίας λογισμικού και προστασία των κλειδιών υπογραφής.
8. Πώς εντοπίζονται οι Supply Chain Attacks
Ο εντοπισμός μιας επίθεσης στην αλυσίδα εφοδιασμού μπορεί να είναι δύσκολος, επειδή το αρχικό λογισμικό ενδέχεται να έχει εγκατασταθεί μέσω μιας κανονικής διαδικασίας.
Η παρουσία μιας νόμιμης εφαρμογής δεν αρκεί για να αποδείξει ότι κάθε έκδοσή της είναι ασφαλής. Αντίστοιχα, μια ενημέρωση που προέρχεται από γνωστό κατασκευαστή χρειάζεται να αξιολογείται στο πλαίσιο της συνολικής διαδικασίας ασφάλειας του οργανισμού.
Ο εντοπισμός μπορεί να βασίζεται σε συνδυασμό τεχνικών ελέγχων.
8.1 Έλεγχος ακεραιότητας αρχείων
Οι οργανισμοί μπορούν να συγκρίνουν αρχεία, εκδόσεις και κρυπτογραφικά hashes με αξιόπιστες αναφορές, όπου αυτές είναι διαθέσιμες.
Ένας διαφορετικός hash μπορεί να υποδεικνύει ότι ένα αρχείο έχει αλλάξει. Ωστόσο, η διαφορά δεν αποτελεί από μόνη της απόδειξη κακόβουλης δραστηριότητας, καθώς οι νόμιμες ενημερώσεις αλλάζουν επίσης τα αρχεία.
8.2 Παρακολούθηση συμπεριφοράς
Η παρακολούθηση της συμπεριφοράς μιας εφαρμογής μπορεί να αποκαλύψει ασυνήθιστες ενέργειες, όπως απρόσμενες δικτυακές συνδέσεις, μη αναμενόμενη εκτέλεση διεργασιών ή προσπάθειες πρόσβασης σε ευαίσθητους πόρους.
Η αξιολόγηση πρέπει να λαμβάνει υπόψη τον κανονικό τρόπο λειτουργίας της εφαρμογής και το περιβάλλον στο οποίο εκτελείται.
8.3 Καταγραφή και συσχέτιση συμβάντων
Τα logs από endpoints, servers, συστήματα ταυτοποίησης και δικτυακές υποδομές μπορούν να βοηθήσουν στην ανασύνθεση μιας επίθεσης.
Η συσχέτιση συμβάντων από διαφορετικές πηγές μπορεί να αποκαλύψει δραστηριότητα που δεν θα ήταν εμφανής αν εξεταζόταν ένα μόνο αρχείο καταγραφής.
8.4 Έλεγχος εξαρτήσεων
Η καταγραφή των εξωτερικών βιβλιοθηκών και των εκδόσεών τους βοηθά στον εντοπισμό γνωστών ευπαθειών και ύποπτων αλλαγών.
Τα εργαλεία Software Composition Analysis (SCA) μπορούν να υποστηρίξουν αυτή τη διαδικασία, εντοπίζοντας εξαρτήσεις και συγκρίνοντάς τες με διαθέσιμες πληροφορίες ασφαλείας.
Κανένας από αυτούς τους μηχανισμούς δεν αρκεί μόνος του για τον εντοπισμό κάθε πιθανής επίθεσης. Η αποτελεσματικότητα προκύπτει από τον συνδυασμό ελέγχων, καταγραφής, παρακολούθησης και σωστής αξιολόγησης των ευρημάτων.
9. Πώς προστατεύονται οργανισμοί και developers
Η προστασία της αλυσίδας εφοδιασμού λογισμικού απαιτεί μέτρα σε περισσότερα από ένα επίπεδα. Δεν αρκεί η εγκατάσταση ενός antivirus ή η χρήση ενός εργαλείου που ελέγχει μόνο γνωστές ευπάθειες.
9.1 Ασφάλεια της διαδικασίας ανάπτυξης
Τα συστήματα ανάπτυξης και δημιουργίας λογισμικού πρέπει να προστατεύονται με περιορισμένη πρόσβαση, ισχυρή αυθεντικοποίηση και σαφή διαχωρισμό δικαιωμάτων.
Οι λογαριασμοί που μπορούν να τροποποιήσουν τον πηγαίο κώδικα ή να δημοσιεύσουν εκδόσεις πρέπει να διαθέτουν μόνο τα απαραίτητα δικαιώματα.
9.2 Έλεγχος εξαρτήσεων
Οι developers πρέπει να γνωρίζουν ποιες βιβλιοθήκες και ποια πακέτα χρησιμοποιούν οι εφαρμογές τους.
Η καταγραφή των εξαρτήσεων, η αξιολόγηση των πηγών τους και η παρακολούθηση των εκδόσεων βοηθούν στον εντοπισμό προβλημάτων πριν αυτά επηρεάσουν την παραγωγική λειτουργία.
9.3 Software Bill of Materials (SBOM)
Το SBOM είναι μια δομημένη καταγραφή των στοιχείων λογισμικού που περιλαμβάνονται σε μια εφαρμογή ή ένα προϊόν.
Μπορεί να περιλαμβάνει βιβλιοθήκες, εξαρτήσεις και πληροφορίες για τις εκδόσεις τους, βοηθώντας τους οργανισμούς να κατανοήσουν από ποια επιμέρους στοιχεία αποτελείται το λογισμικό που χρησιμοποιούν.
Ένα SBOM διευκολύνει τη διερεύνηση όταν εντοπίζεται μια ευπάθεια ή ένα προβληματικό πακέτο. Δεν εγγυάται, όμως, ότι όλα τα καταγεγραμμένα στοιχεία είναι ασφαλή ούτε ότι η ίδια η καταγραφή είναι πλήρης και ενημερωμένη.
9.4 Ασφάλεια των ενημερώσεων
Οι οργανισμοί πρέπει να διαθέτουν διαδικασίες για την αξιολόγηση και την εφαρμογή ενημερώσεων, ιδιαίτερα όταν αυτές επηρεάζουν κρίσιμα συστήματα.
Η αξιολόγηση μπορεί να περιλαμβάνει έλεγχο της προέλευσης, επαλήθευση υπογραφών, δοκιμές σε κατάλληλο περιβάλλον και παρακολούθηση της συμπεριφοράς μετά την εγκατάσταση.
Οι ενημερώσεις δεν πρέπει να καθυστερούν αδικαιολόγητα, αλλά ούτε και να αντιμετωπίζονται ως αυτόματα ακίνδυνες μόνο επειδή διατίθενται από έναν γνωστό προμηθευτή.
9.5 Προστασία λογαριασμών και μυστικών
Οι λογαριασμοί developers, τα API tokens, τα διαπιστευτήρια αυτοματοποίησης και τα κλειδιά υπογραφής χρειάζονται αυστηρή προστασία.
Η χρήση MFA όπου υποστηρίζεται, η περιορισμένη διάρκεια ζωής των tokens και η αποθήκευση μυστικών σε κατάλληλα συστήματα διαχείρισης μπορούν να μειώσουν τον κίνδυνο κατάχρησης.
9.6 Secure Software Development Framework
Το NIST έχει δημοσιεύσει το Secure Software Development Framework (SSDF), ένα σύνολο πρακτικών που μπορούν να ενσωματωθούν στη διαδικασία ανάπτυξης λογισμικού.
Οι πρακτικές αυτές καλύπτουν θέματα όπως η προστασία του περιβάλλοντος ανάπτυξης, η παραγωγή ασφαλέστερου λογισμικού και η αντιμετώπιση ευπαθειών.
Η επίσημη δημοσίευση είναι διαθέσιμη εδώ:
Η ασφάλεια του λογισμικού δεν πρέπει να αντιμετωπίζεται ως έλεγχος που πραγματοποιείται μόνο πριν από την κυκλοφορία μιας έκδοσης. Χρειάζεται να αποτελεί μέρος ολόκληρου του κύκλου ανάπτυξης και συντήρησης.
10. Συνηθισμένοι μύθοι και λάθη
10.1 «Αν το κατέβασα από την επίσημη ιστοσελίδα, είναι ασφαλές»
Η επίσημη πηγή μειώνει τον κίνδυνο λήψης πλαστού λογισμικού από άγνωστες πηγές, αλλά δεν αποκλείει την πιθανότητα παραβίασης του κατασκευαστή ή της διαδικασίας διανομής.
10.2 «Ένα ψηφιακά υπογεγραμμένο αρχείο είναι ακίνδυνο»
Η ψηφιακή υπογραφή παρέχει πληροφορίες για την προέλευση και την ακεραιότητα του αρχείου. Δεν αποδεικνύει ότι ο κώδικας δεν περιέχει κακόβουλες λειτουργίες.
10.3 «Οι επιθέσεις στην αλυσίδα εφοδιασμού αφορούν μόνο μεγάλες εταιρείες»
Μικρότεροι οργανισμοί και ανεξάρτητοι developers μπορούν επίσης να επηρεαστούν, ειδικά όταν χρησιμοποιούν κοινές βιβλιοθήκες, εξωτερικές υπηρεσίες ή λογισμικό που έχει παραβιαστεί.
10.4 «Αν το antivirus δεν εντοπίσει κάτι, το λογισμικό είναι ασφαλές»
Τα εργαλεία προστασίας μπορούν να εντοπίζουν πολλές απειλές, αλλά δεν εγγυώνται ότι κάθε νέα ή στοχευμένη επίθεση θα αναγνωριστεί εγκαίρως.
10.5 «Το SBOM εγγυάται την ασφάλεια μιας εφαρμογής»
Το SBOM καταγράφει τα συστατικά του λογισμικού. Δεν πιστοποιεί από μόνο του ότι αυτά είναι ασφαλή ή ότι δεν έχουν υποστεί κακόβουλη τροποποίηση.
10.6 «Αν ενημερώνω τα πάντα, δεν κινδυνεύω»
Οι ενημερώσεις είναι απαραίτητες για την αντιμετώπιση γνωστών προβλημάτων, αλλά μια επίθεση στην ίδια τη διαδικασία ενημέρωσης μπορεί να δημιουργήσει διαφορετικό είδος κινδύνου.
Η σωστή στρατηγική συνδυάζει ενημερώσεις, έλεγχο ακεραιότητας, προστασία υποδομών και παρακολούθηση της συμπεριφοράς των συστημάτων.
11. Checklist ασφαλείας
Πριν και κατά τη χρήση λογισμικού, οργανισμοί και developers μπορούν να ελέγχουν τα παρακάτω:
- Γνωρίζουμε ποιος αναπτύσσει και συντηρεί το λογισμικό που χρησιμοποιούμε.
- Κατεβάζουμε εφαρμογές και ενημερώσεις από αξιόπιστες πηγές.
- Επαληθεύουμε τις ψηφιακές υπογραφές όπου υποστηρίζονται.
- Διατηρούμε καταγραφή των εξαρτήσεων και των εκδόσεών τους.
- Ελέγχουμε τις βιβλιοθήκες για γνωστές ευπάθειες και ύποπτες αλλαγές.
- Περιορίζουμε τα δικαιώματα πρόσβασης στα συστήματα ανάπτυξης.
- Προστατεύουμε τους λογαριασμούς developers με κατάλληλους μηχανισμούς αυθεντικοποίησης.
- Διαχειριζόμαστε με ασφάλεια τα API tokens και τα κλειδιά υπογραφής.
- Χρησιμοποιούμε SBOM όπου είναι κατάλληλο για το περιβάλλον μας.
- Διατηρούμε logs από κρίσιμα συστήματα και διαδικασίες ανάπτυξης.
- Παρακολουθούμε ασυνήθιστη συμπεριφορά μετά την εγκατάσταση ενημερώσεων.
- Διαθέτουμε διαδικασία αντιμετώπισης περιστατικών που αφορούν προμηθευτές και εξαρτήσεις.
- Εξετάζουμε τακτικά τις πρακτικές ασφάλειας των κρίσιμων προμηθευτών μας.
Η λίστα αυτή δεν εξαλείφει κάθε κίνδυνο, αλλά βοηθά στη δημιουργία μιας πιο ελεγχόμενης διαδικασίας ανάπτυξης, διανομής και χρήσης λογισμικού.
12. Συμπέρασμα
Οι Supply Chain Attacks αποτελούν μια ιδιαίτερα σημαντική κατηγορία κυβερνοεπιθέσεων, επειδή εκμεταλλεύονται την εμπιστοσύνη που υπάρχει μεταξύ του τελικού χρήστη, του κατασκευαστή και των επιμέρους στοιχείων ενός λογισμικού.
Μια παραβίαση δεν χρειάζεται να ξεκινήσει από το σύστημα που αποτελεί τον τελικό στόχο. Μπορεί να ξεκινήσει από έναν προμηθευτή, ένα αποθετήριο πακέτων, έναν λογαριασμό developer ή μια υποδομή ανάπτυξης και να μεταφερθεί σε άλλα συστήματα μέσω της κανονικής διαδικασίας διανομής.
Τα περιστατικά της SolarWinds και της 3CX δείχνουν ότι τέτοιες επιθέσεις μπορούν να επηρεάσουν οργανισμούς μέσω λογισμικού που χρησιμοποιείται ήδη και θεωρείται έμπιστο. Παράλληλα, η αυξανόμενη εξάρτηση από εξωτερικές βιβλιοθήκες και αυτοματοποιημένες διαδικασίες ανάπτυξης δημιουργεί περισσότερα σημεία που χρειάζονται προστασία.
Η αντιμετώπιση αυτών των κινδύνων απαιτεί ασφαλή ανάπτυξη λογισμικού, έλεγχο εξαρτήσεων, προστασία των λογαριασμών και των υποδομών δημιουργίας εφαρμογών, καθώς και αποτελεσματική παρακολούθηση της δραστηριότητας των συστημάτων.
Το σημαντικότερο είναι να κατανοούμε ότι η εμπιστοσύνη σε έναν κατασκευαστή δεν ισοδυναμεί με απόλυτη εγγύηση ασφάλειας. Η προέλευση του λογισμικού, η ακεραιότητά του και η διαδικασία με την οποία φτάνει στον τελικό χρήστη αποτελούν εξίσου σημαντικά στοιχεία.
Στην κυβερνοασφάλεια, δεν αρκεί να προστατεύεις το σύστημα που χρησιμοποιείς. Πρέπει να εξετάζεις και την αλυσίδα από την οποία προέρχεται αυτό που εμπιστεύεσαι.