Posts Tagged ‘Checkpoint’

TCP Split Handshake Attack Explained

April 17, 2011 9 comments

Update May 12: TCP Split Handshake: Why Cisco ASA is not susceptible

Update May 11: The Never Ending Story

Update April 21: Other Considerations on TCP Split Handshake

Few days ago, independent security research and testing NSS Labs, issued a comparative report among six network security technologies. The controversial results created a comprehensible turmoil among the security vendors involved in the tests, and more in general inside the infosec landscape. As a matter of fact it turned out that that five of the six tested platforms were susceptible to TCP Split handshake attack.

As a security professional, I am pretty much involved with at least five of the six tested technologies, consequently, although I never heard about TCP Split Handshake before, I must confess I was really curious to learn which was the only platform capable of surviving the test (the answer is indirectly provided by the vendor – Checkpoint – missing from the list contained on the remediation report subsequently released). Fortunately the scientific side of me took over and instead of making judgments and drawing conclusions about the results, I decided to learn more about TCP Split Handshake and the reasons why a security equipment may be vulnerable.

TCP Split Handshake in RFC 793

Since TCP is a connection-oriented protocol, every connection begins with a “handshake” defined in RFC 793. The handshake defines three well defined steps and for this reason it is called “TCP Three Way Handshake.”

The host initiating the connection, referred as the client, send to its peer, referred as the server, a synchronization packet, or SYN. In order to correctly identify the beginning (and the subsequent “state” of the session, the SYN packet contains an initial Sequence Number (ISN) which corresponds to a pseudo-random number.

Upon reception of the SYN packet, the server acknowledges that, and generates its own SYN. This “SYN/ACK” packet contains both the server’s Initial Sequence Number, as well as an acknowledgment number equal to the client’s Sequence Number plus 1. The fact that the server sends a single packet to initiate the connection on its side and to acknowledge the initial SYN sent from the client is known as piggy-backing and, as explained later, is the fundamental aspect in which TCP Split Handshake differs from Three Way Handshake.

At this point, in order to establish the session, the client concludes the Three Way Handshake and acknowledges the server’s SYN/ACK, sending a packet with its own ISN incremented by one, as well as its acknowledgement number equal to the server’s ISN plus 1.

As mentioned above, in the second phase of the handshake, the piggy-backing allows the server to use a single packet to send its own SYN and to acknowledge the SYN packet received from the client (ACK). However, let us assume that the server could decide to split the second phase of the handshake and send a dedicated ACK packet to acknowledge the client SYN, and a further dedicated packet with its own SYN. This is exactly what is stated at section 3.3, page 27, of RFC 793, which introduces an intriguing four-step process:

1) A --> B  SYN my sequence number is X
2) A <-- B  ACK your sequence number is X
3) A <-- B  SYN my sequence number is Y
4) A --> B  ACK your sequence number is Y

As a consequence, one might expect that an RFC 793 perfectly compliant client be capable to silently accept packet two, explicitly ACK packet 3, and hence complete the handshake more-or-less normally. At least in theory…

In reality, in such similar circumstances, NSS test have shown that some network security devices, with the sole firewall function enabled, get confused and behaves in a stateless manner. In few words, if even the client behaves as stated in the RFC, that is it is able to correctly establish the session even if it accepts separated ACK and SYN packets from the server, the network security device, on receiving the SYN from the server (packet 2), loses the awareness of the session and lets the traffic flow without enforcing any security control as if it belongs to an uncontrolled session (in theory an unknown or out-of-state session should be blocked). This means that a malicious payload conveyed through a TCP Split Handshake intiated session could go through the firewall and as a consequence, an attack scenario is quite straightforward: an attacker could think to use a server-side malicious script to establish the session by mean of a TCP Split Handshake and consequently install an executable on the client (a very fashionable event in the last days), for instance, by mean of an ActiveX Buffer Overflow on the target client browser.

The bad news is that this kind of attack is not new, and a similar attack scenario was reported for the first time approximately one year ago (with different behaviours reported for clients and security devices). The strange side of the story relies on the fact that this behaviour may not be considered a real vulnerability, but rather an occurrence covered by RFC not correctly implemented or not enabled on the default configuration by security vendors (please consider that RFC 793 also includes a further method for establishing a TCP connection dubbed “TCP Simultaneous Open” in which two TCP hosts simultaneously attempt to open a connection to each other via a SYN packet).

Last but not least…

For the record, as previously stated, NSS Labs released a remediation report containing the indications needed to mitigate (where necessary) the occurrence of the TCP Split Handshake for the affected technologies. Moreover two vendors (Cisco and Fortinet) added some indications as reported in the following:

  • According to an official blog post, Cisco was not able to reproduce the issue occurred in NSS Labs Test and is further investigating the TCP Split Handshake attack on its devices.
  • According to an official response in a blog post, Fortinet is not susceptible to TCP Split Handshake attack if IPS and Antivirus protections are enabled. A special IPS signature has been developed and a firmware update is scheduled for May in order to block TCP Split Handshake attack with only firewall enabled:
  • For Juniper devices the line “set security flow tcp-session strict-syn-check” must be  inserted into configuration (this option affects all the traffic, so it must be set with caution);
  • Palo Alto is working to release an official fix between mid-April and early May;
  • For Sonicwall devices, the option “Enforce Strict TCP Compliance” must be enabled (also in this case this option affects all the traffic and must be set with caution).

Application Security: What’s Next?

April 6, 2011 3 comments

In the wake of the infamous LizaMoon which has flooded an impressive number of databases all over the world with SQL Injection, infecting more than 1,500,000 URLs according to Google Search, the next frontier of Information Security to which security vendors are likely to move, is the branch of application security. The last vendor in order of time to make an acquisition (just a couple of days before LizaMoon was detected) was Intel McAfee, which decided to enter the database security market (estimated more than $ 600 million in 2012) acquiring Sentrigo, a Santa Clara based company focused on database security, former member of the SIA Technology Partnership Program (McAfee Security Innovation Alliance) and currently linked to McAfee by an OEM partnerships.

The red Infosec Colossus of Santa Clara is just the latest player to enter this market, following the example of IBM, which offers a complete Application Security solution since 2009, thanks to the acquisitions (in rigorous chronological order) of DataPower (Web Application/XML Security), Ounce Labs (Code Analysis) and Guardium (Database Security). A set of solutions which form respectively the Websphere, Rational and InfoSphere Guardium Security Solutions.

McAfee and IBM are accompanied by Fortinet, another important security player which has been active in this field for some years. Fortinet has been investing in database and application security since 2006, and even if it lacks a code analysis solution, it offers a portfolio which extends up to the database (scanning and monitoring) level, through the acquisition of IP-Locks, and up to XML /Application Firewall, thanks to its offer of FortiWeb appliances.

As you may notice the three examples above are particularly meaningful of how the security is now converging towards application security. Although McAfee, Fortinet and IBM have very different backgrounds, they are converging to a comparable application security offer: McAfee approached the problem from the endpoint security, which is its historical strength, IBM from the content security, since its adventure in security has started from the acquisition of ISS, and finally Fortinet from the network security, well represented by its Fortigate appliances.

According to my personal model, the complete cycle of application security moves on four levels: training of developers is the first level and the necessary foundation upon which an application security project is built. Where the ability (and security awareness) of developers does not arrive, Vulnerability Assessment/Penetration Test (second level) may be enforced to check the level of security of the applications. If we move to a more “technological” plane there are two more levels: they consist respectively in Code Analysis (a preventive measure) and XML/Application/Database security solutions implemented with dedicated software or appliances (an infrastructural measure). Please consider that (an aspect which is not secondary) these kindw of solutions are also driven by increasingly stringent regulations, such as PCI-DSS, and emerging “De Facto” standards such as OWASP (Open Web Application Security Program).

If IBM is currently the only vendor to cover the three areas of application security (code analysis, XML/Web application security and database security), in addition to McAfee and Fortinet, there are other vendors at the door, looking at this market with great interest starting from Cisco Systems, provided with a great ability to execute, but currently focused primarily on its network-centric approach by mean of its ACE family of XML Firewalls, and HP, which, even if currently leaks an XML/WAF or Database Security solution) is approaching the world of Application Security starting from code analysis thanks to the acquisition of Fortify, considered by many observers the market leader in this field.

