Sette passi verso la protezione software

Business white paper
Sette passi verso la
protezione software
Business white paper | Sette passi verso la protezione
software
Sommario
2 Che cosa scoprirete
2 Adottare un codice più sicuro: i sette passi
3 Passo 1: valutazione e pianificazione rapide
4 Passo 2: definizione dei rischi e delle minacce
al software
4 Passo 3: revisione del codice
5 Passo 4: test e verifica
Dopo un decennio di notizie relative a innumerevoli attacchi
informatici riusciti, è difficile immaginare che un'azienda non
comprenda la necessità di una soluzione di protezione
software. A differenza dell'implementazione di procedure di
controllo qualità per il software, i processi per rendere le
applicazioni più sicure sono ancora piuttosto immaturi.
Inoltre, la responsabilità della sicurezza del software
all'interno di un' organizzazione non è sempre definita in
modo chiaro e coerente. In questo documento vengono
indicate sette azioni concrete che le organizzazioni possono
intraprendere subito per proteggere le loro applicazioni e
impedire i danni causati dagli attacchi informatici.
Che cosa scoprirete
5 Passo 5: creazione di un gate di sicurezza
•Sette azioni concrete per avviare un programma di sicurezza per le applicazioni
6 Passo 6: misurazione
•Metodi per misurare i successi ottenuti dal programma di sicurezza per le applicazioni
7 Passo 7: informazione
•Modalità di implementazione di un ciclo di vita di sviluppo protetto
8 Conclusioni
•Best practice sulla sicurezza delle applicazioni e metodologie di successo
8 Informazioni su HP Fortify
8 Informazioni su HP Enterprise Security
Dal 2000 al 2012, quattro delle prime sei
vulnerabilità segnalate nell'Open Source
Vulnerability Database (OSVDB) risultavano
sfruttabili tramite il web.2
1, 2
3
P 2012 Cyber Security Risk Report,
H
marzo 2013
" The Economic Impacts of Inadequate
Infrastructure for Software Testing", National
Institute of Standards & Technology
2
Adottare un codice più sicuro: i sette passi
Per comprendere i rischi tecnici per la sicurezza, occorre innanzitutto sapere come e dove
si presentano le vulnerabilità all'interno di un'organizzazione. Le vulnerabilità possono
influire su tutti i livelli dell'infrastruttura aziendale, dall'hardware, alla rete, fino al software,
vecchio e nuovo. Tali vulnerabilità costituiscono il punto di accesso utilizzato dagli aggressori
per eludere i sistemi di sicurezza e sottrarre o modificare i dati, impedire l'accesso e
compromettere i processi business-critical. I punti di ingresso per gli aggressori sono sempre
più spesso rappresentati dalle applicazioni web. Le vulnerabilità di lunga data, come lo script
da altri siti, non sono ancora state corrette in fase di sviluppo o distribuzione. Quasi la metà
delle applicazioni web esaminate nel 2012 era esposta allo script da altri siti, una minaccia
presente da quando esiste il web o quasi.1 In termini semplici, gli sviluppatori di applicazioni
non considerano con attenzione i propri dati per quanto riguarda i metodi di archiviazione,
raccolta o recupero.
Come iniziare ad affrontare questi problemi? Secondo il National Institute of Standards
and Technology (NIST), dopo il rilascio di un'applicazione nell'ambiente di produzione, la
correzione delle vulnerabilità costa 30 volte di più rispetto alla fase di progettazione.3 È
quindi opportuno tentare di risolvere tali problemi durante i processi di sviluppo, dove si
può ottenere il maggior impatto economico. Le organizzazioni capaci di affrontare con
successo queste sfide hanno individuato alcuni aspetti più efficaci di altri. L'elemento chiave
per intraprendere il percorso è selezionare poche attività pratiche in grado di avviare
l'adozione di processi di sicurezza per creare applicazioni più protette. Tali attività possono
essere semplicemente costituite da un unico "gate di sicurezza" che le applicazioni devono
superare prima del rilascio, oppure da una serie di piccole attività in ciascuna fase del ciclo
di vita di sviluppo del software (SDLC, Software Development Life Cycle) per integrare la
sicurezza all'interno dell'applicazione. Tuttavia, anche questo semplice approccio è più facile
da descrivere che da adottare concretamente. L'inerzia contraria al cambiamento può essere
così forte da portare alla paralisi, che di solito determina un'attenzione insufficiente nei
confronti della sicurezza a ogni livello, dallo sviluppo alla distribuzione. Come strumento di
supporto, questo documento propone sette azioni concrete che i responsabili dello sviluppo
possono intraprendere per fornire software più sicuro, con una particolare rilevanza per gli
aspetti pratici.
Business white paper | Sette passi verso la protezione
software
Passo 1: valutazione e pianificazione rapide
Il primo passo consiste nel valutare lo stato corrente della sicurezza software all'interno
dell'azienda e nel definire un piano per le azioni aggiuntive da intraprendere in tale ambito.
Consideriamolo una sorta di triage. Questo processo di valutazione e pianificazione non
deve necessariamente essere un lavoro approfondito che comporta un impegno di molti
mesi. Il modo migliore per iniziare è creare semplici elenchi delle attività attualmente in
corso per affrontare i problemi di sicurezza e delle azioni da aggiungere. Ad esempio, la
tabella della figura 1 riporta il livello di preparazione complessiva per la sicurezza software
di un progetto, con una scala di valori per la misurazione di ciascun punto. Un piano, anche
se conciso e a breve termine, è essenziale per ottenere l'approvazione all'interno delle
organizzazioni. Realisticamente, come piano iniziale, potrebbe essere necessario creare
una sorta di "prototipo" che consenta la realizzazione di una strategia più approfondita e
aggressiva dopo il raggiungimento di risultati positivi. Sembra semplice (e lo è per certi versi),
ma è sorprendente il numero di aziende che ignora questo passaggio fondamentale.
Figura 1. Valutazione
Sono disponibili e sono stati identificati gli esperti interni per la sicurezza 1
2
3
4
5
L'analisi delle minacce viene completata per ogni progetto
1
2
3
4
5
Si svolgono regolarmente programmi di formazione sulla sicurezza
1
2
3
4
5
Sono stati acquisiti e destinati specifici strumenti e risorse
1
2
3
4
5
La protezione successiva all'implementazione è totalmente integrata nel processo complessivo 1
2
3
4
5
La risposta alle vulnerabilità ottimizza i vantaggi e previene i problemi ricorrenti 1
2
3
4
5
Indipendentemente dall'approccio adottato, il piano dovrebbe considerare tre elementi: (1)
l'infrastruttura di sicurezza del software che supporta ogni progetto di sviluppo software;
(2) le specifiche attività di sicurezza che ciascun team di progetto decide di svolgere; (3) la
modalità di gestione delle vulnerabilità riscontrate. Nella tabella della figura 2 sono illustrati
elementi di esempio di un piano.
Figura 2. Elementi di un piano
Esperto per la sicurezza
assegnato scelto
tra i leader del team
Chi: assegnare gli individui
ad attività e ruoli
Modalità di registrazione
e segnalazione
dei problemi
Strumenti automatici
che supportano le azioni
Cosa: elencare i passaggi
e i criteri di successo per
ognuno di essi
Checklist e requisiti di
processo
Quando: inserire azioni e
attività all'interno della
cronologia del progetto
Processi di team per il
triage, l'assegnazione
di priorità e l'azione
sui difetti di sicurezza
segnalati
3
Business white paper | Sette passi verso la protezione
software
Passo 2: definizione dei rischi e delle minacce al software
In sintesi, la sicurezza si può definire come l'arte di ridurre i rischi. Le applicazioni software in
cui sono memorizzate informazioni private dei clienti devono essere maggiormente protette
rispetto a un'applicazione interna per la programmazione delle sale conferenza. Quindi,
nella stessa misura in cui si elencano le capacità del proprio gruppo di creare software più
protetto, è necessario stabilire i rischi associati a un software e le minacce alla sua sicurezza.
L'analisi dei rischi è un campo a sé stante, che può essere affrontato tramite soluzioni
commerciali come Microsoft ® STRIDE e approcci basati su standard quali NIST ASSET.
Sebbene differiscano in termini di implementazione, gli approcci menzionati presentano
generalmente numerosi passaggi dettagliati e implicano un ingente investimento di tempo.
Una tecnica più semplice rispetto a una vera e propria analisi dei rischi è l'analisi delle
minacce, che considera le minacce a cui un'applicazione è esposta. L'analisi delle minacce
permette di evitare errori relativi alla sicurezza in fase di progettazione e di concentrare le
revisioni del codice e i test di protezione sui componenti più vulnerabili dell'applicazione.
Per tale ragione, è opportuno considerare questo passaggio come uno dei più importanti
da compiere. Una semplice analisi delle minacce può essere divisa in due fasi. Nella fase
uno vengono identificate le risorse che un'applicazione deve proteggere, effettuando una
valutazione di quelle più importanti. Questa attività potrebbe risultare complessa, poiché
alcune risorse sono più evidenti rispetto ad altre e la loro natura varia da un'applicazione
all'altra. Tra gli esempi di risorse figurano record di informazioni private, come i numeri di
carte di credito, schede su dipendenti e clienti oppure dati finanziari. Altri esempi includono
asset che l'impresa fornisce a soggetti terzi, come soluzioni di e-commerce, siti web
aziendali e supporti di comunicazione via e-mail. In altri casi ancora si tratta di risorse
immateriali, come la reputazione della società. Ad esempio, in che modo una violazione della
sicurezza potrebbe intaccare la credibilità dell'azienda?
La fase due dell'analisi delle minacce consiste nell'esame dell'applicazione stessa e dei
pericoli creati dagli aggressori. Le organizzazioni devono sviluppare un modello di alto livello
per i componenti dell'applicazione e per i percorsi del flusso di dati. È opportuno tracciare
uno schema della superficie di attacco dell'applicazione, identificando  le interfacce che
accettano input dagli utenti o interagiscono con altri sistemi. I team devono rilevare ogni
punto della superficie di attacco che può essere sfruttato per compromettere l'integrità, la
disponibilità o la riservatezza di un asset. È assolutamente necessario considerare anche
le applicazioni non fondamentali installate sullo stesso server di quelle essenziali, poiché
una violazione delle prime può avere un impatto negative sulle seconde. Infine, le minacce
sono da classificare in base all'importanza della risorsa interessata e alla probabilità di
exploit. Questa attività di analisi delle minacce, sebbene più semplice rispetto a una vera e
propria analisi dei rischi, potrebbe comunque richiedere un elevato livello di competenza
sull'applicazione e sulle modalità di attacco. Tuttavia, non deve necessariamente essere
precisa e può portare a risultati significativi poiché consente di concentrare gli sforzi sulle
aree più importanti senza processi troppi dispersivi. Naturalmente nemmeno la più accurata
analisi delle minacce è in grado di prevenire l'introduzione di vulnerabilità di sicurezza
durante la fase di sviluppo; questa considerazione ci porta al passo 3.
Passo 3: revisione del codice
Il mondo del software è caratterizzato da un semplice dato di fatto: il codice che viene
distribuito rappresenta la vera creazione dell'istanza per qualsiasi applicazione. Di
conseguenza, le imprese sono tenute a rivedere il codice nel corso delle procedure di
implementazione e test per rilevare le eventuali vulnerabilità di sicurezza introdotte durante
lo sviluppo. Nella maggior parte dei casi, queste revisioni evidenziano numerose vulnerabilità
di sicurezza che diversamente sarebbero state presenti nella fase di distribuzione. Insieme
all'analisi delle minacce, un'azienda può utilizzare la revisione per verificare che il software
non lasci aperti punti di accesso e vulnerabilità alle minacce più temute. Oggi molti gruppi si
affidano a revisioni manuali del codice per effettuare questo passaggio. I controlli manuali,
tuttavia, richiedono ampie competenze sulla sicurezza ed enormi investimenti in termini di
tempo. Per fortuna, le modalità con cui gli sviluppatori introducono vulnerabilità di sicurezza
nelle applicazioni sono oggetto di modelli coerenti e adeguatamente documentati, che
offrono una base per strumenti di analisi della sicurezza automatici e precisi. I migliori
strumenti di analisi del codice sorgente sono in grado di valutare più livelli e tenere traccia
del flusso di dati all'interno di un'applicazione. Tali strumenti sono utilizzabili su corpi di
codice piccoli e grandi e offrono una presentazione e una gestione efficaci dei propri risultati
per permettere ai revisori umani di identificare rapidamente i potenziali difetti di sicurezza e
ordinarli in base alle priorità.
4
Business white paper | Sette passi verso la protezione
software
Le tecnologie di analisi per la sicurezza del codice sorgente integrate negli ambienti di
sviluppo, come Microsoft Visual DevStudio ed Eclipse, possono essere sfruttate anche come
strumenti di base e per la formazione continua degli sviluppatori. Essi forniscono feedback
sul punto in cui è stato introdotto l'errore, consentendo una risoluzione meno costosa e
un'esperienza formativa più concreta. Di seguito è riportato l'elenco delle funzionalità chiave
richieste a un'efficace strumento automatico di sicurezza per il codice sorgente:
•Identificazione completa di numerosi tipi di vulnerabilità
•Capacità di eseguire analisi diversificate, ad esempio sul flusso di dati globale, sul flusso di
controllo e sui file di configurazione, per ridurre i falsi positivi
•Capacità analitiche in grado di superare i confini dei livelli di applicazioni, per rilevare
vulnerabilità che le revisioni manuali non riuscirebbero mai a scoprire
•Varie opzioni di filtro, query e ordinamento per i risultati dell'analisi
•Supporto per tutti i linguaggi utilizzati dai tema di sviluppo
•Flessibilità per applicare le specifiche policy di codifica protetta delle aziende
•Supporto per l'analisi sul desktop dello sviluppatore tramite plug-in IDE (Integrated
Development Environment, ambiente di sviluppo integrato)
Passo 4: test e verifica
I test costituiscono una tecnica complementare alle revisioni del codice, un esame finale per
il ciclo di vita di sviluppo del software protetto e una procedura che può essere supportata
tramite l'automazione. Desideriamo però ricordare che i test funzionali tradizionali non sono
efficaci nel rilevare le vulnerabilità di sicurezza. I test di qualità del software si concentrano
generalmente sulla verifica di una serie di funzionalità sulla base di requisiti adeguatamente
specificati o azioni utente previste. I test di sicurezza richiedono un atteggiamento mentale e
un approccio diversi: infatti è la mancanza di sicurezza che deve essere rilevata.
Una prassi comune consiste nel condurre test sulla penetrazione delle applicazioni. Lo scopo
dei test di penetrazione è simulare attacchi al software per individuare comportamenti
anomali. Come le revisioni del codice, questi test possono essere condotti manualmente
o con uno strumento automatico. I test di penetrazione effettuati da esseri umani, simili
all'analisi del codice sorgente, sono in grado di scoprire problemi complessi non rilevabili in
altro modo. Tuttavia richiedono competenze, esperienza e tempistiche non disponibili nella
maggior parte delle imprese. Gli strumenti automatici possono fornire una knowledge base
di attacchi noti e rispondere rapidamente a questi ultimi, ma spesso trascurano i difetti più
lievi o i campi di input sfruttati dai pirati informatici umani. In più, la copertura dei test di
penetrazione, ovvero il volume di un'applicazione in esecuzione effettivamente sottoposto
a un test di penetrazione, è spesso molto limitata rispetto alla reale superficie di attacco.
Una soluzione consiste nell'introdurre i risultati dell'analisi del codice sorgente nel test di
penetrazione, in modo che (1) quest'ultimo consideri tutte le fonti di input e ignori le aree
in cui non esistono vulnerabilità e (2) l'attività di correzione sia notevolmente più efficiente.
Sono anche disponibili prodotti che mettono in correlazione i risultati delle revisioni
del codice e dell'analisi automatica dinamica, combinando i punti di forza di entrambi
gli approcci.
Non esiste una risposta semplice ai test per la sicurezza. L'atteggiamento più pratico è
comunque quello di non affidarsi ai test per individuare le vulnerabilità, ma utilizzarli
principalmente per verificare che le vulnerabilità riscontrate nella revisione del codice siano
state eliminate.
Passo 5: creazione di un gate di sicurezza
Il metodo fondamentale e probabilmente migliore per avviare il processo e ottenere risultati
tangibili è creare un "gate" di sicurezza. Se un'organizzazione è in grado di implementare
una sola azione, è su questa che si deve concentrare. Molte aziende iniziano introducendo
un unico gate quando il software ha concluso la fase di test e prima che sia rilasciato negli
ambienti operativi o di produzione.
Questo gate di "controllo finale" presenta il vantaggio di essere semplice da comprendere e
di aumentare la visibilità dei problemi di sicurezza prima del rilascio. L'aspetto negativo è che
un passaggio così essenziale nella fase finale del ciclo di sviluppo non garantisce il tempo
necessario per correggere i difetti di sicurezza trovati nel codice.
5
Business white paper | Sette passi verso la protezione
software
Ovviamente è fondamentale stabilire i criteri che saranno utilizzati per giudicare se il
software è pronto per attraversare il gate di sicurezza. Un criterio concreto potrebbe essere
un controllo del codice. Un gate di revisione del codice, indipendentemente dal fatto che
sia richiesto durante lo sviluppo attivo, i test o come ultima verifica prima del rilascio del
software nell'ambiente di produzione, di solito rileva un numero significativo di vulnerabilità
di sicurezza. Inoltre, anche effettuare una scansione dinamica dell'applicazione in stato
di esecuzione, come farebbe un aggressore, può costituire un efficace gate di sicurezza.
L'aspetto importante è testare la sicurezza dell'applicazione prima che venga distribuita.
Con la maturazione dei processi di sviluppo protetto dell'organizzazione, i criteri possono
essere ampliati e prevedere il completamento dettagliato di azioni specifiche e la correzione
dei problemi riscontrati; in pratica, si potrà richiedere l'esecuzione di un'analisi delle minacce,
la conduzione di revisioni del codice e la limitazione dei problemi scoperti, il completamento
dei test di sicurezza, la verifica dell'assenza di altre gravi vulnerabilità e la correzione di
quelle minori. Questo gate più rigoroso potrebbe anche includere un audit di sicurezza
specializzato effettuato da esperti indipendenti prima di dichiarare l'applicazione "pronta per
la produzione".
Passo 6: misurazione
È opportuno che le aziende misurino il successo delle loro attività di sicurezza per migliorare
il processo e soddisfare requisiti sempre in evoluzione. La sicurezza software rimane un
settore emergente, come i parametri per giudicare l'efficacia delle attività in questo ambito.
Tuttavia, vi sono numerose attività che possono e devono essere misurate per ottenere
informazioni sullo stato della sicurezza software per un'organizzazione o un progetto. Le
aziende possono valutare il rispetto del processo di sicurezza così come è stato concepito,
oppure misurarne il successo per quanto riguarda l'implementazione. Ad esempio, Microsoft
misura l'efficacia del proprio SDLC calcolando il numero di bollettini di sicurezza entro i
primi dodici mesi successivi al rilascio (vedere figura 3). Mentre il parametro di Microsoft
considera un periodo successivo, le misurazioni effettuate durante lo sviluppo possono
garantire un tempo sufficiente per correggere le vulnerabilità prima della distribuzione.
Tali metriche comprendono misurazioni di rilevamento come le vulnerabilità riscontrate
per categoria, gravità e nel corso del tempo. Ad esempio, un progetto potrebbe introdurre
errori di sovraccarico del buffer o SQL Injection in misura più frequente rispetto a un altro,
segnalandosi come candidato per esami aggiuntivi. Sono possibili misurazioni relative alla
copertura e alla cronologia dei controlli, alla durata delle vulnerabilità e anche a molteplici
rischi. L'aspetto essenziale è iniziare presto la raccolta dei dati per creare una base di
riferimento durante lo sviluppo.
Figura 3. Livelli di gravità delle vulnerabilità per il progetto Pluto
Critica
Alta
Media
Critica = 3
Bassa = 3
3
3
Media = 1
1
9
Alta = 9
6
Bassa
Business white paper | Sette passi verso la protezione
software
Figura 4. Tendenze delle vulnerabilità per ogni progetto
Pluto
Orion
100
75
Vulnerabilità
25
0
27 dic
30 dic
02 gen
05 gen
08 gen
Passo 7: informazione
Dopo aver deciso quali misure di sicurezza saranno implementate, l'elemento determinante è
informare i principali soggetti interessati per consentire loro di avviare le attività di sicurezza
in modo efficace. Anche se in possesso dell'adeguata formazione, è improbabile che gli
sviluppatori diventino esperti della sicurezza, poiché hanno altre pressanti responsabilità
e, in generale, a causa della difficoltà nel diventare un esperto in questo campo. Di solito è
necessario assegnare ad alcuni gruppi o a singoli individui il ruolo di "leader" della sicurezza.
Questi ultimi potrebbero essere soggetti già interessati all'argomento, in possesso di una
formazione specifica in materia di sicurezza oppure assunti appositamente per ricoprire tale
ruolo. Gli esperti saranno responsabili dell'intero processo di implementazione del piano di
sicurezza e sono fondamentali per il suo successo. La presenta di esperti della sicurezza,
tuttavia, non solleva gli altri dalle responsabilità correlate. Tutti i membri dell'azienda devono
essere responsabili della sicurezza, anche partendo da azioni limitate. Senza la completa
partecipazione, nessun piano di sicurezza ha la possibilità di ottenere successo.
Tuttavia, dato che gli individui non possono essere responsabili di ciò che non capiscono,
l'informazione è essenziale. La comprensione delle tematiche della sicurezza richiede la
conoscenza di molti dettagli specifici. Gli sviluppatori devono comprendere la mentalità dei
pirati informatici, individuare le caratteristiche che rendono vulnerabili le funzioni, sapere da
quanti bit deve essere formato un ID di sessione per un sito che riceve sette milioni di viste al
giorno e così via.
Le aziende non possono trasformare tutti i membri di ciascun team operativo, di architettura, di
sviluppo e di controllo qualità in un esperto della sicurezza, quindi come è possibile migliorarla?
Il piano di sicurezza per la risposta alle vulnerabilità suggerisce di sviluppare best practice
interne. Si tratta di eccellenti risorse di formazione sulla sicurezza per tecnici nuovi e già
presenti in azienda. Quale fonte migliore di errori da evitare assolutamente di un elenco di quelli
che sono già stati fatti? Sfruttando le best practice sviluppate internamente come strumenti
formativi è possibile fornire conoscenze mirate sulla sicurezza con rilevanza comprovata.
È opportuno considerare la possibilità di fa partecipare i soggetti con ruoli fondamentali a
sessioni di formazione durante il ciclo di vita di sviluppo oppure richiedere la presenza di
un esperto all'interno dell'azienda per fornire occasioni di formazione sul campo. Il tempo
e il denaro dedicati alla formazione sono ben spesi, in particolare nel contesto dei sei passi
precedenti. Infine, la soluzione è creare all'interno del gruppo di sviluppo una mentalità
improntata alla sicurezza. Tutti devono riflettere sugli errori che si possono verificare ogni volta
che progettano una funzione, creano una build o generano una riga di codice. Ognuno dovrebbe
chiedersi: "In che modo un aggressore potrebbe trarre vantaggio da ciò che sto facendo?" Se, in
ogni fase, tutti rifletteranno sui problemi che potrebbero sorgere, la sicurezza migliorerà.
7
Business white paper | Sette passi verso la protezione
Conclusioni
La sicurezza software è un problema serio. Per ridurre i rischi, le aziende che si occupano di
sviluppo software devono iniziare a considerare la sicurezza come un aspetto di ogni fase
dell'intero ciclo di vita di sviluppo. I team di sviluppo possono utilizzare un piano composto
da sette azioni concrete per fornire software più protetto:
1. Valutazione dello stato corrente della sicurezza software e definizione di un piano per
gestirla durante tutto il ciclo di vita di sviluppo.
2. Definizione dei rischi e delle minacce al software in modo da poterli eliminare prima che
vengano introdotti.
3. Creazione di un gate per impedire alle applicazioni con vulnerabilità di passare
all'ambiente di produzione.
4. Revisione del codice per individuare vulnerabilità di sicurezza introdotte durante
lo sviluppo.
5. Test dell'applicazione per rilevare le vulnerabilità, in aggiunta ai test funzionali.
6. Misurazione del successo del piano di sicurezza per un miglioramento continuo
del processo.
7. Informazioni sulla sicurezza da fornire ai soggetti interessati per consentire loro di
implementare il piano di sicurezza.
Scoprite HP Fortify visitando il sito hp.com/go/
fortify
Tutte le organizzazioni che si occupano di sviluppo possono adottare questo piano di
sicurezza e iniziare a raccogliere i frutti del loro impegno in in periodo di tempo minimo.
L'importante è partire subito.
Informazioni su HP Fortify
Scoprite HP Enterprise Security visitando il sito
hp.com/go/SIRM
HP Fortify è la soluzione leader del mercato per l'automazione e la gestione di un
programma di sicurezza software completo e approfondito. Grazie alle più moderne
tecnologie disponibili in loco e on demand, HP Fortify consente alle aziende di rilevare,
correggere e rafforzare tutte le loro applicazioni software, dai sistemi legacy alle odierne
applicazioni mobili.
Informazioni su HP Enterprise Security
HP è un provider leader nel campo delle soluzioni di sicurezza e conformità per le aziende
moderne che desiderano contenere i rischi nei propri ambienti ibridi e difendersi dalle
minacce avanzate. Basata sui prodotti leader di mercato ArcSight, Fortify e TippingPoint,
la piattaforma HP Security Intelligence and Risk Management (SIRM) è l'unica soluzione ad
offrire le tecnologie di correlazione avanzata, protezione delle applicazioni e difesa della
rete necessarie per proteggere le applicazioni e le infrastrutture IT di oggi dalle minacce
cibernetiche più sofisticate.
Per saperne di più visitate il sito
hp.com/go/fortify
Registrati per ricevere gli aggiornamenti
hp.com/go/getupdated
Condividi questo documento
con i colleghi
© Copyright 2013 Hewlett-Packard Development Company, L.P. Le informazioni contenute nel presente documento sono soggette a modifica
senza preavviso. Le uniche garanzie relative ai prodotti e servizi HP sono quelle stabilite nelle dichiarazioni di garanzia esplicite che accompagnano
tali prodotti e servizi. Nulla di quanto contenuto nel presente documento potrà essere interpretato come garanzia supplementare. HP non è
responsabile degli eventuali errori tecnici o editoriali, né delle omissioni contenute nel presente documento.
Microsoft è un marchio registrato USA di Microsoft Corporation.
4AA4-6504ITE, ottobre 2013, Rev. 1