Μοντελοποίηση απειλών για ISO 27001, NIS2 και DORA

Η Anya, CISO μιας ταχέως αναπτυσσόμενης εταιρείας fintech, κλήθηκε να εγκρίνει το σχέδιο διάθεσης μιας νέας B2B πλατφόρμας κινδύνου πληρωμών. Το Διοικητικό Συμβούλιο ήθελε είσοδο στην αγορά πριν από το τέλος του τριμήνου. Η ομάδα πωλήσεων είχε ήδη εξασφαλίσει τραπεζικούς πελάτες. Η ομάδα μηχανικής είχε σκιαγραφήσει μια cloud-native αρχιτεκτονική, με χαρακτηριστικά ταυτότητας, σήματα συσκευών, μεταδεδομένα συναλλαγών, βαθμολογίες συμπεριφορικού κινδύνου, διαχειριζόμενη βάση δεδομένων και τρίτο πάροχο αναλυτικών υπηρεσιών.

Στα χαρτιά, η πλατφόρμα έμοιαζε με εμπορική τομή. Για την Anya, έμοιαζε με πέντε συζητήσεις συμμόρφωσης που έφταναν ταυτόχρονα.

Ως πάροχος χρηματοοικονομικής τεχνολογίας, η εταιρεία δεχόταν πίεση από το DORA. Ως πάροχος υπηρεσιών υπολογιστικού νέφους και ψηφιακής πλατφόρμας, έπρεπε να κατανοήσει την έκθεσή της στο NIS2. Επειδή η πλατφόρμα επεξεργαζόταν δεδομένα προσωπικού χαρακτήρα φυσικών προσώπων στην ΕΕ, εφαρμοζόταν το GDPR. Οι επιχειρησιακοί πελάτες ανέμεναν πιστοποίηση ISO/IEC 27001:2022. Αν η υπηρεσία εντασσόταν σε συνδεδεμένο προϊόν λογισμικού, οι απαιτήσεις του Cyber Resilience Act θα πρόσθεταν αποδεικτικά στοιχεία προϊόντος για ασφάλεια εκ σχεδιασμού.

Η ομάδα ανάπτυξης πρότεινε το συνήθες σχέδιο ασφάλειας: σάρωση εξαρτήσεων, εκτέλεση σαρώσεων ευπαθειών, προγραμματισμός δοκιμών διείσδυσης και διόρθωση των κρίσιμων ευρημάτων πριν από την παραγωγική λειτουργία. Η Anya γνώριζε ότι αυτό δεν αρκούσε. Αυτές οι δραστηριότητες ελέγχουν αυτό που έχει ήδη κατασκευαστεί. Δεν αποδεικνύουν ότι η αρχιτεκτονική ήταν ασφαλής εκ σχεδιασμού, ότι τα όρια εμπιστοσύνης είχαν κατανοηθεί, ότι οι ροές δεδομένων προσωπικού χαρακτήρα είχαν ελαχιστοποιηθεί, ότι οι παραδοχές για τους προμηθευτές είχαν ανασκοπηθεί ή ότι τα σενάρια διακοπής υπηρεσιών είχαν εξεταστεί πριν από τη διάθεση.

Έτσι, επιβράδυνε τη σύσκεψη με τέσσερις ερωτήσεις:

1. Πού βρίσκονται τα όρια εμπιστοσύνης;
2. Ποια σενάρια κατάχρησης θα μπορούσαν να οδηγήσουν σε απάτη, έκθεση δεδομένων ή διακοπή υπηρεσιών;
3. Ποιες αποφάσεις σχεδιασμού μειώνουν τον κίνδυνο πριν γραφτεί κώδικας;
4. Ποια αποδεικτικά στοιχεία θα ικανοποιήσουν τους αξιολογητές ISO 27001, NIS2, DORA, CRA και GDPR σε έξι μήνες από σήμερα;

Στην τέταρτη ερώτηση αποτυγχάνουν πολλοί οργανισμοί. Η μοντελοποίηση απειλών αντιμετωπίζεται συχνά ως χρήσιμο εργαστήριο μηχανικής και στη συνέχεια θάβεται σε μια σελίδα wiki. Το 2026 αυτό δεν αρκεί. Για παρόχους SaaS, εταιρείες fintech, πλατφόρμες υπολογιστικού νέφους, MSPs, MSSPs, φορείς ψηφιακών υποδομών και κατασκευαστές λογισμικού, η μοντελοποίηση απειλών έχει εξελιχθεί σε μηχανισμό παραγωγής αποδεικτικών στοιχείων συμμόρφωσης.

Μια ώριμη διαδικασία μοντελοποίησης απειλών μετατρέπει ευρήματα STRIDE, σενάρια κατάχρησης και αποφάσεις αρχιτεκτονικής σε καταχωρίσεις στο Μητρώο Κινδύνων, απαιτήσεις ασφάλειας, σχέδια αντιμετώπισης κινδύνων, περιπτώσεις δοκιμών, εργασίες διασφάλισης προμηθευτών, αποδεικτικά στοιχεία προστασίας της ιδιωτικότητας εκ σχεδιασμού και ιχνηλασιμότητα προς τη Δήλωση Εφαρμοσιμότητας.

Γιατί τα αποδεικτικά στοιχεία ασφάλειας εκ σχεδιασμού έχουν πλέον σημασία