Actually, alongside these vendors there are more players which, even if more focused on network security, however, look carefully in this market by offering niche solutions, as is the case, for instance, with Checkpoint, which combines its traditional firewall modules (or software blades according to the current terminology) with Web Security functions specifically tailored for application threat, or also Citrix which approaches the problem from the Application Acceleration/Distribution perspective.

It is likely that the market value and the emotional drive of LizaMoon will soon bring furher earthquakes in this market. In my honest opinion, the next to fall will be two more important partners in the McAfee SIA focused in Application Security: Imperva (Web Application/XML Firewall) and VeraCode (Code Analysis) are well advised…

Il 2011 Secondo Arbor Networks? Me Lo Tolgo DDoS…

February 8, 2011 3 comments

Arbor Networks, il principale produttore di sensori anti-DDoS, oramai da qualche anno tiene sotto controllo, con l’aiuto dei principali operatori, la madre di tutte le reti al fine di studiare l’andamento degli attacchi DDoS ed i relativi trend di diffusione.

Dal lontano 2005 Arbor Networks pubblica annualmente il Worldwide Infrastructure Security Report che riassume i dati raccolti nei 12 mesi che spaziano da ottobre 2009 a settembre 2010, e consente di capire cosa è accaduto dal punto di vista della sicurezza infrastrutturale nel corso dell’anno appena passato, permettendo nel contempo di gettare le basi per tracciare l’evoluzione dei grandi attacchi geografici nel corso del 2011.

Naturalmente il 2010, uno degli anni più “prolifici” per quanto riguarda gli eventi di sicurezza, non ha fatto mancare le sorprese nemmeno per gli attacchi DDoS. I risultati, sintesi di un questionario di 113 domande posto a 111 operatori appartenenti a Stati Uniti, Canada, America Centro-Meridionale, EMEA, Africa e Asia sono riassunti nei punti sottostanti:

Alcuni Dati Preliminari

Il 68% degli intervistati ha indicato che gli attacchi DDoS verso i propri clienti sono stati una minaccia significativa nei 12 mesi oggetto della survey. Il 61% degli intervistati ha anche identificato corresponsabilità nelle configurazioni errate o nei malfunzionamenti degli apparati. Come si nota in questa poco invidiabile classifica anche le Botnet (e gli effetti collaterali derivanti) occupano posizioni di tutto rispetto.

Per quanto riguarda gli attacchi a livello applicativo ai primi posti si classificano HTTP, DNS e SMTP seguiti da SIP/VoIP e HTTPS. All’interno di “Other” ricadono protocolli quali SSH, FTP, Telnet, RDP, SQL, IRC, etc.

Mentre le maggiori preoccupazioni di sicurezza hanno coinvolto attacchi verso i clienti, attacchi verso i servizi accessori degli operatori, attacchi verso gli apparati di rete, botnet e nuove vulnerabilità. Interessanti soprattutto quest’ultime poiché rilevate , in questo caso, da un produttore di sicurezza infrastrutturale analogamente a quanto fatto da alcuni produttori di sicurezza dell’endpoint.

Andando ad Analizzare i risultati della survey nel suo complesso, ecco i punti di maggior interesse:

Lascia e Raddoppia.

Nel corso del 2010 il volume degli attacchi DDoS è drammaticamente aumentato.. Il respiro lasciato agli amministratori di rete negli anni 2008 e 2009 è stato illusorio e quest’anno per la prima volta è stata superata la barriera dei 100 Gbps in un singolo attacco. Questo volume di fuoco è praticamente raddoppiato rispetto all’analogo evento rilevato nel corso del 2009 (aumento del 102%) ed è addirittura aumentato di un fattore 10 (corrispondente ad un iperbolico 1000%) rispetto al 2005, anno di rilevazione della prima survey

Gli attaccanti si “applicano” sempre di più

I data Center e gli operatori mobili e wireless hanno registrato un incremento del livello di sofisticazione e impatto operativo degli attacchi in quanto gli attaccanti si sono rivolti, nel corso del 2010, con maggiore insistenza verso attacchi DDoS al livello applicativo verso i propri servizi o quelli dei propri clienti.

La disponibilità è sempre più cara

Secondo l’analisi di Arbor Networks, gli operatori di infrastrutture mobili e wireless hanno dovuto sudare le proverbiali sette camicie nel 2010 per mantenere la disponibilità dei servizi. Questo si deve alla scarsa visibilità che gli stessi hanno relativamente al traffico che transita dentro le proprie infrastrutture di rete. Nel corso dell’analisi dei possibili proto-botnet di androidi ho ribadito la necessità di un nuovo modello di sicurezza per gli operatori mobili (una botnet all’interno di una rete mobile sarebbe estremamente difficile da identificare e bloccare), questa evidenza di Arbor Networks tende senza dubbio verso questa direzione, con l’ulteriore aggravante che il produttore afferma, forse provocatoriamente, che, seppur con qualche eccezione, molti operatori mobili o wireless hanno un modello di sicurezza confrontabile a quello che gli operatori fissi avevano 8/10 anni orsono.

Quando si parla di DDoS i muri di fuoco fanno acqua da tutte le parti…

… E gli IPS non sono da meno.  Se (a detta del produttore) gli operatori mobili, i Data Center e gli operatori VoIP stanno adottando un modello di sicurezza obsoleto, parte della responsabilità si deve all’adozione di tecnologie del decennio scorso quali firewall di tipo stateful e sistemi IPS (Intrusion Prevention) che abbassano il livello di sicurezza e rendono la rete più suscettibile ad attacchi DDoS. A mio avviso questa osservazione un po’ forzata. Capisco che un DDoS da 100 Gbps si può mitigare solamente redirigendo il traffico, ma quanti sono i DDoS a 100 Gbps?  Un firewall ben configurato (e qui sta il difficile) è in grado di mitigare la maggior parte dei DDoS da comuni mortali. A parte questa distinzione  non ho potuto fare a meno di notare la sottigliezza nel passaggio sottostante:

In light of the growth in application-layer DDoS attacks, such devices (Firewall e IPS ndr) frequently lower the overall security postures of operators by acting as stateful DDoS chokepoints—rendering networks more susceptible to both deliberate and inadvertent DDoS attacks.

In cui lo stateful chokepoint (ovvero punto di blocco) richiama molto da vicino lo stateful Checkpoint (ovvero il produttore di firewall israeliano inventore della tecnologia di Stateful Inspection).

Gli Attacchi DDoS sono una cosa seria

I media hanno riportato, nel corso del 2010 numerosi esempi di attacchi di DDoS motivati da dispute politiche o ideologiche, il più famoso dei quali ha sicuramente interessato l’arcinota questione di Wikileaks. Il livello e la diffusione di questa tipologia di attacchi è cresciuta talmente che oramai sono diventati un problema per i livelli esecutivi di un’Organizzazione (e fonte di servizi per le aziende di sicurezza). Che siano diventati una cosa seria lo dimostra anche il recente attacco effettuato al sito del Governo Italiano da parte del Gruppo Anonymous.

Il DNS, questo sconosciuto (per la sicurezza)

Purtroppo la scarsa attenzione prestata da molti provider ai problemi di sicurezza del DNS, ha fatto si che il servizio di risoluzione dei nomi, fondamentale per le usuali operazioni di navigazione e di accesso a qualsiasi servizio, sia diventato suo malgrado protagonista degli attacchi DDoS, che consentono, con relativa facilità, di buttare giù un servizio e renderlo indisponibile in maniera relativamente semplice. La conseguenza è che, nel corso del 2010, il servizio DNS è stato protagonista vittima di numerosi attacchi di tipo DNS Reflection o DNS Amplification.

IPv6 Sicurezzav4

L’analisi ha dimostrato una crescente preoccupazione degli operatori che sono passati a IPv6 nell’applicare le stesse precauzioni e misure di sicurezza adottate per il controllo dell’IPv4. Le preoccupazioni sono anche aumentate dalla necessità di inserire dispositivi per la compatibilità dei due protocolli.

Mancanza Cronica di Team di Gestione Organizzati

