La sécurité, c’est les autres
Mettons que vous gérez une SSII. Vous développez un service, vous le sécurisez convenablement, et prenez garde à ce qu’il reste sûr dans la durée. Vous vendez votre service, vos clients sont contents, et au fur et à mesure, votre activité s’étend. Au bout d’un moment, vos clients demanderont à ce que votre service puisse discuter avec celui d’une autre SSII, spécialisée dans un autre domaine. Et là, c’est le drame.
Posons les bases : le futur partenaire dispose d’une API sous la forme d’un service web. Si on s’en tient là, il n’y a rien de choquant à noter. Jusqu’à ce que vous receviez la documentation technique de ladite API. Là commence la longue descente aux enfers. Parce que si vous avez le professionnalisme de traiter la sécurité comme une partie intégrante de votre infrastructure, vous vous apercevez que c’est loin d’être le cas pour les gus d’en face.
Il faut les comprendre, aussi. Se mettre dans la peau d’un gérant qui construit une entreprise autour d’un service qu’il souhaite performant. Sans y être initié, la sécurité est une simple étape barbante et non rentable. C’est vrai, quoi, la disponibilité des développeurs et administrateurs n’est pas infinie,et il est plus important de faire évoluer le service. Et puis c’est pas grave s’il y a des failles, de toutes façons, qui irait vérifier, ou encore les exploiter ? Au pire, si ça arrive, ça ne se verra quasiment pas…
Si vous me permettez une comparaison douteuse, ça reviendrait à dire « je ne vais...