Unità 10 / 11

Confini, privacy, etica e divieto di utilizzo non autorizzato

Guadagni:

  • Comprendere che i dati sulla sicurezza sono sensibili a tre livelli (dati personali, intelligence aziendale, mappa delle vulnerabilità) e non possono essere forniti a uno strumento esterno senza anonimizzazione.
  • Ciò che distingue la difesa dall'attacco è l'autorità e l'intenzione; Essere in grado di far valere tale buona fede non sostituisce l'autorità e l'autorizzazione del veicolo non sostituisce la legalità.
  • Essere in grado di trasformare i dati di sicurezza in sorveglianza personale e prendere l'abitudine di chiedere "sono autorizzato, ho reso anonimo, lo scopo è difensivo" prima di ogni missione?

In questo modulo abbiamo utilizzato l'intelligenza artificiale in ogni aspetto del lavoro di un professionista della sicurezza: analisi dei registri, ricerca delle minacce, definizione delle priorità delle vulnerabilità, risposta agli incidenti, analisi del phishing, revisione del codice, intelligence sulle minacce, reporting. Questa unità si occupa delle linee tracciate attorno a tutti questi potenti usi. Perché il potere dell’intelligenza artificiale nella sicurezza informatica è duplice: la stessa capacità può essere utilizzata sia per la difesa che per l’attacco; Lo stesso accesso ai dati accelera e le perdite funzionano. Questa unità chiarisce la differenza tra "può" e "dovrebbe".

I limiti fondamentali sono due ed entrambi indiscussi. Il primo è la privacy e la protezione dei dati: i dati di sicurezza (log, IP, informazioni utente, codice, dettagli eventi) sono sia dati personali che informazioni sensibili che rivelano la superficie di attacco dell'organizzazione; Non va da nessuna parte senza protezione. In secondo luogo, etica e legalità: l’intelligenza artificiale viene utilizzata solo nei sistemi per i quali si è autorizzati, per scopi difensivi e con permesso scritto; L'accesso non autorizzato, la creazione di strumenti di attacco o i test non autorizzati sono un reato. Il titolo di questa unità non è uno slogan, è una licenza per la professione: una stampa non verificata è una rivendicazione, un utilizzo non autorizzato è un reato.

Privacy: perché i dati sulla sicurezza sono così sensibili?

I dati sulla sicurezza sono sensibili a tre livelli:

  1. Livello dati personali: nomi utente, e-mail, IP (che possono essere considerati dati personali in KVKK), record di accesso. È protetto da KVKK e GDPR.
  2. Livello di intelligence aziendale: topologia della rete interna, nomi dei server, schema di denominazione, quale sistema si trova e dove. Ciò fornisce all'aggressore una mappa dell'organizzazione.
  3. Livello di vulnerabilità: quali vulnerabilità sono aperte, quale sistema è vulnerabile. Questo è un elenco di obiettivi per l'aggressore nel caso in cui le informazioni trapelano.

Incollare un evento con il registro non elaborato, l'IP reale e i nomi dei server interni in uno strumento AI pubblico espone tutti e tre i livelli. Regola: prima anonimizzare, poi se possibile non divulgarlo affatto. Sostituisci i valori effettivi con segnaposto coerenti (USER_A, IC_IP_1, HOST_1); Se possibile, utilizza strumenti aziendali che dispongono di un contratto di elaborazione dati, non utilizzare i tuoi dati nella formazione del modello e preferibilmente lavora in sede. In alcuni casi (ad esempio indagini forensi in corso, dati top-secret) non vengono utilizzati strumenti esterni.

Etica e legalità: linea di difesa/attacco

Lo stesso know-how può essere utilizzato sia in modo difensivo che offensivo; l’autorità e l’intento determinano la differenza. Trovare e chiudere una vulnerabilità nel proprio sistema è una difesa; La ricerca nel sistema di qualcun altro senza autorizzazione costituisce un accesso non autorizzato. Analizzare un'e-mail di phishing è una difesa; Scrivere una dichiarazione di phishing convincente è un attacco. Esaminare un registro e rilevare un attacco è una difesa; La raccolta di dati per tracciare una persona è molesta e illegale.

La tabella seguente chiarisce questa linea:

azione

Difesa (legittima)

Attacco/divieto

Trovare una vulnerabilità

Nel proprio sistema, con il permesso, per chiudere

In quello di qualcun altro, senza permesso

Test di penetrazione

Con ambito e autorizzazione scritti

Test non autorizzati = attacco

Phishing

analizzare, rilevare

produrre, inviare

malware

Analisi (in isolamento)

scrivere, diffondere

raccolta dati

Per l'evento, completo, registrato

guardare, spiare la persona

Accesso

all'interno dell'autorità

non autorizzato = crimine

I moderni strumenti di intelligenza artificiale rifiutano già richieste come "scrivimi un ransomware funzionante" o "come faccio a infiltrarmi in quel sito"; Ma la responsabilità non è nel filtro del veicolo, bensì nella vostra etica professionale. L'uso non autorizzato non è legittimo se il veicolo lo consente.

La verifica: il pilastro tecnico dell'etica

La verifica non è solo un passo di qualità, è un imperativo etico. Scrivere un'accusa non provata in una relazione può significare accusare qualcuno ingiustamente o interrompere il lavoro con una decisione sbagliata. Ribadiamo la disciplina della verifica che abbiamo visto in tutto questo modulo come un principio etico qui: nessun rilievo, CIO, CVE, attribuzione o frase di rapporto prodotta dall'AI si trasforma in un'azione o un documento ufficiale senza essere confermato con prove grezze e una fonte ufficiale.

tre mini custodie

Caso 1 – Corretta anonimizzazione. Un analista vuole analizzare un incidente critico con l'intelligenza artificiale. Innanzitutto sostituisce tutti gli IP reali, i nomi utente e i nomi dei server interni con segnaposto coerenti, utilizza uno strumento di contratto di elaborazione dei dati aziendali e condivide solo il modello. L'analisi è più veloce, nessun dato sensibile viene divulgato. Questa è la strada giusta: velocità e privacy non devono necessariamente escludersi a vicenda.

Caso 2 – “Carità” non autorizzata. Un esperto “si chiede se l’azienda di un amico è sicura” e chiede all’IA come testare il sistema di quell’azienda. Sebbene ciò possa sembrare ben intenzionato, si tratta di un tentativo di accesso non autorizzato: testare il sistema di qualcun altro senza un permesso scritto e un ambito definito è un crimine. Modo corretto: nessun test; indirizzandolo al team di sicurezza dell'azienda o a un servizio di test di penetrazione autorizzato. La buona volontà non può sostituire l’autorità.

Caso 3 – Passaggio alla sorveglianza. Un manager vuole utilizzare l'intelligenza artificiale per profilare tutta l'attività di un dipendente dai registri di sicurezza per capire se quella persona è "fedele" o meno. Ciò va oltre lo scopo della sicurezza e si estende alla sorveglianza personale; Viola KVKK e supera il limite di utilizzo legittimo dei dati di sicurezza. Il professionista della sicurezza respinge e indirizza la richiesta al canale appropriato (risorse umane, legale, quadro investigativo definito). Lezione: i dati di sicurezza vengono raccolti per sicurezza; Non è uno strumento di sorveglianza personale.

Prompt debole / Prompt forte

Suggerimento debole:

Analizzare tutta l'attività di Ahmet Yılmaz (10.2.14.7) negli ultimi 3 mesi, se ha fatto qualcosa di sospetto, creare un profilo della personalità.

Questa richiesta prende di mira una persona reale, fornisce dati personali senza maschera, va oltre gli scopi di sicurezza e scivola nella sorveglianza e richiede un output illegittimo come un "profilo della personalità". È sia una violazione della KVKK che una violazione etica.

Suggerimento potente:

Il tuo ruolo: assistente che redige l'analisi della sicurezza per l'analista. Lavorare con dati anonimizzati nell'ambito di un'indagine sull'incidente definita. Compito: esiste un'anomalia nel modello di accesso di USER_A nella finestra dell'evento definita (03:00-04:00) compatibile con l'ipotesi di fuga di dati? Non commentare la personalità/lealtà; basta valutare il modello tecnico in base alle prove. Non rinunciare. Dati: [anonimo, solo finestra pertinente]

La richiesta forte è anonima, limitata a un ambito di indagine definito, non richiede interpretazione personale, funziona solo con i dati pertinenti e il modello tecnico.

Modelli di prompt copiabili

MODELLO DI AUDIT DI ANONIMIZZAZIONEControlla i seguenti dati prima di fornirli a uno strumento AI esterno: sono presenti IP reali, nome utente, e-mail, nome host/server interno, nome di dominio, informazioni aziendali, dati personali? Elencali tutti e suggerisci segnaposto coerenti. Avvisare se c'è qualcosa di sospetto. Dati: [incolla]

MODELLO DI CONTROLLO DELL'AMBITO E DELL'AUTORITÀVerifica il compito di sicurezza che svolgerò: rientra nei limiti del sistema per cui sono autorizzato, rientra nell'ambito di uno scopo/indagine definito, si sposta alla sorveglianza personale, richiede un'autorizzazione scritta? Se c’è un segnale d’allarme, avvisa e suggerisci un’alternativa legittima. Compito: [scrivere]

MODELLO DI PROMEMORIA DEL CONFINE ETICO Valutare la richiesta: è difensiva e autorizzata o rientra nel confine di accesso/attacco/sorveglianza non autorizzati? Se è legittimo, scrivi come farlo in sicurezza, in caso contrario, perché non dovrebbe essere fatto e il canale corretto.Richiesta: [scrivi]

MODELLO DI REQUISITO DI VERIFICA Per ogni rilievo, CIO, CVE, attribuzione e frase di relazione prodotta, aggiungere una nota "con quale prova grezza/fonte ufficiale deve essere verificata". Supponiamo che non diventerà un'azione o un documento ufficiale finché non sarà verificato. Compito: [scrivere]

Errori comuni

  • Bypassare l'anonimizzazione. È sbagliato dire “comunque uso interno”; Qualsiasi IP/utente/host effettivo dello strumento AI esterno è una perdita.
  • Confondere le buone intenzioni con l'autorità. “Volevo aiutare” non giustifica l’accesso non autorizzato; Sono richiesti il ​​permesso scritto e l'ambito definito.
  • Trasformare i dati sulla sicurezza in sorveglianza. I registri vengono raccolti per motivi di sicurezza; La profilazione/monitoraggio di una persona costituisce una violazione della KVKK e un abuso.
  • Pensare che il permesso del veicolo sia legittimo. Solo perché l’IA non rifiuta qualcosa, quell’azione non è legale/etica; La responsabilità è tua.
  • Considerare la verifica come un lusso. Un'accusa senza prove può accusare qualcuno ingiustamente o interrompere il lavoro; la verifica è un obbligo etico.
Suggerimento: porre tre domande prima di qualsiasi attività: "Sono autorizzato in questo sistema? Ho reso anonimi questi dati? Lo scopo è difensivo o di sorveglianza/offensivo?" Se non riesci a dire chiaramente "sì/difesa" a tutti e tre, fermati e consulta qualcuno che abbia autorità.
Attenzione: accesso non autorizzato, test non autorizzati, pirateria informatica e sorveglianza personale; Anche se fatto con buone intenzioni, è un crimine ed esula da questa professione. Il potere dell'IA non cambia questa linea, ne aumenta solo la velocità se usato in modo errato. Il limite non è tecnico, ma legale ed etico.

In sintesi

Questa unità ha tracciato linee indiscusse attorno ai potenti usi appresi durante il modulo. Ci sono due limiti: riservatezza (i dati di sicurezza sono dati personali + intelligence aziendale + mappa delle vulnerabilità; non divulgati senza anonimizzazione, se possibile) ed etica/legalità (l'intelligenza artificiale viene utilizzata solo in sistemi autorizzati, per scopi difensivi, con permesso scritto). Ciò che distingue la difesa dall'attacco è l'autorità e l'intento; La buona fede non sostituisce l’autorità, né l’autorizzazione del veicolo sostituisce la legalità. La verifica non è solo qualità, è un obbligo etico che impedisce accuse senza prove e decisioni sbagliate. Tre domande prima di ogni missione: sono autorizzato, ho anonimizzato, lo scopo è difensivo?

Compito dell'applicazione

Scegli tre delle attività apprese nel modulo (ad esempio analisi dei log, analisi del phishing, indagine sugli incidenti). Applica i modelli “Controllo ambito e autorizzazione” e “Controllo anonimizzazione” per ciascuno: sei autorizzato, come anonimizzerai i dati, lo scopo è borderline difensivo? Quindi scrivi una richiesta di esempio che supera il limite (non autorizzata/sorveglianza) e documenta il motivo per cui dovrebbe essere rifiutata e qual è il canale corretto con il modello "Promemoria limite etico".

lista di controllo

  • [ ] In ogni ruolo, ho lavorato solo sui sistemi per i quali ero autorizzato.
  • [ ] Ho reso anonimi e analizzato i dati prima di fornirli allo strumento esterno.
  • [ ] Ho confermato che lo scopo è la difesa, non la sorveglianza/attacco.
  • [ ] Non ho sostituito la buona volontà con l'autorità, né il permesso del veicolo con la legalità.
  • [ ] Ho rifiutato le richieste di profilazione/tracciamento personale e le ho indirizzate al canale corretto.
  • [ ] Non ho messo in atto ogni constatazione/CIO/CVE/citazione/reclamo senza verificarlo.
  • [ ] Nel dubbio mi sono rivolto a qualcuno con autorità (legale, amministrativa, titolare del trattamento).