Βουτώντας απευθείας στα «βαθιά», είναι δυστυχώς αλήθεια ότι δεν έχουμε ”μάθει” ακόμη να αναπτύσσουμε ΑΣΦΑΛΕΣ λογισμικό, εξού και οι τόσες αδυναμίες ασφαλείας.
Τηλέμαχος Βαλκανιώτης 
Cyber Assurance Lead
Γεώργιος Νικολάου
Developer & Software Security Engineer
Cyber Noesis
Ακούγεται, συνεπώς, λογικό ότι όσο αυξάνονται οι επιθέσεις και οι κίνδυνοι, τόσο θα αυξάνεται και η ανάγκη για εφαρμογή προστατευτικών μέτρων καθ’ όλη την διάρκεια του SDLC (Software Development Lifecycle) aka Design, Development, Testing & Deployment.
Στο παρελθόν, το Cybersecurity δεν είχε σίγουρα προέχουσα θέση στην όλη διαδικασία. Τα μέτρα ασφαλείας συνήθως θέτονταν σε ισχύ προς το τέλος της, ως διακριτό στάδιο, με αποτέλεσμα το οποιοδήποτε θέμα πρόκυπτε να επηρεάζει όλα τα προηγούμενα στάδια, την οποιαδήποτε απαιτούμενη αλλαγή να κοστίζει σε disruption, χρόνο και χρήμα. Και αυτό ήταν το καλό σενάριο…
Το χειρότερο σενάριο ήταν η απουσία του Cybersecurity από τη διαδικασία. Ως αποτέλεσμα, καταλήγαμε με ένα λογισμικό το οποίο εξέθετε τους χρήστες, και κατ’ επέκταση τους δημιουργούς του, σε κίνδυνο.
Εν αρχή ην ο χρόνος…
Τις δεκαετίες του 1950 και 1960, η προτεραιότητα των μηχανικών λογισμικού ήταν να δημιουργηθεί λογισμικό το οποίο καλύπτει τις απαιτήσεις των χρηστών του και να είναι λειτουργικό. Το cybersecurity ήταν ελάσσονος σημασίας, μιας και οι χρήστες ήταν λιγοστοί, οι υπολογιστές ακόμα λιγότεροι και το Internet πολύ διαφορετικό από όπως το ξέρουμε σήμερα.
Την δεκαετία του 1970 και ιδιαίτερα του 1980, υπήρξε σημαντική αύξηση στον αριθμό των χρηστών και ως φυσικό επόμενο, εμφανίστηκαν χρήστες με ανήσυχο πνεύμα, οι οποίοι δοκίμαζαν τα λογισμικά με τρόπο που δεν είχε φανταστεί ο δημιουργός τους. Αυτό είχε ως απόρροια (και) τα πρώτα Security Incidents.
…και στην συνέχεια ο κόσμος.
Στη δεκαετία του 1990 αρχίζουν να γίνονται φανερά τα πρώτα δείγματα cybersecurity στην ανάπτυξη λογισμικού. Καταλυτικό ρόλο φέρεται να έχει η εισαγωγή του Internet στην ζωή μας και η εκρηκτική αύξηση στον αριθμό των χρηστών.
Γεννιούνται 2 μεθοδολογίες:
- το Trusted Computing Base (TCB), όπου οι μηχανικοί χώριζαν το λογισμικό σε μέρη που εμπιστεύονταν (trusted) και σε μέρη που δεν εμπιστεύονταν (untrusted), κάτι το οποίο οδήγησε σε μείωση των ευπαθειών.
- το Common Criteria for Information Technology (CC), βάσει της οποίας η αξιολόγηση της ασφάλειας μιας εφαρμογής πραγματοποιείται από αναγνωρισμένα κέντρα, βάσει διεθνώς αναγνωρισμένων και τυποποιημένων προτύπων, ανάλογα με το σενάριο χρήσης της εφαρμογής.
…μα ο κόσμος εξελίσσεται.
Η εξέλιξη είναι αναπόφευκτη! Το SDLC δεν θα έπρεπε – μπορούσε να εξαιρεθεί από αυτό το γεγονός.
Οι ολοένα αυξανόμενες απαιτήσεις και ο όγκος χρηστών, οδήγησε στο Agile Manifesto, ένα έγγραφο το οποίο ευαγγέλιζε τη συνεργασία μεταξύ μηχανικών, την ευελιξία και τους αστραπιαίους χρόνους παράδοσης. Αυτός ο τρόπος ναι μεν προσφέρει πολλαπλά παραδοτέα, αλλά απαιτεί από το cybersecurity να προσαρμοστεί και να εμπλακεί σε κάθε στάδιο του SDLC, αν θέλει να παραμείνει σχετικό (relevant).
Ένας τρόπος να εφαρμόσουμε το cybersecurity στο SDLC είναι να αξιοποιήσουμε, συλλογικά, εργαλεία όπως τα ακόλουθα:
- Threat Modeling – Διαδικασία που τοποθετείται στην αρχή του SDLC και πιο συγκεκριμένα στο στάδιο του Design. Μέσω του Threat Modeling, μπορούμε να αναδείξουμε ευπάθειες που μπορεί να προκύψουν από τον σχεδιασμό του λογισμικού, προτού καν αρχίσει η ανάπτυξη του. Έτσι, τα όποια μέτρα προστασίας χρειάζονται να δημιουργηθούν, γίνονται γνωστά εξ αρχής και οι μηχανικοί δεν βρίσκονται προ εκπλήξεως σε μεταγενέστερα στάδια.
Το Threat Modeling, μοιάζει πολύ με το risk assessment, καθώς για κάθε πιθανή ευπάθεια, υπολογίζεται η πιθανότητα και η επίπτωση του κάθε κινδύνου. Αυτή η άσκηση, βοηθά στο να αποφασιστεί τι τελικά θα αναπτυχθεί και τι όχι.
- Code Analysis – Ελληνιστί η Ανάλυση Κώδικα, κατά την διάρκεια της οποίας, ο πηγαίος κώδικας του λογισμικού ελέγχεται για πιθανές ευπάθειες.
Ο έλεγχος του κώδικα από κάποιον μηχανικό, μπορεί να είναι μια διαδικασία πολύ αποδοτική, ωστόσο μπορεί να είναι αρκετά χρονοβόρα έως και μη εφικτή αν το λογισμικό αποτελείται από πολλές γραμμές κώδικα. Τα αυτόματα εργαλεία, μπορούν να βοηθήσουν σε αυτό και μάλιστα πλέον σε έναν πολύ ικανοποιητικό βαθμό, χρησιμοποιώντας τεχνικές όπως:
- Static Code Analysis, κατά την οποία ο κώδικας εξετάζεται ως έχει, χωρίς να εκτελεστεί.
- Dynamic Analysis, κατά την οποία το λογισμικό εξετάζεται κατά τη λειτουργία του.
- Fuzz Testing, κατά την οποία το λογισμικό λαμβάνει ένα μεγάλο όγκο τυχαίων δεδομένων ως είσοδο, με σκοπό να εμφανιστούν τυχόν υποβόσκοντα σφάλματα.
- Security Testing – Γνωστός και ως «ο επί τούτου έλεγχος ασφαλείας». Τα πατροπαράδοτα penetration tests, είναι το προπύργιο αυτού του σταδίου ωστόσο σε έναν κόσμο που τα παραδοτέα μπορούν να είναι καθημερινά, πόσο βιώσιμα μπορούν να είναι; Η αυτοματοποίηση μοιάζει και είναι μονόδρομος.
Εν κατακλείδι..
Ο κόσμος προχωρά.
Μαζί έχουν προχωρήσει και τα εργαλεία που έχουμε στα χέρια μας για να αντιμετωπίσουμε τις προκλήσεις που αναφέρθηκαν παραπάνω. Η ραγδαία ανάπτυξη όλο και πιο εξελιγμένων εργαλείων Security Testing και Code Analysis και η παράλληλη εμφάνιση μεθόδων όπως το DevSecOps, το οποίο αποτελεί μια εξέλιξη του DevOps, επιδιώκουν να λύσουν τα προβλήματα αυτά. Μέσα από συνεχόμενους, αυτοματοποιημένους ελέγχους οι οποίοι πραγματοποιούνται νωρίς στο SDLC, αλλά και μέσα από την κουλτούρα κοινής ευθύνης σχετικά με την ασφάλεια, το DevSecOps προσφέρει λύσεις στα προβλήματα του αυξημένου όγκου παραδοτέων και των αντίστοιχων απαιτήσεων ασφαλείας.
Αν αναλογιστούμε ότι βρισκόμαστε στην αυγή της 4ης βιομηχανικής επανάστασης, πόσο καιρό διαθέτουμε μέχρι να αρχίσουν να εμφανίζονται περιστατικά με την συνδρομή τεχνητής νοημοσύνης (ΑΙ);
Ας μην είμαστε καταστροφολόγοι όμως… το Defense-in-Depth δείχνει να λειτουργεί και η υιοθέτηση του Secure SDLC είναι ένα σημαντικότατο σημείο το οποίο δε μπορούμε να αμελούμε άλλο!
