Φάκελος Ασφάλειας Προϊόντος CRA 2026 με ISO 27001

Ένας κατασκευαστής συνδεδεμένων συσκευών καλεί την CISO, τη Μαρία, σε σύσκεψη Παρασκευή απόγευμα. Οι πωλήσεις μόλις εξασφάλισαν συμφωνία ευρωπαϊκής διανομής. Το Νομικό Τμήμα ρωτά αν η εταιρεία μπορεί να τεκμηριώσει τη συμμόρφωση με το Cyber Resilience Act. Η ομάδα μηχανικής υποστηρίζει ότι η ασφαλής ανάπτυξη «καλύπτεται σε μεγάλο βαθμό», επειδή υπάρχουν ανασκοπήσεις κώδικα, SAST και εφαρμογή διορθώσεων. Οι Προμήθειες αναφέρουν ότι οι προμηθευτές «δεσμεύονται από συμφωνίες εμπιστευτικότητας». Οι ομάδες προϊόντων έχουν εξαρτήσεις firmware σε ένα εργαλείο, απογραφές API νέφους σε άλλο και αιτήματα ευπαθειών στο Jira. Η λειτουργία συμμόρφωσης διαθέτει τεκμήρια πιστοποίησης ISO/IEC 27001:2022, αλλά αυτά είναι οργανωμένα γύρω από το εταιρικό ISMS και όχι γύρω από κάθε προϊόν που διατίθεται στην αγορά της ΕΕ.

Τότε τίθεται το δύσκολο ερώτημα: «Αν μια αρχή της ΕΕ, ένας πελάτης, ένας κοινοποιημένος οργανισμός ή ένας μεγάλος διανομέας ζητήσει τον Φάκελο Ασφάλειας Προϊόντος το 2026, μπορούμε να τον παραδώσουμε μέσα σε μία εβδομάδα;»

Για πολλούς προμηθευτές λογισμικού, κατασκευαστές έξυπνων συσκευών και παρόχους συνδεδεμένων υπηρεσιών, η ειλικρινής απάντηση είναι όχι. Όχι επειδή δεν διαθέτουν ελέγχους ασφάλειας, αλλά επειδή τα τεκμήρια ασφάλειας προϊόντος είναι διασκορπισμένα. Τα αρχεία ασφαλούς ανάπτυξης βρίσκονται στη μηχανική. Τα SBOM δημιουργούνται ανά έκδοση, αλλά δεν υπόκεινται σε διακυβέρνηση. Η Συντονισμένη Γνωστοποίηση Ευπαθειών υπάρχει ως ιστοσελίδα, αλλά δεν συνδέεται πάντα με την αρχική αξιολόγηση, τις διορθώσεις, τις ενημερώσεις ασφάλειας και την παρακολούθηση μετά τη διάθεση στην αγορά. Η ασφάλεια προμηθευτών είναι θαμμένη στις συμβάσεις προμηθειών. Η αναφορά περιστατικών ανήκει στις λειτουργίες ασφάλειας, ενώ η τεκμηρίωση συμμόρφωσης ανήκει στη συμμόρφωση προϊόντος.

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

Εδώ το ISO/IEC 27001:2022 αποκτά ουσιαστική αξία, εφόσον χρησιμοποιηθεί σωστά. Δεν αποτελεί από μόνο του σχήμα πιστοποίησης προϊόντος, αλλά το ISMS και οι έλεγχοι για κινδύνους, περιουσιακά στοιχεία, προμηθευτές, ασφαλή ανάπτυξη, ευπάθειες και περιστατικά μπορούν να αποτελέσουν τη ραχοκοκαλιά ενός Φακέλου Ασφάλειας Προϊόντος CRA. Ο στόχος δεν είναι να δημιουργηθεί ακόμη ένα απομονωμένο σύστημα συμμόρφωσης. Ο στόχος είναι να μετατραπεί το υφιστάμενο ISMS σε σύστημα τεκμηρίων σε επίπεδο προϊόντος.

Όπως αναφέρει το Zenith Blueprint: An Auditor’s 30-Step Roadmap της Clarysec στη Φάση 2, Βήμα 8, Evidence Architecture:

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

Αυτή η πρόταση συνοψίζει τον πυρήνα της ετοιμότητας CRA. Το ερώτημα δεν είναι απλώς: «Έχουμε ασφαλή ανάπτυξη;» Το ερώτημα είναι: «Μπορούμε να αποδείξουμε ασφαλή ανάπτυξη, επίγνωση στοιχείων, χειρισμό ευπαθειών και παρακολούθηση μετά τη διάθεση στην αγορά για αυτό το προϊόν, αυτή την έκδοση, αυτή τη διάθεση και αυτή την αγορά;»

Ο Φάκελος Ασφάλειας Προϊόντος CRA είναι ένα ζωντανό σύστημα τεκμηρίων

Ένας Φάκελος Ασφάλειας Προϊόντος CRA δεν πρέπει να αντιμετωπίζεται ως στατικό PDF που παράγεται μία φορά πριν από τη διάθεση και στη συνέχεια ξεχνιέται. Πρέπει να είναι δομημένος φάκελος που αφηγείται την ιστορία ασφάλειας του προϊόντος από τη σύλληψη έως τη λήξη της υποστήριξης.

Ένας χρήσιμος φάκελος εξηγεί:

1. Τι είναι το προϊόν και πώς προορίζεται να χρησιμοποιηθεί.
2. Ποιο λογισμικό, firmware, υπηρεσίες νέφους και εξαρτήσεις τρίτων περιλαμβάνει.
3. Ποιοι κίνδυνοι κυβερνοασφάλειας αξιολογήθηκαν.
4. Ποιες απαιτήσεις ασφάλειας εφαρμόστηκαν.
5. Πώς εκτελέστηκε η ασφαλής ανάπτυξη.
6. Πώς παραλαμβάνονται, αξιολογούνται, διορθώνονται και γνωστοποιούνται οι ευπάθειες.
7. Πώς παρέχονται οι ασφαλείς ενημερώσεις.
8. Πώς ελέγχονται οι προμηθευτές και τα στοιχεία ανοικτού κώδικα.
9. Πώς κλιμακώνονται τα περιστατικά και οι ενεργά εκμεταλλευόμενες ευπάθειες.
10. Πώς παρακολουθείται το προϊόν μετά τη διάθεσή του στην αγορά.

Για έναν CISO, αυτό είναι πρόκληση τεκμηρίωσης του ISMS. Για έναν υπεύθυνο συμμόρφωσης προϊόντος, είναι τεχνική τεκμηρίωση. Για τη μηχανική, είναι DevSecOps και διακυβέρνηση εκδόσεων. Για τα διευθυντικά στελέχη, είναι πρόσβαση στην αγορά και έλεγχος ευθύνης.

Το λάθος είναι να αντιμετωπίζονται αυτά ως διακριτές ροές εργασίας. Το καλύτερο μοντέλο είναι να δημιουργείται φάκελος τεκμηρίων σε επίπεδο προϊόντος που αντιστοιχίζεται στους ελέγχους ISO/IEC 27001:2022 και ISO/IEC 27002:2022 και στη συνέχεια τα ίδια τεκμήρια να αντιστοιχίζονται, όπου απαιτείται, σε NIS2, DORA, GDPR, NIST και COBIT 2019.

Το Zenith Controls: The Cross-Compliance Guide της Clarysec το περιγράφει ως αλυσίδα από τον έλεγχο στο τεκμήριο και από εκεί στον ελεγκτή:

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

Αυτή είναι η πειθαρχία που απαιτεί η προετοιμασία CRA. Ο Φάκελος Ασφάλειας Προϊόντος δεν είναι απλώς ένας φάκελος αρχείων. Είναι το επίπεδο μετάφρασης μεταξύ μηχανικής προϊόντος, διακυβέρνησης ασφάλειας, αξιολόγησης συμμόρφωσης και διασφάλισης πελατών.

Δημιουργήστε πρώτα τον βασικό κορμό τεκμηρίων προϊόντος

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

