Σκοπός

Ο σκοπός αυτής της πολιτικής είναι να καθοριστεί ενός προτύπου εντός της εταιρείας {COMPANY_NAME} ( {ABBREVIATION_NAME} ) για την εφαρμογή ενός κύκλου ζωής ασφαλούς ανάπτυξης «Secure Development Lifecycle» (SDL) που παράγει λογισμικό που είναι ασφαλές , προσβάσιμο, έτοιμο για τις συσκευές του οργανισμού και συμμορφώνεται με τα πρότυπα ανάπτυξης, τις πολιτικές, και τις διεθνείς πρακτικές.

Τα τρωτά σημεία των εφαρμογών αντιπροσωπεύουν το μεγαλύτερο μέρος των διαμορφούμενων επιθέσεων (attack vectors) ύστερα από το κακόβουλο λογισμικό. Είναι σημαντικό οποιαδήποτε εφαρμογή να αξιολογείται και ελέγχεται για ευπάθειες και οι ευπάθειες που αποκαλύπτονται να αποκαθίστανται πριν από την παραγωγική λειτουργία.

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

Πεδίο Εφαρμογής

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

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

Όλες οι δραστηριότητες ασφαλούς ανάπτυξης εφαρμογών θα εκτελούνται από εξουσιοδοτημένο προσωπικό είτε ήδη απασχολούμενο είτε με σύμβαση από την {ABBREVIATION_NAME} .

Όλα τα ευρήματα των αξιολογήσεων θεωρούνται εμπιστευτικά και πρέπει να διανεμηθούν σε άτομα με βάση «ανάγκη γνώσης». Απαγορεύεται αυστηρά η διανομή τυχόν ευρημάτων εκτός του {ABBREVIATION_NAME} εκτός εάν εγκριθεί από τον Διευθύνοντα Σύμβουλο .

Δήλωση Πολιτικής

Γενική Μεθοδολογία

Οι περισσότερες μεθοδολογίες ανάπτυξης εφαρμογών αποτελούνται γενικά από τα ίδια βασικά δομικά στοιχεία (στάδια ανάπτυξης εφαρμογών):

1. Αρχική Ιδέα και Γενικός Σχεδιασμός (Concept and planning)
2. Αρχιτεκτονική και Ειδικός Σχεδιασμός (Architecture and design)
3. Υλοποίηση (Implementation)
4. Δοκιμές και Διόρθωση Σφαλμάτων (Testing and bug fixing)
5. Απελευθέρωση και Συντήρηση (Release and maintenance)
6. Τέλος Ζωής (End of life)

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

Αρχική Ιδέα και Γενικός Σχεδιασμός (Concept and planning)

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

• SDL discovery: Το SDL discovery ξεκινά με τον καθορισμό στόχων ασφάλειας και συμμόρφωσης για το έργο. Στη συνέχεια, γίνεται επιλογή μιας μεθοδολογίας SDL και γράφεται ένα λεπτομερές σχέδιο των σχετικών δραστηριοτήτων SDL. Αυτό διασφαλίζει ότι η ομάδα του έργου θα αντιμετωπίσει ζητήματα ασφαλείας το συντομότερο δυνατό.
• Security requirements: Μια λίστα με τις απαιτήσεις ασφαλείας του έργου πρέπει να είναι προετοιμασμένη. Πρέπει να περιλαμβάνει τόσο τεχνικές όσο και κανονιστικές απαιτήσεις. Η λίστα βοηθά στην εύκολη αναγνώριση και επιδιόρθωση πιθανών μη συμμορφούμενων περιοχών του έργου.
• Security awareness training: Οι εκπαιδευτικές δραστηριότητες παρέχουν βασικές γνώσεις ασφάλειας που ξεκινούν από βασικές γνώσεις σχετικά με τις διάφορες απειλές έως αναλυτικές πληροφορίες σχετικά με την ασφαλή ανάπτυξη. Η βασική εκπαίδευση ασφάλειας δημιουργεί μια νοοτροπία ασφάλειας για όλους τους συμμετέχοντες στο έργο. Τα προχωρημένα μαθήματα διδάσκουν αρχές ασφαλούς σχεδιασμού σε βασικούς συμμετέχοντες στο έργο.

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

Αρχιτεκτονική και Ειδικός Σχεδιασμός (Architecture and design)

Σκοπός αυτού του σταδίου είναι ο σχεδιασμός ενός προϊόντος που πληροί τις απαιτήσεις. Αυτό περιλαμβάνει μοντελοποίηση της δομής της εφαρμογής και των σεναρίων χρήσης της, καθώς και επιλογή στοιχείων τρίτων (third party components) που μπορούν να επιταχύνουν την ανάπτυξη. Το αποτέλεσμα αυτού του σταδίου είναι ένα έγγραφο σχεδιασμού . Οι πρακτικές SDL που συνιστώνται για αυτό το στάδιο περιλαμβάνουν:

