AGIL ȘI SIGUR

FOLOSIREA ȘABLOANELOR (PATTERNS) PENTRU A SECURIZA PROGRAMELE

DEZVOLTATE PRIN METODOLOGIE AGILE
 PRINCIPII COMUNE TUTUROR METODOLOGIILOR AGILE
(SCRUM, XTREME PROGRAMING, KANBAN, LEAN.
CRYSTAL, etc)
• Dezvoltare iterativă:
• codul se rafinează în iterații succesive („nu e niciodată gata dar e întotdeauna funcțional”);
• funcționalitățile suplimentare se adaugă în timpul iterațiilor, nu de la început (YAGNI = „You Ain’t Gonna Need It”, adică la
fiecare iterație codul oferă un număr minim de funcționalități, restul „nu sunt necesare” în etapa respectivă);

• Fiecare funcționalitate are la bază o „poveste a utilizatorului” („user story”):

• o user story descrie o nevoie elementară pe care softul trebuie să o satisfacă;
• specificațiile se obțin în timp, prin acumularea de user stories, în loc să fie obținute toate de la început;
• „Dezvoltare prin testare” (test-driven development):
• întâi se scrie codul prin care se testează funcționalitatea apoi se scrie codul care implementează funcționalitatea;
• codul nou-scris trebuie să treacă toate testele automate anterioare, nu doar cel scris explicit pentru acea etapă;
• „Integrare continuă” („continuous integration”):
• codul nou-scris, odată ce a trecut toate testele automate, este compilat împreună cu restul proiectului, obținându-se o versiune
complet funcțională (chiar dacă setul de funcționalități este redus la început);
• odată ce un număr suficient de funcționalități au fost integrate, softul „intră în producție’, adică e folosit de client în activitatea
zilnică, chiar dacă dezvoltarea lui continuă.
CARE E PROBLEMA CU METODOLOGIILE AGILE, DIN
PUNCT DE VEDERE AL SECURITĂȚII?
INCIDENTELE DE SECURITATE APAR FOARTE RAR ÎN
„USER STORIES” (MAI DEGRABĂ DELOC)
 PRIORITĂȚILE UZUALE ALE SPECIALIȘTILOR ÎN
SECURITATE
1. Autentificarea utilizatorului („Cum știm cine folosește softul?”);
2. Autorizare utilizatorului („La ce funcționalități are acces utilizatorul autentificat?”);
3. Integritatea datelor („Cum ne asigurăm că datele corecte rămân corecte?”);
4. Confidențialitatea datelor („Cum ne asigurăm că datele sunt citite doar de
utilizatorii autentificați și care au dreptul să le citească?”);
5. Jurnalizarea funcționării software-ului („Cum ne asigurăm că se memorează modul
în care a fost utilizat software-ul și de către cine?”)*

* Sistemul de jurnalizare trebuie să satisfacă aceleași cerințe

 AGIL ȘI SIGUR, ETAPA 1

1. Se creează user stories pentru a răspunde cerințelor uzuale de securitate, care se

adaugă la user stories ale clientului;
2. Se aplică metodologia favorită de dezvoltare agilă.

Problema este că există două rezultate teoretice (teorema de

incompletitudine a lui Goedel și reformularea lui Turing,
cunoscută ca problema opririi/halting problem), care arată
imposibilitatea creării unui set complet de teste care să valideze
corectitudinea unui program!!!
CE E DE FĂCUT?
 AGIL ȘI SIGUR, ETAPA 2

• Folosirea șabloanelor („patterns”) de programare sigură:

• Șabloanele sunt structuri de cod demonstrate ca fiind sigure (Goedel/Turning se referă la
imposibilitatea existenței unei baterii exhaustive de teste valabile pentru orice program,
dar bucăți de cod specifice pot fi testate exhaustiv);
• Setul de șabloane trebuie reîmprospătat pentru că în timp se descoperă șabloane care
previn atacuri noi (fapt care e în acord cu Goedel/Turning pentru că imposibilitatea unui
set finit de teste exhaustive permite existența unei infinități de teste specifice, care să
verifice structuri de cod specifice).
EXEMPLU: DISTRUSTFUL DECOMPOSITION

1. Scopuri urmărite:
1. Reducerea „suprafeței de atac” (adică a elementelor care pot fi atacate);
2. Limitarea consecințelor unui atac reușit la o porțiune minimală din întregul sistem.

2. Implementare:
1. Fiecare funcționalitate este un program/proces distinct, cu propria schemă de autentificare și autorizare;
2. Programele/procesele comunică între ele prin mecanisme verificate de comunicare inter-proces (oferite de sistemul de
operare, API-uri, API-uri web, etc)

Observații:
1. Este un pattern arhitectural, prin urmare poate fi implementat în orice limbaj de programare și pentru orice
sistem de operare;
2. Poate fi combinat cu un alt pattern arhitectural (Single Sign-On), pentru a nu obliga utilizatorul să se
autentifice explicit pentru fiecare proces/program
CE FACEM DACĂ VREM SĂ ȘTIM MAI MULT DESPRE
SECURE DESIGN PATTERNS?
1. Căutăm „secure design patterns” cu motorul de căutare favorit;
2. Citim mai multe articole dintre cele propuse de motorul de căutare;
3. Implementăm patternul în limbajul favorit, pentru a vedea cum funcționează
lucrurile în realitate.