La plupart des entreprises n'investissent pas suffisamment dans la sécurité des applications

La plupart des entreprises n'investissent pas suffisamment dans la sécurité des applications
jusqu'à ce que survienne une attaque informatique

Pièce jointe 380415

L’intégrité des données des entreprises est davantage menacée aujourd’hui qu’avant à cause de la multiplicité des applications multiplateformes et la facilité avec laquelle l’on peut accéder à ces dernières. Cependant, plus de la moitié des entreprises ne mesurent pas encore l’ampleur de l’exposition de leurs données aux éventuelles cyberattaques. Pour en savoir davantage, les résultats de l’étude mondiale 2018 sur la sécurité des applications menée par l'Institut Ponemon, ont été publiés par Arxan Technologies. L'étude a permis d'interroger près de 1400 professionnels de l'IT et de la sécurité informatique aux États-Unis, dans l'Union européenne et en Asie-Pacifique afin de comprendre les risques auxquels les entreprises sont confrontées lorsqu'elles travaillent dans des environnements non sécurisés.

Les résultats de l’étude 2018 sont sans appel. En effet, les risques d’accès des applications non autorisées s’augmentent et la probabilité d’exécution de ces applications, critiques pour le système d’information, est en hausse. La plupart des entreprises en sont conscientes, mais elles attendent très souvent une attaque entraînant la perte de productivité, de confiance des clients et de revenus, avant de penser à une solution de sécurité.

Rusty Carter, vice-président de la gestion des produits chez Arxan, s’inquiète à ce sujet. Il estime le coût moyen d’une attaque de données à 4 millions de dollars.

Selon l’étude, 75 % des entreprises ont, probablement, subi une cyberattaque matérielle ou une violation de données au cours de la dernière année en raison d'une application compromise. Cependant, 65 % des entreprises disent qu'elles seraient incitées à augmenter les mesures de protection des applications seulement après qu'un utilisateur final ou un client ait été affecté négativement et 48 % estiment que la performance et la rapidité des applications sont plus importantes que la sécurité.

C’est seulement 25 % des personnes interrogées qui déclarent que leur organisation fait un investissement significatif dans des solutions pour prévenir les attaques applicatives, 64 % des répondants se disent très préoccupés par la possibilité d’être piratés via les applications et plus de 54 % prévoient une augmentation des menaces en 2018.

Joe Sander, PDG d'Arxan explique : « Il est inquiétant que tant d'entreprises reconnaissent le risque croissant d'attaques par les applications, mais elles font très peu pour empêcher les violations », il continue en disant : « C'est avoir des pensées rétrogrades, et cela expose les données des clients à un risque important. Il est crucial de placer des investissements de sécurité là où des attaques se produisent. »

Toutefois, 79 % des répondants à l'enquête ont convenu que la capacité de détecter les attaques d'applications « dans la nature » est très importante. Et près de la moitié des répondants à l'enquête disent qu'ils mettraient à jour leur solution de protection des applications aussi souvent ou quotidiennement s'ils avaient une visibilité sur des types d'attaques spécifiques contre leurs applications.

« La capacité de savoir comment les attaques d'applications sont exécutées au fur et à mesure qu'elles se déroulent réduit les possibilités pour les attaquants », explique Sander. « Cette intelligence en temps réel permet aux entreprises de réagir par des contre-mesures directes pour repousser les menaces, et peut aider à valider le besoin d'un investissement dans la sécurité des applications avant qu'il ne soit trop tard. »

Anticiper par la surveillance est une meilleure solution contre les attaques via les applications, aujourd’hui, étant donné que la défense d’un périmètre réseau au moyen de pare-feu est révolue. Détecter et réagir en amont est aujourd’hui devenu nécessaire.

Source : arxan

Et vous ?

:fleche: Selon vous, les entreprises mesurent-elles vraiment, aujourd’hui, l’ampleur de la menace via les applications ?
:fleche: Si elles en sont conscientes, pourquoi négligent-elles l’investissement dans la sécurité ?
:fleche: Selon vous, quelle est la meilleure stratégie de protection contre les attaques via les applications ?

Voir aussi

:fleche: Un spécialiste en sécurité dresse la liste des applications iOS et Android qui sont le plus interdites en entreprise, whatsApp vient en tête sur iOS
:fleche: L'EFF évalue la sécurité des applications de messagerie. Skype, WhatsApp, Viber ou encore Google Hangsout loin de satisfaire les critères souhaités

