Στην καταχώρηση περιστατικών στην ανάπτυξη λογισμικού, πρόκειται για δύο διαφορετικά πράγματα που συχνά συγχέονται: μια ευπάθεια ή βλάβη στο λογισμικό που δημιουργείτε και παρέχετε, και ένα περιστατικό στη δική σας γραμμή ανάπτυξης — το περιβάλλον στο οποίο δημιουργείτε αυτό το λογισμικό. Αυτό που καταγράφετε, ποιος πρέπει να το ξέρει και ποιο είναι το επόμενο βήμα, διαφέρει ανά είδος. Όποιος δεν κάνει αυτή τη διάκριση, συχνά χάνει το περιστατικό που έχει τη μεγαλύτερη σημασία: μια μόλυνση στον αγωγό δημιουργίας που διαδίδεται μέσω του κώδικα σε όλους τους πελάτες που το χρησιμοποιούν.
Μια ευπάθεια στον κώδικα που παρέχεται επηρεάζει άμεσα τον πελάτη: αυτός τρέχει το λογισμικό, επομένως κινδυνεύει. Ένα περιστατικό στη γραμμή ανάπτυξης — ένα κλεμμένο κλειδί πρόσβασης, ένας συμβιβασμένος λογαριασμός δημιουργίας, ένα ρέμα στο αποθετήριο πηγαίου κώδικα — σας επηρεάζει κατ' αρχήν, αλλά μπορεί να μεταφραστεί σε κάθε πελάτη που εργάζεται με αυτόν τον κώδικα. Και για τα δύο ισχύει ότι ένας κατάλογος ερωτήσεων ασφάλειας ή ένας ελεγκτής δεν σας ρωτά αν κάτι έχει ποτέ πάει στραβά, αλλά αν μπορείτε να δείξετε τι έχετε καταγράψει και τι έχετε μάθει.
Τι καταγράφετε κατά τη διάρκεια ενός περιστατικού στον κώδικα
Σε περίπτωση ευπάθειας ή βλάβης στο παρεχόμενο λογισμικό, πρόκειται για: πότε ανακαλύφθηκε, από ποιον ή τι (εσωτερικό τεστ, ανάφορα πελάτη, σάρωση, εξωτερικός ερευνητής), ποιο μέρος του λογισμικού επηρεάζεται, ποιο είναι το πιθανό αποτέλεσμα, ποια ενέργεια ελήφθη και σε ποια ημερομηνία, και ποιος στην οργάνωσή σας είναι υπεύθυνος για την παρακολούθηση. Μια καλή καταχώρηση καθιστά επίσης ορατό εάν μια διόρθωση έχει ανάπτυξη σε όλους τους πελάτες που χρησιμοποιούν τη σχετική έκδοση, ή μόνο σε αυτόν που την ανέφερε. Το τελευταίο είναι ακριβώς αυτό για το οποίο ένας πελάτης σας ρωτάει σε έναν κατάλογο ερωτήσεων: όχι αν είχατε ποτέ ευπάθεια, αλλά αν η διαδικασία σας εγγυάται ότι ο καθένας που επηρεάζεται από αυτήν, θα το ακούσει επίσης.
Τι καταγράφετε κατά τη διάρκεια ενός περιστατικού στη γραμμή ανάπτυξης
Ένα περιστατικό στο δικό σας περιβάλλον ανάπτυξης — ένας συμβιβασμένος λογαριασμός με πρόσβαση στον πηγαίο κώδικα, ένας διακομιστής δημιουργίας που ανταποκρίνεται διαφορετικά από το αναμενόμενο, μια εξάρτηση που αργότερα αποδεικνύεται κακόβουλη — απαιτεί μια ελάχιστα διαφορετική καταχώρηση. Εδώ πρόκειται για: ποιο σύστημα ή λογαριασμό ενδιαφέρει, ποιος είχε πρόσβαση κατά τη διάρκεια της περιόδου που εκτυλίσσετο, αν υπάρχουν ίχνη ότι ο κώδικας έχει τροποποιηθεί ή προβληθεί, και ποιοι πελάτες πιθανώς χρησιμοποιούν λογισμικό που δημιουργήθηκε ή παραδόθηκε κατά τη διάρκεια αυτής της περιόδου. Αυτό είναι το είδος του περιστατικού όπου ο έλεγχος πρόσβασης στη γραμμή ανάπτυξης επηρεάζει άμεσα: χωρίς ένα τρέχον αναφορά για το ποιος μπορεί να έχει πρόσβαση όπου, αυτό το ερώτημα διερεύνησης κατά τη διάρκεια ενός περιστατικού είναι σημαντικά δυσκολότερο να απαντηθεί.
Ποιον ενημερώνετε και ποιον όχι
Το αν εσείς οι ίδιοι εμπίπτετε στην υποχρέωση φροντίδας του Νόμου για την Ασφάλεια του Κυβερνοχώρου ή όχι, καθορίζει ποιον ενημερώνετε για ένα περιστατικό. Οι οντότητες που έχουν χαρακτηριστεί αυτές που είναι ουσιαστικής σημασίας ή σημαντικής σημασίας, έχουν υποχρέωση αναφοράς προς τον εποπτικό τους οργανισμό· τι ακριβώς είναι υποχρεωτικό και εντός ποιου χρονικού διαστήματος, περιγράφεται στην οδηγία και στον εθνικό νόμο, και διαφέρει ανά περίπτωση. Μια εταιρεία λογισμικού που επηρεάζεται μέσω της αλυσίδας — δηλαδή δεν είναι υποχρεωτική από μόνη της, αλλά παρέχει σε έναν πελάτη που είναι — δεν έχει αυτή την υποχρέωση αναφοράς στον εποπτικό οργανισμό, αλλά συνήθως έχει μια συμβατική συμφωνία για την ενημέρωση του πελάτη. Αυτό δεν κάνει τη δική σας καταχώρηση λιγότερο σημαντική: ένας πελάτης που ρωτάει αν είχατε ποτέ ένα περιστατικό, θέλει να δει μια συγκεκριμένη απάντηση, όχι μια εκ των υστέρων εκτίμηση.
Ένας ζωντανός κατάλογος, όχι ένα αρχείο
Η καταγραφή περιστατικών λειτουργεί καλύτερα ως ζωντανό έγγραφο: ένας κατάλογος όπου για κάθε περιστατικό είναι δυνατό να βρεθούν η κατάστασή του, το αποδεικτικό στοιχείο και ο υπεύθυνός του, αντί για μια χωριστή έκθεση που εξαφανίζεται σε έναν φάκελο μετά την επίλυσή του. Αυτό ευθυγραμμίζεται με τον τρόπο που έχει δομηθεί η ευρύτερη υποχρέωση φροντίδας, με δέκα μέτρα που το καθένα απαιτεί κατάστασή του και έναν υπεύθυνό του. Όποιος θέλει να δει πώς η καταγραφή περιστατικών σχετίζεται με τα άλλα εννέα μέτρα, θα βρει αυτή την επισκόπηση στη σελίδα με όλα τα θέματα ανά περίσταση τη σελίδα με όλα τα θέματα ανά περίσταση.
Για να δείτε αν ο οργανισμός σας υπόκειται στην υποχρέωση φροντίδας, επηρεάζεται μέσω της αλυσίδας εφοδιασμού, ή κανένα από τα δύο, είναι δυνατό να γίνει κατανοητό με λίγες ερωτήσεις μέσω του ελέγχου NIS2 που παρέχει μια ένδειξη σε λίγες ερωτήσειςΌποιος θέλει να γνωρίζει ακριβώς από πού προέρχονται τα στοιχεία στο secria.eu και πώς διατηρούνται, θα τα διαβάσει στη σελίδα που εξηγεί πώς λειτουργεί τη σελίδα που εξηγεί πώς λειτουργείΚαι όποιος μετά την ανάγνωση θέλει να γνωρίζει τι προσθέτει ένα abonnement στο ελεύθερο περιεχόμενο εδώ, θα το βρει σαφώς αναφερόμενο στην επισκόπηση του τι περιλαμβάνεται.
Αυτό το κείμενο είναι μια γενική επεξήγηση και όχι νομικές συμβουλές σχετικά με τη δική σας κατάσταση. Για αποφάνσεις σχετικά με τη δική σας διαδικασία περιστατικών ή υποχρέωση δήλωσης, μπορείτε να απευθυνθείτε σε έναν δικηγόρο ή στην εποπτική αρχή που είναι αρμόδια για τον τομέα σας.