Dezvoltarea Securizată de Cod – metoda cepei: 4 întrebări triplu stratificate

Dezvoltarea Securizată de Cod – metoda cepei: 4 întrebări triplu stratificate

34
Interpretare: partea de sus – etapele de testare și dezvoltare sigură de cod/ partea de jos – etapa de evaluare dinamică a codului

Din ce în ce mai des, în organizațiile mari, se vorbește despre Dezvoltare Securizată de Cod (Safe Code Development – SSC), mai precis despre instrumente automatizate de suport pentru programatori, care permit analizarea software-ului creat, identificarea vulnerabilităților (de tipul Owasp TOP10 sau SANS25) și rezolvarea lor înainte de lansarea oficială, determinând astfel realizarea unui software puternic și sigur.

Dar este oare această abordare mulţumitoare?

Există modalităţi diferite de efectuare a testelor de siguranţă a aplicaţiilor, toate bazate pe detectarea erorilor de

programare și implementarea logicii la nivel de aplicaţie, dar practica dezvoltării securizate de cod reprezintă întotdeauna cel mai delicat și „nesigur” strat al producţiei unei aplicaţii „impenetrabile”.

În experienţa mea cu audit-urile de securitate, de foarte multe ori am dat peste diverse proceduri de evaluare a impactului, impact care decurge din existenţa prea multor vulnerabilităţi nerezolvate din SSC dar, foarte des, nu există nicio urmă de astfel de vulnerabilităţi în rapoartele realizate cu instrumentele statice de scanare.

Dar, înainte de a vă spune mai multe, trebuie să ne punem următoarea întrebare: „Ce presupune scanarea statică a unui cod?” Dacă răspunsul vostru este „un instrument care îţi permite să identifici toate problemele de securitate ale unei aplicaţii, probleme care ar expune respectiva aplicaţie la riscuri”, sunteţi departe de adevăr.

De fapt, instrumentele statice de scanare (dar și cele dinamice, după cum voi arăta ulterior, în ciuda celor spuse de furnizorii acestor instrumente) permit detecţia, cu o marjă mică de eroare, a vulnerabilităţilor specifice codurilor de intrare și filtrare precum XSS și Injection.

Tabelul următor (Sursa: Owasp, plus câteva completări) identifică această problemă, iar voi puteţi trage propriile concluzii.

Dacă este analizat în amănunt acest TOP 10 al Owasp se observă că există vulnerabilităţi cu impact puternic care nu sunt identificate de instrumentele

Facile = Ușor; Medio = Mediu; Difficile = Dificil; Severo = Puternic; Comune = Obișnuit; Diffuso = Frecvent

automatizate iar aceste vulnerabilităţi apar la nivelul comportamentului aplicaţiei sau sunt erori de proiectare care nu pot fi detectate de instrumentele actuale.

Spre exemplu, vulnerabilităţile de tipul Broken Authentication și Broken Access Control sunt vectori formidabili de atac care pot duce la un impact puternic fără a lua în considerare codul de SQL Injection care este dificil de identificat, astfel se dovedește că scanarea statică este limitată deoarece:

  • nu identifică toate erorile de logică din aplicaţie, identificându-le doar pe cele din zonele critice de exploatare de tipul deficienţelor de la nivelul dezvoltării profilelor și a autorizărilor de acces la conţinut.
  • determină apariţia unor rezultate de tip fals – pozitiv (peste 50% dintre studii sunt de acest tip) dar și a unor rezultate fals – negative, acestea fiind mult mai riscante și incontrolabile, cum ar fi adevăratele vulnerabilităţile care sunt de multe ori confundate cu SQL injection.
  • calitatea scanărilor depinde de calitatea aparatelor de scanat dar și a mediului în care această scanare se realizează (de ex. dependenţele dintre librării sau dintre modulele aplicaţiei, arhitecturi din afara aplicaţiei sau atenţionări de scanare nerezolvate).