Citation:

---

Anticiper par la surveillance est une meilleure solution contre les attaques via les applications, aujourd’hui, étant donné que la défense d’un périmètre réseau au moyen de pare-feu est révolue.

---

Mais quelle blague!!! Si les entreprises faisait plus attention à la segmentation de leurs réseaux il y aurait déjà bien moins d'attaques possibles! Aujourd'hui, en 2018, on a encore des boites qui ont des réseaux complètement à plat! Pas de réseau d'administration, pas de segmentation réseau front end/back end, etc...

Oui la surveillance est devenu presque indispensable pour détecter certaines menace, mais avant il y a déjà bien du boulot qui n'a jamais été fait.

Citation:

---

Selon vous, les entreprises mesurent-elles vraiment, aujourd’hui, l’ampleur de la menace via les applications ?

---

Assez peu. Quand je présente à des clients les résultat de l'audit je peux vous dire que je vois leurs cheveux se dresser sur leurs têtes.

Citation:

---

Selon vous, quelle est la meilleure stratégie de protection contre les attaques via les applications ?

---

Programmation aux normes actuelles, sensibilisation de tous les employés selon leur poste, ne pas presser les devs au détriment de la sécurité, budget pour des audits, budget pour patcher, ...

Citation:

---

Pourquoi négligent-elles l’investissement dans la sécurité ?

---

Parce que :
- On n'a pas (ou plus) le temps
- On n'a pas le budget
- Le piratage, ça n'arrive qu'aux autres
- Les données de Mme Michu, ça n'intéresse personne, et même si elles partent dans la nature, qu'est-ce que ça peut bien faire ? (probablement l'excuse la plus courante, quand les arguments manquent)

Citation:

---

la défense d’un périmètre réseau au moyen de pare-feu est révolue

---

Hélas, tout le monde n'en n'a pas encore pris conscience. Le temps où on achetait (très cher) la suite de sécurité d'un grand éditeur (Firewall, anti-virus, ...), sensé prévenir tous les risques, est malheureusement loin d'être révolu et cela a conduit à une certaine appropriation du domaine de la sécurité informatique par les gens des systèmes et réseaux, laissant les développeurs d'application loin de tout cela ...
Le niveau général des développeurs dans le domaine de la sécurité applicative ne pousse pas à l'optimisme. Etant parti prenante de nombreux entretiens dans le monde du web, je constate que même si le top 10 OWASP dit vaguement quelque chose à une grosse moitié des dev, on s'aperçoit qu'il ne sont pas légion à savoir précisément et concrètement quels en sont les tenants et aboutissants.

Citation:

---

Selon vous, quelle est la meilleure stratégie de protection contre les attaques via les applications ?

---

La première stratégie, c'est, en amont, d'empêcher qu'on en prenne le contrôle.
Ensuite, les notions d'attaques/défenses ont été théorisée pendant des millénaires par des professionnels : les militaires. Dans le cas présent, de nombreuses stratégies sont tout à fait opportunes : réduction de la surface d'attaque, confinement, dissuasion, ...

Citation:

---

Envoyé par Stan Adkens

:fleche: Selon vous, les entreprises mesurent-elles vraiment, aujourd’hui, l’ampleur de la menace via les applications ?

---

Absolument pas.
Tant qu'elles ne sont pas fait avoir et qu'il n'y a pas de conséquences business, les décideurs s'en contrefoutent royalement.

Citation:

---

Envoyé par Stan Adkens

:fleche: Si elles en sont conscientes, pourquoi négligent-elles l’investissement dans la sécurité ?

---

Car les budgets sont serrés et que c'est le business avant tout.
La sécurité ne rapporte pas d'argent et les utilisateurs n'en n'ont pas pas conscience donc ce n'est pas une priorité.
Aujourd'hui, tout se décide en fonction du ROI et le ROI de la sécurité est quasi nul.

Même dans des milieux ou les applications sont sensibles, les termes de Sécurité Informatique donnent des boutons à presque tout le monde, et sont réservés aux empêcheurs de tourner en rond.

Sinon, cette news me rappelle ça ;)
http://www.commitstrip.com/fr/2017/0...ve-try-a-hack/

Citation:

---

Envoyé par benjani13

