Ο έλεγχος ασφάλειας πρέπει να γίνεται πριν ένα έργο εξελιχθεί σε επείγον περιστατικό.

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

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

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

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

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

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

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

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

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

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