• Threat modeling: Η μοντελοποίηση απειλών συνίσταται στην αναγνώριση πιθανών σεναρίων επίθεσης και στην προσθήκη σχετικών αντιμέτρων στον σχεδιασμό της εφαρμογής. Η μοντελοποίηση αποκαλύπτει τις πιθανές απειλές νωρίς, μειώνοντας έτσι το σχετικό κόστος και θέτει τη βάση για μελλοντικά σχέδια αντιμετώπισης συμβάντων.
• Secure design: Το έγγραφο σχεδιασμού και οι επακόλουθες ενημερώσεις του επικυρώνονται με βάση τις απαιτήσεις ασφαλείας. Οι έγκαιρες ανασκοπήσεις του σχεδιασμού βοηθούν στον εντοπισμό χαρακτηριστικών που εκτίθενται σε κινδύνους ασφαλείας πριν από την υλοποίησή τους.
• Third-party software tracking: Οι ευπάθειες σε στοιχεία τρίτων μπορούν να αποδυναμώσουν ολόκληρο το σύστημα, καθιστώντας σημαντικό να παρακολουθείται η ασφάλειά τους και να εφαρμόζονται ενημερώσεις κώδικα/βιβλιοθηκών όταν είναι απαραίτητο. Οι τακτικοί έλεγχοι του λογισμικού τρίτων, βοηθούν στον εντοπισμό περιοχών που απειλούνται από στοιχεία που μπορεί να παραβιαστούν και βοηθά στο να συμπληρωθούν τα κενά ασφαλείας.

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

Υλοποίηση (Implementation)

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

• Secure coding: Οδηγίες και οι λίστες ελέγχου υπενθυμίζουν στους προγραμματιστές τυπικά λάθη που πρέπει να αποφεύγονται, όπως η αποθήκευση μη κρυπτογραφημένων κωδικών πρόσβασης. Η επιβολή ασφαλών πρακτικών κωδικοποίησης εξαλείφει πολλές ασήμαντες ευπάθειες και εξοικονομεί χρόνο για άλλες σημαντικές εργασίες. Υπάρχουν διάφορα πρότυπα που ακολουθούνται , όπως το «SEI CERT Coding Standards»[1], «.NET Secure coding guidelines»[2], «OWASP Secure Coding Practices-Quick Reference Guide»[3] που εξαρτώνται κυρίως από τη γλώσσα προγραμματισμού που χρησιμοποιείται και την αρχιτεκτονική του έργου.
• Static scanning: Τα εργαλεία σάρωσης στατικών εφαρμογών (SAST) ανασκοπούν τον γραμμένο κώδικα και εντοπίζουν πιθανές αδυναμίες χωρίς να χρειάζεται να εκτελεσθεί η εφαρμογή. Η καθημερινή χρήση των εργαλείων στατικής σάρωσης αποκαλύπτει λάθη προτού μπορέσουν να μπουν στα εκτελέσιμα.
• Code review: Ενώ η αυτόματη σάρωση εξοικονομεί πολλή προσπάθεια, οι μη αυτόματες ανασκοπήσεις κώδικα εξακολουθούν να είναι απαραίτητες για τη δημιουργία ασφαλών εφαρμογών. Οι έγκαιρες ανασκοπήσεις βοηθούν τους προγραμματιστές να επισημάνουν και να διορθώσουν πιθανά ζητήματα προτού στρέψουν την προσοχή σε άλλες εργασίες.

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

Δοκιμές και Διόρθωση Σφαλμάτων (Testing and bug fixing)

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

• Dynamic scanning: Τα δυναμικά εργαλεία σαρωτή εφαρμογών (DAST) αποκαλύπτουν ευπάθειες προσομοιώνοντας επιθέσεις hacker κατά το χρόνο εκτέλεσης. Για τη μείωση των ψευδών θετικών (false positive), χρησιμοποιείται μια συνδυασμένη προσέγγιση (IAST). Αυτή η προσέγγιση συμπληρώνει τη σάρωση χρόνου εκτέλεσης με την παρακολούθηση του εκτελεσμένου κώδικα και της ροής δεδομένων της εφαρμογής. Εκτός από την αποκάλυψη τακτικών τρωτών σημείων, η δυναμική σάρωση εντοπίζει σφάλματα διαμόρφωσης που επηρεάζουν την ασφάλεια.
• Fuzzing: Η δοκιμή Fuzz περιλαμβάνει τη δημιουργία τυχαίων εισόδων με βάση προσαρμοσμένα μοτίβα και τον έλεγχο κατά πόσον η εφαρμογή μπορεί να χειριστεί αυτές τις εισόδους σωστά. Τα αυτοματοποιημένα εργαλεία fuzzing βελτιώνουν την προστασία από επιθέσεις που χρησιμοποιούν λανθασμένες εισόδους, όπως π.χ. SQL injection.
• Penetration testing: Είναι προτιμότερο να γίνεται χρήση επαγγελματικών ομάδων ασφαλείας τρίτων (εκτός οργανισμού) για προσομοίωση πιθανών επιθέσεων. Οι εξωτερικοί εμπειρογνώμονες βασίζονται στη γνώση και τη διαίσθησή τους για την αναπαραγωγή σεναρίων επίθεσης που μπορεί να παραβλεφθούν από την ομάδα του έργου.

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