Για εργαστήρια ετοιμότητας CRA, η Clarysec συνιστά συνήθως την ακόλουθη δομή Φακέλου Ασφάλειας Προϊόντος για οργανισμούς που ήδη λειτουργούν ISMS βάσει ISO/IEC 27001:2022.

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

Στο Zenith Blueprint, η Φάση 1, Βήμα 3 επικεντρώνεται στον καθορισμό πεδίου εφαρμογής και ορίων. Για το CRA, αυτό το βήμα γίνεται ειδικό ανά προϊόν. Ορίστε την οικογένεια προϊόντων, τις εκδόσεις λογισμικού, τις παραδοχές εγκατάστασης, τους ρόλους χρηστών, τις συνδεδεμένες υπηρεσίες, τα κανάλια ενημέρωσης και την περίοδο υποστήριξης. Αν το πεδίο εφαρμογής του ISMS είναι «εταιρική πλατφόρμα SaaS και διαχείρισης συσκευών», ο φάκελος CRA πρέπει και πάλι να απαντά σε πιο συγκεκριμένο ερώτημα: «Ποιο προϊόν με ψηφιακά στοιχεία διατίθεται στην αγορά της ΕΕ και τι περιλαμβάνεται σε αυτό το προϊόν;»

Αντιστοιχίστε την ασφαλή ανάπτυξη με αρχεία σε επίπεδο προϊόντος

Η καρδιά του Φακέλου Ασφάλειας Προϊόντος είναι τα τεκμήρια ασφάλειας ήδη από τον σχεδιασμό. Το ISO/IEC 27001:2022 παρέχει το σύστημα διακυβέρνησης. Το ISO/IEC 27002:2022 παρέχει καθοδήγηση υλοποίησης μέσω ελέγχων όπως A.8.25 Κύκλος ζωής ασφαλούς ανάπτυξης, A.8.27 Αρχές ασφαλούς αρχιτεκτονικής και μηχανικής συστημάτων, A.8.28 Ασφαλής κωδικοποίηση και A.8.29 Δοκιμές ασφάλειας στην ανάπτυξη και την αποδοχή.

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

Η Enterprise Πολιτική Ασφαλούς Ανάπτυξης της Clarysec έχει σχεδιαστεί ώστε να επιβάλλει αυτή τη διαδρομή τεκμηρίων. Στη ρήτρα 6.1, Απαιτήσεις Κύκλου Ζωής Ασφαλούς Ανάπτυξης, αναφέρει:

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

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

Για έναν έξυπνο θερμοστάτη, μια ιατρική συσκευή IoT, έναν βιομηχανικό αισθητήρα ή ένα προϊόν συνδεδεμένο με SaaS, τα τεκμήρια ασφαλούς ανάπτυξης πρέπει να περιλαμβάνουν:

• Απαιτήσεις ασφάλειας προϊόντος αντιστοιχισμένες με αναγνωρισμένους κινδύνους.
• Μοντέλο απειλών ή ανάλυση σεναρίων κατάχρησης για το προϊόν και τις συνδεδεμένες υπηρεσίες.
• Ανασκόπηση αρχιτεκτονικής, συμπεριλαμβανομένων των ορίων εμπιστοσύνης και των εξωτερικών διεπαφών.
• Πρότυπο ασφαλούς κωδικοποίησης και απόδειξη αναγνώρισης ή εκπαίδευσης προγραμματιστών.
• SAST, DAST, ανάλυση σύνθεσης λογισμικού, σάρωση μυστικών και ανάλυση firmware όπου εφαρμόζεται.
• Αιτήματα αποκατάστασης για ευρήματα υψηλού κινδύνου.
• Αρχεία αποδοχής κινδύνου με έγκριση από την επιχείρηση και την ασφάλεια.
• Λίστα ελέγχου πύλης έκδοσης που δείχνει ότι πληρούνται τα κριτήρια ασφάλειας.
• Τεκμήρια κρυπτογραφικής υπογραφής και ακεραιότητας ενημερώσεων.
• Παραδοχές περιόδου υποστήριξης και τέλους κύκλου ζωής.

