Com a part de les seves activitats professionals, els desenvolupadors, els pentesters i els especialistes en seguretat han de fer front a processos com ara la gestió de vulnerabilitats (VM), SDLC (segur).
Sota aquestes frases hi ha diferents conjunts de pràctiques i eines utilitzades que s'entrellacen, encara que els seus usuaris difereixen.
El progrés tècnic encara no ha arribat al punt en què una eina pugui substituir una persona per analitzar la seguretat de la infraestructura i el programari.
És interessant entendre per què això és així i quins problemes s'enfronta.
Процессы
El procés de gestió de vulnerabilitats està dissenyat per a un seguiment continu de la seguretat de la infraestructura i la gestió de pedaços.
El procés Secure SDLC ("cicle de desenvolupament segur") està dissenyat per mantenir la seguretat de l'aplicació durant el desenvolupament i el funcionament.
Una part similar d'aquests processos és el procés d'avaluació de vulnerabilitats: avaluació de vulnerabilitats, exploració de vulnerabilitats.
La principal diferència entre l'exploració de VM i SDLC és que en el primer cas l'objectiu és detectar vulnerabilitats conegudes en programari o configuració de tercers. Per exemple, una versió obsoleta de Windows o la cadena de comunitat predeterminada per a SNMP.
En el segon cas, l'objectiu és detectar vulnerabilitats no només en components de tercers (dependències), sinó principalment en el codi del nou producte.
Això crea diferències en eines i enfocaments. En la meva opinió, la tasca de trobar noves vulnerabilitats en una aplicació és molt més interessant, ja que no es redueix a les versions de les empremtes digitals, la recollida de banners, el forçament brut de contrasenyes, etc.
Per a l'escaneig automatitzat d'alta qualitat de les vulnerabilitats de les aplicacions, calen algorismes que tinguin en compte la semàntica de l'aplicació, el seu propòsit i amenaces específiques.
Sovint, un escàner d'infraestructura es pot substituir per un temporitzador, tal com vaig dir . La qüestió és que, purament estadísticament, podeu considerar la vostra infraestructura vulnerable si no l'heu actualitzada, per exemple, durant un mes.
Instruments
L'escaneig, com l'anàlisi de seguretat, es pot realitzar mitjançant una caixa negra o una caixa blanca.
requadre negre
En escanejar la caixa negra, l'eina ha de poder treballar amb el servei a través de les mateixes interfícies a través de les quals els usuaris hi treballen.
Els escàners d'infraestructura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) cerquen ports de xarxa oberts, recullen "bàners", determinen versions del programari instal·lat i cerquen la seva base de coneixement per obtenir informació sobre vulnerabilitats en aquestes versions. També intenten detectar errors de configuració com contrasenyes predeterminades o accés a dades obertes, xifratge SSL feble, etc.
Els escàners d'aplicacions web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) també poden identificar components coneguts i les seves versions (per exemple, CMS, frameworks, biblioteques JS). Els passos principals de l'escàner són el rastreig i el fuzz.
Durant el rastreig, l'escàner recopila informació sobre les interfícies d'aplicació existents i els paràmetres HTTP. Durant el fuzzing, les dades mutades o generades s'insereixen a tots els paràmetres detectats per provocar un error i detectar una vulnerabilitat.
Aquests escàners d'aplicacions pertanyen a les classes DAST i IAST: proves de seguretat d'aplicacions dinàmiques i interactives, respectivament.
Caixa blanca
Hi ha més diferències amb l'escaneig de caixa blanca.
Com a part del procés de VM, els escàners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) sovint tenen accés als sistemes mitjançant la realització d'una exploració autenticada. Així, l'escàner pot descarregar les versions dels paquets instal·lats i els paràmetres de configuració directament des del sistema, sense endevinar-los dels banners del servei de xarxa.
L'escaneig és més precís i complet.
Si parlem d'escaneig de caixa blanca (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) d'aplicacions, normalment estem parlant d'anàlisi de codi estàtic i l'ús d'eines adequades de la classe SAST - Prova de seguretat d'aplicacions estàtiques.
Problemes
Hi ha molts problemes amb l'escaneig! He de tractar amb la majoria d'ells personalment com a part de la prestació d'un servei per a la creació de processos d'escaneig i desenvolupament segur, així com a l'hora de realitzar treballs d'anàlisi de seguretat.
Destacaré 3 grups principals de problemes, que es confirmen amb converses amb enginyers i caps de serveis de seguretat de la informació en diverses empreses.
Problemes d'escaneig d'aplicacions web
- Dificultat d'implementació. Els escàners s'han de desplegar, configurar, personalitzar per a cada aplicació, assignar un entorn de prova per a les exploracions i implementar-los en el procés CI/CD perquè això sigui efectiu. En cas contrari, serà un procediment formal inútil que només produirà falsos positius
- Durada de l'escaneig. Fins i tot el 2019, els escàners fan una mala feina de deduplicar les interfícies i poden passar dies escanejant mil pàgines amb 10 paràmetres a cadascuna, considerant-les diferents, encara que el mateix codi n'és el responsable. Al mateix temps, la decisió sobre el desplegament a producció dins del cicle de desenvolupament s'ha de prendre ràpidament
- Pobres recomanacions. Els escàners donen recomanacions força generals i el desenvolupador no sempre pot entendre ràpidament com reduir el nivell de risc i, el més important, si cal fer-ho ara mateix o encara no fa por.
- Impacte destructiu en l'aplicació. Els escàners poden dur a terme un atac DoS a una aplicació i també poden crear un gran nombre d'entitats o canviar-ne les existents (per exemple, crear desenes de milers de comentaris en un bloc), de manera que no hauríeu de llançar sense pensar una exploració en producció.
- Baixa qualitat de la detecció de vulnerabilitats. Els escàners solen utilitzar una sèrie fixa de càrregues útils i poden perdre fàcilment una vulnerabilitat que no encaixa en l'escenari de comportament conegut de l'aplicació.
- L'escàner no entén les funcions de l'aplicació. Els mateixos escàners no saben què són la "banca per Internet", el "pagament", el "comentari". Per a ells, només hi ha enllaços i paràmetres, de manera que una gran capa de possibles vulnerabilitats de la lògica empresarial queda completament descoberta; no se'ls pensarà en fer una doble cancel·lació, espiar les dades d'una altra persona per ID o augmentar el saldo mitjançant l'arrodoniment.
- L'escàner no entén la semàntica de les pàgines. Els escàners no poden llegir les preguntes freqüents, no poden reconèixer captchas i per si mateixos no esbrinaran com registrar-se i tornar a iniciar la sessió, que no podeu fer clic a "tancar sessió" i com signar sol·licituds quan canvieu el paràmetre valors. Com a resultat, és possible que la major part de l'aplicació no s'escanegeixi en absolut.
Problemes en escanejar el codi font
- Falsos positius. L'anàlisi estàtica és una tasca complexa que implica moltes compensacions. Sovint s'ha de sacrificar la precisió, i fins i tot els escàners empresarials cars produeixen un gran nombre de falsos positius
- Dificultat d'implementació. Per augmentar la precisió i la integritat de l'anàlisi estàtica, cal perfeccionar les regles d'escaneig, i escriure aquestes regles pot ser massa mà d'obra. De vegades és més fàcil trobar tots els llocs del codi amb algun tipus d'error i solucionar-los que escriure una regla per detectar aquests casos.
- Manca de suport a la dependència. Els grans projectes depenen d'un gran nombre de biblioteques i marcs que amplien les capacitats del llenguatge de programació. Si la base de coneixement de l'escàner no té informació sobre els "embornals" en aquests marcs, es convertirà en un punt cec i l'escàner simplement ni tan sols entendrà el codi.
- Durada de l'escaneig. Trobar vulnerabilitats al codi és una tasca complexa pel que fa als algorismes. Per tant, el procés pot trigar molt de temps i requerir recursos informàtics importants.
- Baixa cobertura. Malgrat el consum de recursos i el temps d'escaneig, els desenvolupadors d'eines SAST encara han de fer compromisos i analitzar no tots els estats en què es pot trobar el programa.
- Reproductibilitat de les troballes. Assenyalar la línia específica i la pila de trucades que condueixen a una vulnerabilitat és fantàstic, però, en realitat, sovint l'escàner no proporciona prou informació per comprovar la presència d'una vulnerabilitat des de l'exterior. Després de tot, el defecte també pot estar en un codi mort, que és inabastable per a un atacant
Problemes d'escaneig d'infraestructura
- Inventari insuficient. En grans infraestructures, especialment les separades geogràficament, sovint és el més difícil saber quins hosts escanejar. En altres paraules, la tasca d'escaneig està estretament relacionada amb la tasca de gestió d'actius
- Pobre priorització. Els escàners de xarxa solen produir molts resultats amb defectes que no es poden explotar a la pràctica, però formalment el seu nivell de risc és alt. El consumidor rep un informe que és difícil d'interpretar i no està clar què cal corregir primer.
- Pobres recomanacions. La base de coneixement de l'escàner sovint conté només informació molt general sobre la vulnerabilitat i com solucionar-la, de manera que els administradors hauran d'armar-se amb Google. La situació és una mica millor amb els escàners de caixa blanca, que poden emetre una ordre específica per solucionar-ho
- Fet a mà. Les infraestructures poden tenir molts nodes, la qual cosa significa potencialment molts defectes, informes sobre els quals s'han d'analitzar i analitzar manualment a cada iteració.
- Poca cobertura. La qualitat de l'exploració de la infraestructura depèn directament de la mida de la base de coneixement sobre vulnerabilitats i versions de programari. on, , fins i tot els líders del mercat no tenen una base de coneixement exhaustiva, i les bases de dades de solucions gratuïtes contenen molta informació que els líders no tenen
- Problemes amb el pegat. Molt sovint, aplicar pedaços a les vulnerabilitats de la infraestructura implica actualitzar un paquet o canviar un fitxer de configuració. El gran problema aquí és que un sistema, especialment un antic, es pot comportar de manera imprevisible com a resultat d'una actualització. Bàsicament, haureu de realitzar proves d'integració a la infraestructura en directe en producció.
Enfocaments
Com ser?
Us explicaré més sobre exemples i com tractar molts dels problemes enumerats a les parts següents, però de moment us indicaré les principals direccions en què podeu treballar:
- Agregació de diverses eines d'escaneig. Amb l'ús correcte de diversos escàners, podeu aconseguir un augment significatiu de la base de coneixement i la qualitat de la detecció. Podeu trobar encara més vulnerabilitats que el total de tots els escàners llançats per separat, mentre que podeu avaluar amb més precisió el nivell de risc i fer més recomanacions.
- Integració de SAST i DAST. És possible augmentar la cobertura de DAST i la precisió de SAST intercanviant informació entre ells. Des de les fonts podeu obtenir informació sobre les rutes existents, i amb DAST podeu comprovar si la vulnerabilitat és visible des de l'exterior.
- Machine Learning™. L'any 2015 I (i ) sobre l'ús de les estadístiques per donar als escàners la intuïció d'un pirata informàtic i accelerar-los. Definitivament, això és un farratge per al desenvolupament d'anàlisis de seguretat automatitzades en el futur.
- Integració d'IAST amb autotests i OpenAPI. Dins del pipeline CI/CD, és possible crear un procés d'escaneig basat en eines que funcionen com a servidor intermediari HTTP i proves funcionals que funcionen mitjançant HTTP. Les proves i contractes OpenAPI/Swagger donaran a l'escàner la informació que falta sobre els fluxos de dades i permetran escanejar l'aplicació en diversos estats.
- Configuració correcta. Per a cada aplicació i infraestructura, cal crear un perfil d'escaneig adequat, tenint en compte el nombre i la naturalesa de les interfícies i les tecnologies utilitzades.
- Personalització de l'escàner. Sovint, una aplicació no es pot escanejar sense modificar l'escàner. Un exemple és una passarel·la de pagament en la qual s'ha de signar cada sol·licitud. Sense escriure un connector al protocol de passarel·la, els escàners bombardejaran sense cap sol·licitud amb la signatura incorrecta. També cal escriure escàners especialitzats per a un tipus concret de defecte, com ara
- Gestió de riscos. L'ús de diversos escàners i la integració amb sistemes externs com Asset Management i Threat Management permetran utilitzar molts paràmetres per avaluar el nivell de risc, de manera que la gestió pugui obtenir una imatge adequada de l'estat actual de seguretat del desenvolupament o de la infraestructura.
Estigueu atents i interrompem l'exploració de vulnerabilitats!
Font: www.habr.com