Uno dei motivi di maggiore rischio nella gestione degli incidenti (e nella conseguente dilatazione relativistica dei tempi di mitigazione degli stessi) è rappresentato dalla mancanza cronica di risorse con le necessarie competenze, da organizzazioni che adottano processi a compartimenti stagni (o a silo come li definiscono gli anglosassoni) e dalla mancanza di responsabilità e policy chiare e definite. Questo punto evidenza, come il contrasto agli eventi DDoS non sia una questione meramente tecnologica ma passa attraverso l’adozione di ben definite procedure di gestione degli incidenti.

La Legge Non è Uguale Per Tutti

A causa della scarsa fiducia nelle istituzioni competenti che dovrebbero investigare gli incidenti di sicurezza e perseguire gli autori (e anche a causa della mancanza di risorse specializzate), diversi operatori preferiscono non denunciare gli incidenti, soprattutto in contesti in cui dovrebbero passare attraverso molteplici giurisdizioni.

Infrastrutture Critiche (di nome ma non di fatto)

Sebbene molti operatori vedano di buon occhio la formazione di Cyber-eserciti nazionali (o sarebbe meglio dire Computer Emergency Response Team Nazionali), durante la survey hanno manifestato scarsa fiducia nelle misure adottate dai governi per proteggere le infrastrutture critiche, misure che ritengono non adeguate al livello di esposizione delle stesse.

Concludendo… Concludendo…

Il DDoS non abbandonerà questi lidi nemmeno nel corso del 2011, ed è  anzi destinato a incrementare i suoi effetti nefasti. Ponendo l’attenzione su un punto specifico, è evidente che la nuova frontiera degli attacchi DDoS diventeranno purtroppo gli operatori mobili, sia come destinazione che (presumibilmente) come sorgenti. Da un lato dal report si evince che le loro infrastrutture non sono all’altezza dei livelli di sicurezza richiesti, dall’altro le minacce (e quindi le botnet) si stanno spostando sempre di più verso gli endpoint mobili. In questo contesto le preoccupazioni ed i grattacapi per gli operatori dovrebbero essere duplici: da un lato le proprie reti potrebbero essere sorgenti di attacchi DDoS (difficilmente tracciabili se è vero, come indicato dal report, che una delle difficoltà per gli operatori mobili e wireless consiste proprio nel controllo del traffico originato dalle loro infrastrutture), dall’altro i dispositivi compromessi potrebbero essere vittime di Data Leackage (ovvero furto di informazioni).

Ne resterà soltanto uno… (Seconda Parte)

December 8, 2010 5 comments

Se immaginassimo per un attimo che non esista Antitrust, concentrandoci ad immaginare il framework di sicurezza ideale, potremmo suddividere un offerta completa di sicurezza in 6 domini:

  • Sicurezza degli Endpoint (EPP) che include le funzioni di Antivirus, Personal Firewall/Network Access Control, Host IPS, DLP, Cifratura per tutte le classi di dispositivi, mobili o fissi;
  • Sicurezza della rete e dei contenuti (NP) che include le funzioni di Firewall, IPS, Web and Email Protection;
  • Sicurezza applicativa  (AP) che include le aree di analisi del codice, WEB/XML/Database Firewall;
  • Compliance: che include le funzioni di assessment e verifica della sicurezza delle postazioni e delle applicazioni
  • Identity & Access Management (IAM) che include le funzi0ni di autenticazione, accesso sicuro ai dati, etc.
  • Gestione & Management che inclide la funzione di gestione unificata dei domini delineati in precedenza.

Rappresentando graficamente il modello, per ogni offerta di sicurezza da parte di un produttore è possibile associare tre livelli di conformità (conforme, parzialmente conforme, non conforme). Il modello di sicurezza unificato (che vede la sicurezza come un processo end-to-end) è quello a cui stanno tendendo i produttori:  se si mappano gli stessi in 3 livelli (Colossi,  Leader e Niche Player) è interessante notare come i vendor stiano tendendo verso il modello, ove possibile tramite prodotti interni, oppure mediante acquisizioni mirate a colmare eventuali lacune della propria offerta.

  • I “Colossi” sono produttori dotati delle capacità tecnologiche e finanziarie tali da poter costruire una offerta completa. Liquidità e capitalizzazione sono tali da poter acquisire una o più aziende per colmare un Gap all’interno della loro offerta. Rientrano in questa categoria aziende con capitalizzazione attorno o superiore a 100 miliardi di dollari, quali il nuovo arrivato Intel e vecchie conoscenze come Cisco, IBM, Microsoft, HP.
  • I “Leader”: rientrano in questa categoria i player focalizzati sulla sicurezza che offrono, nel proprio segmento, soluzioni best of breed. I player appartenenti a queta categoria sono di dimensioni tali da effettuare acquisizioni per costruire una offerta completa ma non abbastanza grandi per non essere loro stessi oggetti del desiderio dei colossi in una situazione di mercato complessa come l’attuale. Esempi rampanti sono le compiante McAfee e ISS (acquisite rispettivamente da Intel e IBM) e gli oggetti del desiderio Symantec e Checkpoint.
  • I “Niche Player: rientrano in questa categoria i produttori di Nicchia che ci sono specializzati in specifici segmenti in cui hanno raggiunto livelli tecnologici eccellenti e che di conseguenza potrebbero far gola a rappresentanti delle categorie sopra riportate. Rientrano in questa categoria ad esempio Kasperky, Trend Micro,  etc…

In realtà ai colossi andrebbe aggiunta una ulteriore categoria, quella degli “outsider”. Gli outsider sono aziende dotate di vasta capitalizzazione ma ad oggi non sufficientemente focalizzate sulla sicurezza (ovvero potenziali colossi come era Intel sino a qualche mese fa) oppure fortemente focalizzate sulla sicurezza, ma con una capitalizzazione che le rende inappetibili ai Colossi. In queste personalissima classificazione appartengono alla prima categoria Oracle e EMC, mentre appartiene alla seconda categoria Juniper. Entrambi gli appartenenti a questa categoria potrebbero fare acquisizioni da un momento all’altro ma ad oggi hanno, nel modello di sicurezza unificata, più di due caselle rosse.

Esaminando la mappa delle acquisizioni dei colossi si può avere un quadro chiaro delle loro strategia: in rigoroso ordine alfabetico:


Punti di Forza: notevoli risorse e Ability to Execute, crescia esponenziale nella sicurezza di rete e dei contenuti.

Punti di debolezza: Gestione Frammentata, Strategia sull’Endpoint incerta, Offerta IAM Parziale


Punti di Forza: Disponibilità di Risorse per Acquisizioni. Presenza nell’Application Security con Soluzione Leader.

Punti di debolezza: Mancanza di copertura per l’Endpoint, copertura parziale nella sicurezza di rete (limitata all’IPS ma la strategia è incerta).


Punti di Forza: Dispnibilità di Risorse, Offerta completa su Sicurezza delle Applicazioni e su IAM.

Punti di debolezza: Offerta su Endpoint, Compliance e Rete Parziale (Mancano Antivirus, DLP, e soluzioni di Content Security.


Punti di Forza: Gestione Unificata Estesa, Offerta Completa

Punti di debolezza: Strategia Incerta e Fantascientifica dopo l’acquisizione di McAfee (Focalizzazione sul Mobile o Antivirus Hardware Integrato sul processore), Difficoltà nell’integrare le acquisizioni, Offerta IAM Assente, Offerta Application Security Limitata.




Punti di Forza: Risorse Notevoli, vasta base di installato (!!) da utilizzare come punto di partenza

Punti di debolezza: Funzioni parziali su tutti i domini (‘Antitrust?).


Noi balliamo da sole

Di seguito le aziende di sicurezza che maggiormente suscitano l’attenzione degli analisti e puntualmente sono al centro di voci di mercato: Checkpoint, Fortinet e Symantec. Questi player partono da approcci opposti (rispetttivamente rete per i primi due ed endpoint per il terzo) e potrebbero far gola ad uno dei player sopra indicati (come accaduto a McAfee) oppure ad un Outsider. Anche se non perfettamente partinente in questa categoria è stata inserita anche Juniper. In realtà è praticamente impossibile che Juniper venga acqquisita da un colosso, tuttavia, come capitalizzazione è più vicina a questi player (pur valendo circa 20 volte Fortinet) che hai colossi.


Punti di Forza: Forte focalizzazione sulla rete. Modello di gestione unificata Esemplare. Precursore del modello di unificazione della sicurezza unificata sull’endpoint.

Punti di Debolezza: Stenta a imporsi come venditore di soluzioni Endpoint. Carente su Application Security, Compliance e IAM.


Punti di Forza: Forte focalizzazione sulla sicurezza di rete e dei contenuti.

Punti di Debolezza: Copertura deole degli altri domini.


Punti di Forza: Forte focalizzazione sulla sicurezza di rete e dei contenuti.

Punti di Debolezza: Copertura debole degli altri domini.


Punti di Forza: Forte focalizzazione sull’endpoint.

Punti di Debolezza: Strategia e focalizzazione sulla sicurezza da ricostruire dopo l’acquisizione di Veritas. Strategia Altalenante per la sicurezza di rete.



E quindi?

E quindi vederemo se i fuochi di artificio sono finiti qui o continueranno nel corso del 2011. Certo è che soprattutto  HP, IBM e la stessa Microsoft necessitano di una o più acquisizioni per riempire il gap rispetto al modello unificato ideale (all’inizio di novembre si è parlato di un interessamento, in seguito smentito, di IBM verso Fortinet), tramite una unica acquisizione, come fatto da Intel con McAfee o facendo shopping tra i produttori di nicchia.

Ne resterà soltanto uno… (Prima Parte)

December 5, 2010 Leave a comment

Il titolo di questo post riporta alla memoria la frase prinicipale del bel film “Higlander, L’Ultimo Immortale”, il capolavoro fantasy di Russel Mulcahy che nell’ormai lontanto 1986 rapì la mente di noi geek adolescenti con i suoi improbabili duelli tra le montagne scozzesi, duelli avvolti tra la bruma e la bellissima colonna sonora dei Queen (Who wants to live forever?). Se ripenso al film e guardo il mercato della sicurezza informatica direi che la frase  essenza si adatta perfettamente alla situazione attuale, con la sola non trascurabile differenza che ai tempi di Connor MacLeod, non esisteva l’Antitrust.

All’inizio erano il firewall e l’antivirus…

L’inizio del mercato della sicurezza informatica (si parla del termine degli anni ’90) vedeva tecnologie con ruoli ben distinti, rivolte alla risoluzione di problemi di sicurezza inerenti alla rete ed ai sistemi. Esisteva un modello di sicurezza informatica basato su un approccio “a silo”, ovvero un approccio che prevedeva tecnologie verticali e trovava la massima espressione nel firewall e l’antivirus (a sua volta declinato in antivirus di rete e antivirus di sistema). In quegli anni formidabili, nel 99% dei casi un progetto di sicurezza informatica poteva dirsi completo se prevedeva queste due componenti che con il passare del tempo erano anche in grado di dialogare tra loro (oggi diremmo in modo non efficiente, ma allora i protocolli di content vectoring erano il massimo che la tecnologia poteva garantire). Certo la gestione non era ottimale, ma con l’ausililo della tecnologia consentita dall’epoca, si ponevano le basi per un modello unitario.

Poi vennero gli IDS…

E si realizzò ben presto che il firewall e l’antivirus non potevano tutto: all’interno delle regole consentite era possibile veicolare minacce invisibili in grado di sfruttare le vulnerabilità dei sistemi. Di conseguenza fu necessario innalzare il livello di protezione mediante l’inserimento di sistemi di difesa dedicati in grado di scansionare il traffico ad un livello superiore rispetto a quanto consentito dai firewall. Sorsero così i primi produttori dedicati ai sistemi IDS. Questi produttori utilizzavano la tecnologia nata per scansionare i sistemi alla ricerca di vulnerabilità per proteggere i sistemi stessi. Con questo approccio nel 1998 Internet Security Systems mise in commercio i primi sensori di rete, sensori che con il passare degli anni divennero apparati dedicati, sempre più evoluti, in grado di estendere il proprio livello di protezione verso l’endpoint (Host IPS). Nel contempo, e in modo del tutto analogo, i produttori di dispositivi firewall si apprestavano, anche essi, ad aggredire gli endpoint con soluzioni di Personal Firewall. Endpoint che prima di allora sembravano appannaggio esclusivo dei produttori di antivirus.

E le applicazioni inscure e magari anche mobili…

Nella seconda metà degli anni 2000, la crescita prepotente del Web 2.0 e l’evoluzione tecnologica dei dispositivi mobili (che hanno allargato notevolmente il livello di esposizione dell informazioni) hanno reso necessaria l’introduzione di un ulteriore livello di sicurezza per la protezione delle applicazioni (al livello 7 della pila OSI direbbero gli esperti) e dell’utenza mobile. Questa piccola rivoluzione copernicana ha portato all’introduzione di soluzioni tecnologiche atte a focalizzare l’analisi su applicazioni WEB, database, transazioni XML e soprattutto, più in generale, ad introdurre la sicurezza nel ciclo di sviluppo del Software e nel processo di accesso alle informazioni. Nel contempo si è cominciato a guardare con interesse a soluzioni di protezione dell’endpoint fissi e mobili più evolute, in grado di garantire cifratura, protezione dei dispositivi rimovibili e, specialmente negli ultimi tre anni, dedicate ad impedire la perdita o il furto di informazioni (Wikileaks docet).

E alla fine la necessità di avere una gestione unificata

La crescita del modello di sicurezza end-to-end ha reso infine necessaria l’introduzione di un modello di gestione unificata (qualcuno una volta diceva “La Potenza è nulla senza il controllo”) poiché gestire in modo disomogeneo (per l’appunto con un approccio “a silo”) le numerose componenti è costoso, inefficiente e inefficace (ed è altrettanto improbabile che giustifichi investimenti cospicui in tecnologia di sicurezza). E’ importante inoltre considerare il problema dell’analisi dei dati: soluzioni di protezione eterogenee non devono offrire solamente un unico punto di amministrazione, ma anche un unico punto di raccolta e analisi dei dati.

La conseguenza del trend sopra descritto è stata che nel corso degli anni si è assistito a numerose scosse di mercato: i produttori di sicurezza (generalisti o verticali) dotati di adeguate capacità finanziarie, hanno avviato importanti campagne di acquisizione  e/o fusione con lo scopo di realizzare il modello di sicurezza unificato sopra citato ed utilizzare lo stesso come base per altre strategie, estendendo nel contempo la propria sfera di azione su segmenti di mercato non precedentemente coperti. Naturalmente in alcuni casi le campagne di acquisizione sono state effettuate anche per garantire crescite  di fatturato in un epoca di congiuntura economica non certo esaltante  (ma questa è un altra storia).

La conseguenza, per quanto riguarda i produttori di sicurezza informatica, è stato uno sconvolgimento del panorama tecnologico ed economico da parte di tre forze contrastanti:

  • I produttori provenienti dalla “sicurezza di rete” si sono estesi verso l’endpoint (approccio network-centric). Per questa classe di produttori la sicurezza dell’endpoint rappresenta l’estensione del proprio modello strategico che parte dalla rete: questa rileva le minacce che vengono utilizzate per proteggere gli endpoint, il tutto effettuato tramite una gestione unificata.
  • I produttori provenienti dalla “sicurezza dell’endpoint” si sono estesi verso la rete (approccio endpoint-centric). Per questi produttori l’estensione alla rete rappresenta il mezzo per realizzare un modello unico di correlazione delle informazioni di sicurezza a partire dai dati raccolti nei nodi terminali (siano essi fissi o mobili, client o server).
  • I colossi produttori di hardware, software e servizi hanno si sono estesi verso la sicurezza per realizzare un modello unico di che parte dallo sviluppo del software e dall’accesso sicuro alle applicazioni, e si estende verso la rete e i sistemi per offire un modello end-to-end.

La descrizione dello scenario è estremamente complessa e merita un capitolo a parte, per cui, dopo aver elencato le ragioni, nel prossimo post cercherò di far luce sulla mappa delle acquisizioni e le mie personalissime considerazioni sulle relative strategie.

Nel frattempo però prendo il mio Androide e mi cerco un bel posto per il brunch…


Get every new post delivered to your Inbox.

Join 3,788 other followers