Même si les attaques arrivent en général par le réseau, ce sont les outils que nous choisissons et nos pratiques de développement logiciel qui déterminent la résistance des systèmes aux attaques, et non pas l'intervention a priori ou a posteriori d'un ingénieur sécurité. Que de responsabilités !
Voici le résumé d'un guide de survie, "les 6 idées stupides en sécurité informatique", l'expérience montrant que ce sont les idées les plus séduisantes et/ou sensées qui conduisent aux pire catastrophes :

  • Permissions par défaut : une expression à bannir. Le défaut doit être l'interdiction. Le firewall d'un site web qui rejette les URLs malicieuses ? Non, il ne laisse passer que les URLs autorisées.
  • Liste des attaques : mauvaise approche, puisqu'il en arrive de nouvelles tous les jours (80000 virus identifiés). Il est plus facile de lister les utilisations légitimes d'un réseau ou d'une application, et de bannir tout le reste.
  • Pénétration/correction : refuser la logique qui voudrait qu'un logiciel / un système puisse être amélioré au fur et à mesure que ses vulnérabilités sont découvertes. Si c'était le cas, IE serait devenu sûr et le nombre de vulnérabilités découvertes diminuerait. L'alternative ? Concevoir le logiciel avec la sécurité en tête. Des exemples : QMail, Postfix...
  • Les hackers sont cool, il faut les excuser : non, ce sont des sociopathes qui détruisent volontairement.
  • Former les utilisateurs : nécessaire mais insuffisant. Si ça marchait, personne n'ouvrirait plus de pièce jointe exécutable.
  • Agir plutôt qu'attendre : non, car agir vite fait prendre les mauvaises décisions. Mieux vaut attendre d'avoir des retours d'expérience que d'installer la nouvelle passoire juste parce qu'elle est à la mode.
  • un septième point ? A lire directement dans l'article, avec les exemples, assez savoureux.

Autre sujet, même question, celle de la confiance que l'ingénieur peut avoir dans le résultat de ce qu'il produit : les "Observations personnelles sur la sûreté de la navette spatiale" du (grand) physicien Richard Feymann.