Οι σύγχρονοι κανονισμοί συγκλίνουν στην ίδια προσδοκία: οι οργανισμοί πρέπει να εντοπίζουν έγκαιρα τους κινδύνους ασφάλειας και ιδιωτικότητας, να αναθέτουν ιδιοκτησία, να εφαρμόζουν αναλογικά μέτρα ελέγχου και να διατηρούν αποδεικτικά στοιχεία.

Το ISO/IEC 27001:2022 απαιτεί Σύστημα Διαχείρισης Ασφάλειας Πληροφοριών βάσει κινδύνου. Οι ρήτρες 6.1.2 και 6.1.3 απαιτούν αξιολόγηση και αντιμετώπιση κινδύνων ασφάλειας πληροφοριών. Η ρήτρα 8.1 απαιτεί επιχειρησιακό σχεδιασμό και έλεγχο. Το Παράρτημα A παρέχει ελέγχους που πρέπει να επιλέγονται μέσω της Δήλωσης Εφαρμοσιμότητας, με βάση τον κίνδυνο, τις νομικές απαιτήσεις και τις επιχειρησιακές ανάγκες.

Το NIS2 μεταφέρει την ίδια αρχή στη διακυβέρνηση κυβερνοασφάλειας. Το Article 20 απαιτεί από τα διοικητικά όργανα να εγκρίνουν μέτρα διαχείρισης κινδύνων κυβερνοασφάλειας και να εποπτεύουν την εφαρμογή τους. Το Article 21 απαιτεί κατάλληλα και αναλογικά τεχνικά, επιχειρησιακά και οργανωτικά μέτρα, συμπεριλαμβανομένων της ανάλυσης κινδύνου, του χειρισμού περιστατικών, της επιχειρησιακής συνέχειας, της ασφάλειας της εφοδιαστικής αλυσίδας, της ασφάλειας κατά την απόκτηση, ανάπτυξη και συντήρηση, του χειρισμού ευπαθειών, της κυβερνοϋγιεινής, της κρυπτογράφησης, του ελέγχου πρόσβασης, της διαχείρισης περιουσιακών στοιχείων και της MFA όπου ενδείκνυται.

Το DORA εφαρμόζει, από τις 17 Ιανουαρίου 2025, οπτική επιχειρησιακής ανθεκτικότητας για τον χρηματοοικονομικό τομέα. Απαιτεί από τις καλυπτόμενες χρηματοοικονομικές οντότητες να διατηρούν άρτιο, ολοκληρωμένο και τεκμηριωμένο πλαίσιο διαχείρισης κινδύνων ΤΠΕ, να εντοπίζουν περιουσιακά στοιχεία ΤΠΕ και εξαρτήσεις, να εφαρμόζουν προστατευτικά και προληπτικά μέτρα, να ανιχνεύουν ανώμαλη δραστηριότητα, να δοκιμάζουν την ψηφιακή επιχειρησιακή ανθεκτικότητα, να διαχειρίζονται τον κίνδυνο τρίτων παρόχων ΤΠΕ και να προετοιμάζουν ικανότητες απόκρισης και ανάκαμψης. Για τις καλυπτόμενες χρηματοοικονομικές οντότητες, το DORA είναι η ειδική ανά τομέα νομική πράξη της Ένωσης για τις επικαλυπτόμενες υποχρεώσεις του NIS2.

Το GDPR προσθέτει την αρχή της λογοδοσίας και την προστασία των δεδομένων ήδη από τον σχεδιασμό και εξ ορισμού. Κάθε σύστημα που επεξεργάζεται δεδομένα προσωπικού χαρακτήρα πρέπει να μπορεί να αποδεικνύει νόμιμη, θεμιτή, διαφανή, περιορισμένη ως προς τον σκοπό, ελαχιστοποιημένη, περιορισμένη ως προς τη διατήρηση και ασφαλή επεξεργασία. Ένα μοντέλο απειλών που χαρτογραφεί ροές δεδομένων προσωπικού χαρακτήρα, διαδρομές πρόσβασης, αρχεία καταγραφής, διατήρηση, διαγραφή και διαβιβάσεις σε τρίτους είναι άμεσα σχετικό με τα GDPR Articles 5, 25, 32 και 35.

Το Cyber Resilience Act αυξάνει την πίεση για προϊόντα με ψηφιακά στοιχεία. Οι ομάδες προϊόντων χρειάζονται αποδεικτικά στοιχεία κύκλου ζωής που δείχνουν ότι εξετάστηκαν έγκαιρα οι κίνδυνοι κυβερνοασφάλειας, η προβλέψιμη κακή χρήση, οι διεπαφές, οι μηχανισμοί επικαιροποίησης, οι ροές αυθεντικοποίησης και οι παραδοχές χειρισμού ευπαθειών.

Το συμπέρασμα είναι σαφές: αν μια ανασκόπηση αρχιτεκτονικής δεν μπορεί να ιχνηλατηθεί σε κινδύνους, μέτρα ελέγχου, ιδιοκτήτες, μετριασμούς και δοκιμές, θα είναι δύσκολο να υποστηριχθεί σε έλεγχο ή κανονιστική ανασκόπηση το 2026.

Το μοντέλο της Clarysec: ένα μοντέλο απειλών, πολλαπλά αποτελέσματα

Η προσέγγιση της Clarysec ξεκινά από μια πρακτική αρχή: ένα μοντέλο απειλών δεν είναι ολοκληρωμένο μέχρι να παράγει αποφάσεις που μπορούν να ελεγχθούν.

Στο Zenith Blueprint: Ο οδικός χάρτης 30 βημάτων για ελεγκτές [ZB], η φάση διαχείρισης κινδύνων, Βήμα 9, παρέχει στις ομάδες μια απλή μορφή για τη μετατροπή τεχνικών παρατηρήσεων σε γλώσσα κινδύνου:

«Τώρα συνδυάστε Περιουσιακό στοιχείο + Απειλή + Ευπάθεια σε μια συνοπτική περιγραφή σεναρίου κινδύνου. Ουσιαστικά, περιγράψτε το πιθανό περιστατικό. Αυτό αργότερα θα αποτελέσει γραμμή στο Μητρώο Κινδύνων. Χρησιμοποιήστε μια απλή μορφή: “[Απειλή] εκμεταλλεύεται [ευπάθεια] σε [περιουσιακό στοιχείο], με αποτέλεσμα [αντίκτυπο]”.»

Αυτή η πρόταση είναι η γέφυρα μεταξύ μηχανικής και συμμόρφωσης.

Μια σημείωση σε πίνακα, όπως «κίνδυνος πλαστοπροσωπίας API συνεργάτη», γίνεται:

«Επιτιθέμενος εκμεταλλεύεται αδύναμη αυθεντικοποίηση API συνεργάτη στο API κινδύνου συναλλαγών, με αποτέλεσμα μη εξουσιοδοτημένη πρόσβαση σε αποφάσεις κινδύνου πληρωμών και έκθεση δεδομένων προσωπικού χαρακτήρα.»

Πλέον το εύρημα έχει περιουσιακό στοιχείο, απειλή, ευπάθεια και αντίκτυπο. Μπορεί να αξιολογηθεί, να ανατεθεί, να αντιμετωπιστεί, να δοκιμαστεί και να γίνει αποδεκτό.

Το επίπεδο πολιτικών καθιστά αυτή την πρακτική επαναλήψιμη. Η P24 Πολιτική Ασφαλούς Ανάπτυξης [P24] ορίζει:

«Όλες οι νέες εφαρμογές και οι μείζονες αλλαγές πρέπει να υποβάλλονται σε ανασκόπηση ασφαλούς αρχιτεκτονικής και μοντελοποίηση απειλών πριν από την έναρξη της ανάπτυξης.»
Από την ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα πολιτικής 6.1.1.

Απαιτεί επίσης:

«Οι ανασκοπήσεις σχεδιασμού πρέπει να τεκμηριώνουν διαγράμματα ροής δεδομένων, όρια εμπιστοσύνης και μέτρα μετριασμού για τους αναγνωρισμένους κινδύνους.»
Από την ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα πολιτικής 6.1.2.

Αυτές οι δύο ρήτρες αποτελούν ισχυρά σημεία αναφοράς για έλεγχο. Δείχνουν ότι η μοντελοποίηση απειλών δεν είναι προαιρετική και ότι τα αποδεικτικά στοιχεία σχεδιασμού πρέπει να περιλαμβάνουν διαγράμματα, όρια και αποφάσεις μετριασμού.

Η P06 Πολιτική Διαχείρισης Κινδύνων [P06] συνδέει τη μοντελοποίηση απειλών με τη διαχείριση κινδύνων σε επιχειρησιακό επίπεδο:

«Όλες οι επιχειρησιακές μονάδες πρέπει να αναγνωρίζουν προληπτικά κινδύνους με χρήση δομημένων τεχνικών που προέρχονται από το ISO/IEC 27005:2024, συμπεριλαμβανομένων της μοντελοποίησης απειλών, της χαρτογράφησης εξαρτήσεων περιουσιακών στοιχείων και της αναγνώρισης βάσει σεναρίων.»
Από την ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα πολιτικής 6.1.1.

Ορίζει επίσης:

«Οι αναγνωρισμένοι κίνδυνοι πρέπει να τεκμηριώνονται με αναφορά στον ιδιοκτήτη περιουσιακού στοιχείου, τον φορέα απειλής, την ευπάθεια και τον πιθανό αντίκτυπο στην Εμπιστευτικότητα, Ακεραιότητα και Διαθεσιμότητα (CIA).»
Από την ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα πολιτικής 6.1.4.

Αυτή είναι η αλυσίδα αποδεικτικών στοιχείων που θέλουν να βλέπουν οι ελεγκτές: απαίτηση πολιτικής, δραστηριότητα σχεδιασμού, σενάριο κινδύνου, επιλογή μέτρου ελέγχου, υλοποίηση, δοκιμή και έγκριση.

Το STRIDE καθιστά την κάλυψη συστηματική, τα σενάρια κατάχρησης την καθιστούν πραγματική

Το STRIDE παραμένει μία από τις πιο χρήσιμες μεθόδους μοντελοποίησης απειλών στο στάδιο του σχεδιασμού, επειδή υποχρεώνει τις ομάδες να εξετάζουν έξι κοινές κατηγορίες αστοχίας:

• Πλαστοπροσωπία
• Παραποίηση
• Άρνηση ευθύνης
• Κοινολόγηση πληροφοριών
• Άρνηση υπηρεσίας
• Κλιμάκωση προνομίων

Για την πλατφόρμα κινδύνου πληρωμών της Anya, η ομάδα εφάρμοσε το STRIDE σε κάθε στοιχείο, ροή δεδομένων και όριο εμπιστοσύνης.