Άλλα πρότυπα ενισχύουν τη μέθοδο. Το ISO/IEC 27005 υποστηρίζει την προσέγγιση κινδύνου πίσω από αυτά τα αρχεία. Το ISO/IEC 27017 είναι χρήσιμο όταν οι υπηρεσίες νέφους αποτελούν μέρος του οικοσυστήματος προϊόντος. Το ISO/IEC 27035 υποστηρίζει τον χειρισμό περιστατικών. Τα ISO/IEC 29147 και ISO/IEC 30111 είναι ιδιαίτερα συναφή για τη γνωστοποίηση ευπαθειών και τον χειρισμό ευπαθειών. Το ISO/IEC 27036 υποστηρίζει την ασφάλεια προμηθευτών, η οποία έχει σημασία όταν το προϊόν περιλαμβάνει λογισμικό εξωτερικής ανάθεσης, ενσωματωμένα modules, διαχειριζόμενες υπηρεσίες νέφους ή βιβλιοθήκες τρίτων.

Στο Zenith Controls, τα τεκμήρια ασφαλούς ανάπτυξης για CRA συνήθως αντιστοιχίζονται γύρω από θεματικές ελέγχων ISO/IEC 27002:2022, όπως ασφάλεια πληροφοριών στη διαχείριση έργων, κύκλος ζωής ασφαλούς ανάπτυξης, ασφαλής κωδικοποίηση, δοκιμές ασφάλειας, διαχείριση αλλαγών και διαχείριση τεχνικών ευπαθειών. Ο οδηγός τα συνδέει επίσης με το αποθετήριο περιουσιακών στοιχείων και τους ελέγχους προμηθευτών, επειδή καμία διαδικασία ασφαλούς ανάπτυξης δεν είναι πλήρης αν ο οργανισμός δεν μπορεί να αναγνωρίσει τα στοιχεία που διαθέτει.

Αντιμετωπίστε το SBOM ως ελεγχόμενο τεκμήριο προϊόντος

Το Software Bill of Materials αντιμετωπίζεται συχνά ως τεχνικό τεχνούργημα. Για ετοιμότητα CRA, πρέπει να αντιμετωπίζεται ως τεκμήριο προϊόντος.

Ένα χρήσιμο SBOM δείχνει ποια στοιχεία περιλαμβάνονται στο προϊόν, ποιες εκδόσεις χρησιμοποιούνται, από πού προέρχονται, ποιες άδειες ισχύουν, ποιες ευπάθειες τα επηρεάζουν και ποιες εκδόσεις τα περιέχουν. Για firmware και ενσωματωμένα προϊόντα, αυτό μπορεί να περιλαμβάνει πακέτα λειτουργικού συστήματος, bootloaders, βιβλιοθήκες, drivers, containers, modules τρίτων και εξαρτήσεις στην πλευρά του νέφους που απαιτούνται για τη λειτουργία του προϊόντος.

Το πρόβλημα είναι ότι πολλοί οργανισμοί δημιουργούν SBOM αλλά δεν τα διακυβερνούν. Ένας αγωγός δημιουργίας εκδόσεων μπορεί να παράγει αρχείο SPDX ή CycloneDX, αλλά κανείς δεν επικυρώνει την πληρότητα. Τα εργαλεία ασφάλειας μπορεί να επισημαίνουν ευπάθειες, αλλά τα αποτελέσματα δεν συνδέονται με εκδόσεις προϊόντος. Οι Προμήθειες μπορεί να εγκρίνουν έναν προμηθευτή, αλλά η λίστα στοιχείων του προμηθευτή δεν συμφωνείται με το προϊόν που κυκλοφόρησε.

Η Enterprise Πολιτική Διαχείρισης Περιουσιακών Στοιχείων της Clarysec αντιμετωπίζει αυτό το κενό διακυβέρνησης στη ρήτρα 5.2, Αποθετήριο Πληροφοριών και Συναφών Περιουσιακών Στοιχείων:

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

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

