Auditoria de ciberseguretat i vulnerabilitats web

Auditoria de vulnerabilitats, monitoratge lleuger i enduriment d’aplicacions.

Proves d’intrusió, revisió de permisos, enduriment de les API i pla de resposta a incidents. L’informe prioritza per CVSS i per impacte real, i inclou el protocol de notificació de bretxes: el RGPD dóna 72 hores per comunicar-les a l’autoritat.

Per a qui és

  • Empreses amb dades personals subjectes al RGPD
  • SaaS amb clients enterprise que exigeixen auditoria
  • Startups amb finançament i exposició pública

Per què acaba fent falta

Gairebé cap incident comença amb un atac sofisticat. Comença amb una llibreria que fa dos anys que no s’actualitza, una clau d’API que va quedar en un repositori, un usuari d’un empleat que va marxar i encara està actiu, o un tauler d’administració accessible des d’internet perquè un dia calia per treballar des de casa.

El que converteix això en un problema seriós és que gairebé sempre es descobreix tard. Sense registres ni alertes, algú pot portar setmanes a dins; i quan es detecta, el rellotge corre: el RGPD dona setanta-dues hores per notificar una bretxa de dades personals a l’autoritat, i aquest termini comença quan te n’assabentes, no quan decideixes què fer.

Per això una auditoria útil no acaba amb una llista de vulnerabilitats. Acaba amb un ordre de correcció justificat per impacte real, amb l’urgent ja endurit, i amb un procediment escrit de què fa cadascú a les primeres hores. Una llista sense això s’arxiva i no canvia res.

Què entrego

  • Informe d’auditoria — Vulnerabilitats prioritzades per CVSS amb prova de concepte.
  • Pla de mitigació — Full de ruta de correccions amb l’esforç estimat.
  • Enduriment aplicat — Regles, polítiques d’accés i tallafoc quan escau.
  • Manual de resposta — Procediment documentat per quan passa alguna cosa.
  • Revisió de dependències — Biblioteques amb vulnerabilitat coneguda i l’actualització que la tanca.
  • Segona passada — Es torna a provar allò corregit i es tanca per escrit.

Què inclou

  • Anàlisi de vulnerabilitats
  • Revisió de configuració i accessos
  • Informe prioritzat per risc
  • Revisió posterior de les correccions

El que es decideix abans d’escriure una línia

  • Què es prova i què no — L’abast s’acorda per escrit abans de tocar res: quins sistemes hi entren, en quina finestra horària i quines proves en queden fora. Una auditoria que tomba un servei en hora punta no és una auditoria, és un incident que has pagat tu.
  • Producció o un entorn de proves — Les proves actives van sobre un entorn de proves sempre que existeixi i s’assembli al real. Quan no existeix, s’acota què es pot fer en producció i es fa en finestra acordada. La diferència entre els dos entorns és, ella mateixa, una troballa de l’informe.
  • Com s’ordenen les troballes — Per CVSS i per exposició real, no només per la puntuació. Una fallada crítica en un sistema intern sense sortida a internet no va abans que una de mitjana al web públic, i presentar-ho a l’inrevés fa que es corregeixi el que menys importa primer.
  • Què es corregeix aquí i què després — L’enduriment que no trenca res —permisos, polítiques, capçaleres, dependències— s’aplica dins de la feina. El que implica canviar l’aplicació es lliura prioritzat i amb esforç estimat, perquè ho planifiquis. I es torna a provar el que s’ha corregit abans de tancar per escrit.

El que no hi entra

  • Enginyeria social ni proves de suplantació al personal, tret que es contractin a part.
  • Corregir el codi de l’aplicació: es lliura prioritzat, l’aplica el teu equip o s’acorda com a desenvolupament.
  • Vigilància contínua ni servei de guàrdia, que són un contracte diferent.
  • Certificació: això és una auditoria tècnica, no l’emissió d’un certificat.
  • Auditar sistemes de tercers sense la seva autorització escrita.

El que necessites tenir

  • Autorització escrita del titular dels sistemes que es provaran.
  • Una finestra horària acordada i a qui avisar si alguna cosa cau.
  • Accessos de prova amb els diferents rols, per revisar permisos de debò.
  • Saber quines dades personals tracta cada sistema, per ordenar per impacte real.

Preguntes freqüents

És una auditoria de debò o un escàner automàtic?

Hi ha escaneig automàtic, però l'informe es revisa a mà. Un escàner marca centenars d'avisos i la majoria no són explotables; el que es lliura és el que sí que ho és.

Amb quin criteri es prioritzen els resultats?

Per CVSS i per impacte real, amb un pla de mitigació per ordre. Una fallada crítica en un sistema que no està exposat no va abans que una de mitjana al web públic.

Tocareu el sistema en producció?

No sense acordar abans i per escrit l'abast, la finestra horària i quines proves queden fora. Una auditoria que tomba un servei no és una auditoria.

Quant dura?

L’auditoria són dues setmanes: reconeixement, proves actives i informe amb reunió de priorització. La segona passada sobre el que s’ha corregit va després i està inclosa.

Què passa si trobeu alguna cosa greu?

S’avisa al moment, no al final a l’informe. Si hi ha indici que ja ha estat explotat, el primer és el procediment de bretxa i els seus terminis, no continuar provant.

Serveix per al que em demana un client enterprise?

Serveix com a auditoria tècnica amb informe prioritzat i segona passada, que és el que se sol demanar. Si el que t’exigeixen és una certificació concreta, això ho emet una entitat acreditada i es diu abans de començar.