Sept étapes pour assurer la sécurité logicielle

Livre blanc
Sept étapes pour
assurer la
sécurité logicielle
Livre blanc | Sept étapes pour assurer la sécurité logicielle
Sommaire
2 Ce que vous apprendrez
2 Fournir un code plus sécurisé :
les sept étapes
3 Etape 1 : Evaluation rapide et élaboration
d'un plan
4 Etape 2 : Identification des risques et
menaces auxquels est exposé le logiciel
4 Etape 3 : Révision du code
5 Etape 4 : Test et vérification
Après une décennie marquée par la médiatisation d'un nombre
incalculable de cyberattaques parvenues à leurs fins, il est difficile
d'imaginer qu'une entreprise n'ait pas encore pris conscience
de la nécessité d'adopter une solution de sécurité logicielle.
Contrairement à la mise en œuvre de contrôles qualité logiciels,
les processus de sécurisation des applications ne sont pas encore
arrivés à maturité. De même, les responsabilités en matière de
sécurité logicielle au sein d'une organisation ne sont pas toujours
cohérentes ou clairement définies. Le présent document propose
sept étapes pratiques que les organisations peuvent commencer à
mettre en place dès aujourd'hui pour sécuriser leurs applications et
prévenir les dommages que des cyberattaques pourraient leur
faire subir.
Ce que vous apprendrez
•Sept étapes pratiques pour initier un programme de sécurité des applications
5 Etape 5 : Mise en place d'un portail
de sécurité
•Méthodes permettant d'évaluer l'efficacité d'un programme de sécurité des applications
6 Etape 6 : Evaluation
•Meilleures pratiques en matière de sécurité des applications et méthodologies pour réussir
•Manières de mettre en œuvre un cycle de vie de développement sécurisé
7 Etape 7 : Education
8 Conclusions
Fournir un code plus sécurisé : les sept étapes
8 A propos de HP Fortify
8 A propos de HP Enterprise Security
Entre 2000 et 2012, quatre des six principales
failles soumises à la base de données OSVDB
(Open Source Vulnerability Database) étaient
exploitables par le biais du Web.2
1, 2
3
P 2012 Cyber Security Risk Report (Rapport
H
HP 2012 sur les risques de cybersécurité),
mars 2013
" The Economic Impacts of Inadequate
Infrastructure for Software Testing", National
Institute of Standards & Technology (NIST)
2
Pour comprendre les risques techniques en matière de sécurité, il faut d'abord savoir où et
comment les vulnérabilités surviennent au sein d'une organisation. Les vulnérabilités peuvent
frapper à tous les niveaux de l'infrastructure de l'organisation, du matériel au réseau et aux logiciels
(les nouveaux comme les anciens). Ces vulnérabilités sont la voie qu'empruntent des individus
malveillants pour contourner les mécanismes de sécurité et dérober ou endommager des données,
refuser des accès et compromettre les processus métier cruciaux de l'organisation. De plus en
plus, les pirates attaquent par le biais des applications Web. Certaines vulnérabilités au long cours,
comme l'exécution de scripts de site à site, ne sont toujours pas corrigées lors des phases de
développement ou de déploiement. Près de la moitié des applications Web testées en 2012 étaient
sujettes à l'exécution de scripts de site à site, une menace presque aussi ancienne que le Web
lui-même.1 Autrement dit, les développeurs d'applications ne se préoccupent pas de la manière dont
leurs données sont stockées, collectées ou récupérées.
Par quoi commencer pour régler ces problèmes ? Selon le National Institute of Standards and
Technology (NIST), une fois qu'une application passe en production, toute correction coûte 30 fois plus
cher que durant la phase de conception.3 Par conséquent, il est plus judicieux de tenter de résoudre ces
problèmes au cours du développement, là où la correction aura le plus fort impact économique.
Les organisations ayant su relever ces défis avec succès constatent que certaines solutions
fonctionnent mieux que d'autres. Pour commencer, la clé réside dans la sélection de quelques mesures
pratiques qui peuvent servir de prémices à la mise en place de processus de sécurité permettant la
génération d'applications mieux sécurisées. Ces mesures peuvent être aussi simples que mettre en
place un "portail de sécurité" unique que les applications doivent franchir avant leur lancement ou
instaurer une série de petites tâches à chaque étape du cycle de vie du développement d'un logiciel
afin d'intégrer la notion de sécurité dans l'application. Toutefois, même une approche aussi simple
que celle-ci est bien souvent plus compliquée à mettre en œuvre qu'il n'y paraît. L'inertie face au
changement peut être telle qu'il est facile de rester paralysé, ce qui explique que les problèmes de
sécurité ne soient pas suffisamment traités à chaque étape du processus, du développement au
déploiement. Pour y remédier, ce document propose sept étapes pratiques (et la notion de "pratique"
est essentielle) que les groupes de développement peuvent adopter afin de fournir des logiciels
plus sûrs.
Livre blanc | Sept étapes pour assurer la sécurité logicielle
Etape 1 : Evaluation rapide et élaboration d'un plan
La première étape consiste à évaluer l'état actuel de la sécurité logicielle au sein de votre organisation
et à élaborer un plan regroupant les étapes supplémentaires nécessaires pour résoudre les problèmes
de sécurité. Considérez-la comme une étape de tri. Cette évaluation et ce plan n'ont pas besoin d'être le
fruit de grands efforts de plusieurs mois. La meilleure manière de commencer est de simplement créer
des listes de mesures prises actuellement pour résoudre les problèmes de sécurité et des actions qui
doivent y être ajoutées. Par exemple, le tableau de la figure 1 présente l'état de préparation générale à
la sécurité logicielle d'un projet et fournit une échelle permettant de l'évaluer. Pour remporter l'adhésion
au sein des organisations, il est indispensable de disposer d'un plan, même bref ou à court terme.
Votre plan initial pourra être envisagé de manière réaliste comme une "preuve de concept" qui vous
permettra ensuite de concevoir un plan plus complet et plus offensif une fois les premiers résultats
positifs obtenus. Si cette étape semble (volontairement) simple, il est étonnant de constater le nombre
de sociétés qui négligent cette étape pourtant essentielle.
Figure 1. Evaluation
Il existe en interne des experts en sécurité et ils ont été identifiés
1
2
3
4
5
Analyse des menaces réalisée pour chaque projet
1
2
3
4
5
Des programmes de formation aux questions de sécurité sont proposés régulièrement 1
2
3
4
5
Des outils et ressources spécifiques ont été achetés et attribués
1
2
3
4
5
La sécurité post-déploiement a été entièrement intégrée à l'ensemble du processus
1
2
3
4
5
La réaction aux failles optimise les avantages et empêche les doublons
1
2
3
4
5
Quelle que soit l'approche que vous aurez retenue, le plan doit traiter trois points :
(1) l'infrastructure de sécurité logicielle autour de chaque projet de développement logiciel ; (2) les
mesures de sécurité spécifiques que chaque équipe de projet choisit de prendre ; et
(3) la manière dont vous gérerez les vulnérabilités détectées. Le tableau de la figure 2 fournit des
exemples d'éléments constitutifs d'un plan.
Figure 2. Eléments constitutifs d'un plan
Attribution des
responsabilités
d'expert en sécurité
de l'équipe
Qui : Attribuer les tâches
et rôles
Mode de suivi et
de consignation
des problèmes
Outils automatisés
prenant en charge
les différentes étapes
Quoi : Répertorier les
étapes et critères de
réussite de chacune
Listes de contrôle
et exigences
des processus
Date : Inclure les étapes
et activités dans le
calendrier du projet
Processus d'équipe
visant à trier, définir
les priorités et prendre
des mesures
concernant les failles
de sécurité signalées
3
Livre blanc | Sept étapes pour assurer la sécurité logicielle
Etape 2 : Identification des risques et menaces auxquels
est exposé le logiciel
Par nature, la sécurité est l'art d'atténuer les risques. Les applications logicielles qui stockent des
informations personnelles concernant les clients doivent être mieux protégées qu'une application
interne servant à planifier l'utilisation des salles de conférence. Par conséquent, tout comme
vous dresseriez la liste des capacités de votre groupe nécessaires pour créer un logiciel plus sûr,
vous devez déterminer les risques associés à un composant logiciel et les menaces qui planent
sur sa sécurité. L'analyse des risques constitue un domaine en soi et elle est intégrée dans des
solutions commerciales telles que Microsoft ® STRIDE et des approches normatives du type NIST
ASSET. Même si leur mise en œuvre varie, les approches de ce type comptent généralement
de nombreuses étapes détaillées et exigent un lourd investissement en temps. Une technique
plus simple qu'une analyse exhaustive des risques consiste à réaliser une analyse des menaces
portant spécifiquement sur les menaces auxquelles est confrontée une application. L'analyse
des menaces vous aide à éviter les erreurs de sécurité lors de votre conception et s'intéresse
en priorité aux révisions de code et aux tests de sécurité concernant les composants les plus
vulnérables de l'application. C'est la raison pour laquelle vous devriez considérer cette étape
comme l'une des plus importantes à réaliser. Une analyse des menaces simple se divise en
deux phases. La première phase identifie les ressources qu'une application doit protéger et
les ressources les plus importantes. Cette tâche peut être délicate étant donné que certaines
ressources sont plus visibles que d'autres et la nature des ressources varie d'une application à
l'autre. Parmi ces ressources, citons à titre d'exemple les dossiers contenant des informations
personnelles, comme des numéros de carte de crédit, des dossiers de personnel ou de client ou
encore des données financières. Autres exemples : les ressources qu'une organisation fournit
à d'autres, comme des solutions de commerce électronique, des sites Web d'entreprise et une
assistance par e-mail aux clients. En outre, d'autres ressources sont intangibles, comme la
réputation de votre entreprise. Par exemple, quel impact une faille de sécurité peut-elle avoir sur
la crédibilité d'une société ?
La deuxième phase de l'analyse des menaces consiste à comprendre l'application proprement dite
et les dangers auxquels les pirates l'exposent. Les organisations doivent mettre au point un modèle
détaillé représentant les composants et les chemins de flux de données de l'application. La surface
d'attaque de l'application doit être cartographiée et il est essentiel d'identifier les interfaces qui
acceptent la saisie de données de la part des utilisateurs ou l'interaction avec d'autres systèmes.
Les équipes doivent repérer tout point de la surface d'attaque susceptible d'être exploité pour
compromettre l'intégrité, la disponibilité ou la confidentialité d'une ressource. Les applications non
critiques stockées sur le même serveur que des applications critiques doivent aussi être prises en
considération étant donné que leurs failles peuvent également nuire aux applications critiques.
Enfin, classez les menaces en fonction de l'importance de la ressource concernée et de la probabilité
que cette faille soit exploitée. Même si elle est plus simple qu'une analyse complète des risques,
cette analyse des menaces n'en exige pas moins un haut niveau d'expertise concernant l'application
et les méthodes d'attaque des pirates. Toutefois, elle n'a pas besoin d'être précise et peut valoir
largement la peine étant donné qu'elle permet de concentrer ses efforts sur les éléments les
plus importants sans perdre trop de temps. Bien entendu, même l'analyse des menaces la plus
exhaustive ne permet pas d'empêcher l'apparition de failles de sécurité au cours du développement,
ce qui nous amène à l'étape 3.
Etape 3 : Révision du code
Dans l'univers des logiciels, une chose est sûre : le code déployé constitue la véritable instanciation
d'une application. Par conséquent, les organisations se doivent de réviser le code tout au long de la
mise en œuvre et des étapes de test, en quête d'éventuelles failles de sécurité susceptibles d'avoir été
introduites au cours du développement. La plupart du temps, ces révisions permettent de détecter
de nombreuses failles de sécurité qui auraient autrement été déployées. Associée à une analyse des
menaces, cette révision peut permettre à une organisation de vérifier que le logiciel est bien protégé
contre les principales menaces. Actuellement, de nombreux groupes se basent sur des révisions
manuelles du code pour réaliser cette étape. Les contrôles manuels exigent toutefois une grande
expertise en matière de sécurité et prennent énormément de temps. Par chance, il existe des schémas
cohérents et bien documentés de la manière dont les développeurs introduisent des failles de sécurité
dans les applications, ce qui constitue une base pour mettre au point des outils d'analyse de la sécurité
précis et automatisés. Les meilleurs outils d'analyse du code source sont en mesure d'évaluer plusieurs
niveaux et d'effectuer le suivi du flux de données au sein d'une application. Ils peuvent travailler sur
des éléments de code de toute taille, puis présenter et gérer efficacement leurs résultats de manière
à permettre aux contrôleurs d'identifier rapidement les éventuelles failles de sécurité et de définir un
ordre de priorité.
4
Livre blanc | Sept étapes pour assurer la sécurité logicielle
L'analyse du code source de sécurité intégrée aux environnements de développement, du type
Microsoft Visual DevStudio et Eclipse, peut également servir d'outil de base permanent pour les
développeurs. Ces outils fournissent des informations au moment où l'erreur est introduite, ce qui
permet une correction moins coûteuse et une expérience d'apprentissage plus concrète. Voici la liste
des capacités clés nécessaires pour obtenir des outils efficaces de code source de sécurité automatisés :
•Identification complète de nombreux types de vulnérabilités
•Capacité à réaliser, dans le but de réduire les faux positifs, une analyse variée, par exemple, du flux
de données global, du flux de contrôle, des fichiers de configuration
•Capacité à poursuivre l'analyse au-delà des limites de niveau d'une application afin d'identifier des
vulnérabilités que des révisions manuelles ne permettraient pas de détecter
•Nombreuses options de filtrage, d'interrogation et de tri des résultats d'analyse
•Prise en charge de toutes les langues utilisées par vos équipes de développement
•Evolutivité permettant l'application de vos politiques spécifiques en matière de codage sécurisé
•Aide à l'analyse au niveau du bureau des développeurs par le biais de plug-ins d'environnement de
développement intégré (IDE)
Etape 4 : Test et vérification
Le test constitue une technique complémentaire des révisions de code. Il s'agit d'un examen final du
cycle de vie de développement du logiciel sécurisé qui peut en outre être partiellement automatisé.
Attention toutefois : les tests fonctionnels traditionnels ne sont pas efficaces lorsqu'il s'agit de repérer
les failles de sécurité. En règle générale, les tests de qualité des logiciels vérifient en priorité un
ensemble de fonctions déterminées suivant des exigences clairement et raisonnablement définies ou
des actions attendues de la part des utilisateurs. Les tests de sécurité nécessitent d'adopter un état
d'esprit et une approche différents, car il s'agit là, pour les testeurs, de détecter l'absence de sécurité.
Une approche standard consiste à procéder à des tests d'intrusion dans l'application. L'objectif du
test d'intrusion est de simuler des attaques contre le logiciel afin de repérer tout comportement
anormal. Tout comme les révisions de code, ces tests peuvent être réalisés manuellement ou
à l'aide d'un outil automatisé. Au même titre que l'analyse du code source, les tests manuels
d'intrusion permettent de repérer des problèmes complexes qui passeraient autrement inaperçus.
Ils exigent toutefois du temps, des compétences et une expertise dont la plupart des organisations
ne disposent pas. Des outils automatisés peuvent fournir une base de connaissances des attaques
connues et les neutraliser rapidement, mais passent souvent à côté des failles plus subtiles ou
des champs de saisie que les pirates sont susceptibles d'exploiter. De plus, la portée des tests
d'intrusion, c'est-à-dire la proportion d'une application réellement mise à l'épreuve au cours d'un
test d'intrusion, est souvent plus restreinte que la véritable surface d'attaque d'une application.
Une solution consiste à utiliser les résultats de l'analyse du code source pour renforcer le test
d'intrusion. Résultat : (1) les tests tiennent compte de toutes les sources d'entrée et ignorent les
zones invulnérables et (2) la tâche de résolution est considérablement améliorée. Il existe aussi des
produits qui allient les résultats des deux révisions de code et de l'analyse automatisée dynamique,
combinant ainsi les deux approches.
Il n'existe pas de réponse simple en matière de tests de sécurité. Toutefois, l'approche la plus pratique
consiste à ne pas se fier aux tests pour repérer les vulnérabilités. Les tests doivent avant tout vérifier
que les vulnérabilités détectées lors de la révision du code ont été éliminées.
Etape 5 : Mise en place d'un portail de sécurité
Le procédé le plus élémentaire et peut-être le plus efficace pour initier le processus et obtenir
des résultats concrets consiste à mettre en place un "portail" de sécurité. Si une organisation ne
peut se permettre de mettre en œuvre qu'une seule étape, ce doit être celle-ci. Un grand nombre
d'organisations commencent à exiger un portail unique lorsque le logiciel a passé la phase de test,
juste avant de passer en phase d'exploitation ou de production.
Ce portail de "contrôle final" présente l'avantage d'être facile à comprendre et de mettre en évidence
les problèmes de sécurité avant le lancement de l'application. L'inconvénient est qu'en étant mise
en œuvre à un stade tardif du cycle de développement, cette mesure ne laisse pas suffisamment de
temps pour remédier aux problèmes de sécurité détectés dans le code.
5
Livre blanc | Sept étapes pour assurer la sécurité logicielle
De toute évidence, la question centrale consiste à définir les critères qui détermineront si le logiciel
est apte ou non à franchir le portail de sécurité. Un critère pratique peut être la réalisation d'un
contrôle du code. En règle générale, un portail de révision de code, qu'il soit mis en œuvre au
moment du développement, des tests ou en tant que contrôle final avant la mise en production du
logiciel, permet de déceler de nombreuses failles de sécurité. De même, l'analyse dynamique de
l'application en cours d'exécution, comme le ferait un pirate, peut également constituer un portail de
sécurité efficace. L'important est de tester la sécurité de l'application avant son déploiement.
A mesure que les processus de développement sécurisé d'une organisation se précisent, des
critères supplémentaires peuvent faire leur apparition pour assurer l'exécution d'étapes spécifiques
et la résolution des problèmes repérés ; par exemple, une analyse des menaces a été réalisée, des
examens de code ont été menés et les problèmes détectés ont été atténués, des tests de sécurité
ont été conduits, aucune vulnérabilité grave n'a été décelée et les vulnérabilités mineures ont été
corrigées. Ce portail plus exigeant peut également comprendre un contrôle de sécurité spécialisé
réalisé par des experts en sécurité indépendants avant que l'application ne puisse être déclarée
"apte à la production".
Etape 6 : Evaluation
Les organisations doivent évaluer l'efficacité de leurs mesures de sécurité de manière à pouvoir
améliorer le processus et l'adapter aux changements d'exigences. La sécurité logicielle est encore
un domaine émergeant, tout comme les critères de mesure qui permettent d'évaluer l'efficacité des
mesures prises à cet égard. Toutefois, de nombreuses mesures peuvent et doivent être évaluées
afin de fournir des informations concernant l'état de la sécurité logicielle d'une organisation ou
d'un projet. Les organisations peuvent évaluer le respect du processus de sécurité tel qu'il a été
conçu ou mesurer l'efficacité du processus de sécurité lors de sa mise en œuvre. Par exemple,
Microsoft évalue l'efficacité de son SDLC en comptabilisant le nombre de bulletins de sécurité au
cours des douze premiers mois suivant un lancement (voir la figure 3). Si l'évaluation Microsoft
est une évaluation de suivi, les mesures prises lors du développement laissent suffisamment de
temps pour remédier aux vulnérabilités avant le déploiement. Parmi ces critères de mesure, citons
des mesures de suivi comme le classement des vulnérabilités par catégorie, par gravité et au fil du
temps. Par exemple, un projet peut présenter un dépassement de tampon ou des erreurs d'injection
SQL plus fréquentes que de coutume, signe qu'une formation supplémentaire est nécessaire.
Diverses formations sont envisageables, par exemple, concernant la portée et l'historique de
contrôle, l'ancienneté des vulnérabilités et même les mesures de risques composites. L'essentiel
est de commencer la collecte de données très tôt dans le processus, ce qui constituera une base de
référence pendant le développement.
Figure 3. Gravité des vulnérabilités pour le projet Pluton
Critique
Elevée
Moyenne
Critique = 3
Faible = 3
3
3
Moyenne = 1
1
9
Elevée = 9
6
Faible
Livre blanc | Sept étapes pour assurer la sécurité logicielle
Figure 4. Tendances par projet en matière de vulnérabilités
Pluton
Orion
100
75
Failles
25
0
27 déc.
30 déc.
2 janv.
5 janv.
8 janv.
Etape 7 : Education
Une fois que les mesures de sécurité à mettre en œuvre ont été choisies, le problème le plus urgent
consiste à former les intervenants afin qu'ils puissent prendre efficacement les mesures de sécurité
adéquates. Même avec une formation, les développeurs n'ont que peu de chances de devenir des
experts en sécurité, tout d'abord parce qu'ils ont d'autres responsabilités plus urgentes, mais aussi
au vu de la difficulté à devenir un expert en la matière. En règle générale, il s'agira d'attribuer le
rôle de "responsables de la sécurité" à un groupe ou à un ensemble de personnes. Il peut s'agir
de personnes ayant déjà montré de l'intérêt pour les questions de sécurité, de personnes ayant
suivi une formation spécifique en la matière ou de personnes explicitement embauchées à ces
fins. Ces experts seront chargés de mettre en œuvre le plan de sécurité, de bout en bout. Ils seront
essentiels à sa réussite. Toutefois, la présence d'experts en sécurité ne dispense pas les autres de
toute responsabilité en la matière. La sécurité doit être l'affaire de chaque membre de l'organisation,
même lorsque celle-ci n'en est qu'à ses débuts. Un plan de sécurité ne peut être efficace que si
chacun y participe.
Toutefois, étant donné qu'il est impossible d'être responsable d'une question que l'on ne comprend
pas, l'éducation est essentielle. Pour comprendre la sécurité, des connaissances approfondies sont
nécessaires. Les développeurs doivent comprendre la façon de penser des pirates, ce qui rend des
fonctions vulnérables et le nombre de bits que doit comporter un ID de session dans le cas d'un site
recevant sept millions de visites par jour, etc.
Il est impossible pour une organisation de hisser au rang d'expert en sécurité chaque membre de
ses équipes d'architecture, de développement, de contrôle qualité et d'exploitation.
Par conséquent, comment améliorer la sécurité ? Le plan de sécurité à mettre en place pour
répondre aux vulnérabilités implique de développer les meilleures pratiques en interne. Elles
constituent d'excellentes ressources de formation à la sécurité pour les nouveaux ingénieurs et les
plus expérimentés. Pour identifier les erreurs critiques à éviter, pourquoi ne pas se baser en premier
sur celles qui ont été commises par le passé ? L'utilisation des meilleures pratiques développées en
interne en guise d'outils pédagogiques permet d'obtenir des connaissances ciblées et pertinentes en
matière de sécurité.
On envisagera par exemple d'envoyer en formation les personnes impliquées dans le cycle de vie de
développement ou de demander à un expert en sécurité de dispenser une formation sur site.
Les investissements en temps et en argent consacrés à la formation paient toujours, en particulier
dans le cas des six étapes susmentionnées. En fin de compte, la solution consiste à faire de la
sécurité un état d'esprit partagé par l'ensemble du groupe de développement. Chacun doit réfléchir
à ce qui pourrait mal tourner à chaque fois qu'il conçoit une fonction, produit une version ou écrit une
ligne de code. Chacun doit se poser la question suivante : "Comment un pirate pourrait-il tirer parti
de ce que je suis en train de faire ?" Si chacun réfléchit à ce qui pourrait mal tourner à chaque étape,
la sécurité ne peut que s'en trouver améliorée.
7
Livre blanc | Sept étapes pour assurer la sécurité logicielle
Conclusions
La sécurité logicielle constitue un grave problème. Pour atténuer les risques, les organisations de
développement de logiciels doivent commencer à réfléchir à la sécurité à chaque étape du cycle de
vie du développement de logiciels. Les équipes de développement peuvent se baser sur un plan
regroupant sept étapes pratiques pour fournir un logiciel plus sûr :
1. E
valuer l'état actuel de la sécurité logicielle et élaborer un plan de gestion des problèmes de
sécurité tout au long du cycle de vie du développement
2. Identifier les risques et menaces auxquels est exposé le logiciel afin de pouvoir les éliminer avant
leur apparition
3. C
oncevoir un portail qui empêchera la mise en production d'applications présentant
des vulnérabilités
4. Réviser le code pour détecter les failles de sécurité introduites au cours du développement
5. Tester l'application pour détecter les failles de sécurité, en complément des tests fonctionnels
6. M
esurer l'efficacité du plan de sécurité de manière à pouvoir améliorer constamment
le processus
7. F ormer les intervenants en matière de sécurité afin qu'ils puissent mettre en œuvre le plan
de sécurité
Toute organisation de développement peut appliquer ce plan de sécurité et commencer à en tirer les
bénéfices rapidement. L'essentiel est de commencer dès maintenant.
Découvrez HP Fortify sur le site
hp.com/go/fortify
A propos de HP Fortify
Leader sur le marché, la solution HP Fortify permet d'automatiser et de gérer un programme complet
de sécurité logicielle. Mettant à disposition sur site et à la demande les technologies les plus avancées,
HP Fortify permet aux organisations de détecter les failles, de les résoudre et de renforcer l'ensemble
de leurs applications logicielles, qu'il s'agisse de systèmes hérités ou d'applications mobiles actuelles.
Découvrez HP Fortify sur le site
hp.com/go/SIRM
A propos de HP Enterprise Security
HP est l'un des principaux fournisseurs de solutions de sécurité et de conformité pour les entreprises
modernes qui veulent réduire les risques dans leurs environnements hybrides et se protéger contre
des menaces sophistiquées. Basée sur les produits leaders du marché d'ArcSight, de Fortify et de
TippingPoint, la plate-forme HP Security Intelligence and Risk Management (SIRM) est la seule à offrir
aux entreprises la corrélation, la protection des applications et la technologie de sécurité des réseaux
qui protègent les applications et les infrastructures informatiques actuelles contre les cybermenaces.
En savoir plus
hp.com/go/fortify
Abonnez-vous sur
hp.com/go/getupdated
Partager avec des collègues
© Copyright 2013 Hewlett-Packard Development Company, L.P. Les informations contenues dans ce document peuvent être modifiées sans préavis.
Les seules garanties relatives aux produits et services HP sont stipulées dans les déclarations de garantie expresse accompagnant ces produits
et services. Aucune déclaration contenue dans ce document ne peut être interprétée comme constituant une garantie supplémentaire. HP décline
toute responsabilité quant aux éventuelles erreurs ou omissions techniques ou éditoriales.
Microsoft est une marque déposée de Microsoft Corporation aux Etats-Unis.
4AA4-6504FRE, octobre 2013, rév. 1