Partajați prin

Recomandări pentru testarea securității

Se aplică acestei recomandări privind lista de verificare a securității bine construite: Power Platform

SE:09 Stabiliți un regim de testare cuprinzător care combină abordări pentru prevenirea problemelor de securitate, validarea implementărilor de prevenire a amenințărilor și testarea mecanismelor de detectare a amenințărilor.

Testarea riguroasă este fundamentul unui design de securitate bun. Testarea este o formă tactică de validare pentru a ne asigura că controalele funcționează conform așteptărilor. Testarea este, de asemenea, o modalitate proactivă de a detecta vulnerabilitățile din sistem.

Stabiliți rigoarea testării prin cadență și verificare din perspective multiple. Ar trebui să includeți perspective din interior spre exterior care testează platforma și infrastructura și evaluări din exterior spre interior care testează sistemul ca un atacator extern.

Acest ghid oferă recomandări pentru testarea stării de securitate a volumului de lucru. Implementați aceste metode de testare pentru a îmbunătăți rezistența volumului de lucru la atacuri și pentru a menține confidențialitatea, integritatea și disponibilitatea resurselor.

Definiții

Termen Definiție
Testarea securității aplicațiilor (AST) O tehnică Microsoft Security Development Lifecycle (SDL) care utilizează metodologii de testare white-box și black-box pentru a verifica vulnerabilitățile de securitate din cod.
Testarea cutiei negre O metodologie de testare care validează comportamentul vizibil extern al aplicației fără a cunoaște componentele interne ale sistemului.
Echipa albastră O echipă care se apără împotriva atacurilor echipei roșii într-un exercițiu de război.
Testarea penetrării O metodologie de testare care folosește tehnici de hacking etic pentru a valida apărarea de securitate a unui sistem.
Echipa roșie O echipă care joacă rolul unui adversar și încearcă să pirateze sistemul într-un exercițiu de război.
Ciclul de viață al dezvoltării securității (SDL) Un set de practici furnizate de Microsoft care acceptă cerințele de asigurare a securității și conformitate.
Ciclul de viață al dezvoltării software (SDLC) Un proces sistematic, în mai multe etape, pentru dezvoltarea sistemelor software.
Testarea în cutie albă O metodologie de testare în care structura codului este cunoscută practicianului.

Strategii cheie de design

Testarea este o strategie non-negociabilă, în special pentru securitate. Vă permite să descoperiți și să remediați în mod proactiv problemele de securitate înainte ca acestea să poată fi exploatate și să verificați dacă controalele de securitate pe care le-ați implementat funcționează conform proiectării.

Domeniul de aplicare al testării trebuie să includă aplicația, infrastructura și procesele automatizate și umane.

Notă

Aceste îndrumări fac o distincție între testare și răspunsul la incidente. Deși testarea este un mecanism de detectare care, în mod ideal, remediază problemele înainte de producție, aceasta nu trebuie confundată cu remedierea sau investigarea efectuată ca parte a răspunsului la incidente. Aspectul recuperării după incidente de securitate este descris în *Recomandări pentru răspunsul la incidente de securitate*. ...

Fii implicat în planificarea testelor. Este posibil ca echipa responsabilă cu sarcina de lucru să nu proiecteze cazurile de testare. Această sarcină este adesea centralizată în cadrul întreprinderii sau îndeplinită de experți externi în securitate. Echipa responsabilă cu sarcina de lucru ar trebui să fie implicată în procesul de proiectare pentru a se asigura că asigurările de securitate se integrează cu funcționalitatea aplicației.

Gândește ca un atacator. Proiectați-vă cazurile de testare pornind de la presupunerea că sistemul a fost atacat. În acest fel, puteți descoperi potențialele vulnerabilități și puteți prioritiza testele în consecință.

Executați testele într-o manieră structurată și cu un proces repetabil. Construiește-ți rigoarea testării în jurul cadenței, tipurilor de teste, factorilor determinanți și rezultatelor scontate.