Programmation aux normes actuelles, sensibilisation de tous les employés selon leur poste, ne pas presser les devs au détriment de la sécurité, budget pour des audits, budget pour patcher, ...

---

L'un des gros dangers à venir c'est justement la programmation aux normes actuelles.
Aujourd'hui la norme est la mutliplication de brique dont on ne maitrise absolument rien. Comment s'imaginer que le produit final peut-etre sécurisé? Des failles sont trouvées sur des briques très utilisées (éléctron pas plus tard qu'il y a pas longtemps) alors sur des "petites" briques dont les devs sont de plus en plus friands, c'est assurément un carnage en puissance qui se prépare :aie:.

Citation:

---

Envoyé par John Bournet

Hélas, tout le monde n'en n'a pas encore pris conscience. Le temps où on achetait (très cher) la suite de sécurité d'un grand éditeur (Firewall, anti-virus, ...), sensé prévenir tous les risques, est malheureusement loin d'être révolu et cela a conduit à une certaine appropriation du domaine de la sécurité informatique par les gens des systèmes et réseaux, laissant les développeurs d'application loin de tout cela ...
Le niveau général des développeurs dans le domaine de la sécurité applicative ne pousse pas à l'optimisme. Etant parti prenante de nombreux entretiens dans le monde du web, je constate que même si le top 10 OWASP dit vaguement quelque chose à une grosse moitié des dev, on s'aperçoit qu'il ne sont pas légion à savoir précisément et concrètement quels en sont les tenants et aboutissants.

---

Tu parles du niveau général en sécurité, moi je te parle du niveau général tout court :ptdr:. Moi c'est pire, les anciens développeurs donnaient gratuitement les mots de passes, tous les donneées utilisateurs (addresse, telephone, ...). Parce que Mr le développeur a voulu faire de l'ORM. En plus, il est sensé être expert dedans. Des fois juste le bon sens, n'est pas respecté car ils contrôlent pas la technologie ou la technique.

Des fois c'est juste même culturel, en tant que français dans un pays étranger (je ne citerais pas le pays des bisounous), je râle trop à ce qu'il parait, je peux juste fermé ma gueule pour éviter de trop me la ramener. Mais juste la culture elle-même st trop forte pour faire quoi ce soit. Tu vois mais t'es obligé de fermer les yeux.

Citation:

---

Envoyé par micka132

L'un des gros dangers à venir c'est justement la programmation aux normes actuelles.
Aujourd'hui la norme est la mutliplication de brique dont on ne maitrise absolument rien.

---

Ce que tu décris n'est pas une norme mais un usage. Et effectivement c'est l'usage actuel. Je parlais bien de la prise en compte des normes de sécurité (contre mesure à appliquer pour se prémunir des vulns classiques, algorithmes de chiffrement/hash aux gouts du jour, etc) et des bonnes pratiques, que ce soit dans son propre code ou dans la vérification (tant que possible) de la sécurité des briques tierces. Et justement je mettrai dans les bonnes pratiques de sécurité le fait d'être conscient que les briques tierces ne sont pas exempt de failles, de les tenir à jour, et de rester informer pour obtenir rapidement des informations en cas publication de vulnérabilités sur ces briques.

Citation:

---

Envoyé par micka132

L'un des gros dangers à venir c'est justement la programmation aux normes actuelles.
Aujourd'hui la norme est la mutliplication de brique dont on ne maitrise absolument rien. Comment s'imaginer que le produit final peut-etre sécurisé? Des failles sont trouvées sur des briques très utilisées (éléctron pas plus tard qu'il y a pas longtemps) alors sur des "petites" briques dont les devs sont de plus en plus friands, c'est assurément un carnage en puissance qui se prépare :aie:.

---

La seule norme qui compte aujourd'hui c'est le fric...

1. On utilise des "briques" pour économiser le travail de développement

2. La sécurité des applications n'est pas prise au sérieux parce que le client n'est pas prêt d'en payer le coût

Tout autre argument n'est que de la littérature pour soirée pluvieuse...

Citation:

---

Envoyé par Anselme45

2. La sécurité des applications n'est pas prise au sérieux parce que le client n'est pas prêt d'en payer le coût

---

La question est du coup pourquoi le client n'est pas prêt de payer le coup de la sécurité?

Mon analyse est qu'aux niveaux des prestations de sécurisation, il n'y a que des engagements de moyens, et jamais de résultats. C'est à dire que jamais un presta ne peux dire "Je vous sécurise cette solution à 100%, si un problème arrive, c'est pour ma pomme".
A partir de ce constat, il y a toujours un risque de piratage, et pour le diminuer un peu, il faut augmenter les coûts beaucoup.

Donc quitte à garder un risque, autant diminuer les coûts... entre pas trop de risque et un peu plus, quelle différence?

Citation:

---

Envoyé par AoCannaille

La question est du coup pourquoi le client n'est pas prêt de payer le coup de la sécurité?

Mon analyse est qu'aux niveaux des prestations de sécurisation, il n'y a que des engagements de moyens, et jamais de résultats. C'est à dire que jamais un presta ne peux dire "Je vous sécurise cette solution à 100%, si un problème arrive, c'est pour ma pomme".
A partir de ce constat, il y a toujours un risque de piratage, et pour le diminuer un peu, il faut augmenter les coûts beaucoup.

Donc quitte à garder un risque, autant diminuer les coûts... entre pas trop de risque et un peu plus, quelle différence?

---

Votre analyse est pertinente, mais je crains que les décideurs soient beaucoup plus "basiques" dans leur réflexion :mrgreen:

Quand on gère sa société avec un tableau Excel, il n'y a que le total au fond de l'offre qui compte! J'en veux pour preuve des affaires que l'on a perdu face à des sociétés de développement marocaines qui proposent le développeur au prix de 80 euro/jour! Même le freelance le moins gourmand de France (un mec qui boit de l'eau à la rivière et qui se nourrit en broutant la pelouse du voisin) ne peut pas les concurrencer...

Citation:

---

Envoyé par AoCannaille

La question est du coup pourquoi le client n'est pas prêt de payer le coup de la sécurité?

Mon analyse est qu'aux niveaux des prestations de sécurisation, il n'y a que des engagements de moyens, et jamais de résultats. C'est à dire que jamais un presta ne peux dire "Je vous sécurise cette solution à 100%, si un problème arrive, c'est pour ma pomme".
A partir de ce constat, il y a toujours un risque de piratage, et pour le diminuer un peu, il faut augmenter les coûts beaucoup.

Donc quitte à garder un risque, autant diminuer les coûts... entre pas trop de risque et un peu plus, quelle différence?

---

Pourrais tu préciser ce que tu appelles une "prestation de sécurisation"? Un test d'intrusion (pentest)? Accueillir un développeur spécialisé sécurité dans ton équipe pour un temps?

De ton analyse, ce que je ressors et un problème de process. On développe, puis on sécurise. La oui tu n'auras jamais une application avec une forte sécurité et ça te coutera très cher. Si tu inclues la sécurité tout au long du cycle de développement, depuis le design, ça te coutera bien moins chère et t'as de bonnes chances d'avoir une application robuste. La sécurité je pense peut être vue comme une dette technique, tout comme des bugs que tu laisses trainer en te disant que tu les corrigeras à la fin.

Citation:

---

Envoyé par benjani13

Pourrais tu préciser ce que tu appelles une "prestation de sécurisation"? Un test d'intrusion (pentest)? Accueillir un développeur spécialisé sécurité dans ton équipe pour un temps?

---

Peut importe, n'importe quelle intervention, qu'elle soit ponctuelle où sur la durée, personne en sécurité ne peux prétendre faire qqch d'inviolable.

Citation:

---

De ton analyse, ce que je ressors et un problème de process. On développe, puis on sécurise. La oui tu n'auras jamais une application avec une forte sécurité et ça te coutera très cher. Si tu inclues la sécurité tout au long du cycle de développement, depuis le design, ça te coutera bien moins chère et t'as de bonnes chances d'avoir une application robuste.

---

Pareil, prendre en compte la sécurité et les risques connus dés la conception, c'est bien, mais ça ne garantie pas qu'une forme inconnue arrive (genre oh zut! les processeurs intels sont des passoires! qui l'eut cru? snif snif.)

Citation:

---

La sécurité je pense peut être vue comme une dette technique, tout comme des bugs que tu laisses trainer en te disant que tu les corrigeras à la fin.

---

C'est une façon de voir les chose de manière très développeur et pas chef de projet (et encore moins marketing :aie: ). La dette technique est facilement repérable (analyse statique de code), quantifiable (nombre de lignes de codes incriminées, temps nécessaire à corriger) et la solution est connue.
Beaucoup de failles de sécurités ne sont pas forcément facilement repérable (en particulier si tu y as porté attention dés la conception), quantifiable, et des fois aucune solution n'est disponible...
Et quand tu as corrigé tout ce que tu as repéré, il reste toujours un risque qu'il en traine encore. D'où ce que je disais plus haut : en augmentant le budget, tu limites le risque, mais tu ne pourras jamais l'annuler. D'un point de vu comptable c'est un effort vain, alors autant diminuer l'effort.

Note que je déplore énormément cette façon de voire les chose, évidemment.

Personne ne prétend sécuriser une appli/infra à 100% non.

Pour revenir sur ton précédent message:

Citation:

---

Donc quitte à garder un risque, autant diminuer les coûts... entre pas trop de risque et un peu plus, quelle différence?

---

Oui il est vrai que passer d'un niveau de risque faible à un niveau très faible coute chère. C'est un peu comme si vous avez une bonne porte blindé chez vous, vous avez un niveau de risque faible d'intrusion. Vous pouvez ajouter un sas biométrique avec scanner rétinien, ça coutera très chère, et le niveau de risque sera qu'un peu plus faible.
Par contre si vous avez une vieille porte pourrie qui s'ouvre avec une radio et que vous passez à une bonne porte blindée, là le risque est drastiquement abaissé, pour un coup assez limité.

C'est ce gros gap là, passer d'une sécurité quasi nulle à quelque chose d'assez robuste, qui coute pas très chère mais qui n'est pas mis en place. Faire du code sécurisé ne coute pas plus chère (ça ne prend pas plus de temps) que de faire du code bancale. Pour me répéter c'est de la dette technique semblables aux bugs. Plutôt que de coder comme un goret et de ramasser 200 rapports de bugs, on code correctement dès le début.

Pour le reste, l'avis sur les efforts en vain je reste perplexe. Est-ce que ces même personnes ne mettent pas de porte chez eux car on pourra dans tous les cas l'enfoncer avec un bulldozer? Enfin je ne m'étendrais pas plus là dessus vu que tu ne partage pas cette avis de toute façon.

Bonjour,

Je suis éditeur d'une plateforme de workflow en ligne je préfère être transparent dans l'orientation de mon message.
Cette plateforme est à destination des petites et grandes entreprise et est amenée à manipuler des informations sensibles.
Notre combat vers la sécurisation est permanent.

Plusieurs entreprises pensent que garder les données leur apporte plus de sécurité.

Notre avis est que déléguer cette sécurisation à des experts peut être une solution
pour ceux qui n'ont pas le budget ni les compétences pour sécuriser leurs système d'information.
Et nous savons que ce budget est énorme, nous le dépensons tous les jours.

En effet cela implique de stocker leurs données dans un réseau externe à leur structure.
Mais quelle différence entre un réseau interne et un réseau externe ?
Quel est le pourcentage de ces attaques qui viennent de l'intérieur ?
Et quelle est la difficulté aujourd'hui pour un attaquant de prendre le contrôle d'un poste interne,
sachant que le nombre de postes infectés dans les grandes entreprises est juste effrayant ?


Mon quotidien en tant que RSSI de DAMAaaS, surtout dans un contexte de nouvelle réglementation RGPD,
est d'essayer de changer les réflexes naturels et de donner confiance aux entreprise dans l'utilisation de solutions en ligne, même pour des traitements sensibles.



Bien à vous,
Nicolas THERY
CTO DAMAaaS

Citation:

---

Selon vous, quelle est la meilleure stratégie de protection contre les attaques via les applications ?

---

• NIDS (Suricata pour la signature - Bro pour le comportemental) en amont du réseau et sur certains points sensibles
• Serveur central de gestion des certificats en zone sécurisée (Pour que les NIDS fonctionnent correctement)
• HIDS sur chaque stations importantes
• SIEM/Graylog pour corréler tout ça
• Centreon pour la supervision du trafic et de la santé des services
• Un firewall robuste
• Clustering failover pour la haute disponibilité de Centreon et du SIEM
• Accès par VPN

Voila ton réseau est sécurisé à 99.9% si tu configure bien tout ça.