Dar adevăratul „om rău” nu lucrează în dezvoltare ci în producţie, și de cele mai multe ori este din China sau Rusia, așadar următoarea întrebare concludentă ar fi „…dacă se transferă funcţia de control în etapa de producţie și se utilizează instrumente dinamice, oare acest lucru ar duce la o siguranţă mai mare?”. Răspunsul la această întrebare este asemănător cu răspunsul la întrebarea care este diferenţa dintre un om și o mașină. Pe scurt, totuși scanarea de tip dinamic (spre ex cu instrumente de scanare web) este utilă (așa cum sunt și evaluările de vulnerabilitate) deoarece mută controlul mai aproape de activitatea ilegală. Și în acest caz trebuie avute în vedere o serie de limitări:

  • Instrumentele Web de scanat nu elimină prezenţa erorilor de aplicaţie din dezvoltarea programelor (așa cum se întâmplă și în cazul scanarilor statice), chiar dacă au o gamă mai mare de acoperire, tocmai pentru că sunt realizate la faţa locului.
  • Un scanner dinamic este foarte intruziv, deci este de preferat să se realizeze în faza de testare pentru a proteja exerciţiul, dar scanarea dinamică în etapa de testare conţine și posibile elemente de slăbiciune, cum ar fi mediile eterogene, diferite versiuni software, patch-uri diferite, medii de testare care nu sunt disponibile, etc…
  • Intruziunea la nivel de politică este direct proporţională cu vulnerabilităţile detectate. Este nevoie de experienţă pentru a ajunge la compromisul potrivit între cele două elemente.
  • Spre deosebire de politicile și tehnologiile definite, scanarea dinamică poate determina răspunsuri fals pozitive sau și mai riscantele răspunsuri fals negative.

Ajungem acum la cea de-a treia întrebare: „… poate totuși este de preferat ca toată activitatea de scanare să se realizeze în etapa de testare a aplicaţiei”. Aceasta poate fi soluţia, dar chiar și atunci trebuie avute în vedere următoarele aspecte:

  • Testarea web de tipul Application Penetration se desfășoară înainte de lansare, are în vedere toate riscurile existente la nivelul aplicaţiei și este minim invazivă deoarece se realizează de către un specialist iar eficacitatea sa este direct proporţională cu abilităţile personalului specializat.
  • În cazul aplicaţiilor complexe, testarea de tipul Application Penetration nu se poate realiza la toate nivelurile aplicaţiei, cum ar fi limitele de timp pentru managementul controlului (nu se realizează o testare de tip etic).
  • Testarea permite identificarea impactului real dar și a deficienţelor, spre deosebire de scanările statice/dinamice.
  • Pune la dispoziţie o imagine de ansamblu (în combinaţie cu un web scan) asupra gradului real de risc al aplicaţiei.
  • Are costuri mai ridicate decât activităţile automatizate obișnuite.

Iar cea de-a patra întrebare este: …„și atunci? … care este cea mai bună soluţie?”, răspunsul de obicei este „depinde” deoarece:

  1. Dezvoltarea Securizată de Cod se realizează în fabrică, scopul ei este scanarea statică obligatorie a celor mai simple breșe de securitate. De asemenea, utilizarea acestor scannere (menite să fie instrumente de dezvoltare de nivelul Eclipse sau VisualStudio) aduce v aloare indirectă prin introducerea „Conștientizării” la nivelul echipelor de dezvoltare, echipe care încă au multe lipsuri la capitolul dezvoltare securizată de software.
  2. Scanarea dinamică (la fel ca toate evaluările de vulnerabilitate) este utilă, are multe avantaje și identifică vulnerabilităţi reale dar trebuie să fii foarte atent la riscurile din etapa de producţie, la nivelul de intruziune al produselor de scanare utilizate dar și la politicile utilizate.
  3. Testarea de tip Application Penetration este soluţia ideală pentru a avea o imagine de ansamblu asupra riscurilor care apar în urma unui abuz în utilizarea unei aplicaţii și acoperă toate vulnerabilităţile din Owasp TOP10, dar un test de tip Application Penetration poate fi utilizat la nivelul unei aplicaţii complexe doar pentru a o testa.
Autor: Massimiliano Brolli

BIO

În prezent responsabil cu funcțiile de monitorizare a nivelelor de securitate și a activităților de Risk Assessment în cadrul TIM și al societăților sale, Massimiliano a avut funcții de conducere și în cadrul Telecom Italia precum și la TIIT (Telecom Italia Information Tecnology), cu experiență în activitați de governance și audit de securitate pentru platforme centralizate de gestiune. Anterior, el a lucrat în programare la IBM, 3inet, Praxi si BNL. Massimiliano predă des cursuri pe teme precum uml object oriented și structuri și limbaje de programare.