Folosește unealta potrivită pentru lucrare. Folosește instrumente configurate să funcționeze cu volumul de lucru. Dacă nu ai o unealtă, cumpără-o. Nu-l construi. Instrumentele de securitate sunt extrem de specializate, iar construirea propriului instrument ar putea introduce riscuri. Profitați de expertiza și instrumentele oferite de echipele centrale SecOps sau prin mijloace externe, dacă echipa responsabilă de volumul de lucru nu are această expertiză.

Configurați medii separate. Testele pot fi clasificate ca distructive sau nedistructive. Testele nedistructive nu sunt invazive. Acestea indică o problemă, dar nu modifică funcționalitatea pentru a remedia problema. Testele distructive sunt invazive și pot deteriora funcționalitatea prin ștergerea datelor dintr-o bază de date.

Testarea în mediile de producție vă oferă cele mai bune informații, dar cauzează cele mai mari perturbări. Ai tendința de a face doar teste nedistructive în medii de producție. Testarea în medii non-productive este de obicei mai puțin perturbatoare, dar este posibil să nu reprezinte cu acuratețe configurația mediului de producție în moduri importante pentru securitate.

Puteți crea o clonă izolată a mediului dvs. de producție utilizând funcția de copiere a mediului. Dacă ați configurat canale de implementare, puteți implementa soluțiile și într-un mediu de testare dedicat.

Evaluați întotdeauna rezultatele testelor. Testarea este un efort irosit dacă rezultatele nu sunt folosite pentru a prioritiza acțiunile și a face îmbunătățiri în amonte. Documentați instrucțiunile de securitate, inclusiv cele mai bune practici, pe care le descoperiți. Documentația care surprinde rezultatele și planurile de remediere informează echipa despre diversele modalități prin care atacatorii ar putea încerca să încalce securitatea. Organizați periodic instruire în domeniul securității pentru dezvoltatori, administratori și testeri.

Când vă proiectați planurile de testare, gândiți-vă la următoarele întrebări:

  • Cât de des vă așteptați să ruleze testul și cum vă afectează mediul?
  • Care sunt diferitele tipuri de teste pe care ar trebui să le rulați?

Cât de des vă așteptați să se execute testele?

Testați volumul de lucru în mod regulat pentru a vă asigura că modificările nu introduc riscuri de securitate și că nu există regresii. Echipa trebuie, de asemenea, să fie pregătită să răspundă la validările de securitate organizațională care ar putea fi efectuate în orice moment. Există, de asemenea, teste pe care le puteți executa ca răspuns la un incident de securitate. Următoarele secțiuni oferă recomandări privind frecvența testelor.

Teste de rutină

Testele de rutină sunt efectuate la o frecvență regulată, ca parte a procedurilor dumneavoastră operaționale standard și pentru a îndeplini cerințele de conformitate. Diverse teste pot fi efectuate la ritmuri diferite, dar esențial este ca acestea să fie efectuate periodic și conform unui program.

Ar trebui să integrați aceste teste în SDLC-ul dvs., deoarece oferă o apărare în profunzime în fiecare etapă. Diversificați suita de teste pentru a verifica asigurările privind identitatea, stocarea și transmiterea datelor și canalele de comunicare. Efectuați aceleași teste în diferite puncte ale ciclului de viață pentru a vă asigura că nu există regresii. Testele de rutină ajută la stabilirea unui punct de referință inițial. Totuși, acesta este doar un punct de plecare. Pe măsură ce descoperiți probleme noi în aceleași puncte ale ciclului de viață, adăugați noi cazuri de testare. Testele se îmbunătățesc și odată cu repetarea.

În fiecare etapă, aceste teste ar trebui să valideze codul adăugat sau eliminat sau setările de configurare modificate pentru a detecta impactul asupra securității al acestor modificări. Ar trebui să îmbunătățești eficacitatea testelor prin automatizare, echilibrată cu evaluări inter pares.