Η πλαστοπροσωπία έθεσε το ερώτημα αν ένας πελάτης API συνεργάτη θα μπορούσε να υποδυθεί τραπεζικό πελάτη σε περίπτωση αδύναμης αμοιβαίας αυθεντικοποίησης. Η παραποίηση ανέδειξε τον κίνδυνο χειραγώγησης σημάτων συσκευής ή ποσών συναλλαγών πριν από την εισαγωγή τους. Η άρνηση ευθύνης ανέδειξε την ανάγκη για αρχεία καταγραφής ελέγχου διαχειριστών και συναλλαγών. Η κοινολόγηση πληροφοριών εστίασε στη διαρροή μέσω αρχείων καταγραφής, εξαγωγών αναλυτικών, εργαλείων υποστήριξης και API αναφορών. Η άρνηση υπηρεσίας υποχρέωσε την ομάδα να εξετάσει παράθυρα αιχμής συναλλαγών και πλημμύρες κακοδιαμορφωμένων αιτημάτων. Η κλιμάκωση προνομίων ανέδειξε κινδύνους σε ρόλους υποστήριξης, διακριτικά συνεδρίας και διαχειριστικές λειτουργίες.

Τα σενάρια κατάχρησης μετέτρεψαν αυτές τις κατηγορίες σε πραγματικές ιστορίες:

• Απατεώνας ανεβάζει παραποιημένα σήματα συσκευής για να επηρεάσει μια βαθμολογία κινδύνου.
• Συμβιβασμένο διαπιστευτήριο συνεργάτη πλημμυρίζει το API με δόλια αιτήματα.
• Προγραμματιστής χρησιμοποιεί δεδομένα προσωπικού χαρακτήρα παραγωγής σε περιβάλλον δοκιμών.
• Κακόβουλος εσωτερικός χρήστης εξάγει αναγνωριστικά πελατών και λογική βαθμολόγησης.
• Διακοπή σε προμηθευτή αναλυτικών υπηρεσιών υπολογιστικού νέφους εμποδίζει αποφάσεις κινδύνου κατά τη διάρκεια παραθύρου πληρωμών.
• Εσφαλμένη παραμετροποίηση αποθήκευσης εκθέτει ανεβασμένα έγγραφα ταυτότητας.
• Ροή εργασίας διαγραφής αφαιρεί την εγγραφή της εφαρμογής, αλλά αφήνει αντίγραφα ασφαλείας και αντίγραφα προμηθευτών.

Κάθε σενάριο κατάχρησης έγινε εγγραφή κινδύνου σχεδιασμού με το επηρεαζόμενο περιουσιακό στοιχείο, τον φορέα απειλής, την ευπάθεια, τον αντίκτυπο, τις υφιστάμενες παραδοχές, τον απαιτούμενο μετριασμό, τον ιδιοκτήτη υπολειπόμενου κινδύνου, τα αποδεικτικά στοιχεία δοκιμών και τη ρυθμιστική συνάφεια.

Αυτή η δομή αποτρέπει ασαφή ευρήματα όπως «κίνδυνος ασφάλειας API». Παράγει δηλώσεις κινδύνου επιπέδου αποδεικτικών στοιχείων, όπως:

«Επιτιθέμενος χρησιμοποιεί κλεμμένα διαπιστευτήρια συνεργάτη για να υποβάλει δόλια αιτήματα βαθμολόγησης μέσω του API κινδύνου συναλλαγών, με αποτέλεσμα συμβιβασμό της ακεραιότητας των αποφάσεων κινδύνου, πιθανή οικονομική ζημία για πελάτες και μη εξουσιοδοτημένη επεξεργασία δεδομένων προσωπικού χαρακτήρα.»

Χαρτογράφηση της μοντελοποίησης απειλών σε ISO/IEC 27001:2022 και ISO/IEC 27002:2022

Το ISO/IEC 27001:2022 δεν απαιτεί ρητά μοντελοποίηση απειλών. Απαιτεί συνεπή, τεκμηριωμένη αξιολόγηση κινδύνων και αντιμετώπιση κινδύνων. Η μοντελοποίηση απειλών είναι μία από τις ισχυρότερες μεθόδους παραγωγής αυτών των αποδεικτικών στοιχείων σε περιβάλλοντα λογισμικού, υπολογιστικού νέφους και προϊόντων.

Το κλειδί είναι η ιχνηλασιμότητα. Στο ZB, η φάση διαχείρισης κινδύνων, Βήμα 13, συνιστά την αντιστοίχιση ελέγχων σε κινδύνους και ρήτρες, συμπεριλαμβανομένων αναφορών στο Παράρτημα A μέσα στα σχέδια αντιμετώπισης κινδύνων και επισήμανσης των σημείων όπου οι έλεγχοι υποστηρίζουν GDPR, NIS2 ή DORA.

Το Zenith Controls: Ο οδηγός διατομεακής συμμόρφωσης [ZC] συμβάλλει στη δόμηση αυτής της ιχνηλασιμότητας, χαρτογραφώντας ελέγχους ISO/IEC 27002:2022 σε συναφείς ελέγχους, ελεγκτικές προσδοκίες και εξωτερικά πλαίσια.

Για τη μοντελοποίηση απειλών, ο έλεγχος 5.8 του ISO/IEC 27002:2022, Ασφάλεια πληροφοριών στη διαχείριση έργων, αποτελεί το σημείο αναφοράς διακυβέρνησης έργου. Δείχνει ότι η ασφάλεια ενσωματώνεται στην έναρξη, τον σχεδιασμό, την εκτέλεση και την αποδοχή του έργου.

