Grafvision - Fotolia

Actualites

Les systèmes métiers, grands oubliés de la sécurité ?

Juan Pablo Perez Etchegoyen, directeur technique d’Onapsis, souligne la complexité de la sécurisation des applications métiers critiques, SAP notamment, mais pas uniquement.

Valéry Rieß-Marchive
par
Publié le: 26 févr. 2016

Si c’était nécessaire, une étude Ponemon pour Onapsis vient de souligner l’importance des systèmes métiers SAP pour les entreprises : pour 60 % des dirigeants sondés par le cabinet, une attaque sur ceux-ci serait très grave, voire catastrophique, et une indisponibilité coûterait en moyenne 4,5 M$. Pourtant, la sécurité de ces systèmes semble largement négligée.

Des systèmes hautement complexes

Dans un entretien avec la rédaction, Juan Pablo Perez Etchegoyen, directeur technique d’Onapsis explique ainsi que « chez chacun de nos nouveaux clients, nous découvrons des systèmes SAP qui ne sont pas correctement administrés et tendent à être exposés, du fait de vulnérabilités non corrigées, ou encore de défauts de configuration ».

Une situation qu’il impute principalement à « la complexité des systèmes SAP ; les sécuriser est vraiment difficile ». De fait, il souligne qu’une très large majorité de déploiements comportent une importante part de personnalisation : « il n’y a pas, en définitive, deux déploiements SAP identiques ».

Dès lors, les risques associés à des opérations de maintenance que l’on pourrait considérer comme banales sur d’autres systèmes, s’avèrent là particulièrement grands : « l’application d’un même correctif à deux systèmes différents peut entraîner des réactions diamétralement opposées, en raison de toutes ces personnalisations ».

Un écosystème complet, largement opaque

Pour Juan Pablo Perez Etchegoyen, la première condition, pour sécuriser un système métier de type SAP ou autre, consiste sans surprise à acquérir de la visibilité. Comprendre : « est-ce que j’ai implémenté les correctifs ? Suis-je à jour des plus récentes alertes de vulnérabilités ? Suis à jour dans mes configurations, mes listes de contrôle d’accès, mes services, mes protocoles, mes capacités de chiffrement, d’authentification ? »

Et la tâche apparaît d’autant plus complexe qu’il « n’y a pas d’application métier critique isolée. Typiquement, il s’agit d’un grand nombre de serveurs et d’applications interconnectés dans le cadre de relations croisées et d’interfaces ».

C’est donc tout un écosystème qu’il convient de prendre en compte, dans son intégralité. A défaut, « un attaquant pourrait par exemple s’infiltrer dans un système de développement et parcourir l’infrastructure pour compromettre un environnement de production et accéder à des informations métiers critiques ».

D’importantes contraintes de production

Et puis si les applications métiers évoluent dans le temps, c’est généralement suivant des processus phasés très structurés et longuement planifiés. Le parallèle qui vient spontanément à l’esprit est celui des systèmes industriels.

Juan Pablo Perez Etchegoyen y voit d’ailleurs une bonne approche : « dans les deux cas, on parle de systèmes critiques qui doivent fonctionner sans interruption ». Mais la comparaison ne suffit pas. « Il y a bien d’autres systèmes de production critiques auxquels on parvient à appliquer des correctifs, comme les serveurs Web, de messagerie, etc. Parce que l’on sait comment faire et que l’on a l’habitude de le faire depuis longtemps ».

A l’inverse, pour lui, avec les applications métiers, même si les correctifs sont disponibles, « il n’y a finalement que peu de connaissance de la sécurité des systèmes ».

Une culture de la conformité plus que de la sécurité

En fait, pour directeur technique d’Onapsis, la culture de la sécurité des applications métiers critiques apparaît finalement limitée : « il y a cinq ans, lorsque les clients affirmaient faire de la sécurité sur leur système SAP, c’était surtout pour assurer la séparation des tâches. Tout était centré sur la prévention de la fraude et la gestion du risque fonctionnel ». Une question de conformité réglementaire, en somme, poussée notamment par la loi américaine Sarbanes-Oxley.

Et si les choses changent, Juan Pablo Perez Etchegoyen explique que c’est dans ce manque de culture de la sécurité, au-dessus de la couche d’infrastructure, gérée par la DSI, et en-deçà de la couche fonctionnelle, qu’il faut chercher l’origine d’Onapsis. « Cela progresse avec le temps, mais le besoin et le manque de visibilité dans ce domaine persistent ».

Alors pourquoi ne pas intégrer les traces d’activités des applications métiers à des systèmes de gestion des incidents et des événements de sécurité (SIEM) ? « Cela pourrait effectivement aider, mais on ne voit pas les éditeurs de SIEM fournir de telles capacités ». Surtout, il ne s’agit pas seulement d’intégrer des traces… « il faut aussi comprendre le contexte. Et c’est une limite des SIEM ». 

Pour approfondir sur Backup