La cybersecurity non può essere un prodotto: l’abbiamo affrontata nel modo sbagliato

Per molto tempo la cybersecurity è stata percepita come un problema marginale. Non era un tema da consiglio di amministrazione, non era un tema da budget strutturato, non era nemmeno davvero un mercato maturo.

Quando la sicurezza era artigianale

La sicurezza si faceva con pochi strumenti, molta competenza tecnica e una capacità quasi artigianale di leggere i sistemi. Reverse engineering, debugging, analisi del traffico, studio del codice, comprensione delle architetture. Non c’erano grandi piattaforme a promettere protezione totale. C’erano persone che cercavano di capire come funzionavano davvero le cose, dove si rompevano e perché.

Il paradosso è che, pur con meno strumenti, l’approccio era spesso più vicino alla sostanza di quanto non lo sia oggi.

Il problema principale, allora, era la mancanza di consapevolezza. Molte aziende non capivano il rischio. Un database esposto, un servizio pubblicato male, una credenziale riutilizzata, una rete piatta senza segmentazione: tutto veniva percepito come un dettaglio tecnico, non come un problema strategico.

Poi è diventata un mercato e un prodotto

Poi qualcosa è cambiato.

Con l’aumento degli incidenti pubblici, dei ransomware, dei data breach e dell’attenzione mediatica, la cybersecurity è entrata finalmente nel linguaggio delle aziende. Il mercato si è aperto, le imprese hanno iniziato a comprare soluzioni, a chiedere servizi, a pretendere report, dashboard, monitoraggio, certificazioni, compliance.

È stato un passaggio necessario, ma anche profondamente ambiguo.

Perché nel momento in cui la sicurezza è diventata mercato, è stata trasformata soprattutto in prodotto.

• Per ogni rischio, una licenza.
• Per ogni attacco, una piattaforma.
• Per ogni paura, una dashboard.
• Per ogni variante tecnica, un nuovo modulo commerciale.

Il risultato è che molte competenze realmente offensive, architetturali e analitiche sono state assorbite dentro una logica da system integration. Persone che avrebbero potuto smontare sistemi, ragionare da attaccanti e progettare difese migliori sono state spesso trasformate in installatori esperti, configuratori o intermediari di soluzioni prodotte da altri.

È qui che la cybersecurity ha preso una direzione discutibile.

La sicurezza non può essere un prodotto

Perché la sicurezza non può essere ridotta a un prodotto. Non è un appliance, non è un software, non è un SOC acceso 24 ore su 24, non è un portale pieno di grafici, non è un report automatico.

Tutti questi strumenti possono essere utili. Ma solo se arrivano dopo una buona architettura.

Il punto centrale è che il 90% della sicurezza si decide nell’architettura.

Monitoring, patching, detection e incident response sono importanti, ma arrivano dopo. Strumenti di controllo, contenimento e reazione non sono il cuore della sicurezza.

Un caso concreto: l’accesso VPN a terzi

Un esempio concreto chiarisce meglio il punto:

Sto lavorando alla pubblicazione di un prodotto on-premise per un cliente, installato dentro l’infrastruttura interna di un’azienda, che deve esporre un servizio critico verso Internet e consentire accessi esterni controllati.

Alla domanda del titolare "siamo sicuri a pubblicarlo" la parte commerciale ha subito risposto dipende quanto avere investito nelle ultime tecnologie per la sicurezza, il che è francamente disarmante.

La soluzione più immediata, proposta dall' integrator presente, è il dare l’accesso VPN per soggetti esterni (anche agenti su device di cui non c' è il minimo controllo).

A prima vista sembra una scelta facile, normale corretta. In realtà può essere estremamente rischiosa.

Dare accesso VPN a soggetti terzi significa spesso portarli troppo vicino alla rete interna. Anche con segmentazione, subnet dedicate e regole firewall, resta una superficie delicata. Bisogna gestire identità, dispositivi, revoche, credenziali rubate, MFA, logging, responsabilità, accessi temporanei e livelli di privilegio.

Un’altra strategia frequente è quella dell’“isola e monitora”: si espone il servizio, lo si separa un po’, si aggiungono log, alert, magari qualche prodotto di sicurezza, e si resta a guardare.

Ma monitorare non significa proteggere.

Se il software non è sotto il proprio controllo, se il patching dipende da terzi, se il servizio è opaco e se la superficie esposta è ampia, il monitoring diventa una forma elegante di attesa. Si osserva il problema, ma non lo si riduce davvero.

Un’architettura corretta: niente servizi critici esposti su Internet

Un approccio architetturale corretto dovrebbe partire da un principio diverso, nessun servizio critico interno dovrebbe essere direttamente esposto su Internet.

Come abbiamo affrontato il problema ( Attenzione stiamo omettendo tutta la parte di isolamento nell' insfrastruttura interna, ci stiamo concentrando solo sull' esposizione dei servizi e accessi ).

Il traffico proveniente da Internet arriva prima su Cloudflare, con proxy attivo e origin lockdown. L’indirizzo reale dell’infrastruttura non viene pubblicato direttamente e l’accesso viene limitato tramite firewall e security group.

Da lì il traffico viene inoltrato verso una VPS pubblica con Nginx. Ma Nginx non deve essere trattato come un semplice reverse proxy. deve diventare un punto di decisione ( e questo esclude il 99% del rumore).

La richiesta viene valutata in base a più segnali: provenienza geografica, ASN, user-agent, accept-language, rate limit, pattern comportamentali, coerenza della richiesta e altri indicatori ,da questi elementi si costruisce un trust score NEL PROXY.

Se il trust score è alto e la richiesta presenta un session cookie valido generato da una sessione precedente, il traffico può essere inoltrato verso il backend reale.

Ma il backend reale, in questo disegno, non è una macchina pubblica è la VM applicativa dentro l’infrastruttura interna (per quanto isolata). Non ha esposizione diretta su IP pubblico e riceve traffico solo attraverso un tunnel WireGuard cifrato dal VPS.

Se il trust score è medio, la richiesta non dovrebbe accedere direttamente al backend. Può essere sottoposta a validazione aggiuntiva: session cookie precedente, credenziali corrette, 2fa e coerenza del profilo della richiesta. Solo se tutti questi elementi sono validi, il traffico viene portato al backend reale.

Se il trust score è basso, oppure se mancano session cookie, credenziali valide, 2FA o coerenza comportamentale, la richiesta non deve toccare il backend reale. Deve finire in un honeypot.

L’honeypot, in questo caso, può essere una finta pagina di login senza alcun legame con il servizio reale. Serve a trattenere traffico sospetto, raccogliere segnali, rallentare l’attaccante e proteggere il backend. Dopo un certo numero di tentativi falliti, l’IP può essere mandato in blacklist automaticamente nei vari "sistemi" limitrofi.

Il punto non è costruire un labirinto scenografico. Il punto è impedire che traffico non affidabile arrivi al sistema critico.

Il flusso concettuale diventa quindi:

• Internet passa da Cloudflare.
• Cloudflare nasconde l’origine e limita l’accesso.
• Nginx valuta la richiesta e calcola un trust score.
• Solo richieste coerenti e già riconosciute possono raggiungere il backend reale.
• Le richieste intermedie vengono sottoposte a validazione ulteriore.
• Le richieste sospette finiscono in honeypot.
• Il backend reale resta nella rete interna.
• Il database è accessibile solo dalla VM applicativa, con privilegi limitati e controlli sulle query.

I risultati: superficie d’attacco ridotta prima dei prodotti

Con questa architettura si ottengono diversi risultati importanti.

• Il server di produzione non è esposto direttamente
• Il DNS non punta alla sede o ai server interni. *
• L’indirizzo reale dell’infrastruttura privata resta nascosto.
• Non si concede accesso VPN generico a soggetti esterni.
• Il traffico sospetto non arriva direttamente al backend dovendomi fidare delle release rapide di patching del prodotto.
• L’honeypot assorbe e identifica tentativi malevoli e mi permette di gestire hardenind automatizzato in cascata.
• La VM applicativa espone solo ciò che serve.
• Il database non è raggiungibile ed è "sotto diversi strati".
• L' utente non ha complicazioni inutili e disservizi nell' utilizzo.
• La superficie d’attacco viene ridotta drasticamente.( il 99% del rumore online è fuori dalla mia infrastruttura, ci arriva solo, traffico nazionale o limitrofo, con un pass sulla credenziale di sessione di primo livello, autenticata di 2fa sul proxy, che conosce le credenziali dell' applicativo)

• Non pubblicate mai nei DNS gli indirizzi IP delle vostre infrastrutture interne, regalare anche un solo IP della vostra subnet pubblica a un attaccante significa dargli il vostro “indirizzo di casa”: da lì potrà iniziare a ricostruire la vostra superficie esposta. Se non fornite questo punto di partenza, restate molto più difficili da individuare, semplicifando 1 tra 2³² di indirizzi ipv4.

La cybersecurity è una disciplina di progetto

È così che dovrebbe essere pensata la sicurezza: non come una somma di tool, ma come un disegno.

Non perché elimina ogni rischio, ma perché riduce drasticamente le possibilità di errore sistemico. Ogni componente ha un ruolo limitato. Ogni passaggio ha una funzione. Ogni accesso viene condizionato. Ogni livello riduce la fiducia implicita nel precedente.

Il problema è che oggi chi progetta davvero queste architetture viene spesso considerato solo un integrator. Una figura operativa. Qualcuno che “mette su le macchine”, “configura i servizi”, “fa il deploy”.

È un errore enorme.

Chi decide come un servizio viene pubblicato sta facendo sicurezza o crea la falla. Chi decide come una rete viene segmentata sta facendo sicurezza o crea un problema. Chi decide come un backend viene isolato sta facendo sicurezza o lo espone a rischi. Chi decide come ridurre disclosure, privilegi e superfici d’attacco sta facendo sicurezza.

Spesso molto più di chi osserva alert su una dashboard.

La cybersecurity deve tornare a essere una disciplina di progetto. Deve tornare a occuparsi di architettura, non solo di prodotto. Deve smettere di confondere il monitoraggio con la protezione, la compliance con la robustezza, la dashboard con la comprensione.

Se manca l’architettura, tutto il resto è solo un modo più costoso di restare vulnerabili.