ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 141
Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 96
Abonament PDF

Maximizarea securității cu un eveniment Bug Bounty – călătoria noastră

Joao Morais
Security Testing Lead @ Paddy Power Betfair



PROGRAMARE


Călătoria noastră a început acum doi ani. Am schimbat foarte multe lucruri până am reușit să ajungem la nivelul pe care îl avem azi, cu ajutorul evenimentelor bug bounty (vânătoare de recompense cu buguri). În acest articol, dorim să împărtășim cunoștințele noastre despre programele bug bounty, dar și experiența noastră cu lansarea și menținerea unui astfel de program.

Să clarificăm mai întâi conceptul bug bounty. Bug bounty este un program ce se referă la identificarea responsabilă de vulnerabilități în schimbul recunoașterii sau a premiilor. Cercetătorii din domeniul securității pot raporta vulnerabilitățile pe care le-au găsit în cadrul evenimentului bug bounty din cadrul organizației pentru care lucrează, iar programul va recunoaște beneficiile colaborării. Astfel, cercetătorii pot face dovada colaborărilor lor pentru a le folosi ulterior în găsirea unui loc de muncă, de exemplu. Mai mult, în cele mai multe bug bounties există premii ce pot fi simbolice ( de exemplu, un tricou ) sau consistente (de exemplu, sume mari de bani,).

Când organizațiile nu organizează un eveniment bug bounty, cercetătorii din domeniul securității nu pot de multe ori să scoată la iveală vulnerabilitățile identificate de echipa de securitate a organizației. Deoarece echipele de suport nu au de obicei un proces definit pentru aceste situații, organizațiile rămân vulnerabile, iar cercetătorii sunt ignorați. În trecut, pentru a evita aceste situații, am avut o adresă de e-mail publicată pe website-ul nostru. Adresa a permis comunicarea directă între cercetătorii de securitate externi și echipa noastră de securitate, dar procesul a fost greu de gestionat și nu a atras cercetători cu experiență. Aceste probleme au fost reduse prin organizarea unui eveniment bug bounty despre care vă vom spune mai multe mai târziu.

La Paddy Power Betfair lucrăm de foarte mulți ani la securitatea produselor noastre. Momentan, avem o echipă de securitate care se ocupă de toate aspectele legate de securitate, fiind aproape autonomi, fără prea mult ajutor extern. Câteva exemple de domenii de securitate pentru care dezvoltăm aplicații sunt: securitatea aplicațiilor (Application Security), securitatea infrastructurii (Infrastructure Security), securitatea operațiunilor (Security Operations Center - SOC), gestiunea riscului (Risk Management) și conformitatea securității (Security Compliance), toate beneficiind de pe urma evenimentului bug bounty, așa cum vom arăta mai jos.

Echipa de securitate deservește modulul Software Development Life Cycle (SDLC), unde oferă expertiză echipei de dezvoltare, de la etapa de design la etapa de livrare către client. În faza inițială, se oferă suport echipelor de dezvoltare pentru a realiza designul și arhitectura noilor produse ținând cont de amenințările posibile, astfel încât aplicațiile noastre să fie robuste și sigure. Se folosesc și instrumente Static Application Security Testing (SAST), acestea stând la baza proceselor Continuous Integration și Continuous Delivery (CI/CD - integrare continuă - livrare continuă). În versiunea aproape finală a produsului, realizăm sesiuni de Penetration Testing (Pentesting) împreună cu echipele de dezvoltare și management de proiect. Când toate vulnerabilitățile identificate sunt îndepărtate și produsul este considerat sigur, acesta este livrat clienților și este evaluat zilnic cu instrumentele Dynamic Application Security Testing (DAST) pentru a ne asigura că își păstrează nivelul de securitate în timp. Pe măsură ce se identifică vulnerabilități noi în produse noi sau open source, trebuie să ne asigurăm că acestea nu afectează securitatea produselor noastre.

Deși aveam toate aceste nivele de securitate implementate, am dorit să maximizăm securitatea aplicațiilor și să fim cu un pas în fața atacatorilor. Astfel, am planificat un eveniment bug bounty pentru a ne evalua munca și a ne măsura eficiența, prin identificarea vulnerabilităților pe care le-am scăpat din vedere.

Trebuie luate o serie de decizii când planificăm un eveniment bug bounty. Trebuie să decidem ce platformă vom utiliza, dar aceasta ar trebui să aibă cel puțin următoarele caracteristici:

Am decis să colaborăm cu o firmă externă, HackerOne, ce oferă o platformă cu funcționalități multiple, inclusiv cerințele de mai sus.

Pentru a atrage cercetătorii, e de foarte mare ajutor să oferiți recompense în bani. Am ales această opțiune, ne-am alocat buget pentru platformă și pentru alte evenimente similare înainte de a lansa programul. De asemenea, timpul de răspuns al organizației este foarte important. Așadar, organizația trebuie să îmbunătățească permanent procesele interne referitoare la bug bounty - triajul, plata, explicarea vulnerabilităților celor responsabili și soluționarea vulnerabilităților. Toate aceste sarcini de lucru necesită mult timp, iar acest lucru trebuie transmis clar echipei de management.

Evenimentul bug bounty poate fi privat sau public. Acestea sunt identice, dar la un eveniment bug bounty privat, doar cei invitați pot participa. La un eveniment bug bounty public, oricine poate participa. Am început cu un eveniment bug bounty privat care a avut în jur de 20 de cercetători invitați. Platforma, pe care am utilizat-o, ne-a permis să restricționăm aceste invitații doar cercetătorilor care aveau o reputație bună. Dacă avem mulți cercetători ce lucrează activ la un program, acest lucru va duce la un număr mare de rapoarte. Acest aspect este de evitat pentru un program de abia lansat, deoarece echipele nu vor putea procesa rapoartele într-un interval de timp rezonabil.

Pentru a gestiona rapoartele, ne folosim de concepte precum program "gestionat" sau "auto-gestionat". Un program "gestionat" este un eveniment bug bounty, unde serviciul de triaj este oferit de un furnizor terț, iar organizația se ocupă doar de rapoartele triate anterior. Într-un program "auto-gestionat" toate rapoartele sunt triate de organizație. Am ales a doua variantă. Procesul de triaj determină dacă raportul este acceptat ca valid sau respins. De exemplu, rapoartele pot fi "invalide" dacă se referă la domenii neprevăzute de specificații (out-of-scope) sau pot fi "duplicate" dacă evidențiază o vulnerabilitate raportată de un alt cercetător.

Programele sunt mereu bazate pe politici care permit organizației să decidă toate regulile pe care vor să le urmeze cercetătorii. O componentă importantă este "orizontul/domeniul de aplicare" ("scope"). Am început cu un orizont îngust ce a inclus doar componentele noastre mature, astfel reducându-se numărul de aplicații eligibile pentru un eveniment bug bounty și, prin urmare, numărul de rapoarte primite.

Unele vulnerabilități au fost îndepărtate din program în faza inițială prin intermediul politicilor create (de exemplu, Denial of Service). Multe din aceste vulnerabilități excluse inițial sunt în continuare eliminate , dar vor deveni eligibile în evenimente viitoare. Politicile noastre sunt și foarte restrictive, pentru că folosim scanere și alte instrumente care afectează performanța aplicațiilor noastre.

Pe parcursul a doi ani, am crescut gradual numărul cercetătorilor, orizontul de aplicare și evenimentele cu recompensele aferente. Când am trecut la evenimente publice, aveam aproximativ 700 de cercetători invitați. Momentan, oricine poate consulta politicile noastre și să raporteze vulnerabilități în mod responsabil. Acum desfășurăm un program "gestionat", public, având în vedere că numărul rapoartelor va crește exponențial, ceea ce s-a dovedit o decizie bună. Acum colaborăm cu un număr nelimitat de cercetători cu abilități și experiență aparte.

Cea mai mare provocare a programului este să ne asigurăm că procesele interne decurg natural. Buna comunicare între echipa de securitate și echipele interne este obligatorie. Timpul necesar pentru triajul, plata și raportarea vulnerabilităților către echipa internă nu este greu de controlat, spre deosebire de timpul alocat rezolvării vulnerabilităților care este dificil de-l ținut sub control. Echipele de dezvoltare și infrastructură trebuie să planifice și să prioritizeze rezolvările în contextul restului sarcinilor de lucru pe care le au de efectuat. Dacă se identifică mai multe vulnerabilități pe o perioadă scurtă de timp, iar acestea sunt toate responsabilitatea aceleași echipe, identificarea unei soluții pentru toate, într-un interval de timp rezonabil, este o problemă greu de rezolvat.

Având în vedere așteptările inițiale ale programului, rezultatele au fost surprinzător de bune. Deși avem controale de securitate solide, evenimentul bug bounty a identificat vulnerabilitățile care nouă ne-au scăpat. Pe lângă această îmbunătățire, programul a ajutat și echipele de Application Security și Infrastructure Security să identifice golurile din cadrul controalelor lor de securitate. Echipa SOC a devenit mai puternică în ceea ce privește controalele implementate pentru a înlătura pericolele cele mai noi. După ce am integrat datele de pe platforma bug bounty în instrumentul nostru intern de monitorizare a vulnerabilităților, echipa de Risk Management a putut semnala vulnerabilitățile identificate de program către management. Mai mult, echipa de Security Compliance este de multe ori cu un pas înainte, atunci când vulnerabilitățile sunt identificate de auditul extern, din moment ce aceste vulnerabilități au fost deja identificate în trecut de evenimentul bug bounty și sunt în curs de rezolvare.

În concluzie, a fost o călătorie lungă cu rezultate deosebite. Organizarea unui eveniment bug bounty aduce un nivel de securitate suplimentar pe care dorim să îl păstrăm pe termen lung.

LANSAREA NUMĂRULUI 141

Analiza de business (BA)

miercuri, 27 martie, ora 18:00

sediul Accesa

Facebook Meetup StreamEvent YouTube

NUMĂRUL 140 - Generative AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO