Discussion :

[lolo_ici_et_la]

Bonjour,

Sujet sensible et d'actualités la sécurité de nos applications inquiètent de plus en plus notre client.

Il souhaite que nous prouvions que ses applications que nous développons soient sécurisés.

Comment faire ?

- Nos développeurs sont sensibilisées (utilisations de preparedStatement, accès aux pages vérifiés coté serveur, pas de données 'sensibles' dans les url...)
- En phase de recette, test de point sensible (injection sql, url modifiée manuellement...)

Est ce suffisant ?

Utilisez vous des application de tests de faille ?
Ecrivez-vous vous même vos tests de faille ?
Sous-traiter à des spécialiste ?
Comment certifié la sécurité des applications ?

Je suis preneur de vos expériences.

Notre environnement : J2EE, tomcat, wicket, oracle.

Merci !

[Logan Mauzaize]

Pour commencer, je me poserai la question suivante :
Combien me coûtes le manque de sécurité ?

Ensuite il conviendrait de lister les différents points qui posent problème :

• Une personne externe récupère l'information d'un utilisateur
• Un utilisateur accède à des informations qui concernent un autre utilisateur
• Un utilisateur accède à des informations administratives (d'un point de vue applicatif)
• Une personne externe se connecte à l'application
• Une personne fait tomber mon application
• Une personne fait tomber un service de mon application
• Une personne modifie la configuration de mon application
• Une personne modifie un service de mon application
• etc.

Il faut ensuite prioriser et pondérer ses différents points, établir un budget, répartir ce budget.
..

[lolo_ici_et_la]

En effet sécuriser, et éprouver une application à un coût.

Cependant avant de ma lancer dans du chiffrage, je souhaite avoir plutôt des informations techniques.

Comment faire d'un point de vue technique, pour vérifier que l'application est plus ou moins sécurisé.

[Logan Mauzaize]

Il faut identifier les Input/Output qui sont sûrs (échanges internes), moins sûrs (éventuellement les données récupérées d'un fichier de conf, de la base de données) et ceux qui ne le sont pas du tout (entrées utilisateurs).

Et identifier ce qui pourrait être critique (ex: le mot de passe de l'utilisateur dans un page de login), combien de temps ca prendrait pour se rendre compte que l'information est mauvaise (ex: une mauvaise configuration peut empêcher son démarrage ou bloquer une fonctionnalité).

Ensuite il faut établir une liste de "réponses" adaptée. Exemples :

Pour la page de login, soit on utilise un mécanisme complexe en JavaScript, soit on passe en connexion sécurisée type SSL, soit on remplace le mot de passe par un certificat, etc.

Pour une entrée utilisateur, on vérifie son format. Et on évite de planter toute l'application si celle-ci n'est pas conforme à ce qui est attendu.


Concernant le chiffrage, il faudra bien estimer le temps que tu es prêt à perdre à trouver/lister les solutions envisageables à l'un des problèmes de ta liste. Un problème sans importance, tu notes les 2-3 solutions qui te passent par la tête et tu passes au problème suivant. Pour un problème critique, tu chercheras à maximiser le nombre de solution.

Une fois ton analyse terminée. Tu es prêt à chiffrer l'étude de chaque solution envisagée.

[Jimmy_]

Bonjour,

Avant d'appliquer une check list, il faut savoir quelle sont les données sensibles à protéger ?
Dans une grosse entreprise, il y a en général quatre niveau :
C1: Public : L'information est connue et disponible publiquement de tous.

C2: Interne : L'information est en principe connu uniquement dans l'entreprise sans être sensible.

C3: Confidentiel : L'information est protégée et uniquement le personnel habilité peut l'obtenir.

C4: Secret : L'information est protégée et ultra sensible car elle peut nuire à la réputation de l'entreprise, ou la mettre en péril.


Voilà il ne reste plus qu'à savoir dans quelle case vous êtes.

Par exemple un intranet d'entreprise est en C2, tandis qu'un frontal de vente est en C3. Des sites sensibles comme une administration est surement en C4.


Ca sert absolument à rien de faire toute une usine à gaz avec bases chiffrées, https et authentifications fortes si c'est pour afficher la météo du jour.

Classifiez déjà vos informations.

[tchize_]

Une des méthodes de base de sécurisation du code, raisonnablement facile à mettre en place, c'est la revue de code.

Quand le code est prêt (alpha, beta, peu importe) une deuxième équipe qui n'a pas touché à l'application passe en revue le code et le test afin d'y chercher des failles. Idéalement il faut passer par des personnes expérimentée. Cette équipe n'a pas pour but de te démontrer des utilisations de trous de sécurité mais de mettre le doigt sur les choses suspectes.

au delà de ça, il y a les test unitaires, pour s'assurer que toute validation est bien prise en compte.


Enfin, l'environnement d'installation doit aussi faire l'objet d'un audit. Tu peux aussi faire auditer ton application, etc.