Pendant le développement et la révision de la politique de sécurité, il faudra
faire des compromis. Comme il n'existe pas de système de sécurité parfait, il
n'y a pas de bonne ou de mauvaise sécurité.
Parfois, il faudra choisir entre adopter une nouvelle technologie et accroître
la sécurité. Il
Les compromis
faut déterminer le degré de tolérance au risque. Si l’on est tenu
au secret professionnel (pour des dossiers médicaux, par exemple), on sera (ou
on devrait être !) plus strict que s’il s’agit de donner des scores de box office
à des sites Internet. Pour déterminer le degré d’acceptation du risque, il faut
prendre en compte les lois régissant la protection des données, leur degré de
confidentialité et leur valeur. Si quelqu’un, par exemple, vole certaines données
pour les vendre à des concurrents, quel sera le préjudice subi ? Moins il y a
de tolérance au risque et plus il faudra de mesures ou des couches de sécurité
pour imposer la politique de sécurité.
Mais il est tout aussi évident que, dans la pratique, pour rester dans la course,
il faut parfois prendre davantage de risques qu’on aimerait le faire. Au fur et
à mesure que les besoins changent et que de nouvelles technologies aident à protéger
les données, on peut être amené à accepter davantage de risques moyennant la mise
en place de nouvelles technologies pour minimiser les risques encourus. Dans certains
cas, il faudra modifier quelques aspects de la politique de sécurité pour refléter
les nouvelles exigences de gestion.
Dans d’autres cas, on préfèrera ne pas modifier la politique et mettre plutôt
en place une » acceptation du risque « . Une acceptation du risque se traduit généralement
par un addendum à la politique de sécurité, qui informe d’un écart bien particulier
par rapport à ce qui est établi, du pourquoi cet addendum est nécessaire, des
procédures de sécurité mises en place pour atténuer le risque et du moment où
cet écart devrait être résolu. Exemple d’acceptation du risque : on consent à
laisser fonctionner un logiciel tiers qui assure une fonction de gestion critique
sur le système, mais ne répond pas aux critères de sécurité des logiciels tiers,
tels que stipulés dans la politique de sécurité de l’entreprise. L’écart doit
s’accompagner d’un accord avant d’acheter le produit, stipulant que le fournisseur
corrigera les problèmes de sécurité dans la prochaine version du logiciel.
| Bibliographie Livres et redbooks Woodbury, Carol et Wayne Madden. Implementing AS/400 Security, 4ème édition. NEWS/400 Books, 2000. OS/400 Security – Reference (SC41-5302-04) Tips and Tools for Securing Your AS/400 (SC41-5300-04) Articles de NEWS/400 et NEWSMAGAZINE |
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Les coûts cachés des merge requests générées par l’IA
- WatchGuard lance Rai, une IA agentique taillée pour les MSP
- Mythos révèle les limites d’un Zero Trust centré sur le réseau
- Faire évoluer la souveraineté des données du statut d’ambition politique à son application opérationnelle
Articles les + lus
Analyse Patch Tuesday Mai 2026
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Avril 2026
À la une de la chaîne Tech
- Analyse Patch Tuesday Mai 2026
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Avril 2026