Luați în considerare executarea testelor de securitate ca parte a unei conducte automate sau a unei rulări programate de testare. Cu cât descoperiți mai repede problemele de securitate, cu atât este mai ușor să găsiți codul sau modificarea de configurație care le cauzează.

Nu te baza doar pe teste automate. Folosește testarea manuală pentru a detecta vulnerabilități pe care doar expertiza umană le poate detecta. Testarea manuală este bună pentru cazurile de utilizare exploratorii și pentru identificarea riscurilor necunoscute.

Teste improvizate

Testele improvizate oferă validare la un moment dat a apărării de securitate. Alertele de securitate care ar putea afecta volumul de lucru la momentul respectiv declanșează aceste teste. Mandatele organizaționale ar putea necesita o mentalitate de tip „pauză și testare” pentru a verifica eficacitatea strategiilor de apărare dacă alerta se transformă într-o urgență.

Avantajul testelor improvizate este pregătirea pentru un incident real. Aceste teste pot fi o funcție de forțare pentru a efectua teste de acceptare a utilizatorilor (UAT).

Echipa de securitate ar putea audita toate sarcinile de lucru și rula aceste teste după cum este necesar. Ca proprietar al unui volum de lucru, trebuie să facilitezi și să colaborezi cu echipele de securitate. Negociază suficient timp cu echipele de securitate pentru a te putea pregăti. Recunoașteți și comunicați echipei și părților interesate că aceste perturbări sunt necesare.

În alte cazuri, este posibil să vi se solicite să executați teste și să raportați starea de securitate a sistemului în raport cu potențiala amenințare.

Compromis Deoarece testele improvizate sunt evenimente perturbatoare, așteptați-vă la reprioritizarea sarcinilor, ceea ce poate întârzia alte activități planificate.

Risc: Există riscul necunoscutului. Testele improvizate ar putea fi eforturi singulare, fără procese sau instrumente stabilite. Însă riscul predominant este potențiala întrerupere a ritmului afacerilor. Trebuie să evaluezi aceste riscuri în raport cu beneficiile.

Teste de incidente de securitate

Există teste care detectează cauza unui incident de securitate la sursă. Aceste lacune de securitate trebuie rezolvate pentru a ne asigura că incidentul nu se va repeta.

Incidentele îmbunătățesc, de asemenea, cazurile de testare în timp, prin descoperirea lacunelor existente. Echipa ar trebui să aplice lecțiile învățate din incident și să includă în mod curent îmbunătățiri.

Care sunt diferitele tipuri de teste?

Testele pot fi clasificate după tehnologie și după metodologii de testare. Combinați aceste categorii și abordări din cadrul acelor categorii pentru a obține o acoperire completă.

Prin adăugarea mai multor teste și tipuri de teste, puteți descoperi:

  • Lacune în controalele de securitate sau în controalele compensatorii.
  • Configurații greșite.
  • Lacune în metodele de observabilitate și detectare.

Un exercițiu bun de modelare a amenințărilor poate indica domenii cheie pentru a asigura acoperirea și frecvența testelor. Pentru recomandări privind modelarea amenințărilor, consultați *Recomandări pentru securizarea unui ciclu de dezvoltare* .

Majoritatea testelor descrise în aceste secțiuni pot fi efectuate ca teste de rutină. Cu toate acestea, repetabilitatea poate genera costuri în unele cazuri și poate cauza perturbări. Luați în considerare cu atenție aceste compromisuri.

Teste care validează stiva tehnologică

Iată câteva exemple de tipuri de teste și domeniile lor de interes. Această listă nu este exhaustivă. Testați întregul stack, inclusiv stiva de aplicații, front-end-ul, back-end-ul, API-urile, bazele de date și orice integrări externe.

  • Securitatea datelor: Testați eficacitatea criptării datelor și a controalelor de acces pentru a vă asigura că datele sunt protejate corespunzător împotriva accesului neautorizat și a manipulării.
  • Rețea și conectivitate: Testați firewall-urile pentru a vă asigura că permit doar traficul așteptat, permis și sigur către sarcina de lucru.
  • Aplicație: Testați codul sursă prin tehnici de testare a securității aplicațiilor (AST) pentru a vă asigura că respectați practicile de codare securizate și pentru a detecta erorile de execuție, cum ar fi coruperea memoriei și problemele de privilegii.
  • Identitate: Evaluați dacă atribuirile de roluri și verificările condiționale funcționează conform așteptărilor.

Metodologia de testare

Există multe perspective asupra metodologiilor de testare. Recomandăm teste care permit identificarea amenințărilor prin simularea atacurilor din lumea reală. Aceștia pot identifica potențialii actori amenințători, tehnicile lor și exploatările lor care reprezintă o amenințare la adresa volumului de lucru. Faceți atacurile cât mai realiste posibil. Folosește toți vectorii de amenințare potențiali pe care îi identifici în timpul modelării amenințărilor.

Iată câteva avantaje ale testării prin atacuri din lumea reală:

  • Când incluzi aceste atacuri în testele de rutină, folosești o perspectivă din exterior spre interior pentru a verifica volumul de muncă și a te asigura că apărarea poate rezista unui atac.
  • Pe baza lecțiilor învățate, echipa își îmbunătățește cunoștințele și nivelul de abilități. Echipa își îmbunătățește conștientizarea situației și își poate autoevalua gradul de pregătire de a răspunde la incidente.

Risc: Testarea în general poate afecta performanța. Pot exista probleme de continuitate a afacerii dacă testele distructive șterg sau corupesc datele. Există, de asemenea, riscuri asociate cu expunerea informațiilor; asigurați-vă că mențineți confidențialitatea datelor. Asigurați integritatea datelor după finalizarea testării.

Câteva exemple de teste simulate includ testarea black-box și white-box, testarea de penetrare și exercițiile de jocuri de război.

Testarea în cutie neagră și în cutie albă

Aceste tipuri de teste oferă două perspective diferite. În testele de tip cutie neagră, componentele interne ale sistemului nu sunt vizibile. În testele white-box, testerul are o bună înțelegere a aplicației și are chiar acces la cod, jurnale, topologia resurselor și configurații pentru efectuarea experimentului.

Risc: Diferența dintre cele două tipuri constă în costul în avans. Testarea în cutie albă poate fi costisitoare din punct de vedere al timpului necesar pentru a înțelege sistemul. În unele cazuri, testarea în cutie albă necesită achiziționarea de instrumente specializate. Testarea de tip „cutie neagră” nu necesită timp de inițiere, dar s-ar putea să nu fie la fel de eficientă. S-ar putea să fie nevoie să depui eforturi suplimentare pentru a descoperi problemele. Este un compromis de investiție de timp.

Teste care simulează atacuri prin testare de penetrare

Experții în securitate care nu fac parte din echipele IT sau de aplicații ale organizației efectuează teste de penetrare sau *pentesting*. Ei privesc sistemul în modul în care actorii rău intenționați explorează o suprafață de atac. Scopul lor este de a găsi lacune de securitate prin colectarea de informații, analizarea vulnerabilităților și raportarea rezultatelor.

Compromis: Testele de penetrare sunt improvizate și pot fi costisitoare în ceea ce privește întreruperile și investițiile financiare, deoarece pentesting-ul este de obicei o ofertă plătită de către practicieni terți.

Risc: Un exercițiu de pentesting ar putea afecta mediul de execuție și ar putea perturba disponibilitatea pentru traficul normal.

Practicienii ar putea avea nevoie de acces la date sensibile din întreaga organizație. Respectați regulile de interacțiune pentru a vă asigura că accesul nu este utilizat în mod abuziv. Vedeți resursele enumerate în Informații conexe.

Teste care simulează atacuri prin exerciții de tip joc de război

