ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 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 31
Abonament PDF

Competență sau fraudă?

Cristian Șerban
Application Security
@Betfair



PROGRAMARE

În urmă cu zece ani la universitatea unde eram student s-a organizat o miniconferință de securitate. Pentru a fi mai interesant, organizatorii au creat și o pagină de înregistrare care urma să fie deschisă pentru a accepta înscrieri începând cu ora 12 la o anumită dată. Mă pasiona domeniul și mi-am dorit să particip. Mi-am dorit să mă înscriu printre primii pentru a-mi asigura locul și mai ales că au promis că dau câte un tricou la primii 20 de participanți care se înscriu.

La vremea respectivă eu lucram ca programator angajat full time și deja adunasem ceva ore de lucru în tehnologia folosită pentru dezvoltarea paginii de înscrieri. Așa că nu mi-a luat mult timp să descopăr o vulnerabilitate și să reușesc să o exploatez în timp util. Am reușit să mă înscriu puțin mai înainte de ora oficială. În următoarea zi m-am prezentat la conferință la intrare, am salutat politicos, mi-am spus numele, colegul m-a cautat pe listă și m-a găsit destul de ușor. Am tras puțin cu ochiul: eram primul 11:58. Perfect.

Uimit puțin, acesta a zis: "Ah tu ești ăla, cum ai reușit?". La întrebarea mea dacă primesc un tricou, el a răspuns că nu, dar că o să primesc ceva mai bun. În timpul conferinței m-a anunțat public și mi-a înmânat drept premiu cartea "Writing Secure Code" a lui Michael Howard și David LeBlanc.

Puțin dezamăgit, m-am întrebat oare de ce îmi dă mie cartea aceasta. El avea nevoie mai mare de carte, el avea nevoie să învețe să scrie cod mai sigur nu eu.

Dacă deplasăm această întâmplare într-un cadru puțin mai critic cum ar fi de exemplu un site pe Internet unde clienții își pot crea cont și să își depoziteze banii în cont cu scopul de a-i folosi mai târziu, cartea și tricoul de mai devreme se transformă în alte lucruri mai de valoare. În loc de un tricou, atacatorul își dorește să obțină banii clientilor, și primește în loc de o carte, ani de închisoare.

De exemplu, un individ pe nume Alistair Peckover a fost condamnat prima dată la 26 de săptămâni cu suspendare, având doar 20 de ani în 2009, pentru că a furat 39.000 lire. În 2010 a fost condamnat din nou la 20 de luni cu execuție după ce și-a cumpărat un Porsche și un lingou de aur în valoare de 30.000 lire. În 2012 este din nou condamnat la 3 ani de închisoare după ce a furat 46.000 lire. Când a primit ultima sentință judecătorul i-a spus : "I believe that I will see you again in the future due to your gambling addiction and the temptation to use your computer skills to cheat, which will be hard to resist due to your character."

"Computer skills to cheat" mi-a atras atenția. Adică el ar fi un mare geniu sau un super meseriaș în ale calculatoarelor. Dar dacă ne uitam un pic mai atent la viața lui, vedem că locuia cu părinții lui și nu lucra nimic, nici cu școala nu era ocupat. Avea tot timpul din lume, 24 de ore pe zi, să studieze toate site-urile de jocuri și să găsească jocuri care au fost scrise de programatori care nu au citit cartea "Writing Secure Code". Găsea vulnerabilități în ele și le exploata pe bani adevărați. După multe încercări și experiență a devenit un expert în domeniu.

De ce se întâmplă lucrurile astea? Din mai multe motive. Ca să numesc două: pentru că oamenii sunt lacomi și vor să aibă mulți bani, dar și pentru că site-urile sunt scrise de către oameni și este în natura lor să facă greșeli.Vulnerabilitățile de securitate nu sunt altceva decât erori de programare. Programatorii nu au învățat în facultate foarte multe despre vulnerabilități de securitate. Nici product owner-ii nu le cunosc, așa că cer echipelor de dezvoltare să implementeze doar feature-urile dorite de business, cât se poate de repede. Dacă reușesc să livreze înainte de termen primesc bonus! Totuși, oricine poate învăța despre vulnerabilități de securitate dacă are ceva timp la dispoziție.

