Consulente ICT ICT Consultant

The Problem: Invisible Data Exfiltration via LLMs

Image generated with Gemini AI

The Shadow IT phenomenon has evolved. Today, the primary threat is no longer the unauthorized cloud server, but Shadow AI. To speed up their workflow, employees are pasting source code, confidential contracts, or financial data (PII) into public AI chatbots (like the free versions of ChatGPT or Claude). Because these tools often use user prompts to train their language models, the company's sensitive data is irrevocably exposed outside the corporate security perimeter.

The Solution: Policies, DNS Filtering, and Enterprise AI

Simply blocking access to AI tools generates frustration and pushes users to find loopholes (e.g., hotspot connections). The solution requires a three-tiered approach.

1. Visibility and Network-Level Blocking

The first step is to stop the data hemorrhage to unauthorized endpoints. Configure the corporate firewall or DNS resolver (like Pi-hole or NextDNS) to monitor and block queries to the public APIs of major uncontracted AI providers.

# Example domains to add to the DNS blocklist
api.openai.com
chatgpt.com
claude.ai
gemini.google.com

2. Implementing Enterprise AI (Walled Garden)

To maintain productivity without compromising security, you must provide a safe alternative. Deploy private instances via enterprise cloud services (such as Google Cloud Vertex AI or Azure OpenAI) where contracts explicitly guarantee that data will not be used for model training. Alternatively, for highly classified data, deploy open-source LLMs (like Llama 3) locally on on-premise servers.

3. Endpoint DLP Configuration

Update Data Loss Prevention (DLP) software policies on endpoints to detect and block attempts to copy-paste sensitive strings (e.g., credit card numbers, IBANs, or proprietary code) into browser windows directed at URL categories classified as "Generative AI".

Il Problema: L'esfiltrazione invisibile dei dati tramite LLM

Immagine realizzata con Gemini AI

Il fenomeno dello Shadow IT si è evoluto. Oggi la minaccia principale non è più il server cloud non autorizzato, ma la Shadow AI. I dipendenti, per velocizzare il lavoro, incollano codice sorgente, contratti riservati o dati finanziari (PII) all'interno di chatbot IA pubblici (come la versione gratuita di ChatGPT o Claude). Poiché questi strumenti utilizzano spesso i prompt degli utenti per addestrare i propri modelli linguistici, i dati sensibili dell'azienda vengono irrimediabilmente esposti all'esterno del perimetro di sicurezza aziendale.

La Soluzione: Policy, DNS Filtering ed Enterprise AI

Bloccare semplicemente l'accesso agli strumenti IA genera frustrazione e spinge gli utenti a trovare scappatoie (es. connessioni hotspot). La soluzione richiede un approccio a tre livelli.

1. Visibilità e Blocco a livello di Rete

Il primo passo è fermare l'emorragia di dati verso endpoint non autorizzati. Configura il firewall aziendale o il resolver DNS (come Pi-hole o NextDNS) per monitorare e bloccare le query verso le API pubbliche dei principali fornitori IA non contrattualizzati.

# Esempio di domini da inserire in blocklist DNS
api.openai.com
chatgpt.com
claude.ai
gemini.google.com

2. Implementazione di IA Aziendale (Walled Garden)

Per mantenere la produttività senza compromettere la sicurezza, è necessario fornire un'alternativa sicura. Implementa istanze private tramite servizi cloud enterprise (come Google Cloud Vertex AI o Azure OpenAI) dove i contratti garantiscono esplicitamente che i dati non verranno utilizzati per il training dei modelli. In alternativa, per dati ad altissima classificazione, distribuisci LLM open-source (come Llama 3) localmente sui server aziendali.

3. Configurazione Endpoint DLP

Aggiorna le policy del software di Data Loss Prevention (DLP) sugli endpoint per rilevare e bloccare i tentativi di copia-incolla di stringhe sensibili (es. numeri di carte di credito, IBAN o codice proprietario) all'interno delle finestre del browser dirette a categorie URL classificate come "Generative AI".

When managing an IT infrastructure, relying on consumer GUI tools like Microsoft's PC Health Check app to verify Windows 11 compatibility isn't scalable. As sysadmins, we need automated, fast tools that provide clear text output to integrate into broader deployment scripts.

The two most critical (and often blocking) requirements for upgrading from Windows 10 to Windows 11 concern hardware security: the presence of TPM 2.0 (Trusted Platform Module) and the enablement of Secure Boot at the UEFI level.

I wrote a quick PowerShell script that queries the operating system directly to extract this information without needing to reboot the machine or enter the BIOS/UEFI.

The Script

You can run this code block by opening PowerShell with Administrator privileges. The script checks the TPM status and Secure Boot configuration, returning immediate color-coded feedback.

<#
.SYNOPSIS
    Verifies system readiness for the Windows 11 upgrade (Focus on TPM and Secure Boot).
.DESCRIPTION
    The script checks if the TPM module is present, ready, and version 2.0.
    It also verifies whether Secure Boot is enabled in the UEFI firmware.
#>

Write-Host "=========================================" -ForegroundColor Cyan
Write-Host "  Windows 11 Requirements Check          " -ForegroundColor Cyan
Write-Host "=========================================`n" -ForegroundColor Cyan

# 1. Check TPM
Write-Host "[*] Checking TPM module..."
try {
    $tpm = Get-Tpm
    if ($tpm.TpmPresent) {
        # The TpmReady property indicates if it is ready for use
        if ($tpm.TpmReady) {
            Write-Host "    [OK] TPM detected and ready for use." -ForegroundColor Green
        } else {
            Write-Host "    [WARNING] TPM present but not initialized." -ForegroundColor Yellow
        }
    } else {
        Write-Host "    [ERROR] No TPM module detected on the motherboard." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERROR] Cannot query TPM. Ensure you are running as Administrator." -ForegroundColor Red
}

# 2. Check Secure Boot
Write-Host "`n[*] Checking Secure Boot..."
try {
    $secureBoot = Confirm-SecureBootUEFI
    if ($secureBoot) {
        Write-Host "    [OK] Secure Boot enabled in UEFI firmware." -ForegroundColor Green
    } else {
        Write-Host "    [ERROR] Secure Boot is disabled. You need to enable it in BIOS/UEFI." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERROR] Cmdlet not supported or system in Legacy BIOS mode (non-UEFI)." -ForegroundColor Red
}

Write-Host "`n=========================================" -ForegroundColor Cyan
Write-Host "Check complete." -ForegroundColor Cyan

How does it work under the hood?

Get-Tpm: This is a native Windows cmdlet that returns an object containing the details of the Trusted Platform Module. We check TpmPresent and TpmReady to ensure not only that the chip exists, but that it has been properly activated at the OS level.

Confirm-SecureBootUEFI: This cmdlet directly queries the firmware variables. If it returns True, Secure Boot is active. If the script falls into the catch block, it is highly likely that the system drive is MBR-partitioned and booting in Legacy BIOS mode (which prevents the installation of Windows 11).

Conclusion and Future Developments

This script is a great starting point for a security baseline. In Enterprise environments, these checks can be integrated into a larger PowerShell module, perhaps executed via GPO or RMM, to generate a CSV report of all machines in the corporate fleet that are ready (or not) for the new OS rollout.

You can find this and other automation scripts on my GitHub.

Quando si gestisce un'infrastruttura IT, affidarsi a tool grafici "consumer" come l'app Controllo integrità PC di Microsoft per verificare la compatibilità a Windows 11 non è scalabile. Come sistemisti, abbiamo bisogno di strumenti automatizzabili, rapidi e che forniscano output testuali chiari da poter integrare in script di deploy più ampi.

I due requisiti più critici (e spesso bloccanti) per l'upgrade da Windows 10 a Windows 11 riguardano la sicurezza hardware: la presenza del TPM 2.0 (Trusted Platform Module) e l'abilitazione del Secure Boot a livello UEFI.

Ho scritto un rapido script in PowerShell che interroga direttamente il sistema operativo per estrarre queste informazioni senza dover riavviare la macchina o entrare nel BIOS/UEFI.

<#
.SYNOPSIS
    Verifica la prontezza del sistema per l'upgrade a Windows 11 (Focus su TPM e Secure Boot).
.DESCRIPTION
    Lo script controlla se il modulo TPM è presente, pronto e in versione 2.0.
    Verifica inoltre se il Secure Boot è abilitato nel firmware UEFI.
#>

Write-Host "=========================================" -ForegroundColor Cyan
Write-Host "  Verifica Requisiti Windows 11          " -ForegroundColor Cyan
Write-Host "=========================================`n" -ForegroundColor Cyan

# 1. Verifica TPM
Write-Host "[*] Controllo modulo TPM..."
try {
    $tpm = Get-Tpm
    if ($tpm.TpmPresent) {
        # La proprietà TpmReady indica se è pronto all'uso
        if ($tpm.TpmReady) {
            Write-Host "    [OK] TPM rilevato e pronto all'uso." -ForegroundColor Green
        } else {
            Write-Host "    [WARNING] TPM presente ma non inizializzato." -ForegroundColor Yellow
        }
    } else {
        Write-Host "    [ERRORE] Nessun modulo TPM rilevato sulla scheda madre." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERRORE] Impossibile interrogare il TPM. Assicurati di eseguire come Amministratore." -ForegroundColor Red
}

# 2. Verifica Secure Boot
Write-Host "`n[*] Controllo Secure Boot..."
try {
    $secureBoot = Confirm-SecureBootUEFI
    if ($secureBoot) {
        Write-Host "    [OK] Secure Boot abilitato nel firmware UEFI." -ForegroundColor Green
    } else {
        Write-Host "    [ERRORE] Secure Boot disabilitato. È necessario attivarlo nel BIOS/UEFI." -ForegroundColor Red
    }
} catch {
    Write-Host "    [ERRORE] Cmdlet non supportata o sistema in modalità BIOS Legacy (non UEFI)." -ForegroundColor Red
}

Write-Host "`n=========================================" -ForegroundColor Cyan
Write-Host "Controllo terminato." -ForegroundColor Cyan

Come funziona sotto il cofano?

Get-Tpm: È una cmdlet nativa di Windows che restituisce un oggetto contenente i dettagli del Trusted Platform Module. Verifichiamo TpmPresent e TpmReady per assicurarci non solo che il chip esista, ma che sia stato attivato correttamente a livello di sistema operativo.

Confirm-SecureBootUEFI: Questa cmdlet interroga direttamente le variabili firmware. Se restituisce True, il Secure Boot è attivo. Se lo script finisce nel blocco catch, è altamente probabile che il disco di sistema sia partizionato in MBR e avvii in modalità Legacy BIOS (che impedisce l'installazione di Windows 11).

Conclusioni e Sviluppi Futuri

Questo script è un ottimo punto di partenza per una baseline di sicurezza. In ambienti Enterprise, questi controlli possono essere integrati in un modulo PowerShell più grande, magari eseguito tramite GPO o RMM, per generare un report CSV di tutte le macchine del parco aziendale pronte (o meno) per il rollout del nuovo OS.

Trovate questo e altri script di automazione sul mio GitHub.