TSM - Competență sau fraudă?

Cristian Șerban - Application Security

Î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