Noi cei care lucrăm în departamentul de Application Security studiem aceste fascinante vulnerabilități de securitate. Eu le numesc fascinante pentru că multă lume le vede ca fiind ceva magic, ceva ce doar geniile pot înțelege. Dar de fapt oricine le poate vedea și înțelege, este nevoie numai de timp și dedicare. Noi descoperim aceste vulnerabilități în codul scris de programatorii noștri, îi sfătuim cum să le fixeze și îi învățăm cum să le prevină data următoare.

Pentru a îndeplini acest job am implementat un proces pe care unii îl numesc Secure Software Development Lifecycle. În mare acesta constă în următorii pași:

Lucrăm împreună cu arhitecții și contribuim la designul unui nou produs, înainte ca acesta să intre în faza de implementare. În această fază definim toate controalele și standardele de securitate care trebuie implementate în funcție de funcționalitatea produsului și locul unde va fi folosit.

Stăm aproape de echipele de dezvoltare și avem vizibilitate asupra sprint-urilor astfel încât atunci când au de implementat un user story care atinge date sau funcționalitate sensibilă din punct de vedere al securității, programatorii se consultă cu noi și împreună stabilim cum se va implementa corect.

Când avem funcționalitatea implementată facem un test de securitate manual, prin care verificăm dacă nu cumva s-au strecurat ceva vulnerabilități. Astfel ne asigurăm că în producție nu vor fi probleme. Acest test de securitate implică code review, user story review și un penetration test pe toată funcționalitatea nou implementată în sprint-ul curent.

În biroul din România suntem două persoane pe Application Security și avem aproximativ 16 echipe de dezvoltare. Asta înseamnă o grămada de muncă. Așa că am cerut ajutor. Am cerut ajutorul programatorilor spunându-le: "voi vă cunoașteți cel mai bine codul, voi știți cel mai bine cum funcționează aplicația și voi știți fiecare linie de cod ce face pentru că voi ați scris-o." După care am continuat: "avem o propunere pentru voi, noi vă învățăm care sunt vulnerabilitățile posibile și cum să le evitați și voi ne ajutați cu îmbunătățirea securității în produsele la care lucrați. Așa că acum avem o echipă virtuală de "Security Champions" formată din câte cel puțin un programator din fiecare echipă plus reprezentați din celelalte echipe, cum ar fi QA, DevOps, IT. Ținem în mod regulat conferințe de securitate interne cu prezentări și _workshop-_uri și deseori invităm și oameni cu expertiză din afara firmei. Noi îi învățăm cum să fie "hackeri", cum să folosească diferite unelte de securitate cu care să-și testeze produsele, astfel încât să scrie cod care nu poate fi hackuit prea ușor.

Programul de Security Champions este eficient pentru că în acest mod cel puțin o persoană se gândește la aspectele de securitate din cadrul echipei.

Este o situație win-win pentru toată lumea, atât pentru campioni pentru că își dezvoltă _skil-_uri ninja cât și pentru companie și pentru echipa de security. Așa că acum noi putem pleca pe o insulă exotică și să stăm la plajă, pentru că programatorii noștri scriu cod sigur, iar hackerii nu pot fura bani. Câteodată mai primim un telefon de la HR care ne informează că încă un developer a trecut la management sau că au angajat alți cinci programatori proaspăt absolvenți de facultate în locul lui și că trebuie să ne întoarcem să îi învățăm să scrie cod sigur.

Referințe

  1. http://www.crawleynews.co.uk/Broadfield-hacker-jailed-46-000-fraud/story-17502872-detail/story.html
  2. http://www.amazon.co.uk/Writing-Secure-Code-Best-Practices/dp/0735617228/ref=sr_1_1?ie=UTF8&qid=1421158841&sr=8-1&keywords=writing+secure+code

LANSAREA NUMĂRULUI 148

Agile Craftsmanship

joi, 24 Octombrie, ora 18:30

Colors in Projects (București)

Facebook Meetup StreamEvent YouTube

Agile Leadership &
Ways of Working

miercuri, 30 Octombrie, ora 18:00

ING Hubs Romania (Cluj)

Facebook Meetup StreamEvent YouTube

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects