PWN-ALL · Cybersecurity e sviluppo software

PWN-ALL offre quattro servizi integrati: test di penetrazione e simulazione di attacchi; risposta agli incidenti e analisi forense digitale; ingegneria del software sicura in Rust e Python; e consulenza sulla sicurezza indipendente dai fornitori. Ogni incarico prevede un ambito di intervento definito per iscritto, risultati concreti e criteri di accettazione concordati.

Sì. PWN-ALL Auditing, Reviewing & Testing Cyber Risks CO. L.L.C è una società con sede a Dubai, negli Emirati Arabi Uniti, fondata nel 2024 e operante in base alla licenza DET di Dubai n. 1324553. La società è inoltre registrata con i codici D-U-N-S 571235572 e NCAGE 10G8W.

Lavoriamo principalmente con aziende, enti governativi e piattaforme di alto valore in tutto il mondo. I nostri servizi possono essere forniti da remoto in diverse giurisdizioni, con comunicazioni disponibili in oltre 20 lingue; eventuali requisiti specifici relativi alla giurisdizione in materia legale, probatoria o di trattamento dei dati vengono concordati durante la fase di definizione dell’ambito di intervento.

Sì. Possiamo firmare un accordo di riservatezza (NDA) prima di condividere informazioni sensibili e utilizzare Signal, e-mail crittografate con PGP o un altro canale approvato dal cliente. L'accesso alle informazioni del cliente è gestito secondo il principio della "necessità di sapere", nel rispetto dei controlli concordati per l'incarico.

Iniziate definendo il risultato desiderato, il servizio o le risorse coinvolte, l’urgenza, le scadenze ed eventuali vincoli operativi o normativi; non inviate informazioni riservate prima che siano stati stipulati un accordo di riservatezza (NDA) e sia stato predisposto un canale sicuro. Successivamente confermeremo per iscritto l’ambito di applicazione, le esclusioni, le autorizzazioni, le regole di ingaggio, i risultati attesi, i criteri di accettazione, i referenti e il calendario.

I test di penetrazione programmati possono in genere avere inizio entro 3–5 giorni lavorativi dalla definizione dell'ambito e dall'autorizzazione scritta, compatibilmente con la disponibilità del momento. Gli incidenti in corso seguono una procedura di risposta separata, attiva 24 ore su 24, 7 giorni su 7; pertanto, in caso di emergenza è necessario segnalarla immediatamente per telefono o tramite un canale di messaggistica sicuro.

Il prezzo dipende dalle risorse, dalla complessità, dalle scadenze, dal rischio, dai requisiti in materia di prove e dai risultati finali. Una volta definito l’ambito del progetto, riceverete un’offerta scritta; per i lavori chiaramente definiti sono disponibili opzioni a prezzo fisso, i termini di pagamento sono stabiliti nel contratto e, per i progetti di maggiore entità, è possibile concordare garanzie bancarie.

Gli ambiti autorizzati possono includere applicazioni web, API, reti esterne e interne, Active Directory, ambienti cloud e applicazioni mobili. Gli interventi più ampi del red team possono inoltre verificare i controlli relativi all’identità, al personale e agli aspetti fisici, qualora tali attività siano esplicitamente autorizzate.

No. Gli strumenti automatizzati possono supportare la copertura, ma il processo è guidato da professionisti che mappano i percorsi di attacco, testano la logica di business, verificano la vulnerabilità e valutano l’impatto realistico. Il risultato sono prove concrete e misure correttive ordinate per priorità, non un file di esportazione non verificato generato da uno scanner.

I test seguono le pratiche in linea con gli standard OWASP e PTES attraverso cinque fasi: definizione dell'ambito e delle regole di ingaggio, ricognizione e mappatura della superficie di attacco, sfruttamento sicuro, reportistica a due livelli e ripetizione dei test. I casi di test specifici vengono adattati alle risorse concordate e al modello di minaccia.

Testiamo esclusivamente le risorse coperte da un'autorizzazione scritta e da regole di intervento concordate. Il cliente deve essere il proprietario dei sistemi o disporre dell'autorizzazione del proprietario o del fornitore di riferimento; le risorse di terze parti, il social engineering, l'accesso fisico e le azioni distruttive non rientrano nell'ambito del servizio, salvo espressa approvazione.