Απελευθέρωση και Συντήρηση (Release and maintenance)

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

• Environment management: Οι πραγματικοί εισβολείς εκμεταλλεύονται σφάλματα και ευπάθειες στη διαμόρφωση του περιβάλλοντος (configuration errors). Η παρακολούθηση ασφάλειας πρέπει να καλύπτει ολόκληρο το σύστημα και όχι μόνο την εφαρμογή. Η παρακολούθηση αυτή βελτιώνει τη συνολική ασφάλεια της εφαρμογής.
• Incident response plan: Ένα σχέδιο αντιμετώπισης περιστατικών περιγράφει με σαφήνεια τις διαδικασίες που ο ΥΑΠ ή η ομάδα διαχείρισης του περιστατικού πρέπει να ακολουθήσει για την αντιμετώπιση τυχόν παραβιάσεων ασφάλειας που μπορεί να προκύψουν. Η ταχεία εκτέλεση του σχεδίου απόκρισης είναι ζωτικής σημασίας για τη δοκιμή και την διόρθωση παραβιάσεων ασφαλείας.
• Ongoing security checks: Security checks must be repeated on a regular basis because new types of vulnerabilities are being discovered at a steady rate. Regular checks protect our applications from newly discovered vulnerabilities. Οι έλεγχοι ασφαλείας πρέπει να επαναλαμβάνονται σε τακτική βάση επειδή καθημερινά ανακαλύπτονται νέοι τύποι ευπάθειας με σταθερό ρυθμό. Οι τακτικοί έλεγχοι προστατεύουν τις εφαρμογές μας από ευπάθειες που ανακαλύφθηκαν πρόσφατα.

Αυτές οι πρακτικές μας βοηθούν να ανταποκριθούμε στις νέες απειλές γρήγορα και αποτελεσματικά.

Τέλος Ζωής (End of life)

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

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

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

Χρήση Μεθοδολογιών

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

• Microsoft Security Development Lifecycle (SDL)[4]
• OWASP Software Assurance Maturity Model (SAMM)[5]
• Building Security in Maturity Model (BSIMM)[6]

Ασφαλές Περιβάλλον Ανάπτυξης (Secure Development Environment)

Απομόνωση Παραγωγικού και Περιβάλλοντος Ανάπτυξης

It is required the separation of development, test, and production environments. It keeps untested code changes from deleting or corrupting production data, and it keeps developers from having access to test and production systems.

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

Τελικά Σημεία (Secure Endpoints)

•  Οι προγραμματιστές πρέπει να συνδέονται στο περιβάλλον χρησιμοποιώντας υπολογιστές που έχουν το καθορισμένο επίπεδο ασφάλειας.
• Η χρήση εξωτερικών μέσων αποθήκευσης, ιδιαίτερα φορητές μονάδες USB, για μεταφορά αρχείων απαγορεύεται[7].
•  Όλος ο εξοπλισμός ανάπτυξης (υπολογιστές, φορητοί υπολογιστές, φορητές συσκευές) πρέπει να έχουν εγκατεστημένα προγράμματα προστασίας από ιούς.
• Οι υπολογιστές που χρησιμοποιούνται για ανάπτυξη ιδιαίτερα ευαίσθητων εφαρμογών, πρέπει να έχουν κρυπτογραφημένα αποθηκευτικά μέσα.
• Απαγορεύεται η σύνδεση εξωτερικών μέσων αποθήκευσης με το περιβάλλον ανάπτυξης.

Αποθετήριο Κώδικα (Code Repository)

Εκτός από την ασφάλεια των τελικών σημείων, ισχύουν τα ακόλουθα:

• Τα δημόσια αποθετήρια κώδικα απαγορεύονται, εκτός εάν ένα έργο είναι ανοικτού κώδικα (π.χ. GitHub).
• Ο κώδικας διατηρείται σε ιδιωτικούς διακομιστές (Εσωτερικά αποθετήρια) .
• Backups πρέπει να τηρούνται και στο περιβάλλον ανάπτυξης. Τα αντίγραφα ασφαλείας κώδικα σε μη ασφαλή περιβάλλοντα μπορούν να θέσουν σε κίνδυνο ευαίσθητες πληροφορίες και η ανάκτηση των πληροφοριών από ένα μη ασφαλές περιβάλλον θα μπορούσε να είναι μια ανοιχτή πρόσκληση για κακόβουλο λογισμικό.
• Καταγραφές για το ποιος έχει πρόσβαση στο κώδικα πρέπει να τηρούνται. Είναι σημαντικό να καταγράφονται οι περιπτώσεις στις οποίες ένα εξουσιοδοτημένο άτομο παίρνει τον πηγαίο κώδικα ή αποθηκεύει τον πηγαίο κώδικα (checks source code in or out).

