Information Security

L'infrastruttura tecnologica di un'azienda deve consentire all'azienda di connettersi con i clienti, interagire con fornitori e partner, migliorare la produttività della forza lavoro e ottimizzare le attività di back-office. Inoltre, questa infrastruttura richiede misure di sicurezza che proteggono le risorse informative e garantiscono la disponibilità del sistema. Oggi, le organizzazioni devono gestire i propri dispositivi di sicurezza per ottenere sia la sicurezza dell'esclusione (tenendo fuori gli intrusi) sia la sicurezza dell'inclusione (consentendo agli utenti autorizzati di utilizzarli).

■ Componenti dell'infrastruttura tecnologica di sicurezza. Quando si pianifica la sicurezza dell'infrastruttura tecnologica, le organizzazioni devono garantire la sostenibilità operativa e la sicurezza fisica dell'infrastruttura. Le organizzazioni devono inoltre considerare i requisiti di sicurezza della rete e del perimetro, piattaforme e applicazioni e i relativi archivi di dati associati. Inoltre, poiché sempre più organizzazioni distribuiscono servizi Web per progetti di integrazione interni ed esterni, devono anche comprendere i requisiti di sicurezza unici per questa tecnologia emergente.

SOSTENIBILITÀ OPERATIVA

La sicurezza dell'infrastruttura dipende dal concetto di sostenibilità operativa; ovvero, utilizzando un approccio coerente per l'implementazione di componenti dell'infrastruttura e garantendo una capacità sufficiente per stabilire un'infrastruttura robusta, scalabile e altamente disponibile. Le organizzazioni possono utilizzare dei supervisore delle prestazioni e della capacità, i controlli sull'utilizzo delle risorse e i calcoli dell'utilizzo previsto delle risorse per aiutarli a stabilire una capacità adeguata. Meccanismi come bilanciamento del carico, dispositivi di fail-over e sistemi di gestione della rete aiutano a mantenere un'elevata disponibilità. La sostenibilità operativa fornisce anche operazioni di supporto comuni per il backup, il disaster recovery e la replica.

SICUREZZA FISICA

La sicurezza fisica si riferisce al controllo dell'accesso a risorse fisiche come edifici, computer e documenti cartacei. Queste risorse possono contenere informazioni critiche o fornire accesso alle risorse di rete. Quando si implementa la sicurezza fisica, le organizzazioni dovrebbero considerare il livello appropriato di sicurezza e accesso a luoghi come il sito, gli edifici, le sale computer e i centri dati e come monitorare la struttura. Inoltre, le organizzazioni devono definire metodi per proteggere i supporti rimovibili e l'archiviazione dei dati offline e determinare come etichettare e proteggere i documenti che devono rimanere riservati.

SICUREZZA DELLA RETE

La sicurezza di rete si concentra sulle tecnologie che compongono la rete aziendale, nonché sul confine dell'infrastruttura tecnologica di un'azienda, dove si connette a Internet. Le organizzazioni devono anche considerare la sicurezza delle loro reti wireless. Fornendo accesso controllato alle risorse di rete e facilitando la prevenzione e il rilevamento di attacchi a basso livello, le organizzazioni possono abilitare l'accesso e proteggere le risorse nelle proprie reti informatiche.

PIATTAFORMA DI SICUREZZA

La sicurezza della piattaforma si concentra sulla sicurezza dei sistemi operativi sottostanti, come le versioni client e server di Windows, UNIX, Linux e OS / 400. La sicurezza a questo livello fornisce controlli di accesso utente dettagliati, autorizzazioni e opzioni di configurazione. Stabilendo elenchi di controllo di accesso restrittivi (ACL) e definendo le impostazioni di sicurezza, controllo e registrazione, le organizzazioni possono migliorare il rilevamento e la prevenzione degli attacchi ai sistemi operativi. Inoltre, la riduzione delle funzionalità del sistema operativo al minimo richiesto può aiutare a rafforzare le piattaforme. Altre tecniche per migliorare la sicurezza della piattaforma includono la definizione dei parametri di accesso e di utilizzo, la definizione di un insieme restrittivo di servizi e configurazioni di servizi, la limitazione dei punti di accesso al sistema e la definizione di politiche di blocco e password.

DATA STORE SECURITY

La sicurezza dell'archivio dati si concentra sulla sicurezza di database, directory e altri repository di informazioni aziendali. Le organizzazioni possono abilitare il livello appropriato di accesso e autorizzazioni agli archivi dati utilizzando i meccanismi di autenticazione; definire utenti, applicazioni e servizi di rete autorizzati ad accedere ai dati; e monitoraggio, controllo e registrazione di tutte le attività riguardanti l'accesso ai dati, l'aggiornamento e la cancellazione. La sicurezza dell'archivio dati fornisce anche meccanismi per proteggere l'integrità, l'accuratezza e la completezza dei dati.

SICUREZZA DELL'APPLICAZIONE

La sicurezza delle applicazioni si riferisce a opzioni di sicurezza, impostazioni e configurazioni per mainframe, client / server tradizionali e applicazioni Web. La sicurezza a questo livello consente l'accesso alle persone che hanno il livello appropriato di accesso utente e il permesso di utilizzare le applicazioni. La sicurezza dell'applicazione include anche la protezione dell'archivio dati utilizzato dall'applicazione. Le organizzazioni stanno iniziando a distribuire servizi Web per progetti di integrazione delle applicazioni e a utilizzarli come meccanismo per esporre funzionalità limitate di applicazioni sia agli utenti interni che a quelli esterni. Poiché i servizi Web sono una tecnologia basata sugli standard non ancora collaudata e in continua evoluzione, i problemi di sicurezza relativi ai servizi Web richiedono un'attenzione speciale e un approccio multiforme.

■ Sicurezza della rete. Si concentra sulle tecnologie e sulla sicurezza che circondano le tecnologie che costituiscono la rete aziendale. Un approccio comune alla sicurezza della rete consiste nel circondare una rete non sicura con un perimetro difensivo che controlla l'accesso alla rete. Una difesa perimetrale è funzionale come parte di una difesa generale. Tuttavia, una volta passato il perimetro, un utente non è vincolato e può causare un danno intenzionale o accidentale. La rete è completamente vulnerabile se una parte ostile accede a un sistema all'interno del perimetro o compromette un singolo utente autorizzato. Una combinazione di strumenti di sicurezza, inclusi firewall, sistemi di rilevamento delle intrusioni (IDS), sistemi di prevenzione delle intrusioni (IPS) e reti private virtuali (VPN), contribuisce a garantire la sicurezza perimetrale e di rete. Le azioni intraprese dal firewall si basano sulle definizioni stabilite quando il firewall è configurato e sono determinate dalla politica di sicurezza aziendale articolata in termini di utenti, accesso alle risorse e utilizzo Internet accettabile. Ad esempio, se un'organizzazione decide che le comunicazioni da determinati indirizzi IP potrebbero non accedere alla rete dell'organizzazione, la configurazione del firewall garantirà che il traffico proveniente da quel punto di origine venga negato.

Distribuzione del firewall

L'implementazione e l'implementazione del firewall sono diventate una pratica comune poiché la maggior parte delle aziende e organizzazioni sviluppa queste funzionalità a vari livelli, a seconda delle esigenze. Cambiamenti significativi nelle tecnologie di sicurezza e una tendenza verso i dispositivi di appliance (pacchetti hardware e software integrati e standalone con un sistema operativo integrato) hanno portato all'aggiunta di diverse funzionalità ai firewall. Tuttavia, i principi fondamentali nella distribuzione di un firewall rimangono gli stessi, come discusso nelle sezioni seguenti.

Risorse.

Una buona implementazione del firewall inizia sempre con una completa comprensione delle risorse (processi aziendali, dati e proprietà intellettuale) che un'organizzazione deve proteggere. In base alle minacce e ai rischi corrispondenti coinvolti, la protezione firewall deve essere commisurata al livello di rischio. Inoltre, i requisiti legali e normativi devono essere presi in considerazione, in particolare in alcuni settori industriali come i servizi finanziari e l'assistenza sanitaria. In genere, i firewall che si trovano di fronte a una rete pubblica come Internet richiederebbero il massimo livello di protezione, soprattutto quando si protegge una grande rete aziendale.

Politica di sicurezza

La politica del firewall dovrebbe dettare il livello di protezione richiesto e l'implementazione tecnica dettagliata, come le applicazioni oi protocolli consentiti o negati, gli indirizzi IP di origine o destinazione consentiti o negati, il livello di autenticazione richiesto e il livello di monitoraggio e registrazione richiesti. In particolare, nelle grandi aziende la creazione di politiche firewall dovrebbe includere la comunità IT aziendale e il feedback, poiché la progettazione e l'implementazione dei processi aziendali critici (come l'e-commerce e le attività business-to-business) si basano su una connettività di rete onnipresente. Una volta stabilite, le policy del firewall dovrebbero essere riviste periodicamente (e in base alle necessità) e aggiornate in base alle nuove minacce e ai requisiti aziendali.

Architettura firewall

Sulla base del profilo di rischio e della politica di sicurezza stabiliti, l'architettura del firewall deve essere sviluppata tenendo in considerazione i requisiti operativi, le risorse protette, le reti a cui saranno esposte le risorse protette, le aspettative di rendimento, la crescita prevista e l'interoperabilità con le applicazioni esistenti e previste.Data la gamma di firewall e fornitori sul mercato, il processo di selezione deve essere rigoroso e accurato per evitare problemi futuri.

Operazioni e gestione.

Senza adeguate procedure operative in grado di rilevare, tracciare e contrastare gli attacchi, le aziende e le organizzazioni sono a rischio. Una solida politica operativa incorporerà e attuerà adeguatamente (in base ai livelli di rischio) almeno questi requisiti minimi: auditing e registrazione degli eventi; monitoraggio in tempo reale degli eventi utilizzando un appropriato software di gestione della rete; backup e ripristino; verifiche periodiche dell'integrità con l'utilizzo di software di integrità (ad es. Tripwire); procedure di gestione delle modifiche e della configurazione per l'esecuzione delle modifiche ai criteri del firewall; e rapporti di gestione periodici.

Minacce e vulnerabilità.

Le nuove minacce e vulnerabilità che colpiscono sistemi e firewall sono scoperte quotidianamente e possono causare gravi danni, chiudendo efficacemente l'ambiente di elaborazione aziendale di un'organizzazione. Le operazioni firewall di un'organizzazione devono includere le procedure in base alle quali le minacce e le vulnerabilità scoperte di recente vengono esaminate in base alle esigenze e vengono applicate immediatamente contromisure appropriate (come patch, correzioni rapide e definizioni dei virus). Diverse organizzazioni (in particolare il Computer Emergency Response Team o CERT) e i fornitori forniscono servizi di intelligence di sicurezza quando vengono scoperte nuove vulnerabilità.

Risposta agli incidenti di sicurezza.

Una procedura efficace di risposta agli incidenti fornisce una road map per le azioni da eseguire quando il monitoraggio in tempo reale ha stabilito che un potenziale compromesso del firewall è in corso o si è verificato. Determinando i tipi di azioni richieste per i livelli di attacchi e compromessi, un'organizzazione può continuare a svolgere le funzioni aziendali chiave, minimizzare i danni e difendersi efficacemente dagli attacchi.

Servizi di firewall gestiti.

Anche se una volta è stata attribuita notevole stigmatizzazione alle funzioni di esternalizzazione della sicurezza, un'attività significativa si è verificata di recente nel mercato dell'outsourcing. Questa tendenza può essere attribuita alla crescente accettazione dell'outsourcing in generale, alla situazione economica nel 2003 e alla maturità dei fornitori di outsourcing della sicurezza. Le operazioni e la gestione del firewall sono ormai consolidate e le funzioni banali che le società esternalizzano a fornitori qualificati che possono trarre vantaggio dalle economie di scala per il monitoraggio e la difesa da attacchi nuovi e complessi. Prima dell'outsourcing, è necessario tenere in debita considerazione le qualifiche dei fornitori, la valutazione da parte di terzi indipendenti (ad esempio, la conduzione di un audit SAS 70 del data center del fornitore) e le condizioni dei contratti e degli accordi sul livello di servizio (SLA).

Prodotti e tecnologie firewall

I firewall possono essere impacchettati come software di sistema, hardware e software combinati o dispositivi hardware dedicati. I firewall aziendali utilizzano in genere una combinazione di hardware e software che fornisce alta disponibilità, throughput elevato e meccanismi per la gestione centralizzata del sistema firewall. La gestione centralizzata diventa particolarmente importante quando le grandi imprese utilizzano molti firewall in diversi luoghi fisici. Le appliance firewall semplificano le attività di installazione e gestione e sono adatte per organizzazioni con risorse limitate. I firewall software vengono spesso utilizzati per proteggere singoli computer in ambienti più piccoli. Le tecnologie firewall operano su diversi livelli del modello di riferimento OSI (Open Systems Interconnection) per il processo di comunicazione. A livello di rete, un firewall può limitare il flusso di pacchetti in base agli attributi del protocollo. L'indirizzo di origine del pacchetto, l'indirizzo di destinazione, la porta TCP / UDP (Transmission Control Protocol / User Datagram Protocol), la porta di destinazione e il tipo di protocollo originario vengono utilizzati per queste decisioni di controllo.
A livello di applicazione, un firewall può partecipare alle comunicazioni tra le applicazioni di origine e di destinazione e il firewall baserà le sue decisioni di controllo sui dettagli della conversazione (ad esempio, rifiutando tutte le conversazioni che trattano di un argomento specifico o utilizzare una parola chiave con restrizioni ) e altre informazioni disponibili come la precedente connettività o l'identificazione dell'utente. La maggior parte dei prodotti firewall utilizza una combinazione di tecniche e tecnologie per fornire un meccanismo di sicurezza. Le tecniche comuni includono i proxy a livello di applicazione, i gateway di filtraggio dei pacchetti e l'ispezione stateful. Il filtraggio dei pacchetti funziona a livello di rete (livello 3) del modello OSI, dove può monitorare le connessioni in entrata e in uscita. Proxy a livello di applicazione e stateful   le tecnologie di ispezione possono essere applicate attraverso il livello dell'applicazione (Livello 7). L'ispezione stateful controlla lo stato del flusso di comunicazione e i proxy a livello di applicazione esaminano l'intestazione del pacchetto e i dati dell'applicazione nel pacchetto. Attacchi come i worm Nimda e SQL Slammer stanno aumentando la necessità di un'ispezione più approfondita del contenuto dell'applicazione.
Proxy a livello di applicazione. I proxy a livello di applicazione sono programmi software che inoltrano il traffico per un'applicazione o un servizio specifici come Telnet, FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), HTTP (Hypertext Transfer Protocol) o NNTP (Network News Transport Protocol) ). In questo tipo di firewall, un'applicazione client esterna al firewall (come Telnet o FTP) comunica con il server proxy anziché direttamente con i server delle applicazioni protetti. Il firewall proxy a livello dell'applicazione può controllare la comunicazione dell'applicazione, ad esempio intercettando il traffico dei messaggi e chiedendo un'autenticazione forte prima di consentire la prosecuzione della conversazione. Poiché non avviene alcuna connessione di rete diretta tra le reti esterne e il server protetto, il sistema protetto è protetto da attacchi a livello di rete come l'attacco denial of service di Ping of Death. L'intercettazione della connessione inerente ai proxy a livello di applicazione rende questa tecnica firewall più sicura rispetto ai filtri a pacchetto, ma l'intercettazione della connessione può rallentare le prestazioni della rete. Inoltre, ogni applicazione di rete richiede uno specifico proxy dell'applicazione. Poiché lo sviluppo di proxy può richiedere molto tempo e le esigenze aziendali potrebbero essere molto specifiche, la maggior parte dei pacchetti commerciali include solo i principali servizi Internet.   Un gateway a livello di circuito è un caso speciale di un gateway basato su proxy in cui non esiste un proxy specifico per le applicazioni. In questo caso, il gateway non esegue alcuna funzione di controllo a livello di protocollo dell'applicazione, ma piuttosto passa il traffico in modo trasparente per una determinata applicazione. Generalmente un gateway a livello di circuito viene utilizzato come parte di un gateway che esegue funzionalità proxy a livello di applicazione; Ignora essenzialmente le funzioni di controllo del gateway per una particolare applicazione che non è considerata una minaccia per la sicurezza e per la quale non esiste alcun proxy specifico dell'applicazione. Uno dei relè di circuito più diffusi è SOCKS (per SOCKetS), un protocollo a livello di circuito sviluppato nel 1990 e supportato dall'Internet Engineering Task Force (IETF). SOCKS fornisce un canale di dati proxy protetto per il traffico di rete e può essere utilizzato in combinazione con o come firewall standalone a livello di circuito. SOCKS stabilisce un canale sicuro e autenticato indipendentemente dall'applicazione o dal protocollo richiesto. La workstation client deve essere in esecuzione software che gli consenta di negoziare con il server SOCKS; questo requisito di installazione del software client è uno dei motivi per cui i gateway a livello di circuito non sono ampiamente utilizzati nelle aziende.

Gateway di filtraggio dei pacchetti.

A differenza dei proxy a livello di applicazione, che aggiungono sicurezza monitorando e possibilmente alterando la comunicazione tra applicazioni, un gateway di filtraggio dei pacchetti controlla il traffico ai livelli di rete (IP) e di trasporto (TCP) (Layer 3 e Layer 4). I gateway di filtraggio dei pacchetti esaminano gli indirizzi di origine e destinazione dei pacchetti di dati, le porte del servizio di origine e di destinazione, i tipi di pacchetto e le opzioni di pacchetto. I pacchetti ricevuti da questi gateway di filtro sono consentiti o negati in base a un ACL, un meccanismo utilizzato per implementare la politica di sicurezza del sito (ad esempio, negare tutti i messaggi del timeserver in entrata bloccando la porta TCP 525). (Vedere Figura 24.) Un firewall filtrante pacchetti non può impedire tutti gli attacchi a livello di rete contro il server protetto. Ad esempio, se una regola basata su ACL non è impostata per una particolare classe di traffico, il firewall sarà inefficace rispetto al traffico IP indefinito.Inoltre, un firewall con filtraggio dei pacchetti non esamina le informazioni di livello superiore come l'autenticazione dell'utente o le attività all'interno della conversazione dell'applicazione e quindi può consentire a un utente malintenzionato di entrare nel perimetro. Tuttavia, l'elaborazione ridotta per pacchetto significa che un gateway per il filtraggio dei pacchetti supera in genere un firewall a livello di applicazione.

Stateful inspection.

La stateful inspection è una tecnica avanzata di filtraggio dei pacchetti che opera tra il livello di collegamento dati (livello 2) e il livello di rete (livello 3) del modello OSI. I filtri possono essere applicati per consentire l'ispezione attraverso tutti e sette i livelli. Ispezione con stato esamina le informazioni di intestazione e confronta i dati con una tabella di stato creata per ciascun servizio. Questa tabella tiene traccia delle connessioni in entrata e in uscita e dello stato della conversazione. Se l'utente tenta un'azione non registrata nella tabella o per la quale non sono state concesse le autorizzazioni, l'utente viene rifiutato. Questa tecnica è più efficiente dell'utilizzo di un proxy per applicazioni specifiche. Essa ricompone i pacchetti TCP e IP frammentati e li esamina prima di permetterli attraverso il firewall. Questo riassemblaggio garantisce che i pacchetti frammentati di connessioni legittime non vengano eliminati e che gli attacchi nascosti in pacchetti frammentati vengano rilevati e bloccati. Questo tipo di ispezione funziona bene con protocolli complessi, può essere facilmente estesa per supportare nuovi servizi e funziona meglio in ambienti in cui l'impatto delle tecnologie di sicurezza sulle prestazioni della rete è una considerazione chiave. Per comprendere appieno il contesto della comunicazione, tuttavia, un firewall che utilizza la stateful inspection potrebbe dover lasciare passare un pacchetto o due prima che l'analisi sia completata.

Ispezione profonda dei pacchetti.

Mentre la stateful inspection analizza il pacchetto a vari livelli del modello OSI, in genere non analizza i dati a pacchetto. La nuova tecnica di ispezione dei pacchetti profondi funziona come un IDS (discusso di seguito) e analizza il payload di un'applicazione di un pacchetto (il suo contenuto) e tenta di identificare e bloccare il codice dannoso. L'ispezione approfondita dei pacchetti utilizza tecniche come l'ispezione della firma e il contenuto   visita medica. Solo pochi prodotti commercialmente disponibili a partire da ottobre 2003 includono l'ispezione approfondita dei pacchetti, ma ci si aspetta che più fornitori includano questa funzionalità in futuro.

Tendenze del firewall

I prodotti firewall stanno sviluppando una maggiore integrazione, utilizzando una combinazione di tecnologie per fornire più funzionalità e facilitare l'interoperabilità dei componenti di sicurezza in tutta l'infrastruttura. Molti firewall includono la tecnologia VPN, in cui viene creato un tunnel sicuro attraverso la rete esterna tramite una connessione crittografata tra i firewall per accedere in modo trasparente alla rete interna protetta. Ci si aspetta che altri firewall incorporino le tecnologie utilizzate negli IDS attuali. Le funzionalità firewall a livello di applicazione stanno diventando sempre più importanti poiché le operazioni aziendali richiedono un maggiore accesso alle informazioni. Inoltre, è previsto un crescente utilizzo di firewall personali lato client nelle aziende.

Firewall dell'applicazione.

I firewall tradizionali controllano il traffico a livello di rete. Anche i firewall proxy a livello di applicazione, che controllano il traffico a livello di applicazione, in genere non eseguono un controllo dettagliato a livello di applicazione.
Una recente ondata di attacchi a livello di applicazione ha utilizzato il protocollo Web standard HTTP, che può passare attraverso un firewall standard fino a quando il protocollo è consentito dalla politica. Per difendersi da tali attacchi, le organizzazioni hanno sempre più utilizzato i firewall delle applicazioni, che ispezionano i pacchetti a livello di applicazione e intercettano gli exploit a livello di applicazione. Questi firewall forniscono un ulteriore e forte livello di sicurezza, in particolare quando si proteggono le applicazioni Web e le farm di hosting Web critiche.

Apparecchi di sicurezza integrati.

Poiché le aziende richiedono velocità di connessione avanzate a Internet e funzionalità di sicurezza avanzate, e poiché i firewall risiedono in genere in punti panoramici sulla rete, i fornitori di firewall stanno incorporando sempre più funzionalità come il rilevamento delle intrusioni e la prevenzione nei dispositivi firewall. Prima di distribuire tali dispositivi, gli amministratori dovrebbero considerare fattori come la postura e le prestazioni complessive della sicurezza.

Firewall basati su hardware.

Nei firewall basati su hardware, la logica del firewall è incorporata nell'hardware (i firewall tradizionali incorporano la logica nel software). Questo approccio basato sull'hardware, che è diventato più diffuso negli ultimi anni, aiuta a migliorare significativamente le prestazioni del firewall.

Confini di rete tradizionali sfocati.

Le applicazioni business-to-business e di e-commerce hanno causato un aumento significativo dell'attività di rete che ha origine al di fuori dei confini della rete aziendale. Per soddisfare tali richieste e fornire adeguati livelli di protezione, le aziende devono riprogettare i loro firewall e fornire zone neutrali tra reti pubbliche e private (le cosiddette zone demilitarizzate o DMZ). Questa sfocatura dei confini della rete ha anche forzato una tendenza verso l'autenticazione avanzata, l'autorizzazione e la sicurezza a livello di host.

Firewall personali.

I firewall personali o lato client sono diventati una necessità in quanto più persone si connettono a Internet utilizzando tecnologie a banda larga che hanno una connessione persistente. I firewall personali sono in genere una versione ridotta dei firewall tradizionali. Molte aziende che incoraggiano i dipendenti a connettersi alle reti aziendali tramite servizi VPN su Internet implementeranno anche software di applicazione delle policy. In sostanza, se il sistema dell'utente finale non soddisfa un livello accettabile di sicurezza definito dalla società, l'accesso alla rete aziendale tramite la VPN non è consentito.

Firewall wireless.

Le reti wireless, se non implementate con i controlli di sicurezza, forniscono agli utenti non autorizzati un metodo semplice per accedere alle reti aziendali e questo accesso non può essere facilmente rilevato o controllato. La funzionalità firewall che protegge le reti aziendali dagli attacchi tramite reti wireless può essere trovata in diversi router wireless di fascia alta utilizzati per la distribuzione aziendale. I firewall possono anche essere implementati come ulteriore livello di sicurezza tra la rete aziendale e il router wireless.

SISTEMI DI RILEVAMENTO DELL'INTRUSIONE

Un sistema di rilevamento delle intrusioni (IDS) è un tipo di sistema di gestione della sicurezza per computer e reti. Raccoglie e analizza le informazioni provenienti da varie aree all'interno di un computer o di una rete per identificare possibili violazioni della sicurezza, incluse le intrusioni (attacchi esterni all'organizzazione) e l'uso improprio (violazioni delle policy all'interno dell'organizzazione) - preferibilmente in tempo reale.

Le funzioni IDS includono:
• Monitoraggio e analisi delle attività dell'utente e di sistema

• Analisi delle configurazioni di sistema

• Valutazione del sistema e integrità del file

• Riconoscimento di modelli tipici di attacchi

• Analizzando i modelli di attività anormali

• Monitoraggio delle violazioni delle policy degli utenti Gli IDS hanno avuto sovrapposizioni con la funzionalità dei firewall, ma i due sono stati considerati servizi complementari, poiché entrambe le tecnologie sono necessarie per l'applicazione e il monitoraggio costante di una strategia di sicurezza completa. Le tendenze attuali indicano che i firewall presto incorporeranno più funzionalità IDS, migliorando i firewall e contribuendo a superare le carenze di IDS.

Gli IDS possono essere caratterizzati dai seguenti attributi chiave: ubicazione dell'origine di controllo, metodo di rilevamento, comportamento al rilevamento e frequenza di utilizzo.
Audit Source Location L'approccio più comune consiste nel categorizzare gli IDS sulla base della fonte di audit degli eventi monitorati. Le due principali fonti di dati di audit sono gli host e la rete. Un IDS basato su host si basa su log di sistema e audit trail, mentre un IDS basato su rete campiona il flusso di eventi di rete. Alcuni IDS sono soluzioni ibride, che comprendono le caratteristiche e le funzionalità desiderabili sia dei sistemi basati su host che di quelli basati su rete.
IDS basati su host. Questi IDS richiedono l'installazione di software sul sistema da monitorare. La principale fonte di informazioni sull'attività dell'utente per un IDS basato su host è l'insieme di record di controllo dal sistema informatico. Gli IDS basati su host possono essere distribuiti come pacchetti indipendenti su sistemi chiave o come software basato su agente distribuito con una stazione di monitoraggio centrale separata. Un sensore IDS basato su applicazione è basato su host e utilizza i file di registro delle transazioni di un'applicazione per analizzare eventi all'interno di un'applicazione software. Nella selezione degli IDS basati su host, è necessario considerare i seguenti punti:
• I registri di controllo potrebbero non arrivare in modo tempestivo, poiché alcuni IDS utilizzano un computer separato per eseguire l'analisi.

• Il sistema di audit stesso può essere vulnerabile perché gli intrusi possono disattivare il sistema di audit o modificare i record di audit per nascondere le loro intrusioni.

• I registri di controllo non possono contenere informazioni sufficienti per rilevare determinati tipi di intrusioni.

• Possono insorgere implicazioni sulla privacy e regolamenti relativi al monitoraggio e al mining dei dati dell'utente. IDS basati su rete. Questi IDS monitorano il traffico su un segmento di rete. Il sensore del dispositivo di monitoraggio è in genere un computer o dispositivo in una posizione strategica sulla rete e può visualizzare solo i pacchetti trasportati sul segmento di rete a cui è collegato. I pacchetti sono considerati di interesse se corrispondono a una firma. Esistono tre tipi principali di firme:
• String signature: una stringa di testo che indica un possibile attacco.

• Firma della porta: un tentativo di connessione a una porta nota e frequentemente attaccata. • Firma delle condizioni dell'intestazione: combinazione pericolosa o illogica in un'intestazione di pacchetto.
Un intruso potrebbe essere in grado di eludere il rilevamento frammentando abilmente i pacchetti o attraverso attacchi collaborativi. La necessità di ispezionare i pacchetti e il loro contenuto limita l'efficacia dei sistemi basati su rete negli ambienti VPN perché non sono in grado di rilevare un tentativo di intrusione perpetrato attraverso una connessione crittografata.
IDS ibridi. Gli IDS ibridi combinano funzionalità di rilevamento delle intrusioni basate su host e rete che monitorano i pacchetti di rete per gli attacchi di IP spoofing e packet flooding con i prodotti di analisi dei log che vengono eseguiti sugli host e monitorano i log di sistema. I sistemi ibridi rilevano attacchi su reti e sistemi. Questo tipo di soluzione integrata offre agli amministratori IT una visione più completa degli attacchi in tutta l'azienda e l'interfaccia comune e la console di monitoraggio centrale aumentano la probabilità di rilevare gli attacchi.

Metodi di rilevamento

Oltre alla classificazione della fonte di audit, gli IDS possono anche essere classificati mediante i metodi di rilevamento utilizzati per identificare attività anomale: rilevamento di anomalie (o comportamento) e uso improprio (o basato sulla conoscenza). Il metodo di rilevamento è il nucleo di un IDS e descrive l'approccio utilizzato per identificare i problemi.
Rilevamento dell'anomalia. Spesso definito come rilevamento basato sul comportamento, il rilevamento delle anomalie consiste nello stabilire profili di comportamento normali per gli utenti e l'attività del sistema e nell'osservare le deviazioni significative dai modelli normali stabiliti. Le deviazioni significative sono contrassegnate come anomale e dovrebbero destare sospetti. Idealmente, l'uso quotidiano di un sistema informatico da parte di un determinato utente segue un modello di comportamento riconoscibile che può servire come caratterizzazione dell'identità dell'utente e dell'attività del sistema prevista. Poiché il profilo di attività normale di un utente può cambiare nel tempo man mano che impara nuovi comandi e acquisisce maggiore familiarità, il suo profilo stabilito deve essere aggiornato continuamente per adattarsi ai cambiamenti di comportamento.
È possibile considerare i profili di comportamento delle applicazioni anziché (o in aggiunta) i profili di comportamento degli utenti. I profili di comportamento delle applicazioni sono più affidabili nel rilevare le anomalie, in particolare le applicazioni di masquerading come i cavalli di Troia, perché i programmi applicativi hanno generalmente comportamenti più prevedibili rispetto ai soggetti degli utenti.

Le tecniche utilizzate per il rilevamento delle anomalie includono:

• Analisi statistica: considera l'intensità dell'attività, la distribuzione dei record di audit, le misure categoriali e ordinali.

• Generazione di modelli predittivi: tiene conto degli eventi passati durante l'analisi dei dati per prevedere eventi futuri.

• Reti neurali: rileva modelli sottili in serie di dati come i registri di sistema.

Queste tecniche possono scoprire tentativi di sfruttare nuove vulnerabilità impreviste. Sono meno dipendenti dai meccanismi specifici del sistema operativo e possono anche aiutare a rilevare gli attacchi di abuso di privilegi che non comportano in realtà lo sfruttamento di alcuna vulnerabilità di sicurezza.
Un alto tasso di falsi allarmi è generalmente citato come il principale svantaggio delle tecniche di anomalia perché l'intero ambito del comportamento di un sistema informativo potrebbe non essere coperto durante la fase di apprendimento. Un altro inconveniente è la difficoltà associata alla scelta di una soglia appropriata per segnalare un comportamento anomalo. Soglie più basse possono comportare un aumento dei tassi di falsi allarmi, mentre soglie più elevate possono perdere attività anomale. Il comportamento può anche cambiare nel tempo, introducendo la necessità di una periodica riqualificazione online del profilo comportamentale, con conseguente indisponibilità dell'IDS o ulteriori falsi allarmi. Durante la riqualificazione, il sistema informativo può subire attacchi nello stesso momento in cui l'IDS sta imparando il comportamento e, di conseguenza,il profilo comportamentale potrebbe essere infuso con un comportamento intrusivo che non verrebbe rilevato come anomalo se rilevato successivamente.
Rilevamento errato. Conosciuto anche come rilevamento basato sulla conoscenza, il rilevamento dell'abuso consiste nella ricerca delle tracce di controllo per il verificarsi di specifici modelli di record di controllo generati da abusi noti del sistema in base a intrusioni passate, vulnerabilità note e politiche di sicurezza. Nel rilevamento di un uso improprio, la base di conoscenza è una codifica delle azioni specifiche, come manifestate nella traccia di controllo, che costituiscono un uso improprio del sistema. La struttura dei record di audit che rappresentano lo scenario di penetrazione viene anche definita firma di attacco o attacco. Il ricorso a queste firme di attacco limita il rilevamento a vulnerabilità note.
Le tecniche utilizzate per il rilevamento dell'uso improprio includono:

• Sistemi esperti: automatizzano l'applicazione dell'euristica o delle regole empiriche.

• Analisi firme: ricerca per particolari schemi che indicano l'intrusione.

• Reti di Petri colorate: possono essere utilizzate per creare un modello di un sistema che può essere analizzato per problemi.

• Analisi della transizione di stato: identifica particolari sequenze di azioni.
Gli approcci basati sulla conoscenza hanno il potenziale per tassi di falsi allarmi molto bassi e l'analisi contestuale proposta dall'IDS è dettagliata, rendendo più facile per il team di risposta agli incidenti intraprendere un'azione preventiva o correttiva immediata.
Gli svantaggi includono la difficoltà di raccogliere le informazioni richieste sugli attacchi noti e di tenerli aggiornati con nuove vulnerabilità e ambienti. Il mantenimento della base di conoscenze di IDS richiede un'attenta analisi di ciascuna vulnerabilità ed è un'attività che richiede tempo. Anche gli approcci basati sulla conoscenza possono rendere difficile generalizzare la capacità di rilevamento delle intrusioni. La conoscenza degli attacchi è molto focalizzata e dipende dal sistema operativo, dalla versione, dal sistema e dall'applicazione.

L'IDS risultante è strettamente legato a un determinato ambiente. Il rilevamento di attacchi interni che comportano un abuso di privilegi è più difficile perché nessuna vulnerabilità viene effettivamente sfruttata dall'attaccante.

Comportamento al rilevamento

Sono possibili diverse risposte a un attacco, in particolare se l'attacco è in corso quando rilevato. La risposta più comune è registrare l'incidente e generare un allarme per consentire agli amministratori di valutare la necessità di un'azione. Questo metodo è indicato come una risposta passiva. In alternativa, un IDS autonomo intelligente può decidere la prossima linea d'azione sulla base del livello di certezza che un attacco è genuino. In questo caso, una sessione può essere chiusa, oppure il sistema può chiudersi, impedendo così ulteriori violazioni. Questo tipo di reazione è indicato come una risposta attiva. Le aziende devono considerare le ramificazioni normative e legali relative a entrambi i tipi di rilevamento.

Risposta passiva.

La maggior parte degli IDS sono passivi, il che significa che quando viene rilevato un attacco, viene generato un allarme, ma nessuna contromisura viene attivamente applicata per contrastare l'attacco. Il team di risposta agli incidenti viene informato di un possibile attacco, indaga sull'incidente e risponde di conseguenza. In seguito all'incidente, il team di sicurezza analizza il sistema attaccato per determinare la vulnerabilità che potrebbe essere stata utilizzata dall'intruso e l'entità del danno.

Risposta attiva

I sistemi di risposta attiva possono essere divisi in due classi, in base al controllo che esercitano. Alcuni sistemi di risposta attiva esercitano il controllo sul sistema attaccato: cioè, modificano lo stato del sistema attaccato per contrastare o mitigare gli effetti dell'attacco. Questo controllo può assumere la forma di terminare le connessioni di rete o uccidere processi errati. La risposta può includere l'aumento della registrazione di sicurezza per facilitare l'analisi degli incidenti dopo il fatto. Altri sistemi di risposta attiva esercitano il controllo sul sistema di attacco: cioè, contrattaccano nel tentativo di annullare la piattaforma operativa dell'attaccante. Una possibile preoccupazione con la risposta attiva è che un utente malintenzionato potrebbe sfruttare il sistema per attivare gli attacchi DoS. Ad esempio, attivando ripetutamente un IDS di destinazione per terminare un firewall,un utente malintenzionato potrebbe ridurre la disponibilità del firewall.

Frequenza di utilizzo

Gli IDS possono essere caratterizzati da due tipi di frequenza di utilizzo. Gli IDS di monitoraggio continuo cercano di rilevare le intrusioni in tempo reale o quasi reale. Gli IDS di monitoraggio periodici elaborano i dati di audit con un certo ritardo.

Monitoraggio continuo

Questa classe di IDS può essere basata su host o su rete. Il monitoraggio continuo dei registri di audit e di sistema o del traffico di rete consente di rilevare un'intrusione e segnalare la sua presenza con il più breve ritardo possibile. Contrastare un attacco prima che il danno sia fatto è una capacità desiderabile che è possibile solo con IDS in tempo reale; tuttavia, richiede che sia messo a punto un processo ben definito per la revisione dei dati da parte del personale di sicurezza.

Monitoraggio periodico

Questa classe elabora i dati in lotti a intervalli regolari. Questi sistemi sono utili per rilevare tendenze o schemi di attacco, ma offrono funzionalità limitate per la notifica tempestiva delle intrusioni. La raccolta dei dati per l'analisi consente il rilevamento di possibili nuove firme di attacco ma richiede strumenti avanzati di gestione dei dati per elaborare i volumi di informazioni.

Funzionalità IDS La funzionalità degli IDS può essere descritta in base a accuratezza, prestazioni, completezza, sicurezza e tempestività.

Precisione.

L'imprecisione si verifica quando un IDS segnala un'azione legittima come anomala o invadente (falso positivo). Il verificarsi di falsi positivi può essere ridotto mettendo a punto un IDS per distinguere gli attacchi da azioni legittime e aggiornando le firme di attacco su base regolare. Inoltre, un IDS deve essere in grado di integrarsi con tecnologie come la valutazione della vulnerabilità o strumenti di test di penetrazione del sistema per prevenire conflitti con le normali operazioni dei vari sistemi.

Prestazione.

La performance di un IDS è la velocità con cui vengono elaborati gli eventi di controllo. Se la prestazione è scarsa, il rilevamento in tempo reale non è possibile. Le prestazioni possono essere migliorate perfezionando gli IDS per dare priorità agli eventi e concentrarsi sulla rilevazione degli attacchi più probabili.

Completezza.

L'incompletezza si verifica quando l'IDS non riesce a rilevare un attacco, creando un risultato falso-negativo. Questa misura è molto difficile da valutare perché è impossibile avere una conoscenza globale degli attacchi o degli abusi dei privilegi. Aggiornamenti regolari delle firme di attacco e dei profili statistici derivanti da modifiche del comportamento dell'utente o del sistema possono aiutare a minimizzare le sviste.

Sicurezza.

Un IDS dovrebbe essere resistente agli attacchi, in particolare contro i tentativi maliziosi di attivare un attacco DoS, e dovrebbe essere progettato tenendo presente questo obiettivo. Gli IDS funzionano su sistemi operativi o hardware disponibili in commercio, che sono noti per essere vulnerabili agli attacchi. Inoltre, un IDS dovrebbe funzionare correttamente in condizioni estreme, come ad esempio un livello molto alto di attività di calcolo sul sistema host.

Tempestività.

Un IDS dovrebbe eseguire e pubblicare le sue analisi il più rapidamente possibile prima che si verifichino molti danni da un attacco. La capacità di identificare prontamente le intrusioni può consentire a un IDS di disabilitare i servizi o impedire che l'aggressore possa sovvertire la fonte di audit o l'IDS stesso. Un IDS può anche comunicare richieste ad altri dispositivi, come router e firewall, per bloccare la sorgente o terminare la sessione dell'intruso. Inoltre, l'IDS può notificare al team di risposta agli incidenti di reagire rapidamente a un'intrusione. Le organizzazioni devono disporre di processi ben definiti per la revisione e la gestione dei dati IDS.

Distribuzione IDS

L'implementazione strategica degli IDS dovrebbe migliorare significativamente le capacità di rilevamento. Tuttavia, la comprensione dei limiti di un IDS è essenziale per una strategia di implementazione, che potrebbe consistere nel localizzare i sensori di rilevamento delle intrusioni per proteggere quelle risorse di rete in cui risiedono le risorse più preziose, invece di cercare di proteggere ogni risorsa sulla rete. Tale decisione di implementazione è importante perché richiede di classificare il valore delle attività in base alla loro priorità prima del posizionamento dei sensori.
Le architetture di rete costituite principalmente da switch possono porre problemi in relazione alle posizioni degli IDS a causa della segregazione di ciascun segmento commutato e della difficoltà di visualizzare i flussi di eventi in tutti i segmenti. Le reti locali virtuali (VLAN) possono anche limitare l'accessibilità ai flussi di eventi. La localizzazione degli IDS agli switch può fornire un mezzo per visualizzare tutto il traffico che passa attraverso lo switch. Tuttavia, le sessioni crittografate all'interno della rete possono impedire a un IDS di ispezionare il contenuto della sessione.

Sebbene le sessioni crittografate possano impedire agli utenti non autorizzati di accedere a dati e sistemi, possono anche essere utilizzati da utenti autorizzati che tentano di ottenere l'accesso non autorizzato a dati sensibili.
Anche l'amministrazione e la gestione di IDS distribuiti devono essere considerati in relazione al costo di distribuzione di un IDS e alla sicurezza dei dati e dei registri mentre vengono trasferiti attraverso la rete, a un repository centralizzato oa un sistema di gestione. L'integrità dei dati e la disponibilità degli IDS sono requisiti chiave per fornire una soluzione efficace.
Gli IDS locali vengono eseguiti su un solo sistema e monitorano solo le tracce di controllo di quel sistema, il che significa che non possono rilevare ciò che sta accadendo sulla rete o su altri sistemi. Per fornire una copertura più ampia, è necessario installare copie di strumenti su molte piattaforme. Il costo e la complessità del mantenimento di questo tipo di soluzione potrebbero renderlo poco pratico all'interno di organizzazioni più grandi che potrebbero trarre vantaggio da un IDS gestito centralmente utilizzando agenti o sensori remoti.
Sia gli IDS basati su host che quelli basati su rete possono essere distribuiti su una LAN. I sensori possono risiedere su vari punti di rete o su più host. Ci sono tre problemi principali da considerare quando si distribuisce un ID distribuito.

Efficacia. Il rilevamento distribuito che prende i risultati di più sensori distribuiti in tutta l'azienda e li mette in correlazione in un'unica visione coerente può essere difficile. L'efficacia del sistema nel rilevare intrusioni in un ambiente eterogeneo multihost dipende dalla sua capacità di interpretare i dati da sensori diversi, e possibilmente da diversi fornitori. La corretta configurazione e la posizione strategica dei sensori sono fondamentali per fornire un servizio efficace.

Scalabilità. La capacità di scala del sistema è strettamente legata alle funzioni di gestione. I prodotti che possono essere gestiti centralmente e integrati con un sistema di gestione della sicurezza centrale riducono il sovraccarico di gestione e scalano più facilmente. La scalabilità è vitale per l'implementazione efficace di un IDS nella maggior parte delle reti aziendali.

Gestione . Una struttura di gestione centralizzata consente a un'organizzazione di monitorare e amministrare sensori locali e remoti in modo economicamente efficace. Inoltre, attenua alcuni dei problemi di rilevamento dei pattern di intrusione in un ambiente multihost, in cui le prove di attacco possono estendersi su più audit trail che sono raccolti in diversi host di architetture, sistemi operativi e strutture di auditing possibilmente differenti. Affrontare il problema di rilevamento delle intrusioni in un ambiente multihost implica più dell'analisi di tutti gli eventi rilevanti per la sicurezza prodotti localmente da ciascun host monitorato. Richiede anche una correlazione intelligente dei dati relativi agli eventi da più host.

SISTEMI DI PREVENZIONE DELL'INTRUSIONE

I sistemi di rilevamento delle intrusioni sono stati progettati per rilevare l'accesso non autorizzato o l'uso improprio delle risorse di elaborazione. Ora, i nuovi sistemi di sicurezza denominati sistemi di prevenzione delle intrusioni (IPS) sottolineano la prevenzione degli attacchi prima che si verifichi il danno reale. Gli IPS proteggono da minacce comuni come worm, virus e cavalli di Troia; installazione e attivazione di porte posteriori; modifiche ai file di sistema; cambiamenti nei livelli di privilegio dell'utente (in particolare acquisizione di privilegi di root, superutente o amministratore); attacchi di overflow del buffer; e attacchi a script e file system. Alcuni IPS, tuttavia, sono IDS che sono stati rinominati per scopi di marketing.

Come gli IDS, gli IPS utilizzano l'individuazione di anomalie e abusi per esaminare il comportamento di un attacco. Concentrandosi su ciò che fa un attacco, gli IPS imparano a riconoscere potenziali attacchi. Le implementazioni IPS possono essere basate su host e basate sulla rete.
Oltre al rilevamento delle anomalie, gli IPS basati su host potrebbero utilizzare sandbox e tecniche basate sul kernel per fornire protezione. Una sandbox è un'area riservata in cui il codice sospetto può essere messo in quarantena. Qui, il codice può essere eseguito ma non può accedere alle risorse di sistema. Se il comportamento del codice viola una politica predefinita, verrà impedito l'esecuzione all'esterno della sandbox. I codici mobili come le applet ActiveX e Java vengono spesso messi in quarantena quando si entra in un sistema.
Le organizzazioni possono evitare l'esecuzione di chiamate di sistema dannose caricando un agente software tra l'applicazione utente e il kernel del sistema operativo. L'agente intercetta le chiamate di sistema al kernel e le confronta con un ACL prima di consentire o bloccare l'accesso alle risorse.
Gli IPS basati sulla rete sono dispositivi di rete incorporati che utilizzano il rilevamento di anomalie e abusi nonché ispezioni stateful per impedire l'intrusione di rete. Questi IPS possono esaminare pacchetti, rilevare un attacco e rilasciare il traffico, proteggendo in tal modo il dispositivo di destinazione.
La necessità di protezione dalle intrusioni crescerà man mano che le organizzazioni si sforzano di consentire l'accesso ai sistemi proteggendo dagli attacchi interni ed esterni. Lo sviluppo di prodotti IPS robusti, tuttavia, è ancora nelle fasi iniziali.

RETI PRIVATE VIRTUALI

Una rete privata virtuale (VPN) è una rete di dati privata che fa uso dell'infrastruttura di comunicazione pubblica, mantenendo la riservatezza attraverso l'uso di un protocollo di tunneling e procedure di sicurezza associate come la crittografia. Essenzialmente, una VPN consente alle organizzazioni di estendere il loro perimetro di fiducia della rete sulle reti pubbliche senza sacrificare la sicurezza. Utilizzando Internet come backbone, una VPN può connettere in modo sicuro ed economico tutti gli uffici, i telelavoratori, gli utenti mobili, i clienti e i business partner di un'organizzazione.
Gli obiettivi di connettività IT aziendali tipici sono quelli di consentire l'uso di Internet:

• Tra le strutture aziendali per ridurre le tariffe della WAN, che sono spesso di grandi dimensioni.

• Per l'accesso remoto alle risorse della rete aziendale, per evitare costosi addebiti interurbani da parte degli utenti mobili.

• Come mezzo di comunicazione tra diverse entità aziendali.
Tuttavia, poiché Internet è una rete pubblica, alcuni requisiti di sicurezza di base devono essere soddisfatti per proteggere le informazioni trasmesse tramite VPN per garantire:

• Mantenimento della riservatezza dei dati attraverso la rete pubblica

• Manutenzione dell'integrità dei dati

• Autenticazione reciproca degli endpoint

• Disponibilità di sistemi

Applicazioni VPN Le tecnologie VPN sono generalmente implementate in tre diversi tipi di applicazioni.

Accesso remoto. Le VPN di accesso remoto consentono agli utenti remoti di accedere alla rete aziendale connettendosi a un provider di servizi Internet (ISP) per l'accesso a Internet. Come mostra la Figura 27, il software sulla workstation dell'utente negozia una sessione VPN crittografata con il gateway VPN aziendale. I dati crittografati si spostano tra l'utente e il gateway VPN su Internet. Una volta connessi e autenticati, gli utenti possono accedere a una varietà di servizi, come e-mail, siti Web interni, database e applicazioni aziendali. Questo approccio offre numerosi benefici all'impresa. Gli ISP di solito hanno punti di presenza nella maggior parte delle aree metropolitane e la chiamata all'ISP è in genere una chiamata locale, pertanto le tariffe a lunga distanza sono ridotte al minimo. Anche,la fornitura e la gestione dell'infrastruttura dial-in (linee telefoniche e modem) è responsabilità dell'ISP piuttosto che dell'organizzazione IT aziendale.

Filiale.

Le reti in varie sedi aziendali possono essere collegate tramite VPN basate su IP anziché utilizzare linee dedicate per costruire una rete di dati privata o utilizzare la rete di frame relay di un vettore. In questo caso, un provider di servizi di rete IP o ISP fornisce la connettività IP a tutti i siti e i gateway VPN crittografano in modo trasparente i dati trasferiti tra i siti.

Business partner / fornitore.

Un'applicazione sempre più popolare per VPN è l'extranet aziendale per condividere importanti informazioni aziendali con partner commerciali fidati e joint venture aziendali. In una tipica applicazione extranet, un'organizzazione crea un segmento di rete discreto che è separato da un firewall dalla rete aziendale principale. In questo segmento di rete si trovano server che ospitano i dati e le applicazioni condivise tra i partecipanti Extranet. La VPN extranet è configurata come una rete condivisa ad accesso controllato a cui solo l'organizzazione e i suoi partner commerciali designati possono accedere. Oltre alla sicurezza della rete, il server stesso richiede in genere un accesso autenticato, in particolare se più partner commerciali accedono alle stesse risorse. Ad esempio, con una VPN,un fornitore può avere accesso online globale ai piani di inventario e ai piani di produzione di un produttore in qualsiasi momento. Se viene utilizzato un servizio di frame relay o una linea dedicata, potrebbe essere più costoso e la copertura geografica potrebbe essere limitata. Le VPN forniscono un approccio alternativo ed economicamente vantaggioso.

Come funzionano le VPN Le VPN si basano su tecnologia e protocolli di rete familiari. Piuttosto che collegarsi a una rete attraverso una linea dedicata, tuttavia, la maggior parte delle VPN crea un tunnel attraverso una rete condivisa, come Internet. Il tunneling avvolge o incapsula l'intero pacchetto originale in un nuovo pacchetto con una nuova intestazione, creando un nuovo carico utile.

Il tunnelling prevede tre tipi di protocolli: il protocollo passeggero è il protocollo che viene incapsulato; il protocollo incapsulante viene utilizzato per creare, mantenere e abbattere il tunnel; e il protocollo portante è il protocollo utilizzato per trasportare il protocollo incapsulato. Il metodo più diffuso per creare tunnel VPN standard del settore è quello di incapsulare i protocolli di rete (protocolli passeggeri) all'interno di un protocollo incapsulante, e quindi inviare l'intero pacchetto utilizzando il protocollo carrier.

Implementazione di VPN

L'applicazione e altri requisiti aziendali guideranno la scelta di protocolli, tunnel e crittografia, portando alla selezione dei prodotti VPN più appropriati per un'organizzazione. Le aziende devono anche considerare in che modo la VPN è configurata in relazione ai firewall della rete, se l'applicazione richiederà l'uso di chiavi pubbliche o private e quali sono i requisiti di disponibilità e prestazioni.
I prodotti VPN predefiniti offrono una combinazione di nome utente / password o metodo sharedsecret per autenticare i partecipanti in un canale sicuro. Questi stessi prodotti VPN offrono anche integrazione con soluzioni di sicurezza avanzate come l'infrastruttura a chiave pubblica (PKI).

Selezione del protocollo

Dove viene posizionata la VPN all'interno del modello di riferimento OSI a sette livelli. I protocolli funzionano su diversi livelli del modello OSI, come il Layer 2, e sono usati come protocolli di incapsulamento per fornire servizi di tunneling e di crittografia VPN. Alcuni dei più comuni sono Internet Protocol Security (IPSec), Pointto-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP) e Multiprotocol Label Switching (MPLS).
Il protocollo Secure Sockets Layer (SSL) è recentemente emerso come un altro metodo per stabilire le VPN. SSL è un protocollo comunemente usato per migliorare la sicurezza crittografando i messaggi che viaggiano sulle reti pubbliche. SSL, sviluppato da Netscape nei primi anni '90, ha guadagnato enorme popolarità perché potrebbe fornire un metodo sicuro per la trasmissione di informazioni basate sul Web su Internet. Come protocollo, SSL è stato ampiamente utilizzato per diversi anni per proteggere le comunicazioni Internet e la sua popolarità ha alimentato l'adozione per altri usi, come le VPN.

I prodotti VPN basati su SSL utilizzano SSL come protocollo sottostante per comunicazioni sicure e questi prodotti hanno conquistato recentemente quote di mercato. L'uso di SSL elimina la necessità di installare client VPN sui sistemi degli utenti finali, riducendo significativamente i costi di implementazione, operativi e di supporto. Le VPN basate su SSL utilizzano come browser i browser Web standard, come Netscape Navigator e Microsoft Internet Explorer.
Le VPN basate su SSL non dovrebbero sostituire le VPN basate su IPSec per tutti i tipi di comunità di utenti, ma le VPN basate su SSL offrono un'opzione praticabile per alcuni utenti. Le VPN basate su IPSec sono vantaggiose perché possono fornire maggiore sicurezza e accesso alla rete aziendale onnipresente (sono indipendenti dall'applicazione), in particolare per le comunità di utenti che necessitano di un accesso continuo e ininterrotto. Tuttavia, per gli utenti che viaggiano e necessitano di un accesso rapido a e-mail e portali intranet aziendali oltre alla possibilità di aggiornare o caricare file, le VPN basate su SSL possono fornire una soluzione più semplice, più rapida ed economica. I fattori da considerare prima di implementare le VPN basate su SSL includono i requisiti di controllo degli accessi, il livello di sicurezza richiesto, il livello di supporto richiesto per le applicazioni aziendali, la crittografia, le prestazioni e la scalabilità. Per alcune di queste aree,IPSec può fornire una soluzione migliore in base alle esigenze e ai requisiti dell'organizzazione.
Configurazione. All'interno dell'ambiente di rete, la configurazione è un fattore essenziale per stabilire un'efficace sicurezza perimetrale. Poiché una VPN trasporta pacchetti crittografati, il normale filtraggio e il controllo che un firewall esegue per far rispettare i controlli di accesso alla rete sono sovrascritti. Il firewall passa semplicemente i pacchetti crittografati della VPN; non li decifra.
Esistono diverse possibilità di configurazione. Se il gateway VPN è collocato all'esterno del firewall con una singola connessione a una rete esterna, la VPN è soggetta a compromessi, poiché un utente malintenzionato potrebbe essere in grado di accedere al segmento di rete a cui è collegato il gateway VPN. Quando il gateway VPN è protetto dal firewall, il firewall può eseguire lo screening normale su traffico non VPN e passare attraverso il traffico VPN crittografato. La combinazione dell'elaborazione di VPN e firewall su un server è adatta solo per installazioni molto piccole. Il carico combinato dell'elaborazione crittografica e del controllo e della registrazione del firewall potrebbe essere troppo pesante per le reti più grandi.
Un'altra alternativa di configurazione VPN consiste nel localizzare il gateway VPN su un segmento di rete sicura dedicato con un secondo firewall tra esso e il resto della rete aziendale. Questa configurazione consente al firewall aggiuntivo di filtrare tutto il traffico non crittografato dal gateway VPN quando entra nella LAN aziendale. Il gateway VPN crittografa anche tutto il traffico prima che lasci il firewall aziendale sulla sua strada verso Internet.

Gestione delle chiavi.

L'accesso VPN può essere utilizzato per concedere l'accesso a risorse aziendali sensibili. È essenziale che i due punti finali in una VPN siano reciprocamente e fortemente autenticati, sia tra due firewall o tra un utente remoto e un gateway aziendale. Sono disponibili schemi di autenticazione multipli. Ad esempio, i prodotti VPN conformi IPSec possono fornire l'autenticazione tramite chiavi pubbliche certificate o chiavi private.

Elevata disponibilità e prestazioni.

Le soluzioni di livello enterprise richiedono un alto livello di disponibilità e scalabilità. Esistono molti modi per fornire un'elevata disponibilità, tra cui hardware ridondante, clustering o bilanciamento del carico dinamico. La sfida consiste nel fornire un failover attivo della sessione, in modo che i dispositivi VPN comunicanti possano sincronizzare tutte le informazioni necessarie per ripristinare correttamente una sessione e le chiavi crittografiche coinvolte nell'associazione di sicurezza.
A causa della quantità variabile di traffico che tenta di utilizzare la VPN, e poiché la crittografia e la decrittografia sono operazioni computazionalmente intensive, la progettazione dell'architettura VPN e il trasferimento di servizi esistenti in un ambiente VPN richiedono un'attenta considerazione. Sebbene la potenza di elaborazione sia in costante miglioramento, l'utilizzo di Internet sta crescendo rapidamente e il carico di lavoro computazionale per i gateway VPN potrebbe richiedere lo spostamento di alcune attività di crittografia e decrittografia verso coprocessori di crittografia dedicati speciali. Inoltre, l'aumento della velocità di accesso alla rete e l'aumento della necessità di connessioni simultanee possono rendere difficile per i dispositivi di rete che si occupano della sicurezza di eseguire l'elaborazione necessaria.

Tendenze VPN

La tecnologia VPN è maturata in modo significativo ed è ampiamente adottata nelle aziende come soluzione di accesso remoto economica e praticabile. IPSec è emerso come una scelta chiara per la tecnologia VPN. Tuttavia, le VPN Layer-2 come quelle che utilizzano il protocollo MPLS stanno guadagnando consensi. Le VPN basate su SSL promettono meno supporto operativo e costi di implementazione e forniscono una buona soluzione per determinati tipi di utenti.
Con la maturazione della tecnologia VPN, sempre più organizzazioni stanno implementando un software di gestione della rete che cerca di migliorare l'efficienza operativa. Questo software consente di gestire software client e gateway aggiornando il software, distribuendo nuovi numeri di accesso, distribuendo nuove politiche di accesso e sicurezza e così via. Un'altra tendenza è l'emergere del software di applicazione delle policy, che aiuta a migliorare la sicurezza generale limitando l'accesso VPN a sistemi e dispositivi che hanno applicato un livello di sicurezza adeguato e predeterminato.

■ Sicurezza WLAN Molte organizzazioni utilizzano la connettività wireless come complemento alle tradizionali tecniche di rete cablate basate su Ethernet. Basato sulla famiglia 802.11 di IEEE (Institute of Electrical and Electronics Engineers), la tecnologia di fedeltà wireless (Wi-Fi) è un mezzo semplice ed economico per costruire reti wireless (WLAN). Dal punto di vista della sicurezza, tuttavia, il wireless solleva molte nuove sfide oltre a quelle associate al networking tradizionale. La trasmissione del traffico di dati attraverso le onde radio pubbliche apre la possibilità di intercettazioni in modi impossibili con le reti terrestri.
I rischi sono simili se la WLAN si basa sull'hardware 802.11b 11 Mbps o sugli standard 802.11a e 802.11g più recenti e veloci. Nella maggior parte dei casi, il rischio associato alle WLAN non supera la ricompensa. Le organizzazioni dovrebbero essere in grado di godersi il

i vantaggi del wireless con elevata affidabilità, a condizione che gli amministratori di rete osservino le precauzioni appropriate nella progettazione della WLAN aziendale e nella diligenza degli esercizi nel monitoraggio del suo utilizzo.

CONSIDERAZIONI SULLA SICUREZZA WLAN

La sicurezza di qualsiasi WLAN può essere compromessa. Nella maggior parte delle aree metropolitane, la pratica di "guidare la guerra" - letteralmente, guidando nei quartieri armati di un laptop con tecnologia wireless alla ricerca di punti di accesso aperti - è comune. Sono disponibili strumenti software in grado di scansionare le onde radio per tutti i punti di accesso Wi-Fi entro il raggio d'azione e restituire informazioni su di essi, la più importante è un'applicazione chiamata NetStumbler. Una WLAN aziendale scoperta casualmente in questo modo potrebbe essere di scarso interesse per l'intruso originale. Una volta che la sua esistenza è resa pubblica attraverso i forum online o altri canali, tuttavia, le probabilità di un attacco successivo più dannoso aumentano drammaticamente.
Pertanto, indipendentemente dal livello di rischio percepito, gli architetti delle reti WLAN aziendali dovrebbero sempre presumere che la loro rete sia vulnerabile agli attacchi. Per quanto riguarda la politica, dovrebbero implementare il maggior numero possibile di contromisure contro potenziali intrusi, a condizione che tali misure non ostacolino indebitamente l'uso legittimo della WLAN all'interno dell'organizzazione.

Impostazioni predefinite

Quando si installano punti di accesso wireless, gli amministratori devono modificare le configurazioni di fabbrica predefinite dell'hardware. I valori preconfigurati includono in genere l'ID del set di servizi (SSID, un nome identificativo univoco che i client devono conoscere per accedere alla rete) e la password amministrativa utilizzata per riconfigurare il punto di accesso . Gli intrusi esperti conosceranno i valori predefiniti per tutti i principali fornitori di hardware e, con il minimo sforzo, questi intrusi potranno accedere a una WLAN configurata in modo inadeguato.

Signal Range

Gli amplificatori di segnale e le antenne after-market ad alta potenza sono diventati accessori popolari per ambiziosi progetti Wi-Fi, ma in molti casi non sono necessari e possono estendere l'area di copertura della WLAN oltre una gamma prudente. Nelle reti Ethernet tradizionali, l'accesso è limitato alle aree in cui sono state installate porte di rete cablate. Nelle reti wireless, l'accesso può essere molto più difficile da controllare, poiché è probabile che la copertura si estenda oltre le aree fisicamente sicure di un'organizzazione che ospitano componenti dell'infrastruttura nelle hall, nelle mense, nelle sale riunioni e persino all'esterno dell'edificio.

Sondaggi periodici

L'installazione di punti di accesso wireless non dovrebbe mai essere un processo casuale e dovrebbero essere considerati potenziali risultati non previsti. Dopo aver installato la WLAN, gli amministratori devono condurre regolarmente sondaggi periodici del sito utilizzando gli stessi strumenti che potrebbero utilizzare i potenziali aggressori (come NetStumbler) per verificare che tutti i punti di accesso siano configurati correttamente e che le aree di copertura siano come previsto.

Ponti di rete

I tecnici di rete dovrebbero anche prestare attenzione quando si collegano il traffico tra le reti cablate e wireless. I ponti "stupidi", quelli che inoltrano indiscriminatamente tutto il traffico tra i due, sono particolarmente da evitare, perché rendono efficacemente i pacchetti destinati esclusivamente alla rete cablata vulnerabili quanto quelli della WLAN. Invece, gli architetti di rete dovrebbero specificare router intelligenti che inoltrano solo il traffico che è specificamente inteso per la rete wireless.

BASIC WIRELESS SECURITY

Nessuna quantità di diligenza durante il processo di installazione può garantire che una WLAN sfugga all'esame indesiderato. Armato del SSID di una rete e dell'accesso all'area di copertura, un intruso può utilizzare il software di port-sniffing per monitorare efficacemente ogni pacchetto di traffico che attraversa la rete. Per questo motivo, i venditori wireless hanno implementato diverse tecnologie aggiuntive progettate per limitare l'accesso solo agli utenti autorizzati.
Wired Equivalent Privacy (WEP)

Il più importante di questi è Wired Equivalent Privacy (WEP), un protocollo che fa parte della specifica 802.11b. WEP crittografa tutto il traffico sulla WLAN utilizzando chiavi univoche assegnate dal punto di accesso. Sebbene l'hardware di prima generazione abbia utilizzato solo chiavi di crittografia a 40 bit, i dispositivi di oggi utilizzano regolarmente lunghezze chiave di 128 bit o più. Le chiavi più lunghe sono più difficili da decifrare usando metodi a forza bruta.
Sfortunatamente, non molto tempo dopo la finalizzazione della specifica WEP, i ricercatori dell'Università della California, Berkeley, hanno scoperto un difetto nell'implementazione del WEP che consente a un utente malintenzionato di prevedere la sequenza di chiavi generate dal punto di accesso, indipendentemente dalla chiave lunghezza. Nell'agosto 2001, la Wireless Ethernet Compatibility Alliance (WECA) ha annunciato di aver scoperto un'altra debolezza nella progettazione del protocollo, questa ancora più significativa della prima. Oggi è generalmente accettato in tutto il settore che WEP è vulnerabile agli attacchi e non può fornire un'efficace garanzia di sicurezza.
Questo non vuol dire che la crittografia WEP sia priva di valore. Anche se può essere compromesso, farlo richiede tempo, specialmente con chiavi lunghe più lunghe. Quindi, mentre non può garantire la sicurezza, WEP rappresenta ancora un ostacolo per un potenziale intruso. Gli amministratori sono invitati ad abilitare il WEP sulle loro reti Wi-Fi in tutti i casi e utilizzare la lunghezza della chiave più lunga disponibile sul proprio hardware.
Alcuni fornitori di Wi-Fi hanno sviluppato estensioni di sicurezza proprietarie aggiuntive per compensare le carenze di WEP. Gli esempi includono Cisco Wireless Security Suite, SMC EliteConnect e 3Com Dynamic Security Link. Tali estensioni specifiche del fornitore possono essere problematiche, tuttavia, poiché non fanno parte delle specifiche 802.11 pubblicate. Una ragione per la popolarità del Wi-Fi è che è uno standard aperto; le offerte di prodotti concorrenti di vari produttori si basano sulle stesse specifiche e possono pertanto interagire senza troppi problemi. L'adozione di estensioni proprietarie significa che non solo un'organizzazione deve essere standardizzata su un singolo fornitore per il proprio hardware Wi-Fi, ma deve anche limitare l'accesso alla sua WLAN da parte di clienti esterni, fornitori o altri partner che non possono utilizzare la stessa apparecchiatura.

Filtro indirizzi MAC

Molti fornitori offrono il filtraggio degli indirizzi MAC (Media Access Control) come mezzo per limitare l'accesso WLAN ai client pre-approvati. Ogni componente dell'hardware di rete, cablato o wireless, viene assegnato dal produttore a un numero identificativo univoco, chiamato indirizzo MAC. L'indirizzo MAC è cablato nel dispositivo e non è progettato per essere modificato dall'utente. Quando il filtro degli indirizzi MAC è abilitato, una porta di accesso accetterà solo il traffico trasmesso dai trasmettitori autorizzati in base ai loro indirizzi MAC, come specificato dall'amministratore di rete. Tale politica impone restrizioni agli ospiti e ad altri utenti temporanei, e in organizzazioni più grandi tali politiche possono causare notevoli costi amministrativi.

CONTRASTI AVANZATI PER WLAN

Molti ambienti aziendali hanno implementato un ulteriore livello di autenticazione, che obbliga gli utenti ad accedere manualmente con un nome utente e una password prima di consentire loro l'accesso alla rete. Un metodo per implementare tale sistema è il servizio utente di accesso remoto con autenticazione remota (RADIUS), attualmente lo standard di fatto per l'autenticazione remota. RADIUS è stato a lungo utilizzato nei terminal server per autenticare gli utenti dial-in e ora viene visualizzato nei punti di accesso Wi-Fi di alcuni fornitori, inclusi i prodotti Avaya, Lucent e Orinoco. Un altro standard di autenticazione più complicato è 802.1x, che consente il supporto per una varietà di standard di autenticazione. 802.11x è implementato in Windows XP e dai punti di accesso wireless di tali fornitori come Hewlett-Packard, Intel e Linksys.

802.11 standard

Le misure di stopgap come quelle menzionate in precedenza non dovrebbero essere necessarie per molto più tempo. Wi-Fi Alliance, il consorzio industriale responsabile per l'avanzamento della famiglia di specifiche 802.11, sta sviluppando lo standard 802.11i come sostituto della sicurezza wireless basata su WEP. Un componente di 802.11i, uno schema di autenticazione denominato Wi-Fi Protected Access (WPA), è già in fase di implementazione da parte dei principali fornitori nel loro hardware 802.11g a 54 Mbps. L'altro componente della nuova specifica, denominato Robust Security Network (RSN), sarà uno strato di crittografia trasparente per il traffico di rete wireless. Sfortunatamente, non è chiaro quando le specifiche complete 802.11i saranno finalizzate e disponibili per i produttori di hardware da implementare nei loro prodotti. Finché non lo sarà, l'adozione diffusa persino del WPA rischia di essere un processo lento.

SSL e SSH

Nel frattempo, è consigliabile utilizzare un ulteriore livello di sicurezza a livello di applicazione per tutto il traffico WLAN. SSL è stato a lungo disponibile per transazioni sicure basate sul Web ed è supportato dalla maggior parte dei browser. Il traffico per altre applicazioni può essere protetto incapsulandolo in "tunnel" crittografati usando il protocollo Secure Shell (SSH). In entrambi i casi, i pacchetti crittografati saranno inintelligibili, anche per gli intrusi che hanno altrimenti compromesso la WLAN.

VPN

Tuttavia, anche questi metodi possono consentire al traffico di uscire in modo non criptato. La maggior parte degli esperti di sicurezza consiglia che l'unico modo per proteggere veramente tutto il traffico su una WLAN è di utilizzare una soluzione VPN. Separando la rete wireless da altre reti e forzando tutto il traffico verso e da esso per passare attraverso il gateway VPN, le organizzazioni possono essere ragionevolmente certe che le loro WLAN sono virtualmente invulnerabili agli attacchi.
Sembra probabile che la maggior parte delle organizzazioni implementerà una qualche forma di VPN per la connettività wireless nel prossimo futuro, anche dopo la ratifica della specifica finale 802.11i. Le aziende impongono già regolarmente ai client VPN utenti remoti che accedono alle loro reti tramite modem dial-up o reti pubbliche come Internet. Standardizzando su un singolo pacchetto VPN sia per macchine cablate che Wi-Fi, gli amministratori di rete possono semplificare notevolmente le loro politiche di sicurezza.

■ Sicurezza delle applicazioni e dell'archiviazione dei dati Sebbene i meccanismi di sicurezza a livello di rete forniscano le basi necessarie per un'infrastruttura protetta, le autorizzazioni e i meccanismi di sicurezza all'interno delle applicazioni possono aiutare a proteggere l'applicazione. Tuttavia, è necessario adottare misure aggiuntive a livello di sistema operativo e archivio dati, poiché gli intrusi possono attaccare un sistema aggirando l'applicazione.

CONTROLLI DI APPLICAZIONE

Molte applicazioni, come il software ERP (Enterprise Resource Planning), includono controlli che garantiscono la sicurezza. I pacchetti ERP vengono utilizzati per manipolare dati critici aziendali, tra cui informazioni sulle risorse umane, transazioni finanziarie e dati della supply chain. Le autorizzazioni e altre funzionalità di sicurezza all'interno del software ERP sono pensate per garantire l'accesso appropriato alle funzioni di elaborazione sensibili e la capacità di leggere i dati e applicare la segregazione dei compiti (SOD).
Il meccanismo di autorizzazione all'interno dei pacchetti ERP può essere progettato per consentire o vietare determinate transazioni commerciali all'interno del sistema. Ogni transazione ha un insieme definito di oggetti che possono supportare una definizione più profonda della sicurezza. Ad esempio, forse un utente vuole la possibilità di eseguire report di vendita. Questo tipo di rapporto è identificato all'interno del sistema da un codice di transazione univoco. Il codice di transazione, per il report delle vendite display, può essere ulteriormente limitato dall'organizzazione di vendita. Il risultato è che l'utente può solo visualizzare il report delle vendite all'interno della propria unità di vendita o reparto.
Ogni tipo di transazione è assegnato a un ruolo all'interno del sistema ERP. Questo ruolo di sistema si differenzia da una posizione o un lavoro all'interno dell'azienda in quanto un dato lavoro può essere costituito da molti ruoli. Ad esempio, un sovrintendente di costruzione è un lavoro, ma quell'individuo può svolgere i ruoli di programmatore di progetto e approvatore di ordini di acquisto. Entrambi questi ruoli all'interno del sistema devono contenere le transazioni richieste e gli oggetti di autorizzazione per eseguire le attività associate a tale funzione aziendale.
Un potenziale rischio è che a una persona specifica possa essere assegnata una combinazione di ruoli di sistema che presentano una violazione SOD. Il sovrintendente alla costruzione, ad esempio, ha la capacità di approvare gli ordini di acquisto, pertanto il progetto di sicurezza dovrebbe garantire che a tale individuo non vengano assegnati i ruoli di richiedente materiale, destinatario della merce o processore di fatture. L'organizzazione deve definire un elenco completo delle violazioni SOD e dei rigorosi processi di manutenzione e approvazione della sicurezza per mitigare questo rischio.

Un altro problema può sorgere se il sovrintendente alla costruzione può approvare ordini di acquisto al di fuori della business unit. Tale autorizzazione consentirebbe a questa persona di assumere impegni per un'altra organizzazione. L'ID utente deve essere limitato solo alle unità di business appropriate per le quali una persona specifica è autorizzata a svolgere attività. Comprendere e documentare i requisiti di sicurezza e l'affiliazione organizzativa di un individuo aiuterà a gestire questo rischio.
Sebbene le applicazioni ERP offrano sicurezza a livello di applicazione (come i ruoli), altri componenti sottostanti richiedono misure di sicurezza per impedire agli utenti di eludere i controlli a livello di applicazione. L'uso di applicazioni ERP implica l'uso dei seguenti componenti:

• Uno o più archivi dati che memorizzano i dati dell'applicazione e le informazioni dell'utente.

• Uno o più sistemi operativi per supportare il pacchetto ERP e gli archivi dati associati.

• Un'infrastruttura di rete per connettere questi componenti tra loro, nonché alla comunità degli utenti finali.
La protezione delle applicazioni ERP richiede la protezione di tutti questi componenti. Se non sono disponibili adeguati controlli e sicurezza per tutti i punti di accesso al database, l'integrità, la disponibilità e la riservatezza del database potrebbero essere compromesse.

Ad esempio, a un addetto alla contabilità fornitori possono essere assegnati ruoli e responsabilità appropriati nell'applicazione SAP, ma in qualche modo è possibile ottenere la possibilità di accedere direttamente al database Oracle con autorizzazioni di scrittura su tutti i campi del database. Tecnicamente, questa capacità fornisce una via per l'impiegato pagabile dei conti per modificare i dati al di fuori del proprio ruolo assegnato e al di fuori dei controlli dell'applicazione. L'impiegato ipoteticamente potrebbe aggiungersi come beneficiario e creare transazioni per generare un pagamento a se stesso   Oltre ai controlli delle applicazioni, vengono utilizzati anche controlli generali del computer per garantire la sicurezza dell'applicazione e dell'archivio dati. Questi controlli proteggono il codice dell'applicazione ei file del sistema operativo, controllano le connessioni e l'accesso al database, abilitano forme di sicurezza più complesse (come la crittografia dei dati e il Single Sign-On) e garantiscono la recuperabilità dei dati aziendali.

CONTROLLI GENERALI DEL COMPUTER

Le categorie generali di controllo computer rappresentativo per la sicurezza del sistema operativo e dell'archivio dati includono quanto segue:
Amministrazione utente. I processi per amministrare l'accesso degli utenti dovrebbero essere documentati e affrontare l'aggiunta, la modifica e la revoca dell'accesso degli utenti, nonché l'approvazione necessaria per l'accesso. Una comune supervisione si verifica quando gli utenti cambiano le responsabilità. Spesso agli utenti viene concesso l'accesso per le loro nuove responsabilità, ma l'accesso che non richiedono più non viene rimosso. Gli amministratori dovrebbero rivedere periodicamente l'accesso degli utenti per assicurarsi che sia commisurato alle responsabilità lavorative. Le seguenti sono linee guida generali.

Le password.

Tutti gli account utente devono richiedere una password con una lunghezza minima stabilita. Una password vuota o una password più breve della lunghezza minima aumenta il rischio di accesso non autorizzato al sistema. Per i nuovi account utente, gli amministratori devono impostare password univoche che scadono al primo accesso e garantire che le password siano distribuite in modo sicuro. Altri utenti possono accedere come utente appena creato e iniziare immediatamente a eseguire le transazioni se conoscono le password predefinite fornite durante la creazione dell'account.
L'impostazione di scadenze periodiche di tutti gli utenti, ad esempio ogni 60-90 giorni, consente di ridurre il rischio che un utente che ha ottenuto l'accesso non autorizzato al sistema compromettendo una password abbia accesso continuato al sistema. Le password per gli account predefiniti dovrebbero essere cambiate dai loro valori predefiniti. In caso contrario, aumenta il rischio che una persona non autorizzata possa accedere al sistema.
L'amministratore di sistema non deve creare account guest o account temporanei, poiché tali account aumentano il rischio che utenti non autorizzati ottengano l'accesso al sistema e successivamente compromettano l'integrità e la riservatezza del sistema. Per i casi in cui i sistemi operativi creano account per impostazione predefinita e potrebbero non consentirne l'eliminazione (ad esempio l'account guest di Windows), questi account devono essere disabilitati. Un metodo comune per ottenere l'accesso non autorizzato al sistema sta tentando di accedere utilizzando account predefiniti o conosciuti.
Una politica di sicurezza dovrebbe impostare una soglia di tentativi di accesso non validi consentiti e bloccare gli account una volta raggiunto questo numero di tentativi non validi. Gli account dovrebbero rimanere bloccati finché un amministratore non li sblocca. Un potenziale intruso tenterà manualmente o automaticamente di accedere agli account con password multiple fino al successo. Abilitando i blocchi degli account dopo 3-5 tentativi, il rischio di accesso non autorizzato all'utente diminuisce.

Gruppi di utenti

Agli utenti che richiedono l'accesso ai file e alle utilità dell'archivio dati dovrebbe essere concesso l'accesso tramite l'utilizzo di gruppi a livello di sistema operativo definiti dai requisiti di ruolo e responsabilità. Ad esempio, tutti gli amministratori di database devono essere membri di un gruppo di amministratori di database (DBA) che dispone dell'autorizzazione per arrestare e riavviare il servizio di database sul server. L'uso appropriato degli account utente a livello di sistema operativo impedisce agli utenti di ottenere un accesso non commisurato ai loro ruoli e responsabilità, compromettendo così l'integrità, la disponibilità e la riservatezza del database.
Ogni sistema di archiviazione dati contiene più oggetti (tabelle di dati, ad esempio), ciascuno dei quali ha determinati diritti di accesso ad esso associati. I privilegi di sistema e oggetto dovrebbero essere assegnati ai ruoli piuttosto che ai singoli account. Assegnare i privilegi direttamente agli account crea un processo amministrativo oneroso e complicato e aumenta il rischio che un account abbia privilegi non autorizzati.
La limitazione dell'accesso a ID amministrativi e altri ID privilegiati, come root o amministratore, riduce il rischio di modifiche accidentali e non autorizzate al sistema.
Revisione periodica Gli amministratori dovrebbero inoltre implementare una procedura per controllare periodicamente l'accesso per identificare gli account inattivi e determinare se l'accesso concesso è appropriato alle responsabilità lavorative. L'accesso inadeguato a livello di sistema aumenta il rischio di accesso non autorizzato, errore accidentale o frode.

Controllo delle modifiche

Le procedure formali di controllo delle modifiche approvate dalla direzione dovrebbero essere sviluppate e implementate per limitare i cambiamenti del sistema operativo, del database e delle applicazioni. Le procedure di controllo delle modifiche formali sono fondamentali per gestire le modifiche a qualsiasi archivio dati e alla relativa infrastruttura. Senza un processo di controllo delle modifiche, le modifiche apportate al sistema operativo, al database o all'applicazione potrebbero non essere eseguite secondo gli standard di controllo interno. Ad esempio, se non si seguono le procedure di controllo delle modifiche, è possibile apportare delle modifiche che: • Non si allineano alle esigenze aziendali.

• Non sono stati completamente testati e sottoposti a controllo qualità.

• Può avere un impatto su altri sistemi di produzione.

La documentazione dei processi di controllo delle modifiche dovrebbe essere completa e includere un metodo per tenere traccia delle richieste di modifica e modificare le approvazioni delle richieste. Le procedure dovrebbero inoltre disporre di meccanismi per la registrazione e la definizione delle priorità delle modifiche, garantendo un'adeguata separazione delle funzioni, test delle modifiche, ottenendo l'approvazione della direzione, la gestione delle procedure di back-out e la comunicazione alla direzione.

I backup

Tutti i dati business-critical devono essere sottoposti a backup su base regolare, inclusi i file di sistema del sistema operativo e del database. Senza una strategia di backup e ripristino documentata, approvata e testata, un'organizzazione potrebbe non essere in grado di ripristinare correttamente i dati entro un arco di tempo adeguato in caso di disastro. Le organizzazioni devono eseguire backup completi del sistema operativo dell'archivio dati a intervalli regolari e determinare un periodo di tempo appropriato per archiviarli fuori sede. I supporti di backup devono essere conservati in un luogo sicuro e protetto. Se un'organizzazione non dispone di strutture di archiviazione dati off-site adeguate, un disastro nel luogo di un'organizzazione potrebbe causare la perdita di dati e impedire, o eventualmente interrompere, le operazioni per un periodo di tempo indeterminabile.

Procedure di ripristino di emergenza e continuità aziendale

Le organizzazioni dovrebbero sviluppare e documentare le procedure di emergenza e testarle annualmente. Procedure inadeguate di risposta alle emergenze possono comportare il fallimento nel recupero dei sistemi in modo efficace ed efficiente. Inoltre, potrebbe emergere confusione sulle responsabilità e sui compiti da svolgere.

A livello di data store, procedure inadeguate di accesso di emergenza potrebbero compromettere l'integrità del database e allungare i tempi di recupero o impedire una piena comprensione dell'impatto dell'emergenza. A livello di sistema operativo, dovrebbero essere predisposte procedure appropriate per garantire che i guasti operativi (ad esempio, i problemi del disco) siano identificati, risolti tempestivamente e, se del caso, le azioni correttive siano approvate in modo retrospettivo dal personale IT e dagli utenti appropriati .

CONTROLLI DEL NEGOZIO DI DATI

Ogni singolo pacchetto di data store ha le proprie configurazioni di sicurezza e impostazioni da considerare. Tuttavia, per qualsiasi archivio dati, è necessario rivedere i seguenti controlli generali del computer.
Accesso al database Tutti gli utenti, inclusi i DBA, devono accedere al sistema con un ID univoco assegnato solo a loro. Gli utenti privilegiati hanno tutti i diritti sul database. Se gli utenti sono autorizzati ad accedere utilizzando account condivisi (come root o oracle), la sicurezza del database potrebbe essere compromessa. La responsabilità per le azioni intraprese all'interno del sistema può essere raggiunta solo assegnando a tutti gli utenti un proprio account univoco e richiedendo che prima che utilizzino un account privilegiato, prima accedono utilizzando il loro ID personale. Questa pratica fornisce la possibilità di controllare l'utilizzo di account con privilegi (presupponendo che sia disponibile una registrazione adeguata). La pratica di condividere account o utilizzare lo stesso nome account per individui diversi riduce il livello di responsabilità quando sono state intraprese azioni di sistema irregolari, non autorizzate e inappropriate.

Accesso ai file di sicurezza

Solo gli utenti autorizzati come DBA e gli amministratori di sistema dovrebbero avere accesso ai file di archiviazione dati relativi alla sicurezza (file init.ora e di controllo, ad esempio) all'interno del database. La limitazione dell'accesso al personale autorizzato ridurrà al minimo le modifiche inappropriate ai file e il conseguente danneggiamento del database.

Impostazioni della sessione

Gli amministratori non dovrebbero consentire agli utenti di aprire più sessioni. Gli accessi simultanei potrebbero consentire l'utilizzo dello stesso account più volte nello stesso intervallo di tempo. L'uso autorizzato e non autorizzato potrebbe avvenire contemporaneamente senza preavviso.
Gli utenti dovrebbero avere un'impostazione di tempo di inattività da 10 a 30 minuti a seconda della natura dell'account. Permettere agli account di rimanere loggati quando inattivo per periodi di tempo eccessivi aumenta il rischio che un utente non autorizzato possa accedere al sistema. Ad esempio, se un gestore con l'autorizzazione per approvare le transazioni accede a una sessione e parte per il giorno senza disconnettersi dal sistema, un utente con meno privilegi potrebbe utilizzare tale sessione aperta per approvare transazioni non autorizzate.

Arresto e riavvio del database

Negli ambienti in cui è richiesto che il database sia altamente disponibile, garantire che il database sia raramente, se non mai, arrestato e riavviato è fondamentale. Arresti e riavvii imprevisti del database potrebbero indicare un potenziale problema a livello fisico (capacità hardware o interruzioni dell'alimentazione, ad esempio) o un livello logico (gli utenti effettuano arresti non autorizzati). L'amministratore del database deve esaminare il file di registro di controllo del database o la tabella e indagare su eventuali blocchi di database non pianificati. Le istanze dell'archivio dati devono essere arrestate e successivamente riavviate solo da personale autorizzato in orari pianificati in cui gli utenti possono ricevere una notifica appropriata. Arresti di database non pianificati o non programmati negheranno agli utenti l'accesso al sistema   Registrazione e monitoraggio Il controllo è fondamentale per la riservatezza, l'integrità e la disponibilità dei dati. Se il controllo non è abilitato, tentativi accidentali o dannosi di alterare i dati potrebbero non essere rilevati. Le attività di archiviazione dati devono essere registrate e monitorate per eventuali modifiche ai dati business-critical. Il controllo può essere realizzato utilizzando strumenti integrati che possono essere utilizzati con uno strumento di analisi del registro, se lo si desidera. Eventi come errori di accesso, modifiche nelle autorizzazioni, modifiche ai dati critici, modifiche al codice e utilizzo dell'ID privilegiato dovrebbero essere registrati e monitorati. Se non vengono registrati eventi importanti nel database, aumenta il rischio che azioni di sistema non autorizzate (come la cancellazione o la modifica di dati sensibili) oi tentativi di accesso non possano essere identificati e risolti in modo tempestivo. Gli amministratori devono eseguire il backup dei log di controllo secondo necessità.Il controllo può essere utile per la raccolta di dati storici per particolari attività del database. Gli amministratori devono inoltre eseguire il mirror dei file di registro, poiché più copie dei file di registro riducono il rischio di perdita dei dati in caso di disastro del sistema.
Il DBA dovrebbe monitorare lo spazio disponibile su disco assegnato al database. Il continuo funzionamento di tutte le applicazioni di database richiede che siano disponibili risorse di database sufficienti per continuare a registrare le transazioni delle applicazioni e i record di log generati dal sistema. Un rischio potenzialmente elevato è che una volta che il database (o anche il log di archivio) esaurisce lo spazio su disco, smetterà di rispondere e tutti i processi verranno interrotti. La percentuale di spazio disponibile su disco può variare a seconda del prodotto. Fare riferimento alle raccomandazioni del fornitore e determinare se una percentuale superiore alla raccomandata è più appropriata.
Oltre a controllare gli eventi citati in precedenza, è necessario verificare anche le attività di ID privilegiati e azioni contro determinati dati critici (come le attività di controllo completate dall'ID Oracle o le modifiche alle transazioni finanziarie). Il controllo delle azioni degli utenti con i privilegi di amministratore di sistema riduce la probabilità di un uso inappropriato. Sebbene un'organizzazione si basi molto sul DBA, una traccia di controllo che documenti azioni specifiche (come l'eliminazione di transazioni da determinate tabelle) dovrebbe essere creata per l'utente DBA. Tale traccia di controllo è importante anche quando la funzione DBA viene esternalizzata, ma il sistema è in loco, poiché l'amministratore di database ha effettivamente accesso completo a tutti i record aziendali.
Le organizzazioni devono controllare tutti gli oggetti sensibili per determinate modifiche (istruzioni SQL come INSERT TABLE, DELETE TABLE e UPDATE TABLE, ad esempio). I trigger devono essere utilizzati per controllare le modifiche ai dati critici. Ad esempio, uno script interno può essere sviluppato per scrivere in un file di registro ogni volta che viene eseguito il comando UPDATE TABLE. Il registro deve includere il nome del comando, i valori originali nella tabella, i valori modificati nella tabella, l'ID che invia la modifica e un timestamp per la modifica. La natura di questi trigger dipende dall'organizzazione e dai dati che risiedono all'interno del database.
Revisioni periodiche dei profili utente e tentativi di accesso non riusciti sono importanti. Gli utenti non autorizzati possono scegliere come target i profili che non sono stati utilizzati di recente per penetrare nel sistema. Il numero di tentativi di accesso potrebbe indicare un tentativo di hacking nel database, che, se ha successo, potrebbe compromettere l'integrità, la disponibilità e la riservatezza del database.

CONTROLLI DEL SISTEMA OPERATIVO

I controlli del sistema operativo sono un sottoinsieme di controlli generali del computer che consentono di impedire agli utenti non autorizzati di ottenere l'accesso al sistema operativo e, in definitiva, l'accesso ai file di dati e ai file eseguibili.

Autorizzazioni per i file

Gli amministratori devono limitare l'accesso a livello di sistema operativo ai file eseguibili dell'archivio dati, ai servizi, alle utilità e ai comandi di sistema. Inoltre, gli amministratori devono assicurarsi che il gruppo Everyone non abbia autorizzazioni di lettura, scrittura o esecuzione sulla directory o sui file. Il proprietario dei file e delle directory deve essere il DBA o altro proprietario appropriato e l'accesso al gruppo deve appartenere al gruppo definito per gli utenti dell'archivio dati. Se ciò non viene fatto, gli utenti non autorizzati ad accedere al database possono ancora accedere ai dati (ovvero, leggere, modificare o eliminare) a livello di sistema operativo utilizzando l'accesso alla riga di comando della directory di dati. Pertanto l'integrità, la disponibilità e la riservatezza dell'archivio dati potrebbero essere compromesse.Un utente che ha accesso alla riga di comando potrebbe ignorare i controlli di sicurezza delle applicazioni e dell'archivio dei dati per eseguire servizi e funzioni dell'archivio dati.

Profili utente

Analogamente ai gruppi di sistemi operativi, è necessario utilizzare i profili di database per imporre limiti di risorse a un utente oa un gruppo specifico di utenti. I profili dovrebbero essere creati e assegnati a un utente o al numero di utenti. Se viene utilizzato solo il profilo predefinito, nessun limite di risorse verrà applicato a un account utente. L'accesso non autorizzato (ovvero, più accesso di quello che gli utenti richiedono per svolgere il proprio lavoro) al sistema potrebbe risultare, a seconda della natura del Banca dati. Come con i gruppi, i profili dovrebbero essere separati dalla funzione lavoro. Ad esempio, DBA e gli utenti SAP dovrebbero essere separati. Agli utenti SAP non dovrebbe essere consentito di interagire direttamente con il database, perché non riempiono un ruolo di amministrazione del database. Allo stesso modo, gli amministratori di database non dovrebbero avere accesso a SAP, perché non è compito loro condurre transazioni finanziarie. Se questi utenti condividono un profilo, esiste il rischio che transazioni non autorizzate possano essere completate al di fuori della loro funzione lavorativa.

Accesso al codice sorgente

Gli amministratori dovrebbero consentire l'accesso al codice sorgente solo alle parti obbligatorie. Fornire agli utenti l'accesso alle informazioni sul codice sorgente fornisce informazioni sui meccanismi di protezione in atto e aumenta il rischio che si verifichino modifiche non autorizzate o inappropriate al codice sorgente.

Accesso per gli sviluppatori

Per aiutare a prevenire modifiche accidentali e non autorizzate all'ambiente di produzione, l'accesso in scrittura degli sviluppatori all'ambiente dovrebbe essere limitato.

Registrazione e monitoraggio

Le attività di sistema su qualsiasi server di archiviazione dati contenente dati business-critical devono essere registrate e monitorate. La registrazione e il monitoraggio devono includere eventi quali errori di accesso, modifiche alle autorizzazioni, modifiche ai dati critici, utilizzo dell'ID privilegiato e riciclaggio dei servizi.

CONTROLLI DI RETE

Un altro tipo di controlli generali del computer, i controlli di rete, vengono utilizzati anche per implementare la sicurezza dell'archivio dati. Ad esempio, gli archivi di dati ERP dovrebbero risiedere solo sulla rete interna o essere separati all'interno della propria rete protetta. I firewall possono aiutare a proteggere gli archivi dati limitando l'accessibilità del server e si devono prendere in considerazione diversi controlli collegati alla rete.

Le connessioni di rete

Le connessioni basate su Internet non dovrebbero essere autorizzate ad accedere alle risorse situate sulla rete interna aziendale. Tali connessioni aumentano il rischio che si verifichi un incidente di sicurezza. Il firewall dovrebbe negare tutte le connessioni a meno che non siano specificamente richieste per supportare uno scopo aziendale. L'accesso al server dell'archivio dati deve essere concesso solo all'applicazione ERP, agli account di servizio pertinenti, agli amministratori di rete richiesti e agli amministratori necessari dell'archivio dati. Queste restrizioni riducono al minimo il rischio che le parti non autorizzate abbiano accesso a informazioni sensibili.

Annunci DNS

Le voci DNS (Domain Name Service) interne devono essere separate dai database DNS esterni. L'elencazione dei sistemi interni in un database DNS accessibile al pubblico potrebbe consentire agli intrusi di ottenere informazioni sulla topologia e sui sistemi della rete aziendale, dando quindi loro la possibilità di accedere ai dati aziendali.

Configurazioni del firewall

L'accesso per visualizzare o modificare le configurazioni del firewall deve essere strettamente controllato per mantenere l'integrità della rule base. La mancata implementazione di controlli rigorosi relativi agli utenti e alle workstation autorizzati a gestire il firewall aumenta il rischio che si verifichino modifiche inappropriate alla configurazione del firewall. L'accesso fisico al firewall deve essere limitato al personale tecnico chiave che richiede l'accesso per le procedure di manutenzione e di emergenza.

Servizi e protocolli

Gli amministratori dovrebbero disabilitare servizi e protocolli non necessari. Ogni servizio o processo non esplicitamente richiesto per supportare le funzioni aziendali rappresenta una potenziale esposizione. Se tale esposizione fosse sfruttata per accedere all'host o comprometterne la capacità di operare correttamente, le persone non autorizzate potrebbero compromettere l'archivio dati.

Programma antivirus

Il software antivirus riduce il rischio di virus, worm, cavalli di Troia e altri eseguibili dannosi in esecuzione sui server. Questi programmi, tuttavia, possono anche influire sulle prestazioni del server e della rete e potrebbero potenzialmente inviare informazioni interne a parti esterne.

Registrazione e monitoraggio

Monitorare la rete per tentativi di intrusione aiuta a identificare attività non autorizzate o inappropriate. Mantenere una consapevolezza delle normali transazioni aiuterà a identificare gli eventi che sono anormali nell'ambiente. Le attività di monitoraggio possono variare dalla revisione manuale dei registri alla distribuzione di un IDS. L'accesso ai file di registro deve essere limitato per impedire agli utenti non autorizzati di ottenere informazioni di sicurezza sull'host e sull'ambiente.

Traffico spoofato

Gli amministratori dovrebbero implementare i controlli per proteggersi dal traffico falsificato; cioè, il traffico che nasconde la sua vera fonte dietro un interno o un altro indirizzo IP affidabile. Questo tipo di traffico è considerato un attacco. La mancata ispezione del traffico per pacchetti contraffatti può lasciare aperta la rete interna per l'attacco.

■ Sicurezza dei servizi Web Il Web segue una premessa semplice: utilizzare i metodi standard per codificare le informazioni - Hypertext Markup Language (HTML) - e accedervi - Hypertext Transfer Protocol (HTTP) - da qualsiasi computer in rete dotato di browser Web, indipendentemente dal suo funzionamento sistema. Un concetto simile è alla base dei servizi Web e dell'XML (Extensible Markup Language): standardizza il modo in cui i componenti e le applicazioni software comunicano tra loro su Internet o attraverso qualsiasi rete, indipendentemente dalle piattaforme host o dagli ambienti software in cui vengono eseguiti. Servizi Web e XML   specificare un modo semplificato per i sistemi di interoperare su Internet, consentendo la condivisione delle risorse di informazioni - applicazioni e dati e facilitando lo sviluppo di software in grado di accedere e manipolare le informazioni.
Molte aziende stanno ritardando le implementazioni dei servizi Web a causa dei seguenti problemi di sicurezza:

• La capacità delle tecnologie di sicurezza dell'infrastruttura convenzionale come firewall e IDS per proteggere le risorse accessibili tramite i servizi Web.

• La possibilità che i nuovi attacchi di hacker specifici dei servizi Web possano essere difficili da individuare e sconfiggere.

• Protezione inadeguata per i servizi Web fornita da protocolli di sicurezza dell'infrastruttura esistenti come SSL e dal fatto che i nuovi protocolli di sicurezza specifici dei servizi Web sono ancora in fase di sviluppo.
Mentre il traffico standard basato sul Web coinvolge l'HTML dal server al browser, il traffico dei servizi Web può coinvolgere le API (Application Programming Interface) che inviano i dati avanti e indietro su una varietà di protocolli, inclusi HTTP e SMTP. Ogni interfaccia dell'applicazione di servizio Web può avere centinaia di operazioni a cui è possibile accedere, fornendo agli hacker e ad altri utenti non autorizzati nuove opportunità di compromettere i sistemi. Ad esempio, una richiesta di prestito bancario per una transazione immobiliare potrebbe essere esposta come servizio Web. Una volta invocata, questa applicazione potrebbe dover eseguire una serie di operazioni quali la verifica dell'identità, la verifica della cronologia del credito, la verifica del valore di valutazione, il calcolo del pagamento o il trasferimento di fondi. Ogni operazione successiva può comportare altre operazioni più granulari.Compromettere una delle operazioni componente può fornire a un utente malintenzionato l'opportunità di accedere ad altre applicazioni e ai relativi dati.
Queste preoccupazioni sono amplificate dalle considerazioni aggiuntive di architettura e implementazione introdotte dai servizi Web.

Basato sul messaggio Mentre le applicazioni tradizionali sono orientate alla connessione e supportano le implementazioni di sicurezza a livello di connessione, i servizi Web sono orientati ai messaggi e mancano della garanzia di una connessione diretta tra fornitore di servizi e consumatore. In uno scenario di connessione diretta, i dati che viaggiano tra i sistemi possono essere protetti dalle applicazioni o dalla rete.
Coordinamento del sistema L'architettura dei servizi Web richiede un coordinamento significativo tra diversi sistemi. Ad esempio, un'implementazione di servizi Web può includere l'accesso a applicazioni precedenti, l'accesso a servizi Web esterni e l'interfaccia con altre applicazioni aziendali utilizzando tecnologie di servizi Web. È probabile che i componenti dell'implementazione abbiano meccanismi di sicurezza diversi, che complicano sia il coordinamento dell'autenticazione e dell'autorizzazione, sia il mantenimento dell'integrità e della riservatezza tra le interfacce dei servizi Web. Se si verifica un errore di sicurezza in uno qualsiasi dei componenti, la vulnerabilità potrebbe mettere a rischio tutti gli altri sistemi partecipanti.

Interazione macchina-macchina.

Le operazioni dei servizi Web sono prevalentemente interazioni machine-to-machine, pertanto la creazione, la federazione e la gestione di identità e titolarità digitali in tutti i domini di sicurezza rappresentano un'altra sfida. L'utilizzo di tecnologie di servizi Web per attività business-to-business implica che le organizzazioni interagenti debbano consentire agli utenti esterni (macchine o persone) di accedere alle loro applicazioni aziendali. Le pratiche e gli standard di sicurezza esistenti che sono stati sviluppati per uso interno possono essere privi di significato, inappropriati o completamente inaccettabili quando vengono introdotti utenti esterni. Ad esempio, una politica interna può imporre che solo i membri di un particolare gruppo o reparto con titoli di lavoro o gradi specifici possano accedere a una determinata risorsa; chiaramente, questi criteri potrebbero non essere applicabili per gli utenti esterni.
Interoperabilità. I servizi Web aumentano anche la complessità dei test, della gestione delle modifiche e della risoluzione dei problemi dei componenti delle applicazioni a causa della natura dinamica e non strettamente correlata dell'ambiente di runtime dei servizi Web. Per garantire l'interoperabilità sicura ed efficace, le aziende che implementano servizi Web devono testare attributi quali:

• Pubblicare, trovare e associare funzionalità di un ambiente di servizi Web

• Funzionalità intermediario del protocollo SOAP (Simple Object Access Protocol)

• Monitoraggio della qualità del servizio

• Test di orchestrazione dei servizi Web

• Controllo delle versioni del servizio Web

Poiché alcuni requisiti di test influiscono sulla progettazione dei servizi Web, i nuovi strumenti di test richiedono sia funzionalità di test di runtime che funzionalità di progettazione.

PROBLEMI DI SICUREZZA PER I SERVIZI WEB

Le discipline di sicurezza utilizzate abitualmente in ambienti tipici - autenticazione, autorizzazione e controllo degli accessi, crittografia e integrità dei dati - svolgono anche un ruolo importante nel fornire livelli di sicurezza di base per le comunicazioni dei servizi Web.
I richiedenti del servizio Web di autenticazione devono essere autenticati dal fornitore di servizi Web prima che la richiesta venga elaborata. Le applicazioni Web standard utilizzano password, certificati X.509, Kerberos, LDAP (Lightweight Directory Access Protocol) e altre tecnologie per l' autenticazione. Quando un'organizzazione adotta un approccio ai servizi Web, potrebbe richiedere ulteriori misure di sicurezza per proteggere e autenticare i componenti dei servizi Web esposti in altro modo.
Ad esempio, un'applicazione Web di e-commerce potrebbe utilizzare un servizio di terze parti per autorizzare l'acquisto di una carta di credito. Implementato come servizio Web, l'elaborazione potrebbe richiedere la creazione di un file WSDL (Web Services Description Language) che descrive il servizio. Tuttavia, questo requisito può introdurre una vulnerabilità di sicurezza perché il file WSDL può essere manomesso, causando forse un richiedente del servizio a comunicare con un provider di servizi Web non autorizzato che sta impersonando il provider desiderato. Le interazioni dei servizi Web richiedono due tipi di autenticazione: oltre all'autenticazione reciproca tra l'utente e il fornitore del servizio, è necessaria anche l'autenticazione principale (ovvero dell'utente finale). Il primo tipo di autenticazione, tra consumatore e provider, viene generalmente realizzato utilizzando la sicurezza orientata alla connessione come SSL;l'autenticazione principale è più difficile e richiede un certo tipo di token di autenticazione messageembedded.

Autorizzazione e controllo degli accessi

L'autorizzazione è fondamentale perché i servizi Web possono introdurre livelli di accesso complessi. La sicurezza dei servizi Web richiede la determinazione delle informazioni a cui gli utenti o le applicazioni possono accedere, nonché le operazioni che un'applicazione o un utente possono eseguire. Poiché i servizi Web sono interfacce programmatiche, potrebbero essere più difficili da monitorare per attività sospette rispetto alle applicazioni standard. Ad esempio, l'accesso non autorizzato a un'interfaccia SOAP protetta in modo non corretto può facilmente non essere rilevato perché potrebbe apparire come una chiamata API da parte di un programma autorizzato. Questo scenario è simile a quello di proteggere le pagine Web e le applicazioni che possono essere incorporate in esse; l'URL della pagina Web può essere protetto utilizzando le soluzioni di controllo dell'accesso Web e Single Sign-On (SSO),ma l'applicazione all'interno della pagina non è protetta perché non è un URL (Uniform Resource Locator).
Poiché i servizi Web consentono un'integrazione molto più semplice con applicazioni e provider di servizi di terze parti, come fornitori, clienti e altri partner commerciali, i diritti di autenticazione e di accesso devono essere strettamente controllati e aggiornati. Ma il coinvolgimento di più parti può rendere difficile la standardizzazione su uno schema di autenticazione e controllo degli accessi. Ad esempio, gli scambi business-to-business hanno la sfida aggiuntiva di gestire più formati di autenticazione tra i loro membri. Nel peggiore dei casi, ogni servizio Web in un'applicazione business-to-business richiederebbe una credenziale separata per ciascun servizio a cui si accede.
Il SAML (Security Assertion Markup Language) è progettato per facilitare la gestione e l'interoperabilità delle credenziali di sicurezza tra domini di sicurezza, ma se il payload SAML non è protetto da sé, potrebbe presentare una vulnerabilità di sicurezza che potrebbe essere sfruttata da un utente malintenzionato. Le soluzioni SSO Web e di mappatura delle credenziali progettate per rendere questi ambienti più facili da gestire e più facili da usare per i partecipanti possono presentare un ulteriore rischio per la sicurezza se non sono state adottate misure di sicurezza adeguate.

Gestione della sessione

Poiché i servizi Web sono generalmente privi di stato, i componenti di servizio devono autenticare il client su ogni accesso, a meno che non siano state adottate le misure di sicurezza appropriate. Ad esempio, un servizio Web che avvia una transazione di trasferimento di fondi può consistere in diverse operazioni e contenere più passaggi. Ogni passo, ad esempio, accedere, scegliere account, scegliere gli importi, confermare, richiederebbe l'autenticazione da parte dell'utente, il che potrebbe raddoppiare il numero di interazioni richieste.

I componenti dei servizi Web possono sfruttare le tecnologie Web SSO e utilizzare i cookie o le sessioni SSL per garantire la fiducia per un determinato periodo di tempo. In alternativa, alcune soluzioni offrono implementazioni di macchine a stati che aiutano ad alleviare questo problema. Tuttavia, la stessa gestione dello stato può diventare un rischio per la sicurezza. Ad esempio, se una soluzione di gestione dello stato persistente dovesse mantenere le informazioni di stato esposte abbastanza a lungo, un utente malintenzionato potrebbe sfruttare le informazioni sulla sessione memorizzate e impersonare l'utente autorizzato. Questo tipo di vulnerabilità potrebbe risultare da una circostanza semplice come un utente autorizzato che lascia un sistema incustodito, consentendo così l'accesso non autorizzato da parte di un altro utente che potrebbe - maliziosamente o semplicemente incautamente - eseguire altre operazioni con i dati.

Crittografia e privacy dei dati

In genere, la crittografia SSL standard garantisce la riservatezza dei dati point-to-point tra i punti finali dei richiedenti il ​​servizio e i provider di servizi. Tuttavia, data la natura disconnessa e non strettamente correlata dei servizi Web, il fornitore di servizi potrebbe non essere la destinazione finale per il messaggio di transazione e potrebbe anche fungere da richiedente di un servizio come parte di una transazione commerciale a più stadi. Ad esempio, un servizio Web che gestisce l'acquisto di attrezzature può essere risolto nell'applicazione dell'ordine di acquisto dell'acquirente. L'applicazione dell'ordine di acquisto, a sua volta, funge da consumatore per il produttore dell'apparecchiatura, che può essere un consumatore di servizi per la società di spedizione e così via durante il processo di acquisto. Poiché la crittografia SSL termina su un server Web o applicativo, affidarsi a SSL per la protezione end-to-end potrebbe essere insufficiente;una protezione aggiuntiva, come l'utilizzo dello standard XML Encryption, consentirebbe la crittografia di porzioni del messaggio SOAP, offrendo una maggiore sicurezza durante tutto il ciclo di elaborazione.
La crittografia, tuttavia, può ostacolare il rilevamento dei virus. Come con la posta elettronica, il traffico dei servizi Web potrebbe includere allegati. Quando il contenuto viene crittografato, anche i virus che possono essere incorporati nel messaggio vengono crittografati, rendendo difficile per un motore antivirus rilevare i dati infetti.
Integrità e riservatezza dei dati Un'organizzazione che espone un'applicazione interna come servizio Web può anche esporre archivi dati di supporto, come database, registri o directory. Questi dati devono essere protetti, mediante crittografia o, se l'impatto delle prestazioni della crittografia non è un'opzione accettabile, fornendo controlli di accesso basati sulle risorse (controllo dell'accesso basato sulla valutazione dei nomi di risorse come i nomi dei database rispetto a un elenco di utenti autorizzati ). I dati possono anche essere in pericolo di intercettazione mentre vengono elaborati, specialmente quando un servizio Web utilizza dati temporanei memorizzati localmente e l'archiviazione locale non è adeguatamente protetta.
Un altro problema di protezione dei dati è la potenziale intercettazione e modifica dell'output di un servizio Web. Lo standard XML Signature fornisce un modo per firmare parti di documenti XML, fornendo l'integrità dei dati end-to-end su più sistemi. Un vantaggio chiave della firma è il concetto di verificabilità e non ripudio: la capacità di dimostrare che una determinata azione ha avuto luogo. Ad esempio, una richiesta di prestito online deve essere approvata da un funzionario bancario autorizzato e una traccia di controllo di tutte le azioni eseguite deve essere mantenuta ai fini del controllo e della risoluzione delle controversie. Se l'applicazione è un modulo basato su XML, alcuni campi (come il nome del richiedente e il numero di previdenza sociale, l'importo del prestito, il nome dell'approvatore e la firma) possono essere crittografati e firmati da un ufficiale di prestito.

Contesto condiviso Contesto condiviso si riferisce alle informazioni che un servizio Web deve conoscere su un consumatore di servizi per fornire un'esperienza personalizzata e personalizzata; i dati di contesto condiviso possono includere l'identità del consumatore, la posizione del consumatore e eventuali vincoli di riservatezza associati alle informazioni del consumatore. Quando diversi servizi Web discreti vengono aggregati per creare un servizio aziendale composito, i servizi partecipanti devono condividere le informazioni sul contesto.
Ad esempio, un consumatore che pianifica una vacanza può utilizzare un servizio di viaggio online che è in realtà un insieme di servizi Web aggregati di compagnie aeree, hotel e servizi di autonoleggio. I servizi devono comunicare tra loro per soddisfare il programma, il budget e le altre preferenze dell'acquirente. Tuttavia, il consumatore può chiedere esplicitamente di non rivelare particolari informazioni personali a nessuno dei servizi partecipanti. Per rispondere adeguatamente alle preoccupazioni di convenienza e privacy del consumatore, i servizi devono utilizzare un complesso insieme di regole e salvaguardie per garantire l'integrità dei dati e dell'identità dell'utente.

APPLICAZIONI DI SERVIZI WEB E ATTACCHI MORTALI

Come con qualsiasi applicazione componente, le applicazioni di servizi Web sono vulnerabili agli attacchi perché rappresentano una catena di componenti di elaborazione la cui sicurezza è forte quanto il collegamento più debole. Questo collegamento è il più vulnerabile agli attacchi e può compromettere altri componenti della catena. Lo sfruttamento delle vulnerabilità può avvenire in vari modi:

• I dati che fluiscono da o verso il componente di collegamento debole possono essere intercettati, consentendo ad un intruso di acquisire informazioni sensibili, personali o di valore.

• I flussi di dati che viaggiano tra i componenti possono essere manipolati per alterare i dati, reindirizzare i dati o utilizzare server ignari per montare un attacco DoS.

• Un componente può essere spento completamente, negando la sua funzionalità agli altri componenti che dipendono da esso; questo può effettivamente distruggere le attività degli utenti da molti punti di accesso differenti.

• Se il meccanismo di condivisione delle credenziali tra un servizio e l'altro non è sicuro, i presidi di un servizio Web intermedio possono essere rappresentati.

Sebbene un compromesso più debole non sia esclusivamente una vulnerabilità dei servizi Web, i servizi Web offrono maggiori opportunità di compromissione grazie alla semplicità percepita del design: il traffico dei servizi Web scorre attraverso le porte 80 (HTTP) e 443 (HTTPS), proprio come il traffico del sito Web standard . La maggior parte dei firewall è in grado di riconoscere i messaggi SOAP ma visualizzarli come traffico HTTP ben formato (sintatticamente corretto). Possono essere configurati solo per consentire o rifiutare il traffico SOAP; tuttavia, i firewall XML più recenti possono ispezionare i contenuti SOAP e consentire in modo selettivo il passaggio di determinati servizi Web. Ma il filtraggio XML e SOAP potrebbe non essere adeguato perché, come notato in precedenza, le interfacce dei servizi Web sono molto più complesse delle interfacce del sito Web che scambiano solo pagine e moduli HTML.
Un'applicazione abilitata ai servizi Web può, per esempio, avere esposto centinaia o migliaia di operazioni critiche, tutte accessibili tramite la porta 80. Inoltre, un utente malintenzionato ha più informazioni disponibili, come i file WSDL e Descrizione universale, individuazione e integrazione (UDDI voci, siano esse private o pubbliche. L'esposizione al WSDL è particolarmente pericolosa perché il suo formato XML è auto-descrittivo e definisce chiaramente gli elementi dei dati. Quindi l'esposizione WSDL può fornire un attaccante intelligente con un modo documentato per invocare un servizio - le sue API, i parametri accettati e così via - sufficienti informazioni forse per consentire all'aggressore di entrare   Oltre agli attacchi ai collegamenti deboli basati su UDDI e WSDL esposti dalle implementazioni dei servizi Web, i componenti dei servizi Web possono essere vittime dei tradizionali tipi di attacchi. Ma come gli attacchi sono diventati più sofisticati, così hanno le contromisure. Nell'ambiente dei servizi Web, queste contromisure includono l'analisi di più informazioni, come il contenuto dei messaggi SOAP e i sistemi di sicurezza per aiutare a rilevare e scoraggiare gli attacchi. Ad esempio, le informazioni nelle intestazioni SOAP consentono ai firewall, agli IDS e agli IPS di analizzare il traffico e persino il carico utile per attività, riconoscimento dei pattern e auditing. Le misure preventive come questa sono efficaci, ma devono essere considerate parte di un processo continuo, in modo che gli strumenti di sicurezza e di monitoraggio siano in linea con i continui progressi dell'hacking.

QUADRO DI SICUREZZA DEI SERVIZI WEB

Per un utilizzo aziendale efficace e accettabile dei servizi Web, l'autenticazione e la non recidiva devono essere applicate ai messaggi dei servizi Web a livello granulare. Questo requisito potrebbe potenzialmente coinvolgere molti utenti in organizzazioni disparate in situazioni in cui potrebbe essere necessario crittografare e autenticare una transazione in sequenze arbitrarie. Inoltre, la capacità di fornire una gestione dell'identità digitale che può estendersi su più organizzazioni è essenziale per le transazioni business-to-business di alto livello. Queste complessità possono rendere più difficile prendere decisioni a livello aziendale e verificare la conformità agli standard di sicurezza aziendali.
Pertanto, un aspetto critico di qualsiasi architettura di servizi Web deve essere un framework di gestione della sicurezza che consenta un'organizzazione centralizzata e il coordinamento di diversi sistemi di sicurezza in modo interoperabile e gestito. Tale framework potrebbe non essere posizionato in modo esclusivo per supportare i servizi Web, ma potrebbe essere incentrato sull'affrontare problemi di sicurezza più ampi. Per garantire che un framework di gestione della sicurezza possa fornire la funzionalità desiderata, deve essere implementato come un'istanza di un'architettura orientata ai servizi (SOA).
Tale framework di gestione della sicurezza estenderebbe la nozione di gestione basata su policy per consentire l'impostazione e l'applicazione di policy di sicurezza su tutti i servizi Web presenti nell'organizzazione. Un quadro di gestione della sicurezza includerebbe ma non si limiterà a quanto segue:
• Identità interoperabili affidabili: - Identity federation (collegamento di identità tra vari domini di sicurezza) - Condivisione di autenticazione (scambio degli stati di autenticazione) - Condivisione di attributi (scambio di informazioni su attributi / ruoli)

• Credenziali interoperabili: emissione, scambio e convalida di credenziali digitali

• Politiche interoperabili: - Politiche operative - Politiche di accesso alle risorse - Politiche di riservatezza e privacy • Modelli di fiducia: - Modelli di fiducia delle imprese - Modelli di trust crittografico

• Integrità e riservatezza dello scambio di messaggi

STANDARD DI SICUREZZA DEI SERVIZI XML E WEB

I blocchi di base dei servizi Web, SOAP, WSDL e UDDI, non riguardano la sicurezza. Pertanto, sono necessari nuovi standard come SAML e WS-Security per garantire che le architetture dei servizi Web siano in grado di soddisfare i requisiti di sicurezza aziendali. Inoltre, sono richiesti anche gli standard che affrontano i problemi di sicurezza relativi all'XML, il linguaggio di base dei servizi Web.
Linguaggio markup assertion di sicurezza ratificato dall'Organizzazione per il progresso degli standard di informazioni strutturate (OASIS) nel quarto trimestre del 2002, SAML 1.0 è una specifica per un framework di sicurezza basato su XML che abiliterà una rete federata di gestione delle identità per l'interoperabilità tra distribuzioni servizi e siti Web ospitati.
SAML 1.0 fornisce lo scambio sicuro di informazioni di autenticazione e autorizzazione utilizzando Transport Layer Security (TLS) con standard di servizi Web di base come XML e SOAP. SAML offre inoltre suggerimenti e best practice per l'utilizzo degli standard XML Signature e XML Encryption con i messaggi SAML. I vantaggi di SAML includono SSO.
SAML è stato sviluppato dal Comitato tecnico dei servizi di sicurezza di OASIS, con i contributi di BEA, HP, IBM, Netegrity, RSA Security, Sun, VeriSign e le società di infrastrutture a chiave pubblica Baltimore Technologies e Entrust. Inizialmente, c'era la preoccupazione che le specifiche SAML potessero competere con WS-Security, che è supportato da IBM e Microsoft. Tuttavia, le due specifiche sono complementari e i fornitori si stanno impegnando a utilizzare SAML per le prossime soluzioni di gestione degli accessi Web.
I seguenti tre scenari mostrano come utilizzare SAML per il controllo dell'accesso ai servizi Web:

• SSO Web distribuito: in questo scenario, un utente Web ha autenticato (ha dimostrato la propria identità) il sistema di sicurezza della società A e desidera accedere al sito Web della società partner B. Nonostante l'utilizzo di diversi sistemi di sicurezza, queste società hanno concordato che si fiderà dell'autenticazione degli altri utenti. Questa cooperazione richiede un collegamento tra i sistemi SSO dei due domini, fornito da SAML.

• Transazione distribuita: questo scenario implica una transazione che scorre tra due organizzazioni, ad esempio una transazione finanziaria tra gateway business-to-business. A seconda dei rapporti commerciali stabiliti, le diverse informazioni sulla sicurezza correlate alla transazione dovranno essere comunicate tramite SAML tra le parti della transazione. Esempi di informazioni sulla sicurezza possono includere l'identità dell'iniziatore della transazione, i tipi di autenticazione forniti, gli attributi sull'utente e le decisioni di autorizzazione prese da un'autorità.

• Il SAML affidabile di terze parti può anche essere utile quando un'organizzazione deve richiedere informazioni sulla sicurezza da una terza parte attendibile. Ad esempio, un dipendente della Società A potrebbe essere registrato nel sito Web di un fornitore per ordinare forniture per ufficio. Il sistema del fornitore dovrebbe determinare se elaborare l'ordine, quindi utilizzerebbe SAML per interrogare la società A per determinare se il dipendente è autorizzato a effettuare l'ordine.

La specifica SAML include uno schema XML che definisce asserzioni SAML e messaggi di protocollo. La specifica descrive anche i metodi per associare queste asserzioni ad altri protocolli esistenti (come HTTP e SOAP) per abilitare funzionalità di sicurezza aggiuntive. I componenti di SAML sono:
• Asserzioni SAML: le asserzioni SAML sono le dichiarazioni fatte per comunicare le informazioni di autenticazione e autorizzazione. SAML specifica tre tipi di asserzioni: - Le asserzioni di autenticazione contengono affermazioni che un determinato sistema (o utente) ha dimostrato la propria identità (autenticata) a una determinata autorità o dominio di sicurezza. - Le asserzioni di attributo contengono istruzioni sugli attributi di un sistema o utente; queste dichiarazioni possono essere utilizzate dai sistemi di sicurezza per elaborare le regole di autorizzazione o dalle applicazioni nei loro processi aziendali. - Le asserzioni sulle decisioni di autorizzazione contengono dichiarazioni sui risultati di un'applicazione della politica di autorizzazione.

• Protocollo SAML: SAML definisce uno schema XML per i messaggi di richiesta e risposta conformi alle specifiche SOAP per la definizione dei servizi Web. Il protocollo SAML supporta i collegamenti SAML, ma può anche essere utilizzato indipendentemente come modo per le organizzazioni di comunicare le informazioni di sicurezza.

• Bind SAML: uno dei modi in cui verrà utilizzato SAML è il binding a protocolli esistenti per una maggiore sicurezza. L'attuale specifica SAML definisce due collegamenti: il binding SSO del browser Web e il binding SOAP. Il collegamento SSO del browser Web consente l'SSO tra i sistemi Web delle organizzazioni standardizzando i sistemi Web per la comunicazione dell'autenticazione degli utenti. L'associazione SOAP SAML descrive un metodo per associare le asserzioni SAML ai normali messaggi SOAP per associare le varie caratteristiche di sicurezza (autenticazione, attributi o decisioni di autorizzazione) ai messaggi.

WS-Security

Lo standard WS-Security è stato originariamente proposto da IBM, Microsoft, RSA Security e VeriSign all'inizio del 2002. WS-Security fornisce meccanismi standard per lo scambio di messaggi sicuri e firmati in un ambiente di servizi Web e fornisce un livello di base che aiuterà gli sviluppatori a costruire servizi Web più sicuri e ampiamente interoperabili.
WS-Security è progettato per essere flessibile e modulare in modo da adattarsi efficacemente alla varietà di sistemi che possono essere utilizzati tra le organizzazioni che collaborano, che possono anche adottare approcci di sicurezza diversi. Questo approccio interoperativo consente alla tecnologia di sicurezza e al suo utilizzo aziendale di evolvere secondo le esigenze. Di conseguenza, la roadmap WS-Security descrive come supportare gli approcci di sicurezza attuali e futuri. Le organizzazioni possono scegliere le credenziali che desiderano utilizzare, ad esempio ID utente e password, certificati X.509 o certificati Kerberos. Il processo di adozione e distribuzione può essere incrementale, consentendo in tal modo alle organizzazioni di iniziare con le credenziali di ID utente e password di base e successivamente di adottare meccanismi di sicurezza più potenti.WS-Security fornisce una specifica generica per associare i token di sicurezza ai messaggi utilizzando gli standard XML Signature e XML Encryption.
WS-Security è la base per una road map più ampia e un set aggiuntivo di funzionalità per la sicurezza dei servizi Web delineati principalmente da IBM e Microsoft. Le società continuano a sviluppare le specifiche sussidiarie, come WS-Trust, WSPolicy e WS-Secure Conversation. La roadmap WS-Security include i seguenti standard.

WS-Trust.

La specifica WS-Trust è stata rilasciata come bozza pubblica nel quarto trimestre del 2002. L'obiettivo di WS-Trust è consentire alle applicazioni di creare meccanismi di fiducia direttamente nello scambio di messaggi SOAP tra fornitori di servizi Web e consumatori. Le estensioni della specifica facilitano la richiesta e l'emissione di token di sicurezza nella gestione delle relazioni di fiducia. Le specifiche non definiscono un protocollo di sicurezza esplicito, ma sono progettate per supportare un intervallo di protocolli esistenti e nuovi. WS-Trust funziona con altri protocolli nello stack di sicurezza, come WSSecurity e WS-Policy, per garantire che un richiedente sia correttamente autenticato e concesso accesso alle risorse appropriato.

WS-SecureConversation. WS-SecureConversation si basa su WS-Security definendo i metodi per derivare e passare le chiavi di sessione, nonché per stabilire e condividere i contesti di sicurezza. Un contesto di sicurezza condiviso viene stabilito quando viene avviata la conversazione tra i partecipanti. Il contesto può essere utilizzato per derivare le chiavi di sessione che aumentano la sicurezza generale riducendo al contempo il sovraccarico dell'elaborazione della sicurezza per ciascun messaggio. Il progetto iniziale di WS-SecureConversation 1.0 è stato rilasciato nel quarto trimestre del 2002.
Framework dei criteri dei servizi Web (criterio WS). WS-Policy fornisce un modello e una sintassi XML per i fornitori di servizi Web e i consumatori per definire le regole di riservatezza e utilizzo delle informazioni. WS-Policy funziona con i meccanismi WS-Security per imporre diritti di accesso e utilizzo ed è progettato per la scoperta tramite WSDL e il repository UDDI . Le specifiche di WS-Policy si basano su ulteriori blocchi di policy, tra cui: il linguaggio delle asserzioni della politica dei servizi Web (WS-PolicyAssertion), che fornisce un linguaggio comune per rappresentare i requisiti e le preferenze individuali; e il collegamento ai criteri dei servizi Web (W-PolicyAttachment), che definisce tre diversi metodi di collegamento per associare le definizioni dei criteri alle entità WSDL e UDDI. La bozza della WS-Policy è stata pubblicata nel quarto trimestre del 2002.

WS-autorizzazione.

WS-Authorization definirà come i servizi Web gestiscono i dati e le politiche di autorizzazione. Le specifiche sono in fase di sviluppo e non sono ancora disponibili al pubblico a partire da ottobre 2003.

WS-Privacy. WS-Privacy è attualmente in fase di sviluppo a partire da ottobre 2003 e definirà in che modo i servizi Web stabiliscono e implementano le pratiche sulla privacy.

WS-Federation. Pubblicato nel luglio 2003, WS-Federation migliora la roadmap WS-Security descrivendo come gestire e mediare le relazioni di trust in un ambiente federato eterogeneo, incluso il supporto per le identità federate. La specifica consente all'utente di accedere a più applicazioni senza accedere a ciascuna applicazione separatamente, anche se le applicazioni sono fornite da società diverse. WS-Federation include i seguenti tre elementi:

• Il profilo Richiedente attivo della Federazione dei servizi Web definisce i mezzi per richiedere, scambiare ed emettere token di sicurezza nel contesto dei richiedenti attivi.

• La lingua della federazione dei servizi Web è il documento delle specifiche che definisce il funzionamento della federazione nello stack WS-Security.

• Il profilo richiedente passivo della Federazione dei servizi Web definisce un sistema in cui i meccanismi passivi funzionano senza problemi utilizzando un accesso singolo o semplificato al sistema WS-Federation.