Είχαμε 2 αναλυτές κώδικα, 4 εργαλεία δυναμικής δοκιμής, δικές μας χειροτεχνίες και 250 σενάρια. Όχι ότι όλα αυτά χρειάζονταν στην τρέχουσα διαδικασία, αλλά μόλις ξεκινήσατε να εφαρμόζετε το DevSecOps, πρέπει να πάτε μέχρι το τέλος.
. Χαρακτήρες που δημιουργήθηκαν από τον Justin Roiland και τον Dan Harmon.
Τι είναι το SecDevOps; Τι γίνεται με το DevSecOps; Ποιες είναι οι διαφορές; Ασφάλεια Εφαρμογών - περί τίνος πρόκειται; Γιατί η κλασική προσέγγιση δεν λειτουργεί πια; Όλες αυτές οι ερωτήσεις ξέρουν την απάντηση Γιούρι Σαμπαλίν του Ασφάλεια ξιφία. Ο Yuriy θα απαντήσει σε όλα λεπτομερώς και θα αναλύσει τα προβλήματα της μετάβασης από το κλασικό μοντέλο Ασφάλειας Εφαρμογών στη διαδικασία DevSecOps: πώς να προσεγγίσετε σωστά την ενσωμάτωση της διαδικασίας ασφαλούς ανάπτυξης στη διαδικασία DevOps και να μην σπάσετε τίποτα, πώς να περάσετε από τα κύρια στάδια δοκιμών ασφαλείας, ποια εργαλεία μπορούν να χρησιμοποιηθούν, πώς να διαφέρουν και πώς να τα διαμορφώσετε σωστά για να αποφύγετε παγίδες.
Σχετικά με τον ομιλητή: Γιούρι Σαμπαλίν - Επικεφαλής Αρχιτέκτονας Ασφαλείας στην εταιρεία Ασφάλεια ξιφία. Υπεύθυνος για την υλοποίηση του SSDL, για τη συνολική ενσωμάτωση των εργαλείων ανάλυσης εφαρμογών σε ένα ενιαίο οικοσύστημα ανάπτυξης και δοκιμών. 7 χρόνια εμπειρίας στην ασφάλεια πληροφοριών. Εργάστηκε στις Alfa-Bank, Sberbank και Positive Technologies, που αναπτύσσει λογισμικό και παρέχει υπηρεσίες. Ομιλητής διεθνών συνεδρίων ZerONights, PHDays, RISSPA, OWASP.
Ασφάλεια Εφαρμογής: περί τίνος πρόκειται;
Ασφάλεια εφαρμογών είναι η ενότητα ασφαλείας που είναι υπεύθυνη για την ασφάλεια της εφαρμογής. Δεν πρόκειται για την ασφάλεια της υποδομής ή του δικτύου, αλλά για το τι γράφουμε και τι εργάζονται οι προγραμματιστές - αυτά είναι τα ελαττώματα και τα τρωτά σημεία της ίδιας της εφαρμογής.
Κατεύθυνση - Κύκλος ζωής ανάπτυξης ασφάλειας - Αναπτύχθηκε από τη Microsoft. Το διάγραμμα δείχνει το κανονικό μοντέλο SDLC, το κύριο καθήκον του οποίου είναι η συμμετοχή της ασφάλειας σε κάθε στάδιο ανάπτυξης, από τις απαιτήσεις, έως την κυκλοφορία και την κυκλοφορία στην παραγωγή. Η Microsoft συνειδητοποίησε ότι υπάρχουν πάρα πολλά σφάλματα στον χορό, υπάρχουν περισσότερα από αυτά και κάτι πρέπει να γίνει γι' αυτό, και πρότεινε αυτήν την προσέγγιση, η οποία έγινε κανονική.
Η Ασφάλεια Εφαρμογών και το SSDL δεν στοχεύουν στον εντοπισμό τρωτών σημείων, όπως πιστεύεται συνήθως, αλλά στην πρόληψη της εμφάνισής τους. Με την πάροδο του χρόνου, η κανονική προσέγγιση από τη Microsoft έχει βελτιωθεί, αναπτυχθεί, έχει μια βαθύτερη λεπτομερή εμβάπτιση.
Το κανονικό SDLC είναι εξαιρετικά λεπτομερές σε διάφορες μεθοδολογίες - OpenSAMM, BSIMM, OWASP. Οι μεθοδολογίες διαφέρουν, αλλά είναι γενικά παρόμοιες.
Μοντέλο οικοδόμησης ασφάλειας στην ωριμότητα
Μου αρέσει περισσότερο BSIMM - . Η βάση της μεθοδολογίας είναι η διαίρεση της διαδικασίας Ασφάλειας Εφαρμογών σε 4 τομείς: Διακυβέρνηση, Ευφυΐα, Σημεία επαφής SSDL και Ανάπτυξη. Κάθε τομέας έχει 12 πρακτικές, οι οποίες αντιπροσωπεύονται ως 112 δραστηριότητες.
Κάθε μία από τις 112 δραστηριότητες έχει 3 επίπεδα ωριμότητας: αρχάριος, μεσαίος και προχωρημένος. Μπορείτε να μελετήσετε και τις 12 πρακτικές σε ενότητες, να επιλέξετε πράγματα που είναι σημαντικά για εσάς, να μάθετε πώς να τα εφαρμόσετε και να προσθέσετε σταδιακά στοιχεία, για παράδειγμα, στατική και δυναμική ανάλυση κώδικα ή αναθεώρηση κώδικα. Καταρτίζετε ένα σχέδιο και εργάζεστε σύμφωνα με αυτό ήρεμα ως μέρος της υλοποίησης των επιλεγμένων δραστηριοτήτων.
Γιατί DevSecOps
Το DevOps είναι μια συνολική μεγάλη διαδικασία στην οποία πρέπει να ληφθεί μέριμνα για την ασφάλεια.
Αρχικά περιλάμβανε ελέγχους ασφαλείας. Στην πράξη, ο αριθμός των ομάδων ασφαλείας ήταν πολύ μικρότερος από τώρα και δεν ενεργούσαν ως συμμετέχοντες στη διαδικασία, αλλά ως φορέας ελέγχου και εποπτείας που θέτει απαιτήσεις σε αυτό και ελέγχει την ποιότητα του προϊόντος στο τέλος της κυκλοφορίας. Αυτή είναι μια κλασική προσέγγιση στην οποία οι ομάδες ασφαλείας βρίσκονταν πίσω από έναν τοίχο από την ανάπτυξη και δεν συμμετείχαν στη διαδικασία.
Το κύριο πρόβλημα είναι ότι η ασφάλεια των πληροφοριών είναι ξεχωριστή από την ανάπτυξη. Συνήθως πρόκειται για κάποιο είδος κυκλώματος IB και περιέχει 2-3 μεγάλα και ακριβά εργαλεία. Μία φορά κάθε έξι μήνες, ο πηγαίος κώδικας ή η εφαρμογή φτάνει για δοκιμή και μία φορά το χρόνο . Όλα αυτά οδηγούν στο γεγονός ότι οι ημερομηνίες κυκλοφορίας για τον κλάδο αναβάλλονται και ένας τεράστιος αριθμός ευπαθειών από αυτοματοποιημένα εργαλεία πέφτει στον προγραμματιστή. Είναι αδύνατο να αποσυναρμολογηθεί και να επισκευαστεί όλο αυτό, γιατί ακόμη και τους προηγούμενους έξι μήνες τα αποτελέσματα δεν είχαν αποσυναρμολογηθεί, και εδώ είναι μια νέα παρτίδα.
Κατά τη διάρκεια των εργασιών της εταιρείας μας, βλέπουμε ότι η ασφάλεια σε όλους τους τομείς και τις βιομηχανίες κατανοεί ότι είναι καιρός να καλύψουμε τη διαφορά και να περιστρέψουμε την ανάπτυξη σε έναν τροχό - σε . Το παράδειγμα DevSecOps ταιριάζει απόλυτα στη μεθοδολογία ευέλικτης ανάπτυξης, την υλοποίηση, την υποστήριξη και τη συμμετοχή σε κάθε έκδοση και επανάληψη.
Μετάβαση στο DevSecOps
Η πιο σημαντική λέξη στον κύκλο ζωής ανάπτυξης ασφάλειας είναι "επεξεργάζομαι, διαδικασία". Πρέπει να το καταλάβετε αυτό πριν σκεφτείτε να αγοράσετε εργαλεία.
Δεν αρκεί απλώς η συμπερίληψη εργαλείων στη διαδικασία DevOps - η επικοινωνία και η κατανόηση μεταξύ των συμμετεχόντων στη διαδικασία είναι σημαντική.
Οι άνθρωποι είναι πιο σημαντικοί από τα εργαλεία
Συχνά ο σχεδιασμός μιας ασφαλούς διαδικασίας ανάπτυξης ξεκινά με την επιλογή και την αγορά ενός εργαλείου και τελειώνει με τις προσπάθειες ενσωμάτωσης του εργαλείου στην τρέχουσα διαδικασία, οι οποίες παραμένουν προσπάθειες. Αυτό οδηγεί σε θλιβερές συνέπειες, επειδή όλα τα εργαλεία έχουν τα δικά τους χαρακτηριστικά και περιορισμούς.
Μια συνηθισμένη περίπτωση είναι όταν το τμήμα ασφαλείας επέλεξε ένα καλό, ακριβό εργαλείο με ένα ευρύ φάσμα δυνατοτήτων και ήρθε στους προγραμματιστές για να το ενσωματώσουν στη διαδικασία. Αλλά δεν λειτουργεί - η διαδικασία έχει σχεδιαστεί με τέτοιο τρόπο ώστε οι περιορισμοί ενός ήδη αγορασμένου οργάνου να μην ταιριάζουν στο τρέχον παράδειγμα.
Αρχικά, περιγράψτε ποιο αποτέλεσμα θέλετε και πώς θα είναι η διαδικασία. Αυτό θα βοηθήσει στην κατανόηση των ρόλων του εργαλείου και της ασφάλειας στη διαδικασία.
Ξεκινήστε με αυτό που χρησιμοποιείται ήδη
Πριν αγοράσετε ακριβά εργαλεία, δείτε τι έχετε ήδη. Κάθε εταιρεία έχει απαιτήσεις ασφαλείας που ισχύουν για την ανάπτυξη, υπάρχουν έλεγχοι, δοκιμές διείσδυσης - γιατί να μην τα μετατρέψετε όλα αυτά σε μια κατανοητή και βολική μορφή για όλους;
Συνήθως οι απαιτήσεις είναι ένα χάρτινο Ταλμούδ που βρίσκεται σε ένα ράφι. Υπήρχε περίπτωση που ήρθαμε στην εταιρεία για να δούμε τις διαδικασίες και να της ζητήσουμε να δείξει τις απαιτήσεις ασφαλείας για το λογισμικό. Ο ειδικός που το έκανε αυτό έψαχνε για πολύ καιρό:
- Τώρα, κάπου στις σημειώσεις υπήρχε μια διαδρομή όπου βρίσκεται αυτό το έγγραφο.
Ως αποτέλεσμα, λάβαμε το έγγραφο μια εβδομάδα αργότερα.
Για απαιτήσεις, ελέγχους και άλλα, δημιουργήστε μια σελίδα, για παράδειγμα στο Συμβολή - είναι βολικό για όλους.
Είναι πιο εύκολο να διαμορφώσετε ξανά αυτό που υπάρχει ήδη και να το χρησιμοποιήσετε για να ξεκινήσετε.
Χρησιμοποιήστε το Security Champions
Συνήθως, σε μια μέση εταιρεία για 100-200 προγραμματιστές, υπάρχει ένας αξιωματικός ασφαλείας που εκτελεί πολλές λειτουργίες και δεν έχει φυσικά χρόνο να ελέγξει τα πάντα. Ακόμα κι αν κάνει το καλύτερο δυνατό, δεν θα ελέγξει μόνος του όλο τον κώδικα που δημιουργεί η ανάπτυξη. Για τέτοιες περιπτώσεις, έχει αναπτυχθεί μια ιδέα - .
Οι πρωταθλητές ασφαλείας είναι ένα άτομο στην ομάδα ανάπτυξης που ενδιαφέρεται για την ασφάλεια του προϊόντος σας.
Το Security Champion είναι ένα σημείο εισόδου στην ομάδα ανάπτυξης και ένας ευαγγελιστής ασφαλείας, όλοι μαζί.
Συνήθως, όταν ένας αξιωματικός ασφαλείας έρχεται στην ομάδα ανάπτυξης και επισημαίνει ένα σφάλμα στον κωδικό, λαμβάνει μια έκπληκτη απάντηση:
- Και ποιος είσαι εσύ? Σε βλέπω για πρώτη φορά. Όλα είναι καλά μαζί μου - ο ανώτερος φίλος μου έβαλε "εφαρμογή" στην αναθεώρηση κώδικα, προχωράμε!
Αυτή είναι μια τυπική κατάσταση, επειδή υπάρχει πολύ μεγαλύτερη εμπιστοσύνη στους ηλικιωμένους ή απλώς στους συμπαίκτες με τους οποίους ο προγραμματιστής αλληλεπιδρά συνεχώς στην εργασία και στην αναθεώρηση κώδικα. Αν αντί για σεκιούριτι ο Πρωταθλητής Ασφαλείας επισημάνει το λάθος και τις συνέπειες, τότε ο λόγος του θα έχει μεγαλύτερη βαρύτητα.
Επίσης, οι προγραμματιστές γνωρίζουν τον κώδικα τους καλύτερα από οποιονδήποτε τύπο ασφαλείας. Για ένα άτομο που έχει τουλάχιστον 5 έργα σε ένα εργαλείο στατικής ανάλυσης, είναι συνήθως δύσκολο να θυμηθεί όλες τις αποχρώσεις. Οι πρωταθλητές ασφαλείας γνωρίζουν το προϊόν τους: τι αλληλεπιδρά με τι και τι πρέπει να κοιτάξουμε αρχικά - είναι πιο αποτελεσματικά.
Σκεφτείτε λοιπόν να εφαρμόσετε το Security Champions και να επεκτείνετε την επιρροή της ομάδας ασφαλείας. Για τον ίδιο τον πρωταθλητή, αυτό είναι επίσης χρήσιμο: επαγγελματική εξέλιξη σε έναν νέο τομέα, επέκταση των τεχνικών οριζόντων, άντληση τεχνικών, διοικητικών και ηγετικών δεξιοτήτων, αύξηση της αξίας της αγοράς. Αυτό είναι κάποιο στοιχείο της κοινωνικής μηχανικής, τα «μάτια» σας στην ομάδα ανάπτυξης.
Στάδια δοκιμής
λέει ότι το 20% των προσπαθειών δίνει το 80% των αποτελεσμάτων. Αυτό το 20% είναι πρακτικές ανάλυσης εφαρμογών που μπορούν και πρέπει να αυτοματοποιηθούν. Παραδείγματα τέτοιων δραστηριοτήτων είναι η στατική ανάλυση − SAST, δυναμική ανάλυση — DAST и έλεγχος ανοιχτού κώδικα. Θα σας πω περισσότερα για τις δραστηριότητες, καθώς και για τα εργαλεία, ποια χαρακτηριστικά συναντάμε συνήθως όταν εισάγονται στη διαδικασία και πώς να το κάνουμε σωστά.
Κύρια προβλήματα εργαλείων
Θα επισημάνω τα προβλήματα που σχετίζονται με όλα τα μέσα που απαιτούν προσοχή. Θα τα αναλύσω πιο αναλυτικά για να μην επαναλάβω περαιτέρω.
Μεγάλος χρόνος ανάλυσης. Εάν χρειαστούν 30 λεπτά για όλες τις δοκιμές και τη συναρμολόγηση από τη δέσμευση έως την κυκλοφορία για παραγωγή, τότε οι έλεγχοι ασφάλειας πληροφοριών θα διαρκέσουν μία ημέρα. Έτσι κανείς δεν θα επιβραδύνει τη διαδικασία. Σκεφτείτε αυτό το χαρακτηριστικό και βγάλτε συμπεράσματα.
Υψηλό ψευδώς αρνητικό ή ψευδώς θετικό. Όλα τα προϊόντα είναι διαφορετικά, όλα χρησιμοποιούν διαφορετικά πλαίσια και το δικό τους στυλ κωδικοποίησης. Σε διαφορετικές βάσεις κώδικα και τεχνολογίες, τα εργαλεία μπορούν να εμφανίζουν διαφορετικά επίπεδα ψευδώς αρνητικών και ψευδώς θετικών. Δείτε λοιπόν τι υπάρχει σας εταιρείες και για σας οι εφαρμογές θα δείξουν ένα καλό και αξιόπιστο αποτέλεσμα.
Δεν υπάρχουν ενσωματώσεις με υπάρχοντα εργαλεία. Δείτε τα εργαλεία όσον αφορά τις ενσωματώσεις με αυτά που ήδη χρησιμοποιείτε. Για παράδειγμα, εάν έχετε Jenkins ή TeamCity, ελέγξτε την ενσωμάτωση των εργαλείων με αυτό το λογισμικό και όχι με το GitLab CI, το οποίο δεν χρησιμοποιείτε.
Έλλειψη ή υπερβολική πολυπλοκότητα προσαρμογής. Εάν το εργαλείο δεν διαθέτει API, τότε γιατί χρειάζεται; Όλα όσα μπορούν να γίνουν στη διεπαφή θα πρέπει να είναι διαθέσιμα μέσω του API. Στην ιδανική περίπτωση, το εργαλείο θα πρέπει να έχει τη δυνατότητα να προσαρμόζει τους ελέγχους.
Δεν υπάρχει οδικός χάρτης ανάπτυξης προϊόντων. Η ανάπτυξη δεν μένει ακίνητη, χρησιμοποιούμε πάντα νέα πλαίσια και λειτουργίες, ξαναγράφουμε τον παλιό κώδικα σε νέες γλώσσες. Θέλουμε να διασφαλίσουμε ότι το εργαλείο που αγοράζουμε θα υποστηρίζει νέα πλαίσια και τεχνολογίες. Ως εκ τούτου, είναι σημαντικό να γνωρίζετε ότι το προϊόν έχει μια πραγματική και σωστή ανάπτυξη.
Λειτουργίες επεξεργασίας
Εκτός από τα χαρακτηριστικά των εργαλείων, εξετάστε τα χαρακτηριστικά της διαδικασίας ανάπτυξης. Για παράδειγμα, η παρέμβαση στην ανάπτυξη είναι ένα τυπικό λάθος. Ας δούμε ποια άλλα χαρακτηριστικά πρέπει να ληφθούν υπόψη και τι πρέπει να προσέξει η ομάδα ασφαλείας.
Για να μην διαταραχθούν οι προθεσμίες ανάπτυξης και κυκλοφορίας, δημιουργήστε διαφορετικούς κανόνες και διαφορετικά δείχνουν στόπερ - κριτήρια για τη διακοπή της διαδικασίας κατασκευής παρουσία τρωτών σημείων - για διαφορετικά περιβάλλοντα. Για παράδειγμα, καταλαβαίνουμε ότι το τρέχον υποκατάστημα πηγαίνει σε ένα περίπτερο ανάπτυξης ή UAT, επομένως δεν σταματάμε και λέμε:
- Έχεις τρωτά σημεία εδώ, δεν θα πας πουθενά!
Σε αυτό το σημείο, είναι σημαντικό να πείτε στους προγραμματιστές ότι υπάρχουν ζητήματα ασφάλειας που πρέπει να προσέξετε.
Η παρουσία τρωτών σημείων δεν αποτελεί εμπόδιο για περαιτέρω δοκιμές: εγχειρίδιο, ενσωμάτωση ή εγχειρίδιο. Από την άλλη πλευρά, πρέπει να βελτιώσουμε κατά κάποιο τρόπο την ασφάλεια του προϊόντος και έτσι οι προγραμματιστές να μην βαθμολογούν σε αυτά που βρίσκει η ασφάλεια. Επομένως, μερικές φορές κάνουμε αυτό: στο περίπτερο, όταν κυκλοφορεί στο περιβάλλον ανάπτυξης, απλώς ειδοποιούμε την ανάπτυξη:
- Παιδιά, έχετε προβλήματα, προσέξτε τα.
Στο στάδιο UAT, δείχνουμε ξανά προειδοποιήσεις σχετικά με τρωτά σημεία και στο στάδιο εξόδου στον χορό λέμε:
«Παιδιά, σας προειδοποιήσαμε πολλές φορές, δεν κάνατε τίποτα - δεν θα σας αφήσουμε να βγείτε με αυτό.
Αν μιλάμε για κώδικα και δυναμική, τότε είναι απαραίτητο να δείξουμε και να προειδοποιήσουμε για τα τρωτά σημεία μόνο εκείνων των δυνατοτήτων και του κώδικα που μόλις γράφτηκε σε αυτό το χαρακτηριστικό. Εάν ο προγραμματιστής μετακίνησε το κουμπί κατά 3 pixel και του πούμε ότι έχει μια ένεση SQL εκεί και επομένως πρέπει να διορθωθεί επειγόντως, αυτό είναι λάθος. Δες μόνο τι γράφεται τώρα, και την αλλαγή που έρχεται στην εφαρμογή.
Ας υποθέσουμε ότι έχουμε κάποιο λειτουργικό ελάττωμα - ο τρόπος με τον οποίο δεν πρέπει να λειτουργεί η εφαρμογή: δεν μεταφέρονται χρήματα, όταν κάνετε κλικ στο κουμπί, δεν υπάρχει μετάβαση στην επόμενη σελίδα ή το προϊόν δεν φορτώνεται. Ελαττώματα ασφαλείας - αυτά είναι τα ίδια ελαττώματα, αλλά όχι στο πλαίσιο της εφαρμογής, αλλά ασφάλειας.
Δεν είναι όλα τα ζητήματα ποιότητας λογισμικού ζητήματα ασφάλειας. Όμως όλα τα προβλήματα ασφαλείας σχετίζονται με την ποιότητα του λογισμικού. Σερίφ Μανσούρ, Expedia.
Δεδομένου ότι όλα τα τρωτά σημεία είναι τα ίδια ελαττώματα, θα πρέπει να βρίσκονται στο ίδιο σημείο με όλα τα ελαττώματα ανάπτυξης. Ξεχάστε λοιπόν τις αναφορές και τα τρομακτικά PDF που κανείς δεν διαβάζει.
Όταν εργαζόμουν σε μια εταιρεία ανάπτυξης, έλαβα μια αναφορά από εργαλεία στατικής ανάλυσης. Το άνοιξα, φρίκαρα, έφτιαξα καφέ, ξεφύλλισα 350 σελίδες, το έκλεισα και συνέχισα τη δουλειά. Οι μεγάλες αναφορές είναι νεκρές αναφορές. Συνήθως δεν πάνε πουθενά, τα email διαγράφονται, ξεχνιούνται, χάνονται ή η επιχείρηση λέει ότι παίρνει ρίσκα.
Τι να κάνω? Απλώς μετατρέπουμε τα επιβεβαιωμένα ελαττώματα που βρήκαμε σε μια φόρμα κατάλληλη για ανάπτυξη, για παράδειγμα, την προσθέτουμε στο ανεκτέλεστο αρχείο του Jira. Τα ελαττώματα ιεραρχούνται και εξαλείφονται με σειρά προτεραιότητας μαζί με λειτουργικά ελαττώματα και ελαττώματα δοκιμής.
Στατική Ανάλυση - SAST
Αυτή είναι η ανάλυση κώδικα για τρωτά σημεία., αλλά δεν είναι το ίδιο με το SonarQube. Ελέγχουμε όχι μόνο για μοτίβα ή στυλ. Η ανάλυση χρησιμοποιεί έναν αριθμό προσεγγίσεων: κατά δέντρο ευπάθειας, κατά , αναλύοντας αρχεία διαμόρφωσης. Αυτό είναι όλο για τον ίδιο τον κώδικα.
Πλεονεκτήματα της προσέγγισης: εντοπισμός τρωτών σημείων στον κώδικα σε πρώιμο στάδιο ανάπτυξηςόταν δεν υπάρχουν βάσεις και έτοιμα εργαλεία, και δυνατότητα σταδιακής σάρωσης: σαρώνει ένα τμήμα κώδικα που έχει αλλάξει και μόνο τη δυνατότητα που κάνουμε αυτήν τη στιγμή, η οποία μειώνει τον χρόνο σάρωσης.
Μειονεκτήματα είναι η έλλειψη υποστήριξης για τις απαιτούμενες γλώσσες.
Απαιτούμενες ενσωματώσεις, που θα έπρεπε να είναι στα εργαλεία, κατά την υποκειμενική μου γνώμη:
- Εργαλείο ενσωμάτωσης: Jenkins, TeamCity και Gitlab CI.
- Περιβάλλον ανάπτυξης: Intellij IDEA, Visual Studio. Είναι πιο βολικό για έναν προγραμματιστή να μην σκαρφαλώνει σε μια ακατανόητη διεπαφή που πρέπει ακόμα να θυμάται, αλλά να δει όλες τις απαραίτητες ενσωματώσεις και τρωτά σημεία που έχει βρει ακριβώς στο χώρο εργασίας στο δικό του περιβάλλον ανάπτυξης.
- Αναθεώρηση κώδικα: SonarQube και μη αυτόματη αναθεώρηση.
- Ανιχνευτές ελαττωμάτων: Jira και Bugzilla.
Η εικόνα δείχνει μερικούς από τους καλύτερους εκπροσώπους της στατικής ανάλυσης.
Δεν έχουν σημασία τα εργαλεία, αλλά η διαδικασία, επομένως υπάρχουν λύσεις ανοιχτού κώδικα που είναι επίσης καλές για την εκτέλεση της διαδικασίας.
Το SAST Open Source δεν θα βρει τεράστιο αριθμό τρωτών σημείων ή πολύπλοκων DataFlow, αλλά μπορούν και πρέπει να χρησιμοποιηθούν κατά τη δημιουργία μιας διαδικασίας. Βοηθούν να κατανοήσουμε πώς θα κατασκευαστεί η διαδικασία, ποιος θα απαντήσει στα σφάλματα, ποιος θα αναφέρει, ποιος θα αναφέρει. Εάν θέλετε να πραγματοποιήσετε το αρχικό στάδιο δημιουργίας της ασφάλειας του κώδικά σας, χρησιμοποιήστε λύσεις ανοιχτού κώδικα.
Πώς μπορεί να ενσωματωθεί αυτό αν βρίσκεστε στην αρχή του ταξιδιού, δεν έχετε τίποτα: ούτε CI, ούτε Jenkins, ούτε TeamCity; Εξετάστε την ενσωμάτωση της διαδικασίας.
Ένταξη σε επίπεδο CVS
Εάν έχετε Bitbucket ή GitLab, μπορείτε να κάνετε ενοποίηση σε επίπεδο .
Ανά εκδήλωση έλξη αίτημα, δέσμευση. Σαρώνετε τον κωδικό και εμφανίζετε στην κατάσταση κατασκευής ότι ο έλεγχος ασφαλείας πέρασε ή απέτυχε.
Ανατροφοδότηση. Φυσικά, η ανατροφοδότηση είναι πάντα απαραίτητη. Εάν το κάνατε απλώς από την πλευρά της ασφάλειας, το βάλατε σε ένα κουτί και δεν είπατε σε κανέναν τίποτα γι 'αυτό και στη συνέχεια πετάξατε ένα σωρό σφάλματα στο τέλος του μήνα, αυτό δεν είναι σωστό και δεν είναι καλό.
Ενσωμάτωση με σύστημα ελέγχου κώδικα
Κάποτε, ορίσαμε τον τεχνικό χρήστη AppSec ως τον προεπιλεγμένο αναθεωρητή σε ορισμένα σημαντικά έργα. Ανάλογα με το αν βρέθηκαν σφάλματα στον νέο κώδικα ή αν δεν υπάρχουν σφάλματα, ο αναθεωρητής βάζει την κατάσταση στο αίτημα έλξης για "αποδοχή" ή "χρειάζομαι δουλειά" - είτε όλα είναι εντάξει, είτε πρέπει να ολοκληρώσετε και να συνδέσετε με το τι ακριβώς να οριστικοποιηθεί. Για ενσωμάτωση με την έκδοση που κυκλοφορεί, έχουμε απενεργοποιήσει τη συγχώνευση εάν η δοκιμή IS δεν περάσει. Το συμπεριλάβαμε στη μη αυτόματη αναθεώρηση κώδικα και οι υπόλοιποι συμμετέχοντες στη διαδικασία είδαν τις καταστάσεις ασφαλείας για τη συγκεκριμένη διαδικασία.
Ενσωμάτωση με το SonarQube
Πολλοί έχουν όσον αφορά την ποιότητα του κώδικα. Το ίδιο συμβαίνει και εδώ - μπορείτε να φτιάξετε τις ίδιες πύλες μόνο για όργανα SAST. Θα υπάρχει η ίδια διεπαφή, η ίδια πύλη ποιότητας, μόνο που θα καλείται πύλη ασφαλείας. Και επίσης, εάν έχετε ρυθμίσει μια διαδικασία χρησιμοποιώντας το SonarQube, μπορείτε εύκολα να ενσωματώσετε τα πάντα εκεί.
Ένταξη σε επίπεδο ΚΠ
Και εδώ όλα είναι πολύ απλά:
- Στο ίδιο επίπεδο με τις αυτόματες δοκιμές, δοκιμές μονάδας.
- Διαίρεση ανά στάδια ανάπτυξης: dev, test, prod. Μπορεί να περιλαμβάνονται διαφορετικά σύνολα κανόνων ή διαφορετικές συνθήκες αποτυχίας: διακόπτουμε τη συναρμολόγηση, δεν διακόπτουμε τη συναρμολόγηση.
- Σύγχρονη/Ασύγχρονη Εκτέλεση. Περιμένουμε το τέλος των δοκιμών ασφαλείας ή δεν περιμένουμε. Δηλαδή, απλώς τα εκτοξεύσαμε και προχωράμε, και μετά παίρνουμε μια κατάσταση ότι όλα είναι καλά ή κακά.
Είναι όλα σε έναν τέλειο ροζ κόσμο. Στην πραγματική ζωή, αυτό δεν συμβαίνει, αλλά προσπαθούμε. Το αποτέλεσμα των ελέγχων ασφαλείας θα πρέπει να είναι παρόμοιο με τα αποτελέσματα των δοκιμών μονάδας.
Για παράδειγμα, πήραμε ένα μεγάλο έργο και αποφασίσαμε ότι τώρα θα το σαρώσουμε με SAST - ΟΚ. Ωθήσαμε αυτό το έργο στο SAST, μας έδωσε 20 τρωτά σημεία και πήραμε μια σθεναρή απόφαση ότι όλα είναι καλά. 000 τρωτά σημεία είναι το τεχνικό μας χρέος. Θα βάλουμε το χρέος σε ένα κουτί, θα το σηκώσουμε σιγά σιγά και θα ξεκινήσουμε σφάλματα σε ανιχνευτές ελαττωμάτων. Προσλάβετε μια εταιρεία, κάντε τα πάντα μόνοι μας ή ζητήστε από τους Security Champions να μας βοηθήσουν και το τεχνικό χρέος θα μειωθεί.
Και όλα τα τρωτά σημεία που εμφανίζονται πρόσφατα στον νέο κώδικα θα πρέπει να εξαλειφθούν με τον ίδιο τρόπο όπως τα σφάλματα σε μια μονάδα ή στους αυτόματους ελέγχους. Σχετικά μιλώντας, η συναρμολόγηση ξεκίνησε, έφυγε, δύο δοκιμές και δύο δοκιμές ασφαλείας έπεσαν κάτω. Εντάξει - πήγαμε, κοιτάξαμε τι συνέβη, διορθώσαμε το ένα, διορθώσαμε το δεύτερο, οδηγήσαμε την επόμενη φορά - όλα είναι καλά, δεν εμφανίστηκαν νέα τρωτά σημεία, οι δοκιμές δεν απέτυχαν. Εάν αυτή η εργασία είναι βαθύτερη και πρέπει να την κατανοήσετε καλά, ή η επιδιόρθωση τρωτών σημείων επηρεάζει μεγάλα στρώματα του τι βρίσκεται κάτω από την κουκούλα: ένα σφάλμα εισάγεται στον εντοπισμό ελαττωμάτων, τίθεται προτεραιότητα και διορθώνεται. Δυστυχώς, ο κόσμος δεν είναι τέλειος και μερικές φορές οι δοκιμές αποτυγχάνουν.
Ένα παράδειγμα πύλης ασφαλείας είναι ένα ανάλογο μιας πύλης ποιότητας, όσον αφορά την παρουσία και τον αριθμό των τρωτών σημείων στον κώδικα.
Ενσωματωνόμαστε με το SonarQube - η προσθήκη έχει εγκατασταθεί, όλα είναι πολύ βολικά και δροσερά.
Ενοποίηση αναπτυξιακού περιβάλλοντος
Επιλογές ενσωμάτωσης:
- Έναρξη σάρωσης από το περιβάλλον ανάπτυξης ακόμη και πριν από τη δέσμευση.
- Προβολή αποτελεσμάτων.
- Ανάλυση των αποτελεσμάτων.
- Συγχρονισμός με τον διακομιστή.
Έτσι φαίνεται η λήψη αποτελεσμάτων από τον διακομιστή.
Στο αναπτυξιακό μας περιβάλλον Απλώς εμφανίζεται ένα πρόσθετο στοιχείο που λέει ότι εντοπίστηκαν τέτοια τρωτά σημεία κατά τη σάρωση. Μπορείτε να επεξεργαστείτε αμέσως τον κώδικα, να δείτε συστάσεις και . Όλα αυτά βρίσκονται στο χώρο εργασίας του προγραμματιστή, το οποίο είναι πολύ βολικό - δεν χρειάζεται να ακολουθήσετε τους υπόλοιπους συνδέσμους και να παρακολουθήσετε κάτι επιπλέον.
Open Source
Αυτό είναι το αγαπημένο μου θέμα. Όλοι χρησιμοποιούν βιβλιοθήκες ανοιχτού κώδικα - γιατί να γράψετε ένα σωρό πατερίτσες και ποδήλατα όταν μπορείτε να πάρετε μια έτοιμη βιβλιοθήκη στην οποία έχουν ήδη εφαρμοστεί τα πάντα;
Φυσικά, αυτό είναι αλήθεια, αλλά οι βιβλιοθήκες γράφονται επίσης από ανθρώπους, περιλαμβάνουν επίσης ορισμένους κινδύνους και υπάρχουν επίσης τρωτά σημεία που αναφέρονται περιοδικά ή συνεχώς. Επομένως, υπάρχει ένα επόμενο βήμα στην Ασφάλεια Εφαρμογών - αυτή είναι η ανάλυση των στοιχείων ανοιχτού κώδικα.
Ανάλυση Ανοιχτού Κώδικα - OSA
Το εργαλείο περιλαμβάνει τρία βασικά βήματα.
Εύρεση τρωτών σημείων σε βιβλιοθήκες. Για παράδειγμα, το εργαλείο γνωρίζει ότι χρησιμοποιούμε κάποιο είδος βιβλιοθήκης και ότι μέσα ή σε προγράμματα παρακολούθησης σφαλμάτων υπάρχουν ορισμένες ευπάθειες που σχετίζονται με αυτήν την έκδοση της βιβλιοθήκης. Εάν προσπαθήσετε να το χρησιμοποιήσετε, το εργαλείο θα σας προειδοποιήσει ότι η βιβλιοθήκη είναι ευάλωτη και θα σας συμβουλεύσει να χρησιμοποιήσετε μια άλλη έκδοση όπου δεν υπάρχουν τρωτά σημεία.
Ανάλυση καθαρότητας άδειας. Αυτό δεν είναι πολύ δημοφιλές σε εμάς ακόμα, αλλά εάν εργάζεστε με μια ξένη χώρα, τότε μπορείτε να δεχθείτε περιοδικά επίθεση για χρήση ενός στοιχείου ανοιχτού κώδικα που δεν μπορεί να χρησιμοποιηθεί ή να τροποποιηθεί. Σύμφωνα με την πολιτική της αδειοδοτημένης βιβλιοθήκης, δεν μπορούμε να το κάνουμε αυτό. Ή, εάν το έχουμε τροποποιήσει και το χρησιμοποιήσουμε, πρέπει να δημοσιεύσουμε τον κωδικό μας. Φυσικά, κανείς δεν θέλει να δημοσιεύσει τον κωδικό των προϊόντων του, αλλά μπορείτε επίσης να προστατευτείτε από αυτό.
Ανάλυση εξαρτημάτων που χρησιμοποιούνται σε βιομηχανικό περιβάλλον. Φανταστείτε μια υποθετική κατάσταση ότι επιτέλους ολοκληρώσαμε την ανάπτυξη και κυκλοφορήσαμε την τελευταία έκδοση της microservice μας στον κλάδο. Ζει εκεί υπέροχα - μια εβδομάδα, ένα μήνα, ένα χρόνο. Δεν το συλλέγουμε, δεν διενεργούμε ελέγχους ασφαλείας, όλα δείχνουν να είναι καλά. Αλλά ξαφνικά, δύο εβδομάδες μετά την κυκλοφορία, εμφανίζεται μια κρίσιμη ευπάθεια στο στοιχείο Ανοιχτού Κώδικα, το οποίο χρησιμοποιούμε στη συγκεκριμένη διάταξη, στο βιομηχανικό περιβάλλον. Εάν δεν καταγράψουμε τι και πού χρησιμοποιούμε, τότε αυτή η ευπάθεια απλά δεν θα φανεί. Ορισμένα εργαλεία έχουν τη δυνατότητα να παρακολουθούν τρωτά σημεία σε βιβλιοθήκες που χρησιμοποιούνται αυτήν τη στιγμή στο prom. Είναι πολύ χρήσιμο.
χαρακτηριστικά:
- Διαφορετικές πολιτικές για διαφορετικά στάδια ανάπτυξης.
- Παρακολούθηση εξαρτημάτων σε βιομηχανικό περιβάλλον.
- Έλεγχος βιβλιοθηκών στο περίγραμμα του οργανισμού.
- Υποστήριξη για διάφορα συστήματα κατασκευής και γλώσσες.
- Ανάλυση εικόνων Docker.
Μερικά παραδείγματα ηγετών στον τομέα που ασχολούνται με την ανάλυση του Ανοιχτού Κώδικα.
Το μόνο δωρεάν είναι από το OWASP. Μπορείτε να το ενεργοποιήσετε στα πρώτα στάδια, να δείτε πώς λειτουργεί και τι υποστηρίζει. Βασικά, όλα αυτά είναι προϊόντα cloud ή on-premise, αλλά πίσω από τη βάση τους εξακολουθούν να πηγαίνουν στο Διαδίκτυο. Δεν στέλνουν τις βιβλιοθήκες σας, αλλά κατακερματισμούς ή τις τιμές τους που υπολογίζουν και δακτυλικά αποτυπώματα στον διακομιστή τους για να λαμβάνουν νέα για την παρουσία τρωτών σημείων.
Ενσωμάτωση διαδικασίας
Έλεγχος περιμετρικής βιβλιοθήκηςπου λαμβάνονται από εξωτερικές πηγές. Έχουμε εξωτερικά και εσωτερικά αποθετήρια. Για παράδειγμα, έχουμε το Nexus μέσα στο Event Central και θέλουμε να βεβαιωθούμε ότι δεν υπάρχουν ευπάθειες με "κρίσιμη" ή "υψηλή" κατάσταση στο χώρο αποθήκευσης μας. Μπορείτε να ρυθμίσετε το διακομιστή μεσολάβησης χρησιμοποιώντας το εργαλείο Nexus Firewall Lifecycle, έτσι ώστε τέτοιες ευπάθειες να αποκοπούν και να μην περιλαμβάνονται στον εσωτερικό χώρο αποθήκευσης.
CI ενσωμάτωση. Στο ίδιο επίπεδο με τις αυτόματες δοκιμές, τις δοκιμές μονάδων και τη διαίρεση σε στάδια ανάπτυξης: dev, test, prod. Σε κάθε στάδιο, μπορείτε να κάνετε λήψη οποιωνδήποτε βιβλιοθηκών, να χρησιμοποιήσετε οτιδήποτε, αλλά αν υπάρχει κάτι δύσκολο με την κατάσταση "κρίσιμης σημασίας", θα πρέπει πιθανώς να επιστήσετε την προσοχή των προγραμματιστών σε αυτό στο στάδιο της συμμετοχής στο χορό.
Ενσωμάτωση τεχνουργημάτων: Nexus και JFrog.
Ενσωμάτωση στο αναπτυξιακό περιβάλλον. Τα εργαλεία που επιλέγετε θα πρέπει να έχουν ενοποίηση με περιβάλλοντα ανάπτυξης. Ο προγραμματιστής πρέπει να έχει πρόσβαση στα αποτελέσματα σάρωσης από τον χώρο εργασίας του ή τη δυνατότητα να σαρώσει και να ελέγξει τον κώδικα για τρωτά σημεία πριν τον δεσμεύσει στο CVS.
Ενσωμάτωση CD. Αυτό είναι ένα ωραίο χαρακτηριστικό που μου αρέσει πολύ και για το οποίο έχω ήδη μιλήσει - παρακολούθηση της εμφάνισης νέων τρωτών σημείων σε ένα βιομηχανικό περιβάλλον. Δουλεύει κάπως έτσι.
Εχουμε Δημόσια αποθετήρια στοιχείων - μερικά εργαλεία έξω και το εσωτερικό μας αποθετήριο. Θέλουμε να υπάρχουν μόνο αξιόπιστα εξαρτήματα. Κατά τη δημιουργία ενός αιτήματος μεσολάβησης, ελέγχουμε ότι η βιβλιοθήκη που κατεβάσατε δεν έχει τρωτά σημεία. Εάν εμπίπτει σε ορισμένες πολιτικές που ορίζουμε και αναγκαστικά συντονίζουμε με την ανάπτυξη, τότε δεν το ανεβάζουμε και λαμβάνουμε απόρριψη για χρήση άλλης έκδοσης. Αντίστοιχα, εάν υπάρχει κάτι πραγματικά κρίσιμο και κακό στη βιβλιοθήκη, τότε ο προγραμματιστής δεν θα λάβει τη βιβλιοθήκη ακόμη και στο στάδιο της εγκατάστασης - αφήστε τον να χρησιμοποιήσει μια έκδοση υψηλότερη ή χαμηλότερη.
- Κατά την κατασκευή, ελέγχουμε ότι κανείς δεν γλίστρησε κάτι κακό, ότι όλα τα εξαρτήματα είναι ασφαλή και κανείς δεν έφερε κάτι επικίνδυνο στη μονάδα flash.
- Έχουμε μόνο αξιόπιστα στοιχεία στο αποθετήριο.
- Κατά την ανάπτυξη, ελέγχουμε για άλλη μια φορά το ίδιο το πακέτο: war, jar, DL ή εικόνα Docker για το γεγονός ότι συμμορφώνεται με την πολιτική.
- Κατά την είσοδο στο βιομηχανικό περιβάλλον, παρακολουθούμε τι συμβαίνει στο βιομηχανικό περιβάλλον: κρίσιμα τρωτά σημεία εμφανίζονται ή δεν εμφανίζονται.
Δυναμική Ανάλυση - DAST
Τα εργαλεία δυναμικής ανάλυσης διαφέρουν θεμελιωδώς από όλα όσα έχουν ειπωθεί προηγουμένως. Αυτό είναι ένα είδος μίμησης της εργασίας του χρήστη με την εφαρμογή. Εάν πρόκειται για διαδικτυακή εφαρμογή, στέλνουμε αιτήματα που μιμούνται την εργασία του πελάτη, κάνουμε κλικ στα κουμπιά στο μπροστινό μέρος, στέλνουμε τεχνητά δεδομένα από τη φόρμα: εισαγωγικά, αγκύλες, χαρακτήρες σε διαφορετικές κωδικοποιήσεις για να δούμε πώς λειτουργεί η εφαρμογή και επεξεργάζεται εξωτερικά δεδομένα.
Το ίδιο σύστημα σάς επιτρέπει να ελέγχετε για ευπάθειες προτύπων στο Open Source. Δεδομένου ότι το DAST δεν γνωρίζει ποιο Ανοιχτό Κώδικα χρησιμοποιούμε, απλώς ρίχνει "κακόβουλα" μοτίβα και αναλύει τις απαντήσεις του διακομιστή:
- Ναι, υπάρχει ένα πρόβλημα αποζερικοποίησης εδώ, αλλά όχι εδώ.
Υπάρχουν μεγάλοι κίνδυνοι σε αυτό, γιατί εάν πραγματοποιήσετε αυτήν τη δοκιμή ασφαλείας στην ίδια βάση με την οποία συνεργάζονται οι δοκιμαστές, μπορεί να συμβούν δυσάρεστα πράγματα.
- Υψηλό φορτίο στο δίκτυο διακομιστή εφαρμογών.
- Χωρίς ενσωματώσεις.
- Δυνατότητα αλλαγής των ρυθμίσεων της αναλυόμενης εφαρμογής.
- Δεν υπάρχει υποστήριξη για τις απαραίτητες τεχνολογίες.
- Δυσκολία ρύθμισης.
Είχαμε μια κατάσταση όταν ξεκινήσαμε τελικά το AppScan: αποκλείσαμε την πρόσβαση στην εφαρμογή για μεγάλο χρονικό διάστημα, λάβαμε 3 λογαριασμούς και ήμασταν ενθουσιασμένοι - τελικά, θα ελέγξουμε τα πάντα! Ξεκινήσαμε μια σάρωση και το πρώτο πράγμα που έκανε το AppScan ήταν να μπει στον πίνακα διαχείρισης, να τρυπήσει όλα τα κουμπιά, να αλλάξει τα μισά δεδομένα και, στη συνέχεια, να σκοτώσει τον διακομιστή με το δικό του -αιτήσεων. Το Development with Testing είπε:
«Παιδιά, πλάκα με κάνετε;! Σου δώσαμε λογαριασμούς και εσύ έβαλες το περίπτερο!
Εξετάστε πιθανούς κινδύνους. Στην ιδανική περίπτωση, ετοιμάστε μια ξεχωριστή βάση για τη δοκιμή της ασφάλειας πληροφοριών, η οποία θα απομονωθεί από το υπόλοιπο περιβάλλον τουλάχιστον με κάποιο τρόπο, και ελέγξτε υπό όρους τον πίνακα διαχείρισης, κατά προτίμηση σε χειροκίνητη λειτουργία. Αυτό είναι μια δοκιμασία - αυτά τα υπόλοιπα ποσοστά προσπαθειών που δεν εξετάζουμε τώρα.
Αξίζει να ληφθεί υπόψη ότι μπορείτε να το χρησιμοποιήσετε ως ανάλογο της δοκιμής φορτίου. Στο πρώτο στάδιο, μπορείτε να ενεργοποιήσετε τον δυναμικό σαρωτή σε 10-15 νήματα και να δείτε τι συμβαίνει, αλλά συνήθως, όπως δείχνει η πρακτική, τίποτα καλό.
Μερικοί πόροι που χρησιμοποιούμε συνήθως.
Αξίζει να τονιστεί είναι το «ελβετικό μαχαίρι» για κάθε επαγγελματία ασφαλείας. Το χρησιμοποιούν όλοι και είναι πολύ βολικό. Μια νέα δοκιμαστική έκδοση της έκδοσης για επιχειρήσεις έχει πλέον κυκλοφορήσει. Αν παλαιότερα ήταν απλώς ένα αυτόνομο βοηθητικό πρόγραμμα με πρόσθετα, τώρα οι προγραμματιστές φτιάχνουν επιτέλους έναν μεγάλο διακομιστή από τον οποίο θα είναι δυνατή η διαχείριση πολλών πρακτόρων. Είναι ωραίο, σας προτείνω να το δοκιμάσετε.
Ενσωμάτωση διαδικασίας
Η ενσωμάτωση είναι αρκετά καλή και απλή: ξεκινήστε τη σάρωση μετά την επιτυχή εγκατάσταση εφαρμογές στο περίπτερο και σάρωση μετά από επιτυχή δοκιμή ενσωμάτωσης.
Εάν οι ενσωματώσεις δεν λειτουργούν ή υπάρχουν στελέχη και ψευδείς λειτουργίες, είναι ανούσιο και άχρηστο - ανεξάρτητα από το μοτίβο που στέλνουμε, ο διακομιστής θα εξακολουθεί να ανταποκρίνεται με τον ίδιο τρόπο.
- Στην ιδανική περίπτωση, ένας ξεχωριστός πάγκος δοκιμών.
- Πριν από τη δοκιμή, σημειώστε τη σειρά σύνδεσης.
- Η δοκιμή του συστήματος διαχείρισης είναι μόνο χειροκίνητη.
διαδικασία
Λίγο γενικευμένο για τη διαδικασία γενικά και για τη δουλειά του κάθε εργαλείου, ειδικότερα. Όλες οι εφαρμογές είναι διαφορετικές - μια λειτουργεί καλύτερα με δυναμική ανάλυση, μια άλλη με στατική ανάλυση, η τρίτη με ανάλυση OpenSource, pentest ή κάτι άλλο γενικά, για παράδειγμα, συμβάντα με .
Κάθε διαδικασία πρέπει να ελέγχεται.
Για να κατανοήσετε πώς λειτουργεί η διαδικασία και πού μπορεί να βελτιωθεί, πρέπει να συλλέξετε μετρήσεις από όλα όσα μπορείτε να βρείτε στα χέρια σας, συμπεριλαμβανομένων των μετρήσεων παραγωγής, των μετρήσεων από εργαλεία και των ανιχνευτών ελαττωμάτων.
Οποιαδήποτε πληροφορία είναι χρήσιμη. Είναι απαραίτητο να εξετάσετε σε διάφορες ενότητες πού χρησιμοποιείται καλύτερα αυτό ή εκείνο το εργαλείο, όπου η διαδικασία κρεμάει συγκεκριμένα. Ίσως αξίζει να κοιτάξετε τον χρόνο απόκρισης ανάπτυξης για να δείτε πού να βελτιώσετε τη διαδικασία βάσει χρόνου. Όσο περισσότερα δεδομένα, τόσο περισσότερες περικοπές μπορούν να κατασκευαστούν από το ανώτερο επίπεδο μέχρι τις λεπτομέρειες κάθε διαδικασίας.
Δεδομένου ότι όλοι οι στατικοί και δυναμικοί αναλυτές έχουν τα δικά τους API, τις δικές τους μεθόδους εκκίνησης, τις δικές τους αρχές, μερικοί έχουν προγραμματιστές, άλλοι όχι - γράφουμε ένα εργαλείο AppSec Orchestrator, το οποίο σας επιτρέπει να κάνετε ένα μόνο σημείο εισόδου σε ολόκληρη τη διαδικασία από το προϊόν και να το διαχειριστείτε από ένα σημείο.
Οι διαχειριστές, οι προγραμματιστές και οι μηχανικοί ασφαλείας έχουν ένα σημείο εισόδου από το οποίο μπορούν να δουν τι εκτελείται, να διαμορφώσουν και να εκτελέσουν σαρώσεις, να λάβουν αποτελέσματα σάρωσης και να υποβάλουν απαιτήσεις. Προσπαθούμε να απομακρυνθούμε από κομμάτια χαρτιού, να μεταφράσουμε τα πάντα σε ανθρώπινα που χρησιμοποιεί η ανάπτυξη - σελίδες στο Confluence με κατάσταση και μετρήσεις, ελαττώματα στο Jira ή σε διάφορους ανιχνευτές ελαττωμάτων ή ενσωμάτωση σε μια σύγχρονη / ασύγχρονη διαδικασία σε CI / CD.
Βασικές τακτικές
Τα εργαλεία δεν έχουν σημασία. Σκεφτείτε πρώτα τη διαδικασία και μετά εφαρμόστε τα εργαλεία. Τα εργαλεία είναι καλά, αλλά ακριβά, ώστε να μπορείτε να ξεκινήσετε με τη διαδικασία και να βελτιώσετε την αλληλεπίδραση και την κατανόηση μεταξύ ανάπτυξης και ασφάλειας. Από την άποψη της ασφάλειας, δεν υπάρχει λόγος να "σταματούν" τα πάντα στη σειρά. Από την άποψη της ανάπτυξης, εάν υπάρχει κάτι υψηλό μέγα σούπερ κρίσιμο, τότε αυτό πρέπει να εξαλειφθεί και να μην κλειστεί στο πρόβλημα .
Ποιότητα προϊόντος - κοινός στόχος τόσο την ασφάλεια όσο και την ανάπτυξη. Κάνουμε ένα πράγμα, προσπαθούμε να διασφαλίσουμε ότι όλα λειτουργούν σωστά και δεν υπάρχουν κίνδυνοι φήμης και οικονομικές απώλειες. Αυτός είναι ο λόγος για τον οποίο προωθούμε την προσέγγιση των DevSecOps, SecDevOps προκειμένου να δημιουργήσουμε επικοινωνία και να κάνουμε το προϊόν καλύτερο.
Ξεκινήστε με αυτό που υπάρχει ήδη: απαιτήσεις, αρχιτεκτονική, μερικοί έλεγχοι, εκπαιδεύσεις, κατευθυντήριες γραμμές. Δεν είναι απαραίτητο να εφαρμοστούν αμέσως όλες οι πρακτικές σε όλα τα έργα - κινηθείτε επαναληπτικά. Δεν υπάρχει ενιαίο πρότυπο πείραμα και δοκιμάστε διαφορετικές προσεγγίσεις και λύσεις.
Ισότητα μεταξύ ελαττωμάτων IS και λειτουργικών ελαττωμάτων.
Αυτοματοποιήστε τα πάνταπου κινείται. Οτιδήποτε δεν κινείται, κινείται και αυτοματοποιείται. Εάν κάτι γίνεται με το χέρι, αυτό δεν είναι καλό μέρος της διαδικασίας. Ίσως αξίζει να το ξανασκεφτούμε και να το αυτοματοποιήσουμε.
Εάν το μέγεθος της ομάδας IB είναι μικρό - χρησιμοποιήστε Security Champions.
Ίσως αυτό για το οποίο μίλησα να μην σας ταιριάζει και να καταλήξετε σε κάτι δικό σας - και αυτό είναι καλό. Αλλά επιλέξτε εργαλεία με βάση τις απαιτήσεις της διαδικασίας σας. Μην κοιτάτε τι λέει η κοινότητα ότι αυτό το εργαλείο είναι κακό και αυτό είναι καλό. Ίσως να είναι το αντίστροφο στο προϊόν σας.
Απαιτήσεις εργαλείου.
- Χαμηλό ψευδώς θετικό.
- Επαρκής χρόνος ανάλυσης.
- Η ευκολία χρήσης.
- Διαθεσιμότητα ενσωματώσεων.
- Κατανόηση του οδικού χάρτη ανάπτυξης προϊόντων.
- Δυνατότητα προσαρμογής εργαλείων.
Η έκθεση του Yuriy επιλέχθηκε ως μία από τις καλύτερες στο DevOpsConf 2018. Για να εξοικειωθείτε με ακόμα πιο ενδιαφέρουσες ιδέες και πρακτικές περιπτώσεις, ελάτε στο Skolkovo στις 27 και 28 Μαΐου στα πλαίσια . Ακόμα καλύτερα, αν είστε πρόθυμοι να μοιραστείτε την εμπειρία σας, τότε Υποβάλετε την αναφορά σας έως τις 21 Απριλίου.
Πηγή: www.habr.com