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