Ce ar trebui să conțină politica de securitate a informațiilor pentru dezvoltarea de software?
O politică de securitate a informațiilor pentru dezvoltarea de software este documentul în care stabilești cum se ocupă organizația ta de securitatea informațiilor, sistemelor și codului. Pentru o companie de software, aceasta se referă la două lucruri simultan: securitatea a ceea ce construiești și securitatea mediului în care o construiești. Ambele aparțin în același document, chiar dacă sunt subiecte diferite din punct de vedere al conținutului.
În practică, aceasta înseamnă că politica de obicei tratează sfera de aplicare (ce sisteme și ce proiecte de dezvoltare sunt cuprinse), responsabilitățile (cine decide, cine gestionează, cine monitorizează), modul în care se reglementează accesul la codul sursă și la mediile de dezvoltare, cum se identifică și se remediază vulnerabilitățile din propriul cod, cum se gestionează mediile de testare în raport cu mediile de producție, cum sunt înregistrate incidentele și cum este politica în sine menținută și revizuită. O listă de verificare de la un client cere adesea exact acest tip de documente ca dovadă, nu o descriere tehnică a codului tău sursă.
Două niveluri: produsul și linia de dezvoltare
Primul nivel se referă la produs: software-ul pe care îl livrez clienților. Acesta include o descriere a modului în care se gestionează vulnerabilitățile descoperite după livrare, cum ajung actualizările și patch-urile la clienți, și cine din organizație este responsabil pentru urmărirea rapoartelor privind problemele de securitate din produs.
Al doilea nivel se referă la linia de dezvoltare: mediul în care lucreaza echipa ta. Aceasta este mediul de gestionare a versiunilor, conducta de construire și testare, și separarea între mediile de testare și de producție. Aici se pune problema cine are acces la codul sursă, cum sunt controlate modificările înainte de a deveni active și cum se revoaca accesul atunci când cineva pleacă din echipă. Ambele niveluri pot fi în același document, dar sunt adesea descrise separat deoarece riscurile și proprietarii acestora sunt diferiți.
De ce un client o solicită
Organizațiile care se supun singure obligației de diligență sunt obligate să evalueze riscurile la furnizorii lor. O companie de software care dezvoltă pentru o astfel de organizație primește deci întrebări care nu decurg din propria obligație, ci din lanț. O politică de securitate a informațiilor este atunci adesea primul document care este solicitat, deoarece arată într-un singur document cum a fost abordată structural securitatea. Dacă lipsește, va trebui să explicați acest lucru într-o listă de verificare pentru fiecare întrebare în parte, ceea ce consumă mai mult timp și pare mai puțin convingător decât un document existent.
Dacă organizația ta se supune obligației de diligență, lanțului sau niciunuia dintre acestea, nu este ușor de văzut într-o privire. în câteva întrebări vedeți unde se află organizația dvs. oferă o primă indicație în acest sens, cu o explicație a motivului.
Cum se raportează această politică la măsurile izolate
O politică de securitate a informațiilor nu stă singură. Ea descrie pe larg cum se ocupi de securitate, în timp ce măsurile izolate — controlul accesului, copiile de rezervă, înregistrarea incidentelor, evaluarea furnizorilor — sunt execuția concretă a acesteia. Cine scrie politica fără a avea implementate măsurile subiacente, are un document care nu corespunde practicii. Și invers, este și greu: măsuri izolate fără o politică omnibus par fragmentate pentru cine întreabă. prezintă o imagine de ansamblu a tuturor subiectelor pe situație arată cum aceste componente sunt legate între ele.
Ce lipsește adesea în practică
În multe dintre primele versiuni ale unei astfel de politici lipsește un proprietar clar pentru fiecare componentă: cine este responsabil pentru menținerea actualizată a politicii de acces, cine pentru politica de remediere. De asemenea, o dată de evaluare fixă lipsește frecvent, ceea ce duce la faptul că o politică de acum doi ani este încă prezentată ca fiind actuală, în timp ce lanțul de dezvoltare s-a schimbat între timp. Și un al treilea punct care adesea lipsește: o legătură explicită între politică și dovezile care demonstrează că aceasta este, de asemenea, pusă în aplicare, cum ar fi jurnalele drepturilor de acces sau o sinteză a remedierilor implementate.
Evaluați-vă propria situație
Exact care componente sunt așteptate depinde de rolul organizației dvs. în lanț și de ceea ce cere un anumit client. Acest articol descrie structura obișnuită, nu un șablon obligatoriu, și textul legii în sine nu prescrie o dispoziție fixă. Pentru o evaluare a situației dvs. specifice, un jurist sau autoritatea de reglementare competentă sunt entitățile desemnate; întrebările frecvente despre acest tip de documente oferă o sinteză suplimentară a ceea ce este adesea solicitat.
Doriți să vedeți cum se menține o astfel de politică, împreună cu măsurile și dovezile subiacente, într-un dosar în curs de desfășurare în loc de a fi un document separat? modul în care secria.eu structurează și menține informațiile o demonstrează. În caz contrar, începeți cu verificarea NIS2 gratuită sau răsfoiți baza de cunoștințe pentru a vedea care subiecte sunt relevante pentru organizația dvs.