Désolé, la phrase n'est pas très claire…
Je voulais dire au lecteur pressé qui ne lirait que les 3 premières lignes, que la simulation de MySQL Server est vraiment opérationnelle.
C'est vrai que, par ailleurs, Linux est correctement simulé si on ne couvre pas les aspects réseaux. Il est possible de simuler votre application transactionnelle préférée, comme l'exemple de l'application RBAC le montre.
Il est aussi possible, en prenant la peine de lire attentivement la documentation Javadoc, de simuler un logiciel en configurant une centaine de paramètres. Le plus simple alors est de le dériver d'une simulation existante. Si en plus, on est prêt à coder un module complémentaire en Java, alors là…
Depuis 25 ans que j'observe les états, dont les USA en premier, tenter de mettre en oeuvre des standards d'assurance de sécurité des logiciels, l'échec me semble patent, en gros pour 3 raisons :
Un : cela coûte entre 2 et 5 fois plus cher à développer, et entre 4 et 10 fois plus cher à mettre à jour, parce qu'on ne sait pas bien limiter la charge de vérification de la sécurité lorsqu'une modification limitée du code a été faite.
Deux : les critères de vérification de la sécurité sont régulièrement en retard par rapport à l'inventivité des experts en attaque informatique, bien que les coûts de vérification croissent eux aussi régulièrement.
Trois : personne ne saura jamais démontrer rigoureusement, indiscutablement, la sécurité d'un système complexe, quand on utilise un petit sous-ensemble de briques de sécurité élémentaires qui sont garanties sûres, intégrés dans un vaste ensemble de logiciels sans assurance de sécurité, et utilisés par une organisation donnée, plus ou moins connue et figée.
C'est pourquoi je milite pour la formation et la promotion d'architectes de sécurité capables de bien concevoir la défense en profondeur d'un système complexe. Ce ne sera jamais facile, et il faut procéder de manière à la fois experte et pragmatique, en collaboration avec tous les métiers impliqués de l'entreprise, et en incluant l'organisation.
Investir dans ce domaine me semble infiniment plus urgent que de miser sur l'assurance de sécurité. Car les concepts, le partage d'expérience et les outils pour les architectes de sécurité sont encore trop rares et rudimentaires. Il est possible de faire beaucoup mieux, avec des investissements qui seraient plus utiles et plus pérennes que ceux demandés par l'assurance de sécurité.
[^] # Re: Lapin compris
Posté par pthaz . En réponse à la dépêche Sortie de Access Road 0.7. Évalué à 3.
Désolé, la phrase n'est pas très claire…
Je voulais dire au lecteur pressé qui ne lirait que les 3 premières lignes, que la simulation de MySQL Server est vraiment opérationnelle.
C'est vrai que, par ailleurs, Linux est correctement simulé si on ne couvre pas les aspects réseaux. Il est possible de simuler votre application transactionnelle préférée, comme l'exemple de l'application RBAC le montre.
Il est aussi possible, en prenant la peine de lire attentivement la documentation Javadoc, de simuler un logiciel en configurant une centaine de paramètres. Le plus simple alors est de le dériver d'une simulation existante. Si en plus, on est prêt à coder un module complémentaire en Java, alors là…
# Vive la défense en profondeur conçue par de bons architectes !
Posté par pthaz . En réponse à la dépêche Les gouvernements devraient-ils s'abstenir d'externaliser les développements ?. Évalué à 6.
Un : cela coûte entre 2 et 5 fois plus cher à développer, et entre 4 et 10 fois plus cher à mettre à jour, parce qu'on ne sait pas bien limiter la charge de vérification de la sécurité lorsqu'une modification limitée du code a été faite.
Deux : les critères de vérification de la sécurité sont régulièrement en retard par rapport à l'inventivité des experts en attaque informatique, bien que les coûts de vérification croissent eux aussi régulièrement.
Trois : personne ne saura jamais démontrer rigoureusement, indiscutablement, la sécurité d'un système complexe, quand on utilise un petit sous-ensemble de briques de sécurité élémentaires qui sont garanties sûres, intégrés dans un vaste ensemble de logiciels sans assurance de sécurité, et utilisés par une organisation donnée, plus ou moins connue et figée.
C'est pourquoi je milite pour la formation et la promotion d'architectes de sécurité capables de bien concevoir la défense en profondeur d'un système complexe. Ce ne sera jamais facile, et il faut procéder de manière à la fois experte et pragmatique, en collaboration avec tous les métiers impliqués de l'entreprise, et en incluant l'organisation.
Investir dans ce domaine me semble infiniment plus urgent que de miser sur l'assurance de sécurité. Car les concepts, le partage d'expérience et les outils pour les architectes de sécurité sont encore trop rares et rudimentaires. Il est possible de faire beaucoup mieux, avec des investissements qui seraient plus utiles et plus pérennes que ceux demandés par l'assurance de sécurité.