ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 127
Abonament PDF

Shift Left Security

Dragoș Cojocari
Principal Security Engineer @ Snyk



PROGRAMARE


A fost o vreme când în echipele de programatori exista rolul de "build meister", persoana responsabilă cu transformarea codului sursă în cod mașină. Acel rol a dispărut în mare măsură odată cu popularizarea noțiunii de devops și automatizarea procesului de build.

În echipele ce folosesc metode și instrumente moderne de programare, fiecare programator e așteptat să contribuie la implementarea și menținerea pipeline-urilor de CI/CD. Aceasta nu înseamnă că fiecare programator trebuie să fie expert în Github Actions/Circle CI/Argo CD etc. sau să aibă cunoștințe de cum se administrează acele aplicații. Ce se așteptă e ca fiecare programator să devină responsabil și direct implicat în întregul "Software Development Lifecycle (SDLC)".

Securitatea - cine e responsabil?

În mod similar, securitatea e văzută ca o «problemă» a echipei de testare sau a celei de IT/infrastructură. Echipa de dezvoltare livrează funcționalitatea, echipa de test identifică problemele inclusiv problemele de securitate care ulterior vor fi triate și testate ca orice alt defect.

Acest mod de abordare nu mai e posibil în ziua de azi, când aplicațiile sunt expuse unui mediu ostil (Internetul) din primul moment.

Securitatea e o problemă echipei de testare?

E mult prea târziu ca securitatea să fie abordată doar în faza de testare. O problemă găsită în această fază poate solicita rescrierea unui mare volum de cod. Aceasta duce la creșterea semnificativă a costurilor de dezvoltare și va întârzia proiectul.

De asemenea, soluțiile aplicate retroactiv sunt adesea ineficiente, incomplete sau limitează funcționalitatea aplicației.

Securitatea e o problemă a echipei de IT/Infrastructură?

O infrastructură securizată nu poate remedia vulnerabilitățile aplicației. Viceversa însă, o aplicație vulnerabilă devine un risc pentru întreaga infrastructură.

Securitatea e o problema a echipei securitate?

Nu toate companiile au echipe de securitate dedicate. Dar chiar și atunci când aceste echipe există, e imposibil pentru o singură echipă să înțeleagă în detaliu particularitățile tuturor aplicațiilor.

Shift Left Security / Secure by Design / DevSecOps

Soluția ce s-a impus în ultimii ani a fost schimbarea paradigmei în industria software. Similar cu modul în care testarea, compilarea și instalarea aplicațiilor s-au mutat înspre echipa de dezvoltare, aspectele legate de securitate s-au "mutat de asemenea la stânga" în procesul de dezvoltare.

Termenii folosiți variază, însă descriu aceeași idee: securitatea trebuie abordată devreme și trebuie să fie prezentă în fiecare etapă a ciclului de dezvoltare. Pe cale de consecință, programatorii ajung să preia o parte din responsabilitățile asociate în mod tradițional cu alte roluri.

Ce se întâmplă în fiecare ciclu?

Fiecare etapă din ciclul de dezvoltare e potrivită pentru o anume activitate ce vizează securitatea aplicației. Un singur aspect se justifică la nivelul fiecărei etape și activități: educarea întregii echipe, indiferent de rol, în probleme și tehnici de securitate.

Arhitectură - Threat Modelling

Din punctul meu de vedere, aceasta e una din cele mai importante activități, dacă nu cea mai importantă. Rolul acestei activități e de a determina care sunt punctele vulnerabile ale aplicației precum și soluțiile ce pot fi folosite.

Una din întrebările folosite pentru a prioritiza problemele identificate este: care e cel mai rău lucru care se poate întâmpla dacă riscul X se materializează?

Exemple de aspecte ce sunt luate în considerare:

Există diverse metodologii de Threat Modelling precum STRIDE (Microsoft), DREAD, Vast. De asemenea există aplicații ce le implementează precum OWASP Threat Dragon, IriusRisk, Threagile etc.

Un proces de Threat Modelling formalizat (metodologie + aplicație) va aduce cele mai bune rezultate. Dar simpla considerare a aspectelor de securitate în procesul de design reprezintă un pas imens.

