Ένας δημόσιος ή ιδιωτικός φορέας που υπόκειται στην υποχρέωση φροντίδας της NIS2 πρέπει να είναι σε θέση να αποδείξει ότι γνωρίζει τους κινδύνους στη δική του αλυσίδα εφοδιασμού. Το λογισμικό που κατασκευάζετε για αυτόν τον φορέα είναι μέρος αυτής της αλυσίδας. Στην πράξη, αυτό μεταφράζεται σε συμβατικές απαιτήσεις που δρουν σε δύο πράγματα ταυτόχρονα: το προϊόν που παραδίδετε και ο τρόπος με τον οποίο κατασκευάζετε αυτό το προϊόν. Και τα δύο εμφανίζονται στο κείμενο της συμφωνίας, συχνά ως παράρτημα του συμβολαίου προμήθειας.
Ο πυρήνας είναι απλός για να θυμάστε: ο δημόσιος ή ιδιωτικός φορέας δεν ρωτά μόνο αν το λογισμικό λειτουργεί, αλλά και αν μπορείτε να δείξετε πώς παραμένει ασφαλές, ποιος μπορεί να έχει πρόσβαση και τι συμβαίνει εάν κάτι πάει στραβά. Αυτή είναι μια αλλαγή σε σχέση με το παρελθόν, όταν η λειτουργικότητα και ο χρόνος παράδοσης ήταν συχνά τα μόνα σημεία συζήτησης.
Απαιτήσεις για το προϊόν που παραδίδετε
Η πιο συνηθισμένη συμβατική απαίτηση αφορά τη σύνθεση του ίδιου του λογισμικού. Οι δημόσιοι και ιδιωτικοί φορείς ζητούν όλο και πιο συχνά μια αναφορά των χρησιμοποιούμενων βιβλιοθηκών και συστατικών ανοικτού κώδικα, ένα λεγόμενο απογραφή υλικού λογισμικού. Ο λόγος είναι ότι μια ευπάθεια σε ένα υποκείμενο στοιχείο είναι εξίσου κίνδυνος όπως ένα σφάλμα στον δικό σας κώδικα, και ένας δημόσιος ή ιδιωτικός φορέας θέλει να μπορεί να δει αυτούς τους κινδύνους χωρίς να διαβάσει ο ίδιος τον πηγαίο κώδικα.
Επιπλέον, υπάρχουν απαιτήσεις σχετικά με τον τρόπο ανίχνευσης και επιδιόρθωσης ευπαθειών στο λογισμικό και σε ποιο χρονικό διάστημα. Αυτό μπορεί να αφορά αυτοματοποιημένες σαρώσεις για γνωστά αδύνατα σημεία, μια σταθερή διαδικασία για διορθώσεις, ή το ερώτημα ποιος μπορεί να αναφέρει μια ευπάθεια και πού καταλήγει. Για υπάρχον λογισμικό, μερικές φορές ρωτούν και για την περίοδο υποστήριξης: πόσο καιρό παραμένει μια έκδοση με ενημερώσεις ασφαλείας.
Απαιτήσεις για τη δική σας γραμμή παραγωγής
Ένα δεύτερο σύνολο απαιτήσεων δεν επικεντρώνεται στο προϊόν, αλλά στη διαδικασία με την οποία δημιουργείται: η γραμμή παραγωγής. Σκεφτείτε ποιος έχει πρόσβαση στον πηγαίο κώδικα και το περιβάλλον στο οποίο κατασκευάζεται και δοκιμάζεται, πώς ελέγχονται οι αλλαγές πριν να ενεργοποιηθούν, και αν υπάρχει διαχωρισμός μεταξύ περιβάλλοντος δοκιμής, αποδοχής και παραγωγής. Η χρήση πολλαπλών παραγόντων επαλήθευσης για προγραμματιστές που έχουν πρόσβαση στον πηγαίο κώδικα ή τα συστήματα κατασκευής εμφανίζεται επίσης σε συμβόλαια, όπως και το ερώτημα ποιος διαχειρίζεται τα κλειδιά και τα στοιχεία πρόσβασης που σχετίζονται με την ανάπτυξη λογισμικού.
Ορισμένοι δημόσιοι και ιδιωτικοί φορείς ρωτούν επίσης για την προέλευση του λογισμικού που χρησιμοποιείτε ο ίδιοι για να κατασκευάσετε: ο μεταγλωττιστής, τα εργαλεία κατασκευής, τα πακέτα που ανακτώνται κατά τη διάρκεια της κατασκευής. Αυτό συνδέεται με μια ευρύτερη αντίληψη ότι μια επίθεση δεν μπορεί μόνο να περάσει από το τελικό προϊόν, αλλά και από το εργοστάσιο στο οποίο κατασκευάζεται.
Γιατί αυτές οι απαιτήσεις διατυπώνονται ακριβώς με αυτόν τον τρόπο
Η υποχρέωση φροντίδας που βρίσκεται στη βάση όλων αυτών, υποχρεώνει έναν δημόσιο ή ιδιωτικό φορέα υποχρεωτικής εφαρμογής να αξιολογήσει και να ελέγξει τους κινδύνους στη δική του αλυσίδα εφοδιασμού. Ο τρόπος με τον οποίο αυτό ακριβώς εφαρμόζεται διαφέρει ανά χώρα στο εθνικό νόμο που βασίζεται στην Ευρωπαϊκή οδηγία, και ανά τομέα στον οποίο δραστηριοποιείται ο δημόσιος ή ιδιωτικός φορέας. Αυτό που είναι σκληρή απαίτηση σε ένα συμβόλαιο, εμφανίζεται ακόμα ως ένα προαιρετικό ερώτημα σε άλλο. Εάν θέλετε να γνωρίσετε πώς είναι δομημένη αυτή η υποχρέωση στον πυρήνα της, διαβάστε το στην εξήγηση ανά υποχρέωση στη βάση γνώσεών μας.
Σημαντικό να θυμάστε: είναι ο δημόσιος ή ιδιωτικός φορέας που θέτει αυτές τις απαιτήσεις επειδή ο ίδιος υπόκειται σε εποπτεία, όχι επειδή οι εταιρείες λογισμικού ως τέτοιες υπόκεινται στην οδηγία. Το αν και πόσο αυστηρά αυτό εφαρμόζεται στη δική σας περίπτωση εξαρτάται από τον τομέα και το μέγεθος αυτού του συγκεκριμένου δημόσιου ή ιδιωτικού φορέα. Για τη δική σας κατάσταση, το κείμενο του εθνικού νόμου ή η συμβουλή ενός νομικού συμβούλου είναι το κατάλληλο σημείο εκκίνησης, όχι μια γενική εκτίμηση.
Τι σημαίνει αυτό για την προετοιμασία σας
Τα περισσότερα από αυτά τα κριτήρια μπορούν να απαντηθούν σχετικά εύκολα με λίγη προετοιμασία, και η απάντηση που συντάσσετε μία φορά μπορείτε να την χρησιμοποιήσετε ξανά και ξανά με τον επόμενο πελάτη. Ένας κατάλογος των χρησιμοποιούμενων συστατικών, μια σύντομη περιγραφή του ελέγχου πρόσβασής σας και μια σταθερή διαδικασία για διορθώσεις δεν είναι έγγραφα που πρέπει να ανακαλύψετε ξανά για κάθε σύμβαση.
Εάν θέλετε πρώτα να δείτε εάν και πώς αυτό επηρεάζει την επιχείρησή σας, τότε ο έλεγχος που καθορίζει τη θέση σας στην αλυσίδα εφοδιασμού με λίγες ερωτήσεις δίνει μια πρώτη κατεύθυνση, χωρίς να χρειάζεστε λογαριασμό. Για τις ερωτήσεις που θέτουν συγκεκριμένα οι πελάτες και τον τρόπο με τον οποίο σας βοηθάμε, διαβάστε περισσότερα στο τη σελίδα με τις συχνές ερωτήσεις ή δείτε πώς τεκμηριώνουμε τις πληροφορίες στην πλατφόρμα.
Η δωρεάν τράπεζα γνώσης και ο έλεγχος σας δίνουν μια πρώτη εικόνα χωρίς δεσμεύσεις. Εάν στη συνέχεια θέλετε να μετατρέψετε τις συμβατικές απαιτήσεις σε ένα ενεργό αρχείο με αποδεικτικά στοιχεία και έτοιμες απαντήσεις σε ερωτηματολόγια, τότε είναι η στιγμή να ελέγξετε τι προσθέτει μια συνδρομή.