Ανασκόπηση (Audit)

Η ανασκόπηση του κώδικα είναι υποχρεωτική ώστε να διασφαλιστεί ότι δεν εισέρχονται κακόβουλες λειτουργίες ή ευπάθειες στο παραγωγικό εκτελέσιμο. Όλες οι δοκιμές πρέπει να καλύπτουν το 100 τοις εκατό του πηγαίου κώδικα, ειδικά όταν ο κώδικας είναι γραμμένος σε γλώσσα δέσμης ενεργειών (scripting language) που μπορεί να οδηγήσει σε κακόβουλο κώδικα από εξωτερική πηγή.

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

Outsourced Development

Όταν η ανάπτυξη λογισμικού συστημάτων ανατίθεται σε εξωτερικούς συνεργάτες, πρέπει να αντιμετωπιστούν τα ακόλουθα σημεία σε ολόκληρη την εξωτερική αλυσίδα εφοδιασμού του {ABBREVIATION_NAME}:

• Θα πρέπει να προβλεφθούν ρυθμίσεις Licensing, ιδιοκτησίας κώδικα και τα δικαιώματα πνευματικής ιδιοκτησίας που σχετίζονται με το περιεχόμενο της εξωτερικής ανάθεσης.
• Θα πρέπει να προβλεφθούν συμβατικές απαιτήσεις για ασφαλείς πρακτικές σχεδιασμού, κωδικοποίησης και δοκιμών. Αυτή η πολιτική ισχύει για όλους τους αναδόχους.
• Θα πρέπει να γνωστοποιηθεί το εγκεκριμένο μοντέλο απειλής στους εξωτερικούς προγραμματιστές.
• Ένας έλεγχος αποδοχής για την ποιότητα και την ακρίβεια των παραδοτέων πρέπει να είναι προγραμματισμένος βάσει συμβολαίου.
• Κρατήστε αποδεικτικά στοιχεία ότι τα όρια ασφάλειας χρησιμοποιήθηκαν για την επιτυχή υλοποίηση των ελάχιστων αποδεκτών επιπέδων ποιότητας ασφάλειας και απορρήτου.
• Κρατήστε αποδεικτικά στοιχεία ότι έχουν εφαρμοστεί επαρκείς δοκιμές για την προστασία από την απουσία κακόβουλου περιεχομένου εκούσιου ή ακούσιου κατά την παράδοση .
• Κρατήστε αποδείξεις ότι έχουν εφαρμοστεί επαρκείς δοκιμές για την προστασία από την παρουσία γνωστών τρωτών σημείων .
• Προβλέψτε ρυθμίσεις διαμεσολάβησης, π.χ. εάν ο πηγαίος κώδικας δεν είναι πλέον διαθέσιμος.
• Διατηρήστε το συμβατικό δικαίωμα ελέγχου και επιθεωρήσεων των διαδικασιών και των μέτρων ελέγχου κατά την διάρκεια της ανάπτυξης.
• Ζητήστε αποτελεσματική τεκμηρίωση του περιβάλλοντος κατασκευής που χρησιμοποιείται για τη δημιουργία παραδοτέων.
• Το {ABBREVIATION_NAME} παραμένει υπεύθυνο για τη συμμόρφωση με τους ισχύοντες νόμους και την επαλήθευση της αποτελεσματικότητας του ελέγχου.

Συμμόρφωση

Μέτρηση

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

Εξαιρέσεις

Οποιαδήποτε εξαίρεση στην πολιτική πρέπει να εγκριθεί εκ των προτέρων από τον ΥΑΠ.

Μη Συμμόρφωση

Ένας υπάλληλος που διαπιστώνεται ότι έχει παραβιάσει αυτήν την πολιτική ενδέχεται να υπόκειται σε πειθαρχικές κυρώσεις, έως και τη λήξη της απασχόλησης.

---

[1] https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards

[2] https://docs.microsoft.com/en-us/dotnet/standard/security/secure-coding-guidelines

[3] https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/migrated_content

[4] https://www.microsoft.com/en-us/securityengineering/sdl/practices

[5] https://owaspsamm.org/

[6] https://www.bsimm.com/

[7] Stuxnet, arguably the world’s first known cybersecurity weapon, came from a USB drive designed to infect a programming environment