În această metodologie de atacuri simulate, există două echipe:

  • Cel/Cea/Cei/Cele roşu Echipa este adversarul care încearcă să modeleze atacuri din lumea reală. Dacă au succes, găsiți lacune în designul de securitate și evaluați raza de explozie care poate limita breșele lor.
  • Cel/Cea/Cei/Cele albastru Echipa este echipa care responsabilă cu sarcina de lucru și se apără împotriva atacurilor. Își testează capacitatea de a detecta, de a răspunde și de a remedia atacurile. Acestea validează apărările implementate pentru a proteja resursele volumului de lucru.

Dacă sunt efectuate ca teste de rutină, exercițiile de război pot oferi vizibilitate continuă și asigurarea că apărarea dumneavoastră funcționează conform proiectării. Exercițiile de tip jocuri de război pot testa potențial mai multe niveluri din cadrul sarcinilor de lucru.

O opțiune populară pentru simularea scenariilor de atac realiste este Microsoft Defender pentru Office 365 Antrenament de simulare a atacurilor.

Pentru mai multe informații, consultați Informații și rapoarte pentru antrenamentul de simulare a atacurilor.

Pentru informații despre configurarea echipelor roșii și albastre, consultați Microsoft Cloud Red Teaming.

Power Platform facilitare

Soluția Microsoft Sentinel pentru Microsoft Power Platform permite clienților să detecteze diverse activități suspecte, cum ar fi:

  • Power Apps execuție din zone geografice neautorizate
  • Distrugere suspectă a datelor de către Power Apps
  • Ștergerea în masă a Power Apps
  • Atacuri de phishing efectuate prin Power Apps
  • Power Automate fluxuri de activitate ale angajaților care pleacă
  • Microsoft Power Platform conectori adăugați la un mediu
  • Actualizarea sau eliminarea politicilor de prevenire a pierderii de date Microsoft Power Platform

Pentru mai multe informații, consultați soluția Microsoft Sentinel pentru Microsoft Power Platform prezentare generală.

Pentru documentația produsului, consultați Capacitățile de vânătoare în Microsoft Sentinel.

Microsoft Defender for Cloud oferă scanare a vulnerabilităților pentru diverse domenii tehnologice. Pentru mai multe informații, consultați Activarea scanării vulnerabilităților cu Microsoft Defender Vulnerability Management.

Practica DevSecOps integrează testarea securității ca parte a unei mentalități de îmbunătățire continuă și continuă. Exercițiile de tip „jocuri de război” sunt o practică obișnuită integrată în ritmul afacerii la Microsoft. Pentru mai multe informații, consultați Securitatea în DevOps (DevSecOps).

Azure DevOps acceptă instrumente terțe care pot fi automatizate ca parte a canalelor de integrare continuă/implementare continuă (CI/CD). Pentru mai multe informații, consultați Activarea DevSecOps cu Azure și GitHub.

Cele mai recente teste de penetrare și evaluări de securitate pot fi găsite pe Microsoft Service Trust Portal.

Microsoft efectuează teste ample ale serviciilor Microsoft Cloud. Această testare include teste de penetrare, iar rezultatele vor fi publicate pe Portalul de Încredere în Servicii pentru organizația dumneavoastră. Organizația dumneavoastră poate efectua propriul test de penetrare asupra serviciilor Microsoft Power Platform și Microsoft Dynamics 365. Toate testele de penetrare trebuie să respecte *Regulile de angajament pentru testarea de penetrare în cloud Microsoft*. ... Este important să rețineți că, în multe cazuri, Microsoft Cloud utilizează infrastructură partajată pentru a găzdui activele dvs. și activele aparținând altor clienți. Trebuie să limitați toate testele de penetrare la activele dvs. și să evitați consecințele nedorite pentru alți clienți din jurul dvs.

Respectați regulile de interacțiune pentru a vă asigura că accesul nu este utilizat în mod abuziv. Pentru îndrumări privind planificarea și executarea atacurilor simulate, consultați:

Puteți simula atacuri de tip denial of service (DoS) în Azure. Asigurați-vă că respectați politicile stabilite în testarea simulării Azure DDoS Protection.

Listă de verificare a securității

Consultați setul complet de recomandări.

Listă de verificare a securității