Il lavoro è concepito per ridurre al minimo i disagi, ma i test non possono mai essere privi di rischi. Le finestre di attacco, i limiti di frequenza, le esclusioni dei sistemi critici, i contatti di escalation, le condizioni di interruzione e i piani di ripristino vengono concordati in anticipo, e i test distruttivi non vengono eseguiti senza un’approvazione esplicita.

La durata dipende dall'ambito, dall'accessibilità, dalla complessità e dall'eventuale necessità di ripetere i test. La pagina dedicata al servizio fornisce tempi indicativi a partire da circa due settimane per i test sul web e sulle API, tre settimane per i test di rete e sei settimane per un'esercitazione "red team"; la proposta riporta il calendario effettivo.

Riceverete una sintesi esecutiva destinata alla dirigenza, oltre a risultati tecnici per gli ingegneri, tra cui prove, risorse interessate, impatto realistico, gravità e linee guida per la risoluzione dei problemi ordinate per priorità. L’ambito finale può inoltre definire i debriefing, i workshop sulla risoluzione dei problemi o i formati delle prove richiesti dagli stakeholder interni.

Sì, il flusso di lavoro standard dei test di penetrazione prevede una nuova verifica dei risultati corretti come concordato. La proposta riporta il periodo previsto per la nuova verifica, i risultati da sottoporre a verifica, gli accessi necessari e le modalità con cui le correzioni verificate saranno riportate nel rapporto finale.

No. Un test di penetrazione è una valutazione limitata nel tempo dell'ambito autorizzato e non può dimostrare l'assenza di vulnerabilità. Riduce l'incertezza e fornisce priorità basate su dati concreti, ma la sicurezza dipende comunque dalle misure correttive, dalle operazioni, dal monitoraggio e dai cambiamenti futuri.

Sì. Il servizio di risposta agli incidenti, attivo 24 ore su 24, 7 giorni su 7, si occupa del contenimento, della conservazione delle prove, della valutazione forense, dell'eliminazione, del ripristino e del rafforzamento della sicurezza post-incidente. In caso di incidente in corso, chiama o utilizza immediatamente Signal ed evita di inviare prove sensibili tramite canali non autorizzati.

No. Il team DFIR si occupa anche di furti di dati ed estorsioni senza crittografia, compromissione delle e-mail aziendali e frodi nei pagamenti, appropriazione indebita di account, compromissione di Microsoft 365, Google Workspace e servizi cloud, casi di insider e compromissione di applicazioni web o server.

Isolare gli host interessati dalla rete senza spegnerli, preservare le prove volatili, proteggere i backup da ulteriori accessi, registrare le azioni intraprese e aprire un canale di comunicazione per la gestione dell’incidente. Non procedere a riavvii generalizzati, cancellazioni, ripristini, decrittografie o negoziazioni prima che il responsabile dell’incidente e i vostri referenti legali o assicurativi abbiano concordato un piano.

Il servizio di gestione degli incidenti garantisce una linea di risposta attiva 24 ore su 24, 7 giorni su 7. Il livello di servizio dichiarato prevede un tempo inferiore a 60 minuti dalla prima chiamata all’ingresso di un analista nella linea condivisa, con le prime indicazioni per il contenimento che vengono fornite già durante la fase di triage; il tempo effettivo necessario per il contenimento dipende dall’accessibilità, dalla portata dell’incidente e dalla capacità del cliente di attuare le misure necessarie.

In genere sì, anche se lo spegnimento può distruggere prove volatili quali chiavi residenti in memoria, processi iniettati e connessioni attive. Non riaccendere i sistemi; conservarne lo stato attuale e contattare il team di risposta affinché si possano pianificare il triage a freddo e l’acquisizione di altre fonti di prova.

No. Il recupero dipende dalla famiglia di ransomware, dalla disponibilità di chiavi o strumenti di decrittografia, dalla qualità delle prove, dall’integrità dei backup, dalle condizioni del sistema, dai vincoli legali e dall’entità delle attività svolte dopo la compromissione. Valutiamo i backup integri, le ricostruzioni, la ricerca di strumenti di decrittografia e le opzioni di recupero delle chiavi, per poi indicare cosa è recuperabile e cosa no.