Ο έλεγχος 8.25, Ασφαλής κύκλος ζωής ανάπτυξης, αποτελεί το σημείο αναφοράς για το SDLC. Το ZC συνδέει το 8.25 με υποστηρικτικούς ελέγχους όπως 8.26 απαιτήσεις ασφάλειας εφαρμογών, 8.27 ασφαλής αρχιτεκτονική συστήματος και αρχές μηχανικής, 8.28 ασφαλής κωδικοποίηση, 8.29 δοκιμές ασφάλειας κατά την ανάπτυξη και αποδοχή, 8.30 εξωτερική ανάθεση ανάπτυξης και 8.31 διαχωρισμός περιβαλλόντων ανάπτυξης, δοκιμών και παραγωγής.

Αυτή η χαρτογράφηση βοηθά να μετατραπεί ένα εργαστήριο σχεδιασμού σε αποδεικτικό στοιχείο Δήλωσης Εφαρμοσιμότητας. Υποστηρίζει επίσης τις ρήτρες 4 έως 6 του ISO/IEC 27001:2022, επειδή οι απαιτήσεις ενδιαφερόμενων μερών, το πεδίο εφαρμογής του ISMS, οι δεσμεύσεις ηγεσίας και οι αποφάσεις αντιμετώπισης κινδύνων καθίστανται ορατές.

Χάρτης διατομεακής συμμόρφωσης για NIS2, DORA, CRA, GDPR και NIST CSF

Ένα σωστά εκτελεσμένο μοντέλο απειλών δεν πρέπει να παράγει πέντε αποσυνδεδεμένες ροές εργασιών συμμόρφωσης. Πρέπει να παράγει μία δέσμη αποδεικτικών στοιχείων κινδύνου σχεδιασμού που μπορεί να επαναχρησιμοποιηθεί σε πολλαπλά πλαίσια.

Το NIST CSF 2.0 είναι ιδιαίτερα χρήσιμο για την επικοινωνία με τη διοίκηση. Η λειτουργία GOVERN υποστηρίζει νομικές, κανονιστικές, συμβατικές υποχρεώσεις και υποχρεώσεις ιδιωτικότητας, ενώ τα αποτελέσματα που αφορούν την εφοδιαστική αλυσίδα βοηθούν στη σύνδεση της κρισιμότητας προμηθευτών, των συμβατικών απαιτήσεων, της δέουσας επιμέλειας, της παρακολούθησης και του σχεδιασμού περιστατικών με τα ίδια αποδεικτικά στοιχεία μοντελοποίησης απειλών.

Το GDPR απαιτεί ιδιαίτερη προσοχή, επειδή η μοντελοποίηση απειλών και η εργασία DPIA πρέπει να αλληλοενισχύονται. Η P17 Πολιτική Προστασίας Δεδομένων και Ιδιωτικότητας [P17] ορίζει:

«Η μοντελοποίηση απειλών και οι Εκτιμήσεις Αντικτύπου σχετικά με την Προστασία Δεδομένων (DPIAs) είναι υποχρεωτικές για συστήματα επεξεργασίας υψηλού κινδύνου.»
Από την ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα πολιτικής 6.3.4.

Για μικρότερες ομάδες, η P17S Πολιτική Προστασίας Δεδομένων και Ιδιωτικότητας - ΜΜΕ [P17S] ορίζει:

«Η προστασία της ιδιωτικότητας ήδη από τον σχεδιασμό και εξ ορισμού πρέπει να εφαρμόζεται σε όλα τα νέα συστήματα και υπηρεσίες»
Από την ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα πολιτικής 5.3.1.

Το αποτέλεσμα είναι ένα πρακτικό μοντέλο λειτουργίας: χρησιμοποιήστε τα ίδια διαγράμματα ροής δεδομένων, όρια εμπιστοσύνης και σενάρια κατάχρησης για κίνδυνο ασφάλειας, κίνδυνο ιδιωτικότητας, ανασκόπηση προμηθευτών και ρυθμιστικά αποδεικτικά στοιχεία.

90λεπτη συνεδρία κινδύνου σχεδιασμού για χαρακτηριστικά υψηλού κινδύνου

Η μοντελοποίηση απειλών δεν χρειάζεται να ξεκινά ως βαρύ πρόγραμμα. Για νέο API πληρωμών, ροή εργασίας ένταξης, χαρακτηριστικό με τεχνητή νοημοσύνη, υπηρεσία ταυτότητας, μεταφορά υπηρεσιών σε υπολογιστικό νέφος ή εξωτερική ενσωμάτωση, μια 90λεπτη συνεδρία κινδύνου σχεδιασμού μπορεί να παραγάγει πολύτιμα αποδεικτικά στοιχεία.

1. Ανοίξτε σημείο ελέγχου ασφάλειας έργου

Χρησιμοποιήστε τη ρήτρα 6.1.1 της P24 ως έναυσμα. Για κάθε νέα εφαρμογή ή μείζονα αλλαγή, δημιουργήστε φάκελο αποδεικτικών στοιχείων με:

• Διάγραμμα αρχιτεκτονικής
• Διάγραμμα ροής δεδομένων
• Χάρτη ορίων εμπιστοσύνης
• Κατάλογο περιουσιακών στοιχείων
• Σημειώσεις για δεδομένα προσωπικού χαρακτήρα
• Κατάλογο προμηθευτών και εξαρτήσεων ΤΠΕ
• Αρχικές απαιτήσεις ασφάλειας
• Φύλλο εργασίας μοντέλου απειλών
• Καταχωρίσεις Μητρώου Κινδύνων
• Ιχνηλασιμότητα μετριασμών και δοκιμών
• Αρχείο έγκρισης