Ένας πρακτικός κανόνας τεκμηρίων SBOM είναι απλός: κάθε διατεθειμένη έκδοση προϊόντος πρέπει να έχει εγκεκριμένη απογραφή στοιχείων που μπορεί να αντιστοιχιστεί στο τεχνούργημα έκδοσης. Αν ο οργανισμός δεν μπορεί να συνδέσει το SBOM με την ακριβή εικόνα firmware, το πακέτο εφαρμογής, το digest container ή την έκδοση SaaS, το SBOM αποτελεί αδύναμο τεκμήριο.

Αν αποτύχουν περισσότερες από δύο γραμμές, το πρόβλημα συνήθως δεν είναι το εργαλείο SBOM. Είναι η διακυβέρνηση. Ο Φάκελος Ασφάλειας Προϊόντος πρέπει να καταγράφει διορθωτική ενέργεια στο ISMS, επειδή η αδυναμία τεκμηρίων CRA είναι επίσης ζήτημα αποτελεσματικότητας ελέγχων ISO/IEC 27001:2022.

Συνδέστε το CVD με τον χειρισμό ευπαθειών και τη διακυβέρνηση εκδόσεων

Η Συντονισμένη Γνωστοποίηση Ευπαθειών είναι μία από τις πιο ορατές περιοχές ετοιμότητας CRA, επειδή εξωτερικοί ερευνητές, πελάτες και αρχές μπορούν να τη δοκιμάσουν άμεσα. Η δημοσίευση σελίδας γνωστοποίησης ευπαθειών ή αρχείου security.txt είναι χρήσιμη, αλλά αποτελεί μόνο την είσοδο. Ο Φάκελος Ασφάλειας Προϊόντος πρέπει να αποδεικνύει ότι λειτουργεί η υποστηρικτική διαδικασία.

Ένα τεκμηριωμένα ισχυρό σύνολο τεκμηρίων CVD και χειρισμού ευπαθειών πρέπει να περιλαμβάνει:

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

Η Enterprise Πολιτική Διαχείρισης Ευπαθειών της Clarysec, ρήτρα 6.3, Παραλαβή, αρχική αξιολόγηση και αποκατάσταση ευπαθειών, αναφέρει:

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

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

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

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

Τα τεκμήρια προμηθευτών είναι η κρυφή αδυναμία

Ο Φάκελος Ασφάλειας Προϊόντος συχνά θα αμφισβητηθεί πιο έντονα στα σημεία όπου ο κατασκευαστής βασίζεται σε άλλους. Αυτό περιλαμβάνει ενσωματωμένα modules, ανάπτυξη firmware εξωτερικής ανάθεσης, white-label στοιχεία, φιλοξενία νέφους, SDK για κινητές εφαρμογές, υπηρεσίες πληρωμών, κρυπτογραφικές βιβλιοθήκες και παρόχους διαχειριζόμενης υποστήριξης.

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

Η Enterprise Πολιτική Ασφάλειας Τρίτων Μερών και Προμηθευτών της Clarysec, ρήτρα 7.1, Απαιτήσεις ασφάλειας προμηθευτών, αναφέρει:

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

Για το CRA, η φράση «επηρεάζουν ουσιωδώς προϊόντα» είναι κρίσιμη. Αν ένα στοιχείο προμηθευτή μπορεί να εισαγάγει ευπάθεια, να διαταράξει ενημερώσεις, να εκθέσει δεδομένα πελατών ή να θέσει σε κίνδυνο την ακεραιότητα συσκευής, ανήκει στον Φάκελο Ασφάλειας Προϊόντος.

Η ίδια πολιτική μπορεί επίσης να υποστηρίξει τη συμβατική κάλυψη του SBOM. Η ρήτρα 7.3 αναφέρει:

«Για όλα τα στοιχεία λογισμικού τρίτων, τις βιβλιοθήκες ή τα λειτουργικά συστήματα που πρόκειται να ενσωματωθούν στα εταιρικά “Προϊόντα με Ψηφιακά Στοιχεία”, ο προμηθευτής πρέπει, κατόπιν αιτήματος, να παρέχει μηχανικώς αναγνώσιμο Software Bill of Materials (SBOM) σε πρότυπο μορφότυπο όπως SPDX ή CycloneDX. Η απαίτηση αυτή πρέπει να ενσωματώνεται σε όλες τις συμβάσεις προμηθειών και προμηθευτών.»

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

Τα ISO/IEC 27002:2022 A.5.19, A.5.20 και A.5.21 παρέχουν τις βασικές θεματικές ελέγχων προμηθευτών. Το ISO/IEC 27036 προσθέτει βάθος στην ασφάλεια σχέσεων με προμηθευτές. Σε όρους διατομεακής συμμόρφωσης, το NIS2 δίνει έμφαση στην εφοδιαστική αλυσίδα και στον χειρισμό ευπαθειών. Το DORA δίνει έμφαση στον κίνδυνο τρίτων ΤΠΕ για χρηματοοικονομικές οντότητες. Το GDPR καθίσταται συναφές όταν το προϊόν ή οι υπηρεσίες νέφους του επεξεργάζονται δεδομένα προσωπικού χαρακτήρα. Το COBIT 2019 πλαισιώνει τη διακυβέρνηση προμηθευτών ως ζήτημα εταιρικής διακυβέρνησης τεχνολογίας, όχι μόνο ως ζήτημα λειτουργιών ασφάλειας.

Η παρακολούθηση μετά τη διάθεση στην αγορά μετατρέπει τα τεκμήρια σε λειτουργία

Οι πιο ώριμοι οργανισμοί ασφάλειας προϊόντων σκέφτονται πέρα από τη διάθεση. Ρωτούν: «Πώς θα γνωρίζουμε ότι αυτό το προϊόν έχει καταστεί επικίνδυνο μετά την εγκατάστασή του στο πεδίο;»

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

Η Enterprise Πολιτική Καταγραφής και Παρακολούθησης της Clarysec, ρήτρα 5.4, Παρακολούθηση και ανασκόπηση ασφάλειας, αναφέρει:

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

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

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

Στο Zenith Blueprint, η Φάση 5, Βήμα 30 επικεντρώνεται στη συνεχή βελτίωση και στην ετοιμότητα επιτήρησης. Για το CRA, εδώ ο Φάκελος Ασφάλειας Προϊόντος γίνεται ζωντανός φάκελος. Κάθε έκδοση προϊόντος, ευπάθεια, αλλαγή προμηθευτή και σήμα από το πεδίο πρέπει να επικαιροποιεί το αρχείο τεκμηρίων.

Ένας φάκελος τεκμηρίων, πολλά ερωτήματα συμμόρφωσης

Ένας καλά σχεδιασμένος Φάκελος Ασφάλειας Προϊόντος CRA μειώνει την επανάληψη, επειδή τα ίδια τεκμήρια απαντούν σε πολλά ερωτήματα συμμόρφωσης. Η γλώσσα αλλάζει, αλλά η πραγματικότητα των ελέγχων είναι συχνά παρόμοια.

Το Zenith Controls έχει σχεδιαστεί για αυτή την επαναχρησιμοποίηση. Αντιστοιχίζει τις θεματικές ελέγχων ISO/IEC 27002:2022 με χαρακτηριστικά όπως προληπτικός, ανιχνευτικός και διορθωτικός σκοπός ελέγχου, έννοιες κυβερνοασφάλειας, επιχειρησιακές ικανότητες και ιδιότητες ασφάλειας. Για το CRA, αυτό βοηθά έναν CISO να εξηγήσει γιατί ένα και μόνο αντικείμενο τεκμηρίωσης, όπως μια ανασκόπηση ασφάλειας έκδοσης, υποστηρίζει ασφαλή ανάπτυξη, αντιμετώπιση κινδύνων, έλεγχο αλλαγών, διαχείριση ευπαθειών και ετοιμότητα ελέγχου.

Προετοιμαστείτε για διαφορετικές ελεγκτικές οπτικές