Il pagamento non dovrebbe essere la prima misura adottata e non garantisce il recupero o la cancellazione dei dati rubati. Occorre innanzitutto valutare le opzioni di recupero e le prove disponibili; qualsiasi comunicazione con l’operatore o decisione relativa al pagamento deve coinvolgere il cliente, il consulente legale, l’assicuratore, se del caso, e deve essere soggetta all’approvazione in materia di sanzioni.

A seconda dell’ambito di intervento, i risultati finali possono includere una documentazione delle prove e della catena di custodia, una cronologia degli interventi, i risultati relativi alle cause alla radice e all’accesso iniziale, l’analisi dei movimenti laterali e dell’esfiltrazione, gli indicatori di compromissione, le priorità di ripristino e un rapporto pronto per essere presentato all’assicuratore o all’autorità di regolamentazione, corredato di un piano di rafforzamento della sicurezza. Le conclusioni rimangono limitate dalle prove conservate e dal processo di custodia seguito.

Realizziamo backend sicuri in Rust e Python, API, sistemi di gestione dei dati, soluzioni di automazione, integrazioni di intelligenza artificiale, migrazioni e servizi di produzione critici dal punto di vista della sicurezza. La stessa pratica ingegneristica consente inoltre di creare strumenti forensi specifici per gli incidenti, quali collector, parser, generatori di timeline, scanner IOC o YARA, nonché strumenti di ricerca per la decrittografia o il recupero delle chiavi.

Rust viene utilizzato nei casi in cui sono fondamentali la sicurezza della memoria, la concorrenza, le prestazioni prevedibili e il controllo a basso livello; Python viene utilizzato nei casi in cui sono fondamentali la velocità di implementazione, i dati, l’apprendimento automatico, l’orchestrazione e le integrazioni. Il lavoro di progettazione dell’architettura assegna il linguaggio a ciascun componente, anziché costringere l’intero sistema a utilizzare un unico stack.

Il modello di consegna prevede le fasi di analisi, progettazione, implementazione, messa in sicurezza e consegna, con test di accettazione e di prestazione concordati per il progetto. La consegna può includere il codice sorgente, le risorse di distribuzione, i contratti API, le decisioni architetturali, i runbook, i diagrammi, il trasferimento di conoscenze e un supporto post-lancio di 30 giorni, se previsto dal contratto.

La consulenza riguarda l'architettura di sicurezza, la valutazione dei rischi orientata al business, la preparazione al GDPR, la preparazione agli audit, le politiche e i processi di risposta agli incidenti, l'integrazione dello sviluppo sicuro e la formazione specifica per ruolo. I risultati tipici includono i risultati classificati per priorità, un registro dei rischi con i responsabili, una roadmap di rafforzamento della sicurezza, manuali operativi e un pacchetto di documentazione pronto per l'audit.

No. La preparazione alla conformità consiste in un supporto tecnico e operativo, non in una consulenza legale né in una garanzia di certificazione; i risultati delle analisi forensi dipendono dalle prove conservate; il recupero dipende dalle condizioni dell’incidente; e i test di sicurezza non possono dimostrare l’assenza di vulnerabilità. Ogni proposta definisce attività misurabili e criteri di accettazione senza promettere risultati che esulano dal controllo di PWN-ALL.

PWN-ALL elenca come prodotti separati un monitor del Dark Web e delle fughe di dati, il rilevamento dei bot BotGuard e un hub per la scansione delle vulnerabilità. Fornisce inoltre oltre 20 strumenti gratuiti basati su browser per attività quali l'hashing, la generazione di chiavi, la steganografia, l'identificazione del ransomware e la visualizzazione di file o analisi forense; gli strumenti identificati come "client-side" vengono eseguiti localmente nel browser senza caricare i dati elaborati.

Reimpostare la password dell'account interessato da un dispositivo che si sa essere sicuro, anziché da quello compromesso; disconnettersi e revocare tutte le sessioni attive; rimuovere eventuali password delle app o accessi ad app collegate; e attivare l'autenticazione a più fattori. Conservare la casella di posta insieme ai log di accesso e di controllo e verificare la presenza di regole di inoltro o di posta in arrivo nascoste, ma non eliminare messaggi, regole o l'account, poiché costituiscono prove. Se la compromissione è ancora attiva o sono coinvolti movimenti di denaro, chiamare o utilizzare Signal per contattare la linea attiva 24 ore su 24, 7 giorni su 7, invece di attendere la risposta tramite chat. Il team DFIR gestisce end-to-end i casi relativi a Microsoft 365, Google Workspace e alla presa di controllo degli account, dal contenimento all'individuazione della causa principale fino al rafforzamento della sicurezza.

Si tratta di un caso in corso di compromissione dell'account e-mail aziendale e di frode nei pagamenti, quindi la tempestività è fondamentale: contattate immediatamente la vostra banca e la banca destinataria per tentare di revocare o bloccare il bonifico, e segnalate l'accaduto alle autorità competenti. Segnalateci l'accaduto tramite la nostra linea attiva 24 ore su 24, 7 giorni su 7, piuttosto che attendere la chat, soprattutto finché i fondi potrebbero essere ancora in transito. Il nostro team DFIR indagherà poi su come si sia avuto accesso alla casella di posta o all'account, se siano state alterate le fatture o le coordinate bancarie e a quali altri dati si sia avuto accesso, conservando al contempo le prove per la vostra banca, l'assicuratore ed eventuali autorità di vigilanza. Conservate intatte le e-mail e i log dell'account ed evitate di cancellare qualsiasi cosa, in modo che il quadro forense rimanga completo.

Si tratta di furto di dati ed estorsione senza crittografia, e rientra pienamente nell'ambito di competenza del team DFIR anche se non è stato utilizzato alcun ransomware. La priorità è preservare le prove, determinare l'entità dei dati a cui si è effettivamente avuto accesso e che sono stati sottratti, contenere il percorso di accesso e comprendere la richiesta prima che qualcuno risponda all'autore della minaccia. Non pagare, negoziare né rispondere alla richiesta prima che il responsabile dell'incidente e i referenti legali e assicurativi concordino su una linea d'azione. Segnalare l'accaduto alla linea di assistenza attiva 24 ore su 24, 7 giorni su 7, e condividere i messaggi di minaccia tramite un canale sicuro anziché uno pubblico o non autorizzato.

Quando si riscontrano indicatori o si nutre un sospetto, ma non vi è alcun incidente confermato, il team DFIR può esaminare i log, gli endpoint e i dati relativi al cloud e alle identità per determinare se vi siano prove di intrusioni attuali o passate, persistenza o accesso non autorizzato ai dati. Successivamente, il team segnala se vi sono segni di compromissione e quali azioni intraprendere; qualora venissero rilevate chiare attività dannose, si passa a un intervento completo di risposta agli incidenti, comprensivo di contenimento e analisi forense. Mentre è in corso tale valutazione, conservate i log esistenti ed evitate di reinstallare il sistema operativo o di cancellarne i dati, poiché ciò potrebbe eliminare le prove necessarie per rispondere alla domanda. Se state assistendo a un attacco in corso, chiamate subito la nostra linea attiva 24 ore su 24, 7 giorni su 7, oppure contattateci immediatamente su Signal, invece di attendere la risposta in chat.

Ogni intervento prevede misure di rafforzamento della sicurezza post-incidente una volta gestita la minaccia immediata. Sulla base dei risultati relativi alla causa principale e all'accesso iniziale, il team fornisce un piano di rafforzamento con priorità definite, volto a colmare le specifiche lacune sfruttate dall'autore dell'attacco e a ridurre le possibilità di recidiva. Per un intervento più approfondito e continuativo, la pratica di consulenza può tradurre il tutto in un registro dei rischi con i responsabili, politiche aggiornate e runbook di risposta agli incidenti, oltre a formazione specifica per ciascun ruolo, mentre la pratica ingegneristica può sviluppare gli strumenti necessari per le correzioni. Il rafforzamento della sicurezza riduce il rischio e migliora la resilienza, ma nessun fornitore può garantire che un incidente futuro sia impossibile.

Il ripristino del servizio è importante, ma non rivela come l'autore dell'attacco sia riuscito a penetrare nel sistema, se sia ancora presente o a quali dati abbia avuto accesso; inoltre, il ripristino può sovrascrivere le prove relative a tutti e tre questi aspetti. Se il percorso di accesso iniziale e qualsiasi forma di persistenza non vengono individuati ed eliminati, la stessa intrusione può ripetersi dopo il ripristino. È opportuno che il team DFIR identifichi la causa principale, verifichi la presenza di accessi residui e confermi quali dati siano stati sottratti, per poi applicare misure di rafforzamento mirate — conservando eventuali log, immagini o supporti interessati rimasti, anziché eliminarli. Se non si è certi che la minaccia sia stata completamente eliminata, è opportuno considerarla attiva e segnalarla alla linea di assistenza attiva 24 ore su 24, 7 giorni su 7.

I sistemi esistenti rientrano pienamente nell'ambito di intervento; la pratica ingegneristica si occupa regolarmente di migrazioni, rafforzamento della sicurezza e servizi di produzione critici dal punto di vista della sicurezza, piuttosto che limitarsi esclusivamente alla realizzazione di progetti ex novo. Un incarico inizia con una fase di analisi per stabilire come funzionano effettivamente il codice, i dati e i confini di fiducia attuali prima di apportare qualsiasi modifica, seguita dalla progettazione dell'architettura, dall'implementazione e da una fase dedicata al rafforzamento della sicurezza. Laddove l'esigenza primaria sia una valutazione della sicurezza del codice applicativo esistente, questa viene fornita tramite penetration test delle applicazioni e l'integrazione dello sviluppo sicuro offerta dalla pratica di consulenza; la combinazione più adeguata viene definita durante il colloquio iniziale.

È possibile occuparsi di sistemi ereditati, parzialmente realizzati o in fase di stallo, ma il lavoro inizia comunque con una fase di analisi che definisce lo stato attuale reale, ciò che esiste, ciò che funziona e dove si trovano i rischi e le lacune, prima di impegnarsi in qualsiasi approccio. Da quel momento in poi si applica il modello standard che copre le fasi di progettazione dell'architettura, implementazione, rafforzamento della sicurezza e consegna, ciascuna regolata da uno Statement of Work scritto con criteri di accettazione concordati, anziché da una promessa a tempo indeterminato di risolvere ogni problema. Una volta compreso lo stato attuale, si definisce ciò che è realisticamente realizzabile e in quale ordine.

L'integrazione di IA e LLM è parte integrante della pratica ingegneristica in Rust e Python, progettata per garantire la sicurezza fin dalla progettazione (secure-by-design) attraverso lo stesso flusso di analisi, architettura, implementazione e rafforzamento della sicurezza, con test di sicurezza e di accettazione concordati. I rischi specifici delle funzionalità LLM, quali l'invio di input non attendibili al modello, l'esposizione di dati sensibili, le autorizzazioni di accesso del modello e i controlli contro gli abusi o i costi fuori controllo, vengono definiti nell'ambito del progetto e affrontati come parte integrante di tale lavoro, anziché essere aggiunti a posteriori. Come per qualsiasi attività di sicurezza, l'intervento definisce controlli misurabili e criteri di accettazione, piuttosto che garantire che un sistema non possa essere utilizzato in modo improprio.

Non vi viene semplicemente consegnato del codice "grezzo": il passaggio di consegne è concepito per essere implementato e gestito nel vostro ambiente e può includere risorse di distribuzione, contratti API, decisioni architetturali, runbook, diagrammi e trasferimento di conoscenze, con un supporto post-lancio di 30 giorni, se previsto dal contratto. Poiché il lavoro è finalizzato a un utilizzo in produzione in cui la sicurezza è fondamentale, prima del passaggio di consegne viene eseguita una fase dedicata al rafforzamento della sicurezza. Chi esattamente esegue e gestisce l'implementazione viene concordato per ogni singolo incarico nello Statement of Work.

L'integrazione della sicurezza nel modo in cui un team sviluppa già il software avviene attraverso l'integrazione dello sviluppo sicuro offerta dalla pratica di consulenza, che ha carattere di consulenza: si valuta dove la sicurezza si inserisce nel flusso di lavoro esistente, si definiscono i controlli e le misure di protezione da includere e si forniscono agli sviluppatori indicazioni specifiche per il loro ruolo. Laddove tale processo richieda l'automazione personalizzata o lo sviluppo di strumenti su misura, ad esempio scanner o controlli personalizzati, la pratica ingegneristica può implementarli nell'ambito di un progetto separato. La pratica di consulenza fornisce consulenza e definisce il processo, ma non sviluppa direttamente il software; pertanto, qualsiasi elemento che debba essere realizzato viene considerato come un risultato finale di ingegneria.

Rust e Python sono i pilastri fondamentali: Rust quando contano la sicurezza della memoria, la concorrenza e le prestazioni prevedibili, e Python quando contano la velocità di implementazione, i dati, l'apprendimento automatico e le integrazioni. Il lavoro di progettazione dell'architettura assegna il linguaggio in base al singolo componente, anziché costringere l'intero sistema a utilizzare un unico stack; inoltre, i sistemi esistenti e le migrazioni rientrano nell'ambito del progetto, pertanto la scelta del linguaggio più adatto viene determinata in base alle vostre esigenze durante la definizione dell'ambito.

La consulenza comprende la preparazione al GDPR e all'audit: una valutazione delle lacune, i controlli e le politiche per colmarle, nonché un pacchetto di documentazione pronto per l'audit, fornito in modo indipendente dai fornitori. Si tratta di un supporto alla preparazione e all'adeguamento, non di consulenza legale, e di per sé non garantisce la conformità o la certificazione — queste dipendono dalle vostre operazioni e dall'ente valutatore. I risultati sono costituiti da riscontri ordinati per priorità, un registro dei rischi con l'indicazione dei responsabili e una roadmap di rafforzamento della sicurezza su cui potete agire.

La formazione sulla sicurezza specifica per ruolo fa parte della pratica di consulenza ed è strutturata in base al vostro stack, ai vostri rischi e ai ruoli che ne hanno bisogno. In genere è integrata con le attività di consulenza correlate — integrazione dello sviluppo sicuro, politiche e processi di risposta agli incidenti — in modo che la formazione rifletta il modo in cui i vostri team sviluppano e operano effettivamente. Come per ogni attività di consulenza, l'ambito e i risultati vengono concordati in anticipo.

La revisione dell'architettura di sicurezza, o di un progetto di sistema proposto prima della sua implementazione, costituisce una parte fondamentale della nostra attività di consulenza. Valutiamo il progetto alla luce dei vostri rischi aziendali e vincoli operativi, per poi fornire i risultati ordinati per priorità, una roadmap di rafforzamento della sicurezza e, ove opportuno, runbook e un registro dei rischi con i responsabili designati. Poiché la nostra attività è indipendente dai fornitori, le raccomandazioni si basano sui vostri rischi piuttosto che su qualsiasi prodotto che potremmo altrimenti vendere.

La differenza sta nell'ambito di applicazione: la consulenza è un servizio indipendente dai fornitori che valuta i rischi, esamina l'architettura e vi prepara agli audit, ma non sviluppa software né gestisce la risposta agli incidenti di emergenza. Se avete bisogno di scrivere codice o di realizzare un sistema, quella è la pratica di ingegneria del software sicuro; se è in corso un attacco, quello è il processo di risposta agli incidenti attivo 24 ore su 24, 7 giorni su 7; e se avete bisogno che le vulnerabilità vengano individuate e sfruttate in modo sicuro previa autorizzazione, quello è il penetration test. Vi indicheremo la pratica più adatta, o le combineremo, in base al risultato che vi serve.

Potete contattarci via e-mail (PGP disponibile), Signal, Telegram all'indirizzo t.me/pwn_all, WhatsApp o per telefono al numero +971 58 594 6337; è inoltre disponibile una linea attiva 24 ore su 24, 7 giorni su 7, per gli incidenti in corso. Per qualsiasi questione sensibile, consigliamo di utilizzare Signal o l'e-mail crittografata con PGP e vi chiediamo di non inviare informazioni riservate o credenziali prima che siano stati stipulati un accordo di riservatezza (NDA) e sia stato stabilito un canale sicuro. In caso di incidente in corso, chiamate o utilizzate immediatamente Signal invece di attendere una risposta in chat.

L'accesso alle vostre informazioni è gestito secondo il principio della "necessità di sapere", nel rispetto dei controlli concordati per l'incarico, previa sottoscrizione di un accordo di riservatezza (NDA) e l'utilizzo di un canale sicuro prima della condivisione di qualsiasi dato sensibile. Le condizioni specifiche relative al trattamento, all'archiviazione e alla conservazione dei dati sono definite nell'ambito di tale accordo, anziché essere stabilite in base a un modello predefinito valido per tutti i casi; vi chiediamo pertanto di non inviare informazioni riservate prima che tali condizioni siano state stabilite. Per qualsiasi informazione sensibile, i canali consigliati sono Signal o le e-mail crittografate con PGP.

La prova che pubblichiamo consiste nelle lettere di referenza firmate riportate nella sezione "Referenze" del sito, che potete consultare direttamente. Poiché la riservatezza è la nostra priorità, non forniamo ulteriori dettagli su clienti specifici o casi concreti; eventuali ulteriori informazioni possono essere condivise solo con il consenso del cliente interessato e previa firma di un accordo di riservatezza (NDA). Possiamo inoltre illustrare, nel corso di una chiamata, alcuni esempi illustrativi e anonimi di come si svolge un tipico incarico.

No, il sito web e questa chat hanno scopo puramente informativo e non costituiscono un contratto. Ogni incarico è regolato da uno Statement of Work firmato che definisce l'ambito di intervento, le esclusioni, le autorizzazioni, le regole di ingaggio, i risultati attesi, i criteri di accettazione, i referenti e la tempistica, con i prezzi confermati in una proposta scritta dopo la definizione dell'ambito di intervento. Non è necessario scambiarsi alcuna informazione sensibile finché non saranno stati stipulati un accordo di riservatezza (NDA) e non sarà stato predisposto un canale sicuro.

Un tipico progetto relativo al web o alle API inizia con la definizione dell'ambito, le regole di ingaggio e l'autorizzazione scritta, per poi passare alla ricognizione e alla mappatura della superficie di attacco, allo sfruttamento sicuro degli obiettivi concordati, alla reportistica a due livelli e a un nuovo test dei risultati corretti. I professionisti mappano manualmente i percorsi di attacco e ne verificano la sfruttabilità, anziché limitarsi a fornire i dati grezzi esportati dallo scanner; in questo modo riceverete un riepilogo esecutivo destinato alla dirigenza, i risultati tecnici corredati da prove e indicazione del livello di gravità, nonché linee guida per la correzione ordinate per priorità. La pagina del servizio indica un tempo di esecuzione iniziale indicativo di circa due settimane per gli interventi su web e API, mentre la tempistica effettiva e l'ambito del retest ammissibile vengono definiti nella proposta. Si tratta di uno schema illustrativo; i casi di test esatti vengono adattati alle risorse autorizzate e al modello di minaccia.

Un caso tipico si avvia sul ponte operativo 24/7 con le misure di contenimento e la conservazione delle prove, seguite da un'analisi forense per stabilire la causa principale, il punto di accesso iniziale, il movimento laterale e quali dati siano stati sottratti. Il ripristino viene pianificato sulla base di quanto supportato dalle prove — backup integri, ricostruzioni e, ove pertinente, ricerca di strumenti di decrittografia e opzioni di recupero delle chiavi — con il coinvolgimento del cliente, del consulente legale e dell'assicuratore in qualsiasi decisione relativa ai pagamenti o alle trattative. Riceverete un registro della catena di custodia, una cronologia degli interventi, gli indicatori di compromissione, le priorità di ripristino e un rapporto pronto per l'assicuratore o l'autorità di regolamentazione, corredato di un piano di rafforzamento della sicurezza. Si tratta di uno schema illustrativo; ciò che è recuperabile dipende dalla famiglia di ransomware, dalle chiavi, dai backup e dalle prove, e nulla è garantito.

Un ciclo di sviluppo tipico prevede le fasi di analisi, progettazione dell'architettura, implementazione, rafforzamento della sicurezza e consegna, con test di accettazione e di prestazione concordati in anticipo per il progetto. Il linguaggio di programmazione viene scelto in base al componente — Rust dove contano sicurezza e prestazioni, Python dove contano velocità, dati e integrazioni — e la sicurezza viene integrata fin dall'inizio anziché aggiunta alla fine. La consegna può includere il codice sorgente, le risorse di distribuzione, i contratti API, le decisioni architetturali, i runbook, i diagrammi e il trasferimento di conoscenze, con un supporto post-lancio di 30 giorni, se previsto dal contratto. Si tratta di uno schema illustrativo; l'ambito esatto e i criteri di accettazione sono definiti nello Statement of Work.