Για μικρότερους οργανισμούς, η P24S Πολιτική Ασφαλούς Ανάπτυξης - ΜΜΕ [P24S] υποστηρίζει την ίδια πειθαρχία, συνδέοντας τις διαδικασίες ασφαλούς ανάπτυξης με τον έλεγχο πρόσβασης προγραμματιστών, τις δοκιμές, τη μοντελοποίηση απειλών και την τεκμηρίωση. Απαιτεί επίσης κεντρική τήρηση καταλόγων ελέγχου, εγκρίσεων ανασκόπησης, αναφορών δοκιμών και απογραφών στοιχείων για σκοπούς ελέγχου. Η ρήτρα 11.3.1 παραπέμπει στα SA-3 έως SA-15 για τον ορισμό διαδικασιών ασφαλούς ανάπτυξης, συμπεριλαμβανομένης της μοντελοποίησης απειλών.

2. Σχεδιάστε την ελάχιστη βιώσιμη ροή δεδομένων

Μην ξεκινήσετε με γυαλισμένο διάγραμμα. Ξεκινήστε με τις ροές που δημιουργούν κίνδυνο:

• Ο χρήστης ανεβάζει έγγραφα ταυτότητας ή δεδομένα συναλλαγών.
• Η διαδικτυακή εφαρμογή στέλνει αιτήματα στο API.
• Το API γράφει σε διαχειριζόμενη αποθήκευση ή σε βάση δεδομένων.
• Ο προμηθευτής λαμβάνει δεδομένα επαλήθευσης ή αναλυτικών.
• Η εσωτερική πύλη αναλυτών εμφανίζει αποτελέσματα.
• Το σύστημα πελάτη ανακτά κατάσταση ή αποφάσεις.
• Αρχεία καταγραφής, εργαλεία παρακολούθησης και αντίγραφα ασφαλείας λαμβάνουν αντίγραφα.

Σημειώστε κάθε όριο εμπιστοσύνης: διαδίκτυο προς εφαρμογή, εφαρμογή προς API, εσωτερική υπηρεσία προς προμηθευτή, σύστημα παραγωγής προς αναλυτικά, διαχειριστής προς προνομιούχα λειτουργία και παραγωγή προς μη παραγωγικό περιβάλλον.

3. Εκτελέστε μαζί STRIDE και σενάρια κατάχρησης

Για κάθε όριο, θέστε τις ερωτήσεις STRIDE και γράψτε σενάρια κατάχρησης σε απλή επιχειρησιακή γλώσσα. Στόχος δεν είναι να καταγραφεί κάθε πιθανή επίθεση. Στόχος είναι να εντοπιστούν εύλογα, ουσιώδη σενάρια που επηρεάζουν την εμπιστευτικότητα, την ακεραιότητα, τη διαθεσιμότητα, την ιδιωτικότητα, την ανθεκτικότητα ή την ασφάλεια.

4. Μετατρέψτε τα ευρήματα σε σενάρια κινδύνου

Χρησιμοποιήστε τον τύπο του ZB Βήμα 9:

«[Απειλή] εκμεταλλεύεται [ευπάθεια] σε [περιουσιακό στοιχείο], με αποτέλεσμα [αντίκτυπο].»

Για παράδειγμα:

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

Στη συνέχεια προσθέστε ιδιοκτήτη, πιθανότητα, αντίκτυπο, εγγενή κίνδυνο, επιλογή αντιμετώπισης, στοχευόμενο έλεγχο, υπολειπόμενο κίνδυνο και αποδεικτικά στοιχεία.

5. Παραγάγετε απαιτήσεις και δοκιμές

Ένα μοντέλο απειλών δεν ολοκληρώνεται όταν καταγραφούν οι κίνδυνοι. Ολοκληρώνεται όταν οι μετριασμοί υλοποιηθούν, δοκιμαστούν ή γίνουν επισήμως αποδεκτοί.

Η Πολιτική Διαχείρισης Αλλαγών - ΜΜΕ παρέχει ένα πρακτικό έναυσμα:

«Εάν μια αλλαγή αφορά ευαίσθητα δεδομένα, δικαιώματα πρόσβασης συστήματος ή εξωτερικές ενσωματώσεις, απαιτείται ανασκόπηση επιπτώσεων στην ασφάλεια. Το ορισμένο σημείο επαφής ασφάλειας ή συμμόρφωσης πρέπει να αξιολογεί αν η αλλαγή εισάγει πρόσθετους κινδύνους και να συνιστά πρόσθετες δικλίδες ασφαλείας.»
Από την ενότητα «Αντιμετώπιση κινδύνων και εξαιρέσεις», ρήτρα πολιτικής 7.5.1.

Τα ευαίσθητα δεδομένα, τα δικαιώματα πρόσβασης και οι εξωτερικές ενσωματώσεις είναι ακριβώς οι αλλαγές που απαιτούν ανασκόπηση κινδύνου σχεδιασμού.

Τι θα ρωτήσουν διαφορετικοί ελεγκτές

Ένας ελεγκτής ISO/IEC 27001:2022 θα ρωτήσει αν η μοντελοποίηση απειλών αποτελεί μέρος καθορισμένης διαδικασίας αξιολόγησης κινδύνων, αν τα κριτήρια είναι συνεπή, αν οι ιδιοκτήτες κινδύνου ενέκριναν τους υπολειπόμενους κινδύνους, αν τα σχέδια αντιμετώπισης κινδύνων συνδέονται με τη SoA και αν τα αποδεικτικά στοιχεία διατηρούνται. Θα αναζητήσει επαναληψιμότητα, ιστορικό εκδόσεων, ορατότητα στην ανασκόπηση από τη Διοίκηση και κάλυψη από τον εσωτερικό έλεγχο.