Ένας Φάκελος Ασφάλειας Προϊόντος CRA μπορεί να αμφισβητηθεί από ελεγκτή ISO, ομάδα εσωτερικού ελέγχου, ομάδα διασφάλισης πελατών, αξιολογητή συμμόρφωσης προϊόντος, ρυθμιστική αρχή, αξιολογητή βάσει NIST ή ελεγκτή COBIT εκπαιδευμένο από ISACA. Όλοι θα θέσουν παρόμοια ερωτήματα μέσα από διαφορετική οπτική.

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

Οδικός χάρτης 30 βημάτων, προσαρμοσμένος για ετοιμότητα CRA

Το Zenith Blueprint αποτρέπει τις ομάδες συμμόρφωσης από το να περάσουν απευθείας στη συλλογή εγγράφων. Για το CRA, ο οδικός χάρτης 30 βημάτων μετατρέπεται σε πρόγραμμα τεκμηρίων ασφάλειας προϊόντος.

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

Η Φάση 2 δημιουργεί την αρχιτεκτονική τεκμηρίων. Ορίστε το ευρετήριο Φακέλου Ασφάλειας Προϊόντος, τους ιδιοκτήτες τεκμηρίων, τις απαιτήσεις διατήρησης, τη δομή αποθετηρίου και τη ροή έγκρισης. Ευθυγραμμίστε τα με τα συστήματα μηχανικής αντί να επιβάλλετε χειροκίνητες αναρτήσεις.

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

Η Φάση 4 δοκιμάζει την ετοιμότητα ελέγχου. Επιλέξτε μία έκδοση προϊόντος και πραγματοποιήστε προσομοιωμένο έλεγχο. Μπορεί η ομάδα να ανακτήσει το SBOM; Μπορεί να αποδείξει τις δοκιμές ασφάλειας; Μπορεί να δείξει πώς αξιολογήθηκε αρχικά μια ευπάθεια; Μπορεί να συνδέσει τα τεκμήρια προμηθευτών με τα στοιχεία του προϊόντος;

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

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

Συνήθη κενά ετοιμότητας CRA πριν από το 2026

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

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

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

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

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

Πέμπτον, η παρακολούθηση μετά τη διάθεση στην αγορά είναι αντιδραστική. Οι ομάδες αποκρίνονται σε επείγουσες ευπάθειες, αλλά δεν εκτελούν περιοδικές ανασκοπήσεις κινδύνου προϊόντος. Η λύση είναι προγραμματισμένη ανασκόπηση ασφάλειας μετά τη διάθεση στην αγορά, συνδεδεμένη με αναφορές προς τη διοίκηση.

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

Δημιουργήστε τον φάκελο τεκμηρίων πριν τον δημιουργήσει για εσάς η προθεσμία

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

Ξεκινήστε με ένα προϊόν. Δημιουργήστε έναν Φάκελο Ασφάλειας Προϊόντος. Αντιστοιχίστε τον με ISO/IEC 27001:2022 και ISO/IEC 27002:2022. Επισυνάψτε τεκμήρια ασφαλούς ανάπτυξης, SBOM, αρχεία CVD, διασφάλιση προμηθευτών και παρακολούθηση μετά τη διάθεση στην αγορά. Εκτελέστε προσομοίωση ελέγχου πριν το κάνει κάποιος εξωτερικός για εσάς.

Η Clarysec μπορεί να σας βοηθήσει να επιταχύνετε αυτή τη διαδρομή με το Zenith Blueprint, το Zenith Controls, την Enterprise Πολιτική Ασφαλούς Ανάπτυξης, την Πολιτική Διαχείρισης Ευπαθειών, την Πολιτική Διαχείρισης Περιουσιακών Στοιχείων, την Πολιτική Ασφάλειας Τρίτων Μερών και Προμηθευτών, την Πολιτική Καταγραφής και Παρακολούθησης και την Πολιτική Διαχείρισης Περιστατικών Ασφάλειας Πληροφοριών.

Το σημαντικότερο ερώτημά σας για το CRA 2026 δεν είναι: «Έχουμε ελέγχους ασφάλειας;»

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

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