Implementare - *AST

În faza de implementare există o serie de aspecte ce pot și trebuie să fie verificate. Obiectivul trebuie să fie rularea acestor teste automat în pipeline-urile de CI/CD. La fel de important e ca problemele identificate să fie automat convertite în acțiuni. Acțiunile rezultate pot fi crearea de tichete în JIRA, oprirea unui build, marcarea unui "pull request" ca eșuat etc.

Test Descriere
Static Application Security Testing Verificare statică a codului pentru
(SAST) identificarea unor "rele practici" ce
pot introduce vulnerabilități. Exemple:
"buffer overflows", SQL Injection,
deserializare nesigură de JSON/XML etc.
Aplicații: Snyk, Fortify, AppScan
Static, Semgrep, Sonar Qube.
Dependency Vulnerabilities Analizează modulele "open source"
folosite pentru a detecta
vulnerabilități cunoscute pentru
acestea. Exemple: log4j vulnerability
Unele aplicații scanează și licența
folosită pentru a evita/detecta
utilizarea de licențe restrictive (GPL).
Aplicații: Snyk, Node Security
Project.
Container Image Scanning Analizează fișierele Docker. Exemple:
imagini de bază cu vulnerabilități
cunoscute, lipsa specificării explicite
a userului cu care containerul rulează
etc. Aplicații: Snyk (also integrated
Docker-Hub), Docker Bench, AWS ECR.
Infrastructure as Code Testing Analizează elementele de infrastructură
exprimate în cod, precum Kubernetes
deployments/services yaml. Exemple:
execuția cu cont de administrator, lipsa
limitărilor de memorie, sistem de
fișiere ce nu e read-only etc.
Aplicații: Snyk.
Dynamic Application Testing (DAST) Scanează aplicațille ce au o interfață
web. Exemple: lipsa unor headere,
XRSS, SQL Injection, path traversal
sau probleme aparent benigne precum
informații despre infrastructură expuse
în răspuns etc. Aplicații: Zap, Blurp
Suite, HCL App Scan.
Interactive Application Testing (IAST) O specializare a DAST în care un agent
rulează în spațiul de memorie al
aplicației ceea ce permite identificarea
codului ce e responsabil pentru o
anumită problemă (ex: lipsa anumitor
headere).

O mențiune specială merită făcută detectării pierderii/furtului de secrete: parole, chei API, tokens etc. Detectarea timpurie a unui secret inclus accidental în codul sursă permite invalidarea rapidă a acestora, evitând astfel incidente de securitate costisitoare. Github oferă această opțiune dar sunt și alte aplicații ce permit același lucru, unele chiar înainte de a "comite" codul.

IT / Operations

Nu trebuie nicidecum înțeles că "shift left security" mută cu totul responsabilitatea pe umerii echipei de dezvoltare. Echipele de IT și cele de operations continuă să joace un rol esențial în asigurarea securității aplicațiilor software.

Aceste echipe sunt responsabile printre altele de întreținerea, monitorizarea și exploatarea infrastructurii și a aplicațiilor. Exemple de aplicații utilizate de aceste echipe:

Nu trebuie ignorată importanța separării rolurilor, aspect ce contribuie semnificativ la postura globală de securitate.

Concluzie

DevOps e un termen deja supraîncărcat, greșit utilizat sau de-a dreptul prost înțeles. ShiftLeft / DevSecOps nu trebuie să contribuie la această confuzie. În nici un caz nu înseamnă înlocuirea echipei de IT/operații sau a celei de securitate.

Ceea ce Shift Left urmărește este obținerea unei posturi de securitate îmbunătățită prin Detectarea problemelor de securitate în primele etape ale SLDC, acolo unde sunt cel mai ușor și eficient de rezolvat.

Deși pare contraintuitiv, integrând securitatea în SDLC putem evita irosirea de timp, resurse umane și financiare reparând problemele generate de un incident de securitate. Timpul și resursele economisite astfel pot fi folosite pentru a crea noi funcționalități.

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