Για το Παράρτημα A, θα συνδέσει τα αποδεικτικά στοιχεία σας με τα 5.8, 8.25, 8.26, 8.27 και 8.29. Το ZB Βήμα 21, Έλεγχοι στην πράξη, αναδεικνύει την ασφαλή αρχιτεκτονική συστήματος και τις αρχές μηχανικής, ρωτώντας ποιες αρχές καθοδηγούν την ασφαλή αρχιτεκτονική. Οι ελεγκτές μπορεί να ρωτήσουν αν η μοντελοποίηση απειλών διεξάγεται κατά τον σχεδιασμό με μεθόδους όπως STRIDE ή δένδρα επίθεσης και αν οι αρχιτεκτονικές αποφάσεις ανασκοπούνται πριν από την υλοποίηση.

Ένας αξιολογητής NIS2 θα εστιάσει στη διακυβέρνηση και την αναλογικότητα. Μπορεί να ρωτήσει αν η διοίκηση ενέκρινε την προσέγγιση διαχείρισης κινδύνων κυβερνοασφάλειας, αν καλύπτονται η ασφαλής απόκτηση, ανάπτυξη και συντήρηση, αν εξετάζονται οι ευπάθειες προμηθευτών, αν τα σενάρια περιστατικών συνδέονται με ροές αναφοράς και αν αναλύονται σενάρια συνέχειας. Η σταδιακή αναφορά σημαντικών περιστατικών του NIS2 Article 23, συμπεριλαμβανομένης της έγκαιρης προειδοποίησης εντός 24 ωρών, της ειδοποίησης εντός 72 ωρών και της τελικής αναφοράς εντός ενός μήνα, καθιστά ιδιαίτερα πολύτιμη τη σαφήνεια των σεναρίων.

Ένας εξεταστής DORA θα εστιάσει στη διακυβέρνηση κινδύνων ΤΠΕ, τις κρίσιμες λειτουργίες, τα περιουσιακά στοιχεία ΤΠΕ, τις εξωτερικές εξαρτήσεις, τις δοκιμές ανθεκτικότητας και τις υπηρεσίες τρίτων παρόχων ΤΠΕ. Αν το σύστημα υποστηρίζει κρίσιμη ή σημαντική λειτουργία, θα αναμένει ισχυρότερα αποδεικτικά στοιχεία που συνδέουν σενάρια απειλών με αποθετήρια περιουσιακών στοιχείων, χάρτες εξαρτήσεων, σχέδια δοκιμών, συμβάσεις τρίτων και μέτρα ανάκαμψης.

Ένας αξιολογητής ιδιωτικότητας θα εξετάσει τις ροές δεδομένων και θα ρωτήσει αν η επεξεργασία δεδομένων προσωπικού χαρακτήρα είναι αναγκαία, νόμιμη, ελαχιστοποιημένη και προστατευμένη. Θα ρωτήσει αν εμπλέκονται ειδικές κατηγορίες δεδομένων, αν χρησιμοποιείται ψευδωνυμοποίηση ή κρυπτογράφηση, αν η διατήρηση αιτιολογείται και αν απαιτείται DPIA. Η μοντελοποίηση απειλών και η DPIA είναι διαφορετικές δραστηριότητες, αλλά πρέπει να μοιράζονται διαγράμματα, σενάρια και μετριασμούς.

Ένας αξιολογητής με προσανατολισμό στο NIST CSF ή στο COBIT 2019 θα αναζητήσει διακυβέρνηση, ιδιοκτησία διεργασιών, απόδοση, λογοδοσία και συνεχή βελτίωση. Μπορεί να τον ενδιαφέρει λιγότερο το ίδιο το φύλλο εργασίας STRIDE και περισσότερο το αν η διαδικασία είναι αξιόπιστη, μετρήσιμη, εγκεκριμένη και βελτιώνεται.

Συνήθεις αστοχίες τεκμηρίωσης στη μοντελοποίηση απειλών

Οι πιο συχνές αστοχίες δεν είναι τεχνικές. Είναι αστοχίες αποδεικτικών στοιχείων.

Οι ομάδες εκτελούν μοντελοποίηση απειλών πολύ αργά, αφού το σύστημα έχει ήδη κατασκευαστεί. Σε αυτό το σημείο, το εργαστήριο μετατρέπεται σε ενημέρωση πριν από δοκιμή διείσδυσης αντί για έλεγχο σχεδιασμού.

Τα ευρήματα δεν μετατρέπονται σε γλώσσα κινδύνου. Φράσεις όπως «προσθήκη αυθεντικοποίησης» ή «ζήτημα καταγραφής» μπορεί να βοηθούν τους μηχανικούς, αλλά οι ελεγκτές χρειάζονται περιουσιακό στοιχείο, απειλή, ευπάθεια, αντίκτυπο, ιδιοκτήτη, αντιμετώπιση και υπολειπόμενο κίνδυνο.

Η ιδιωτικότητα και η ασφάλεια διαχωρίζονται. Μία ομάδα τεκμηριώνει κινδύνους πλαστοπροσωπίας και επιθέσεων έγχυσης, ενώ άλλη τεκμηριώνει διατήρηση και νομική βάση. Η λογοδοσία του GDPR λειτουργεί καλύτερα όταν οι ροές δεδομένων, τα σενάρια κατάχρησης και τα εναύσματα DPIA συνδέονται.

Οι παραδοχές για προμηθευτές παραμένουν ατεκμηρίωτες. Το NIS2, το DORA και το NIST CSF αυξάνουν όλα τις προσδοκίες για τον κίνδυνο εφοδιαστικής αλυσίδας ΤΠΕ. Αν ένας μετριασμός εξαρτάται από την κρυπτογράφηση, την καταγραφή, τη διαγραφή, την ανθεκτικότητα ή την απόκριση σε περιστατικά ενός προμηθευτή, συλλέξτε τα αποδεικτικά στοιχεία.

Οι δοκιμές δεν αντιστοιχίζονται πίσω στις απειλές. Μια αναφορά δοκιμών διείσδυσης μπορεί να είναι χρήσιμη, αλλά μπορεί να μην αποδεικνύει ότι οι συγκεκριμένοι κίνδυνοι σχεδιασμού μετριάστηκαν. Κάθε μείζον εύρημα απειλής πρέπει να έχει αποδεικτικά στοιχεία επικύρωσης.

Η αποδοχή υπολειπόμενου κινδύνου είναι ανεπίσημη. Το «το αποδεχόμαστε για το MVP» δεν αρκεί. Το ISO/IEC 27001:2022 αναμένει αποδοχή υπολειπόμενου κινδύνου από κατάλληλους ιδιοκτήτες κινδύνου ως τεκμηριωμένες πληροφορίες.

Η δέσμη αποδεικτικών στοιχείων μοντελοποίησης απειλών για το 2026

Για κάθε μείζον σύστημα ή σημαντική αλλαγή, τηρείτε τυποποιημένη δέσμη αποδεικτικών στοιχείων που μπορεί να υποστηρίξει ISO 27001, NIS2, DORA, CRA, GDPR και διασφάλιση πελατών.

Η Πολιτική Διαχείρισης Κινδύνων - ΜΜΕ αποτυπώνει καλά το μοντέλο λειτουργίας:

«Διασφαλίζει ότι η διαχείριση κινδύνων αποτελεί ενεργό συστατικό του σχεδιασμού, της εκτέλεσης έργων, της επιλογής προμηθευτών και της απόκρισης σε περιστατικά, σε ευθυγράμμιση με ISO 27001, ISO 31000 και τις ισχύουσες κανονιστικές απαιτήσεις.»
Από την ενότητα «Σκοπός», ρήτρα πολιτικής 1.2.

Αυτός είναι ο σωστός στόχος. Η μοντελοποίηση απειλών πρέπει να επηρεάζει τον σχεδιασμό, τη μηχανική, την επιλογή προμηθευτών, την απόκριση σε περιστατικά και την ετοιμότητα για έλεγχο.

Κάντε τη μοντελοποίηση απειλών έτοιμη για έλεγχο πριν από την επόμενη έκδοση

Οι οργανισμοί που θα διαχειριστούν καλύτερα την πίεση συμμόρφωσης του 2026 δεν είναι εκείνοι με τα περισσότερα διαγράμματα. Είναι εκείνοι που μπορούν να αποδείξουν μια απλή αλυσίδα:

Ο κίνδυνος σχεδιασμού αναγνωρίστηκε. Ο κίνδυνος αξιολογήθηκε. Οι έλεγχοι επιλέχθηκαν. Οι μετριασμοί υλοποιήθηκαν. Οι δοκιμές επικύρωσαν τους μετριασμούς. Ο υπολειπόμενος κίνδυνος εγκρίθηκε. Τα αποδεικτικά στοιχεία αντιστοιχίζονται στα πλαίσια που έχουν σημασία.

Ξεκινήστε με μία αλλαγή υψηλού κινδύνου: ενσωμάτωση πληρωμών, νέο API, ροή εργασίας με τεχνητή νοημοσύνη, χαρακτηριστικό ταυτότητας, μεταφορά υπηρεσιών σε υπολογιστικό νέφος, διάθεση προϊόντος για πελάτες ή υπηρεσία συνδεδεμένη με προμηθευτή. Εκτελέστε μια 90λεπτη συνεδρία κινδύνου σχεδιασμού. Χρησιμοποιήστε το ZB για να μετατρέψετε ευρήματα σε σενάρια κινδύνου, σχέδια αντιμετώπισης κινδύνων και ιχνηλασιμότητα SoA. Χρησιμοποιήστε το ZC για να χαρτογραφήσετε ελέγχους ISO/IEC 27002:2022 όπως 5.8, 8.25, 8.26, 8.27 και 8.29 σε υποστηρικτικούς ελέγχους, κίνδυνο προμηθευτών, ιδιωτικότητα, δοκιμές και ελεγκτικά αποδεικτικά στοιχεία. Ευθυγραμμίστε τις P24, P06, P17, P24S και τη διαδικασία διαχείρισης αλλαγών σας, ώστε η μοντελοποίηση απειλών να γίνει απαιτούμενη, επαναλήψιμη και ανασκοπήσιμη.

Αν θέλετε τη βοήθεια της Clarysec, ξεκινήστε με ανασκόπηση αποδεικτικών στοιχείων μοντελοποίησης απειλών. Θα αξιολογήσουμε ένα πραγματικό έργο, θα εντοπίσουμε κενά έναντι των προσδοκιών ISO/IEC 27001:2022, NIS2, DORA, CRA και GDPR και θα σας δώσουμε έναν πρακτικό οδικό χάρτη αποκατάστασης που μπορούν να κατανοήσουν οι μηχανικοί, οι ελεγκτές και το Διοικητικό Συμβούλιό σας.